Mailing List Archive

dr@cluenet.de (Daniel Roesen) writes:

> On Mon, Oct 20, 2003 at 05:08:13PM -0400, Niaz, Wajahat wrote:
>
> 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 ?

You can't get routing information loops. BGP route reflection has
mecanisms to avoid loops. You will not get into forwarding loops
unless your network design is such that clients are in the forwarding
path between RRs... which is a no-no anyway.

The thing that you have to pay attention to is that if you
configure nh-self for reflected routes you loose IGP metric info to
the originator of the route. if the same prefix can show up both from
within and outside a cluster/region, you will want to find a way to
make sure that the IGP metric of the RR loopbacks get penalyzed.

Pedro.

Pedro Roque Marques <roque@juniper.net> writes:

> You will not get into forwarding loops
> unless your network design is such that clients are in the forwarding
> path between RRs... which is a no-no anyway.

Why is the follow a no-no?

C1 ------- C2 --------- RR

Both C1 and C2 are route reflector clients of RR. C1 announces a
prefix to RR; C2 sees this prefix with a next-hop of RR (if
unconditional next-hop self is configured). And we have a forwarding
loop in what looks like a perfectly sane topology to me.

Robert

On Tue, Oct 21, 2003 at 09:12:27AM -0700, Joe Soricelli wrote:
> I believe that was 'from external' and not 'from route-type external'.

Yep. Back then I tried "from external" but it worked only for OSPF
(as [between the lines] documented).


Regards,
Daniel

On Tue, Oct 21, 2003 at 09:24:28AM -0700, Aviva Garrett wrote:
> 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.

OK, thanks. And it might be a good idea to add it to the release notes
as well. Rest assured that many people are waiting for this to appear.
:-)


Best regards,
Daniel

Hi Daniel,

I've passed along the request.

Thanks,
..Aviva

In message <20031021223417.B6244@homebase.cluenet.de>you write:
> On Tue, Oct 21, 2003 at 09:24:28AM -0700, Aviva Garrett wrote:
> > In message <425CE0ADBE82F946AFBAE21AA54D4A8801CC281C@quark.jnpr.net>you wr
> ite:
> > > 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.
>
> OK, thanks. And it might be a good idea to add it to the release notes
> as well. Rest assured that many people are waiting for this to appear.
> :-)
>
>
> Best regards,
> Daniel
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp

On Tuesday, October 21, 2003, at 01:15 AM, Daniel Roesen wrote:

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

o TE to a specific RR next hop
o RR client doesn't share IGP (or other) routes with RRs IBGP
peers, etc..
o I'm sure there are others.

I still think as a matter of default behavior Juniper shouldn't
rewrite the NEXT_HOP on reflected routes.

-danny

On Tue, Oct 21, 2003 at 09:33:54AM -0700, Pedro Roque Marques wrote:
> > > How changing the next hop attribute for an EBGP learnt route will lead
> > > to routing loops ?
>
> You can't get routing information loops. BGP route reflection has
> mecanisms to avoid loops.

Correct. Cluster list, specifically. But I wasn't talking about routing
information loops, but forwarding loops.

> You will not get into forwarding loops unless your network design is
> such that clients are in the forwarding path between RRs... which is
> a no-no anyway.

Why is that a no-no? Those setups are perfectly fine.


Best regards,
Daniel

On Tue, Oct 21, 2003 at 09:43:07AM +0200, Robert Kiessling wrote:
| "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;
| }


there is a fix to this problem from JUNOS 6.1 onwards:

the fix allows the policy processor to match against the
"internal" flag which is set for all iBGP learned routes;

from now on your next-hop self policy should look like:

juniper@route-relector> show configuration policy-options policy-statement nhs
term no-internal-rewrite {
from {
protocol bgp;
internal; <-------- new option
}
then {
next policy;
}
term final {
then {
next-hop self;
}
}

---


HTH,

/hannes

I question the utility in using next-hop-self on internal sessions, or
even eBGP import policy-statements. In my ASes, I keep the remote (/30)
next-hop and import the /30s into my IGP. This allows me to tweak the
metrics on those /30s as another means of controlling my egress paths.

When you rewrite learnt next-hops to the addresses of your own routers,
you lose the ability to influence the IGP-cost step in BGP best-path
selection based on the specific eBGP peer.

One thing I have always wished for is the ability to skip the external >
internal step in best-path selection, which comes before IGP cost. This
would have to be applied through the entire AS to avoid inconsistent
best-path decisions (routing loops), but I think it would be useful.

--
Jeff at Reflected Networks

you may also use something like :

policy-statement color-external-neighbor {
then {
color 666;
}
}
policy-statement next-hop-self {
from color 666;
then {
next-hop self;
}
}

and use color-external-neighbor as import policy in your core bgp mesh group

adel mezibra



-----Message d'origine-----
De : juniper-nsp-bounces@puck.nether.net
[mailto:juniper-nsp-bounces@puck.nether.net]De la part de Jeff Wheeler
Envoy? : lundi 15 d?cembre 2003 21:51
? : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] JUNOS Equivalent to CISCO IOS next-hop-self


I question the utility in using next-hop-self on internal sessions, or
even eBGP import policy-statements. In my ASes, I keep the remote (/30)
next-hop and import the /30s into my IGP. This allows me to tweak the
metrics on those /30s as another means of controlling my egress paths.

When you rewrite learnt next-hops to the addresses of your own routers,
you lose the ability to influence the IGP-cost step in BGP best-path
selection based on the specific eBGP peer.

One thing I have always wished for is the ability to skip the external >
internal step in best-path selection, which comes before IGP cost. This
would have to be applied through the entire AS to avoid inconsistent
best-path decisions (routing loops), but I think it would be useful.

--
Jeff at Reflected Networks

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

On 15.12.2003 15:51:14 +0000, Jeff Wheeler wrote:
> I question the utility in using next-hop-self on internal sessions, or
> even eBGP import policy-statements. In my ASes, I keep the remote (/30)
> next-hop and import the /30s into my IGP. This allows me to tweak the
> metrics on those /30s as another means of controlling my egress paths.

BGP MED or IGP metric to next-hop (router loopback). Only set
next-hop-self on the eBGP ingress router, not on iBGP sessions.

For eBGP peering session over a common IX LAN this practice is bad as
you would carry, say, 195.66.225.254/23 as BGP next-hop; what happens if
some one happens to inject 195.66.225.254/24 into your routing table?

> When you rewrite learnt next-hops to the addresses of your own routers,
> you lose the ability to influence the IGP-cost step in BGP best-path
> selection based on the specific eBGP peer.

You would still choose the shortest IGP path to the next-hop (loopback
address on egress router) if you overwrite next-hop on ingress.

/Michael

--
Michael Lyngb?l -- michael at lyngbol dot dk
Network Architect, AS3292 TDC, IP?backbone

sorry my previous mail miss some info :


you may also use something like :

policy-statement color-external-neighbor {
then {
color 666;
}
}
policy-statement next-hop-self {
from color 666;
then {
next-hop self;
}
}

and use color-external-neighbor as import policy in all your bgp session
and use next-hop-self policy as export policy in your core full mesh group.
This will show the real next hop (/30) on the local router and from any
other
router on the backbone you will have the router loopback as nexthop.

adel mezibra


-----Message d'origine-----
De : juniper-nsp-bounces@puck.nether.net
[mailto:juniper-nsp-bounces@puck.nether.net]De la part de Jeff Wheeler
Envoy? : lundi 15 d?cembre 2003 21:51
? : juniper-nsp@puck.nether.net
Objet : Re: [j-nsp] JUNOS Equivalent to CISCO IOS next-hop-self


I question the utility in using next-hop-self on internal sessions, or
even eBGP import policy-statements. In my ASes, I keep the remote (/30)
next-hop and import the /30s into my IGP. This allows me to tweak the
metrics on those /30s as another means of controlling my egress paths.

When you rewrite learnt next-hops to the addresses of your own routers,
you lose the ability to influence the IGP-cost step in BGP best-path
selection based on the specific eBGP peer.

One thing I have always wished for is the ability to skip the external >
internal step in best-path selection, which comes before IGP cost. This
would have to be applied through the entire AS to avoid inconsistent
best-path decisions (routing loops), but I think it would be useful.

--
Jeff at Reflected Networks

_______________________________________________
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, Dec 15, 2003 at 10:53:06PM +0100, adel mezibra wrote:
> you may also use something like :
>
> policy-statement color-external-neighbor {
> then {
> color 666;
> }
> }

Which is generally a bad idea because color influences the best path
decision process (if only as a very late criteria). Mark didn't think
of that when he did this band-aid for the lack of "from protocol ebgp"
(or equivalent), I've already talked to him about that a couple of
months ago. :-)

> and use color-external-neighbor as import policy in your core bgp
> mesh group

You mean in a customer import chain, not on IBGP sessions...


Regards,
Daniel

dr@cluenet.de (Daniel Roesen) writes:

> On Mon, Dec 15, 2003 at 10:53:06PM +0100, adel mezibra wrote:
> > you may also use something like :
> >
> > policy-statement color-external-neighbor {
> > then {
> > color 666;
> > }
> > }
>
> Which is generally a bad idea because color influences the best path
> decision process (if only as a very late criteria).

I don't believe that is correct.

In what do you base yourself ? i.e. is that written somewhere ?

Pedro.

On Mon, Dec 15, 2003 at 03:51:45PM -0800, Pedro Roque Marques wrote:
> > Which is generally a bad idea because color influences the best path
> > decision process (if only as a very late criteria).
>
> I don't believe that is correct.
>
> In what do you base yourself ? i.e. is that written somewhere ?

Yes:

http://www.juniper.net/techpubs/software/junos/junos61/swconfig61-routing/html/protocols-overview4.html#1014007

See paragraph below "Alternate and Tiebreaker Preferences".

It's a more detailed modifier to the route preference.

So, looking from the "How the Active Route Is Determined" it is
influencing even actually very early in the best path decision process.
:-)


Regards,
Daniel

I think this assumes that a color has been set with an incoming policy. As I
understand, color is purely a local function, and routes have none unless a
color is associated with import policy.

HTHs




> -----Original Message-----
> From: juniper-nsp-bounces@puck.nether.net
> [mailto:juniper-nsp-bounces@puck.nether.net] On Behalf Of
> Daniel Roesen
> Sent: Monday, December 15, 2003 4:57 PM
> To: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] JUNOS Equivalent to CISCO IOS next-hop-self
>
>
> On Mon, Dec 15, 2003 at 03:51:45PM -0800, Pedro Roque Marques wrote:
> > > Which is generally a bad idea because color influences
> the best path
> > > decision process (if only as a very late criteria).
> >
> > I don't believe that is correct.
> >
> > In what do you base yourself ? i.e. is that written somewhere ?
>
> Yes:
>
http://www.juniper.net/techpubs/software/junos/junos61/swconfig61-routing/ht
ml/protocols-overview4.html#1014007

See paragraph below "Alternate and Tiebreaker Preferences".

It's a more detailed modifier to the route preference.

So, looking from the "How the Active Route Is Determined" it is influencing
even actually very early in the best path decision process.
:-)


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

On Mon, Dec 15, 2003 at 05:17:02PM -0800, harry wrote:
> I think this assumes that a color has been set with an incoming
> policy.

Well, this is exactly what Adel was proposing... Setting color in
import chains of EBGP neighbors.

> As I understand, color is purely a local function, and routes have
> none unless a color is associated with import policy.

Correct.

BTW, JunOS "docs" seem to lack a description of how non-existant
color[2] compare to whatever existant color[2]. Same of all the
other alternatives/tie-breakers. It's the same basic question as
with MED.


Best regards,
Daniel

dr@cluenet.de (Daniel Roesen) writes:

> On Mon, Dec 15, 2003 at 03:51:45PM -0800, Pedro Roque Marques wrote:
> > > Which is generally a bad idea because color influences the best path
> > > decision process (if only as a very late criteria).
> >
> > I don't believe that is correct.
> >
> > In what do you base yourself ? i.e. is that written somewhere ?
>
> Yes:
>
> http://www.juniper.net/techpubs/software/junos/junos61/swconfig61-routing/html/protocols-overview4.html#1014007
>
> See paragraph below "Alternate and Tiebreaker Preferences".
>
> It's a more detailed modifier to the route preference.
>
> So, looking from the "How the Active Route Is Determined" it is
> influencing even actually very early in the best path decision process.
> :-)
>

Preference and preference2 (BGP localpref) are used as
tiebreakers. color and color2, although stored in the same data
structure internally, are not used as tiebreakers as far as i can
gather from the code or my understanding of what the design is.

mho is that documentation is a tad bit ambiguous.

Pedro.

On Mon, Dec 15, 2003 at 05:57:36PM -0800, Pedro Roque Marques wrote:
> > http://www.juniper.net/techpubs/software/junos/junos61/swconfig61-routing/html/protocols-overview4.html#1014007
> >
> > See paragraph below "Alternate and Tiebreaker Preferences".
> >
> > It's a more detailed modifier to the route preference.
>
> Preference and preference2 (BGP localpref) are used as
> tiebreakers. color and color2, although stored in the same data
> structure internally, are not used as tiebreakers as far as i can
> gather from the code or my understanding of what the design is.
>
> mho is that documentation is a tad bit ambiguous.

What is ambiguos about "You can also mark route preferences with
additional route tiebreaker information by specifying a color, color,
and a tiebreaker color, color2."?

It's explicitly, unambiguos saying that color/color2 are used as
tiebreakers. If this is not the factual case, then the documentation
is wrong.

The description of color/color2 in
http://www.juniper.net/techpubs/software/junos/junos61/swconfig61-policy/html/policy-framework-config8.html#1017021
is also very explicit and unambiguos.

If color/color2 wouldn't by some kind of actual metric, it wouldn't make
sense to allow adding/subtracting to/from the value.


Regards,
Daniel

Michael Lyngb?l (michael@lyngbol.dk) wrote:
> On 15.12.2003 15:51:14 +0000, Jeff Wheeler wrote:
> > I question the utility in using next-hop-self on internal sessions, or
> > even eBGP import policy-statements. In my ASes, I keep the remote (/30)
> > next-hop and import the /30s into my IGP. This allows me to tweak the
> > metrics on those /30s as another means of controlling my egress paths.
>
> BGP MED or IGP metric to next-hop (router loopback). Only set
> next-hop-self on the eBGP ingress router, not on iBGP sessions.

[x] not everybody is using BGP med in the correct way :-(

> For eBGP peering session over a common IX LAN this practice is bad as
> you would carry, say, 195.66.225.254/23 as BGP next-hop; what happens if
> some one happens to inject 195.66.225.254/24 into your routing table?

[x] protect your infrastucture - it's a GoodIdea(tm) to reject
195.66.22x/23 or longer in your routingtable. if most of us (a lot of
ISPs i know) use loopback redist'ed into IGP (usually IS-IS) and have
all their routes in bgp. if you next-hop the ibgp sessions, nothing
would happen if somebody injects this, so i second your opinion.
>
> > When you rewrite learnt next-hops to the addresses of your own routers,
> > you lose the ability to influence the IGP-cost step in BGP best-path
> > selection based on the specific eBGP peer.
>
> You would still choose the shortest IGP path to the next-hop (loopback
> address on egress router) if you overwrite next-hop on ingress.
>

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

Preference and preference2 are not BGP localpref. Those preferences are
similar to 'weight' in Cisco or a metric local to a route. The
preference and preference2 are not propagated to other routers in the
network.

-evt

-----Original Message-----
From: Pedro Roque Marques [mailto:roque@juniper.net]
Sent: Monday, December 15, 2003 8:58 PM
To: Daniel Roesen
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] JUNOS Equivalent to CISCO IOS next-hop-self


dr@cluenet.de (Daniel Roesen) writes:

> On Mon, Dec 15, 2003 at 03:51:45PM -0800, Pedro Roque Marques wrote:
> > > Which is generally a bad idea because color influences the best
path
> > > decision process (if only as a very late criteria).
> >
> > I don't believe that is correct.
> >
> > In what do you base yourself ? i.e. is that written somewhere ?
>
> Yes:
>
>
http://www.juniper.net/techpubs/software/junos/junos61/swconfig61-routin
g/html/protocols-overview4.html#1014007
>
> See paragraph below "Alternate and Tiebreaker Preferences".
>
> It's a more detailed modifier to the route preference.
>
> So, looking from the "How the Active Route Is Determined" it is
> influencing even actually very early in the best path decision
process.
> :-)
>

Preference and preference2 (BGP localpref) are used as
tiebreakers. color and color2, although stored in the same data
structure internally, are not used as tiebreakers as far as i can
gather from the code or my understanding of what the design is.

mho is that documentation is a tad bit ambiguous.

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

Not exactly like distance in Cisco ..

Rgds,


Eric Van Tol wrote:

> Preference and preference2 are not BGP localpref. Those preferences are
> similar to 'weight' in Cisco or a metric local to a route. The
> preference and preference2 are not propagated to other routers in the
> network.
>
> -evt
>
> -----Original Message-----
> From: Pedro Roque Marques [mailto:roque@juniper.net]
> Sent: Monday, December 15, 2003 8:58 PM
> To: Daniel Roesen
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] JUNOS Equivalent to CISCO IOS next-hop-self
>
>
> dr@cluenet.de (Daniel Roesen) writes:
>
>
>>On Mon, Dec 15, 2003 at 03:51:45PM -0800, Pedro Roque Marques wrote:
>>
>>>>Which is generally a bad idea because color influences the best
>
> path
>
>>>>decision process (if only as a very late criteria).
>>>
>>>I don't believe that is correct.
>>>
>>>In what do you base yourself ? i.e. is that written somewhere ?
>>
>>Yes:
>>
>>
>
> http://www.juniper.net/techpubs/software/junos/junos61/swconfig61-routin
> g/html/protocols-overview4.html#1014007
>
>>See paragraph below "Alternate and Tiebreaker Preferences".
>>
>>It's a more detailed modifier to the route preference.
>>
>>So, looking from the "How the Active Route Is Determined" it is
>>influencing even actually very early in the best path decision
>
> process.
>
>>:-)
>>
>
>
> Preference and preference2 (BGP localpref) are used as
> tiebreakers. color and color2, although stored in the same data
> structure internally, are not used as tiebreakers as far as i can
> gather from the code or my understanding of what the design is.
>
> mho is that documentation is a tad bit ambiguous.
>
> Pedro.
> _______________________________________________
> 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
>
>

Yes, that is why I said "similar" and not "exactly".

-eric

-----Original Message-----
From: Thanh Huong TRAN [mailto:tran@opentransit.net]
Sent: Tuesday, December 16, 2003 11:47 AM
To: Eric Van Tol
Cc: juniper-nsp@puck.nether.net
Subject: Re: [j-nsp] JUNOS Equivalent to CISCO IOS next-hop-self


Not exactly like distance in Cisco ..

Rgds,


Eric Van Tol wrote:

> Preference and preference2 are not BGP localpref. Those preferences
are
> similar to 'weight' in Cisco or a metric local to a route. The
> preference and preference2 are not propagated to other routers in the
> network.
>
> -evt
>
> -----Original Message-----
> From: Pedro Roque Marques [mailto:roque@juniper.net]
> Sent: Monday, December 15, 2003 8:58 PM
> To: Daniel Roesen
> Cc: juniper-nsp@puck.nether.net
> Subject: Re: [j-nsp] JUNOS Equivalent to CISCO IOS next-hop-self
>
>
> dr@cluenet.de (Daniel Roesen) writes:
>
>
>>On Mon, Dec 15, 2003 at 03:51:45PM -0800, Pedro Roque Marques wrote:
>>
>>>>Which is generally a bad idea because color influences the best
>
> path
>
>>>>decision process (if only as a very late criteria).
>>>
>>>I don't believe that is correct.
>>>
>>>In what do you base yourself ? i.e. is that written somewhere ?
>>
>>Yes:
>>
>>
>
>
http://www.juniper.net/techpubs/software/junos/junos61/swconfig61-routin
> g/html/protocols-overview4.html#1014007
>
>>See paragraph below "Alternate and Tiebreaker Preferences".
>>
>>It's a more detailed modifier to the route preference.
>>
>>So, looking from the "How the Active Route Is Determined" it is
>>influencing even actually very early in the best path decision
>
> process.
>
>>:-)
>>
>
>
> Preference and preference2 (BGP localpref) are used as
> tiebreakers. color and color2, although stored in the same data
> structure internally, are not used as tiebreakers as far as i can
> gather from the code or my understanding of what the design is.
>
> mho is that documentation is a tad bit ambiguous.
>
> Pedro.
> _______________________________________________
> 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
>
>