Common operational misconceptions
gbonser at seven.com
Mon Feb 20 23:27:31 UTC 2012
> Your trick is that your routers at the border between MTUs
> 7500 and 1500 (or maybe, 1400 or so) generate ICMP packet too big
> packets to your servers and no intermediate entities filter them, isn't
> Masataka Ohta
I am saying that MTU probing works just fine, even with a link in between that has a shorter MTU and doesn't pass ICMP. I actually have one of those.
It actively probes with packets of varying sizes and learns what the path MTU is. It does not rely on ICMP. Again, it actively probes with varying sizes of packets until it believes it has "converged". There are two modes with linux. 1: where it only probes if there is a problem and 2: where it probes all the time.
The initial value for search_high SHOULD be the largest possible
packet that might be supported by the flow. This may be limited by
the local interface MTU, by an explicit protocol mechanism such as
the TCP MSS option, or by an intrinsic limit such as the size of a
protocol length field. In addition, the initial value for
search_high MAY be limited by a configuration option to prevent
probing above some maximum size. Search_high is likely to be the
same as the initial Path MTU as computed by the classical Path MTU
It is RECOMMENDED that search_low be initially set to an MTU size
that is likely to work over a very wide range of environments. Given
today's technologies, a value of 1024 bytes is probably safe enough.
The initial value for search_low SHOULD be configurable.
The probe may have a size anywhere in the "probe size range"
described above. However, a number of factors affect the selection
of an appropriate size. A simple strategy might be to do a binary
search halving the probe size range with each probe. However, for
some protocols, such as TCP, failed probes are more expensive than
successful ones, since data in a failed probe will need to be
retransmitted. For such protocols, a strategy that raises the probe
size in smaller increments might have lower overhead. For many
protocols, both at and above the Packetization Layer, the benefit of
increasing MTU sizes may follow a step function such that it is not
advantageous to probe within certain regions at all.
As an optimization, it may be appropriate to probe at certain common
or expected MTU sizes, for example, 1500 bytes for standard Ethernet,
or 1500 bytes minus header sizes for tunnel protocols.
Some protocols may use other mechanisms to choose the probe sizes.
For example, protocols that have certain natural data block sizes
might simply assemble messages from a number of blocks until the
total size is smaller than search_high, and if possible larger than
Each Packetization Layer MUST determine when probing has converged,
that is, when the probe size range is small enough that further
probing is no longer worth its cost. When probing has converged, a
timer SHOULD be set. When the timer expires, search_high should be
reset to its initial value (described above) so that probing can
resume. Thus, if the path changes, increasing the Path MTU, then the
flow will eventually take advantage of it. The value for this timer
MUST NOT be less than 5 minutes and is recommended to be 10 minutes,
per RFC 1981.
The timer for Linux is 5 minute by default but you can change it.
More information about the NANOG