BGP Confederation

Confederation is another solution to the iBGP full-mesh requirement. It is a more comprehensive change than implementing route reflectors to the network because it requires that the BGP process is replaced in the configuration. This poses a problem with BGP because it is kind of the highlander of routing protocols - there can be only one (process defined per router). So, to change the process you cannot really do a smooth transition from one to the other on the same router.

The way confederations work is by dividing an iBGP network into multiple sub-ASes and running eBGP between these sub-ASes. Outside of the confederation, all routers see the same AS, but inside the AS the confederation routers are aware of the confederation configuration due to the use of the AS_CONFED_SEQ and AS_CONFED_SET configured in the AS_PATH PA. These are used much like the regular AS_SEQ and AS_SET, but they are not propagated outside the actual AS.

Below is shown a network topology with AS 100 being the AS external BGP peers will peer with, but inside of AS 100 there are two confederation ASes (sub-AS). Sub-as 65123 with routers R1, R2 and R3 in a fully-meshed iBGP configuration and sub-AS 65045 with routers R4 and R5 with R4 and R3 connecting the two sub-ASes.

BGP Confederation Network Topology

Peerings between R3 and R4 works much like regular eBGP peerings, but because they are confederation peers, the next-hop stays unchanged in updates between them. The routers R5 and R6 are also eBGP peers, but regular eBGP.

Below is the pertinent configuration for R3 and R4.

R3#show running-config | section router bgp
router bgp 65123
 bgp router-id 3.3.3.3
 bgp log-neighbor-changes
 bgp confederation identifier 100
 bgp confederation peers 65045
 neighbor 10.0.12.1 remote-as 65123
 neighbor 10.0.32.2 remote-as 65123
 neighbor 10.0.34.4 remote-as 65045
R4#show running-config | section router bgp
router bgp 65045
 bgp router-id 4.4.4.4
 bgp log-neighbor-changes
 bgp confederation identifier 100
 bgp confederation peers 65123
 neighbor 10.0.34.3 remote-as 65123
 neighbor 10.0.45.5 remote-as 65045

Even though the main AS is 100, the BGP process is configured with the ASN of the sub-AS - this is what makes this so difficult in configuring on production equipment. The main AS is configured using the bgp confederation identifier command. Note that the bgp confederation peers command is only needed on the confederation routers connecting between sub-ASes.

Lets have look at the BGP configuration on R2 for reference.

R2#show running-config | section router bgp
router bgp 65123
 bgp router-id 2.2.2.2
 bgp log-neighbor-changes
 bgp confederation identifier 100
 neighbor 10.0.12.1 remote-as 65123
 neighbor 10.0.23.3 remote-as 65123

Notice that the only confederation command is the bgp confederation identifier command everything else is just iBGP.

The upside of this configuration is, that the BGP routers only need full-mesh peering with routers in the same sub-AS. When you talk large-scale deployments of BGP, this may significantly decrease the amount of configuration as well as control-plane traffic. You can combine the confederations with route reflector configuration as well to make it even more manageable.
But, the downside, is that this is for LARGE deployments and it is in no way an easy task to migrate to a confederation configuration, when a networks grows to a size that could leverage this feature - it is much easier just to configure route reflectors and call it a day.