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_mi...@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@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@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/