A tax assessor’s border routers see two candidate BGP paths that are equal through AS-path length and origin. Before router-ID becomes the tie-break, which earlier decision steps should the engineer still expect in Cisco’s best-path order?
Select an answer to reveal the explanation.
Short Explanation
BGP best-path is a ranked checklist, not a coin flip at router-ID. Weight and LOCAL_PREF speak first, then AS-path, origin, MED, eBGP-over-iBGP, and IGP distance to the next hop—router-ID is way down the list when everything else tied.
Full Explanation
Cisco’s BGP best-path algorithm applies a fixed order of decision steps. When a tax assessor’s border routers see two candidate paths equal through AS-path length and origin, engineers should still expect earlier and later steps in order: prefer higher LOCAL_PREF, then shorter AS path, then lower origin code, then MED when comparable, then eBGP over iBGP, then lower IGP metric to next hop—before oldest-path or lower router-ID style tie-breaks. Even when AS-path lengths already match, LOCAL_PREF, MED (when applicable), eBGP/iBGP preference, and IGP metric remain relevant earlier or later in that sequence.
It is wrong that IGP metric is ignored until after router-ID and that MED is never compared between different ASes without always-compare configuration caveats being understood as absolute bans. It is wrong that only Weight and then immediate router-ID apply while LOCAL_PREF and MED are skipped when AS paths are equal. It is wrong that eBGP over iBGP preference and IGP metric become irrelevant once AS-path lengths match.
Exam caveat: platform details (oldest path vs router-ID) and always-compare-med change edge cases—know the Cisco order cold for CCIE EI. Operational check: show bgp with path details for the contested prefix, walk each decision step until the winner is explained, and avoid jumping straight to router-ID when an earlier attribute still differs.