350-401 Practice Question: Is configuring EIGRP on a router that connects to…

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  The 'passive-interface' command also prevents EIGRP from sending routing updates on that interface.

  Why this is correct

  In EIGRP, the passive-interface command does far more than suppress hello packets; it completely disables the protocol on the specified interface for both control and data-plane updates. Specifically, the router will neither send nor receive EIGRP hello packets, which prevents the formation of any neighbor adjacency, and it will also suppress the transmission of all routing updates (unicast or multicast) out that interface. This is why remote sites stop receiving routes: even though the adjacency may have existed before, once passive-interface is applied, the router no longer advertises any learned routes over that link. The command is often used on LAN-facing interfaces to stop unnecessary multicasts, but on a WAN link it effectively isolates the remote site from the EIGRP domain.

• ✗

  The 'passive-interface' command only affects hello packets, not updates, but the remote sites are not configured correctly.

  Why it's wrong here

  This statement is incorrect on two counts. First, the passive-interface command in EIGRP does not distinguish between hello and update packets—it suppresses both hello and all routing updates, effectively muting the interface for EIGRP traffic. Second, while misconfiguration at the remote sites could cause issues, the scenario clearly states that routes were received before the passive-interface command was applied, so the remote configuration is not the root cause. The passive-interface command is the direct reason the updates stop, not a remote-side problem. The remote site's inability to receive routes is a direct and expected consequence of the local interface being passive.

• ✗

  The engineer should use the 'neighbor' command under the EIGRP process to specify the remote routers.

  Why it's wrong here

  The neighbor command in EIGRP is used to define a static neighbor on a point-to-point link, typically to avoid multicast or to support a non-broadcast multi-access (NBMA) network. However, this command does not override the behavior of passive-interface; if the interface is configured as passive, the router still will not send hellos or updates to any neighbor, including a statically defined one. In fact, configuring the neighbor command without first removing the passive-interface setting will simply not result in any adjacency or route exchange. The correct solution would be to remove the passive-interface restriction or use neighbor-specific configuration only after ensuring the interface is active, but the static neighbor itself is not a fix for the update suppression.

• ✗

  The remote sites are using a different EIGRP autonomous system number.

  Why it's wrong here

  If the remote sites were using a different EIGRP autonomous system number, they would never have formed an adjacency in the first place, and the scenario states they were receiving routes before the passive-interface command was applied. EIGRP routers only exchange routes with neighbors that share the same AS number, as the AS number is part of the protocol's routing domain identifier. Since the route exchange was previously working, the AS numbers must already match; a change in AS number is not implied by the symptoms. The passive-interface command is a local interface attribute and does not affect the AS number configuration, making this option a plausible but incorrect distraction.

Go deeper

Related to this question