Overcoming Scalability Limitations of iBGP

Overcoming Scalability
Limitations of iBGP
As a network grows in size, iBGP can cause scalability issues. The main issue of concern is fully
meshing BGP inside an AS. iBGP devices will not advertise a route they have learned from an
iBGP neighbor to another iBGP neighbor, which is why iBGP requires a fully meshed network.
In small networks, this doesn’t cause any scalability issues, but as a network grows into a large
network, scalability can become a real problem. The reason fully meshing an iBGP network
causes a problem is the number of sessions needed to fully mesh the network.
Think of it like this: For
n
BGP speakers, the number of sessions needed would be
n
(
n
– 1)
/
2.
For a network with only four BGP speakers, you would need only six sessions. That’s not too bad,
but if you double the number of BGP speakers, you would need 28 sessions, and if you double that
number of BGP speakers, you would need 120 sessions. As you can see, the more BGP speakers
that are added, the harder it becomes to manage the number of sessions required. Not only that,
but to establish
n
(
n
– 1)/2 sessions, you must enter twice as many configuration commands (one
at each of the two ends of the session), or
n
(
n
– 1).
There are a couple of alternatives to fully meshed iBGP networks in use today:

Route reflection

Confederations
Each of these alternatives can be used by itself or together to overcome the iBGP scalability issue.