Difference between revisions of "MTU Changing default in Linux and Windows"

From Free Knowledge Base- The DUCK Project: information for everyone
Jump to: navigation, search
m
 
Line 243: Line 243:
  
 
[[Category:Computer_Technology]]
 
[[Category:Computer_Technology]]
 +
[[Category:Linux]]
 +
[[Category:Microsoft]]

Latest revision as of 20:43, 24 June 2007

( MTU ) - IP MASQ seems to be working fine but some sites don't work. This usually happens with WWW and some FTP sites.

Depending on what Linux kernel version you are running on the MASQ server, some will people disagree on the real problem. The two following arguments have valid points, are inter-related, and users from each camp continue to debate this to this day.

  • With modern 2.4.x Linux systems, most users point their finger at the adminstrators of these remote broken sites (typically SSL-encrypted WWW sites, etc.) or your MASQ server's upstream router run by your ISP. The main though it that these machines are either filtering or not properly responding to SOME or ALL FORMS of ICMP packets (specifically ICMP Code 3 Type 4 - Fragmentation Needed) messages due to a fray of misplaced security paranoia.

What does that all mean? Basically, say your machine is connected to the Internet with a MTU of 1492 bytes (Maximum Transmission Unit -- the maximum packet size your computer can transmit) which is common for PPPoE users. At the same time, the remote WWW/FTP site is connected to the Internet at a MTU of 1500 bytes. The way that TCP/IP works is that when a TCP connection is being negotiated for your HTTP / FTP connection, the remote side will try to verify that a 1500 byte packet can reach your computer via the initial TCP "SYN" packet.

Since the packet is too big for your connection, your upstream router (run by your ISP) will send a ICMP 3:4 (fragmentation needed) packet back to the remote WWW / FTP server. Within this packet is a recommended smaller MTU size to retry with. The problem is that either your local upstream router, some router between you and the remote server, or the remote HTTP / FTP server is either misconfigured or has a firewall in front of it that is BLOCKing these ICMP packets.

  • The final UNCOMMON possibility is a debatable 2.0 / 2.2 kernel bug in the IPMASQ code. Some users point their finger to the fact that IPMASQ might have problems with ICMP packets that have the DF or "Don't Fragment" bit set. Basically, when a MASQ box connects to the Internet with an MTU of anything less than 1500, some packets will have the DF field set. Though changing the MTU of the MASQ server's Internet link to 1500 seemingly fixes the problem, the possible bug is still there. What is believed to be happening in these older kernels is that the MASQ code is not properly re-writing the return IP addresses of the ICMP 3 Sub 4 code packets back to the originating MASQed computer. Because of this, these critical packets get dropped.

No worries though. A there are several perfectly good ways to fix this nasty MTU problem:

  • Enable PMTU clamping in PPPoE
This solution is mostly for modern 2.4.x and 2.2.x kernel users connected to the Internet via a PPPoE DSL or Cablemodem connections. This solution allows for changes to be done ONLY on the MASQ server itself and not on all of the internal MASQ clients.
  • Enable PMTU clamping via IPTABLES
This solution is only modern 2.4.x kernel users connected via ANY type of Internet connection. This solution allows for changes to be done ONLY on the MASQ server itself and not on all of the internal MASQ clients.
  • Change your MASQ server's Internet Link MTU
This solution will work for any Linux kernel version but is is NOT a solution if you have a PPPoE connection for DSL/Cablemodem users.
It should be noted that some users will balk at this solution because it can hurt some latency specific programs like TELNET and Internet games but the impact is only slight. On the other hand, most HTTP and FTP traffic will SPEED UP!
  • Change the MTU of all internal MASQed machines
This solution requires the most work as you have to make minor changes to ALL of the internal IPMASQed machines. Basically, you would be changing the MTU on all of the internal machines to match the MTU of your MASQ server's Internet connection. Fortunately, this solution is usually bulletproof where as some of the other solutions mentioned in this section might rarely not work.

Enabling PMTU Clamping for PPPoE and some PPP Users:

For those users who use PPPoE clients for (DSL / Cablemodem) or PPP (Dialup), your Internet connection is NOT "eth0" (for example) but usually "ppp0". In addition to this, your Internet link's MTU or Maximum Transmission Unit (largest packet you can transmit over the Internet) isn't 1500 bytes but 1492. The 1492 byte MTU comes from the link size of Ethernet (1518 bytes) - Ethernet MAC overhead (18) = 1500. Then you subtract the PPPoE header (8 bytes) == MTU of 1492. This overhead isn't a big deal but sometimes ISPs or remote Internet sites do stupid things to break PPPoE or non-1500 byte MTU connected machines.

You can find more info about this topic on the web. Specifically, here is good presentaion on the topic: mss-talk presentation (PDF). Here is the entire Write up and other good info

To enable clamping in both the RP or PPPd PPPoE clients, add the following line to your /etc/ppp/pppoe.conf file: 

 # - If you have a computer acting as a gateway for a LAN, choose "1412".
 #   The setting of 1412 is safe for either setup, but uses slightly more
 #   CPU power.
 #
 CLAMPMSS=1412

Clamping the MSS via IPTABLES:

As mentioned above for PPPoE users, some ISPs and WWW sites filter critical ICMP packets like MTU Path Discovery. Because of this, many users might find more Internet sites work but others hang or work poorly. Fortunately, recent IPTABLES have added PMTU Clamping support which should help you. If your using IPTABLES and think you're hitting this issue, try adding the following line to the end of your rc.firewall-iptables ruleset. It should be noted that there is no PMTU clamping support in IPCHAINS. 

iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

If this line causes an error when you re-run the rc.firewall-iptables* firewall rulesets, you might need to upgrade your version of IPTABLES which includes the "TCPMSS" IPTABLES module. 7.15.3. Changing the External MTU of the MASQ server:

This solution usually only applies to DIALUP users since PPPoE users cannot INCREASE their MTU because of PPPoE's header overhead.

To use this solution, first see what your current MTU for your Internet link is. To do so, run "/bin/ifconfig" on the MASQ server. Look at the lines that corresponds to your Internet connection and look for the MTU (for example, ppp0). This NEEDs to be set to 1500. Usually, Ethernet links will default to 1500 for Ethernet but serial / DIALUP modem PPP links might default to 576.

  • To change the MTU on a standard Ethernet link to your bridged or routed DSL, Cablemodem, etc. connection, you need to edit the correct network startup scripts for your Linux distribution. Please see the TrinityOS - Section 16 document for network optimizations.
  • To change the MTU issue on a PPP (not PPPoE) Internet link, edit your "/etc/ppp/options" file and towards the top, add the following text on two seperate lines, add: 
  mtu 1500
  mru 1500

Save these new changes and then restart PPP. Like shown above, verify that your PPP link has the correct MTU and MTU.

CUA Users: Lastly, though this isn't a common problem, some Linux 2.0.x kernel users have found a MTU solution to the following problem. With PPP users, verify what port is your PPPd code connecting to. Is it a /dev/cua* port or a /dev/ttyS* port? It NEEDS to be a /dev/ttyS* port as the /dev/cua* device ststem has been deprecated and it breaks some things in very odd ways.

Changing the MTU of various operating systems:

If you reconfigure ALL of your MASQed PCs to use the SAME MTU as your external Internet link's MTU (for example, 1492 for PPPoE users), everything should work fine and this method is sometimes the MOST EFFECTIVE way of fixing things. This is including ALL of the solutions mentioned above. But doing things this way can be a lot of work if there are lots of internal MASQed machines or be even impossible to do if you don't have administrative access to all the internal MASQed machines.

Follow these simple steps for your respective operating system:

The follow examples utilize an MTU of 1492 for typical PPPoE connections for some DSL and Cablemodem users. It is recommended to use the HIGHEST values possible for all connections that are 128Kb/s and faster. It should be noted that some PPPoE ISPs might require an MTU setting of 1460 (not 1492) for proper connectivity due to additional overhead in the ISP's internal network.

The only real reason to use smaller MTUs than 1492 or 1460 is to lower your Internet link's latency but at the cost of throughput. Please see http://www.ecst.csuchico.edu/~dranch/PPP/ppp-performance.html#mtu for more details on this topic.

If you know how to make similar changes like these to other OSes like OS/2, MacOS, etc. please email David Ranch so it can be included in the HOWTO.

Changing the MTU on Linux:

1. The setting of MTU can vary from Linux distribution to distribution. 

  For Redhat: You need to edit the various "ifconfig" statements in 
              the /sbin/ifup script

  For Slackware: You need to edit the various "ifconfig" statements in 
                 the /etc/rc.d/rc1.inet

2. Here is one good, any-distribution-will-work example, edit the /etc/rc.d/rc.local file and put the following at the END of the file: 

       echo "Changing the MTU of ETH0"
       /sbin/ifconfig eth0 mtu 1492
Replace "eth0" with the interface name that is the machine's upstream connection which is connected to the Internet.

3. For advanced options like "TCP Receive Windows" and such, detailed examples on how to edit the respective networking scripts for your specific Linux distro, etc., please see Chapter 16 of

Changing the MTU on MS Windows 2000

1. Making ANY changes to the Registry is inheritantly risky but with a backup copy, you should be safe. Proceed at your 

  OWN RISK.

2. Goto Start-->Run-->RegEdit

3. Registry-->Export Registry File-->Save a copy of your registry to a reliable place

4. Navigate down to the key: 

  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<ID for Adapter>
Each ID Adapter has default keys for DNS, TCP/IP address, Default Gateway, subnet mask, etc. Find the key one that is for your network card.

5. Create the following Entry: 

     type=DWORD
     name="MTU"				(Do NOT include the quotes)
     value=1492 (Decimal)      (Do NOT include the text "(Decimal)")


      • If you know how to also change the MSS, TCP Window Size, and the
      • TTL parameters in NT 2000, please email dranch@trinnet.net as I
      • would love to add it to the HOWTO.

5. Reboot to let the changes take effect.

Changing the MTU on MS Windows NT 4.x

1. Making ANY changes to the Registry is inheritantly risky but with a backup copy, you should be safe. Proceed at your OWN RISK.

2. Goto Start-->Run-->RegEdit

3. Registry-->Export Registry File-->Save a copy of your registry to a reliable place

4. Create the following keys in the Registry trees, choose two possible Registry trees. Multiple entries are for various network devices like DialUp Networking (ppp), Ethernet NICs, PPTP VPNs, etc. 


  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Parameters\Tcpip]
                    and
  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<Adapter-name>\Parameters\Tcpip]

     Replace "<Adapter-Name>" with the respective name of your uplink LAN NIC 
     interface

        type=DWORD
        name="MTU"              (Do NOT include the quotes)
        value=1492 (Decimal)    (Do NOT include the text "(Decimal>")

      (Do NOT include the quotes)


      • If you know how to also change the MSS, TCP Window Size, and the
      • TTL parameters in NT 4.x, please email dranch@trinnet.net as I
      • would love to add it to the HOWTO.

5. Reboot to make the changes take effect.

Changing the MTU on MS Windows 98:

1. Making ANY changes to the Registry is inheritantly risky but with a backup copy, you should be safe. Proceed at your OWN RISK.

2. Goto Start-->Run-->RegEdit

3. You should make a backup copy of your Registry before doing anything. To do this, copy the "user.dat" and "system.dat" files from the \WINDOWS directory and put them into a safe place. It should be noted that the previously mentioned method of using "Regedit: Registry-->Export Registry File-->Save a copy of your registry" would only perform Registry MERGES and NOT do a replacement.

4. Search though each of the Registry trees that end in "n" (e.g. 0007) and have a Registry entry called "IPAddress" which has the IP address of your NIC. Under that key, add the following: 

    [Hkey_Local_Machine\System\CurrentControlset\Services\Class\NetTrans\000n]
        type=STRING
        name="MaxMTU"            (Do NOT include the quotes)
        value=1492 (Decimal)     (Do NOT include the text "(Decimal)")


5. You can also change the "TCP Receive Window" which sometimes increases network performance SUBSTANTIALLY. If you notice your 

  throughput has DECREASED, put these items BACK to their original settings and reboot.

    [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]

       type=STRING
       name="DefaultRcvWindow"    (Do NOT include the quotes)
       value=32768 (Decimal)      (Do NOT include the text "(Decimal>")

       type=STRING
       name="DefaultTTL"          (Do NOT include the quotes)
       value=128 (Decimal)        (Do NOT include the text "(Decimal>")

6. Reboot to let the changes take effect.

Changing the MTU on MS Windows 95:

1. Making ANY changes to the Registry is inheritantly risky but with a backup copy, you should be safe. Proceed at your OWN RISK.

2. Goto Start-->Run-->RegEdit

3. You should make a backup copy of your Registry before continuing. To do this, copy the "user.dat" and "system.dat" files from the \WINDOWS directory and put them into a safe place. It should be noted that the previously mentioned method of using "Regedit: Registry-->Export Registry File-->Save a copy of your registry" would only do Registry MERGES and NOT do a replacement.

4. Search through each of the Registry trees that end in "n" (e.g. 0007) and have a Registry entry called "IPAddress", which has the IP address of your NIC. Under that key, add the following: 

    [Hkey_Local_Machine\System\CurrentControlset\Services\Class\NetTrans\000n]

        type=DWORD
        name="MaxMTU"           (Do NOT include the quotes)
        value=1492 (Decimal)    (Do NOT include the text "(Decimal)")

        type=DWORD
        name="MaxMSS"           (Do NOT include the quotes)
        value=1450 (Decimal)    (Do NOT include the text "(Decimal>")


5. You can also change the "TCP Receive Window" which sometimes increases network performance SUBSTANTIALLY. If you notice your 

  throughput has DECREASED, put these items BACK to their original settings and reboot.

    [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\MSTCP]
       type=DWORD
       name="DefaultRcvWindow"   (Do NOT include the quotes)
       value=32768 (Decimal)     (Do NOT include the text "(Decimal>")

       type=DWORD
       name="DefaultTTL"         (Do NOT include the quotes)
       value=128 (Decimal)       (Do NOT include the text "(Decimal>")


6. Reboot to let the changes take effect.


References

http://www.linux.org/docs/ldp/howto/IP-Masquerade-HOWTO/mtu-issues.html

Retrieved from "http://wiki.robotz.com/index.php?title=MTU_Changing_default_in_Linux_and_Windows&oldid=505"