Route table growth and hardware limits...talk to the filter
mksmith at adhost.com
Fri Sep 21 16:05:20 UTC 2007
On Sep 21, 2007, at 7:18 AM, Pekka Savola wrote:
> 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
> 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?
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.
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
More information about the NANOG