23

According to the table here, it says that MTU = 1500 bytes and that the payload part is 1500 - 42 bytes or 1458 bytes (<- this is actually wrong!). Now on top of that you have to add IPv4 and UDP headers, which are 28 bytes (20 IP + 8 UDP). That leaves my maximum possible application message to as 1430 bytes! But by looking for this number in the Internet I see 1472 instead. Am I doing this calculation wrong here?

All I want to find out is the maximum application message I can send over the wire without the risk of fragmentation. It is definitely not 1500 because that includes the frame headers. Can someone help?

The confusion is the PAYLOAD can actually be as large as 1500 bytes and that's the MTU. So now what is the size in-the-wire for a payload of 1500? From that table it can be as big as 1542 bytes.

So the maximum app messages I can send is 1472 (1500 - 20 (ip) - 8 (udp)) for a maximum in the wire size of 1542. It amazes me how things can get so complicated when they are actually simple. And I have not clue how someone came up with the number 1518 if the table says 1542.

HoldOffHunger
  • 141
  • 5
chrisapotek
  • 575
  • 2
  • 5
  • 17
  • The real question here is what do you mean by "in the wire size" and what will you do with this information? Are you trying to calculate packets per second? – Mike Pennington Aug 28 '12 at 22:37
  • @MikePennington Trying to determine in-the-wire transite time. With packet size and ethernet speed (10 gigabits) you can calculate that. – chrisapotek Aug 28 '12 at 22:51

4 Answers4

31

The diagram on Wikipedia is horrible. Hopefully what I'm about to write is clearer.

The maximum payload in 802.3 ethernet is 1500 bytes.
This is the data you're trying to send out over the wire (and what the MTU is referring to).
[payload] <- 1500 Bytes

The payload is encapsulated in an Ethernet Frame (which adds the Source/Destination MAC, VLAN tag, Length, and CRC Checksum. This is a total of 22 bytes of additional "stuff"
[SRC+DST+VLAN+LENGTH+[payload]+CRC] <- 1522 Bytes

The Frame is transmitted over the wire -- before your ethernet card does that it basically stands up and shouts really loud to make sure nobody else is using the wire (CSMA/CD) -- This is the Preamble and Start-of-Frame delimiter (SFD) -- an additional 8 bytes, so now we have:
[Preamble+SFD+[Ethernet Frame]] <- 1530 Bytes

Finally when an ethernet transceiver is done sending a frame it is required by 802.3 to transmit 12 bytes of silence ("Interframe Gap") before it's allowed to send its next frame.
[Preamble+SFD+[Ethernet Frame]+Silence] <- 1542 bytes transmitted on the wire.

The Preamble, SFD and Interframe Gap do not count as part of the frame. They are support structure for the Ethernet protocol itself.

The MTU applies to the payload -- it is the largest unit of data you can cram into the packet. Thus an ethernet packet with an MTU of 1500 bytes will actually be a 1522 byte frame, and 1542 bytes on the wire (assuming there's a vLAN tag).

So the answer to your question - What is the biggest packet I can send out over 802.3 ethernet without fragmentation? - is 1500 bytes of payload data.

HOWEVER the ethernet layer may not be your limiting factor. To discover if something along the way is restricting the MTU to be smaller than 1500 bytes of payload data use one of the following:

  • Windows: ping hostname -f -l sizeofdata (technique John K mentioned)
  • BSD: ping -D -s sizeofdata hostname
  • Linux: ping -M do -s sizeofdata hostname

The largest value of sizeofdata that works is the MTU (over the particular path your data is taking).

skohrs
  • 1,510
  • 11
  • 23
voretaq7
  • 79,345
  • 17
  • 128
  • 213
3

It depends on the amount of data you put in the frame. If you put 1500 bytes of data in a frame, your total frame size is going to be 1518 bytes. With 1472 bytes of data, you'll end up with a total frame size of 1500..

http://en.wikipedia.org/wiki/Ethernet_frame

That being said, if you're truly interested in testing fragmentation, a good way to test this is with a good old ping with a few flags:

ping hostname -f -l sizeofdata

The -f flag will cause the ping to fail if the packet is fragmented. The key to understand here is "sizeofdata" is the amount of data you can put in a message without fragmenting - so if you send a payload of 1500, you'll start fragmenting as you go over 1500 bytes. Turn that down to 1472 though (1500 - the 18 byte overhead), and you'll see the pings go through.

Univ426
  • 2,139
  • 14
  • 26
  • I'm sorry, 1542 bytes is way above the standard ethernet frame defined by IEEE 802.3. A untagged 1500-byte ethernet payload is 1518 bytes (not including the SFD / preable). An 802.1q-tagged frame is 1522 bytes (same caveats) – Mike Pennington Aug 28 '12 at 20:36
  • That's very confusing. MTU = 1500 but the frame size is 1542 ??? So MTU is just the payload, in other words, it is the frame size of 1542 minus the 42 extra stuff. Is that correct? – chrisapotek Aug 28 '12 at 20:39
  • Sorry, I typed that wrong - I just updated the answer, but if I'm still wrong, just let me know - this is the math that I remember :S – Univ426 Aug 28 '12 at 20:40
  • I'm sorry, I must be wrong - I thought I understood it but I clearly have my numbers off, it looks like its 1518 :S sorry about that – Univ426 Aug 28 '12 at 20:42
  • It is not you who are confused, but everyone. So my questions continues. What the heck is the difference between MTU and ethernet frame size? Is the payload 1500 or less? – chrisapotek Aug 28 '12 at 20:44
  • My understanding is the payload can be up to 1500 octets, which will give you a total frame size of 1518. I have no idea why I thought the total frame size was 1542. @MikePennington is correct, an 802.1q tagged frame has an additional 4 bytes for VLAN taggin – Univ426 Aug 28 '12 at 20:46
  • Where are the extra 18 bytes coming from for a payload of 1500? If I count the stuff in that wiki table, it gives me 42 extra bytes. Your mistake was the same mistake I was doing. We need to understand the logic behind this. – chrisapotek Aug 28 '12 at 20:50
  • Agreed, I'll leave this atrocity here for now, but yeah, I'm hoping someone else can answer it too - I'm just as confused. Again, my apologies for that. – Univ426 Aug 28 '12 at 20:53
0

For the basic Ethernet_II frame, the frame size is 1518 bytes (on or off the wire). This is made up of 6 bytes for each of the destination and source address, 2 bytes for the type field between 46 and 1500 bytes for the payload (in your case the entire IP packet with its IP header and UDP header) and 4 bytes for the FCS. In addition to this there is a restriction on how small a frame may be (64 bytes). This is why the range is from 46 bytes ( add this to the two addresses and the type and the FCS and you get 64 bytes - 46+6+6+2+4=64).

If the frame is on a network which supports multiple vlans and you need to tag the frame with a vlan tag, then one extra field is added before the type field. This is 4 bytes. This now means that the range of sizes for the payload can be reduced by 4 bytes at the bottom end and still have 64 bytes as a minimum. Hence the 42. (So 42+6+6+2+4 + 4 for the vlan tag = 64)

So when the range is written 1500-42 is does not mean 1500 minus 42, it means anything from 1500 to 42 bytes is valid. One the wire, this tagged frame could be as large as 1522 bytes ( if only one tag is used, or 1526 if two tags are used). None of this explains the number 1542.

To get to this number, you need to consider how a frame can be sent on Ethernet. There is no clock on an Ethernet LAN, so a series of 1's and 0's are sent by the transmitter of a frame to set a clock. This is called the preamble. Not every listener will 'hear' all of the preamble, but most should hear some part of it. To signal the end of the preamble, one of the last 8 bits sent is flipped so that instead of 10101010 it becomes 10101011. This byte is called the Start of Frame Delimiter (SDF). This is not technically useful to capture off the wire, so the 7 bytes of the preamble and the 1 byte SDF are normally not counted but if they were our original 1518 would now be 1526. Still not 1542..

After a frame has been sent, there is an enforced silence on the wire which is called the inter frame gap. This is equivalent to a transmission of 12 bytes. This is also not counted or capture but if it were it would get us to 1538 bytes. The only way to now get to 1542 from 1538 is to say that the frame is tagged (i.e. it does contain the 4 byte plan tag). Phew, 1542 at last.

It's all in the terminology. A standard frame is 1518 bytes on the wire (as far as any capturing device is concerned). A tagged frame (single tag) is 1522 bytes on the wire. These take up 1538 bytes or 1542 bytes of transmission space on the wire.

Hope that helps to clarify..

Joevpt
  • 1
-1

no you want fragmentation to occur this is why you get packet need to be fragmented but df set take it like this a 2 way highway with a whole bunch of semis vs the same highway with a whole bunch of small smart cars which are both going to the same destination semis carry more payload but are slower and can congest easier smaller cars carry less but travel faster MSS is not the same as MTU either

joseph
  • 1