Show IP Route Output 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.

The routers are configured with a different enable secret that does not match the one in the Ansible vault.

Why it fails: An incorrect enable secret in the Ansible vault would produce an immediate authentication failure — IOS would return '% Bad secrets' or 'Enable password incorrect' — causing the task to error out, not hang while waiting for a prompt. The indefinite wait suggests Ansible never even attempted to send the enable command because it did not know to use enable as the become method. Thus the failure is a missing escalation configuration, not a credential mismatch.

The SSH key exchange is taking longer than the default 12-second timeout.

Why it fails: SSH key exchange and the default 12-second connection timeout occur during transport establishment, before the CLI session is interactive; a problem there would surface as an unreachable host or 'SSH Error: timeout' without ever reaching a prompt. The described symptom specifically involves waiting for a shell/privilege prompt after the SSH session is already up, so it cannot be caused by key exchange latency. Therefore it is a post-authentication escalation issue, not a transport-layer timeout.

The ios_command module requires a different privilege level to execute 'show ip route'.

Why it fails: The ios_command module does not enforce privilege levels; the device does, and 'show ip route' would at worst produce an IOS authorization error such as 'Invalid input' if executed from a restricted view, not an indefinite wait. The timeout shown indicates the session was never elevated to privileged EXEC mode, so the command was never actually sent. That points to the missing become_method setting, not to a requirement that the command run at a different privilege level.

The AS-path contains the local AS number.

Why it fails: This is incorrect. While an AS-path containing the local AS number can cause routes to be rejected due to loop prevention, the typical symptom is routes not being received at all or being marked as invalid, not the specific 'received but not valid' status. The most common cause for 'not valid' is next-hop unreachability.

BGP synchronization is enabled.

Why it fails: This is incorrect. BGP synchronization is a legacy feature that requires the route to be in the IGP before it is advertised. In modern networks, synchronization is disabled by default. Even if enabled, it affects advertisement, not the validity of received routes in the BGP table.

The maximum-prefix limit has been exceeded.

Why it fails: This is incorrect. Exceeding the maximum-prefix limit typically causes the BGP session to reset or routes to be withdrawn, not to be marked as 'not valid' in the BGP table. Routes would likely be removed entirely, not just marked invalid.

The physical interface is configured with 'no ip address'.

Why it fails: The physical interface in a PPPoE configuration is intentionally left without an IP address. This interface operates at Layer 2 only and is used to encapsulate PPPoE frames via a dialer pool, while the dialer interface carries all Layer 3 addressing. IPCP assigns the IP address to the dialer interface, not to the physical Ethernet port. Therefore, seeing 'no ip address' on the physical interface is both expected and correct, and it is not the cause of the connectivity failure.

The default route is pointing to the wrong next-hop IP.

Why it fails: A default route in a PPPoE environment is typically configured with the dialer interface as the egress, using the form 'ip route 0.0.0.0 0.0.0.0 dialer 0' rather than a concrete next-hop IP. If the default route points to a specific next-hop IP, that IP would normally be the ISP gateway IP assigned during IPCP. However, because the dialer interface lacks an IP address, IPCP has not provided that next-hop value, and even a correctly pointed route cannot function. Thus the issue is not the route's target, but the missing IPCP address that makes any route unusable.

The ISP's gateway is not responding to ICMP.

Why it fails: While an unresponsive gateway could cause symptoms like this, it is not the root cause when the PPPoE session is already up. A PPPoE session being established confirms that the Ethernet link, PPP authentication, and LCP negotiation have succeeded, but ICMP requires IP-level routing and addressing. If the dialer interface has no IP address, the router cannot generate an ICMP echo request, so the gateway's response (or lack thereof) is irrelevant. The gateway is not the problem; the router's own missing IP address prevents it from participating in IP communication.

The RP is not configured as the DR on its segment.

Why it fails: The Designated Router (DR) on a segment is responsible only for sending PIM register messages on behalf of a directly connected source, not for selecting the tree used by other routers. The RP's DR status on its own segment has no bearing on whether last-hop routers use the SPT or the shared tree. In this scenario, the issue is purely a tree-switching delay, not any DR misconfiguration on the RP's link.

The multicast source is using a different group address.

Why it fails: If the source were sending to a different group address, the last-hop router wouldn't receive those packets at all—they'd be dropped because the router has no group state for that other group. The fact that traffic is flowing at all, albeit via the RP, proves the group address is correctly matched. This option incorrectly conflates the tree type with group addressing; the group address is consistent, and the actual problem is the absence of an SPT switchover.

The last-hop router has a higher metric to the source than to the RP.

Why it fails: The SPT switchover in PIM-SM is triggered by the first packet arriving at the last-hop router, or by the spt-threshold configuration—not by any comparison of unicast metrics to the source versus the RP. Even if the metric to the source is higher, PIM defaults to switching to the SPT anyway, and a higher metric would only delay the switch if a policy like spt-threshold were in place. Thus, a metric difference alone cannot explain why the traffic remains on the shared tree.

The IP SLA operation is not configured with a 'request-data-size' that matches the remote router's MTU, causing fragmentation and delay variations.

Why it fails: Configuring a 'request-data-size' that exceeds the path MTU between the source and destination would cause IP fragmentation, possibly increasing delay and jitter or causing packet drops, but it cannot produce a negative one-way delay value. One-way delay is calculated as receive timestamp minus send timestamp; fragmentation only adds transit time, so the result would remain positive (or the probe would fail). Thus, this misconfiguration explains performance degradation, not the reported negative delay.

The IP SLA operation is using a 'frequency' that is too high, causing the probes to overlap and corrupt the statistics.

Why it fails: Setting the IP SLA 'frequency' to a value shorter than the operation's actual execution time can cause probes to overlap or be skipped, which may corrupt the statistics or cause false timeouts. However, overlapping probes would affect packet timing, loss, and jitter metrics, not the sign of the computed one-way delay. A negative delay is a mathematically impossible result under normal timing and is specifically a symptom of clock desynchronization, not probe scheduling.

The remote router's IP SLA responder is not configured, so the source is using a different method to estimate delay.

Why it fails: If the remote router did not have an IP SLA responder configured, the UDP jitter operation would fail entirely because it relies on the responder to process and timestamp the probe packets and return control messages. There is no fallback 'different method' for estimating one-way delay; the operation would report an error or no data. Consequently, a missing responder could not yield a negative delay value, as the measurement would never complete.

Routes advertised to 10.1.1.2 will have the MED set to 50, influencing outbound path selection from AS 65000.

Why it fails: MED is fundamentally an inbound path-selection metric: it is advertised to a neighbor so that the neighbor can decide which of multiple paths into your AS to prefer. The claim that this affects outbound path selection from AS 65000 is incorrect—outbound path selection is driven by Local Preference, AS-path length, and origin, not by MED set on routes you advertise. The route-map only influences how AS 65001 chooses to reach your networks, not how your own routers choose egress paths.

Routes received from 10.1.1.2 will have the MED set to 50.

Why it fails: The route-map is attached with the 'out' keyword in the neighbor statement, meaning it processes only routes being advertised toward 10.1.1.2, not routes received from that neighbor. Inbound update policy would require a separate route-map applied with 'in', and that would be configured on the receiving router to modify attributes before installing routes in the BGP table. Therefore, the MED of 50 is never applied to prefixes learned from 10.1.1.2.

The MED value will be set to 50 for all routes in the BGP table.

Why it fails: This neighbor-specific route-map is applied only to the session with 10.1.1.2, not globally to all BGP speakers or the entire BGP table. MED is a per-neighbor attribute and is inserted into the UPDATE messages sent to that peer; other neighbors receive their own advertised routes without this MED modification, and locally originated or learned routes in the BGP table retain their original MED values unless explicitly changed by other policies.

The OSPF adjacency between PE1 and CE1 is down.

Why it fails: An OSPF adjacency failure would prevent the PE from learning CE routes in the first place, so the VRF routing table would not contain the missing prefix as an OSPF route. The scenario explicitly indicates the route is present in the VRF, which proves that the OSPF hello/DBD/LSU process has completed and the neighbor is in the Full state. Therefore, an adjacency-down condition cannot explain why an already-installed VRF route is absent from BGP.

The VRF forwarding table on PE1 is full.

Why it fails: A full VRF forwarding table is an FIB/CEF resource issue and would affect how packets are forwarded or whether a new route can be programmed into the data plane, not whether that route exists in the BGP VPNv4 table. In L3VPN operation, VPNv4 advertisement is driven by the VRF routing table and the redistribution policy under BGP, not by the size or capacity of the VRF forwarding table. If the route already appears in the VRF RIB, there is no capacity-related reason it cannot also be redistributed into BGP.

MPLS LDP is not enabled on the PE1-CE1 link.

Why it fails: LDP on the PE-CE link is nonsensical in a standard L3VPN design because LDP typically allocates labels for IGP routes across the MPLS core (P-to-P and PE-to-P interfaces), while the PE-to-CE link runs a plain IP routing protocol such as OSPF. VPNv4 prefixes are carried end-to-end in MP-BGP, which also allocates the inner VPN label; any core label needed for transport is handled by LDP or segment routing inside the service provider backbone. Missing LDP on the access link therefore has nothing to do with the failure to redistribute OSPF VRF routes into BGP on PE1.

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.

Reduce the collection frequency to every 4 hours

Why it fails: Lowering the collection interval to every 4 hours does not address the underlying cause of the timeout. The script still iterates through 500 devices sequentially within a single run, so the total execution time remains unchanged and will still exceed any fixed timeout threshold. This change merely reduces how often the problem occurs, not the problem itself, and could degrade monitoring granularity.

Replace Netmiko with SNMP polling using the pysnmp library

Why it fails: Switching to SNMP polling with pysnmp changes the data-collection paradigm entirely: SNMP requires every router to have an SNMP agent configured with community strings or credentials, and it can only return OIDs defined in MIBs, not arbitrary CLI output or show commands. While SNMP GETs are lightweight and could be parallelized, the missing metrics or the need to rewrite the entire collection logic makes this a non-trivial replacement that does not directly solve the existing timeout issue. It also adds operational overhead for SNMP configuration and security policy.

Use Ansible playbooks instead of a custom Python script

Why it fails: Ansible can parallelize device connections using the 'forks' parameter, but a default of 5 concurrent forks is often insufficient for 500 devices, and the control node's SSH connection handling can still hit timeout or performance bottlenecks. The playbook approach also shifts to a different automation framework, requiring inventory management and YAML task definitions, and does not inherently fix the root cause—the need for concurrent connections. If forks are not explicitly increased and connection timeout values not tuned, the same timeout behavior will persist.

It sets the local preference to 50 for routes received from the neighbor.

Why it fails: Local preference is a BGP attribute that influences egress traffic within the local AS and is configured with the set local-preference command, not set metric. Moreover, this route-map is applied in the outbound direction, so it modifies routes being advertised to 10.1.1.1, not routes received from that neighbor. Therefore, this option misidentifies both the attribute and the traffic direction.

It filters routes with a metric of 50 from being advertised to the neighbor.

Why it fails: A set metric clause assigns the metric value to routes that match the route-map's permit statement; it does not act as a filter. Filtering would require a deny statement or a match clause that evaluates the existing metric and then denies/filters the route. Since the route-map permits all routes and applies the set metric command, all routes are advertised with their metric changed to 50, not filtered out based on a metric of 50.

It sets the weight to 50 for routes learned from the neighbor.

Why it fails: Weight is a Cisco-proprietary BGP attribute configured with the set weight command, not set metric, and it is a locally significant value used for outbound interface selection on the router itself. Additionally, weight is applied to routes received from a neighbor (inbound direction) or generated locally—not to routes advertised outbound to a peer. Because this route-map is outbound to 10.1.1.1, it cannot set weight on routes learned from that neighbor.

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.

The route is an OSPF intra-area route

Why it fails: In OSPF, an intra-area route is derived from Type 1 or Type 2 LSAs and is listed with the route code 'O' in show ip route output. The routing table snippet explicitly shows 'type inter area' for this prefix, which is the marker for a Type 3 LSA generated by an ABR. Because the output does not say 'intra area' and the route type is explicitly inter-area, calling it an intra-area route is incorrect.

The route is an OSPF external route

Why it fails: OSPF external routes are flagged as 'type external' and have an E1 or E2 metric as well as the 'O E1' or 'O E2' route code. They are generated by an ASBR redistributing external networks, using Type 5 or Type 7 LSAs. The output here lacks any external metric marker and explicitly says 'type inter area', so this prefix is not an external OSPF route.

The route is learned via EIGRP

Why it fails: This prefix is learned via OSPF because the line 'Known via ospf 1' names the routing protocol and process ID. EIGRP routes are always displayed with 'Known via eigrp' followed by the autonomous system number, and they also use different route types such as internal or external. Since the output clearly points to OSPF as the source, and the route type is inter-area, EIGRP cannot be the originating protocol.

uRPF is checking the destination IP address, which is not reachable.

Why it fails: uRPF is designed to validate the source address, not the destination. It performs a FIB lookup using the source IP as the destination of the return path, ensuring that the packet's source is topologically reachable from the ingress interface. Destination reachability is irrelevant to uRPF; packet forwarding decisions are made separately by the normal destination-based lookup.

The router does not have a default route, so uRPF drops all traffic.

Why it fails: uRPF does not require a default route; it requires a FIB entry for the source address, which can be a specific route, a connected network, or a default route depending on configuration. Even without a default route, uRPF will permit packets whose source address has a specific route pointing back out the same interface. Conversely, the presence of a default route does not guarantee acceptance if the default route points out a different interface or if strict mode requires an exact match.

uRPF cannot be used with static routes; it requires a dynamic routing protocol.

Why it fails: Unicast Reverse Path Forwarding is independent of the routing protocol used to populate the FIB. It works with static routes, directly connected routes, dynamic routing protocol routes (OSPF, EIGRP, BGP), and even default routes. The only requirement is that a valid route to the source prefix exists in the FIB pointing back to the ingress interface; how that route was learned is irrelevant.

The group is using PIM dense mode.

Why it fails: The mroute table for this group shows the flag 'S', which explicitly indicates PIM Sparse-Mode (PIM-SM). Dense mode would instead display a 'D' flag, and dense-mode entries do not reference a Rendezvous Point (RP) because they forward traffic on all interfaces in the absence of explicit joins. Since the output includes an RP address (10.0.0.1) and the 'S' flag, the group is definitively running in sparse mode, making the dense-mode claim incorrect.

The multicast traffic is being hardware switched.

Why it fails: In Cisco multicast route output, the outgoing interface flags include 'H' when the entry is hardware-switched (i.e., programmed into the forwarding hardware such as ASIC or TCAM). The shown entry does not include an 'H' flag on any interface, indicating the packet replication is being performed in software by the CPU, not in hardware. This absence of 'H' is the definitive sign that multicast traffic for this group is not hardware switched, so the claim is wrong, and it also implies potential performance limitations at high traffic rates.

The group is a Bidir group.

Why it fails: The flags field in the mroute entry shows 'S' for sparse mode, not 'B' which would specifically denote a Bidir (bidirectional) group. In Bidir PIM, the router maintains only (*,G) state with no (S,G) entries, and all traffic flows along a shared tree rooted at the RP without source registration. Since the output displays the 'S' flag and likely includes (S,G) state (as evidenced by a sparse-mode entry), and critically lacks the 'B' flag, the group cannot be Bidir. Therefore, this option is incorrect.