11-03-2009 02:23 PM - edited 03-04-2019 06:36 AM
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?
Solved! Go to Solution.
11-03-2009 03:07 PM
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)
11-03-2009 03:07 PM
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)
11-03-2009 04:15 PM
(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.)
11-03-2009 11:38 PM
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
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: