Rick Thomas writes:
On Jun 5, 2011, at 9:46 AM, Pascal Hambourg wrote:
Rick Thomas a écrit :
On Jun 3, 2011, at 10:46 AM, Jeffrey B. Green wrote:
The RFCs say that any conforming implementation MUST handle an MTU of
1280, and may not necessarily handle anything larger.
What is your point in mentionning this requirement? Do you mean that the
server should not send packets bigger than 1280 bytes if it fails to
handle properly path MTU discovery ? If so, I fully agree.
My point is that by setting your MTU to 1280, you have done *your* part. At
least you can be assured that all your packets will get thru without
fragmentation, even if the host at the other end -- or some intervening router
-- is improperly configured.
If the host on the other end sets its MTU to something larger and an
intervening router doesn't do fragmentation, they (or the admins of the router)
need to fix that. An easy recommendation that you can make in this case (if the
server admin on the other end is clueless but willing to help) is for them to
set their MTU to 1280 as well. That will fix the problem regardless of
intervening routers.
Finding a (possible series of) mis-configured intermediate router(s) and
convincing the respective router-admin(s) to fix their configuration is often
difficult. It's easier if you have only one person to talk to, the server admin
on the other end.
In my case, I was able to explore some of the pitfalls of MTUs, in
particular in crossing a firewall. I know that I was not able to easily
take care of a decreasing MTU mismatch _across the firewall_ in the case
of IPv4; so the internal lan-side MTU must match the wan-side MTU for
our location. (Not sure at present if the MTU correction messages were
not making it back or if some of the workstations were being obstinate
in setting the MTU or if the firewall was killing the latter fragments.)
And at present only the servers and a handful of workstations here are
accessing the world by IPv6, and consequently any tunnel impact on MTU
here was minimal.
-jeff
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4df0bc4f.1080...@kikisoso.org