Ethernet Frame Format: Every Field Explained

An Ethernet frame is the Layer 2 envelope that carries data across a local network. It has seven fields: preamble (7 bytes), start frame delimiter (1), destination MAC (6), source MAC (6), EtherType (2), payload (46 to 1500) and frame check sequence (4). Counted from destination MAC to FCS, a frame is 64 to 1518 bytes. Add a VLAN tag and the maximum becomes 1522.

That’s the whole format. Here it is as a table you can keep open next to your notes.

The rest of this guide explains each field, then builds one real frame byte by byte, with a checksum you can verify yourself. Most explanations skip that part. Honestly, it’s the part that makes the numbers stick.

What is an Ethernet frame?

An Ethernet frame is the unit of data that Ethernet moves between two directly connected devices. Your PC hands an IP packet down to its network card. The card wraps it in a header with two MAC addresses and a type code, adds a checksum at the end, and puts it on the wire.

Which layer constructs the Ethernet frame? The data link layer, Layer 2 of the OSI model. Specifically its MAC sublayer builds the header and the FCS. The physical layer then adds the preamble and SFD as it turns the frame into signals. If you want the layers side by side, our OSI model cheat sheet PDF puts them on one page.

One thing trips people up early. A frame only lives for one hop. It goes from your PC to the switch to the router, and the router throws it away and builds a brand new frame for the next link. The IP packet inside survives the whole trip. The frame doesn’t.

What does the Ethernet frame format look like?

The Ethernet frame format is a fixed sequence. Place the Ethernet II frame fields into the correct order and you get this:

1. Preamble
2. Start frame delimiter
3. Destination MAC address
4. Source MAC address
5. EtherType
6. Payload (data plus any padding)
7. Frame check sequence

Group them and the structure gets simpler. The header is destination MAC, source MAC and EtherType, 14 bytes in total. The payload follows. The trailer is the 4-byte FCS. The preamble and SFD sit in front of all of it.

Preamble and SFD: 8 bytes in front of the frame. Header: 14 bytes (destination MAC 6, source MAC 6, EtherType 2). Payload: 46 to 1500 bytes. FCS: 4 bytes. Header to FCS, the frame itself is 64 to 1518 bytes.

Here’s a detail most study guides blur. IEEE 802.3 calls the preamble and SFD part of the packet on the wire, not part of the frame. The frame starts at the destination MAC. That’s why the famous 64 and 1518 numbers don’t include those first 8 bytes. Lots of material lists the preamble as “field one” anyway, so you’ll see it both ways. Just know where the counting starts.

What does each field in an Ethernet frame do?

What is the preamble in an Ethernet frame?

The Ethernet frame preamble is 7 bytes of alternating ones and zeros: 10101010 repeated seven times on the wire. It carries no data. It’s a rhythm the receiver uses to sync its clock to the sender’s before anything important arrives.

Ethernet sends the least significant bit of each byte first, so if you write those bytes out in hex they’re 0x55, not 0xAA. Small thing. It explains why you’ll see both values quoted.

What is the start frame delimiter (SFD)?

The SFD in an Ethernet frame is one byte, 10101011 on the wire, 0xD5 as a byte value. It’s the preamble pattern with the last bit flipped to a 1. Those two ones in a row tell the receiver: the rhythm’s over, the next bit is the destination address.

Why does the destination MAC come first?

The destination MAC is the first real field because it’s the one a switch needs most, and needs fast. A switch can start looking up where to send the frame before the rest of it has even arrived.

The address is 6 bytes (48 bits). It can be a single device (unicast), a group (multicast), or everyone on the segment (broadcast, ff:ff:ff:ff:ff:ff). DHCP Discover and ARP requests both go out as broadcasts, which is why a DHCP client can find a server it has never heard of.

How many MAC addresses are in an Ethernet frame header? Two. Destination, then source. Never more, in a standard frame.

What does the source MAC tell a switch?

The source MAC is the 6-byte address of the sending interface. The receiving host mostly ignores it. The switch doesn’t. Every time a frame arrives, the switch reads the source MAC and records “this address lives on this port” in its MAC address table. That’s how a switch learns the network without being told anything.

What does the EtherType field specify?

The EtherType field specifies which protocol is inside the payload, so the receiver knows which part of its software to hand the data to. It’s 2 bytes, written in hex. The type field in an Ethernet frame is the reason one cable can carry IPv4, IPv6 and ARP at the same time without confusion.

These are the Ethernet type values you’ll actually meet, from the IEEE assignments that IANA lists:

What’s inside an 0x86DD frame is explained in our IPv6 guide and free PDF.

Notice 0x8809. When two switches negotiate a bundle, the LACP messages ride in ordinary Ethernet frames with that type code.

What’s inside the payload?

The payload carries the packet from the layer above, most often an IPv4 or IPv6 packet, or an ARP message. How much data can be encapsulated in an Ethernet frame? Between 46 and 1500 bytes.

The 1500 is the ceiling, and it’s the number you know as the MTU. The 46 is a floor. If the packet is smaller, the sender adds padding bytes (usually zeros) until the payload reaches 46. The receiver strips them back off. The worked example below shows exactly this happening.

What is the frame check sequence (FCS)?

The frame check sequence in Ethernet is a 4-byte CRC-32 value, and it makes up the whole Ethernet frame trailer. The sender runs every byte from the destination MAC to the end of the padding through the CRC-32 calculation and appends the result. The receiver runs the same calculation. If the answers differ, the frame got damaged on the way and gets dropped.

Two things the FCS doesn’t do. It doesn’t cover the preamble or SFD. And it doesn’t fix anything: there’s no retransmission at Layer 2. A dropped frame stays dropped, and TCP, or the application, has to notice and send again.

What does a real Ethernet frame look like in hex?

Enough theory. Below is one complete Ethernet frame: an ARP request asking “who has 192.0.2.1? Tell 192.0.2.10”. It uses documentation addresses (RFC 9542 MACs, RFC 5737 IPs), so nothing here belongs to a real device.

It was built byte by byte with a short Python script, and the FCS was computed with CRC-32, not copied from anywhere. The preamble and SFD aren’t shown, the same way your capture tools never show them. Offsets are in hex.

0000  ff ff ff ff ff ff 00 00 5e 00 53 01 08 06 00 01
0010  08 00 06 04 00 01 00 00 5e 00 53 01 c0 00 02 0a
0020  00 00 00 00 00 00 c0 00 02 01 00 00 00 00 00 00
0030  00 00 00 00 00 00 00 00 00 00 00 00 e9 18 79 d7

Exactly 64 bytes. Now take it apart:

The ARP message itself is only 28 bytes. That’s under the 46-byte minimum, so the sender pads it with 18 zeros. 14 bytes of header, plus 28, plus 18, plus 4 of FCS: 64. The minimum frame size isn’t a coincidence here. It’s the padding doing its job.

Look inside the ARP payload for a second. Bytes 16-17 are 08 00, the same code as IPv4’s EtherType. ARP reuses the EtherType list to say “I’m resolving an IPv4 address”. Then c0 00 02 0a is 192.0.2.10 and c0 00 02 01 is 192.0.2.1, written in hex.

And the FCS? The CRC-32 of bytes 0 to 59 is 0xD77918E9. Ethernet sends it least significant byte first, so it appears as e9 18 79 d7. Run CRC-32 over all 64 bytes, FCS included, and you get the fixed value 0x2144DF1C, which is how receiving hardware checks a frame in one pass. This frame passes.

Flip a single bit, say the lowest bit of the first source MAC byte, and the check fails. One bit out of 512. That’s how sensitive it is.

Why can’t you see the preamble or FCS in Wireshark?

Because your network card eats them. The hardware strips the preamble before any software gets the frame, and most interfaces don’t pass the FCS up either. So Wireshark usually shows you destination MAC through padding, and nothing else.

That’s why the same ARP request can look like a different size depending on where you capture it. On the host that sent it, you’ll often see 42 bytes: the frame before padding and FCS were added. On the receiving host, you’ll usually see 60: padded, but with the FCS already removed. Neither is wrong. Neither is the full 64 either.

How big is an Ethernet frame?

What are the two sizes of an Ethernet frame? A standard frame is at least 64 bytes and at most 1518 bytes, counted from destination MAC to FCS. With an 802.1Q tag the maximum is 1522. Those numbers are the Ethernet frame size limits you’ll be tested on.

Why is the minimum Ethernet frame size 64 bytes?

Collisions. Early Ethernet was a shared cable, and two devices could talk at once. A sender had to still be transmitting when news of a collision came back from the far end of the cable, otherwise it would finish, assume success, and never know its frame was destroyed.

The standard sized that window at 512 bit times, the slot time. 512 bits is 64 bytes. At 10 Mbps that’s 51.2 microseconds of transmitting; at 100 Mbps it’s 5.12. So the minimum Ethernet frame size is simply the shortest frame that keeps the sender talking long enough to hear a collision.

Today’s switched, full-duplex links don’t have collisions at all. The 64-byte minimum stayed anyway, so new hardware still works with old.

Gigabit Ethernet hit the wall at half duplex. 512 bit times at 1 Gbps is just 0.512 microseconds, which would have shrunk a collision domain to about 10 metres of cable. So the gigabit standard added carrier extension, stretching the slot to 4,096 bit times (512 bytes) without changing the 64-byte frame minimum. You’ll almost never meet half-duplex gigabit in practice. But if someone tells you gigabit has a 512-byte minimum, that’s where the number comes from: it’s the slot, not the frame.

What is the maximum Ethernet frame size?

The maximum Ethernet frame size is 1518 bytes untagged and 1522 tagged. Inside that, the payload tops out at 1500, which is the MTU.

Three different numbers get called “frame size”, and mixing them up causes most of the confusion. Here’s the same frame measured three ways:

The “on the wire” column includes the 12-byte minimum interframe gap, the idle time Ethernet leaves between frames. It’s why a 1 Gbps link tops out at 1,488,095 minimum-size frames per second (10^9 / (84 x 8)), or 81,274 full-size ones. Line-rate figures in switch datasheets usually come straight from this maths.

What is a jumbo frame in Ethernet?

A jumbo frame is any frame with a payload above 1500 bytes, usually around 9000. Jumbo frames aren’t part of the IEEE standard. They’re a vendor extension that storage and data centre networks use to move more data per frame.

Look at the table again. Going from 1500 to 9000 only lifts efficiency from 97.5% to 99.6%. The bigger win is about 5.9 times fewer frames to process for the same throughput, which matters to CPUs and storage arrays.

On Cisco Catalyst 9000 switches, system mtu accepts 1500 to 9216 bytes, and Cisco’s MTU troubleshooting guide points out that the value is the payload size, not the whole frame. Since IOS XE 17.1.1 you can also set it per port, on hardware that supports it.

Here’s what’s at stake. Every device in the path has to agree. Cisco’s own test in that guide sends 5 pings from a neighbour with an 1800-byte MTU into a port still at 1500, and the port drops all 5, counting them as giants. Small pings sail through, so the link looks healthy. Only big packets vanish.

How big is the Ethernet frame header?

The Ethernet frame header is 14 bytes: 6 for the destination MAC, 6 for the source MAC, 2 for the EtherType. An 802.1Q tag adds 4, making it 18. The trailer is always the 4-byte FCS.

That right-hand column is the one Cisco uses when it talks about “L2 header” in MTU maths: 1500 + 18 = 1518 on an access port, 1500 + 22 = 1522 on a trunk. Same numbers, different labels. If an exam question says the Ethernet frame header size is 18 bytes, check whether it’s quietly counting the FCS.

What is an Ethernet II frame, and how is 802.3 different?

There are two main Ethernet frame types, and they differ in one field. In an Ethernet II frame (also called DIX), bytes 12-13 are an EtherType. In an 802.3 Ethernet frame, the same two bytes are a length, and the payload starts with an 802.2 LLC header that says what’s inside.

So how does a receiver tell them apart? It reads the value:

• 1536 (0x0600) or higher: it’s an EtherType. Ethernet II.
• 1500 (0x05DC) or lower: it’s a length. 802.3, with an LLC header next.
• 1501 to 1535: undefined. Nothing valid uses it.

That gap is deliberate. No payload can be longer than 1500, and the few old Xerox type codes below 1536 were retired as EtherTypes back in 1983. So one field can do two jobs without ambiguity.

Bytes 12-13 decide it. 1536 (0x0600) or more is an EtherType, so it’s an Ethernet II frame. 1500 (0x05DC) or less is a length, so it’s an 802.3 frame with an LLC header next. 1501 to 1535 is unused.

Ethernet II won. IPv4, IPv6 and ARP all ride in Ethernet II frames, which is why most diagrams only show the EtherType version. But 802.3 frames never went away, and you see them every day on a switch.

Spanning tree is the classic example. IEEE BPDUs go to 01:80:C2:00:00:00 inside 802.3 frames with an LLC header whose service access points are both 0x42. An RSTP BPDU is 36 bytes, plus 3 bytes of LLC, so bytes 12-13 read 0x0027, which is 39. That’s under 1500, so it’s a length, so it’s an 802.3 frame. Cisco’s per-VLAN PVST+ BPDUs use an LLC/SNAP header instead and go to 01:00:0C:CC:CC:CD. If you’re studying how spanning tree protocol works or the RSTP port roles, that’s the frame those BPDUs ride in.

How does an 802.1Q tag change an Ethernet frame?

An 802.1Q tag inserts 4 bytes between the source MAC and the EtherType. The first 2 bytes are 0x8100, which tells the receiver “this frame is tagged”. The next 2 hold a 3-bit priority (PCP), a 1-bit drop-eligible flag (DEI) and the 12-bit VLAN ID.

The tag slots in right after the source MAC: TPID 0x8100, then PCP, DEI and a 12-bit VLAN ID, 4 bytes in all. The EtherType moves 4 bytes to the right, the maximum frame grows from 1518 to 1522 bytes, and the FCS is recalculated.

Here’s the same ARP request from earlier, tagged for VLAN 10:

0000  ff ff ff ff ff ff 00 00 5e 00 53 01 81 00 00 0a
0010  08 06 00 01 08 00 06 04 00 01 00 00 5e 00 53 01
0020  c0 00 02 0a 00 00 00 00 00 00 c0 00 02 01 00 00
0030  00 00 00 00 00 00 00 00 00 00 00 00 90 78 42 6e

Spot the tag at bytes 12-15: 81 00 00 0a. VLAN 10 is 0x00a. The real EtherType, 08 06, just moved four bytes to the right.

Two other things changed. The padding dropped from 18 bytes to 14, because a tagged frame only needs 42 bytes of payload to stay at 64. And the FCS is completely different, 90 78 42 6e, because the bytes changed. Every time a switch adds or removes a tag, it has to recalculate the FCS.

That tag is what makes VLANs work across a trunk, it’s what Dynamic Trunking Protocol negotiates, and it’s how a router on a stick tells VLANs apart on one interface.

What is an Ethernet pause frame?

An Ethernet pause frame is a short control frame that tells the device on the other end of a link to stop sending for a while. It’s the flow control mechanism from IEEE 802.3x, published in 1997, and it only works on full-duplex links.

It’s a normal 64-byte frame with a special layout:

One quantum is 512 bit times, so how long a pause lasts depends on link speed. The biggest value, 0xFFFF, works out to 65,535 quanta:

• 1 Gbps: 512 ns per quantum, about 33.6 ms maximum
• 10 Gbps: 51.2 ns per quantum, about 3.4 ms maximum

That might sound tiny. At 10 Gbps, 3.4 ms is about 4 MB of traffic that didn’t get sent. And a pause frame stops everything on the link, not one flow. Pause an uplink between two switches and every conversation crossing it waits, not just the one causing the congestion.

Ethernet frame vs packet: what’s the difference?

A frame is Layer 2 and a packet is Layer 3. The frame uses MAC addresses and only travels one link. The packet uses IP addresses and travels end to end. The packet rides inside the frame’s payload, not the other way round, at least on an ordinary LAN.

The easiest way to see it is one trip through a router. Your PC (192.0.2.10) sends to a server (198.51.100.20) on another network:

The MACs change at every hop. The IPs don’t (unless something like NAT rewrites them). The router strips the old frame, looks at the IP header, lowers the TTL, and builds a brand new frame for the next link. So “Ethernet frame vs packet” isn’t really a versus. It’s an envelope and the letter inside it.

The envelope is the frame, the card is the packet. The router builds a new frame for the second link, with new source and destination MACs and a new FCS. The IP addresses inside, 192.0.2.10 to 198.51.100.20, don’t change.

How does a switch use the Ethernet frame header?

What important information is examined in the Ethernet frame header? For a switch, two fields: the source MAC to learn, and the destination MAC to forward.

Here’s the sequence for every frame:

1. Learn. Read the source MAC and record it against the incoming port in the MAC address table.
2. Look up. Read the destination MAC and check the table.
3. Forward or flood. Known unicast goes out one port. Broadcast, multicast and unknown unicast get flooded out every port in that VLAN except the one it came in on.

Learn from the source MAC, forward on the destination MAC. Here the destination is already in the MAC address table, so the frame leaves on one port only. If it weren’t, all three laptops would get a copy.

So which statement is correct about Ethernet switch frame forwarding decisions? Forwarding decisions are based on the destination MAC address and the switch’s MAC address table. Not the IP address, and not the source MAC. The source MAC is only for learning.

When the switch checks the FCS depends on how it forwards:

• Store-and-forward buffers the whole frame, checks the FCS, and drops anything corrupted.
• Cut-through starts sending the frame as soon as it has read enough of the header to decide. It can’t check the FCS first, because the FCS is the last thing to arrive.

So what does a cut-through switch do with a bad frame it’s already half sent? Cisco’s Nexus 9000 CRC guide explains it: the switch “stomps” the CRC, overwriting the FCS with the bitwise inverse of the correct value. The next device sees a deliberately broken FCS and drops the frame, and the stomp counter tells you the damage happened further upstream.

Which Ethernet frame errors show up in show interfaces?

Three counters on show interfaces map straight to the frame rules above:

Input errors is the umbrella total. It includes runts, giants and CRCs plus a few others.

Cisco’s MTU guide shows what a mismatch looks like on a Catalyst 9000. After those 5 oversized pings, the interface reports:

0 runts, 5 giants, 0 throttles

That’s the giants counter doing exactly what the size rules predict. CRC errors that climb steadily, on the other hand, usually mean something physical. A damaged patch lead, a bad keystone, a cable that isn’t rated for the job. Our network troubleshooting commands PDF has the show commands for this on one sheet.

Where do Ethernet frames show up on the CCNA exam?

Frames are all over the CCNA, and the blueprint is about to change. Cisco’s Learning blog confirms the last day to test on CCNA v1.1 is February 2, 2027, and v2.0 goes live on February 3, 2027.

Notice the shift. v1.1 asks you to describe switching concepts. v2.0 drops that line and asks you to diagnose and troubleshoot, including reading packet capture output. In other words, the hex dump earlier in this post isn’t trivia anymore. Reading one is part of the job description. Our breakdown of what CCNA v2.0 changes covers the rest of the new blueprint.

Want to test yourself? The CCNA 200-301 practice test PDF and the free CCNA 200-301 notes both cover switching basics.

How can you capture Ethernet frames yourself?

Reading about frames is fine. Watching one go past is better. Build two hosts and a switch in a lab, ping between them, and capture on the link. The EVE-NG client pack bundles Wireshark, so you can start a capture on any link from the browser once you’ve installed EVE-NG.

Then go hunting:

• Find the ARP request. Is the destination ff:ff:ff:ff:ff:ff? Is the EtherType 0x0806?
• Find the ping. Is the EtherType 0x0800?
• Check the frame length Wireshark reports for the ARP. 42 or 60? Now you know why.
• Put a trunk between two switches and capture again. Find the 0x8100 tag and read the VLAN ID out of it.
• Leave spanning tree running and find a BPDU. Read bytes 12-13. Length or type?

If you need a starting topology, these EVE-NG CCNA labs are a good base, and the home lab setup guide covers the hardware side. Our CCNA lab workbook covers VLANs, 802.1Q trunking, EtherChannel and Rapid PVST+ as hands-on labs and comes with an EVE-NG ISO, so you can skip the wiring and go straight to the capture.

Frequently asked questions

What are the two sizes of an Ethernet frame?

A standard Ethernet frame is 64 bytes minimum and 1518 bytes maximum, counted from the destination MAC to the FCS. With an 802.1Q VLAN tag the maximum becomes 1522 bytes. Those limits leave out the 8 bytes of preamble and SFD, which come before the frame.

How much data can an Ethernet frame carry?

An Ethernet frame carries 46 to 1500 bytes of payload. Payloads under 46 bytes get padded up to 46. With an 802.1Q tag, the minimum payload drops to 42 because the tag fills the gap. Jumbo frames raise the ceiling to around 9000 bytes, but only where every device on the path supports them.

How many MAC addresses are in an Ethernet frame header?

Two. The destination MAC comes first, then the source MAC, each 6 bytes long. Switches use the destination to forward the frame and the source to learn which port each device sits on.

Which layer constructs the Ethernet frame?

The data link layer, Layer 2, builds the Ethernet frame. Its MAC sublayer adds the header and the FCS. The physical layer, Layer 1, adds the preamble and SFD and turns the bits into signals on the wire.

Is the preamble part of the Ethernet frame?

Strictly, no. IEEE 802.3 treats the preamble and SFD as part of the packet on the wire, and the frame starts at the destination MAC. Many study guides still list the preamble as the first frame field, so expect to see it both ways. What matters is that the 64 and 1518 byte limits don’t include it.

Does an Ethernet frame have a TTL?

No. IP packets have a TTL that drops at every router, but Ethernet frames have no such counter. A frame caught in a Layer 2 loop keeps circling until the loop is broken, which is exactly the problem spanning tree protocol exists to prevent.

Bottom line

• An Ethernet frame has seven fields. The frame itself runs from destination MAC to FCS: 64 to 1518 bytes, 1522 with a tag.
• The 64-byte minimum comes from collision detection. The 1500-byte payload limit is the MTU.
• Bytes 12-13 decide the frame type: 1536 or more is an EtherType (Ethernet II), 1500 or less is a length (802.3).
• Switches learn from the source MAC and forward on the destination MAC.
• Runts, giants and CRC errors are the size and FCS rules showing up in your counters.

Learn the fields once, then read real frames until they stop looking like hex soup. That’s the skill CCNA v2.0 is moving toward. Build it in the CCNA lab workbook.