23 Confederations
Confederations are the second method for solving the iBGP full-mesh scalability problem (route reflectors, note 22, are the first). A confederation splits one AS into several smaller sub-AS, so that a full mesh is only needed inside each smaller sub-AS instead of across the entire AS.
The core idea
The full-mesh requirement (note 09) grows as n(n-1)/2 and becomes impractical at scale. A confederation divides the single large AS into multiple sub-AS. Inside each sub-AS a full mesh (or a route reflector) is used, but the number of routers in each sub-AS is small, so the mesh is manageable.
To the outside world, the whole confederation still looks like one single AS. The sub-AS structure is hidden from external peers.
Two AS number concepts
- The confederation AS (also the public/outer AS): the single ASN the confederation presents to the outside world.
- The member sub-AS (private ASN): the smaller ASNs used internally to divide the confederation. These typically use private ASNs and are not visible outside the confederation.
Peering types inside a confederation
Confederations introduce a third kind of session, between sub-AS:
- Intra-confederation iBGP: normal iBGP within a single sub-AS.
- Intra-confederation eBGP (confederation eBGP): between two different sub-AS of the same confederation. This behaves like eBGP in some respects but preserves iBGP attributes.
How attributes behave between sub-AS
Sessions between sub-AS are a special case that keeps important iBGP properties:
- Next-hop, Local Preference, and MED are preserved across sub-AS boundaries (unlike true eBGP, which would strip Local Preference).
- The AS-PATH gains a special segment (the AS_CONFED_SEQUENCE) recording the sub-AS traversed. This segment is used for loop prevention inside the confederation but is removed before the route is advertised outside the confederation, and it is not counted in AS-PATH length comparisons for best-path.
Route Reflectors vs Confederations
Both eliminate the full mesh, and both can even be combined. The high-level trade-off:
| Property | Route Reflectors | Confederations |
|---|---|---|
| Approach | Designate reflectors that re-advertise between iBGP peers | Split the AS into sub-AS |
| Change to topology | Minimal; keeps one AS | Restructures into sub-AS |
| External appearance | One AS | One AS |
| Loop prevention | Originator ID, Cluster List | AS_CONFED_SEQUENCE in AS-PATH |
| Common in practice | More widely deployed | Less common, seen in some large/legacy designs |
Route reflectors are more commonly deployed; confederations appear in some large or legacy networks.
Self-check
Q1 — What does a confederation do to solve the full-mesh problem?
A) It designates reflectors that re-advertise between peers
B) It splits one AS into smaller sub-AS, so full mesh is only needed inside each sub-AS
C) It disables the split-horizon rule globally
D) It raises the TTL between iBGP peers
Respuesta
B is correct. A confederation divides the AS into smaller sub-AS; a manageable full mesh (or RR) is used inside each, while the whole still looks like one AS externally.
- A) False — designating reflectors describes route reflectors, the other method.
- C) False — split-horizon is not simply disabled globally.
- D) False — TTL is unrelated to the confederation mechanism.
Q2 — How does a confederation appear to external peers?
A) As many separate AS
B) As one single AS (the sub-AS structure is hidden)
C) As a route reflector cluster
D) As an IGP domain
Respuesta
B is correct. Externally the whole confederation looks like one AS; the internal sub-AS division is hidden from outside peers.
- A) False — the sub-AS are private and not exposed externally.
- C) False — that is a different mechanism (RR).
- D) False — it is still a BGP AS externally, not an IGP domain.
Q3 — What happens to Local Preference and MED across sub-AS boundaries in a confederation?
A) They are stripped, like true eBGP
B) They are preserved across sub-AS boundaries
C) They are converted into Weight
D) They are reset to defaults
Respuesta
B is correct. Intra-confederation eBGP preserves next-hop, Local Preference, and MED across sub-AS, unlike true eBGP which would strip Local Preference.
- A) False — that is true eBGP behavior, not confederation behavior.
- C) False — they are not converted to Weight.
- D) False — they are preserved, not reset.
Q4 — What provides loop prevention between sub-AS in a confederation?
A) Originator ID and Cluster List
B) The AS_CONFED_SEQUENCE segment in the AS-PATH
C) The synchronization rule
D) Weight
Respuesta
B is correct. A special AS_CONFED_SEQUENCE records the sub-AS traversed for loop prevention; it is removed before the route leaves the confederation and is not counted in AS-PATH length.
- A) False — those are the route reflector loop guards.
- C) False — synchronization is an unrelated legacy IGP rule.
- D) False — Weight is a local best-path attribute, not a loop guard.