BGP Route Reflector Dual-Next-Hop Reflection for Path Protection

In traditional BGP Route Reflector (RR) deployments , an RR only selects and propagates its single best path to its clients. While this significantly reduces the IBGP mesh complexity, it inherently hides alternative paths, limiting the clients' ability to perform Equal-Cost Multi-Path (ECMP) or Fast Reroute (FRR). Although extensions like BGP Add-Path solve this by allowing the advertisement of multiple paths for the same prefix, they require both the RR and all receiving clients to support the Add-Path capability negotiation and parsing logic. In many legacy or multi-vendor environments, upgrading all edge clients is operationally challenging. This document proposes a localized, RR-centric behavioral change. When an RR receives a route R1 from Client-1, it generates two distinct routing updates for the same prefix towards Client-2: Path A (Unmodified Next-Hop): The NEXT_HOP attribute remains as Client-1's IP address. Path B (Modified Next-Hop): The NEXT_HOP attribute is altered to the RR's own loopback or interface IP address. Upon receiving these two parallel updates, Client-2 views them as distinct BGP paths and can program them into its forwarding pipeline for load-balancing or active/standby protection.

The following terms are used in this document: RR: Route Reflector. Client-1: The originating BGP client that advertises the baseline route R1. Client-2: The target BGP client intended to receive the dual reflected paths. R1: The original BGP route containing prefix P and NEXT_HOP NH1.

The RR MUST maintain standard BGP route selection processes to determine the best path. When a route R1 for prefix P is received from Client-1 with NEXT_HOP set to IP_C1, and the local outbound policy dictates path-protection for the target Client-2, the RR MUST trigger the dual-reflection processing logic.

The RR MUST construct the first outbound BGP UPDATE message destined to Client-2 following standard procedures: The NEXT_HOP attribute MUST remain unchanged (IP_C1). Standard RR attributes (ORIGINATOR_ID and CLUSTER_LIST) MUST be appended as per [RFC4456].

Simultaneously, the RR MUST construct a second, distinct BGP UPDATE message for the identical prefix P destined to Client-2. To ensure Client-2 accepts this as a separate path rather than an implicit withdrawal/replacement of Update 1, the RR MUST modify its BGP path attributes: The NEXT_HOP attribute MUST be overwritten with the RR's own local BGP Router-ID or a designated Loopback IP address (IP_RR). To prevent Client-2's BGP decision process from immediately dropping this path due to identical tie-breakers, the RR SHOULD manipulate an attribute (e.g., Local_Pref or MED) based on network design requirements: For Load Balancing: Keep Local_Pref identical. For Primary-Backup: Set a lower Local_Pref or higher MED on Update 2 to render the RR-mediated path as the backup. [Optional - Path Differentiator]: If Client-2 does not support receiving duplicate prefixes via different paths under a single session, the RR MAY utilize BGP Add-Path mechanisms strictly on the RR-to-Client-2 session, or send them via separate BGP sessions/families if configured.

Upon receiving both updates, Client-2's local BGP RIB will contain two paths for prefix P.

Traffic steered via Path 1: Enters the network fabric with a data-plane destination IP or transport label pointing directly to Client-1 (bypassing the RR's data plane, if optimal). Traffic steered via Path 2: Enters the network fabric targeting the IP_RR. The RR MUST be capable of line-rate data-plane forwarding to subsequently relay these packets towards Client-1.

If the links or node associated with Client-1 fail: If Client-2 was operating in Primary-Backup mode (Path 1 as Primary, Path 2 as Backup), Client-2 can immediately trigger local repair or switch traffic over to Path 2 (towards RR) while BGP control plane convergence takes place.

This mechanism does not alter the baseline security properties of the BGP protocol. However, changing the next-hop to the RR causes the RR to actively participate in the data-plane forwarding path for a subset of traffic. Network operators MUST ensure that the RR hardware or software platform has sufficient forwarding capacity (throughput and PPS) to handle the redirected backup/load-shared data traffic without introducing data-plane degradation or susceptibility to Denial of Service (DoS) attacks.

This document requires no IANA actions.

The following people made significant contributions to this document:

The authors would like to acknowledge the review and inputs from xxx.