Home » BGP » IBGP Basics

IBGP Basics

IBGP works a little different from EBGP. There are a set of rules that apply to IBGP implementation which make IBGP different from EBGP.

# 1. Routes learnt from One IBGP Peer cannot be advertised to another IBGP Peer.

When two IBGP neighbors send update messages to each other they do not add the ASN in AS_Path attribute in the update because both of them are in the same AS and  the AS_Path will not change. Since BGP uses the ASN in the AS_Path attribute to avoid loops, and IBGP will not add the ASN to AS_Path when sending updates in the same AS, this can cause a potential routing loop. To avoid such loops IBGP has to follow a rule which says that when a route is learnt from an IBGP neighbor, that route cannot be advertised to another IBGP Peer.

Consider the example below.

RTR-A is advertising to RTR-B. RTR-B learns the route but will not advertise that route to RTR-C. Similarly RTR-B will also learn the route From RTR-C but will not advertise this route to RTR-A. Since all the three routers are in the same AS and in same AS BGP does not advertise routes that have been learned from an IBGP peer to another IBGP peer.

This is a partially meshed IBGP network hence RTR-A and RTR-C are not exchanging the NLRI.

This can be resolved by creating a logical connection between RTR-A and RTR-C. A BGP Session can be established between RTR-A and RTR-C to allow both of them to exchange their BGP learnt Routes.The TCP Session that RTR-A and RTR-C use to establish the BGP passes through RTR-B, so it is important that the data link addresses interconnecting RTR-A and RTR-C are known to them.

In iBGP, the routes learnt from one iBGP neighbor are not advertised to another iBGP neighbor due to the BGP Split Horizon Rule. To overcome the issues generated by this rule, one option is to have a full mesh of iBGP routers, where each iBGP router is peering directly with all other iBGP routers in the AS. The solution is feasible if you have a small number of iBGP routers, but it will not scale if you need a large number of iBGP speaking routers in the AS.

The number of iBGP Sessions needed in an AS for Full mesh IBGP are calculated with the formula N(N-1)/2.

So assuming you have 10 iBGP routers then the number of iBGP peering sessions would be  10(10-1)/2 = 45 iBGP Sessions to manage within the AS. Thats a lot of configuration and a lot of room for errors and may become difficult to troubleshoot.

There are 2 alternatives to creating a Full Mesh iBGP Routing, which are
1. Route Reflectors
2. Confederations

# 2 Rule of Synchronization: For A Route to be learnt from an IBGP neighbor, it must first be known via an IGP. Any route learnt from IBGP is entered into the routing table only if that route is first learnt by an IGP

Note: In some case Synchronization is not practical and this rule can be turned off by command: No Synchronization.

Synchronization requires that before a route is learnt from an IBGP neighbor and entered into Routing table and advertised to other BGP peers, the route must first be learnt via IGP.

In this example, RTR-A and RTR-C have formed a BGP Peering, and the TCP session passes through RTR-B. There is no physical connectivity between RTR-A and RTR-C but a logical connection exists. If Synchronization is turned on, then it is important to note that the routes advertised by RTR-A will appear in the RTR-C’s Routing table only if these routes exist in the IGP. The same applies for RTR-A, the routes advertised by RTR-C will not appear in the RTR-A’s Routing table if these routes are not being learnt by the IGP first.

RTR-B is directly connected to Both RTR-A and RTR-C and is learning the routes from both of them.  RTR-B still  cannot advertise the routes learnt from RTR-A to RTR-C and the routes learnt from RTR-C to RTR-A because there is either no IGP running or these routes are not in IGP, and since both RTR-A and RTR-C are not directly connected they have to cross through RTR-B. Since there is no entry in IGP for these routes RTR-B cannot advertise these routes -as per the rule of synchronization.

If the routes advertised by RTR-A and RTR-C are being learnt by an IGP then both RTR-A and RTR-C will learn each others BGP routes in their BGP and routing tables.

There are two workarounds for these situations.

1. Not all routes can be redistributed into IGP (Since the Internet Routing table is very large and IGP cannot scale to it) then  have all the IBGP routers fully meshed and then turn off the Synchronization rule with no synchronization command.

2. Redistribute all external routes into IGP. Not a feasible solution as IGP will not scale to hold all the internet routes.

Python Tutorial: Python Network Programming – Build 7 Apps


Incoming search terms for the article:

One thought on “IBGP Basics

  1. Homesagilient says:

    Excellent post. Thanks!

Leave a Reply