skip to content

How does a BGP confederation (RFC 5065) remove the iBGP full mesh, and when would you choose one over route reflectors?

level: seniorimportance: nice to knowfreq 10%

answer

  1. split one AS into several
  2. eBGP-like sessions between members
  3. AS_CONFED_SEQUENCE for loop detection
  4. outsiders see one AS
  5. every member must support it

basics

~20 s

A confederation splits one AS into member-ASes, each internally meshed, joined by eBGP-like sessions that record member-AS numbers in AS_CONFED_SEQUENCE. Outsiders see one AS. Reflectors deploy more gradually; confederations add policy boundaries and per-member IGPs.

solid answer

~50 s

RFC 5065 (obsoleting RFC 3065) divides the AS into **member-ASes**. Inside each member, ordinary iBGP runs, as a full mesh or with reflectors; between members, sessions behave like eBGP, so the no-relay rule does not apply across them. Loop detection comes back through `AS_CONFED_SEQUENCE` (segment type 3) and `AS_CONFED_SET` (type 4) segments of `AS_PATH`, holding member-AS numbers. Toward the outside, those segments MUST be removed and the externally visible **confederation identifier** is used instead, so neighbours see one AS. Inside, `NEXT_HOP` and `MED` may cross members unchanged, `LOCAL_PREF` may be sent, and confederation segments are not counted in path length. Reflectors suit most growth: they deploy gradually and clients need no support. A confederation, which every router in it must support, fits when the AS really is several domains, such as merged networks or separate IGPs.

go deeper

for a junior

Know that a confederation splits one large AS into smaller internal ASes while the outside world still sees a single AS number.

for a middle

Explain how member-AS numbers in AS_CONFED_SEQUENCE restore loop detection and why that removes the need for one AS-wide mesh, with the session count before and after.

for a senior

Describe what crosses member boundaries unchanged, what is stripped at the edge, and the operational costs: full support everywhere, duplicate routes, MED oscillation.

for a principal

Choose between reflectors and a confederation for an AS that is growing or merging, weighing migration disruption, policy boundaries and IGP separation against path visibility.

## The idea The iBGP full mesh is quadratic because base BGP forbids relaying routes between internal peers. A **confederation** (RFC 5065, which obsoletes RFC 3065) sidesteps the rule by making most of those peers no longer internal to one another. The AS is split into **member-ASes**; between members the sessions follow eBGP's relay rules, so routes flow across them without a full mesh. Terms from RFC 5065 section 1.2: - **AS confederation identifier**: the externally visible AS number, say AS 64500. - **Member-AS number**: visible only inside the confederation. Operators commonly draw these from the private range RFC 6996 reserves, for example 64512 to 64514; that is a practice, not an RFC 5065 requirement. ## The arithmetic for 30 routers Split AS 64500's 30 BGP speakers into three member-ASes of 10. Each member keeps a full mesh internally: 10 x 9 / 2 = **45** sessions, so 135 in all. Add one confederation session between each pair of members, three more: **138** sessions instead of 435. Running reflectors inside each member reduces it further; the two techniques combine. ## What happens to a route RFC 5065 sections 4 and 5 replace parts of RFC 4271: 1. **Inside a member-AS**, `AS_PATH` is not modified, exactly as in iBGP. 2. **To a neighbouring member-AS**, the speaker prepends its member-AS number in an `AS_CONFED_SEQUENCE` segment (type 3); `AS_CONFED_SET` (type 4) is the unordered counterpart, as `AS_SET` is to `AS_SEQUENCE`. A speaker that finds its own member-AS number there treats the route like one containing its own AS: a loop. 3. **To a peer outside the confederation**, confederation segments **MUST be removed**, and the confederation identifier is prepended as an ordinary `AS_SEQUENCE` entry. Sending confederation segments outside is forbidden; receiving them from outside is treated as a malformed `AS_PATH`. Inside the confederation, routes keep iBGP behaviour where it matters: - `NEXT_HOP` and `MED` may be advertised unchanged to a neighbouring member-AS (section 5.2). - The ban on sending `LOCAL_PREF` to another AS is lifted for member-ASes, so the whole confederation can share one exit preference. - Confederation segments SHOULD NOT be counted when comparing `AS_PATH` length, and a route from anywhere in the confederation counts as internal when eBGP and iBGP routes are compared. ## Confederation or route reflectors? | | Route reflectors (RFC 4456) | Confederation (RFC 5065) | |---|---|---| | Who must support it | the reflectors only | every router in the confederation | | Migration | gradual, one cluster at a time | re-number every router into a member-AS | | Loop detection | `ORIGINATOR_ID`, `CLUSTER_LIST` | member-ASes in `AS_CONFED_SEQUENCE` | | Internal policy boundaries | none | at each member-AS edge | | Separate IGPs per part | not a natural fit | allowed; `NEXT_HOP` may then need policy | | Path visibility | reflectors may hide paths | each member still meshes internally | Reflectors are the usual first choice for scale: clients are ordinary speakers, and RFC 4456 lets reflection be introduced one cluster at a time. A confederation earns its migration cost when the AS is genuinely several domains: - two networks merged under one external AS number, each keeping its own IGP and operations; - regions that want eBGP-style policy control at their boundaries; - a design where every router already supports confederations and the member boundaries match the topology. ## Costs to plan for - RFC 5065 section 6: all members MUST support confederations; a speaker that does not will reject the confederation segments as a malformed `AS_PATH`. - Section 7 warns that misconfiguration can duplicate routes inside the confederation, and that confederations, like reflectors, can cause persistent route oscillation with some MED and tie-breaking choices. - Member-AS numbers appear in internal paths, so troubleshooting needs familiarity with both numbering layers. ## Common misreadings - A confederation does not remove iBGP: each member-AS still needs a full mesh or reflectors inside it. - Sessions between member-ASes look like eBGP for relaying and `AS_PATH`, yet `NEXT_HOP`, `MED` and `LOCAL_PREF` can pass through them unchanged, so they are not ordinary eBGP sessions. - Neighbours outside cannot tell a confederation from a single AS; nothing about it is visible in the paths they receive.

  • A route crosses three member-ASes inside a confederation and then leaves it. What AS_PATH does the external neighbour see?
    The `AS_CONFED_SEQUENCE` holding the three member-AS numbers is removed at the edge, and the confederation identifier, say 64500, is prepended once as an ordinary `AS_SEQUENCE` entry. The neighbour sees the path as if it had crossed one AS. RFC 5065 forbids sending confederation segments outside.
  • Can you run route reflectors inside a member-AS of a confederation?
    Yes. Each member-AS is ordinary iBGP internally, so it can use a full mesh or reflectors. Large networks sometimes combine the two: confederation boundaries for policy or IGP separation, reflectors inside each member to avoid a mesh of its own.

saying these in an interview costs you the question

  • External neighbours see every member-AS number in the AS_PATH
  • Member-ASes need no iBGP inside them because confederation sessions replace it
  • Each member-AS hop adds one to AS_PATH length in best-path comparison
  • Only the confederation's border routers need to support confederations
  • LOCAL_PREF is lost at every member-AS boundary, as on eBGP