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: 30

    this 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!

  • IP SLA icmp jitter operation

    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 2012

    Update (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..

  • Ip sla reults timeout

    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

  • IP-SLA

    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 configuration

    Hi 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,

  • Eem scripting for IP SLA

    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 clarify

    Does 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"

  • IP SLA TRACK issue

    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,
    MB

    Hi,
    >>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
    Oscar 

    Did 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

  • Detailed IP SLA information

    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,
    Alex

    appreciate 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
    Gautam

    IPM 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,
    Amit

    jclarke 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.

  • IPSLA UDP-Jitter Issues

    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 result

    Checked 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

  • SQL Developer Show Grants

    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