Route Reflector architecture and how to get small customer blocks in to BGP?

Sun Jan 28 16:06:19 UTC 2007

On Sat, Jan 27, 2007 at 01:39:54PM -0500, Pete Crocker wrote:
[snip]
> First, they've got a BGP full mesh of all their routers. They're  
> considering moving towards route reflectors. There's 2 core routers  
> per-POP. And anywhere between 5 and 15 edge/aggregation routers in a  
> POP. The current thought is to move to a route-reflector full mesh  
> between all the dual-core routers in each POP. The other alternative  
> is to deploy just 2 route reflectors for the entire network. Can  
> anyone point me towards real-world info on the pros and cons of each  
> approach? There seems to be little public info on why people do what  
> they do, it's more info on how to do it.

Data missing above: how many sites in this design overall?  What is 
the fragility of the inter-site links?  What are the growth plans? 
If "few", "robust" and "none-to-low" are the answers then yes only 
a pair or quartet of network wide RRs make sense. I wouldn't want 
to have to maintain it, nor really recommend it.  For any kind of 
growth, failure condition coverage, or many POP sites, then you'll 
want all the individual sites' core routers in the core iBGP mesh 
and a pair of RR trees per site, each rooted in the core router.
I'll leave the whole confederation issue aside for now.

> Assume that there are /29s assigned to customers. It would be a  
> beautiful world if these /29s could be easily rolled up in to /24s,  
[snip]
> router. Also, there's /22s to /19s per-pop in nice little  
> aggregatable subnets, so at least that's good.
[snip]
> - Should he use a static route which would be withdrawn if the link  
> went down? This would mean traffic to a down customer would be  
> dropped quicker, but flaps cause more BGP churn.

Select the latter.  Modifying networks statements for move/add/changes 
invites trouble.  Carefully constructed policies to redistribute 
your connected or static routes into iBGP and tagged appropriately
are a win. At the very least, you can limit to subnets of "my network's 
prefixes"; If possible, leverage the nice aggregation and limit to 
"my network's local prefixes" and you scope potential future havoc.

> - Would confederations help? Seems like overkill, but he could  
> aggregate at the POP level instead of the router level.

There is no need for small slices of the nice aggregatable local 
site prefixes to leave the site in eithe a confederation or an 
RR model.  Think of what device owns the tie-down route for the 
site-level, and how it is hearing that route, and how it is 
redistributing to the rest of your network.

Cheers,

Joe

-- 
             RSUC / GweepNet / Spunk / FnB / Usenix / SAGE