Show IP Route Output Practice Questions

BGP is not receiving any routes due to CoPP dropping updates.

Why it fails: The output shows one prefix marked valid and best, so updates are arriving; CoPP dropping updates would leave the received-routes table empty or stale. It tempts because CoPP does police BGP TCP/179, but that would be the diagnosis only when no prefixes appear at all.

BGP is receiving routes but not installing them in the routing table due to CoPP.

Why it fails: The prefix carries the > and * valid-best codes, meaning it was installed in the BGP table and passed to the RIB; a RIB-failure would show the r code instead. CoPP causing non-installation is correct only when routes appear with r or are missing from the routing table.

BGP session is flapping due to CoPP.

Why it fails: A flapping session would show the neighbour in Idle/Active or repeatedly reset, and received-routes would list nothing or reset counters; here the session is Established and passing one prefix. Flapping is the right conclusion only when neighbour state or uptime changes repeatedly.

90

Why it fails: 90 is the default administrative distance for EIGRP internal routes, not OSPF. It is tempting because both are interior gateway protocols, but OSPF's default sits at 110, so this value would misrepresent OSPF in route selection.

100

Why it fails: 100 is the default administrative distance for IGRP, a legacy protocol, not OSPF. It is tempting because it sits close to OSPF's real value, but OSPF defaults to 110 on Cisco IOS-XE, so this figure is wrong.

120

Why it fails: 120 is the default administrative distance for RIP, not OSPF. OSPF's default is 110. The value 120 is correct when the question asks about RIP routes on a Cisco IOS-XE router, so it fails this OSPF-specific scenario.

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 neighbor is administratively shut down.

Why it fails: An administratively shut neighbour shows the state "Admin" or "Idle (Admin)", not plain "Idle". The Idle state here reflects no active session attempt, typically from no route to the neighbour or a misconfigured update-source. Shutting a neighbour is done with the neighbour shutdown command.

The neighbor is in the process of establishing the session.

Why it fails: Active, Connect or OpenSent indicate session establishment in progress; Idle is the initial state before any TCP connection attempt. The zero MsgRcvd and MsgSent counters confirm no BGP messages have been exchanged, so establishment has not begun. Idle here points to reachability or configuration failure.

The neighbor has sent all its prefixes and is waiting for updates.

Why it fails: A neighbour that has sent all prefixes and is awaiting updates shows Established with a PfxRcd count, not Idle. Idle means no session exists at all, so no prefixes could have been received. The zero counters and 00:00:05 uptime confirm the session never came up.

The prefix is learned via iBGP and is not the best path.

Why it fails: The output shows 'external' and 'best', meaning the path was learned via eBGP and selected as best, contradicting this option. It is tempting because iBGP paths also appear in the BGP table, but the external and best flags here rule that out.

The prefix is suppressed and not advertised to peers.

Why it fails: The entry shows 'best #1' and is advertised to update-group 1, so the prefix is selected and being advertised, not suppressed. It is tempting because route suppression does hide prefixes from peers, but no dampening or suppression state appears in this output.

The prefix is invalid due to missing next-hop reachability.

Why it fails: The output shows the path as valid and best, with no next-hop unreachability flagged, so the prefix is installed in the BGP table. It is tempting because a missing next-hop does invalidate a path, but that would appear as 'invalid' with the next-hop inaccessible, not as 'valid, external, best'.

The router is load-balancing between OSPF and EIGRP routes.

Why it fails: EIGRP's administrative distance of 90 beats OSPF's 110, so the OSPF route is deleted and only the EIGRP path remains installed. Load-balancing requires equal-cost paths from the same or configured sources; unequal distances prevent it. This debug would show two inserts only if both protocols had matching distances.

The OSPF route is preferred due to lower metric.

Why it fails: Administrative distance, not metric, decides here: EIGRP's 90 beats OSPF's 110, so the OSPF route is deleted despite its lower metric of 20. Metric comparison is the correct tie-breaker only when both routes come from the same protocol.

Both routes are installed in the routing table.

Why it fails: The OSPF entry is deleted after the EIGRP insert, leaving only the EIGRP path; the table holds one route, not two. It is tempting because both protocols initially inserted the prefix, but administrative distance resolves the conflict in EIGRP's favour.

110

Why it fails: 110 is the default administrative distance for OSPF, not internal EIGRP, so this value would misrepresent EIGRP's trustworthiness in route selection. It is tempting because OSPF is a common interior gateway protocol, and 110 would be the correct answer if the question asked about OSPF instead.

120

Why it fails: 120 is the default administrative distance for RIP, not internal EIGRP, so selecting it would rank EIGRP routes incorrectly against other sources. It is tempting because RIP is a widely taught routing protocol, and 120 would be correct if the question concerned RIP's default distance.

170

Why it fails: 170 is the default administrative distance for external EIGRP routes, not internal ones, so it misstates how the router ranks internal EIGRP paths. It is tempting because it is a genuine EIGRP value, and would be correct if the question specified external EIGRP routes instead.

The BGP session is not established.

Why it fails: The received-routes output lists a prefix learned from 10.1.12.2, which is only possible once the session reaches Established and routes are exchanged. A non-established session would show nothing received; Active state is a separate concern, not proof of this.

The BGP session is in Active state.

Why it fails: Active state means the router is actively attempting TCP port 179 connection and no prefixes have been exchanged. Receiving a route from 10.1.12.2 proves the session reached Established, so Active is contradicted by the output itself.

The BGP session is in Idle state.

Why it fails: Idle state means the neighbour is down and no BGP messages flow, so no received routes could appear. The output shows a prefix learned from 10.1.12.2, which requires an Established session; Idle is the initial state before any connection attempt succeeds.

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.

Check if the server is responding to ICMP echo requests.

Why it fails: The track object already reports Up, so ICMP replies are arriving; the fault lies in how the route references the track, such as a missing or mismatched track number. It tempts because unreachable probes are the usual cause of a down track object.

Ensure the IP SLA probe is configured with a timeout value less than the frequency.

Why it fails: A timeout shorter than the frequency cannot explain a missing route: the track object already reports Up, so probes are succeeding. Timeout tuning only affects how quickly a probe is declared failed, which matters when tuning SLA responsiveness, not when the track is already satisfied and the route still absent.

Reboot the router to clear any routing table inconsistencies.

Why it fails: Rebooting clears transient state but cannot fix a misconfigured track reference, and the track already shows Up, so the route's tracking configuration is the real fault. It tempts as a familiar first-line remedy for stubborn routing anomalies.

Enable `ip local policy route-map PBR` globally to apply the policy to all interfaces.

Why it fails: `ip local policy route-map` applies PBR to locally generated traffic from the router itself, not to transit traffic. The scenario describes traffic from a subnet, which is transit traffic that arrives on an interface. Applying a local policy would not affect that traffic. The correct application is on the ingress interface using `ip policy route-map`. Therefore, this command does not solve the problem.

Apply the route map to the egress interface with the `ip policy route-map` command.

Why it fails: PBR is applied to ingress traffic on the interface where packets arrive, not on the egress interface. Applying it to the egress interface would not affect the forwarding decision, as the routing decision is made before the packet is forwarded out. The correct placement is on the ingress interface. Therefore, this action would not cause PBR to take effect for the specified subnet.

Configure a default route with a next-hop of 192.168.2.1 to override the existing default route.

Why it fails: Adding a default route would affect all traffic, not just the subnet 10.1.1.0/24. PBR is designed to selectively override routing for specific traffic. Changing the default route would disrupt other traffic and does not implement the desired policy. The issue is that PBR is not correctly configured or applied, not that the default route is missing. This action would not selectively forward the subnet's traffic.

1

Why it fails: Administrative distance 1 belongs to static routes, not connected interface routes, so this value misstates the default. It is tempting because static routes are also highly trusted, and 1 would be correct when identifying the default distance assigned to a manually configured static route.

5

Why it fails: Distance 5 is assigned to EIGRP summary routes, not directly connected interface routes. It is tempting because it is a low, trusted value, and would be correct when identifying the administrative distance Cisco assigns to a summary route generated by EIGRP.

110

Why it fails: Distance 110 belongs to OSPF, a dynamic routing protocol, not a directly connected interface route. It is tempting because OSPF is widely deployed, and 110 would be correct when identifying the default administrative distance assigned to routes learned through OSPF.

Check the EEM applet's script for errors.

Why it fails: Reading the script for syntax or logic errors only proves the code is valid, not that its frequent routing-table rewrites are causing the loss. Script inspection is the right step when an applet fails outright or throws execution errors, not when correlating trigger frequency with intermittent packet loss.

Use the 'show event manager statistics' command to see how often the applet is triggered.

Why it fails: Trigger counts alone cannot confirm the applet is rewriting routes during the loss windows; the statistics show frequency, not the routing impact. This command is the correct choice when validating whether an applet fires as expected after configuration, not for correlating route changes with packet loss.

Increase the logging level to debug to see more details.

Why it fails: Raising logging to debug increases output volume and CPU load without proving the applet alters the routing table; it shows more messages, not causation. Debug logging suits diagnosing protocol or adjacency errors, where the fault lies in message exchanges rather than a triggered script.

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.

The route is learned from a BGP peer

Why it fails: The path shows "Local" with next hop 0.0.0.0 and weight 32768, meaning R1 originated the prefix itself; a peer-learned route would list the neighbour's IP as the from address. It is tempting because BGP tables routinely hold peer-learned entries, but this specific output describes a locally sourced route.

The route has an MPLS label

Why it fails: No label stack, RD, or VPNv4 NLRI appears; the entry is plain IPv4 unicast in the default table, so no MPLS label is associated. It is tempting because the stem concerns MPLS L3VPN, where labelled VPNv4 routes are expected, but this command displays the global IPv4 table instead.

The route is in a VRF

Why it fails: The header states "table default", so the route sits in the global BGP table, not a VRF; VRF routes appear under a named table. It is tempting because L3VPN verification often involves VRF tables, and the command's unicast keyword resembles per-VRF lookups, but no RD or VPNv4 context is present here.