Route table growth and hardware limits...talk to the filter

Michael Smith mksmith at adhost.com
Fri Sep 21 16:05:20 UTC 2007


Hello Pekka:

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  
> 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?
>
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  
around.

Regards,

Mike



More information about the NANOG mailing list