What is BGP Path Selection? All 13 Steps of the Best Path Algorithm

BGP needs a multi-step algorithm because it operates in a policy-rich environment where no single metric captures business intent. Unlike OSPF or EIGRP, which optimize for shortest path or lowest delay, BGP must honor commercial agreements (prefer routes from paid transit over free peering), political constraints (avoid certain AS paths for geopolitical reasons), and traffic engineering goals (balance load across multiple links). The 13 steps encode a hierarchy of decision criteria, starting with locally significant attributes (Weight, LOCAL_PREF) that reflect operator policy, then moving to globally visible attributes (AS_PATH, ORIGIN, MED) that reflect inter-domain reachability, and finally tie-breakers (Router ID, neighbor address) that ensure deterministic selection even when all policy attributes are equal. RFC 4271 §9.1.2 defines the core algorithm, but vendors extend it: Cisco's proprietary Weight attribute (step 1) has no standard equivalent; Juniper uses a different default LOCAL_PREF value (100 vs Cisco's 100). The algorithm is always evaluated left-to-right: if step 3 (locally originated check) produces a winner, steps 4–13 are never consulted for that prefix. This strict ordering prevents routing loops and ensures that every BGP speaker in an AS makes the same best-path decision for iBGP-learned routes, critical for consistent forwarding in large networks. In production, path selection directly impacts revenue: an ISP that misconfigures LOCAL_PREF might send customer traffic over expensive transit instead of settlement-free peering, costing thousands of dollars per month. A content delivery network that fails to prepend AS_PATH to certain peers will attract unwanted traffic, saturating links. The 13-step algorithm is not academic—it is the contract between network operators and the global routing system.

Weight is a Cisco-proprietary attribute, locally significant to the router where it is configured, and never transmitted in BGP UPDATE messages. It ranges from 0 to 65535; higher values are preferred. Weight is evaluated before any RFC-defined attribute, making it the ultimate local policy knob: an operator can override all other path selection logic by setting Weight on a specific route. Common use case: A dual-homed enterprise receives the same prefix from two ISPs. The network team wants all outbound traffic to prefer ISP-A (lower cost) unless ISP-A fails. They configure neighbor <ISP-A-peer> weight 200 and leave ISP-B at the default Weight 0. Now all routes learned from ISP-A win step 1, and the router never evaluates LOCAL_PREF, AS_PATH, or any other attribute for those prefixes. Weight is not propagated to other routers, even within the same AS. If Router-A sets Weight 200 on a route and advertises it via iBGP to Router-B, Router-B sees Weight 0 (or its own locally configured value). This makes Weight unsuitable for AS-wide policy—use LOCAL_PREF instead for that. Weight is typically set via route-maps applied inbound on a neighbor: route-map SET_WEIGHT permit 10 / set weight 150. In our HSR Layout lab, we demonstrate Weight manipulation in a scenario where a student's router receives 0.0.0.0/0 from three upstream peers (two ISPs + one IX peering). By setting different Weight values per neighbor, students observe real-time best-path changes in show ip bgp output and correlate them with traffic flow using NetFlow data. This hands-on exercise clarifies why Weight exists: it is the only attribute that survives a route reflector or confederation boundary without being altered, because it never enters the wire protocol.

LOCAL_PREF (Local Preference) is a well-known discretionary attribute defined in RFC 4271 §5.1.5, carried in iBGP UPDATE messages but stripped from eBGP advertisements. It is a 32-bit unsigned integer; higher values are preferred. LOCAL_PREF is the primary tool for AS-wide egress path selection: all routers in the AS see the same LOCAL_PREF value for a given route, ensuring consistent forwarding decisions. Default value: Cisco and Juniper both use 100. If a route is learned via eBGP and no LOCAL_PREF is explicitly set, the router assigns 100 before redistributing the route into iBGP. If a route is learned via iBGP and carries no LOCAL_PREF attribute, RFC 4271 behavior is undefined—most implementations treat it as 100, but this is not guaranteed. Common use case: An AS has two exit points to the Internet—one via a paid transit provider (expensive, high capacity) and one via a regional IX (free, lower capacity). The operator wants to prefer the IX for all prefixes learned there, falling back to transit only if the IX route is unavailable. On the border router peering at the IX, they apply: route-map PREFER_IX permit 10 / set local-preference 200. On the transit border router, they leave LOCAL_PREF at default 100. Now all internal routers receive both routes via iBGP, compare LOCAL_PREF at step 2, and install the IX route as best path. LOCAL_PREF is not transitive across AS boundaries. When the border router advertises the best path to an eBGP peer, it strips LOCAL_PREF from the UPDATE. This is by design: LOCAL_PREF reflects internal policy, which neighboring ASes have no business seeing. Attempting to set LOCAL_PREF on an eBGP session (e.g., neighbor x.x.x.x route-map SET_LP out) has no effect—the attribute is silently discarded. In CCNP ENARSI labs (350-401 blueprint §3.2), students configure LOCAL_PREF to implement hot-potato routing: prefer the nearest exit point to reach external destinations, minimizing intra-AS path cost. A common pitfall: setting LOCAL_PREF on a route-map applied outbound on an iBGP neighbor—this works, but the route-map runs after the best-path decision, so the router has already chosen a best path based on the old LOCAL_PREF. Correct practice: set LOCAL_PREF inbound on the eBGP session where the route enters the AS.

Step 3 prefers routes that the local router itself injected into BGP via the network command, aggregate-address, or redistribution from another protocol. These routes have no NEXT_HOP attribute pointing to an external peer—they are "locally originated" in the sense that this router is the authoritative source. The check is binary: if one candidate path is locally originated and the other is learned from a peer, the locally originated path wins immediately, and steps 4–13 are skipped. If both paths are locally originated (e.g., the same prefix is injected via network and also via aggregate-address), the algorithm proceeds to step 4. Why does this step exist? It prevents a router from preferring a learned route over its own authoritative announcement. Consider a router that originates 10.0.0.0/8 via network 10.0.0.0 mask 255.0.0.0 and also receives 10.0.0.0/8 from an iBGP peer (which learned it from this router via route reflection). Without step 3, the router might prefer the reflected route if it has higher LOCAL_PREF or shorter AS_PATH due to policy manipulation elsewhere in the AS. Step 3 ensures the originating router always prefers its own announcement, maintaining loop-free topology. Common pitfall: Operators use network to originate a summary route but forget to configure a static discard route (e.g., ip route 10.0.0.0 255.0.0.0 Null0). If no component subnet of 10.0.0.0/8 exists in the RIB, the network statement has no effect, and the router never originates the route. The route then appears to be "learned" from an iBGP peer (who successfully originated it), and step 3 does not apply. Correct practice: always pair network with a matching RIB entry, typically a static discard route for summaries. In our 4-month paid internship at the Network Security Operations Division, interns troubleshoot production incidents where a data center router oscillates between locally originated and iBGP-learned paths for the same prefix due to flapping IGP routes. They learn to use show ip bgp <prefix> to identify the "Local" flag (indicates locally originated) and correlate it with show ip route to verify RIB presence. This real-world debugging skill is rarely taught in vendor courses but is critical for NOC engineers.

AS_PATH is a well-known mandatory attribute (RFC 4271 §5.1.2) that records the sequence of autonomous systems a route has traversed. Each AS prepends its own AS number when advertising a route to an eBGP peer. Step 4 counts the number of AS numbers in the AS_PATH and prefers the route with the fewest ASes—this approximates shortest inter-domain path. AS_PATH serves two purposes: loop prevention (a router discards any UPDATE containing its own AS number in the path) and policy (operators can prepend extra copies of their AS number to make a route less attractive). For example, AS 65001 advertises 192.0.2.0/24 with AS_PATH 65001. When AS 65002 receives it and re-advertises to AS 65003, the path becomes 65002 65001. If AS 65001 wants to discourage inbound traffic via AS 65002, it can prepend: route-map PREPEND permit 10 / set as-path prepend 65001 65001 65001, resulting in AS_PATH 65001 65001 65001 65001 as seen by AS 65002's peers. Now any AS comparing this route to an alternative path with fewer hops will prefer the alternative at step 4. AS_PATH length is counted after removing AS_SET and AS_CONFED_* segments. An AS_SET (used in route aggregation when component routes have different AS_PATHs) counts as 1 regardless of how many AS numbers it contains. AS_CONFED_SEQUENCE and AS_CONFED_SET (used within BGP confederations, RFC 5065) are ignored entirely for path length calculation—they are stripped before advertising to non-confederation peers. Common mistake: Operators prepend their AS number on inbound route-maps, expecting to influence their own path selection. This has no effect—prepending must be done outbound to neighbors, so those neighbors see the longer path and de-prefer it. Correct use case: AS 65001 has two upstream providers and wants to load-balance inbound traffic 70/30. They prepend once to the 30% provider, making that path length 2 vs length 1 for the 70% provider. Upstream ASes then prefer the shorter path, shifting traffic accordingly. In CCIE lab scenarios, candidates must implement AS_PATH filtering using ip as-path access-list to block routes from specific origin ASes (e.g., filter all routes originating from AS 65123 due to a security incident). This requires understanding AS_PATH regex: _65123$ matches routes originated by AS 65123 (AS number appears at the end), while _65123_ matches routes that transit AS 65123 (AS number appears mid-path).

ORIGIN is a well-known mandatory attribute (RFC 4271 §5.1.1) that indicates how the route was injected into BGP at its origin AS. Three values exist: IGP (code 0), EGP (code 1), and INCOMPLETE (code 2). Step 5 prefers IGP over EGP over INCOMPLETE—lower numeric code wins. IGP (code 0): Route was injected via the network command. The name "IGP" is historical (it originally meant the route was learned from an Interior Gateway Protocol like OSPF), but in modern BGP it simply means "injected via network statement." This is the most trustworthy origin because the operator explicitly listed the prefix in BGP configuration. EGP (code 1): Route was learned from the Exterior Gateway Protocol, a predecessor to BGP that is now obsolete (last defined in RFC 904, 1984). No modern router sets ORIGIN to EGP. If you see EGP in a production network, it indicates a misconfiguration or a very old device. Treat it as a red flag. INCOMPLETE (code 2): Route was injected via redistribution from another protocol (redistribute ospf, redistribute static, etc.) or via aggregate-address without the summary-only keyword. INCOMPLETE signals uncertainty about the route's true origin—it might be a static route, a connected interface, or a dynamically learned IGP route. Because the origin is ambiguous, INCOMPLETE is least preferred. In practice, step 5 rarely decides the best path because most production networks use network statements (IGP origin) for all BGP-advertised prefixes. Redistribution is discouraged due to lack of control: redistributing OSPF into BGP can inject thousands of internal routes into the global table, and redistributing static routes risks leaking infrastructure prefixes (loopbacks, management networks) to the Internet. Common pitfall: An operator uses aggregate-address 10.0.0.0 255.0.0.0 to summarize component routes learned via redistribution. The aggregate inherits ORIGIN INCOMPLETE from the component routes. If a peer also advertises 10.0.0.0/8 with ORIGIN IGP, step 5 prefers the peer's route, and the local aggregate is not used. Fix: Use aggregate-address 10.0.0.0 255.0.0.0 summary-only to suppress component routes and explicitly set ORIGIN to IGP via route-map SET_ORIGIN permit 10 / set origin igp applied to the aggregate. In our HSR Layout lab, students configure three routers in a triangle topology, each originating the same prefix with different ORIGIN codes (one via network, one via redistribute static, one via aggregate-address). They observe show ip bgp output to see step 5 in action and learn to identify ORIGIN in UPDATE messages using Wireshark (ORIGIN is a 1-byte attribute, type code 1, appearing early in the path attribute list).

MED (Multi-Exit Discriminator) is an optional non-transitive attribute (RFC 4271 §5.1.4) that allows an AS to suggest to a neighboring AS which entry point to prefer when multiple links connect the two ASes. Lower MED values are preferred. MED is only compared between routes learned from the same neighboring AS—routes from different ASes are not compared at step 6 unless bgp always-compare-med is configured (non-default, not recommended). Example: AS 65001 is dual-homed to AS 65002 via two routers, R1 and R2. AS 65001 wants inbound traffic for 192.0.2.0/24 to prefer the R1 link. AS 65001 advertises 192.0.2.0/24 to R1 with MED 50 and to R2 with MED 100. When AS 65002's border routers receive both advertisements, they compare MED at step 6 (because both routes are from AS 65001) and prefer the R1 path (MED 50 < 100). MED is non-transitive: when AS 65002 re-advertises 192.0.2.0/24 to AS 65003, it strips the MED attribute. This prevents AS 65001's internal policy from influencing routing decisions in AS 65003. However, some operators configure set metric in outbound route-maps to set MED on advertisements to peers, effectively using MED as an inter-AS metric. This is controversial because it violates the non-transitive principle and can cause unexpected path selection in downstream ASes. Default MED behavior: If a route has no MED attribute, Cisco treats it as MED 0 (most preferred) by default. This can cause problems: a route with explicit MED 10 loses to a route with no MED (treated as 0). To fix this, configure bgp bestpath med missing-as-worst, which treats missing MED as 4294967295 (least preferred). This is recommended for consistent behavior. Common pitfall: Operators set MED on routes advertised to different ASes and expect step 6 to compare them. It does not—step 6 only compares MED for routes from the same neighbor AS. If you need to compare MED across ASes, enable bgp always-compare-med, but be aware this can cause routing instability if different ASes use different MED scales (one AS uses 0–100, another uses 0–10000). In CCNP ENARSI labs, students configure MED to implement cold-potato routing: prefer the entry point that minimizes path cost within the neighboring AS, even if it increases path cost within your own AS. This is the opposite of hot-potato routing (step 8, prefer nearest exit). The lab demonstrates that MED is a suggestion—the neighboring AS can ignore it by setting LOCAL_PREF to override step 6.

Step 7 prefers routes learned from an external BGP peer (eBGP) over routes learned from an internal BGP peer (iBGP). This step exists to prevent routing loops in ASes that do not use route reflectors or confederations: if a border router learns a route via eBGP and advertises it to internal peers via iBGP, those internal peers must not re-advertise the route back to the border router (iBGP split-horizon rule). Step 7 ensures the border router always prefers its own eBGP-learned route over any iBGP reflection of that route. The check is binary: if one candidate path is eBGP and the other is iBGP, the eBGP path wins immediately. If both paths are eBGP or both are iBGP, the algorithm proceeds to step 8. In route reflector topologies, step 7 can cause suboptimal routing. Consider: Client-A learns prefix 10.0.0.0/8 from an eBGP peer with AS_PATH length 3. Route Reflector (RR) also learns 10.0.0.0/8 from a different eBGP peer with AS_PATH length 2 and reflects it to Client-A. Client-A now has two paths: its own eBGP path (length 3) and the reflected iBGP path (length 2). Step 7 prefers the eBGP path (length 3), even though the iBGP path is shorter. This is called route reflector suboptimality. Fix: Configure bgp bestpath as-path multipath-relax on Client-A. This command modifies step 7 to allow iBGP and eBGP paths to proceed to step 8 (IGP metric comparison) instead of stopping at step 7. Now Client-A compares IGP cost to the NEXT_HOP of each path and chooses the shortest intra-AS path, which is often the reflected route. Note: This command also affects multipath installation (allows iBGP and eBGP paths to coexist in the RIB for load balancing). Another scenario: An AS uses iBGP full mesh (no route reflectors). A border router learns the same prefix from two eBGP peers. It chooses one as best path (based on steps 1–6) and advertises it to all iBGP peers. Those peers now have one iBGP path. Later, one of those peers establishes its own eBGP session to a third AS and learns the same prefix via eBGP. Step 7 ensures this peer prefers its own eBGP path over the iBGP path from the original border router, preventing a loop where the peer tries to forward traffic back to the border router. In our 4-month paid internship, interns work on a live MPLS backbone where route reflectors serve 200+ PE routers. They troubleshoot cases where a PE router selects a suboptimal path due to step 7, then implement bgp bestpath as-path multipath-relax and measure the traffic shift using SNMP polling of interface counters. This hands-on experience with RR suboptimality is critical for roles at Cisco India, HCL, and Aryaka, where large-scale BGP deployments are common.

Step 8 prefers the route whose NEXT_HOP address is reachable via the lowest-cost IGP path. This is called hot-potato routing: forward the packet to the nearest exit point (lowest intra-AS cost), even if that exit point leads to a longer inter-AS path. The goal is to minimize the distance the packet travels within your AS, offloading it to the neighboring AS as quickly as possible. The IGP metric is the cost to reach the NEXT_HOP as reported by the IGP (OSPF cost, EIGRP metric, IS-IS metric, or static route administrative distance + metric). For eBGP routes, NEXT_HOP is the IP address of the eBGP peer. For iBGP routes, NEXT_HOP is typically the loopback of the border router that learned the route via eBGP (unless next-hop-self is configured). Example: Router-A in AS 65001 has two iBGP peers: Border-1 (IGP cost 10 to reach its loopback) and Border-2 (IGP cost 50). Both borders advertise prefix 192.0.2.0/24 with identical LOCAL_PREF, AS_PATH, ORIGIN, and MED. Router-A compares the IGP cost to each border's NEXT_HOP at step 8 and prefers Border-1 (cost 10 < 50). Traffic from Router-A to 192.0.2.0/24 exits via Border-1, even if Border-2's eBGP path has fewer AS hops. Step 8 is the primary driver of traffic flow in large ASes. It explains why adding a new PoP (point of presence) in a distant city can shift traffic patterns across the entire network: if the new PoP peers with an IX and advertises routes via iBGP, routers near the new PoP will prefer those routes at step 8 due to lower IGP cost, even if the IX path is longer than existing transit paths. Common pitfall: Operators configure next-hop-self on iBGP sessions to simplify NEXT_HOP reachability (avoids needing to redistribute eBGP peer IPs into IGP). This causes all iBGP routes to have the same NEXT_HOP (the route reflector's loopback), so step 8 cannot differentiate between paths. All routes tie at step 8 and proceed to step 9 (oldest route). This can cause suboptimal routing. Fix: Use next-hop-self only on route reflectors, not on clients. Clients should preserve the original eBGP NEXT_HOP so step 8 can compare IGP costs to different border routers. In CCIE Routing & Switching lab (now CCIE Enterprise Infrastructure), candidates must configure OSPF costs to influence BGP path selection via step 8. A common task: "Ensure Router-A prefers Border-1 for all Internet routes without modifying any BGP attributes." Solution: Increase OSPF cost on the link between Router-A and Border-2, making the IGP path to Border-2's loopback more expensive. Router-A then prefers Border-1 at step 8. This demonstrates that BGP and IGP are tightly coupled—you cannot optimize BGP without understanding IGP topology.

If steps 1–8 fail to produce a winner, the algorithm proceeds to tie-breakers that ensure deterministic selection even when all policy-relevant attributes are identical. Step 9: Prefer oldest route (lowest uptime). Among routes with equal attributes, prefer the route that has been in the BGP table the longest. This promotes stability: if two paths are equally good, keep using the one you are already using rather than flapping to the new one. Caveat: This step is skipped if bgp bestpath compare-routerid is configured (see step 11). Oldest route is identified by the "Last update" timestamp in show ip bgp <prefix>. Step 10: Prefer route from BGP neighbor with lowest Router ID. Router ID is a 32-bit identifier, typically the highest loopback IP or highest physical interface IP if no loopback exists. Lower Router ID wins. This step ensures that in a full-mesh iBGP topology, all routers agree on the same best path for a given prefix (assuming steps 1–9 are tied). Without this step, Router-A might prefer the path from Router-B (higher Router ID) while Router-C prefers the path from Router-D (lower Router ID), causing inconsistent forwarding and potential loops. Step 11: Prefer route with shortest cluster list length (route reflector environments only). A cluster list is an optional non-transitive attribute (RFC 4456 §8) that records the sequence of route reflector clusters a route has traversed. Each route reflector prepends its cluster ID when reflecting a route to a client. Step 11 counts the number of cluster IDs and prefers the route with the fewest—this approximates shortest intra-AS path in RR topologies. If a route has no cluster list (it was not reflected), it is treated as length 0 (most preferred). This step only applies if the routes being compared are both iBGP and at least one has a cluster list. Step 12: Prefer route from neighbor with lowest neighbor IP address. If all else is equal, compare the IP address of the BGP neighbor that advertised the route. Lower IP wins. This is the final tie-breaker for eBGP routes (which have no cluster list). For iBGP routes, step 11 usually decides before reaching step 12. In practice, steps 9–13 rarely matter in production networks because steps 1–8 (policy attributes and IGP metric) almost always produce a winner. However, these tie-breakers are critical in lab scenarios and during network failures. Example: A route reflector has two clients, both advertising the same prefix with identical attributes. The RR must choose one to advertise to other clients. Step 11 (cluster list) is tied (both routes have no cluster list, since they came from clients, not other RRs). Step 12 (lowest neighbor IP) decides: the RR prefers the route from the client with the lower IP address. Common mistake in CCIE labs: Candidates configure bgp bestpath compare-routerid expecting it to enable step 10 (Router ID comparison). It does, but it also disables step 9 (oldest route). This can cause route flapping: every time a route is withdrawn and re-advertised, the router re-evaluates step 10 and might switch to a different path, even though the old path is still valid. Use bgp bestpath compare-routerid only when you need deterministic path selection across all routers in the AS and are willing to sacrifice stability (oldest route preference). In our HSR Layout lab, we run a 10-router full-mesh iBGP topology where students inject the same prefix from multiple routers with carefully crafted attributes to force tie-breaking at each step 9–13. They use debug ip bgp updates and show ip bgp <prefix> to observe which step decides the best path. This deep dive into tie-breakers is rarely covered in online courses but is essential for understanding why BGP behaves the way it does in complex topologies.