Route table growth and hardware limits...talk to the filter

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
candidate.

note thatv my original proposal/case some years back allowed a number of
flavors of phylter, longer+same-next-hop, longer+same-as-path,
longer+same_origin-as.

randy