North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: Route table growth and hardware limits...talk to the filter
> 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, http://www.nac.net
|