Mailing List Archive: NANOG: users

mtu mis-match

Index | Next | Previous | View Threaded

annkok2001 at yahoo

Mar 19, 2008, 12:05 PM

Post #1 of 7 (566 views)
Permalink

mtu mis-match

Hi

I have this problem about mtu mismatch

Some DSL clients, some are working fine.
(browsing...ping ...)

Some DSL clients have this problem
they can't browse the sites.
they can ssh the host but couldn't run the command in
the shell prompt
ping packet are working fine (no packet lost)

Why?
but I still don't know why mtu can cause this problem

Thank you for your help

____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs

Jon.Kibler at aset

Mar 19, 2008, 12:28 PM

Post #2 of 7 (533 views)
Permalink

Re: mtu mis-match [In reply to]

ann kok wrote:
> Hi
>
> I have this problem about mtu mismatch
>
> Some DSL clients, some are working fine.
> (browsing...ping ...)
>
> Some DSL clients have this problem
> they can't browse the sites.
> they can ssh the host but couldn't run the command in
> the shell prompt
> ping packet are working fine (no packet lost)
>
> Why?
> but I still don't know why mtu can cause this problem
>
> Thank you for your help
>

Why do you think you have an MTU mismatch problem?

If are using a Linux box as a router, then you can set
the MTU of any interface with the ifconfig command.

Jon K.
--
Jon R. Kibler
Chief Technical Officer
Advanced Systems Engineering Technology, Inc.
Charleston, SC USA
(843) 849-8214

==================================================
Filtered by: TRUSTEM.COM's Email Filtering Service
http://www.trustem.com/
No Spam. No Viruses. Just Good Clean Email.

streiner at cluebyfour

Mar 19, 2008, 12:38 PM

Post #3 of 7 (530 views)
Permalink

Re: mtu mis-match [In reply to]

On Wed, 19 Mar 2008, ann kok wrote:

> I have this problem about mtu mismatch
>
> Some DSL clients, some are working fine.
> (browsing...ping ...)
>
> Some DSL clients have this problem
> they can't browse the sites.
> they can ssh the host but couldn't run the command in
> the shell prompt
> ping packet are working fine (no packet lost)
>
> Why?
> but I still don't know why mtu can cause this problem

Are you using PPPoE to transport and manage your DSL users, or are they
bridged?

Ping packets, unless you specifically use a larger packet size, are
usually pretty small. Try running ping tests with a larger packet size,
say, 1495 bytes, and see if those fail.

HTTP, SSH, etc, can easily (and often do) generate packets up to the
maximum segment size. That's why MTU mismatches can seem to affect some
types of traffic but not others.

The 'lowest common denominator' for MTUs is often 1500 bytes, but
protocols that need to wrap or tunnel existing packets (GRE, PPPoE, IPSEC,
etc) impose some overhead of their own. Unless the MTU or TCP maximum
segment size of the original traffic is reduced a bit, the tunneled
packets will need to be fragmented for transport across the network. This
can lead to performance problems like the ones you're seeing. The magic
number for an MTU on PPPoE DSL is 1492 bytes, based on past DSL
aggregation work I've done.

jms

pekkas at netcore

Mar 20, 2008, 1:07 AM

Post #4 of 7 (537 views)
Permalink

Re: mtu mis-match [In reply to]

On Wed, 19 Mar 2008, ann kok wrote:
> Some DSL clients, some are working fine.
> (browsing...ping ...)
>
> Some DSL clients have this problem
> they can't browse the sites.
> they can ssh the host but couldn't run the command in
> the shell prompt
> ping packet are working fine (no packet lost)

Seems like that when the first packet that exceeds MTU (I guess 1492)
on the path is sent, you get a PMTU blackhole. You will see the same
problem if you ping with big packets.

As to why some clients work and others do not -- a good question. I
have some theories on this point (different behaviour wrt setting DF
bit; no MSS clamping and some DSL clients have MTU=1492 exposed to the
user, others have a middlebox router which shows MTU=1500; some
others).

You may want to check that both ends are receiving ICMP packet too big
messages (i.e. a firewall doesn't filter them out).

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

nanog at grrrrreg

Mar 20, 2008, 2:29 AM

Post #5 of 7 (526 views)
Permalink

Re: mtu mis-match [In reply to]

On Mar 19, 2008, at 8:05 PM, ann kok wrote:

>
> Hi
>
> I have this problem about mtu mismatch
>
> Some DSL clients, some are working fine.
> (browsing...ping ...)
>
> Some DSL clients have this problem
> they can't browse the sites.
> they can ssh the host but couldn't run the command in
> the shell prompt
> ping packet are working fine (no packet lost)
>
> Why?
> but I still don't know why mtu can cause this problem
>
> Thank you for your help

Sounds like the old PPPoE issue : 1500 vs 1492.
It usually is dealt with on a per destination basis:

For a given destination (the ones that are causing problems to you)
start with :
ping -D -s 1500 <your_destination> and lower the -s value until the
ping goes through.
-D forces "don't fragment bit"
-s manages packetsize

When your ping reaches your destination, your -s size is good (for
that destination only...).

Greg VILLAIN
Independent Network & Telco Architecture Consultant

Greg VILLAIN
Independant Network & Telco Architecture Consultant
+33 6 87 48 66 14

rsk at gsp

Mar 20, 2008, 3:38 AM

Post #6 of 7 (528 views)
Permalink

Re: mtu mis-match [In reply to]

On Wed, Mar 19, 2008 at 12:05:19PM -0700, ann kok wrote:
> Some DSL clients, some are working fine.
> (browsing...ping ...)
>
> Some DSL clients have this problem
> they can't browse the sites.
> they can ssh the host but couldn't run the command in
> the shell prompt
> ping packet are working fine (no packet lost)
>
> Why?
> but I still don't know why mtu can cause this problem

Path MTU discovery failures are one of the possible causes for
what you're seeing. (For example, you can establish an ssh
connection to a host, because none of the packets exceed the
path MTU. But as soon as you run a command that generates a
substantial amount of output, the connection will appear to hang
because the remote host is repeatedly retrying to send the same
data because it doesn't see an ack while the local host is
never seeing the data because it exceeds the MTU).

This is often caused by overly-aggressive filtering of ICMP.
I recommend taking a look at

http://www.znep.com/~marcs/mtu/

as well as

http://www.cymru.com/Documents/icmp-messages.html

and then checking the configurations of network devices to
make sure that ICMP type 3 code 4 traffic isn't being blocked.

---Rsk

michael.holstein at csuohio

Mar 20, 2008, 8:30 AM

Post #7 of 7 (542 views)
Permalink

Re: mtu mis-match [In reply to]

> but I still don't know why mtu can cause this problem
>

Blocking ICMP (specifically type 3,code 4) can also cause this ..
because it breaks path MTU discovery (pmtud).

The first part of this doc helps explain the issue :

http://www.cisco.com/warp/public/105/pmtud_ipfrag.html

Cheers,

Michael Holstein
Cleveland State University

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads