reason of BGP full mesh

hi all

I am searching for the reason of making iBGP peers a Full-Mesh,

so if they will be fully meshed, what this will achieve exactlly ?

and do we need a full mesh in all cases (this is regardless of route reflectors and confederations)

 

thanks,

Comments

  • Hi,

    There is a loop prevention mechanism that says: "Don't advertise a prefix received from an iBGP peer to another iBGP peer".

    That's the reason why you need either:

    1) full-mesh

    2) route-reflectors

    3) confederations

    Route reflection is the most used design, as it is difficult to accomplish full-mesh in most designs.

    If you consider the following simple topology:

    R1 --iBGP-- R2 --iBGP--R3

    Prefixes received from R1 are not propagated to R3 and vice-versa, due to the loop prevention mechamism. Best thing here is to make R2 a route-reflector, so it can "bypass" this rule.

    HTH

    Good luck!

  • dear qqabdal

    thanks for your reply,

    so let me change the question to

    "how this prevention loop mechanisim can garentee loop free in the topology"

    let us say there are two kinds of topologies

    1- linear like R1 === R2 === R3
        so why R2 will not send updates to R3 ? there should be no issue

    2- complex topology which the update mechanisim can work similar to EIGRP with split horizon rule !

        so R1 will advertise something to R2, then R2 will forward it to R3 but will no send it to R1 (split Horizon)

     

    thanks, 

  • hi all

    I am searching for the reason of making iBGP peers a Full-Mesh,

    so if they will be fully meshed, what this will achieve exactlly ?

    and do we need a full mesh in all cases (this is regardless of route reflectors and confederations)

    thanks,

    Hi,

    You should have full mesh iBGP peering if you don't deploy route-reflector or confideration. 

    BGP Split-horizon rule says "BGP update recieved from an iBGP peer is not sent to another iBGP peer". So, you have to have full mesh peering between iBGP peers so that all the updates received from an eBGP peer is sent to entire iBGP peers. You can use route-reflector in order to scale the design & confideration would also help you acheiving same goal.

    Hope this helps!

     

  • dear qqabdal

    thanks for your reply,

    so let me change the question to

    "how this prevention loop mechanisim can garentee loop free in the topology"

    let us say there are two kinds of topologies

    1- linear like R1 === R2 === R3
        so why R2 will not send updates to R3 ? there should be no issue

    2- complex topology which the update mechanisim can work similar to EIGRP with split horizon rule !

        so R1 will advertise something to R2, then R2 will forward it to R3 but will no send it to R1 (split Horizon)

     

    thanks, 

    If you had eBGP peering scenario in place, AS path attribute would prevent the loop but in the case of iBGP peering AS path attribute doesn't work for loop prevention at all. So, BGP Split-horizon rule prevents the loop by restricting the update between iBGP peers which helps receiving the update from a particular edge router to get to rest of the BGP world.

    HTH

  • In the linear topology there is no potential for loop, but BGP expects to have a full-mesh, that's why it is not advertise. So in the linear topology, BGP expects to have R1 somehow connected to R3.

  • dear qqabdal

    thanks for your reply,

    so let me change the question to

    "how this prevention loop mechanisim can garentee loop free in the topology"

    let us say there are two kinds of topologies

    1- linear like R1 === R2 === R3
        so why R2 will not send updates to R3 ? there should be no issue

    2- complex topology which the update mechanisim can work similar to EIGRP with split horizon rule !

        so R1 will advertise something to R2, then R2 will forward it to R3 but will no send it to R1 (split Horizon)

     

    thanks, 


     

    BGP can be regarded as an improvised distance vector protocol. It differs from your regular RIP like DV protocols in that it incorporates AS-PATH attributtes in every prefixes it advertises. To prevent routing loops, BGP will reject a prefix that has its own ASN on the AS-PATH list. However, this rule only works for eBGP peering. For iBGP peering, this rule is useless because the AS-PATH never changes inside an AS. To help overcome this shortfall, the BGP "split horizon" rule is enacted to prevent iBGP learned routes from being passed on to another iBGP peer. One way to propagate prefixes within an AS without violating the split-horizon rule is to have full-mesh iBGP peering. But this is an impractical requirement for a network of meaningful size because it just doesn't scale. As a result, RR and Confederation was invented as a workaround.

    That's the gist of it, I think.

  • Apart from the split-horizon/loop-prevention also remember n(n-1)/2 where "n" is the number iBGP peers and as the number of peers increase so does the mesh which is an administrative overhead, not to forget the cpu cycles.

    for ex: if there are 5 x iBGP peers a full mesh required 10 connections as per n(n-1)/2

  • peetypeety ✭✭✭

    so let me change the question to

    "how this prevention loop mechanisim can garentee loop free in the topology"

    let us say there are two kinds of topologies

    1- linear like R1 === R2 === R3
        so why R2 will not send updates to R3 ? there should be no issue

    2- complex topology which the update mechanisim can work similar to EIGRP with split horizon rule !

        so R1 will advertise something to R2, then R2 will forward it to R3 but will no send it to R1 (split Horizon)

    You're asking BGP to understand the topology.  It's not written to do that.  What if your linear example becomes a ring?  How do you expect BGP to realize it's been looped?  How do you expect BGP to implement split horizon, while also allowing next-hop to be rewritten?  That's not going to scale reliably.

  • thanks all for the explanatetions, I got the full story behind this.

    it is clear,

     

    and I was thinking like instead of making a full mesh solution to solve iBGP peering issue, so why the network scientists did not create a number (E.X RID) to be beside AS-PATH and it will work as following:

    1- if R1 sends an update to R2, if the AS-PATH does not match (eBGP peering), then R2 will forward this update to all connected routers inside its AS.

    2- when R2 sends this update to R3, here the AS-PATH will be matched, then it will look to the other value which is RID (RID of R2), and then R3 can forward it to R4 ,,,etc.

    in case if this update will reach back to R2, then R2 will discard it due to the presence of R2 RID in that update.

    [:^)]

     

Sign In or Register to comment.