BGP Path Attributes Explained: Well-Known vs Optional

Unlike IGPs that use a single metric (cost, bandwidth, delay), BGP makes routing decisions based on a rich set of path attributes attached to every prefix in an UPDATE message. These attributes describe the path to a destination - which ASes the traffic will cross, how the originator prefers traffic to flow, and what communities or tags are attached for policy purposes.

Path attributes are the foundation of BGP policy. Every traffic engineering technique - local preference, MED, AS-path prepending, communities - works by manipulating one or more path attributes. Before we get into the individual knobs (covered in later articles), you need to understand the attribute classification system.

Attribute Categories

BGP path attributes fall into a 2x2 matrix based on two properties:

• Well-Known vs Optional: Must every BGP implementation recognize it, or not?
• Mandatory vs Discretionary (well-known) / Transitive vs Non-Transitive (optional): Must it always be present? If optional, should it be passed along even if not understood?

Well-Known Mandatory

Every BGP implementation must recognize these, and they must be present in every UPDATE with NLRI. Missing one is a protocol violation that triggers a NOTIFICATION.

Well-Known Discretionary

Every BGP implementation must recognize these, but they don't have to be present in every UPDATE. They're included when relevant.

Optional Transitive

Not every implementation must recognize these, but if a router receives one it doesn't understand, it must pass it along to its peers (transitive). The Partial bit is set to indicate it wasn't fully processed.

Optional Non-Transitive

Not every implementation must recognize these, and if a router doesn't understand one, it silently drops it rather than passing it along.

How Attributes Flow

The transitive/non-transitive distinction matters in multi-AS paths:

• AS_PATH, NEXT_HOP, ORIGIN: Always present, always forwarded - they're mandatory.
• LOCAL_PREF: Only carried within an AS (stripped at eBGP boundaries). Your iBGP peers see it; your eBGP peers don't.
• MED: Sent to eBGP peers but is non-transitive - it's only meaningful to the directly connected neighboring AS, not passed further.
• COMMUNITY: Transitive - passed along unless explicitly stripped. This is why communities are so powerful for multi-hop policy signaling.

Viewing Attributes on IOS XE

R1-HQ# show ip bgp 100.64.1.0/24
BGP routing table entry for 100.64.1.0/24, version 22
Paths: (2 available, best #1, table default)
  Advertised to update-groups:
     1
  65010
    203.0.113.1 from 203.0.113.1 (203.0.113.1)
      Origin IGP, metric 0, localpref 150, valid, external, best
      Community: 65010:100 65010:200
      rx pathid: 0, tx pathid: 0x0
  65020 65010
    198.51.100.1 from 198.51.100.1 (198.51.100.1)
      Origin IGP, metric 10, localpref 100, valid, external
      Community: 65020:300
      rx pathid: 0, tx pathid: 0

Reading this output:

• Origin IGP - injected via the network command (origin code "i")
• metric 0 - MED value of 0 (first path) vs 10 (second path)
• localpref 150 - local preference is 150 for the first path (set by inbound route-map), 100 for the second (default)
• 65010 - AS-path for the first path (one hop through AS 65010)
• 65020 65010 - AS-path for the second path (two hops - through AS 65020, then 65010)
• Community: 65010:100 65010:200 - standard communities attached by the originating AS

Attribute Flags

Each attribute is encoded with a flag byte that indicates its properties:

• Bit 0 (Optional): 0 = well-known, 1 = optional
• Bit 1 (Transitive): 0 = non-transitive, 1 = transitive
• Bit 2 (Partial): 1 = attribute was not fully processed by some intermediate router
• Bit 3 (Extended Length): 1 = attribute length field is 2 bytes instead of 1

You'll see these flags in packet captures (Wireshark decodes them clearly), and they're useful for debugging attribute handling issues in multi-vendor environments.

Key Takeaways

• BGP path attributes fall into four categories: well-known mandatory (must exist), well-known discretionary (recognized but optional), optional transitive (passed along if not understood), and optional non-transitive (dropped if not understood).
• The three mandatory attributes - ORIGIN, AS_PATH, and NEXT_HOP - must be in every UPDATE with NLRI.
• LOCAL_PREF stays within the AS (iBGP only). MED is sent to eBGP peers but not forwarded beyond the neighboring AS. COMMUNITY is transitive and passes through multiple ASes.
• Every BGP traffic engineering technique works by manipulating one or more of these attributes - understanding the categories helps you predict how changes propagate.
• Use show ip bgp [prefix] to see all attributes for a specific route, including origin, AS-path, next-hop, local-pref, MED, and communities.