A county courts campus enables keyed MD5 authentication on named-mode EIGRP, after which one peer remains down while others form. What should operators treat as the most likely adjacency blocker?
Select an answer to reveal the explanation.
Short Explanation
If three peers wave the same secret handshake and one does not, that loner never gets past the door. Auth mismatch kills adjacency before variance, stubs, or leak-maps even matter. Match the key chain and string first.
Full Explanation
EIGRP authentication must agree on both sides; a key-chain or key-string mismatch prevents adjacency. After a county courts campus enables keyed MD5 authentication on named-mode EIGRP and one peer remains down while others form, configuration asymmetry on that pair—wrong key, wrong key-id, or key-chain application—is the most likely adjacency blocker. Authentication failures present as missing neighbors, not as mysterious metric issues.
A variance value that is too low for unequal-cost load balancing affects whether feasible successors are used for sharing traffic after adjacency exists; it does not block neighbor formation. An EIGRP stub flag constrains query scope and advertisement roles after (or as part of) adjacency design, but a stub mismatch is not the first place to look when authentication was just enabled and only one peer fails. A missing leak-map on a summary influences which prefixes are advertised, not whether hellos authenticate.
Exam caveat: named-mode authentication is configured under the address-family/interface hierarchy—verify the key is applied where the peer actually forms. Operational check: compare key-chains and key-strings on the failing pair, watch debug or logs for auth failures, bring the neighbor up with matching keys, and leave working peers untouched.