A municipal hospital campus WAN learns the same external prefix as both OSPF External Type-1 and Type-2 toward a cloud breakout. Which preference rule should the engineers expect?
Select an answer to reveal the explanation.
Short Explanation
Treat E1 like a taxi meter that keeps adding the in-OSPF miles, and E2 like a flat airport fee that mostly cares about the external tag. When both show up for the same place, OSPF grabs the E1.
Full Explanation
When a municipal hospital campus WAN learns the same external prefix as both OSPF External Type-1 (E1) and External Type-2 (E2) toward a cloud breakout, OSPF prefers External Type-1 over External Type-2 for that identical prefix. E1 metrics include the external metric plus the cost to the ASBR, so they reflect path expense inside the OSPF domain; E2 metrics primarily reflect the external metric and do not add internal cost the same way for comparison against E1. Given both types present for one prefix, the preference rule selects E1—hence the correct hospital engineering expectation. Claiming Type-2 always beats Type-1 regardless of metric reverses the preference rule. Saying OSPF ignores external types and picks only by router ID invents a nonexistent selection rule for same-prefix externals. Asserting Type-1 and Type-2 are equal-cost load-balanced by default with no preference is incorrect; OSPF does not ECMP E1 and E2 together as equivalent types for the same prefix when the type preference applies. Exam caveat: preference among externals is E1 over E2; separately, intra-area still beats inter-area beats external overall—do not confuse type preference within externals with the broader O > O IA > E order. Operational check: for the cloud prefix, show ip route and show ip ospf database external; identify whether competing LSAs are E1 or E2; if both exist unintentionally, fix redistribution metric-type consistency at the ASBRs rather than fighting symptoms with random costs.