BGP Confederation is specified in RFC 5065, which describes the use of Autonomous System Confederations for BGP – Border Gateway Protocol.
This topic and many other simple and advanced BGP topics are covered in Orhan Ergun’s BGP In-Depth course from a design and hands-on perspective.
BGP confederations help with this scalability issue by allowing the engineer to subdivide the autonomous system into smaller sub-autonomous systems.
There are generally two design methods when considering BGP confederations.
BGP Confederation is designed in two ways:
1. Same IGP (OSPF, IS-IS, EIGRP, etc.) in each Sub-AS
2. Different IGP in the sub-AS
There are pros and cons of each method as usual. Implementing the BGP confederation significantly reduces the total number of BGP sessions.
Implementing BGP confederations involves quite a change to BGP configurations and the architecture itself, adding more complexity to achieve a stable and scalable BGP design.
Migrating a network to a BGP confederation will be disruptive. Routers that are part of a sub-AS will need to change their BGP configuration to use the sub-AS instead of the real AS numbers.
Figure – BGP Confederation
BGP routers within a sub-AS peering are IBGP peers., BGP routers in different sub-AS are EBGP peers which means that the AS number is prepended when an update travels between the sub-AS.
In the above figure, as you can see, the entire BGP network is divided into Sub-AS (Sub- Autonomous Systems). Since IBGP runs in each sub-AS, IBGP rules still apply in each Sub-AS. So, in each sub-AS, either full-mesh IBGP or Route Reflector can run. In the figure, Sub-AS 65001 have Full-mesh IBGP and Sub-AS 65002 has IBGP Route-Reflection.
If a router has to send an update towards its IBGP neighbor within a sub-AS, it will not change the AS_PATH attribute. BGP between the sub-ASs is called as intra-confederation EBGP
EBGP routes that are exchanged between the sub-ASs are also known as confederation external routes, which are preferred over IBGP routes when it comes to best path selection.
If BGP has to choose between two paths to the same destination, one path leading inside the sub-AS, and another outside the sub-AS but within confederation, it will choose the external path – towards the neighboring sub-AS.
If it has to choose between the confederation EBGP route and the EBGP route that leads outside the confederation, BGP will choose the second one
Implementing BGP confederations involves quite a change to BGP configurations and the architecture itself, adding more complexity to achieve a stable and scalable BGP design.
Migrating a network from full-mesh IBGP or Route-Reflection to a BGP confederation will be disruptive because Routers that are part of a sub-AS will need to change their BGP configuration to use the sub-AS instead of the real AS numbers.
BGP Confederation Configuration on Cisco:
To configure a BGP confederation on Cisco Routers, you must specify a confederation identifier. To the outside world, the group of autonomous systems will look like a single autonomous system with the confederation identifier as the autonomous system number. To configure a BGP confederation identifier, use the following command in router configuration mode:
Router(config-router)# bgp confederation identifier as-number To create Intra Confederation EBGP peering with the other sub-ASes, use the following command in router configuration mode:
Router(config-router)# bgp confederation peers as-number BGP Confederation vs. BGP Route Reflector:
Although this comparison requires a separate blog post, in this post very briefly let’s discuss the differences.
Both BGP design option is done for BGP Scaling. But the main difference is BGP Confederation is usually preferred in Merger and Acquisition scenarios.
BGP Route Reflection in IBGP networks is the most common deployment model and in most cases, it is the preferred option when BGP Scalability is the requirement.
