iBGP full mesh

Hi there,

I have question about iBGP full mesh,

To solve BGP split horizen issue, we need to make full mesh all iBGP.

I know that there is route reflector to decrease number of BGP peer.

The question is that why full mesh is default way to solve issue as design?

I think hub and spoke diagram ,means route reflector?, is enough diagram to solve issue.

If we need more fault tolerance it's ok to put 2 hub.

I want to know the reason why iBGP was designed as it needs full mesh as default.

Comments

  • The real issue was that iBGP by default doesn't include any field in the update to help prevent control plane loops. So the mechanism taken was to ensure that only the router that put the route into the domain is allowed to tell others. In this way a control plane loop cannot form.

    Also note that other enhancements to iBGP add fields in the update that is used for loop prevention.

    RR - cluster-id (prevent RR loop) originator-id (prevents client loop)

    Confed - as-confed-sequence (prevent loop) and as-confed-set (prevent loop during summarization within AS)

    HTH

    I want to know the reason why iBGP was designed as it needs full mesh as default.
  • I have question about iBGP full mesh,

    Historically there are some very good reasons why.  In the old days routers were not very powerful and within an AS only the routers on the edge would be able to run BGP - remember it CPU intensive.  Other routers within the AS would run an IGP like OSPF.

    Say we have as1-as2-as3. Considering as2 we have routers r1,r2 and r3. r1 has an iBGP with r3 and eBGP peering with as1, while r3 has an eBGP peering with as3 and of course the iBGP peering with r1. The routers in as2 are connected r1-r2-r3 and r2 isn't running BGP. All three routers are running OSPF.

    if as1 announced a prefix to as2 it would be announced by as2 onto as3, however the data plane would be broken at r2. Why it wouldn't know how to reach the prefix advertised by as1.  Two thing we're done to fix this. BGP prefixes were redistributed into OSPF and BGP synchronisation was turned on.  This fixed the blackholing on r2 and placed the additional requirement that the prefix learnt from as1 couldn't advertised until it was learnt via an IGP.

    Clearly this design was OK but had massive scaleability issues as the Internet routing table has grown.

    The solution to this problem was to turn off synchronisation and not to redistribute BGP routes into an IGP.  In this design r2 would have to run BGP a (be powerful enough) and have a an iBGP a peering with both r1 and r2 as iBGP learnt prefixes are advertised to other iBGP a peers.

    As a side note full mesh is still a valid design if you want to support multi path. With a route reflector only the best path is advertised to other peers.

    Typically you would align the BGP design with your network topology so - in hub and spoke with all routers in the same as a route relflector at the hub makes sense but doesn't always have to be the case.

    An iBGP session running over TCP has a TTL of 255 and is traditionally sourced from loopbacks with are advertised via an IGP. As such it is irelevant which path the TCP session takes as long as the correct information imparted for the correct best path to be chosen.

     

  • Hi everyone.

    Let me check.

    I am littli bit confused.

  • HI All,

    I understand than you.

Sign In or Register to comment.