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