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

[Paul Goyette]

I can confirm that more than one customer has noticed that the
next-hop-self is unconditional, and therefore one's policy needs
to be selective WRT which routes are affected by such a policy.

I am not aware of any instances where this has been discovered
only after deployment in production networks.

-----Original Message-----
From: juniper-nsp-bounces at puck.nether.net
[mailto:juniper-nsp-bounces at puck.nether.net]On Behalf Of Danny McPherson
Sent: Monday, October 20, 2003 6:05 PM
To: juniper-nsp at puck.nether.net
Subject: Re: [j-nsp] JUNOS Equivalent to CISCO IOS next-hop-self



On Monday, October 20, 2003, at 04:40 PM, Daniel Roesen wrote:

> 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"?

Yes, I can think of several!  ...and the spec says SHOULD 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.

Ahh, hence my language above.  If this is indeed the case, I'd say
Juniper SHOULD fix this..

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

Hrmm..  Can some from Juniper confirm?  I don't recall seeing this
problem in the deployments I'm familiar with?

-danny

_______________________________________________
juniper-nsp mailing list juniper-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp