|
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
On Fri, 21 Sep 2007, Michael Smith wrote: Well, how do you determine which routes to select from each provider and what to cover with defaults? How do you modify those settings once they're in place, particularly when you find exceptions in your design? I know the answers, but these are not easy questions to answer if you are a small provider that is smart enough to have multiple transit providers and enough clue to configure .* and ^$, but not enough clue to filter based upon upstream provider communities, flows and/or other dynamic means. One approach is to accept everything up to some prefix length, e.g., /16, /20, /21 or whatever, and filter the rest -- and point the primary default route to a non-tier1 so that it should _always_ have connectivity to all the world. Now, I guess one question is, what do you do when your tierN upstream you point default route to has routing or forwarding broken in such a way that your packets get dropped? Answer: you fix it manually or just ignore it and get SLA credits. However, very probably the same problem (e.g., BGP works but forwarding broken) would happen with full BGP feeds as well, so it's not like you're losing much. (FWIW, not sure if such a small provider needs other than default route and potentially routes of networks directly attached to its upstreams, but filtered full feeds may be a more politically correct approach for network administrators) The whole point of BGP, to my mind, is so that I *can* accept full routes from multiple providers and *may* elect to change that behavior for other reasons. I shouldn't have to modify my BGP configuration to support my vendors' inability to provide a device that can scale to the present demands of the global routing table. Last time I checked, they are here to support me, not the other way around. But the vendors aren't unable -- AFAIK, such devices have been available on the market for, what, 7-8 years now? It's just your wallet that's unable to get equipment that's needed to face the network that's getting more complex. In this case your choices seem to be a) dig out more money and get a better router, b) complain to vendor so that they make their implementations better (e.g., better memory or FIB utilization, transparently) so that you can continue doing exactly as before, at least for a while, c) change the configuration in such a manner that your gear remains viable for a longer while, or d) complain to IETF, ITU-T, ... or whoever to create a new protocol that would accomplish the same thing as b). I don't oppose b) but I fail to see how that could provide more than a quick term fix as the number of routes is climbing and the mountaintop is nowhere in sight. Similarly, d) would take so long that it won't help you here. So your real options are either a) or c). Whether the drawbacks of letting go of full, unfiltered BGP feeds is worth the cost of a) is up to you. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
|