Re: mtu mis-match
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 Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: mtu mis-match
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
Re: mtu mis-match
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
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
Re: mtu mis-match
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.
Re: mtu mis-match
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
