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

Fri Sep 21 16:33:06 UTC 2007

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