I’m having a bit of an issue with our setup: 2x Nexus switches in VPC, performing QoS policing. I notice that QoS only applies in one direction, (upload from the clients’ view) and don’t see the reason yet.
Here’s a sample of my config for a client VLAN:
IP access list VLAN109
10 permit ip any any vlan 109
class-map type qos match-all VLAN109
match access-group name VLAN109
policy-map type qos Networkx
class VLAN109
police cir 50 mbps bc 200 ms conform transmit violate drop
interface port-channel46
switchport mode trunk
switchport trunk allowed vlan 1-9,11-19,21-29,31-4094
spanning-tree port type normal
mtu 9216
service-policy type qos input Networkx no-stats
service-policy type qos output Networkx no-stats
vpc 46
hardware access-list tcam region vacl 0
hardware access-list tcam region racl 256
hardware access-list tcam region e-racl 0
hardware access-list tcam region qos 512
hardware access-list tcam region e-qos 256
What am I missing here? I’ve had a similar setup before and both egress and ingress were policed as intended. Looking forward to your feedback!
Hmm, that’s interesting. The config looks fine as far as I can see. I’ve worked with Nexus devices using vPC and multi-chassis port channels before, and I can tell you that there is a lot of variety on which NX-OS version supports which features. Sometimes when using such port-channel scenarios, one direction is supported while the other is not, or it may be supported for physical ports but not SVIs. There are a lot of caveats when it comes to the NX-OS, platform, and configuration options.
Now having said that I was unable to find any documentation that mentions this particular scenario, however it may be worth it to take some time and research the specific NX-OS and platform combination you are using to see if there are any such limitations.
Also, comparing with other platform/NX-OS combinations that you have used in the past with a similar config that have worked may also be helpful in determining the issue. Let us know how you get along so that we can help you further in your troubleshooting process…
Thanks again for your feedback.
I believe it might have something to do with the TCAM allocation at this point. I’ll make a few changes but as you might now, any changes require a reload, which is not easy in production.
After reading a bit on the different TCAM regions (which I dare say are poorly documented on the Cisco side), I’m making some changes:
hardware access-list tcam region ifacl 256
hardware access-list tcam region redirect 256
hardware access-list tcam region e-racl 256
hardware access-list tcam region vacl 256
Yes, unfortunately, Cisco documentation can be lacking at times, especially in such specific and specialized cases. Let us know how you get along… if you have any more info let us know so that we can help you further in your troubleshooting process…
hardware access-list tcam region e-qos 0
hardware access-list tcam region e-qos-lite 256
hardware access-list tcam region vacl 256
vacl at 0 has a detrimental effect it seems. e-qos has a width of 2 so 256 => 512 used in the egress table, hence I switched to e-qos-lite and used the “service-policy no-stats” command on the interface itself.