Ethernet is one of those technologies that becomes less interesting the more casually you describe it. “Ethernet is a wired networking standard.” Technically true. Practically useless. It does not explain why a computer needs a MAC address, how a switch knows where another computer is connected, why a router changes Ethernet headers at every hop, why ARP exists, what the difference is between an Ethernet frame and an IP packet, why a 1,500-byte MTU produces a 1,460-byte TCP MSS, why VLAN tags appear in the middle of an Ethernet frame, why a switch can forward millions of frames without understanding TCP, why old Ethernet cared about collisions, why modern full-duplex Ethernet does not, why Wireshark sometimes reports perfectly healthy packets as having bad checksums, or why a packet capture is not necessarily a recording of everything that physically crossed the cable.

To understand Ethernet properly, it is better to follow an actual piece of data.

Imagine a program running on one computer sends:

Hello from Bob

to a TCP server on another machine.

The application thinks it is sending a string. The operating system turns those bytes into transport-layer data. TCP puts them into a byte stream. IP gives the communication a network-layer destination. Ethernet determines which interface should receive the frame on the current local link. The network interface converts the resulting data into the physical signaling used by the Ethernet medium.

A switch may receive the frame, inspect its Ethernet addresses, consult its forwarding table, and send the frame out another port. The receiving machine reverses the process. Ethernet removes its framing. IP processes the packet. TCP reconstructs the stream. The application receives the original bytes. Nothing about this is magic. It is a chain of carefully separated responsibilities. That is the key to understanding Ethernet.

What is Ethernet

Ethernet is the family of wired LAN technologies standardized primarily through IEEE 802.3. It is not a single speed, cable or physical medium. Ethernet has existed across many generations, from early shared coaxial networks to twisted-pair Fast Ethernet and Gigabit Ethernet, through 10 Gigabit, 25 Gigabit, 40 Gigabit, 100 Gigabit and much faster data-center implementations.

Different Ethernet variants can use different physical media, signaling techniques, wavelengths, encoding schemes, lane configurations and speeds while retaining common Ethernet concepts at the data-link layer.

That is why “Ethernet” does not mean “the blue cable plugged into a laptop.” The cable is only one possible physical medium. The Ethernet system encompasses the rules governing frames, MAC addressing and link operation, while the physical layer determines how those bits and symbols are actually transmitted.

The IEEE 802.3 working group continues to maintain and extend the Ethernet standards family.

A useful mental model is therefore:

Application
    ↓
TCP / UDP
    ↓
IPv4 / IPv6
    ↓
Ethernet
    ↓
Physical medium

But even that diagram hides a lot.

Ethernet itself has to solve several different problems:

• How is a device identified on the local network?
• How is a frame formatted?
• How does the receiver know where the frame begins?
• How does the sender identify the intended local recipient?
• How does a switch determine where that recipient is located?
• How are transmission errors detected?
• How are different protocols identified inside the frame?
• How can multiple logical networks share the same physical infrastructure?
• How are Layer 2 loops prevented?
• How does a physical link determine its speed and duplex mode?
• How does the NIC interact with the operating system?
• What happens when frames become too large?
• How do multicast and broadcast traffic work?
• What happens when the destination is not on the local network?

Those are the questions that make Ethernet worth learning.

The Most Important Idea: A Message Becomes Several Different Things

Suppose an application writes:

Hello from Bob

The application does not directly create an Ethernet frame. Instead, the data moves through layers.

A simplified TCP/IP view looks like this:

Application data
        │
        ▼
TCP segment
        │
        ▼
IP packet
        │
        ▼
Ethernet frame
        │
        ▼
Physical transmission

The application has data. TCP carries that data in a TCP segment. IP carries the TCP segment inside an IP packet. Ethernet carries the IP packet inside an Ethernet frame. People routinely call all of these “packets,” and in casual conversation that is understandable. But when troubleshooting networking, this becomes important.

A TCP retransmission problem is not an Ethernet framing problem. An ARP failure is not a TCP problem. A bad Ethernet FCS is not the same thing as a TCP checksum failure. A switch forwarding problem is not an IP routing problem. The layers interact, but they solve different problems.

Layer 1: Before There Is Even an Ethernet Frame

Before discussing MAC addresses, it is worth going one level lower. A computer ultimately has to transmit something physical.

Copper does not understand:

01001000 01100101 ...

in the abstract.

The Ethernet physical layer defines how information is represented as electrical, optical or other physical signals. The details vary considerably between Ethernet implementations.

A 1000BASE-T copper connection and a 10GBASE-SR fiber connection are both Ethernet, but their physical transmission mechanisms are very different. This is why Ethernet is better understood as a family of technologies than as one particular cable standard.

Ethernet PHYs

The physical-layer component is commonly called the PHY.

The PHY sits between the MAC-side logic and the actual physical medium.

A simplified NIC architecture looks something like:

Operating system
       │
       ▼
Network driver
       │
       ▼
NIC / MAC
       │
       ▼
PHY
       │
       ▼
Cable / fiber

The MAC handles Ethernet framing and addressing functions. The PHY handles the physical signaling. The exact architecture differs across implementations, but the separation is useful when troubleshooting.

If a switch reports a physical link as down, the problem may have nothing to do with IP configuration. There might not even be an Ethernet frame yet. The PHY has to establish a usable link first.

Link Negotiation: How Two Ethernet Devices Agree to Communicate

When you plug an Ethernet cable into a switch, the devices do not simply assume that they should communicate at some arbitrary speed. Depending on the Ethernet technology and configuration, the endpoints use mechanisms such as auto-negotiation to exchange capabilities and determine compatible operating parameters.

Auto-negotiation can communicate capabilities such as supported speeds and duplex modes. For example, an interface may support:

10 Mb/s
100 Mb/s
1 Gb/s

while the switch supports:

10 Mb/s
100 Mb/s
1 Gb/s
2.5 Gb/s
5 Gb/s
10 Gb/s

The actual result depends on the capabilities and configuration of both sides.

Cisco’s documentation describes auto-negotiation as a mechanism through which link partners exchange information about speed and duplex capabilities.

This is also why an Ethernet interface can report:

1000 Mb/s
Full duplex

rather than merely “Ethernet connected.”

The link has established operating parameters. A physical link being “up” does not automatically mean that IP connectivity is working. You can have:

Physical link: UP
Ethernet:      UP
IP address:    WRONG
Routing:       WRONG
Application:   DOWN

This information is important when troubleshooting.

Speed and Bandwidth Are Not the Same Thing as Latency

A 10 Gbit/s Ethernet link can transmit data at a much higher rate than a 1 Gbit/s link. That does not mean the 10 Gbit/s link automatically has one-tenth the latency.

Bandwidth describes how much data can be transferred over time. Latency describes how long it takes something to travel through the system.

Serialization delay is one component of latency. For example, putting a 1,500-byte frame onto a 1 Gbit/s link takes approximately:

1500 × 8 / 1,000,000,000

which is 12 microseconds, ignoring the additional physical and inter-frame timing details.

At 10 Gbit/s, serialization takes roughly one-tenth as long. But propagation through fiber, copper, transceivers, switches, routers and queues contributes separately.

MAC Addresses: The Identity Used by Ethernet

Now we reach the most recognizable Ethernet concept i.e. the MAC address.

A conventional Ethernet MAC address is 48 bits. It is usually written as six hexadecimal octets:

00:11:22:33:44:55

The first portion is historically associated with an organizational identifier, commonly referred to as an OUI, while the remaining bits distinguish the address within that allocation. But there is an important correction to a common beginner explanation.

A MAC address is not an absolutely permanent, globally guaranteed identity of a physical computer.

Modern operating systems can use locally administered addresses, virtualization creates virtual interfaces, containers can have their own interfaces, and software can change an interface’s configured MAC address. The address is primarily a Layer 2 identifier used in the context of the local link.

Ethernet also defines special address semantics. The low-order bit of the first octet indicates whether an address is an individual/unicast address or a group address. Another bit indicates whether the address is globally administered or locally administered. So the MAC address contains more information than simply “this is the manufacturer’s serial number.”

Wireshark exposes these fields directly in its Ethernet dissector, including the individual/group and locally administered bits.

Unicast, Multicast and Broadcast MAC Addresses

Ethernet traffic is not always one sender talking to one receiver. There are three important delivery categories.

Unicast

One sender to one intended receiver.

Example:

Laptop → Server

The destination MAC identifies one interface.

Broadcast

One sender to all devices in the relevant Layer 2 broadcast domain. The classic Ethernet broadcast address is:

ff:ff:ff:ff:ff:ff

ARP requests for IPv4 commonly use this mechanism.

Multicast

One sender to multiple interested receivers. Multicast is not the same as broadcast. A broadcast is delivered broadly to all hosts within the relevant broadcast domain.

Multicast allows receivers to join specific groups and lets network infrastructure make more selective forwarding decisions, depending on the protocols and configuration in use.

IPv6 makes extensive use of multicast and does not use broadcast in the IPv4 sense.

The Ethernet Frame

A conventional Ethernet frame can be represented as:

+------------------------+
| Destination MAC        | 6 bytes
+------------------------+
| Source MAC             | 6 bytes
+------------------------+
| EtherType / Length     | 2 bytes
+------------------------+
| Payload                | 46-1500 bytes*
+------------------------+
| FCS                    | 4 bytes
+------------------------+

There are details and variants, but this is the frame structure most people encounter when inspecting ordinary Ethernet II traffic.

Wireshark documents the physical Ethernet packet as including an 8-byte preamble/SFD portion, followed by destination and source addresses, a Type/Length field, data and FCS. It also notes that the preamble is normally removed by Ethernet hardware before the capture software sees the packet, and that many interfaces do not provide the FCS to applications.

The basic Ethernet header is:

6 + 6 + 2 = 14 bytes

That does not mean a packet capture necessarily contains exactly 14 bytes of Ethernet overhead. VLAN tagging can add additional fields. Other encapsulations can add additional headers. The physical transmission also includes information that ordinary packet captures frequently do not expose.

EtherType: How Ethernet Knows What Is Inside

The two-byte field following the source MAC is commonly interpreted as an EtherType in Ethernet II framing. Some important values are:

0x0800  IPv4
0x0806  ARP
0x86DD  IPv6

If the frame contains:

EtherType = 0x0800

the receiving stack knows that the payload should be interpreted as IPv4. If it contains:

EtherType = 0x0806

the payload is ARP. If it contains:

EtherType = 0x86DD

the payload is IPv6.

This is how Ethernet can carry multiple network-layer protocols without having to understand each protocol’s internal structure.

Ethernet II Versus IEEE 802.3

This is one of the areas that introductory articles often gloss over. “Ethernet frame” does not necessarily mean there is always an EtherType field in exactly the same conceptual sense. Ethernet II uses the two-byte field as an EtherType.

IEEE 802.3 historically uses the corresponding field as a length value when the numeric value falls within the length range. The payload may then contain an IEEE 802.2 LLC header, and certain protocol identification schemes such as SNAP can be used. This is why packet analyzers sometimes show:

Ethernet II

and sometimes:

IEEE 802.3
LLC
SNAP

These are not random Wireshark classifications. They reflect different Ethernet framing conventions. For modern IP networking, Ethernet II is overwhelmingly what you are likely to encounter. Still, understanding the differences are important when analyzing older protocols, specialized environments or unusual captures.

The Preamble and Start Frame Delimiter

The frame that Wireshark displays is not the complete physical event. Before the destination MAC address appears, the transmitter sends the Ethernet preamble.

A conventional Ethernet transmission has:

7-byte preamble
1-byte Start Frame Delimiter

The preamble provides a known pattern that helps the receiver synchronize with the incoming signal. The Start Frame Delimiter marks the transition from synchronization information to the actual frame. Only after this does the destination MAC address begin. The receiver needs timing information before it can interpret the incoming data as frame fields.

This is a useful reminder that networking is not merely a sequence of bytes sitting on a cable. The receiver has to determine where the bits are and how to sample them.

The Frame Check Sequence

At the end of the conventional Ethernet frame is the Frame Check Sequence, or FCS. It is four bytes and is based on a CRC. The sender calculates the CRC over the appropriate portion of the frame and transmits the resulting FCS.

The receiver performs the corresponding verification. If the check fails, the frame is considered corrupted. Ethernet’s error detection is therefore fundamentally different from TCP’s reliability mechanism.

Ethernet says:

This frame appears corrupted.

TCP says:

I need these bytes in this sequence, and I have not received them correctly.

Wireshark’s documentation notes that Ethernet hardware can calculate the CRC during transmission and validate it during reception. A bad received FCS can result in the hardware discarding the frame before Wireshark ever sees it.

This is one reason Ethernet captures do not necessarily show every corrupted frame that physically appeared on the medium. A frame discarded by the NIC may never become a packet-capture record.

Ethernet Padding and the 64-Byte Minimum

Traditional Ethernet has a minimum frame size of 64 bytes, measured from the destination MAC through the FCS. If the payload is too small, padding is inserted.

This produces the familiar:

Destination
Source
Type
Payload + Padding
FCS

The application does not see that padding.

Why does Ethernet care about a minimum frame size? The answer comes from Ethernet’s history. Early Ethernet was a shared medium. Several devices could transmit on the same physical network. That created collisions.

A sender had to remain transmitting long enough to detect a collision occurring at the far end of the network and propagating back. The minimum frame size and maximum network diameter were therefore historically related.

CSMA/CD and Why Modern Ethernet Doesn’t Behave Like Old Ethernet

Classic Ethernet used:

Carrier Sense Multiple Access with Collision Detection, or CSMA/CD.

The basic idea was:

1. Listen to the medium.
2. If it appears idle, transmit.
3. Continue monitoring while transmitting.
4. If a collision is detected, stop.
5. Send the appropriate collision indication.
6. Wait for a randomized backoff period.
7. Try again.

The backoff was important. If two devices collided and both waited exactly the same fixed amount of time, they could collide again.

Ethernet therefore used binary exponential backoff to progressively increase the range from which retransmission delays were selected after repeated collisions. This is one of the places where the history of Ethernet explains a frame-format rule that otherwise seems arbitrary.

But you should not carry this model into modern switched full-duplex Ethernet as though devices are still fighting over one shared wire. They generally are not.

Hubs Versus Switches

A hub and a switch are not interchangeable concepts. A hub operates as a multiport repeater. If it receives a signal on one port, it repeats that signal to other ports. All devices attached to the hub therefore share the same collision domain.

A switch is fundamentally different. A switch receives frames and makes forwarding decisions. It learns source MAC addresses.

Suppose:

Host A MAC = aa:aa:aa:aa:aa:aa

sends a frame into:

Port 4

The switch can learn:

aa:aa:aa:aa:aa:aa → Port 4

If it later receives a frame destined for that MAC, it can forward it toward Port 4.

The switch does not need to know that the MAC belongs to a Linux server running SSH. It does not need to understand TCP. It does not need to understand the application. It can forward the frame using Layer 2 information alone.

How a Switch Learns

A typical switch learns from the source MAC address of incoming frames.

Suppose Host A sends:

Source MAC:      A
Destination MAC: B

The switch receives the frame on Port 1.

It learns:

A → Port 1

It then checks whether it already knows where B is.

If it knows:

B → Port 8

it can forward the frame only to Port 8. If it does not know where B is, the switch can flood the frame out the appropriate ports.

When B eventually sends traffic back, the switch learns:

B → Port 8

The forwarding table therefore becomes a continuously updated map. It is not a permanent database. Entries can age out. Hosts can move. Virtual machines can migrate. Links can fail. MAC addresses can appear on different ports. Switches have to adapt.

Why a Switch Does Not Normally Send Your Neighbor’s Traffic to You

This explains a common Wireshark misconception.

Suppose three computers are connected to a switch:

A ─┐
B ─┼── Switch
C ─┘

A is communicating directly with B. C is running Wireshark. C normally does not see A’s unicast conversation. Why? Because the switch knows that B is reachable through B’s port and forwards the frame there. The switch has no reason to send the frame to C. Putting C’s network interface into promiscuous mode does not change this. Promiscuous mode tells C’s NIC to accept frames that reach C’s interface even if the destination MAC is not C’s own address. It does not cause the switch to copy unrelated traffic to C.

For that, you need something such as:

SPAN / port mirroring
Network TAP
Inline capture architecture

This detail is important in network security. A modern switched Ethernet network is not a shared medium in the way old hub-based networks were.

Broadcast Domains and Collision Domains

These terms are often mixed together.

A collision domain describes the portion of a network in which simultaneous transmissions could collide under the applicable Ethernet operating mode.

A broadcast domain is the set of Layer 2 interfaces that receive a given Layer 2 broadcast.

Modern switched full-duplex links largely eliminate ordinary Ethernet collisions on individual links. Broadcast domains, however, remain very relevant.

For example:

Host A
Host B
Host C

may all belong to one VLAN and therefore one Layer 2 broadcast domain. A router or Layer 3 boundary can separate that broadcast domain. VLANs can also divide a physical switch infrastructure into multiple logical broadcast domains.

VLANs: Multiple Logical Networks on the Same Ethernet Infrastructure

VLANs are one of the most important extensions to Ethernet. Suppose one physical switch has 48 ports. You could place all 48 ports into one Layer 2 network.

But you might instead want:

VLAN 10 → Employees
VLAN 20 → Servers
VLAN 30 → Guest devices
VLAN 40 → VoIP

The same physical switch infrastructure can then carry multiple logical Layer 2 networks. IEEE 802.1Q defines the standard framework for VLANs and bridged networks.

The key idea is that a VLAN creates a separate Layer 2 forwarding domain. A broadcast in VLAN 10 should not simply appear in VLAN 20. A host in VLAN 10 cannot directly communicate at Layer 2 with a host in VLAN 20 merely because both are plugged into the same physical switch.

Communication between VLANs normally requires Layer 3 routing.

What a VLAN Tag Does to the Ethernet Frame

An 802.1Q VLAN tag adds four bytes to the Ethernet frame.

Conceptually:

Destination MAC
Source MAC
802.1Q Tag
EtherType
Payload
FCS

The tag contains information including:

TPID
Priority / PCP
DEI
VLAN ID

The VLAN ID is the value that identifies the VLAN. The tag is inserted between the source MAC address and the original EtherType. This is why a VLAN-tagged frame is larger than an ordinary untagged Ethernet frame. It also means that an MTU discussion becomes more important.

A conventional 1500-byte IP MTU can coexist with a frame carrying an additional VLAN header because the VLAN tag is part of the Layer 2 overhead rather than part of the IP payload.

Access Ports and Trunk Ports

A common enterprise switch configuration uses two conceptual port types.

An access port is normally associated with one VLAN for an endpoint.

For example:

Laptop
   │
Access Port
   │
VLAN 20

The endpoint generally sends ordinary untagged Ethernet frames. The switch internally associates the traffic with the configured VLAN. A trunk is designed to carry traffic belonging to multiple VLANs across one link.

For example:

Switch A
   │
   │ VLAN 10
   │ VLAN 20
   │ VLAN 30
   │
Switch B

The Ethernet frames are typically VLAN-tagged on the trunk so the receiving switch can distinguish the logical networks.

This is how a VLAN can span multiple physical switches without requiring one physical link per VLAN.

VLANs Do Not Automatically Provide Security

A VLAN creates a Layer 2 separation. That does not mean it automatically provides complete security isolation.

A properly configured VLAN architecture can provide meaningful network segmentation, but misconfigured trunks, access controls, routing policies, native VLAN behavior, switch configuration and other infrastructure can undermine the intended isolation.

There are also attacks against Layer 2 protocols and infrastructure, including MAC-table exhaustion, ARP spoofing, VLAN misconfiguration and rogue network services.

Ethernet itself was designed primarily to provide local networking, not modern zero-trust security. Security controls are layered on top.

Spanning Tree: Why Layer 2 Loops Are Dangerous

Layer 2 networks have a serious problem.

Suppose two switches are connected by two physical links:

Switch A
  │    │
  │    │
Switch B

The redundancy is useful. If one link fails, the other can continue carrying traffic. But if both are forwarding simultaneously, a Layer 2 loop exists.

Ethernet frames do not contain a general-purpose TTL equivalent that automatically kills them after a certain number of switches. A broadcast can therefore circulate. Unknown-unicast flooding can circulate. MAC addresses can appear to move rapidly between ports. The network can become unstable. This is where Spanning Tree Protocol enters the picture.

STP creates a loop-free logical topology while allowing redundant physical paths to exist. Cisco’s current STP documentation describes its purpose directly: provide Layer 2 redundancy while preventing loops, selecting a logical tree and placing redundant paths into non-forwarding states when necessary.

A simplified topology might be:

        Switch A
        /      \
       /        \
Switch B ------ Switch C

Physically there is a triangle.

Logically, STP may block one path:

        Switch A
        /      \
       /        \
Switch B      Switch C
        X
        |
     blocked

If an active path fails, the topology can reconverge and use the redundant connection.

Modern networks often use variants and successors such as Rapid Spanning Tree and Multiple Spanning Tree, but the core idea remains the same: prevent forwarding loops while retaining redundancy.

ARP in More Detail

ARP deserves more attention because it sits at the boundary between IP and Ethernet.

Suppose:

Host:
192.168.1.100
Gateway:
192.168.1.1

The host wants to send an IPv4 packet outside the subnet. It determines that the destination is not directly reachable at Layer 2.

The route says:

next hop = 192.168.1.1

But Ethernet needs:

MAC = ?

ARP resolves that. The request is broadcast. The gateway responds. The operating system caches the result. Then the Ethernet frame can be created.

Conceptually:

Destination IP:
8.8.8.8
Next-hop IP:
192.168.1.1
Next-hop MAC:
aa:bb:cc:dd:ee:ff

The Ethernet frame therefore looks approximately like:

Ethernet destination = aa:bb:cc:dd:ee:ff
IP destination       = 8.8.8.8

The two addresses are supposed to be different. They represent different layers.

ARP is defined in RFC 826. The source material also describes this relationship between the ARP cache and the local Ethernet destination.

ARP Spoofing

The same mechanism that makes ARP useful creates a security problem. ARP does not provide cryptographic authentication of the mapping.

A malicious host can potentially send forged ARP messages claiming:

192.168.1.1 is at
attacker-mac

A victim may update its ARP cache accordingly. Traffic intended for the legitimate gateway can then be sent toward the attacker. This is the foundation of ARP spoofing and many man-in-the-middle attacks on IPv4 LANs.

Defensive mechanisms include switch-level inspection and filtering technologies such as Dynamic ARP Inspection, appropriate DHCP snooping architectures, static mappings in special environments, segmentation and cryptographic protection at higher layers.

HTTPS and other encrypted protocols can prevent the attacker from simply reading or modifying protected application data even if the attacker succeeds in intercepting the traffic.

IPv6 Changes the Local Discovery Model

IPv6 does not use ARP. Instead, IPv6 uses Neighbor Discovery, implemented using ICMPv6. RFC 8200 defines IPv6 and explicitly describes the link concept and IPv6 operation over Ethernet and other link technologies.

IPv6 Neighbor Discovery provides mechanisms for functions that include:

• Neighbor address resolution
• Router discovery
• Prefix discovery
• Duplicate Address Detection
• Neighbor reachability information

Instead of an IPv4-style ARP broadcast asking:

Who has 192.168.1.1?

IPv6 uses ICMPv6 Neighbor Solicitation and related multicast-based mechanisms.

This is one reason IPv6 packet captures can look quite different from IPv4 captures during local network discovery.

IPv4 and IPv6 Inside Ethernet

Ethernet does not need separate frame formats for IPv4 and IPv6. The EtherType tells the receiver what is inside.

For IPv4:

EtherType = 0x0800

For IPv6:

EtherType = 0x86DD

The Ethernet layer can therefore carry both simultaneously.

Conceptually:

Ethernet
 ├── IPv4
 │    └── TCP
 │         └── Application
 │
 └── IPv6
      └── TCP
           └── Application

IPv6 uses 128-bit addresses rather than IPv4’s 32-bit addresses and has a different base-header structure. RFC 8200 specifies IPv6’s header format, extension headers, packet-size rules and related behavior.

The IP Packet Is Still Not the Ethernet Frame

This information becomes particularly important at routers.

Imagine:

PC
 |
Switch
 |
Router
 |
Internet

The PC sends:

Ethernet frame
    ↓
IPv4 packet
    ↓
TCP segment

The router receives the Ethernet frame. It does not simply forward that exact Ethernet frame onto the next Ethernet network. Instead, it processes the IP packet and constructs a new Layer 2 frame for the outgoing interface.

Conceptually:

Incoming:
MAC A → MAC Router
IP A  → IP Server
Outgoing:
MAC Router → MAC Next Hop
IP A       → IP Server

The Ethernet addresses change. The IP addresses generally remain the same from end to end, aside from mechanisms such as NAT or other transformations.

This is the fundamental difference between Layer 2 forwarding and Layer 3 routing.

TTL and Hop Limit

There is another reason IP survives multiple hops while Ethernet does not.

IPv4 has a Time To Live field. Routers decrement it as the packet is forwarded. If it reaches zero, the packet is discarded.

IPv6 uses a field called Hop Limit instead. RFC 8200 explicitly describes the IPv6 Hop Limit as the successor to IPv4’s TTL concept.

Ethernet does not provide the equivalent end-to-end mechanism. An Ethernet frame belongs to a local link. An IP packet belongs to a routed path.

MTU: One of the Most Misunderstood Ethernet Concepts

MTU stands for Maximum Transmission Unit.

In a typical Ethernet/IP network, the commonly encountered IP MTU is:

1500 bytes

But “Ethernet MTU = 1500” is a shorthand that can create confusion.

The MTU generally describes the maximum size of the IP packet that can be carried over the interface without fragmentation at that layer.

The Ethernet frame itself contains additional overhead.

For an untagged Ethernet II frame carrying a 1500-byte IP packet:

14-byte Ethernet header
1500-byte IP packet
4-byte FCS

Ignoring physical preamble and inter-frame timing, that produces:

1518 bytes

of frame material from the Ethernet header through FCS.

A VLAN tag adds four bytes:

1522 bytes

for the same 1500-byte IP payload.

This is why you will often see:

1518-byte Ethernet frame
1522-byte VLAN-tagged frame

in switch documentation.

MSS: Why TCP Often Uses 1460 Bytes

For IPv4:

Ethernet MTU = 1500
IPv4 header = 20
TCP header = 20

Therefore:

1500 - 20 - 20 = 1460

So a common TCP MSS is:

1460 bytes

MSS means Maximum Segment Size. It represents the maximum TCP payload that an endpoint advertises it can receive in one TCP segment. TCP uses this to avoid producing segments that are too large for the known path. The exact value can change when headers contain options or when the path has a different MTU.

TCP itself also has a number of mechanisms designed around path MTU behavior. RFC 9293 discusses TCP segmentation and the interaction between TCP and the underlying IP layer.

TCP Segmentation Is Not IP Fragmentation

Suppose the application wants to send:

10,000 bytes

TCP can split the byte stream into multiple segments.

For example:

Segment 1: 1460 bytes
Segment 2: 1460 bytes
Segment 3: 1460 bytes
...

Each segment becomes its own IP packet. Each IP packet becomes its own Ethernet frame. This is normal TCP segmentation. IP fragmentation is something else.

If an IPv4 packet is too large for a downstream link and fragmentation is permitted, IPv4 can split the IP datagram into fragments.

IPv6 takes a different approach: routers do not fragment packets in transit. Fragmentation, when used, is performed by the source using the IPv6 Fragment header. RFC 8200 specifies this behavior.

Jumbo Frames

Standard Ethernet deployments commonly use a 1500-byte IP MTU. Some environments configure larger frames, commonly called jumbo frames.

A frequently encountered configuration is:

MTU 9000

Jumbo frames can reduce per-packet overhead for large transfers because fewer packets are required to transport the same amount of data.

But there is a catch. MTU configuration has to be consistent across the relevant path.

If one device supports:

9000

and another part of the path only supports:

1500

the larger packet cannot simply travel through the smaller-MTU link unchanged.

This is why jumbo frames are particularly common in controlled environments such as storage networks and data centers, where administrators can manage the complete path.

They are much less common as a universal Internet setting.

Frame Size, MTU and Offloads Can Make Packet Captures Look Strange

Modern NICs complicate packet analysis. An operating system may give a NIC a large buffer containing a substantial amount of TCP data. Hardware can then perform TCP segmentation offload. Instead of the CPU manually constructing every 1500-byte TCP segment, the NIC can split the data into appropriate frames during transmission.

Wireshark explicitly documents this behavior and explains that TSO/GSO can result in large “superpacket” buffers being provided to the hardware and later divided into maximum-size packets. That means a capture taken on the sending host can show traffic in a form that does not exactly match the frames that physically appeared on the cable.

This is one reason serious troubleshooting sometimes requires capturing traffic at an external observation point.

Checksum Offloading

The same principle applies to checksums. The operating system may construct a packet without calculating the final TCP checksum. The NIC calculates it just before transmission. If Wireshark captures the packet before the NIC performs that calculation, Wireshark may see an incomplete checksum.

The result can look like:

TCP checksum: incorrect

even though the actual transmitted packet had the correct checksum.

Wireshark’s current documentation specifically warns about this and explains that checksum offloading can cause locally generated packets to appear invalid in a capture.

This is why “Wireshark says bad checksum” should never immediately be interpreted as:

The network is corrupting packets.

You first need to determine where the capture was taken and whether offloading is active.

Ethernet Flow Control

Ethernet can also provide flow-control mechanisms. One example is the Ethernet PAUSE mechanism. The basic idea is that a receiving device experiencing congestion can request that a peer temporarily stop transmitting. This operates at Layer 2. It is not the same thing as TCP flow control.

TCP has its own receive window and congestion-control mechanisms. Ethernet PAUSE operates over a local Ethernet link. This fact matters because congestion can exist at multiple layers.

You can have:

Application slow
TCP receive window constrained
TCP congestion controlled
Switch queue congested
NIC receive buffer congested
Physical link saturated

These are not equivalent problems.

Full Duplex Ethernet

Modern switched Ethernet is normally full duplex.

The endpoint can transmit and receive simultaneously.

Conceptually:

Host A
  ⇄
Switch
  ⇄
Host B

The transmit and receive paths operate independently. This is very different from the old shared-medium Ethernet models. As a result, ordinary collision detection is no longer part of the normal operation of a full-duplex switched link.

Duplex mismatches were historically a particularly painful troubleshooting problem on 10/100 Ethernet. One side operating full duplex while the other operated half duplex could produce severe performance problems, collisions and retransmissions.

Modern auto-negotiated links greatly reduce the frequency of such problems, but understanding duplex remains important when diagnosing legacy equipment or manually configured interfaces. Cisco’s Ethernet troubleshooting material specifically discusses speed and duplex negotiation and mismatches. (Cisco)

The Ethernet Inter-Frame Gap

Frames are not transmitted continuously with no separation. Ethernet defines an interpacket or interframe gap. The classic requirement is 96 bit-times.

At 1 Gbit/s, a bit-time is approximately one nanosecond, making 96 bit-times roughly 96 nanoseconds. At 10 Gbit/s, the same number of bit-times is roughly 9.6 nanoseconds.

So the physical transmission looks conceptually like:

Preamble
Frame
Inter-frame gap
Preamble
Frame
Inter-frame gap
...

The gap is part of the timing behavior of Ethernet and is another example of something that normally disappears from a conventional packet capture. The complete physical event is larger than the neat frame representation shown by packet analyzers.

MAC Learning Is Not Routing

A switch might have:

aa:aa:aa:aa:aa:aa → Port 4

A router has something more like:

10.20.0.0/16 → next hop X
192.168.50.0/24 → next hop Y
0.0.0.0/0 → next hop Z

The switch asks:

Which physical port should receive this Ethernet frame?

The router asks:

Which Layer 3 path should carry this IP packet next?

These are fundamentally different decisions.

Layer 2 forwarding is based primarily on MAC addresses.

Layer 3 forwarding is based on IP addresses and routing information.

Some modern switches can perform both functions, which is why the hardware boundary between “switch” and “router” is less obvious than it used to be. But conceptually, the forwarding decisions remain different.

CAM Tables and MAC Address Tables

Switch forwarding tables are often implemented using specialized hardware structures commonly referred to as CAM tables. CAM stands for Content Addressable Memory.

Rather than scanning every possible table entry like a conventional CPU might, specialized hardware can perform extremely fast matching operations.

A simplified conceptual model is:

Destination MAC
      ↓
CAM lookup
      ↓
Output port

This is one reason dedicated switches can forward enormous numbers of frames at line rate.

The actual architectures of modern switching ASICs are considerably more sophisticated than a simple CAM-only model, but the conceptual idea remains useful.

Unknown Unicast Flooding

What happens if a switch receives:

Destination MAC = X

but has no table entry for X?

The switch does not know which port leads to X.

Depending on VLAN and switch behavior, it can flood the frame out other forwarding ports within the relevant Layer 2 domain. This is called unknown-unicast flooding.

It is different from broadcast because the destination address is still a unicast MAC address. The switch simply does not know where it is. Once the switch learns the destination’s location, subsequent frames can be forwarded directly.

MAC Address Aging

MAC learning cannot remain permanent. Imagine a laptop moves from Switch Port 5 to Switch Port 12.

If the switch permanently believed:

Laptop MAC → Port 5

traffic would continue going to the wrong place. Therefore MAC entries age out.

When the laptop begins transmitting from Port 12, the switch can relearn:

Laptop MAC → Port 12

This is one of the reasons network administrators sometimes observe MAC addresses apparently “moving” between switch ports.

A single movement can be normal. Rapid movement between ports may indicate a loop, virtualization behavior, misconfiguration or another problem.

MAC Flapping

A switch may report something similar to:

MAC A seen on Port 4
MAC A seen on Port 7
MAC A seen on Port 4
MAC A seen on Port 7

This is commonly described as MAC flapping.

It can happen for legitimate reasons, particularly in complex virtualized or redundant environments. But it can also indicate a Layer 2 loop.

STP exists partly because uncontrolled Layer 2 loops can cause exactly this type of instability. Cisco’s STP documentation notes that loops can cause devices to learn the same MAC addresses through multiple interfaces and destabilize the network.

Broadcast Storms

Broadcast traffic is useful. ARP, DHCP and various discovery mechanisms depend on broadcast or multicast behavior. But uncontrolled broadcast traffic can become destructive.

If a Layer 2 loop exists, a broadcast frame can circulate around the topology. Each switch can forward it onward. The result can become a broadcast storm.

Network interfaces and switches spend increasing amounts of their capacity processing traffic that is not useful to applications. This is one of the reasons Layer 2 loop prevention is not merely a theoretical concern.

STP Is More Than “Blocking a Port”

At a conceptual level, STP creates a tree. It identifies a root bridge. Switches determine preferred paths toward that root. Redundant paths are prevented from simultaneously forwarding in a way that would create a loop.

The details involve Bridge Protocol Data Units, bridge IDs, path costs, port roles and state transitions. Modern variants such as Rapid STP improve convergence compared with classic STP.

The important engineering principle is:

Physical redundancy does not require logical forwarding redundancy.

You can maintain multiple physical paths while allowing only a loop-free subset to forward at any particular time.

LLDP: How Ethernet Devices Advertise Information About Themselves

Ethernet networks also have discovery protocols.

One widely used example is LLDP, the Link Layer Discovery Protocol. A switch can use LLDP to learn information about directly connected devices.

This can include information such as:

Device identity
Port identity
Capabilities
Management address
System description

LLDP is particularly useful when troubleshooting large networks.

Instead of physically tracing every cable, an administrator can query switches and determine what is connected to each port.

Voice deployments can also use link-layer discovery information to help endpoints learn network configuration.

Ethernet and DHCP

Ethernet itself does not assign IP addresses. DHCP does.

A newly connected host may have:

MAC address
No IPv4 address

It can use DHCP to obtain:

IP address
Subnet mask
Default gateway
DNS servers
Other configuration

The initial DHCP exchange may involve Layer 2 broadcast because the client does not yet know its IPv4 configuration.

This produces an excellent real-world example of multiple protocols interacting:

Ethernet
   ↓
IPv4
   ↓
UDP
   ↓
DHCP

The Ethernet layer simply transports the frames containing the IP/UDP/DHCP traffic

What Happens When You Browse a Website?

Consider opening:

https://example.com

A modern connection can involve considerably more than the classic “HTTP over TCP” diagram, but the underlying layering remains useful.

The application needs to resolve the destination name. DNS may be used. The operating system determines the destination IP. It consults the routing table. If the destination is outside the local subnet, the next hop is normally the gateway. The host resolves the gateway’s MAC address if needed. A TCP connection may be established.

For HTTPS, TLS is negotiated over the transport connection. Application data is then transmitted. At every Ethernet hop, the local Ethernet frame is appropriate for that link. The remote web server never needs to know the MAC address your laptop used on its local LAN. The MAC address is local. The IP destination represents the network-layer endpoint.

Ethernet Does Not Know What HTTPS Is

This is a useful example of abstraction.

Suppose the Ethernet payload contains:

IPv6
  ↓
TCP
  ↓
TLS
  ↓
HTTP

Ethernet does not care.

It sees:

Destination MAC
Source MAC
EtherType = IPv6
Payload
FCS

The Ethernet layer is not parsing HTTP.

It does not know whether the payload is:

GET /index.html

or:

encrypted TLS ciphertext

or some completely different application protocol. This is precisely what layering is supposed to accomplish.

What Happens When the Destination Is Not on Your LAN?

This deserves a complete walkthrough.

Suppose:

Your IP:
192.168.1.100
Gateway:
192.168.1.1
Remote server:
203.0.113.50

Your computer determines that:

203.0.113.50

is outside the local subnet.

The routing table says:

Next hop = 192.168.1.1

The host resolves:

192.168.1.1 → gateway MAC

It constructs:

Ethernet destination = Gateway MAC
Ethernet source      = Your MAC
IP source            = 192.168.1.100
IP destination       = 203.0.113.50

The switch forwards the frame to the gateway. The router receives it. The Ethernet header is removed. The router examines the IP packet. The routing decision identifies the next interface.

The router constructs another Ethernet frame:

Ethernet source      = Router's outgoing MAC
Ethernet destination = Next-hop MAC
IP source            = 192.168.1.100
IP destination       = 203.0.113.50

The IP packet continues. The original Ethernet frame does not.

That process repeats at each Ethernet-based routed hop.

What NAT Changes

If the network uses NAT, there is another transformation.

For example, a private host might have:

192.168.1.100

while the router has a public address.

The router can translate the source address and often source port as the traffic leaves the private network. The exact behavior depends on the NAT implementation.

This is another example of why the statement:

The IP packet never changes.

is too simplistic.

Across a routed path, IP addresses may remain stable in ordinary forwarding, but devices such as NAT gateways can intentionally modify them.

Ethernet addresses, meanwhile, are expected to change from local link to local link.

MAC Addresses and IP Addresses Have Different Lifetimes

Another useful way to understand the layers is to consider how long an address remains relevant.

The destination IP can remain relevant for the duration of the end-to-end communication. The Ethernet destination MAC is only relevant to the current link.

At the next router:

Old Ethernet frame

is discarded. A new one is constructed.

This is why a packet capture at two different routed locations can show the same IP conversation wrapped in completely different Ethernet addresses.

Why MAC Addresses Are Not Security Boundaries

A MAC address can be useful for identifying a device in a network-management context. It should not be treated as an unforgeable identity. Software can often change the MAC address used by an interface. Virtual machines have virtual MAC addresses. Containers can have virtual interfaces. Attackers can forge source addresses.

Switch security mechanisms can restrict which MAC addresses are allowed on a port, but MAC addresses themselves are not cryptographic identities.

This is important in network access control.

Port Security

Switches can impose restrictions on which MAC addresses are permitted on an access port.

For example, an administrator may configure a port to allow only a particular MAC address or a limited number of learned addresses. This can help mitigate certain unauthorized-device scenarios. It is not a complete security solution.

An attacker may be able to spoof an allowed MAC address, and the effectiveness of port security depends heavily on the environment and other controls.

Layer 2 security should therefore be treated as one component of a larger security architecture.

DHCP Snooping and Dynamic ARP Inspection

Enterprise switches can use DHCP snooping to build bindings between information such as:

MAC
IP
VLAN
Switch port

Those bindings can then be used by other security mechanisms.

Dynamic ARP Inspection can use trusted information to validate ARP messages and help defend against ARP spoofing.

This is a good example of how Ethernet infrastructure can enforce security policy without requiring the application to participate.

Ethernet and Network Segmentation

A large Ethernet network is rarely just one flat network.

Modern enterprise networks commonly use combinations of:

VLANs
Layer 3 interfaces
ACLs
Firewalls
Routing
Network access control
Private VLANs
VXLAN / overlays

The physical Ethernet infrastructure provides the underlying connectivity. The logical architecture determines which hosts are allowed to communicate.

This is why a modern switch can be doing much more than simply forwarding frames.

Ethernet Overlays and Modern Data Centers

Modern data centers increasingly use overlays such as VXLAN. The idea is to carry one logical network over another underlying network.Modern data centers increasingly use overlays such as VXLAN. The idea is to carry one logical network over another underlying network.

Conceptually:

Original Ethernet frame
        ↓
VXLAN encapsulation
        ↓
UDP
        ↓
IP
        ↓
Outer Ethernet

The original Ethernet frame becomes payload inside another packet. This lets data-center networks provide large logical Layer 2 domains over Layer 3 infrastructure.

It is a powerful example of encapsulation continuing beyond the traditional Ethernet/IP stack. The Ethernet frame itself does not have to know that it is being transported through an overlay.

Ethernet Frames Can Be Nested

Encapsulation does not stop with:

Ethernet → IP → TCP

You can have:

Ethernet
  ↓
IP
  ↓
UDP
  ↓
VXLAN
  ↓
Inner Ethernet
  ↓
IP
  ↓
TCP
  ↓
Application

Packet captures of modern data-center traffic can therefore look dramatically more complicated than a simple laptop-to-server capture.

The same fundamental principle remains:

Each layer wraps another protocol and gives the next layer enough information to perform its job.

Ethernet and Virtual Machines

Virtualization makes Ethernet even more interesting.

A physical server may have:

Physical NIC
    ↓
Virtual switch
    ↓
VM1
VM2
VM3
VM4

Each virtual machine can have its own virtual NIC and MAC address. The virtual switch performs Layer 2 forwarding in software or hardware-assisted infrastructure. From the VM’s perspective, it may appear to have an ordinary Ethernet interface. But the physical network may only see frames after the hypervisor has processed them.

This is another reason packet captures taken inside a VM and packet captures taken on the physical network can look different.

Containers Add Another Layer

Linux containers commonly use virtual Ethernet pairs and bridges.

A container may have:

eth0

inside its network namespace.

That interface can be connected to a virtual Ethernet pair. The host may connect the other side to a Linux bridge. The bridge can then connect the traffic to a physical NIC.

Conceptually:

Container eth0
      ↓
veth pair
      ↓
Linux bridge
      ↓
Host interface
      ↓
Physical NIC
      ↓
Ethernet

Again, the application does not need to know. It writes to a socket. The networking stack handles the rest.

Why Packet Capture Location Matters So Much

Imagine capturing traffic in three places:

Capture A:
Inside application host
Capture B:
On the switch mirror port
Capture C:
On the receiving host

The captures may not look identical.

Capture A can be affected by:

Checksum offload
TSO
GSO
GRO
Virtualization
Driver behavior

Capture B can show traffic closer to what traversed the physical network.

Capture C shows traffic after it has passed through the receiving NIC and network stack.

Wireshark’s documentation explicitly warns that capture location and checksum offloading can affect how traffic appears.

This is why experienced network engineers do not blindly trust one capture point. They understand what that capture point can and cannot observe.

GRO and Receive-Side Processing

The receive path has similar optimizations. Instead of delivering every individual packet immediately to the operating system, the NIC and kernel can combine or coalesce packets for processing efficiency.

This reduces CPU overhead. It can also make a local capture appear different from what was physically received.

This is one of the reasons packet analysis at high speeds increasingly requires understanding the host’s networking stack rather than treating packet captures as perfect wire recordings.

The NIC Is Doing Much More Than Sending Bits

Modern network interface cards can perform tasks such as:

Checksum offload
TCP segmentation offload
Receive coalescing
VLAN insertion/removal
RSS
Packet filtering
Timestamping
Queue management

High-performance NICs can go much further, especially in data-center environments.

They may expose multiple transmit and receive queues and support hardware steering, virtualization features and programmable processing.

The basic Ethernet frame remains the conceptual foundation, but the path between an application’s memory and the physical wire is no longer a simple “copy bytes into NIC” operation.

RSS and Multiple CPU Cores

Modern servers receive enormous numbers of packets.

Processing all network traffic on one CPU core would quickly become a bottleneck.

Receive Side Scaling, commonly known as RSS, can distribute incoming traffic across multiple receive queues and CPU cores.

A hashing mechanism can map flows to queues.

For example:

Flow A → Queue 0 → CPU 2
Flow B → Queue 1 → CPU 5
Flow C → Queue 2 → CPU 7

The goal is to parallelize network processing while preserving ordering within a flow. This is an important part of understanding high-speed Ethernet systems.

Ethernet Timestamps and Precision

Some Ethernet environments require extremely precise timing. Financial systems, industrial systems, telecom infrastructure and high-performance measurement systems can use hardware timestamping and protocols such as Precision Time Protocol.

The NIC can timestamp packets much closer to the physical transmission or reception event than ordinary software timestamps.

Again, Ethernet becomes more than simply:

MAC → payload

once you move into specialized environments.

Ethernet and PoE

Ethernet can also carry electrical power over twisted-pair cabling through Power over Ethernet technologies.

PoE allows compatible equipment such as:

IP phones
Wireless access points
Cameras
IoT devices

to receive both network connectivity and electrical power through the same physical cable. The power-delivery mechanisms are distinct from the Ethernet frame itself.

The same cable can simultaneously participate in:

Power delivery
Ethernet signaling

without the power itself becoming part of the Ethernet frame.

Copper Ethernet

Twisted-pair Ethernet is extremely common.

Examples include:

10BASE-T
100BASE-TX
1000BASE-T
2.5GBASE-T
5GBASE-T
10GBASE-T

The exact physical signaling differs between generations.

Higher speeds can require more sophisticated signal processing, better cabling characteristics and more advanced transceiver technology.

Cable category therefore matters. A cable is not simply “Ethernet cable.” Its characteristics affect what Ethernet modes can reliably operate over it.

Fiber Ethernet

Fiber is common for longer distances and high-speed links. It provides electrical isolation and can support long-distance transmission without the same copper limitations. Common optical implementations include multimode and single-mode fiber variants. The transceiver determines how the electrical data from the Ethernet MAC is converted into optical signaling.

This is why Ethernet equipment often uses pluggable modules such as:

SFP
SFP+
SFP28
QSFP+
QSFP28
QSFP56
QSFP-DD

The exact module type corresponds to different generations, lane counts, speeds and physical implementations.

Ethernet Naming Conventions

Names such as:

1000BASE-T
10GBASE-SR
10GBASE-LR

encode information about the Ethernet implementation.

For example:

10GBASE-SR

is a 10 Gbit/s Ethernet physical technology using short-range optical signaling, commonly over multimode fiber.

The naming convention varies across generations, but understanding it helps when selecting NICs, transceivers and cables.

Ethernet Errors

When troubleshooting Ethernet, interface counters can be extremely useful.

You may encounter counters related to:

CRC errors
FCS errors
Alignment errors
Runts
Giants
Collisions
Late collisions
Symbol errors
Drops
Overruns
Pause frames

These counters point toward different classes of problems.

A CRC/FCS error can indicate corruption somewhere in the physical transmission path. A large number of drops may indicate congestion or buffer exhaustion. Symbol errors can indicate physical-layer problems. A high collision count on a supposed full-duplex modern link deserves investigation.

The exact interpretation depends heavily on the Ethernet technology and hardware.

Runt Frames and Giant Frames

A runt is generally a frame smaller than the minimum valid Ethernet frame size. A giant is an oversized frame relative to the configured or supported maximum.

These can occur because of:

Physical problems
Duplex issues
Misconfiguration
Jumbo-frame configuration
Malformed traffic
Driver problems

The switch or NIC may count them separately.

This is why interface statistics can tell you things that a normal packet capture does not.

CRC Errors Do Not Necessarily Mean the Sender Is Broken

Suppose a switch reports many FCS/CRC errors.

The problem could be:

Bad cable
Damaged connector
Faulty transceiver
Optical problem
Electromagnetic interference
Physical-layer failure
NIC problem
Switch port problem

The device reporting the error is not necessarily the device that caused it. The frame may have been corrupted somewhere between the sender and receiver.

This is why physical troubleshooting often involves replacing components systematically and checking error counters at both ends.

Ethernet Security Starts at Layer 2

Ethernet attacks are not limited to packet sniffing.

An attacker on a LAN may attempt:

ARP spoofing
MAC spoofing
MAC flooding
DHCP spoofing
VLAN hopping
STP manipulation
Rogue discovery services
Broadcast abuse
Layer 2 denial of service

Defenses can include:

Port security
802.1X
DHCP snooping
Dynamic ARP Inspection
BPDU Guard
Root Guard
Storm control
VLAN segmentation
Private VLANs
Network access control

The precise configuration depends on the environment.

The important lesson is that Ethernet itself is not inherently a trusted environment. The local network has historically been treated as a relatively cooperative domain. Modern security architectures cannot safely assume that.

802.1X and Network Access Control

802.1X provides port-based network access control.

Instead of allowing every device that physically connects to an Ethernet port to immediately gain unrestricted network access, the network can require authentication before granting normal access.

This is particularly useful in enterprise environments. The physical Ethernet connection becomes only the starting point. Identity and authorization are layered above it.

Why Encryption Still Matters on Ethernet

Ethernet can provide local delivery. It does not automatically encrypt the payload. Someone who can capture traffic on the network may be able to inspect unencrypted protocols.

This is why protocols such as:

HTTPS
SSH
TLS
IPsec

remain important.

Even if the Ethernet frame is visible, encryption can prevent the observer from understanding the protected application data.

Ethernet provides connectivity. Security often comes from higher layers.

A Practical Wireshark Walkthrough

The best way to understand all of this is to capture it.

Start with two machines on the same LAN. Clear the relevant ARP cache if appropriate for your operating system and capture traffic while initiating a connection.

You may observe something resembling:

ARP Request
ARP Reply
TCP SYN
TCP SYN, ACK
TCP ACK
TCP data
TCP ACK
TCP FIN / ACK
...

If the destination is remote, the Ethernet destination should normally be the local gateway rather than the remote server’s MAC address.

Open the Ethernet section.

You should see something similar to:

Destination: aa:bb:cc:dd:ee:ff
Source:      11:22:33:44:55:66
Type:        IPv4

Expand IPv4:

Source:      192.168.1.100
Destination: 203.0.113.50

Expand TCP:

Source Port:      50000
Destination Port: 443
Sequence Number:  ...
Acknowledgment:   ...
Flags:            ...
Window:           ...
Checksum:         ...

Continue down into the application or encrypted protocol. This is the nested structure we started with.

Useful Wireshark Filters

When investigating Ethernet, filters such as these are useful:

eth

All Ethernet frames.

eth.addr == 00:11:22:33:44:55

Traffic involving a specific MAC address.

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

Ethernet broadcasts.

arp

ARP traffic.

eth.type == 0x0800

IPv4 Ethernet frames.

eth.type == 0x86dd

IPv6 Ethernet frames.

vlan

VLAN-tagged traffic.

tcp

TCP traffic.

tcp.analysis.retransmission

TCP retransmissions identified by Wireshark.

tcp.checksum_bad

Bad TCP checksum indications, although these should be interpreted carefully when capturing locally because of checksum offloading.

Wireshark’s current display-filter reference exposes fields for Ethernet source and destination addresses, EtherType, VLAN information, FCS and related Ethernet metadata. (Wireshark)

How to Follow an Entire TCP Stream

Wireshark can reconstruct higher-level streams.

If you select a TCP packet and use the Follow TCP Stream functionality, Wireshark can reconstruct the stream as the application sees it. This is important because the packet boundaries are not necessarily the application boundaries.

The application may have sent:

Hello
World

while the network carried the bytes in different TCP segments.

Wireshark can reassemble the stream so you can see the higher-level byte sequence. Its documentation specifically describes Follow Stream and TCP reassembly as tools for examining traffic in the way the application sees it.

What Wireshark Does Not Show You

A normal capture often does not show:

Ethernet preamble
Start Frame Delimiter
Physical encoding
Electrical waveform
Optical waveform
Inter-frame timing at the physical layer

It may also omit:

FCS

depending on the capture environment.

And on the sending host, it can show:

Incomplete TCP checksum
Large offloaded segments

before the NIC transforms them into their final wire representation.

Wireshark therefore should be thought of as a packet-analysis instrument, not a physical-layer analyzer.

What a Network TAP Changes

A network TAP sits directly in the traffic path and copies traffic to a monitoring interface. This can provide a more faithful observation point than capturing inside an endpoint.

A TAP is especially useful when investigating:

Physical corruption
Packet loss
Latency
Network security events
Unexpected retransmissions
Switch behavior

The capture still does not magically expose every physical signal detail, but it moves the observation point closer to the actual network.

Ethernet and Packet Loss

Ethernet itself does not generally provide end-to-end reliable delivery.

If an Ethernet frame is corrupted and discarded, Ethernet does not establish a connection and ask the sender to resend it. Higher-layer protocols decide what happens next. TCP may retransmit. UDP may not. An application protocol might implement its own recovery. Or the data might simply be lost.

This is why saying “Ethernet is reliable” is misleading. Ethernet has error detection. TCP can provide reliable end-to-end delivery. Those are different guarantees.

Ethernet and TCP Solve Different Problems

Consider a frame carrying TCP data.

Ethernet can detect:

Did the frame become corrupted?

TCP can determine:

Did I receive the required bytes?
Are they in the correct sequence?
Do I need retransmission?
How much data can the receiver currently accept?
How aggressively should I send?

The two protocols cooperate.

Neither replaces the other.

The TCP specification explicitly describes TCP as an end-to-end transport protocol and requires TCP checksum generation and verification.

The TCP Three-Way Handshake Still Travels Through Ethernet

When a new TCP connection begins, the application data does not immediately appear.

The endpoints first establish TCP state.

The classic exchange is:

Client                         Server
SYN ------------------------>
       <--------------------- SYN/ACK
ACK ------------------------>

Every one of those TCP segments can be carried inside an IP packet and then an Ethernet frame.

So even the TCP handshake is ultimately being transported by the underlying Ethernet infrastructure when Ethernet is the local link.

The Ethernet layer does not know that the frame contains a SYN. It merely carries it.

Ethernet and UDP

Everything above does not require TCP.

UDP can also be carried through Ethernet:

Ethernet
   ↓
IP
   ↓
UDP
   ↓
Application

UDP does not provide TCP’s ordered reliable byte-stream semantics. But Ethernet does not care.

The EtherType identifies IP. IP identifies UDP through its protocol or Next Header information. UDP identifies the destination port. The application receives the datagram.

This is another demonstration of layering.

IPv6 Extension Headers

IPv6 adds another layer of complexity. An IPv6 packet can contain extension headers between the base IPv6 header and the upper-layer protocol.

For example:

Ethernet
  ↓
IPv6
  ↓
Extension Header
  ↓
TCP
  ↓
Application

RFC 8200 defines the IPv6 extension-header mechanism and the Next Header field used to identify what follows. Again, Ethernet simply carries the resulting IPv6 packet.

Ethernet Is the Local Delivery Layer

This is perhaps the cleanest mental model to keep.

IP asks:

Where is the destination?

Ethernet asks:

Which interface on this local link gets this frame next?

TCP asks:

How do I provide the application with an ordered, reliable stream of bytes?

The switch asks:

Which port leads toward this MAC address?

The PHY asks:

How do I represent these bits using this physical medium?

The application asks:

What do these bytes actually mean?

Each question belongs to a different layer.

The Entire Journey, From Program to Wire

Now we can put everything together.

A program executes:

send(socket, data)

The operating system accepts the bytes. TCP associates them with an existing connection. TCP determines the sequence space and constructs an appropriate segment. The IP layer determines the destination and consults the routing table. If the destination is remote, the next hop is usually the local gateway. For IPv4, the system may perform an ARP lookup. The network stack passes the packet toward the Ethernet interface.

The Ethernet layer constructs the frame:

Destination MAC
Source MAC
EtherType
Payload
FCS

The NIC and PHY handle the physical transmission. The preamble and Start Frame Delimiter precede the frame. The signal travels across the medium. A switch receives the frame. It validates it at the physical/link level. It learns the source MAC if necessary. It looks up the destination MAC. It forwards the frame toward the correct port. If a router is the destination of the current frame, the router processes the IP packet. The old Ethernet frame is removed. A new frame is created for the next link.

Eventually the packet reaches the destination network. The final switch forwards the frame to the receiving host. The receiving NIC validates the frame. The Ethernet layer accepts the payload. The IP layer processes the packet. TCP validates the segment, uses its sequence numbers and acknowledgment mechanisms, and reconstructs the ordered byte stream. The operating system places those bytes into the receiving socket.

The application reads:

Hello from the Universe

The application never had to know:

MAC address
ARP
VLAN
STP
EtherType
FCS
switch CAM table
preamble
physical signaling
NIC checksum offload
TCP segmentation

That invisibility is the entire point of the design.

A Single Message Can Therefore Have Several “Addresses”

Take one application message. At the application level, it belongs to a particular application protocol.

At TCP:

Source port
Destination port

At IP:

Source IP
Destination IP

At Ethernet:

Source MAC
Destination MAC

These are not competing address systems. They answer different questions.

For a remote destination:

Application:
HTTPS
TCP:
ephemeral port → 443
IP:
192.168.1.100 → 203.0.113.50
Ethernet on first link:
Laptop MAC → Gateway MAC

At the next routed hop:

Ethernet:
Router MAC → Next-hop MAC

while the IP destination can still be:

203.0.113.50

That is one of the most important facts in networking.

Why Ethernet Has Survived for So Long

Ethernet’s success is not simply because it is fast. Its architecture is flexible. The physical technology can evolve. The speeds can increase. The media can change. Switching can replace shared-medium operation. VLANs can divide physical networks into logical networks. Higher-layer protocols can change. Virtual machines can create virtual Ethernet interfaces. Overlays can carry Ethernet frames over IP networks.

Yet the fundamental abstraction remains useful:

Frames
MAC addresses
Local delivery

That stability has allowed Ethernet to survive enormous changes in computing.

Ethernet Is Not a Cable

This is perhaps the misconception worth eliminating completely.

Ethernet is not:

the RJ45 connector.

It is not:

Cat6 cable.

It is not:

1 Gbit/s.

It is not:

a switch.

It is not:

a MAC address.

It is a family of networking technologies and standards that span link operation and many physical implementations.

The connector is merely one physical interface. The cable is merely one medium. The switch is one device that participates in Ethernet networking. The MAC address is one component of Ethernet addressing. The frame is one unit of Ethernet data transfer. The complete system is much larger.

The Ethernet Model That Actually Works

If you remember only one diagram from this entire guide, use this:

                    APPLICATION
                         │
                         │ bytes
                         ▼
                  TCP / UDP
                         │
                         │ segment / datagram
                         ▼
                    IPv4 / IPv6
                         │
                         │ IP packet
                         ▼
                      ETHERNET
                         │
              ┌──────────┴──────────┐
              │                     │
        Destination MAC       Source MAC
              │                     │
              └──────────┬──────────┘
                         │
                    Ethernet frame
                         │
                         ▼
                       NIC
                         │
                         ▼
                       PHY
                         │
                         ▼
                 Copper / Fiber
                         │
                         ▼
                      SWITCH
                         │
                   MAC lookup
                         │
                         ▼
                 Next Ethernet link
                         │
                         ▼
                      ROUTER
                         │
                  IP forwarding
                         │
                         ▼
              New Ethernet frame
                         │
                         ▼
                   Next network

And the reverse happens at the destination.

Final Perspective

The easiest way to underestimate Ethernet is to describe it as a method for sending data between computers.

It is more precise to think of Ethernet as the machinery responsible for moving frames across local links while providing the addressing, framing, error detection and link behavior required to make that possible.

The application creates bytes. TCP can turn those bytes into a reliable ordered stream. IP gives that communication a network-layer destination. Routing determines the next network. ARP or IPv6 Neighbor Discovery can resolve the local next hop. Ethernet creates the frame that can actually be delivered across that link. A switch learns where MAC addresses live and forwards frames accordingly. VLANs allow the physical infrastructure to carry multiple logical Layer 2 networks. STP and related mechanisms prevent Layer 2 loops. The NIC and PHY convert the frame into a physical transmission. The receiver validates it. The higher layers unwrap it. TCP reconstructs the stream when TCP is being used. And finally, the application receives the same bytes that started the entire process.

What makes Ethernet remarkable is not any individual field in the frame. It is the fact that all of these independent mechanisms cooperate while remaining largely invisible to the application.

A programmer can write:

send(socket, "Hello World")

without knowing which switch port the server is connected to, what its MAC address is, whether the frame will cross a VLAN trunk, which routing protocol selected the path, whether the NIC calculates the checksum in hardware, whether the physical link is copper or fiber, or whether the eventual IP packet will cross ten routers before reaching its destination. The application does not need to know.

That is what good networking architecture looks like and when something breaks, understanding the layers gives you a way to reason about where the failure actually is.

If the link is down, look below Ethernet. If ARP fails, investigate local Layer 2 and IPv4 neighbor resolution. If the MAC is learned on the wrong port, investigate switching and topology. If VLAN traffic disappears, investigate tagging and VLAN membership. If a Layer 2 network is unstable, investigate loops and STP. If the Ethernet interface reports CRC errors, investigate the physical path. If the IP packet reaches the gateway but goes no further, investigate routing. If TCP repeatedly retransmits, investigate packet loss, congestion, MTU problems or the endpoint behavior.

If Wireshark reports bad TCP checksums only for locally generated packets, investigate checksum offloading before blaming the network. If a packet capture does not show another machine’s unicast traffic, remember that a switch normally does not forward that traffic to your capture port.

If you see an Ethernet frame carrying an IP packet destined for a server thousands of kilometres away but addressed to your local gateway’s MAC address, do not assume something is wrong. That is exactly how Ethernet is supposed to work. The MAC address gets the frame to the next local hop. The IP address gets the packet toward the ultimate destination. TCP, when used, gets the resulting bytes into the correct ordered stream and the application eventually gets the data it asked to send. Once that is clear, Ethernet stops being a collection of terms to memorize. It becomes something you can actually trace.

From the application, down through TCP and IP, into an Ethernet frame, through a switch, across physical media, potentially through multiple routed networks, and finally back up the stack at the destination, that is what is really happening every time a seemingly trivial application sends a few bytes across an Ethernet network.