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.