|
| |
Route Selection
The BGP standard specifies a number of decision factors, more than 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 located.
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.
Per-Neighbor Decisions
After verifying that the next hop is reachable, if the route comes from an
internal (i.e., iBGP) peer, the first rule to apply, according to the standard,
is to examine the LOCAL_PREF attribute. If there are several iBGP routes from
the neighbor, the one with the lowest LOCAL_PREF is selected, unless there are
several routes with the same LOCAL_PREF. In the latter case, the route selection
process moves to the next tie-breaker. While LOCAL_PREF is the first rule in the
standard, once reachability of the NEXT_HOP is verified, Cisco and several other
vendors first consider a decision factor called WEIGHT, which is local to the
router (i.e., not transmitted by BGP). The route with the highest WEIGHT is
preferred.
LOCAL_PREF, WEIGHT, and other criteria can be manipulated by local configuration
and software capabilities. Such manipulation is outside the scope of the
standard but is commonly used. For example, the COMMUNITY attribute (see below)
is not directly used by the BGP selection process. The BGP neighbor process,
however, 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.
At the per-neighbor level, ignoring implementation-specific policy modifiers,
the order of tie-breaking rules is:
Prefer the route with the shortest AS_PATH. An AS_PATH is the set of AS numbers
that must be traversed to reach the advertised destination. AS1-AS2-AS3 is
shorter than AS4-AS5-AS6-AS-7.
Prefer routes with the lowest value of their ORIGIN attribute.
Prefer routes with the lowest MULTI_EXIT_DISC (multi-exit discriminator or MED)
value.
Before the most recent edition of the BGP standard, if an UPDATE had no
MULTI_EXIT_DISC value, several implementations created an MED with the least
possible value. The current standard, however, specifies that missing MEDs are
to be treated as the highest possible value. Since the now-specified 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.
| |
|
