Cos and DSCP - mappings

[fdebulois]

on an ingress port on switch A I set the COS value to 5 which is map to dscp 46 (I can check that when I change the CoS value the dscp value changes according to the cos-dscp map). On switch B (802.1Q trunk between the switches), I now look at the incoming packet. When on switch B I set the incoming Trunk to trust DSCP, i can see the dscp value set in switch A. But if I code the trunk as trust COS and look a tthe dscp value in the packet, I can see dscp=0 which means that the Cos was also set to 0.

It looks like switch 1 uses cos-dscp and dscp-cos maps internally but does not tag the ougoing packet at L2. IS this normal ?

I tested between 3550 and 2950.

Thank you

Fred

[royalblues]

wow seems to be a good observation.

Need to check this out.

BTW, can you check by removing the cos-dscp map when trusting the cos value?

Narayan

[fdebulois]

Yes I can check... later ;-)

Here are my 2 cents...

Since I've seen some references to "internal dscp" when reading the doc I assume the following:

When a packet enters with cos 5 it is map to internal DSCP (why I don't know but I've read that for 6500) using (cos-dscp map).

From that internal dscp (using dscp-cos map) a cos value is found so that the switch can use this cos value to use the right egress queue.

But nowhere I've found written that this COS value will be used to mark the packet at layer 2 which somehow makes sense since the outgoing link may be something else that a 802.1Q interface and therefore does not include the 802.1Q tag.

However since does not make sense since I think I should be able to prioritize a packet using L2 (802.1Q) tag all across my network assuming the packet is switched all the way.

Ok.. All I need is an aspirin !!!

What do you, guys think about that ..

Fred

[andrew.butterworth]

How is the trunk configured? I had a similar experience recently with a 2950. The customer had not changed the Native VLAN and the User VLAN was also using the default. Packets were arriving on the 802.1q Trunk for VLAN #1 untagged and therefore had no 802.1q header (so obviously no 802.1p CoS values). I changed the Native VLAN on either end of the trunk to an unused VLAN (500 I think?) and then we could see the 802.1q headers on frames arriving on VLAN #1.

HTH

Andy

[fdebulois]

Andy

Thank you for your answer

Cannot check the config at the moment but the Trunk was defined as encap 802.1Q on the 3550 side and as trunk (cannot define encap on 2950 since it only supports 802.1Q).

Native Vlan was not set .. will give it a try as soon as I get the machines...

Does HTH mean something ?.

[andrew.butterworth]

HTH - Hope This Helps....

Andy