[99197] in North American Network Operators' Group
RE: Route table growth and hardware limits...talk to the filter
daemon@ATHENA.MIT.EDU (Alex Rubenstein)
Sun Sep 9 09:32:07 2007
Date: Sun, 9 Sep 2007 09:30:15 -0400
From: "Alex Rubenstein" <alex@corp.nac.net>
To: <nanog@nanog.org>
Errors-To: owner-nanog@merit.edu
> 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
