Route table growth and hardware limits...talk to the filter
randy at psg.com
Sun Sep 9 09:28:55 UTC 2007
>>> If you do save it in your BRIB, then you can do this filtering between
>>> RIB and FIB. That turns out to be a completely local feature, requiring
>>> no protocol changes or additions whatsoever, and thus does not even
>>> require an RFC or Internet draft. This feature has been seen in some
>>> circles under the name "ORIB". Ask YFRV's PM for it. ;-)
>>> Note that this feature *is* CPU intensive. This also does not decrease
>>> the RP RAM usage the way that update filtering would. In fact, due to
>>> the overhead of tracking filtered and non-filtered prefixes, there is
>>> additional RP RAM usage. YMMV.
>> so, bottom line, no help other than reducing fib?
> Not unless you're actually willing to accept a real change in the results.
how about a filter between in-rib and what you actually crank through
the churning clothes washer? pass on the in-rib, calc on the phyltered
data. so when shorter prefix is withdrawn, you can look for next best
note thatv my original proposal/case some years back allowed a number of
flavors of phylter, longer+same-next-hop, longer+same-as-path,
More information about the NANOG