[j-nsp] JUNOS Equivalent to CISCO IOS next-hop-self

[Daniel Roesen]

On Mon, Oct 20, 2003 at 03:28:30PM -0600, Danny McPherson wrote:
> EBGP (and locally generated) routes are no problem. You will get
> problems when you pass on IBGP routes (route reflection!) and
> you overwrite the next-hop with self. See my other comment.
> 
> ---------------------
> 
> You stated that you "will get problems",

Yes, because he's unconditionally setting next-hop self egress on IBGP
sessions, no matter where the route he's sending to the IBGP neighbors
came from. This _does_ work as long as the router is not acting as
a route reflector.

> I'm saying you SHOULD NOT per the route reflector SHOULD NOT change
> the NEXT_HOP on reflected routes.

Uhm, route reflectors MUST NOT change NEXT_HOP of reflected routes.
Otherwise it might lead to routing loops. Can you outline an example
of where setting NEXT_HOP to self on a route reflector for reflected
routes makes sense, so that a "SHOULD NOT" is justified instead of a
"MUST NOT"?

> As such, you could enable setting of NEXT_HOP to self on a peering
> session and only locally generated and EBGP learned routes will be
> effected, NOT reflected routes.

No, this is only the case for IOS, not for JunOS. Junos "then next-hop
self" _unconditionally_ overwrites the NEXT_HOP, no matter where the
route came from (local, EBGP, or IBGP [route reflection]). This is
the problem at hand.

> >> As such, it should work as a generic configuration
> >
> > Uhm, can you rephrase? I'm not sure that I understand you correctly.
> 
> Enabling NEXT_HOP setting to self as a general policy is a good
> idea for many reasons.

We are in violent agreement here.

> It SHOULD NOT break with route reflection per it SHOULD only apply
> to non-reflected routes.

But with JunOS this is not the case. And I know for sure, several ISPs
were bitten by that.


Best regards,
Daniel