IP SLA Statistics Reliable?
Hi,
I have 2 routers configured with IP SLA udp jitter monitoring both as source and destination. They are connected over a private fiber link. But the statistics has never been of any similiarity. One constantly shows a large number of packet loss, while the other shows little. Can one IP SLA operation send that large number of packets? Can someone explain this please?
Thanks in advance.
3845 is configured as:
ip sla responder
ip sla 1
udp-jitter 192.168.176.50 17000 codec g729a
tos 184
ip sla schedule 1 life forever start-time now
1841 is configured as:
ip sla responder
ip sla 1
udp-jitter 192.168.176.51 17000 codec g729a
tos 184
ip sla schedule 1 life forever start-time now
==========================================
on 3845:
sh ip sla stati 1
Round Trip Time (RTT) for Index 1
Latest RTT: 4 milliseconds
Latest operation start time: 13:33:54.880 NZDT Tue Sep 28 2010
Latest operation return code: OK
RTT Values:
Number Of RTT: 999 RTT Min/Avg/Max: 3/4/37 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 999
Source to Destination Latency one way Min/Avg/Max: 3/3/36 milliseconds
Destination to Source Latency one way Min/Avg/Max: 1/0/2 milliseconds
Jitter Time:
Number of Jitter Samples: 997
Source to Destination Jitter Min/Avg/Max: 1/1/32 milliseconds
Destination to Source Jitter Min/Avg/Max: 1/1/2 milliseconds
Packet Loss Values:
Loss Source to Destination: 1 Loss Destination to Source: 0
Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 11
MOS score: 4.06
Number of successes: 59
Number of failures: 0
Operation time to live: Forever
On 1841:
sh ip sla stati 1
IPSLAs Latest Operation Statistics
IPSLA operation id: 1
Latest RTT: 4 milliseconds
Latest operation start time: 13:34:16.498 NZDT Tue Sep 28 2010
Latest operation return code: Over threshold
RTT Values:
Number Of RTT: 999 RTT Min/Avg/Max: 3/4/7 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 510
Source to Destination Latency one way Min/Avg/Max: 1/1/2 milliseconds
Destination to Source Latency one way Min/Avg/Max: 3/3/6 milliseconds
Jitter Time:
Number of SD Jitter Samples: 509
Number of DS Jitter Samples: 508
Source to Destination Jitter Min/Avg/Max: 0/122189/62193664 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/1/3 milliseconds
Packet Loss Values:
Loss Source to Destination: 4294966376 Loss Destination to Source: 716
Out Of Sequence: 233 Tail Drop: 4294966836
Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 11
MOS score: 4.06
Number of successes: 55
Number of failures: 0
Operation time to live: Forever
Looks like 2 different IOS version judging by the output differences, but output should be accurate.
Here is the white papaer for udp jitter:
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6555/ps6602/prod_white_paper0900aecd804fb392.pdf
Looks like the 1841 is reporting a lot more drops to be sure.
However the MOS score and impairment factors are the same for both directions.
I would try clearing the counters and see if the drops reappear, if not, possibly some transient issue
led to this and the results are cumulitive.
Command refernce for this output is here:
http://www.cisco.com/en/US/partner/docs/ios/ipsla/command/reference/sla_04.html#wp1074642
Hope this helps.
Similar Messages
-
Show IP SLA statistics output definitions
Does anyone have a link or documentation that defines ALL the fields in a show ip sla statistics command? Some are clearly obvious, but in Packet Loss Values for instance what are the measurement values for Source to Destination Loss Periods Number: or Source to Destination Loss Periods Number: ?
IPSLA operation id: 8502
Start Time Index: 13:56:14 UTC Tue Mar 25 2014
Type of operation: udp-jitter
Voice Scores:
MinOfICPIF: 0 MaxOfICPIF: 0 MinOfMOS: 0 MaxOfMOS: 0
RTT Values:
Number Of RTT: 48157 RTT Min/Avg/Max: 54/56/503 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Jitter Time:
Number of SD Jitter Samples: 43824
Number of DS Jitter Samples: 43824
Source to Destination Jitter Min/Avg/Max: 0/1/142 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/1/81 milliseconds
Packet Loss Values:
Loss Source to Destination: 96
Source to Destination Loss Periods Number: 796
Source to Destination Loss Period Length Min/Max: 1/17
Source to Destination Inter Loss Period Length Min/Max: 1/2828
Loss Destination to Source: 5746
Destination to Source Loss Periods Number: 4319
Destination to Source Loss Period Length Min/Max: 1/17
Destination to Source Inter Loss Period Length Min/Max: 1/321
Out Of Sequence: 0 Tail Drop: 1
Packet Late Arrival: 0 Packet Skipped: 0
Number of successes: 18
Number of failures: 30this is a great document as well, but doesn't dive down deep enough. The best example would be Packet Loss, where is says -
Packet Loss
Five types of packet loss or assimilated events can be measured with IP SLA:
Packet loss in the source to destination (packetLossSD)
Packet loss in the destination source (packetLossDS)
Tail Drop: we know it has been dropped, but we do not know in which direction. This is when the last packet(s) of the test streams were dropped, because in this case, we do not receive the sequence numbers. In older releases, this is called Packet MIA for missing in action. In the MIB, the notation PacketMIA is still in use.
Packet Late Arrival: the packet did arrive, but so late that the underlying application probably considered it as dropped, or at least not useful. Think about a VoIP application. If one packet arrives much later than expected, it is too late because the conversation keeps going. This packet is assimilated to a drop.
Packet Misordering: the packet arrived but not in the right order. This may or may not be considered as a packet drop. (packetOutOfOrder)
The cool thing is the power that lies behind those numbers. Differenct values can be calculated the way you want it. For instance the total amount of packet dropped is:
packetDropped = RTTMonPacketLossSD + RTTMonPacketLossDS + RTTMonPacketMIA
The total percentage of packets that have dropped during the instance is:
drop_rate_%age = 100 * packetDropped / (RTTMonNumOfRTT + packetDropped)
Many other values can be calculated, and that is entirely up to you to decide what parameters are important.
But does not address the fields that I am looking for -
Source to Destination Loss Period Length Min/Max: 1/17
Source to Destination Inter Loss Period Length Min/Max: 1/2828
Destination to Source Loss Periods Number: 4319
Destination to Source Loss Period Length Min/Max: 1/17
Destination to Source Inter Loss Period Length Min/Max: 1/321
appreciate all the input though Vinod! -
Hello
I would like to track icmp jitter for end host. I verified in documentation that it can be any host as a destination. But i got error on this operation:
Latest RTT: NoConnection/Busy/Timeout
I verified that there is no firewall between the source and destination and icmp timestamp request works when done manually:
r01#ping
Protocol [ip]:
Target IP address: 10.23.33.6
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]: Timestamp
Number of timestamps [ 9 ]:
Loose, Strict, Record, Timestamp, Verbose[TV]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.23.33.6, timeout is 2 seconds:
Packet has IP options: Total option bytes= 40, padded length=40
Timestamp: Type 0. Overflows: 0 length 40, ptr 5
>>Current pointer<<
Time= 01:00:00.000 CET (00000000)
Time= 01:00:00.000 CET (00000000)
Time= 01:00:00.000 CET (00000000)
Time= 01:00:00.000 CET (00000000)
Time= 01:00:00.000 CET (00000000)
Time= 01:00:00.000 CET (00000000)
Time= 01:00:00.000 CET (00000000)
Time= 01:00:00.000 CET (00000000)
Time= 01:00:00.000 CET (00000000)
Reply to request 0 (4 ms). Received packet has no options
Reply to request 1 (4 ms). Received packet has no options
Reply to request 2 (1 ms). Received packet has no options
Reply to request 3 (1 ms). Received packet has no options
Reply to request 4 (1 ms). Received packet has no options
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
r01#sh ip sla statistics 196
IPSLAs Latest Operation Statistics
IPSLA operation id: 196
Type of operation: icmp-jitter
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 12:45:21.019 CET Fri Nov 21 2014
Latest operation return code: Timeout
RTT Values:
Number Of RTT: 0 RTT Min/Avg/Max: 0/0/0
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0
Destination to Source Latency one way Min/Avg/Max: 0/0/0
Jitter Time:
Number of SD Jitter Samples: 0
Number of DS Jitter Samples: 0
Source to Destination Jitter Min/Avg/Max: 0/0/0
Destination to Source Jitter Min/Avg/Max: 0/0/0
Packet Late Arrival: 0
Out Of Sequence: 0
Source to Destination: 0 Destination to Source 0
In both Directions: 0
Packet Skipped: 0 Packet Unprocessed: 0
Packet Loss: 0
Loss Period Length Min/Max: 0/0
Number of successes: 0
Number of failures: 34
ip sla 197
icmp-jitter 10.23.33.6
frequency 30
ip sla schedule 197 life forever start-time now
Nov 21 12:57:43: IP SLAs(197) Scheduler: saaSchedulerEventWakeup
Nov 21 12:57:43: IP SLAs(197) Scheduler: Starting an operation
Nov 21 12:57:43: IP SLAs(197) icmpjitter operation: Starting icmpjitter operation
Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
Nov 21 12:57:49: IP SLAs(197) Scheduler: Updating result
Nov 21 12:57:49: IP SLAs(197) Scheduler: start wakeup timer, delay = 24796
Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
Nov 21 12:57:49: IP SLAs(197) icmpjitter operation: Timeout
Any help would be appreciated.Hi Jorge
According to Cisco documentation icmp-jitter should work on any IP Device.
I have a similar issue.
1. I can run icmp-jitter successfully to non cisco routers
2. it fails to run to a generic ip device.
Imran -
IP SLA stats - one-way latency / MOS score 4.34 not updating
I'm trying to use Cisco IP SLA to bench mark voice traffic peformance before and after I apply QoS to the network.
* I've setup IP SLA in both directions over a DSL connection between a 7600, and an 1801
* I've setup IP SLA in both directions over an Ethernet WAN link between a 7200 and another 7200
ip sla 1
udp-jitter 10.101.1.1 32770 source-ip 10.101.2.1 source-port 32770 codec g711alaw
frequency 30
ip sla schedule 1 life forever start-time now
ip sla responder
I have a problem in that I'm not getting any meaningful data from the IP SLA statistics for Voice Score Values:, or any data for Latency one-way time: for any of my tests(x 4).
After a day of testing it seems the MOS score never changes from 4.34, and the ICPIF never changes from 1
Is there something wrong with my config? Is this working properly or could this be a bug?
ADSL-R1#show ip sla statistics 1 details
Round Trip Time (RTT) for Index 1
Latest RTT: 48 milliseconds
Latest operation start time: *09:27:48.435 UTC Thu Jul 5 2012
Latest operation return code: OK
Over thresholds occurred: FALSE
RTT Values:
Number Of RTT: 999 RTT Min/Avg/Max: 45/48/89 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Source to Destination Latency one way Sum/Sum2: 0/0
Destination to Source Latency one way Sum/Sum2: 0/0
Jitter Time:
Number of Jitter Samples: 997
Source to Destination Jitter Min/Avg/Max: 1/2/26 milliseconds
Destination to Source Jitter Min/Avg/Max: 1/1/18 milliseconds
Source to destination positive jitter Min/Avg/Max: 1/2/26 milliseconds
Source to destination positive jitter Number/Sum/Sum2: 348/793/4295
Source to destination negative jitter Min/Avg/Max: 1/2/16 milliseconds
Source to destination negative jitter Number/Sum/Sum2: 346/802/3742
Destination to Source positive jitter Min/Avg/Max: 1/1/18 milliseconds
Destination to Source positive jitter Number/Sum/Sum2: 330/611/2051
Destination to Source negative jitter Min/Avg/Max: 1/1/18 milliseconds
Destination to Source negative jitter Number/Sum/Sum2: 318/606/1992
Interarrival jitterout: 0 Interarrival jitterin: 0
Packet Loss Values:
Loss Source to Destination: 0 Loss Destination to Source: 1
Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 1
MOS score: 4.34
Number of successes: 72
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never
7200-R2#show ip sla statistics details
Round Trip Time (RTT) for Index 1
Type of operation: jitter
Latest RTT: 6 ms
Latest operation start time: 08:08:31.349 UTC Thu Jul 5 2012
Latest operation return code: OK
RTT Values
Number Of RTT: 1000
RTT Min/Avg/Max: 2/6/199 ms
Latency one-way time milliseconds
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 ms
Destination to Source Latency one way Min/Avg/Max: 0/0/0 ms
Source to Destination Latency one way Sum/Sum2: 0/0
Destination to Source Latency one way Sum/Sum2: 0/0
Jitter time milliseconds
Number of SD Jitter Samples: 999
Number of DS Jitter Samples: 999
Source to Destination Jitter Min/Avg/Max: 0/2/13 ms
Destination to Source Jitter Min/Avg/Max: 0/1/195 ms
Source to destination positive jitter Min/Avg/Max: 1/1/13 ms
Source to destination positive jitter Number/Sum/Sum2: 342/638/2142
Source to destination negative jitter Min/Avg/Max: 1/1/11 ms
Source to destination negative jitter Number/Sum/Sum2: 335/638/1886
Destination to Source positive jitter Min/Avg/Max: 1/2/195 ms
Destination to Source positive jitter Number/Sum/Sum2: 198/408/38510
Destination to Source negative jitter Min/Avg/Max: 1/2/128 ms
Destination to Source negative jitter Number/Sum/Sum2: 203/408/20720
Interarrival jitterout: 0 Interarrival jitterin: 0
Over thresholds occurred: FALSE
Packet Loss Values
Loss Source to Destination: 0 Loss Destination to Source: 0
Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0
Packet Skipped: 0
Voice Score Values
Calculated Planning Impairment Factor (ICPIF): 1
MOS score: 4.34
Number of successes: 19
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: 15:59:31.345 UTC Wed Jul 4 2012Update (RESOVLED)
The MOS and ICPIF scores do change. I saturated the WAN link with FTP down/upload traffic inducing packet loss,increased jitter and delay. The scores degraded accordingling show ip sla statistics 10 details
R#show ip sla statistics 10
Round Trip Time (RTT) for Index 10
Type of operation: jitter
Latest RTT: 292 ms
Latest operation start time: 19:07:12.358 UTC Tue Jul 17 2012
Latest operation return code: OK
RTT Values
Number Of RTT: 979
RTT Min/Avg/Max: 58/292/487 ms
Latency one-way time milliseconds
Number of Latency one-way Samples: 1
Source to Destination Latency one way Min/Avg/Max: 1/1/1 ms
Destination to Source Latency one way Min/Avg/Max: 112/112/112 ms
Jitter time milliseconds
Number of SD Jitter Samples: 958
Number of DS Jitter Samples: 958
Source to Destination Jitter Min/Avg/Max: 0/1/6 ms
Destination to Source Jitter Min/Avg/Max: 0/11/151 ms
Packet Loss Values
Loss Source to Destination: 0 Loss Destination to Source: 21
Out Of Sequence: 0 Tail Drop: 0
Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values
Calculated Planning Impairment Factor (ICPIF): 10
MOS score: 4.09
Number of successes: 32
Number of failures: 0
Operation time to live: Forever
Source to Destination Latency one way Sum/Sum2: 9591/94681
Destination to Source Latency one way Sum/Sum2: 346227/125286895
Jitter time milliseconds
Number of SD Jitter Samples: 999
Number of DS Jitter Samples: 999
Source to Destination Jitter Min/Avg/Max: 0/2/11 ms
Destination to Source Jitter Min/Avg/Max: 0/10/48 ms
Source to destination positive jitter Min/Avg/Max: 1/2/11 ms
Source to destination positive jitter Number/Sum/Sum2: 231/513/2789
Source to destination negative jitter Min/Avg/Max: 1/2/10 ms
Source to destination negative jitter Number/Sum/Sum2: 232/512/2724
Destination to Source positive jitter Min/Avg/Max: 1/15/48 ms
Destination to Source positive jitter Number/Sum/Sum2: 305/4762/93106
Destination to Source negative jitter Min/Avg/Max: 1/6/42 ms
Destination to Source negative jitter Number/Sum/Sum2: 682/4717/43395
Interarrival jitterout: 0 Interarrival jitterin: 0
Over thresholds occurred: FALSE
Packet Loss Values
Loss Source to Destination: 0 Loss Destination to Source: 0
Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0
Packet Skipped: 0
Voice Score Values
Calculated Planning Impairment Factor (ICPIF): 5
MOS score: 4.24
Number of successes: 43
Number of failures: 0
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: 17:51:41.945 BST Fri Jul 20 2012 -
Ip SLA RTP based VOIP Operation - To find out MOS value
Hi All,
I am new to VOIP. We are trying to find out the MOS value in our VOIP network. For that we thought of using IP SLA RTP Based VOIP operation to get the MOS values. http://www.cisco.com/en/US/docs/ios/12_4t/12_4t4/htrtpvip.html
I ve used 3825 with NM HDV module with 3 DSP as SLA originator and AS 5400 XM as SLA responder.
But i'm not getting the MOS values,
show ip sla statistics shows that the operation failed due to Format Failure.
I ve attached the config of my 3825. Kindly go through it and advise if any changes to be done.
In AS 5400 XM there is no special config related to this. I ve enabled only " IP SLA RESPONDER"
Error message:
LAB-3825-R6# sh ip sla stat
Round Trip Time (RTT) for Index 1
Type of operation: rtp
Latest operation start time: *05:04:58.707 UTC Wed May 14 2008
Latest operation return code: Format failure
Latest RTT (milliseconds): 0
Source to Destination Path Measurements:
Interarrival Jitter: 0
Packets Sent: 0
Packets Lost: 0
Estimated R-factor: 0 MOS-CQ: 0.00
Destination to Source Path Measurements:
Interarrival Jitter: 0
Packets Sent: 0
Packets Lost: 0
Estimated R-factor: 0 MOS-CQ: 0.00
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never
LAB-3825-R6# sh ip sla stat aggre
Round Trip Time (RTT) for Index 1
Type of operation: rtp
Start Time Index: *05:06:21.019 UTC Wed May 14 2008
Number of successful operations: 0
Number of operations over threshold: 0
Number of failed operations due to a Timeout: 0
Number of failed operations due to a No Connection: 1
Number of failed operations due to an Internal Error: 5
Number of failed operations due to a Sequence Error: 0
RTT (avg/min/max): 0/0/0 ms
Source to Destination Path Measurements:
Interarrival Jitter (avg/min/max): 0/0/0
Packets Sent (avg/min/max): 0/0/0
Packets Lost (avg/min/max): 0/0/0
Estimated R-factor (avg/min/max): 0/0/0
MOS-CQ (avg/min/max): 0.00/0.00/0.00
Destination to Source Path Measurements:
Interarrival Jitter (avg/min/max): 0/0/0
Packets Sent (avg/min/max): 0/0/0
Packets Lost (avg/min/max): 0/0/0
Estimated R-factor (avg/min/max): 0/0/0
MOS-CQ (avg/min/max): 0.00/0.00/0.00
Any help is greatly appreciated.
thanks in advance.Hi,
AS 5400 cannot be used even as SLA responder for RTP probe. Thats the reason i got the Format Failure error. We can view the type of SLA Probes the router supports by issuing the following command:
sh ip sla application.
for eg below is what i ve taken from AS 5400
sh ip sla application
IP Service Level Agreements
Version: Round Trip Time MIB 2.2.0, Infrastructure Engine-II
Time of last change in whole IP SLAs: 10:48:00.737 IST Tue May 20 2008
Estimated system max number of entries: 49625
Estimated number of configurable operations: 49608
Number of Entries configured : 17
Number of active Entries : 17
Number of pending Entries : 0
Number of inactive Entries : 0
Supported Operation Types
Type of Operation to Perform: dhcp
Type of Operation to Perform: dlsw
Type of Operation to Perform: dns
Type of Operation to Perform: echo
Type of Operation to Perform: frameRelay
Type of Operation to Perform: ftp
Type of Operation to Perform: http
Type of Operation to Perform: icmpJitter
Type of Operation to Perform: jitter
Type of Operation to Perform: pathEcho
Type of Operation to Perform: pathJitter
Type of Operation to Perform: tcpConnect
Type of Operation to Perform: udpEcho
Type of Operation to Perform: voip
IP SLAs low memory water mark: 68416281
chnmgw1#
Hope this will help others looking for RTP based VOIP operation.. -
I have an IP SLA as below, the result is always timeout. have tried debug, but not much information
ip sla 25
icmp-echo 10.255.32.25 source-ip 10.255.32.1
timeout 2000
vrf Corp
frequency 10
RTR01#sh ip sla statistics 25
Round Trip Time (RTT) for Index 25
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: .14:51:44.215 BST Wed Aug 13 2014
Latest operation return code: Timeout
Number of successes: 0
Number of failures: 28
Operation time to live: Forever
-RTR01#sh ip sla conf 25
IP SLAs, Infrastructure Engine-II.
Entry number: 25
Owner:
Tag:
Type of operation to perform: echo
Target address/Source address: 10.255.32.25/10.255.32.1
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Operation timeout (milliseconds): 2000
Verify data: No
Vrf Name: Corp
Schedule:
Operation frequency (seconds): 10
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): never
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
History Statistics:
Number of history Lives kept: 0
Number of history Buckets kept: 15
History Filter Type: None
Enhanced History:
-RTR01#ping vrf Corp 10.255.32.25 source 10.255.32.1
IF YOU PING THE DEVICE MANUALLY, ALL SEEMS OK
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.255.32.25, timeout is 2 seconds:
Packet sent with a source address of 10.255.32.1
Success rate is 100 percent (5/5), round-trip min/avg/max = 55/56/57 ms
HEX-SBT-RTR01#RTR01#sh debug
IP SLAs:
TRACE debugging is on for entries:
25
ERROR debugging is on for entries:
25
359097: .Aug 14 14:21:22.291 BST: IP SLAs (25) echo operation: Timeout
359098: .Aug 14 14:21:22.291 BST: IP SLAs (25) Scheduler: Updating result
359099: .Aug 14 14:21:30.291 BST: IP SLAs (25) Scheduler: saaSchedulerEventWakeup
359100: .Aug 14 14:21:30.291 BST: IP SLAs (25) Scheduler: Starting an operation
359101: .Aug 14 14:21:30.291 BST: IP SLAs (25) echo operation: Sending an echo operation
359102: .Aug 14 14:21:30.291 BST: IP SLAs (25) echo operation: VRF: Corp lookup table id: 2
359103: .Aug 14 14:21:32.291 BST: IP SLAs (25) echo operation: Timeout
359104: .Aug 14 14:21:32.291 BST: IP SLAs (25) Scheduler: Updating result
359105: .Aug 14 14:21:40.291 BST: IP SLAs (25) Scheduler: saaSchedulerEventWakeup
359106: .Aug 14 14:21:40.291 BST: IP SLAs (25) Scheduler: Starting an operation
359107: .Aug 14 14:21:40.291 BST: IP SLAs (25) echo operation: Sending an echo operation
359108: .Aug 14 14:21:40.291 BST: IP SLAs (25) echo operation: VRF: Corp lookup table id: 2
359109: .Aug 14 14:21:42.291 BST: IP SLAs (25) echo operation: Timeout
359110: .Aug 14 14:21:42.291 BST: IP SLAs (25) Scheduler: Updating result
359111: .Aug 14 14:21:50.291 BST: IP SLAs (25) Scheduler: saaSchedulerEventWakeup
359112: .Aug 14 14:21:50.291 BST: IP SLAs (25) Scheduler: Starting an operation
359113: .Aug 14 14:21:50.291 BST: IP SLAs (25) echo operation: Sending an echo operation
359114: .Aug 14 14:21:50.291 BST: IP SLAs (25) echo operation: VRF: Corp lookup table id: 2
359115: .Aug 14 14:21:52.291 BST: IP SLAs (25) echo operation: Timeout
359116: .Aug 14 14:21:52.291 BST: IP SLAs (25) Scheduler: Updating result
359117: .Aug 14 14:22:00.291 BST: IP SLAs (25) Scheduler: saaSchedulerEventWakeup
359118: .Aug 14 14:22:00.291 BST: IP SLAs (25) Scheduler: Starting an operation
359119: .Aug 14 14:22:00.291 BST: IP SLAs (25) echo operation: Sending an echo operation
359120: .Aug 14 14:22:00.291 BST: IP SLAs (25) echo operation: VRF: Corp lookup table id: 2
359121: .Aug 14 14:22:02.291 BST: IP SLAs (25) echo operation: Timeout
359122: .Aug 14 14:22:02.291 BST: IP SLAs (25) Scheduler: Updating result
359123: .Aug 14 14:22:10.289 BST: IP SLAs (25) Scheduler: saaSchedulerEventWakeup
359124: .Aug 14 14:22:10.290 BST: IP SLAs (25) Scheduler: Starting an operation
359125: .Aug 14 14:22:10.290 BST: IP SLAs (25) echo operation: Sending an echo operation
359126: .Aug 14 14:22:10.290 BST: IP SLAs (25) echo operation: VRF: Corp lookup table id: 2
359127: .Aug 14 14:22:12.289 BST: IP SLAs (25) echo operation: Timeout
359128: .Aug 14 14:22:12.290 BST: IP SLAs (25) Scheduler: Updating result
359129: .Aug 14 14:22:20.289 BST: IP SLAs (25) Scheduler: saaSchedulerEventWakeup
359130: .Aug 14 14:22:20.290 BST: IP SLAs (25) Scheduler: Starting an operation
359131: .Aug 14 14:22:20.290 BST: IP SLAs (25) echo operation: Sending an echo operation
359132: .Aug 14 14:22:20.290 BST: IP SLAs (25) echo operation: VRF: Corp lookup table id: 2
359133: .Aug 14 14:22:22.289 BST: IP SLAs (25) echo operation: Timeout
359134: .Aug 14 14:22:22.290 BST: IP SLAs (25) Scheduler: Updating result
359135: .Aug 14 14:22:30.290 BST: IP SLAs (25) Scheduler: saaSchedulerEventWakeup
359136: .Aug 14 14:22:30.290 BST: IP SLAs (25) Scheduler: Starting an operation
359137: .Aug 14 14:22:30.290 BST: IP SLAs (25) echo operation: Sending an echo operation
359138: .Aug 14 14:22:30.290 BST: IP SLAs (25) echo operation: VRF: Corp lookup table id: 2 -
Hi guys,
I am new to configuring switches.
I have been given the task of configuring IP SLA in cisco 1941 router. I have performed following operation:
Device> enable
Device# configure terminal
Device(config)# ip sla 1
Device(config-ip-sla)# icmp-echo xxx.xxx.xxx.xxx
Device(config-ip-sla-echo)# frequency 5
Device(config)# ip sla schedule 10 life forever start-time now
Device(config-ip-sla-echo)# end
Next I want to be able to see last 1 months/2 months/3months IP SLA Statics. Kindly advise the configurationHi Paul,
Thank You for responding to my query.
I haven't set the destination device as responder. but "show ip sla statistics" gives me packet sent, received and dropped.
How do I store history for last 2 months/three months is my question.
Regards, -
I am trying to extract the numerical value from the followng using Embedded event manager(TCL Scripting)
i also have SLA probes running between 2 connected routers
sho ip sla statistics | sec SD Jitter
So i write the the following
conf ter
event manager applet STAT
event none sync yes
action 1 cli command "enable"
action 2 cli command "sho ip sla stat | sec SD Jitter"
action 3 regexp " [0-9]+ " $_cli_result result
action 4 puts "$result"
However it produces result
*Mar 27 16:42:08.806: %HA_EM-3-FMPD_UNKNOWN_ENV: fh_parse_var: could not find environment variable: result
*Mar 27 16:42:08.806: %HA_EM-3-FMPD_ERROR: Error executing applet STAT statement 4
pls clarifyDoes the "show ip sla stat | sec SD Jitter" show any output with numbers? If not, then the result variable will not be populated. Try adding line 2 below into your applet so if there is not a match it will not produce an error.
event manager applet STAT
event none sync yes
action 1 cli command "enable"
action 2 set result "No match"
action 3 cli command "sho ip sla stat | sec SD Jitter"
action 4 regexp " [0-9]+ " $_cli_result result
action 5 puts "$result" -
Hello,
I am facing problem with ip sla track mechanism.
I have two ISPs connected to my router C881.
ISP1 = primary (connected to FastEthernet4)
ISP2 = backup (connected to FastEterhet3/Vlan20)
I am using ISP1 as primary ISP and tracking reachability of IP address 8.8.4.4 through ip sla track 200:
ip sla 200
icmp-echo 8.8.4.4
request-data-size 200
timeout 3000
threshold 1000
owner SYSADMIN
frequency 5
history hours-of-statistics-kept 25
history distributions-of-statistics-kept 20
history lives-kept 2
history buckets-kept 60
history filter all
ip sla schedule 200 life forever start-time now
ip sla enable reaction-alerts
track 200 ip sla 200 reachability
delay down 30 up 180
Default-route to ISP1 is tracked and second default-route is configured with higher value of metric.
This is how my static routing looks like:
ip route 0.0.0.0 0.0.0.0 FastEthernet4 1.1.1.1 name ISP1 track 200
ip route 0.0.0.0 0.0.0.0 Vlan20 2.2.2.2 250 name ISP2
ip route 8.8.4.4 255.255.255.255 FastEthernet4 1.1.1.1 name force-ISP1
ip route 8.8.4.4 255.255.255.255 Null0 250 name deny-via-ISP2
It works almost as expected:
- when ISP1 is going down (i mean if 8.8.4.4 becomes unreachable via ISP1), after 30 seconds, default route is pointing to ISP2
- also when ISP1 is going up (8.8.4.4 becomes reachable again via ISP1), after 180 seconds, default route is pointing back to ISP1
*Mar 14 14:09:52.034: %TRACKING-5-STATE: 200 ip sla 200 reachability Up->Down
*Mar 14 14:12:57.039: %TRACKING-5-STATE: 200 ip sla 200 reachability Down->Up
...but
In some cases (I believe that it may be in situation, that ISP1 is down for longer time), ip sla/track is unable to detect that ISP1 becomes UP again and the default route is pointing to ISP2 forever (at least until FastEthernet4 is disconnected/connected again, or shut/no shut command is applied).
*Mar 17 14:18:13.019: %TRACKING-5-STATE: 200 ip sla 200 reachability Up->Down
This is how some show command outputs looks like:
ROUTER-MD#show ip route static
8.0.0.0/32 is subnetted, 2 subnets
S 8.8.4.4 [1/0] via 1.1.1.1, FastEthernet4
S* 0.0.0.0/0 [250/0] via 2.2.2.2, Vlan20
ROUTER-MD#show ip sla statistics 200 details
IPSLAs Latest Operation Statistics
IPSLA operation id: 200
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: *12:17:51.494 MET Wed Mar 18 2015
Latest operation return code: Timeout
Over thresholds occurred: FALSE
Number of successes: 0
Number of failures: 31
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never
ROUTER-MD#show track 200
Track 200
IP SLA 200 reachability
Reachability is Down
42 changes, last change 22:00:06
Delay up 180 secs, down 30 secs
Latest operation return code: Timeout
Tracked by:
STATIC-IP-ROUTING 0
But as you can see here, 8.8.4.4 is reachable from the router:
ROUTER-MD#show ip route 8.8.4.4
Routing entry for 8.8.4.4/32
Known via "static", distance 1, metric 0
Routing Descriptor Blocks:
* 1.1.1.1, via FastEthernet4
Route metric is 0, traffic share count is 1
ROUTER-MD#ping 8.8.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.4.4, timeout is 2 seconds:
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/41/44 ms
During that behavior, I see no icmp traffic destined to 8.8.4.4 with "debug ip icmp" command enabled.
Debug IP sla & track results are here:
ROUTER-MD#show debug
Track debugging is on
IP SLAs:
TRACE debugging is on for entries:
200
ERROR debugging is on for entries:
200
*Mar 18 12:40:16.530: IP SLAs(200) Scheduler: saaSchedulerEventWakeup
*Mar 18 12:40:16.530: IP SLAs(200) Scheduler: Starting an operation
*Mar 18 12:40:16.530: IP SLAs(200) echo operation: Sending an echo operation - destAddr=8.8.4.4, sAddr=1.1.1.2
*Mar 18 12:40:16.530: IP SLAs(200) echo operation: Sending ID: 27
*Mar 18 12:40:19.530: IP SLAs(200) echo operation: Timeout - destAddr=8.8.4.4, sAddr=1.1.1.2
*Mar 18 12:40:19.530: IP SLAs(200) Scheduler: Updating result
*Mar 18 12:40:19.530: IP SLAs(200) Scheduler: start wakeup timer, delay = 2000
*Mar 18 12:40:21.530: IP SLAs(200) Scheduler: saaSchedulerEventWakeup
*Mar 18 12:40:21.530: IP SLAs(200) Scheduler: Starting an operation
*Mar 18 12:40:21.530: IP SLAs(200) echo operation: Sending an echo operation - destAddr=8.8.4.4, sAddr=1.1.1.2
*Mar 18 12:40:21.530: IP SLAs(200) echo operation: Sending ID: 27
*Mar 18 12:40:24.530: IP SLAs(200) echo operation: Timeout - destAddr=8.8.4.4, sAddr=1.1.1.2
*Mar 18 12:40:24.530: IP SLAs(200) Scheduler: Updating result
*Mar 18 12:40:24.530: IP SLAs(200) Scheduler: start wakeup timer, delay = 2000
...etc
I would appreciate any help.
Thank you,
MBHi,
>>when ISP 1 is down, is the static route to 8.8.4.4 via 1.1.1.1 still in the routing table?
Unfortunately I can not catch the situation, when ISP1 is down. Now the ISP1 is UP.
But there can be two situations regarding this configuration:
ip route 8.8.4.4 255.255.255.255 FastEthernet4 1.1.1.1 name force-ISP1
1. If FE4 goes down, static route is removed from the routing table.
2. If FE4 remains up (but connection to 8.8.4.4 is broken within ISP1 network), static route is still in the routing table.
As I can see in logs, FE4 was not down, so route to 8.8.4.4 via ISP1 was in RT all the time.
>> Are you sure that reach ability to 8.8.4.4 is actually going through ISP2?
No, reach ability to 8.8.4.4 is actually going through ISP1 as configured:
S 8.8.4.4 [1/0] via 1.1.1.1, FastEthernet4
ROUTER#ping 8.8.4.4 source fastEthernet 4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.4.4, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.2
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/40/44 ms
, my problem is that ip sla is somehow not seeing this:
ROUTER#show ip sla statistics
IPSLAs Latest Operation Statistics
IPSLA operation id: 200
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: *09:48:42.553 METDST Mon Apr 27 2015
Latest operation return code: Timeout
Number of successes: 0
Number of failures: 42
Operation time to live: Forever
>> have you applied ACL denying ICMP destined to 8.8.4.4 through ISP2 to make sure that 8.8.4.4 is not pingable through ISP2?
No... I have applied more specific static route to 8.8.4.4 via ISP1.
Besides of that, I have applied source-ip command under the ip sla configuration:
ip sla 200
icmp-echo 8.8.4.4 source-ip 1.1.1.2
Sure, I can try to deny icmp to 8.8.4.4 through ISP2 as third action, and we will see...
What will be better from your point of view? To use ACL as you mentioned, or to use "ip local policy route-map" as pille1234 mentioned...? Maybe both, to be 100% sure? -
SLA doesn't send syslog message
Hi all, i've configure a sla on a router 3945 running IOS 15.1 for icmp-echo operation and it works as expected but what i'm trying to find out is why when the icmp-echo operation fails the ipsla does not send a syslog message.
ip sla 1
icmp-echo 10.172.19.1 source-interface Loopback0
frequency 5
ip sla schedule 1 life forever start-time now
ip sla reaction-configuration 1 react timeout threshold-type immediate action-type trapOnly
ip sla enable reaction-alert
snmp-server community public RO
snmp-server enable traps syslog
snmp-server enable traps ipsla
logging buffered debugging
R1#sh ip sla statistics
IPSLAs Latest Operation Statistics
IPSLA operation id: 1
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 15:07:29 UTC Wed Mar 26 2014
Latest operation return code: Timeout
Number of successes: 0
Number of failures: 16
Operation time to live: Forever
Please any idea will be appreciated!
Regards
OscarDid you used iphone before?
Did you made a clean install of update from 10.0 to 10.1?
Proudful & loyal Blackberry supporter ..
throwing mud at others makes you happy now but in future you might end up in sinking in mud lake.. wake up b4 it happens. Be secure
10.3.0.296 -
Hello - I am trying to find some detailed information on IP SLA probes. We are implementing udp jitter probes in our network, but I am curious about what constitutes a test failure. Considering the default test parameters (10 packets, 10 bytes, spaced 10ms each 60 seconds) what does the test consider to be a failure? Is it based on the connection, number of packets received back, or are there other parameters?
Is there any documentation anywhere that details this?
thanks,
Alexappreciate the response Sathvik. Maybe I asked incorrectly. What does ip sla consider a failed test? Is it as simple as no connection to the testing point? If that is the case, then everything else would be displayed in the sh ip sla statistics command. I could not find anything in the configuration documentation that stated what a test failure was, or could be a result of.
-
Is SNMP RO and telnet good enough for IPM?
Dear friends,
I have only SNMP RO access to the router and telnet access as well from Ciscoworks LMS.
But i dont have SNMP RW access.
Is it possible that i configure ip sla monitor manually on the routers / switches and just use IPM to poll these routers and collect the SLA statistics?
Thanks a lot
GautamIPM requires read-write access. However, you could try configuring the collectors on the devices manually, then import those collectors into IPM using the "ipm importcollector" cli command. I haven't tested doing this without having SNMP RW configured, but it should work. IPM will just not be able to fully manage the collectors, but it should be able to poll them.
-
IPM 4.2.0 and icmp-echo 0.0.0.0 problem
Hi,
I'm having a problem with IPM.
We are running LMS 3.2 with IPM 4.2.0.
I used IPM to configure a device to perform a ping to an ad-hoc target, the source router was configured as:
ip sla 182611
icmp-echo 0.0.0.0
request-data-size 64
owner ipm|<name>
tag <tag>
ip sla schedule 182611life forever start-time now ageout 3600
The target device is an ad-hoc with an ip-address but the IP SLA job ends up as 0.0.0.0.
When I'm running 'show ip sla statistics' it shows that the ping are timed out (as they are being sent to 0.0.0.0 instead of the real IP address).
The source router is running:
Cisco IOS Software, 3800 Software (C3825-ADVSECURITYK9-M), Version 12.4(22)T, RELEASE SOFTWARE (fc1)
Anyone had familiar problems?
Thanks,
Amitjclarke wrote:I haven't seen this before. Can you redo the configuration, and collect a sniffer trace of SNMP traffic between the IPM server and the device? This will help determine if the problem is with IPM or IOS.
Hi,
My IPM is running on Solaris 10.
Can you advise what/how I can sniff the SNMP traffic between the server and the IOS device?
Here is more information from the device:
#show version
Cisco IOS Software, C3550
Software (C3550-IPSERVICESK9-M), Version 12.2(46)SE, RELEASE SOFTWARE
(fc2)
#show running-config | inc 154366
ip sla 154366
ip sla schedule 154366 life forever start-time now ageout 3600ip sla reaction-configuration 154366 react timeout threshold-type immediate action-type trapOnly
ip sla reaction-configuration 154366 react rtt threshold-value 4000 3000 threshold-type consecutive 2 action-type trapOnly
35PROB#show ip sla configuration 154366
IP SLAs, Infrastructure Engine-II.
Entry number: 154366Owner: ipm|unix107776a44Tag: 35PROB_AMIT
Type of operation to perform: echoTarget address: 0.0.0.0
Source address: 0.0.0.0Request size (ARR data portion): 64
Operation timeout (milliseconds): 5000Type Of Service parameters: 0x0
Verify data: NoVrf Name:
Schedule: Operation frequency (seconds): 60
Next Scheduled Start Time: Start Time already passed Group Scheduled : FALSE
Randomly Scheduled : FALSE Life (seconds): Forever
Entry Ageout (seconds): 3600 Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): ActiveThreshold (milliseconds): 4000
Distribution Statistics:
Number of statistic hours kept: 2 Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
History Statistics: Number of history Lives kept: 0
Number of history Buckets kept: 15 History Filter Type: None
Enhanced History:
Thanks -
IPM and dynamic user tracking not running properly.
Hello, I've got two problems after a reinstallation of CiscoWorks LMS 3.2.
Versions of software components:
LMS-3.2
Campus Manager-5.2.1
CiscoView-6.1.9
CiscoWorks Assistant-1.2.0
CiscoWorks Common Services-3.3.0
Device Fault Manager-3.2.0
Integration Utility-1.9.0
Internetwork Performance Monitor-4.2.0
LMS Portal-1.2.0
Resource Manager Essentials-4.3.0
First probelm I have sounds pretty much like this thread:
https://supportforums.cisco.com/message/3064784#3064784
Source device is a WS-C3560-8PC - 12.2(55)SE1 - C3560-IPSERVICESK9-M
I configured a IPM collector, if I have a look at the "Collector Management" the collector is running and I can also monitor the running collector.
But if I have a look at the running config of the switch, there is no ip sla collector configuration but I can see the ip sla statistics via the show command.
#sh ip sla configuration 135123
IP SLAs, Infrastructure Engine-II.
Entry number: 135123
Owner: ipm|XXXS1077
Tag: QA-Site1-Site2
Type of operation to perform: udp-jitter
Target address/Source address: target ip address/source ip address
Target port/Source port: 2000/0
Type Of Service parameter: 0xB8
Operation timeout (milliseconds): 5000
Codec Type: g729a
Codec Number Of Packets: 1000
Codec Packet Size: 32
Codec Interval (milliseconds): 20
Advantage Factor: 12
Verify data: No
Vrf Name:
Control Packets: enabled
Schedule:
Operation frequency (seconds): 60
Next Scheduled Start Time: Start Time already passed
Group Scheduled : FALSE
Randomly Scheduled : FALSE
Life (seconds): Forever
Entry Ageout (seconds): 3600
Recurring (Starting Everyday): FALSE
Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
Number of statistic hours kept: 2
Number of statistic distribution buckets kept: 1
Statistic distribution interval (milliseconds): 20
Enhanced History:
#sh ip sla statistics
Round Trip Time (RTT) for Index 135123
Type of operation: jitter
Latest RTT: 45 ms
Latest operation start time: 14:36:31.759 MET Wed Mar 16 2011
Latest operation return code: OK
RTT Values
Number Of RTT: 1000
RTT Min/Avg/Max: 21/45/60 ms
Latency one-way time milliseconds
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 ms
Destination to Source Latency one way Min/Avg/Max: 0/0/0 ms
Jitter time milliseconds
Number of SD Jitter Samples: 999
Number of DS Jitter Samples: 999
Source to Destination Jitter Min/Avg/Max: 0/3/15 ms
Destination to Source Jitter Min/Avg/Max: 0/1/9 ms
Packet Loss Values
Loss Source to Destination: 0 Loss Destination to Source: 0
Out Of Sequence: 0 Tail Drop: 0
Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values
Calculated Planning Impairment Factor (ICPIF): 11
MOS score: 4.06
Number of successes: 18
Number of failures: 0
Operation time to live: Forever
#sh run all | include 135123
Any suggestions? Am I right?
The second problem is about the dynamic user tracking like these theads https://supportforums.cisco.com/message/3135881#3135881 or
https://supportforums.cisco.com/message/3195492#3195492
Access switches are configured properly, the configuration ran without any problems with the previous installation.
No changes done at the configuration, using the default trap listener port etc.
In the macuhic.log file I get entries like in the attached txt.
When I try to run a full Campus Manager Data Collection I get the following errormessage:
Failed to start acquisition: Construction of XML data required for UT is in progress.Please try after some time
Also any suggestions? Am I right, too?By default IP SLA collectors installed by IPM do not appear in the running configuration. If you want to install the collectors into the running configuration, then set the "Copy IPSLA Configuration to running-config" property under IPM > Admin > Application Settings, then delete and recreate the collector.
Your Campus problem could be CSCtd49439 (a patch is available by contacting TAC). However, you should start a new thread for your Campus problem. -
Hi guys,
Our customer has a WAN network (DCoS) and has voice protected across it. I work for an integrator assisting the customer with their CPE routers end-to-end. Essentially CPE routers extend PSTN lines end-to-end over voice-ports and voip call legs between locations. On CPE routers we're seeing voice traffic being marked/matched end-to-end. We're pretty sure that the ISP is somehow shaping/causing delays on the voice traffic interstate but now we're trying to gather some evidence.
To help isolate, test and provide evidence we were planning on using UDP-Jitter in IP SLA. I've been trying to get this enabled on live routers without success due to the reason "No connection" in the initiators show output. An example of the "show ip sla statistics" on a production device is shown below:
SITE-1#show ip sla statistics
IPSLAs Latest Operation Statistics
IPSLA operation id: 100
Type of operation: udp-jitter
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 17:26:47 BNE Mon Jul 2 2012
Latest operation return code: No connection
RTT Values:
Number Of RTT: 0 RTT Min/Avg/Max: 0/0/0 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Jitter Time:
Number of SD Jitter Samples: 0
Number of DS Jitter Samples: 0
Source to Destination Jitter Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/0/0 milliseconds
Packet Loss Values:
Loss Source to Destination: 0
Source to Destination Loss Periods Number: 0
Source to Destination Loss Period Length Min/Max: 0/0
Source to Destination Inter Loss Period Length Min/Max: 0/0
Loss Destination to Source: 0
Destination to Source Loss Periods Number: 0
Destination to Source Loss Period Length Min/Max: 0/0
Destination to Source Inter Loss Period Length Min/Max: 0/0
Out Of Sequence: 0 Tail Drop: 0
Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 0
Mean Opinion Score (MOS): 0
Number of successes: 0
Number of failures: 1
Operation time to live: Forever
Number of failures continues to increase every 30 seconds or so. The configuration of SITE-1 is as follows:
SITE-1#show run | sec ip sla
ip sla 100
udp-jitter 10.2.2.2 16584 source-ip 10.1.1.1 source-port 16384
tos 30
owner NetFlow
timeout 60000
ip sla schedule 100 life forever start-time now
The configuration of SITE-2 (IP SLA Responder) is as follows:
SITE-2#show run | sec ip sla
ip sla responder
For the sake of privacy I've adjusted the IPs above as well as the router hostnames. The 10.2.2.2 IP lives on SITE-2's router and 10.1.1.1 lives on SITE-1's router.
If I do the above in GNS it works perfectly so I think something else is going on here. Either I've got a bug (doubt it) or something is preventing the UDP from connecting/responding for the IP SLA. Frustratingly, if I do a "show ip sla responder" on the SITE-2 router... it says it received the packets normally without error:
SITE-2#show ip sla responder
General IP SLA Responder on Control port 1967
General IP SLA Responder is: Enabled
Number of control message received: 123 Number of errors: 0
Recent sources:
10.1.1.1 [18:06:35.989 BNE Mon Jul 2 2012]
10.1.1.1 [18:06:30.989 BNE Mon Jul 2 2012]
10.1.1.1 [18:06:25.989 BNE Mon Jul 2 2012]
10.1.1.1 [18:05:35.989 BNE Mon Jul 2 2012]
10.1.1.1 [18:05:30.989 BNE Mon Jul 2 2012]
Recent error sources:
Permanent Port IP SLA Responder
Permanent Port IP SLA Responder is: Enabled
udpEcho Responder:
IP Address Port
If I enable trace debug ("debug ip sla trace") on SITE-1's router I get the following...
Jul 2 08:13:25.993: IPSLA-INFRA_TRACE:OPER:100 slaSchedulerEventWakeup
Jul 2 08:13:25.993: IPSLA-INFRA_TRACE:OPER:100 Starting an operation
Jul 2 08:13:25.993: IPSLA-OPER_TRACE:OPER:100 Starting jitter operation
Jul 2 08:13:25.993: IPSLA-OPER_TRACE:OPER:100 Ctrl msg: id=116, type=1, len=52, dest_ip=10.2.2.2, enablePort=16584, duration=60200
Jul 2 08:13:25.993: IPSLA-OPER_TRACE:OPER:100 table_id=0, topo_id=65535
Jul 2 08:13:30.993: IPSLA-OPER_TRACE:OPER:100 Timeout
Jul 2 08:13:30.993: IPSLA-OPER_TRACE:OPER:100 Ctrl msg: id=117, type=1, len=52, dest_ip=10.2.2.2, enablePort=16584, duration=60200
Jul 2 08:13:30.993: IPSLA-OPER_TRACE:OPER:100 table_id=0, topo_id=65535
Jul 2 08:13:35.993: IPSLA-OPER_TRACE:OPER:100 Timeout
Jul 2 08:13:35.993: IPSLA-OPER_TRACE:OPER:100 Ctrl msg: id=118, type=1, len=52, dest_ip=10.2.2.2, enablePort=16584, duration=60200
Jul 2 08:13:35.993: IPSLA-OPER_TRACE:OPER:100 table_id=0, topo_id=65535
Jul 2 08:13:40.993: IPSLA-OPER_TRACE:OPER:100 Timeout
Jul 2 08:13:40.993: IPSLA-OPER_TRACE:OPER:100 No connection
Jul 2 08:13:40.993: IPSLA-INFRA_TRACE:OPER:100 Updating resultChecked the ports and found I am using different ones on each VoIP gateway. I just added a new operation with a totally unique port that I know is not in use on the source or destination and it still failed:
voipgw02(config)#ip sla 4033
voipgw02(config-ip-sla)# udp-jitter 10.205.50.5 17333 source-ip 10.225.50.5 codec g711ulaw codec-numpackets 100
voipgw02(config-ip-sla-jitter)# tos 184
voipgw02(config-ip-sla-jitter)# timeout 18000
voipgw02(config-ip-sla-jitter)# threshold 1000
voipgw02(config-ip-sla-jitter)# frequency 30
voipgw02(config-ip-sla-jitter)#ip sla schedule 4033 life forever start-time now ageout 3600
voipgw02#sh ip sla stat
IPSLAs Latest Operation Statistics
IPSLA operation id: 4033
Type of operation: udp-jitter
Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 21:47:43 EDT Mon Sep 3 2012
Latest operation return code: No connection
RTT Values:
Number Of RTT: 0 RTT Min/Avg/Max: 0/0/0 milliseconds
Latency one-way time:
Number of Latency one-way Samples: 0
Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds
Jitter Time:
Number of SD Jitter Samples: 0
Number of DS Jitter Samples: 0
Source to Destination Jitter Min/Avg/Max: 0/0/0 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/0/0 milliseconds
Packet Loss Values:
Loss Source to Destination: 0
Source to Destination Loss Periods Number: 0
Source to Destination Loss Period Length Min/Max: 0/0
Source to Destination Inter Loss Period Length Min/Max: 0/0
Loss Destination to Source: 0
Destination to Source Loss Periods Number: 0
Destination to Source Loss Period Length Min/Max: 0/0
Destination to Source Inter Loss Period Length Min/Max: 0/0
Out Of Sequence: 0 Tail Drop: 0
Packet Late Arrival: 0 Packet Skipped: 0
Voice Score Values:
Calculated Planning Impairment Factor (ICPIF): 0
Mean Opinion Score (MOS): 0
Number of successes: 0
Number of failures: 1
Operation time to live: Forever
Do you know if there are any licensing issues?
barvoipgw02#show ip sla appl
IP Service Level Agreements
Version: Round Trip Time MIB 2.2.0, Infrastructure Engine-III
Supported Operation Types:
icmpEcho, path-echo, path-jitter, udpEcho, tcpConnect, http
dns, udpJitter, dhcp, ftp, VoIP, rtp, icmpJitter
802.1agEcho VLAN, Port, 802.1agJitter VLAN, Port, udpApp
wspApp
Supported Features:
IPSLAs Event Publisher
IP SLAs low memory water mark: 63126085
Estimated system max number of entries: 46234
Estimated number of configurable operations: 39313
Number of Entries configured : 3
Number of active Entries : 3
Number of pending Entries : 0
Number of inactive Entries : 0
Time of last change in whole IP SLAs: .21:47:43.954 EDT Mon Sep 3 2012
Maybe you are looking for
-
Question about using "current_date" in OBIEE filter
Hello guys I have a metadata set up as the following: Logical Fact table has 2 LTS, each has a fragmentation content defined as: LTS1 ----- Dim.Dates < current_date LTS2 ----- Dim.Dates >= Current_date With this setup, when the filter on the dates co
-
IMac output to Plasma suddenly darker
Hi guys, Can anyone help with this problem? I have had my iMac 20" Display output connected to our Panasonic 37" Plasma for 18 months now with no problems at all, then the other day I put the TV to the Computer and the picture was very dark with skin
-
To find a column based on a value
Hello Experts, I have an urgent requirement. Based on a value in a particular column in a table, i have to select the previous column value. I have tried using select statement with more compliaction which will affect the performance. Is ther
-
ErrorJarUpdate on deploying portlet war file
I'm trying to deploy a war file of portlets. Upon running pdeploy, I get the following errors in the pdeploy.debug log: 10/07/2004 10:11:00:617 AM CDT: Thread[main,5,main] ERROR: Exception: com.sun.portal.portlet.cli.PortletDeployerException: errorJa
-
Hi! I use SQL Developer and also Toad to connect to my Oracle 10.2 Database. Maybe since Oracle 10 (and / or maybe InstanceClient) I cannot see the Grants in the SQL Developer of other users than the one I'm connecting. If I use Toad I have no Proble