Why did RFC 7606 replace the BGP session reset for many malformed UPDATE messages with treat-as-withdraw, and what does that trade away?
answer
- one bad attribute, every route lost
- transitive attributes travel unchecked
- four approaches, strongest to weakest
- parse the NLRI or reset
basics
~20 sUnder RFC 4271, any malformed BGP UPDATE reset the whole session, dropping every route on it, often far from the router at fault. For most attribute errors RFC 7606 withdraws only that UPDATE's routes, risking unreachability and inconsistent routing inside an AS.
solid answer
~50 sRFC 4271 answers any `UPDATE` error with a `NOTIFICATION` (UPDATE Message Error) and closes the session, so one bad attribute takes down every valid route learned over it. Optional transitive attributes make it worse: speakers that do not recognise them pass them on unchecked, so the reset happens on a session far from the router that created the error, and repeats each time the route is re-sent. RFC 7606 (2015, updating RFC 4271) defines four responses from strongest to weakest: session reset, AFI/SAFI disable, treat-as-withdraw, attribute discard. Malformed `ORIGIN`, `AS_PATH`, `NEXT_HOP`, `MULTI_EXIT_DISC` or `LOCAL_PREF` now get treat-as-withdraw; `ATOMIC_AGGREGATE` and `AGGREGATOR` get attribute discard. The cost: those prefixes become unreachable or suboptimal, and on iBGP different routers can disagree, causing loops or black holes. If the prefixes cannot be parsed, the session still resets (or, where RFC 4760 allows, that address family is disabled).
go deeper
Recall that BGP reports a bad UPDATE with a NOTIFICATION and, in the original rules, closes the session. Later RFCs softened that.
Explain why one bad attribute resetting a session loses every route on it, and name RFC 7606's gentler responses.
Know which errors get treat-as-withdraw, attribute discard or a reset, why a transitive attribute makes the fault appear far away, and why iBGP inconsistency is the price.
Frame it as a blast-radius decision: a loud, total failure against a quiet, partial one, and what monitoring and ingress filtering must cover once failures become quiet.
## The base rule: any error resets the session A **BGP UPDATE** message carries withdrawn prefixes, a set of **path attributes**, and the prefixes (**NLRI**, network layer reachability information) those attributes describe. **RFC 4271** handles every error found in an UPDATE the same way: the receiver sends a **NOTIFICATION** with the **UPDATE Message Error** code and closes the connection. Closing a BGP connection clears everything learned from that peer, so routes are recomputed and withdrawals propagate to other peers. That is a **session reset**, and it is a heavy response to a light fault. ## Why the reset became a problem **RFC 7606** lists the reasons the IETF revised the rule in 2015: - **Collateral damage.** One UPDATE with one bad attribute takes down every valid route on the session, which may be a full routing table. - **The fault travels.** An **optional transitive** attribute is passed on by speakers that do not recognise it, without being checked. RFC 7606 describes such attributes as effectively tunnelled: they cross many networks until one speaker that does recognise and check them finds the error and resets its session, a session not associated with the router at fault. - **It repeats.** When the session comes back, the peer still holds the route and sends it again, so the session resets again. One bad announcement can make sessions flap in many networks at once. ## RFC 7606's four approaches | Approach | What the receiver does | Strength | |---|---|---| | Session reset | sends a NOTIFICATION and closes the session, RFC 4271's original behaviour | strongest | | AFI/SAFI disable | ignores later routes of the affected address family on that session, as RFC 4760 allows | strong | | Treat-as-withdraw | handles the UPDATE as if all its prefixes were listed as withdrawn, removing them from the Adj-RIB-In | weaker | | Attribute discard | drops the malformed attribute and keeps processing the UPDATE | weakest | When one UPDATE carries several errors that call for different approaches, the strongest applies. The **Adj-RIB-In** named in the table is the per-peer store of routes exactly as that peer advertised them, before local policy is applied. Removing prefixes from it is what would have happened had the peer sent a withdrawal itself, so the rest of the decision process needs no special case: the speaker simply recomputes its best paths for those prefixes. ## Which error gets which - **Treat-as-withdraw** applies to errors involving `ORIGIN`, `AS_PATH`, `NEXT_HOP`, `MULTI_EXIT_DISC` or `LOCAL_PREF`; to a missing well-known mandatory attribute; and to an attribute whose Optional or Transitive flag bits conflict with its definition. - **Attribute discard** applies to errors in `ATOMIC_AGGREGATE` or `AGGREGATOR`. It is allowed only for an attribute that has no effect on route selection or installation. - **Session reset still applies** when the message cannot be safely taken apart. Treat-as-withdraw needs every prefix in the UPDATE to be parsed, because the receiver must know what to withdraw. If the lengths are inconsistent, for example Withdrawn Routes Length plus Total Attribute Length plus 23 exceeds the message length, the error is a Malformed Attribute List and the session resets. More generally, whenever the prefixes cannot be parsed, RFC 4271's reset applies, or AFI/SAFI disable where RFC 4760 allows it. ## What treat-as-withdraw trades away The change is a trade, not a free improvement, and RFC 7606 says so: 1. **The affected prefixes still suffer.** They become unreachable, or are reached by a worse path, until the sender fixes its announcement. 2. **iBGP can become inconsistent.** If one router inside an AS withdraws a route while others keep it, routers disagree about the path, and RFC 7606 warns this can cause long-lived forwarding loops and black holes. It judges this rarer and less harmful than resets, and recommends tracing such routes to the router where they entered the AS and filtering them there. 3. **Silent failure needs logging.** A reset is loud; a withdrawal is quiet. RFC 7606 requires debugging facilities that, at a minimum, log an error listing the affected NLRI and containing the entire malformed UPDATE. Treat-as-withdraw is also **not the same as ignoring the UPDATE**. Discarding the whole message would keep whatever route was there before, which may now be wrong; withdrawing the prefixes keeps the table honest. ## Common mistakes - Saying a malformed attribute is always silently dropped: only two attributes get attribute discard. - Saying RFC 7606 removed session resets: they remain for errors that prevent parsing. - Treating withdraw as harmless: on iBGP it can split an AS's view of a route. - Confusing attribute discard with ignoring the UPDATE: under attribute discard the routes are still processed, only without the bad attribute.
- Why can a BGP speaker not use treat-as-withdraw when the UPDATE's length fields are inconsistent?Treat-as-withdraw removes every prefix the UPDATE carried, so the receiver must find and parse the whole NLRI. If the lengths contradict each other, it cannot tell where the attributes end and the prefixes begin, so it cannot know what to withdraw. RFC 7606 keeps the session reset for that case: a NOTIFICATION with Malformed Attribute List.
- Why is treat-as-withdraw riskier on an iBGP session than on an eBGP one?Inside an AS, every router is expected to reach the same decision about a prefix. If one router withdraws the route because it saw a malformed attribute while others keep it, they can forward toward each other and loop, or send traffic toward a router with no route. RFC 7606 accepts this as rarer than the damage of resets and recommends filtering at the ingress router.
saying these in an interview costs you the question
- RFC 7606 removed BGP session resets for malformed UPDATEs entirely.
- Treat-as-withdraw means the receiver ignores the bad UPDATE and keeps the old route.
- A malformed AS_PATH is handled by discarding the attribute and keeping the route.
- A malformed attribute can only reset the session with the router that created it.
- Treat-as-withdraw is always safe because it only affects the bad prefixes.