[c-nsp] Setting CS0 on ARP traffic

[Ivan]

I ran into this same issue.  In my case the carrier only took CS0 and 
CS6.  No issues with ARP (CS6) but it turned out IPv6 neighbour 
discovery is marked CS7.  I am still without a solution...


On 29/May/2014 11:37 p.m., Ryan West wrote:
> First thing, that's a bad carrier. Second, they are already remarking, so why bother?  If your 7609 was using a routing protocol, that would be CS6 as well.
>
> Personally, I would go the route of terminating services with that carrier, sounds like you'll be getting more surprises in the future.
>
> Sent from handheld.
>
>> On May 29, 2014, at 7:27 AM, "Tony" <td_miles at yahoo.com> wrote:
>>
>> 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.
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>