[c-nsp] Setting CS0 on ARP traffic

Ryan West rwest at zyedge.com
Thu May 29 07:37:01 EDT 2014


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/



More information about the cisco-nsp mailing list