Route reflectors and confederations

Theoretical foundations and architecture

To eliminate the n-squared scaling bottleneck of iBGP Full Mesh, service providers implement BGP Route Reflectors (RR, RFC 4456) or Confederations (RFC 5065). A Route Reflector relaxes the standard iBGP Split Horizon rule: when configured as an RR, it is permitted to reflect routes learned from one iBGP client to other clients and non-client peers. PE routers act as RR clients and peer exclusively with redundant Route Reflectors (RR1 and RR2), collapsing session complexity from quadratic N*(N-1)/2 to linear 2*N. Loop prevention is strictly maintained through two non-transitive BGP attributes: ORIGINATOR_ID (the Router-ID of the ingress PE that originated the update; if a router receives an update bearing its own ID, it discards it) and CLUSTER_LIST (an ordered sequence of Cluster-IDs traversed by the update; an RR drops any update containing its local Cluster-ID). Redundant RRs are typically configured in a shared Cluster-ID architecture.

Reflection rules (RFC 4456)

A Route Reflector relaxes the iBGP split horizon. A client is an iBGP neighbor for which the RR is configured as a reflector; all other iBGP neighbors of the RR are non-clients. The client knows nothing about its role: route-reflector-client (Cisco), reflect-client (Huawei) or cluster in the group (Junos) are configured only on the RR. The rules for distributing the best path:

The RR reflects only the best path, chosen from its own table. As a result clients see not all paths but exactly what the RR selected, and the RR does not change the next hop of reflected routes (next-hop-self on the RR is normally not needed for clients and by default does not apply to reflected routes).

ORIGINATOR_ID and CLUSTER_LIST

Two optional non-transitive attributes protect against reflection loops:

• ORIGINATOR_ID (type 9, 4 bytes): the router-id of the router inside the AS that first injected the route into iBGP. The first RR sets it when reflecting. If a PE receives a route with its own ORIGINATOR_ID, it discards it.
• CLUSTER_LIST (type 10): a sequence of 4-byte Cluster-IDs. Each RR prepends its own Cluster-ID when reflecting; an RR that sees its own Cluster-ID in the list discards the route.

Both attributes are meaningful only inside the AS and are not sent to eBGP. In path selection (after router-id) the ORIGINATOR_ID is compared instead of the router-id, then the shortest CLUSTER_LIST, and only then the neighbor address. The Cluster-ID defaults to the router-id of the RR; Cisco bgp cluster-id 100 and Junos cluster 0.0.0.100 are the same number 100 in decimal and dotted form.

Cluster-ID: shared or different on an RR pair

A backup RR2 is built in one of two ways:

• The same Cluster-ID on RR1 and RR2 (both serve one cluster): RR2 discards a route reflected by RR1 when it receives it, because it sees its own Cluster-ID. This saves memory (fewer paths on clients and RRs), but every client must have sessions with both RRs. If a client is connected only to RR1 and RR1 fails, the client is isolated.
• Different Cluster-IDs (RR1 and RR2 are clients or non-clients of each other inside a top-level mesh): every client receives paths from both RRs, and convergence after the failure of one RR is faster and independent. The price: twice as many paths and more memory on RRs and PEs.

Sessions with two RRs and N clients: 2*N plus the session between the RRs, against N*(N-1)/2 in a full mesh (100 PEs: 201 against 4950).

Design: where to place the RR

The RR works in the control plane and does not have to sit in the traffic path (out-of-path): so it can be a dedicated virtual or separate router that does not carry forwarding load. It is enough to have IGP and LDP reachability between the RR and the PEs so that the clients' next hops resolve. Large networks build a hierarchy: regional RRs are clients of central RRs. RR limitations: it sees the topology from the point of view of its own IGP, so it selects the best path by the metric to the next hop from the RR, not from the client (the hot potato problem), which can lead to suboptimal exits. Solutions: place an RR in every zone, Optimal Route Reflection (RFC 9107), BGP add-path (RFC 7911) to carry several paths, and best-external on the PEs. For VPN (VPNv4) the RR additionally does not import VRFs and stores all routes without RT filtering unless RT-constrained distribution is enabled.

Confederation (RFC 5065)

An alternative to RR: the AS is divided into sub-ASes (private numbers 65001, 65002), each sub-AS needs a full mesh or an RR inside, and between sub-ASes an "almost eBGP" runs. The outside world sees a single confederation identifier 65000. What changes:

• The AS_PATH contains AS_CONFED_SEQUENCE (type 3) and AS_CONFED_SET (type 4) segments. They are not counted when comparing AS_PATH length (on Cisco bgp bestpath as-path confed enables counting) and are removed when leaving the confederation.
• Between sub-ASes NEXT_HOP, LOCAL_PREF and MED are preserved, as in iBGP, so the policy stays uniform across the whole AS.
• Loops are caught by AS_CONFED_SEQUENCE: if the local sub-AS is already in the path, the route is discarded.
• A session between sub-ASes is eBGP with TTL 1: for peering on loopbacks ebgp-multihop 2 is needed (Huawei ebgp-max-hop, Junos multihop ttl).

A mistake in bgp confederation peers or in the identifier produces a session that looks like eBGP to another AS rather than an internal part of the confederation.

RR versus confederation

The two mechanisms can be combined: put an RR inside a sub-AS (as in this lesson's configuration).