I need to implement a single QoS marking policy on +/- 100 VLANs. The MQC-policy contains 8 classes (including the class-default).
The 8 class-maps refer to 8 named extended ACL for a total of +/- 1000 lines. I don't need marking stats.
So I did the "qos vlan-based" on my interfaces and "no mls qos marking stats", but the 6500 still populates the QOS_TCAM with every class for every VLAN on every modules... no surprise that I get into TCAM_Mask capacity exceeded.
When I get this message, does it only means that ACL treatment will not be done in hardware but only in software, or does it means no ACL treatment will be done ?
In any case, how can I have the QoS_TCAM to hold a single copy of my policy ACLs for all the VLANs and modules on that 6500 ???
It explains a bit better the limitation for QOS TCAM on the 6500 platforms. About the first question I really don´t think that once you reached the TCAM limit this will be perform at the sofware level since if that was the case it may cause high cpu issues and that is why you see the error message warning that the limit was reached. The second question not sure if it is possible because when you configure an ACL, map the ACL to the QoS and when you apply the QoS policy on the interface, the switch programs the TCAM with that information.
I agree that if ACL processing is done in software it might cause high CPU usage but since I saw some documented high-cpu issues related to TCAM i thought maybe when HW capacity was exceeded it would revert back to software processing. ACL software processing is not all that bad since regular routers do it all the time. Not talking about the same speed, I know but... In some cases, higher CPU usage is better than no ACL treatment at all. Having an option to fall back, or not, to software processing would be even better.
On the second point, there might be a need for a separate TCAM area for each interface for policy-map counters or netflow stats etc, but there should be a way to share the QOS_TCAM entries when the same QOS_ACL is applied to multiple interfaces and no fancy features are needed.. How do people provision large ACLs on multiple VLANs? In the most efficient usage, the QOS_TCAM contains 4000masks and 32000entries. If these entries have to be split/dedicated to specific interfaces and not shared between interfaces, then if the same ACL is applied to 10 interfaces, the ACL has to be less than 400masks/3200entries. On 100 interfaces, it needs to be less than 40masks/320entries. It would make more sense if these entries could be shared instead of split if I don't need fancy features. And on these machines, 100interfaces is not rare.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...