There is an important distinction that needs to be made here. Traffic that flows out of a DSL connection changes form a few times along the way. When it leaves your computer, travels through your network and hits the modem, it is Ethernet traffic. Most consumer grade equipment defaults to 1500 and the modem your ISP sends you is also probably defaulted at 1500. If you were to change the MTU, ALL interfaces between your PC NIC and the modem (including the modem) would need to be changed.
Once it leaves the modem, it is officially on the ISP network and is running as ATM traffic. This interface, and the rest of the path, you will have no control over. ATM traffic runs at a different MTU typically, but it depends on the equipment and the network. For example, cisco ATM equipment runs at 4470. An ISP network's ATM cloud may consist of Juniper, Cisco, Alcatel, Nortel, Fujitsu, Adtran or any of many other vendors. It may also interface with other provider's networks and their equipment. In other words, you have no way of knowing what will happen to packets once they leave the prem - and your ISP may not even have an idea of the entire journey of a packet either.
Once it reaches the other side and becomes Ethernet again, the MTU on the other network will then be a factor. If you don't know anything about the network you're sending to, it is best to assume it is 1500.
Also, ATMs most likely will not be set to block fragmented packets. All that will happen if a packet too large for the interface's MTU comes through is that the packet will be broken down in to smaller chunks and passed on. This may not be the case with the network at the other end.
If you send packets that are equal to or lower than the Maximum MTU on the chain, they'll get through without a problem. If you send higher, there is a chance they'll fragment or even be discarded.
What it comes down to is that you really should be aware of the MTU across the entire path if you are going to use anything higher than 1500, otherwise it is safest to just default to 1500.
UDP datagrams have little to do with the MTU size you can make them as big as you like up to the 64K is maximum mentioned above. You can even send one of them in an entire packet as long as you are using jumbo frames with a size larger the large datagram.
However jumbo frames have to be supported by all the equipment the frame will pass over and this a problem. For practical purposes Ethernet frames are the most common tranport size, the MTU for these is circa 1500 bytes, I will say 1500 going forward, but it isn't always. When you create a UDP datagram larger than the underlying MTU (which as indicated is most often be ethernet) then it will be quietly be broken up into a number of 1500 byte frames. If you tcpdump this traffic you will see a number of packets broken at MTU boundary which will have the more fragments flag set along with a fragment number. The first packet will have a fragment number of 0 and the more fragments set and the last one will have a non-zero fragment number and more fragments not set.
So why care? The implementation detail actually matters. Fragmentation can hurt performance in the network not a big issue anymore but one to be aware of. If a huge datagram size it used then should any fragment be lost the whole datagrams will need to be resent. Equally at high volumes and today these are perfectly achievable volumes then mis-association of frames at reassembly is possible. There can also be problems getting fragmented UDP packets to traverse enterprise firewall configurations where load balancers spread the packets out, if one fragment is on one firewall and the other on a different one then the traffic will get dropped as incomplete.
So don't create UDP datagrams bigger than the MTU size fragmentation unless you have to and if you have to specify that the infrastructure being communicated between is close (same subnet close) at which point jumbo frames would likely be a good option.
Best Answer
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 BytesThe 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 BytesThe 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 BytesFinally 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:
ping hostname -f -l sizeofdata
(technique John K mentioned)ping -D -s sizeofdata hostname
ping -M do -s sizeofdata hostname
The largest value of
sizeofdata
that works is the MTU (over the particular path your data is taking).