QOS Design Question

[mikegrous]

So the network will have a core 6500 and roughly 10 idf switches. A few vlans and a Voice VLAN. I will enable MLS QOS on all switches. I will trust the DSCP on the ports to the phones. I will trust DSCP on the trunk links into the cores, or do i trust COS since its L2? Is there anything else to take into consideration?

[Edison Ortiz]

Mike,

You can trust DSCP on the trunk ports. The command simply tells the switch to trust the QoS markings.

You also need to change the default QoS mappings to mls qos map cos-dscp 0 8 16 26  32 46 48 56

The SRND covers this in details

http://www.cisco.com/en/US/docs/solutions/Enterprise/WAN_and_MAN/QoS_SRND/QoSDesign.html#wp998207

Regards,

Edison

[mikegrous]

mls qos map cos-dscp 0 8 16 26  32 46 48 56

So since the port is an access port to the phone i cannot trust COS as it doesnt have a dot1q header so no COS.  So i trust DSCP, i am confused as to why i would need to make sure the COS to DSCP mapping is correct? Is that so when it sends the packets up the trunk it marks the COS correctly?

[Mahesh Gohil]

Hi mike,

your assumption seems to be correct. You are taking data from access port which do not understand cos but still trust dscp

and when it will handover to trunk port it will be converted to cos..at this time you need to rewrite the default

dscp-to-cos value ..

you can verify default by ""sh mls qos map dscp-cos" command and decide what exactly you need here

Regards

Mahesh

[Edison Ortiz]

By default, COS 3 maps to 24 and COS 5 maps to 40. These mappings will cause issues when a packet needs to be translated from COS and DSCP and viceversa.

If the phone sends a DSCP 46 marking, the switch will be able to map it to COS 5 and then back to DSCP 46 when going from a trunk port to an access port.

Regards,

Edison.

[mikegrous]

So should there be another hop after the 6500 (there isnt) but if there was i would need to manipulate the maps there to make sure it tags it with the correct dscp tag if it went to a access port. If it went to a trunk it would retain its original COS. Correct?

[lgijssel]

This is correct.

It's also why you should not use an untagged vlan (native) for qos traffic.

In general, you always use a trunk.

cos-dscp mappings should be set consistenly on all switches in the network.

regards,

Leo

[mikegrous]

And trusting DSCP on a trunk would be pointless as it will only send COS?

[lgijssel]

No, the dscp info is also there, only it sits in the ip header instead of the dot1pQ tag.

You can choose to trust dscp, you would typically do this when you want to support more than one dscp value per cos-class.

However, in that case you cannot differentiate between them at layer 2. Remember there are only eight cos classes (0 - 7) and 64 dscp classes.

The cos-dscp map defines to which dscp number your respective cos values are tied.

A proper qos design utilizes a consistant mapping between the two throughout the network.

My advice: Keep it simple, use the 'trust cos' and utilize a maximum of six classes (cos 0-6) for customer traffic.

Typically voice goes into cos5 (ef), video into cos 4 (af41) and voice/video control traffic into cos3 (af31)

If you like, you could use cos 1 and cos 2 for special purposes, such as preferring applications but I would not encourage this.

A good solution for real time traffic is still the most important goel for qos on the LAN.

regards,

Leo

[mikegrous]

If the DSCP is indeed in the IP Packet of the trunk why do we need to manipulate the COS-DSCP Map? Is it because of the COS to output queue mapping because we are going over a trunk? And if we were not going over a trunk it would use the DSCP-output-q map?

[lgijssel]

You typically want to have the cos value because it allows you to use the qos capabilities of your device at layer 2.

Otherwise there is not too much difference between the use of either type of markings.

By trusting one or the other you effectively invalidate the other because cos is used to reset dscp or vice versa at every switch it traverses.

The link below provides more detailon the concepts involved in qos on layer2 switches:

http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst2950/software/release/12.1_22_ea2/configuration/guide/swqos.html

Mandatory reading if you want to come uo with a good design!

regards,

Leo

[mikegrous]

I think i get it..

So When the packet comes in i trust dscp because it is access port.

It then checks the dscp to cos map and marks the COS as it sends it up the trunk.

On the other side of the trunk i can trust COS of DSCP, if i trust COS it will use the cos to dscp map if it sends it out an access port if it sends it out a trunk port it will retain its origial COS marking and so on and so on.

[lgijssel]

Congratulations!

I also think you got it!