Use the later begin and end markers deliberately
05RFC7313 adds explicit boundaries and peer/family-scoped stale-route cleanup.
After the shown re-advertisement, B sends subtype 2. A immediately removes still-stale R3 in B’s IPv6-unicast scope, retaining fresh R1/R2, C’s route and the IPv4 route. This is not Graceful Restart EoR.
Source for this drawing: RFC 2918 · Read RFC source: RFC 7313 §4 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
RFC7313 updates RFC2918. Its Enhanced Route Refresh Capability is Code 70 / Length 0. A supporting speaker SHOULD advertise it; the enhanced procedures apply only after receiving that capability from the peer. Our enhanced example explicitly assumes both peers advertised the base and enhanced capabilities (RFC7313 §§3.1,4).
- RFC7313 updates RFC2918. Its Enhanced Route Refresh Capability is Code 70 / Length 0. A supporting speaker SHOULD advertise it; the enhanced procedures apply only after receiving that capability from the peer. Our enhanced example explicitly assumes both peers advertised the base and enhanced capabilities (RFC7313 §§3.1,4).
- Before a locally initiated or requested refresh, a speaker that uses these enhanced procedures MUST send a Beginning of Route Refresh (BoRR), subtype 1. After re-advertising the entire relevant Adj-RIB-Out it MUST send End of Route Refresh (EoRR), subtype 2. The conceptual set at the start includes reachability and unreachability information; changed entries need only be advertised in their modified form (RFC7313 §4).
- On BoRR, the receiver MUST mark routes from that peer for that AFI/SAFI stale. Subsequent matching advertisements replace corresponding stale routes. Other peers’ routes and other families remain outside this cleanup scope (RFC7313 §4).
- On EoRR, the receiver MUST immediately remove routes still stale in that peer/family scope. Purged routes MAY be logged. In our chosen case R1 is refreshed, R2 is newly advertised, and old R3 remains stale and is removed. These four snapshots show the named boundaries, not a timed animation or proof of a valid real network path (RFC7313 §4).
- An EoRR without an associated BoRR MAY be ignored, and a locally configurable stale-retention upper bound MAY be imposed; no universal timer is specified here. Graceful Restart End-of-RIB (EoR) is a different marker with ordering guards, covered next. This guide models selected reachability replacement/withdrawal and cleanup, not all Graceful Restart or ORF behavior (RFC7313 §§4,7).
Fictional documentation prefixes and selected route records illustrate control-plane behavior. No full BGP UPDATE codec, best-path algorithm, ORF, network session or security validation is implemented.
Read the RFC section ↗