It's only a pity that things fossilized on 1500 byte packets.
Yeah, we can compensate for that with hardware, but it's ridiculous to do 100G or even 10G in 1500 byte chunks.
Yeah, we can compensate for that with hardware, but it's ridiculous to do 100G or even 10G in 1500 byte chunks.
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.
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.
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.
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).
If your switch is configured on defaults and not running a for purpose config, you probably don't need jumbo frames.
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.
I have layer 3 switches doing eBGP.
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.
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
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.
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?
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.
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.
https://en.m.wikipedia.org/wiki/Ethernet_frame
Also, while we are being picky, datagram is one word not two.
There's fragmentation, but that's separate from NAT and often broken.