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 [email protected] http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
