Full Bridged Packet Walk
Follow an L2 packet: source-MAC learning into the FDB, destination FDB lookup, and the three delivery cases — known unicast (forward to one port), unknown unicast and broadcast (flood within the VLAN), and multicast (constrained or flooded). Egress filtering (split-horizon, STP/VLAN state) prunes where the frame may go. Bridging does not rewrite MACs or touch TTL.
Prerequisites: Lesson 3.2 · Lesson 3.5
Learning objectives
- →Explain source-MAC learning and how it populates the FDB (SAI FDB entries).
- →Trace destination FDB lookup and the known-unicast forward.
- →Explain flooding for unknown unicast and broadcast within a VLAN.
- →Describe multicast handling considerations and egress filtering.
- →Contrast bridged forwarding with routed forwarding (no MAC rewrite, no TTL change).
L2 problems (flooding, MAC flaps, missing FDB entries) are common and are diagnosed by understanding learning and lookup precisely.
EVPN/VXLAN (later module) builds directly on this FDB/flood model, extended across a fabric.
What your CCNP already gives you
- • You know MAC learning, aging, unicast flooding, broadcast, and STP port states.
- • You understand VLANs as broadcast domains and the flood scope they define.
What is new in SONiC
- • FDB entries are SAI objects (keyed by VLAN+MAC → bridge port) observable in the databases.
- • Learning events can surface as SAI FDB notifications flowing back up to STATE_DB.
- • Software-visible MAC state and true hardware forwarding can momentarily differ — you will test this in Lab 3.2.
| In the analogy | In SONiC |
|---|---|
| Noting which corridor a sender's mail came from | Source-MAC learning |
| The mail room's who-sits-where directory | FDB table |
| Deliver straight to the one known desk | Known unicast |
| No directory entry → copy to every desk in the department (VLAN) | Unknown unicast / broadcast |
| Skip corridors that are blocked or the one it arrived on | Egress filtering |
Where the analogy stops working
Real learning has aging, move detection, and hardware/software interplay (some learning is offloaded to the ASIC, some events are punted). Multicast can be flooded or constrained (IGMP/MLD snooping). The directory is finite — a full FDB changes behavior. The analogy omits these; the lesson does not.
The bridged packet walk
- Ingress + VLAN classification: frame arrives; ingress VLAN determined (tagged or port default). The (VLAN) defines the flood domain.
- Source-MAC learning: the (VLAN, source MAC) is learned against the ingress bridge port. New or moved MACs create/update a FDB entry; a move (same MAC, new port) updates the entry (and may raise a notification).
- Destination-MAC lookup: the (VLAN, destination MAC) is looked up in the FDB (exact-match).
- Case A — known unicast: hit → forward to the single bridge port in the entry (subject to egress filtering).
- Case B — unknown unicast: miss → flood to all ports in the VLAN except the ingress port.
- Case C — broadcast: destination FF:FF:FF:FF:FF:FF → flood to all ports in the VLAN except ingress.
- Case D — multicast: without snooping, treated like broadcast within the VLAN; with IGMP/MLD snooping, constrained to ports with interested receivers.
- Egress filtering: prune the delivery set — never send back out the ingress port; honor STP/port state and VLAN membership/tagging; apply split-horizon where applicable (e.g., overlay).
- Transmit: frame egresses unchanged at L2 (no MAC rewrite, no TTL decrement). Egress counters increment per port.
Bridged vs routed forwarding (the diagnostic contrast)
| Aspect | Bridged (L2) | Routed (L3) |
|---|---|---|
| Lookup key | (VLAN, destination MAC) exact-match FDB | Destination IP, LPM route table |
| Miss behavior | Flood within the VLAN | Drop / default route / punt to resolve |
| MAC addresses | Unchanged (delivered as-is) | Rewritten: src=router MAC, dst=neighbor MAC |
| TTL / checksum | Untouched | TTL decremented; IPv4 checksum updated |
| Scope | One broadcast domain (VLAN) | Between subnets / VRFs |
| Key object | FDB entry, VLAN, bridge port | Route, next hop, RIF, neighbor |
The same MAC can exist in multiple VLANs as independent entries. A MAC that rapidly changes ports (a MAC move/flap) usually signals a loop, a dual-homed device, or a misconfig — and can generate notification churn. Persistent unknown-unicast flooding often means asymmetric paths or aging mismatches so the destination is never learned.
Software-visible state vs hardware forwarding
show mac (fdbshow) presents learned MACs from SONiC's databases, which are fed by SAI FDB notifications. On real hardware, learning may be offloaded to the ASIC and reported up asynchronously, so there can be a brief window where the software view and the exact hardware state differ — and on SONiC-VS learning is emulated and may not mirror any physical ASIC's timing or behavior at all. When L2 forwarding and the MAC table seem to disagree, that gap between *software-visible* and *hardware-programmed* state is the thing to test (Lab 3.2), not a number to trust blindly.
Common misconceptions
Myth: Flooding means something is broken.
Reality: Unknown-unicast and broadcast flooding is normal L2 behavior. It is a problem only when it is excessive or persistent (e.g., a destination that should be learned never is).
Myth: A switch rewrites MACs when bridging.
Reality: Bridging forwards frames unchanged. MAC rewrite and TTL decrement are routing (L3) behaviors — a key way to tell what actually happened to a frame.
Myth: The MAC table in show output is exactly the hardware.
Reality: It is the software-visible view fed by notifications. It is normally accurate but can briefly diverge from hardware; VS may not reflect real behavior.
- Excessive unknown-unicast flooding: check whether the destination MAC is ever learned (asymmetry, aging) rather than assuming a hardware fault.
- MAC flapping between ports: suspect a loop or dual-homing before blaming the FDB.
- If L2 forwards but
show maclooks wrong (or vice versa), test the software-visible-vs-hardware gap explicitly.
Key takeaways
- ✓Bridging learns (VLAN, src MAC)→port, then looks up (VLAN, dst MAC): hit=unicast to one port, miss/broadcast=flood in the VLAN.
- ✓Multicast is flooded like broadcast unless snooping constrains it; egress filtering prunes ingress port, STP/VLAN state, split-horizon.
- ✓Bridging delivers frames unchanged — no MAC rewrite, no TTL decrement (unlike routing).
- ✓FDB entries are SAI objects; learning surfaces via notifications, so software-visible state can briefly differ from hardware (and VS may not mirror hardware).
Tested against: Model; ASIC specifics vary · Upstream concepts · Reasoning model · last reviewed 2026-07. Exact commands and behavior can vary by SONiC release, image, hardware platform, and enterprise distribution.
Knowledge check
A monitoring alert flags 'excessive unknown-unicast flooding' in one VLAN. Explain how bridged forwarding produces flooding normally, and how you would decide whether this instance is a real problem — and contrast why bridged forwarding floods on a miss whereas routed forwarding does not.