[150006] in North American Network Operators' Group
RE: Common operational misconceptions
daemon@ATHENA.MIT.EDU (George Bonser)
Fri Feb 17 11:11:36 2012
From: George Bonser <gbonser@seven.com>
To: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Date: Fri, 17 Feb 2012 16:10:37 +0000
In-Reply-To: <4F3DF9A9.2090201@necom830.hpcl.titech.ac.jp>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
>=20
> It depends on how you define "work well".
>=20
> As the RFC says:
>=20
> indication of some significantly disruptive event in the network,
> such as a router failure or a routing change to a path with a
> smaller
> MTU.
>=20
> it can not react against PMTU changes very well.
>=20
> It is seemingly working well means there is not much PMTU changes,
> which means we had better assumes some PMTU (1280B, for example) and
> use it without PMTUD.
>=20
> Masataka Ohta
It depends on the OS and the method being used. If you set the option to "=
2" on Linux, it will do MTU probing constantly and react to MTU changes. A=
lso, the MTU for a given path only "lives" for 5 minutes anyway (by default=
) and is "rediscovered" with Linux. (value in /proc/sys/net/ipv4/route/mt=
u_expires) but other operating systems may behave in other ways.
I agree that if one tries hard enough, they can ensure a broken path and th=
ere are always people who seem to devote a lot of energy to that end. Ther=
e's nothing that can be done about them but there is much the OS can try to=
do to defeat them at their task.
