[j-nsp] static route priority for iBGP distribution

[Chris Cappuccio]

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

[Mark Tinka]

Post by Chris Cappuccio
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>