pjhtech Tools
Cisco · Cisco IOS XE

Cisco IOS XE Route Lookup: Routing Table, VRF and CEF Commands

Quick answer #

Use show ip route with the actual destination address to inspect its matching route. If the traffic enters a VRF, include that VRF in the lookup. Then inspect CEF and next-hop resolution. Finding a route establishes a forwarding decision in that context; it does not prove the complete application path.

Scope: IPv4 unicast on IOS XE routed platforms with CEF and, where used, VRF support. References include IOS XE 17.x protocol-independent commands and Catalyst VRF-lite. CEF output is not a universal hardware ASIC validation procedure.

Global-table commands #

Global-table commands
Cisco IOS XE · Authorized EXEC mode; context specified below

Read-only

Replace these example values: 203.0.113.25.

show ip route 203.0.113.25
Read-only

Replace these example values: 203.0.113.25.

show ip cef 203.0.113.25 detail
Read-only

Replace these example values: 192.0.2.10, 203.0.113.25.

show ip cef exact-route 192.0.2.10 203.0.113.25

VRF commands #

VRF commands
Cisco IOS XE · Authorized EXEC mode; context specified below

Read-only
show vrf definition brief
Read-only

Replace these example values: CUSTOMER, 203.0.113.25.

show ip route vrf CUSTOMER 203.0.113.25
Read-only

Replace these example values: CUSTOMER, 203.0.113.25.

show ip cef vrf CUSTOMER 203.0.113.25 detail
Read-only

Replace these example values: CUSTOMER, 192.0.2.10, 203.0.113.25.

show ip cef vrf CUSTOMER exact-route 192.0.2.10 203.0.113.25
Read-only

Replace these example values: CUSTOMER.

show ip arp vrf CUSTOMER

Workflow #

  1. Write down the source, destination and ingress interface. Establish the ingress routing context before reading any route table. An identical destination address can have different answers in different VRFs.
  2. Query the destination address, not just a guessed network. Note the matched prefix, source protocol, next hop and outgoing interface. A default route is a valid match, but it may not be the intended path.
  3. Follow recursive next hops until the forwarding path reaches a usable adjacency. CEF helps inspect the resolved forwarding information for the selected destination.
  4. Use the source-destination CEF lookup to investigate path selection where supported. Treat its result as a prediction within that forwarding context, not evidence that a packet actually completed the journey.
  5. Check the return direction and any packet-processing features on the path. ACLs, policy-based routing and translation can matter even when ordinary destination routing looks correct.

Interpretation pitfalls #

Longest-prefix matching comes before comparing preferences for routes to the same prefix. A more specific route can therefore explain a surprising path even when the default route points elsewhere. Preserve the prefix length in your notes; a next-hop address alone omits the most important part of the decision.

An unresolved next hop, discard entry or unexpected interface deserves investigation. However, a software CEF display is not proof that every hardware forwarding entry on every IOS XE platform is programmed correctly. Hardware checks are platform-specific and should be a separate escalation step.

Evidence to save #

Keep the ingress VRF, matched prefix, next-hop resolution and relevant return-path result together. This prevents different engineers from unknowingly comparing the global table with a customer's isolated table.

Useful tools and references #

  • IPv4 subnet calculator: Confirm the address range and prefix length returned by a destination lookup.
  • CIDR list comparison: Compare expected and observed route coverage. Coverage equality alone does not establish identical next-hop selection.

Sources

Documentation reviewed: 8 October 2026