Eigrp practice questions

The engineer used 'ip default-network' which is not supported in EIGRP; instead, 'default-information originate' should be used.

Why it fails: Ly states that 'default-information originate' should be used for EIGRP. That command is for OSPF, not EIGRP. While 'ip default-network' is indeed not supported in EIGRP, the correct method is to redistribute a properly configured static default route, not to use 'default-information originate'. Therefore, this is not the most likely reason.

The internal routers have a route to the default network with a better metric from another source.

Why it fails: Internal routers are not receiving the default route at all, so they cannot have a route with a better metric from another source. This option describes a scenario where the route is received but not preferred, which does not match the problem.

The engineer needs to configure 'eigrp stub' on the router to allow default route advertisement.

Why it fails: Configuring 'eigrp stub' on the router would restrict route advertisement, not allow it. To advertise a default route from a stub router, you would need the 'summary' keyword, but the router is not necessarily a stub. This would not be the most likely reason for the failure.

Both neighbors are using MD5 authentication.

Why it fails: The EIGRP neighbor table command output (show ip eigrp neighbors) does not include any authentication-related fields, such as the key ID or hash algorithm, because authentication is configured under the EIGRP process or interface, not displayed in the neighbor adjacency table. A stable neighbor relationship can exist with or without authentication, and this output offers no evidence to determine whether MD5 or any other authentication method is in use. Therefore, the statement about MD5 authentication is unsupported by the provided data.

Neighbor 192.168.1.2 has a higher metric than 10.1.1.2.

Why it fails: The EIGRP neighbor table lists neighbor IP addresses along with hold time, uptime, SRTT, RTO, queue count, and sequence number, but it does not display metric values for routes learned from those neighbors. Metrics are stored and shown in the EIGRP topology table (show ip eigrp topology), which contains the composite metric and vector metrics for each route. Without topology table output, there is no basis to claim that 192.168.1.2 has a higher metric than 10.1.1.2.

Router R1 is using EIGRP named mode.

Why it fails: The header 'EIGRP-IPv4 Neighbors for AS(100)' is the format used for classic EIGRP configuration, which is created with the 'router eigrp 100' global configuration command. In named mode (EIGRP named configuration), the output includes VRF and address-family context, such as 'EIGRP-IPv4 Neighbors for VRF(NAME)' or 'EIGRP-IPv4 Neighbors for AS(100) VRF(NAME)' when using address-family configuration. The absence of a VRF or address-family label in the header indicates the router is running classic EIGRP mode, not named mode.

VRF CUSTOMER-A is not using BGP for routing

Why it fails: This statement is incorrect because the routing table for VRF CUSTOMER-A explicitly includes a BGP entry. The 'B' code in the output is standard for Border Gateway Protocol routes, and the presence of this entry with a valid next-hop (192.168.1.2) proves BGP is operational for this VRF. BGP is often configured under 'router bgp' with an address-family ipv4 (or ipv6) vrf CUSTOMER-A to enable per-VRF route exchange. Therefore, claiming BGP is not used contradicts the direct evidence from the show ip route vrf output.

The default route is learned via BGP

Why it fails: The gateway of last resort being 10.0.1.1 does not mean the default route was learned via BGP. A default route in the routing table is shown as 0.0.0.0/0, and its source can be static configuration, connected, or a dynamic protocol such as OSPF or EIGRP. The BGP entry for 10.0.2.0/24 is a distinct, non-default prefix, and there is no indication in the output that a BGP-learned default route exists. It is equally plausible the default route is a static route pointed to 10.0.1.1 originating from the service provider or local configuration.

GigabitEthernet0/0.100 is not associated with VRF CUSTOMER-A

Why it fails: This is incorrect because the directly connected route for GigabitEthernet0/0.100 appears within the VRF CUSTOMER-A routing table. If the subinterface had not been associated with the VRF, its connected network would reside in the global routing table instead. A subinterface is placed into a VRF by issuing the 'vrf forwarding CUSTOMER-A' command under the interface configuration, which tags all subsequently learned routes on that interface with the VRF instance. Therefore, the presence of that interface's connected routes in the VRF table is definitive proof of association.

Both interfaces have the same metric weight for bandwidth and delay.

Why it fails: The show output for these interfaces only reports interface-level attributes such as bandwidth and delay; EIGRP metric weights (k-values) are configured globally under the EIGRP process via the metric weights command and are not interface-specific. Consequently, comparing metric weights for Gi0/0 and Gi0/1 is not possible from this output, and the statement that both interfaces have the same metric weight is an unsupported and incorrect inference.

Interface Gi0/1 is configured as a passive interface.

Why it fails: The command output includes a Passive interface field for each interface, and for Gi0/1 it explicitly states No. A passive interface in EIGRP would stop sending Hello packets and would not establish neighbors, leaving the interface in a passive state; the output would then indicate Yes. Therefore, the assertion that Gi0/1 is passive directly contradicts the displayed interface status and is wrong.

EIGRP authentication is enabled on both interfaces.

Why it fails: The output clearly lists Authentication: None for both interfaces, which means no MD5 or HMAC-SHA authentication key is configured for EIGRP on Gi0/0 or Gi0/1. If EIGRP authentication were enabled, the interface output would show the authentication mode (e.g., MD5 or HMAC-SHA-256) and associated key chain. Since the field is None, both interfaces are operating without authentication, making the statement false.

EIGRP will only advertise routes that have a metric within 50% of the best path.

Why it fails: EIGRP does not filter or suppress route advertisement based on a percentage of the best-path metric; route selection is governed by the composite metric (bandwidth, delay, load, reliability), and all feasible routes are advertised to neighbors. The `ip bandwidth-percent eigrp` command operates purely at the interface level on the control-plane packet rate, so it has no bearing on which routes EIGRP advertises or how the topology table is populated. A 50% figure in the command refers to bandwidth consumption, not a metric threshold.

EIGRP will use 50% of the interface bandwidth for data traffic.

Why it fails: This command is scoped to EIGRP's own control-plane traffic, not user data traffic. The interface bandwidth itself is used by data and control traffic: EIGRP packets are independent of the forwarding plane, and the bandwidth-percent setting limits only the EIGRP hello/update/etc. packets. Data traffic forwarded by the router is unconstrained by this command and instead is governed by QoS policies, interface speed, and hardware queues, so '50% for data' is a fundamental misreading of the parameter's purpose.

EIGRP will reduce its hello interval by 50%.

Why it fails: The EIGRP hello interval and hold time are tuned via `ip hello-interval eigrp` and `ip hold-time eigrp` on a per-interface basis; they are unrelated to the bandwidth-percent limit. Changing the bandwidth-percent value affects only how much EIGRP traffic can be sent, not how often hello packets are transmitted. The default hello interval remains 5 seconds (or 60 on slow links) unless explicitly modified, so a 50% value would not alter that timer in any way.

The route to 10.1.1.0/24 is in the same OSPF area as R3.

Why it fails: The route to 10.1.1.0/24 is in the same OSPF area as R3. The routing table entry for 10.1.1.0/24 shows 'O IA', which stands for OSPF Inter-Area route. An IA route means the network belongs to a different OSPF area than the one in which R3 resides; it was advertised by an Area Border Router (ABR) using a Type 3 LSA. Therefore, it is not in the same area as R3 — it is from another area.

The metric for 10.3.3.0/24 includes the internal cost to the ASBR.

Why it fails: The metric for 10.3.3.0/24 includes the internal cost to the ASBR. For an OSPF External Type 2 (E2) route, the metric shown in the routing table is the external cost only — the cost configured or advertised by the ASBR — and does not include the internal OSPF cost from R3 to the ASBR. This is a key distinction between E1 and E2 routes: E1 adds the internal cost to the external cost, while E2 does not. Since the displayed metric is 20 and the route type is E2, the internal cost is intentionally omitted.

R3 is an ASBR.

Why it fails: R3 is an ASBR. The routing table output on R3 shows it receiving external routes (O E2 for 10.3.3.0/24), which only indicates that some other router redistributed those routes into OSPF. An Autonomous System Boundary Router (ASBR) is a router that injects external routes into OSPF, but nothing in the output suggests R3 is performing that redistribution. R3 is simply an internal OSPF router learning about the external routes via LSAs, not the source of those routes.

A stub router can still be used as a transit router for other EIGRP neighbors.

Why it fails: Stub routing exists precisely to prevent a router advertising itself as a transit path; the stub router advertises only connected and summary routes, so neighbours never route through it. It is tempting because stub routers still form adjacencies and exchange routes with their hub, which looks like transit participation, but that is reachability, not forwarding.

The 'eigrp stub' command is configured on the hub router in a hub-and-spoke topology.

Why it fails: The eigrp stub command is configured on the spoke routers, which suppress transit advertisements toward the hub; configuring it on the hub would restrict the hub's own advertisements and break spoke reachability. It is tempting because the hub is the central device in the topology, so administrators assume configuration belongs there, but stub status applies to the leaf routers.

A stub router can be configured with the 'receive-only' keyword to advertise all its routes.

Why it fails: The receive-only keyword makes a stub router advertise nothing, so it cannot advertise all its routes; that behaviour belongs to connected or summary advertisements. It is tempting because receive-only is a genuine stub option, correct when the router should forward no prefixes at all to its EIGRP neighbours.

The OSPF process ID is different on the routers.

Why it fails: OSPF process IDs are locally significant and do not need to match between neighbours for adjacency formation or route exchange; the router ID, area configuration, and authentication parameters govern adjacency, not the process ID. This option is tempting because many routing protocols, such as EIGRP, require matching autonomous system numbers for neighbourship, so a candidate might incorrectly assume OSPF behaves identically.

The external route has a higher administrative distance than the internal route.

Why it fails: OSPF external routes carry administrative distance 110, identical to internal OSPF routes, so AD cannot discriminate between them; the real tiebreaker is the OSPF route type preference order. It tempts because AD does resolve conflicts between different protocols, which is the correct mechanism when OSPF and EIGRP offer the same prefix.

The OSPF metric for the external route is too high.

Why it fails: A high external metric only affects path selection between competing OSPF routes; it never prevents installation, since the route still enters the table as the sole candidate. Metric tuning is the right lever when choosing between multiple OSPF paths to the same destination, not when a route is absent entirely.

Use route maps to filter all redistributed routes.

Why it fails: Using route maps to filter all redistributed routes would indeed prevent any external routes from being injected into the other protocol, which could temporarily stop loops. However, this is a blunt instrument that completely breaks redistribution—the very purpose of the design—whereas the actual problem is not the existence of redistributed routes but the lack of proper route preference control. Filtering does not adjust AD or metrics, so even with selective filtering, loops can still occur when mutually redistributed routes with conflicting AD values exist.

Enable OSPF on all EIGRP interfaces.

Why it fails: Enabling OSPF on all EIGRP interfaces does not prevent redistribution loops; instead, it creates a dual-protocol environment on every link, which introduces redundant routing information and forces routers to resolve conflicts via AD. This can actually increase the risk of loops because each protocol may independently forward traffic, and without careful AD tuning, packets can bounce between domains. Furthermore, it adds unnecessary protocol overhead and complexity, providing no mechanism to stop the specific route feedback loop caused by mutual redistribution.

Use a single routing protocol throughout the network.

Why it fails: Using a single routing protocol throughout the network would completely avoid the need for redistribution, and thus would sidestep loops by design. However, this solution is not pragmatic in many enterprise environments where OSPF and EIGRP are already deployed, and the question scenario explicitly requires integrating these two protocols. The whole point of the design is to manage redistribution safely; abandoning one protocol is beyond the intended scope and may violate existing network requirements or migration constraints.

Split horizon

Why it fails: Split horizon prevents routing updates from being sent back out the same interface on which they were received. While EIGRP does honor split horizon on many interfaces, it only blocks immediate re-origination of a learned route and does not guarantee a loop-free alternate path in a more complex topology, so it is not the key mechanism preventing the routing loop in question.

Route poisoning

Why it fails: Route poisoning marks a route as unreachable by setting its metric to infinity, which in EIGRP is 4,294,967,295 (compared to RIP's 16). This tells neighboring routers to invalidate the route, but it does not itself verify whether an alternative path is loop-free; DUAL's feasibility condition performs that verification, making route poisoning insufficient on its own and not the correct answer.

Hold-down timers

Why it fails: Hold-down timers are a RIP-specific convergence feature that forces routers to ignore new route information for a period after a route is withdrawn. EIGRP does not implement hold-down timers; instead, DUAL relies on a query/reply process and the feasibility condition to recompute paths, so hold-down timers would be irrelevant when troubleshooting an EIGRP routing loop.

EIGRP hellos are sent on all interfaces, but GigabitEthernet0/1 is prevented from forming adjacencies.

Why it fails: This option inverts the configuration effect. With 'passive-interface default', EIGRP hellos are not sent on all interfaces; rather, they are suppressed on every interface until an explicit 'no passive-interface' command is applied. Here, only GigabitEthernet0/1 has been reactivated, so Gi0/1 is the one interface where hellos are permitted and adjacencies can form. The other interfaces are the ones prevented from forming adjacencies, not Gi0/1.

Only the network 10.0.0.0 is advertised, and all interfaces are passive.

Why it fails: This conflates the EIGRP network statement with passive-interface behavior. The 'network 10.0.0.0' command merely tells EIGRP which directly connected networks to advertise and which interfaces to consider for participation; it has no bearing on passive-interface settings. With 'passive-interface default', all interfaces are passive regardless of the network statement, so even if a loopback or another interface is matched by the network statement, it still will not send hellos unless explicitly enabled. Additionally, 'Only the network 10.0.0.0 is advertised' is not established by the given commands—passive-interface does not modify advertisement.

EIGRP will only form adjacencies on interfaces with an IP address in the 10.0.0.0/8 range.

Why it fails: This option misattributes the adjacency behavior to the IP addressing scheme. The passive-interface default command applies to every EIGRP-enabled interface, independent of whether its IP address falls within the 10.0.0.0/8 block. The only interface that can form an adjacency is GigabitEthernet0/1, because it is the sole one with passive mode disabled; other interfaces in the 10.0.0.0/8 range remain passive and will not exchange hellos. Thus, the deciding factor is the interface-specific override, not the network range.

Both network statements are classful and will enable EIGRP on all interfaces with IP addresses in the 192.168.0.0/16 and 10.0.0.0/8 ranges.

Why it fails: This option incorrectly assumes both network statements are classful. In reality, the first statement includes a wildcard mask, so it is a classless match limited to 192.168.1.0/24, not the entire 192.168.0.0/16 Class B supernet. The wildcard mask overrides the classful boundary, so EIGRP is not enabled on interfaces in other /24 subnets of 192.168.0.0/16.

EIGRP will only be enabled on interfaces with an IP address in the 192.168.1.0/24 range.

Why it fails: This option overlooks the second network statement. Even if the first statement only enables EIGRP on 192.168.1.0/24 interfaces, the classful `network 10.0.0.0` statement independently enables EIGRP on every interface with an IP address in the 10.0.0.0/8 range. As a result, EIGRP runs on interfaces in both ranges, not solely on the 192.168.1.0/24 subnet.

This configuration will cause an error because wildcard masks are not allowed in EIGRP network statements.

Why it fails: Wildcard masks are fully supported in classic EIGRP network statements; this configuration is valid and will not produce an error. In fact, the wildcard mask is used to define a prefix range for interface matching, and it is a common technique to enable EIGRP on a specific subnet rather than the entire classful network. EIGRP will simply process both statements and enable the protocol on all matching interfaces.

EIGRP will send updates on all interfaces except GigabitEthernet0/0.

Why it fails: This option reverses the effect of the passive-interface default and the no passive-interface override. With passive-interface default enabled, all interfaces start in passive mode; only GigabitEthernet0/0 is explicitly taken out of passive mode via 'no passive-interface GigabitEthernet0/0', so Gi0/0 is the only active interface. Therefore, EIGRP sends updates only on Gi0/0, not on all interfaces except Gi0/0. The phrase 'except GigabitEthernet0/0' directly contradicts the configuration, which enables EIGRP on Gi0/0 and disables it everywhere else.

EIGRP will not send any updates because the network statement is incorrect.

Why it fails: The EIGRP network statement 10.0.0.0 0.255.255.255 is valid; the wildcard mask correctly matches the entire 10.0.0.0/8 range, so EIGRP is enabled on any interface whose IP address falls within that range. The router's failure to send updates on other interfaces is not due to a malformed network statement, but because the passive-interface default command suppresses all interfaces unless specifically overridden. Therefore, the claim that the network statement is incorrect is false; the configuration is syntactically and logically correct, just constrained by the passive-interface default behavior.

EIGRP will form adjacencies on all interfaces that have an IP address in the 10.0.0.0/8 range.

Why it fails: While the network statement 10.0.0.0 0.255.255.255 would normally enable EIGRP on all interfaces with an IP in the 10.0.0.0/8 range, the global 'passive-interface default' command prevents EIGRP from sending hello packets or forming adjacencies on those interfaces. EIGRP only forms adjacencies on interfaces where it can send and receive hello packets, and passive interfaces do not participate in that process. Since only GigabitEthernet0/0 has been explicitly set to 'no passive-interface', it is the sole interface where adjacencies can form; all other interfaces with 10.x.x.x addresses remain passive and cannot establish EIGRP neighbors.

The IKEv2 proposal does not match between hub and spoke.

Why it fails: An IKEv2 proposal mismatch between hub and spoke would prevent the IKE SA and IPsec SA from ever being negotiated, so the tunnel would not initialize and the spoke would not be able to ping even the hub's tunnel IP. Since the tunnel is already established and the spoke can ping the tunnel interface, the IKE proposal must have matched successfully, and this cannot explain why the loopback is unreachable.

The certificate authority is not trusted by the hub.

Why it fails: In a certificate-based DMVPN, the hub must validate the spoke's certificate against a trusted root CA during IKEv2 authentication. If the CA were not trusted, certificate chain validation would fail, IKE_AUTH would be rejected, and the tunnel would never come up. Because the tunnel is operational and the spoke can ping the tunnel IP, the hub already trusts the CA, so this is not the cause of the loopback reachability problem.

The tunnel interface is not in an up/up state.

Why it fails: The tunnel interface being up/up indicates that the tunnel-protocol layer (e.g., GRE) and the underlying physical transport are functioning correctly. If the tunnel interface were down, the spoke could not ping the tunnel IP at all, because the interface would not process IP traffic. The fact that the tunnel IP responds proves the interface is up; this isolates the failure to the routing/route-propagation layer rather than the interface state.