BGP Route Reflection - An Alternative to Full Mesh IBGP
obsoleted by
- rfc-4456 — BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)
updates
- rfc-1966 — BGP Route Reflection An alternative to full mesh IBGP
Extracted elements (21)
Route reflection topology should be congruent with the physical network topology when multiple paths exist for a prefix, to prevent routing loops and maintain consistent routing views. POP-based reflection (each POP has its own fully-meshed RRs) is a commonly used approach.
Route Reflection was designed to satisfy three criteria: simplicity (easy to configure and understand), easy transition (no topology or AS changes required), and compatibility (non-compliant IBGP peers can continue operating without loss of routing information). These criteria were motivated by operational experience with large, topology-rich networks.
The BGP protocol provides no mechanism for a Client to dynamically identify itself as a Client of an RR; the simplest approach is manual configuration. The RR summarizes routing information and reflects only its best path, which is a key component in addressing the scaling issue.
The CLUSTER_LIST prepend order was changed from RFC 1966's 'append' to 'prepend' to reflect actual deployed code behavior. This correction was a key change in this revision.
The full mesh IBGP requirement requires n*(n-1)/2 unique IBGP sessions for n BGP speakers, which does not scale for large networks. Route Reflection allows a Route Reflector to re-advertise IBGP-learned routes to other IBGP peers, eliminating the need for full mesh.
With certain route reflection topologies, the route selection result may differ from full IBGP mesh because MEDs are not always comparable and IGP metrics may differ per router. Mitigation strategies include configuring intra-cluster IGP metrics better than inter-cluster, using LOCAL_PREF to reflect MED values, or using community-based policies.
Conventional BGP speakers that do not understand Route Reflectors can co-exist in the same AS as either members of a Non-Client group or a Client group, enabling easy and gradual migration from full mesh IBGP to the Route Reflection model.
This document updates RFC 1966 with clarifications on terminology, loop handling, CLUSTER_ID prepend vs append order, and expanded deployment considerations. References to EBGP routes/peers were removed.
A BGP speaker SHOULD NOT create an ORIGINATOR_ID attribute if one already exists in the route being reflected.
A router which recognizes the ORIGINATOR_ID attribute SHOULD ignore a route received with its own ROUTER_ID as the ORIGINATOR_ID, to prevent routing loops.
Care should be taken to ensure that none of the BGP path attributes (ORIGINATOR_ID, CLUSTER_LIST) can be modified through configuration when exchanging internal routing information between RRs and Clients and Non-Clients, as modification could result in routing loops.
If the local CLUSTER_ID is found in the CLUSTER_LIST of a received advertisement, the advertisement SHOULD be ignored to prevent routing loops caused by misconfiguration.
When a RR reflects a route, it MUST prepend the local CLUSTER_ID to the CLUSTER_LIST. If the CLUSTER_LIST is empty, it must create a new one.
When a RR reflects a route, it should not modify the following path attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED, as their modification could potentially result in routing loops.
A cluster is identified by the ROUTER_ID of the single RR when only one RR exists. To support multiple RRs in the same cluster (for redundancy), all RRs in the cluster are configured with the same 4-byte CLUSTER_ID.
A Route Reflector (RR) divides its internal peers into two groups: Client Peers and Non-Client Peers. A RR along with its client peers forms a Cluster. Non-Client peers must be fully meshed, but Client peers need not be.
CLUSTER_LIST is a new optional, non-transitive BGP attribute of Type code 10, encoded as a sequence of 4-byte CLUSTER_ID values representing the reflection path the route has traversed. The Length field specifies the number of octets.
ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type code 9, 4 bytes long, created by a RR when reflecting a route. It carries the ROUTER_ID of the originator of the route in the local AS.
When a RR receives a route from a Non-Client IBGP peer and selects it as best path, it reflects the route to all Client peers only. When received from a Client peer, it reflects to all Non-Client peers and all Client peers.
This extension to BGP does not change the underlying security issues inherent in the existing IBGP; the security properties are the same as baseline IBGP as described in RFC 2385 (TCP MD5 Signature Option).
CLUSTER_LIST is encoded with Attr. Flags (1 byte), Attr. Type Code (1 byte), Length (1 byte indicating number of octets), followed by a sequence of 4-byte CLUSTER_ID values.