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.netReceived on Tue Dec 04 2012 - 07:54:57 ART
This archive was generated by hypermail 2.2.0 : Tue Jan 01 2013 - 09:36:53 ART