Re: BGP Backdoor (Doyle Vol II page 240)

From: afiddler (afiddler@xxxxxxxxx)
Date: Wed Sep 05 2001 - 00:51:07 GMT-3


   
I believe that is correct. The addition of the backdoor parameter to the
network statement on the "other" IGP router will remove the entry in its BGP
table indicating that it was the originator of the route and (so) it will
not advertise the route.

You may want to go through the Halibi example. It is less complex to set up
and explains the backdoor concept a little better than the Doyle book. In
that scenario, as soon as you add the backdoor parameter, the local entry in
RTC's BGP table will disappear and so it will not advertise that route to
RTA and RTF.
----- Original Message -----
From: "Michael Wong" <Michael.Wong@nec.com.au>
To: "'afiddler'" <afiddler@wi.rr.com>; "Peng Li" <lipeng@canada.com>;
"Groupstudy - CCIELAB (E-mail)" <ccielab@groupstudy.com>
Sent: Friday, August 31, 2001 10:04 PM
Subject: RE: BGP Backdoor (Doyle Vol II page 240)

> OK, lets start with the "network" only command. On page 238, Doyle's book
states .....
>
> ".... the network command causes the EBGP discovered routes to be treated
as local BGP routes. Network 172.17.0.0 is advertised to Lillehammer via
EBGP, for instance, and is entered into the routing table. The command
network 172.17.0.0 is added to Lillehammer's configuration, even though
172.17.0.0 is not really a local route. Because the address is in the
routing table, the network command matches it and makes it a local route."
>
> ".... By first being an EBGP route, 172.17.0.0 is changed into a local BGP
route with the network command. Because 172.17.0.0 is now considered a local
route at Lillehammer, it is assigned an AD of 200. The RIP route to
172.17.0.0 now has a lower AD and becomes the preferred route ...."
>
> The above makes perfect sense and I can get this part to work .... yes it
does take a little time for it to appear, but other than that, no problems.
However my issue is with the "network backdoor" command. On page 241,
Doyle's book states ....
>
> "The network backdoor command has the same effect as the network command.
The EBGP route is treated as a local BGP route, and the AD is changed to
200. The difference is that the address specified by the network backdoor
command is not advertised to EBGP peers."
>
> OK, so basically I understand this to be the RIP route will take over as
it still has the lower AD, however the only difference is that the address
specified in the network command will not be advertised ..... cool !!!! No
problems ...... I get the picture and the logic about why you don't want the
network to be advertised etc., but it seems that when the "backdoor" command
is used, the routes no longer become local ???? By the way they also don't
get advertised.
>
> Am I understanding this correctly and I'm having these issues due to dodgy
IOS ????
>
> Thanks .... MW :)
>
>
> -----Original Message-----
> From: afiddler [mailto:afiddler@wi.rr.com]
> Sent: Saturday, 1 September 2001 9:02 am
> To: Peng Li; Michael Wong
> Subject: Re: BGP Backdoor (Doyle Vol II page 240)
>
>
> My study buddy and I went through this lab just a few weeks ago. It seems
> to work as stated. Lillehammer does not really have the RIP route, but
> advertises it so that it looks like an IBGP route. With a much higher AD,
> this route is not preferred as long as the RIP route exists. As soon as
the
> RIP route disappears, the next best route is the IBGP route from
> Lillehammer, which advertises it with an origin of IGP.
>
> Perhaps I just do not understand the issue you are having. I would be
happy
> to set this up again in my lab and provide some results to you if that
would
> help.
> ----- Original Message -----
> From: "Peng Li" <lipeng@canada.com>
> To: "Michael Wong" <Michael.Wong@nec.com.au>; <ccielab@groupstudy.com>
> Sent: Friday, August 31, 2001 6:03 AM
> Subject: Re: BGP Backdoor (Doyle Vol II page 240)
>
>
> > Hi,
> > I think there's several examples in the book either Jeff overlooked or
> doesn't elaborate in much detail or maybe some misunderstanding If I dare
to
> challenge.
> >
> > One of the AM example is what you discovered. According to my
> understanding and lab results, the "network xxx backdoor" does't change
the
> Ebgp into IBGP with changing AD from 20-200. This is not the way it works.
> When you finish you config of AM command, you should shut down the EBGP
> neibor and see the difference. It works now. The reason is that it takes
> time for EBGP tcp connection to setup and get routes with AD20,
> approximately 40-50 seconds. By this time, the rip already got the route
and
> by using "network" command . The rip learned route is already entered in
> Local BGP table with Weitht 32768 much hiher than the later learned EBGP
> with Weight of 100, this cause the Router deny EBGP routes and prefer IBGP
> one. at the same time, he keeps the RIP one in RT.
> >
> > Hope it helps and correct me if I'm wrong.
> >
> > Take care.
> > My lab is Oct.10 in Beijing.
> >
> > ----- Original Message -----
> > From: "Michael Wong" <Michael.Wong@nec.com.au>
> > To: "Groupstudy - CCIELAB (E-mail)" <>
> > Sent: Friday, August 31, 2001 1:40 AM
> > Subject: BGP Backdoor (Doyle Vol II page 240)
> >
> >
> > > BGP gurus .....
> > >
> > > Has anyone managed to get BGP backdoor to work properly ??? I'm going
> through Doyle's example on page 240 and I can't seem to get the BGP
backdoor
> command to work properly.
> > >
> > > The funny thing is that I am able to get the correct results and
change
> the EBGP route to a local BGP route and make RIP take precedence over the
> local BGP route with the "network 172.18.0.0" command, however when I use
> the same network command and just add "backdoor" to it, the RIP routes do
> not appear .... strange I thought ????
> > >
> > > The RIP routes are definitely getting through as when I close the BGP
> sessions, the RIP routes appear in the routing table. It seems that when
the
> "backdoor" command is added to the network command, BGP does not modify
the
> EBGP to a local BGP route and the route table still has an AD of 20.
> > >
> > > Any thoughts ????
> > >
> > > Thanks peoples ..... MW
> > > **Please read:http://www.groupstudy.com/list/posting.html
> > **Please read:http://www.groupstudy.com/list/posting.html
> **Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:32:14 GMT-3