On 3 June 2016 at 08:10, Saku Ytti <[email protected]> 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, _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
