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