(Message mtu:14) Date: 02 Dec 1997 20:19:11 GMT From: Marc Slemko Newsgroups: comp.dcom.sys.cisco Subject: Re: Cannot reach sites with MTU<1500 X-Return-Path: dhesi@rahul.net X-Nojunk-Status: OK 0 Organization: WorldGate Inc. http://www.worldgate.com/ References: <880958743.6326@news.Colorado.EDU> <65ttqn$37e$1@samba.rahul.net> <65uar9$m94$1@news.ibm.net.il> <65unj9$6dv$1@scanner. ***worldgate.com> <661jjm$si1$1@samba.rahul.net> Nntp-Posting-Host: valis.worldgate.com Xref: samba.rahul.net comp.dcom.sys.cisco:41112 In <661jjm$si1$1@samba.rahul.net> c.c.eiftj@65.usenet.us.com (Rahul Dhesi) writes: >I will summarize what I have seen here to so far. Somebody >please correct me if I am wrong. >SCENARIO >- Remote server sends a packet with DF (don't fragment) bit set, in an > attempt to do MTU discovery. Correct, except that either side can try PTMU discovery; often (eg. some HTTP requests) the data sent from the client to the server is small enough that it doesn't matter. I will call them client and server for ease of reference, with the server trying PMTU discovery. >- Client side sees that its MTU is smaller than packet size, responds > with ICMP type 3 code 4 (destination unreachable, fragmentation > needed but DF bit set). - ICMP packet is filtered out at server > end, so server times out waiting for response. Some router between one box and the other sends this. It can not be the client because if it got to the client then the MTU couldn't be too small. In the case of a PPP connection with a low MTU at one end, it will often be the termserv that the client is connected to that would be sending this. >HOW TO DIAGNOSE >- Analyze packets arriving from remote, see if you get one with DF bit set. That is a start, and normally a very good indication that the other end is trying PMTU discovery. >- Ping remote site, see if pings seem to be blocked. Sometimes, but not always. There are other possible causes for this; eg. having a router with an interface using a private address for sending the ICMPs with the remote site filtering traffic from private addresses. If you have access to both ends, you will be able to see a "large" packet with the DF bit set sent from one end, yet it won't arrive at the other end and you won't get an ICMP can't fragment. >HOW TO FIX >- Set MTU at 1500, so we never have to fragment incoming packets Workaround, not fix. If _any_ MTU between you and the other end is too small you will have trouble. This can fix the symptoms, but not the problem. In some cases, that may be good enough for you. >OR >- Advertise a suitable MSS, such that remote will never send a > packet that is too big. Again, this doesn't hold because it is actually any router in between the two that can have a MTU too small for the packet. You can not, in general, set any MTU on the client that will be efficient and still leave zero chance of fragmenting. In some cases, with a known path, you can set a reasonable MTU that will avoid most problems. The only real solution is to find out why the ICMP can't fragment isn't getting back to the server and fix that. This is one of the reasons why blindly filtering all ICMP because some ICMP can be bad sometimes is a foolish idea. The MSS advertised should always be the appropriate MSS for the MTU of the interface the packet is leaving the client on. >Ok, now I'm a bit confused. Suppose we have a dial-up PPP client. > [ PPP client ] ====== [ terminal server ] ========> to Internet >The terminal server uses MTU=576 for the dial-in line, so if it seems a >large packet arriving from the remote web server headed for the PPP >client, it will either fragment the packet or (if the DF bit was set) >send back the ICMP "fragmentation needed" message. >But the TCP/IP connection will be between the PPP client and the remote >web server. The terminal server has no control over the MSS seen by the >remote web server -- or does it? Please educate me. How do I make the >terminal server, which has control over the MTU, make sure that the >remote web server seems the right MSS? The PPP client knows its MTU is 576. Therefore it had better advertise a MSS of 576 - 40 or else it is too dumb for words. When the server sees the MSS, it knows not to send anything that would exceed that size; if it does anyway, it is broken. NT may misbehave this way; I don't know. Unless some TCP stack at one end is broken, you should never see a problem with PTMU discvoery where increasing the MTU at the client from 576 to 1500 will fix it. You _can_ see this if the "client" is actually a router and there are other hosts downstream of it on networks with higher MTUs.