Cannot setup IPSLA JitterMoS Response Path

Document ID : KB000048206
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

Cannot setup a IPSLA JitterMoS Response Path because it does not show up to be selected.

But the CLI output on the Cisco device shows the Application is supported.

During discovery using Response technology, the code queries the device mib for the following OIDs. The results are stored as the Response Source element's attribute

which are passed to the OneClick UI - Protocol --> Type: dropdown list when creating a Response Path.

rttMonApplSupportedProtocolsValid 1.3.6.1.4.1.9.9.42.1.1.8.1.2


1.3.6.1.4.1.9.9.42.1.1.8.1.2.0, Integer     , 2
1.3.6.1.4.1.9.9.42.1.1.8.1.2.1, Integer     , 2
1.3.6.1.4.1.9.9.42.1.1.8.1.2.2, Integer     , 1
1.3.6.1.4.1.9.9.42.1.1.8.1.2.3, Integer     , 1
1.3.6.1.4.1.9.9.42.1.1.8.1.2.4, Integer     , 1
1.3.6.1.4.1.9.9.42.1.1.8.1.2.5, Integer     , 1
1.3.6.1.4.1.9.9.42.1.1.8.1.2.6, Integer     , 2
1.3.6.1.4.1.9.9.42.1.1.8.1.2.7, Integer     , 2
1.3.6.1.4.1.9.9.42.1.1.8.1.2.8, Integer     , 2
1.3.6.1.4.1.9.9.42.1.1.8.1.2.9, Integer     , 2
<snipped>

A value of 1 means the protocol is supported, a value of 2 means the protocol is not supported.

The rttMonApplSupportedProtocols OID maps the index number to protocol

name. For example index 27 represents Jitter.

Protocols from the CISCO-RTTMON-MIB:


SYNTAX       INTEGER
 {
   notApplicable(1),
   ipIcmpEcho(2),
   ipUdpEchoAppl(3),
   snaRUEcho(4),
   snaLU0EchoAppl(5),
   snaLU2EchoAppl(6),
   snaLU62Echo(7),
   snaLU62EchoAppl(8),
   appleTalkEcho(9),
   appleTalkEchoAppl(10),
   decNetEcho(11),
   decNetEchoAppl(12),
   ipxEcho(13),
   ipxEchoAppl(14),
   isoClnsEcho(15),
   isoClnsEchoAppl(16),
   vinesEcho(17),
   vinesEchoAppl(18),
   xnsEcho(19),
   xnsEchoAppl(20),
   apolloEcho(21),
  apolloEchoAppl(22),
   netbiosE.choAppl(23),
   ipTcpConn(24),
   httpAppl(25),
   dnsAppl(26),
   jitterAppl(27),
   dlswAppl(28),
   dhcpAppl(29),
   ftpAppl(30)

In this case, jitterAppl(27 did not exist in the agent mib.

Solution:

Cisco confirmed this was a bug in the IOS version 15.1(3)S, which is the reason we are not able to do snmp queries to the rttMonMIB.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtw78343