[c-nsp] BGP memory on a 6500

[Richard A Steenbegen]

On Tue, Oct 03, 2006 at 03:22:53PM -0700, Tony Li wrote:
>  
> > I think that doesn't make the problem go away, only delays a bit (and
> > that might be quite small) when you see the problem.  On the plus
> > side, the current situation means that TAC will know what's going on
> > as the routing table creeps towards the cutoff point (modulo a
> > thousand or two routes +/- per provider).  When aggregatability has a
> > 50% non-deterministic span rather than a 1% non-deterministic span,
> > things will be rougher for longer.
> 
> I know some folks that have implemented this and found that it worked
> VERY well indeed.  Even in centralized portions of a Tier 1 network,
> this tended to reduce the forwarding table by 20-30% and in edgier
> situations it was more like 40%.  
> 
> It's well worth it, IMHO, and Cisco should take the opportunity to port
> it to IOS.

It works even better if you have a default route. :)

Foundry used such CAM aggregation to keep devices with only 8k 16k or 32k 
cam entries available alive for many years. Of course the simple "don't 
install unnecessary more specifics" solution is non-deterministic, but it 
is trivial to implement, and fairly effective at delaying new hardware 
purchases for a few years (thus explaining why it isn't implemented).

-- 
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)