I use communities attached to static routes at local routers in my network to "anchor" aggregate eBGP-announced routes specific to that locality. It's just a static route with community XXX:XXX and discard specified. They get redistributed through iBGP to the borders of the network, and, if the right community is attached, they get redistributed through eBGP to peers and upstreams. Straight forward enough, right?
Well then I guess the answer to my question is pretty simple too. We had a customer bring over an IP range which they want attached directly to an ethernet interface. Since this route has the same netmask as the static route, Juniper just dumps the static route and the border routers no longer have a route to redistribute to eBGP peers. While it's easy to just make the customer's routes use a more specific netmask within the network, it could be error prone. I'm sure there is a better way. So I'm curious what works for others in this scenario to keep announcing (and attaching a community to) a static route, even when a directly connected route with the same netmask exists. Or is there just a more preferred way of "anchoring" aggregate routes in this type of network configuration with JunOS? Chris _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
