North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: Route table growth and hardware to the filter

  • From: Alex Rubenstein
  • Date: Sun Sep 09 09:40:54 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
> 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, [email protected], latency, Al Reuben
Net Access Corporation, 800-NET-ME-36,