Lesson
How Switches Learn and Forward
Learning objective
Build and use a MAC address table to predict forwarding, filtering, and flooding.
The switch decision cycle
A switch connects devices inside a Layer 2 network and decides where each Ethernet frame should leave. It does not begin by asking for the sender's IP route or application. It works with the frame arriving on a physical or logical switch interface.
For every ordinary frame, remember this order:
- Receive the frame on an ingress interface.
- Learn the source MAC address on that ingress interface.
- Look up or classify the destination MAC address.
- Forward, filter or flood through eligible interfaces—never back through ingress.
Think of a receptionist recording the door through which a person entered, then consulting a directory for the recipient. The analogy stops at one important limit: a switch learns from observed source frames, not from a trusted identity system, and an entry can age or move.
Learn the source address
When a frame from 02:00:00:00:00:0A arrives on Gi0/1, the switch records or refreshes
02:00:00:00:00:0A → Gi0/1. That evidence answers one narrow question: where was this source
most recently observed in this Layer 2 scope?
The switch does not learn the destination from this frame. If the same source later arrives on
Gi0/3, source learning refreshes the entry to Gi0/3. This is how normal host movement is
learned; the table is dynamic rather than a permanent cabling inventory.
Look up the destination
After source learning, the switch examines the destination MAC:
- A current unicast entry on another interface identifies one egress interface.
- A current unicast entry on the ingress interface means no other interface is required.
- A missing unicast entry remains unicast, but its location is unknown.
FF:FF:FF:FF:FF:FFis explicitly broadcast and is not narrowed by a unicast table entry.
The source and destination fields have different jobs: the source teaches the switch; the destination guides the forwarding decision.
Forward, filter or flood
| Destination evidence | Decision | Eligible egress | What it means |
|---|---|---|---|
| Known on another interface | Forward | That learned interface | Known unicast |
| Known on ingress | Filter | None | The destination is already behind the arriving segment |
| Unknown unicast | Flood | All eligible interfaces except ingress | One destination, temporarily unknown location |
| Broadcast | Flood | All eligible interfaces except ingress | Every receiver in the Layer 2 broadcast domain examines it |
Flooding describes a switch action, not automatic acceptance by every endpoint. A network interface can receive a copy and discard it because the destination does not apply: receipt is not acceptance. The switch also stays within its current Layer 2 scope; routing and VLAN boundaries are separate decisions.
Interactive switch learning
Watch the frame enter a labelled interface, open its Ethernet fields, and follow the MAC table through source learning, destination lookup, egress selection and transmission. The player starts automatically unless reduced motion is enabled; all stages remain available through manual controls.
Watch the switch make one decision
Change the evidence, then replay the same receive → learn → look up → forward sequence.
The destination entry identifies Gi0/2, so one copy leaves that interface.
- Host A: Host A eth0Switch: Switch Gi0/1
- Switch: Switch Gi0/2Host B: Host B eth0
- Switch: Switch Gi0/3Host C: Host C eth0
Active: Host A, Switch; link Host A to Switch
Step 1 of 5
Frame arrives on Gi0/1
Host A transmits one Ethernet frame. The switch receives it on Gi0/1 before making any forwarding decision.
Packet inspector
Inside the packet
Ethernet frame
- Source MAC
- 02:00:00:00:00:0A
- Destination MAC
- 02:00:00:00:00:0B
Technical packet details
- Ingress interface
- Gi0/1
- MAC table before
- 02:00:00:00:00:0B → Gi0/2
Read MAC-table evidence
I know this—proceed to advancedA MAC table is evidence about learned Layer 2 locations. Read the VLAN or forwarding context, MAC address, learned interface and entry freshness together. A single entry does not prove that the endpoint has a correct IP address, that return traffic works, or that its application is healthy.
Basic Wireshark check
Display filter: eth.addr == 02:00:00:00:00:0A
Fields to inspect
frame.numbereth.srceth.dsteth.typeframe.time_relative
Normal evidence: Repeated source frames establish where and when the endpoint was observed. Compare the capture point with the switch's learned interface before claiming movement or flooding.
Try it: Send traffic in both directions. Record the first unknown-unicast observation, the reply that teaches the second source, and a later known-unicast exchange.
Evidence-first switching workflow
- Define the affected hosts, traffic direction, and local scope.
- Verify physical link and port state before interpreting the forwarding table.
- Identify the observed ingress port and every expected eligible egress port.
- Read the source MAC, destination MAC, and whether the destination is unicast or broadcast.
- Inspect the forwarding table and whether its entries are current.
- Compare observed behavior with known forwarding, filtering, or flooding.
- Change one condition, repeat the same test, and record the result.
Diagnose switching behaviour
Use the same evidence sequence every time:
- Define the affected source, destination, direction and Layer 2 scope.
- Verify link and interface state before interpreting the MAC table.
- Identify ingress and read the frame's source and destination MAC addresses.
- Confirm whether the source entry was learned or refreshed.
- Classify the destination as known unicast, unknown unicast or broadcast.
- Predict eligible egress interfaces, excluding ingress.
- Repeat the same traffic and compare the new table and forwarding result.
Common mistakes include clearing the entire table before collecting evidence, calling every flooded frame a broadcast, assuming an aged entry proves failure, and treating a learned MAC as proof that the application works. A physical link failure must be repaired before MAC-table changes can help.
Interview scenario
The first frame to a server is seen on three access ports, but later frames use only one. Is the switch malfunctioning?
Show answer and reasoning
Not necessarily. The first destination may have been unknown, so the switch flooded eligible ports. A reply taught the server's source location, allowing later known-unicast forwarding. Verify the destination bit pattern, table timestamps, VLAN and capture position before concluding there is a loop.
Interview scenario
A user's MAC address changes from Gi0/2 to Gi0/3. What would you verify before treating it as an attack?
Show answer and reasoning
Confirm the endpoint identity, recent physical move, wireless or downstream bridging path, timestamps, VLAN context and repeated source frames. Source learning refreshes a legitimate moved host. Rapid alternation between distant interfaces can be suspicious, but one updated entry is not sufficient proof.
Knowledge check and summary
Remember: learn the source first, inspect the destination second, then forward, filter or flood. Always separate receipt, forwarding and endpoint acceptance when explaining the outcome.