[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