[c-nsp] Dynamic TCAM allocation/optimization? (was Re: N7K tcam handling)

[Richard A Steenbergen]

On Fri, Mar 12, 2010 at 01:40:27PM +1100, Lincoln Dale wrote:
> we have looked at this. many times.  it gets nondeterministic very
> very quickly and does not scale from a control plane perspective.

Of course what you COULD do with minimal effort is ye olde Foundry trick
of "if you have a covering default route, optimize away any more
specifics that point to the same next-hop". That technique worked pretty
darn well for simple edge aggregation boxes with a default pointing
upstream, back when they were shipping cards with 16k or 32k cam entries
and fast-cache style population. Plus if I were you I would never want
to admit to not being able to do something as well as Foundry. :)

We do something similar to this with Juniper, which has a policy hook
between the RIB->FIB export process where you can configure any actions
you would like. This means you can take any box, even say a small 1U
stackable EX4200, and learn a full BGP table via the RIB while blocking
the installation of the upstream routes to the FIB, and use a covering
default route instead. It certainly beats the old Cogent trick of using
two BGP sessions, one local for announcing to them, and one multihop for
receiving full routes from an upstream device.

-- 
Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)