Rich Lafferty's LiveJournal (mendel) wrote in lj_userdoc,
Rich Lafferty's LiveJournal

Better hints re MTU problems?

FAQ 165 reads in part (well, "in most"):

If you can update with smaller entries, but not long ones, there is most likely a problem with your computer's MTU (maximum transmission unit) limit. This is most commonly found when your computer is set up to share an Internet connection with another computer in the house, or if you have a firewall on your computer.

LiveJournal can't help you resolve the problem; you will need to contact your network administrator or consult your operating system's help files.
I think we can be more helpful and clearer there. How about something along the lines of
If you can update with smaller entries, but not long ones, your computer's MTU (Maximum Transmission Unit, the maximum amount of data that can be sent in one packet over your network) may be set too high. This situation is most commonly found when your computer is set up to share an Internet connection with another computer in the house, or if you connect to your Internet provider over PPPoE (PPP over Ethernet, common on ADSL connections).

LiveJournal can't help you resolve the problem; if you cannot resolve it yourself you will need to contact your Internet service provider or network administrator, or consult the documentation for your operating system.
The problem, essentially, is roughly this: The client computer has an MTU of, say, 1500. That travels fine over Ethernet, but if they are using something that has to encapsulate the packets -- say, PPPoE or a VPN -- then they can creep larger than 1500 bytes. When that happens, the next hop has to fragment the packets, which slows things down, sometimes even noticeably. But that's the good scenario -- in the bad (and most common) scenario, the packets get set with the Don't Fragment (DF) bit set. Then the next hop receives them, sees they're too large to send unfragmented, sees it can't fragment them, and just discards them. That hop thus acts as (and is called) a "black hole route".

Too low an MTU cannot cause the problem the FAQ describes, (although it can slow things down itself because of packet reassembly overhead), and users won't necessarily grasp what values are canonically problematic and which are sensible for their situation, so "lower" is an important hint.

I can't think of a scenario where a firewall, software or black-box, could introduce MTU problems without also encapsulating, so I replace the firewall reference with a PPPoE reference, which is the most common scenario for MTU problems.

Other changes: mention ISP before network administrator, since people will probably encounter this at home rather than in an office or school, and include those operating systems that don't have "help files". :-)

I would also really, really recommend linking to the dslreports FAQ on MTU tuning, since it provides step-by-step instructions on how to set your MTU. I realize external links are rare (but not nonexistent) in the FAQ, but there's a lot of dumb advice on the Web about MTU settings, and the dslreports FAQ is one exception to that.


  • FAQ232

    There is a typo (or two) in FAQ232. I'm talking about the following sentence: Ddd them to your Friends list them with the Add Friend button at…

  • New FAQ: How do I deal with spam?

    This FAQ is meant to tie together all of our spam-related information, currently spread over several different categories. Ideally, I'd like to have…

  • Identity Account FAQs

    As LiveJournal Support regularly uses the term identity accounts both in answers to users and amongst themselves, and some system pages refer to…

  • Post a new comment


    Comments allowed for members only

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded