13

So basically do the modern routers in the internet still use 1500 as the MTU of Ethernet? or the 1500 Byte was for the old days?

What I'm asking here is what is the MTU of Ethernet in modern Networks?

and if it is 1500 bytes, what will happen if we for example use 15000 bytes instead and what will happen to the Internet if we force all the routers to use 15000 bytes instead?

John P
  • 531
  • 5
  • 17
  • Highest MTU on Cisco equipment is 9216 bytes. The internet is typically running 1500 bytes. You can't control what the internet has set. If you send 15000 bytes packets they will simply be segmented into 1500 bytes packets and reassembled on the other end. If you want to change MTU on your LAN, remember it should be done on every device on your network otherwise you could experience problems. –  Jul 16 '18 at 11:57
  • @Cown but with all the developments in technology why the MTU of ethernet in the internet is still usually 1500? what will happen if they set the MTU to a higher number like 30k? (what would be the downside of increasing the MTU?) – John P Jul 16 '18 at 11:59
  • IPv4 routers fragment on behalf of the source node that is sending a larger packet. Routers can fragment IPv4 packets unless the Do-Not-Fragment (DF) bit is set to 1 in the IPv4 header. If the DF bit is set to 0 (default), the router splits the packet that is too large to fit into the outgoing interface and send the two packets toward the destination. When the destination receives the two fragments, then the destination's protocol stack must perform reassembly of the fragments before processing the Protocol Data Unit (PDU). –  Jul 16 '18 at 12:05
  • The primary concern with having the routers performing fragmentation on behalf of the source is the added CPU processing overhead on the router. If IPsec is being used, then the routers on both ends of the tunnel will need to handle the fragmentation and reassembly of the packets. –  Jul 16 '18 at 12:06
  • 2
    Oh and i've never heard of an MTU size of 30k. –  Jul 16 '18 at 12:07
  • 1
    @Cown. ehm... "and reassembly of the packets". That would never be a router's task. That's up to the end host, tunneling involved or not. – Marc 'netztier' Luethi Jul 16 '18 at 12:14
  • 2
    @Marc'netztier'Luethi you should read up about this command: ip virtual reassembly (router will reassemble fragments) – Mike Pennington Jul 16 '18 at 13:45
  • @MikePennington why would a router reassemble a packet? i assume you mean when the destination is the router itself and the packet was fragmented, but what type of packet has the destination of a router and is large enough to be fragmented? can you elaborate and give some examples? thanks – John P Jul 16 '18 at 14:23
  • 2
    Router reassembly is very common in pppoe and firewall configurations. https://supportforums.cisco.com/t5/wan-routing-and-switching/purpose-of-ip-virtual-assembly/td-p/1189229 – Mike Pennington Jul 16 '18 at 14:28
  • @MikePennington but it only happens when the destination is the router itself correct? – John P Jul 16 '18 at 14:29
  • 2
    I stand corrected. Reassembly may happen on routers. – Marc 'netztier' Luethi Jul 16 '18 at 14:56
  • 1
    Because fragments other than the first fragment don't contain the L4 headers. Therefore any firewall that wants to apply L4 rules and any NAT that wants to perform port translation needs to keep track of which fragments go together, hold out of order fragments until the first fragment arrives, handle headers that cross fragment boundries and so-on. A firewall could do that without actually reassembling the packet but given that it has done most of the work of reasembly the firewall may as well finish the job. – Peter Green Jul 16 '18 at 20:56
  • Routers can't fragment packets at a very high rate, so if your traffic requires fragmentation you're likely to see lots of drops, causing lower throughput. Routers fragment on a "best effort" basis. It's usually done in the CPU and not on the fast path, and implementations intentionally throttle this traffic to avoid overloading the CPU. Best to avoid it! – Jeff Learman Dec 17 '20 at 20:25
  • Hardware I've coded, such as Broadcom DNX, Intel Castine, EZChip, and proprietary network processors, have 16-bit fields for packet size internally, so don't expect anything to support over 16K byte frame size, any time soon. – Jeff Learman Dec 17 '20 at 20:29

2 Answers2

20

Standard maximum payload size for Ethernet is still 1500 bytes.

While the maximum frame size has grown slightly, from 1518 to 1522 byte with 802.1Q and further with 802.1AD, the payload, "MAC client data" size, or Maximum Service Data Unit (MSDU) hasn't been changed as per IEEE standards for compatibility reasons - maintaining the payload size enables transparent switching within the whole range from 10 Mbit/s up to 400 Gbit/s.

In Ethernet, there is no concept for negotiating a frame size nor for fragmenting a frame oversized for forwarding nor for providing an error message to the sender, so the frame can only be dropped. Each node in a segment needs to use the same MTU.

However, "jumbo" frames exceeding this maximum have been popular for a while in closed, controlled networks. The network administrator has to make sure that all nodes on a network can handle the non-standard size before actually using that frame size. Very common is a payload size of 9000 bytes, six times the official size.

There are also "baby giant" implementations where a tunnel's outside MTU is increased somewhat to enable encapsulation of full-sized packets without eating into the inside MTU (or for similar reasons).

On the Internet the requirement is just a minimum link MTU of 68 bytes for IPv4 and 1280 bytes for IPv6. Note that while large parts of the Internet use Ethernet nowadays, not all do.

If you pass an IPv4 packet larger than 1500 bytes to your Internet router it should fragment it according to its uplink MTU. Without fragmentation, the next hop router will likely just drop the packet. For IPv6, there's no router fragmentation and path MTU discovery is mandatory, so your client should never send a packet exceeding the destination path's MTU.

Zac67
  • 84,333
  • 4
  • 69
  • 133
  • 2
    Jumbo frames are especially useful when dumping large amounts of data from device to device in a UDP manner. The decrease in overhead by having more data per packet is significant enough to be worth it at times and I've seen it in use for such in data-heavy environments. – Mast Jul 16 '18 at 18:51
  • 2
    Jumbo frames are more significant for reducing the processing overhead - or rather were, the overhead has been significantly reduced by offloading features since. By bandwith, UDP throughput increases by just 3.7% (1.5k vs 9k). – Zac67 Jul 16 '18 at 19:32
  • Wouldn't that be "grown slightly, from 1514 to 1518 bytes with 802.1Q VLAN and further with 802.1AD"? (MTU of 1500 + 14 byte Ethernet header (excluding preamble)) – Jonathon Reinhart Sep 10 '19 at 18:01
  • @JonathonReinhart The FCS is part of the frame as well, so that's 18 bytes overhead for L2 (22 for 802.1Q, ...). – Zac67 Sep 10 '19 at 18:09
6

The ethernet (IEEE 802.3) standard is still 1500 octets for the MTU, but some vendors support jumbo frames. Unfortunately, there is no standard for jumbo frames, and different vendors support different sizes for a jumbo MTU, even across the product line, or sometimes even different sizes for a jumbo MTU on different interfaces in the same switch.

If you try to send a jumbo frame, and it encounters an interface anywhere along its switched path with a smaller MTU, it will be dropped as a giant frame, and it will simply be lost. Switches do not fragment frames. Routers may fragment packets to fit an MTU on a different interface, but switches do not fragment frames because ethernet has no facility for fragmentation. Even with routers fragmenting packets, most businesses are now dropping fragmented packets to prevent fragment DoS attacks. Fragmentation is expensive to router resources, and IPv6 has eliminated fragmentation in the path, requiring hosts to use PMTUD to discover the minimum MTU in a path, and to pre-fragment packets before sending.

Ron Maupin
  • 99,565
  • 26
  • 120
  • 195