SONiC

Glossary

Every term with a concise definition, an analogy where it helps, a technical explanation, and a link to where it is taught.

34 terms

APPL_DBThe application/producer state database.
The Redis database where feature applications (route producers, FRR via fpmsyncd, LLDP, teamd, etc.) publish the state that orchagents consume on their way to the ASIC.
Analogy: The production queue where accepted work orders wait to be turned into machine instructions.
Technically: APPL_DB sits between config/protocol producers and SWSS. For example, fpmsyncd writes FRR's kernel/route updates into ROUTE_TABLE in APPL_DB; RouteOrch then converts them to SAI route objects. Presence in APPL_DB means 'submitted to orchestration', not yet 'in hardware'. Conventionally logical DB 0.
CONFIG_DBASIC_DBSWSSorchagentFIB
ASICApplication-Specific Integrated Circuit — the forwarding silicon.
The switching chip that performs line-rate packet forwarding, lookups, and rewrites. In SONiC it is programmed indirectly through SAI/syncd.
Analogy: The high-speed production machinery that actually moves product down the line.
Technically: The ASIC holds the true forwarding tables (in TCAM/SRAM-backed structures). SONiC never touches it directly — it programs SAI objects that the vendor SDK realizes in silicon. Scales, table sizes, and feature support are ASIC-specific, which is why 'which ASIC?' is a first-class question.
SAIsyncdSDKMerchant siliconTCAMSRAMFIB
ASIC_DBThe SAI-object database in the sync path.
The Redis database that represents SAI objects in the synchronization path between SONiC and the vendor SAI implementation, maintained by syncd.
Analogy: The machine's instruction log — a faithful record of what was handed to the operator, not the machine's spinning parts.
Technically: ASIC_DB is NOT the physical hardware. It is the database representation syncd uses to program and reconcile the ASIC. An object present in ASIC_DB means syncd issued the corresponding SAI operation; confirming actual hardware/forwarding state still requires SAI get calls, counters, or a real data-plane test. Conventionally logical DB 1.
syncdSAIASICSTATE_DBAPPL_DB
CONFIG_DBThe desired-state (intent) database.
The Redis database that holds operator-authored configuration — ports, VLANs, interfaces, BGP, ACLs — as desired state, and is serialized to /etc/sonic/config_db.json for persistence.
Analogy: The work-order database at the front desk: it records what was requested, not what has been built.
Technically: CONFIG_DB is intent, not confirmation. Config landing here does not mean the ASIC is programmed — managers must translate it toward APPL_DB, orchagents must resolve it, and syncd must push it. config save writes CONFIG_DB to disk; without it, changes are lost on reboot. Conventionally logical DB 4.
APPL_DBRedisSTATE_DBManagement plane
Control planeThe 'decide' layer: protocols and state computation.
The set of processes that learn topology and compute forwarding state — routing protocols, ARP/ND, MAC learning logic, EVPN — before it is programmed into hardware.
Analogy: The planners deciding routes and schedules, distinct from the trucks that actually drive.
Technically: In SONiC the control plane is largely FRR (bgpd/zebra) plus SONiC agents, running on the CPU. Its outputs (RIB, neighbors, MAC/IP bindings) feed APPL_DB and, via SWSS/syncd/SAI, the ASIC. Control-plane health is separate from data-plane health — either can fail independently.
Data planeManagement planeRIBEVPN
COUNTERS_DBThe statistics/telemetry database.
The Redis database where periodically polled counters (per-port, per-queue, PG, buffer, and more) are stored for tools like show interfaces counters.
Analogy: The meter room where every gauge's reading is logged on a schedule.
Technically: flexcounter/syncd poll SAI counter objects and write them to COUNTERS_DB, keyed via OID-to-name maps. Values are snapshots at the polling interval, not live per-packet reads, so brief microbursts can be undercounted. Conventionally logical DB 2.
STATE_DBRedisASIC_DBData plane
Data planeThe 'do' layer: line-rate packet forwarding.
The forwarding hardware and pipeline that actually moves packets at line rate according to tables the control plane programmed.
Analogy: The trucks and conveyor belts physically moving goods, following the planners' schedule.
Technically: In SONiC the data plane is the ASIC pipeline (parser → match-action → rewrite) using FIB/FDB/ACL tables programmed via SAI. It keeps forwarding even if the control plane restarts (see warm restart). Confirming a fault is data-plane vs. control-plane narrows troubleshooting dramatically.
Control planeManagement planeFIBFDBASICMatch-action
Disaggregated networkingSeparating the NOS from the switch hardware via open interfaces.
The model in which the network operating system and the switch hardware are sourced independently and joined through open interfaces, rather than sold as one locked vendor stack.
Analogy: Buying the building and the machinery from different suppliers because they agree on standard fittings.
Technically: SONiC is the OS layer of a disaggregated switch; merchant silicon is the hardware layer; SAI (and ONIE for install) are the open contracts between them. This decoupling gives operators independent upgrades, multi-vendor tooling, and fault isolation — the same properties that make SONiC observable to troubleshoot.
SONiCMerchant siliconSAIASIC
EVPNEthernet VPN — a BGP control plane for overlays.
A BGP address-family (typically MP-BGP EVPN, AFI/SAFI 25/70) that distributes MAC/IP reachability and VTEP information for VXLAN overlays, replacing flood-and-learn.
Analogy: A shipping manifest service that tells every dock exactly where each recipient is, so nobody has to broadcast 'who has this address?'.
Technically: EVPN advertises MAC/IP (Type-2), inclusive multicast (Type-3), and IP-prefix (Type-5) routes so VTEPs learn remote endpoints via the control plane. In SONiC it is implemented in FRR (bgpd) with fpmsyncd/VxlanOrch programming the resulting FDB/next-hop/tunnel state. Feature maturity varies by SONiC version.
VXLANVTEPVNIIRBRIBControl plane
Exact matchA lookup requiring the key to match a stored entry bit-for-bit.
A table lookup that matches only when the search key equals a stored key exactly, typically via hashing — used for MAC/FDB and host-route style lookups.
Analogy: A lock that opens only for the one exact key, no near-misses.
Technically: Exact-match tables (often hash/SRAM-backed) are dense and fast but cannot express wildcards or ranges. They contrast with TCAM/LPM lookups that support don't-care bits and prefix matching. Choosing exact vs. ternary is a hardware table-design decision with scale trade-offs.
FDBSRAMLPMTCAMMatch-action
FDBForwarding Database — the L2 MAC address table.
The table mapping learned MAC addresses (per VLAN) to egress ports/tunnels, used for Layer-2 forwarding decisions.
Analogy: A mailroom directory mapping each recipient's name to the exact bin their mail goes in.
Technically: In SONiC, MAC learning results flow through FdbOrch into SAI FDB entries; observed entries surface via STATE_DB and show mac. For EVPN VXLAN, remote MACs are programmed as FDB entries pointing at VTEP tunnels rather than local ports.
STATE_DBorchagentVTEPEVPNData plane
FIBForwarding Information Base — the data-plane forwarding table.
The distilled table the data plane actually uses to forward packets, derived from the RIB and programmed into the ASIC.
Analogy: The turn-by-turn directions loaded into the car, distilled from the master atlas.
Technically: In SONiC the hardware FIB is realized as SAI route/next-hop objects in the ASIC (tracked via ASIC_DB) and typically backed by LPM structures. A mismatch between RIB (FRR) and FIB (ASIC) is a classic 'programmed vs. intended' fault; the kernel FIB is a third, separate view.
RIBLPMASIC_DBData planeASIC
IRBIntegrated Routing and Bridging.
The capability to both bridge within an overlay segment and route between segments on the same device, enabling inter-VNI routing at the VTEP.
Analogy: A dock that can both move parcels between bins in the same warehouse and forward them to an entirely different warehouse.
Technically: With EVPN VXLAN, IRB is commonly deployed as symmetric IRB using an L3 VNI/VRF: routed traffic is encapsulated with the L3 VNI and routed at the remote VTEP. Asymmetric IRB routes then bridges into the destination L2 VNI. SONiC support and the required SVI/VRF plumbing vary by release.
EVPNVXLANVNIVTEPRIB
LPMLongest Prefix Match.
The IP forwarding rule of choosing the most specific matching route (longest prefix) among all routes that match a destination.
Analogy: Preferring the most detailed street-level direction over a vague 'head north'.
Technically: LPM is implemented via TCAM and/or algorithmic tries (e.g. LPM engines) depending on the ASIC. It is how the FIB resolves overlapping routes. Prefix scale and update rate under LPM are platform-specific and a common capacity limit.
FIBTCAMExact matchASIC
Management planeThe 'operate' layer: access, config, and telemetry.
The interfaces and services used to configure, monitor, and manage the switch — SSH/CLI, gNMI/telemetry, SNMP, the mgmt interface and its VRF.
Analogy: The front office and reception: how people and systems interact with the factory without touching the machines.
Technically: In SONiC the management plane spans the mgmt interface (often in a dedicated mgmt VRF), the CLI/config tooling that writes CONFIG_DB, and telemetry/gNMI/SNMP containers. It is distinct from control/data planes: losing management access does not necessarily stop forwarding.
Control planeData planeCONFIG_DB
Match-actionThe pipeline model: match on fields, then apply actions.
The forwarding-pipeline paradigm in which each stage matches extracted fields against a table and applies resulting actions (forward, drop, rewrite, set metadata).
Analogy: An assembly line of stations, each checking a rule and doing one operation before passing the item on.
Technically: Match-action tables are backed by TCAM (ternary) or SRAM (exact) as appropriate. SAI objects (routes, ACLs, next-hops) ultimately populate these tables. The match+action abstraction is why the same intent maps onto very different silicon.
ParserMetadataExact matchTCAMSAI
Merchant siliconCommercially available switch ASICs sold to many vendors.
Switching chips (e.g. Broadcom, Marvell, Cisco Silicon One families) sold as off-the-shelf components rather than built exclusively in-house, enabling disaggregated switches.
Analogy: Standardized off-the-shelf engines that many different car makers can build a chassis around.
Technically: Merchant silicon is what makes SONiC's hardware portability practical: many platforms share a few ASIC families, each exposed through SAI. Even so, scales, buffer models, and feature support differ per chip and per SAI/SDK version — never assume parity across merchant ASICs.
ASICSAISDKDisaggregated networking
MetadataPer-packet scratch state carried through the pipeline.
Transient, per-packet information (not part of the wire headers) that pipeline stages set and read to pass decisions downstream — VRF, ingress port, drop reason, etc.
Analogy: Sticky notes attached to a package as it moves down the line, read and updated at each station, then discarded at shipping.
Technically: Metadata exists only for the packet's transit through the ASIC. Examples include the resolved VRF/router-interface, ingress/egress port IDs, and drop codes. It coordinates decisions across stages but is not transmitted; available metadata fields are ASIC-specific.
Match-actionParserData planeASIC
orchagentThe orchestration agent(s) inside SWSS.
The logic in the swss container that reacts to APPL_DB changes, resolves object dependencies, and produces the SAI operations needed to realize intent in hardware.
Analogy: A dispatcher turning 'we want this route' into an ordered checklist the machine operator can follow.
Technically: orchagent is a family of orchestrators (PortOrch, RouteOrch, NeighOrch, FdbOrch, VxlanOrch, etc.) sharing one process. Each watches specific APPL_DB tables and writes resulting SAI objects toward ASIC_DB. If a dependency is unresolved, the object is held pending — a common reason intent never reaches the ASIC.
SWSSsyncdAPPL_DBASIC_DBSAI
ParserThe pipeline stage that extracts header fields from a packet.
The first stage of a forwarding pipeline that walks a packet's headers and extracts the fields (MAC, VLAN, IP, ports, tunnel headers) used by later lookups.
Analogy: A mail sorter reading the envelope to pull out the address, ZIP, and postage before routing it.
Technically: Parsers may be fixed-function or programmable (as in some programmable pipelines). What the parser can recognize bounds which protocols/encapsulations (e.g. VXLAN) the ASIC can act on. In SONiC you do not program the parser directly; SAI/SDK expose only what the silicon supports.
Match-actionMetadataASICVXLAN
RedisThe in-memory key-value store SONiC uses as its shared state bus.
An in-memory database, running in the database container, that hosts SONiC's numbered logical databases and provides pub/sub so services can react to state changes.
Analogy: The shared operational record every department reads from and writes to.
Technically: SONiC runs multiple logical DBs (selected by number) inside Redis instances. Services communicate by writing keys and subscribing to keyspace notifications rather than calling each other directly. Prefer SCAN/targeted keys over KEYS *, which can block the single-threaded Redis server at scale. DB numbering is defined in database_config.json and can vary by version.
CONFIG_DBAPPL_DBASIC_DBSTATE_DBCOUNTERS_DBSONiC
RIBRouting Information Base — the control-plane route table.
The full set of routes the control plane knows, including all candidates and their attributes, before best-path selection and installation.
Analogy: The master atlas of every road anyone has ever reported — before you choose the route you will actually drive.
Technically: In SONiC the RIB lives in FRR (zebra aggregates routes from bgpd/staticd/etc.). The chosen best paths are pushed toward the kernel and, via fpmsyncd → APPL_DB → RouteOrch → SAI, become the hardware FIB. RIB ≠ FIB: a route in the RIB may not be in hardware.
FIBAPPL_DBControl plane
SAISwitch Abstraction Interface.
A vendor-neutral, object-oriented API SONiC uses to program switch ASICs — routes, next-hops, FDB, ACLs, tunnels, ports, buffers and more — through create/remove/set/get operations on SAI objects.
Analogy: A standardized control panel that fits many different families of machinery.
Technically: SAI standardizes the request, not the hardware. Supported object types, attributes, scales, and default behaviors still differ by ASIC and by each vendor's SAI implementation. A SAI call that succeeds on one platform may be unsupported or capped on another.
ASICsyncdSONiCSDKASIC_DB
SDKVendor Software Development Kit for the ASIC.
The vendor-proprietary driver/library that actually manipulates a specific ASIC family; SAI calls are translated into SDK calls beneath syncd.
Analogy: The machine-specific driver software that only that manufacturer's machinery understands.
Technically: The SDK is where vendor-specific behavior, table layouts, and quirks live. syncd links the vendor SAI, which sits on top of the SDK. Two switches can share SONiC and SAI yet differ because their SDKs and silicon differ. The SDK is generally closed-source even in open SONiC builds.
SAIsyncdASICMerchant silicon
SONiCSoftware for Open Networking in the Cloud.
A Linux-based, open-source network operating system that runs switching features as containerized services coordinating through Redis databases and programs merchant-silicon ASICs through the vendor-neutral SAI API.
Analogy: A factory of specialized departments sharing one operational record rather than a single all-knowing foreman.
Technically: SONiC is not monolithic: desired and observed state live in Redis (CONFIG_DB, APPL_DB, ASIC_DB, STATE_DB, COUNTERS_DB and others), features run as Docker containers under systemd, and hardware is programmed through SAI. Behavior, CLI, and DB layout vary across releases (e.g. 202205/202305/202311 lineages) and vendor distributions.
SAISWSSsyncdorchagentRedisDisaggregated networkingWhere it is taught →
SRAMStatic Random-Access Memory — fast on-chip tables.
Fast volatile memory used on-chip for tables and buffers that are looked up by hashing/indexing rather than parallel wildcard match.
Analogy: A well-indexed filing cabinet: fast if you know the exact drawer, but no wildcard searching.
Technically: SRAM backs exact-match tables (e.g. hash-based FDB/host routes) and packet buffers. It is denser and cheaper per bit than TCAM but cannot match wildcards in one shot. ASICs balance TCAM vs. SRAM-backed structures differently, affecting where scale limits appear.
TCAMExact matchLPMASIC
STATE_DBThe observed operational-state database.
The Redis database holding observed, runtime state — link/oper status, transceiver presence, LLDP neighbors, feature readiness — reported by monitoring agents.
Analogy: The status board on the factory floor reporting what is actually happening right now.
Technically: STATE_DB is populated by agents such as portsyncd, pmon (transceiver/thermal), and others. It answers 'what is the current observed reality?' as opposed to CONFIG_DB's intent. Useful for correlating intent vs. observed vs. programmed. Conventionally logical DB 6.
CONFIG_DBCOUNTERS_DBRedisFDB
SWSSSwitch State Service.
The container that holds the orchestration agents (orchagents) which resolve dependencies and translate application state into ordered SAI operations.
Analogy: The production coordinator who sequences work so machines are never asked to build on a part that does not yet exist.
Technically: orchagents consume objects from APPL_DB, resolve dependencies (interfaces before neighbors, neighbors before next-hops, next-hops before routes), and enqueue SAI operations. syncd, not swss, actually issues them to the vendor SAI. The swss container also hosts producers/consumers built on the sonic-swss-common library.
orchagentsyncdSAIAPPL_DB
syncdThe synchronization daemon that programs the ASIC via SAI.
The process/container that takes SAI object state and applies it to the vendor SAI implementation and SDK, keeping ASIC_DB in sync with what has actually been pushed toward hardware.
Analogy: The operator standing at the machine who executes each instruction and confirms the machine accepted it.
Technically: syncd links against the vendor SAI/SDK library and owns the sole path to the ASIC. It reconciles the desired SAI objects (written via ASIC_DB) against hardware, and reports back. Because syncd holds the vendor SDK, restarting it is where warm restart / warm reboot logic matters most.
SAISDKASIC_DBASICWarm restart
TCAMTernary Content-Addressable Memory.
A specialized memory that matches a search key against many stored entries in parallel, including wildcard (don't-care) bits — ideal for ACLs and longest-prefix matching.
Analogy: A room of clerks who all check their own rule against your request simultaneously and one raises a hand.
Technically: TCAM enables single-lookup matching with wildcards but is power-hungry, area-expensive, and limited in size — which is why ACL and route scale are ASIC-constrained. Prefixes/ACLs compete for finite TCAM; exhaustion is a real, platform-specific failure. Vendors use hybrid TCAM/algorithmic-LPM designs, so capacity varies.
SRAMLPMMatch-actionExact matchASIC
VNIVXLAN Network Identifier.
The 24-bit segment identifier carried in the VXLAN header that distinguishes overlay networks, allowing far more segments than the 12-bit VLAN space.
Analogy: The container's shipping label that says which customer's goods are inside, independent of which truck carries it.
Technically: The 24-bit VNI yields ~16M segments vs. 4094 usable VLANs. In EVPN designs, L2 VNIs map to bridge domains/VLANs and L3 VNIs map to VRFs for routed (symmetric IRB) traffic. VNI-to-VLAN and VNI-to-VRF mappings are configured in CONFIG_DB and programmed via SAI.
VXLANVTEPEVPNIRB
VTEPVXLAN Tunnel Endpoint.
The device/function that encapsulates and decapsulates VXLAN traffic, mapping local Layer-2/Layer-3 segments to VXLAN tunnels over an IP underlay.
Analogy: A shipping dock that puts local parcels into standardized containers for transit and unpacks arriving ones.
Technically: A VTEP owns a source IP (loopback in the underlay) and encaps frames into VXLAN (VNI-tagged) toward remote VTEP IPs. In SONiC, VxlanOrch programs tunnel/VTEP SAI objects; with EVPN, VTEP reachability and MAC/IP bindings are learned via BGP rather than flood-and-learn.
VXLANVNIEVPNIRBFDB
VXLANVirtual Extensible LAN — a MAC-in-UDP overlay encapsulation.
A data-plane encapsulation that tunnels Layer-2 frames inside UDP/IP (default port 4789), carrying a 24-bit VNI, so overlay segments ride over any IP underlay.
Analogy: Putting a local letter inside a standardized national-post envelope so it can traverse the wider network unchanged.
Technically: VXLAN is the data plane; EVPN is the usual control plane that populates it. SONiC programs VTEP/tunnel/VNI SAI objects via VxlanOrch. Encap/decap and VNI scale are ASIC-dependent, and the default UDP port can differ from 4789 on some deployments.
VTEPVNIEVPNIRBData plane
Warm restartRestarting a service without disrupting forwarding.
A mechanism allowing SONiC components (and warm reboot overall) to restart while the data plane keeps forwarding, by preserving and reconciling state instead of tearing it down.
Analogy: Swapping the shift crew while the machines keep running, then reconciling the logs so nothing is lost.
Technically: Warm restart relies on state in Redis and reconciliation logic so that, e.g., syncd or bgp can restart without flushing hardware. Warm reboot extends this to the whole system. Support, timers, and correctness are feature- and version-specific — some features do not support it, and traffic loss guarantees differ by platform.
syncdSWSSControl planeSTATE_DB