I am getting incorrect values for the Cisco IP SLA HTTP sensor, specifically the TCP RTT.

PRTG is reporting the DNS RTT as identical to the TCP Connection RTT value on all my devices. Is it possible there is an error in your OID for that sensor (IOS 12.4-10 through 15.1)?

Article Comments

Could you share some more details? Especially the IP SLA configuration? Just so we could possible recreate the issue within our labs?


Mar, 2016 - Permalink

I am monitoring a Cisco router, IOS 15.1M. (Sorry for the viewing format) Here is command-line snippet for the IP SLA 2 (HTTP probe):

IPSLA operation id: 1
        Latest RTT: 78 milliseconds
Latest operation start time: 12:28:49 EDT Wed Mar 16 2016
Latest operation return code: OK
Latest DNS RTT: 1 ms
Latest TCP Connection RTT: 39 ms
Latest HTTP Transaction RTT: 38 ms
Number of successes: 34
Number of failures: 0
Operation time to live: Forever

IPSLA operation id: 1
        Latest RTT: 92 milliseconds
Latest operation start time: 12:32:49 EDT Wed Mar 16 2016
Latest operation return code: OK
Latest DNS RTT: 1 ms
Latest TCP Connection RTT: 42 ms
Latest HTTP Transaction RTT: 49 ms
Number of successes: 38
Number of failures: 0
Operation time to live: Forever

Now, let's look at the PRTG Live-Data View:
Date Time 	Avg. Round Trip Time (RTT)	DNS RTT	TCP RTT	Transaction RTT	Message Body Octets	Downtime	Coverage
1 to 50 of 121 Items: 50  
 
3/16/2016 12:29:50 PM	78 msec	1 msec	1 msec	39 msec	1,785 #	0 %	100 %
3/16/2016 12:29:50 PM	78 msec	1 msec	1 msec	39 msec	1,785 #	0 %	100 %
3/16/2016 12:29:25 PM	78 msec	1 msec	1 msec	38 msec	1,785 #	0 %	100 %
3/16/2016 12:28:25 PM	94 msec	1 msec	1 msec	46 msec	1,785 #	0 %	100 %

Notice how reported DNS RTT and TCP RTT are identical (1ms). The CML output shows the TCP Connect RTT to be 42ms for the timeslot above.


Mar, 2016 - Permalink

Thanks! I'll let our developer have a look at it.


Mar, 2016 - Permalink

Ok, so is there anyway to do a custom query that presents itself in the same way as the IP SLA module? It appears that your query is only setup to poll 4/5 OIDs (TCP Connect RTT is missing).

. iso (1) . org (3) . dod (6) . internet (1) . private (4) . enterprises (1) . cisco (9) . ciscoMgmt (9) . ciscoRttMonMIB (42) . ciscoRttMonObjects (1)
   |
    - -- rttMonLatestOper (5)
      |
       - -- rttMonLatestHTTPOperTable (1)
      |      |
      |       - -- rttMonLatestHTTPOperEntry (1)
      |         |
      |         | --   rttMonLatestHTTPOperRTT (1)
      |         |
      |         | --   rttMonLatestHTTPOperDNSRTT (2)
      |         |
      |         | --   rttMonLatestHTTPOperTCPConnectRTT (3)
      |         |
      |         | --   rttMonLatestHTTPOperTransactionRTT (4)
      |         |
      |         | --   rttMonLatestHTTPOperMessageBodyOctets (5)
      |         |
      |         | --   rttMonLatestHTTPOperSense (6)
      |         |
      |         | --   rttMonLatestHTTPErrorSenseDescription (7)

Mar, 2016 - Permalink

Hello fti_tywu, thank you for your reply.

As you've shared the MIB tree data, the require information is stored in an SNMP Table rttMonLatestOper. This table is part of the CISCO-RTTMON-MIB.

You should be able to deploy an SNMP Custom Table sensor for this table (The OID of the table is 1.3.6.1.4.1.9.9.42.1.5.1), and there's a guide for setting up SNMP Custom Table Sensors here.

The sensor should be able to query all values stored within that Table, that is:

  • rttMonLatestHTTPOperRTT (1)
  • rttMonLatestHTTPOperDNSRTT (2)
  • rttMonLatestHTTPOperTCPConnectRTT (3)
  • rttMonLatestHTTPOperTransactionRTT (4)
  • rttMonLatestHTTPOperMessageBodyOctets (5)
  • rttMonLatestHTTPOperSense (6)
  • rttMonLatestHTTPErrorSenseDescription (7)

Additional details about the MIB can be found using the Cisco SNMP Object Navigator.

Best Regards,


Mar, 2016 - Permalink