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

["Alex Rubenstein" <alex () corp nac net>]

> The problem with this is that if you reject the routes initially and
> then later need them, then they're not in your incoming BRIB to
> reconsider.  BGP is an incremental protocol.  You can either save an
> update or you can ignore it, but if you ignore it, it's just plain
> gone.

If BGP is an incremental protocol (which of course, I know it is), why
doesn't a certain vendor treat it that way?

 *cough* BGP Scanner *cough*.

In any event, if the feature was implemented post-received routes (just
like prefix-lists were with soft-reconfig), having a copy of the table
that was sent to you by a peer, this would be trivial to do in code.
Would it be CPU intensive? Perhaps, but so is having 225k routes and
climbing. I'd submit that the CPU burned to do a route lookup on a
BGP-RIB when a route is withdrawn or announced to see if something less
specific exists would not in fact be that bad -- routing lookups, isn't
that what a router is supposed to do?


--
Alex Rubenstein, AR97, K2AHR, alex () nac net, latency, Al Reuben
Net Access Corporation, 800-NET-ME-36, http://www.nac.net