An emergency-management office cannot form EIGRP neighbors on a transit link after a change window. Investigation shows passive-interface was applied to that transit interface. What is the direct effect causing the adjacency failure?
Select an answer to reveal the explanation.
Short Explanation
Passive on a transit link is like putting the radio on receive-only—you announce the subnet from elsewhere, but you never say hello on that wire. No hellos means no neighbor. Move passive to user-facing edges, not the links that must peer.
Full Explanation
EIGRP passive-interface stops hello transmission and adjacency formation on the specified interface while still allowing the connected network to be advertised out other non-passive interfaces. When an emergency-management office cannot form EIGRP neighbors on a transit link after applying passive-interface there, that suppression of hello and update exchange on the transit interface is the direct cause of the adjacency failure. Misapplying passive on a required peer link is a common post-change outage in civic WANs.
Passive-interface does not encrypt hellos so peers need IPsec to parse them. It does not raise the interface metric above the feasible-successor threshold forever as its defining effect. It does not convert the link to OSPF broadcast type or rewrite EIGRP timers into OSPF behavior. Those distractors confuse passive with authentication, metric math, or protocol migration.
Exam caveat: passive-interface default plus selective no passive-interface is a common hardening pattern on LAN edges—just never leave it on transit peer links that must form neighbors. Operational check: remove passive from the transit interface, confirm hellos resume and adjacency reaches up, verify the connected prefix still advertises appropriately, and audit which interfaces are intentionally passive after the change window.