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 <[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/
