Editing Border Gateway Protocol (section)

=== Route selection process ===

The BGP standard specifies a number of decision factors, more than the ones that are used by any other common routing process, for selecting NLRI to go into the Loc-RIB. The first decision point for evaluating NLRI is that its next-hop attribute must be reachable (or resolvable). Another way of saying the next-hop must be reachable is that there must be an active route, already in the main routing table of the router, to the prefix in which the next-hop address is reachable.

Next, for each neighbor, the BGP process applies various standard and implementation-dependent criteria to decide which routes conceptually should go into the Adj-RIB-In. The neighbor could send several possible routes to a destination, but the first level of preference is at the neighbor level. Only one route to each destination will be installed in the conceptual Adj-RIB-In. This process will also delete, from the Adj-RIB-In, any routes that are withdrawn by the neighbor.

Whenever a conceptual Adj-RIB-In changes, the main BGP process decides if any of the neighbor's new routes are preferred to routes already in the Loc-RIB. If so, it replaces them. If a given route is withdrawn by a neighbor, and there is no other route to that destination, the route is removed from the Loc-RIB and no longer sent by BGP to the main routing table manager. If the router does not have a route to that destination from any non-BGP source, the withdrawn route will be removed from the main routing table.

As long as there is [[tiebreaker]] the route selection process moves to the next step.

{| class="wikitable"
|+ Steps to determine best path, in order of [[tiebreaker]]:
<ref>{{cite web |url=https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html |title=BGP Best Path Selection Algorithm |website=[[Cisco]].com}}</ref>

<ref>{{cite web |url=https://www.juniper.net/documentation/us/en/software/junos/vpn-l2/bgp/topics/concept/routing-protocols-address-representation.html |title=Understanding BGP Path Selection |website=[[Juniper]].com}}</ref>

! Step !! Scope !! Name !! Default !! Preferred !! BGP field !! NOTE
|-
| 1 || Local to router || local Weight || {{notnom|"Off"}} || Higher || || Cisco-specific parameter
|-
| 2 || rowspan="2" |Internal to AS || Local preference || {{notnom|"Off", all set to 100.}} || Higher || LOCAL_PREF || If there are several iBGP routes from the neighbor, the one with the highest local preference is selected unless there are several routes with the same local preference.
|-
| 3 || Accumulated Interior Gateway Protocol (AIGP) || {{notnom|"Off"}} || Lowest  || AIGP  || rfc7311
|-
| 4 ||  rowspan="3" |External to AS || Autonomous system (AS) jumps || {{good|"On", skipped if ignored in configuration}} || Lowest  || AS-path || AS jumps is the number of AS numbers that must be traversed to reach the advertised destination. AS1–AS2–AS3 is a shorter path with fewer jumps than AS4–AS5–AS6–AS7.
|-
| 5 ||  origin type || "IGP" || Lowest  || ORIGIN  ||0 = IGP<br />1 = EGP<br />2 = Incomplete
|-
| 6 || multi-exit discriminator (MED) || {{good|"on", imported from IGP}} || Lowest  || MULTI_EXIT_DISC|| By default only route with the same autonomous system (AS) is compared. Can be set to ignore same autonomous system (AS). <br />
By default Internal IGP is not added. Can be set to add IGP metric.
Before the most recent edition of the BGP standard, if an update had no MED value, several implementations created a MED with the highest possible value. The current standard specifies that missing MEDs are treated as the lowest possible value. Since the current rule may cause different behavior than the vendor interpretations, BGP implementations that used the nonstandard default value have a configuration feature that allows the old or standard rule to be selected.
|-
| 7 ||  rowspan="6" |Local to router (Loc-RIB) || eBGP over iBGP paths || "on" ||  ||  || Directly connected, over indirectly
|-
| 8 || IGP metric to BGP next hop || "on", imported from IGP || Lowest  ||  || Continue, even if bestpath is already selected. Prefer the route with the lowest interior cost to the next hop, according to the main routing table. If two neighbors advertised the same route, but one neighbor is reachable via a low-bitrate link and the other by a high-bitrate link, and the [[interior routing protocol]] calculates lowest cost based on highest bitrate, the route through the high-bitrate link would be preferred and other routes dropped.
|-
| 9 ||  Path that was received first || "on" || oldest ||  || Used to ignore changes on the steps 10+
|-
| 10 || Router ID || "on" || Lowest  ||  ||
|-
| 11 || Cluster list length || "on" || Lowest  ||  ||
|-
| 12 || Neighbor address || "on" || Lowest
|}

The local preference, weight, and other criteria can be manipulated by local configuration and software capabilities. Such manipulation, although commonly used, is outside the scope of the standard. For example, the ''community'' attribute (see below) is not directly used by the BGP selection process. The BGP neighbor process can have a rule to set local preference or another factor based on a manually programmed rule to set the attribute if the community value matches some pattern-matching criterion. If the route was learned from an external peer the per-neighbor BGP process computes a local preference value from local policy rules and then compares the local preference of all routes from the neighbor.