Common operational misconceptions

George Bonser 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
> it?
> 
> 						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
   Discovery algorithm.

   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
   search_low.

   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 mailing list