An Ethernet switch does not “know” where a host lives simply because the host appears on a network diagram. It learns a forwarding association from the source MAC address of frames it receives in a particular VLAN. Cisco CCNA 200-301 v1.1 explicitly tests MAC learning, aging, unicast forwarding, flooding and MAC address-table behavior. Understanding this process explains why a healthy cable can coexist with missing connectivity—and why a router does not merely extend a Layer 2 flooding domain.
The examples here use Ethernet switching concepts and Cisco IOS-style observation commands. They are worked illustrations, not logs from a production device. The relevant official objectives appear in Cisco CCNA v1.1 topics 1.13.
Learn from source addresses; forward by destination addresses
Imagine two endpoints, A and B, on switch ports Gi1/0/1 and Gi1/0/2 in VLAN 10. The first frame arrives from A with source MAC 0011.2233.4455. The switch updates or creates a dynamic table entry mapping that source MAC to the ingress port and VLAN. It then examines the destination MAC to choose whether to forward the frame to a known output port or flood it within the VLAN.
The switch does not learn B’s address from the destination field of A’s first frame. It learns B when a frame sourced by B arrives. A symmetric flow therefore fills both associations, but only if traffic actually returns. This is why observing a source-learning event is often an early troubleshooting clue when a host transmits but no reply is seen.
The VLAN is part of the forwarding context. The same MAC address can occur in different VLAN tables or under specialized virtualization; ordinary forwarding decisions must not ignore VLAN membership. A Layer 2 switch carrying VLAN 10 and VLAN 20 on the same physical chassis does not automatically route IP between those VLANs.
Distinguish known unicast, unknown unicast, broadcast and multicast
Known unicast: the switch has an entry for the destination MAC in the receiving VLAN, so it forwards toward the matching interface, unless forwarding policy or protection blocks it. Unknown unicast: the switch has not learned the destination in that VLAN, so it usually floods the frame to eligible other forwarding ports in that VLAN. Broadcast: Ethernet ff:ff:ff:ff:ff:ff is flooded through the local broadcast domain. Multicast: forwarding may depend on specialized control features such as snooping, which are beyond the simplest learning model.
Unknown unicast flooding is not the same as ARP. An IPv4 host sends an ARP request as an Ethernet broadcast because it needs a MAC address for a destination on the local link or for its next-hop gateway. Once the host knows that MAC, it transmits a unicast frame. The switch may still flood that unicast if its own CAM entry is absent. Host neighbor resolution and switch forwarding-table learning are related but independent processes.
A troubleshooting example: A can ping B immediately after B sends traffic, but the first packet after a long idle period briefly triggers flooding. Aging of B’s dynamic MAC entry is one plausible cause. That does not justify disabling aging across the switch; MAC mobility, security, topology changes and wireless roaming also affect the design.
Explain how aging and host movement change forwarding state
Dynamic entries expire after an aging interval when no eligible source traffic refreshes them. The exact timer and learning behavior are platform- and feature-dependent. This prevents a switching table from permanently claiming that a host is still on an old port. Static or secured MAC entries follow different management rules; do not apply the dynamic aging model to every entry type.
If a laptop moves from one wall jack to another within the same VLAN, the next sourced frame should update its learned port. If the switch persistently reports the same MAC alternating between two uplinks, look for a loop, bridging mistake, duplicated address, inappropriate VM forwarding configuration or a legitimate multi-homing design. Rapid MAC flapping can be an observable symptom, not a root cause diagnosis by itself.
A port-security feature may limit learned MAC addresses on an access port. When a legitimate desk phone and workstation share a port, a too-low limit can produce a violation even if the switching loop is healthy. Switch port security and Layer 2 controls explain why an error-disabled interface needs a policy investigation, not simply a reboot.
Use the MAC address table with a VLAN-aware method
Cisco IOS-style diagnostic commands often include:
show mac address-table dynamic
show mac address-table address 0011.2233.4455
show vlan brief
show interfaces trunk
Exact command variants differ across software trains and platforms; use local context-sensitive help. First verify the VLAN and expected access/trunk path, then find the MAC entry. A correct MAC-to-port mapping but no Layer 3 reachability suggests looking at ARP, the local gateway, prefix length, access policy or the destination service rather than immediately clearing the table.
If the MAC is unexpectedly learned on a trunk, that may be normal: the host may reside beyond a downstream switch. Follow the path hop by hop. It does not mean the trunk is incorrectly configured. Conversely, a switch that learns nothing from a host may have a wrong VLAN, a blocked port, a device that is not transmitting, or a security restriction.
Keep VLAN membership separate from IP subnetting
A VLAN defines a Layer 2 forwarding and broadcast domain; an IPv4 subnet defines an IP addressing boundary. In a common enterprise design, one subnet corresponds to one VLAN, but the concepts are not identical. A wrong switchport access VLAN can cause a host to fail DHCP or ARP even if the configured subnet mask is mathematically valid.
Consider A in VLAN 10 with 192.0.2.10/24 and B in VLAN 20 with 192.0.2.20/24. Despite sharing the same IP prefix, they are in separate broadcast domains and cannot directly exchange ARP. That addressing model is invalid without another deliberate design; adding a trunk does not merge the VLANs. The right fix is not blindly changing an ACL but aligning Layer 2 membership, IP prefix planning and the routing boundary.
When hosts in different, correctly addressed subnets communicate, their Ethernet destination MAC changes at each routed hop. The L3 switch or router forwards a new link-layer frame with its egress interface’s link-layer addresses. The remote host does not normally appear as a MAC table entry on every intermediate Ethernet switch across the routed path.
Diagnose a missing ARP neighbor without clearing everything
A simple investigation moves from host configuration to switching state. Confirm the host IP, prefix and gateway. Check its neighbor/ARP cache; on Windows arp -a and ipconfig /all provide useful clues. On Linux, ip neigh and ip route help confirm local neighbor and route state. Cisco router commands such as show ip arp can reveal whether the gateway has resolved the host.
Then check the access-port VLAN, link and MAC learning on the switch. If the host’s MAC appears in VLAN 20 but its gateway exists only in VLAN 10, the failure is unlikely to be the remote application. If the host is correctly placed but ARP replies never reach it, examine trunk VLAN carriage, first-hop protections and whether an ARP inspection policy is dropping traffic.
Do not immediately clear the entire MAC table or ARP cache across production devices. That can create broad bursts of unknown unicast flooding and temporary resolution work. Scope the observation and use reversible targeted changes.
Integrate Spanning Tree and EtherChannel correctly
Loops are especially dangerous at Layer 2 because Ethernet frames lack a general TTL field like an IP datagram. An accidental redundant forwarding path can circulate broadcasts and unknown unicasts, saturate links, produce MAC flapping and destabilize learning. Spanning Tree blocks redundant topology paths so the broadcast domain has a loop-free active tree; EtherChannel presents several eligible physical links as one logical bundle.
Spanning Tree changes can also make the physical forwarding path differ from the cable diagram. A blocked/discarding port should not be expected to learn ordinary host source frames on that path. The observed MAC table reflects the active topology at that moment, not necessarily every physical connection that exists.
After a legitimate failover, re-check the expected forwarding path rather than assuming prior MAC locations remain permanent. That is why an explanation of switching without STP context is incomplete, and why Rapid PVST+ roles and guard conditions matters to forwarding behavior.
Create a small, repeatable verification exercise
Build two VLANs with at least two hosts and a routed gateway. First send A-to-B traffic inside VLAN 10 and predict which source addresses the switches learn. Then wait for the dynamic entry to age out and compare flooding behavior. Move a host to a different switchport and check whether the learning location updates. Next introduce a routed destination in VLAN 20 and predict why the remote MAC is not visible on the original VLAN.
For each step, write an expected show mac address-table, show vlan and show ip arp observation before running a command. Keep the diagrams simple enough to see which layer owns each decision. The exercise becomes useful when a real client cannot reach its gateway: the first question is no longer “What command fixes networking?” but “Which device was supposed to learn or forward this frame, and what evidence shows that it did?”
A strong CCNA answer follows the frame from ingress VLAN and source learning through destination lookup, flooding or unicast forwarding, and onward to an IP gateway when routing is required. It treats MAC tables as dynamic observations that depend on topology and traffic—not as a static list of device addresses.