cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
13581
Views
5
Helpful
24
Replies

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

24 Replies 24

David Vasquez
Level 1
Level 1

I am having the exact same problem with one wierd twist:

Site A is a 3925 running c3900-universalk9-mz.SPA.150-1.M1.bin that cannot connect to any of my other sites ( I get the same error messages as you "NoConnection/Busy/Timeout")


Site B is a 3925 running c3900-universalk9-mz.SPA.152-1.T1.bin that can connect to ANY other site, including site A

Site C is a 2921 running c2900-universalk9-mz.SPA.152-1.T1.bin that can connect to ANY other site, including site A

Site D is a 2911 running c2900-universalk9-mz.SPA.150-1.M3.bin that can connect to ANY other site, including site A

I am in the process of upgrading the IOS on site A to c3900-universalk9-mz.SPA.152-1.T1.bin because this is the only logincal thing I can think of that might be causing this problem. Once my change management ticket is complete I will update this post (probably week of 09/10/12).

I actually forgot I lodged this in the first place. The problem was resolved for me by removing the specific ports in the IP SLA:

ITE-1#show run | sec ip sla

ip sla 100

udp-jitter 10.2.2.2 16584 source-ip 10.1.1.1

tos 30

owner NetFlow

timeout 60000

ip sla schedule 100 life forever start-time now

Essentially, my IP SLA was being generated by ManageEngine. ManageEngine was defining a "port". That port configuration though valid was not working. CIsco TAC advised to removed the specific port definition.... this resolved it.

Thanks for the update.

I tried doing that, but my VoIP gateway is requiring a port number:

voipgw01(config-ip-sla)# udp-jitter 10.2.2.2 source-ip 10.11.1.1

                                                   ^

% Invalid input detected at '^' marker.

voipgw01(config-ip-sla)# udp-jitter 10.215.50.5 ?                                                       

  <0-65535>  Port Number. For codec options recommended port range

             is an Even Port range between 16384-32767 or 49152-65535

voipgw01(config-ip-sla)# udp-jitter 10.2.2.2 source-ip 10.11.1.1 codec g711ulaw codec-numpackets 100

                                                   ^

% Invalid input detected at '^' marker.

Cisco 2911 running c2900-universalk9-mz.SPA.150-1.M3

voipgw01#show ip sla appl

IP Service Level Agreement Technologies

IPSLAs Infrastructure version: Engine-II

Supported Operation Types:

        802.1ag Echo, 802.1ag Jitter, dhcp, dns, frame relay, ftp

        http, icmp-echo, icmp-jitter, path-echo, path-jitter, rtp

        tcp-connect, udp-echo, udp-jitter, voip

I think my next step is Cisco TAC.

Thanks again for the reply!

David - had this same timeout issue and just fixed my issue 5 min ago, problem was a miss configured source-ip.

Can you post the router configuration ?

R1#show ip sla mon stat

Round trip time (RTT)   Index 11

       Latest RTT: 112 ms

Latest operation start time: *01:06:19.287 UTC Fri Mar 1 2002

Latest operation return code: OK

Number of successes: 21

Number of failures: 0

Operation time to live: Forever

R1#show debug

IP SLA Monitor:

TRACE debugging for all operations is on

ERROR debugging for all operations is on

*Mar 1 01:06:19.283: IP SLA Monitor(11) Scheduler: Starting an operation

*Mar 1 01:06:19.287: IP SLA Monitor(11) echo operation: Sending an echo operation

*Mar 1 01:06:19.399: IP SLA Monitor(11) echo operation: RTT=112

*Mar 1 01:06:19.399: IP SLA Monitor(11) Scheduler: Updating result

I know source IP is ok because there is only one IP on the router and I successfully connect to 4 other voice gateways using the same source IP.

What code are you running on your VoIP gateway? Do you have more than one IP SLA sourcing from that device?

I really think there is something wrong with the responder. I can successfully create IP SLA operations to the other devices, but cannot to this one. Any ideas about the responder configuration?

The responder will respond to "anything" it supports. Another trick I remember reading through these comments is that you have to be extremely careful that the responder isn't responding to the same port from different IP SLA tests. i.e. each site must be configured to use a unique port number.

EDIT: This was the reason why Cisco recommended letting IP SLA select the port.

Mine is running in GNS3 - disregard the wrong date and time

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

Contrary to my original response, I am in fact defining ports on my live routers.

I have a mix of 2911 and 2921 where I am running this on. Mix of universal and old codes. In the example I provide below, both sites are using universal and have "uc" licensing enable. That might your issue... do a "show ver"? Do you have "uc" license enabled to get udp-jitter?

A router can be a responder and tracker at the same time. My head office "test" router has the below config:

HeadOffice#show run | sec ip sla

ip sla responder

ip sla 103

udp-jitter 16584 source-ip source-port 16500 codec g729a advantage-factor 4

tos 46

owner NetFlow

timeout 60000

ip sla schedule 103 life forever start-time 16:13:38 Jul 25 ageout 60

ip sla 105

udp-jitter 16584 source-ip source-port 16404 codec g729a advantage-factor 4

tos 46

owner NetFlow

timeout 60000

ip sla schedule 105 life forever start-time now ageout 60

[...] (ip sla threshold config suppressed)

The remote ends just have:

Remote_2911#show run | sec ip sla

ip sla responder

As an example show ver:

[...]

Technology Package License Information for Module:'c2900'

-----------------------------------------------------------------

Technology    Technology-package           Technology-package

              Current       Type           Next reboot 

------------------------------------------------------------------

ipbase        ipbasek9      Permanent      ipbasek9

security      None          None           None

uc            uck9          Permanent      uck9

data          None          None           None

Configuration register is 0x2102

Hopefully that helps. IP sla responder config is extremely simple... I doubt that is the issue. Probably more likely ports/config/licensing. Another useful mechanism to troubleshoot is show udp:

Remote_2911#show udp

Proto        Remote      Port      Local       Port  In Out  Stat TTY OutputIF

17       --listen--          --any--          1975   0   0 1000001   0

[...]

17          16400      16584   0   0   441   0

I could be totally wrong with the license. I seem to remember that being a sticking point back when I looked at this.

Router R1 has 4 interfaces, I'm sourcing from 2 Ethernet Interfaces and routing packets from each source out the other 2 Serial ports, but each source goes over specific paths.

I have two ACL's, Route-Maps, and IPSLA's configured. I take packets from host 1 and route them out serial 0/0, and take packets from host 2 and routing them out serial 0/1. Both host 1 and host 2 have ACL's allowing them to talk to host 3 on a distant network.  Currently studying for CCNP routing, so my config is much simpler than what is shown in your posts. My "NoConnection/Busy/Timeout" issue was missconfigured source-ip on the R1 router. Sorry couldn't be more help.

Thanks for all of the feedback. I am going to open a TAC case and see what they have to say. Once I have their solution I will post it here.

The same problem here. And your post helped...  in a certain way.

 

The strangest thing is that, I configed SLA jitter from router A to B, it worked, and then used the exact same config(with necessary changes) from router B to A, it won't work, and gave me the " no connection" error.

 

I would really appreciate any input, since I was stuck here for too long.

 

Thanks

I never did get it working on the original routers, I used a spare ISR whose only mission was to run IPSLA. As a matter of fact, I only created the operation in one direction because I am able to monitor the "Bidirectional Jitter," with that one operation, which was sufficient for me. I can still see packet loss, MOS, latency, and jitter for all of my operations. If you really need to create an operation in each direction, I would use two different routers or two different source/destination IPs on each router. I think the addition of the second operation fails when the router sees that there is an existing operation established between the same source and destination IPs, regardless of the port numbers that are being used.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: