What Is BGP Confederations in Networking?

Think of BGP Confederations like a large company that has several smaller regional offices, but all offices share the same company name and branding to customers. In networking, an autonomous system (AS) is like a company with a unique ID number. Normally, all routers inside one AS must talk to every other router directly, which is called a full mesh.

This works for small networks but becomes a huge burden as the network grows, because each router must maintain many connections. A BGP Confederation solves this by dividing the big AS into smaller sub-AS numbers, each like a regional office with its own internal number. Routers inside one sub-AS talk to each other with normal internal BGP rules.

When they need to talk to routers in a different sub-AS, they use a special kind of communication that looks like external BGP between companies, but with a twist: the routing information is still treated as internal. To the outside world, the entire network still appears as a single AS, just like the company uses one name publicly. So you get the benefit of reduced connections and simpler management without breaking how other networks see you.

This is extremely useful for large service providers or enterprises that have hundreds of routers in one AS. It allows them to scale efficiently without redesigning their whole routing architecture. The approach uses standard BGP rules with some modifications, making it a well-understood and reliable technique for advanced network design.

BGP Confederations are a scalability enhancement for Internal BGP (IBGP) that reduces the number of required IBGP peering sessions within a single autonomous system. In standard IBGP, all routers inside the same AS must form a full mesh of TCP connections because IBGP does not re-advertise routes received from one IBGP peer to another IBGP peer, by default. This full mesh requirement becomes impractical in large networks, as the number of connections grows quadratically with the number of routers.

BGP Confederations address this by subdividing the autonomous system into multiple smaller sub-autonomous systems, each identified by a unique confederation AS number. Within each sub-AS, routers operate under standard IBGP rules, maintaining a full mesh among themselves. When a router in one sub-AS sends a route to a router in another sub-AS, the communication uses a mechanism similar to External BGP (EBGP).

However, several important differences exist. The next hop, AS_PATH, and MED (Multi-Exit Discriminator) attributes are preserved across sub-AS boundaries, unlike standard EBGP. The AS_PATH is prepended with the confederation AS numbers, but these are enclosed in special brackets (e.

g., [64510 64520]) and are removed before the route is advertised to external EBGP peers. This ensures that external networks see only the global AS number, not the internal confederation structure.

BGP Confederations require that all sub-AS numbers are from the private AS range (64512 to 65534) to avoid conflict with public AS numbers. Configuration involves enabling the BGP confederation identifier (the global AS number) and listing the member sub-AS numbers under the BGP process. Additionally, the peering between sub-AS uses the update-source and ebgp-multihop commands if routers are not directly connected.

The BGP confederation peer is defined using the neighbor command with the sub-AS number, not the global AS. Confederations are considered an alternative to Route Reflectors, another IBGP scaling technique. While Route Reflectors are more common in modern networks, Confederations offer better control over routing policy and can be combined with Route Reflectors for even greater scalability.

Real implementations are found in large ISP backbones and multi-tenant data centers where administrative domains must be segmented but still appear unified externally. Understanding BGP Confederations is essential for CCNP and CCIE candidates, as Cisco exams test the configuration, behaviour, and troubleshooting of confederation scenarios.

BGP Confederations matter because they solve a real scalability problem in large networks. In any network with more than a handful of routers, the requirement for a full mesh of IBGP sessions becomes a massive administrative and resource burden. Each router must maintain a TCP session with every other router in the AS, which consumes CPU, memory, and bandwidth.

With hundreds of routers, the number of sessions can reach thousands, making configuration error-prone and troubleshooting difficult. BGP Confederations break this problem into smaller pieces, allowing network engineers to manage groups of routers independently while maintaining a consistent routing policy across the entire organization. This is particularly important for Internet Service Providers (ISPs) and large enterprises that operate backbone networks spanning multiple geographic regions or administrative domains.

Without confederations or an alternative like Route Reflectors, these networks would be unmanageable. Confederations also provide finer control over routing policy because each sub-AS can implement its own local policies, such as route filtering or preference adjustments, before passing routes to the larger confederation. This flexibility is valuable in multi-tenant environments, data centers, and cloud infrastructure where different departments or customers require distinct routing behaviour but must still appear as a single network to the outside.

From a career perspective, understanding BGP Confederations distinguishes a junior network engineer from a senior architect. Many enterprises still use confederations in legacy designs, and knowing how to configure, troubleshoot, and migrate them is a sought-after skill. For anyone pursuing Cisco certifications, particularly CCNP Enterprise or CCIE, confederations are a core topic that demonstrates deep knowledge of BGP internals.

In summary, this concept matters because it directly impacts the stability, scalability, and manageability of real-world routing infrastructures.

In certification exams, BGP Confederations appear in several distinct question patterns. The first is conceptual multiple-choice questions that test your understanding of why confederations are used. For instance, a question might ask: Which BGP scalability technique divides an AS into smaller sub-AS numbers?

The correct answer is BGP Confederations, while distractors might include Route Reflectors, Communities, or Prefix Lists. Another common pattern asks about the difference between confederations and Route Reflectors. You might be given a scenario with network metrics and asked which technique preserves the NEXT_HOP attribute unchanged across sub-AS boundaries.

The answer is confederations, because confederation EBGP does not modify the next hop, whereas Route Reflectors do. Configuration questions expect you to identify the correct commands. For example: Which command is used to define the global AS number in a BGP confederation?

The answer is bgp confederation identifier 65000. You might also see a fill-in-the-blank or drag-and-drop question asking you to order the steps for configuring a confederation. Troubleshooting questions are common and often involve a network diagram.

A typical scenario: R1 in sub-AS 64510 is not learning routes from R3 in sub-AS 64520. The question provides partial show ip bgp output and asks for the root cause. Possible answers include missing neighbor command under BGP, incorrect sub-AS number in the neighbor statement, or missing bgp confederation peers list.

Another pattern tests your ability to interpret the AS_PATH output. You might see show ip bgp output showing AS_PATH [64510 64520] 100 and be asked which AS numbers are confederation sub-AS numbers versus global AS numbers. The correct interpretation is that values inside brackets are confederation sub-AS numbers, and values outside are global AS numbers.

Design questions appear in advanced exams, where you must choose the best scalability solution given network requirements. For example, a question may describe a large ISP with multiple regional divisions that each require independent routing policies but must appear as one AS externally. The best answer would be BGP Confederations, not Route Reflectors, because confederations allow policy control per sub-AS.

Finally, there are comparison questions: How does confederation EBGP differ from standard EBGP? Key points include: confederation EBGP does not change next hop, does not reset TTL to 1, and preserves MED, while standard EBGP does the opposite. Mastering these question patterns helps you tackle any BGP confederation problem on the exam.

BGP Confederations are one of the two main methods for scaling IBGP in a large autonomous system, the other being Route Reflectors. In practice, network professionals must evaluate which method best fits their operational needs. Confucian wisdom says, 'choose the right tool for the job.'

Route Reflectors are easier to configure and are the default choice in many modern networks, especially when traffic engineering is not complex. However, confederations offer superior policy control because each sub-AS can have its own routing policies, such as different route redistribution rules, prefix filters, or local preference settings. This is particularly useful in service provider environments where different regions or business units require autonomy.

For instance, a global ISP might have separate sub-AS for North America, Europe, and Asia, each with distinct peering agreements and customer requirements. To configure a confederation, start with the global AS number using the bgp confederation identifier command. Then list all member sub-AS using bgp confederation peers.

Each router must be in one sub-AS, and within that sub-AS, IBGP full mesh is required. Peering between sub-AS uses the same neighbor commands but with the remote sub-AS number. A common mistake is forgetting to include the neighbor ebgp-multihop command when the peer routers are multiple hops away.

Since confederation EBGP does not set TTL to 1 by default, this command is needed for non-directly connected peers. Another practical consideration is the interaction with BGP attributes. As mentioned, NEXT_HOP is preserved, which can cause issues if routers in one sub-AS do not have a route to the next hop interface in another sub-AS.

This is often solved by ensuring that the underlying IGP (like OSPF or IS-IS) has routes to all loopback addresses used for peering. The AS_PATH attribute includes the sub-AS numbers in brackets, which are stripped before advertising to external EBGP peers. This is important for loop prevention within the confederation.

From a troubleshooting perspective, the show ip bgp command is your best friend. Look for the brackets in the AS_PATH column. If you see numbers without brackets, the confederation peer list might be missing or configured incorrectly.

Also verify that the BGP session state is 'Established' using show ip bgp summary. If a session is stuck in 'Active', check the reachability and the remote-as configuration. In a lab environment, you can practice by setting up three routers with two sub-AS, configure confederation, and observe how routes propagate.

Try to add a Route Reflector inside a sub-AS to see how both technologies can coexist. This combination is advanced but appears in CCIE labs. The key takeaway is that confederations give you scalability plus policy granularity, but they require more careful planning and configuration than Route Reflectors.

Mastery of confederations demonstrates a solid understanding of BGP internals and network design principles.