[c-nsp] TCAM utilization on Nexus 9396

Satish Patel satish.txt at gmail.com
Sun Mar 24 15:19:28 EDT 2019


James, 

Thanks for wonderful explanation.. now it’s much clear in my mind how to hand it better way, I had multiple subnets which I summarized and make it single line rule ;)  thanks for that tip. 
 

Sent from my iPhone

> On Mar 22, 2019, at 5:22 AM, James Bensley <jwbensley at gmail.com> wrote:
> 
>> 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.
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/


More information about the cisco-nsp mailing list