Route table growth and hardware limits...talk to the filter
alex at corp.nac.net
Sun Sep 9 13:30:15 UTC 2007
> 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
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 at nac.net, latency, Al Reuben
Net Access Corporation, 800-NET-ME-36, http://www.nac.net
More information about the NANOG