MTU
There is kind of a work around to detect MTU problems with TCP using ICMP as a base: http://en.wikipedia.org/wiki/Path_MTU_Discovery
PMTU. The caveats are: it doesn't work with UDP, and some scenarios
with ICMP being blocked or old operating systems, and some
interoperability/network topology situation
The problem comes when you want to send more data over this connection - lets say you wanted to send 3000 bytes: your computer would split this up based on your MTU - in this case, two packets of 1500 bytes each, and send them to your ADSL modem which would then split them up so that it can fulfill its MTU. Now your 3000 byte data has been fragmented into four packets: two with a payload of 1492 bytes and two with a payload of 8 bytes. This is obviously inefficient, we really only need three packets to send this data. Had your computer been configured with the correct MTU for the network, it would have sent this as three packets in the first place (two 1492 byte packets and one 16 byte packet.)
To avoid this inefficiency, many IP stacks flip a bit in the IP header called "Don't Fragment." In this case, we would have sent our first 1500 byte packet to the ADSL modem and it would have rejected the packet, replying with an Internet Control (ICMP) message informing us that our packet is too large. We then would have retried the transmission with a smaller packet. This is called Path MTU discovery. Similarly, a layer below, at the TCP layer, another factor in avoiding fragmentation is the MSS (Maximum Segment Size) option where both hosts reply with the maximum size packet they can transfer without fragmenting. This is typically computed from the MTU.
The problem here arises when misconfigured firewalls drop all ICMP traffic. When you connect to (say) a web server, you build a TCP session and send that you're willing to accept TCP packets based on your 1500 byte MTU (since you're connected over ethernet to your router.) If the foreign web server wanted to send you a lot of data, they would split this into chunks that (when combined with the TCP and IP headers) came out to 1500 byte payloads and send them to you. Your ISP would receive one of these and then try to wrap it into a PPPoE packet to send to your ADSL modem, but it would be too large to send. So it would reply with an ICMP unreachable, which would (in a perfect world) cause the remote computer to downsize its MSS for the connection and retransmit. If there was a broken firewall in the way, however, this ICMP message would never be reached by the foreign web server and this packet would never make it to you.
https://stackoverflow.com/questions/6360916/do-mtu-modifications-impact-both-directions
Interestingly enough, the post from Greg Ferro illustrated that the reason 9000 is a common MTU size for jumbo frames is because the CRC field isn’t long enough to guarantee detection of errors for frames longer than 9000 bytes. I also recommend a read of this article, as it goes into a bit more detail on the math, as well as little tweaks on optimizing network performance. https://keepingitclassless.net/2013/03/jumbo-frames-beyond-the-broadcast-domain/
Weird behavior if link MTUs on both ends of a link don't match.
https://unix.stackexchange.com/questions/342290/interface-mtu-different-than-seen-in-ip-link-show-output
Other links
http://thenetworksherpa.com/ospf-master-the-mtu-madness/
https://learningnetwork.cisco.com/thread/37638
http://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xr-software/116350-trouble-ios-xr-mtu-00.html
https://supportforums.cisco.com/discussion/11530346/does-mtu-effect-packets-are-received-interface
https://supportforums.cisco.com/discussion/10072121/pmtu-and-mpls-networks
http://www.networkworld.com/article/2224654/cisco-subnet/mtu-size-issues.html
http://www.cisco.com/c/en/us/td/docs/ios/12_2sb/feature/guide/newmtu.html
http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13684-12.html
https://arstechnica.com/civis/viewtopic.php?t=1168225
The problem comes when you want to send more data over this connection - lets say you wanted to send 3000 bytes: your computer would split this up based on your MTU - in this case, two packets of 1500 bytes each, and send them to your ADSL modem which would then split them up so that it can fulfill its MTU. Now your 3000 byte data has been fragmented into four packets: two with a payload of 1492 bytes and two with a payload of 8 bytes. This is obviously inefficient, we really only need three packets to send this data. Had your computer been configured with the correct MTU for the network, it would have sent this as three packets in the first place (two 1492 byte packets and one 16 byte packet.)
To avoid this inefficiency, many IP stacks flip a bit in the IP header called "Don't Fragment." In this case, we would have sent our first 1500 byte packet to the ADSL modem and it would have rejected the packet, replying with an Internet Control (ICMP) message informing us that our packet is too large. We then would have retried the transmission with a smaller packet. This is called Path MTU discovery. Similarly, a layer below, at the TCP layer, another factor in avoiding fragmentation is the MSS (Maximum Segment Size) option where both hosts reply with the maximum size packet they can transfer without fragmenting. This is typically computed from the MTU.
The problem here arises when misconfigured firewalls drop all ICMP traffic. When you connect to (say) a web server, you build a TCP session and send that you're willing to accept TCP packets based on your 1500 byte MTU (since you're connected over ethernet to your router.) If the foreign web server wanted to send you a lot of data, they would split this into chunks that (when combined with the TCP and IP headers) came out to 1500 byte payloads and send them to you. Your ISP would receive one of these and then try to wrap it into a PPPoE packet to send to your ADSL modem, but it would be too large to send. So it would reply with an ICMP unreachable, which would (in a perfect world) cause the remote computer to downsize its MSS for the connection and retransmit. If there was a broken firewall in the way, however, this ICMP message would never be reached by the foreign web server and this packet would never make it to you.
https://stackoverflow.com/questions/6360916/do-mtu-modifications-impact-both-directions
Interestingly enough, the post from Greg Ferro illustrated that the reason 9000 is a common MTU size for jumbo frames is because the CRC field isn’t long enough to guarantee detection of errors for frames longer than 9000 bytes. I also recommend a read of this article, as it goes into a bit more detail on the math, as well as little tweaks on optimizing network performance. https://keepingitclassless.net/2013/03/jumbo-frames-beyond-the-broadcast-domain/
Weird behavior if link MTUs on both ends of a link don't match.
https://unix.stackexchange.com/questions/342290/interface-mtu-different-than-seen-in-ip-link-show-output
Other links
http://thenetworksherpa.com/ospf-master-the-mtu-madness/
https://learningnetwork.cisco.com/thread/37638
http://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/ios-xr-software/116350-trouble-ios-xr-mtu-00.html
https://supportforums.cisco.com/discussion/11530346/does-mtu-effect-packets-are-received-interface
https://supportforums.cisco.com/discussion/10072121/pmtu-and-mpls-networks
http://www.networkworld.com/article/2224654/cisco-subnet/mtu-size-issues.html
http://www.cisco.com/c/en/us/td/docs/ios/12_2sb/feature/guide/newmtu.html
http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13684-12.html
https://arstechnica.com/civis/viewtopic.php?t=1168225
Comments
Post a Comment