Traffic shaping for 1720/21 to prioritize RTP packets 1

[573dawn]

Hi All, I am trying to solve a problem with voice telephony and have repreatedly been told that I need to have my ciscos prioritizing my packets. I have an avaya IP400 system which consistently drops calls to a remote location. I can see no real issues with my PTP T1 as far as packet loss or errors. The circuit has been tested to death but shows clean. I have some discards, both tx & rx between the 2 locations, but nothing that seems unusual.

As far as I can tell the avaya uses RTP packets on ports between 49152-53246. I have 1720/21 on both ends of the PTP, queuing is fifo, all routing static. Software is 12.2 on one end, 12.3 on the other. I have some cisco background, but never with voice. Any help would be much appreciated!

Thanks, Dawn

 

[plshlpme]

is the T1 regularly congested?
are the calls simply dropping or are you experiencing jitter and other voice issues?

is your avaya IP400 marking packets with a different tos so that you can distinguish your voice from your data?


it is pretty easy to create a quick qos policy at both ends of your link that will reserve bandwidth for your voice calls.

llq will also ensure that voice packets are first to be processed instead of fifo.

 

[573dawn]

Hi plshpme, the T1 is regularly at under 5% overall usage, very underutilized. If I force large quantities of data across I do get jitter, but I practially have to force that to occur, i.e. installing a large program or moving a large file. Since I'm the only person who does those things, I do them after hours.

We do have some issues where one party can hear the other, but not both, but those calls don't actually drop. There are many many calls that do fully drop however.

I'm not sure how to answer regarding tos, as far as I can tell the packets the avaya creates are rtp, I have asked my vendor to verify that.

Can you please tell me what llq is? I have not had to deal with queuing other than fifo.

Thanks, Dawn

 

[pgordemer]

AVAYA tags its packets, here is a policy you can apply to each side to give Voice Packets priority.



class-map match-any VoIP
match ip dscp ef
match ip dscp af41

policy-map voipQos
class VoIP
priority 768
class class-default
fair-queue
random-detect dscp-based

Interface XXXXX
service-policy output voipQos


I use this with IP office and Avaya 402 units and it works fine

 

[573dawn]

gordemer, thank you very much, I will apply that immediately.

Dawn

 

[573dawn]

gordemer, is there any way I can see the prioritization in the routers? I really appreciate it.

Thanks, Dawn

 

[573dawn]

One more silly question, should I apply this only to my serial interfaces? Or should it apply to the fastethernet too?

Thanks, Dawn

 

[ADB100]

To see the stats from the policy you created just use the command:

show policy-map interface serial x/x

This should only be applied to your Serial interface.

HTH

Andy

 

[573dawn]

ABD100, thanks! I have only applied it to the serials.

Dawn

 

[573dawn]

Here is what I am seeing, please tell me if I am interpreting this correctly: There have been 107223 packets that are VoIP and have been given priority. The remaining 79752 packets are any data other than VoIP. I have lost no packets of either type. Policy is working as it should. Thanks, Dawn

to3mm#sho policy-map int se0
Serial0

Service-policy output: voipQos

Class-map: VoIP (match-any)
107223 packets, 21873492 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip dscp ef
107223 packets, 21873492 bytes
5 minute rate 0 bps
Match: ip dscp af41
0 packets, 0 bytes
5 minute rate 0 bps
Queueing
Strict Priority
Output Queue: Conversation 264
Bandwidth 768 (kbps) Burst 19200 (Bytes)
(pkts matched/bytes matched) 490/99960
(total drops/bytes drops) 0/0

Class-map: class-default (match-any)
79752 packets, 7936736 bytes
5 minute offered rate 20000 bps, drop rate 0 bps
Match: any
Queueing
Flow Based Fair Queueing
Maximum Number of Hashed Queues 256
(total queued/total drops/no-buffer drops) 0/0/0
exponential weight: 9

dscp Transmitted Random drop Tail drop Minimum Maximum Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh prob
af11 0/0 0/0 0/0 32 40 1/10
af12 0/0 0/0 0/0 28 40 1/10
af13 0/0 0/0 0/0 24 40 1/10
af21 0/0 0/0 0/0 32 40 1/10
af22 0/0 0/0 0/0 28 40 1/10
af23 0/0 0/0 0/0 24 40 1/10
af31 0/0 0/0 0/0 32 40 1/10
af32 0/0 0/0 0/0 28 40 1/10
af33 0/0 0/0 0/0 24 40 1/10
af41 0/0 0/0 0/0 32 40 1/10
af42 0/0 0/0 0/0 28 40 1/10
af43 0/0 0/0 0/0 24 40 1/10
cs1 0/0 0/0 0/0 22 40 1/10
cs2 0/0 0/0 0/0 24 40 1/10
cs3 0/0 0/0 0/0 26 40 1/10
cs4 0/0 0/0 0/0 28 40 1/10
cs5 0/0 0/0 0/0 30 40 1/10
cs6 179/13768 0/0 0/0 32 40 1/10
cs7 0/0 0/0 0/0 34 40 1/10
ef 0/0 0/0 0/0 36 40 1/10
rsvp 0/0 0/0 0/0 36 40 1/10
default 80328/8001926 0/0 0/0 20 40 1/10

to3mm#

 

[plshlpme]

you can tweak the numbers a bit to suit your needs.

class-map match-any VoIP
match ip dscp ef
match ip dscp af41

policy-map voipQos
class VoIP
priority 768
class class-default
fair-queue
random-detect dscp-based

Interface XXXXX
service-policy output voipQos

that example is using llq (low latency queuing) to prioritize your voice class over the default class.
it is reserving 768kb (half your t1)
The default class has access to the whole pipe but as soon as the voice class starts seeing traffic it will back off the default class and take back the bandwidth it needs.

just keep in mind that since you are using llq for your voice traffic that if you exceed that number (768 in this case) the router will drop the exceeding packets.

did you put it on your serial interfaces at both sides of the link?

 

[573dawn]

plshlpme, yes I did put it on both sides' serial interfaces. I doubt very much we'll ever even get up to 768 on this circuit, the data overhead is very low and they max out their VCMs long before they max out their bandwidth.

I did discover yesteday that I had made a critical addressing error when I replaced a data switch trying to solve all the problems. I addressed the data switch with the same IP as my fa port on the cisco. Now that I have corrected that AND prioritized the traffic, the problems have gone to zero, at least for the few hours it's been corrected. Of course, most of my problems pre-dated the misaddressing. My vendor didn't configure the phone system correctly to begin with, I found that out courtesy of the very helpful folks over on the Avaya IPO forum.

This weekend will be the test, we are a marina on a weekender lake, if problems are going to continue or come back, today and tomorrow will show that as our call volume is tremendous on weekends.