iBGP Confederation Configuration and Verification

1. The Concept of a BGP Confederation

A BGP confederation addresses the iBGP full-mesh problem by dividing a single, large Autonomous System (AS) into multiple smaller, more manageable sub-autonomous systems (sub-ASes).

From the perspective of the outside world (any external BGP peer), this entire collection of sub-ASes appears as a single AS, identified by a "confederation identifier." Internally, however, the network operates as a group of distinct ASes.

Think of it like a large corporation (the confederation) made up of several divisions (the sub-ASes). External partners only need to know how to interact with the corporation as a whole. Internally, the divisions have their own structure but communicate with each other following specific corporate protocols.

Let's watch a video that introduces this concept and contrasts it with the iBGP full-mesh and route reflector solutions.

2. Peering and Route Propagation in a Confederation

The key to understanding confederations is knowing how peering and BGP attributes are handled.

• Peering within a sub-AS: This is standard iBGP. This means all routers within the same sub-AS must be fully meshed or, more practically, use route reflectors inside that sub-AS.
• Peering between sub-ASes: This is technically an eBGP session because the peers are in different AS numbers. However, the router is configured to know these peers are part of the same confederation. This "confederation eBGP" behaves much like an iBGP session: attributes like Next Hop, Local Preference, and MED are preserved as the route crosses from one sub-AS to another. This is a crucial difference from a standard eBGP peering.

To understand this special behavior and how routes propagate, let's continue with the video.

AS_PATH Handling

As the video explained, the AS_PATH is treated specially:

1. When a route is advertised from one sub-AS to another, the sending sub-AS number is added to a confederation sequence in the AS_PATH, typically shown in parentheses: (65002 65001). This sequence is used for loop prevention within the confederation.
2. When the route is advertised outside the confederation entirely, this entire parenthesized sequence is removed and replaced by the single public confederation AS number. The outside world remains unaware of the internal sub-AS structure.

To reinforce these core concepts, let's review the official Cisco documentation.

3. Configuration and Verification

Configuring a confederation involves three key commands within the BGP routing process. All commands are applied on routers that are part of the confederation.

1. router bgp <sub-as-number>: A router's BGP process is initiated using its local sub-AS number, not the main confederation number.
2. bgp confederation identifier <main-as-number>: This command tells the router the public-facing AS number of the entire confederation. This AS number will be presented to all true eBGP peers outside the confederation.
3. bgp confederation peers <list-of-other-sub-as-numbers>: This command lists all other sub-AS numbers that are part of the same confederation. This is what enables the special "confederation eBGP" behavior for peerings with routers in those ASes.

Let's look at the official documentation for the command syntax and a complete configuration example.

Verification

After configuration, you verify a confederation primarily using the show ip bgp command. When you inspect a route that has traversed the confederation, you will see the sub-AS path in parentheses.

For example, on a router in sub-AS 6003 from the example you just read, a route originating from an external AS (e.g., 777) and passing through sub-AS 6001 would show an AS_PATH like (6001) 777. This confirms the confederation is working and the path is being tracked correctly for internal loop prevention. If that same route were then advertised to an external peer, the (6001) part would be removed and replaced with 500, the confederation identifier.

router bgp 100
 bgp confederation identifier 65010
 bgp confederation peers 65020 65030

router bgp 65010
 bgp confederation identifier 100
 bgp confederation peers 65020 65030

router bgp 65010
 bgp confederation identifier 100
 neighbor 192.168.1.2 remote-as 100
 neighbor 192.168.1.3 remote-as 100

router bgp 100
 bgp confederation peers 65010 65020 65030

4. Confederations vs. Route Reflectors

You now have two powerful tools for scaling iBGP. Choosing between them is a key design decision.

In many large networks, you may even see a hybrid approach: a confederation is used to break the AS into large sub-ASes, and route reflectors are used within each sub-AS to manage the internal iBGP mesh.

Conclusion

In this lesson, we added BGP confederations to your network design toolkit. It is a powerful, if more complex, alternative to route reflectors for solving the iBGP full-mesh scalability problem.

Key Takeaways:

• A confederation logically divides a single AS into multiple sub-ASes.
• Externally, the confederation appears as a single AS via the bgp confederation identifier.
• Peering between sub-ASes is a special form of eBGP that preserves iBGP attributes like Local Preference, Next Hop, and MED.
• The bgp confederation peers command identifies which ASes are part of the confederation.
• Loop prevention is handled by adding sub-AS numbers to the AS_PATH in a parenthesized list, which is stripped before being advertised to external peers.
• Confederations provide strong administrative and policy boundaries, making them ideal for very large or complex autonomous systems.

Preview of the Next Lesson:

Having mastered the two primary methods for scaling iBGP inside your autonomous system (route reflectors and confederations), our focus will now shift outward. In the next lesson, we will apply BGP for enterprise multihoming scenarios, connecting your enterprise network to one or more Internet Service Providers for redundancy and performance.