Check which peer advertised receive support
02Receive capability, request direction and family scope are separate checks.
In a separate well-framed request, A asks B for AFI 1 / SAFI 2, which B did not advertise in this example. B ignores the message; it does not export another family’s routes instead.
Source for this drawing: RFC 2918 · Read RFC section 2 ↗
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.
The Route Refresh Capability uses Capability Code 2 and Capability Length 0: the TLV bytes are 02 00. A speaker advertises it in OPEN to say that it can receive and properly handle ROUTE-REFRESH messages (§2; RFC5492 §4).
- The Route Refresh Capability uses Capability Code 2 and Capability Length 0: the TLV bytes are 02 00. A speaker advertises it in OPEN to say that it can receive and properly handle ROUTE-REFRESH messages (§2; RFC5492 §4).
- A may send ROUTE-REFRESH to B only if A has received B’s Route Refresh Capability. B’s advertisement enables requests toward B. A’s own receive-capability advertisement alone does not enable A to request from B (§4).
- The requested Address Family Identifier (AFI) and Subsequent Address Family Identifier (SAFI) should be among those the peer advertised when establishing the session. Our selected Multiprotocol tuple is AFI 2 / SAFI 1, IPv6 unicast (§§3–4; RFC4760 §§6,8). Both peers advertise that Multiprotocol tuple in these examples, as RFC4760 §8 requires for bidirectional exchange; this is separate from the Route Refresh receive capability.
- If B receives a request for a family B did not advertise to A at session establishment, B shall ignore that message. Otherwise B shall re-advertise the relevant Adj-RIB-Out under its outbound route-filtering policy (§4).
- RFC2918 uses lower-case “should” and “shall”; the guide preserves those distinctions and does not promote the family-selection recommendation to an uppercase MUST. The local sender helper chooses to stop an out-of-family request. Uppercase requirements in later chapters come from RFC7313, not invented wording in RFC2918.
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 ↗