By design, iBGP requires a full mesh of peerings between all routers so every router can learn routes from all other routers without loops. Prefixes learned from an iBGP peer are not advertised to another iBGP peer. This rule exists to prevent routing loops inside the autonomous system, and it is also the main reason why a full mesh is required. As the number of routers grows, maintaining this full mesh becomes complex and resource-heavy.
BGP confederations are one way to solve the scaling problems created by the BGP full mesh requirement. Another common approach is using Route Reflectors. BGP confederations break up a large autonomous system into smaller subautonomous systems (sub-ASs), reducing the number of iBGP peerings required.
Suresh Vinasiththamby
Routers within the same sub-AS still need a full iBGP mesh, but the number of peerings is much smaller now. Connections to other confederations are made with standard eBGP, and peers outside the sub-AS are treated as external.
The confederation AS appears whole to other confederation ASs, and the sub-AS numbers are removed when the route is advertised out of the confederation AS. To avoid routing loops, a sub-AS uses a confederation sequence, which operates like an AS path but uses only the privately assigned sub-AS numbers.
BGP Confederation Example
Let’s look at an example. In this diagram, we have five routers inside a single autonomous system 200. If we were to use plain iBGP, every router would need to peer with every other router. With five routers, that means 10 separate iBGP peerings. This quickly becomes hard to manage as the network grows.
By using a BGP confederation, we can split the AS into smaller sub-ASes. In this case, the routers are divided into two sub-ASes. 201 and 202. Routers inside the same sub-AS still form a full iBGP mesh, but there are fewer routers, so fewer peerings are required. Between the sub-ASes, the routers use eBGP confederation peerings.
To someone external to our AS, AS 100 in this example, the whole confederation is hidden. Even though we are internally using sub-AS numbers like 201 and 202, those are only used inside our AS.
When routes are advertised to an external peer, the sub-AS numbers are stripped out and replaced with the confederation identifier. So from the outside, AS 100 only ever sees AS 200 in the AS path.
Netlab Topology File
I covered Netlab in depth in my previous posts, which I’ve linked below. You can recreate the entire lab used in this example using netlab with a single command. I’ve attached the topology file here so you can follow along or build the lab yourself.
Suresh Vinasiththamby
Suresh Vinasiththamby
BGP Confederation Configuration
Next, let’s look at the configuration, and you will see it looks almost identical to a normal BGP config, with just a few small differences.
At a high level, you still define the BGP process, configure neighbors, and exchange routes the same way you would with iBGP or eBGP. The main changes are the addition of the confederation identifier and the sub-AS number. Once those are in place, the rest of the configuration should feel very familiar.
IP Schema
Let’s look at the IP schema used in this lab. Each router has a loopback address from the 10.0.0.x range. These loopbacks are used for router IDs. In this example, p1 uses 10.0.0.11, r1 uses 10.0.0.1, r2 uses 10.0.0.2, r3 uses 10.0.0.3, and so on.
All point-to-point links are taken from the 172.16.1.0/24 range. Each link is assigned a /30 subnet. For example, the link between r1 and r2 uses 172.16.1.4/30, the link between r2 and r3 uses 172.16.1.8/30, and the other links follow the same pattern.
p1 config
From p1’s perspective, this is just a standard eBGP session toward r1. It is peering with remote AS 200, advertising its local prefix, and nothing in the configuration suggests that a confederation is being used on the other side.
p1#show run | sec bgp
router bgp 100
bgp router-id 10.0.0.11
neighbor 172.16.1.2 remote-as 200
neighbor 172.16.1.2 description r1
!
address-family ipv4
network 100.10.10.0 mask 255.255.255.0
neighbor 172.16.1.2 activateNeighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
172.16.1.2 4 200 33 34 2 0 0 00:27:01 0r1 config
On r1, we can see three types of BGP peerings. First, r1 peers with r2 and r3 using iBGP within sub-AS 201. These sessions use loopback addresses and an update source of Loopback0, which is typical for internal BGP peerings. Since r1, r2, and r3 are in the same sub AS, these are standard iBGP sessions.
r1#show run | sec bgp
router bgp 201
bgp router-id 10.0.0.1
bgp confederation identifier 200
bgp confederation peers 202
neighbor 10.0.0.2 remote-as 201
neighbor 10.0.0.2 description r2
neighbor 10.0.0.2 update-source Loopback0
neighbor 10.0.0.3 remote-as 201
neighbor 10.0.0.3 description r3
neighbor 10.0.0.3 update-source Loopback0
neighbor 172.16.1.1 remote-as 100
neighbor 172.16.1.1 description p1
neighbor 172.16.1.18 remote-as 202
neighbor 172.16.1.18 description r4
!
address-family ipv4
bgp scan-time 5
neighbor 10.0.0.2 activate
neighbor 10.0.0.2 next-hop-self
neighbor 10.0.0.3 activate
neighbor 10.0.0.3 next-hop-self
neighbor 172.16.1.1 activate
neighbor 172.16.1.18 activate
neighbor 172.16.1.18 next-hop-self allNext, r1 peers with p1 using eBGP. This is the external BGP session toward AS 100. From r1’s point of view, this looks like a normal eBGP session and is not treated as part of the confederation logic.
Finally, r1 peers with r4 in sub-AS 202. This session is an eBGP confederation peering. Even though it uses eBGP behavior, it is still internal to the overall AS 200.
The bgp confederation identifier 200 defines the public AS number that external peers will see. The bgp confederation peers 202 command tells r1 which other sub-AS numbers belong to the same confederation.
r1#show ip bgp summary
BGP router identifier 10.0.0.1, local AS number 201
BGP activity 1/0 prefixes, 1/0 paths, scan interval 5 secs
1 networks peaked at 13:21:03 Dec 27 2025 UTC (00:54:58.965 ago)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.2 4 201 64 65 2 0 0 00:55:04 0
10.0.0.3 4 201 65 65 2 0 0 00:55:03 0
172.16.1.1 4 100 65 64 2 0 0 00:55:03 1
172.16.1.18 4 202 63 64 2 0 0 00:54:59 0r4 config
On r4, the config is very similar, but from the perspective of sub AS 202. r4 runs BGP in AS 202 and defines 200 as the confederation identifier.
r4 has an iBGP peering with r5 inside sub AS 202 using loopback addresses. It also has an eBGP confederation peering with r1 in sub AS 201. The bgp confederation peers 201 line tells r4 that AS 201 is part of the same confederation.
r4#show run | sec bgp
router bgp 202
bgp router-id 10.0.0.4
bgp confederation identifier 200
bgp confederation peers 201
neighbor 10.0.0.5 remote-as 202
neighbor 10.0.0.5 description r5
neighbor 10.0.0.5 update-source Loopback0
neighbor 172.16.1.17 remote-as 201
neighbor 172.16.1.17 description r1
!
address-family ipv4
bgp scan-time 5
neighbor 10.0.0.5 activate
neighbor 10.0.0.5 next-hop-self
neighbor 172.16.1.17 activate
neighbor 172.16.1.17 next-hop-self allr4#show ip bgp summary
BGP router identifier 10.0.0.4, local AS number 202
1 networks peaked at 13:21:03 Dec 27 2025 UTC (00:57:46.363 ago)
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.5 4 202 68 68 2 0 0 00:57:48 1
172.16.1.17 4 201 67 66 2 0 0 00:57:46 1On r4, when you look at the BGP table, the AS path shows (201) 100. The bracketed AS number means the route passed through a sub AS inside the confederation. In this case, the prefix originates in AS 100 and is learned via sub AS 201 before reaching r4.
r4#show ip bgp
BGP table version is 2, local router ID is 10.0.0.4
Network Next Hop Metric LocPrf Weight Path
* i 100.10.10.0/24 10.0.0.5 0 100 0 (201) 100 i
*> 172.16.1.17 0 100 0 (201) 100 iconfed-internal vs confed-external
If you look at the paths for this prefix above on r4, you can see two options. One path is marked as confed-internal and the other as confed-external. The confed-internal path is learnt from r5 within the same sub-AS. The confed-external path is learned from r1 in a different sub-AS, using a confederation eBGP peering. The output shows both paths for the prefix and how BGP classifies them inside the confederation.
r4#show ip bgp 100.10.10.0/24
BGP routing table entry for 100.10.10.0/24, version 2
Paths: (2 available, best #2, table default)
Advertised to update-groups:
1
Refresh Epoch 1
(201) 100
10.0.0.5 (metric 11) from 10.0.0.5 (10.0.0.5)
Origin IGP, metric 0, localpref 100, valid, confed-internal
rx pathid: 0, tx pathid: 0
Updated on Dec 27 2025 13:21:06 UTC
Refresh Epoch 1
(201) 100
172.16.1.17 from 172.16.1.17 (10.0.0.1)
Origin IGP, metric 0, localpref 100, valid, confed-external, best
rx pathid: 0, tx pathid: 0x0
Updated on Dec 27 2025 13:21:03 UTCIt is interesting that the path marked as confed-external is selected as the best path, but this is not because it is confed-external. According to Cisco's documentation and community discussion, the confed-internal or confed-external state is not used in the BGP path selection process.
AS_CONFED_SEQUENCE and AS_CONFED_SET are local to the confederation. Therefore, these paths are treated as internal paths. There is no distinction between Confederation External and Confederation Internal.References
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
https://community.cisco.com/t5/routing/bgp-confederation-and-path-selection/td-p/1528607
