After a change window, a county network team finds EIGRP adjacencies down between two civic hubs. Show commands reveal mismatched K-values. What is the expected result?
Select an answer to reveal the explanation.
Short Explanation
K-values are the shared recipe both kitchens must use to score routes. If county hub A cooks with different spices than hub B, they will not even sit down as neighbors—EIGRP just walks away. Fix the recipe match, then adjacency comes back.
Full Explanation
EIGRP requires identical K-values (metric weights) on both ends of a link before an adjacency can form. After a county civic-hub change window, mismatched K-values are a classic reason neighbors stay down even when AS numbers, IP reachability, and authentication otherwise look correct. The protocol will not form a working neighbor relationship under conflicting metric recipes because DUAL metric comparison would be meaningless across peers that score paths differently. Restoring matching K-values on both hubs is the corrective path.
Claiming neighbors form normally but unequal-cost load balancing is merely disabled fails by concept: the adjacency itself is refused, not formed with a limited variance feature. Claiming neighbors form with infinite metric until a clear command fails because the neighbor state does not establish under K mismatch. Claiming EIGRP averages the K-values and continues with only a syslog warning fails—there is no averaging reconciliation that preserves adjacency through divergent metric weights.
Exam caveat: K-value mismatch is one of several adjacency gates (AS, auth, passive-interface, primary address, timers on some platforms); fix K-values but still verify the full neighbor checklist if hubs remain down. Operational check for the county hubs: compare metric weights on both devices (show run / show ip protocols), align K-values, clear or wait for adjacency, and confirm neighbors reach a stable state before validating court or civic prefixes.