[j-nsp] static route priority for iBGP distribution

Mark Tinka mtinka at globaltransit.net
Mon Mar 30 19:50:07 EDT 2009


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/juniper-nsp/attachments/20090331/d77d2fab/attachment.bin>


More information about the juniper-nsp mailing list