Re: BGP Filtering

["William Herrin" <herrin-nanog () dirtside com>]

On Jan 15, 2008 12:51 PM, Dave Israel <davei () otd com> wrote:
>    I think I understand what you want, and you don't want it.  If you
> receive a route for, say, 204.91.0.0/16,  204.91.0.0/17, and
> 204.91.128.0/17, you want to drop the /17s and just care about the /16.  But
> a change in topology does not generally result in a complete update of the
> BGP table.  Route changes result in route adds and draws, not a flood event.
> So if you forgot about the /17s and just kept the /16, and the /16 was
> subsequently withdrawn, your router would not magically remember that it had
> /17s to route to as well.

Dave,

That's half-true.

The "routing table" is comprised of two components: the Routing
Information Base (RIB) and the Forwarding Information Base (FIB). The
RIB sits in slow, cheap memory and contains routes and metrics for
every route as announced by every neighbor. The FIB sits in fast,
expensive memory and contains the currently "best" route for each
destination. The FIB is built by choosing the best routes from the
RIB. Packet-forwarding decisions are made by consulting the FIB.

Opportunistically filtering routes from the RIB would have exactly the
problem you point out: routing updates are incremental. The knowledge
that the /16 has been withdrawn may not accompany the knowledge that
the /17s are available.

Opportunistically filtering more-specific routes from the FIB,
however, could be very valuable at the edge of the DFZ. If Cisco
supported such filtering, those Sup2's could have another few years of
life left in them. With 512m ram in a two-transit provider scenario a
Sup2 could handle upwards of 1M routes in the RIB. Unfortunately, they
can only handle 244k routes in the FIB.


Ben, coming back to your question: I don't think there is a way to
make the software filter the routes inserted into the FIB. I don't see
a reason why it couldn't be programmed to do that. But the fine folks
at Cisco didn't see fit to write that software. Its a pity 'cause it
would be very useful.

The next best thing you can do is statically filter /8's from distant
regions. You're posting to NANOG, so I assume that the RIPE and APNIC
regions are distant for you. Go to IANA's web site and download the
list of /8's assigned exclusively to each of those registries. For
each, create a set of /8 static routes towards each of your transit
providers with a route target address picked from an address block
that will disappear or become distant if your link to that transit
provider is severed. Then use prefix lists to filter more specific
routes within those /8's.

That should give you a result that's almost as good as if you carried
all the routes while cutting a bunch of routes from your table.

Regards,
Bill Herrin


-- 
William D. Herrin                  herrin () dirtside com  bill () herrin us
3005 Crane Dr.                        Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004