What are BGP's four path-attribute categories, and how does each decide whether a speaker must recognise, send and pass on an attribute?
answer
- two yes-or-no questions
- known by all, or optional?
- unknown: forward or drop?
- flags octet: Optional, Transitive, Partial
basics
~20 sWell-known mandatory attributes (ORIGIN, AS_PATH, NEXT_HOP) are understood by every speaker and carried on every route; well-known discretionary ones (LOCAL_PREF, ATOMIC_AGGREGATE) are understood but sent only when relevant; unrecognised optional transitive ones are passed on, unrecognised non-transitive ones dropped.
solid answer
~40 sRFC 4271 sorts path attributes with two questions. **Must every speaker understand it?** If yes it is *well-known*; if no it is *optional*. Well-known attributes split into **mandatory**, carried in every UPDATE with reachable prefixes (`ORIGIN`, `AS_PATH`, `NEXT_HOP`), and **discretionary**, sent when they apply (`ATOMIC_AGGREGATE`; `LOCAL_PREF` is usually listed here, though RFC 4271 requires it on every iBGP update and forbids it on eBGP). **What does a speaker that does not understand an optional attribute do?** If it is *transitive* (`AGGREGATOR`, `COMMUNITIES`), it accepts the route and passes the attribute on with the Partial bit set; if *non-transitive* (`MULTI_EXIT_DISC`), it quietly drops it. Each attribute's flags octet carries the Optional and Transitive bits, so a router can apply these rules to a type it has never seen.
go deeper
Recall the four category names and one member of each: AS_PATH, LOCAL_PREF, COMMUNITIES and MULTI_EXIT_DISC.
Explain the two questions behind the categories and what a router does with an optional attribute it does not understand: pass it on with Partial set, or drop it.
Separate the category from each attribute's own scope rules: a recognised MED stops at the neighbouring AS and LOCAL_PREF never leaves the AS, whatever their category suggests.
Explain why the optional, transitive design let BGP add four-octet AS numbers and new communities without a flag day, and what carrying unknown data unchecked costs.
## Two questions decide the category A **path attribute** is a typed field in a BGP UPDATE that describes the route to the prefixes in that message. RFC 4271 §5 sorts every attribute into one of **four categories** by asking two questions. | Category | Must every speaker recognise it? | Must it be sent? | Speaker that does not recognise it | |---|---|---|---| | **Well-known mandatory** | yes | in every UPDATE that carries prefixes | cannot happen legitimately | | **Well-known discretionary** | yes | only when it applies | cannot happen legitimately | | **Optional transitive** | no | as the attribute's own rules say | accepts the route, passes the attribute on, sets **Partial** | | **Optional non-transitive** | no | as the attribute's own rules say | quietly ignores it and does not pass it on | A well-known attribute that a speaker does not recognise is a protocol error, because RFC 4271 requires implementations to recognise all of them; it even defines an UPDATE error subcode, *Unrecognized Well-known Attribute*. ## Which attribute sits where | Attribute | Type code | Category | Defined in | |---|---|---|---| | `ORIGIN` | 1 | well-known mandatory | RFC 4271 | | `AS_PATH` | 2 | well-known mandatory | RFC 4271 | | `NEXT_HOP` | 3 | well-known mandatory | RFC 4271 | | `MULTI_EXIT_DISC` | 4 | optional non-transitive | RFC 4271 | | `LOCAL_PREF` | 5 | well-known (see below) | RFC 4271 | | `ATOMIC_AGGREGATE` | 6 | well-known discretionary | RFC 4271 | | `AGGREGATOR` | 7 | optional transitive | RFC 4271 | | `COMMUNITIES` | 8 | optional transitive | RFC 1997 | | `LARGE_COMMUNITY` | 32 | optional transitive | RFC 8092 | **`ORIGIN`** says how the origin AS learned the prefix: `IGP` (0, interior to that AS), `EGP` (1, the historic Exterior Gateway Protocol) or `INCOMPLETE` (2, some other means). Only the originator sets it; others SHOULD NOT change it. **`NEXT_HOP`** is the address to forward to. **`ATOMIC_AGGREGATE`** is zero bytes long: its presence says an aggregate dropped some AS numbers from the path. **`AGGREGATOR`** names the AS and router that formed an aggregate. ## The flags octet on the wire Every attribute starts with an **Attribute Flags** octet and a type-code octet. The high-order bits are: 1. **Optional** (bit 0): 1 = optional, 0 = well-known. 2. **Transitive** (bit 1): for optional attributes, 1 = transitive; for well-known attributes it MUST be 1. 3. **Partial** (bit 2): set on an optional transitive attribute that some speaker passed on without recognising it, or added after the origin; MUST be 0 on well-known and non-transitive attributes. 4. **Extended Length** (bit 3): the length field is two octets instead of one. So a well-known attribute carries flags `0x40`, an optional transitive one `0xC0` and an optional non-transitive one `0x80`, before any Partial or Extended Length bit. Because the category is **on the wire**, a router can apply the rules to an attribute type it has never heard of. ## What "transitive" does and does not mean - It governs only what a speaker does with an optional attribute it **does not recognise**. - A speaker that **does** recognise an attribute follows that attribute's own rules. `MULTI_EXIT_DISC` received over eBGP may go to iBGP peers but MUST NOT go to other neighbouring ASes; `COMMUNITIES` may be added to or changed by local policy. - "Well-known" does not mean "sent everywhere": RFC 4271 says a speaker must pass on well-known attributes, yet `LOCAL_PREF` MUST NOT be sent to external peers (confederations aside). ## Why BGP has optional attributes at all The scheme lets BGP grow without a flag day. A new attribute is defined as optional; old routers that do not understand it either carry it (transitive) or drop it (non-transitive) without breaking the session. RFC 6793's `AS4_PATH` is the textbook case: an optional transitive attribute that carries four-octet AS numbers **across** routers that only understand two-octet ones. ## Two wording traps - **`LOCAL_PREF`** is taught as well-known discretionary, but RFC 4271 calls it simply well-known, makes it **required** on iBGP and forbids it on eBGP. Say both when it matters. - **`NEXT_HOP`** is mandatory for IPv4 prefixes in the classic UPDATE fields. With multiprotocol BGP (RFC 4760), the next hop travels inside `MP_REACH_NLRI`, and an UPDATE with no other prefixes SHOULD NOT carry `NEXT_HOP`; `ORIGIN` and `AS_PATH` stay mandatory.
- MULTI_EXIT_DISC is non-transitive, yet routers inside the receiving AS see it. Why is that not a contradiction?Non-transitive describes what a speaker does with the attribute when it does **not** recognise it: drop it. A speaker that recognises `MULTI_EXIT_DISC` follows its own rule from RFC 4271: it MAY propagate a MED received over eBGP to iBGP peers, but MUST NOT pass it to other neighbouring ASes.
- Why are new BGP attributes defined as optional rather than well-known?Every speaker must recognise every well-known attribute, so a new well-known type would be an error for every router that predates it. An optional type is safe: old routers carry it if it is transitive or drop it if not, and keep their sessions up. `AS4_PATH` crossed two-octet-only routers this way.
- Is LOCAL_PREF mandatory or discretionary?Neither label fits exactly. It is usually taught as well-known discretionary, but RFC 4271 calls it well-known, says a speaker SHALL include it in every UPDATE to internal peers, and MUST NOT include it toward external peers outside a confederation. It is required inside the AS and absent outside it.
saying these in an interview costs you the question
- MULTI_EXIT_DISC is well-known, so every router in the path keeps it.
- An unrecognised optional transitive attribute makes the receiver reset the session.
- COMMUNITIES is a well-known mandatory attribute carried on every route.
- Transitive means the attribute can never be changed by an AS on the path.
- Every well-known attribute is sent to every peer, external ones included.
- LOCAL_PREF is optional, so routers may drop it on iBGP sessions.