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

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