Packet Path and SAI Evidence

Trace one routed destination across software boundaries without confusing object state with hardware readback.

Lesson 16 of 18Prerequisite: core lessons 01–09 or equivalent operator knowledge

By the end, you should be able to:

Map a prefix to route, neighbor, and SAI dependencies.
Treat Redis transport as one scoped implementation path.
Collect evidence without mutating internal tables.

Scope: community SONiC 202505 source baseline; single ASIC/default namespace unless stated. Commands, outputs, faults, and recovery are illustrative only. Confirm image, management mode, and platform support before a separate lab. No device commands, builds, containers, or packet tests were executed for this course.

Control-state trace, separate from transit packets

Original conceptual trace for a common single-ASIC Redis route path. Other transport options, notifications, direct CONFIG_DB consumers, and responses are omitted; transit packets do not traverse Redis.

Freeze one prefix and context

Use the restored static-route lab from lesson09: S1 E0 192.0.2.1/24 to A, E4 198.51.100.1/30 to R1 .2, destination203.0.113.10, return route present. The lab begins operational, with no intended change in this lesson. Record release, namespace, VRF, prefix, interface, and timestamps before comparing asynchronous state.

A route depends on a virtual router/router interface, a usable neighbor/next hop, and sometimes a next-hop group. Object identifiers are implementation handles, not portable port names.

Read named state and bounded logs

show ip route 203.0.113.10
show arp
sonic-db-cli APPL_DB HGETALL "ROUTE_TABLE:203.0.113.0/24"
show logging --lines 50
docker logs --tail 50 swss
docker logs --tail 50 syncd

APPL_DB route excerpt: nexthop=198.51.100.2; ifname=Ethernet4
Separate programming observation: dependency pending / status needs review

Illustrative shortened output, not a device observation.

The application key is an example for the conventional default-VRF Redis path. Some releases/options use ZMQ or different representations; an absent key is not universal proof of a missing route. Container log names and logging sinks vary. Empty Docker logs do not prove a healthy daemon.

Translate evidence into a bounded conclusion

On the common path, RouteOrch resolves forwarding objects and calls SAI through the Redis client library. syncd translates serialized operations/identifiers and calls the vendor implementation. ASIC_DB captures software-oriented object/operation state; it does not independently read every silicon table.

Use supported vendor/platform diagnostics for hardware readback when necessary, and correlate their scope with responses, logs, counters, and endpoint captures. A SAI API definition specifies an interface, not identical scale, offload behavior, or recovery semantics for every ASIC. Do not invent a universal vendor dump command.

Locate the first unsupported boundary

For an invented failure, FRR selects the route but the expected neighbor is unresolved and orchestration reports a dependency wait. The next action is to verify the adjacent link/peer and resolve that dependency, not to force an ASIC_DB route entry. If dependencies are healthy yet SAI returns an error, preserve status/context and inspect supported platform evidence.

This lesson is read-only. Reuse lesson09’s bounded route deletion/repair only in that isolated scenario if a controlled comparison is needed; restore its recorded route, not a raw Redis key. No cleanup mutation is required here. End with a conclusion such as “selected route and application intent observed; physical programming not independently verified,” rather than “ASIC proven healthy.”

Key takeaways

Follow one prefix in one namespace/VRF and time interval.
Routes require usable forwarding dependencies.
Transport and table representations are release-specific.
SAI/ASIC_DB state alone does not prove physical forwarding.
Use supported interfaces for changes and scoped evidence for conclusions.

Check your understanding

Six questions, four options each. Check each answer for an explanation, review your score, and retry.

Sources & scope

Reviewed 18 October 2026. Community release-source pins: utilities 7511bf2f8ea3582c2b67cf5016f8e8237e62882b; buildimage ff3c0c9f686a1d0dbddbe813b233b3b7a51bd8e2. FRR 10.2 and RFC references explain semantics; they do not identify an installed image’s exact daemon version. Windows reference code is separately pinned: SWSS b8a9b65494c234ac33b6cf0a2b7f13fb291cee7f, buildimage 128f6802b6e1, utilities cc4fbb3e8313, SAI Redis dd925f4cf6fa. These are source-inspection baselines, not deployed-binary or hardware validation.

Exact inspected files and actual website checks are recorded in SOURCE-REVIEW.txt. No vendor CLI extension, production support level, scale, or timing guarantee is implied.