Re: BGP Trick: Peering Double Default Route

Hi Marko/Joe

BGP neighbrship cannot be formed between two neighbors when the only route
to reach the neighbor is the default route. This is a FACT. and i want to
know what is the logic behind this fact.

In what logic they have designed like this. Is there any logic behind this
fact ?

On Fri, Jul 20, 2012 at 1:11 AM, Joe Astorino <joeastorino1982_at_gmail.com>wrote:

> The really fun part is the rule about using the default-route to hit
> the BGP next-hop has changed over time between different IOS releases.
> I believe the current releases work as everybody has stated whereby
> the default route will not be used for next hop reachability, but I
> have actually seen it both ways.
>
> On Thu, Jul 19, 2012 at 12:37 PM, Marko Milivojevic <markom_at_ipexpert.com>
> wrote:
> > Sud,
> >
> > If the only route to reach the neighbor is the default route, a router
> > will not attempt to connect to it. I wrote a blog about it few years
> > back:
> >
> > http://blog.ipexpert.com/2010/11/08/bgp-peering-and-default-routes/
> >
> > By the end of the article, I address the double-default problem in a
> > slightly different fashion than posted here. My solution would work
> > after a reload though ;-).
> >
> > --
> > Marko Milivojevic - CCIE #18427 (SP R&S)
> > Senior CCIE Instructor - IPexpert
> >
> > On Thu, Jul 19, 2012 at 5:30 PM, Sud <mitsuie2_at_gmail.com> wrote:
> >> Hi Jose,
> >>
> >> I don't understand why it is not working with default routes at each
> end.
> >>
> >> Sud
> >>
> >> Sent from my iPad
> >>
> >> On Jul 18, 2012, at 5:29 PM, Raghava Rao <raghava.rao85_at_gmail.com>
> wrote:
> >>
> >>> Good article to further read on
> >>>
> >>>
> http://gandikitchen.net/post/2011/06/20/When-Null0-and-BGP-May-Cause-Problems
> >>>
> >>>
> >>>
> >>> //RR
> >>>
> >>> On 18 July 2012 17:14, Jose Jara <jjarafiz_at_gmail.com> wrote:
> >>>
> >>>> Hi mates,
> >>>>
> >>>> I am just writing to put here a trick that I have found out after
> doing
> >>>> some testing in BGP peering. Let4s say we have two routers (R1&R2)
> directly
> >>>> connected and they're going to establish an eBGP session between their
> >>>> loopbacks.They will use update-source with the loopback and
> >>>> disable-connected check. However, the reachability is via a default
> route
> >>>> in each router, therefore, the BGP session can not be established:
> >>>>
> >>>> BGP: *2.2.2.2 active open failed - no route to peer*, open active
> delayed
> >>>> 32091ms (35000ms max, 28% jitter)
> >>>>
> >>>> What I thought was, how could they go ahead and establish the session
> >>>> without changing the routing? What if I install a route to the
> loopback
> >>>> pointing to null 0 to bypass the BGP check and then, remove it ?
> >>>> I tested it and surprisingly it worked! Look at that:
> >>>>
> >>>> *R1(config)#ip route 2.2.2.2 255.255.255.255 null 0
> >>>> *R1(config)#
> >>>> *Mar 1 00:05:11.751: BGP: 2.2.2.2 open active, local address 1.1.1.1
> >>>> *R1(config)#no ip route 2.2.2.2 255.255.255.255 null 0
> >>>> *R1(config)#
> >>>> *Mar 1 00:05:17.843: BGP: 2.2.2.2 went from Active to OpenSent
> >>>> *Mar 1 00:05:17.847: BGP: 2.2.2.2 sending OPEN, version 4, my as:
> 100,
> >>>> holdtime 180 seconds
> >>>> *Mar 1 00:05:17.851: BGP: 2.2.2.2 send message type 1, length (incl.
> >>>> header) 45
> >>>> *Mar 1 00:05:17.903: BGP: 2.2.2.2 rcv message type 1, length (excl.
> >>>> header) 26
> >>>> *Mar 1 00:05:17.907: BGP: 2.2.2.2 rcv OPEN, version 4, holdtime 180
> >>>> seconds
> >>>> *Mar 1 00:05:17.907: BGP: 2.2.2.2 rcv OPEN w/ OPTION parameter len:
> 16
> >>>> *Mar 1 00:05:17.907: BGP: 2.2.2.2 rcvd OPEN w/ optional parameter
> type 2
> >>>> (Capability) len 6
> >>>> *Mar 1 00:05:17.907: BGP: 2.2.2.2 OPEN has CAPABILITY code: 1,
> length 4
> >>>> *Mar 1 00:05:17.907: BGP: 2.2.2.2 OPEN has MP_EXT CAP for afi/safi:
> 1/1
> >>>> *Mar 1 00:05:17.911: BGP: 2.2.2.2 rcvd OPEN w/ optional parameter
> type 2
> >>>> (Capability) len 2
> >>>> *Mar 1 00:05:17.911: BGP: 2.2.2.2 OPEN has CAPABILITY code: 128,
> length 0
> >>>> *Mar 1 00:05:17.911: BGP: 2.2.2.2 OPEN has ROUTE-REFRESH
> capability(old)
> >>>> for all address-families
> >>>> *Mar 1 00:05:17.911: BGP: 2.2.2.2 rcvd OPEN w/ optional parameter
> type 2
> >>>> (Capability) len 2
> >>>> *Mar 1 00:05:17.911: BGP: 2.2.2.2 OPEN has CAPABILITY code: 2,
> length 0
> >>>> *Mar 1 00:05:17.915: BGP: 2.2.2.2 OPEN has ROUTE-REFRESH
> capability(new)
> >>>> for all address-families
> >>>> BGP: 2.2.2.2 rcvd OPEN w/ remote AS 200
> >>>> *Mar 1 00:05:17.915: BGP: 2.2.2.2 went from OpenSent to OpenConfirm
> >>>> *Mar 1 00:05:17.915: BGP: 2.2.2.2 went from OpenConfirm to
> Established
> >>>> *Mar 1 00:05:17.915: %BGP-5-ADJCHANGE: neighbor 2.2.2.2 Up
> >>>>
> >>>> Just for fun!
> >>>>
> >>>>
> >>>> 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
> >>
> >> _______________________________________________________________________
> >> 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
> >
> >
> >
> >
> >
> >
> >
>
>
>
> --
> Regards,
>
> Joe Astorino
> CCIE #24347
> http://astorinonetworks.com
>
> "He not busy being born is busy dying" - Dylan
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
With Warmest Regards,
CCIE KID
CCIE#29992 (Security)
Blogs and organic groups at http://www.ccie.net