nanog mailing list archives
Re: Route table growth and hardware limits...talk to the filter
From: Michael Smith <mksmith () adhost com>
Date: Fri, 21 Sep 2007 09:05:20 -0700
Hello Pekka: On Sep 21, 2007, at 7:18 AM, Pekka Savola 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.On Fri, 21 Sep 2007, Randy Bush wrote:Meanwhile, I have brought myself to three options:Has the option of using default route(s) occurred to you?welcome to v6. we forgot to sort out routing, so just don't do it. you're kidding, right?No, I'm not kidding but maybe we're talking about a different thing (you may have a more generalized network in mind).The way I see it, a network which is considering "Juniper M7i or Cisco 7300 plus a couple of switches" as an option does not _need_ 220K IPv4 routes in its routing table. Whether it has 150K, 40K (Hi Simon!) or 5K shouldn't matter that much from the functionality perspective.If we still disagree, it might be interesting to hear why filtered BGP feeds from upstream and appropriately placed default routes to cover the holes wouldn't provide a functionally and operationally an equivalent solution?
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.
Regards, Mike
Current thread:
- Re: Route table growth and hardware limits...talk to the filter, (continued)
- Re: Route table growth and hardware limits...talk to the filter Kevin Oberman (Sep 12)
- Re: Route table growth and hardware limits...talk to the filter Matt Liotta (Sep 20)
- Re: Route table growth and hardware limits...talk to the filter Jon Lewis (Sep 20)
- Re: Route table growth and hardware limits...talk to the filter Bora Akyol (Sep 20)
- Re: Route table growth and hardware limits...talk to the filter Jon Lewis (Sep 20)
- Re: Route table growth and hardware limits...talk to the filter John A. Kilpatrick (Sep 21)
- Re: Route table growth and hardware limits...talk to the filter Pekka Savola (Sep 21)
- Re: Route table growth and hardware limits...talk to the filter Randy Bush (Sep 21)
- Re: Route table growth and hardware limits...talk to the filter Pekka Savola (Sep 21)
- Re: Route table growth and hardware limits...talk to the filter Randy Bush (Sep 21)
- Re: Route table growth and hardware limits...talk to the filter Michael Smith (Sep 21)
- Re: Route table growth and hardware limits...talk to the filter Pekka Savola (Sep 21)
- Re: Route table growth and hardware limits...talk to the filter Donald Stahl (Sep 21)
- Re: Route table growth and hardware limits...talk to the filter John A. Kilpatrick (Sep 21)
- Re: Route table growth and hardware limits...talk to the filter Pekka Savola (Sep 21)
- Re: Route table growth and hardware limits...talk to the filter Warren Kumari (Sep 21)
- Re: Route table growth and hardware limits...talk to the filter Deepak Jain (Sep 21)
- Re: Route table growth and hardware limits...talk to the filter Pekka Savola (Sep 21)
- Re: Route table growth and hardware limits...talk to the filter Jon Lewis (Sep 22)
- Re: Route table growth and hardware limits...talk to the filter Joe Provo (Sep 22)
- RE: Route table growth and hardware limits...talk to the filter michael.dillon (Sep 23)