RFC 5065 defines BGP confederations, this RFC seperates each router within an AS into one of several BGP subautonomous systems. Peers inside the same sub-AS are considered to be confederation iBGP peers, routers in different sub-AS systems are considered to be confederation eBGP peers.
Confederations propagate routes to all routers without a full mesh of peers inside the entire AS. eBGP peer connections act like true eBGP peers within a confederation. All routes within each sub-AS need to be advertised to all other sub-AS’s.
Since these routers act like eBGP peers even though these are all routes that are within the same parent AS and would normally be considered internal.
Loop avoidance is handled the same using AS_CONFED_SEQ and AS_CONFED_SET. Befoer the router can advertise an iBGP route to another sub-AS, the router must make sure that the destination sub-AS is not already in the AS_PATH AS_CONFED_SEQ segment.
- Inside a sub-AS, full mesh is required because full iBGP rules are in effect
- The confederation eBGP connections act like normal eBGP connections in that iBGP routes are advertised as lon as the AS_PATH implies there is no loop
- Confederation eBGP connections also act like normal eBGP connections regarding TTL.
- Confederation eBGP connections act like iBGP connections in every other regard
- Confederation ASNs are not considered part of the length of the AS_PATH when a router chooses the best route based on shortest AS_PATH
- Confederation routers remove the confederation ASNs from the AS_PATH in updates sent outside of the confederation so other routers do not know that a confederation was used.