Stop reflected loops and handle malformed input
04Originator checks, cluster checks and malformed-attribute handling solve different problems.
RFC7606 requires withdrawing the UPDATE’s contained routes in this selected malformed case; external-neighbor attributes take a different discard path.
Source for this drawing: RFC 4456 · Read RFC section 8 ↗
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 recommended loop rejection is different from a malformed UPDATE disposition.
- A router recognizing ORIGINATOR_ID SHOULD ignore a received route whose originator equals its own BGP Identifier. The chosen receiver follows that recommendation and stops before installing the returning route. This is SHOULD, not an invented universal MUST (§8).
- An RR finding its local CLUSTER_ID anywhere in a received CLUSTER_LIST SHOULD ignore the advertisement. The check is membership in the entire list, not only its first item. Prepending alone does not prevent loops unless receivers apply the checks (§8).
- For redundant RRs in one cluster, a shared four-byte CLUSTER_ID can be configured so an RR can discard a route reflected by another RR in that same cluster. In a single-RR cluster the RR’s BGP Identifier normally identifies the cluster. A shared cluster ID is distinct from sharing the routers’ own BGP Identifiers (§7).
- RFC7606 formally updates RFC4456 error handling. From an internal neighbor, ORIGINATOR_ID length other than4 and CLUSTER_LIST length that is not a non-zero multiple of4 are malformed; the UPDATE SHALL be handled using treat-as-withdraw. This treats all routes carried in that UPDATE as withdrawn, rather than automatically resetting the whole session (§§7.9–7.10; RFC7606 §2).
- From an external neighbor, these recognized attributes SHALL instead be discarded using attribute discard, and the UPDATE continues processing. Do not confuse discarding an attribute with withdrawing the whole UPDATE. The selected helper classifies these two attributes only after their framing is available; general truncation, flags, other attributes and errors require the broader BGP rules (RFC7606 §§2,7.9–7.10).
- The depicted malformed internal CLUSTER_LIST has six value bytes, so it cannot contain whole four-byte IDs. This is different from a well-formed route carrying a looped identifier. A zero-length received CLUSTER_LIST is also malformed under the update, even though a missing attribute can be the starting point for creating a new list.
Fictional offline routing examples. Lines show BGP control sessions or route advertisements, not user-packet forwarding paths. Helpers model selected reflection and attribute rules; they do not implement a BGP daemon, TCP session, full decision process or production configuration.
Read the RFC section ↗