One issue I’ve encountered with the Nexus 9k (specifically, the 93180YC-EX) is that it has very limited TCAM space. I’m guessing this is because the vision for the 9k involves implementation of ACI and eventual migration of the control plane to APIC… but the 9k does make a very cost effective core/aggregation switch for smaller deployments if you don’t need all the features of the 7k. That being said, I’ve been working on implementing QoS on the 9k and have had to review the essentials of TCAM in order to properly carve out enough space to handle the number of Access Control Entries (ACEs) for classification and marking.
Simply counting the number of ACEs will not give an accurate approximation of the number of TCAM entries required. It’s very easy to err-disable ports when applying a policy map due to TCAM exhaustion.
Accurately determining TCAM requirements is beyond the scope of this post; an in-depth discussion written by Yogesh Ramdoss may be found in the Cisco Support Forums and will be discussed on this site in follow-up postings.
As a networking professional, precision in planning is important. However, there is an argument to be made for “close enough” when precision comes at the expense of a very limited time budget – and when “close enough” will give a slight over-estimation for budgetary concerns; in this case, the number of TCAM entries.
Now, about that TCAM utilization…