Traditional NOS Comparison
Your routing troubleshooting reflexes came from an integrated NOS where a handful of show commands read one system. This lesson maps that workflow onto SONiC and contrasts four worlds — Cisco-style NOS, Dell OS10, open-source SONiC, and enterprise SONiC — so you know which instincts transfer and where the surface genuinely changes.
Prerequisites: Lessons 2.1–2.4.
Learning objectives
- →Translate a familiar routing-troubleshooting workflow into SONiC terms.
- →Contrast the diagnostic surface of Cisco-style NOS, Dell OS10, open-source SONiC, and enterprise SONiC.
- →Explain what OS10 shares with SONiC (Linux/merchant silicon) and where it differs.
- →Set correct expectations about enterprise SONiC add-ons without assuming they exist everywhere.
Knowing which of your reflexes transfer keeps you fast; knowing which mislead you keeps you accurate.
Enterprise SONiC distributions add tooling and change defaults. Assuming upstream behavior on an enterprise box (or vice versa) is a common source of confusion.
What your CCNP already gives you
- • The RIB/FIB/hardware mental model — it maps directly onto SONiC's layers.
- • The workflow 'check the protocol, check the route, check forwarding' — still valid, just more stops.
- • Reading BGP state and route tables — FRR's CLI is familiar.
What is new in SONiC
- • The 'check forwarding' step means querying APPL_DB/ASIC_DB, not one
show ... hardwarecommand. - • You cross container and database boundaries deliberately.
- • Behavior and available tooling depend on upstream vs. enterprise distribution.
| In the analogy | In SONiC |
|---|---|
| A single service counter that answers every question about the whole plant | Cisco-style NOS |
| A modern plant on standard machinery, with a familiar counter bolted over a Linux shop floor | Dell OS10 |
| The shop floor itself — you walk between departments and read each department's own ledger | Open-source SONiC |
| The same shop floor with a vendor-added supervisor's dashboard and support desk | Enterprise SONiC |
show ip route, show ip bgp, show ip cef all read the same vendor stack, and the RIB→FIB→hardware path is internal. SONiC replaces that single counter with a set of departments (containers) and ledgers (databases) you inspect individually. Dell OS10 is an interesting middle: it also runs on Linux and merchant silicon and even uses FRR for routing, but presents a more traditional, integrated CLI over it. Enterprise SONiC is open-source SONiC plus a vendor's tooling, defaults, QA, and support — the underlying model is the same, the surface and conveniences differ.Where the analogy stops working
The 'one counter vs. walk the floor' split is a spectrum, not a binary: modern Cisco/Arista platforms expose plenty of internal state too, and enterprise SONiC can feel quite integrated. Treat this as a guide to *where state lives and how you reach it*, not a claim that one is simply better. And OS10's internals differ from SONiC's despite the shared Linux/FRR/merchant-silicon DNA — do not assume SONiC DB commands work there.
Same question, four worlds: 'Is this prefix forwarding?'
| Concept | Cisco / Dell / traditional NOS | In SONiC |
|---|---|---|
| See BGP paths | show ip bgp <pfx> (integrated) | vtysh -c 'show ip bgp <pfx>' in the bgp container (FRR) |
| See selected route | show ip route <pfx> | vtysh -c 'show ip route <pfx>' (zebra RIB) or show ip route |
| See the FIB / hardware | show ip cef <pfx> / platform FIB command | APPL_DB ROUTE_TABLE then ASIC_DB SAI route object (two stores) |
| See resource scale | show platform hardware ... tcam (vendor-specific) | crm show resources all (open, uniform interface) |
| Restart the routing stack | Process restart hidden inside the NOS | Restart the bgp container (with warm-restart caveats) |
Diagnostic surface: integrated NOS vs. SONiC
| Aspect | Cisco-style integrated NOS | Open-source SONiC |
|---|---|---|
| Where state lives | Inside one vendor process; exposed through curated show commands. | Across containers and Redis databases you query directly. |
| RIB→FIB→hardware | Internal; a few commands summarize the whole path. | Explicit, multi-layer, individually observable (Lesson 2.2). |
| Routing daemon | Proprietary; not separately restartable by you. | FRR in a container you can inspect and restart. |
| Consistency model | One system; little cross-store skew to reason about. | Multiple stores must converge; skew is a first-class concept. |
| Tooling uniformity | Rich but vendor-specific per platform. | Open, uniform DB/CRM/SAI interfaces across vendors' hardware. |
Four-way orientation
| Platform | OS base | Routing stack | Troubleshooting surface | Support model |
|---|---|---|---|---|
| Cisco-style NOS (IOS-XE/NX-OS/EOS) | Vendor OS (EOS is Linux-based) | Vendor (EOS also uses many open components) | Integrated show commands | Single vendor |
| Dell OS10 | Debian Linux + merchant silicon | Uses FRR under an integrated CLI | Familiar CLI over Linux; less DB-walking than SONiC | Single vendor (Dell) |
| Open-source SONiC | Debian Linux + containers + Redis | FRR (zebra/bgpd) + fpmsyncd | Walk containers + databases + SAI/CRM | Community / self-support |
| Enterprise SONiC | SONiC base + vendor additions | FRR, possibly with vendor enhancements | Same model + vendor dashboards/CLI/telemetry | Commercial vendor support |
Open-source vs. enterprise SONiC — set expectations correctly
Enterprise distributions (from switch vendors and NOS vendors) build on the same SONiC architecture but add hardened images, certified HWSKUs, extra CLI/telemetry, different defaults, and — crucially — a support contract. Features like warm/fast-reboot maturity, additional show commands, and management integrations may be present on an enterprise image and absent (or different) upstream. When you read a runbook, note which it targets. A command or behavior that is universal in one distribution can be missing in another.
Regardless of platform, the diagnostic spine is the same: confirm the protocol (BGP session/paths), confirm the selected route (RIB), confirm forwarding (FIB/hardware), and check scale/resources. SONiC just makes each stop a distinct, observable place instead of a line in one output.
Common misconceptions
Myth: OS10 is just SONiC with a different badge.
Reality: Both run Linux on merchant silicon and use FRR, but their architectures and operator interfaces differ. SONiC's Redis/SAI DB-walking workflow does not directly apply to OS10.
Myth: Anything true of one SONiC image is true of all of them.
Reality: Upstream and enterprise distributions differ in features, defaults, CLI, and tooling. Always note the distribution and version.
Myth: SONiC has fewer troubleshooting tools than a traditional NOS.
Reality: It has more surface, not less — the state is exposed rather than hidden. The skill is knowing which store to read.
- Reuse your protocol→RIB→FIB→scale spine; just add the SONiC stops (APPL_DB, ASIC_DB, CRM).
- On an unfamiliar box, first establish the distribution (upstream vs. enterprise) and version before trusting any runbook.
- Do not carry SONiC DB/SAI commands onto OS10 or vice versa — shared DNA is not a shared interface.
Key takeaways
- ✓The troubleshooting spine (protocol → route → forwarding → scale) transfers across all four worlds.
- ✓SONiC replaces integrated show commands with explicit, multi-store observation.
- ✓OS10 shares Linux/merchant-silicon/FRR roots but not SONiC's operator interface.
- ✓Enterprise SONiC = open-source SONiC + vendor tooling, defaults, and support; always note the distribution.
Tested against: SONiC 202305 / 202311 lineage; OS10 10.5.x-era behavior · Compares upstream vs. enterprise SONiC explicitly · Conceptual; commands illustrative per platform · last reviewed 2026-07. Exact commands and behavior can vary by SONiC release, image, hardware platform, and enterprise distribution.
Knowledge check
Match each platform/world to how you inspect the FIB / hardware forwarding state.
Related lessons