Module 3 · ASICs, Switching Pipelines, SAI & Forwarding

Physical Switch Validation

75 minLabPhysicalObservationCorrelationEnterprise

On dedicated lab hardware only, identify the vendor/model/SONiC distribution/ASIC family, compare the command surface, ASIC/platform visibility, and hardware counters against SONiC-VS, validate a real route and MAC in hardware, and document the concrete differences between virtual and physical SONiC.

Safety: Physical hardware — restricted

Performed only on dedicated lab hardware with console/out-of-band access. Save configuration first. Do not assume virtual failure-injection steps are safe on physical hardware.

PHYSICAL-RESTRICTED: perform ONLY on a dedicated lab switch you are authorized to use — never production or shared-production hardware.

Save the running config before you start, and confirm console/OOB access and a rollback plan first.

Do NOT restart critical containers (swss, syncd) on hardware as you might on VS — it reprograms the ASIC and interrupts forwarding.

Do NOT assume the VS failure-injection steps (Lab 3.3) are safe here; hardware disruption has real blast radius.

Make one change at a time, verify, and keep a written rollback for each.

Dedicated lab switch with OOB/console

  [OOB mgmt / console] ── lab switch (SONiC on real ASIC)
        front-panel ports ── test host(s) for route/MAC validation

Objective

• Positively identify the hardware: vendor, model, SONiC distribution/version, and ASIC family (where documented).
• Compare command surface, ASIC/platform visibility, and counters versus SONiC-VS.
• Validate a route and a MAC on real hardware and observe hardware counters.
• Document concrete virtual-vs-physical differences for the course record.

Starting state

• Dedicated lab switch powered, reachable via OOB/console, current config saved.
• You have change authorization and a rollback plan for this specific device.

Prerequisites: All Module 3 lessons complete; Labs 3-1..3-5 done on VS so you have a VS baseline to compare against. · Authorized access to a DEDICATED lab switch with console/OOB reachability. Not a production or shared-production device.

Tasks

1
Identify hardware, distribution, and ASIC family
SONiC CLI
```
show version
```
SONiC CLIplatform / HWSKU / ASIC where reported
```
show platform summary
```
SONiC CLIvendor/model/serial from EEPROM
```
show platform syseeprom
```
Expected:
- Vendor, model, HWSKU, SONiC version/distribution, and the ASIC family where documented — recorded verbatim.
What happened internally: Everything downstream (which SAI attributes exist, what scale to expect) depends on this identity. On VS these fields describe a virtual platform; here they describe real silicon.
2
Compare the command / visibility surface vs VS
Note commands and outputs that exist here but not on VS (vendor tools, platform sensors, real ASIC visibility).
SONiC CLIreal sensors — absent/emulated on VS
```
show platform temperature
```
SONiC CLIreal optics — not present on VS
```
show interfaces transceiver eeprom
```
Linuxcompare container set (pmon, platform services) to VS
```
docker ps
```
Expected:
- A short list of hardware-only surfaces (sensors, optics, platform daemons, vendor tooling) not present or only emulated on VS.
What happened internally: This is the tangible meaning of 'VS does not reproduce physical ASIC behavior' — whole categories of visibility exist only on hardware.
3
Validate a route in hardware and read hardware counters
Pick an existing installed route (do not add churn unless authorized). Confirm it in ASIC_DB and watch real counters move under a controlled test.
SONiC CLI
```
show ip route <prefix>
```
SONiC DB
```
redis-cli -n 1 SCAN 0 MATCH 'ASIC_STATE:SAI_OBJECT_TYPE_ROUTE_ENTRY*<prefix>*' COUNT 500
```
SONiC CLIreal per-port hardware counters
```
show interfaces counters
```
Expected:
- Route present in ASIC_DB; hardware counters increment on the expected egress port during a controlled ping/iperf.
What happened internally: On real silicon, counter movement is genuine ASIC statistics via flex counters — unlike VS, where forwarding and counters are emulated.
4
Validate a MAC in hardware
SONiC CLI
```
show mac
```
SONiC DB
```
redis-cli -n 1 SCAN 0 MATCH 'ASIC_STATE:SAI_OBJECT_TYPE_FDB_ENTRY*' COUNT 500
```
Expected:
- A learned MAC visible in both the software view and as a real FDB entry, with hardware learning behavior.
What happened internally: Compare learning timing/behavior to what you saw on VS in Lab 3.2 — note any differences you can observe.
5
Document virtual-vs-physical differences
Write a concise comparison: command surface, ASIC/platform visibility, counter authenticity, learning behavior, and any scale/limit visibility (CRM) that only means something on hardware.
Expected:
- A one-page virtual-vs-physical difference record added to the course notes.
What happened internally: This document is the deliverable: it prevents the class-wide mistake of over-trusting VS for hardware behavior and scale.

Troubleshooting branches

If: A VS command is missing on hardware (or vice versa)

Then: Command surface varies by distribution/platform; consult the platform docs and record the difference rather than assuming breakage.

If: Counters differ from VS expectations

Then: Expected — hardware counters are real; VS counters are emulated. Trust the hardware figures here.

If: Unsure whether an action is safe on this device

Then: Stop. This is physical-restricted; confirm authorization, console/OOB, and rollback before any change.

Cleanup / rollback

Remove any temporary test config you added; sudo config save -y only if you intended a change and are authorized.
Confirm the device is left in its original, saved state; verify OOB/console still reachable.

Lab evidence checklist

☐ Hardware identity recorded (vendor, model, HWSKU, SONiC version/distribution, ASIC family where documented).
☐ Hardware-only command/visibility surfaces listed.
☐ Route validated in ASIC_DB with real counter movement.
☐ MAC validated in hardware.
☐ One-page virtual-vs-physical difference document produced.

Reflection

Which differences between VS and hardware would most mislead someone who only ever used VS?
Which Module 3 lessons could only be fully validated here, and why?
Which of the earlier labs' actions (especially failure injection) would be unsafe on this device, and why?

Lab notes & observations