VOIP distorted on network saturation 2

[seniortech01]

I think I am missing a few commands. Bandwidth is a full T-1. I'd prefer to use the correct ports too but the phone vender has no idea; only that they set the PBX to IP Precedence 5. I'm a MCSE of 10 years and I've worked with Cisco PIXs for a long time but QOS is specialty I could really use your assistance on. Thanks in advance.

ip cef
!
controller T1 0/0/0
framing esf
linecode b8zs
channel-group 0 timeslots 1-24
!
class-map match-any voip
match access-group 101
match ip precedence 5
!
policy-map voip-qos
class voip
priority 256
!
interface FastEthernet0/0
description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-FE 0/0$
ip address 192.168.10.50 255.255.255.0
duplex full
speed auto
no mop enabled
!
interface Serial0/0/0:0
ip address 192.168.11.2 255.255.255.0
ip nbar protocol-discovery
encapsulation ppp
load-interval 30
service-policy output voip-qos
!
access-list 101 permit udp any any range 16384 32767



2800#show policy-map int
Serial0/0/0:0

Service-policy output: voip-qos

Class-map: voip (match-any)
126379796 packets, 36195962291 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: access-group 101
0 packets, 0 bytes
30 second rate 0 bps
Match: ip precedence 5
126379799 packets, 36195962329 bytes
30 second rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 256 (kbps) Burst 6400 (Bytes)
(pkts matched/bytes matched) 10405755/2970746452
(total drops/bytes drops) 587630/169997042

Class-map: class-default (match-any)
781564525 packets, 618484231324 bytes
30 second offered rate 0 bps, drop rate 0 bps
Match: any

 

[ADB100]

Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 256 (kbps) Burst 6400 (Bytes)
(pkts matched/bytes matched) 10405755/2970746452
(total drops/bytes drops) 587630/169997042

It looks like you are not allocating enough bandwidth to the strict priority queue. Under normal load conditions the strict priority queue can use unused bandwidth from the class-default queue, however under congestion periods it will be limited to it's configured bandwidth (256Kbps). What codec are you using over this T1 and is there a CAC limit on how many calls are allowed? 256Kbps is only good for 3 simultaneous G.711 calls.

HTH

Andy

 

[seniortech01]

They are using G7.11 with 12 lines. I also found out that they are using comdial and I don't think the ports I am using are the right ones for comdial. I added UDP 2076, UDP 2077 and TCP 2078 to access list 101. It's a guess that I may not need the line "access-list 101 permit udp any any range 16384 32767" in this case. I'm having trouble confirming the correct ports to use for comdial.

 

[ADB100]

With the configuration you posted any more than 3 simultaneous G.711 calls and any network congestion you will have problems.....

Andy

 

[BuckWeet]

Also keep in mind that if you are using the 'priority' command any traffic that is matched by your class-map will be policed once it his the 256kbps threshold..

I would not match based the UDP range because that could classify non VoIP traffic.

You need to either set your priority up to bandwidth high enough to cover the 12 calls so that policing doesn't kick in or change it to the 'bandwidth' statement. However if you were to change it to the bandwidth statement you would lose your low latency queueing.. It would just then be class based weighted fair queueing.


BuckWeet

 

[ADB100]

Also keep in mind that if you are using the 'priority' command any traffic that is matched by your class-map will be policed once it his the 256kbps threshold..

It will be policed ONLY if there is congestion. I looked into this a while ago and there seems to be some vagueness on CCO regarding whether or not an LLQ is policed to its configured rate when the interface isn't congested. However it is only policed if the interface is congested. There is a link here, however I have tested this in the lab and it does behave as described:

http://www.cisco.com/en/US/tech/tk543/tk757/technologies_tech_note09186a0080103eae.shtml

I think the heart of the problem here is he wants to allow up to 12 simultaneous G.711 calls and has only allocated 256Kbps. 256Kbps is only good enough to handle 3 simultaneous G.711 calls.

Andy

 

[Cluebird]

If you're not too familiar with QoS and all the complexities involved, you can always use "autoqos voip" or the SDM to help you. Also, G.711 on WAN links is not a good idea. G.729 would work better without much difference in MOS, especially if you're trying to carry 12 simultaneous calls.

Regarding all the QoS mechanisms... a general rule is they don't kick in until congestion starts to become a factor. If congestion isn't a factor, managed unfairness doesn't kick in. Another finding, if you don't properly implement ALL the mechanisms, you won't get the proper result. That's why autoqos is so handy.

 

[seniortech01]

Guys thanks so much. I was onsite today and got more info. It is a comdial mp5000. I'm still not sure the exact ports this system uses. If anyones knows please advise.

The comdial mp5000 is suppose to support other codecs. If you think the users won't hardly notice the change from G7.11 @ 64kbps to G.729 I can try that.

Other than the priority setting and removing the access list with the UDP range do you think the config looks ok for QOS?

They aren't using all 12 lines at once. Maybe 4-5 at best. They don't want me to change the priority, they want to change the codec first and go from there.

 

[seniortech01]

Extended IP access list 101
10 permit udp any any eq 2076 (5348 matches)
20 permit udp any any eq 2077 (497911 matches)
30 permit tcp any any eq 2078 (6007 matches)

 

[BuckWeet]

ADB100,

Interesting.. Amazing how you can read and read for years and still learn things..

While you are correct in your statements, I assume since there is garbled voice that congestion is present someplace in the network. Most likely it is the WAN link that he is speaking of and therefore the policer is kicking in.


Thoughts?


BuckWeet

 

[BuckWeet]

Also one thing I would do if you have high amounts of traffic rates on that serial link always is to enable fair-queuing and random detection.

Using these mechanism helps with TCP global sync.


I believe this is the correct syntax (you might have to ? through it)

policy-map voip-qos
class class-default
fair-queue
random-detect dscp-based


BuckWeet

 

[ADB100]

BuckWeet,

Yes you are correct. If there is no congestion then the LLQ can use unused bandwidth from the other queues, however under congestion it will be throttled to its configured bandwidth - the traffic conforming to the rate will be expedited but any excess will just be dropped. This is different from the behaviour of the CBWFQ's. The original question was 'VOIP distorted on network saturation', so I assume when the WAN link isn't under congestion there are no VoIP quality issues?

I agree use random-detection, however the 'dscp-based' tag has limited use unless you are using DSCP (it can't hurt though). In this case as there are only 2-queues - 1 for VoIP and one for everthing else it might kick in, however you would need to look at the stats for the policy. Personally I would create multiple queues (VoIP RTP, VoIP Signalling, Control traffic and then everything else) and also remark (bleach) any unidentified traffic back to DSCP 0.

Just my preference though...

Andy

 

[BuckWeet]

Agreed on the LLQ, since there is congestion the policer of the LLQ is taking effect on the traffic. Thus causing some of his problems.

BuckWeet

 

[seniortech01]

Please advise, it appears that the IP Precedence is working so do I really need the access-list for the ports on the phone system? The phone system is the only thing configured with IP Precedence and the show policy-map shows it is working. Thoughts?
Match: ip precedence 5
117845261 packets, 33788154319 bytes
30 second rate 0 bps
Extended IP access list 101
10 permit udp any any eq 2076 (5348 matches)
20 permit udp any any eq 2077 (497911 matches)
30 permit tcp any any eq 2078 (6007 matches)

 

[ADB100]

Don't take this the wrong way but I think you need to concentrate your time on reading instead of putting in a 'quick-fix'. Have a read of Cisco's excellent QoS SRND here:

http://www.cisco.com/go/srnd

You need to develop a QoS policy, it doesn't have to be really deep but needs agreeing otherwise you will end up putting this together in one way and then 2-months down the line someone else will start configuring something else a different way.

You could simply trust the DSCP or IP Precedence, however what is stopping users setting IP Precedence 5 in their data? Should it be IPP 5? Ideally DSCP EF (46) should be used for Voice RTP as this is what the standard says.

HTH

Andy