Common queries related to IP SLA

In OpManager, the IP SLA operations are supported only for Cisco devices using the IP SLA technology. OpManager performs the following operations for its IP SLA monitoring:

• ICMP Echo operation: For WAN RTT Monitor
• ICMP Path Echo operation: For Trace Route
• UDP Jitter operation: For VoIP Monitor
• Video operation: For Video monitors

When an IP SLA monitor is configured in OpManager, the following changes are observed:

• The running configuration will be updated with the new monitor configuration.
• Usage of the system resource will increase as the IP SLA monitor at the source consumes a small amount of memory and CPU. Generally, 3 - 12 KB of memory usage and 1- 8% of CPU usage is observed.

OpManager has an intuitive GUI to configure an IP SLA Monitor using SNMP credentials. The prerequisites for an IP SLA Monitor Configuration are:

• The source device should be a Cisco device with IP SLA agent running.
• The device should be configured with the correct SNMP credentials with RW (read-write) community.

The SNMP set operation is done at the device side. This configuration is then applied and saved in the running configuration. Write to memory should be done by the network admin to save the configuration permanently.

The OpManager WAN RTT Monitor monitors the latency between two locations using Cisco's IP SLA. Therefore, one of the locations should be a Cisco router on which the IP SLA agent is enabled (this router will act as the source), and the target can be any IP on the network (this destination need not be CISCO device). For more information. please refer to this article for the prerequisites required to add an IP SLA monitor to OpManager.

As of now, OpManager only supports Cisco IOS and Cisco IOS-XE type switches and routers for IP SLA monitoring in OpManager.

There are three ways in which a notification profile can be associated to an IP SLA monitor:

• From IP SLA settings page.
• From Device Snapshot page.
• From Notification Profiles page.

To learn more, check this page.

This issue occurs due to the incorrect naming of the Vendor. The Vendor name should be specified as 'Cisco' (not Cisco Systems).

This is a device specific issue. Overloading a device may result in not having the resource to support this functionality. Troubleshooting the device can improve the performance and make the necessary resources available for other functionalities. Check for the reasons here:

• No more operation is left to configure in the device or there is not enough resource (CPU/Memory) available to perform the configuration.
• IP SLA Agent is not enabled and Cisco-RTTMON-MIB is not properly implemented.
• The Operation ID is already available in the device and can't be modified.

• sh ip sla application: Shows all types of operations supported
• sh ip sla statistics: Shows complete statistics related to the monitor.
• sh ip sla configuration: Shows configuration related to the monitor.
• sh ip interface brief: To know the IP address that is being used in the monitor configuration.

As of now, IP SLA monitoring in OpManager supports an "apply once threshold settings" at the time of Configuration. The threshold value used at the time configuration is written to the source device configuration. Whenever an update is done from the Threshold Settings page, the update will be applicable for new monitors only.

OpManager's IP SLA WAN monitor keeps track of 2 types of alerts:

• Availability Threshold Violation : If the availability% is less than 100, an alert will be generated. This is calculated as (Total_Completions / Total_Initiations) * 100
• Round Trip Time Threshold Violation: If the Avg_RTT exceeds the RTT Threshold value it will generate an alert.

Check whether the Device Vendor is Cisco or not. Sometimes when applying the template, the vendor name is not updated with the value 'Cisco'.

There are many contributing factors to this. To troubleshoot,

• Use telnet to verify whether the write community is enabled on the device.
• Make sure to enter a valid write community string in the field. The write community string must be enabled in the source.
• The device may be unresponsive due to busy for this instance, please try again.

• Source device must be Cisco device with IP SLA enabled on it.
• Source device should be added in OpManager.
• SNMP with RW Permission should be configured in the source device. Same is used to add SNMP Credential with Read And Write Community and associated to source device properly.
• Source device should be reachable from the OpManager server. Test the reachability using "ping ". If the device is not reachable, make sure that it is reachable.
• For VoIP/Video Monitor, IP SLA responder should be enabled in the destination device (If it is a Cisco Device).
• It is not necessary for the destination device to be added to the OpManager inventory. If it's added for other reason there is no relation with respect to IP SLA Monitor Configuration.

If OpManager's IP SLA monitors have stopped data collection suddenly, it could be because of the following reasons:

• The OIDs may not have been scheduled properly.
  
  What to do? Check for the output of the following query:
  select count(ID), TIMEVAL, GROUPNAME from PolledData where active='true' and POLICYNAME='IPSLA' group by TIMEVAL, GROUPNAME order by GROUPNAME;
  
  For each Row there should be the following set of OIDs
  WAN RTT --> 18
  WAN RTT (pathHop) --> 16
  VoIP --> 44
  Video --> 26
  If for any GroupName, there is more than one record, that monitor might not collect data.


• Due to High Poll Rate
  Polling might not happen in Regular interval of default 5 Mins. It may have delay.


• IP SLA Data is not accumulated at Device Level.
  Due to Connection Initiation Fails between end points. Refer OID to Check the latest operation return code.


• IP SLA Operation scheduler is not running due to Schedule Time not set properly.


• SNMP timeout happens in OpManager

The IP SLA Monitor data poll will be stopped with Status Change marked as Unknown in the UI. The actual IP SLA Monitor however, will remain operational on the source device without any change.

Disabling the IP SLA monitors from OpManager will result in the following:

• The details and configurations will be deleted from OpManager.
• If Read-Write community is properly associated within OpManager, it will not only delete the configuration in source device, but will also remove it from the Running Configuration. The configuration details, however, could be left within the Startup-Configuration.

[ Note: It is recommended that whenever you add/delete an IP SLA monitor from OpManager, update the startup configuration to the source device as well. ]

Possible Reason :

• Test parameters are not properly set and not supported at the device level. Check the Configuration Details under Settings --> Configuration --> IP SLA
  WAN Monitor --> check WAN Test Parameter
  VoIP Monitor --> Check VoIP Call Settings
  Video Monitor --> Check Video Call Settings
  
  Check for Frequency and TimeOut Value. The Frequency should be greater than or equal to Timeout.
  Some devices do not support a timeout of less than 5-10 seconds. The standard recommendation is 60 secs (Default Value)


• SNMP with RW Community is not configured in IP SLA Source Device.


• Network is slow and SNMP Time Out has occurred. In this case increase the SNMP TimeOut of the SNMP Credential from OpManager.


• No enough Resource is available (CPU/Memory) at Source Device. The Source Device itself deny the configuration. Release some monitor (Delete unused Monitor) from Source Device and Try Again.

Jitter is the variance in the inter-packet delay of network traffic. This variance may vary due to network behavior during packet transfer between source and destination. Network slowness, congestion or delay in network (like queuing, arriving through alternate routes, and so on). Useful to diagnose real-time traffic applications such as VoIP, Video Over VoIP, real-time conferencing.
Example: Consider that 10ms is the ideal inter-packet delay.
Positive Jitter: In a scenario when the packets arrive 12ms apart, the traffic is said to have a Positive Jitter of 2.
Negative Jitter: In a scenario when the packets arrive 8ms apart, the traffic is said to have a Negative Jitter of 2.
Conclusion: Positive Jitter values are undesirable. 0 Jitter values is ideal.