Re: Strange MTU Problem
- From: ibuprofin@xxxxxxxxxxxxxxxxxxxxxx (Moe Trin)
- Date: Sun, 25 May 2008 14:16:27 -0500
On Sat, 24 May 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <L8OdncoNQsz_P6XVnZ2dnUVZ_gmdnZ2d@xxxxxxxxxxxxx>, Shadow_7 wrote:
On my dialup connection I run the MTU at 576, and the MRU at 1500. If I
run the MRU at 576, I can't even check my email from my ISP.
When I was just playing with the MTU and leaving the MRU and stuff alone, I
had to change my MTU to 1500 to get to some sites. Tracfone.com,
Pogo.com, and some others.
That's rather interesting. Normally the problem is packets that are to
big, rather than to small. Setting the MTU to 1500 (the default) says
this is the largest sized packet you will transmit. The normal
concern is the largest _receive_ packet, and that is actually what
gets negotiated between ppp peers. Most links don't care what the
maximum size packet YOU transmit is, as long as it's less than the
maximum size that the peer will accept (default 1500).
Accessibility came and went though, I could access them, but there was
normally a five minute to an hour and a half delay before a page would
suddenly finish downloading. And not really because of media content.
The bandwidth/throughput would just sit idle until it popped up. A
month earlier, and probably a month later, those same sites were NOT
problematic on the same MTU size.
Hind-sight is a wonderful thing, but next time that happens, try using
a packet sniffer looking at the headers, and try using traceroute
(preferably 'tcptraceroute' or 'hping3' which allows using TCP data
rather than ICMP echos or UDP) to see the route and possibly who is
dropping packets. The most likely answer is that the routing between
you and the destination changed. Such routes through the "cloud" are
not under your control, but can be bewildering. As an extreme case,
I once did a traceroute6 (IPv6) from a site in New York to a site in
Montreal, and the intermediate hops included Chicago, Seattle, Tokyo,
and Vancouver.
Most times the routing machine didn't have the issue, where any NAT'd
clients did. I don't know why, just that changing the MTU and
sometimes MRU fixed the problem.
THAT problem is Path MTU Discovery. See the three RFCs I refer to
up-thread (RFC1191, RFC1435 and RFC2923). The problem is that Linux
defaults to using Path MTU Discovery (the DF flag is set in the IP
headers), so when sending full sized packets, they are 1500 octets.
Your router/NAT box is either dropping, or failing to correctly
forward the resulting ICMP Type 3 Code 4 packets (often, because it
can't figure out who they are associated with). If you can run a
packet sniffer on the router/NAT box, you'd likely see the ICMP
errors on the Internet side, and not see them forwarded to your LAN
hosts.
1500 for most things, especially wireless.
1492 for some cable providers
576 for dialup
First two OK - last one definitely not. The 8 octet reduction in
MTU for some cable providers is because they are using PPPoE (or the
similar PPPoA). This service sticks an 8 byte header on top of the
packet, and as (standard) Ethernet is limited to 1500 octet frames,
the payload has to be reduced. See RFC2516 and RFC4937 for more
information on this poorly documented service.
The reduction for dialup - that's a whole 'nother problem. The reason
to reduce the MTU is for interactive services, where what you are
typing is echoed back to you from the remote server - for example,
in 'telnet'. The packet size is reduced to improve the latency (the
time between you typing the character, and the resulting echo back
to your display) - see RFC1144 for further details. The '576' MTU
is suitable for X.25 links (now uncommon) and 19200 BPS serial
links. As most serial connections are substantially faster than that,
the MTU reduction usually serves no purpose today. AN EXCEPTION
is when you are using the link for multiple connections _at_the_same_
time_ such as a bloated webpage AND an SSH session, or large FTP file
transfer. The concept here is that with smaller packets, the second
or third connection can 'get a word in edge-wise' between packets of
the bandwidth hog. The overall time for the combined connections will
not significantly change, but each component may have a better chance
to get _some_ bandwidth.
Changing the MTU in XP, a real PITA (registry hack). In Vista a
little less painfull with the proper documentation of course. netsh
or whatever it's called. Used it once, hopefully never have to see it
again in my lifetime.
Use a packet sniffer - is windoze setting the 'DF' (Don't Fragment)
flag in the IP header? If it's not, the only reason to be reducing
the MTU would be for connection sharing with bandwidth hogs.
Not that it's all that bad relative to CLI based ifconfig and such.
In most Linux or UNIX operating systems, setting the MTU is a
single variable in the boot configuration file, which you can set
using the windoze-wannabe toy admin application, or by adding a
line to the appropriate (varies by distribution or O/S) file.
Old guy
.
- Follow-Ups:
- Re: Strange MTU Problem
- From: Shadow_7
- Re: Strange MTU Problem
- References:
- Re: Strange MTU Problem
- From: Shadow_7
- Re: Strange MTU Problem
- Prev by Date: How to delete an entry in ARP
- Next by Date: Re: Strange MTU Problem
- Previous by thread: Re: Strange MTU Problem
- Next by thread: Re: Strange MTU Problem
- Index(es):
Relevant Pages
|
