Ethernet II (DIX Ethernet)

What it is (Definition)

Ethernet II—also called DIX Ethernet (named after DEC, Intel, and Xerox)—is the dominant Ethernet frame format used on modern wired LANs. It defines how data is wrapped into a Layer 2 frame so devices in the same broadcast domain can deliver payloads to the next protocol layer reliably and efficiently.

The key feature that distinguishes Ethernet II from older IEEE 802.3 LLC/SNAP framing is the EtherType field. EtherType tells the receiver what protocol is carried inside the frame (for example IPv4, ARP, IPv6, or VLAN-tagged traffic). In practice, most packets you capture on a typical LAN will be Ethernet II frames, even when the higher-layer protocols vary (TCP, UDP, DNS, TLS, and more).

In Wireshark, “Ethernet II” is the envelope that makes higher layers visible. If you understand the Ethernet II header and what it can and cannot do, you can quickly separate link-layer problems (switching, VLANs, loops) from network/transport/application issues above it.

Where it sits in the stack (Layer & usage)

L2 — Data Link layer. Ethernet II sits above physical signaling and below network-layer payloads. Its job is local delivery within a broadcast domain (often a single VLAN), not end-to-end routing across the internet.

• Below: Physical layer signaling over copper or fiber (Wi-Fi uses a different L2 framing model).
• Above: Network-layer payloads such as IPv4, IPv6, ARP, and VLAN-tagged frames (802.1Q).
• Where used: Switch-based LANs, enterprise networks, home routers/switches, virtualization bridges, and many data-center fabrics.

Ethernet frames are forwarded by switches using MAC address learning. When traffic must leave the local network, Ethernet carries the packet to a default gateway (router) as the next hop. The router then makes Layer 3 decisions and sends new Ethernet frames on the next link.

Header overview (Fields at a glance)

Ethernet II is intentionally simple. It identifies destination and source MAC addresses, indicates the payload type via EtherType, then carries the payload. Error detection exists at the link/physical boundary, but many NICs do not include that information in captures.

How it works (Typical flow)

1. Determine the next hop (local destination vs. a gateway/router).
2. Resolve the destination MAC address for that next hop (commonly via ARP for IPv4).
3. Build the Ethernet II frame: destination MAC, source MAC, and EtherType.
4. A switch forwards the frame based on its learned MAC table (or floods if unknown).
5. The receiver checks EtherType and passes the payload to the correct upper-layer protocol.

• Unicast: Delivered toward a single receiver MAC (one port on a switch).
• Broadcast: Delivered to all ports in the same broadcast domain/VLAN.
• Multicast: Delivered based on multicast handling rules.

How it looks in Wireshark

Display filter example:

eth.type == 0x0800

• “Ethernet II” appears as the first decoded header, showing source/destination MAC addresses.
• Vendor names may be displayed based on the MAC OUI (helpful, but not proof of device identity).
• If VLAN tagging is present, you’ll see 802.1Q information between Ethernet and the payload protocol.

Quick read tip: If you see unexpected VLAN tags, check for eth.type == 0x8100 and the VLAN ID. It often tells you whether your capture point is before or after tagging/untagging on a switch or host.

Common issues & troubleshooting hints

Broadcast storms

Symptom

The network becomes noticeably slow or unresponsive, with a continuous flood of broadcast frames visible in packet captures and interface statistics. Users often report timeouts, delayed responses, or “everything is slow” symptoms that affect many hosts at once.

Likely cause

Layer 2 loops caused by missing or misconfigured loop-prevention mechanisms (for example, spanning-tree issues), or incorrect bridging that replicates frames indefinitely inside the same broadcast domain.

How to confirm

Filter for broadcast destination MAC addresses and observe the frame rate over time. A persistently high and steady broadcast rate—especially across many different sources—strongly suggests a broadcast storm rather than a single noisy host.

MAC address flapping

Symptom

Connectivity works intermittently, with sessions dropping and recovering without an obvious pattern from the end-user perspective. You may see bursts of retransmissions or frequent ARP/neighbor discovery traffic as hosts repeatedly try to re-establish reachability.

Likely cause

Duplicate MAC addresses, virtual machine moves, or topology loops that cause the same MAC to appear on multiple switch ports. In some environments, misconfigured link aggregation/bonding can also present as a MAC moving unexpectedly.

How to confirm

Observe packet captures or switch logs for the same source MAC address being learned on different ports within a short time window. In captures, “who is talking” may look normal, but the apparent path changes rapidly.

Missing FCS in captures

Symptom

Network devices report CRC or FCS errors, while packet captures appear normal and show no corrupted frames. This can be confusing when you are trying to prove a physical-layer problem from a PCAP alone.

Likely cause

The network interface card, driver, or capture method removes the Frame Check Sequence before packets reach capture software. Many common capture setups cannot see the on-the-wire FCS even if errors exist.

How to confirm

Compare switch interface counters with capture results. If CRC/FCS errors increase on the switch/NIC side but are absent in Wireshark, FCS stripping (or capture limitations) is the most likely explanation.

Security notes (if relevant)

Ethernet II provides no authentication or encryption. A host on the same L2 segment can often observe or influence traffic unless the network is segmented and protected. Common risks include MAC flooding and L2 spoofing patterns such as ARP spoofing at the IPv4 boundary.

Mitigations typically come from network design and switch features (segmentation/VLANs, port security, 802.1X, storm control), and from higher-layer security (TLS, VPNs), not from changes to Ethernet framing itself.

Related pages (internal links)

• Back to Dictionary Index
• Key fields (Destination MAC, EtherType — Soon)
• Related topics (VLAN basics, Switch MAC learning — Soon)