ME3400 QinQ DSCP marking

[pic_whizz]

Hi,

Please could someone tell me the ME3400 non E variant is able to carry DSCP marking with QinQ?

Many Thanks,

Pic_Whizz

[rsimoni]

Hi there,

I don't see why not. DSCP field is carried on the IP header. The .1q tags do not alter it. The same is true also if you have a single .1q tag on top of it. So one or two .1q tags don't make any difference.

Do you have in mind some particular scenario for which your doubt is pertinent?

Riccardo

[pic_whizz]

Thanks Riccardo,

Let's jusy say our WAN service provider has told me they cannot support trusting of DSCP values with QinQ because they have deployed the ME3400 (non E). They suggested replacing with ME3400E or 3560 which does work apparently?? Hence the question. I too believe this should not affect DSCP markings. Maybe it's a bug??

Any more thoughts?

Thanks.

[rsimoni]

So, if I have undertstood correctly, you are handing to your SP some IP traffic with DSCP value being set and they perform QinQ encapsulation on Me3400 switches facing your devices but they say that they are not able to trust DSCP on those metro switches due to platform limitation and therefore they will reset it to zero? Is this your scenario?

Also, you are handing to your SP tagged or untagged traffic?

Riccardo

[pic_whizz]

Hi Riccardo,

Yes, exactly as you describe this is the scenario. We hand them traffice untagged with DSCP markings present.

Any ideas?

Thanks.

[rsimoni]

ok good, but I still don't understand the issue your SP is facing. On me3400 there is no concept of mls trust dscp as QoS is more similar to router QoS (MQC). So by default DSCP is trusted (hence kept) on all ports without expressely configure a command to do so.

So the DSCP value see at ingress on qinq tunnel port (the one you set) should be preserved on the egress port at the end of the tunnel. Have you tried to set a sniffer to see if it is still there.

If it is not there your SP is applying some QoS policy map which do some re-write operation which reset your DSCP.

If you can share what is the exact problem you see or they complain about I could have a look and try to help you more deeply, but with the info I have now I can only tell you that dscp in general terms should be preserved end to end if if qinq is done on me3400.

Riccardo

[pic_whizz]

Hi Riccardo,

I have just read this on CCO:-

"Support for ingress QoS classification for QinQ-based service on 802.1Q tunneled ports (ME 3400E only)"

This is on the release notes for 12.2.53SE

I'm not too sure if this was just an early release feature and that maybe this has now been fixed on the standard ME3400?

Any ideas?

Thanks.

[rsimoni]

that is available for me3400e only. however trust and classification are not the same thing. As I wrote also on me3400 trust is possible as it is the default behaviour also on tunnel ports.

The point to be clarified is what is the actual problem your SP is facing with regard to trust dscp.

Maybe I can help you (them) if I have a more concrete example to work with.

Riccardo

[Hashiem.croeser]

To reiterate Ricardo's sentiments, there are implicit trusts on the UNI (and NNI) ports on the ME3400.

I suspect its not your SP's ME3400 that's remarking your DSCP's but more likely other upstream nodes (other MEA's, PE's, and possibly P) or perhaps your own CE. You can use an extended ACL to check if you sending the correct markings out of your CE first (both ends).

Let us know how that goes.

Rgds.

Sent from Cisco Technical Support iPad App