asked on
Help Decoding the meaning of this IP SLA Output
I would like to think that this indicates that there is a problem with my isp and the mpls vpn they are providing me. This is across the mpls vpn that I am having call quality issues.
Thanks for any insight
BOS3825#sh ip sla statistics detail
Round Trip Time (RTT) for Index 10
Latest RTT: 64 milliseconds
Latest operation start time: 09:45:27.947 EST Thu Sep 9 2010
Latest operation return code: OK
RTT Values:
Number Of RTT: 1000 RTT Min/Avg/Max: 64/64/67 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 SD Jitter Samples: 999
Number of DS Jitter Samples: 999
Source to Destination Jitter Min/Avg/Max: 0/1/1 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/1/3 milliseconds
Source to destination positive jitter Min/Avg/Max: 1/1/1 milliseconds
Source to destination positive jitter Number/Sum/Sum2: 48/48/48
Source to destination negative jitter Min/Avg/Max: 1/1/1 milliseconds
Source to destination negative jitter Number/Sum/Sum2: 48/48/48
Destination to Source positive jitter Min/Avg/Max: 1/1/3 milliseconds
Destination to Source positive jitter Number/Sum/Sum2: 192/194/200
Destination to Source negative jitter Min/Avg/Max: 1/1/3 milliseconds
Destination to Source negative jitter Number/Sum/Sum2: 191/193/199
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): 11
MOS score: 4.06
Number of successes: 110
Number of failures: 1
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never
Thanks for any insight
BOS3825#sh ip sla statistics detail
Round Trip Time (RTT) for Index 10
Latest RTT: 64 milliseconds
Latest operation start time: 09:45:27.947 EST Thu Sep 9 2010
Latest operation return code: OK
RTT Values:
Number Of RTT: 1000 RTT Min/Avg/Max: 64/64/67 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 SD Jitter Samples: 999
Number of DS Jitter Samples: 999
Source to Destination Jitter Min/Avg/Max: 0/1/1 milliseconds
Destination to Source Jitter Min/Avg/Max: 0/1/3 milliseconds
Source to destination positive jitter Min/Avg/Max: 1/1/1 milliseconds
Source to destination positive jitter Number/Sum/Sum2: 48/48/48
Source to destination negative jitter Min/Avg/Max: 1/1/1 milliseconds
Source to destination negative jitter Number/Sum/Sum2: 48/48/48
Destination to Source positive jitter Min/Avg/Max: 1/1/3 milliseconds
Destination to Source positive jitter Number/Sum/Sum2: 192/194/200
Destination to Source negative jitter Min/Avg/Max: 1/1/3 milliseconds
Destination to Source negative jitter Number/Sum/Sum2: 191/193/199
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): 11
MOS score: 4.06
Number of successes: 110
Number of failures: 1
Operation time to live: Forever
Operational state of entry: Active
Last time this entry was reset: Never
Voice Over IP
Last Comment
Alex Bahar
http://thwack.com/forums/p/13329/85743.aspx
this link follows what you are looking at and your mos looks good :)
Greg
this link follows what you are looking at and your mos looks good :)
Greg
ASKER
I can ping site to site. The call quality is somewhat random. over this vpn is only voice- the network is not converged.
ASKER
My QOS on this link is:
ORD3825#sh policy-map int s0/0/0:0
Serial0/0/0:0
Service-policy output: Qos_Policy
Class-map: ef (match-any)
5179048 packets, 345710908 bytes
5 minute offered rate 61000 bps, drop rate 0 bps
Match: ip dscp ef (46)
5179048 packets, 345710908 bytes
5 minute rate 61000 bps
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 90 (%)
Bandwidth 1382 (kbps) Burst 34550 (Bytes)
(pkts matched/bytes matched) 690896/44338396
(total drops/bytes drops) 0/0
Class-map: af41 (match-any)
83391 packets, 10719915 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp af41 (34)
83391 packets, 10719915 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 265
Bandwidth 9 (%)
Bandwidth 138 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 149/20719
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
156217 packets, 9813568 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
ORD3825#
ORD3825#sh policy-map int s0/0/0:0
Serial0/0/0:0
Service-policy output: Qos_Policy
Class-map: ef (match-any)
5179048 packets, 345710908 bytes
5 minute offered rate 61000 bps, drop rate 0 bps
Match: ip dscp ef (46)
5179048 packets, 345710908 bytes
5 minute rate 61000 bps
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 90 (%)
Bandwidth 1382 (kbps) Burst 34550 (Bytes)
(pkts matched/bytes matched) 690896/44338396
(total drops/bytes drops) 0/0
Class-map: af41 (match-any)
83391 packets, 10719915 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp af41 (34)
83391 packets, 10719915 bytes
5 minute rate 0 bps
Queueing
Output Queue: Conversation 265
Bandwidth 9 (%)
Bandwidth 138 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 149/20719
(depth/total drops/no-buffer drops) 0/0/0
Class-map: class-default (match-any)
156217 packets, 9813568 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
ORD3825#
You have no dropped packets which is a good start.
What are the call quality issues?
which codecs do you use?
Which hardware?
Have you tried any free / trial tools to test the ping quality.
I would suggest using a free trial of whats up gold or solarwinds ip monitor.
This should provide information about your line that you can take back to your isp.
Greg
What are the call quality issues?
which codecs do you use?
Which hardware?
Have you tried any free / trial tools to test the ping quality.
I would suggest using a free trial of whats up gold or solarwinds ip monitor.
This should provide information about your line that you can take back to your isp.
Greg
Your IP SLA and policy map show commands do not point to any issues. There is very little delay between your sites, and there is no jitter. You're not experiencing packet drops either. Obviously, my comments are based on the show command outputs.
You said >The call quality is somewhat random.
That makes it quite difficult to understand what causes the issue. Does it happen completely randomly? For example, have you ever noticed poor quality outside business hours like 10pm?
How would you describe the bad voice? Is it choppy, clipped, robotic?
You said >The call quality is somewhat random.
That makes it quite difficult to understand what causes the issue. Does it happen completely randomly? For example, have you ever noticed poor quality outside business hours like 10pm?
How would you describe the bad voice? Is it choppy, clipped, robotic?
ASKER
The issues present themselves as drops. The "please say that again" is most common. After 10... not sure as noone is using the phones at that time. What should I look at for evaluation software to monitor the call quality?
Broken/choppy/dropped voice happens when consecutive packets are lost or excessively delayed. This typically happens during network congestion.
We know that you are marking your RTP packet with EF, and they go into the priority queue according to the show policy-map interface output. So, we can say that the QoS within your LAN and WAN edge works fine.
We need to ask the following questions>
We know that you are marking your RTP packet with EF, and they go into the priority queue according to the show policy-map interface output. So, we can say that the QoS within your LAN and WAN edge works fine.
We need to ask the following questions>
- How does your service provider treat packets marked with DSCP EF (46) ?
- How much prioirity queue bandwidth does your service provider allocate for DSCP EF?
- What is the maximum number of simultaneous calls going out your WAN during busy hours? What codec do you use for voip over the WAN calls?
ASKER
Their edge routers qos is the same as mine.
At the most 4 or 5 calls at the same time. The Bandwidth is a full t1 to this office.
I have the exact setup in place in my Boston office with literally 8 times the number of extensions and people using the phones and using the same bandwidth, and configs.
G729a from The Avaya 5600 series phones, to the Avaya IP 500.
I do have a question about my layer 2 markings. The phones are sending 6, and 6.
Could this be an issue (even though the setting match in Boston)
Thanks-
At the most 4 or 5 calls at the same time. The Bandwidth is a full t1 to this office.
I have the exact setup in place in my Boston office with literally 8 times the number of extensions and people using the phones and using the same bandwidth, and configs.
G729a from The Avaya 5600 series phones, to the Avaya IP 500.
I do have a question about my layer 2 markings. The phones are sending 6, and 6.
Could this be an issue (even though the setting match in Boston)
Thanks-
Your layer 2 markings are only used by the switches. Router always looks at the TOS/DSCP in the IP header. So, as long as your IP header QoS is marked correctly, QoS on your edge router will work fine. On the switch ports, there should be plenty of bandwidth. I wouldn't expect much issues at the switchport.
4-5 calls consume nothing if you have full T1. You can even run on a 128kbps link dedicated purely to voip.
If the service provider's edge QoS marking/classifiation is the same as yours, then obviously your marking is consistent with the service provider network. That means there must be an issue in the service provider core network during congestion. I suspect 2 issues>
- RTP traffic does not go through the priority queue. That is causing packet drops. Or it is causing excessive delays, which again causes packet drops if the delay becomes larger than jitter buffer.
- Or the priority queue is not large enough, and it is policing. That causes packet drops.
4-5 calls consume nothing if you have full T1. You can even run on a 128kbps link dedicated purely to voip.
If the service provider's edge QoS marking/classifiation is the same as yours, then obviously your marking is consistent with the service provider network. That means there must be an issue in the service provider core network during congestion. I suspect 2 issues>
- RTP traffic does not go through the priority queue. That is causing packet drops. Or it is causing excessive delays, which again causes packet drops if the delay becomes larger than jitter buffer.
- Or the priority queue is not large enough, and it is policing. That causes packet drops.
ASKER
How can I prove this and then be able to say to Paetec "fix this"?
It won't be easy. Start with communicating the issue with them ans ask what kind of evidence they require, if IP SLA would be acceptable. Send your IP SLA config to them, get their confirmation that your verification method is valid.
You need to monitor your voice call quality during busy hours. Hopefully you'll catch a couple of bad IP SLA samples. And send these to the service provider as a proof along with good IP SLA samples.
I also suggest you to verify the IP TOS/DHCP value on your *incoming* voice packets. Verify that they are not changed/overwritten by the service provider in the WAN cloud. If the IP header TOS/DHCP change in the WAN, this also means that there is a router somewhere in the WAN that is incorrectly treating the QOS marking. This is not very likely, but you should check it just in case.
You need to monitor your voice call quality during busy hours. Hopefully you'll catch a couple of bad IP SLA samples. And send these to the service provider as a proof along with good IP SLA samples.
I also suggest you to verify the IP TOS/DHCP value on your *incoming* voice packets. Verify that they are not changed/overwritten by the service provider in the WAN cloud. If the IP header TOS/DHCP change in the WAN, this also means that there is a router somewhere in the WAN that is incorrectly treating the QOS marking. This is not very likely, but you should check it just in case.
ASKER
Is there a software and hardware config that you would recommend to monitor the traffic? My ISP will not accept the ipsla stats.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
what is the result of ping on the vpn please can you ping from both ends (depending on topology it might be nmore)
what other traffic is going on over the vpn.
Do you have times of good call quality?
Greg