BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)
obsoletes
- rfc-1966 — BGP Route Reflection An alternative to full mesh IBGP
- rfc-2796 — BGP Route Reflection - An Alternative to Full Mesh IBGP
updated by
- rfc-7606 — Revised Error Handling for BGP UPDATE Messages
Extracted elements (21)
Full-mesh IBGP requires n*(n-1)/2 unique sessions for n speakers, which does not scale at large AS sizes. Route reflection relaxes the rule that IBGP-learned routes cannot be re-advertised to other IBGP peers, designating certain speakers as route reflectors to redistribute routes.
Route reflection was designed to satisfy three criteria: simplicity (easy to configure), easy transition (no topology or AS changes required), and compatibility (non-compliant IBGP peers can coexist without loss of routing information). These criteria were motivated by operational experience in large, topology-rich networks.
The route reflection topology should be congruent with the network topology when multiple paths exist for a prefix, to prevent routing loops and maintain a consistent routing view. The POP-based reflection model (each POP has its own RRs, all RRs fully meshed) is one commonly used approach.
To support redundant RRs within a single cluster without loops, all RRs in the same cluster share a configured 4-byte CLUSTER_ID. This allows each RR to discard routes that have already traversed the cluster by detecting its CLUSTER_ID in the CLUSTER_LIST, without treating the other RRs as foreign clusters.
MEDs and IGP metrics may cause route reflection topologies to produce different route selections than a full IBGP mesh. Route selection equivalence can be preserved by ensuring intra-cluster IGP metrics are better than inter-cluster metrics, or by using LOCAL_PREF to encode MED values, or community-based policies.
RFC 4456 changes the handling of CLUSTER_ID from appending to prepending relative to RFC 1966, to match deployed implementations. Implementations upgrading from RFC 1966 behavior must reverse the order of CLUSTER_ID insertion.
The BGP protocol provides no way for a Client to dynamically identify itself as a Client of an RR; client configuration must be done manually on the RR. Conventional BGP speakers (those unaware of route reflection) can coexist as either Client or Non-Client peers, enabling gradual migration from full-mesh IBGP.
A BGP speaker SHOULD NOT create an ORIGINATOR_ID attribute if one already exists in the reflected route, preserving the original originator's identity.
A BGP speaker SHOULD prefer a route with the shorter CLUSTER_LIST length when performing tie-breaking between Steps f) and g) of the Decision Process. A route without a CLUSTER_LIST attribute is treated as having length zero.
A router that recognizes the ORIGINATOR_ID attribute SHOULD ignore a route received with its own BGP Identifier as the ORIGINATOR_ID, preventing routing loops caused by a reflected route returning to its originator.
If an RR finds its own local CLUSTER_ID in the received CLUSTER_LIST, the advertisement SHOULD be ignored to prevent routing information loops caused by misconfiguration.
In the BGP Decision Process tie-breaking, if a route carries the ORIGINATOR_ID attribute, the ORIGINATOR_ID SHOULD be treated as the BGP Identifier of the advertising speaker in Step f), replacing the use of the actual neighbor's BGP Identifier.
None of the BGP path attributes defined for route reflection (ORIGINATOR_ID, CLUSTER_LIST) should be modifiable through configuration when exchanging internal routing information between RRs, Clients, and Non-Clients, as modification could result in routing loops.
When an RR receives a best path from a Client peer, it MUST reflect that route to all Non-Client peers and also to all other Client peers, eliminating the need for clients to be fully meshed with each other.
When an RR reflects a route, it MUST prepend the local CLUSTER_ID to the CLUSTER_LIST. If the CLUSTER_LIST is empty, the RR MUST create a new one.
When an RR reflects a route, it SHOULD NOT modify the NEXT_HOP, AS_PATH, LOCAL_PREF, or MED path attributes, as modification of these attributes could potentially result in routing loops.
A cluster is the grouping of an RR and its client peers. When a single RR exists in a cluster, the cluster is identified by the BGP Identifier of the RR. When multiple RRs exist in the same cluster, all are configured with a shared 4-byte CLUSTER_ID.
A Route Reflector (RR) is a BGP speaker that advertises IBGP-learned routes to other IBGP peers. An RR divides its internal peers into two groups: Client peers (which need not be fully meshed among themselves) and Non-Client peers (which must be fully meshed). An RR together with its client peers forms a cluster.
The route reflection extension to BGP does not change the underlying security issues inherent in existing IBGP. Security mechanisms such as TCP MD5 signatures (RFC 2385) still apply as before.
CLUSTER_LIST is a new optional, non-transitive BGP path attribute with Type code 10. It is a sequence of CLUSTER_ID values (each 4 bytes) representing the reflection path the route has passed through, used for loop detection.
ORIGINATOR_ID is a new optional, non-transitive BGP path attribute with Type code 9. It is 4 bytes long and carries the BGP Identifier of the originator of the route in the local AS, created by the RR when reflecting a route.