Module 3 · ASICs, Switching Pipelines, SAI & Forwarding

MAC Learning and FDB

55 minLabObservationPacket tracingVirtualOpen-source

Generate L2 traffic, watch MACs get learned, inspect the FDB, clear an entry and observe relearning, and compare the software-visible MAC state against forwarding behavior — surfacing the gap between what show mac reports and what the data plane does.

Safety: Caution

May change state — take a snapshot first.

sonic-clear fdb causes a brief flood as MACs relearn — safe on VS/lab, but understand the transient before running anywhere shared.

VS learning is emulated; do not treat its timing/behavior as representative of physical hardware.

Two hosts in one VLAN

  hostA ── Ethernet0 ─┐
                       ├─ SONiC-VS (VLAN 10 bridge)
  hostB ── Ethernet4 ─┘

Objective

• Observe source-MAC learning populate the FDB.
• Inspect FDB entries and clear/relearn a specific MAC.
• Compare software-visible MAC state with actual forwarding.

Starting state

• A VLAN (e.g., VLAN 10) with two member ports, both up.
• FDB initially empty or aged for the test MACs.

Prerequisites: Lesson 3.6 complete. · Two endpoints in the same VLAN on the VS (two attached hosts, or Linux namespaces / a traffic tool).

Tasks

1
Baseline the empty/aged FDB
SONiC CLIsoftware-visible FDB (fdbshow)
```
show mac
```
SONiC CLI
```
show vlan brief
```
Expected:
- No (or stale) entries for the test MACs; VLAN 10 shows both member ports.
What happened internally: show mac reads the software-visible FDB fed by SAI FDB notifications — the view you will compare against forwarding.
2
Generate L2 traffic and watch learning
Send from hostA to hostB (and back) to trigger source-MAC learning on both ingress ports.
Linux
```
ping -c 3 <hostB-ip>   # from hostA
```
SONiC CLI
```
show mac | grep -Ei '<hostA-mac>|<hostB-mac>'
```
Expected:
- FDB now shows (VLAN 10, hostA MAC)→Ethernet0 and (VLAN 10, hostB MAC)→Ethernet4.
What happened internally: Each source MAC is learned against its ingress bridge port. The first frame to an unknown dst floods; once both sides are learned, delivery is unicast.
3
Observe the FDB as SAI objects (optional deepening)
SONiC DBASIC_DB FDB entries
```
redis-cli -n 1 SCAN 0 MATCH 'ASIC_STATE:SAI_OBJECT_TYPE_FDB_ENTRY*' COUNT 500
```
Expected:
- FDB_ENTRY objects keyed by bridge/VLAN + MAC, referencing a bridge port.
What happened internally: This ties the software view to the sync-path objects. On VS these are emulated and may not match physical ASIC timing.
4
Clear an entry and observe relearning
SONiC CLI Disruptiveflushes dynamic MACs; brief flooding while relearning
```
sudo sonic-clear fdb type dynamic
```
SONiC CLI
```
show mac | grep -Ei '<hostA-mac>|<hostB-mac>'
```
Linux
```
ping -c 3 <hostB-ip>   # re-trigger learning
```
Expected:
- Entries disappear after the clear; a short flood window; entries reappear after traffic.
What happened internally: Clearing removes dynamic FDB entries; the next frames are unknown-unicast (flooded) until source MACs are relearned. This is normal L2 behavior, not a fault.
5
Compare software-visible state vs forwarding
Immediately after clearing, send one frame and note whether forwarding succeeds even before show mac reflects the relearned entry — the software view lags notifications.
Linux
```
sudo tcpdump -ni Ethernet4 icmp   # confirm delivery at egress
```
SONiC CLI
```
show mac | grep -Ei '<hostB-mac>'
```
Expected:
- Delivery can be observed at the egress port around the same time the software view updates; note any brief discrepancy.
What happened internally: The point: show mac is the software-visible view fed by notifications; it is normally accurate but can briefly differ from the data plane. On VS the timing is emulated — do not generalize VS timing to hardware.

Troubleshooting branches

If: MAC never learned despite traffic

Then: Confirm both ports are in the VLAN and up; confirm traffic actually ingresses (tcpdump on the ingress netdev).

If: Persistent flooding after learning

Then: Look for asymmetric paths or a MAC move/flap (same MAC bouncing ports) indicating a loop or dual-homing.

If: show mac and forwarding disagree for more than a moment

Then: On hardware, check for notification backlog; on VS, treat timing as emulated and not authoritative.

Cleanup / rollback

Clear any test dynamic MACs if desired; revert to 'baseline' snapshot to guarantee a clean state.

Lab evidence checklist

☐ Baseline (empty/aged) FDB captured.
☐ Learned entries for both test MACs captured with their ports.
☐ Clear + relearn sequence captured (including the flood window).
☐ One observation comparing software-visible MAC state to actual forwarding.

Reflection

Why is flooding after a clear expected rather than a failure?
What exactly does show mac report, and when might it briefly differ from the data plane?
How would this same learning/flood model extend across a fabric under EVPN/VXLAN?

Lab notes & observations