The Ethernet frame

What an Ethernet frame is

A frame is the envelope that Ethernet uses to carry data across one link: from a computer to a switch, from a switch to another switch, or from a switch to a router. It has a header at the front (addresses and a type code), the payload in the middle (the data being carried), and a trailer at the end (an error check).

You met Ethernet in Ethernet fundamentals. Here you look inside the envelope. The format shown is Ethernet II, which carries almost all traffic on modern networks.

💡 In simple terms: a frame is like a parcel label stuck on a box. The label says who it is for, who sent it and what kind of thing is inside. The box holds the goods. A seal on the box shows whether it was damaged on the way.

Why frames exist

A cable can only carry a stream of bits: 1s and 0s. On its own, that stream has no meaning. The receiving device needs answers to a few questions:

• Where does a message start and end? The preamble and the frame's length answer this.
• Is this message for me? The destination MAC address answers this.
• Who sent it? The source MAC address. The reply goes back to it.
• What is inside? The EtherType: an IPv4 packet, an IPv6 packet or an ARP message.
• Did it arrive undamaged? The FCS answers this.

Framing turns a raw stream of bits into separate, addressed, checkable messages. That is the main job of Layer 2, the Data Link layer, in the OSI model.

Where the frame sits

When an application sends data, each layer wraps it in its own header (this is encapsulation). The Ethernet frame is the last, outermost wrapper before the bits go onto the cable:

So the frame carries the IP packet, and the IP packet carries the TCP or UDP segment, and the segment carries the application data. The frame only lives for one link. A router removes it, reads the IP packet, and builds a fresh frame for the next link.

The fields, one by one

Preamble and SFD (briefly)

Before the frame proper, the sender transmits 7 bytes of preamble (the pattern 10101010 again and again) and 1 byte called the Start Frame Delimiter, 10101011. The preamble gives the receiver's electronics time to synchronise its clock with the signal. The two 1s at the end of the SFD say “the next bit is the first bit of the destination MAC”.

The network card adds and removes these 8 bytes in hardware. They are never counted in the frame size, and capture tools such as Wireshark never show them.

Destination MAC address (6 bytes)

The MAC address of the receiver. It can be:

• Unicast: one specific interface, such as 02:00:00:00:00:bb.
• Broadcast: ff:ff:ff:ff:ff:ff, meaning every device on the LAN.
• Multicast: a group address such as 01:00:5e:00:00:fb.

The lesson Unicast, broadcast and multicast covers these three in depth.

Source MAC address (6 bytes)

The MAC address of the interface that sent the frame. It is always a unicast address, because a frame always comes from one interface. Switches read this field to learn where each device is (see How a switch learns MAC addresses).

EtherType (2 bytes)

A number that tells the receiver which protocol is inside the payload. Without it, the receiver would not know whether to pass the data to its IPv4 software, its IPv6 software or its ARP software.

Going deeper
In the original IEEE 802.3 format this same 2-byte field held the payload length instead of a type. The two formats can share a network because of a simple rule: a value of 1500 or less is a length, and a value of 1536 (0x0600) or more is an EtherType.

Payload (46 to 1500 bytes)

The data being carried. Usually this is a whole IP packet, headers and all. Two limits apply:

• Maximum 1500 bytes. This is the MTU (Maximum Transmission Unit) of standard Ethernet. An IPv4 packet bigger than this must be split up, or the sender must use smaller packets. With a 20-byte IPv4 header and a 20-byte TCP header, that leaves 1460 bytes of actual data per frame.
• Minimum 46 bytes. If there is less data, the sender adds padding (zero bytes) to reach 46. An ARP message is only 28 bytes, so it always gets 18 bytes of padding.

That gives a frame size (destination MAC to FCS) of 64 to 1518 bytes: 14 bytes of header, 46 to 1500 of payload, and 4 of FCS.

FCS: the error check (4 bytes)

The Frame Check Sequence is a 32-bit CRC (Cyclic Redundancy Check). The sender runs a fixed calculation over every byte from the destination MAC to the end of the payload and puts the result in the FCS. The receiver runs the same calculation. If its answer is different, at least one bit was changed on the way, and the frame is dropped.

⚠️ Ethernet does not ask for a damaged frame to be resent. It just throws it away and counts it as a CRC or FCS error on the interface. TCP notices the missing data later and resends it; UDP traffic is simply lost.

Why the destination comes first

The destination MAC is the very first thing after the preamble. That is on purpose. A device can decide what to do with a frame after reading only 6 bytes:

• A computer's network card compares it with its own MAC address. If it does not match (and it is not a broadcast or a group it has joined), the card ignores the rest of the frame without bothering the operating system.
• A switch can look up the destination in its MAC table while the rest of the frame is still arriving. Some switches (“cut-through” switches) even start sending the frame out of the right port before it has fully arrived.

💡 Think of it like a letter where the address is printed on the outside of the envelope. The postal worker never needs to open it to know where it goes.

What a switch reads

A switch is a Layer 2 device. It works with the frame header and does not need to understand the payload. For each frame it:

1. Reads the destination MAC and looks it up in its MAC address table to choose the outgoing port.
2. Reads the source MAC and records which port it arrived on (learning).
3. Checks the FCS (store-and-forward switches) and drops the frame if it is damaged.
4. Sends the frame on unchanged. The MAC addresses, EtherType and payload stay exactly the same.

You will follow this hop-by-hop behaviour in detail in Different-subnet communication.

A real frame, decoded

Here is a complete ARP request, the frame a PC sends when it wants to find the MAC address of its default gateway. The PC has MAC 02:00:00:00:00:aa and IP 192.168.1.10, and it is asking “who has 192.168.1.1?”. Every byte below is the real value, including a correctly calculated FCS.

Now the same frame as a capture tool shows it. Notice the length: when you capture on the sending PC, the tool sees the frame before the network card adds the padding and FCS, so it reports 42 bytes, not 64.

$ sudo tcpdump -e -n -i eth0 arp or tcp port 443
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:14:02.118204 02:00:00:00:00:aa > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 192.168.1.1 tell 192.168.1.10, length 28
10:14:02.118731 02:00:00:00:00:01 > 02:00:00:00:00:aa, ethertype ARP (0x0806), length 60: Reply 192.168.1.1 is-at 02:00:00:00:00:01, length 46
10:14:02.118802 02:00:00:00:00:aa > 02:00:00:00:00:01, ethertype IPv4 (0x0800), length 74: 192.168.1.10.51514 > 203.0.113.10.443: Flags [S], seq 3518220411, win 64240, options [mss 1460,sackOK,TS val 1873310 ecr 0,nop,wscale 7], length 0

A real-world example: loading a web page

You open https://routelearn.net on a laptop at home. Before any web page arrives, your laptop sends a burst of frames, and each one has a different job:

Notice that the destination MAC is the router every time, never the web server. The server is on another network, so the frame only needs to reach the first router. See What happens when you open a website? for the full journey.

When frames go wrong

💡 A classic sign of an MTU problem: ping works, small websites work, but big downloads or VPN connections stall. The small packets fit; the full-size ones do not.

Troubleshooting and useful commands

You cannot see frames with your eyes, but you can see their counters and capture them:

Why 1472 in the last row? 1472 bytes of ping data + 8 bytes of ICMP header + 20 bytes of IPv4 header = 1500, exactly the MTU. The extra option stops the packet being split, so if it fails, something on the path has a smaller MTU.

$ ip -s link show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 02:00:00:00:00:aa brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    912833410  702144      0       0       0    1312
    TX:  bytes packets errors dropped carrier collsns
     88213004  341207      0       0       0       0

Common mistakes

• Thinking the frame goes all the way to the server. A frame only crosses one link. The packet inside goes end to end.
• Counting the preamble in the frame size. The 64–1518 byte range starts at the destination MAC and ends at the FCS.
• Confusing MTU with frame size. MTU (1500) is the payload limit; the full frame is up to 1518 bytes.
• Expecting Ethernet to resend bad frames. It only detects errors; recovery is TCP's job.
• Thinking a switch rewrites MAC addresses. It does not. Only routers (and other Layer 3 devices) build new frames.

Check yourself

Where to go next

Next, look closely at the addresses in the header in MAC addresses, then see how a switch uses them in How a switch learns MAC addresses. The ARP message decoded above is explained step by step in ARP fundamentals.