BGP Confederations
iBGP requires a full mesh of peerings which can become an administrative nightmare for larger ASes.
A BGP confederation divides our AS into sub-ASes to reduce the number of required IBGP peerings. Within a sub-AS we still require full-mesh IBGP but between these sub-ASes we use something that looks like EBGP but behaves like IBGP (called confederation BGP) . Here’s an example of what a BGP confederation could look like:
By dividing our main AS into two sub-ASes we reduced the number of IBGP peerings from 15 to 8.
Within the sub-AS we still have the full-mesh IBGP requirement. Between sub-ASes it’s just like EBGP, it’s up to you how many peerings you want. The outside world will never see your sub-AS numbers, they will only see the main AS number.
Links
Links to this page:
- BGP - BGP Algorithm within confederations
- BGP - Handling Multiple Communities on a Single Route
- BGP - RRs vs confederations
- BGP - iBGP full-mesh peering
- BGP - remove private AS
- BGP Confederation peerings
- BGP regular expressions - use of backslash for confederations
- BGP sub autonomous system
- MPLS - Using the BGP Allow-AS in feature