0

A client of mine has an organizational network that is comprised of a lot of Ubiquity gear, primarily switches and wireless routers to power their network, with a Sophos XG firewall at the border.

Every once in a while, on the network we provide for 'guest' / 'partner' access, we have someone come in with a laptop that is having problems with 'network speed' and it being slow or nonresponsive for them while connected. This is on an isolated VLAN from the rest of the corporate network and runs on a separate line. This VLAN lives only on the switch and the Router, and we have NUMEROUS devices that work fine, but every once in a while have someone coming by with an issue.

The IT people at this client's site have a tendency to say "Oh, the system is using MTU 1500, this is causing packet fragmentation, you SHOULD be using 1492 instead of 1500." and then say "that's the only way to fix this problem."

My understanding of networking infrastructure (as a network security and design person by trade) and my knowledge of how networks work at the system levels is that the MTU of 1500 is NOT usually the leading cause of network speed / instability problems on wifi networks, because the MTU is the max packet size not the max payload size and the various systems' network stacks should be fragmenting packets which have a payload size that, with packet size overhead, would produce a packet larger than 1500, and in turn would fragment the packets. And that the system sees an MTU of 1500 and has a different thing - an MSS - for determining how to fragment packets based on payload size.

I'm fairly certain that changing the MTU should be the LAST thing that a helpdesk or general support staff should be doing, and instead additional tests on configurations, etc. on the system itself should come first.

Is my knowledge in this correct, or am I confused? It's my understanding that 1500 is the default MTU on every off-the-shelf network device, and should NOT be assumed to be the sole/only cause of issues and probably should NOT be the first thing that IT support staff point fingers at as the problem.

Improve this question
3
  • 1
    "1492" is an old PPPoE/DSL hack. (because ATM cells carry 53bytes - AAL5 eats 5) If their laptops are set with a ethernet MTU of 1492, that's a mess of their own making. Messing with the MTU anywhere but the PPPoE router is a mistake. (PMTUd makes it unnecessary.)
    – Ricky
    Commented Jun 21, 2023 at 20:08
  • @Ricky and if PPPoE isn't actually at play here (read: modern ethernet network, no PPPoE, just a fiber line into an ONT that converts fiber to copper/ethernet, and 1500 standard MTU when you DHCP on the fiber line), there shouldn't be a need to change MTU anyways for the "old PPPoE/DSL hacks"
    – Thomas Ward
    Commented Jun 25, 2023 at 21:38
  • 1
    Correct. And you would only change it at the router / interface where necessary. If they continue to push this, ask them how to change the MTU of an iPhone? Or the printers? Or the IP speakers in the conference room? For every windows laptop that can be changed, there's a 100 things that can't. (and half of them you don't even remember are there.)
    – Ricky
    Commented Jun 26, 2023 at 22:32

2 Answers 2

Reset to default
2

It's impossible to comment specifically without knowing the specific equipment and connections and configuration in use in the network in question.

The mention of MTU 1492 indicates likely use of PPPoE or similar encapsulation on at least part of the network. I would assume they mean that the internet service gateway equipment requires the MTU to be set to 1492 to accommodate the use of PPPoE on the internet service. That should be done only on the router/gateway device (on the WAN interface) and not on any of the LAN or wireless devices unless there is some kind of extremely unusual bridged WAN service that requires PPPoE but does not provide a routed gateway design at the WAN/LAN boundary.

Since fragmentation happens at layer 3 (routing) boundaries, the MTU can be left standard on the majority of the LAN even if the WAN interface requires a different MTU to accommodate PPPoE or something similar.

If they are saying all LAN devices require the MTU to be set to 1492 then there is likely a misconfiguration of some equipment in the LAN that is causing that requirement. That or some equipment with very uncommon features. The standard 1500 byte MTU should be fine for the huge majority of modern Ethernet LAN deployments.

Improve this answer
6
  • The primary culprit machines are past-8-years Linux endpoints and some Mac systems, but they are primarily saying "No, we have to edit all endpoint clients to use 1492 in order to make sure it doesn't fragment". They don't quote any logical technical reason for doing this, and outside of very specific setups this shouldn't be the case. The network is designed by me as a consultant for the company - they asked me over 5 years ago to come in and redesign the network, as such i'm the "network admin" now on contract, and their management asked me to check the IT guys' processes.
    – Thomas Ward
    Commented Jun 21, 2023 at 0:40
  • If there is no logical reason for modern Ethernet LAN deployments (the VLAN part is on a switch and carried to the XG firewall as tagged on a trunk port, but I would ASSUME the trunk's max frame size as the default of the switch, etc. wouldn't impact that as much), then I can safely say that there is no logical reason for these staff members to go and change the MTU as a first-and-foremost step. Incorrect knowledge is incorrect, so having a sanity check here is sane. Everything is set up with modern 1500 MTU defaults across-network, and no PPPoE exists, just pure Ethernet/VLANs.
    – Thomas Ward
    Commented Jun 21, 2023 at 0:41
  • 1
    Yup, that is 'cargo cult' IT behavior. Someone saw it fix a specific problem once so they think doing it all the time will prevent or solve other issues. Like people who insist on manually setting speed and duplex on everything despite it clearly causing problems.
    – FrameHowitzer
    Commented Jun 21, 2023 at 14:52
  • I'm just glad I get paid more than the support guy who started the trend. whistles nonchalantly as he writes up his report to C-level executives and waits for the bag of bricks to drop
    – Thomas Ward
    Commented Jun 21, 2023 at 16:43
  • 1
    If they're paying you for your networking expertise, then tell them they're full of s***. "Are you going to listen to the professional paid to know this stuff, or the idiot who made this mess in the first place?" Ethernet MTU is something EVERY node MUST agree on, and there's NO WAY to negotiate it. L2 DOES NOT fragment. Send a frame larger than the MTU, and it'll disappear - the driver will never even get a chance to see it.
    – Ricky
    Commented Jun 21, 2023 at 20:13
1

I'm fairly certain that changing the MTU should be the LAST thing that a helpdesk or general support staff should be doing, and instead additional tests on configurations, etc. on the system itself should come first.

Most definitely. Changing an end system's MTU should definitively be only the last straw.

If there is a reduced MTU link somewhere in the path (and if PPPoE is in the game chances are high that there is), then make sure...

... on the network, from end system to router/gateway

  • full support for Packets/Frames with a L3 payload size of 1500 on all links.

... on the router/gateway which has the reduced MTU link attached:

  • respects the don't fragment bit set in packets travelling through (in extenso: does not do "df-bit ignore")
  • sends ICMP unreachable, Fragmentation Needed messages (Type 3, Code 4) for packets too large to fit into the reduced MTU link.
  • Network path from router/gateway back to end system does not block the ICMP Type3/Code4 messages, like an unexpected NAT box in the path, for example.
  • performs TCP MSS clamping (Cisco speak: "ip tcp adjust-mss") to an appropriate value (e.g. 1452 for an 1492 MTU link), if possible in both directions.
  • (rather exotic) check if the given DHCP service for the subnet/VLAN does make use of option 26 (MTU) and pushes this option to the DHCP clients, and what value is in there (1500 or 1492).

... on the end systems (although the details and how-tos of this will be off-topic to this board):

  • Investigate if some/all end devices ingest and process DHCP option 26 (MTU) or if some of them ignore it. This is the exotic case, applies only if DHCP option 26 is present at all.
  • Investigate if the given end system IP stack supports PathMTUDiscovery and if it is enabled (i.e. if the IP stack actually ingests and processes the fragmentation needed messages)
  • Check if the device's 'security features' (as in "host based firewall") prevent ingestion of fragmentation needed messages because some 'security admin' ruled that "ICMP unreachables are bad, m'kay?", resulting in broken PathMTUDiscovery support.

Although this is speculative, the symptoms you describe might be caused by something along these lines:

  • Router/Gateway does support PathMTUd, and does send Fragmentation Needed Messages (ICMP Type3/Code 4) for packets too large for the reduced MTU link.
  • Router/Gateway does not perform TCP MSS clamping.
  • Most end systems ingest and process the MTU suggestion in the ICMP Type3/Code4 messages correctly. They don't have to rely on MSS clamping.
  • Few systems won't/can't receive or process ICMP Type3/Code4 correctly and would have to rely on TCP MSS clamping - which might not be running.

The true solution of course would be to have proper PathMTUd support on both Router/GW and end systems. The locally-optimal solution might be to implement TCP MSS clamping correctly.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.