On 15/03/2010, at 7:37 PM, Richard A Steenbergen wrote: > The real mess here is the non-deterministic nature of what you're doing. > Someone flaps that /16 and now you've added 1000 new more specifics, > which might push you over the edge in FIB usage, with no way to predict > when or where it will happen. And yes you can probably consume a fair > bit of CPU by flapping a big aggregator over and over,
its analagous to the issues with fast-switching all over again. > but heck you used > to be able to do similar by flapping 0.0.0.0/32. :) 0.0.0.0/0. :) but yet, a very nice attack vector to remotely take out the internet. news at 11.. > Once you start > exposing these details to the end user though, things get problematic. > It's much easier just to sell them a bigger fib. indeed, the underlying assumption here is that one cannot build larger FIBs. at this point in time, we can. to my mind it has some merits. but only if your FIB is small to start with. cheers, lincoln. _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
