BGP Confederation

In addition to a route reflector, the confederation is another method that reduces the number of IBGP connections in an AS. A confederation divides an AS into sub-ASs. Full-mesh IBGP connections are established in each sub-AS. EBGP connections are established between sub-ASs. ASs outside a confederation still consider the confederation as an AS. After a confederation divides an AS into sub-ASs, it assigns a confederation ID (the AS number) to each router within the AS. This brings two benefits. First, original IBGP attributes are retained, including the Local_Pref attribute, MED attribute, and Next_Hop attribute. Second, confederation-related attributes are automatically deleted when being advertised outside a confederation. Therefore, the administrator does not need to configure the rules for filtering information such as sub-AS numbers at the egress of a confederation.

Networking diagram of a confederation

As shown above, AS 100 is divided into three sub-ASs after a confederation is configured: AS65001, AS65002, and AS65003. The AS number AS 100 is used as the confederation ID. The number of IBGP connections in AS 100 is then reduced from 10 to 4, which simplifies the device configuration and reduces the loads on the network and CPU. In addition, BGP devices outside AS 100 only know the existence of AS 100 but not the confederation within AS 100. Therefore, the confederation does not increase the CPU load.

Key Components of BGP Confederation:

1. Sub-ASes: Smaller autonomous systems within the larger confederation.
2. Confederation Identifier: The AS number used to represent the entire confederation to the outside world.
3. Internal BGP (iBGP) Sessions: Peering sessions between routers within the same sub-AS.
4. External BGP (eBGP) Sessions: Peering sessions between routers in different sub-ASes within the confederation.

How to Implement BGP Confederation

Step-by-Step Configuration:

1. Define the Sub-ASes: Assign unique AS numbers to each sub-AS within the confederation. These numbers are only relevant within the confederation and are not visible to external peers.
2. Configure the Confederation Identifier: Set the confederation identifier, which is the AS number representing the entire confederation to external peers.
3. Establish iBGP Sessions: Configure iBGP sessions within each sub-AS. These sessions operate as standard iBGP connections.
4. Establish eBGP Sessions: Configure eBGP sessions between sub-ASes. Despite being labeled as eBGP, these sessions are treated similarly to iBGP sessions, with the added benefit of not requiring a full mesh within the confederation.
5. Adjust Routing Policies: Apply routing policies as needed to control the flow of routes between sub-ASes and to external peers

The role of AS_PATH attribute in Confederation

As you may already know, it is an attribute that contains a list of autonomous system numbers a route has traversed to reach its destination, including the number of AS that originated that route. When routing update passes an AS, the AS number is prepended to the list. In other words, AS_PATH attribute within routing update is modified only when traversing eBGP.

In standard BGP, AS_PATH attribute contains two parameters:

• AS_SET:?unordered set of ASs that a route has traversed
• AS_SEQUENCE:?ordered set of ASs that a route has traversed

In case of a confederation, two additional parameters are introduced:

• AS_CONFED_SET:?unordered set of sub-ASs that a route has traversed in confederation
• AS_CONFED_SEQUENCE:?ordered set of sub-ASs that a route has traversed in confederation

Confederation set (AS_CONFED_SET) is prepended to the existing AS_SET only when the route traverses the confederation, and is removed and replaced by the AS Confederation Identifier when the route leaves the confederation.

The AS number is prepended only by routers that are advertising routes to their eBGP neighbors. This means that whenever a router has to send a routing update towards another sub-AS, it will do it via intraconfederation eBGP session and add its sub-AS number to the list. Again, sub-AS number is only preserved within the confederation, which prevents routing information loops inside it. If a router has to send an update towards its iBGP neighbour within a sub-AS, it will not change the AS_PATH attribute.

There is one more thing that needs to be kept in mind when it comes to eBGP peering within confederation. In case all the sub-ASs run the same IGP, attributes such as next hop, MED, and local preference do not change when routing update is traversing the confederation eBGP connection, as opposed to standard eBGP. Essentially, the sub-ASs exchange routing information as if they are using iBGP, and the only attribute that changes is AS_PATH. In other words, eBGP behaves like iBGP when implemented inside a confederation. In case different IGPs are running within sub-ASs, the next hop value is changed in routing updates between eBGP peers.

When to Use BGP Confederations or Route Reflectors

RRs should be used:

• In situations where you want a quick solution with minimal architectural changes.
• In networks where the architecture allows for a straightforward implementation of RRs without inducing suboptimal paths.
• If the number of iBGP routers in the AS is on the order of hundreds of routers.

Confederations should be used:

• In networks where there’s a need for fine-grained control over routing policies internally.
• If the network is so large or diverse that breaking it down into smaller domains (sub-ASes) makes logical sense and makes administration easier.
• If the number of iBGP routers in the AS is on the order of hundreds or even thousands of routers.

BGP Confederation vs BGP Route Reflector

• ConfederationsPurpose: they both Overcome scalability limitation requiring full mesh iBGP peerings within an AS
• Method of achievement: Designated Route Reflectors forwards updates from one iBGP peer to other iBGP peers. Confederation breaks up a large AS into smaller sub-ASes.?
• Complexity: Route Reflector complexity is Medium (depending on design). Confederation complexity is High, especially during transition.
• Configuration Changes: The changes are moderate in Route Reflector: Introduce RR and client configurations. In Confedearation the changes are extensive: Need to define sub-ASes and reconfigure peers.?
• AS Number Usage: For Route Reflector there is no change in AS numbers. In confederation, there is internal use of new AS numbers (can use private AS range).
• Scalability: Route Reflector is Suitable for networks in the order of hundreds of iBGP routers.? Confederation Can scale to larger networks, even thousands of iBGP routers.?
• Policy Granularity: Route-Reflector granularity is medium, RRs control route reflection. Confederation granularity is high,Each sub-AS can have distinct policies.?
• Failure Impact?: The impact could be high if RRs are not redundant. For Confederation, the impact is localized within a sub-AS.
• Visibility Outside AS: For both the external peers see standard AS_PATH.
• Routing Table Size: For Route Reflector the table is generally unchanged. In Confederation, the table be smaller within each sub-AS.
• AS_PATH Length?: For Route Reflector the path remains unchanged. In confederation the AS path is increased internally due to sub-ASes, unchanged externally.
• Migration Challenge: For Route Reflector the migration is Low to Medium. whereas transitioning to confederation is complex.?

Conclusion

Both BGP Confederation and Route Reflectors are effective solutions for managing large-scale BGP networks, but they cater to different needs. Confederations are ideal for extremely large networks requiring detailed policy control and segmentation. Route Reflectors, on the other hand, offer a simpler, more scalable solution for networks that need to reduce iBGP peerings without extensive reconfiguration. Understanding these differences will help you choose the best approach for optimizing your network's performance and manageability.

Sources

https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/networking/bgp/bgp-confederations

https://www.routerfreak.com/bgp-network-design-bgp-confederation/

https://support.huawei.com/enterprise/en/doc/EDOC1100034072/cd3a5733/bgp-confederation

https://networklessons.com/bgp/bgp-confederation-explained

.