Re: ibgp/ebgp AD

Hi Atle,

Since the nature of routes learned via BGP is external, they should normally
come from another AS via eBGP and this should be the optimal path. Having
lower eBGP AD protects from learning external routes via iBGP(or via IGP)
from inside your AS that maybe were learned via another gateway of your AS
(in case of multihoming).
Imagine if you have R1 and R2 both peering with ISP routers and both are
learning network 100.100.100.0/24. If you receive this prefix on R1 and
distribute it into your AS via iBGP, on R2 you will receive it from both R1
and from ISP router. If iBGP AD would be higher then R2 would choose this
internal path via R1 which would lead to suboptimal routing. Sometimes you
may need to have this suboptimal routing in case one line is primary another
backup but there are several more fancy ways to achieve this in BGP.

In BGP this logic is reversed because iBGP is never used or should not be
used as an IGP and the routes learned via eBGP are normally the best that is
why eBGP has lowest AD of 20.

Vitali

On Sun, Jan 23, 2011 at 8:59 PM, Atle Xrn Hardarson <
atle.hardarson_at_gmail.com> wrote:

> Hi experts,
>
> It is common knowledge that a routing protocol and platform *should*
> prefer internal routes before external routes.
> Like, OSPF prefers Intra Area Routes before Inter Area Routes, and
> EIGRP prefers Internal (AD 90) before External (AD 170) routes...
>
> So then to my question - *why* does eBGP have a lower AD then iBGP?
> (20 vs 200)? As in "why did Cisco design it that way"?
>
> I tried looking it up, but having problems finding my answer. I really
> enjoy reading protocol history, and knowing why things were designed
> the way they were, it helps me learn...but this one I can't find.
>
> Thx
>
> Atle
>
>
> 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 Sun Jan 23 2011 - 21:41:32 ART