In the last article, we looked at the different path attributes used in BGP. In this article, we will be discussing the requirement that IBGP peers must be fully meshed, the reason behind this, and ways around this requirement.
CCNA Training – Resources (Intense)
One of the rules you may have come across while studying about BGP is that a BGP speaker does not advertise routes learnt from an IBGP peer to other IBGP peers. We will use the diagram below to illustrate this rule:
In the network above, R1 is advertising the 18.104.22.168/24 route. By default, R1 will advertise this route to all its IBGP peers—in this case, R2. When R2 receives the route, the rule above prevents R2 from advertising that route to other IBGP peers because it received the route from an IBGP peer. Therefore, R2 will not advertise that route to R3.
This rule is required to prevent routing loops within the AS. When a route is being sent to an external peer (via EBGP), the AS_PATH attribute is modified to reflect the ASs through which the route has passed. When a BGP speaker receives a route with its own AS in the AS_PATH, the route is ignored. This prevents routing loops in EBGP sessions. On the other hand, when routes are passed between IBGP peers, the AS_PATH attribute is not modified meaning there is no way for a BGP speaker to know that it wasn’t the one that advertised the route it is receiving from another IBGP peer.
Let’s configure the network above to see this rule in action.
hostname R1 ! interface Loopback34 ip address 22.214.171.124 255.255.255.0 ! interface FastEthernet0/0 ip address 192.168.12.1 255.255.255.0 ! router bgp 1 network 126.96.36.199 neighbor 192.168.12.2 remote-as 1 !
hostname R2 ! interface FastEthernet0/0 ip address 192.168.12.2 255.255.255.0 ! interface FastEthernet0/1 ip address 192.168.23.2 255.255.255.0 ! router bgp 1 neighbor 192.168.12.1 remote-as 1 neighbor 192.168.23.3 remote-as 1 !
hostname R3 ! interface FastEthernet0/0 ip address 192.168.23.3 255.255.255.0 ! router bgp 1 neighbor 192.168.23.2 remote-as 1 !
I will now paste the output of the BGP routing table for all three routers:
Notice that R1 is the originator of the route (next hop is 0.0.0.0); R2 has the route in its BGP table with a next hop of 192.168.12.1 (R1). However, R3’s BGP routing table is blank. As we discussed, this is because R2 is not allowed to advertise that route to other IBGP peers.
This rule is the reason why IBGP peers must be fully meshed within an AS. If R1 and R3 had an IBGP peering session between them, then R1 will also advertise that network to R3. The configuration addition on R1 and R3 is as follows:
router bgp 1 neighbor 192.168.23.3 remote-as 1 ! ip route 192.168.23.0 255.255.255.0 192.168.12.2
router bgp 1 neighbor 192.168.12.1 remote-as 1 ! ip route 192.168.12.0 255.255.255.0 192.168.23.2
Note that the IBGP session is only a logical one; i.e., there is no physical connection between R1 and R3; they are forming the IBGP session through R2. I have also used static routes to establish underlying connectivity.
If we look at the BGP table of R3 now, we will see the 188.8.131.52/24 network advertised by R1.
The requirement of fully meshed IBGP means that, for n BGP speakers (within the same AS), there will be n(n-1)/2 IBGP peering sessions. For example, if there are 5 BGP speakers in a particular AS, then there must be 5(5-1)/2 IBGP sessions, which is 10 peering sessions. This may not scale well in ASs that have large number of IBGP peers. As such, there are two methods by which this requirement can be relaxed, as we will now consider.
A BGP speaker configured as a route reflector (RR) can advertise routes received from an IBGP peer to other IBGP peers. When talking about route reflection, there are two types of internal peers related to the RR: client peers and non-client peers. The RR and its client peers form a cluster, while non-client peers are like normal IBGP peers. A diagram will illustrate this concept better.
In the above diagram, R2 is acting as the route reflector. R1 and R3 are client peers while R4 is a non-client peer. As you can see, R1 and R3 do not need to form an IBGP session with each other; they only need to form a peering relationship with the route reflector, thus reducing the number of IBGP peering sessions.
There are a few reflection rules we need to be aware of:
When an RR receives a route from a client peer, it will reflect it to other client peers and also non-client peers.
When the RR receives a route from a non-client (IBGP) peer, it will reflect it to its client peers.
Finally, if an RR receives a route from an EBGP peer, it will advertise it to all clients and non-clients.
Route reflection is able to avoid routing loops by using two new attributes: ORIGINATOR_ID and CLUSTER_LIST. Basically, a client that receives routing information with its own ORIGINATOR_ID will ignore that route because it was the one that originated it. The CLUSTER_LIST contains a sequence of CLUSTER_ID values and is used to prevent a route that was originated in a particular cluster from re-entering that cluster. If an RR finds its CLUSTER_ID in the CLUSTER_LIST of a particular routing information, it ignores such update.
Confederations also reduce the number of IBGP peering sessions by allowing an AS to be broken down into smaller ASs called Member Autonomous Systems. BGP speakers within a member AS form IBGP sessions between themselves but they form EBGP sessions with BGP speakers in other member ASs. External peers to the confederation are not aware of the internal structure of the confederation; i.e., all member ASs are seen as just one AS.
AS 65001 and AS 65002 are member ASs within the confederation (AS1). Like we said, AS3 sees the entire confederation as AS1 and is not aware of the member ASs. Confederation adds two types to the AS_PATH attribute: AS_CONFED_SEQUENCE and AS_CONFED_SET.
The difference between route reflectors and confederations is that all BGP speakers within a confederation must support the confederation function unlike in route reflector, where only the route reflector needs to support route reflection.
In this article, we have discussed the reason why IBGP peers must be fully meshed. This is because of the rule that a BGP speaker cannot advertise routes learned from an IBGP peer to other IBGP peers. This requirement can cause serious scaling issues in the case of an AS with numerous BGP speakers. We looked at two features that can help with this problem: Route reflection and confederations. In the next article, we will be configuring one of these features.
I hope you have found this article insightful.
References and Further Reading
RFC 4456: BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP): https://tools.ietf.org/html/rfc4456
RFC 5065: Autonomous System Confederations for BGP: http://tools.ietf.org/html/rfc5065
Internet Routing Architectures 2nd Edition by Sam Halabi and Danny McPheron
Routing TCP/IP, Volume II, by Jeff Doyle