QoS not being applied

Dear all,

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!

Kind regards,
Vlad

Hello Vlad

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…

I hope this has been helpful!

Laz

Hi Laz,

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

We’ll see how it goes!

Hello Vlad

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…

Laz

Hi Las,

I have the solution:
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.

Unfortunately,

I still encounter issues:
%ACLQOS-SLOT1-2-ACLQOS_FAILED: ACLQOS failure: BCM SDK API bcm_field_entry_install(920) failed for unit 0 with error No resources for operation(-14) (message repeated 3 times)

Here’s my Egress TCAM carving

Egress:


                               Region                  GID     Base     Size     Width

                   Egress IPV4 QoS [e-qos](  25)      28        0        0        2
              Egress IPV6 QoS [e-ipv6-qos](  26)      29        0        0        2
                Egress MAC QoS [e-mac-qos](  27)      30        0        0        2
                   Egress IPV4 VACL [vacl](  28)      31     4352      256        1
              Egress IPV6 VACL [ipv6-vacl](  29)      32        0        0        2
                Egress MAC VACL [mac-vacl](  30)      33        0        0        2
                 Egress IPV4 RACL [e-racl](  31)      34     4608      256        1
            Egress IPV6 RACL [e-ipv6-racl](  32)      35        0        0        2
         Egress IPV4 QoS Lite [e-qos-lite](  33)      36     4864      256        1
                             Egress System(  38)      24     2560      256        1
        Egress FCoE Counters [fcoe-egress](  96)     110        0        0        1

Total: 1024

Also:

     ACL Hardware Resource Utilization (Mod 1)
     ----------------------------------------------------------
                                    Used    Free    Percent
                                                    Utilization

Ingress IPv4 PACL 3 253 1.17
Ingress IPv4 Port QoS 104 408 20.31
Ingress IPv4 VACL 2 254 0.78
Ingress IPv4 RACL 1 255 0.39
Egress IPv4 VACL 3 253 1.17
Egress IPv4 RACL 3 253 1.17
Egress IPv4 QoS Lite 101 155 39.45