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.
| Attribute | Type Code | Description |
|---|---|---|
| ORIGIN | 1 | How the prefix was injected into BGP: IGP (i), EGP (e), or Incomplete (?). IGP means it was injected via the network command; Incomplete means redistribution. |
| AS_PATH | 2 | The ordered list of ASes the route has traversed. Used for loop detection (if your own AS is in the path, reject it) and as a tiebreaker in best path selection (shorter is preferred). |
| NEXT_HOP | 3 | The IP address of the next-hop router to reach the prefix. In eBGP, set to the advertising router's interface IP. In iBGP, preserved from the original eBGP peer by default. |
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.
| Attribute | Type Code | Description |
|---|---|---|
| LOCAL_PREF | 5 | Used within an AS (iBGP only) to indicate the preferred exit point. Higher is better. Default is 100 on Cisco. Covered in Manipulating BGP Local Preference. |
| ATOMIC_AGGREGATE | 6 | Signals that the advertising router aggregated prefixes and some path information may have been lost. Informational only — does not affect path selection. |
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.
| Attribute | Type Code | Description |
|---|---|---|
| AGGREGATOR | 7 | Identifies the AS and router ID that performed route aggregation. |
| COMMUNITY | 8 | A 32-bit tag for grouping routes and applying policy. Standard communities include no-export, no-advertise, and internet. Covered in BGP Communities. |
| EXTENDED COMMUNITY | 16 | 8-byte communities used for VPN route targets, site-of-origin, and other extended tagging. |
| LARGE COMMUNITY | 32 | 12-byte communities (RFC 8092) designed for 4-byte ASNs. Format: ASN:value1:value2. |
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.
| Attribute | Type Code | Description |
|---|---|---|
| MED | 4 | Multi-Exit Discriminator — suggests to an external AS which entry point to prefer. Lower is better. Only compared between paths from the same neighboring AS (by default). Covered in BGP MED: Influencing Inbound Traffic. |
| ORIGINATOR_ID | 9 | Set by route reflectors to identify the original iBGP advertiser. Used for loop prevention in RR environments. |
| CLUSTER_LIST | 10 | Set by route reflectors to track which RR clusters the route has passed through. Loop prevention for hierarchical RR designs. |
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: 0Reading this output:
- Origin IGP — injected via the
networkcommand (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.