Differences

This shows you the differences between two versions of the page.

--- ubuntu:network:change_the_mtu_of_a_network_interface [2020/07/15 09:30] – external edit 127.0.0.1
+++ ubuntu:network:change_the_mtu_of_a_network_interface [2021/01/07 11:15] (current) – removed peter
@@ Line 1: / Line 1: @@
-====== Ubuntu - Network - Change the MTU of a network interface ======
-To change the MTU of a network interface
-===== Background =====
-The maximum transmission unit (MTU) of a network interface is the size of the largest block of data that can be transmitted as a single unit.  Anything larger than the MTU must be broken into smaller units prior to transmission.
-MTUs can be measured either at the network layer or at the link layer.  For example, the standard Ethernet MTU is 1500 bytes at the network layer but 1518 bytes at the link layer. The values given here are network-layer MTUs unless stated otherwise, but be aware that equipment manufacturers often specify link-layer MTUs instead.
-A common reason for wanting to increase the MTU of an interface is to improve the throughput of high-speed Ethernet.  The standard Ethernet MTU has remained fixed at 1500 bytes for backward compatibility with 10 and 100 megabit networks, however this is far from optimal at speeds of 1 gigabit and above.  Most modern networking equipment is capable of handling larger frames but must be explicitly configured to do so.  Frames which take advantage of this ability are known as ‘jumbo frames’, and 9000 bytes is a popular choice for the MTU.
-Possible reasons for wanting to reduce the MTU include:
-  * matching the MTU to that of another network (in order to avoid fragmentation when carrying UDP, and to streamline PMTU discovery when carrying TCP);
-  * matching the MTU to a whole number of ATM cells (when you know that the traffic will at some point need to be encoded using AAL5); or
-  * improving throughput on lines with very high error rates.
-MTUs should not normally be mixed on any given Internet Protocol subnet, however it is possible (and common) for subnets with different MTUs to be connected to each other by means of a router.
-----
-===== Non-persistent Method =====
-The MTU of an interface can be changed temporarily using the mtu option of the ifconfig command:
-<code bash>
-ifconfig eth0 mtu 9000
-</code>
-The new MTU will not persist beyond a reboot.
-----
-===== Persistent Method =====
-If the interface has (or can be given) a static configuration in **/etc/network/interfaces** then its MTU can be persistently altered by adding an **mtu** option to the relevant iface stanza, for example:
-<file bash /etc/network/interfaces>
-auto eth0
-iface eth0 inet static
-	address 192.168.0.2
-	netmask 255.255.255.0
-	mtu 9000
-</file>
-**NOTE**:  This method does not work when using other configuration methods such as dhcp.
-You can activate the new MTU can by taking the interface down using **ifdown** then bringing it back up using **ifup**:
-<code bash>
-ifdown eth0
-ifup eth0
-</code>
-Alternatively you could reboot the machine.
-See:
-  * [[http://www.microhowto.info/howto/persistently_change_the_mtu_of_a_network_interface_on_redhat.html|Persistently change the MTU of a network interface (Red Hat)]]
-  * [[http://www.microhowto.info/howto/change_the_mtu_of_a_network_interface_using_dhcp.html|Change the MTU of a network interface using DHCP]]
-----
-===== Testing =====
-==== Check the configured MTU ====
-You can verify that an interface has the intended MTU using the **-i** option of the **netstat** command:
-<code bash>
-netstat -i
-</code>
-The MTU of each interface is listed in the second column of the output:
-<code bash>
-Iface   MTU Met   RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
-eth0   1500 0      9658      0      0      0      308      0      0      0 BMRU
-lo    16436 0     12952      0      0      0    12952      0      0      0 LRU
-Alternatively you can obtain essentially the same information using the ifconfig command:
-ifconfig eth0
-The MTU is then listed after the interface address (or addresses) but before the packet counters:
-eth0      Link encap:Ethernet  HWaddr 02:00:00:00:00:00
-          inet addr:192.168.0.2  Bcast:192.168.0.255  Mask:255.255.255.0
-          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
-          RX packets:9659 errors:0 dropped:0 overruns:0 frame:0
-          TX packets:309 errors:0 dropped:0 overruns:0 carrier:0
-          collisions:0 txqueuelen:1000
-          RX bytes:2783810 (2.6 MiB)  TX bytes:25318 (24.7 KiB)
-</code>
-Remember that the value listed is not necessarily the one that would apply following a reboot.
-----
-==== Check connectivity using ping ====
-You can verify that the path between two machines has at least the expected MTU using the ping command:
-<code bash>
-ping -M do -c 4 -s 8972 192.168.0.1
-</code>
-This transmits an ICMP echo request to the specified destination then waits for an ICMP echo reply.  As the intention here is to check the behaviour of eth0, it would be best to choose a destination on the same subnet in the first instance.  Both machines must have a sufficiently large MTU if the test is to succeed.
-The **-M do** option causes the DF (don't fragment) flag to be set, meaning that the packet should be dropped if it cannot remain in one piece at any point in its journey.  The **-c** option sets the number of pings.
-The **-s** option specifies the number of bytes of padding that should be added to the echo request.  In addition to this number there will be 20 bytes for the internet protocol header, and 8 bytes for the ICMP header and timestamp.  The amount of padding should therefore be 28 bytes less than the network-layer MTU that you are trying to test (9000 − 28 = 8972).
-If the test is successful then you should see a list of echo replies that were received:
-<code bash>
-PING 192.168.0.1 (192.168.0.1) 8972(9000) bytes of data.
-bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.241 ms
-bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.583 ms
-bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.140 ms
-bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.123 ms
-</code>
-Note that the IP packet size (9000 bytes) is listed on the first line.  You can use this to check that you requested the correct amount of padding.
-If the test is unsuccessful then you should see an error in response to each echo request:
-<code bash>
-PING 192.168.0.1 (192.168.0.1) 8972(9000) bytes of data.
-From 192.168.0.2 icmp_seq=1 Frag needed and DF set (mtu = 1500)
-From 192.168.0.2 icmp_seq=1 Frag needed and DF set (mtu = 1500)
-From 192.168.0.2 icmp_seq=1 Frag needed and DF set (mtu = 1500)
-From 192.168.0.2 icmp_seq=1 Frag needed and DF set (mtu = 1500)
-</code>
-Note that the MTU for the hop that failed is listed in the error message.  This is not necessarily the MTU for the entire path, only the first MTU that was found to be too small.
-Path MTUs are recorded in the routing cache. This can interfere with testing, and in particular, can make a remote MTU restriction appear to be a local one.  You can clear the cache using the ip route command:
-<code bash>
-ip route flush cache
-</code>
-----
-===== Errors =====
-==== Invalid argument ====
-An error of the form:
-<code bash>
-SIOCSIFMTU: Invalid argument
-</code>
-indicates that the requested MTU was rejected by the kernel.  Typically this would be due to it exceeding the maximum value supported by the interface hardware. In that case you must either reduce the MTU to a value that is supported or obtain more capable hardware.
-----
-===== Reference =====
-  * Matt Mathis, [[http://staff.psc.edu/mathis/MTU/|Raising the Internet MTU]]