RIB, FIB & Hardware State
You already know RIB versus FIB. SONiC stretches that two-layer idea into a chain of distinct state representations: bgpd's Loc-RIB, zebra's RIB, (optionally) the Linux kernel FIB, SONiC's APPL_DB route state, the ASIC_DB SAI route objects, and finally the real forwarding entries in silicon. A route can be present in one layer and absent in the next — and knowing which layer you are looking at is most of the diagnosis.
Prerequisites: Lesson 2.1 (FRR inside SONiC). · Module 1 database model.
Learning objectives
- →Enumerate the route-state layers in SONiC and what each authoritatively represents.
- →Explain why the Linux kernel FIB is a supporting/optional representation on a SONiC switch, not the forwarding plane.
- →Map each layer to the command or database key that observes it.
- →Reason about mismatches: a route in zebra but not APPL_DB, in APPL_DB but not ASIC_DB, etc.
On a monolithic NOS you had two mental buckets — RIB and FIB — and vendor tooling hid the rest. SONiC exposes the whole chain, so 'the route is in the table' is ambiguous until you say which table.
Most 'the route exists but traffic drops' cases are a break between two adjacent layers. If you can name the layers, you can bisect the failure quickly.
What your CCNP already gives you
- • The core RIB-vs-FIB distinction and why a RIB entry is not automatically a forwarding entry.
- • Recursive next-hop resolution and administrative distance / route preference.
- • The instinct to compare control-plane tables against forwarding tables.
What is new in SONiC
- • There are more than two layers, and they live in inspectable databases.
- • The kernel FIB is present but is not the switch's forwarding plane — the ASIC is.
- • The 'FIB of record' for hardware is ASIC_DB (SAI objects), reflecting what syncd programmed.
- • You can query each layer directly and pinpoint exactly where a route stops.
| In the analogy | In SONiC |
|---|---|
| Every travel plan anyone suggested, including ones you'll reject | bgpd Loc-RIB (all received paths) |
| The single set of directions you actually chose to follow | zebra RIB (selected/best routes) |
| A copy of the directions taped to the dashboard for the driver-assist software | Kernel FIB (where used) |
| The directions handed to the installer who programs the car's nav hardware | APPL_DB ROUTE_TABLE |
| The route as it now exists inside the nav unit's own memory | ASIC_DB SAI route object |
| The turn the car actually takes at speed | ASIC forwarding entry |
ROUTE_TABLE entries. The orchestration layer turns them into SAI route objects visible in ASIC_DB, and syncd programs the physical forwarding tables. Forwarding is decided by the *last* layer — the silicon entry — not by anything upstream.Where the analogy stops working
A paper map and a car's nav unit are obviously different objects, but in SONiC several of these 'layers' are representations of the same intended route in different stores, and they are meant to converge. When they do not converge quickly, that is not normal steady state — it is the signal. Also, on SONiC-VS there is no real ASIC, so ASIC_DB entries and 'forwarding' are simulated; do not treat VS as proof of silicon behavior.
The route-state layers, top to bottom
| Layer | What it represents | How you observe it | Authoritative for |
|---|---|---|---|
| bgpd Loc-RIB | All BGP paths for a prefix, best-path marked | vtysh -c 'show ip bgp <prefix>' | BGP path selection |
| zebra RIB | Selected routes across all sources (AD applied) | vtysh -c 'show ip route <prefix>' | What FRR chose to install |
| Kernel FIB (where used) | Linux route table copy of selected routes | ip route show <prefix> | Host/software forwarding, punts |
| APPL_DB ROUTE_TABLE | Routes handed to SONiC orchestration | sonic-db-cli APPL_DB HGETALL 'ROUTE_TABLE:<prefix>' | Intent handed toward hardware |
| ASIC_DB SAI route object | The route as programmed via SAI | sonic-db-cli ASIC_DB SCAN for SAI_OBJECT_TYPE_ROUTE_ENTRY | What syncd programmed |
| ASIC forwarding entry | The actual silicon forwarding table | vendor sai/bcmcmd/platform tools | Real packet forwarding |
Why the kernel FIB is a supporting actor
On a Linux router, ip route *is* the FIB. On a SONiC switch it is not the data-plane FIB — it exists so the host stack can originate/receive traffic, handle control-plane punts, and give tools like ip something to read, but transit packets are switched by the ASIC, programmed through SAI. So ip route show can be a useful cross-check, yet a route being present there does not prove hardware forwarding, and its absence does not necessarily prove a data-plane outage. Whether zebra installs into the kernel at all can also depend on configuration (e.g., FPM-only setups).
When someone says 'the route is in the table,' your first question is which table. Loc-RIB, zebra RIB, kernel FIB, APPL_DB, ASIC_DB, and the silicon entry are six different answers, and the gap between two adjacent ones is where most forwarding bugs live.
Walking one prefix down the stack (read-only)
PFX=10.100.5.0/24
# 1) zebra RIB (selected)
docker exec bgp vtysh -c "show ip route $PFX"
# 2) APPL_DB route intent
sonic-db-cli APPL_DB HGETALL "ROUTE_TABLE:$PFX"
# nexthop: 10.0.0.1 ifname: Ethernet4
# 3) ASIC_DB SAI route objects (SCAN, do not KEYS *)
sonic-db-cli ASIC_DB EVAL \
"return redis.call('SCAN',0,'MATCH','ASIC_STATE:SAI_OBJECT_TYPE_ROUTE_ENTRY:*','COUNT',100)" 0
# -> pick the entry whose 'dest' matches 10.100.5.0/24, then HGETALL itPrefer targeted keys and SCAN over KEYS *. ASIC_DB route entries are keyed by a JSON blob, so SCAN with a type match, then inspect. Output is illustrative and version-dependent.
Common misconceptions
Myth: ip route on the switch shows what the hardware forwards.
Reality: It shows the kernel FIB, a supporting representation. Hardware forwarding is reflected in ASIC_DB SAI route objects, programmed by syncd.
Myth: If zebra selected the route, it is programmed in silicon.
Reality: zebra's selection only guarantees it reached the RIB. It still must traverse FPM → APPL_DB → orchagent → SAI → ASIC_DB → silicon.
Myth: APPL_DB and ASIC_DB should sometimes differ, that's normal.
Reality: Transient skew during convergence is normal; persistent divergence is a defect signal (orchagent stuck, SAI error, resource exhaustion) worth investigating.
- Bisect: confirm the route in zebra, then APPL_DB, then ASIC_DB. The first missing layer localizes the fault.
- Use the kernel FIB as a hint, never as proof of hardware forwarding.
- Persistent APPL_DB ↔ ASIC_DB divergence points at the orchagent/syncd/SAI stage, not at BGP.
Key takeaways
- ✓SONiC expands RIB/FIB into six observable route-state layers.
- ✓The ASIC (via ASIC_DB SAI objects) is the forwarding plane; the kernel FIB is only a supporting representation.
- ✓A route can exist at one layer and be missing at the next — name the layers to bisect the failure.
- ✓On SONiC-VS the lower layers are simulated; validate silicon behavior on real hardware.
Tested against: SONiC 202305 / 202311 lineage · Upstream unless noted · SONiC-VS for DB observation; real ASIC for true hardware state · last reviewed 2026-07. Exact commands and behavior can vary by SONiC release, image, hardware platform, and enterprise distribution.
Knowledge check
On a SONiC switch, which statement about the Linux kernel FIB (ip route) is correct?
Order these route-state representations from control-plane candidate down to actual silicon forwarding.
- 1ASIC_DB SAI route object
- 2zebra RIB (selected)
- 3ASIC forwarding entry
- 4bgpd Loc-RIB (all paths)
- 5APPL_DB ROUTE_TABLE
Related lessons