[99196] in North American Network Operators' Group
Re: Route table growth and hardware limits...talk to the filter
daemon@ATHENA.MIT.EDU (Randy Bush)
Sun Sep 9 05:30:21 2007
Date: Sun, 09 Sep 2007 14:58:55 +0530
From: Randy Bush <randy@psg.com>
To: Tony Li <tli@cisco.com>
CC: Forrest <forrest@almighty.c64.org>, nanog@nanog.org
In-Reply-To: <B0CC0DDF-E904-4EF2-83C7-5B8E82A839F1@cisco.com>
Errors-To: owner-nanog@merit.edu
>>> 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
