Handle unknown and malformed markers
05Enhanced error handling applies when capability70 was received. Unknown subtypes and malformed known boundary markers have different required outcomes.
The NOTIFICATION for that malformed case carries all24 octets:19-octet BGP header plus the five-octet body. Merely copying the body is insufficient.
Source for this drawing: RFC 7313 · Read RFC section 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.
A received subtype other than0,1,2 MUST be ignored; the speaker SHOULD log an error for analysis. Reserved255 is included in this rule.
- A received subtype other than0,1,2 MUST be ignored; the speaker SHOULD log an error for analysis. Reserved255 is included in this rule.
- For subtype1 or2, a body length other than4 octets requires a NOTIFICATION: error code7, ROUTE-REFRESH Message Error, subcode1, Invalid Message Length.
- The NOTIFICATION Data field MUST contain the complete offending ROUTE-REFRESH message, including its BGP header. A four-octet boundary body is distinct from the complete23-octet example message.
- Subtype0 processing remains with RFC2918 and RFC5291. These examples are separate error cases, not sequential messages after a NOTIFICATION. General BGP framing and session handling are outside the bounded illustration.
RFC7313 §5. Parsed subtype and bounded small messages are assumed; no complete BGP/ORF parser, network connection or error-recovery engine is implemented.
Read the RFC section ↗