From: Tom Larus (tlarus@cox.net)
Date: Fri Apr 20 2007 - 12:21:30 ART
Wendell Odom in his excellent CCIE R&S official prep guide (published February 2006) states on page 445 that if there is a tie among three paths with As-Path length 3, and two other paths with As-Path have as-path length 5, then there is a tie and all five paths (even the ones with as-path length 5) are considered at the next step in the BGP decision process. If this were true, then it would lead to some unexpected results, where a path with a lower MED could actually end up being selected over several paths with shorter as-path length.
RFC 4271 9.2.2 (issued in January 2006, just before the Odom book was published and probably after the book was written) says the opposite about the way tie-breaking is handled in the BGP decision process. It says:
RFC 4271 9.1.2.2 says the opposite-- that all the paths that did not tie for shortest as-path length are removed from consideration as we go down the line, and so on. Look at (a) below, and (b), and so on:
9.1.2.2. Breaking Ties (Phase 2)
In its Adj-RIBs-In, a BGP speaker may have several routes to the same destination that have the same degree of preference. The local speaker can select only one of these routes for inclusion in the associated Loc-RIB. The local speaker considers all routes with the same degrees of preference, both those received from internal peers, and those received from external peers.
The following tie-breaking procedure assumes that, for each candidate route, all the BGP speakers within an autonomous system can ascertain the cost of a path (interior distance) to the address depicted by the NEXT_HOP attribute of the route, and follow the same route selection algorithm.
The tie-breaking algorithm begins by considering all equally preferable routes to the same destination, and then selects routes to be removed from consideration. The algorithm terminates as soon as only one route remains in consideration. The criteria MUST be applied in the order specified.
Several of the criteria are described using pseudo-code. Note that the pseudo-code shown was chosen for clarity, not efficiency. It is not intended to specify any particular implementation. BGP implementations MAY use any algorithm that produces the same results as those described here.
**** a) Remove from consideration all routes that are not tied for
having the smallest number of AS numbers present in their
AS_PATH attributes. ********** Note that when counting this number, an
AS_SET counts as 1, no matter how many ASes are in the set.
b) Remove from consideration all routes that are not tied for
having the lowest Origin number in their Origin attribute.
c) Remove from consideration routes with less-preferred
MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
between routes learned from the same neighboring AS (the
neighboring AS is determined from the AS_PATH attribute).
Routes that do not have the MULTI_EXIT_DISC attribute are
considered to have the lowest possible MULTI_EXIT_DISC value.
This is also described in the following procedure:
for m = all routes still under consideration
for n = all routes still under consideration
if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
remove route m from consideration
So which is the way that Cisco routers currently handle this? I tried to search Cisco's website for release notes addressing this.
Best regards,
Tom Larus, CCIE #10,014
This archive was generated by hypermail 2.1.4 : Tue May 01 2007 - 08:28:36 ART