Predicting Switch Forwarding, Filtering, and Flooding Decisions

Welcome back. You can now decode the Ethernet header itself: destination MAC, source MAC, EtherType, optional VLAN tag, and the role of FCS. The next operational question is what a switch does when that frame arrives on one of its ports.

This lesson develops a repeatable way to predict a switch’s decision from the frame’s MAC addresses, ingress port, VLAN, and MAC address table. The core logic is simple, but it underlies much of Layer 2 troubleshooting: unexpected flooding, MAC moves, stale entries, VLAN mistakes, and suspicious CAM-table behavior all become easier to reason about once the baseline is precise.

---

The switch’s local view: a forwarding database, not a network map

A Layer 2 switch does not use the IP header to make its ordinary Ethernet forwarding decision. It treats the IP packet, TCP segment, DNS message, or other upper-layer data as payload. Its immediate concern is the Ethernet frame:

• Which port did this frame enter?
• Which VLAN does that frame belong to?
• What is its source MAC address?
• What is its destination MAC address?

The switch keeps a MAC address table, also called a CAM table or forwarding database (FDB). Conceptually, it records:

VLAN	Learned MAC address	Associated switch port	Entry type
10	0000.000a.aaaa	Gi1/1	Dynamic
10	0000.000b.bbbb	Gi1/2	Dynamic

The VLAN is essential. A practical table lookup is not merely “find this MAC address”; it is “find this MAC address within this VLAN.” The same MAC address can legitimately appear in more than one VLAN, and a trunk can lead to many MAC addresses in many VLANs.

A table entry means only this:

The switch most recently saw a frame with this source MAC address arrive on this port in this VLAN.

It does not prove that the MAC belongs directly to a device attached to that exact physical port. The port could lead to another switch, a wireless access point, a hypervisor, a downstream firewall, or another Layer 2 domain.

This short segment from Everything Switches do – Part 1 by Practical Networking gives a visual model of the MAC table and the three basic switch behaviors.

---

The essential algorithm: learn first, then decide

When a switch receives an Ethernet frame, it performs two logically distinct tasks.

1. Learn from the source MAC

The switch examines the source MAC address and associates it with the ingress port and VLAN.

If host 0000.000a.aaaa sends a frame into Gi1/1 in VLAN 10, the switch learns or refreshes an entry such as:

VLAN	MAC	Port
10	0000.000a.aaaa	Gi1/1

This is why switches can begin operating with an empty table. They learn locations from ordinary traffic; they do not need a prior inventory of all endpoint MAC addresses.

A source-MAC observation can produce several outcomes:

• If the source MAC is new, the switch adds a dynamic entry.
• If the MAC is already recorded on the same port and VLAN, the switch refreshes its aging timer.
• If the MAC appears on a different port in the same VLAN, the switch updates the entry. Repeated rapid moves are commonly logged as MAC flapping and may indicate a Layer 2 loop, a misconfigured virtual environment, or an endpoint that is moving unexpectedly.

Dynamic entries age out after an inactivity interval. Five minutes is a common default, though the value is platform- and configuration-dependent. Aging is normal: it prevents a table from indefinitely retaining locations for disconnected or moved devices.

2. Look up the destination MAC

After learning from the source, the switch looks up the destination MAC address in the table for the frame’s VLAN. The result determines whether it forwards, filters, or floods.

Destination condition	Switch decision	Egress ports
Known unicast on a different port	Forward	Only the port associated with that MAC
Known unicast on the ingress port	Filter	None
Unknown unicast	Flood	All eligible ports in the same VLAN except ingress
Broadcast	Flood	All eligible ports in the same VLAN except ingress
Unknown multicast	Usually flood by default	All eligible ports in the same VLAN except ingress

The phrase eligible ports matters. In the base forwarding model, flooding reaches ports in the same VLAN other than the ingress port. In a real network, a port must also be operational and in a forwarding state. For example, a spanning-tree-blocked port is not used as a normal flooding egress path.

Cisco’s Troubleshoot LAN Switching Environments describes the same transparent-bridging rules using CAM-table terminology.

---

Forwarding: the destination is known elsewhere

A known unicast frame is a frame whose destination MAC address has a matching entry in the switch’s table for the current VLAN.

Consider the following switch state.

Suppose host-2 sends a frame in VLAN 10:

Frame field	Value
Ingress port	Gi1/2
Source MAC	0000.000b.bbbb
Destination MAC	0000.000a.aaaa

The switch first refreshes its entry for source 0000.000b.bbbb on Gi1/2. It then searches for destination 0000.000a.aaaa in VLAN 10 and finds Gi1/1.

The decision is forward: send one copy only out Gi1/1.

Host-1 receives the frame; server-1 does not receive it, because Gi1/3 is not a selected egress port. This is the normal steady state of switched Ethernet: traffic that is known to be for a particular MAC is not copied to every port.

A switch performs this lookup independently at every hop. In the two-switch topology below, SW1 and SW2 have separate MAC tables. SW2 does not query SW1’s table, and SW1 does not push its full table to SW2 as part of ordinary Ethernet forwarding.

An uplink can therefore have several remote MAC addresses associated with it. For example, SW2 may learn both Fred’s and Barney’s MAC addresses on G0/2 because frames sourced by both hosts arrive from the SW1 side. That is normal and does not mean both endpoints are physically cabled into the same SW2 port.

---

Flooding: the destination is unknown, broadcast, or sometimes multicast

A frame is unknown unicast when its destination is a unicast MAC address, but the switch has no matching entry for that MAC in the relevant VLAN.

Return to the first diagram. Initially, switch-1 knows host-1 and host-2, but not server-1.

Host-1 sends a frame addressed to server-1:

Frame field	Value
Ingress port	Gi1/1
Source MAC	0000.000a.aaaa
Destination MAC	0000.1234.5678

The switch refreshes its source entry for host-1. It then searches its VLAN 10 MAC table for 0000.1234.5678 and finds no entry.

The switch cannot select one particular egress port, so it floods the frame:

• It sends one copy out Gi1/2.
• It sends one copy out Gi1/3.
• It does not send the frame back out Gi1/1.

The destination MAC in every copy remains 0000.1234.5678. The switch has not converted it into a broadcast frame; it has copied an unknown-unicast frame to multiple ports. Host-2 receives a copy but its NIC sees a destination MAC that does not match host-2, so it discards it. Server-1 accepts the frame because the destination MAC matches its own interface.

If server-1 replies, the switch receives that reply on Gi1/3 with source MAC 0000.1234.5678. It learns server-1’s location. The reply is then forwarded directly to host-1 through Gi1/1 because host-1 is already known. Subsequent host-1-to-server-1 frames are now known unicasts and are forwarded only through Gi1/3.

Broadcast flooding

An Ethernet broadcast has destination MAC address ff:ff:ff:ff:ff:ff. A switch floods broadcast frames within the VLAN, excluding the ingress port.

This is why VLANs are commonly called broadcast domains. A broadcast received in VLAN 10 is not normally sent to ports that belong only to VLAN 20, even if they are physically connected to the same switch.

ARP requests are an important example of broadcast traffic, but the next lesson will trace the ARP request and reply in detail.

Multicast and the baseline rule

Unknown multicast frames are commonly flooded in the same way as broadcast frames within the VLAN. However, later multicast-control mechanisms can constrain this behavior. For example, IGMP snooping can allow a switch to send multicast traffic only to ports with interested receivers.

For the present purpose, use this baseline:

• Broadcast is always a VLAN-scoped flooding case.
• Unknown unicast is a VLAN-scoped flooding case.
• Unknown multicast is generally flooded unless the switch has multicast-snooping state or policy that changes the egress set.

Do not use the word broadcast to mean every kind of flooding. Broadcast is a destination-MAC classification; flooding is a switch forwarding action.

---

Filtering: the destination is already behind the ingress port

A switch filters a frame when it finds the destination MAC address in its table, but that entry points to the same port on which the frame arrived.

For example:

Frame field	Value
Ingress port	Gi1/1
Source MAC	0000.000c.cccc
Destination MAC	0000.000a.aaaa
VLAN	10

Assume the table already says that 0000.000a.aaaa is reachable through Gi1/1. The switch learns or refreshes source 0000.000c.cccc on Gi1/1, looks up destination 0000.000a.aaaa, and sees that the destination is also on Gi1/1.

The switch sends no copy back out Gi1/1. That is filtering.

This situation makes most sense when Gi1/1 leads to a downstream Layer 2 segment, such as another switch, a hub-like device, or an attached virtualization environment containing multiple MAC addresses. The frame has already entered from the same direction in which the destination is known to reside, so transmitting it back toward that segment would be needless.

In switching terminology, filtering here does not mean a security policy blocked the frame. It is simply an efficiency decision based on Layer 2 location. Firewalls, ACLs, port-security rules, and other policy engines may also drop traffic, but those are distinct mechanisms that must not be confused with same-port filtering.

---

A decision routine you can apply to any frame

For a frame-prediction question, work in this order. State the VLAN explicitly if it is supplied or can be inferred.

1. Identify the ingress port and VLAN.
   On an access port, the switch commonly assigns the VLAN based on port configuration. On a trunk, the tag or native-VLAN treatment determines the VLAN context.

2. Learn from the source MAC.
   Add, refresh, or move the source MAC entry for that VLAN and ingress port.

3. Classify the destination MAC.
   Decide whether it is unicast, broadcast, or multicast.

4. If it is a known unicast, compare ports.
   If the destination’s port differs from the ingress port, forward only to that port. If it matches the ingress port, filter it.

5. If it is an unknown unicast, broadcast, or baseline unknown multicast, flood it.
   Use all eligible forwarding ports in the same VLAN, excluding the ingress port.

A compact answer format is useful during troubleshooting and design reviews:

Ingress: Gi1/2, VLAN 10.
Learning: source 0000.000b.bbbb is refreshed on Gi1/2.
Lookup: destination 0000.1234.5678 is unknown in VLAN 10.
Decision: unknown-unicast flooding.
Egress: all eligible VLAN 10 ports except Gi1/2.

That structure prevents two common errors: forgetting source learning and saying “all ports” without applying VLAN and ingress-port constraints.

---

Operational interpretation: why the table may not look as expected

A MAC table is a live, time-dependent observation, not permanent truth. When troubleshooting, unexpected behavior usually has a limited set of explanations.

Observation	Likely interpretation
Destination is unknown and traffic floods	The destination has not transmitted recently, its entry aged out, it is in another VLAN, or the table lacks capacity or correct state
Same MAC repeatedly moves between ports	Layer 2 loop, endpoint movement, misconfigured virtual switching, dual attachment, or spoofing investigation
Many MAC addresses on an uplink	Usually normal; the uplink reaches a downstream Layer 2 domain
No MACs learned on an active access port	Endpoint may be silent, link/VLAN state may be wrong, or the port may not be forwarding
A host sees traffic not intended for it	It may be receiving flood traffic, or a capture/SPAN configuration may be copying traffic to the observation point

This is also why unknown-unicast flooding is relevant to security architecture. It is a necessary recovery mechanism for an empty or incomplete forwarding table, but excessive unknown-unicast flooding increases unnecessary exposure within a VLAN. Controls such as sensible VLAN boundaries, spanning tree, port security, MAC limits, and monitoring of MAC moves can reduce the likelihood and impact of abnormal Layer 2 behavior. The exact controls come later; for now, the important diagnostic anchor is whether a frame was known, unknown, broadcast, or filtered at the moment the switch received it.

Brief EVE-NG observation

In an isolated lab, connect three hosts to a switch in one VLAN. Establish connectivity between two hosts first so their ARP caches are populated, then clear the switch’s dynamic MAC table using the platform-appropriate lab command, such as clear mac address-table dynamic on Cisco IOS-like images.

Send one ping from host A to host B, then inspect the MAC table. The first unicast frame after the table clear causes the switch to learn host A and flood toward the still-unknown host B. Host B’s reply teaches the switch where B resides, so later traffic between A and B is known unicast. If you capture on host C’s segment, it can observe the initial flooded frame but should not see later known-unicast traffic between A and B.

---

Key takeaways

• A MAC address table records where the switch has learned a source MAC address, scoped to a VLAN.
• A switch learns from the source MAC first, then makes its delivery decision from the destination MAC.
• A known unicast destination on a different port is forwarded only through that destination port.
• A known unicast destination on the same ingress port is filtered: no egress copy is sent.
• Unknown unicasts and broadcasts are flooded only through eligible ports in the same VLAN, never back through the ingress port.
• Each switch maintains its own MAC table. An uplink commonly represents many remote MAC addresses.
• MAC entries age and can move, so the forwarding table must be interpreted as current learned state rather than a static topology diagram.

Next, you will follow one of the most common reasons a switch floods in the first place: an ARP request. You will trace the ARP request and reply through a subnet and learn how to recognize abnormal ARP behavior in a packet capture.