[c-nsp] TCAM utilization on Nexus 9396

[James Bensley]

On Wed, 20 Mar 2019 at 19:14, Satish Patel <satish.txt at gmail.com> wrote:
>
> Thanks for clarification, i have noticed when i add 1 rules number
> bump +1 but i believe you can't go above 510 right? that is hard limit
> if i am not wrong.
>
> also changing in resource required reload.

Hi Satish,

I don't know this platform at all but, general rules for platforms with TCAMs:

Whether the TCAM is at 1% utilisation or 99% there should be no impact
to traffic forwarding rate for the features that use the TCAM (e.g.
ACLs, QoS, SPAN).

Yes you can sometimes fit more entries into TCAM than the stated number.
For example if in your config you have two entries in an ACL which are
contiguous e.g.:
1. 192.168.0.0/24
2. 192.168.0.1/24
These will often be aggregated into one single entry: 192.168.0.0/23
However, I wouldn't rely on this. If you devices supports 512 ACLs and
you need 512, you should probably chose a difference device to allow
for future growth or adjust your ACL plan/design.

It is generally OK to run a TCAM at 100%, for example if you have an
ACL that is 512 entries long and your TCAM can store 512 entries, this
is technically fine. However, as soon as you add the 513th entry chaos
may ensure. WIth ACLs as Tim said, the config often won't be applied
and an error presented on the CLI. With routing entries which are
dynamically learnt though and not explicitly configured, it is a
different story. If your routing space inside TCAM is full, when a
packet ingresses the device and there is no match for the destination
inside the TCAM the packet must be CPU punted to check the FIB in slow
memory. These slows will be very slow and experinace high packet drops
rates and your support desk phones will light up etc.

Often you can TCAM paritioning to give more or less space to a certain
feature however, this always required a reboot to implement.

Cheers,
James.