Maximum Transmission Unit (MTU) is the largest data size (in bytes) permitted through the network. Ethernet interfaces have a default MTU of 1500 bytes, not including the Ethernet header or trailer. The value of the MTU depends on the type of the transmission link. The design of IP protocol resolves MTU differences by allowing routers to perform fragmentation of IP datagrams if it is necessary. The receiving host is responsible for reassembling the fragments back into the original full size IP datagram. This article will help you determine and set up the correct MTU size.
To determine the correct MTU size for your network, you can perform specific ping test on the destination you are trying to go to like using another computer or a web address.
For Windows computers, use the following command for the ping test: ping [url/local server or IP address] –f –l [xxxx number of bytes]
• Example: “ping www.google.com –f –l 1472”
For Mac computers, use the following command for the ping test: ping [url/local server or IP address] –d –s [xxxx number of bytes]
• Example: “ping www.google.com –d –s 1472”
To show current MTU on Windows 7 or Windows Vista, from a command prompt:
Here are the results that you may get after doing the ping test:
• Four (4) replies received: This means that the packet size entered is either within or the actual MTU size used within your network.
• Destination net unreachable: This means that there was no path or route to the destination or the address.
• Request Timed Out: This means that within the default wait time period (1 second), there was no response.
• Packet needs to be fragmented but DF set: This means that the packet size you entered is too high for your MTU value.
• Bad parameter –f: This means that you have typed the command incorrectly.
Short discussion about MTU and why we have 28 bytes.
- Ethernet v2 1500 bytes
- Internet IPv4 Path MTU At least 68
- Internet IPv6 Path MTU At least 1280
Network Interface Card has maximum packet size of 1500 bytes. TCP/IP requires 20 bytes (flags 12 bytes, 4 bytes source IP and 4 bytes destination IP). ICMP packets have an 8-byte header and variable-sized data section
Calculation: 1500 (ethernet) - 20 (TCP/IP) - 8 (icmp) = 1472 bytes for payload
I am going to consider simple scenario with three Cisco routers.
Verification of the interface configuration shows us default MTU for ethernet - 1500 bytes (follwoing example is taken from R2)
R2#show interface fastEthernet 0/0
FastEthernet0/0 is up, line protocol is up
Hardware is Gt96k FE, address is c001.347c.0000 (bia c001.347c.0000)
Internet address is 192.168.1.2/24
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec
R3#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/44/76 ms
Lets try to perform connectivity test with extended ping and set DF (don't fragment bit):
R3#ping
Protocol [ip]:
Target IP address: 192.168.1.1
Repeat count [5]:
Datagram size [100]: 100
Timeout in seconds [2]:
Extended commands [n]: yes
Source address or interface: 192.168.2.3
Type of service [0]:
Set DF bit in IP header? [no]: yes
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.3
Packet sent with the DF bit set
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/42/52 ms
Great, connectivity works fine.
Next test will be applying change to R2 Fa0/0 interface toward R1, decrease MTU settings to 1000.
R2(config)#interface fast 0/0
R2(config-if)#ip mtu 1000
R2(config-if)#exit
Connectivity from R2 to R1 still looks good.
R2#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/31/56 ms
R2#
Next two tests will be with running ping from R3 toward R1 Fa0/0 with higher MTU than 1000:
1. DF bit is not set (value 0) which means you can fragment
2. DF bit is set (value 1) which means, please do not fragment the packet
First scenario works pretty fine, R2 can fragment packets and all looks good.
R3#ping
Protocol [ip]:
Target IP address: 192.168.1.1
Repeat count [5]: 10
Datagram size [100]: 1001
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.2.3
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10, 1001-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.3
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 28/52/72 ms
Second scenario does not work because DF bit has value 1 and router R2 is doing fragmentation which is against don't fragment request.
R3#ping
Protocol [ip]:
Target IP address: 192.168.1.1
Repeat count [5]: 10
Datagram size [100]: 1001
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.2.3
Type of service [0]:
Set DF bit in IP header? [no]: yes
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10, 1001-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.3
Packet sent with the DF bit set
M.M.M.M.M.
Success rate is 0 percent (0/10)
According the Cisco, M output means Could not fragment (please see bellow table from Cisco web-site):
So, we have issue here, I have sent DF=1, R2 is doing fragmentation because has MTU 1000 and we can not get proper reply. I have debug ip icmp running and output confirms it.
R3#debug ip icmp
ICMP packet debugging is on
R3#ping
Protocol [ip]:
Target IP address: 192.168.1.1
Repeat count [5]: 10
Datagram size [100]: 1001
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.2.3
Type of service [0]:
Set DF bit in IP header? [no]: yes
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10, 1001-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.3
Packet sent with the DF bit set
M
*Mar 1 09:43:33.593: ICMP: dst (192.168.2.3) frag. needed and DF set unreachable rcv from 192.168.2.2.M
*Mar 1 09:43:35.617: ICMP: dst (192.168.2.3) frag. needed and DF set unreachable rcv from 192.168.2.2.M
*Mar 1 09:43:37.661: ICMP: dst (192.168.2.3) frag. needed and DF set unreachable rcv from 192.168.2.2.M
*Mar 1 09:43:39.705: ICMP: dst (192.168.2.3) frag. needed and DF set unreachable rcv from 192.168.2.2.M
*Mar 1 09:43:41.741: ICMP: dst (192.168.2.3) frag. needed and DF set unreachable rcv from 192.168.2.2.
It is not simple to find proper MTU on the path but Cisco has extended sweep ping command which offers us to start ping from specific size in bytes, increase by size and end up with some size in bytes.
Sweep min size [36]: 999 <- this means, start with 999 bytes
Sweep max size [18024]: 1002 <- this means, end with 1002 bytes
Sweep interval [1]: <- this means, increase with one byte
R3#ping
Protocol [ip]:
Target IP address: 192.168.1.1
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.2.3
Type of service [0]:
Set DF bit in IP header? [no]: yes
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: yes
Sweep min size [36]: 999
Sweep max size [18024]: 1002
Sweep interval [1]:
Type escape sequence to abort.
Sending 4, [999..1002]-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.3
Packet sent with the DF bit set
!!M.
Success rate is 50 percent (2/4), round-trip min/avg/max = 44/54/64 ms
This could be our solution. First ping has 999 bytes and we got reply, second one 1000 and we have reply, third 1001 and we have M (could not fragment). As 1000 bytes normally pass, we can change MTU on the path and apply ip mtu 1000
Another option could be making policy to override DF bit and my next article will be covering it.
No comments:
Post a Comment