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