Strange MTU Problem - Networking

This is a discussion on Strange MTU Problem - Networking ; I run a small home network with two older Linux machines and an XP laptop. Recently I ran a Windows network analysis tool and after testing various URLs it reported my best MTU to be 1500, as this is the ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 30

Thread: Strange MTU Problem

  1. Strange MTU Problem

    I run a small home network with two older Linux machines and an XP laptop.

    Recently I ran a Windows network analysis tool and after testing various
    URLs it reported my best MTU to be 1500, as this is the default for ADSL
    I thought nothing of it and set my router to 1500 (It had been 1472).

    Everything appeared to be fine, web surfing OK, receiving mail OK but
    had a problem sending emails with attachments; also there was one web
    site that I couldn't access on my windows or Linux machines.

    As the only thing I recalled altering was the MTU changed it back to
    1472 and now all fine.

    I know the default is 1500 also for the Linux machines so is this a
    common problem with incorrect MTUs that most will work OK but some areas
    of the network may not.

    Geoff Lane

  2. Re: Strange MTU Problem

    In article , Geoff Lane says...
    > I run a small home network with two older Linux machines and an XP laptop.
    >
    > Recently I ran a Windows network analysis tool and after testing various
    > URLs it reported my best MTU to be 1500, as this is the default for ADSL
    > I thought nothing of it and set my router to 1500 (It had been 1472).
    >
    > Everything appeared to be fine, web surfing OK, receiving mail OK but
    > had a problem sending emails with attachments; also there was one web
    > site that I couldn't access on my windows or Linux machines.
    >
    > As the only thing I recalled altering was the MTU changed it back to
    > 1472 and now all fine.
    >
    > I know the default is 1500 also for the Linux machines so is this a
    > common problem with incorrect MTUs that most will work OK but some areas
    > of the network may not.
    >

    It also manifests itself as an inability to sign into Hotmail/MSN and
    online banking.

    I fail to see, however, how the analysis tool can report the MTU of
    1500 as being the best when it is incapable of altering the MTU you set
    on the router which, in respect to internet activity, is the only
    important one.


    --
    Conor

    I only please one person per day. Today is not your day. Tomorrow isn't
    looking good either. - Scott Adams

  3. Re: Strange MTU Problem

    On Sat, 24 May 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , Geoff Lane wrote:

    >I run a small home network with two older Linux machines and an XP laptop.
    >
    >Recently I ran a Windows network analysis tool and after testing various
    >URLs it reported my best MTU to be 1500, as this is the default for ADSL
    >I thought nothing of it and set my router to 1500 (It had been 1472).


    1472 isn't that common - it's not even listed as a default in one of the
    O/S fingerprinting tools. 1492 on the other hand is _VERY_ common.

    >Everything appeared to be fine, web surfing OK, receiving mail OK but
    >had a problem sending emails with attachments; also there was one web
    >site that I couldn't access on my windows or Linux machines.
    >
    >As the only thing I recalled altering was the MTU changed it back to
    >1472 and now all fine.


    Someplace, there is a firewall that is dropping ICMP Type 3 Code 4
    packets ("Fragmentation needed, but don't fragment bit set"). This
    could be a mis-guided attempt at security, or a NAT translation that
    isn't forwarding the error to the right computer.

    >I know the default is 1500 also for the Linux machines so is this a
    >common problem with incorrect MTUs that most will work OK but some
    >areas of the network may not.


    1191 Path MTU discovery. J.C. Mogul, S.E. Deering. November 1990.
    (Format: TXT=47936 bytes) (Obsoletes RFC1063) (Status: DRAFT
    STANDARD)

    1435 IESG Advice from Experience with Path MTU Discovery. S. Knowles.
    March 1993. (Format: TXT=2708 bytes) (Status: INFORMATIONAL)

    2923 TCP Problems with Path MTU Discovery. K. Lahey. September 2000.
    (Format: TXT=30976 bytes) (Status: INFORMATIONAL)

    The problem has been known for a "few" years, but it still catches
    people by surprise.

    Old guy

  4. Re: Strange MTU Problem

    > I run a small home network with two older Linux machines and an XP laptop.

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

    1500 for most things, especially wireless.
    1492 for some cable providers
    576 for dialup

    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. Not that it's all that bad relative to CLI based ifconfig and
    such. But in the newer windows you have to do special stuff to launch an
    admin capable dos window. And running that netsh thing in a non admin
    window does NOT fail, but does NOT make the change you requested either.

    HTH

  5. Re: Strange MTU Problem

    > I run a small home network with two older Linux machines and an XP laptop.

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

    1500 for most things, especially wireless.
    1492 for some cable providers
    576 for dialup

    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. Not that it's all that bad relative to CLI based ifconfig and
    such. But in the newer windows you have to do special stuff to launch an
    admin capable dos window. And running that netsh thing in a non admin
    window does NOT fail, but does NOT make the change you requested either.

    HTH

  6. Re: Strange MTU Problem

    Conor wrote:

    > It also manifests itself as an inability to sign into Hotmail/MSN and
    > online banking.


    Hadn't tried the online banking during this period.

    > I fail to see, however, how the analysis tool can report the MTU of
    > 1500 as being the best when it is incapable of altering the MTU you set
    > on the router which, in respect to internet activity, is the only
    > important one.


    I hadn't even considered that, blatantly obvious now you've highlighted
    it

    Geoff Lane

  7. Re: Strange MTU Problem

    Moe Trin wrote:

    > 1472 isn't that common - it's not even listed as a default in one of the
    > O/S fingerprinting tools. 1492 on the other hand is _VERY_ common.


    I thought 1472 allowed for a 28 byte header and actually equalled 1500,
    I arrived at this figure initially by using ping with -l and -f flags
    but I may be getting the wrong end of the stick here.

    It is working though

    Geoff Lane

  8. Re: Strange MTU Problem

    Geoff Lane wrote:
    > Moe Trin wrote:


    >> 1472 isn't that common - it's not even listed as a default in one of the
    >> O/S fingerprinting tools. 1492 on the other hand is _VERY_ common.


    > I thought 1472 allowed for a 28 byte header and actually equalled 1500,
    > I arrived at this figure initially by using ping with -l and -f flags
    > but I may be getting the wrong end of the stick here.


    It allows for 28 octets of PPPoX baggage in the framing probably used by
    your ADSL equipment. The (usual) 40 octet TCP/IP headers are included
    in the 1472 leaving 1432 octets for data. The 1492 allows for 8 octets
    of baggage in the most basic PPP over Ethernet, the smallest of all in
    the PPPoX family.

    How you got 1472 using preloaded flood pings is beyond me - unless you
    also specified packet size. However, you might try

    tcptraceroute -n -l 1500 192.175.48.60

    and perhaps see where the hangup occurs when the router MTU is set to
    1500 (the address is an IANA black hole). I suspect it won't even get
    to the ISP but if it does then I've guessed wrong and the problem is
    not on your end even though the cure is.

    > It is working though


    Right. "It" then hopefully doesn't have to depend on Path MTU Discovery,
    which is how TCP/IP can determine a workable MSS (Maximum Segment Size,
    and so maximum packet size) in the absence of broken routers in the path
    and broken endpoints.

    --
    Clifford Kite
    /* Substitute "damn" every time you're inclined to write "very"; your
    editor will delete it and the writing will be just as it should be.
    -- Mark Twain */
    QED

  9. Re: Strange MTU Problem

    On Sat, 24 May 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , 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

  10. Re: Strange MTU Problem

    On Sun, 25 May 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , Geoff Lane wrote:

    >Moe Trin wrote:


    >> 1472 isn't that common - it's not even listed as a default in one of the
    >> O/S fingerprinting tools. 1492 on the other hand is _VERY_ common.


    >I thought 1472 allowed for a 28 byte header and actually equalled 1500,


    While 1472+28 certainly does equal 1500, I'm not aware of a protocol
    that would use 20 or 28 bytes. The default Ethernet packet (RFC0894)
    is 1500 octets (but that doesn't include the Ethernet header and trailer
    of 18 octets). That packet contains an IP datagram of 46 to 1500 octets,
    which consists of a 20 to 60 octet IP header (20 plus options in steps
    of 4 octets), and the MTU is defined as the size of that IP datagram.
    See RFC1191 for additional details. The problem home broadband users
    encounter is the abortion called PPPoE, which sticks an IP packet into
    a PPP frame, and that frame adds 8 octets to the length (see RFC2516 and
    RFC4937 for more details). But the resulting packet still has to have a
    maximum Ethernet length of 1500 octets (without the Ethernet headers),
    so the MTU of the IP datagram has to be reduced by 8 to compensate for
    the 8 extra bytes of PPP header.

    >I arrived at this figure initially by using ping with -l and -f flags
    >but I may be getting the wrong end of the stick here.


    Not exactly sure how that would enter into the argument.

    >It is working though


    That's the important part.

    Old guy

  11. Re: Strange MTU Problem

    Hello,

    Geoff Lane a écrit :
    >
    > I thought 1472 allowed for a 28 byte header and actually equalled 1500,


    What header ? The IP header length is included in the MTU.

    > I arrived at this figure initially by using ping


    Oh, do you mean 28 is the sum of the IP header length (20) + ICMP header
    length (8) and 1472 is the maximum payload length (-s option, online
    help calling it "packetsize" may be misleading) in the ping request ?
    Then the MTU is 1500.

  12. Re: Strange MTU Problem

    Clifford Kite wrote:
    > Geoff Lane wrote:
    >> Moe Trin wrote:

    >
    >>> 1472 isn't that common - it's not even listed as a default in one of the
    >>> O/S fingerprinting tools. 1492 on the other hand is _VERY_ common.

    >
    >> I thought 1472 allowed for a 28 byte header and actually equalled 1500,
    >> I arrived at this figure initially by using ping with -l and -f flags
    >> but I may be getting the wrong end of the stick here.

    >
    > It allows for 28 octets of PPPoX baggage in the framing probably used by
    > your ADSL equipment. The (usual) 40 octet TCP/IP headers are included
    > in the 1472 leaving 1432 octets for data. The 1492 allows for 8 octets
    > of baggage in the most basic PPP over Ethernet, the smallest of all in
    > the PPPoX family.


    PPPoA vcmux has the least overhead (9 or 10) but you can still run MTU
    1500 as AAL5 can carry about 32k. PPPoE adds the mac address amongst
    other things on top of the 8 bytes that eat out of the 1500 ethernet
    payload limit.

    Andy.

  13. Re: Strange MTU Problem

    Andy Furniss wrote:
    > Clifford Kite wrote:
    >> Geoff Lane wrote:
    >>> Moe Trin wrote:

    >>
    >>>> 1472 isn't that common - it's not even listed as a default in one of the
    >>>> O/S fingerprinting tools. 1492 on the other hand is _VERY_ common.

    >>
    >>> I thought 1472 allowed for a 28 byte header and actually equalled 1500,
    >>> I arrived at this figure initially by using ping with -l and -f flags
    >>> but I may be getting the wrong end of the stick here.

    >>
    >> It allows for 28 octets of PPPoX baggage in the framing probably used by
    >> your ADSL equipment. The (usual) 40 octet TCP/IP headers are included
    >> in the 1472 leaving 1432 octets for data. The 1492 allows for 8 octets
    >> of baggage in the most basic PPP over Ethernet, the smallest of all in
    >> the PPPoX family.


    > PPPoA vcmux has the least overhead (9 or 10) but you can still run MTU
    > 1500 as AAL5 can carry about 32k. PPPoE adds the mac address amongst
    > other things on top of the 8 bytes that eat out of the 1500 ethernet
    > payload limit.


    Beg to differ, the source and destination MAC addresses are part of
    the header for Ethernet frames of type 0x8864 (PPPoE session frames)
    just as they are a part of the header for regular Ethernet frames and
    don't take up any of the regular Ethernet payload space.

    --
    Clifford Kite


  14. Re: Strange MTU Problem

    > the MTU reduction usually serves no purpose today.

    The exception is pretty much rule around here. We share a dialup
    connection for the entire house. So the smaller MTU allows for more user
    friendly queuing of packets. Like most web pages with 1,000,000 50 byte
    pics and scripts all imported to one html document. Which appears to be
    the rule these days. Run a torrent or *cough* windows update while trying
    to check your web based email and forget about it, if you're using a larger
    MTU size. Also the ISP seems to drop the connection much quicker if you
    don't use a small MTU. With a 1500 packet size, it will dial out about
    every two minutes. With the smaller MTU size I can stay connected 5 to 10
    hours at a time. I also appear to be able to download at extra 3MB per
    hour at 576. So roughly 15MB per hour, instead of 12MB or less.

    When issues arise, it's problematic in that nothing changed on this end.
    Mom gets edgy, my internet games this morning and my whole day sucked
    because of it. Don't make me run windows. Of course we moved away from
    windows because it's wireless connectivity was dodgy at best. Sometimes it
    worked, sometimes it didn't. Normally if the signal dropped below 34% it
    would forget that it had a wireless interface. So any time the A/C kicked
    on bye bye network. I moved her to linux and she's much happier. But now
    when issues happen she gets flustered as do I because normally it runs
    problem free. And of course "nothing changed on our end".

  15. Re: Strange MTU Problem

    Moe Trin wrote:

    >> I thought 1472 allowed for a 28 byte header and actually equalled 1500,

    >
    > While 1472+28 certainly does equal 1500, I'm not aware of a protocol
    > that would use 20 or 28 bytes.


    On the following URL it explains about using PING to check MTU and gives
    the explanations following.

    http://www.kitz.co.uk/adsl/MTU2.htm


    In the example above it shows that my highest responsive ping is 1402.
    From this we need to add on 28 to get the maximum MTU figure.
    (28 being the header size for IP + ICMP)

    Do not go above 1472. (1472 + 28 = 1500 MTU) since 1500 is the maximum MTU.

    Geoff Lane




  16. Re: Strange MTU Problem

    Pascal Hambourg wrote:

    > Oh, do you mean 28 is the sum of the IP header length (20) + ICMP header
    > length (8) and 1472 is the maximum payload length (-s option, online
    > help calling it "packetsize" may be misleading) in the ping request ?
    > Then the MTU is 1500.


    Yes, I did read that explanation somewhere.

    Geoff Lane


  17. Re: Strange MTU Problem

    Moe Trin wrote:

    >> As the only thing I recalled altering was the MTU changed it back to
    >> 1472 and now all fine.

    >
    > Someplace, there is a firewall that is dropping ICMP Type 3 Code 4
    > packets ("Fragmentation needed, but don't fragment bit set"). This
    > could be a mis-guided attempt at security, or a NAT translation that
    > isn't forwarding the error to the right computer.


    I've got an older Vigor 2600 NAT router, on the IP tables I have barred
    everything in and out unless I open the ports.

    To date with trial and error, if anything don't work I check the ports
    in the router's system log and open that port if I require it. All
    normal ports are open.

    The rules apply to TCP/UDP so I assume ICMP is not affected.

    Is Path MTU Discovery on by default. I have looked at DR TCP and have
    tried altering the MTU and saving but it always comes up blank when I
    launch the program again.

    Geoff Lane

  18. Re: Strange MTU Problem

    Clifford Kite wrote:
    > Andy Furniss wrote:
    >> Clifford Kite wrote:
    >>> Geoff Lane wrote:
    >>>> Moe Trin wrote:
    >>>>> 1472 isn't that common - it's not even listed as a default in one of the
    >>>>> O/S fingerprinting tools. 1492 on the other hand is _VERY_ common.
    >>>> I thought 1472 allowed for a 28 byte header and actually equalled 1500,
    >>>> I arrived at this figure initially by using ping with -l and -f flags
    >>>> but I may be getting the wrong end of the stick here.
    >>> It allows for 28 octets of PPPoX baggage in the framing probably used by
    >>> your ADSL equipment. The (usual) 40 octet TCP/IP headers are included
    >>> in the 1472 leaving 1432 octets for data. The 1492 allows for 8 octets
    >>> of baggage in the most basic PPP over Ethernet, the smallest of all in
    >>> the PPPoX family.

    >
    >> PPPoA vcmux has the least overhead (9 or 10) but you can still run MTU
    >> 1500 as AAL5 can carry about 32k. PPPoE adds the mac address amongst
    >> other things on top of the 8 bytes that eat out of the 1500 ethernet
    >> payload limit.

    >
    > Beg to differ, the source and destination MAC addresses are part of
    > the header for Ethernet frames of type 0x8864 (PPPoE session frames)
    > just as they are a part of the header for regular Ethernet frames and
    > don't take up any of the regular Ethernet payload space.
    >


    In the context of ADSL and PPPoX as above you said PPPoE had the
    smallest baggage. This is not the case as ADSL uses ATM/AAL5 and in the
    case of PPPoE the mac gets sent in the AAL5 frame as well as other
    overheads - for PPPoA it doesn't. If as a DSL customer you have a choice
    (As I do) PPPoA/VC multiplex gives the lowest on the wire overhead of
    the PPPs.

    In both cases there are ATM overheads and padding to consider as well to
    truly know how much of your sync/showtime bitrate is used per packet.

    Andy.

  19. Re: Strange MTU Problem

    Andy Furniss wrote:
    > Clifford Kite wrote:
    >> Andy Furniss wrote:


    >>> PPPoA vcmux has the least overhead (9 or 10) but you can still run MTU
    >>> 1500 as AAL5 can carry about 32k. PPPoE adds the mac address amongst
    >>> other things on top of the 8 bytes that eat out of the 1500 ethernet
    >>> payload limit.

    >>
    >> Beg to differ, the source and destination MAC addresses are part of
    >> the header for Ethernet frames of type 0x8864 (PPPoE session frames)
    >> just as they are a part of the header for regular Ethernet frames and
    >> don't take up any of the regular Ethernet payload space.
    >>

    > In the context of ADSL and PPPoX as above you said PPPoE had the
    > smallest baggage. This is not the case as ADSL uses ATM/AAL5 and in the
    > case of PPPoE the mac gets sent in the AAL5 frame as well as other
    > overheads - for PPPoA it doesn't. If as a DSL customer you have a choice
    > (As I do) PPPoA/VC multiplex gives the lowest on the wire overhead of
    > the PPPs.


    Okay, my bad. I failed to connect the first sentence in your reply
    with the last and thought you were talking about the Ethernet framing
    not that over the wire to the ISP.

    > In both cases there are ATM overheads and padding to consider as well to
    > truly know how much of your sync/showtime bitrate is used per packet.


    > Andy.


    --
    Clifford Kite


  20. Re: Strange MTU Problem

    On Mon, 26 May 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , Shadow_7 wrote:

    >> the MTU reduction usually serves no purpose today.

    >
    >The exception is pretty much rule around here. We share a dialup
    >connection for the entire house. So the smaller MTU allows for more
    >user friendly queuing of packets.


    That is a very valid reason.

    >Like most web pages with 1,000,000 50 byte pics and scripts all
    >imported to one html document. Which appears to be the rule these days.


    Boy, do I know what you mean. I was investigating a webpage that one
    of my users was complaining about, and discovered it had so much
    garbage - mainly small _pictures_ of letters, so the idiot web designer
    could have his own freakin' font, in multiple sizes and colors. WTF???

    >Also the ISP seems to drop the connection much quicker if you don't use
    >a small MTU. With a 1500 packet size, it will dial out about every two
    >minutes. With the smaller MTU size I can stay connected 5 to 10 hours
    >at a time.


    I must say I've never seen that problem.

    >When issues arise, it's problematic in that nothing changed on this end.


    Are you dialing the same number? Your posting IP is changing significantly
    and belongs to a point-of-presence provider (Level3). It's not at all
    unusual to see the systems at the other end of the wire configured
    differently, even when you dial the same number. I usually detect this
    by IP addresses, or the options that ppp negotiates.

    Old guy

+ Reply to Thread
Page 1 of 2 1 2 LastLast