BGP Confederations, or “The private AS”

One of the ways to decrease the number of full-mesh iBGP peers in an AS is the use of BGP confederations.  Route Reflectors can also be used (I cover them in IOS and Junos)

Defined in RFC 3065:

A BGP confederation is a group of iBGP speakers that acts as a disparate sub-AS within an organization.  

A good way to envision BGP confederation groups is to  liken their behavior, roughly, to that of private VLANs.  When a group of BGP speakers is segmented into a confederation, the peers act as iBGP speakers of said private AS, and connections to other confederations are done over eBGP.  

This significantly decreases the number of iBGP connections required within the organization.  Additionally the confederations may be viewed as separate administrative entities, reducing the configuration complexity in medium to large organizations.  

Note: IANA defines private AS #s as being the range of 64512 to 65535.

Note 2: Many readers may only be familiar with the 16bit AS space (1-65535) but this was extended in RFC 4893 to a "4 octet number".  Sound familiar?  It should.

Confederations do add complexity to policies dependent upon the AS_PATH attribute, as this field is subject to the standard rules of AS prepending--perhaps mutating the path-vector nature of the BGP routing protocol in a way that may lead to:

• sub-optimal routing decisions, or 
• overly complicated route manipulation.

Within the BGP packet between different confederation AS units, the path segment type of the confederation AS is set to AS_CONFED_SEQ, whereas a standard BGP update via a public AS will be advertised as a AS_SEQUENCE path type.  

The confederation as appears in the BGP table enclosed by parentheses, e.g.: (65421).  Between a confederation AS and a public AS the eBGP connection strips the AS_CONFED_SEQUENCE leaving only the AS path of the:

 NCC1701D(config-router)#bgp confederation identifier [AS]

As with normal iBGP peering, routes shared between the iBGP speakers within a confederation advertise prefixes with a null AS_PATH.  Neighbor confederation prefix advertisement follows the iBGP rule of un-modified next hop addresses.

IOS includes a neighbor statement of remove-private-AS to strip off the private AS #s for outgoing eBGP updates.  Based on lab testing, it appears that this is not necessary for IOS 12.4 peering.

Loop prevention is provided via the standard BGP AS_PATH rules.

Configuration is somewhat counterintuitive.  Assuming a pristine AS, confederations should be created as groups of fully meshed iBGP speakers.  The confederations should be fully connected, however it is not required for confederation border routers to be fully meshed.  They treat inter-confederation peering as eBGP, remember?

Confederation AS numbers should be private, and peering confederation neighbors must have their sub-AS statically defined.  In this IOS example the confederation AS is 65421, the peer confederation is 65422 and the organization's AS is 34.

NCC1701D(config)#router bgp 65421

NCC1701D(config-router)#bgp confederation peer 65422

NCC1701D(config-router)#bgp confederation identifier 34

NCC1701D(config-router)#neighbor 192.168.34.43 remote-as 65421

NCC1701D(config-router)#neighbor 10.0.0.3 remote-as 65422 

NCC1701D(config-router)#network 10.0.0.0 mask 255.0.0.0

NCC1701D(config-router)#network 192.168.34.0 mask 255.255.254.0