What a Switching ASIC Is
A switching ASIC forwards at line rate using fixed-function and programmable stages, purpose-built lookup tables, and a finite pool of hardware resources. This is fundamentally different from routing packets in software on a CPU, and understanding the difference is the foundation for everything else in the course.
Prerequisites: Module 1 complete (SONiC architecture, the databases, SAI, syncd) · CCNP-level L2/L3 forwarding background
Learning objectives
- →Contrast ASIC hardware forwarding with CPU-based software routing in throughput, latency, and flexibility terms.
- →Explain line-rate forwarding and why it is a property of dedicated silicon, not software.
- →Distinguish fixed-function, programmable, and merchant-silicon designs without over-committing to a single vendor.
- →Describe how vendor SDKs and hardware tables relate to what SONiC can and cannot ask the ASIC to do.
- →Explain why hardware forwarding behavior can differ from what software routing suggests.
This is where intent finally becomes behavior. Every layer above — CLI, CONFIG_DB, FRR, SWSS, SAI — exists only to populate the tables that live in this silicon.
The single most common senior-engineer mistake on SONiC is trusting the control plane and never confirming the hardware. Knowing what the ASIC actually is tells you why the two can disagree.
What your CCNP already gives you
- • You already know a router has a RIB (control-plane routing table) and a FIB (forwarding table), and that they are not the same thing.
- • You know hardware CAM/TCAM concepts from ACL and MAC-table discussions on traditional switches.
- • You know that 'punting to the CPU' is expensive and rate-limited.
What is new in SONiC
- • In SONiC the FIB is programmed through an open API (SAI) and its objects are observable in ASIC_DB, not hidden.
- • The ASIC's specific supported attributes and table sizes are a first-class operational concern — 'which ASIC?' is a real question you must answer.
- • The virtual switch (VS) you learn on has no real ASIC; it emulates behavior and does not reproduce true hardware limits or forwarding.
| In the analogy | In SONiC |
|---|---|
| A skilled general-purpose worker who can do almost any job — but one at a time, and slowly | A CPU running a software router |
| An extremely fast assembly line built for one defined family of jobs | A switching ASIC |
| A few reconfigurable stations on the line | Programmable pipeline stages |
| Fixed-size bins of parts beside the line | Hardware tables (routes, MACs, ACLs) |
| The control panel and wiring specific to that line's machinery | The vendor SDK |
Where the analogy stops working
The analogy breaks in two important places. First, modern ASICs are not fully fixed — several stages are programmable, so the 'line' can be partially rewired for new protocols. Second, an assembly line's bins can be topped up on demand; an ASIC's tables are finite, physically sized, and shared, so filling one (say, ACL/TCAM) can leave less room for another (say, routes). There are also broad *categories* of silicon (fixed-function, deeply programmable, deep-buffer edge, shallow-buffer fabric) that behave differently — do not assume one vendor's design describes them all.
Two different machines for two different jobs
A software router runs the forwarding decision as code on a CPU: parse the packet, look up the route, rewrite headers, send it out. That is infinitely flexible — you can add a new protocol by shipping new code — but a CPU handles work more or less sequentially and tops out at a few million packets per second before it saturates.
A switching ASIC (Application-Specific Integrated Circuit) hard-wires the common case into silicon. Instead of running code per packet, packets flow through a pipeline of stages, each performing one narrow operation (parse, look up, rewrite, schedule) as a fixed hardware function or a small programmable block. Because the stages operate in parallel and in a streaming fashion, the chip sustains terabits per second — every port at line rate at once.
The trade is flexibility for speed. The ASIC is spectacular at the family of jobs it was designed for and unable to do anything outside that family without falling back to the CPU.
The switching pipeline (preview)
Stage 1 · Ingress
Physical ingress
Bits arrive on a front-panel port / SerDes lane. The port maps to an internal ingress interface.
Conceptual pipeline. Actual stage ordering, names, and capabilities vary by ASIC family — some stages are fixed-function, some programmable, and some are shared/recirculated.
CPU software routing vs ASIC hardware forwarding
| Aspect | CPU (software router) | ASIC (hardware forwarding) |
|---|---|---|
| Throughput | Millions of packets/sec; degrades under load | Billions of packets/sec; sustained line rate |
| Latency | Variable, dependent on load and scheduling | Low and deterministic for the fast path |
| Flexibility | Anything you can code; new protocols by software update | Only what the pipeline and tables support |
| Scale limits | Bounded by RAM/CPU, relatively elastic | Bounded by fixed, shared hardware tables |
| How you change behavior | Edit code | Program tables/attributes via SAI, within hardware limits |
| Failure of the fast path | N/A — it is all CPU | Falls back to slow-path punt to CPU (rate-limited) |
Fixed-function, programmable, and merchant silicon
Merchant silicon means switch ASICs that a chip vendor (for example Broadcom, Marvell, or Cisco's Silicon One line, among others) sells to many switch makers — as opposed to silicon a single system vendor builds only for itself. SONiC exists largely to run on merchant silicon across many hardware platforms, which is why the same OS concept spans different chips.
Fixed-function designs bake the pipeline behavior into silicon: fast, power-efficient, and cheap per port, but new features must wait for the next chip. Programmable designs expose reconfigurable parsing and match-action stages so new headers/features can be added in the field — more flexible, often at some cost in area, power, or table capacity. Most shipping switch ASICs sit somewhere on this spectrum rather than at an extreme.
You do not need to memorize vendor catalogs. You need the operational reflex: the *category* and *generation* of silicon under a switch determine which SAI attributes work, how big the tables are, and how features interact — so identify the ASIC before you trust any scale or feature assumption.
Tables and hardware resources
The ASIC's intelligence lives in its tables: the route (LPM) table, the exact-match host/MAC/FDB tables, next-hop and next-hop-group tables, the ACL/TCAM banks, tunnel tables, and the counters attached to them. These are built from specific memory technologies (covered in 3.2) and are finite and often shared.
This is the crux of hardware forwarding: because resources are shared, enabling one feature can reduce what is available for another. Turning up a large ACL profile, more ECMP, or tunnel termination can shrink the space left for routes or MACs. On a CPU router you rarely think this way; on an ASIC it is a daily constraint.
A healthy control plane does not guarantee correct forwarding. The route can be perfect in FRR and still absent, malformed, or resource-starved in the silicon. In this module you learn to confirm the hardware, not just the intent.
Why hardware forwarding can differ from software routing
Your control plane (FRR) computes a *best path*. That result must be translated into SAI objects and programmed into finite tables by asynchronous services. Any of the following can make the ASIC forward differently than the RIB implies: the route never reached the FIB, a table was full, an ECMP member was not resolved (no neighbor/adjacency), an attribute the control plane assumed is not supported by this ASIC, or a feature interaction reprioritized the packet.
So 'the route is in BGP' and 'the packet forwards' are two different claims that require two different checks. Holding them apart is the core discipline of SONiC operations.
Common misconceptions
Myth: The ASIC runs SONiC.
Reality: SONiC runs on the CPU (Linux + containers). The ASIC forwards packets; SONiC programs it through SAI. They are different processors doing different jobs.
Myth: If the CPU is idle, the switch is barely working.
Reality: For line-rate forwarding the CPU should be near-idle — the ASIC is doing the work. A busy CPU often means traffic is being punted to the slow path, which is a problem, not health.
Myth: SONiC makes every ASIC behave the same.
Reality: SONiC + SAI standardize how you *ask*. Supported attributes, table sizes, and behaviors still vary by ASIC and vendor. Abstraction is not equivalence.
Go deeperDeep vs shallow buffers, and why edge and fabric silicon differ
Two chips can both 'forward at line rate' and still be built for opposite roles. Shallow-buffer fabric/leaf-spine silicon minimizes latency and cost per port and relies on the network (ECN/PFC, good design) to avoid deep queues. Deep-buffer edge silicon absorbs large bursts and speed mismatches at the network edge, trading cost and power for buffering. This is one more reason 'which ASIC?' matters: the same SONiC config can behave very differently on the two, especially under congestion (Module on QoS/buffers goes further).
- Before trusting any scale number (routes, MACs, ACLs), identify the ASIC/platform — limits are hardware-specific.
- A near-idle switching CPU is normal; sustained high CPU on a forwarding switch suggests punting/slow-path, not throughput.
- 'The route is in FRR' proves control-plane intent, not that the silicon forwards it.
Key takeaways
- ✓A CPU is a flexible general-purpose worker; an ASIC is a fast, specialized assembly line for a defined family of jobs.
- ✓Line rate is a property of dedicated, parallel silicon, not of software.
- ✓ASIC tables are finite and shared: enabling one feature can starve another.
- ✓SAI standardizes the request but does not erase hardware differences — always identify the ASIC.
- ✓Control-plane health and hardware forwarding are separate claims requiring separate checks.
Tested against: SONiC 202305 / 202311 lineage · Upstream (community) unless noted · Concepts apply to merchant silicon generally; VS has no real ASIC · last reviewed 2026-07. Exact commands and behavior can vary by SONiC release, image, hardware platform, and enterprise distribution.
Knowledge check
Which statement most accurately compares SONiC-VS to a physical switch for learning ASIC behavior?