BGP Graceful Degradation Under Control Plane Memory Pressure

Introduction BGP speakers may experience rapid control-plane memory consumption when routing state grows quickly due to route flapping, configuration errors, large-scale route synchronization, rapid service expansion, or anomalous route injection. When implementations lack active resource-protection mechanisms, continuously receiving and processing routes can lead to memory exhaustion, which may trigger BGP session resets, routing process restarts, board resets, or even device reboots. Such failures not only affect existing services but may also create renewed resource pressure after recovery, because full routing state re-synchronization can again consume significant control-plane resources. This may lead to a cycle of exhaustion, restart, re-synchronization, and renewed exhaustion. This document describes a BGP graceful degradation operations framework oriented toward control-plane memory pressure. The framework progressively reduces BGP route admission and processing based on resource status and, when necessary, isolates selected neighbors, address families, or services to maintain basic device operation. After resource recovery, the device re-synchronizes routing state in a controlled manner and returns to normal operation. This document does not define new BGP messages, path attributes, capabilities, or protocol state machines.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 when, and only when, they appear in all capitals, as shown here.

Problem Description BGP is a stateful, incremental routing protocol. Upon receiving routes, a BGP speaker must maintain control-plane state including prefixes, paths, attributes, policy results, and next-hops. BGP routing state may grow rapidly in a short time under the following scenarios:

Neighbors erroneously advertise a large number of routes;
Route filtering or policy configuration anomalies;
Multiple neighbors performing full-route synchronization simultaneously;
Large-scale route flapping;
Rapid VPN or EVPN service expansion;
Malicious or anomalous route injection.

Existing resource protection typically resets neighbors after the route count exceeds a static threshold, or restarts the protocol process after memory is exhausted. While these methods can stop resource growth, they often have the following limitations:

Protection actions are triggered too late;
Failure impact scope is too broad;
They cannot take progressive measures based on resource status;
They cannot prioritize critical services;
Full routing state re-synchronization after restart may again cause resource peaks;
They are prone to forming an "exhaustion--restart--re-synchronization-- exhaustion again" loop.

Therefore, an active protection mechanism based on resource feedback is needed to limit BGP resource growth while the device still has management and recovery capabilities.

Objectives and Scope The objectives of BGP graceful degradation are:

Identify resource risks before control-plane memory is exhausted;
Slow down or stop memory growth caused by new routes;
Maintain the BGP process, management plane, and existing forwarding state as much as possible;
Limit impact to smaller address families, services, or neighbor scopes;
Prioritize protection of critical services and critical neighbors;
Smoothly restore complete routing state after resource recovery;
Avoid large-scale simultaneous neighbor recovery causing new resource shocks.

This document focuses on control-plane memory pressure caused or significantly aggravated by BGP routing state growth. This document does not replace the following mechanisms:

Network capacity planning;
Route filtering;
Maximum prefix limits;
Control plane protection;
BGP error handling;
Graceful Restart;
Planned Graceful Shutdown.

Graceful Degradation Principles

Prevention First Graceful degradation is a resource-protection mechanism for abnormal states and should not replace normal route filtering, maximum prefix limits, and capacity planning.

Minimum Impact Scope Protection actions should start from a smaller scope and only expand progressively when resources continue to deteriorate. The reference order is as follows:

Reduce route admission or processing rate
Pause admission of new routes for selected scopes
Isolate selected address families, VRFs, or services
Close selected non-critical BGP sessions
Invoke process-level or device-level last-resort protection

Maintain Control Capability During degradation, the following should be preserved as much as possible:

Management access;
Alarms and telemetry;
Basic BGP session processing;
Route withdrawal processing;
Recovery and route re-synchronization capabilities.

Prioritize Route Withdrawal Processing When resources are constrained, route withdrawal is usually more important than new route advertisement. Delaying new routes may cause temporary absence of new reachable paths, while delaying withdrawal may allow invalid routes to persist. Therefore, during degradation, it is preferable to prioritize processing withdrawals and updates affecting existing reachability.

Recovery Must Be Executed in a Controlled Manner Recovery cannot simply be equated with lifting all restrictions. Route refresh, neighbor re-establishment, and full-route learning may all cause memory peaks again, so the recovery process needs to be batched, rate-limited, and have hysteresis.

Resource Monitoring and State Determination Devices can comprehensively use the following information to determine whether to enter a graceful degradation state:

System memory utilization;
Absolute available memory;
Memory growth rate;
Memory allocation failures;
BGP process or module memory share;
Route and path counts;
Route growth rate per neighbor and address family;
UPDATE processing rate and queue length;
Estimated remaining safe operation time.

Relying solely on a fixed memory percentage may not accurately reflect risk. Devices can consider both current resource level and growth trends. Before executing BGP degradation, devices SHOULD also try to determine whether BGP is the main source of current memory pressure. If the main resource consumption comes from other modules, limiting BGP route admission and processing may only slow down the risk without solving the root problem. In such cases, devices SHOULD rely on platform-level resource management, shorten the monitoring interval, and MAY escalate directly to last-resort protection if the non-BGP source cannot be contained. BGP degradation SHOULD NOT be used as the sole response to non-BGP memory pressure. Devices can divide operational states into:

Normal state;
Warning state;
Critical state;
Recovery state.

Normal, Warning, and Critical reflect the current resource level and associated protection actions. Recovery is a transitional operational state entered after the resource level has returned to safe ranges, during which the device executes controlled restoration of routing state. It is not a resource level itself. Implementations can add finer states based on platform architecture, but the externally presented model should remain simple. The following table provides an example mapping between resource states and candidate degradation actions. Implementations may define more detailed internal states based on platform architecture.

State	Resource Level / Condition	Operational Action
Normal	Memory level and growth rate are within expected ranges	Normal BGP route admission and processing
Warning	Memory utilization, growth rate, or UPDATE backlog exceeds a warning threshold	Slow down route admission or processing; prioritize withdrawals
Critical	Memory continues to deteriorate, allocation failures occur, or backlog memory becomes significant	Pause admission for selected scopes; isolate AFI/SAFI, VRFs, or services; close selected sessions
Recovery	Memory has returned below the recovery threshold and remained stable for a period; resource level is now Normal or near-Normal	Perform batched route re-synchronization; rebuild closed sessions; gradually restore normal processing rate

Graded Degradation Strategy

Route Admission and Processing Slowdown When a device enters the warning state, it can reduce BGP route admission and processing speed to slow down memory growth. Methods that can be adopted include:

Limit the number of new routes processed per unit time;
Allocate processing quotas by neighbor or address family;
Batch policy calculation and best-path calculation;
Merge duplicate updates for the same route within a short time;
Limit non-critical background tasks;
Reserve processing capability for route withdrawals.

Route processing slowdown should not cause input queues to grow indefinitely. Implementations need to monitor both UPDATE backlogs and the memory consumed by queued messages. If the input queue backlog itself becomes a significant source of memory pressure, the implementation SHOULD narrow the affected scope, pause new route admission for the affected peers or AFI/SAFI, or close the affected sessions in a controlled manner. An implementation that discards queued UPDATE messages MUST mark the affected routing state as incomplete and MUST perform route re-synchronization before returning the affected scope to normal operation.

Pause Admission of New Routes When learning slowdown is insufficient to control resource growth, new route admission can be paused within a selected scope. The pause scope can be:

Specific neighbors;
Neighbor groups;
Specific AFI/SAFI;
Specific VRFs or services;
All non-critical route sources.

During degradation, route withdrawals and necessary updates affecting existing route validity can continue to be processed. When new route admission is paused, the implementation MUST treat the affected Adj-RIB-In scope, or its equivalent implementation state, as incomplete. The implementation MUST record the affected peers, peer groups, AFI/SAFI, VRFs, and services, as applicable. Routes that are not admitted during the pause period will not necessarily be restored by subsequent incremental UPDATE messages. Before the affected scope is considered fully recovered, the implementation MUST perform route re-synchronization, such as Route Refresh, Enhanced Route Refresh, local soft refresh where applicable, or controlled session re-establishment. If Route Refresh is not supported by the peer, controlled session re-establishment may be required.

Isolate Address Families or Services When pausing new route admission is insufficient to control memory growth, devices can isolate specific address families, services, or VRFs. Isolation means ceasing BGP route admission and processing for the selected scope. Depending on the implementation and local policy, isolation may include withdrawing affected routes from the local RIB. Where the implementation supports independent per-AFI/SAFI processing or uses separate transport sessions for different services, isolation may be applied to the affected AFI/SAFI without closing the entire BGP peer session. Otherwise, isolating an AFI/SAFI may require closing the corresponding BGP session. This action is more severe than pausing admission and is applied before closing entire neighbors or peer sessions.

Controlled Session Closure When a BGP speaker remains in a critical resource state and narrower degradation actions cannot stop resource deterioration, selected BGP sessions can be closed in a controlled manner. Session selection can consider multiple factors, including:

Estimated memory that may be released by closing the session;
Total number of routes and paths received from the peer;
Number or ratio of non-best paths;
Recent route growth rate;
Evidence of anomalous route injection or excessive route churn;
Service importance and configured protection priority;
Availability of alternative paths or redundant peers;
Expected recovery cost and recovery time.

Prioritizing closure of sessions with a large number of non-best paths is an optional strategy, but should not be the sole basis. To reduce service impact, implementations may allow operators to configure protection priority for critical neighbors. Such protection should be combined with explicit resource budgets or exemption limits. Otherwise, an excessively large protected scope can make the degradation mechanism ineffective and may prevent the device from preserving basic operation. Sessions should be closed in batches. After each batch of actions, the memory release effect can be observed before deciding whether to continue expanding the scope.

Last-Resort Protection If available degradation actions cannot preserve basic device operation, the platform may need to invoke BGP process-level, control-unit-level, line-card-level, or device-level protection. Such actions are last-resort measures and are not the normal objective of graceful degradation.

Recovery Strategy When memory returns to a safe range, the device can enter the recovery state. Recovery determination can simultaneously consider:

Memory below recovery threshold;
Memory has stabilized for a certain period;
Memory growth rate has returned to normal;
UPDATE backlog has decreased;
Anomalous route injection or flapping has stopped;
The system has the resource margin required to execute route synchronization.

Entering and exiting degradation MUST use different thresholds (hysteresis) to avoid frequent state switching. The recovery threshold for a given state SHOULD be set sufficiently below its entry threshold, taking into account observed memory volatility, the resource cost of route synchronization, and the time required for memory to stabilize. The recovery process can be executed in the following order:

Confirm management and monitoring capabilities are normal;
Restore new route admission for neighbors that were not disconnected;
Perform full route synchronization, such as Route Refresh, session rebuild, or local soft refresh, for affected neighbors and address families to recover routes missed during degradation;
Batch rebuild closed sessions;
Gradually restore normal processing speed;
Verify RIB, FIB, and resource status;
Exit recovery state.

For neighbors whose new route admission was paused, merely restoring normal processing speed will not fill in the missed routing state. Recovery can use:

Route Refresh;
Enhanced Route Refresh;
Local soft refresh, where sufficient local routing state has been retained;
Controlled BGP session re-establishment.

Local soft refresh is applicable only when the implementation has retained sufficient local pre-policy or post-policy routing state. Under memory pressure, such retained state may be unavailable or may have been released as part of resource protection. Both route refresh and session re-establishment may generate full-route updates, so the number of simultaneously recovering neighbors and address families needs to be limited. If memory grows rapidly again during recovery, the implementation SHOULD stop starting new recovery batches. Scopes that have already recovered and remained stable do not need to be degraded again unless resource pressure continues to worsen or reaches a critical threshold.

Deployment and Operations Considerations

Threshold Setting This document does not specify uniform memory thresholds. Thresholds can be combined with:

Device total memory;
Control plane minimum safe margin;
Normal route scale;
Abnormal period route growth rate;
Memory reclamation delay;
Resources required for route refresh and neighbor rebuilding;
Resource requirements for other protocols and management functions.

Service Classification Critical services can be identified by neighbor, address family, VRF, or neighbor group. Service classification should remain simple and be consistent with real network redundancy relationships. Critical service protection should not be understood as absolute exemption; when the system is about to lose basic operation capability, last-resort protection may still affect critical neighbors.

Observability Devices should provide the following information:

Current resource state;
Current degradation level;
Trigger reason;
Current memory level and memory growth rate;
Affected peers, peer groups, AFI/SAFI, VRFs, and services;
Route admission or processing rate-limit status;
Number of new routes not admitted, where available;
Whether the affected routing state is marked as incomplete;
Sessions closed due to resource protection and their selection reasons;
Current recovery stage;
Route re-synchronization method and progress;
Whether recovery is paused due to renewed resource pressure.

Operations systems need to be able to distinguish session closures caused by resource protection from ordinary link failures or protocol anomalies.

Gradual Deployment Initial deployment can proceed according to the following steps:

Enable only monitoring and alarms;
Collect normal resource baselines;
Verify route admission and processing slowdown;
Verify recovery after pausing new route admission by injecting a controlled volume of test routes under simulated memory pressure. The test should confirm that the device pauses admission for the intended scope, marks the affected routing state as incomplete, records the affected peers and AFI/SAFI, and subsequently performs route re-synchronization without persistent missing state;
Configure a small number of critical neighbors;
Enable automatic slowdown;
Then enable pause admission and controlled session closure;
Regularly drill the recovery process.

Security Considerations Attackers may cause devices to enter resource pressure states by continuously advertising a large number of legitimate routes. Graceful degradation can reduce the probability of a single anomalous neighbor causing a device crash, but cannot replace route filtering, maximum prefix limits, neighbor authentication, and anomaly detection. Attackers may also attempt to:

Keep memory oscillating near degradation or recovery thresholds for long periods;
Induce a device to close specific BGP sessions by manipulating route volume or churn;
Consume resources by exploiting overly broad critical-neighbor exemptions;
Trigger repeated route re-synchronization during the recovery phase;
Cause persistent incomplete routing state if recovery procedures are not executed correctly.

Therefore, devices can adopt recovery hysteresis, reconnection backoff, batch recovery, and multi-factor neighbor ranking to reduce risks. Pausing new route admission can make the local routing view temporarily incomplete. Implementations MUST clearly record the affected scope and MUST perform route re-synchronization before the affected scope is considered fully recovered. Otherwise, some routes may remain missing for an extended period of time.

IANA Considerations This document does not request IANA to allocate new code points.