[c-nsp] 6500/7600 TCAM Usage

[James Bensley]

On 3 June 2016 at 08:10, Saku Ytti <saku at ytti.fi> wrote:
> Not really, BGP table growth is not random at all.
> http://www.potaroo.net/ispcol/2016-01/bgp2015.html

I was thinking of potaroo, and also;

http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp-active.txt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step

>> What puzzles me is: how do vendors go about that in
>> the long run? I have been using my search engine of
>> least distrust to no avail. Which platforms offer vastly
>> bigger TCAMs, like at least twofold, better an order
>> of magnitude?
>
> Not all platforms use TCAMs. Lot of Juniper kit, like MX, QFX10k, PTX
> use various types of DRAM solution, this makes FIB usually not your
> bottleneck, search time to larger database becomes an issue too.

If vendors switched to using hashed tables we would get consistent
look up times irrelevant of table size.

> Yes. But how to deal with that in hostile environment? There is
> stealth startup doing something like above, but I'm skeptical. I know
> some of them read this list, maybe they'll chime in.

If you're feeling brave you can test http://route-aggregation.net/ on
a live system and let the rest of us know how it goes? :) I'm keen to
try it but I have no opportunity.

Cheers,
James,