Decision Process

Decision Process
The decision process is the actual process that decides what routes the BGP speaker will accept,
the routes it will use locally, and the routes it will advertise to its peers. The decision process is
broken down into three distinct phases:
 Phase 1 is responsible for calculating the degree of preference for a route learned from a
neighboring AS. This phase is also responsible for advertising the routes with the highest
degree of preference to the BGP speakers in the local AS.
 Phase 2 occurs after the completion of phase 1. Phase 2’s responsibilities include deciding
which route to a specified destination is the best. It then stores this route in the BGP
speaker’s Loc-RIB. The BGP speaker uses the routes installed during this phase for making
BGP routing decisions.
10
3 11
4
1
2
5
8
9
6
7
Adj-RIBs-In Loc-RIB Adj-RIBs-Out
Inbound
Policy
Engine
Outbound
Policy
Engine
254 Chapter 8  Border Gateway Protocol
 Phase 3 begins once the Loc-RIB of the BGP speaker is updated. Phase 3 is when a BGP
speaker will determine, based on the policies set in the outbound policy engine, which
routes it will advertise to peers in neighboring autonomous systems. Route aggregation can
also be performed during this phase.
This is a high-level view of the decision process. We will now take a more in-depth look at
what actually occurs during each of the three phases.
Phase 1
Phase 1 is also known as the Calculation of Degree Preference phase. Whenever a BGP
speaker receives an UPDATE message from a peer in a neighboring AS, phase 1 will begin.
Once the BGP speaker receives the UPDATE message, it locks the Adj-RIB-In used for that
peer. The BGP speaker leaves the Adj-RIB-In locked until the completion of phase 1. For
each feasible route the BGP speaker receives, it calculates the degree of preference. The
degree of preference is the attractiveness of a route. The BGP speaker calculates the degree
of preference based on the locally preconfigured policy.
Phase 2
Phase 2 is also known as the Route Selection phase. As soon as phase 1 is complete, phase 2 will
initiate. During phase 2, the BGP speaker will lock all of its Adj-RIBs-In and unlock them once
the phase is complete. At this point, any routes that have a NEXT_HOP attribute set to an
address the BGP speaker doesn’t have a route to should be excluded. The BGP speaker will
select a route that is the only route to a destination to put in the Loc-RIB. If multiple routes exist
to the same destination, the BGP speaker will select the route with the highest degree of preference.
This route will then be inserted into the BGP speaker’s Loc-RIB. In the case that multiple
routes exist to the same destination and they have the same degree of preference, the following
tiebreaking rules will apply, in order:
 If the BGP speaker is configured to use the MULTI_EXIT_DISC (MED) and the MEDs of
the routes differ, the BGP speaker will select the route with the lowest MED.
 If the BGP speaker is not configured to use the MED or the MEDs do not differ, the BGP
speaker will select the route with the lowest cost to the next-hop address.
 If the cost of the routes does not differ, the BGP speaker will select the route that was advertised
by a BGP speaker in a neighboring AS with the lowest BGP identifier.
 If the route was not advertised by a BGP speaker in a neighboring AS, the BGP speaker will
select the route advertised by the iBGP peer with the lowest BGP identifier.
Phase 3
Phase 3 is also known as the Route Dissemination phase. Phase 3 will initiate when any of the
following four events occur:
 When phase 2 completes.
 When routes, stored in the Loc-RIB, to local destinations change.
 When any locally generated routes, not learned by BGP, change.
 When a new BGP connection has been established.
BGP Operation 255
During phase 3, the routes stored in the Loc-RIB will be passed through the outbound
policy engine. The routes that make it through the outbound policy engine are then placed
in the Adj-RIBs-Out. These are the routes that the BGP speaker advertises to its peers. The
BGP speaker can optionally perform route aggregation during this phase.
Cisco’s implementation of BGP uses the following steps, in order, for route selection, assuming
that BGP Multipath for load sharing is not enabled:
1. If the route specifies a next hop that is inaccessible, drop the update.
2. Prefer the route with the largest weight.
3. If the weights are the same, prefer the route with the largest local preference.
4. If the local preferences are the same, prefer the route that was originated by BGP running
on this router, with those produced by the network or redistribute commands preferred
over those produced by the aggregate-address command.
5. If no route was locally originated, prefer the route that has the shortest AS_PATH. For purposes
of making this choice, all AS_SETs count as one, regardless of the size of the set.
Additionally, confederation AS counts are not included.
6. If all routes have the same AS_PATH length, prefer the route with the lowest origin type,
where IGP is lower than EGP, and EGP is lower than INCOMPLETE. INCOMPLETE
routes generally come from redistribution.
7. If the origin codes are the same, prefer the route with the lowest MED attribute.
8. If the routes have the same MED, prefer the eBGP-learned route over the iBGP-learned route.
9. If the routes are still the same, prefer the route through the lowest IGP metric to the BGP
next hop.
10. Prefer the route advertised by the BGP router with the lowest BGP router ID.
11. Prefer the path with the shortest cluster list length. (Refer to Chapter 9 for discussions on
route reflection.)
12. Prefer the path advertised by the neighbor with the lowest IP address, as determined by the
address used in the neighbor command for the remote TCP peer connection.
The system administrator can affect the routing decisions a BGP speaker makes. The way this
is done is through route filtering.