Show Command Output Questions

All interfaces have at least one EIGRP neighbor.

Why it fails: Gi0/4 shows a Peers count of 0, so it has no EIGRP neighbour; the other four interfaces each show 1. The Peers column is tempting because a non-zero value does confirm adjacency, but the claim of "all interfaces" is falsified by Gi0/4's zero.

The mean SRTT on Gi0/2 is 18 ms, which is too high and indicates a problem.

Why it fails: Mean SRTT is a smoothed round-trip time measurement, not a threshold; 18 ms is unremarkable and no field flags a fault. The column invites misreading as a health indicator, yet EIGRP raises no alarm on SRTT alone — only queue drops or SIA events signal trouble.

The pending routes count of 0 on all interfaces indicates a routing loop.

Why it fails: Pending Routes counts routes awaiting acknowledgement, and 0 means none are outstanding — the healthy state, not a loop symptom. The field is tempting because non-zero values can indicate stuck replies, but a routing loop would surface as fluctuating metrics or SIA-Queries, not this counter.

The DHCP server has received 200 DHCPREQUEST messages.

Why it fails: The output lists 180 DHCPREQUEST messages received, not 200; 200 is the DHCPDISCOVER count. The figure is tempting because both appear in the same Received column, but reading the row label correctly is the whole task.

The DHCP server has 10 malformed messages, indicating a configuration issue.

Why it fails: Malformed messages shows 0, so no malformed traffic was received; the 10 belongs to Expired bindings, an unrelated counter. The value is tempting because it sits in the same statistics block, but it tracks leases that lapsed, not corrupt packets.

The DHCP server has 2 database agents configured.

Why it fails: Database agents reads 0, meaning no external database agent is configured; the 2 belongs to Address pools. The number is tempting because it appears in the same list, but it counts configured pools, not agents.

The DHCPv6 server has assigned only an IPv6 address to the client.

Why it fails: The binding shows both an IA NA address (2001:DB8:1::100) and an IA PD delegated prefix (2001:DB8:1::/48), so address-only assignment is contradicted by the prefix entry. It is tempting because IA NA alone is the common case for hosts; prefix delegation applies when the client is a requesting router needing downstream subnets.

The DHCPv6 client is using stateless autoconfiguration (SLAAC) because no address is shown.

Why it fails: An address is present (2001:DB8:1::100), and SLAAC bypasses DHCPv6 binding state entirely, so no binding would appear. It is tempting because SLAAC also autoconfigures addresses, but it uses router advertisements, not the DHCPv6 server's binding table shown here.

The DHCPv6 server has a pool with only one prefix available.

Why it fails: The binding shows one client holding one IA_NA address and one IA_PD prefix; it says nothing about pool size or remaining prefixes, since bindings list active leases only. It tempts because a single prefix appears, but pool exhaustion would require checking pool configuration or statistics, not this per-client binding table.

EIGRP has no BFD session for this neighbor.

Why it fails: The descriptor block explicitly reports BFD enabled with state UP, so a session exists and is operational for this neighbour. Absence of a session is what you would see when BFD is unconfigured or the neighbour lacks it, not in this output.

BFD is down, so EIGRP relies on its own hello/dead timers.

Why it fails: The output states BFD state UP, so the session is established and EIGRP is not falling back to hello/dead timers. That fallback occurs when BFD reports Down or no session exists, which is not the case here.

EIGRP is using BFD in passive mode only.

Why it fails: Passive describes the EIGRP topology state, meaning the route is stable with no queries outstanding, not a BFD mode. BFD has no passive mode; it negotiates asynchronous or demand echo sessions, and the output separately states BFD state UP.

The NAT pool is exhausted because all addresses are used.

Why it fails: The configuration uses interface overload, which multiplexes many inside hosts onto one global address using port numbers, so no pool exists to exhaust. It tempts because three translations share 192.0.2.10, but exhaustion applies to finite address pools, not PAT.

Static NAT is configured for DNS traffic.

Why it fails: The statistics line reports 0 static and 3 dynamic translations, and the mapping is ip nat inside source list overload, so no static entry exists. It tempts because the outside entries are port 53 DNS servers, but those are destinations, not static NAT statements.

The inside and outside interfaces are swapped.

Why it fails: GigabitEthernet0/1 is correctly listed as outside and GigabitEthernet0/0 as inside, matching the overload mapping direction. It tempts because the inside local addresses differ from the single global address, which looks reversed, but PAT translation normally rewrites source addresses this way.

It permits all IPv6 traffic

Why it fails: Sequence 10 drops traffic sourced from 2001:DB8:2::/48 before the sequence 20 permit is evaluated, so that prefix is blocked. Permitting everything would need the deny entry absent or placed after the permit, which the ordering here prevents.

It permits only IPv6 traffic from 2001:DB8:2::/48

Why it fails: The sequence 20 permit matches any source, so all other IPv6 traffic is allowed alongside the denied prefix; only 2001:DB8:2::/48 is blocked. Permitting solely that prefix inverts the logic, since sequence 10 explicitly denies it rather than allowing it.

It denies all IPv6 traffic

Why it fails: The list denies only traffic sourced from 2001:DB8:2::/48, then permits everything else via the sequence 20 entry, so traffic from other prefixes still passes. Denying all traffic would require an implicit deny with no matching permit, which this ACL does not have.

There is a problem because more queries were sent than replies received.

Why it fails: Queries and replies are independent counters; 10 queries sent versus 8 replies received is normal, since some queries need no reply or arrive from other neighbours. The asymmetry is tempting as a fault indicator, but SIA-Queries and SIA-Replies both read 0, confirming no stuck-active routes.

The input queue drops of 0 indicate that the router is not processing EIGRP packets.

Why it fails: Zero input queue drops means no EIGRP packets were discarded from the queue, not that processing stopped; the counters show active Hellos, Updates and Acks. Input queue drops would be the answer if the question asked about queue overflow or CPU starvation.

The SIA-Queries count of 0 indicates that the network has experienced stuck-in-active events.

Why it fails: Zero SIA-Queries and SIA-Replies indicate no stuck-in-active events occurred, since those counters increment only when a route stays Active past the query timeout. SIA counters would be the answer if the question asked how to confirm SIA conditions.

The client is using SLAAC instead of DHCPv6.

Why it fails: The presence of an IA NA binding with a server-assigned address, DUID and T1/T2 timers proves stateful DHCPv6 address assignment occurred. SLAAC produces no server binding entry. This option would be correct if the client had formed its address from a received prefix via router advertisement.

The client's lease has expired.

Why it fails: The binding shows a valid lifetime of 2592000 seconds with an expiry timestamp in the future, so the lease remains active. Expired leases are removed from the binding table or shown with zero remaining lifetime. This option would be correct if the Expires field showed a past date.

The client is not authorized.

Why it fails: The binding lists Username: unknown, which reflects that no authentication or authorisation was configured for this client, not a rejection. The address was still assigned successfully. This option would be correct if the server had refused the request and no binding existed.

The tunnel mode is multipoint, but the spokes need to be configured with 'tunnel mode gre ip' for direct communication.

Why it fails: 'tunnel mode gre multipoint' is required for DMVPN and is already correct; changing spokes to 'tunnel mode gre ip' would break the mGRE/NBMA design entirely. The option is tempting because point-to-point GRE tunnels do carry spoke-to-spoke traffic, but that static full-mesh approach is not DMVPN phase 2.

The spokes have different NHRP network IDs, preventing registration.

Why it fails: Mismatched NHRP network IDs would prevent registration, yet the hub already shows both spokes registered, so the IDs must match. The option is tempting because network-ID mismatch is a classic DMVPN fault, and it would be the cause if registration had failed rather than succeeded.

The IPv6 addresses on the tunnel interfaces are in different subnets.

Why it fails: DMVPN tunnel interfaces must share one subnet, and the stem gives no evidence of differing subnets; the hub already shows both spokes registered, which requires reachable tunnel addresses. The option is tempting because subnet mismatch does break spoke-to-spoke reachability, but it would also prevent the registrations already observed.

The IP SLA operation has failed due to a timeout.

Why it fails: 'Output: Over threshold' reports that the latest RTT exceeded the configured threshold, not that the operation timed out; failures are counted separately from threshold breaches. Timeout would appear as a failed operation, whereas threshold monitoring is used to raise alerts on latency.

The IP SLA operation is not reachable and has been disabled.

Why it fails: 'Over threshold' means the RTT exceeded the configured threshold, not that the operation is unreachable or disabled; successes and failures are both recorded. It is tempting because failures appear in the output, but 'Operation time to live: Forever' confirms the operation remains active.

The IP SLA responder is not configured on the target device.

Why it fails: A missing responder would cause timeouts and failures, but the output shows 50 successes and an RTT value, proving replies were received. It is tempting because responder absence is a common IP SLA fault, yet the statistics here demonstrate successful round trips.

uRPF is disabled

Why it fails: Strict mode is enabled, so uRPF is not disabled; the output explicitly reports "IPv6 uRPF: strict mode" on the interface. Disabled interfaces omit this line entirely. The option tempts engineers who assume uRPF defaults to off unless configured, which holds on interfaces where no uRPF command was applied — but here the running configuration already shows strict mode active.

uRPF is enabled in loose mode

Why it fails: Loose mode accepts any source address present in the routing table, regardless of the ingress interface, so it would not be reported as strict. The output explicitly states strict mode, which requires the source to be reachable via the receiving interface. Loose mode suits asymmetric routing, where return traffic arrives on a different path.

uRPF is enabled but only for multicast

Why it fails: The output states strict mode, which applies to unicast source addresses; multicast traffic is not validated by uRPF at all, so the claim contradicts the displayed configuration. It tempts because uRPF does interact with multicast through specific commands, but that would appear as a separate multicast-specific line, not as strict mode.

The route-target import on PE1 is misconfigured.

Why it fails: A wrong import route-target would stop the VPNv4 prefix entering the VRF table entirely, so it would not appear as best in the BGP table. Import route-targets are tuned when you need to control which VPN communities a VRF accepts.

The MP-BGP session is not using the loopback interface.

Why it fails: The 'r' flag denotes RIB-failure, meaning BGP could not install the prefix into the VRF routing table; MP-BGP peering over a loopback affects session stability, not RIB installation. Loopback sourcing is chosen when you need a peering address that survives interface failures.

The VRF on PE1 has a different route-target export.

Why it fails: A mismatched export route-target would prevent the prefix arriving at PE1 at all, yet the route shows as received and best. Route-target export is configured correctly when you want a VRF's prefixes advertised into a particular VPN community.

Interface Gi0/0/1 is allowed to send Router Advertisements.

Why it fails: RA guard in host role drops inbound Router Advertisements, so Gi0/0/1 cannot send them despite the policy being active. The router role permits RAs, which is why Gi0/0/0 is the sending interface; host mode exists to block rogue advertisements from end devices.

Interface Gi0/0/2 is allowed to send Router Advertisements.

Why it fails: The (default) policy assigns the host role, which drops Router Advertisement and Router Solicitation messages received on Gi0/0/2. RA guard is designed so that only explicitly trusted router-facing ports, such as Gi0/0/0, may originate advertisements.

All interfaces are blocked from sending Router Advertisements.

Why it fails: RA guard blocks Router Advertisements only on interfaces configured with the host role, so Gi0/0/0, set to router, still forwards them. The tempting reading treats the policy name as globally blocking, yet RA guard exists precisely to permit legitimate routers on uplinks while filtering rogue RAs from access ports.

NetFlow is enabled only on GigabitEthernet0/0 for both directions.

Why it fails: GigabitEthernet0/1 also shows ip flow ingress, so NetFlow is enabled there for ingress, not only on GigabitEthernet0/0. The output confirms both interfaces carry flow configuration. Restricting the answer to one interface misreads the second stanza.

NetFlow is enabled on GigabitEthernet0/0 for ingress only.

Why it fails: GigabitEthernet0/0 lists both ip flow ingress and ip flow egress, so egress is enabled alongside ingress. The option omits egress, misstating the configuration. Ingress-only would be correct had the egress line been absent from that interface's stanza.

NetFlow is not enabled on any interface.

Why it fails: The output explicitly lists ip flow ingress and ip flow egress under GigabitEthernet0/0 and ip flow ingress under GigabitEthernet0/1, so NetFlow is enabled. Claiming otherwise contradicts the displayed configuration. This command would show nothing if NetFlow were absent from all interfaces.

The static route is still present because the track is down.

Why it fails: The route is absent from the routing table, as shown by "% Network not in table"; the track being down removed it. It is tempting because tracked static routes can remain installed with a raised administrative distance, but here the route was withdrawn entirely.

The IP SLA operation is successful, but the track is misconfigured.

Why it fails: The IP SLA operation failed 100 times with "No connection", so it is not successful. It is tempting because the track correctly reflects the SLA state, but the failure lies in the SLA probe itself, not in track configuration.

The IP SLA operation has a threshold violation, but the route is still active.

Why it fails: The route is absent from the routing table, so it is not active; the track is down and the SLA reports "No connection". It is tempting because threshold violations can leave routes installed, but here the route was removed entirely.