Same here having similiar - Page 2

Jonathan Bekkers · ‎07-02-2012

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

bpeng0001 · ‎08-07-2014

Thank you for you prompt reply.

I tried to delete the original operation and set up a new one along the opposite direction, in the sense not to confuse it with same IPs. However, it still didn't work. Anyway, I'll try to figure it out.

One more follow-up question if I may. Also the operation code was OK, I am getting zero values for all the per-direction jitter, except that RTT being 1ms. I read from some other posts, and synchronized the time on all the routers involved but still with no luck. Was there anything you did to get the correct readings?

I'm totally new to IP SLA and really appreciate your answers.

Thanks,

Bo

David Vasquez · ‎08-08-2014

Bo,

I did not have to do anything special. Are you getting a value of 0 or no value? A value of 0 would be ok, but no value would indicate a problem. Below is one the output from my ipsla router after issuing the show ip sla stat. The one value with all 0's fluctuates between all 0's and a combination of 0's and 1's.

ipsla01#sh ip sla stat

Round Trip Time (RTT) for Index 40008
Latest RTT: 7 milliseconds
Latest operation start time: *15:54:35.715 EST Fri Aug 8 2014
Latest operation return code: OK

---- Path Jitter Statistics ----

Hop IP 10.x.x.x:
Round Trip Time milliseconds:
        Latest RTT: 1 ms
        Number of RTT: 10
        RTT Min/Avg/Max: 1/1/1 ms
Jitter time milliseconds:
        Number of jitter: 1
        Jitter Min/Avg/Max: 0/0/0 ms
Packet Values:
        Packet Loss (Timeouts): 0
        Out of Sequence: 0
        Discarded Samples: 0

HTH,

David

bpeng0001 · ‎08-08-2014

Hi David,

Thanks for your post. I was getting 0 values.

I guess it is because I am doing it in the lab and the bandwidth is handling it well. I will try to generate some traffic and play with it.

Thanks,

Bo

mrisler.ig · ‎10-07-2014

Hi !

Were you able to resolve this ? i m having exactly the same issue.

Regards,

Brian McPhillips · ‎11-21-2014

Same here having similiar issues, if i setup a icmp-echo ip sla test it works fine to the same responder ips. UDP jitter fails though!

joeharb · ‎05-27-2014

Did you ever get a response on this? I have 2 2911 routers that are running 15.1(4)M4 and neither appear to be responding to ip sla requests. Other routers on the network are working fine, but any all connections to these routers show the ip sla as

NoConnection/Busy/Timeout

I can ping the far end without issue.

Any thoughts?

Thanks,

Joe

Jonathan Bekkers · ‎05-27-2014

Well this thread is 2 years old now. Please make a new thread with your configurations and what you're trying to achieve. I'll respond on your thread once its open.

David Vasquez · ‎06-16-2014

I was not able to get it working with the original 3925s, so I just used a spare 850 ISR as a dedicated IPSLA node and it is all working like a champ.

David Vasquez · ‎08-07-2014

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.

Joshua Fontenot · ‎04-13-2015

I had this same issue. TAC told me since my two devices are setup as voice gateway, using the standard RTP port range will not allow the IP SLA to get to the IP SLA engine on the responder. Instead I used the other port range and it worked 49152-65535.

<1-65535> Port Number. For codec options recommended port range is an Even Port range between 16384-32767 or 49152-65535

IPSLA UDP-Jitter Issues