Lab 05 — Ethernet, MAC Addressing and ARP Investigation

Mission Information

Item	Details
Lab	05
Lab Name	Ethernet, MAC Addressing and ARP Investigation
Track	CompTIA Network+
Difficulty	Beginner–Intermediate
Estimated Time	100–130 minutes
Primary Role	Network Technician / Junior Network Administrator
Environment	Network+ Virtual Lab
Primary Systems	NETPLUS-ADMIN, NETPLUS-CLIENT01, NETPLUS-SERVER01
Primary Tools	Wireshark, `arp`, `ip neigh`, `ip link`, `getmac`, `ping`
Skills	Ethernet, MAC Addressing, ARP, Unicast, Broadcast, Multicast, Frame Analysis, Layer 2 Troubleshooting

Mission Objective: Understand how devices communicate on a local Ethernet network by analyzing Layer 2 addressing, Ethernet frames, ARP resolution, neighbor tables, broadcast behavior, and common Layer 2 troubleshooting scenarios.

Mission Scenario

You are working as a Junior Network Technician at GHC Enterprise.

The networking team reports an intermittent connectivity problem on the local network.

Users can sometimes reach:

NETPLUS-SERVER01

but at other times the connection fails.

Initial investigation shows:

IP Addresses Appear Correct
        ↓
Systems Are on the Same Subnet
        ↓
No Router Is Required

The senior network administrator asks you:

“If the IP addresses are correct, how are the systems actually finding each other on the local Ethernet network?”

To answer that question, you will investigate:

Ethernet
   ↓
MAC Addresses
   ↓
ARP
   ↓
Ethernet Frames
   ↓
Local Delivery

You will also simulate a duplicate-IP condition and observe how ARP and MAC mappings help reveal the problem.

Mission Objectives

By completing this lab, you will be able to:

explain Ethernet fundamentals
understand Layer 2 addressing
identify MAC addresses
understand MAC address structure
identify unicast MAC addresses
identify broadcast MAC addresses
understand multicast at a high level
analyze Ethernet II frames
identify source and destination MAC addresses
understand EtherType
explain how ARP works
inspect ARP caches
capture ARP requests and replies
distinguish Layer 2 and Layer 3 addressing
understand local frame delivery
recognize duplicate IP symptoms
identify changing IP-to-MAC mappings
troubleshoot common Ethernet and ARP problems

1. Review the Lab Environment

Use the existing Network+ lab:

NETPLUS-LAB
10.10.10.0/24
      |
      +-----------------------------+
      |              |              |
      |              |              |
10.10.10.10     10.10.10.20    10.10.10.30
ADMIN            CLIENT01        SERVER01

Verify:

NETPLUS-ADMIN:
10.10.10.10/24

NETPLUS-CLIENT01:
10.10.10.20/24

NETPLUS-SERVER01:
10.10.10.30/24

2. Verify Connectivity

From NETPLUS-ADMIN:

ping -c 3 10.10.10.20

Then:

ping -c 3 10.10.10.30

From Windows:

ping 10.10.10.10

Confirm normal communication before beginning the Layer 2 investigation.

3. Understand Ethernet

Ethernet is one of the most widely used technologies for local-area networking.

Conceptually:

Application
    ↓
TCP / UDP
    ↓
IP
    ↓
Ethernet
    ↓
Network Interface

Ethernet operates primarily at:

OSI Layer 2
Data Link

while physical signaling belongs to:

OSI Layer 1
Physical

4. Understand Ethernet Frames

When IP packets move across an Ethernet network, they are carried inside:

Ethernet Frames

A simplified frame looks like:

+----------------------+
| Destination MAC      |
+----------------------+
| Source MAC           |
+----------------------+
| EtherType            |
+----------------------+
| Payload              |
+----------------------+
| FCS                   |
+----------------------+

5. Understand MAC Addresses

A MAC address is typically:

48 bits

or:

6 bytes

Example:

08:00:27:12:34:56

It may also be displayed as:

08-00-27-12-34-56

depending on the operating system.

6. Identify MAC Addresses on Linux

On NETPLUS-ADMIN:

ip link

Look for:

link/ether

Example:

link/ether 08:00:27:12:34:56

Record:

ADMIN MAC:
<value>

7. Identify NETPLUS-SERVER01 MAC

On NETPLUS-SERVER01:

ip link

Record:

SERVER01 MAC:
<value>

8. Identify Windows MAC Address

On NETPLUS-CLIENT01:

getmac

or:

ipconfig /all

Locate:

Physical Address

Record:

CLIENT01 MAC:
<value>

9. Build the MAC Address Table

Create:

System	IPv4	MAC
NETPLUS-ADMIN	10.10.10.10	`<MAC>`
NETPLUS-CLIENT01	10.10.10.20	`<MAC>`
NETPLUS-SERVER01	10.10.10.30	`<MAC>`

This table becomes your Layer 2 baseline.

10. Understand MAC Address Structure

A traditional 48-bit MAC address contains:

First Portion
      ↓
Vendor / OUI-related information

Second Portion
      ↓
Interface-specific identifier

Conceptually:

08:00:27 | 12:34:56

Do not rely on vendor identification alone for security decisions.

Virtualization platforms may assign MAC addresses from their own ranges.

11. Understand Unicast

Unicast means:

One Sender
      ↓
One Destination

Example:

ADMIN
   ↓
SERVER01

Most ordinary Ethernet communication is unicast after the destination MAC is known.

12. Understand Ethernet Broadcast

The Ethernet broadcast MAC address is:

ff:ff:ff:ff:ff:ff

Conceptually:

One Sender
      ↓
Every Device on the Broadcast Domain

ARP requests commonly use Ethernet broadcast.

13. Understand Multicast

Multicast allows traffic to be delivered to:

A Group of Interested Devices

rather than:

One Host

or:

Every Host

IPv6 uses multicast extensively for functions such as Neighbor Discovery.

14. Compare Traffic Types

Type	Delivery
Unicast	One-to-one
Broadcast	One-to-all within broadcast domain
Multicast	One-to-group

15. Start Wireshark

On NETPLUS-ADMIN:

wireshark

Select the interface connected to:

NETPLUS-LAB

Start packet capture.

16. Generate ICMP Traffic

Run:

ping -c 4 10.10.10.30

Apply:

icmp

Select one Echo Request.

17. Inspect the Ethernet II Header

Expand:

Ethernet II

Record:

Destination MAC:

Source MAC:

EtherType:

Then compare with:

Source IP:

Destination IP:

18. Understand Layer 2 vs Layer 3 Addresses

For a local ping:

Ethernet Header

Source MAC:
ADMIN MAC

Destination MAC:
SERVER MAC

while:

IP Header

Source IP:
10.10.10.10

Destination IP:
10.10.10.30

Therefore:

MAC
=
Local Ethernet Delivery

IP
=
Logical Network Addressing

19. Understand EtherType

EtherType identifies what protocol is carried inside an Ethernet frame.

Common examples include:

0x0800
IPv4

0x0806
ARP

0x86DD
IPv6

Find the EtherType in your captured ICMP packet.

20. Analyze an IPv4 Ethernet Frame

For an IPv4 ping packet, you should observe:

Ethernet II
   ↓
EtherType IPv4
   ↓
Internet Protocol Version 4
   ↓
ICMP

This demonstrates encapsulation.

21. Analyze an IPv6 Ethernet Frame

If your IPv6 configuration from Lab 04 remains available, generate:

ping -6 -c 2 2001:db8:10:10::30

Apply:

ipv6

Observe:

EtherType:
IPv6

Compare with the IPv4 frame.

22. Understand Why ARP Is Required

Suppose NETPLUS-ADMIN wants to send traffic to:

10.10.10.30

It knows:

Destination IP

but Ethernet requires:

Destination MAC

Therefore the host must determine:

10.10.10.30
      ↓
Which MAC address?

IPv4 uses:

ARP

23. Review the ARP Cache

On Linux:

ip neigh

or:

arp -n

On Windows:

arp -a

You may already see:

10.10.10.30
      ↓
<SERVER01 MAC>

24. Understand ARP Cache Purpose

Without caching, a host would need to perform ARP resolution before every local packet exchange.

Instead:

ARP Resolution
      ↓
Neighbor Mapping Cached
      ↓
Mapping Reused Temporarily

25. Observe ARP States on Linux

Run:

ip neigh

You may see states such as:

REACHABLE
STALE
DELAY
PROBE
FAILED

These describe neighbor reachability status.

26. Clear an ARP Entry on Linux

Inside the lab, remove the server neighbor entry:

sudo ip neigh del 10.10.10.30 dev <interface>

Verify:

ip neigh

The mapping should no longer appear.

27. Clear ARP Cache on Windows

On Windows, an administrator may use:

arp -d *

or appropriate neighbor-management commands.

Only perform this inside your lab environment.

28. Capture a Fresh ARP Exchange

In Wireshark apply:

arp

Now from NETPLUS-ADMIN:

ping -c 1 10.10.10.30

Observe the packets generated before the ICMP exchange.

29. Analyze the ARP Request

You should see something similar to:

Who has 10.10.10.30?
Tell 10.10.10.10

Inspect the Ethernet header.

Destination MAC:

ff:ff:ff:ff:ff:ff

This means the ARP request is broadcast across the local Ethernet segment.

30. Inspect ARP Request Fields

Record:

Sender MAC:

Sender IP:

Target MAC:

Target IP:

For a request, the target MAC may not yet be known.

The key question is:

Who owns this IPv4 address?

31. Analyze the ARP Reply

The server replies:

10.10.10.30 is at <SERVER MAC>

Unlike the request, the response can normally be sent directly to the requesting host.

Record:

Sender MAC:

Sender IP:

Target MAC:

Target IP:

32. Observe the Complete Communication Sequence

After clearing the neighbor entry and pinging:

Application wants to ping 10.10.10.30
        ↓
Check subnet mask
        ↓
Destination is local
        ↓
Check ARP cache
        ↓
No mapping
        ↓
ARP Broadcast
        ↓
ARP Reply
        ↓
Cache IP-to-MAC mapping
        ↓
ICMP Echo Request in Ethernet frame
        ↓
ICMP Echo Reply

33. Verify the New ARP Entry

Run:

ip neigh

You should now see:

10.10.10.30
      ↓
<SERVER01 MAC>

34. Compare Wireshark and ARP Table

Use Wireshark to identify:

ARP Reply MAC

and compare it with:

ip neigh

The values should match.

35. Investigate CLIENT01 ARP

From NETPLUS-ADMIN:

ping -c 1 10.10.10.20

Then:

ip neigh

Record:

10.10.10.20 → <CLIENT01 MAC>
10.10.10.30 → <SERVER01 MAC>

36. Understand Broadcast Domains

ARP broadcast traffic remains within the:

Broadcast Domain

Routers normally do not forward Ethernet broadcasts between IP networks.

Conceptually:

Subnet A
  ↓
ARP Broadcast

Router
  X

Subnet B

This is one reason subnetting separates broadcast domains when routers or Layer 3 interfaces are used.

37. Understand Same-Subnet Delivery

For:

10.10.10.10/24
      ↓
10.10.10.30/24

the sender determines:

Destination is local

Therefore:

Resolve destination host MAC

38. Understand Remote-Subnet Delivery

Suppose:

ADMIN:
10.10.10.10/24

REMOTE SERVER:
10.10.20.30/24

ADMIN does not normally ARP for:

10.10.20.30

Instead it ARPs for:

Default Gateway

The frame becomes:

Destination MAC:
Router MAC

Destination IP:
10.10.20.30

This distinction is fundamental.

39. Local vs Remote Addressing

Local Destination

Destination IP:
SERVER01

Destination MAC:
SERVER01 MAC

Remote Destination

Destination IP:
Remote Server

Destination MAC:
Default Gateway MAC

IP destination and Ethernet destination do not always identify the same device.

40. Inspect the Broadcast MAC

Apply Wireshark filter:

eth.dst == ff:ff:ff:ff:ff:ff

Observe broadcast frames.

Identify which protocols are generating them.

41. Filter by MAC Address

To view traffic involving a specific MAC:

eth.addr == <MAC>

Example:

eth.addr == 08:00:27:12:34:56

This is useful during Layer 2 troubleshooting.

42. Filter Source MAC

Use:

eth.src == <MAC>

This shows frames transmitted by the selected interface.

43. Filter Destination MAC

Use:

eth.dst == <MAC>

This shows frames addressed to the selected destination.

44. Capture an Ethernet Unicast Frame

Generate:

ping -c 2 10.10.10.30

after ARP resolution already exists.

Apply:

icmp

Observe that the destination Ethernet address is now:

SERVER01 MAC

rather than:

ff:ff:ff:ff:ff:ff

45. Understand Broadcast Then Unicast

The normal pattern is:

ARP Request
=
Broadcast

ARP Reply
=
Usually Unicast

Application Traffic
=
Usually Unicast

This is a useful pattern to remember.

46. Investigate Broadcast Traffic Volume

Let Wireshark capture for several minutes.

Filter:

eth.dst == ff:ff:ff:ff:ff:ff

Observe how often broadcasts occur.

In larger networks, excessive broadcast traffic can affect performance.

47. Understand Broadcast Storms

A broadcast storm occurs when excessive broadcast traffic circulates or is generated at very high volume.

Possible effects include:

High Network Utilization

High CPU Load

Slow Applications

Connectivity Loss

Layer 2 loops are a major possible cause.

You will investigate loop prevention in Lab 08.

48. Understand MAC Learning Conceptually

When an Ethernet switch receives frames, it learns:

Source MAC
      ↓
Incoming Port

Building a table conceptually like:

MAC	Switch Port
ADMIN MAC	Port 1
CLIENT MAC	Port 2
SERVER MAC	Port 3

You will configure and inspect this directly in Lab 06.

49. Understand Unknown Unicast Flooding

If a switch does not know which port contains a destination MAC, it may send the frame out multiple ports within the VLAN.

Conceptually:

Unknown Destination MAC
        ↓
Flood Within VLAN
        ↓
Destination Responds
        ↓
Switch Learns Location

This is different from broadcast traffic, even though multiple ports may receive the frame.

50. Understand ARP and Switch Learning Together

When ADMIN sends an ARP request:

ADMIN Source MAC
      ↓
Switch learns ADMIN location

The server responds:

SERVER Source MAC
      ↓
Switch learns SERVER location

Subsequent communication can then be efficiently forwarded.

51. Troubleshooting Scenario — Incorrect MAC Mapping

Suppose a host believes:

10.10.10.30
      ↓
Wrong MAC

Traffic may be sent to the wrong Ethernet destination.

Clearing the stale mapping and performing new ARP resolution can correct legitimate stale-cache situations.

52. Troubleshooting Scenario — Stale Neighbor Entry

Inspect:

ip neigh

If an entry is:

STALE

this does not automatically mean it is incorrect.

It means the system may need to reconfirm reachability before continued use.

53. Troubleshooting Scenario — Duplicate IPv4 Address

This exercise demonstrates why duplicate addresses cause confusing Layer 2 behavior.

First record:

CLIENT01:
10.10.10.20
<CLIENT MAC>

Temporarily configure NETPLUS-SERVER01 with the same address:

10.10.10.20/24

You now have:

CLIENT01
10.10.10.20
MAC-A

SERVER01
10.10.10.20
MAC-B

Do this only in the isolated lab.

54. Generate Traffic During the Duplicate-IP Scenario

From NETPLUS-ADMIN:

ping 10.10.10.20

Observe the behavior.

Possible symptoms include:

Intermittent Replies

Unexpected MAC Mapping

Duplicate Address Warning

Inconsistent Connectivity

Behavior varies by operating system and timing.

55. Inspect the ARP Mapping

Run repeatedly:

ip neigh show 10.10.10.20

or:

arp -n

Observe which MAC becomes associated with:

10.10.10.20

56. Capture the Duplicate-IP Condition

Apply:

arp

Observe ARP messages involving:

10.10.10.20

You may observe evidence showing different MAC addresses claiming or responding for the same IPv4 address.

57. Why Duplicate IPs Cause Problems

The network expects:

One IP
      ↓
One Current Layer 2 Destination

But now:

10.10.10.20
      ↓
MAC-A

and:

10.10.10.20
      ↓
MAC-B

compete for the same IPv4 identity.

Different hosts may cache different mappings.

58. Restore Unique Addresses

Restore:

NETPLUS-CLIENT01:
10.10.10.20/24

NETPLUS-SERVER01:
10.10.10.30/24

Then clear stale neighbor information where necessary.

From ADMIN:

sudo ip neigh flush dev <interface>

Then:

ping -c 2 10.10.10.20
ping -c 2 10.10.10.30

Verify normal communication.

59. Validate Correct ARP Mappings

Run:

ip neigh

Confirm:

10.10.10.20
→ CLIENT01 MAC

10.10.10.30
→ SERVER01 MAC

60. Troubleshooting Scenario — Disabled Interface

Disable one lab interface temporarily.

From ADMIN:

ping 10.10.10.30

Observe:

No Response

Then check:

ip neigh

You may eventually see neighbor-resolution failures.

61. Understand FAILED Neighbor State

On Linux, a neighbor entry may become:

FAILED

when Layer 2 resolution/reachability cannot be established.

Possible causes include:

Destination Offline

Interface Down

Wrong VLAN

Layer 2 Path Failure

Incorrect Addressing Assumption

62. Troubleshooting Scenario — Wrong Subnet Mask

Suppose ADMIN is configured:

10.10.10.10/24

and SERVER:

10.10.20.30/24

ADMIN determines:

10.10.20.30
=
Remote

Therefore it will not try to resolve the server’s MAC directly.

It expects to use:

Default Gateway

This shows how:

Subnet Mask
      ↓
Controls Layer 2 vs Layer 3 Decision

63. Capture the Local-Remote Decision

Compare traffic generated when pinging:

10.10.10.30

versus a remote address.

For the local destination, look for:

ARP for destination

For a remote destination with a configured router, you would expect:

ARP for gateway

This concept will become practical in routing labs.

64. Understand Gratuitous ARP

A device may send ARP information about its own IPv4 address.

This can be used for functions including:

Duplicate Address Detection

Updating Neighbor Caches

Failover / High Availability

Do not assume every unsolicited ARP message is malicious.

65. Observe Gratuitous ARP if Available

Depending on your operating system, reconnecting an interface or adding an address may generate ARP announcements.

Apply:

arp

Look for ARP traffic where the sender is announcing its own address.

66. Understand ARP Security Risk

ARP has no built-in strong authentication.

A network device can potentially claim:

IP X
=
My MAC Address

This allows attacks such as:

ARP Spoofing

or:

ARP Poisoning

Network+ requires understanding the concept, but this lab does not perform offensive ARP poisoning.

67. Understand ARP Spoofing Conceptually

Concept:

Victim
believes
Gateway IP
      ↓
Attacker MAC

The attacker may then attempt to:

Intercept Traffic

Redirect Traffic

Disrupt Connectivity

Defensive technologies may include:

Dynamic ARP Inspection

DHCP Snooping

Port Security

Network Monitoring

depending on switch capabilities.

68. Build a Layer 2 Troubleshooting Workflow

Use:

Interface Connected?
      ↓
Interface UP?
      ↓
Correct VLAN?
      ↓
Correct MAC?
      ↓
Correct IPv4 Address?
      ↓
Correct Subnet Mask?
      ↓
Destination Local?
      ↓
ARP Request Sent?
      ↓
ARP Reply Received?
      ↓
Correct IP-to-MAC Mapping?
      ↓
Frame Delivery Working?

69. Mission Challenge — Frame Analysis

Capture an ICMP Echo Request from:

NETPLUS-ADMIN

to:

NETPLUS-SERVER01

Document:

Source MAC:

Destination MAC:

EtherType:

Source IPv4:

Destination IPv4:

Protocol:

ICMP Type:

70. Mission Challenge — ARP Analysis

Clear the server ARP/neighbor entry and generate a ping.

Document:

ARP Request

Ethernet Destination MAC:

Sender MAC:

Sender IP:

Target IP:

ARP Reply

Sender MAC:

Sender IP:

Target MAC:

Target IP:

71. Mission Challenge — Explain Local Delivery

Explain how:

10.10.10.10

sends data to:

10.10.10.30

Your answer should include:

Subnet Mask
      ↓
Local Destination Decision
      ↓
ARP Cache
      ↓
ARP Request
      ↓
ARP Reply
      ↓
Destination MAC
      ↓
Ethernet Frame
      ↓
IP Packet

72. Mission Challenge — Explain Remote Delivery

Explain how the process changes when ADMIN sends data to:

10.10.20.30

with a router present.

The expected logic is:

Destination IP is Remote
        ↓
Select Default Gateway
        ↓
Resolve Gateway MAC
        ↓
Frame Destination = Gateway MAC
        ↓
IP Destination = Remote Host

73. Mission Challenge — Duplicate IP Investigation

Document:

Duplicate IP:

MAC Address 1:

MAC Address 2:

Observed Symptoms:

ARP Evidence:

Root Cause:

Corrective Action:

74. Create the Lab Workspace

On NETPLUS-ADMIN:

mkdir -p ~/NetworkPlus-Labs/LAB05/{Captures,Screenshots,Configs,Notes}

Create:

touch ~/NetworkPlus-Labs/LAB05/Notes/lab05-notes.md

75. Save the MAC Baseline

Run:

ip link > ~/NetworkPlus-Labs/LAB05/Configs/admin-mac.txt

Then:

ip neigh > ~/NetworkPlus-Labs/LAB05/Configs/admin-neighbors.txt

Capture equivalent information for the other hosts.

76. Save Packet Captures

Save:

LAB05-ETHERNET-UNICAST.pcapng

LAB05-ARP-RESOLUTION.pcapng

LAB05-BROADCAST.pcapng

LAB05-DUPLICATE-IP.pcapng

under:

~/NetworkPlus-Labs/LAB05/Captures/

77. Document Your Findings

Use:

# LAB05 — Ethernet, MAC Addressing and ARP Investigation

## Environment

### NETPLUS-ADMIN

IP:
MAC:
Interface:

### NETPLUS-CLIENT01

IP:
MAC:
Interface:

### NETPLUS-SERVER01

IP:
MAC:
Interface:

## Ethernet Frame

Source MAC:

Destination MAC:

EtherType:

Payload Protocol:

## ARP Request

Sender MAC:

Sender IP:

Target IP:

Ethernet Destination:

## ARP Reply

Sender MAC:

Sender IP:

Target MAC:

Target IP:

## Neighbor Table

ADMIN → CLIENT:

ADMIN → SERVER:

## Broadcast Analysis

Broadcast MAC:

Observed Protocols:

## Duplicate IP Investigation

Duplicate Address:

MAC 1:

MAC 2:

Symptoms:

ARP Evidence:

Root Cause:

Fix:

## Final Assessment

Summarize how Ethernet and ARP support local IPv4 communication.

78. Evidence to Capture

Capture:

01-admin-mac-address.png

02-client-mac-address.png

03-server-mac-address.png

04-mac-baseline-table.png

05-ethernet-frame.png

06-source-destination-mac.png

07-ethertype-ipv4.png

08-ethertype-ipv6.png

09-arp-cache-before.png

10-arp-request.png

11-arp-broadcast-mac.png

12-arp-reply.png

13-arp-cache-after.png

14-unicast-icmp-frame.png

15-broadcast-filter.png

16-neighbor-table.png

17-duplicate-ip-config.png

18-duplicate-ip-arp.png

19-changing-mac-mapping.png

20-restored-addresses.png

21-final-neighbor-table.png

22-layer2-troubleshooting.png

79. Validation Checklist

Ethernet Fundamentals

Ethernet purpose understood
Ethernet frame structure understood
Source MAC identified
Destination MAC identified
EtherType identified
IPv4 EtherType recognized
IPv6 EtherType recognized
ARP EtherType recognized

MAC Addressing

ADMIN MAC recorded
CLIENT01 MAC recorded
SERVER01 MAC recorded
48-bit MAC structure understood
Unicast understood
Broadcast understood
Multicast understood

ARP

ARP cache reviewed
Neighbor entry cleared safely
ARP Request captured
ARP Reply captured
Broadcast destination identified
Sender IP/MAC identified
Target IP/MAC identified
New ARP mapping validated
ARP cache purpose understood

Local Delivery

Local subnet decision understood
IP-to-MAC resolution understood
Ethernet frame delivery understood
Local and remote delivery differentiated
Gateway MAC concept understood

Troubleshooting

Stale neighbor concept understood
Duplicate IP scenario completed
Multiple MAC claims observed where available
Unique addressing restored
Interface-down scenario understood
FAILED neighbor state understood
Wrong-subnet behavior understood

Security

ARP spoofing concept understood
ARP poisoning concept understood
Lack of ARP authentication understood
Defensive Layer 2 controls recognized

Documentation

MAC baseline completed
ARP mappings documented
Packet captures saved
Duplicate-IP findings documented
Screenshots captured
Lab notes completed

80. Mission Review

In this mission, you moved below Layer 3 and investigated how local Ethernet delivery actually works.

You started with:

Destination IPv4 Address

and followed the process:

Destination IPv4
      ↓
Subnet Decision
      ↓
Local Destination
      ↓
ARP Lookup
      ↓
ARP Broadcast if Unknown
      ↓
ARP Reply
      ↓
Destination MAC Learned
      ↓
Ethernet Frame
      ↓
Local Delivery

You also saw that an Ethernet frame contains both:

Layer 2 Addresses
MAC

and:

Layer 3 Addresses
IP

For local communication:

Destination MAC
=
Destination Host MAC

For remote communication:

Destination MAC
=
Router / Gateway MAC

while the IP destination continues to identify the final remote host.

The key lesson is:

IP addressing decides where traffic needs to go, while Ethernet and MAC addressing determine how that traffic is delivered across the local Layer 2 network. ARP connects these two worlds for IPv4.

Skills Developed

After completing this mission, you should be able to:

explain Ethernet communication
identify Ethernet frame fields
identify MAC addresses
distinguish unicast, broadcast, and multicast
interpret EtherType
explain ARP
inspect ARP and neighbor tables
capture ARP requests and replies
identify Ethernet broadcast traffic
correlate IP addresses with MAC addresses
explain local Ethernet delivery
explain gateway MAC usage for remote traffic
recognize duplicate IPv4 symptoms
investigate changing ARP mappings
understand stale and failed neighbor entries
explain ARP spoofing at a conceptual level
troubleshoot Layer 2 connectivity problems

What’s Next?

Lab 06 — Ethernet Switching Fundamentals

You now understand:

Ethernet Frame
      ↓
Source MAC
      ↓
Destination MAC

The next question is:

How does a switch know which physical or virtual port should receive that frame?

In the next mission, you will investigate:

Ethernet switches
MAC address tables
MAC learning
source MAC learning
frame forwarding
unknown unicast flooding
broadcast forwarding
switch ports
access interfaces
collision domains
broadcast domains
interface status
duplex concepts
speed negotiation
switch troubleshooting
basic switch CLI operations

The progression becomes:

Ethernet Frame
      ↓
Switch Receives Frame
      ↓
Learn Source MAC
      ↓
Check Destination MAC
      ↓
Forward / Flood
      ↓
Correct Switch Port

➡️ Next: Lab 06 — Ethernet Switching Fundamentals