Summary

  • Route Refresh can ask a peer to re-advertise one AFI/SAFI without resetting the BGP session; Enhanced Route Refresh can mark the beginning and end of that replay.
  • Those markers describe a protocol exchange, not the configuration version, policy direction, selected route, forwarding entry or packet outcome that an operator intended to change.
  • A credible completion claim joins the refresh to a controlled route and to evidence from policy commit through traffic, with explicit exceptions and rollback.

The exchange closes before the operational question

Imagine a routine import-policy change. A network intends to reject a newly disallowed route from one transit neighbor. The configuration system reports a successful commit. The router sends a refresh request. Enhanced Route Refresh produces a Beginning-of-RIB marker, a stream of routes and an End-of-RIB marker. The change ticket is closed as reconciled.

Yet a controlled check still finds the route selected on one production edge. Nothing in that sequence makes the standards malfunction. It exposes a category error: completion of the re-advertisement was treated as proof of the policy outcome.

RFC 2918 created Route Refresh to avoid tearing down a BGP session when policy needs to be reapplied. A speaker advertises the capability at session establishment. Later, a refresh message names an address-family identifier and subsequent-address-family identifier. The peer then re-advertises the routes it currently makes available for that family.

That is useful because a session reset can be disruptive and because a receiver may not retain every unmodified route needed for local reprocessing. But the refresh message does not carry the receiver's policy hash, the intended rule, the configuration transaction or a declaration that a particular prefix must disappear. It starts a protocol action, not an operational proof.

Beginning and end are protocol boundaries

RFC 7313 adds Enhanced Route Refresh. Its Beginning-of-RIB and End-of-RIB markers give the receiver a boundary around the re-advertised set. During that interval, the receiver can identify routes that were not refreshed and dispose of stale state according to the procedure.

The markers answer a precise question: when did this refresh of this AFI/SAFI begin and end? They do not answer whether the correct policy version was active before the first replayed update arrived. They do not identify who approved that version. They do not attest that every router in a cohort received it. And they do not prove that a route selected by BGP was installed in the intended forwarding table or carried packets.

Scope matters. An IPv4-unicast refresh does not reconcile IPv6 unicast, VPN routes or another SAFI. A successful event on one peer does not cover a second session, route reflector or edge cohort. Treating one End-of-RIB observation as a fleet-wide completion signal erases the dimensions the protocol deliberately keeps separate.

Direction changes what must be proven

BGP policy is not a single filter. RFC 4271 distinguishes routes received from a peer, routes selected into the local routing information base and routes prepared for advertisement. A receiver that changed inbound policy needs new advertisements so it can apply that policy again. A speaker that changed outbound policy needs to show that the new export decision was used for the named neighbor.

Those are different ownership and evidence paths. A refresh may cause the peer to replay its outbound state while the local router applies inbound rules. The same event cannot silently certify both sides' configuration intent.

Outbound Route Filtering adds another state boundary. RFC 5291 lets one speaker communicate filtering information intended to constrain what its peer advertises. Capability, filter type, direction and installed filter state all matter. Seeing a later refresh does not prove that a particular outbound filter was present, current or interpreted as the change owner expected.

Route state is not forwarding proof

A policy result should be checked at the stage where the claim lives. If the claim is that a route was rejected on import, inspect the relevant received-route and policy result. If the claim is that an alternative became best, inspect the Loc-RIB decision. If the claim is that traffic moved, inspect the FIB, next-hop resolution and a representative packet path.

These observations can disagree without contradiction. A prefix may be absent from one peer's accepted set while still arriving through another. The intended alternative may enter the Loc-RIB but fail recursive next-hop resolution. A FIB entry may exist while an access list, tunnel or downstream fault prevents delivery. Route Refresh is not designed to collapse those questions into one bit.

The safest verification uses a controlled route with a known expected outcome. Record its state immediately before the commit, during the marked refresh window and after End-of-RIB. Compare more than a route count: identify the prefix, source peer, path, relevant attributes, decision reason and final next hop. Then exercise traffic that represents the affected service and address family.

A bounded interpretation protects the mechanism

None of this diminishes Route Refresh. It makes the mechanism more useful by assigning it the claim it can support. A completed marked exchange is strong evidence that a capable peer replayed a bounded routing set. It is an important timestamp in a change record. It simply needs neighboring evidence before it can support a broader declaration.

That distinction also improves incident response. When an expected withdrawal does not occur, the team can ask whether the wrong policy was committed, the right policy reached only part of the fleet, the refresh covered the wrong family, the peer lacked the negotiated capability, an ORF state differed, or the routing result was correct while forwarding failed. “Refresh completed” no longer ends the inquiry prematurely.