QOS - VOIP traffic: payload and signalling

[nkhwaja]

Two questions For VOIP traffic,

Q.1. should the payload and signalling be assigned the same COS ?? to avoid losing Signalling traffic.

Q.2. flash upgrades to the phone sets are tftp. Should this traffic be assigned COS=0 or the same cos as the signalling traffic ? Phone flash gets corrupted if some of these packets are lost ?

thanks for your help,

[mheusinger]

Hello,

best practice puts signaling into another class than voip "payload" as you named it.

The reason is that the qos requirements are different. Signaling needs guaranteed bandwidth, voip needs low delay and guaranteed bandwidth.

TFTP can be placed into signaling class or in a separate class.

An example config could look like this:

ip cef

class-map match-any VoIP

match ip dscp ef cs5

match protocol rtp audio

class-map match-any VoIPsignal

match ip dscp cs3

class-map match-all TFTP

match protocol tftp

policy-map VoIPprio

class VoIP

priority percent 10

class VoIPsignal

bandwidth remaining percent 5

class TFTP

bandwidth remaining percent 5

class class-default

fair-queue

random-detect

interface Serial0

ip address ...

service-policy output VoIPprio

You would have to adjust the bandwith ratios for your needs and the interface naming to your environment.

The policy will give 10% of the link to voip traffic with lowest possible delay, 5% of the rest for voip signaling, 5% to TFTP and the rest for the other data present.

Hope this helps

[nkhwaja]

Thanks for the reply. I have 100Mb ethernet link between 6509s gig ports at two sites.

6509gig5/2------100mb trunk-----6509gig6/1

Q.1. Wondering if 'fair-queue / random-detect' will work on this link for default-class traffic ?? or

Q.2. should I set up COS-Queueing combination like other LAN traffic.

[pkhatri]

Hi,

The use of fair-queue is recommended because it will protect that class from a single greedy flow that is trying to hog the queue..

It also comes in handy if you are experiencing a DOS attack as it will restrict how much damage it can do.

Hope that helps - pls rate the post if it does.

Paresh

[mheusinger]

Hello,

"fair-queue" will always work and has some advantages as described by Paresh. WRED or "random-detect" should be used, if the majority of traffic is TCP. Usually this is the case and therefore I would recommend it as well.

Regarding CoS values and queueing for them:

The first question is, whether you have traffic marked with IP precedence/DSCP values other than default. In case you do not have this in your network, there is no need to modify queueing.

In case you need to prioritize some traffic (like VoIP, SAP, Citrix, etc.) compared to other traffic you should use IP precedence or DSCP values to mark it into different classes and adjust queueing according to the values in use.

Hope this helps! Please rate all posts.

Regards, Martin

[nkhwaja]

Thanks for the reply Martin and Paresh.

I do have voip traffic marked with cos=5, dscp=46 queued to priorityQ. The link in question is between two 6509s gig-ports. 6509 has PFC3. Im not sure if fair-queueing/wred is supported by 6509-PFC3 on ethernet gig trunk ports??

[pkhatri]

Actually, I don't believe you have the option of using fair-queue on the 6509s....but I could be wrong.

Paresh

[nkhwaja]

Could you please elaborate why you say that. Fair-q, and random-detect are valid options in the config command of policy-map under class-map. though 6509-PFC3 QOS chapter doesnot mention FairQ.

[pkhatri]

That's the reason I said that...I have not played with a PFC3 personally and there was no mention of 'fair-queue' in the command reference.

But if it is there, then I'm sure you should be able to use it.

Hope that helps - pls rate the post if it does.

Paresh