On Tuesday 31 March 2009 02:40:23 am Chris Cappuccio wrote: > 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?
So what you're saying, for example, is that customer comes along with 192.168.0.0/24, and asks you to assign 192.168.0.254/24, for instance, to your router interface. Well, what we generally do is separate the routing table from the BGP policy, i.e., rather than attach communities to static routes directly, we attach them to BGP export policies that reference prefixes via route-filters. In your case, if we had a customer like yours, their route would constitute a 'direct' prefix, meaning its entry into the routing table is taken care of. We would then include that route in a route-filter, which belongs to a policy where the community your border routers use to announce said aggregate to the world is attached. If the customer's router dies, or something happens to the link that takes the interface down, JunOS will delete the route from the routing table, and BGP will withdraw it from within the core all the way to/through the upstream. Your mileage may vary, though. Hope this helps. Mark.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ juniper-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/juniper-nsp
