On Thu, Mar 11, 2010 at 02:23:12PM -0500, Chris Woodfield wrote: > Can you elaborate (or point me to docs) on how this dynamic allocation > works? Is the TCAM populated on demand based on traffic? I imagine the > old horror of the Sup1A's flow-based forwarding every time I hear > this...
I believe he means that you no longer have to statically allocate your TCAM at boot time into segments for IPv4/MPLS (72 bit TCAM entries) vs IPv6/Multicast (144 bit TCAM entries). This is a good thing for minimizing unnecessary reboots, especially with the uncertain growth rates of v4 vs v6, and has nothing to do with flow based routing. > And while we're on the subject, are there any reasons why Cisco (or > any other vendor AFAIK) has seriously looked into methods of > "optimizing" the TCAM? I'm thinking in terms of "If 10.0.0.0/16 and > 10.0.1.0/24 both have the same next hop, why do you need two TCAM > slots?" The most compelling argument I've heard against this type of FIB aggregation is that it would be completely non-deterministic. While it might greatly improve your FIB utilization, the amount that it helps would be entirely dependent on your configuration and topology, and you would never be able to predict when a routing change might vastly increase utilization. Imagine for instance that you change your route-maps, and now 10.0.1.0/24 and a bunch of other /24s are pointing to a different next-hop. Suddenly your FIB usage increases, exceeds the capacity of the router, and bad things start to happen. Having customers depending on such an unpredictable mechanism is... risky. Of course we all know the real reason is they'd rather sell you a bigger box with more TCAM, but the above scenerio is certainly not without its risks. :) -- Richard A Steenbergen <[email protected]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
