Virtual Tests and Fault Isolation

Turn a small scenario into a reproducible acceptance test and a useful fault report, without overstating virtual evidence.

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

By the end, you should be able to:

Specify a virtual test’s image, topology, baseline, and oracle.
Separate component tests from packet and physical-platform tests.
Record a bounded failure and exact restoration.

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.

A reproducible virtual test

Original test workflow. This is a test specification, not a running lab or a claim that virtual results transfer to ASIC hardware.

Start with an explicit test manifest

Select an approved compatible SONiC VS image and provisioned harness. Record the immutable image identifier/release, host resources, virtual link mapping, management path, and test revision. The pinned VS guide demonstrates two front-panel ports with server namespaces, but its environment/commands are not proof of readiness on this Windows host.

Use the routed two-endpoint lesson08 as the acceptance scenario: separate subnets, reserved routed ports, prepared endpoint gateways, normal link/neighbor resolution, and no default route masking the expected behavior. Define success before running: intended interfaces/routes present plus a bounded endpoint exchange and correct return path.

Different tests establish different things

Test layer	Evidence	Limit
Mock/unit	One component branch or API expectation	No real end-to-end switch
SWSS DVS integration	Configured objects and database/SAI-VS behavior under fixtures	Software platform, harness-specific setup
Virtual packet test	A defined virtual flow and return path	No physical optics, buffers, line rate, or ASIC scale
Physical platform test	Specified target hardware behavior	Only its tested release, platform, and conditions

The inspected SWSS tests use DVS fixtures and state polling, sometimes writing internal test tables. Those fixture APIs are not normal operator configuration guidance.

A compact acceptance and negative-test plan

# Illustrative inspection on the PRE-PROVISIONED SONiC DUT
show version
show ip interfaces
show interfaces status
show arp
# Prepared Host A, not the DUT
ping -c 3 198.51.100.20

Acceptance record example:
Image: <record immutable identifier>
Expected: correct connected routes + adjacency + 3 bounded replies
Observed: <fill only after an actual run>
Result: NOT RUN for this authored course

Illustrative shortened output, not a device observation.

Use condition-based waits with a bounded timeout; do not hard-code a short sleep and call it convergence proof. Avoid exact timing guarantees and resource-heavy test execution on an unapproved host.

One fault, one hypothesis, explicit restoration

Use lesson08’s isolated endpoint address replacement (.20→.30), preserving the connected route while breaking the expected adjacency after cache expiry/re-resolution. Record timestamps, route/neighbor state, packet evidence, expected failure boundary, and the actual observation. Restore .20 and verify the original success predicate before teardown.

A useful fault report includes preconditions, exact change, expected/observed result, uncertainty, restoration, and residual state. Do not claim zero traffic loss or physical ASIC programming from a virtual result. No harness is launched here; provisioning, traffic generation, and all test outcomes remain unexecuted.

Key takeaways

Specify the image, harness, topology, and success predicate.
Component, virtual packet, and physical tests have different scopes.
Use bounded condition waits and preserve timestamped evidence.
A negative test must include restoration and a clear expected boundary.

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.