Re: BGP Path Selection weirdness regarding next hops

RF,

This was not a case where a default route was being used to reach a
neighbor. The default route (or a supernet) was being used to validate
reachability for a next hop. The end result was that the router chose a
path that was invalid, but it didn't know it.

John

On Mon, Dec 3, 2012 at 9: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
Received on Mon Dec 03 2012 - 10:04:06 ART