10.2 BGP Path Attributes & Best Path Selection Algorithm

10.2 BGP Path Attributes & Best Path Selection Algorithm

Unlike Interior Gateway Protocols that compute routing metrics based solely on link bandwidth or composite delays, Border Gateway Protocol is an administrative policy engine. BGP attaches rich metadata—termed Path Attributes (PAs)—to every Network Layer Reachability Information (NLRI) prefix advertised in an UPDATE message. By systematically evaluating these path attributes through a deterministic 13-step decision algorithm, BGP selects a single best path to install into the Routing Information Base (RIB) and advertise to downstream peers.

+-----------------------------------------------------------------------------------+
|                         BGP PATH ATTRIBUTE CLASSIFICATION                         |
+-----------------------------------------------------------------------------------+
|                                                                                   |
|  1. WELL-KNOWN MANDATORY                                                          |
|     - Must be recognized by ALL standard BGP implementations.                     |
|     - MUST be included in EVERY BGP UPDATE message.                               |
|     - Attributes: ORIGIN (Type 1), AS_PATH (Type 2), NEXT_HOP (Type 3)            |
|                                                                                   |
|  2. WELL-KNOWN DISCRETIONARY                                                      |
|     - Must be recognized by ALL standard BGP implementations.                     |
|     - OPTIONAL to include in UPDATE messages (sent only when relevant).           |
|     - Attributes: LOCAL_PREF (Type 5), ATOMIC_AGGREGATE (Type 6)                  |
|                                                                                   |
|  3. OPTIONAL TRANSITIVE                                                           |
|     - May or may not be recognized by all BGP implementations.                    |
|     - If unrecognized, the router MUST ACCEPT and FORWARD it to downstream peers. |
|     - Attributes: COMMUNITY (Type 8), AGGREGATOR (Type 7)                         |
|                                                                                   |
|  4. OPTIONAL NON-TRANSITIVE                                                       |
|     - May or may not be recognized by all BGP implementations.                    |
|     - If unrecognized, the router SILENTLY DISCARDS the attribute.                |
|     - Recognized attributes are NEVER forwarded outside the local AS.             |
|     - Attributes: MED / MULTI_EXIT_DISC (Type 4), ORIGINATOR_ID (9), CLUSTER_LIST (10)|
|                                                                                   |
+-----------------------------------------------------------------------------------+

1. Path Attribute Classifications & Taxonomy

Every BGP path attribute falls into one of four standardized categories defined in RFC 4271 based on two criteria: whether recognition is mandatory across all vendors, and whether unrecognized attributes must be propagated to downstream peers.

Comprehensive BGP Path Attributes Reference Table

2. The Comprehensive 13-Step BGP Best Path Selection Algorithm

When a BGP router receives multiple candidate routes for the exact same destination prefix and prefix length, it evaluates the paths sequentially through the following 13-step hierarchy until a single winner is determined.

+-----------------------------------------------------------------------------------+
|                    BGP BEST PATH SELECTION MEMONIC / SUMMARY                      |
+-----------------------------------------------------------------------------------+
|  MNEMONIC: "We Love Really Sophisticated Organizations, Never Ever Lowering Old   |
|             Route-reflector Cluster Numbers"                                      |
+-----------------------------------------------------------------------------------+
|  0. Prerequisite : Next-Hop Reachability (Must be reachable via IGP / RIB)        |
|  1. W            : Highest WEIGHT (Cisco local: 0 to 65,535; default 32,768/0)   |
|  2. L            : Highest LOCAL_PREFERENCE (AS-wide: default 100)                |
|  3. R (Originate): Locally Originated (network/redistribute > aggregate-address)  |
|  4. S (AS-Path)  : Shortest AS_PATH length (AS_SET counts as 1)                   |
|  5. O (Origin)   : Lowest ORIGIN code (IGP 'i' < EGP 'e' < Incomplete '?')       |
|  6. N (MED)      : Lowest MULTI_EXIT_DISCRIMINATOR (MED, default 0)               |
|  7. E (eBGP)     : Prefer eBGP over iBGP paths                                    |
|  8. L (IGP Cost) : Lowest IGP metric to BGP Next-Hop (Shortest internal exit)     |
|  9. Multi-Path   : Maximum-Paths installed if ECMP configured                     |
| 10. O (Oldest)   : Oldest (most stable) eBGP path                                 |
| 11. R (Router ID): Lowest BGP Router ID of advertising peer (or Originator ID)   |
| 12. C (Cluster)  : Shortest CLUSTER_LIST length (Route Reflector environment)     |
| 13. N (Neighbor) : Lowest Neighbor IP Address (peering address)                   |
+-----------------------------------------------------------------------------------+

Detailed Step-by-Step Analysis

• Step 0: Next-Hop Reachability (Prerequisite): Before evaluating any path attributes, BGP verifies that the IP address specified in the NEXT_HOP attribute is resolvable in the local Routing Information Base (RIB). If the next-hop is unreachable, the route is marked inaccessible (r RIB-failure or non-valid) and immediately disqualified.
• Step 1: Highest Weight (Cisco Proprietary):
  • Scope: Strictly local to the router; never transmitted in BGP updates to any peer.
  • Value Range: 0 to 65,535. Routes originated locally default to 32,768; routes learned from peers default to 0.
  • Higher values are preferred.
• Step 2: Highest Local Preference (LOCAL_PREF):
  • Scope: AS-wide; advertised to all iBGP peers within the local AS, but stripped from updates sent to external eBGP peers.
  • Value Range: 0 to 4,294,967,295. Default value is 100 (bgp default local-preference <val>).
  • Primary tool for influencing outbound egress traffic from the local Autonomous System.
• Step 3: Prefer Locally Injected Routes:
  • Paths originated locally on the router are preferred over paths learned from peers.
  • Order of precedence among local routes: $\text{network} \; / \; \text{redistribute} \; > \; \text{aggregate-address}$
• Step 4: Shortest AS_PATH Length:
  • Evaluates the number of autonomous systems listed in the AS_PATH attribute.
  • An AS_SEQUENCE (e.g., 100 200 300) counts each ASN as 1 hop (total length 3).
  • An AS_SET (unordered set generated during route aggregation, e.g., {100, 200}) counts as 1 single hop, regardless of how many ASNs are in the set.
  • Can be bypassed globally via bgp bestpath as-path ignore (not recommended in production).
• Step 5: Lowest Origin Code:
  • Evaluates how the prefix was initially introduced into BGP. Order of preference:
    1. IGP (i): Injected via the network command under BGP (Most Preferred).
    2. EGP (e): Learned via the legacy Exterior Gateway Protocol (Historical).
    3. Incomplete (?): Injected via redistribute from another protocol (Least Preferred).
• Step 6: Lowest Multi-Exit Discriminator (MED / Metric):
  • Scope: Optional Non-Transitive attribute sent to external AS peers to influence their inbound ingress path into the local AS.
  • Value Range: 0 to 4,294,967,295. Lower values are preferred (default is 0).
  • The Comparison Rule: By default, BGP only compares MED values if the routes were received from the EXACT SAME neighboring Autonomous System (first ASN in AS_PATH matches). To force comparison across routes from different ASNs, configure bgp always-compare-med.
• Step 7: Prefer eBGP over iBGP:
  • An external eBGP path is preferred over an internal iBGP path. Within confederations, the hierarchy is: $\text{eBGP Path} \; > \; \text{Confederation External Path} \; > \; \text{iBGP Path}$
• Step 8: Lowest IGP Metric to BGP Next-Hop:
  • Evaluates the internal IGP route cost (OSPF cost or EIGRP metric) required to reach the BGP NEXT_HOP IP address. This implements "hot-potato routing", directing packets to the closest egress border router to offload transit traffic immediately.
• Step 9: Multipath (ECMP) Evaluation:
  • If maximum-paths <n> (for eBGP) or maximum-paths ibgp <n> (for iBGP) is configured and candidate routes tie on steps 1 through 8, BGP installs multiple equal-cost paths into the forwarding table (FIB).
• Step 10: Oldest (Most Stable) eBGP Route:
  • For eBGP paths, BGP prefers the route that has been present the longest to prevent route flapping. This step is skipped if bgp bestpath compare-routerid is enabled.
• Step 11: Lowest BGP Router ID (RID):
  • Prefers the route advertised by the peer with the lowest numeric 32-bit BGP Router ID. If a Route Reflector is present, the ORIGINATOR_ID replaces the advertising router's RID in this comparison.
• Step 12: Shortest Cluster List Length:
  • In Route Reflector networks, BGP prefers the path that has traversed the fewest Route Reflector clusters (CLUSTER_LIST length).
• Step 13: Lowest Neighbor IP Address:
  • The final deterministic tie-breaker: prefers the path received from the peer with the lowest numerical IP address defined in the neighbor statement.

3. Administrative Traffic Engineering: Attributes in Practice

Network architects manipulate specific BGP attributes depending on whether they need to control outbound (egress) or inbound (ingress) enterprise traffic flows.

+-----------------------------------------------------------------------------------+
|                       BGP TRAFFIC STEERING MATRIX                                 |
+-----------------------------------------------------------------------------------+
|  OBJECTIVE                  | PRIMARY ATTRIBUTE | SECONDARY ATTRIBUTE | SCOPE     |
+-----------------------------+-------------------+---------------------+-----------|
|  Control Outbound (Egress)  | LOCAL_PREF (100)  | WEIGHT (Cisco only) | AS / Local|
|  Control Inbound (Ingress)  | AS-PATH Prepend   | MED (Metric)        | Inter-AS  |
|  Granular Policy Tagging    | COMMUNITY         | EXTENDED COMMUNITY  | Policy    |
+-----------------------------------------------------------------------------------+

1. Controlling Outbound Traffic: Local Preference vs. Weight

! Example 1: Use Weight (Local Router Scope) to prefer Primary ISP
Edge-1(config)# route-map SET-WEIGHT-PRIMARY permit 10
Edge-1(config-route-map)# set weight 50000
Edge-1(config)# router bgp 65001
Edge-1(config-router-af)# neighbor 203.0.113.2 route-map SET-WEIGHT-PRIMARY in

! Example 2: Use Local Preference (AS-Wide Scope) to steer all internal routers to Primary ISP
Edge-1(config)# route-map SET-LP-PRIMARY permit 10
Edge-1(config-route-map)# set local-preference 200
Edge-1(config)# router bgp 65001
Edge-1(config-router-af)# neighbor 203.0.113.2 route-map SET-LP-PRIMARY in

2. Controlling Inbound Traffic: AS-Path Prepending vs. MED

! Example 1: AS-Path Prepending on Secondary ISP (Makes path 3 hops longer to external peers)
Edge-2(config)# route-map PREPEND-BACKUP permit 10
Edge-2(config-route-map)# set as-path prepend 65001 65001 65001
Edge-2(config)# router bgp 65001
Edge-2(config-router-af)# neighbor 198.51.100.2 route-map PREPEND-BACKUP out

! Example 2: Set MED to 50 on Primary Link and 100 on Secondary Link to same ISP AS 65100
Edge-1(config)# route-map SET-MED-PRIMARY permit 10
Edge-1(config-route-map)# set metric 50
Edge-1(config)# router bgp 65001
Edge-1(config-router-af)# neighbor 203.0.113.2 route-map SET-MED-PRIMARY out

3. BGP Communities (RFC 1997)

A BGP Community is a 32-bit attribute formatted as AA:NN (where AA is the AS number and NN is a policy integer). BGP defines four well-known communities:

1. no-export (0xFFFFFF01): Do not advertise this route to external eBGP peers (retained within local AS / sub-confederation).
2. no-advertise (0xFFFFFF02): Do not advertise this route to any peer (neither eBGP nor iBGP).
3. local-AS / no-export-subconfed (0xFFFFFF03): Do not advertise this route outside the local sub-confederation AS.
4. internet (0x00000000): Standard community; advertise to all peers.

4. Scaling iBGP: Route Reflectors & Confederations

To overcome the quadratic $N(N-1)/2$ full-mesh iBGP scaling barrier, enterprise networks deploy BGP Route Reflectors or BGP Confederations.

1. BGP Route Reflectors (RFC 4456)

A Route Reflector (RR) is a central BGP router that is permitted to re-advertise (reflect) routes learned from one iBGP peer to other iBGP peers, eliminating the need for a full mesh of internal sessions.

The Three Peering Classifications

1. Route Reflector Server: The router configured with reflection policies.
2. RR Client: An iBGP neighbor designated as a client using neighbor <ip> route-reflector-client on the RR. (The client itself requires no special RR configuration; it operates as a standard iBGP peer).
3. Non-Client: A standard iBGP peer that is not configured as an RR client.

The Three Deterministic Reflection Rules

+-----------------------------------------------------------------------------------+
|                         ROUTE REFLECTION PROPAGATION RULES                        |
+-----------------------------------------------------------------------------------+
|  SOURCE OF ROUTE               | REFLECTED TO CLIENTS? | REFLECTED TO NON-CLIENTS?|
+--------------------------------+-----------------------+--------------------------|
|  Learned from eBGP Peer        | YES                   | YES                      |
|  Learned from RR Client        | YES                   | YES                      |
|  Learned from Non-Client       | YES                   | NO (Split-Horizon preserved)|
+-----------------------------------------------------------------------------------+

Core Principle: Routes learned from a Non-Client are never reflected to other Non-Clients. Non-Clients must maintain a full mesh of iBGP sessions among themselves!

Route Reflector Loop Prevention Mechanisms

Because Route Reflectors bypass the iBGP split-horizon rule, BGP introduces two specialized path attributes to prevent internal routing loops:

1. ORIGINATOR_ID (Attribute Type 9, Optional Non-Transitive):
   • A 4-byte attribute created by the first RR that reflects a route. It carries the BGP Router ID of the originating router in the local AS that first injected the prefix.
   • If a router receives an iBGP update where the ORIGINATOR_ID matches its own local Router ID, it immediately drops the update.
2. CLUSTER_LIST (Attribute Type 10, Optional Non-Transitive):
   • A sequence of Cluster IDs (bgp cluster-id <id>, default: RR's Router ID) representing the path of Route Reflectors through which the route has passed.
   • When an RR reflects a route, it prepends its local Cluster ID to the CLUSTER_LIST.
   • If an RR receives an update containing its own Cluster ID within the CLUSTER_LIST, it knows the route has looped and silently discards it.

2. BGP Confederations (RFC 5065)

A BGP Confederation divides a massive Autonomous System (e.g., AS 65000) into multiple smaller, private Sub-Autonomous Systems (e.g., Sub-AS 65001, 65002, 65003).

• External Perspective: Outside external eBGP peers see only the single public Confederation Identifier (AS 65000). The internal sub-AS structure is completely hidden.
• Intra-Confederation Peering: Peering sessions between sub-ASes (e.g., Sub-AS 65001 to Sub-AS 65002) behave like eBGP for loop prevention (recording sub-AS numbers in an AS_CONFED_SEQUENCE inside AS_PATH), but preserve NEXT_HOP, LOCAL_PREF, and MED attributes exactly like iBGP.
• Confederation Stripping: When an edge router advertises a route to a true external eBGP peer, all sub-AS numbers (AS_CONFED_SEQUENCE / AS_CONFED_SET) are automatically stripped from the AS_PATH.

5. Cisco IOS-XE Configuration & Route Reflector Verification

1. Core Route Reflector Configuration (IOS-XE)

! Configure Central Route Reflector (Core-RR, Cluster ID 10.0.0.1)
Core-RR(config)# router bgp 65001
Core-RR(config-router)# bgp router-id 10.0.0.1
Core-RR(config-router)# bgp cluster-id 10.0.0.1
Core-RR(config-router)# no bgp default ipv4-unicast

! Define Client Neighbors
Core-RR(config-router)# neighbor 10.1.1.1 remote-as 65001
Core-RR(config-router)# neighbor 10.1.1.1 update-source Loopback0
Core-RR(config-router)# neighbor 10.2.2.2 remote-as 65001
Core-RR(config-router)# neighbor 10.2.2.2 update-source Loopback0

! Define Non-Client Core Neighbor
Core-RR(config-router)# neighbor 10.3.3.3 remote-as 65001
Core-RR(config-router)# neighbor 10.3.3.3 update-source Loopback0

! Configure IPv4 Unicast Address Family with RR Clients
Core-RR(config-router)# address-family ipv4 unicast
Core-RR(config-router-af)# neighbor 10.1.1.1 activate
Core-RR(config-router-af)# neighbor 10.1.1.1 route-reflector-client
Core-RR(config-router-af)# neighbor 10.2.2.2 activate
Core-RR(config-router-af)# neighbor 10.2.2.2 route-reflector-client
Core-RR(config-router-af)# neighbor 10.3.3.3 activate
Core-RR(config-router-af)# exit-address-family

2. Route Reflector BGP Prefix Inspection (show ip bgp <prefix>)

Core-RR# show ip bgp 198.51.100.0/24
BGP routing table entry for 198.51.100.0/24, version 8
Paths: (1 available, best #1, table default)
  Advertised to update-groups:
     1          2
  Refresh Epoch 1
  65100
    10.1.1.1 (metric 20) from 10.1.1.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best
      Originator: 1.1.1.1, Cluster list: 10.0.0.1
      rx path info: flag 0x41, msgflags 0x0, prio 0