Never seen used in the practice though. One of problems AFAIK - most switch default to dropping jumbo frames. You can enable but if you'll left one unconfigured for some reason you will get hard to diagnose problem. The same with end hosts - they (inside a given L2 domain) should have the same MTU and if you'll left a box with the default MTU you got a problem.
To make jumbo frames easier to use switches should forward them by default and hosts should accept frames large than MTA (but send MTU sized ones).
Jumbo frames are used constantly in practice, just not often on the internet. They're common in all sorts of networks, especially enterprise and storage.
If your switch is configured on defaults and not running a for purpose config, you probably don't need jumbo frames.
I've been terrified to enable jumbo frames because every guide I've read has always had "you have to make sure that every single machine you ever communicate with has to also have jumbo frames on or you will cause a black hole that sucks the whole earth into it!!" kind of disclaimers when I just want to lower the overhead in copying files from my NAS that has some pathetic Atom CPU in it.
If that's the case it's a shame we didn't take the chance with IPv6 to push to higher default MTUs since IPv6 already relies to a much higher degree on PMTUD since it lacks fragmentation.
the internet has a whole bunch of non ethernet stuff, a lot of which has different frame sizes. Its totally possible that backhaul is running jumbo frames, or something like it, but you'd never really know that.
Conversely ADSL has odd frame sizes(inherited from ATM; 48 bytes if I remember correctly), but you don't see that because its hidden from you. Cable has a frame sizes ranging from ~500 up to 2000 bytes. Again, hidden from you.
One of the joys of TCP/IP is that different frame sizes are handled for you. Sure it might be beneficial to have a frame size that marries up with packet size, it might not. you don't really know, because the internets.
The bottom line is that if you ever send an IP frame larger than 1500 bytes outside of your own network, it's most likely that it will never reach its destination. Especially for IPv6.
I wouldn't call them "frame sizes" for ATM or DSL. It's a bit of a transparent fragmentation into "cells" onto the "transport" layer. It could carry arbitrary "frame" sizes on that
It being a thing on "the internet" would require it being a thing on a sizable majority of the internet. You'd need to get large network operators, peering points, user-facing ISPs, and even users themselves on board to change their setups.
And Path MTU discovery is still sufficiently unreliable as to make it incredibly painful to have partial large-MTU networks.
And if you do any of this with standard home customers, a hellscape torrent of user complaints is going to rain down on your support contacts. Which costs money. More money than is lost by the higher cost of routing smaller packets.
So, no, jumbo frames could not be a thing on the internet. There's a reason it's called fossilization. There is no technical reason precluding changing this, it's just frozen into way too many places to be changed.
This the same argument why IPv6 can't be a thing on the internet; I agree that the book isn't closed entirely on that yet, but very significant progress has been made.
Except disruptions (i.e. worse service than IPv4 only) from rolling out IPv6 are the exception while disruptions from rolling out jumbo frames are absolutely the norm.
I thought frame size negotiation was an optional part of LLDP now. I suspect it fits into the broad category of things that could be well-defined if there was broad adoption of a poorly adopted standard.
Just to be picky the correct term is data gram, which describes layer 2 segmentation. Packets describe segmentation between switches, which is layer 3.
If you want to be picky, you need to get it right first. The actual term is frame. datagram is generally used to refer to layer 4 operation, and the term is not used anywhere in IEEE 802.3.
Also the GP is correct to say we fossilized on 1500 byte packets, since the layer 3 MTU is the relevant thing when talking about fossilization in the internet at large. This number was driven by 802.3's standard frame size being 1514 bytes, but that one is not even fossilized as much. It takes work, but you can control your own network and roll out jumbo frames. You can't roll out larger packets on the internet.
> You can't roll out larger packets on the internet.
Devil's advocate: why not? We're in the middle of a long-term push for IPv6, and we have interim solutions to help the migration like Teredo tunneling. It's slow going, but we'll get there eventually.
Why don't we start a similar global migration to jumbo frames?
What's the backwards compatibility story here? Send out dual 1500/9000 packets? I don't see how that would work for the billions of devices in the wild without replacing everything but maybe there's a better solution that doesn't take 30 years.
IPv6 also required hardware in the wild to be replaced, but that's not a reason to give up and let things ossify. Over the next 30 years most hardware will be landfilled and replaced anyway. Let's get these improvements into the software stack of new devices now, and then let nature take its course.
> IPv6 also required hardware in the wild to be replaced
I understand that, but it was (is) able to do that in a mostly backwards compatible manner.
My question is: how is that possible with different MTU sizes? Have ISPs support 9000 byte frames and fragment to 1500 bytes for compatibility with the wider internet? Then something like PMTUD can be used to bypass this fragmentation when supported?
To be clear, I would love to have larger MTU sizes. I just don't see a straightforward way to transition everything over. I'm not a network engineer though, maybe there just isn't enough a strong enough impetus for anyone to dedicate the resources to this.
Also not a network engineer. But I'd imagine first the Tier 1 ISPs (Level 3 etc) could enable jumbo frames and make sure they work smoothly amongst each other. After a few years of waiting, new consumer devices/OSs can start trying to send jumbo frames, while setting the Don't Fragment flag. If some router in the path doesn't support 9000, it will signal back ICMP Fragmentation Needed, and the device can transparently resend with 1500. Then add some local caching to avoid the roundtrip for subsequent connections to the same noncompliant network/endpoint.
And since it's a big change anyway, why stop at 9000? Why not 65000? Packets don't have to fill the entire MTU after all. If 65000 is supported, you can choose to send 1500, 9000, or 65000 based on your desired latency/throughput tradeoff.
I'm pretty sure a switch is just an L2 bridge but still uses the ethernet address management mechanism (mac addresses) not the L3 IP (or whatever) address / routing mechanisms.
Modern ethernet, on wires anyhow, is very different from the original one with a shared broadcast domain. Ironically, wireless networks are still very much like the original "you've got a piece of wire and everyone yells into it after listening for a short period of time" mechanism.
> Ironically, wireless networks are still very much like the original "you've got a piece of wire and everyone yells into it after listening for a short period of time" mechanism.
Maybe not that ironically since Ethernet derives from ALOHANet, the wireless network connecting Hawaiian schools. Early Ethernet was basically ALOHANet piped over a wire instead of radio waves just like cable tv for a while was just broadcast TV over wires instead of radio waves. https://en.wikipedia.org/wiki/ALOHAnet
Well, the "OSI" model where there's a little disassembly and assembly line in your box, where each layer gets taken off by one robot and the payload of that inside package gets handed off to another concern -- all lies.
The chips that do this (if they've got the features, anyhow) do L2, L3, L4, L5, etc all at the same time. So it's not an L2 switch and L3 router -- it's both at the same time, looking at the whole packet at once.
But -- there is no such thing as an ethernet "router" -- it's just a bridge with a forwarding table populated (usually) by listening for MAC addresses and updating forwarding tables. "flood and learn" There are even less ethernetty things out there that use the ethernet signaling but mechanically populate the forwarding tables of switches.
But a "thing that forwards between vlans" usually means "a thing that forwards packets from one L3 subnet to another."
You could probably make some insane custom switch that has routing rules for forwarding mac address packets from one vlan to another based on a bunch of zany rules, but such a cursed object would be hated universally by all who come after you.
Yeah, what's with that? I looked into enabling jumbo frames on my home network (just for fun, I don't really need it) and it seemed horrendous as those packets could end up on the internet and probably wouldn't work.
Yeah, we can compensate for that with hardware, but it's ridiculous to do 100G or even 10G in 1500 byte chunks.