[c-nsp] 6500/7600 TCAM Usage

[Patrick M. Hausen]

Good morning,

interesting read. Of course running on SUP-720 based
gear we are fully aware of the issue. When the DFZ
was about to hit 500k IPv4 prefixes we limited the AS
path length and currently receive default routes from our peers.

Now that we are planning to replace our supervisor engines
(3BXL) with VSS capable ones (10G-3CXL) I'm pondering
to repartition TCAM for 768k IPv4 and 128k IPv6 and
to go back to full tables.
Of course monitoring the usage closely. ;-)

I'm not asking for a time estimate when we will hit that
limit. DFZ is at slightly over 600k v4 and about 30k v6,
currently. And predictions are difficult, especially about
the future.

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?

With RIRs handing out ever smaller prefixes I expect
the IPv4 address space fragmentation to accelerate.

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?

As I said I was searching for some general information
on the topic but all I found were blog entries on the
precise problem we face with the 6500 platform.
What's next?

I did not yet take the time to browse individual datasheets
of gear that is supposedly "bigger" than a 65k.

Some pointers would be most welcome.

Thanks,
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