Re: BGP Path Selection weirdness regarding next hops

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
Received on Tue Dec 04 2012 - 20:24:07 ART