cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6309
Views
10
Helpful
3
Replies

Basic question on eBGP, iBGP and full mesh requirement

news2010a
Level 3
Level 3

Hi, just want to confirm:

The requirement that a BGP peer must have a full mesh connectivity to its neighbors (or otherwise use mechanisms such as router reflectors and confederations to overcome that requirement) applies to both eBGP and iBGP, correct?

1 Accepted Solution

Accepted Solutions

CriscoSystems
Level 5
Level 5

Not fully.

It is a requirement for IBGP (unless, as you note, there are route reflectors configured).

EBGP peers are supposed to be directly connected; but this can be easily overcome if the peers have an IGP (or clunky static route) to each other and the "ebgp-multihop n" paremeter (where n is the number of hops to the EBGP peer) is added to the neighbor...remote-as statement under your bgp process.

HTH,

-- stuey

(p.s. please remember to rate helpful posts)

View solution in original post

3 Replies 3

CriscoSystems
Level 5
Level 5

Not fully.

It is a requirement for IBGP (unless, as you note, there are route reflectors configured).

EBGP peers are supposed to be directly connected; but this can be easily overcome if the peers have an IGP (or clunky static route) to each other and the "ebgp-multihop n" paremeter (where n is the number of hops to the EBGP peer) is added to the neighbor...remote-as statement under your bgp process.

HTH,

-- stuey

(p.s. please remember to rate helpful posts)

(It won't let me "edit" my above post for some reason.)

A note about my answer (whose accuracy I stand by) is that I kind of answered in two flavors. On the EBGP matter I was talking about physical topology; whereas in IBGP the term "full mesh" refers to configured neighborships, irrespective of the physical topology. (I believe... I'll await correction/confirmation on that.)

Hello Stuey,

your answer is correct.

Let me add the root cause of this different behaviour between iBGP and eBGP:

in eBGP the BGP AS path attribute is updated with the ASN of the peer.

in iBGP the BGP AS path attribute is left unchanged until the advertisement has to be sent to an eBGP session.

so eBGP sessions can take advantage of built-in loop avoidance checks in AS path attribute: if an advertisement comes back to a router it will reject it because AS path already contains its AS number.

for iBGP sessions to avoid full mesh requirements there are two tools (that can be used together)

BGP confederation:

add a second separate AS path attribute that will store all the mini AS numbers and that can be easily stripped when sending the update to a true eBGP session.

BGP route reflectors:

to solve the loop avoidance problem they introduce two attributes:

Originator-Id = BGP Router-id of device that injected the route in BGP

Cluster-List = history of reflections contains RRS router-ids or cluster-ids

Hope to help

Giuseppe

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card