First, the essential ideas
- Frame and MAC address
- A frame is an Ethernet delivery unit. Its source and destination MAC addresses identify local interfaces, not remote IP networks. Read them separately from the IP addresses carried inside.
- Ingress and egress
- Ingress is where a frame enters a switch; egress is where it leaves. A switch learns the source on ingress and looks up the destination to choose eligible egress ports.
- MAC address table
- The switch's table associates a VLAN and a MAC address with a port. Dynamic entries come from received source addresses; static entries are configured and do not use ordinary dynamic aging.
- VLAN
- A virtual LAN is a separate Layer 2 broadcast domain. This experiment uses only VLAN 10. Its number is not an IP subnet mask, and the switch does not infer VLAN membership from an IP address.
- Unicast, broadcast and flooding
- Unicast names one destination; broadcast addresses all stations in the local domain. Flooding copies a frame to eligible forwarding ports in its VLAN except the ingress port; it does not change an unknown unicast into a broadcast.
- Aging and relearning
- Aging removes inactive dynamic records after the configured interval. Relearning recreates a record when a frame arrives from that source; table absence is not proof that a device is disconnected.
- ARP and ping
- ARP resolves an IPv4 neighbor to a local MAC address. Ping sends ICMP echo requests and waits for replies. The endpoint ARP cache and the switch MAC table contain different relationships.
- Console and baseline
- Console is the named device's management window, independent of its data cables in this lab. A baseline records known configuration and actual test results before a deliberate change.
Read an Ethernet frame in two passes: learn where its source was heard, then decide where its destination can be reached. The VLAN is part of both decisions. The small lab turns this rule into inspectable records while keeping the difference between a prediction and actual runtime evidence visible.
See the idea
One lookup, three outcomes
Learn the source first. Then use the destination and VLAN to choose forwarding, flooding or filtering.
Known destination
A VLAN-specific destination record selects its forwarding egress port. Source learning is a separate operation.
What this model leaves out: This is a forwarding decision comparison, not a physical topology or captured traffic. Spanning-tree and policy restrictions still determine eligible ports.
Full visual explanation and references
Three decision records compare known unicast, unknown unicast and a destination on the ingress port. Each outcome is scoped to one VLAN.
This is a forwarding decision comparison, not a physical topology or captured traffic. Spanning-tree and policy restrictions still determine eligible ports.
- Known destination
A VLAN-specific destination record selects its forwarding egress port. Source learning is a separate operation.
www.cisco.com - Unknown destination
No matching unicast record means copies can use eligible ports in the same VLAN, excluding ingress.
www.cisco.com - Same-port destination
If the destination record points back to ingress, filter the frame instead of reflecting it.
www.cisco.com
One idea at a time
Start with something familiar.
Draw two boxes called H1 and H2 with SW1 between them. Label the switch's left port Gi0/0 and right port Gi0/1. Before opening a Console, predict what information a frame from H1 could teach SW1.
Why learn this?
A newly connected device can communicate before every destination has a table entry. Understanding why prevents unnecessary resets and helps you interpret a missing record as evidence to investigate, not an automatic outage.
An everyday comparison
Imagine a receptionist recording which doorway each person used to enter, then using that record to deliver a note to a known person. The arrival creates the location record.
What happens in a network
The arriving person's identity represents the source MAC. Looking up the note's recipient represents the destination lookup. Different office groups represent separate VLAN lookup contexts.
Where the comparison stopsEthernet does not ask people where they live. Flooding sends copies to eligible ports, does not guarantee a reply, and does not provide confidentiality.
Follow one worked example
- Learn from the incoming source.
A frame arriving on Gi0/0 from H1 associates H1's MAC with Gi0/0 in VLAN 10, regardless of whether the destination is already known.
Why: The source tells the switch where traffic from that interface was actually heard.
- Look up the destination in the same VLAN.
If H2's destination MAC is associated with Gi0/1, the frame uses that egress. A record for VLAN 20 would not answer the VLAN 10 lookup.
Why: Local delivery state is scoped; matching only the address while ignoring the VLAN is incomplete.
- Handle absent or stale knowledge.
Unknown unicast can be flooded. After H2 sends a reply, its source creates a useful record. Later inactivity may remove that dynamic record.
Why: Forwarding state changes with traffic and time, so a single table snapshot needs a timestamp and context.
Your first small task
On paper, place H1 on Gi0/0 and H2 on Gi0/1 in VLAN 10. Start with only H1 learned. Predict the egress of a frame from H1 to H2, then the egress of H2's reply after source learning.
Show a hint
Do not learn H2 merely because it appears as the first frame's destination; learning needs an incoming frame from H2.
Check the expected result
The first frame is unknown-unicast flooded to eligible ports other than Gi0/0. The reply can use the known H1 entry on Gi0/0.
Pause and explain it in your own words
If H2's MAC record disappears, must H1's next ping fail?
Show a hint
Consider unknown-unicast handling and the separate endpoint ARP cache.
Show the explanation
No. An unknown destination can be flooded and H2 can reply, allowing relearning. A ping result alone cannot distinguish the initial flooded delivery from later known-unicast delivery.
Short answer
What should you understand today?
A switch learns a frame's source MAC address on the receiving port within its VLAN. It then looks up the destination: a known destination uses the learned egress port, an unknown unicast is flooded within that VLAN, and a destination learned on the ingress port is filtered. Dynamic entries can age out and later be learned again. A MAC table is not an ARP cache.
Before you begin
Learning targets
- Read the earlier Ethernet, IPv4 and IOS CLI lessons.
- Use an existing CML 2.10 entitlement with bundled IOSvL2 and IOSv images.
- Use a fresh isolated three-node lab; no External Connector or production cable.
- Distinguish source learning from destination forwarding.
- Predict known-unicast, unknown-unicast and same-ingress filtering decisions.
- Separate endpoint ARP records from switch MAC records.
- Verify dynamic learning and explain aging without inventing timed observations.
- Clear only a disposable VLAN's dynamic records and retest the same peer.
Words you will meet
Open a word when you need its meaning. You do not need to memorize the whole list before reading.
Frame and MAC address
A frame is an Ethernet delivery unit. Its source and destination MAC addresses identify local interfaces, not remote IP networks. Read them separately from the IP addresses carried inside.
Ingress and egress
Ingress is where a frame enters a switch; egress is where it leaves. A switch learns the source on ingress and looks up the destination to choose eligible egress ports.
MAC address table
The switch's table associates a VLAN and a MAC address with a port. Dynamic entries come from received source addresses; static entries are configured and do not use ordinary dynamic aging.
VLAN
A virtual LAN is a separate Layer 2 broadcast domain. This experiment uses only VLAN 10. Its number is not an IP subnet mask, and the switch does not infer VLAN membership from an IP address.
Unicast, broadcast and flooding
Unicast names one destination; broadcast addresses all stations in the local domain. Flooding copies a frame to eligible forwarding ports in its VLAN except the ingress port; it does not change an unknown unicast into a broadcast.
Aging and relearning
Aging removes inactive dynamic records after the configured interval. Relearning recreates a record when a frame arrives from that source; table absence is not proof that a device is disconnected.
ARP and ping
ARP resolves an IPv4 neighbor to a local MAC address. Ping sends ICMP echo requests and waits for replies. The endpoint ARP cache and the switch MAC table contain different relationships.
Console and baseline
Console is the named device's management window, independent of its data cables in this lab. A baseline records known configuration and actual test results before a deliberate change.
Two fields, two different jobs
Source learning and destination forwarding occur for the same received frame but answer different questions. The source contributes a VLAN, MAC and ingress-port association. The destination selects eligible egress behavior. Do not say that a switch learns where a destination lives merely because another device asks for it. The requesting source is the evidence the switch actually received.
- A source record is evidence of received traffic, not authenticated identity.
- A destination lookup always needs the correct VLAN context.
Known unicast, unknown unicast and filtering
A known unicast destination normally selects its associated forwarding egress. If the associated port is also the ingress, the switch filters the frame instead of sending it back. With no matching unicast record, ordinary flooding uses eligible ports in the same VLAN except ingress. Spanning-tree state and other policies still constrain eligibility; flooding is not literally every socket.
- Unknown unicast keeps its original unicast destination MAC.
- Broadcast and unknown unicast can have similar egress sets but different destination fields.
Do not confuse the two address tables
An endpoint's ARP cache maps a local IPv4 neighbor to a MAC address. SW1's forwarding table maps a VLAN and MAC to a switch port. They are independently maintained. Clearing SW1's dynamic records does not necessarily remove H1's ARP entry, and learning a source MAC does not require the switch to learn that source's IP address.
- Use show arp on the endpoint and show mac address-table on SW1.
- A switch does not need a user-data IP address to forward local Ethernet frames.
Aging is normal maintenance, not a failure alarm
Dynamic entries do not remain useful forever. Inactivity lets a learned record expire; new source traffic refreshes or recreates it. A platform may use a default interval such as 300 seconds, but verify the actual value and implementation rather than treating a memorized number as a measurement. Static records have a different lifecycle.
- Do not shorten production timers to make a classroom observation faster.
- Receiving traffic from a source is distinct from merely sending traffic toward it.
Interpret evidence without widening the claim
A table clear is a controlled loss of learned state, not a simulated broken cable. The correct recovery is new traffic and relearning, not restoring an old dynamic table by hand. Match endpoint MAC values observed on their interfaces with SW1's VLAN and ports; do not expect the illustrative A/B labels to appear in IOS.
- A structural validator cannot demonstrate packet forwarding occurred.
- Compare identical source and destination tests before and after the bounded change.
Real-world walkthrough
The quiet printer is missing from a switch table
In a hypothetical small office, an operator cannot find a printer's MAC in a current table snapshot and proposes rebooting the switch. The printer has been idle, and its physical port is still up. A missing learned record may reflect normal aging. The useful question is what arrives when the printer sends traffic, not whether the table remembers it forever.
- Record the VLAN, port status, table timestamp and printer's actual interface MAC before changing anything.
- Generate an authorized small test to the printer, understanding that a response creates source-learning evidence.
- Compare the endpoint's ARP mapping with the switch's separate VLAN-to-MAC-to-port relationship.
- If the expected source is still absent, inspect port membership and ingress evidence rather than clearing unrelated tables.
- Record the limited result: local delivery was observed or remains unresolved; do not infer printer application health from ping.
Guided GNS3 lab
Learn, clear and relearn one isolated VLAN
Build a known two-endpoint baseline and compare dynamic MAC entries before and after clearing only VLAN 10. Expected results below are predictions. The author did not execute CML or measure packet loss, aging time or throughput.
Addressing plan
| Device | Interface | Address | Purpose |
|---|---|---|---|
| H1 | Gi0/0 | 192.0.2.10/24 | Source endpoint |
| H2 | Gi0/0 | 192.0.2.20/24 | Destination endpoint |
| SW1 | Gi0/0 and Gi0/1 | No IP; access VLAN 10 | Local Ethernet forwarding |
Set up the lab
- Create a fresh CML 2.10 lab using your existing entitlement. Record each exact image build; no external connectors, NAT or bridges are permitted.
- Create the three named nodes and exactly the two mapped cables. Keep the browser Console available independently of those data links.
- Start all nodes. On a fresh IOS node decline the initial configuration dialog, then use enable. An unexpected password or interface mapping is a stop condition.
- Preserve the empty lab and keep a private before/change/after worksheet. Without CML entitlement, use the paper decision exercise and mark runtime unperformed.
Inspect the switch baseline
In CML, select SW1, open its Console tab and connect before typing. At the privileged prompt, verify the image, mapped ports and existing state. Stop if this is not a disposable fresh node.
enable
show version
show interfaces status
show mac address-table dynamic
show mac address-table aging-timeWhat each command means
enable- Enter privileged EXEC on the named lab node; stop if authorization is unavailable.
show version- Record the exact IOSvL2 image and release rather than assuming a hardware model.
show interfaces status- Identify the two connected physical ports and their current VLAN membership.
show mac address-table dynamic- Record current learned entries before the experiment.
show mac address-table aging-time- Read the configured aging interval; do not infer elapsed runtime from it.
- What you should see
- The worksheet identifies SW1, Gi0/0 and Gi0/1 and any pre-existing dynamic records.
- Why this step matters
- A trustworthy comparison requires actual starting facts, not a blank table assumed from the diagram.
Create the local switching domain
In CML, select SW1, open its Console tab and connect before typing. Configure only the two mapped ports. VLAN 10 is a lab broadcast domain; it is not a routing instruction.
configure terminal
vlan 10
exit
interface range GigabitEthernet0/0 - 1
switchport mode access
switchport access vlan 10
no shutdown
end
show vlan briefWhat each command means
configure terminal- Enter global configuration mode from privileged EXEC; changes apply as accepted.
vlan 10- Create the isolated normal-range VLAN used by both endpoints.
exit- Return from VLAN configuration to global configuration.
interface range GigabitEthernet0/0 - 1- Select only SW1's two mapped endpoint-facing ports.
switchport mode access- Fix both ports as access ports rather than negotiated trunks.
switchport access vlan 10- Associate incoming untagged endpoint frames with VLAN 10.
no shutdown- Enable the selected lab interfaces administratively.
end- Return to privileged EXEC without saving or reversing the configuration.
show vlan brief- Confirm both mapped interfaces belong to VLAN 10.
- What you should see
- VLAN 10 exists and Gi0/0 and Gi0/1 are its access members.
- Why this step matters
- Source learning and flooding must be interpreted inside a known VLAN, so membership is established first.
Configure the sending endpoint
In CML, select H1, open its Console tab and connect before typing. Use H1's Console, not SW1's. This IOSv router acts only as a local endpoint; no route or default gateway is needed.
enable
configure terminal
interface GigabitEthernet0/0
ip address 192.0.2.10 255.255.255.0
no shutdown
end
show interfaces GigabitEthernet0/0What each command means
enable- Enter privileged EXEC on the named lab node; stop if authorization is unavailable.
configure terminal- Enter global configuration mode from privileged EXEC; changes apply as accepted.
interface GigabitEthernet0/0- Select the port cabled to SW1 Gi0/0.
ip address 192.0.2.10 255.255.255.0- Assign the source endpoint's distinct /24 documentation address.
no shutdown- Enable H1's only data link.
end- Return to privileged EXEC without saving or reversing the configuration.
show interfaces GigabitEthernet0/0- Record H1's real interface MAC and link state.
- What you should see
- H1 has the .10 address and a recorded interface MAC; the link can settle before testing.
- Why this step matters
- The real MAC connects endpoint observations with the switch table without inventing a hardware address.
Configure the receiving endpoint
In CML, select H2, open its Console tab and connect before typing. Use H2's separate Console and confirm the .20 address. Record its MAC independently; do not reuse H1's value.
enable
configure terminal
interface GigabitEthernet0/0
ip address 192.0.2.20 255.255.255.0
no shutdown
end
show interfaces GigabitEthernet0/0What each command means
enable- Enter privileged EXEC on the named lab node; stop if authorization is unavailable.
configure terminal- Enter global configuration mode from privileged EXEC; changes apply as accepted.
interface GigabitEthernet0/0- Select the port cabled to SW1 Gi0/1.
ip address 192.0.2.20 255.255.255.0- Assign the destination endpoint's distinct /24 address.
no shutdown- Enable the receiving endpoint's link.
end- Return to privileged EXEC without saving or reversing the configuration.
show interfaces GigabitEthernet0/0- Record H2's own interface MAC and operational state.
- What you should see
- H2 has .20/24 and its own MAC on the correct cable.
- Why this step matters
- A correct destination identity avoids mistaking a self-ping or duplicate address for successful peer delivery.
Establish the peer baseline
In CML, select H1, open its Console tab and connect before typing. Allow normal link and spanning-tree convergence. Repeat the small peer test if initial discovery loses a probe; stop if no repeatable baseline appears.
ping 192.0.2.20
show arpWhat each command means
ping 192.0.2.20- Send ICMP echo requests to H2, not H1's own address.
show arp- Inspect the separate IP-to-MAC neighbor mapping on H1.
- What you should see
- Expect replies from H2 after discovery; record actual loss and ARP entries.
- Why this step matters
- Only an established baseline makes the later learned-state clear interpretable.
Read both learned records
In CML, select SW1, open its Console tab and connect before typing. Correlate H1 and H2's recorded interface MACs with VLAN 10 and the two physical ports. Extra control-plane entries must not be mistaken for endpoints.
show mac address-table dynamic vlan 10
show interfaces statusWhat each command means
show mac address-table dynamic vlan 10- Display dynamic entries only in the test VLAN.
show interfaces status- Confirm the mapped links remain connected while reading the table.
- What you should see
- Expect H1's MAC on Gi0/0 and H2's MAC on Gi0/1 after both have sent frames.
- Why this step matters
- The table is evidence of source arrivals; ping and interface state answer different questions.
Clear only the disposable learned state
In CML, select SW1, open its Console tab and connect before typing. This is the bounded fault: remove dynamic records for VLAN 10 only. Do not change aging, VLAN configuration or cables. Background traffic may relearn entries immediately.
clear mac address-table dynamic vlan 10
show mac address-table dynamic vlan 10What each command means
clear mac address-table dynamic vlan 10- Remove only learned dynamic records in the isolated test VLAN.
show mac address-table dynamic vlan 10- Observe what is absent or already relearned immediately afterward.
- What you should see
- Entries may briefly disappear and may return as sources transmit. No outage or perfectly empty snapshot is guaranteed.
- Why this step matters
- A table clear changes knowledge, not cabling. Reporting an expected empty result as observed would conceal real traffic.
Retest the identical destination
In CML, select H1, open its Console tab and connect before typing. Keep all addresses and cables unchanged. This repetition supplies traffic for relearning; a reply does not by itself prove which frame was flooded.
ping 192.0.2.20
show arpWhat each command means
ping 192.0.2.20- Repeat the same H1-to-H2 echo test after the bounded clear.
show arp- Compare H1's neighbor mapping with its pre-clear observation.
- What you should see
- Expect peer replies after any discovery and no required ARP-cache deletion.
- Why this step matters
- Dynamic recovery occurs through new source traffic, not by manually restoring stale MAC entries.
Verify relearning and close
In CML, select SW1, open its Console tab and connect before typing. Compare the current records with the baseline. If the expected source stays absent, retain evidence and investigate rather than repeatedly clearing state.
show mac address-table dynamic vlan 10
show mac address-table aging-time
show vlan briefWhat each command means
show mac address-table dynamic vlan 10- Confirm the endpoint source records have returned on their expected ports.
show mac address-table aging-time- Confirm the timer configuration was not changed by the clear.
show vlan brief- Confirm the experiment did not alter VLAN membership.
- What you should see
- The intended MAC-to-port relationships and unchanged VLAN/timer settings match the baseline.
- Why this step matters
- Rollback here means restoring normal learning through traffic; no persistent configuration fault was introduced.
Verify
- Record exact images, endpoint MACs, cable ports and VLAN membership.
- Require repeatable H1-to-H2 replies before clearing any learned state.
- Compare H1 ARP and SW1 MAC records as different data structures.
- After the clear, retain actual observations including immediately relearned entries.
- Retest the same destination and confirm both expected MAC-to-port records return.
Troubleshoot
- If a command is rejected, stop at that node and record the prompt, full syntax and software build. Check matching platform support instead of substituting a built-in GNS3 switch CLI.
- If a source is missing, generate bounded traffic from that endpoint and inspect the correct VLAN. A quiet endpoint may legitimately age out; a visible destination in another frame is not source evidence.
- If the baseline fails, check link state, address uniqueness, /24 masks and VLAN membership before any clear. Wait for normal spanning-tree convergence.
- If records appear on the wrong port, compare the actual cable map and endpoint MACs. Do not force the table to fit the drawing with static entries.
Use an existing Cisco Modeling Labs 2.10 entitlement and its bundled reference images inside CML only. GNS3 does not provide Cisco images; use images there only when a separate applicable license permits that environment. Do not share or redistribute image files. A CML subscription alone does not authorize exporting its Cisco images to GNS3. Without entitlement, use the explicitly labeled paper exercises; they do not establish hands-on competence.
- Leave VLAN membership and aging configuration unchanged from the verified baseline; the table clear needs no configuration inverse.
- Retain private observations, then stop the isolated CML nodes. Do not export or redistribute bundled Cisco images.
Practice set
Answer before you reveal
01Which field teaches SW1 a location?
A destination identifies where a frame wants to go; it does not prove where that destination was heard.
02Does flooding rewrite an unknown unicast as broadcast?
Flooding describes the switch's replication behavior, while unicast or broadcast describes the destination address.
03Why does a VLAN 20 record not answer a VLAN 10 lookup?
The same MAC value can have separate associations in different VLANs; ignoring scope can predict the wrong egress.
04What happens to a known destination on ingress?
This avoids unnecessary reflection when the destination is already on the same segment as the sender.
05Can an idle live endpoint lack a dynamic record?
Link presence, recent source traffic and dynamic table membership are related observations but not equivalent facts.
06What repairs the deliberate table clear?
The exercise changed no persistent VLAN or interface configuration, so a reload or old table import is inappropriate.
Knowledge check
Quiz: prove the reasoning
Keep these
Technical takeaways
- Learn the source, then look up the destination within the correct VLAN.
- Unknown unicast flooding does not rewrite the destination as broadcast.
- A destination learned on ingress is filtered rather than reflected.
- MAC tables and ARP caches answer different operational questions.
- Aging and relearning are normal dynamic behavior, not automatic evidence of failure.
- A ping is a limited traffic test, not a capture of every forwarding decision.