Re: BGP next-hop self benefits

[Baldur Norddahl]

Hi

For the MPLS L3VPN the answer is that the next hop attribute needs to be 
an address from the default VRF and if the peering is happening in a VRF 
context, there is no address from the default VRF you could use as next 
hop other than self.


This can be rather inconvenient as there are advantages to have the real 
next hop. For example fast rerouting works better when all defective 
routes can be removed in one go because the next hop was removed by the 
IGP instantly invalidating the affected routes.


Regards,

Baldur


Den 01/12/2017 kl. 16.06 skrev craig washington:

Hello everyone,


Question, what are the true benefits to using the next-hop self feature, 
doesn't matter what vendor.

Most information I see is just to make sure you have reach-ability for external 
routes via IBGP, but what if all your IBGP knows the eBGP links?

Is there a added benefit to using next hop self in this situation?


Any feedback is much appreciated, either for the question specifically or 
whatever else you got , L3VPN's or underlying technology that has to have that.


Thanks

Re: BGP next-hop self benefits

[Saku Ytti]

I'd like to add that one major advantage is limiting next-hops, thus
labels in your network. This is not just theoretical concern but there
are plenty of practical networks using practical hardware where you
simply cannot expose all next-hops to every node.



On 1 December 2017 at 17:30, Ken Chase  wrote:
> On an IX, without next-hop-self peer A leaking peer B's routes they receive to
> C will have C send direct to B on the IX (assuming flat layer 3 addressing,
> and not multiple little /30s or /96s everywhere or something - do any
> exchanges do that?)
>
> This may seem more efficient than sending C's traffic to A to get to B 
> (pumping up
> the IX's usage graphs) but B may not have peering agreements with C.
>
> Setting next-hop-self avoids this. An 'advantage' in some views. Not related 
> to
> n-h-s in an igp specifically, but an interesting (mis)use case.
>
> /kc
>
>
> On Fri, Dec 01, 2017 at 03:06:34PM +, craig washington said:
>   >Hello everyone,
>   >
>   >
>   >Question, what are the true benefits to using the next-hop self feature, 
> doesn't matter what vendor.
>   >
>   >Most information I see is just to make sure you have reach-ability for 
> external routes via IBGP, but what if all your IBGP knows the eBGP links?
>   >
>   >Is there a added benefit to using next hop self in this situation?
>   >
>   >
>   >Any feedback is much appreciated, either for the question specifically or 
> whatever else you got , L3VPN's or underlying technology that has to have 
> that.
>   >
>   >
>   >Thanks
>   >
>   >
>
> --
> Ken Chase - m...@sizone.org Guelph Canada



-- 
  ++ytti

Re: BGP next-hop self benefits

[Ken Chase]

On an IX, without next-hop-self peer A leaking peer B's routes they receive to
C will have C send direct to B on the IX (assuming flat layer 3 addressing,
and not multiple little /30s or /96s everywhere or something - do any
exchanges do that?)

This may seem more efficient than sending C's traffic to A to get to B (pumping 
up
the IX's usage graphs) but B may not have peering agreements with C.

Setting next-hop-self avoids this. An 'advantage' in some views. Not related to
n-h-s in an igp specifically, but an interesting (mis)use case.

/kc


On Fri, Dec 01, 2017 at 03:06:34PM +, craig washington said:
  >Hello everyone,
  >
  >
  >Question, what are the true benefits to using the next-hop self feature, 
doesn't matter what vendor.
  >
  >Most information I see is just to make sure you have reach-ability for 
external routes via IBGP, but what if all your IBGP knows the eBGP links?
  >
  >Is there a added benefit to using next hop self in this situation?
  >
  >
  >Any feedback is much appreciated, either for the question specifically or 
whatever else you got , L3VPN's or underlying technology that has to have 
that.
  >
  >
  >Thanks
  >
  >

-- 
Ken Chase - m...@sizone.org Guelph Canada

BGP next-hop self benefits

[craig washington]

Hello everyone,


Question, what are the true benefits to using the next-hop self feature, 
doesn't matter what vendor.

Most information I see is just to make sure you have reach-ability for external 
routes via IBGP, but what if all your IBGP knows the eBGP links?

Is there a added benefit to using next hop self in this situation?


Any feedback is much appreciated, either for the question specifically or 
whatever else you got , L3VPN's or underlying technology that has to have that.


Thanks

Re: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]

[Rajiv Asati (rajiva)]

 inside a VRF, but the MPLS standards wg seems content with status quo.


http://tools.ietf.org/html/draft-ietf-mpls-ldp-ipv6

The WG is pretty close to wrap this up (back to the 3rd WGLC very soon). 

But frankly admitting, dual-stacking facilitated more issues than I expected 
early on. 

Cheers,
Rajiv

 On May 3, 2014, at 5:29 AM, Måns Nilsson mansa...@besserwisser.org wrote:
 
 Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices 
 IPv4/IPv6 BGP (dual stack)] Date: Fri, May 02, 2014 at 03:58:42PM -0600 
 Quoting Chris Grundemann (cgrundem...@gmail.com):
 
 Would you expound a bit on what you mean here? I don't quite follow but I
 am very interested to understand the issue.
 
 The fact that you need v4 space to build a MPLS backbone is a very good
 reason to not waste a /10 on CGN crap. 
 
 Ideally, we would have a solution where an entire MPLS infrastructure
 could be built without v4 space, demoting v4 to a legacy application
 inside a VRF, but the MPLS standards wg seems content with status quo.
 
 -- 
 Måns Nilsson primary/secondary/besserwisser/machina
 MN-1334-RIPE +46 705 989668
 I wish I was a sex-starved manicurist found dead in the Bronx!!

Re: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]

[Rajiv Asati (rajiva)]

Mark,

 about leveraging SR to push native IPv6 support into MPLS, 

Segment routing (SR) could/would certainly work with single-stack v6 and enable 
MPLS forwarding. 

Cheers,
Rajiv

 On May 5, 2014, at 3:36 AM, Mark Tinka mark.ti...@seacom.mu wrote:
 
 On Monday, May 05, 2014 09:27:37 AM Vitkovský Adam wrote:
 
 You mean the SR right?
 
 No, I mean:
 
draft-george-mpls-ipv6-only-gap-05
 
 The draft looks at issues that need to be fixed for MPLS to 
 run in a single-stack IPv6 network.
 
 Of course, there is other work that is looking at fixing 
 LDPv6 as well, as you know.
 
 At the recent MPLS SDN Congress in Paris, I asked some folk 
 about leveraging SR to push native IPv6 support into MPLS, 
 but they didn't seem like that was a key application yet. So 
 while SR is promising, I think it's not a solution for this 
 particular use-case yet.
 
 Mark.

Re: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]

[Mark Tinka]

On Tuesday, May 06, 2014 11:27:09 AM Rajiv Asati (rajiva) 
wrote:

 Segment routing (SR) could/would certainly work with
 single-stack v6 and enable MPLS forwarding.

Certainly, but based on the Paris meeting, it was not high 
up on the agenda.

So we will, likely, have to rely on other solutions and wait 
for SR to catch up later.

At the moment, it seems SR is being pushed hard for PCEP as 
well as SDN.

Mark.


signature.asc
Description: This is a digitally signed message part.

RE: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]

[Vitkovský Adam]

 From: Mark Tinka [mailto:mark.ti...@seacom.mu]
 
 On Tuesday, May 06, 2014 11:27:09 AM Rajiv Asati (rajiva)
 wrote:
 
  Segment routing (SR) could/would certainly work with single-stack v6
  and enable MPLS forwarding.
 
 Certainly, but based on the Paris meeting, it was not high up on the agenda.
 
 So we will, likely, have to rely on other solutions and wait for SR to catch 
 up
 later.
 
 At the moment, it seems SR is being pushed hard for PCEP as well as SDN.
 
 Mark. 


I think the most revolutionary SR use case is the: 
3.2.  Protecting a node segment upon the failure of its advertising node. 
Of the now expired: draft-filsfils-rtgwg-segment-routing-use-cases-02. 

It's the first, complete and elegant FRR solution for the hierarchical MPLS 
implementations. 

adam

RE: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]

[Vitkovský Adam]

  Ideally, we would have a solution where an entire MPLS infrastructure
  could be built without v4 space, demoting
  v4 to a legacy application inside a VRF, but the MPLS standards wg
  seems content with status quo.
 
 There is work ongoing in the MPLS IETF WG on identifying the gaps that
 various MPLS applications have so they can be prepared for IPv6 MPLS
 control and data planes.
 
 Long overdue, if you ask me, but at least it's starting to get some attention.
 
 Mark. 

You mean the SR right? 

adam

Re: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]

[Mark Tinka]

On Monday, May 05, 2014 09:27:37 AM Vitkovský Adam wrote:

 You mean the SR right?

No, I mean:

draft-george-mpls-ipv6-only-gap-05

The draft looks at issues that need to be fixed for MPLS to 
run in a single-stack IPv6 network.

Of course, there is other work that is looking at fixing 
LDPv6 as well, as you know.

At the recent MPLS SDN Congress in Paris, I asked some folk 
about leveraging SR to push native IPv6 support into MPLS, 
but they didn't seem like that was a key application yet. So 
while SR is promising, I think it's not a solution for this 
particular use-case yet.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]

[Rob Seastrom]

Randy Bush ra...@psg.com writes:

 Ah, so you're in the camp that a /10 given to one organization for
 their private use would have been better than reserving that /10 for
 _everyone_ to use. We'll have to agree to disagree there.

 you forced an rfc allocation.  that makes public space, and is and will
 be used as such.  you wanted an 'owned' allocation that you and your
 friends control, you shoulda gone to the rirs.

Usually I manage to keep the Strangelove hand in check and not feed
the troll, but the matter was raised (at least in the ARIN region).

https://www.arin.net/policy/proposals/2011_5.html

I believe that the arguments that shared transition space were IETF's
purview were compelling.  I'm no fan of non-globally-unique space in
general, but forcing the RFC route was the least-worst route for
things to move forward.

Randy, I trust that you're also vigorously advocating people's use of
UK-MOD-19850128 (aka net 25) as just more 1918 space inside their
organizations too?  After all, it's what I encourage *my* competitors to do.

-r

Re: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]

[Mark Tinka]

On Saturday, May 03, 2014 11:26:27 AM Måns Nilsson wrote:

 Ideally, we would have a solution where an entire MPLS
 infrastructure could be built without v4 space, demoting
 v4 to a legacy application inside a VRF, but the MPLS
 standards wg seems content with status quo.

There is work ongoing in the MPLS IETF WG on identifying the 
gaps that various MPLS applications have so they can be 
prepared for IPv6 MPLS control and data planes.

Long overdue, if you ask me, but at least it's starting to 
get some attention.

Mark.


signature.asc
Description: This is a digitally signed message part.

Re: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]

[Måns Nilsson]

Subject: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices 
IPv4/IPv6 BGP (dual stack)] Date: Fri, May 02, 2014 at 03:58:42PM -0600 Quoting 
Chris Grundemann (cgrundem...@gmail.com):

 Would you expound a bit on what you mean here? I don't quite follow but I
 am very interested to understand the issue.

The fact that you need v4 space to build a MPLS backbone is a very good
reason to not waste a /10 on CGN crap. 

Ideally, we would have a solution where an entire MPLS infrastructure
could be built without v4 space, demoting v4 to a legacy application
inside a VRF, but the MPLS standards wg seems content with status quo.

-- 
Måns Nilsson primary/secondary/besserwisser/machina
MN-1334-RIPE +46 705 989668
I wish I was a sex-starved manicurist found dead in the Bronx!!


signature.asc
Description: Digital signature

Re: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]

[Randy Bush]

a good number of us use that kinky /10 behind home nats and encourage
everyone to do so.  it was a sick deal and should be treated as such,
just more 1918.

randy

Re: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]

[Chris Grundemann]

On Sat, May 3, 2014 at 3:26 AM, Måns Nilsson mansa...@besserwisser.org wrote:
 The fact that you need v4 space to build a MPLS backbone is a very good
 reason to not waste a /10 on CGN crap.

Ah, so you're in the camp that a /10 given to one organization for
their private use would have been better than reserving that /10 for
_everyone_ to use. We'll have to agree to disagree there.

 Ideally, we would have a solution where an entire MPLS infrastructure
 could be built without v4 space, demoting v4 to a legacy application
 inside a VRF, but the MPLS standards wg seems content with status quo.

We can agree on that.

Thanks,
~Chris


 --
 Måns Nilsson primary/secondary/besserwisser/machina
 MN-1334-RIPE +46 705 989668
 I wish I was a sex-starved manicurist found dead in the Bronx!!

-- 
@ChrisGrundemann
http://chrisgrundemann.com

Re: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]

[Chris Grundemann]

On Sat, May 3, 2014 at 3:58 AM, Randy Bush ra...@psg.com wrote:
 a good number of us use that kinky /10 behind home nats and encourage
 everyone to do so.  it was a sick deal and should be treated as such,
 just more 1918.

A good number of folks use other folks IP space in all kinds of
strange and kinky ways too - it's ALL just more 1918, right??? Or
maybe standards exist for a reason. Perhaps enhancing coordination,
cooperation, and *interoperability* are good things... I'll let you
decide, Randy; is it sick to solve problems through community
consensus and standardization, or is it sick to be the one
intentionally getting in the way of those real world solutions?

Cheers,
~Chris


 randy

-- 
@ChrisGrundemann
http://chrisgrundemann.com

Re: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]

[joel jaeggli]

On 5/3/14, 10:36 AM, Chris Grundemann wrote:
 On Sat, May 3, 2014 at 3:58 AM, Randy Bush ra...@psg.com wrote:
 a good number of us use that kinky /10 behind home nats and encourage
 everyone to do so.  it was a sick deal and should be treated as such,
 just more 1918.
 
 A good number of folks use other folks IP space in all kinds of
 strange and kinky ways too - it's ALL just more 1918, right??? Or
 maybe standards exist for a reason. Perhaps enhancing coordination,
 cooperation, and *interoperability* are good things... I'll let you
 decide, Randy; is it sick to solve problems through community
 consensus and standardization, or is it sick to be the one
 intentionally getting in the way of those real world solutions?

Any time you have two parties that have to interconnect who have
overlapping usage of the same space you're going to have issues.

The authors the 6598 were concerned about intersection with legacy CPE.
100.64.0.0/10 does not  yet have that issue.  The use cases being
described here (randy causing pollution,  numbering internal network
resources (the intended purpose after all)) have no relationship to
legacy CPE.

characterizing it as shared was always a misnomer since by their nature
collisions are not sharing.

in a somewhat unrelated note this prefix is still leaking in some
globally visible ways in some places.

e.g. if you're as3303 you probably shouldn't be importing these prefixes
from customers or exporting  as part of your full table given that you
also accept them from subsidiaries. that's likely to end in tears.

 Cheers,
 ~Chris
 

 randy
 




signature.asc
Description: OpenPGP digital signature

Re: Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]

[Randy Bush]

 Ah, so you're in the camp that a /10 given to one organization for
 their private use would have been better than reserving that /10 for
 _everyone_ to use. We'll have to agree to disagree there.

you forced an rfc allocation.  that makes public space, and is and will
be used as such.  you wanted an 'owned' allocation that you and your
friends control, you shoulda gone to the rirs.

randy

Shared Transition Space VS. BGP Next Hop [was: Re: Best practices IPv4/IPv6 BGP (dual stack)]

[Chris Grundemann]

Hi Mans,

On Fri, May 2, 2014 at 2:35 PM, Måns Nilsson mansa...@besserwisser.orgwrote:

 This is a field where v4 next-hops are essential to make things
 work. rantIn that context, allocating 100.64.0.0/10 to CGN was
 especially un-clever... /rant


Would you expound a bit on what you mean here? I don't quite follow but I
am very interested to understand the issue.

Thanks!
~Chris

-- 
@ChrisGrundemann
http://chrisgrundemann.com

MP-BGP next hop tracking delay 0

[Adam Vitkovsky]

I was wondering whether you have some experience with setting of the next
hop tracking delay value for BGP to 0 for critical changes please
There's gonna be only a few prefixes registered with BGP so far, around 150+

adam

RE: MP-BGP next hop tracking delay 0

[Jeff Tantsura]

Hi Adam,

Works just fine on any relatively modern router.

Cheers,
Jeff

-Original Message-
From: Adam Vitkovsky [mailto:adam.vitkov...@swan.sk] 
Sent: Tuesday, October 23, 2012 12:31 AM
To: nanog@nanog.org
Subject: MP-BGP next hop tracking delay 0

I was wondering whether you have some experience with setting of the next hop 
tracking delay value for BGP to 0 for critical changes please There's gonna be 
only a few prefixes registered with BGP so far, around 150+

adam

Re: BGP next-hop

[Heath Jones]

 Section 9.1.2.1 of RFC 4271 seems to address this.
 A few points from that section:
  - The BGP NEXT_HOP can not recursively resolve (directly or indirectly) 
 through the BGP route.
  - Only the longest matching route should be considered when resolving the 
 BGP NEXT_HOP.
  - Do not consider feasible routes that would become unresolvable if they 
 were installed.

There are 2 ways of reading that.. Perhaps i'll go and look at the it
in more details.
I'm trying to think of a scenario where following this or something
similar would break it:
- Don't use BGP prefixes to resolve next-hop.
- You can use 0/0 or any route with a lower administrative distance to
resolve the next-top.

With that in mind, I wonder if it works with Juniper (ad = 170 vs 20
from memory)..

BGP next-hop

[Heath Jones]

Hi all,

Is there an easy way to see which iBGP routes are not being selected
due to next-hop not being in IGP?

Before and after IGP route added shown below, note both are marked as valid..

-- BEFORE IGP--
AS5000_LA#show ip bgp
BGP table version is 5, local router ID is 10.0.0.5
Status codes: s suppressed, d damped, h history, * valid,  best, i - internal,
 r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

  Network  Next HopMetric LocPrf Weight Path
* i100.10.0.0/1610.0.0.100100  0 2000 3000 ?
*  10.0.0.6   0 1000 3000 3000 ?

-- AFTER IGP--
AS5000_LA#show ip bgp
BGP table version is 6, local router ID is 10.0.0.5
Status codes: s suppressed, d damped, h history, * valid,  best, i - internal,
 r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

  Network  Next HopMetric LocPrf Weight Path
*i100.10.0.0/1610.0.0.100100  0 2000 3000 ?
*   10.0.0.6   0 1000 3000 3000 ?


Cheers
Heath

ps. I've posted this to cisco-nsp also (a day ago) - so apologies in
advance if you are on both and seeing it twice.

Re: BGP next-hop

[Heath Jones]

Cheers Jeff.

I thought i'd give that a go, but it doesnt seem to be working for some reason!

(This is without next-hop in IGP)

AS5000_LA#show ip bgp
BGP table version is 3, local router ID is 10.0.0.5
Status codes: s suppressed, d damped, h history, * valid,  best, i - internal,
  r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network  Next HopMetric LocPrf Weight Path
* 100.10.0.0/1610.0.0.6   0 1000 3000 3000 ?
* i 10.0.0.100100  0 2000 3000 ?

AS5000_LA#show ip bgp rib-failure
NetworkNext Hop  RIB-failure   RIB-NH Matches
AS5000_LA#

AS5000_LA#show ip bgp 100.10.0.0
BGP routing table entry for 100.10.0.0/16, version 3
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Flag: 0x820
  Advertised to update-groups:
 2
  1000 3000 3000
10.0.0.6 from 10.0.0.6 (10.0.0.13)
  Origin incomplete, localpref 100, valid, external, best
  2000 3000
10.0.0.10 (inaccessible) from 10.0.0.2 (10.0.0.9)
  Origin incomplete, metric 0, localpref 100, valid, internal


From the detail view, the route is marked as inaccessible. Perhaps
this is the only way to get to it..


Heath

Re: BGP next-hop

[Leo Bicknell]

In a message written on Thu, Sep 30, 2010 at 10:49:17AM +0100, Heath Jones 
wrote:
 Is there an easy way to see which iBGP routes are not being selected
 due to next-hop not being in IGP?

I have suggested more than a few times to vendors that the command:

show bgp ipv4 unicast 100.10.0.0/16 why-chosen

Would be insanely useful.  Yes, you can recreate the 7+ BGP decision
steps in your mind by running a pile of show commands, but when
you're trying to figure out several odd routes at the same time
this is very hard to keep in your head and very labor intensive.
The box knows why it chose the route, and should be able to show
that to you.

Of course most boxes can't show you outgoing BGP communities either.
*sigh*  Is it really too hard to ask to get a show bgp neighbor ...
advertised that shows ALL of the attributes?

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/


pgpN5zeQJ0dwC.pgp
Description: PGP signature

Re: BGP next-hop

[Peter Hicks]

On Thu, 2010-09-30 at 07:01 -0700, Leo Bicknell wrote:

 I have suggested more than a few times to vendors that the command:
 
 show bgp ipv4 unicast 100.10.0.0/16 why-chosen
 
 Would be insanely useful.

+1 for that, in a similar manner to packet-tracer on ASAs.


Peter

Re: BGP next-hop

[Randy Bush]

i was recently bitten by a cousin of this

research router getting an ebgp multi-hop full feed from 147.28.0.1
(address is relevant)

it is on a lan with a default gateway 42.666.77.11 (address not
relevant), so it has

ip route 0.0.0.0  0.0.0.0  42.666.77.11

massive flapping results.  

it seems it gets the bgp route for 147.28.0.0/16 and then can not
resolve the next hop.  it would not recurse to the default exit.

of course it was solved by

ip route 147.28.0.0  255.255.0.0  42.666.77.11

but i do not really understand in my heart why i needed to do this.

randy

Re: BGP next-hop

[Franck Martin]

Because the path was broken everytime the bgp session was established and 
rewriting the routing table with more specific routes?

- Original Message -
From: Randy Bush ra...@psg.com
To: North American Network Operators Group nanog@nanog.org
Sent: Thursday, 30 September, 2010 2:37:43 PM
Subject: Re: BGP next-hop

i was recently bitten by a cousin of this

research router getting an ebgp multi-hop full feed from 147.28.0.1
(address is relevant)

it is on a lan with a default gateway 42.666.77.11 (address not
relevant), so it has

ip route 0.0.0.0  0.0.0.0  42.666.77.11

massive flapping results.  

it seems it gets the bgp route for 147.28.0.0/16 and then can not
resolve the next hop.  it would not recurse to the default exit.

of course it was solved by

ip route 147.28.0.0  255.255.0.0  42.666.77.11

but i do not really understand in my heart why i needed to do this.

randy

Re: BGP next-hop

[Ingo Flaschberger]

i was recently bitten by a cousin of this

research router getting an ebgp multi-hop full feed from 147.28.0.1
(address is relevant)

it is on a lan with a default gateway 42.666.77.11 (address not
relevant), so it has

   ip route 0.0.0.0  0.0.0.0  42.666.77.11

massive flapping results.

it seems it gets the bgp route for 147.28.0.0/16 and then can not
resolve the next hop.  it would not recurse to the default exit.

of course it was solved by

   ip route 147.28.0.0  255.255.0.0  42.666.77.11

but i do not really understand in my heart why i needed to do this.


last time severall years ago on cisco I used a route-map to rewrite the 
next-hop.

route-map xx-in permit 10
 set ip next-hop 42.666.77.11
route-map xx-out permit 10
 set ip next-hop x.x.x.x

 neighbor 147.28.0.1 remote-as yyy
 neighbor 147.28.0.1 ebgp-multihop 8
 neighbor 147.28.0.1 route-map xx-in in
 neighbor 147.28.0.1 route-map xx-out out

something like this.

Re: BGP next-hop

[Randy Bush]

 last time severall years ago on cisco I used a route-map to rewrite the 
 next-hop.
 route-map xx-in permit 10
   set ip next-hop 42.666.77.11
 route-map xx-out permit 10
   set ip next-hop x.x.x.x
 
   neighbor 147.28.0.1 remote-as yyy
   neighbor 147.28.0.1 ebgp-multihop 8
   neighbor 147.28.0.1 route-map xx-in in
   neighbor 147.28.0.1 route-map xx-out out
 
 something like this.

as i showed, i knew how to hack out of the problem.  and yes, there are
many ways.

the question is why i am in the corner in the first place.

randy

Re: BGP next-hop

[Richard A Steenbergen]

On Thu, Sep 30, 2010 at 07:01:19AM -0700, Leo Bicknell wrote:
 I have suggested more than a few times to vendors that the command:
 
 show bgp ipv4 unicast 100.10.0.0/16 why-chosen
 
 Would be insanely useful.

Been in JUNOS show route since day one, and IMHO is easily in the top 
10 list of why I still buy Juniper instead of Cisco despite all the 
$%^*ing bugs these days.

-- 
Richard A Steenbergen r...@e-gerbil.net   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Re: BGP next-hop

[Heath Jones]

 show bgp ipv4 unicast 100.10.0.0/16 why-chosen
 Would be insanely useful.

 Been in JUNOS show route since day one, and IMHO is easily in the top
 10 list of why I still buy Juniper instead of Cisco despite all the
 $%^*ing bugs these days.

Its interesting, I was heavy into cisco years back and then juniper
for a while. Going back to cisco now is great (always good for me to
keep my exposure up), but there is just so much unclear in it's CLI.
It wasn't until going back that I realised.

I guess they would have to balance keeping the old timers  scripts
etc happy VS bringing in new features that make the output look
different.. Do you keep something that isn't perfect but people know
how to use, or change it and cause more issues than good?

ps. Juniper has really gone to $h!t lately. There's a website called
glassdoor.com that I found - go look up what employees have to say
about it.. reflects exactly the support we were getting, even as as an
'elite' partner..

Re: BGP next-hop

[Richard A Steenbergen]

On Thu, Sep 30, 2010 at 11:56:06PM +0100, Heath Jones wrote:
 
 Its interesting, I was heavy into cisco years back and then juniper 
 for a while. Going back to cisco now is great (always good for me to 
 keep my exposure up), but there is just so much unclear in it's CLI. 
 It wasn't until going back that I realised.
 
 I guess they would have to balance keeping the old timers  scripts 
 etc happy VS bringing in new features that make the output look 
 different.. Do you keep something that isn't perfect but people know 
 how to use, or change it and cause more issues than good?

Personally I still can't believe that it's the year 2010, and IOS still 
shows routes in classful notation (i.e. if it's in 192.0.0.0/3 and is a 
/24, the /24 part isn't displayed because it's assumed to be Class C). 
Of course I say that every year, and so far the only thing that has 
changed is the year I say it about.

 ps. Juniper has really gone to $h!t lately. There's a website called 
 glassdoor.com that I found - go look up what employees have to say 
 about it.. reflects exactly the support we were getting, even as as an 
 'elite' partner..

Don't get me started, I could complain for days and still not run out of 
material, but alas it doesn't accomplish anything. Sadly, many of the 
best Juniper people I know are incredibly disaffected, and are leaving 
(or have already left) in droves. I think the way I heard it put best 
was, I'm convinced that $somenewexecfromcisco is actually on a secret 5 
year mission to come over to Juniper, completely $%^* the company, and 
then go back to Cisco and get a big bonus for it. :)

-- 
Richard A Steenbergen r...@e-gerbil.net   http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

Re: BGP next-hop

[Heath Jones]

 it seems it gets the bgp route for 147.28.0.0/16 and then can not
 resolve the next hop.  it would not recurse to the default exit.

 of course it was solved by
    ip route 147.28.0.0  255.255.0.0  42.666.77.11
 but i do not really understand in my heart why i needed to do this.

Neither do I, Randy.
I have seen recursive routing done - perhaps on a juniper - i really
cannot remember.
Given that the packet would be originating from the device itself (not
hardware forwarded), it would make sense that it should be able to
perform a recursive lookup. I'd put it down to an implementation
thing..

Unrelated, I was doing some thinking about a multihomed site and using
BGP advertisments sent out one link (provider 1) to influence the
sending of the advertisments out of the other link (provider 2). Long
story short I needed to know how long bgp nlri's take to traverse the
net, and subsequently have a paper that you co-authored open in
another tab - well done! :)

Re: BGP next-hop

[Randy Bush]

 it seems it gets the bgp route for 147.28.0.0/16 and then can not
 resolve the next hop.  it would not recurse to the default exit.

 of course it was solved by
    ip route 147.28.0.0  255.255.0.0  42.666.77.11
 but i do not really understand in my heart why i needed to do this.
 
 Neither do I, Randy.

a good friend at cisco says he will take the time to write up why in the
next day or two.

 I needed to know how long bgp nlri's take to traverse the net

high variance

randy

Re: BGP next-hop

[Brett Watson]

On Sep 30, 2010, at 4:57 PM, Randy Bush wrote:

 it seems it gets the bgp route for 147.28.0.0/16 and then can not
 resolve the next hop.  it would not recurse to the default exit.
 
 of course it was solved by
ip route 147.28.0.0  255.255.0.0  42.666.77.11
 but i do not really understand in my heart why i needed to do this.
 
 Neither do I, Randy.
 
 a good friend at cisco says he will take the time to write up why in the
 next day or two.

Only thing I can guess from the Cisco doc that says:

To prevent the creation of loops through oscillating routes, the multihop will 
not be established if the only route to the multihop peer is the default route 
(0.0.0.0).

Is that they think they're saving you from shooting yourself in the foot, if 
you learn the route to 147.28.0.0/16 via BGP (which your multihop peer address 
falls in), yet you have a default route of 0.0.0.0? But then you'd simply 
recursively look up the FIB route to the next hop in BGP... so I still don't 
get it.

-b

Re: BGP next-hop

[Christian Martin]

On Sep 30, 2010, at 5:37 PM, Randy Bush ra...@psg.com wrote:

 i was recently bitten by a cousin of this
 
 research router getting an ebgp multi-hop full feed from 147.28.0.1
 (address is relevant)
 
 it is on a lan with a default gateway 42.666.77.11 (address not
 relevant), so it has
 
ip route 0.0.0.0  0.0.0.0  42.666.77.11
 
 massive flapping results.  
 
 it seems it gets the bgp route for 147.28.0.0/16 and then can not
 resolve the next hop.  it would not recurse to the default exit.
 
 of course it was solved by
 
ip route 147.28.0.0  255.255.0.0  42.666.77.11
 
 but i do not really understand in my heart why i needed to do this.
 

Looks like a classic race condition, in that 147.28/16, upon arrival, becomes a 
better route for the recursed next-hop (which really is a recursed lookup on 
your default)  So you get

147.28/16 - 147.28.0.1, and then 147.28.0.1 looks best through the learned 
route.

Of course, this would appear to be a matter of how it is implemented.  Because 
in fact, the 147 route isn't yet in the routing table, so your default should 
apply.  The static seems to force a recursion to the 666 nh.  

I'll wait for your friend to send the implementation details, but from a 
glance, it looks like a defensive (lazy?) attempt to avoid a recursion loop 
during the update receive process.

Btw, this will happen on a Juniper (or at least it used to).  I'll have to 
check to confirm.

Chris

 randy
 

Re: BGP next-hop

[Smith W. Stacy]

On Sep 30, 2010, at 3:37 PM, Randy Bush wrote:
 it seems it gets the bgp route for 147.28.0.0/16 and then can not
 resolve the next hop.  it would not recurse to the default exit.
 
 of course it was solved by
 
ip route 147.28.0.0  255.255.0.0  42.666.77.11
 
 but i do not really understand in my heart why i needed to do this.

Section 9.1.2.1 of RFC 4271 seems to address this. 

A few points from that section:
 - The BGP NEXT_HOP can not recursively resolve (directly or indirectly) 
through the BGP route.
 - Only the longest matching route should be considered when resolving the BGP 
NEXT_HOP.
 - Do not consider feasible routes that would become unresolvable if they were 
installed.

--Stacy