Re-examine routes without resetting the session
01A local inbound-policy change can need fresh advertisements from an established peer.
B sends the selected family’s advertisements back in UPDATE messages, subject to B’s outbound policy. A applies its new inbound policy and can now retain both R1 and R2 without resetting the session.
Source for this drawing: RFC 2918 · Read RFC section 1 ↗
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.
BGP means Border Gateway Protocol. Peers exchange routing information in UPDATE messages. An inbound policy decides how a speaker treats received routes. After that policy changes, it may need to re-examine routes it previously rejected; changing a local rule cannot reconstruct information it did not retain (§1; RFC4271 §§3.1–3.2).
- BGP means Border Gateway Protocol. Peers exchange routing information in UPDATE messages. An inbound policy decides how a speaker treats received routes. After that policy changes, it may need to re-examine routes it previously rejected; changing a local rule cannot reconstruct information it did not retain (§1; RFC4271 §§3.1–3.2).
- RFC2918 defines a request for a peer to re-advertise its relevant Adj-RIB-Out: the routing information selected for advertisement to that peer. RIB means Routing Information Base; Adj-RIB-Out is a conceptual per-peer view, not a requirement to keep a particular physical table (§§1,4; RFC4271 §3.2).
- In our chosen example, B previously advertised R1 and R2, but A kept only R1 under its old inbound policy and retained no unmodified copy of R2. A changes policy to permit both, then asks B to refresh the IPv6-unicast family. The next chapter supplies the capability prerequisites; all examples assume an established BGP session.
- The ROUTE-REFRESH request travels A to B; route advertisements return B to A in UPDATE messages. The request itself contains a family identifier, not routes, an inbound filter or an acknowledgement (§§3–4).
- The mechanism avoids resetting an otherwise established session just to obtain advertisements again. It is not proof of route correctness, reachability, authentication or completion of every later routing decision. Historical statements about typical policy-change frequency in §1 are not current measurements (§5).
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 ↗