Mailing List Archive

Create policy under policy options to change the next hop

policy-statement next-hop-self {
then {
next-hop self;
}
}

and then import this policy in bgp

protocols {
bgp {
group ibgp-peer {
type internal;

export next-hop-self;
Thanks,
Waj

-----Original Message-----
From: stewells@verizon.net [mailto:stewells@verizon.net]
Sent: Monday, October 20, 2003 4:17 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] JUNOS Equivalent to CISCO IOS next-hop-self


Does anyone know how to configure an JUNOS IBGP peer w/ the equivalent of
the Cisco next-hop-self attribute such that external routes advertised to
IBGP peers uses the IBGP next-hop interface instead of the EBGP next-hop
interface. Is the include-mp-next-hop command which should be under [edit
protocols bgp] the one I should use? I cant't seem to locate it in ver
5.3R2.4.

Thanks...

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .



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

I meant export that policy into bgp

-----Original Message-----
From: Niaz, Wajahat
Sent: Monday, October 20, 2003 4:26 PM
To: 'stewells@verizon.net'; juniper-nsp@puck.nether.net
Subject: RE: [j-nsp] JUNOS Equivalent to CISCO IOS next-hop-self

Create policy under policy options to change the next hop

policy-statement next-hop-self {
then {
next-hop self;
}
}

and then import this policy in bgp

protocols {
bgp {
group ibgp-peer {
type internal;

export next-hop-self;
Thanks,
Waj

-----Original Message-----
From: stewells@verizon.net [mailto:stewells@verizon.net]
Sent: Monday, October 20, 2003 4:17 PM
To: juniper-nsp@puck.nether.net
Subject: [j-nsp] JUNOS Equivalent to CISCO IOS next-hop-self


Does anyone know how to configure an JUNOS IBGP peer w/ the equivalent of
the Cisco next-hop-self attribute such that external routes advertised to
IBGP peers uses the IBGP next-hop interface instead of the EBGP next-hop
interface. Is the include-mp-next-hop command which should be under [edit
protocols bgp] the one I should use? I cant't seem to locate it in ver
5.3R2.4.

Thanks...

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .



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

On Mon, Oct 20, 2003 at 04:25:43PM -0400, Niaz, Wajahat wrote:
> Create policy under policy options to change the next hop
>
> policy-statement next-hop-self {
> then {
> next-hop self;
> }
> }
>
> and then import this policy in bgp
>
> protocols {
> bgp {
> group ibgp-peer {
> type internal;
>
> export next-hop-self;

This will read to routing loops in many topologies. Changing the
next-hop of IBGP-received routes to self must not be done.

Cisco's next-hop-self has this intelligence, JunOS not. You have
to do that manually by tagging EBGP-received routes and setting
next-hop self for them (and static/direct/whatever routes) when
re-advertising those to the IBGP mesh.


Regards,
Daniel

On Mon, Oct 20, 2003 at 11:00:52PM +0200, Daniel Roesen wrote:
> On Mon, Oct 20, 2003 at 04:25:43PM -0400, Niaz, Wajahat wrote:
> > Create policy under policy options to change the next hop
> >
> > policy-statement next-hop-self {
> > then {
> > next-hop self;
> > }
> > }
> >
> > and then import this policy in bgp
> >
> > protocols {
> > bgp {
> > group ibgp-peer {
> > type internal;
> >
> > export next-hop-self;
>
> This will read to routing loops in many topologies. Changing the
> next-hop of IBGP-received routes to self must not be done.

Sorry, I have to mention that this problem exists only on route
reflectors.

On non-RRs, above config is fine. Then again, I prefer configurations
which work everywhere without surprises. :-)


REgards,
Daniel

We are using this technique in our network without running into any problem.

How changing the next hop attribute for an EBGP learnt route will lead to
routing loops ?


-----Original Message-----
From: Daniel Roesen [mailto:dr@cluenet.de]
Sent: Monday, October 20, 2003 5:01 PM
To: Niaz, Wajahat
Cc: 'stewells@verizon.net'; juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] JUNOS Equivalent to CISCO IOS next-hop-self

On Mon, Oct 20, 2003 at 04:25:43PM -0400, Niaz, Wajahat wrote:
> Create policy under policy options to change the next hop
>
> policy-statement next-hop-self {
> then {
> next-hop self;
> }
> }
>
> and then import this policy in bgp
>
> protocols {
> bgp {
> group ibgp-peer {
> type internal;
>
> export next-hop-self;

This will read to routing loops in many topologies. Changing the
next-hop of IBGP-received routes to self must not be done.

Cisco's next-hop-self has this intelligence, JunOS not. You have
to do that manually by tagging EBGP-received routes and setting
next-hop self for them (and static/direct/whatever routes) when
re-advertising those to the IBGP mesh.


Regards,
Daniel

On Mon, Oct 20, 2003 at 05:08:13PM -0400, Niaz, Wajahat wrote:
> We are using this technique in our network without running into any problem.

Then you're probably not using route reflection in more complex
topologies.

> How changing the next hop attribute for an EBGP learnt route will lead
> to routing loops ?

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.


Best regards,
Daniel

On Monday, October 20, 2003, at 03:05 PM, Daniel Roesen wrote:


>
> Sorry, I have to mention that this problem exists only on route
> reflectors.
>
> On non-RRs, above config is fine. Then again, I prefer configurations
> which work everywhere without surprises. :-)
>

Actually, route reflectors SHOULD only apply NEXT_HOP reset
(self) policy on non-reflected routes. As such, it should
work as a generic configuration and is often a fine idea
given the observed benefits to update packing and the like.

-danny

On Mon, Oct 20, 2003 at 03:13:39PM -0600, Danny McPherson wrote:
> Actually, route reflectors SHOULD only apply NEXT_HOP reset
> (self) policy on non-reflected routes.

ACK. Where is the disagreement with what I said? :-)

> As such, it should work as a generic configuration

Uhm, can you rephrase? I'm not sure that I understand you correctly.


Best regards,
Daniel

On Monday, October 20, 2003, at 03:19 PM, Daniel Roesen wrote:

> On Mon, Oct 20, 2003 at 03:13:39PM -0600, Danny McPherson wrote:
>> Actually, route reflectors SHOULD only apply NEXT_HOP reset
>> (self) policy on non-reflected routes.
>
> ACK. Where is the disagreement with what I said? :-)

Here:

From: Daniel Roesen <dr@cluenet.de>

[...]

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", I'm saying you SHOULD
NOT per the route reflector SHOULD NOT change the NEXT_HOP on
reflected routes. 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.

>
>> 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. It SHOULD NOT break with route reflection
per it SHOULD only apply to non-reflected routes.

-danny

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

Just to give my experience:


..snip..

> policy-statement next-hop-self {
> then {
> next-hop self;
> }
> }
>
> and then import this policy in bgp
>
> protocols {
> bgp {
> group ibgp-peer {
> type internal;
>
> export next-hop-self;


in the policy-statement i would prefer doing this:

policy-statement next-hop-self (
then (
next-hop self
next policy
)
)


if you like to have more than one policy-statement, then "next-policy"
is the right way to go..

--jan

--
Jan Czmok, Network Engineering & Support, Global Access Telecomm, Inc.
Ph.: +49 69 299896-35 - fax: +49 69 299896-40 - sip:13129*522@inoc-dba.pch.net

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

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@puck.nether.net
[mailto:juniper-nsp-bounces@puck.nether.net]On Behalf Of Danny McPherson
Sent: Monday, October 20, 2003 6:05 PM
To: juniper-nsp@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@puck.nether.net
http://puck.nether.net/mailman/listinfo/juniper-nsp

On Tue, Oct 21, 2003 at 02:02:11AM +0200, Jan Czmok wrote:
> policy-statement next-hop-self (
> then (
> next-hop self
> next policy
> )
> )
>
>
> if you like to have more than one policy-statement, then "next-policy"
> is the right way to go..

The default action of a policy is "then next policy", so you're just
repeating the default.


Regards,
Daniel

On Mon, Oct 20, 2003 at 07:04:35PM -0600, Danny McPherson 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!

Care to explain one?

> >> 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..

Well, if you stick to "SHOULD NOT" for overwriting next-hops for
reflected routes, and you're saying (see above) that you know scenarios
where setting next-hop self for reflected routes makes sense, then
Juniper MUST NOT "fix" this in order not to remove the option to do so.


Best regards,
Daniel

"Paul Goyette" <pgoyette@juniper.net> writes:

> 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.

And worse, there is no elegant way to write this policy. I.e. it's not
possible to say

from {
bgp-source ebgp;
}
then {
next-hop self;
}

because the condition "bgp-source ebgp" does not exist. You have to
fiddle around by setting colors or such on the eBGP sessions and then
check ingfor this. Ugly, and error prone.

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

I can name some. Most networks (by number, not by deployed routers)
don't have a full lab setup where such issues can be seen before
deployment.

Robert

On Tue, Oct 21, 2003 at 09:43:07AM +0200, Robert Kiessling wrote:
> > 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.
>
> And worse, there is no elegant way to write this policy. I.e. it's not
> possible to say
>
> from {
> bgp-source ebgp;
> }
> then {
> next-hop self;
> }

*nod*

$ fgrep self vendor/juniper/JunOS-featurerequests
- match condition "protocol ibgp/ebgp" for easy next-hop-self handling

> because the condition "bgp-source ebgp" does not exist. You have to
> fiddle around by setting colors or such on the eBGP sessions and then
> check ingfor this. Ugly, and error prone.

Setting "color" might be dangerous as this influences best route
selection (but I was never able to imagine a real-world case where
this really hurts). Using "tag" is better.

> > I am not aware of any instances where this has been discovered
> > only after deployment in production networks.
>
> I can name some. Most networks (by number, not by deployed routers)
> don't have a full lab setup where such issues can be seen before
> deployment.

I know of at least three mid to large carrier/ISPs who (together with
their customers) found out the hard way. Not surprisingly, those are not
running around handwaving, admitting this fact (probably not even to
the vendor). :-)


Regards,
Daniel

Try this in 6.1 and later...

from {
route-type external;
}
then {
next-hop self;
}

Should get what you want.

-joe


> -----Original Message-----
> From: juniper-nsp-bounces@puck.nether.net
> [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of
> Robert.Kiessling@de.easynet.net
> Sent: Tuesday, October 21, 2003 3:43 AM
> To: Paul Goyette
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] JUNOS Equivalent to CISCO IOS next-hop-self
>
>
> "Paul Goyette" <pgoyette@juniper.net> writes:
>
> > 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.
>
> And worse, there is no elegant way to write this policy. I.e.
> it's not possible to say
>
> from {
> bgp-source ebgp;
> }
> then {
> next-hop self;
> }
>
> because the condition "bgp-source ebgp" does not exist. You
> have to fiddle around by setting colors or such on the eBGP
> sessions and then check ingfor this. Ugly, and error prone.
>
> > I am not aware of any instances where this has been discovered only
> > after deployment in production networks.
>
> I can name some. Most networks (by number, not by deployed
> routers) don't have a full lab setup where such issues can be
> seen before deployment.
>
> Robert
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/junipe> r-nsp
>

On Tue, Oct 21, 2003 at 07:59:11AM -0700, Joe Soricelli wrote:
> Try this in 6.1 and later...
>
> from {
> route-type external;
> }
> then {
> next-hop self;
> }
>
> Should get what you want.

Uhm, this is neither in the Release Notes, nor in the documentation
of valid match conditions. Is this a "hidden command" (can't verify
myself, having no JunOS 6.1 box atm).


Best regards,
Daniel

On Tue, 21 Oct 2003, Daniel Roesen wrote:
> Uhm, this is neither in the Release Notes, nor in the documentation
> of valid match conditions. Is this a "hidden command" (can't verify
> myself, having no JunOS 6.1 box atm).

It's there in 6.1R1.4:
# set policy-options policy-statement bgp-test from route-type ?
Possible completions:
external External route
internal Internal route

I don't have an easy way to verify function on that box at the moment.

________________________________________________________________________
Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-ford@uiowa.edu, phone: 319-335-5555, fax: 319-335-2951

On Tue, Oct 21, 2003 at 10:41:14AM -0500, Jay Ford wrote:
> On Tue, 21 Oct 2003, Daniel Roesen wrote:
> > Uhm, this is neither in the Release Notes, nor in the documentation
> > of valid match conditions. Is this a "hidden command" (can't verify
> > myself, having no JunOS 6.1 box atm).
>
> It's there in 6.1R1.4:
> # set policy-options policy-statement bgp-test from route-type ?
> Possible completions:
> external External route
> internal Internal route
>
> I don't have an easy way to verify function on that box at the moment.

If I recall correct, you can configured it even in JunOS 5.x, but it
just didn't have any effect for BGP routes, as it only worked for OSPF
routes.

But it's been a while since I last looked at it.

/Jesper

--
Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456

One Unix to rule them all, One Resolver to find them,
One IP to bring them all and in the zone to bind them.

It's not hidden. Can't speak to the documentation. ;-)

lab@lab-RTR2# run show version brief
Hostname: lab-RTR2
Model: m20
JUNOS Base OS boot [6.1R1.4]
JUNOS Base OS Software Suite [6.1R1.4]
JUNOS Kernel Software Suite [6.1R1.4]
JUNOS Packet Forwarding Engine Support (M20/M40) [6.1R1.4]
JUNOS Routing Software Suite [6.1R1.4]
JUNOS Online Documentation [6.1R1.4]
JUNOS Crypto Software Suite [6.1R1.4]

lab@lab-RTR2# set from route-type ?
Possible completions:
external External route
internal Internal route
[edit policy-options policy-statement test]
lab@lab-RTR2# set from route-type

-joe
> -----Original Message-----
> From: Daniel Roesen [mailto:dr@cluenet.de]
> Sent: Tuesday, October 21, 2003 11:19 AM
> To: Joe Soricelli
> Cc: Robert.Kiessling@de.easynet.net; Paul Goyette;
> juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] JUNOS Equivalent to CISCO IOS next-hop-self
>
>
> On Tue, Oct 21, 2003 at 07:59:11AM -0700, Joe Soricelli wrote:
> > Try this in 6.1 and later...
> >
> > from {
> > route-type external;
> > }
> > then {
> > next-hop self;
> > }
> >
> > Should get what you want.
>
> Uhm, this is neither in the Release Notes, nor in the
> documentation of valid match conditions. Is this a "hidden
> command" (can't verify myself, having no JunOS 6.1 box atm).
>
>
> Best regards,
> Daniel
>

I believe that was 'from external' and not 'from route-type external'.

-joe

> -----Original Message-----
> From: juniper-nsp-bounces@puck.nether.net
> [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of
> Jesper Skriver
> Sent: Tuesday, October 21, 2003 11:51 AM
> To: Jay Ford
> Cc: juniper-nsp@puck.nether.net; Daniel Roesen
> Subject: Re: [j-nsp] JUNOS Equivalent to CISCO IOS next-hop-self
>
>
> On Tue, Oct 21, 2003 at 10:41:14AM -0500, Jay Ford wrote:
> > On Tue, 21 Oct 2003, Daniel Roesen wrote:
> > > Uhm, this is neither in the Release Notes, nor in the
> documentation
> > > of valid match conditions. Is this a "hidden command"
> (can't verify
> > > myself, having no JunOS 6.1 box atm).
> >
> > It's there in 6.1R1.4:
> > # set policy-options policy-statement bgp-test from route-type ?
> > Possible completions:
> > external External route
> > internal Internal route
> >
> > I don't have an easy way to verify function on that box at
> the moment.
>
> If I recall correct, you can configured it even in JunOS 5.x,
> but it just didn't have any effect for BGP routes, as it only
> worked for OSPF routes.
>
> But it's been a while since I last looked at it.
>
> /Jesper
>
> --
> Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456
>
> One Unix to rule them all, One Resolver to find them,
> One IP to bring them all and in the zone to bind them.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/junipe> r-nsp
>

In message <425CE0ADBE82F946AFBAE21AA54D4A8801CC281C@quark.jnpr.net>you write:
> It's not hidden. Can't speak to the documentation. ;-)

I'm not finding it in the docs. I'll file a PR and let the writer
know.

Thanks,
..Aviva

>
> lab@lab-RTR2# run show version brief
> Hostname: lab-RTR2
> Model: m20
> JUNOS Base OS boot [6.1R1.4]
> JUNOS Base OS Software Suite [6.1R1.4]
> JUNOS Kernel Software Suite [6.1R1.4]
> JUNOS Packet Forwarding Engine Support (M20/M40) [6.1R1.4]
> JUNOS Routing Software Suite [6.1R1.4]
> JUNOS Online Documentation [6.1R1.4]
> JUNOS Crypto Software Suite [6.1R1.4]
>
> lab@lab-RTR2# set from route-type ?
> Possible completions:
> external External route
> internal Internal route
> [edit policy-options policy-statement test]
> lab@lab-RTR2# set from route-type
>
> -joe
> > -----Original Message-----
> > From: Daniel Roesen [mailto:dr@cluenet.de]
> > Sent: Tuesday, October 21, 2003 11:19 AM
> > To: Joe Soricelli
> > Cc: Robert.Kiessling@de.easynet.net; Paul Goyette;
> > juniper-nsp@puck.nether.net
> > Subject: Re: [j-nsp] JUNOS Equivalent to CISCO IOS next-hop-self
> >
> >
> > On Tue, Oct 21, 2003 at 07:59:11AM -0700, Joe Soricelli wrote:
> > > Try this in 6.1 and later...
> > >
> > > from {
> > > route-type external;
> > > }
> > > then {
> > > next-hop self;
> > > }
> > >
> > > Should get what you want.
> >
> > Uhm, this is neither in the Release Notes, nor in the
> > documentation of valid match conditions. Is this a "hidden
> > command" (can't verify myself, having no JunOS 6.1 box atm).
> >
> >
> > Best regards,
> > Daniel
> >
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp