[c-nsp] TCAM refresher

[Chris Woodfield]

To answer a question earlier in the thread, a TCAM overflow event  
causes only the prefixes that don't fix to be process switched. The  
TCAM is populated in order of longest-prefix-first, which means that  
in the case of TCAM overflow the shortest prefix matches are the ones  
that will be software-switched. In my own testing this wound up  
maxing out the Sup2 at around 110-120Mbps for a MSFC-switched flow,  
with no active route churn eating up cpu time.

Tony, which type of aggregation did you benchmark - adjacent prefix  
aggregation (x.0/30 + x.4/30 = x.0/29), or overlapping prefix removal  
(x.0/24 + x.128/25 = x.0/24)? If both, which one seemed "easier" to  
do? Do you recall what sort of FIB size savings were realized?

-C

On Mar 14, 2007, at 6:22 PM, Tony Li wrote:

>
> On Mar 14, 2007, at 2:28 PM, Florian Weimer wrote:
>
>> * Tony Li:
>>
>>>> And your ARP table entries.  Of course, Cisco could fix that by
>>>> aggregating entries before they end up in the TCAM: If both
>>>> 192.0.2.8/30 and 192.0.2.12/30 have the same adjacency, you can do
>>>> with a route for 192.0.2.8/29 instead.  But there are probably
>>>> reasons
>>>> for not doing it this way in the first place, so it's unlikely that
>>>> such a change will arrive in time.
>>
>>> Such a change is computationally intensive and would frequently  
>>> cause
>>> problems with processor overload.
>>
>> Just out of curiosity, have actually you benchmarked this?
>>
>> (But I admit, the necessary code changes before you could do this  
>> look
>> pretty significant.)
>
>
> It's been implemented and benchmarked (albeit in a previous life).
> It is very CPU intensive and it is complicated.  At this point, you
> should not expect this to save you from near-term FIB overflow.
>
>
> On Mar 14, 2007, at 2:33 PM, Chris Griffin wrote:
>> How about unnecessary specifics in the presence of a valid covering
>> route?  I imagine the concern would be the potential CPU increase
>> if that covering route went away and you had to install a ton of
>> specifics into the FIB, but it might be a good optional feature.
>
>
> Yet another case in the same analysis.  There are a fair number more.
>
> Tony
> _______________________________________________
> 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/
>