Replay only the relevant outbound advertisements
04A refresh preserves family scope and each side’s policy boundaries.
A’s separate chosen inbound policy accepts R1 and rejects R2. The BGP session stays established; the picture does not certify best-path choice, forwarding installation or a completed real refresh.
Source for this drawing: RFC 2918 · Read RFC section 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.
B shall re-advertise to A the Adj-RIB-Out for the requested AFI/SAFI, based on B’s outbound route-filtering policy. It does not dump every route B knows, bypass export rules or replace a different peer’s outbound view (§4).
- B shall re-advertise to A the Adj-RIB-Out for the requested AFI/SAFI, based on B’s outbound route-filtering policy. It does not dump every route B knows, bypass export rules or replace a different peer’s outbound view (§4).
- For the illustration, B’s candidate list contains three IPv6-unicast prefixes and one IPv4-unicast prefix. A chosen export policy permits R1, R2 and V4, but not R3. Selecting the requested IPv6-unicast family leaves R1 and R2 in the relevant advertisement view. These are fictional documentation prefixes, not a full best-path algorithm.
- B returns those route advertisements in UPDATE messages. One UPDATE can carry several compatible prefixes; the two illustrated arrows are a teaching choice, not a rule that each route requires its own message (RFC4271 §3.1).
- A re-examines the received routes under its own inbound policy. In this separate chosen policy case, A accepts R1 and rejects R2. Receiving an advertisement is not a requirement to install it as a forwarding route, nor proof that the destination can be reached (RFC4271 §§3.1–3.2).
- RFC2918 defines no begin/end demarcation in this plain exchange. Silence or the two arrows drawn here do not prove a real peer has finished. RFC7313 adds explicit BoRR/EoRR markers, explained next. This extension does not change the underlying BGP security issues (§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 ↗