Stop invalid or out-of-order enhanced messages
06The enhanced update distinguishes ignore, notification and restart-order guards.
In a separate case there was no associated BoRR. The helper takes RFC7313’s MAY-ignore branch, keeping all routes unchanged. It does not purge routes just because an EoRR marker arrived.
Source for this drawing: RFC 2918 · Read RFC source: RFC 7313 §5 ↗
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.
These examples assume the Enhanced Route Refresh Capability was received and the family is in the receiver’s advertised set. The enhanced unknown-subtype and malformed-marker length checks are not bypassed merely by an unadvertised family. RFC7313 §5 error handling is conditional on the enhanced capability; the selected helper is not a full BGP state machine or a universal precedence rule for simultaneous independent errors.
- These examples assume the Enhanced Route Refresh Capability was received and the family is in the receiver’s advertised set. The enhanced unknown-subtype and malformed-marker length checks are not bypassed merely by an unadvertised family. RFC7313 §5 error handling is conditional on the enhanced capability; the selected helper is not a full BGP state machine or a universal precedence rule for simultaneous independent errors.
- For an enhanced ROUTE-REFRESH whose Message Subtype is neither 0, 1 nor 2, the receiver MUST ignore the message and SHOULD log an error. The example uses unknown subtype 3; it does not send a notification merely because that subtype is unknown (RFC7313 §5).
- For subtype 1 or 2, body length excluding the fixed BGP header MUST be four octets. If it is not, the receiver MUST send NOTIFICATION Error Code 7 / Subcode 1. Data MUST contain the complete offending ROUTE-REFRESH message, including its header. Our malformed BoRR has a five-octet body and a 24-octet full message (RFC7313 §5; RFC4271 §4.5).
- A speaker supporting Graceful Restart MUST NOT send BoRR for a family before sending that family’s Graceful Restart EoR. A receiver that received the peer’s Graceful Restart Capability MUST ignore BoRR for a family before receiving that family’s EoR, and SHOULD log the condition. BoRR, EoRR and Graceful Restart EoR are not interchangeable (RFC7313 §4).
- An EoRR without an associated BoRR MAY be ignored and MAY be logged. The final snapshot chooses that permitted ignore branch and leaves routes unchanged. Do not turn MAY into mandatory deletion, invent a stale-retention duration, or interpret refresh support as authenticated routing information (RFC7313 §§4,7; RFC2918 §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 ↗