[c-nsp] Setting CS0 on ARP traffic

[Tony]

Thanks for your response.

Unfortunately that isn't an option. The carrier is NBN (National Broadband Network - Australia) a monopoly government backed provider that has been tasked with deploying FTTH to replace the existing copper CAN. These are essentially fibre services that are replacing existing copper/DSL services.

Anything other than CS0 is dropped, that is their policy, nothing I can do about it and can't choose an alternative provider :(

They have reached an agreement with the existing copper tail provider to forcible migrate existing copper services to fibre, once the fibre has been rolled out to each exchange area (first ones are pending later this year, it will likely be a total mess).

They aren't remarking, they are dropping anything not marked as CS0. Near as I can tell the reason being that at some point in the future (roadmap says 6-12 months) they will be deploying "business class" services that allow QoS for stuff other than CS0 (ie. more expensive for some QoS). The remarking they applied was done on this VLAN specifically and we've been told it can't be applied to the whole "port" and so it isn't scalable for them to apply the policy on each vlan/service.


Thanks,
Tony.


________________________________
 From: Ryan West <rwest at zyedge.com>
To: Tony <td_miles at yahoo.com> 
Cc: cisco-nsp <cisco-nsp at puck.nether.net> 
Sent: Thursday, 29 May 2014 9:37 PM
Subject: Re: [c-nsp] Setting CS0 on ARP traffic
 

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/