Differences between version 5 and previous revision of MTU.
Other diffs: Previous Major Revision, Previous Author, or view the Annotated Edit History
Newer page: | version 5 | Last edited on Tuesday, May 31, 2005 3:12:54 pm | by JohnMcPherson | Revert |
Older page: | version 4 | Last edited on Monday, December 27, 2004 7:38:20 am | by AristotlePagaltzis | Revert |
@@ -6,7 +6,10 @@
The [TCP/IP] stacks in [Linux] and most other recent OperatingSystem~s use a clever system called __path [MTU] discovery__ to address this problem. The [MTU] for a new connection is set low, but gradually increases, while the packets are sent with the __don't fragment__ flag set. When the [MTU] grows beyond the smallest [MTU] of any link anywhere in the route, the responsible gateway will refuse to route the packets because they're too large to send them without fragmenting them but it's not allowed to do that. Instead, it will notify the source host with a __Need to fragment, but don't fragment is set__ [ICMP] message. At this point the sending host knows the maximum fragmentation-free [MTU] size it can use on this connection, which is the most bandwidth-efficient size for packets.
Unfortunately, some particularly clueless SysAdmin~s ignorantly block any and all [ICMP] packets from passing through their gateways without fully understanding why [ICMP] is an important part of [IP], and/or without thinking of the consequences. Banks seem to be a major transgressor here.
+
+Another cause of MTU-related brokenness is routers that need to send ICMP packets but are using private non-routable IP addresses.
+
See also:
* Some common (and not so common) [MTU sizes | http://www-12.lotus.com/ldd/doc/domino_notes/5.0/readme.nsf/0/f397306f052d9ea3852567740049a10a?OpenDocument]