In this Post:
- What is MTU – Maximum Transmission Unit
- Why Should I care?
- How and why would this need to change from default
What is MTU?
MTU is the Maximum Transmission Unit. This is the largest physical packet size (measured in bytes) that a network can transmit. Any messages larger than the MTU are divided (broken up) into smaller packets (fragmented) before being sent (which slows down transmission speeds).
In other words, the value of MTU defines the maximum length of a data unit a protocol can send in one shot (without fragmenting)
What is the ‘best’ MTU value to have on my client device?
Ideally, your client device should be configured to have its MTU value to be the same value as the smallest MTU of each of all the separate networks [which form the link between your client machine and the final destination (the server)].
- For example, if your remote destination (server) was running on Ethernet with a MTU value of 1500, but you were connecting to it via a network link using PPP (with an MTU value of 576) then you would ideally want to configure your client PC to have an MTU value of 576 for optimal performance to/from the server.
Additional information: This Technote mainly assumes that your network link is reliable – however, let us consider if your link unreliable:
- Larger MTU is more efficient (assuming that your link is reliable)
- However, if your link is unreliable, a single ‘wrong’ bit in a packet (or any packet loss) means the entire (large) packet must be sent all over again.
- => In such cases, a lower MTU would bring out a better performance.
Why do I have to manually correct the MTU value – surely I should just leave it to be the default/automatic settings?
In general, most people are only familiar with the network protocol Ethernet, where its theoretical maximum MTU is 1500. However, this Technote mostly relates to performance problems when using a VPN. In this case, the VPN encapsulation causes an overhead. VPNs most often send their transport packets with the ‘do not fragment’(DNF) option enabled (which makes things simpler for the encapsulated TCP, and prevents needless retransmission).
- For example, this means that the MTU of your operating system’s (for example Windows XP’s) virtual interface must be smaller than the MTU of your network (ethernet) card. This is so that there is ‘spare room) for the outer ‘encapsulation’ packet.
Most VPNs take this into account, and therefore set MTU automatically (dynamically). For example, they *may* use Path MTU (PMTU) Discovery to figure it out, and enforce the DNF bit (flag).
However, there are several scenarios where this ‘automatic’ MTU discovery process can fail:
- Scenario #1 – I.T. department’s network administrator has configured the Firewall to disable ICMP (which can result in PMTU failing).
- Scenario #2 – There is a network layer (between the client and server, which are both running on Ethernet) which is NOT running on Ethernet (for example ‘CSU/DSU serial’, some DSL lines using ATM/PPPoE+PPPoA etc.) and one of these layers do not support PMTU.
Tweaking the MTU values for the VPN interface (and/or in the VPN itself – very software-dependent) in some environments can give a tremendous performance boost.
- For example, many DSL lines (using various breeds of PPPoE, PPPoA) add extra layers (“padding”) to the datagram, which each reduce the ‘spare’ size of the MTU (the size left to actually carry the data). As a general rule of thumb, such DSL connections may require the MTU to be reduced from 1500 to something close to 1400.
Diagnosing the problem
Method to determine the Maximum MTU
The following process will determine the Maximum MTU between the client device (for example Windows XP PC) and the destination (for example the Cognos server):
- On the client PC, launch a command prompt (START – RUN – “CMD” <Enter>”
- Type the following: ping -f -l 1600 servername
- You should receive the message “Packet needs to be fragmented but DF set“, which indicates that the size of the packet sent (1600 bytes) was too large for the network to send without splitting it.
- Keep repeating step 2, but this time use smaller numeric values (such as 1500, 1450, 1400, 1350 etc.) for the size of the data packet.
- Eventually you should receive the ‘standard’ PING message “Reply from 123.456.789.012: bytes=xxxx time=YYms TTL=ZZZ“. This means that this packet size was small enough to fit inside the MTU.
- Slowly increase the data packet size again, until you find the maximum size that can be sent without receiving the message “Packet needs to be fragmented but DF set“. This is your maximum MTU size between the client PC and the destination.
How and why would this need to change from default
Modify your client device’s MTU setting to the appropriate setting, based on the advice above.
Based on Omer Choudhry’s Blog –
Maximum transmission unit or MTU is by default 1500 for TCP/IP, however it needs to be adjusted
sometimes. In this case it need to be changed on a Citrix Branch Repeater to match its paired BR settings.
1‐ In order to change MTU in Windows 2008 R2, go to an elected command prompt and type
netsh interface ipv4 show interfaces
(press ENTER)
You will get a table like this
Idx Met MTU State Name
— ———- ———- ———— ———————-
1 50 4294967295 connected Loopback Pseudo-Interface 1
11 10 1500 connected NLB
12 10 1500 connected Public
From the table above we need the value of Idx which is basically id of our NIC connected to “Public” interface
2‐ Now type this command to set the MTU value to 1370 instead of 1500
netsh interface ipv4 set subinterface “12”mtu=1370store=persistent
(press ENTER)
If there is no error you will have an “OK” message.
3‐ Now re‐run the command to show interface details and you will see new value of MTU against “Public” Interface
netsh interface ipv4 show interfaces
(press ENTER)
You will notice new value of MTU this time
craigocon 