- IP SLAs Overview
- Configuring Auto IP SLAs in IP SLAs Engine 3.0
- Configuring IP SLA - Percentile Support for Filtering Outliers
- Configuring IP SLAs Video Operations
- Configuring IP SLAs UDP Jitter Operations
- IP SLA - Support for OnDemand UDP Probes
- Configuring IP SLAs UDP Jitter Operations for VoIP
- IP SLAs Multicast Support
- Configuring IP SLAs LSP Health Monitor Operations
- Configuring IP SLAs for Metro-Ethernet
- Configuring Cisco IP SLAs ICMP Jitter Operations
- Configuring RTP-Based VoIP Operations
- Configuring VoIP Gatekeeper Registration Delay Operations
- Configuring VoIP Call Setup Monitoring
- Configuring IP SLAs UDP Echo Operations
- Configuring IP SLAs HTTP Operations
- Configuring IP SLAs TCP Connect Operations
- Configuring IP SLAs ICMP Echo Operations
- Configuring IP SLAs ICMP Path Echo Operations
- Configuring IP SLAs ICMP Path Jitter Operations
- Configuring IP SLAs FTP Operations
- Configuring IP SLAs DNS Operations
- Configuring IP SLAs DHCP Operations
- Configuring IP SLAs DLSw+ Operations
- Configuring an IP SLAs Multioperation Scheduler
- Configuring Proactive Threshold Monitoring for IP SLAs Operations
- IP SLAs TWAMP Responder
IP SLAs Configuration Guide, Cisco IOS Release 15M&T
Bias-Free Language
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
- Updated:
- April 25, 2018
Chapter: Configuring Proactive Threshold Monitoring for IP SLAs Operations
Configuring Proactive Threshold Monitoring for IP SLAs Operations
This document describes the proactive monitoring capabilities of IP Service Level Agreements (SLAs) using thresholds and reaction triggering.
- Finding Feature Information
- Information About Proactive Threshold Monitoring
- How to Configure Proactive Threshold Monitoring
- Configuration Examples for Proactive Threshold Monitoring
- Additional References
- Feature Information for IP SLAs Proactive Threshold Monitoring
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
Information About Proactive Threshold Monitoring
IP SLAs Reaction Configuration
IP SLAs reactions are configured to trigger when a monitored value exceeds or falls below a specified level or when a monitored event, such as a timeout or connection loss, occurs. If IP SLAs measures too high or too low of any configured reaction, IP SLAs can generate a notification to a network management application or trigger another IP SLA operation to gather more data.
When an IP SLA operation is triggered, the (triggered) target operation starts and continues to run independently and without knowledge of the condition of the triggering operation. The target operation continues to run until its life expires, as specified by the target operation's configured lifetime value. The target operation must finish its life before it can be triggered again.
In Cisco IOS Release 15.2(3) and later releases, the (triggered) target operation runs until the condition-cleared event. After which the target operation gracefully stops and the state of the target operation changes from Active to Pending so it can be triggered again.
Supported Reactions by IP SLAs Operation
The tables below list which reactions are supported for each IP SLA operation.
|
Reaction |
ICMP Echo |
Path Echo |
UDP Jitter |
UDP Echo |
TCP Connect |
DHCP |
DLSW |
ICMP Jitter |
DNS |
Frame Relay |
|---|---|---|---|---|---|---|---|---|---|---|
|
Failure |
Y |
-- |
Y |
Y |
Y |
Y |
-- |
Y |
Y |
-- |
|
RTT |
Y |
Y |
-- |
Y |
Y |
Y |
Y |
-- |
Y |
Y |
|
RTTAvg |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
timeout |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
|
connectionLoss |
-- |
-- |
Y |
Y |
Y |
-- |
-- |
-- |
-- |
|
|
verifyError |
-- |
-- |
Y |
Y |
-- |
-- |
-- |
Y |
-- |
Y |
|
jitterSDAvg |
-- |
-- |
Y |
-- |
-- |
-- |
|
Y |
-- |
-- |
|
jitterAvg |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
packetLateArrival |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
packetOutOfSequence |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
MaxOfPostiveSD |
-- |
-- |
Y |
-- |
-- |
-- |
|
Y |
-- |
-- |
|
MaxOfNegativeSD |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
MaxOfPostiveDS |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
MaxOfNegativeDS |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
MOS |
-- |
-- |
Y |
-- |
-- |
-- |
|
-- |
-- |
-- |
|
ICPIF |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
PacketLossDS |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
PacketLossSD |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
PacketMIA |
-- |
-- |
Y |
-- |
-- |
-- |
|
-- |
-- |
-- |
|
iaJitterDS |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
frameLossDS |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
mosLQDSS |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
mosCQDS |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
rfactorDS |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
iaJitterSD |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
successivePacketLoss |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
MaxOfLatencyDS |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
MaxOfLatencySD |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
LatencyDS |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
LatencySD |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
packetLoss |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
Reaction |
HTTP |
SLM |
RTP |
FTP |
Lsp Trace |
Post delay |
Path Jitter |
LSP Ping |
Gatekeeper Registration |
|---|---|---|---|---|---|---|---|---|---|
|
Failure |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
RTT |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
Y |
|
RTTAvg |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
timeout |
Y |
Y |
Y |
Y |
-- |
Y |
Y |
Y |
Y |
|
connectionLoss |
Y |
|
Y |
Y |
Y |
-- |
-- |
Y |
-- |
|
verifyError |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
jitterSDAvg |
-- |
-- |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
jitterAvg |
-- |
-- |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
packetLateArrival |
-- |
-- |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
packetOutOfSequence |
-- |
-- |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
MaxOfPostiveSD |
-- |
-- |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
MaxOfNegativeSD |
-- |
-- |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
MaxOfPostiveDS |
-- |
-- |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
MaxOfNegativeDS |
-- |
-- |
-- |
-- |
-- |
-- |
Y |
-- |
-- |
|
MOS |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
ICPIF |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
PacketLossDS |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
-- |
-- |
|
PacketLossSD |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
-- |
-- |
|
PacketMIA |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
-- |
-- |
|
iaJitterDS |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
-- |
-- |
|
frameLossDS |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
-- |
-- |
|
mosLQDSS |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
-- |
-- |
|
mosCQDS |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
-- |
-- |
|
rfactorDS |
-- |
-- |
Y |
|
|
|
|
|
|
|
iaJitterSD |
-- |
-- |
Y |
-- |
-- |
-- |
-- |
-- |
-- |
|
successivePacketLoss |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
MaxOfLatencyDS |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
MaxOfLatencySD |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
LatencyDS |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
LatencySD |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
|
packetLoss |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
-- |
IP SLAs Threshold Monitoring and Notifications
IP SLAs supports proactive threshold monitoring and notifications for performance parameters such as average jitter, unidirectional latency, bidirectional round-trip time (RTT), and connectivity for most IP SLAs operations. The proactive monitoring capability also provides options for configuring reaction thresholds for important VoIP related parameters including unidirectional jitter, unidirectional packet loss, and unidirectional VoIP voice quality scoring.
Notifications for IP SLAs are configured as a triggered reaction. Packet loss, jitter, and Mean Operation Score (MOS) statistics are specific to IP SLAs jitter operations. Notifications can be generated for violations in either direction (source-to-destination and destination-to-source) or for out-of-range RTT values for packet loss and jitter. Events, such as traps, are triggered when the RTT value rises above or falls below a specified threshold.
IP SLAs can generate system logging (syslog) messages when a reaction condition occurs. System logging messages can be sent as Simple Network Management Protocol (SNMP) traps (notifications) using the CISCO-RTTMON-MIB. SNMP traps for IP SLAs are supported by the CISCO-RTTMON-MIB and CISCO-SYSLOG-MIB.
Severity levels in the CISCO-SYSLOG-MIB are defined as follows: SyslogSeverity INTEGER {emergency(1), alert(2), critical(3), error(4), warning(5), notice(6), info(7), debug(8)}
The values for severity levels are defined differently for the system logging process in software. Severity levels for the system logging process in Cisco software are defined as follows: {emergency (0), alert (1), critical (2), error (3), warning (4), notice (5), informational (6), debugging (7)}.
IP SLAs Threshold violations are logged as level 6 (informational) within the Cisco system logging process but are sent as level 7 (info) traps from the CISCO-SYSLOG-MIB.
Notifications are not issued for every occurrence of a threshold violation. The figure below illustrates the sequence for a triggered reaction that occurs when the monitored element exceeds the upper threshold. An event is sent and a notification is issued when the rising threshold is exceeded for the first time. Subsequent threshold-exceeded notifications are issued only after the monitored value falls below the falling threshold before exceeding the rising threshold ag ain .
|
1 |
An event is sent and a threshold-exceeded notification is issued when the rising threshold is exceeded for the first time. |
|
2 |
Consecutive over-rising threshold violations occur without issuing additional notifications. |
|
3 |
The monitored value goes below the falling threshold. |
|
4 |
Another threshold-exceeded notification is issued when the rising threshold is exceeded only after the monitored value first fell below the falling threshold. |
 Note | A lower-threshold notification is also issued the first time that the monitored element falls below the falling threshold (3). As described, subsequent notifications for lower-threshold violations will be issued only after the rising threshold is exceeded before the monitored value falls below the falling threshold again. |
RTT Reactions for Jitter Operations
RTT reactions for jitter operations are triggered only at the end of the operation and use the latest value for the return-trip time (LatestRTT), which matches the value of the average return-trip time (RTTAvg).
SNMP traps for RTT for jitter operations are based on the value of the average return-trip time (RTTAvg) for the whole operation and do not include RTT values for each individual packet sent during the operation. For example, if the average is below the threshold, up to half of the packets can actually be above threshold but this detail is not included in the notification because the value is for the whole operation only.
Only syslog messages are supported for RTTAvg threshold violations. Syslog nmessages are sent from the CISCO-RTTMON-MIB.
How to Configure Proactive Threshold Monitoring
Configuring Proactive Threshold Monitoring
Perform this task to configure thresholds and reactive triggering for generating traps or starting another operation.
1.
enable
2.
configure
terminal
3.
ip
sla
reaction-configuration
operation-number
react
monitored-element
[action-type
option] [threshold-type {average [number-of-measurements] |
consecutive
[occurrences] |
immediate |
never |
xofy [x-value
y-value]}] [threshold-value
upper-threshold
lower-threshold]
4.
ip
sla
reaction-trigger
operation-number
target-operation
5.
ip
sla
logging
traps
7.
snmp-server
host
{hostname |
ip-address}
[vrf
vrf-name]
[traps |
informs]
[version
{1 |
2c |
3 [auth |
noauth |
priv]}]
community-string [udp-port
port] [notification-type]
8.
exit
9.
show
ip
sla
reaction-
configuration
[operation-number]
10.
show
ip
sla
reaction-
trigger
[operation-number]
DETAILED STEPS
Configuration Examples for Proactive Threshold Monitoring
- Example Configuring an IP SLAs Reaction Configuration
- Example Verifying an IP SLAs Reaction Configuration
- Example Triggering SNMP Notifications
Example Configuring an IP SLAs Reaction Configuration
In the following example, IP SLAs operation 10 is configured to send an SNMP logging trap when the MOS value either exceeds 4.9 (best quality) or falls below 2.5 (poor quality):
Device(config)# ip sla reaction-configuration 10 react mos threshold-type immediate threshold-value 490 250 action-type trapOnly
The following example shows the default configuration for the ip sla reaction-configuration command:
Device# show ip sla reaction-configuration 1 Entry number: 1 Reaction Configuration not configured Device# configure terminal Enter configuration commands, one per line. End with CNTL/Z. Device(config)# ip sla reaction-configuration 1 Device(config)# do show ip sla reaction-configuration 1 Entry number: 1 Reaction: rtt Threshold Type: Never Rising (milliseconds): 5000 Falling (milliseconds): 3000 Threshold Count: 5 Threshold Count2: 5 Action Type: None
Example Verifying an IP SLAs Reaction Configuration
The following example shows that multiple monitored elements are configured for the IP SLAs operation (1), as indicated by the values of Reaction: in the output:
Device# show ip sla reaction-configuration Entry Number: 1 Reaction: RTT Threshold type: Never Rising (milliseconds): 5000 Falling (milliseconds): 3000 Threshold Count: 5 Threshold Count2: 5 Action Type: None Reaction: jitterDSAvg Threshold type: average Rising (milliseconds): 5 Falling (milliseconds): 3 Threshold Count: 5 Threshold Count2: 5 Action Type: triggerOnly Reaction: jitterDSAvg Threshold type: immediate Rising (milliseconds): 5 Falling (milliseconds): 3 Threshold Count: 5 Threshold Count2: 5 Action Type: trapOnly Reaction: PacketLossSD Threshold type: immediate Rising (milliseconds): 5 Threshold Falling (milliseconds): 3 Threshold Count: 5 Threshold Count2: 5 Action Type: trapOnly
Example Triggering SNMP Notifications
The following example shows how to configure proactive threshold monitoring so that CISCO-SYSLOG-MIB traps are sent to the remote host at 10.1.1.1 if the threshold values for RTT or VoIP MOS are violated:
! Configure the operation on source. Device(config)# ip sla 1 Device(config-ip-sla)# udp-jitter 10.1.1.1 3000 codec g711alaw Device(config-ip-sla-jitter)# exit Device(config)# ip sla schedule 1 start now life forever ! Configure thresholds and reactions. Device(config)# ip sla reaction-configuration 1 react rtt threshold-type immediate threshold-value 3000 2000 action-type trapOnly Device(config)# ip sla reaction-configuration 1 react MOS threshold-type consecutive 4 threshold-value 390 220 action-type trapOnly Device(config)# ip sla logging traps ! The following command sends traps to the specified remote host. Device(config)# snmp-server host 10.1.1.1 version 2c public syslog ! The following command is needed for the system to generate CISCO-SYSLOG-MIB traps. Device(config)# snmp-server enable traps syslog
The following sample system logging messages shows that IP SLAs threshold violation notifications are generated as level 6 (informational) in the Cisco system logging process:
3d18h:%RTT-6-SAATHRESHOLD:RTR(11):Threshold exceeded for MOS
This following sample SNMP notification from the CISCO-SYSLOG-MIB for the same violation is a level 7 (info) notification:
3d18h:SNMP:V2 Trap, reqid 2, errstat 0, erridx 0 sysUpTime.0 = 32613038 snmpTrapOID.0 = ciscoSyslogMIB.2.0.1 clogHistoryEntry.2.71 = RTT clogHistoryEntry.3.71 = 7 clogHistoryEntry.4.71 = SAATHRESHOLD clogHistoryEntry.5.71 = RTR(11):Threshold exceeded for MOS clogHistoryEntry.6.71 = 32613037
Additional References
Related Documents
|
Related Topic |
Document Title |
|---|---|
|
Cisco IOS commands |
|
|
Cisco IOS IP SLAs commands |
MIBs
|
MIBs |
MIBs Link |
|---|---|
|
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL: |
Technical Assistance
|
Description |
Link |
|---|---|
|
The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password. |
Feature Information for IP SLAs Proactive Threshold Monitoring
The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.|
Feature Name |
Releases |
Feature Information |
|---|---|---|
|
IP SLAs - Reaction Threshold |
Cisco IOS IP SLAs proactive threshold monitoring capability allows you to configure an IP SLAs operation to react to certain measured network conditions. |
|
|
IP SLAs - VoIP Traps |
The IP SLA - VoIP Traps feature includes new capabilities for configuring reaction thresholds for important VoIP related parameters such as unidirectional jitter, unidirectional packet loss, and unidirectional VoIP voice quality scoring (MOS scores). |
|
|
IP SLAs Additional Threshold Traps |
This enhancement for IP SLAs reaction threshold monitoring includes per direction average jitter, per direction packet loss, maximum positive and negative jitter, and Mean Opinion Score (MOS) traps. The feature also enables one-way latency jitter, packet loss and latency traps within IP SLAs and includes traps for packet loss due to missing in action and late arrivals. |
Feedback