Summary

  • RFC 2918 lets one BGP speaker request re-advertisement of a capable peer's current Adj-RIB-Out for a negotiated AFI/SAFI. The peer still applies its own current outbound policy.
  • RFC 7313 places Beginning-of-RIB-Refresh and End-of-RIB-Refresh markers around a complete replay, allowing the receiver to mark old routes stale, replace refreshed entries and remove those that do not return.
  • Safe policy change requires route-set and forwarding proof. A successful command, stable session or completed marker does not show that the right routes were exported, accepted, selected or used.

Suppose an operator repairs an inbound prefix filter. The old rule accepted 40,000 routes and rejected 200 that should have been allowed. The corrected rule is committed successfully. Nothing about that commit recreates the 200 discarded inputs. If the router did not retain their unmodified advertisements, it has no objects against which to run the new rule.

The opposite failure is just as important. A new policy is meant to reject a class of routes that the previous rule accepted. Those routes already occupy local state. Merely changing the filter does not prove that every existing path was reconsidered and withdrawn from use. A policy can be correct in the repository and stale in the RIB.

Before Route Refresh, one answer was inbound soft reconfiguration. The receiver stored an unmodified copy of all advertisements from the peer, including routes rejected by policy. When the policy changed, it could run the stored set through the new rules without asking the neighbor and without tearing down the session. The price was continuous memory and processing for information that might rarely be needed.

RFC 2918 offered a different allocation of state. A speaker advertises Route Refresh Capability, code 2, to tell its peer that it can receive and handle a ROUTE-REFRESH message. A requester may send that message only after receiving the capability from the peer. The request identifies one Address Family Identifier and Subsequent Address Family Identifier negotiated when the session was established.

The recipient of a valid request re-advertises the relevant Adj-RIB-Out to that peer. The phrase “Adj-RIB-Out” establishes the authority boundary. It is the sender's current set of routes selected for advertisement to this particular neighbor, under the sender's outbound route-filtering policy. The requester does not read the sender's database or order it to expose a rejected route.

This is replay, but not archival replay. A route exported yesterday may no longer exist. The sender may have changed its own policy, lost an upstream path, selected a new best route or withdrawn the prefix. A route not previously exported may qualify now. The refresh gives the receiver a fresh view of what the peer currently says, not an immutable copy of what the peer once said.

That distinction matters in incident reconstruction. If an operator refreshes immediately after changing import policy and sees 39,500 routes rather than 40,000, the difference cannot be assigned to the local filter from counts alone. The peer's export set may also have changed. The evidence needs exact prefixes and attributes, timestamps and, where possible, an independent pre-change observation.

Basic Route Refresh also lacked a clear envelope. The receiver could ask for re-advertisement, but the protocol did not mark where a complete replay began and ended. Ordinary BGP updates could interleave. A route absent so far might still be coming, or might have been withdrawn. Without a finish boundary, removing old state during an online consistency check could be premature.

RFC 7313 added Enhanced Route Refresh Capability, code 70. It redefined the formerly reserved byte in the message as a subtype. Subtype 0 remains a normal refresh request. Subtype 1 marks Beginning-of-RIB-Refresh, or BoRR. Subtype 2 marks End-of-RIB-Refresh, or EoRR.

When a capable sender begins a refresh, it sends BoRR for the AFI/SAFI. The receiver marks all routes from that peer in that address family stale. As routes arrive during the subsequent re-advertisement, corresponding stale entries are replaced. When EoRR arrives, any entries still stale are removed immediately. The missing withdrawal becomes observable as non-return within a bounded epoch.

The sender is not required to freeze the world while replaying. RFC 7313 defines the conceptual entire Adj-RIB-Out at the start of the operation and permits changed entries to be advertised as they change. The receiver must process a live stream whose purpose is consistency, not a file copied from a quiescent database.

Local authority remains visible in the stale timer. An implementation may impose a configurable upper bound on how long stale routes are retained and may remove them without waiting forever for EoRR. That prevents an incomplete refresh from preserving obsolete reachability indefinitely. A timer set too short, however, can withdraw useful routes before a slow but healthy replay finishes.

Enhanced Route Refresh also separates EoRR from the End-of-RIB marker used by BGP Graceful Restart. The names are adjacent but the lifecycle is different. Graceful Restart coordinates retention of forwarding state while a control plane restarts. Enhanced refresh validates or replaces a peer's current route set while the BGP session remains established. RFC 7313 orders their interaction to prevent a BoRR from causing premature cleanup before the relevant restart End-of-RIB.

An inbound refresh and an outbound soft action must not be collapsed into one mental operation. Inbound, the local router needs the neighbor's advertisements again; it either requests remote re-advertisement or reprocesses a locally retained unmodified copy. Outbound, the local router regenerates its own advertisements to the neighbor under its current export policy. The command syntax may use the word “soft” for both, but the source of authority differs.

Cisco documentation illustrates the operational choices. Where Route Refresh was negotiated, a dynamic inbound soft reset sends a refresh request rather than requiring permanent storage of all unmodified updates. If the peer lacks the capability, stored inbound soft-reconfiguration state can supply the inputs. If neither exists, re-evaluation may be impossible without a hard reset that tears down the session and removes its routes.

The fallback is a governance decision, not a command inconvenience. Continuous storage spends memory to preserve local independence from a future peer response. Route Refresh saves that memory but creates a dependency on the peer's capability, responsiveness and current export policy. A hard reset reacquires state through session establishment but expands the failure domain to all reachability carried by the session.

FRRouting documents a further limit. Stored inbound soft reconfiguration remains necessary for features that need to count routes rejected by policy, such as certain maximum-prefix modes. A replay can re-present current advertisements for policy evaluation, but after rejection the receiver may still lack durable knowledge of the full raw set. State retained for one control objective cannot automatically be inferred from support for another.

Outbound Route Filtering, defined by RFC 5291, adds another negotiated interaction. A receiver can communicate filtering information that the sender can apply to what it advertises, and normal Route Refresh can operate with or without ORF. This does not make ordinary refresh a remote policy editor. ORF is a separate capability with its own rules, and the sender still owns the construction of its Adj-RIB-Out.

The first proof therefore precedes the change. Record whether each side advertised and received basic and enhanced capabilities, per AFI/SAFI. “Advertised” in local output is not the same as “received from peer.” A router may be willing to accept requests while the other side cannot satisfy one, or basic refresh may exist without enhanced epoch markers.

Next capture a baseline. For the affected peer and address family, retain exact received prefixes and relevant attributes, accepted routes, best paths, route counts, policy version, session uptime and FIB next hops. If the platform cannot show rejected routes, state that evidence gap instead of treating the accepted RIB as the original feed.

Apply the policy to a bounded peer or route family, then initiate the appropriate re-evaluation. Record the request timestamp. With Enhanced Route Refresh, record BoRR, EoRR and duration. Watch for a missing EoRR, a stale-retention timeout, unexpected session reset, control-plane saturation and bursts of withdrawals or best-path changes.

Compare sets, not just totals. Ten rejected prefixes replaced by ten new accepted prefixes leave a count unchanged. One aggregate replaced by hundreds of more-specifics changes count without necessarily changing reachability. Attribute rewrites can alter selection while NLRI remains identical. The diff needs prefix, path, next hop, communities and policy reason at the level material to the change.

Then cross into forwarding. A route accepted after replay may lose best-path selection to another peer. A changed best path may fail to install because its next hop is unresolved. A FIB change may send traffic to a link without sufficient capacity. Route Refresh makes the policy inputs available; it does not prove packets reached the intended destination.

Rollback needs its own replay. Restoring the old policy text does not automatically restore the route decisions that existed before the change. Request or regenerate the relevant advertisements again, verify the reverse diff and inspect forwarding. If the peer's current export set changed during the window, exact restoration may be impossible, which is another reason to retain the baseline as evidence rather than as a promise.

Fleet-wide automation must respect the work it asks remote systems to perform. Refreshing thousands of peers or many address families simultaneously can generate large update volumes and repeated best-path calculations. The safe unit is bounded by peer, AFI/SAFI, control-plane capacity and observability. Concurrency is a policy choice, not a property inferred from the word “soft.”

Permission should also be divided. A policy author can propose a rule. A reviewer can validate the intended diff on stored or laboratory inputs. An operator with refresh authority can request live replay for a bounded relationship. A separate verifier can decide whether the resulting routes and traffic authorize wider rollout. Combining edit, replay and fleet expansion in one privileged action erases the pause in which evidence can veto harm.

Heng Lu's principle of minimum initial specification fits the message. The protocol standardizes a small request: one negotiated address family, one peer, one re-advertisement behavior. It does not centralize either party's policy or require the sender to surrender historical state. Each AS keeps future decisions local while sharing enough mechanism to avoid destructive session resets.

Running-code primacy supplies the acceptance test. A route-map commit, capability support matrix and successful CLI response are representations. The negotiated capabilities, observed refresh epoch, resulting Adj-RIB-In, Loc-RIB, Adj-RIB-Out and FIB are the system. If the intended routes were not re-evaluated, the policy did not become operational merely because its text changed.

Data sovereignty here is practical control of information needed for a decision. Storing unmodified inbound routes gives the receiver local re-evaluation independence at resource cost. Relying on Route Refresh leaves the sender sovereign over its current export and the receiver sovereign over its current import. Neither architecture is universally superior; the relationship owner must choose which dependency is acceptable and prove the chosen path works.

Route Refresh is valuable because it separates policy repair from session destruction. It does not separate policy from evidence. The request asks a neighbor to speak again. Only the resulting route-set diff, completed epoch and forwarding observation show whether the new rule finally governs the network.

Sources