Re: Juniper equivalent of Cisco's BGP Conditional Advertisements

From: Avram Dorfman (avram@juniper.net)
Date: Fri May 03 2002 - 12:13:27 EDT


On 5/3/02 10:53 AM, "HHH" <jnciecert@yahoo.com> wrote:

> It's just a variation of what you stated...kind of
> hard to explain without diagrams, but I'll take a
> shot..if you are customer of Provider A and Provider
> B, say that Provider A will be your main Provider, and
> you only want to advertise prefixes to Provider B if
> you lose advertisements(prefix) from Provider A, as
> with the cisco bgp conditional advertisement. Create
> a generate route of the prefixes you want to advertise
> with a contributing route from your Provider A. Can
> be a host/static route that not used in your network.
> Then at peering point with Provider B, you can match
> policy with next hop of Provider A, and not advertise
> it, otherwise advertise it conditionally. In essence,
> the generate acts as the variable. What do you think
> of this? I guess it does get complicated.

Well, if these are your prefixes, you shouldn't be getting a contributing
route for them from your provider A. Why would they be announcing your own
address space to you? A contributing route has to be a subset of the route
it is contributing to.

You'll notice that my example did not use an aggregate or a generate route -
it was just a static with a remote next hop. The next hop was the "variable"
that the export policy was looking for.

Also, keep in mind that if Provider A is announcing an aggregate to you in
addition to the specific subnet that you're trying to use for your
conditional, this still won't work, b/c it will still appear to be
reachable. A workaround for *that* is to make a small aggregate that is
identical to the "conditional subnet." This will have a reject next hop, and
you have to give it a worse preference than bgp. That way, the real
announcement will override it making it reachable normally. But when it goes
away, this "specific aggregate" will make your next-hop unreachable despite
having a less specific route still learned from Provider A.

What I'm not seeing is why you don't just send all your routes to Provider B
all the time, but with a "backup" community so they automatically local-pref
them to be worse than anything they learn from anybody else. They do get
full routes, right? So as long as Provider A is announcing your routes to
the Internet, Provider B should choose them over the ones they learn from
you. People also use as-path prepending to get the same effect.

-Avram



This archive was generated by hypermail 2b29 : Mon Aug 05 2002 - 10:42:35 EDT