Re: BGP Backdoor

From: Darby Weaver <ccie.weaver_at_gmail.com>
Date: Tue, 7 Apr 2009 19:06:43 -0400

To add to Shaukat's correct response and give an example.

I've got a network in 2 states over a 150mb Metro E Link.

The link in the north has a Router with about 20 spokes currently over
Frame.

The link in the south has 2 other atm connections (backup connections) both
mave metro for their primary links to the southern data center.

Currently all this is connected via EIGRP with AD of 90

Now... the Hub Router in the northern data center and all of the spokes are
going to be connected into an MPLS Cloud.

So are the 2 atm routers in the south as well a router in the south that is
connecte to the router that is directly connected to the router in the north
over the metro link (incidently this same router was the hub of the hub and
spoke frame topolgy and now is a node on the mpls network over the DS3 link
while the ethernet link still uses the metro link).

Now... the MPLS nodes - Total 3 atm routers in the south. The Router in the
north (EIGRP to the South and eBGP to the MPLS Cloud).

So... the routes from the cloud are going have an AD of 20.

But the primary routes in the south have a metric of 90 to the core in the
south.

The AD to the spoke routers in the north is 20 which would be fine except
the routers in the South should prefer the primary route via the IGP and not
via eBGP.

So...

All the eBGP Sites in the MPLS cloud would be configured with the backdoor
command in order to now give those routes an AD of 200 (less preferred than
EIGRP with an AD of 90) and still less preferred if they are redistributed
into EIGRP with an external AD of 170.

Now traffic between north and south will flow via EIGRP and the Metro Link.

Traffic from the spokes will travel to the hub (a default route would be
injected).

Traffic from the spokes will not prefer to use the south's backup atm links
(in this situation the southern data center is redistributing a 0.0.0.0
however other metrics are being used so that the spokes in the north prefer
the northern hub 1st and the southern atm backup sites prefer the southern
data center to the northern data center).

Summary:

The primary links will use EIGRP in the South and between the North and
South.

The backup links will not prefer eBGP due to the backdoor command and the
eBGP metric now being 200.

The spokes only have a single link out of each site and so even though the
AD is 200 it is the only path with a 0.0.0.0....

Also the 2 data centers will prefer the EIGRP over the eBGP as well.

I think I said all that right....

Anyway... That's a design I'm working on and I think it answers your
question.

On Tue, Apr 7, 2009 at 6:41 PM, Shaukat Khalil (shkhalil) <
shkhalil_at_cisco.com> wrote:

> Nick,
>
> Consider a situation where you have two Autonomous systems and you are
> doing some kind of IGP between them now if you learn the same route
> through bgp process although the bgp is a less efficient way of reaching
> but bgp being lesser admin. Distance, it will be trusted. In order to
> avoid this you use the backdoor command to increase the distance of bgp
> to 200 so it is not trusted. Thanks.
>
> Shaukat
>
> -----Original Message-----
> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
> Nick
> Sent: Tuesday, April 07, 2009 3:36 PM
> To: Cisco certification
> Subject: BGP Backdoor
>
> Hi all,
>
> Can anyone help me understand BGP backdoor command please? Does anyone
> have a real world example of why it would be used?
>
> Thanks
>
> Nick
>
>
> 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 Apr 07 2009 - 19:06:43 ART

This archive was generated by hypermail 2.2.0 : Mon May 04 2009 - 07:39:11 ART