Inspecting Interfaces and Routes

Use a small set of read-only observations to locate a reachability problem without confusing route selection with delivery.

Prerequisite: Configuration and Operational StateLesson 05 · operator workflow

By the end, you should be able to:

Inspect interface, address, neighbor, and route evidence in a useful order.
Interpret routing output without claiming independent ASIC verification.
Keep the port, routing instance, and test destination consistent.

Baseline: community SONiC 202505 release-branch source, pinned in the references; single ASIC, default namespace, community CLI. This is not a claim about the latest release or a certified vendor image. The Windows checkout was cross-checked separately. Commands are examples only; no device changes or live verification were performed.

Start with one destination and one path

A host behind a SONiC switch cannot reach 203.0.113.10. Before collecting output, identify the source, destination, expected next hop, and VRF. This lesson’s invented example uses the default routing instance and an existing interface called Ethernet0.

A focused reachability investigation

Original topology. The source-side subnet is deliberately unspecified; establish the actual ingress and return path before testing a real network.

1. Check interface intent and observed state

show version
show interfaces status Ethernet0
show runningconfiguration ports Ethernet0
show ip interfaces

Read-only commands, checked against the community baseline. Illustrative only; not executed on a SONiC device.

Read Admin and Oper separately. Then check the assigned IP interface and expected subnet. A routed address might belong to a VLAN or PortChannel rather than the physical member port; follow that relationship instead of assuming every physical port carries an IP address.

Interface    Oper    Admin
Ethernet0    up      up

Invented reduced status table; the actual command has more columns. Illustrative only; not executed on a SONiC device.

Up/up narrows the problem. It does not establish the right VLAN, a usable next hop, or destination reachability. Do not change the link merely because a route is missing.

Read further: 202505 interface inspection implementation · 202505 show CLI implementation.

2. Read the route and its next hop

show ip route
show ip route 203.0.113.10
show arp

Default-instance IPv4 inspection. Match address family and VRF on other scenarios; consult local --help for namespace options. Illustrative only; not executed on a SONiC device.

Codes: B - BGP; > - selected route; * - FIB route
B>* 203.0.113.0/24 [20/0] via 192.0.2.2, Ethernet0

Invented routing excerpt with a shortened legend. Illustrative only; not executed on a SONiC device.

In this FRR-style view, B identifies BGP origin, > marks the selected route, and * marks a FIB route in the routing stack’s display. The SONiC show command delegates to the routing view: the marker is not an independent dump of ASIC tables.

Check whether the route lookup for the actual destination resolves through the expected prefix, next hop, and egress interface. For this Ethernet next hop, show arp supplies IPv4 neighbor evidence. A missing or unresolved neighbor deserves investigation; a learned MAC alone still does not prove that the far destination or return path works.

Read further: 202505 command reference (pinned) · FRR zebra documentation.

3. Correlate evidence before changing anything

show interfaces counters

Read-only counter display. Avoid clear/reset subcommands during evidence collection. Illustrative only; not executed on a SONiC device.

Compare observations across a defined interval and the same interfaces. Counters include other traffic and collection delays; an increment alone does not identify a specific flow. If routing looks healthy but packets fail, move to supported programming logs, next-hop dependencies, ACLs, and packet evidence with the correct platform tools.

For another VRF, the baseline accepts a form such as show ip route vrf Vrf-blue 203.0.113.10. Use an existing VRF and align neighbor and interface observations with it; the default-instance show arp example is not sufficient evidence for every VRF.

Close the loop: record the failure, evidence, and next hypothesis. Inspection changes neither startup files nor intended configuration. Even successful current reachability would not prove persistence across a reboot.

Read further: 202505 interface inspection implementation · 202505 command reference (pinned).

Key takeaways

Fix the source, destination, VRF, and expected next hop before interpreting output.
Check administrative state, operational state, and IP interface placement separately.
A routing-stack FIB marker is not independent ASIC proof.
Neighbor and counter evidence narrow a problem but do not prove end-to-end delivery.
Preserve evidence before any controlled change.

Check your understanding

Six questions, four choices each. Check each answer, review the explanation and score, and retry.

Sources & baseline

Reviewed 18 October 2026. Community 202505 branch snapshots: sonic-utilities 7511bf2f8ea3; sonic-buildimage ff3c0c9f686a. Confirm commands with local help and image support before using them. Historical prose within a release branch can describe older behavior; implementation was checked for the examples used here.

Additional read-only Windows source cross-check: sonic-buildimage 128f6802b6e1, sonic-utilities cc4fbb3e8313 (config/main.py, show/main.py, and show/interfaces/__init__.py). This different checkout supports the roles illustrated; it is not presented as a 202505 binary. Full paths, revisions, and verification limits are recorded in SOURCE-REVIEW.txt beside this page.