[c-nsp] Setting CS0 on ARP traffic

[Tony]

Hi all,


A new carrier that we are using requires that all traffic to them is marked as CS0. Any traffic that is non-CS0 is dropped on ingress by the carrier.
We have connected the handoff from this carrier to a port on an ES20+ card in our 7609 (12.2.33.SRE9a).

The first test service was refusing to work and upon inspection by the carrier (packet capture) it was shown that the ARP traffic from our box was marked as CS6. I then applied a QoS policy outbound on the sub-int we had terminated the service on to try and set all traffic to CS0, but the ARP traffic was still CS6. The carrier then applied a policy inbound on their gear (ie. from our 7609 towards them) to set everything to CS0 and the service started happily working. I then put a switch between our 7609 and the carrier so that I could SPAN the traffic and capture it via tcpdump. The results look like this:

17:04:53.446268 vlan 30, p 6, vlan 10, p 6, arp who-has 10.1.7.178 tell 10.1.7.177

So you can see on the outer VLAN 30, it is set to "p 6" and on the inner VLAN 10 it is also set to "p 6".

The configuration of the interface on 7609 on our side looks like this (fairly standard):

interface GigabitEthernet4/4.300010
 encapsulation dot1Q 30 second-dot1q 10
 ip vrf forwarding xyz
 ip address 10.1.7.177 255.255.255.252


I logged a case with TAC and they responded with:

=====
We have tried this in our lab and this seem to be the default behavior.

There is a restriction on ES+ card which states that control plane packets generated from the switch are sent to a special TX queue and these packets do not match the egress QOS policies configured. Please refer the link:

http://www.cisco.com/en/US/docs/routers/7600/install_config/ES40_config_guide/es40_chap7.html#wp1540799

So this is the reason why you do not see any cos 0  packets on the other side even after applying a outbound service policy and see only cos 6 packets. I tried few other things but could not find a way around this restriction
=====

I've asked them to go back and have another look to see if there is something else that can be done.

I'm at a loss at this stage and appealing for any suggestions that people can think of, at this point in time it would appear that I have two options:

1. Terminate the services from this carrier on a different device that doesn't suffer from this problem.
2. Run the service through a switch (ie. 3750, like it is now) so that the switch can set the packets to CS0.

Both of these are sub-optimal solutions, so obviously we'd like to find a way to set the outbound traffic from the ES20 card to CS0 so that it can work how we expected it to.

Any suggestions appreciated.


Thanks,
Tony.