Basic question on eBGP, iBGP and full mesh requirement

Answered Question
Nov 3rd, 2009

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?

I have this problem too.
0 votes
Correct Answer by CriscoSystems about 7 years 3 weeks ago

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)

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Correct Answer
CriscoSystems Tue, 11/03/2009 - 15:07

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)

CriscoSystems Tue, 11/03/2009 - 16:15

(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.)

Giuseppe Larosa Tue, 11/03/2009 - 23:38

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

Actions

This Discussion