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

Sun Jan 28 17:59:50 UTC 2007

On Jan 28, 2007, at 9:06 AM, Joe Provo wrote:

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

I'm not a big fan of redistribution as I've been bitten by it a
few times.  One of the biggest issues is that if a policy is being
updated and some periodic redistribution process runs the
policy at that instant is applied and things not in the policy at
that snapshot are not applied (intuitive enough - now).

For example, if you're redistributing routes into BGP and coloring
with a community based on a route match policy and some of those
routes aren't in the policy snapshot then they won't be "colored"
with communities or the like and may be leaked or not advertised
otherwise.  This is particularly ugly when you've employed "implicit
permit" external advertisement policies where routes that aren't
tagged with some value are passed by default.

Two lessons learned for me:

o If you're going to use redistribution - or not - ensure that all
external advertisement policies require explicit match of advertise
communities and default is to deny

o Don't unnecessarily touch policies or blindly overwrite them
periodically, utilize incrementally updated prefix lists as much as
possible

Given the two conditions above I'm not as wary of redistribution
and it may ease configuration managed as Joe suggests.

-danny