BGP RR Deployment Considerations

3.1. Redundancy

BGP RR redundancy enhances network stability by eliminating single points of failure and protecting against RR-level outages. Note, however, that excessive RR redundancy can be detrimental. This is because the more RRs a client (e.g., border router, PE router) peers with, the more IBGP sessions, updates, and paths the client must carry and process in its BGP table. If we consider two RR clusters (1 and 2), as shown in Figure 1, the RR clients (C-2A, C-2B, C-2C) in cluster 2 must process 50% more sessions, updates, and paths compared to cluster 1 clients. For example, if each of the RRs advertised the same 1.5 million (1.5M) routes to the clients, then the BGP tables on cluster 1 clients would carry 3M paths, while the BGP tables on cluster 2 clients would carry 4.5M paths. That is, the incremental overhead of BGP paths, sessions, and updates increases linearly with every redundant RR in the cluster.¶

 +----------------------------+     +-----------------------------+
 |         Cluster 1          |     |          Cluster 2          |
 +----------------------------+     +-----------------------------+
 |                            |     |                             |
 |      RR-1A      RR-1B      |     |   RR-2A    RR-2B    RR-2C   |
 |       /\\       // \       |     |    |\\      /|\      //|    |
 |      /  \ \   / /   \      |     |    | \ \   / | \   / / |    |
 |     /    \  X  /     \     |     |    |  \  \/  |  \/  /  |    |
 |    /      X   X       \    |     |    |   \ / \ | / \ /   |    |
 |    |    /  | |  \     |    |     |    |    X    *    X    |    |
 |    |  /    | |    \   |    |     |    |   / \ / | \ / \   |    |
 |    |/      | |      \ |    |     |    |  /  /\  |  /\  \  |    |
 |    ||      | |       ||    |     |    | / /   \ | /   \ \ |    |
 |    ||      | |       ||    |     |    |//      \|/      \\|    |
 |   C-1A     C-1B     C-1C   |     |   C-2A      C-2B     C-2C   |
 |                            |     |                             |
 +----------------------------+     +-----------------------------+

Further, when a route is no longer available and needs to be withdrawn, an RR client cannot withdraw a route learned from its RRs until it receives a withdrawal from each of the RRs. As a result, increasing the number of redundant RRs could also lead to slower BGP convergence. Again, the incremental overhead of BGP sessions, updates, and paths increases linearly with every redundant RR in the cluster. Hence, for optimal redundancy and scaling, it is suggested that clients peer with at least two redundant RRs, but no more than four total - typically structured as two clusters, each containing a pair of redundant RRs. Also, depending on the network services and scale, different RR clusters may be suggested for different BGP address families. See Section 5 below for more discussion on this topic. Consequently, this general guideline — limiting clients to peering with at most four RRs — applies per BGP address family.¶

3.2. CLUSTER_ID Configuration

Redundant RRs within a cluster are not required to share the same CLUSTER_ID. When redundant RRs within a cluster use different CLUSTER_IDs, they treat each other as non-client IBGP peers, processing and accepting each other’s updates. Conversely, if they share the same CLUSTER_ID, they continue to exchange routes but will ignore reflected routes from one another to avoid routing information loops, as defined in [RFC4456].¶

Consequently, there is no benefit to IBGP peering between redundant RRs sharing a CLUSTER_ID, unless either of the RRs have EBGP sessions or redistribute local IGP, static, or connected routes into BGP. This is because the CLUSTER_ID is not prepended to such non-IBGP learned routes as these are not reflected routes per [RFC4456]. As a result, these non-reflected routes would be exchanged between redundant RRs configured with the same CLUSTER_ID but not discarded.¶

Although using a shared CLUSTER_ID reduces resource consumption and update processing on redundant RRs within a cluster, it can potentially limit resiliency in the event of simultaneous BGP session failures involving multiple RRs and clients within the cluster. Therefore, it is suggested that redundant RRs within a cluster peer with each other using unique CLUSTER_IDs.¶

3.3. Cluster Sizing

In addition to managing the number of redundant RRs per cluster, it's also important to maintain moderate RR cluster sizes (i.e., the number of client sessions per cluster) to limit the blast radius in the event of an RR cluster failure. Accordingly, BGP networks often require multiple RR clusters - not only for fault containment but also for horizontal scaling (sessions, path selection), geo-redundancy, and improved BGP best path selection.¶

4.1. Full Mesh

A full mesh, multi-cluster RR design employs a full IBGP peering mesh between all RRs in all clusters as shown in Figure 2. This is the most common and widely deployed multi-cluster RR design, as it effectively balances scalability and fault isolation while optimizing the distribution of BGP routes and paths within the network. It achieves this by minimizing the number of IBGP hops that updates traverse, which leads to improved BGP performance at scale.¶

               +---------------------------------+
               |            Cluster 1            |
               |   +-------+         +-------+   |
               |   | RR-1A |---------| RR-1B |   |
               |   +-------+         +-------+   |
               +----/-|-\-\-------------/-/-|-\--+
                   /  |  \  \         /  /  |  \
                  /   |   \   \     /   /   |   \
                 /    |    \    \ /    /    |    \
                /     |     \    X    /     |     \
               /      |      \ /   \ /      |      \
              /       |       X     X       |       \
             /        |     /  \   /  \     |        \
            /         |   /     \ /     \   |         \
           /          | /        X        \ |          \
          /           X         / \         X           \
         /          / |        /   \        | \          \
        /         /   |       /     \       |   \         \
       /        /     |      /       \      |     \        \
      /       /       |     /         \     |       \       \
     /      /         |    /           \    |         \      \
+---|-----/-----------|---/---+    +----\---|-----------\-----|--+
|   |    / Cluster 2  |  /    |    |     \  | Cluster 3   \   |  |
| +-------+         +-------+ |    | +-------+         +-------+ |
| | RR-2A |---------| RR-2B |--------| RR-3A |---------| RR-3B | |
| +-------+         +-------+ |    | +-------+         +-------+ |
+---|-|------------------|----+    +----|----------------|--|----+
    | |                  +--------------+                |  |
    | |                  +--------------+----------------+  |
    | +---------------------------------+                   |
    +-------------------------------------------------------+

However, for massive-scale BGP deployments with many RR clusters, the IBGP full mesh between RRs becomes a scalability bottleneck. This is due to high RR session counts and the provisioning complexity involved when adding new RR clusters to the topology. For example, introducing a new RR requires configuring new IBGP sessions on all existing RRs, which increases overhead and BGP session density. This N^2 scaling challenge can also degrade BGP update processing and network convergence, much like a full IBGP mesh between a large number of border routers without RRs.¶

4.2. Multi-Tier

A multi-tier, multi-cluster RR design is a hierarchical architecture involving multiple tiers of RRs, as illustrated in Figure 3. This design is intended for massively large-scale BGP deployments with many RR clusters.¶

                  +-----------------------------+
                  |          Cluster 2A         |
                  | +-----+    Tier 2   +-----+ |
                  | | RR1 |-------------| RR2 | |
                  | +-----+             +-----+ |
                  +----|---\-----------/---|----+
                       |     \       /     |
                       |       \   /       |
                       |         X         |
                       |       /   \       |
                       |     /       \     |
                  +----|---/-----------\---|----+
                  |    | /   Cluster 1A  \ |    |
                  | +-----+    Tier 1   +-----+ |
                  | |RR10 |-------------|RR20 | |
                  | +-----+             +-----+ |
                  +----|---\-----------/---|----+
                       |     \       /     |
                       |       \   /       |
                       |         X         |
                       |       /   \       |
                       |     /       \     |
                  +----|---/-----------\---|----+
                  |    | /   Cluster 1B  \ |    |
                  | +-----+    Tier 1   +-----+ |
                  | |RR30 |-------------|RR40 | |
                  | +-----+ \         / +-----+ |
                  +/---|---\---\---/---/---|---\+
                 /     |     \  / \  /     |     \
               /       |     / \   / \     |       \
             /         |  /      X      \  |         \
           /           X       /   \       X           \
         /          /  |     /       \     |  \          \
       /         /     |   /           \   |     \         \
     /        /        | /               \ |        \        \
+--/-------/-----------X----+         +----X-----------\-------\--+
|+-----+/            +-----+|         |+-----+            \+-----+|
|| RR3 |-------------| RR4 ||         || RR5 |-------------| RR6 ||
|+-----+ Cluster 2B  +-----+|         |+-----+ Cluster 2C  +-----+|
|          Tier 2           |         |          Tier 2           |
+---------------------------+         +---------------------------+

At the lowest level, border routers remain clients of their assigned RR clusters, similar to the full mesh multi-cluster design described above. In this multi-tier model, the RRs peering with border routers are referred to as Tier 2 RRs. Instead of a full IBGP mesh between them, Tier 2 RRs are deployed as clients of Tier 1 RRs, which are themselves fully meshed.¶

While this design reduces IBGP session density on RRs and simplifies their provisioning, it may adversely affect BGP convergence time given the incremental RR hops within the IBGP control plane. Furthermore, a failure of a Tier 1 RR cluster typically results in a large blast radius.¶

4.3. Multi-Plane

A multi-plane, multi-cluster RR design comprises multiple independent RR planes (e.g., RED and BLUE). Within each plane, clusters can be fully meshed or multi-tier as described above. Note that while this document uses a two-plane model for illustration in Figure 4, the architecture is not limited to two planes. As shown in Figure 4, RRs within the RED plane (RR-R1 through RR-R6) are fully meshed as are RRs in the BLUE plane (RR-B1 through RR-B6). In a two-plane design, RR clients (typically border routers) peer with the redundant RRs of one specific cluster in each plane, resulting in four IBGP sessions per client.¶

Multi-plane RR designs can be used in different ways, and each has a different failure behavior. For example, if multi-plane is used for increased redundancy, each plane should carry enough routing information to maintain service if another plane fails. In this deployment model, the failure of one plane should reduce redundancy but not remove required IP reachability. Further, a multi-plane design used for redundancy also facilitates software or hardware upgrades. Because the planes operate independently and provide mutual redundancy, they can be maintained or upgraded separately without disrupting IP reachability.¶

Alternatively, if planes are used for horizontal scaling, different routes or paths may be distributed across different planes. In this deployment model, the failure of one plane may remove the routes or paths carried only by that plane.¶

         +---------------+                   +---------------+
         |   RED plane   |                   |   BLUE plane  |
         |   Cluster R1  |                   |   Cluster B1  |
         |+-----+ +-----+|                   |+-----+ +-----+|
         ||RR-R1|-|RR-R2||                   ||RR-B1|-|RR-B2||
         |+--+--+ +--+--+|                   |+--+--+ +--+--+|
         +---+-------+---+                   +---+-------+---+
             |       |                           |       |
         +---+-------+---+                   +---+-------+---+
         |   Full Mesh   |                   |   Full Mesh   |
         |       or      |                   |       or      |
         |   Multi-Tier  |                   |   Multi-Tier  |
    +----|     within    |----+         +----|     within    |----+
    |    |   RED plane   |    |         |    |   BLUE plane  |    |
    |    +--+---------+--+    |         |    +---+-------+---+    |
    |       |         |       |         |       |         |       |
+---+-------+---+ +---+-------+---+ +---+-------+---+ +---+-------+---+
|+--+--+ +--+--+| |+--+--+ +--+--+| |+--+--+ +--+--+| |+--+--+ +--+--+|
||RR-R3|-|RR-R4|| ||RR-R5|-|RR-R6|| ||RR-B3|-|RR-B4|| ||RR-B5|-|RR-B6||
|+-----+ +-----+| |+-----+ +-----+| |+-----+ +-----+| |+-----+ +-----+|
|   RED plane   | |   RED plane   | |  BLUE plane   | |  BLUE plane   |
|   Cluster R2  | |   Cluster R3  | |  Cluster B2   | |  Cluster B3   |
+---------------+ +---------------+ +---------------+ +---------------+

8.1. Route Distinguisher Assignment

In BGP L3VPN deployments [RFC4364], operators commonly assign distinct Route Distinguishers (RDs) to routes originated by different PEs (Provider Edge routers). EVPN deployments similarly use RDs to distinguish otherwise identical EVPN NLRI originated from different PEs or EVPN instances. Because the RD is part of the NLRI, routes with different RDs are treated as distinct destinations by BGP and are subject to separate best path decisions.¶

Using distinct RDs can preserve multiple VPN or EVPN routes through the RR system without requiring Add-Paths for those distinct NLRI. After import, a receiving PE can evaluate the eligible routes for the corresponding service destination. This can improve route visibility and preserve useful path diversity.¶

A unique RD does not, by itself, guarantee forwarding-path diversity, optimal routing, or load balancing. The resulting behavior also depends on route import policy, NEXT_HOP reachability, path attributes, the client’s best path and multi-path procedures, and the underlying topology. Operators should therefore assign RDs according to the service design and the path diversity that needs to be preserved.¶

RD-based path preservation does not apply to routes in the global routing table carried using IPv4 unicast, IPv6 unicast, or 6PE, because those routes do not use an RD as part of their NLRI.¶

8.2. Add-Paths

Historically, some networks used policy to cause redundant RRs to select and advertise different paths. A client connected to multiple RRs could consequently receive more than one candidate path. This approach depends on deliberate policy differences between RRs and can increase operational complexity.¶

BGP Add-Paths [RFC7911] provides a protocol mechanism for advertising multiple paths for the same NLRI over a BGP session. Depending on the path-selection and advertisement mode implemented and configured, an RR can advertise a best path and one or more additional paths, such as backup, diverse, n-way, or all eligible paths. This reduces the need to rely exclusively on policy differences between redundant RRs to expose multiple paths.¶

When an RR advertises suitable candidate paths, a client can perform best path selection from its own perspective, including the use of its own IGP metrics where applicable. The benefit depends on which paths the RR selects for advertisement. For example, advertising only the RR’s best path and a backup path does not necessarily expose the path that is best from every client’s location.¶

Add-Paths can improve path visibility, convergence, and resilience, and can be used as part of a solution for the route oscillation conditions discussed in [RFC3345] and [RFC7964]. Its use does not, however, guarantee optimal routing or eliminate every form of path hiding or route oscillation.¶

Add-Paths can also increase the number of paths retained, processed, and advertised by BGP speakers. This can increase memory consumption, update generation, policy processing, and convergence workload on both RRs and clients. Operators should select an advertisement mode that provides the required path diversity without distributing unnecessary paths, then validate its impact against the deployment’s scale and convergence objectives.¶

8.3. Optimal Route Reflection

Optimal Route Reflection (ORR) [RFC9107] addresses cases in which the path selected from the RR’s location is not the path that would be preferred from a client’s location. ORR allows an RR to select and advertise a path using an IGP perspective associated with a root client or group of clients rather than the RR’s own IGP location.¶

ORR can reduce IGP metric-based path hiding and allows RRs to be placed independently of the clients for which they select paths. It does not necessarily produce a globally optimal forwarding path, because selection remains subject to the paths available to the RR, the configured ORR perspective, BGP policy, path attributes, and implementation behavior.¶

ORR and Add-Paths are complementary. ORR selects a path based on the root client’s or client group’s location, rather than the RR’s location. In contrast, Add-Paths advertises multiple candidate paths, allowing the client to perform its own selection. A deployment can use either mechanism or both, depending on its path selection and scaling requirements.¶

ORR requires sufficient IGP topology information to compute path metrics from the perspective of root clients or client groups. An RR can obtain this information by participating in the relevant IGP or by using BGP-LS [RFC9552].¶

Maintaining multiple ORR perspectives and performing path selection for different root clients or client groups increases RR processing and state. Operators should minimize the number of distinct ORR perspectives by grouping clients with equivalent topologies, then evaluate the resulting impact on CPU, memory, and convergence.¶

8.4. Protocol NEXT_HOP Resolution

The need for Protocol NEXT_HOP (PNH) resolution depends on the AFI/SAFI and the paths being processed. For address families carrying reachability information, an RR needs to determine whether a BGP NEXT_HOP is resolvable and, when applicable, obtain the IGP metric to be used during best path selection. The exact PNH behavior depends on the specific address family.¶

Some address families do not use the PNH in the same manner as unicast reachability routes. For example, BGP-LS [RFC9552] distributes topology information rather than forwarding reachability, and Route Target Constraint routes [RFC4684] control VPN route distribution. FlowSpec NLRI [RFC8955] describes traffic-matching and action rules rather than conventional destination reachability. However, FlowSpec validation and route acceptance can still depend on information from the unicast routing system.¶

Implementations can provide mechanisms to avoid or reduce PNH resolution for address families or routes for which it is not required. Where supported, operators can leverage these mechanisms to reduce processing overhead, provided they first verify the protocol procedures, validation rules, policy dependencies, and implementation details for the target AFI/SAFI.¶

8.5. Deployment Guidance

No single path selection mechanism is appropriate for every address family or deployment. Operators should consider:¶

• Distinct RDs where multiple VPN or EVPN routes need to remain distinct NLRI.¶

• Add-Paths where clients benefit from receiving multiple candidate paths.¶

• ORR when path advertisement must be constrained and path selection must align with client-specific or client-group topological proximity, rather than the RR’s local perspective.¶

• Multiple of the above mechanisms where their benefits are complementary.¶

The selection should account for route scale, required path diversity, convergence objectives, RR and client capacity, topology, and operational complexity. Operators should also consider failure scenarios, as a mechanism that provides optimal paths during steady state may fail to offer sufficient alternatives during convergence.¶

9.1. EVPN Route Target Considerations

To optimize NLRI distribution via RR design, special attention is suggested for EVPN. [RFC7432] in Section 7.6 defines the ES-Import Route Target (ES-Import-RT) extended community. The ES-Import-RT, together with RTC, enables optimized route distribution of Ethernet Segment (ES) routes. Namely, from an EVPN architectural point of view, it is sufficient that only PEs connected to the same multi-homed ES receive the ES route specific to a given multi-homed ES. All other PEs — those not connected to a given multi-homed ES — do not require visibility of that specific ES route.¶

To achieve the desired behavior, the value of the ES-Import-RT extended community is derived automatically from the Ethernet Segment Identifier (ESI) by encoding the high-order 6-octet portion of the 9-octet ESI value. For example, as illustrated in Figure 5, the octets depicted as 'XX' are used as the value of the ES-Import-RT.¶

                 ESI = 00:XX:XX:XX:XX:XX:XX:YY:YY:YY

When RTC is enabled, the RT-filter advertised by a PE (which is an RR client) is also automatically updated to signal interest to the RR in receiving NLRIs (here, ES routes) with a specific ES-Import-RT (here, with the value XX:XX:XX:XX:XX:XX). In large-scale deployments with a large number of multi-homed Ethernet segments, this can significantly reduce the number of ES routes that are sent to RR clients.¶

In order, however, to take advantage of this optimized distribution of ES routes, ESI values must be assigned in such a way that they are differentiated in the high-order 6-octet portion of the 9-octet ESI value. While this happens automatically for ESI types 1, 2, and 3, care must be taken with ESI type 0 (manual allocation). Figure 6 depicts an ESI type 0 value allocation scheme that does not result in an optimized distribution of ES routes through RRs.¶

                 ESI-1 = 00:00:00:00:00:00:00:00:00:01
                 ESI-2 = 00:00:00:00:00:00:00:00:00:02
                 ESI-3 = 00:00:00:00:00:00:00:00:00:03
                 ...
                 ESI-65535 = 00:00:00:00:00:00:00:00:ff:ff

In this ESI Type 0 value allocation scheme, the high-order 6-octet portion of the 9-octet ESI value is the same for all ESIs (00:00:00:00:00:00). Therefore, all PEs (all RR clients) update the RT-filters they advertise to the RR with an RT equal to 00:00:00:00:00:00, resulting in all PEs (RR clients) receiving ES routes for all Ethernet segments.¶

Figure 7 depicts a different allocation scheme for ESI Type 0 values. In this allocation scheme, the values are differentiated in the high-order 6-octet portion of the 9-octet ESI value.¶

                 ESI-1 = 00:00:00:00:00:00:01:00:00:00
                 ESI-2 = 00:00:00:00:00:00:02:00:00:00
                 ESI-3 = 00:00:00:00:00:00:03:00:00:00
                 ...
                 ESI-65535 = 00:00:00:00:00:ff:ff:00:00:00

Such an allocation scheme results in different ES-Import-RTs (and, as a consequence, different RT-filters) for each group of PEs connected to different Ethernet segments. Therefore, the ES route pertaining to ESI-1, based on the RT-filters received by the RR from PEs connected to the multi-homed Ethernet segment with ESI-1, is sent by the RR only to PEs (RR clients) connected to that particular Ethernet segment. It is suggested that operators consider adopting this allocation scheme to optimize ES route distribution, thereby reducing both the volume of routes propagated to RR clients and the associated control plane overhead.¶

10.1. TCP Path MTU Discovery

To improve BGP control plane performance, it is suggested to enable TCP Path MTU Discovery (PMTUD) [RFC1191] on both RRs and clients; this allows TCP to select an appropriate Maximum Segment Size (MSS) for each BGP session. In this way, BGP sessions use the largest packet size that does not require IP fragmentation anywhere along the path to client and non-client IBGP peers.¶

10.2. Ethernet MTU

The Ethernet maximum transmission unit (MTU) is the size of the largest frame, minus the 4-byte frame check sequence (FCS), that can be transmitted on a Ethernet network. Every physical network along the path to the destination of a packet can have a different MTU. The default Ethernet MTU (Maxiumum Transmission Unit) value is 1514 bytes for standard Ethernet frames and 1518 bytes for 802.1Q tagged frames. These numbers exclude the 4-byte frame check sequence (FCS).¶

When the MTU size is larger, more data can be sent in fewer number of packets. As each packet contains a header, a small number of packets means less header data to be transmitted. Thus, a larger size MTU helps in transmitting more actual data faster and efficiently.¶

To ensure the RR is not the limiting factor related to PMTUD and BGP update packet sizes, it is suggested to enable Jumbo frame support on RR interfaces with the largest packet size value available.¶

11.1. BGP Router ID

To prevent IBGP session instability caused by changes in the BGP router ID when a physical interface's state changes, it is suggested to statically configure the BGP router ID using the IP address of a virtual loopback interface. This approach is preferred because loopback interfaces are more stable than physical interfaces, which may go down or change state, causing the router ID to change and potentially leading to BGP session resets. This IBGP best practice applies to both RRs and clients.¶

11.2. BGP RIB/FIB Filtering

For RRs operating exclusively in the control plane, configuring RIB/FIB filtering policies to suppress BGP route installation is suggested. Restricting these tables on non-forwarding devices:¶

• Minimizes RIB and FIB resource consumption.¶

• Eliminates unnecessary RIB and FIB processing overhead.¶

• Improves an RR's overall efficiency and scalability.¶

11.3. BGP Error Handling

[RFC7606] specified critical updates to BGP error handling procedures. Ensure these procedures are enabled on RRs (and all other BGP speakers) if they are not already active by default.¶

11.4. Diffserv QoS Considerations

Because BGP control plane stability is fundamental to overall network stability, it is suggested that BGP packets be prioritized using Diffserv QoS [RFC2475] policies. This approach helps to prevent BGP packet loss and minimize queuing delays during congestion events, thereby ensuring session stability and avoiding the traffic disruption that occurs if BGP sessions fail.¶

11.5. Form Factor Considerations

Traditionally, RRs were deployed using physical routing devices. With the advent of Network Function Virtualization (NFV), RRs that operate exclusively in the control plane (i.e., control-plane-only) are now commonly deployed as Virtual Network Functions (VNFs) or virtual RRs.¶

Virtual RRs offer superior scalability and convergence performance compared to physical RRs by providing substantially more CPU performance, memory speed and quantity available for BGP protocol processing. Consequently, deploying control-plane-only RRs as virtual RRs is suggested. In contrast, RRs that participate in the IP forwarding plane are typically deployed as physical RRs, unless a virtual RR can satisfy the required forwarding capacity.¶

It is also worth noting that virtual RRs rely on independent compute, hypervisor, storage, and virtual networking infrastructure; however, vendors offer integrated appliances that bundle these components. If a virtual implementation is not feasible for operational or administrative reasons, a physical RR remains a viable alternative; however, the operator must account for the difference in control plane scale.¶

11.6. BGP Non-Stop Routing/Forwarding

A virtual RR is deployed on a compute server which has no concept of redundant route processors. A physical RR can be configured with redundant route processors and leverage this redundancy to enable BGP Non-Stop Routing (NSR). NSR preserves BGP session and control plane state during a route processor failover, ensuring that IBGP clients and non-client peers do not detect the switchover and eliminating the need for session resets, BGP Graceful Restart, or its helper mode.¶

While physical RRs with redundant route processors uniquely support NSR, they generally offer significantly lower BGP scaling compared to virtual RRs as described earlier. Consequently, deploying multiple redundant virtual RRs is suggested for networks with high BGP control plane scale.¶

11.7. BGP Graceful Restart

[RFC4724] enables a BGP router to gracefully restart its BGP routing process when necessary (e.g., due to a memory leak) and preserve its BGP forwarding state to avoid traffic loss. Redundant route processors are not required, however, sessions with BGP peers must be enabled for the BGP graceful restart capability. Otherwise, the forwarding state of BGP route paths learned via a session without graceful restart enabled is not preserved during a graceful restart of the local BGP routing process.¶

Control-plane-only RRs are not in the traffic forwarding plane, so they do not benefit from having their sessions enabled for graceful restart. Similarly, RR clients typically have multiple copies of reflected routes from multiple redundant RRs and, as a result, incur no traffic loss when their local BGP routing process restarts. Consequently, there is no tangible benefit to using graceful restart on sessions between RRs and their clients. Graceful restart is suggested for BGP routers participating in the traffic forwarding plane that lack BGP NSR and do not have access to redundant copies of BGP route paths from multiple peers.¶

11.8. Multi-hop BFD for IBGP

Multi-hop BFD is not suggested for IBGP sessions between control-plane-only RRs and their clients. Deploying BFD in this context exposes the BGP control plane to unnecessary instability, as it may trigger session resets due to minor, transient connectivity issues that TCP would otherwise handle gracefully. A multi-hop BFD-triggered reset on a session carrying millions of routes, for example, creates significant churn, even when the underlying network topology remains stable. Furthermore, using multi-hop BFD to accelerate failure detection within the BGP control plane is counterproductive; since clients typically receive redundant path information from multiple RRs, the loss of a single RR session does not impact the client's traffic forwarding plane.¶

12.1. BGP Session Authentication

BGP session cryptographic authentication is suggested to ensure that BGP updates are only accepted from trusted, verified peers, which helps to reduce the risk of unauthorized route injection and session hijacking. MD5 is the legacy method for BGP authentication, as it has been deprecated for some time now, given it is considered cryptographically weak by modern standards. TCP-AO [RFC5925] is the modern standard and suggested method for BGP session security as it provides stronger cryptographic algorithms and improved security features.¶

12.2. BGP Session Prefix Limits

Configuring BGP session prefix limits is an important measure to protect a network from an EBGP peer unexpectedly advertising an excessive number of routes, such as the full Internet routing table. BGP session prefix limits enforce a maximum receive prefix count from a neighbor for each address-family, helping safeguard a network from out-of-resource (OOR) conditions which could lead to traffic disruption.¶

In the event a session prefix limit is hit, BGP implementations typically provide several actions in response:¶

• Bring down session¶

• Restart session¶

• Discard extra paths¶

• SYSLOG warning¶

Beyond generating a SYSLOG warning, it is suggested to implement one of the listed actions for EBGP sessions based on your specific network requirements. BGP session prefix limits can be configured on IBGP sessions as well; however, if configured for IBGP, it is suggested to use only a SYSLOG warning without taking further action. This approach helps monitor prefix counts while avoiding IBGP session resets or disruptions, which could result in a more significant detrimental impact.¶

12.3. Control Plane Protection

It is common for modern IP routers to support control plane protection [RFC6192], including but not limited to control plane policing. Typically enabled by default on modern IP routers, this capability helps protect a router from excessive control plane traffic by classifying and policing different packet types, thereby preventing potential denial-of-service conditions. With regard to RRs, it is important for large-scale deployments to ensure that BGP control plane policer rates are optimally configured to prevent BGP packet drops, which could adversely affect both BGP stability and overall network stability.¶

14.1. Normative References

[RFC4271]

Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/rfc/rfc4271>.

[RFC4456]

Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, <https://www.rfc-editor.org/rfc/rfc4456>.

14.2. Informative References

[BGPAFI]

"Address Family Numbers", n.d., <https://www.iana.org/assignments/address-family-numbers/address-family-numbers.xml>.

[BGPSAFI]

"SAFI Namespace", n.d., <https://www.iana.org/assignments/safi-namespace/safi-namespace.xml>.

[I-D.draft-ietf-idr-bgp-fwd-rr]

Vairavakkalai, K. and N. Venkataraman, "BGP Route Reflector with Next Hop Self", Work in Progress, Internet-Draft, draft-ietf-idr-bgp-fwd-rr-05, 23 February 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-fwd-rr-05>.

[I-D.draft-ietf-idr-rtc-hierarchical-rr]

Dong, J., Chen, M., and R. Raszuk, "Extensions to RT-Constrain in Hierarchical Route Reflection Scenarios", Work in Progress, Internet-Draft, draft-ietf-idr-rtc-hierarchical-rr-06, 3 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-rtc-hierarchical-rr-06>.

[I-D.draft-ietf-idr-rtc-interas]

Litkowski, S., Haas, J., and K. Patel, "Inter Domain considerations for Constrained Route distribution", Work in Progress, Internet-Draft, draft-ietf-idr-rtc-interas-00, 17 August 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-idr-rtc-interas-00>.

[I-D.draft-ietf-mpls-seamless-mpls]

Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, M., and D. Steinberg, "Seamless MPLS Architecture", Work in Progress, Internet-Draft, draft-ietf-mpls-seamless-mpls-07, 28 June 2014, <https://datatracker.ietf.org/doc/html/draft-ietf-mpls-seamless-mpls-07>.

[RFC1191]

Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <https://www.rfc-editor.org/rfc/rfc1191>.

[RFC1997]

Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, <https://www.rfc-editor.org/rfc/rfc1997>.

[RFC2018]

Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996, <https://www.rfc-editor.org/rfc/rfc2018>.

[RFC2475]

Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <https://www.rfc-editor.org/rfc/rfc2475>.

[RFC3345]

McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, DOI 10.17487/RFC3345, August 2002, <https://www.rfc-editor.org/info/rfc3345>.

[RFC4364]

Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/rfc/rfc4364>.

[RFC4684]

Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, November 2006, <https://www.rfc-editor.org/rfc/rfc4684>.

[RFC4724]

Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, DOI 10.17487/RFC4724, January 2007, <https://www.rfc-editor.org/rfc/rfc4724>.

[RFC4798]

De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, DOI 10.17487/RFC4798, February 2007, <https://www.rfc-editor.org/rfc/rfc4798>.

[RFC5925]

Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/rfc/rfc5925>.

[RFC6192]

Dugal, D., Pignataro, C., and R. Dunn, "Protecting the Router Control Plane", RFC 6192, DOI 10.17487/RFC6192, March 2011, <https://www.rfc-editor.org/rfc/rfc6192>.

[RFC7432]

Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/rfc/rfc7432>.

[RFC7454]

Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, February 2015, <https://www.rfc-editor.org/rfc/rfc7454>.

[RFC7606]

Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/rfc/rfc7606>.

[RFC7911]

Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, <https://www.rfc-editor.org/rfc/rfc7911>.

[RFC7938]

Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of BGP for Routing in Large-Scale Data Centers", RFC 7938, DOI 10.17487/RFC7938, August 2016, <https://www.rfc-editor.org/rfc/rfc7938>.

[RFC7964]

Walton, D., Retana, A., Chen, E., and J. Scudder, "Solutions for BGP Persistent Route Oscillation", RFC 7964, DOI 10.17487/RFC7964, September 2016, <https://www.rfc-editor.org/rfc/rfc7964>.

[RFC8201]

McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed., "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017, <https://www.rfc-editor.org/rfc/rfc8201>.

[RFC8277]

Rosen, E., "Using BGP to Bind MPLS Labels to Address Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017, <https://www.rfc-editor.org/rfc/rfc8277>.

[RFC8654]

Bush, R., Patel, K., and D. Ward, "Extended Message Support for BGP", RFC 8654, DOI 10.17487/RFC8654, October 2019, <https://www.rfc-editor.org/rfc/rfc8654>.

[RFC8955]

Loibl, C., Hares, S., Raszuk, R., McPherson, D., and M. Bacher, "Dissemination of Flow Specification Rules", RFC 8955, DOI 10.17487/RFC8955, December 2020, <https://www.rfc-editor.org/rfc/rfc8955>.

[RFC9107]

Raszuk, R., Ed., Decraene, B., Ed., Cassar, C., Åman, E., and K. Wang, "BGP Optimal Route Reflection (BGP ORR)", RFC 9107, DOI 10.17487/RFC9107, August 2021, <https://www.rfc-editor.org/rfc/rfc9107>.

[RFC9293]

Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, <https://www.rfc-editor.org/rfc/rfc9293>.

[RFC9552]

Talaulikar, K., Ed., "Distribution of Link-State and Traffic Engineering Information Using BGP", RFC 9552, DOI 10.17487/RFC9552, December 2023, <https://www.rfc-editor.org/rfc/rfc9552>.

[RFC9871]

Rao, D., Ed. and S. Agrawal, Ed., "BGP Color-Aware Routing (CAR)", RFC 9871, DOI 10.17487/RFC9871, November 2025, <https://www.rfc-editor.org/rfc/rfc9871>.