route reflector

An iBGP speaker allowed to pass routes learned from one internal peer on to others, so the AS needs no full mesh.

Route reflection, RFC 4456 (April 2006), is the alternative to the full mesh of internal BGP sessions, which needs n(n-1)/2 sessions for n speakers. The reader meets it in iBGP designs and in route details, where the ORIGINATOR_ID and CLUSTER_LIST attributes mark a route that was reflected.

A route reflector and its client peers form a cluster. The rules are short: a route from a non-client iBGP peer is reflected to all clients; a route from a client is reflected to all non-client peers and to the other clients. Only the non-clients must remain fully meshed; the clients need not be (RFC 4456, sections 5 and 6). It is the exception RFC 4271 itself names in the rule that otherwise forbids passing an internal peer's routes to other internal peers.

Relaxing that rule needs loop guards, so RFC 4456 adds two optional non-transitive attributes, type codes 9 and 10 in the IANA registry. ORIGINATOR_ID carries the BGP Identifier of the route's originator in the local AS, and a router should ignore a route that carries its own identifier there. CLUSTER_LIST records the clusters the route has been reflected through, and a reflector should ignore an advertisement whose list already holds its own CLUSTER_ID.

The gain is the arithmetic of the mesh: ten speakers need 45 iBGP sessions in a full mesh and a hundred need 4,950, while the clients of a reflector need no mesh among themselves. Confederations (RFC 5065) are the other remedy, splitting the AS rather than relaxing the rule.

Also known as: route reflection, bgp route reflector, route reflector client, rr client, bgp route reflection

Sources

← All glossary entries