Re: BGP Path Selection weirdness regarding next hops

Mohammad,

Please refer to the link below: as we have covered this in great detail a
few months back. If you do not find what you are looking for in the
archives, then please restart this email string.

http://www.groupstudy.com/archives/ccielab/201207/msg00415.html

HTH,
Joe Sanchez

On Tue, Dec 4, 2012 at 5:24 PM, Mohammad Mousa <mohd-mousa_at_hotmail.com>wrote:

> Would you please clarify more on this? I need reason why the peering isn't
> come up even if you have underlying connectivity to other loopback? "NO
> ROUTE TO PEER"
> I might misunderstand you, can please tell me what you mean by this :
>
> Try making two routes on one side, one for 0.0.0.0/1 and the other for
> 128.0.0.0/1 and see how that goes.
>
> Thanks!
>
>
>
>
>
>
>
> > CC: bmcgahan_at_ine.com; markom_at_ipexpert.com; routingfreak_at_gmail.com;
> bdennis_at_ine.com; narbikk_at_gmail.com; jneiberger_at_gmail.com;
> ccielab_at_groupstudy.com
> > From: david.rothera_at_gmail.com
> > Subject: Re: BGP Path Selection weirdness regarding next hops
> > Date: Tue, 4 Dec 2012 22:56:34 +0000
> > To: mohd-mousa_at_hotmail.com
> >
> > As Brian already said, BGP won't follow a default route to bring a
> neighbour up. You need at least a /1 or anything more specific on one side.
> >
> > Try making two routes on one side, one for 0.0.0.0/1 and the other for
> 128.0.0.0/1 and see how that goes.
> >
> > Sent from my iPhone
> > Please excuse any mistakes and brevity.
> >
> > On 4 Dec 2012, at 22:28, Mohammad Mousa <mohd-mousa_at_hotmail.com> wrote:
> >
> > > Hello Brian,
> > >
> > > Would you please explain me what's the reason behind the bgp peering
> establishment not happen if they both have default route to each other.I
> did lab it and got this message.
> > >
> > > "BGP: 2.2.2.2 active open failed - no route to peer, open active
> delayed 29135ms (35000ms max, 28% jitter) "
> > >
> > > no route to peer!!!!! If you try to ping 2.2.2.2 sourced from lo0 of
> R1 and vice versa, it pinged fine. How come no route to peer??
> > >
> > > R1
> > > ---
> > > router bgp 1
> > > no synchronization
> > > bgp log-neighbor-changes
> > > neighbor 2.2.2.2 remote-as 2
> > > neighbor 2.2.2.2 ebgp-multihop 255
> > > neighbor 2.2.2.2 update-source Loopback0
> > > no auto-summary
> > >
> > > R2
> > > ---
> > > router bgp 2
> > > no synchronization
> > > bgp log-neighbor-changes
> > > neighbor 1.1.1.1 remote-as 1
> > > neighbor 1.1.1.1 ebgp-multihop 255
> > > neighbor 1.1.1.1 update-source Loopback0
> > > no auto-summary
> > >
> > > Thanks in advance!
> > >
> > >> From: bmcgahan_at_ine.com
> > >> To: markom_at_ipexpert.com; routingfreak_at_gmail.com
> > >> CC: bdennis_at_ine.com; narbikk_at_gmail.com; jneiberger_at_gmail.com;
> ccielab_at_groupstudy.com
> > >> Date: Tue, 4 Dec 2012 12:28:37 -0600
> > >> Subject: RE: BGP Path Selection weirdness regarding next hops
> > >>
> > >> Routing Freak,
> > >>
> > >> The issue isn't the peering establishment in this discussion though.
> You're right that if two peers only have default routes to each other they
> will not be able to establish a peering. At least one side must have a /1
> or greater in order to send the initial TCP SYN to start the handshake.
> > >>
> > >> The problem in this case is that the router John was peering with
> physically went down, and so the route to the peer changed from the
> specific prefix to the default route. This still satisfies the BGP Next
> Hop Tracking (NHT) process, so convergence was in the order of minutes
> relying on BGP keepalives instead of on the order of seconds for IGP
> convergence.
> > >>
> > >> This problem is what conditional BGP NHT is used to solve, as Brian
> Dennis posted the IOS config and I posted the IOS XR config.
> > >>
> > >>
> > >> HTH,
> > >>
> > >> Brian McGahan, CCIE #8593 (R&S/SP/Security)
> > >> bmcgahan_at_INE.com
> > >>
> > >> Internetwork Expert, Inc.
> > >> http://www.INE.com <http://www.ine.com/>
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Marko Milivojevic [mailto:markom_at_ipexpert.com]
> > >> Sent: Tuesday, December 04, 2012 10:01 AM
> > >> To: Routing Freak
> > >> Cc: Brian McGahan; Brian Dennis; Narbik Kocharians; John Neiberger;
> ccielab_at_groupstudy.com
> > >> Subject: Re: BGP Path Selection weirdness regarding next hops
> > >>
> > >> I'm really sorry, but I have no idea what you are inquiring about...
> > >>
> > >> --
> > >> Marko Milivojevic - CCIE #18427 (SP R&S) Senior CCIE Instructor -
> IPexpert
> > >>
> > >> On Tue, Dec 4, 2012 at 7:58 AM, Routing Freak <routingfreak_at_gmail.com>
> wrote:
> > >>> i see tat. Is tat a fair point wat i have raised ?
> > >>> wat are ur thoughts on this
> > >>>
> > >>>
> > >>> On Tue, Dec 4, 2012 at 9:24 PM, Marko Milivojevic
> > >>> <markom_at_ipexpert.com>
> > >>> wrote:
> > >>>>
> > >>>> As I said - only that.
> > >>>>
> > >>>> --
> > >>>> Marko Milivojevic - CCIE #18427 (SP R&S) Senior CCIE Instructor -
> > >>>> IPexpert
> > >>>>
> > >>>> On Tue, Dec 4, 2012 at 6:54 AM, Routing Freak
> > >>>> <routingfreak_at_gmail.com>
> > >>>> wrote:
> > >>>>> Marko
> > >>>>>
> > >>>>> What is wrong in my statement except that when default route is
> > >>>>> there it will accept the peering from neighbor .
> > >>>>> Could you explain me ?
> > >>>>>
> > >>>>>
> > >>>>> On Tue, Dec 4, 2012 at 6:55 AM, Marko Milivojevic
> > >>>>> <markom_at_ipexpert.com>
> > >>>>> wrote:
> > >>>>>>
> > >>>>>> You are not entirely wrong. BGP won't initiate session, but it
> > >>>>>> will respond if a session is initiated from another router.
> > >>>>>>
> > >>>>>> You can read more about it here:
> > >>>>>>
> http://blog.ipexpert.com/2010/11/08/bgp-peering-and-default-routes
> > >>>>>> /
> > >>>>>>
> > >>>>>> --
> > >>>>>> Marko Milivojevic - CCIE #18427 (SP R&S) Senior CCIE Instructor -
> > >>>>>> IPexpert
> > >>>>>>
> > >>>>>> On Mon, Dec 3, 2012 at 8:24 AM, Routing Freak
> > >>>>>> <routingfreak_at_gmail.com>
> > >>>>>> wrote:
> > >>>>>>> Hi Marko, Brian
> > >>>>>>>
> > >>>>>>> How does a BGP neighbor is formed by a default route. Two
> > >>>>>>> routers cannot be neighbors if the only route to reach the
> > >>>>>>> neighbor is a default route.
> > >>>>>>> the
> > >>>>>>> minimum prefix to reach teh neighbor should be /1 and max is /32
> > >>>>>>> and i have tested it several times.
> > >>>>>>>
> > >>>>>>> How will the BGP decide that its neighbor went down, by just
> > >>>>>>> seeing whether it has a route to reach the neighbor with
> > >>>>>>> atelast /1 route to it.
> > >>>>>>> But
> > >>>>>>> in
> > >>>>>>> this case, the next hop to reach the neighbor is not reachable,
> > >>>>>>> So in this case , it should check for any other path to reach
> > >>>>>>> the neighbor and why it is searching for a another path for the
> > >>>>>>> next hop to reach the neighbor ..
> > >>>>>>>
> > >>>>>>> It should check for the another path for the neighbor address
> > >>>>>>> and not the next hop which is used previously to reach the
> > >>>>>>> neighbor. In ALU box and MX960, it works this way and why not it
> > >>>>>>> is not working this way in Cisco.
> > >>>>>>>
> > >>>>>>> Correct me if i am wrong in this logic
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> On Sat, Dec 1, 2012 at 8:07 AM, Marko Milivojevic
> > >>>>>>> <markom_at_ipexpert.com>
> > >>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>> Without going any deeper (some topology information is missing
> > >>>>>>>> and m pod is otherwise busy to try this, no matter how FUN it
> > >>>>>>>> sounds), I'd venture a guess that yes, "igp" metric is compared.
> > >>>>>>>>
> > >>>>>>>> The "igp metric" in this sense is really "the metric to reach
> > >>>>>>>> the protocol, no matter what that protocol might be". In your
> > >>>>>>>> case, one of these protocols happens to be BGP. You may want to
> > >>>>>>>> test this hypotesis by tweaking the BGP's MED value for the
> > >>>>>>>> default route to make it numerically higher than OSPF cost to
> > >>>>>>>> reach the next-hop of the other route.
> > >>>>>>>>
> > >>>>>>>> Funnily enough, this is one of the few places where numerical
> > >>>>>>>> metric values of different protocols are directly compared,
> > >>>>>>>> regardless of the AD and/or longest-match.
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> Marko Milivojevic - CCIE #18427 (SP R&S) Senior CCIE Instructor
> > >>>>>>>> - IPexpert
> > >>>>>>>>
> > >>>>>>>> On Fri, Nov 30, 2012 at 6:21 PM, John Neiberger
> > >>>>>>>> <jneiberger_at_gmail.com>
> > >>>>>>>> wrote:
> > >>>>>>>>> I posted this question to the Cisco NSP list and I've also
> > >>>>>>>>> talked to a couple of guys from Cisco Advanced Services and
> > >>>>>>>>> I'm still stumped about something. I'll try my best to phrase
> > >>>>>>>>> it in a way that makes sense.
> > >>>>>>>>>
> > >>>>>>>>> Router A is learning about a prefix from two route reflector
> > >>>>>>>>> clients.
> > >>>>>>>>> In
> > >>>>>>>>> both cases, the next hop for the prefix is the loopback
> > >>>>>>>>> address of the advertising routers. Their loopback addresses
> > >>>>>>>>> are being advertised into OSPF.
> > >>>>>>>>>
> > >>>>>>>>> So, from the perspective of Router A, it's BGP table for this
> > >>>>>>>>> prefix has two paths:
> > >>>>>>>>>
> > >>>>>>>>> 1: 4.4.4.4 (loopback address of Router B, learned via OSPF)
> > >>>>>>>>> * winner due to lower IGP metric 2. 5.5.5.5 (loopback address
> > >>>>>>>>> of Router C, learned via OSPF)
> > >>>>>>>>>
> > >>>>>>>>> Now for the weirdness to begin. A network event occurs that
> > >>>>>>>>> causes the loopback address of Router C to go away. This
> > >>>>>>>>> shouldn't affect Router A because it is already selecting the
> > >>>>>>>>> shortest path to the network via Router B (4.4.4.4).
> > >>>>>>>>>
> > >>>>>>>>> However, Router A is also learning a default via BGP. That
> > >>>>>>>>> means that even though 5.5.5.5 (loopback of Router C)
> > >>>>>>>>> disappeared and is unreachable, the router is doing a
> > >>>>>>>>> recursive lookup and keeps the path in the BGP table;
> > >>>>>>>>> 5.5.5.5 is still reachable, it thinks, by using the default
> route.
> > >>>>>>>>>
> > >>>>>>>>> The weird thing is that this causes Router A to start using
> > >>>>>>>>> the wrong path!
> > >>>>>>>>> It seems to be preferring a path with a next hop learned via
> > >>>>>>>>> BGP to a path with a next hop learned via OSPF. Why would it
> > >>>>>>>>> do this? I see no documentation that would explain why a
> > >>>>>>>>> BGP-learned next hop is preferred over an IGP-learned next
> > >>>>>>>>> hop.
> > >>>>>>>>>
> > >>>>>>>>> Is the router still comparing IGP metrics even though the
> "wrong"
> > >>>>>>>>> path
> > >>>>>>>>> now
> > >>>>>>>>> has no IGP metric?
> > >>>>>>>>>
> > >>>>>>>>> It's not changing due to router ID, cluster length, or
> > >>>>>>>>> neighbor IP address.
> > >>>>>>>>> I checked. So, why is it switching?
> > >>>>>>>>>
> > >>>>>>>>> As soon as the BGP session from Router A to Router C times
> > >>>>>>>>> out, the extraneous path gets removed from the BGP table and
> > >>>>>>>>> the router goes back to using the correct path it should have
> > >>>>>>>>> been using all along.
> > >>>>>>>>>
> > >>>>>>>>> So, is a BGP-learned next hop preferred over an IGP-learned
> > >>>>>>>>> next hop?
> > >>>>>>>>> If
> > >>>>>>>>> so, why? If not, any idea why my router switches paths? I've
> > >>>>>>>>> turned on BGP debugging and IP routing debugging and haven't
> > >>>>>>>>> found a suitable explanation for the switch.
> > >>>>>>>>>
> > >>>>>>>>> John
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> Blogs and organic groups at http://www.ccie.net
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> _____________________________________________________________
> > >>>>>>>>> __________ Subscription information may be found at:
> > >>>>>>>>> http://www.groupstudy.com/list/CCIELab.html
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Blogs and organic groups at http://www.ccie.net
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> _______________________________________________________________
> > >>>>>>>> ________ Subscription information may be found at:
> > >>>>>>>> http://www.groupstudy.com/list/CCIELab.html
> > >>
> > >>
> > >> Blogs and organic groups at http://www.ccie.net
> > >>
> > >>
> _______________________________________________________________________
> > >> Subscription information may be found at:
> > >> http://www.groupstudy.com/list/CCIELab.html
> > >
> > >
> > > Blogs and organic groups at http://www.ccie.net
> > >
> > > _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Tue Dec 04 2012 - 21:52:06 ART