BGP Path Attributes and Policy Expression

Author

K19G

Updated

October 31, 2026

BGP Path Attributes and Policy Expression

BGP is not merely a routing protocol; it is a distributed policy programming language. Routing policy is expressed, transmitted, and enforced through Path Attributes associated with prefixes in UPDATE messages. Understanding attribute classification, propagation mechanics, and semantics is essential to auditing route behavior and diagnosing policy vulnerabilities.

Attribute Categories

Every BGP path attribute falls into one of four rigid categories based on two binary flags: Is it recognized by all implementations? and Must it be passed across AS boundaries?

Classification Meaning Must Be Understood? Propagated across eBGP? Standard Examples
Well-Known Mandatory Must be present in every single route advertisement update. Yes Yes ORIGIN, AS_PATH, NEXT_HOP
Well-Known Discretionary Recognized by all implementations; optional to include in update. Yes Yes LOCAL_PREF, ATOMIC_AGGREGATE
Optional Transitive May not be supported by every implementation; if unrecognized, must be preserved and passed to peers. No Yes COMMUNITY (RFC 1997), AGGREGATOR
Optional Non-Transitive If unrecognized or across eBGP boundary, must be silently discarded. No No MULTI_EXIT_DISC (MED), ORIGINATOR_ID, CLUSTER_LIST

[!WARNING] The Optional Transitive category introduces a notable vector for covert signaling and table bloat: an upstream router will faithfully propagate unrecognized transitive attributes across the entire global Internet without inspecting or sanitizing their contents.

AS_PATH: Loop Detection and Policy Signal

The AS_PATH attribute (Type Code 2) records the sequence of Autonomous Systems that a route advertisement has traversed. It serves two distinct functions:

1. Loop Prevention

When a router receives an UPDATE over an eBGP session, it scans the AS_PATH for its own ASN. If its ASN is present, the router immediately discards the update. This simple mechanism guarantees loop-free paths in interdomain topologies without running spanning-tree algorithms or Dijkstra SPF across the planet.

Inside an AS_PATH, numbers are grouped into segments: - AS_SEQUENCE: An ordered list of ASNs traversed by the route (most recent hop first). - AS_SET: An unordered collection of ASNs created during route summarization. (Deprecated by RFC 6472 and RFC 6978 due to security and operational complexity).

2. Traffic Engineering (AS-Path Prepending)

Because the BGP decision process prefers shorter AS_PATH lengths, operators intentionally duplicate their ASN multiple times when advertising routes to secondary transit providers:

\[\text{Advertised to Primary ISP:} \quad \text{AS\_PATH} = [65001]\] \[\text{Advertised to Backup ISP:} \quad \text{AS\_PATH} = [65001, 65001, 65001]\]

This artificially inflates the path length, discouraging remote networks from selecting the backup link for ingress traffic.

NEXT_HOP, LOCAL_PREF, MED and ORIGIN: Comparative Selection Logic

+--------------------------------------------------------------------+
|                         BGP Selection Pipeline                     |
|                                                                    |
|  [Inbound UPDATE]                                                  |
|         |                                                          |
|         v                                                          |
|  1. HIGHEST LOCAL_PREF (Internal AS policy preference)             |
|         |                                                          |
|         v                                                          |
|  2. SHORTEST AS_PATH (Fewest AS hops to destination)               |
|         |                                                          |
|         v                                                          |
|  3. LOWEST ORIGIN (IGP [0] < EGP [1] < Incomplete [2])             |
|         |                                                          |
|         v                                                          |
|  4. LOWEST MED (Metric set by neighboring AS for multi-homing)    |
|         |                                                          |
|         v                                                          |
|  5. eBGP over iBGP                                                 |
|         |                                                          |
|         v                                                          |
|  6. LOWEST IGP METRIC TO NEXT_HOP (Hot-potato routing)             |
+--------------------------------------------------------------------+
  • NEXT_HOP (Well-Known Mandatory): Specifies the IP address of the next-hop router. On eBGP sessions, it is the IP address of the peering neighbor. In iBGP, the eBGP next-hop is preserved across the AS backbone, requiring internal routers to resolve it via their IGP (recursive routing) unless next-hop-self is applied at border routers.
  • LOCAL_PREF (Well-Known Discretionary): Valid only within an AS (disseminated via iBGP; stripped before eBGP export). Default is typically \(100\). A higher value indicates higher preference. This is the primary mechanism operators use to prefer customer links over transit uplinks.
  • ORIGIN (Well-Known Mandatory): Defines the origin source of the route:
    • 0 = IGP (prefix originated via network statement or IGP redistribution).
    • 1 = EGP (historic Exterior Gateway Protocol).
    • 2 = INCOMPLETE (redistributed from unknown or static sources).
  • MULTI_EXIT_DISC (MED, Optional Non-Transitive): Conveyed to an adjacent AS across eBGP to indicate preference among multiple parallel ingress links into the originating AS. Lower MED is preferred. By default, routers only compare MED among paths learned from the same neighboring AS.

BGP Communities and Extended Communities: Encoding Policy at Scale

BGP Communities (RFC 1997) are 32-bit values attached to routes that convey operational tags and trigger programmatic actions at remote routers. Standard communities are formatted as ASN:Value (e.g., 65001:100).

Well-Known Standard Communities

  • NO_EXPORT (0xFFFFFF01): Do not advertise the route outside the local AS (or BGP confederation).
  • NO_ADVERTISE (0xFFFFFF02): Do not advertise the route to any peer (neither iBGP nor eBGP).
  • BLACKHOLE (RFC 7999, 0xFFFF029A or ASN:666): Signals transit providers and peers to discard all traffic destined for the prefix in hardware (Remote Triggered Blackholing).

Extended (RFC 4360) and Large Communities (RFC 8092)

  • Extended Communities (8 octets): Provide typed metadata such as Route Targets (RT) and Route Distinguishers (RD) in EVPN and MPLS-VPN deployments.
  • Large Communities (12 octets): Formatted as Global-Admin:Action:Function (e.g., 65000:1:100). Designed to support full 32-bit AS numbers alongside flexible operator tagging.

ADD-PATH, GTSM and Modern Security Attributes

  • ADD-PATH (RFC 7911): By default, BGP only advertises its single best path to peers. ADD-PATH allows a router to advertise multiple alternative paths for the same prefix, each identified by a unique Path ID. This eliminates route-reflector hiding and accelerates convergence.
  • Generalized TTL Security Mechanism (GTSM, RFC 5082): Mitigates CPU denial-of-service by verifying that eBGP packets have traversed exactly one hop (TTL = 255).
  • BGP Only to Customer (OTC, RFC 9234): An attribute designed to enforce provider-customer hierarchy and automatically block route leaks.