[c-nsp] 6500/7600 TCAM Usage

[Patrick M. Hausen]

Hi,

> I'd stick to "only partial table" - while the XL TCAM is big enough for
> "more", the CPU is still slow, and full BGP on that box is stretching
> the limits quite a bit (we have a few still running with ~450k v4 routes,
> and peer restarts do cause too much CPU load for my taste).

OK. We were quite satisfied with 2 full feeds on each of 2 boxes.
I will reconsider.

> ASR9k goes to 4M prefix... plus incredibly fast BGP implementation.
> 
> It has other warts, of course, like "it's a router, so it has few ports
> and those are expensive".

OK, that's some specific gear to start with (studying specs). Thanks.
Given our current bandwidth needs, we could go with a single
10G or 40G interface and a router-on-a-stick architecture. ;-)

>> Or can one get around those rather arbitrary hard limits
>> completely? Is it possible to e.g. have a TCAM with timestamps
>> associated to entries, so one can employ a TCAM as
>> a route cache in LRU fashion and process-switch everything
>> new/unknown?
> 
> It would certainly be possible.  Would vendors be interested in spending
> money to let you run their old and now cheap coming from the second-hand
> market gear longer?  Answer yourself :-)

That question was rather about new gear and architectures. Are
there vendors/products going that route?

AFAIK TCAM is fundamentally expensive and power-hungry. So I'd
expect *someone* to at least explore that route.

Even with the VSS upgrade we expect another 2 years or so of productive
life for our 65k, not more. At the current state of white-box switching,
SDN, and what-have-you, we decided to buy us some more time to watch
the market, first.

Kind regards,
Patrick
--
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
info at punkt.de       http://www.punkt.de
Gf: Jürgen Egeling      AG Mannheim 108285

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20160603/20e38a41/attachment-0001.sig>