Jim Brown wrote: > > I belong to the CheckPoint list server and a very similar > discussion is > happening over there referencing Outlook over a VPN between > CheckPoint > firewalls. > > Could this problem be related to Tunnel overhead and packet > fragmentation? > > I think this might be a problem with Microsoft's implementation > of the > TCP/IP stack and large packets over 1500 MTU.
Earlier in the discussion, we doubted this because why would just Outlook have a problem? E-mail is less likely to be large than HTTP, FTP, extended pings, etc. But there does seem to be a lot of anectdotal evidence that MTU is somehow related, so maybe worth testing. More below..... > Outlook might not > be very > happy with fragmentation. > > There is a registry setting for the end station that forces the > MTU to > 576 for any packets not destined for the local subnet. > > This is cut and pasted from > http://support.microsoft.com/default.aspx?scid=kb;EN-US;q314053 > > EnablePMTUDiscovery > Key: Tcpip\Parameters > Value Type: REG_DWORD - Boolean > Valid Range: 0,1 (False, True) > Default: 1 (True) Interesting that this is TRUE by default. Explains the fact that most traffic seems to have the DF bit set. They set the DF bit, never get back an ICMP Frag Needed But DF Bit Set, so just keep sending with that size and never bother to unset the DF bit. > Description: Setting this parameter to 1 (True) causes TCP to > attempt to > discover the Maximum Transmission Unit (MTU or largest packet > size) over > the path to a remote host. By discovering the Path MTU and > limiting TCP > segments to this size, TCP can eliminate fragmentation at > routers along > the path that connect networks with different MTUs. > Fragmentation > adversely affects TCP throughput and network congestion. > Setting this > parameter to 0 causes an MTU of 576 bytes to be used for all > connections > that are not to computers on the local subnet. > > EnablePMTUBHDetect > Key: Tcpip\Parameters > Value Type: REG_DWORD - Boolean > Valid Range: 0,1 (False, True) > Default: 0 (False) > Description: Setting this parameter to 1 (True) causes TCP to > try to > detect "Black Hole" routers while doing Path MTU Discovery. A > "Black > Hole" router does not return ICMP Destination Unreachable > messages when > it needs to fragment an IP datagram with the Don't Fragment bit > set. TCP > depends on receiving these messages to perform Path MTU > Discovery. With > this feature enabled, TCP will try to send segments without the > Don't > Fragment bit set if several retransmissions of a segment go > unacknowledged. If the segment is acknowledged as a result, the > MSS will > be decreased and the Don't Fragment bit will be set in future > packets on > the connection. Enabling black hole detection increases the > maximum > number of retransmissions performed for a given segment. > > Anyone willing to modify their end station to force an MTU of > 576 and > discovery of "blackholes" and report the results. That wouldn't be the logical test. There's no need to discover black holes unles MTU discovery IS used. So two tests to try would be: 1) MTU discovery off (which forces all packets to be 576 bytes, which would be awful for performance, but OK for a test) Black hole discovery off (irrelevant, but might as well be off) and MTU disocvery on Black hole discovery on also > > It would be most insightful to see the pre and post registry > network > sniffer traces of Outlook traffic. I agree that sniffer traces are probably going to be necessary to debug this problem! I look forward to hearing a resolution. Gotta get back to work, myself, though. ;-) _______________________________ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com > > I don't have time now, but I think this could be the issue. I > think it > may be an end station problem. > > > -----Original Message----- > From: Larry Letterman [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 02, 2002 7:58 PM > To: [EMAIL PROTECTED] > Subject: Re: Confused about MTU size [7:54689] > > > I had the same issue with outlook, its real slow when accessing > Imap > mail. I set the MTU, adjusted other > things, etc..nothing seems to fix this issue for me. I set up > Netscape > 6.2x messenger/mail. Installed the > mail client for Imap mail, and it works fine...sometimes it > hangs for a > second or two, but not anything like > outlook.... > > Larry > > Creighton Bill-BCREIGH1 wrote: > > >I may be way out of line, but there aren't any access lists > which may > be > >prohibiting the IMAP ports used by exchange, are there. I ran > into a > config > >mess with DMZ's and access lists for a beta product test once. > And that > was > >what we saw - all worked (http, proxy, etc.) but Exchange was > gone. > Turned > >out to be some Checkpoint and access-list tweaking. > > > > > >-----Original Message----- > >From: JohnZ [mailto:[EMAIL PROTECTED]] > >Sent: Wednesday, October 02, 2002 5:43 PM > >To: [EMAIL PROTECTED] > >Subject: Re: Confused about MTU size [7:54689] > > > >Thanks Priscilla, I definitely don't mind even if it was > criticisim > >especially coming from some one of your caliber. Thank you for > the > pointers > >and I will do some more deligant troubleshooting. And yes Mike > it is > outlook > >that refuses to work properly. There is no problem browsing, > home user > is > >able to copy files of all sizes with out any problems. We can > ping the > email > >server from the user's workstation heck I am even pc-anwhered > into his > >machine. But as soon we start outlook it just hangs. I will > further > >investigate the router's config although it's using a template > that's > >working elsewhere under different service provider without a > hitch. > >""Priscilla Oppenheimer"" wrote in message > >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > >>I agree that it doesn't sound like an MTU problem. There are > often > >> > >problems > > > >>with MTU when DSL, VPNs, tunnels, etc. are used, so people > might jump > to > >>that conclusion. But e-mail messages are often very short and > would > easily > >>fit into most MTUs even after overhead. To test whether it's > an MTU > >> > >problem, > > > >>try some oversized pings. > >> > >>The MTU issue occurs when a full-sized packet arrives at an > interface > that > >>needs to squeeze it into an MTU along with the overhead. The > interface > >> > >could > > > >>fragment, but maybe the application or transport layer set > the Don't > >>Fragment bit. Quite a few applications do that as part of > their MTU > >>discovery process. The problem is made worse if there's an > access list > >> > >that > > > >>is blocking the ICMP "Fragmentation required but DF bit set" > message. > >> > >>Here's a Cisco article on MTU: > >> > >>http://www.cisco.com/warp/public/105/56.html > >> > >>This isn't a criticism of the original poster, who was already > doubting > >> > >the > > > >>people who told him it was an MTU problem, but it does give > me a > chance to > >>get on my soapbox about troubleshooting methods. A lot of > people > >>troubleshoot using the technique we learned in grade school > to match > items > >>from Column A with items from Column B. ;-) Column A has > network types > and > >>Column B has most common problem for network type. It's > important to > know > >>about common problems, but it's just as important to gather > data, > research > >>symptoms, and use logic and reasoning. > >> > >>Cisco's troubleshooting method really does work: > >> > >>1. Define the problem. > >>2. Gather facts. > >>3. Consider possibilities. > >>4. Create an action plan. > >>5. Implement the action plan. > >>6. Observe the results. > >>7. Do problem symptoms stop? > >> > >>If no, go back to 4 or possibly to 2. > >>If yes, problem resolved, document the results. > >> > >>OK, off my soapbox now! :-) > >> > >>_______________________________ > >> > >>Priscilla Oppenheimer > >>www.troubleshootingnetworks.com > >>www.priscilla.com > >> > >>[EMAIL PROTECTED] wrote: > >> > >>>I found email to be a touchy thing... Especially when > dealing > >>>with M$ > >>>0utlook. Are you sure it's the MTU size that's the problem > >>>with email. > >>> > >>>I know in our situation, I had to add the mail server name & > IP > >>>to the host > >>>file of the remote pc. Some times we experience some > latency, > >>>but for the > >>>most part it's only been about half a minute. > >>> > >>>Cheers, > >>>mkj > >>> > >>>-----Original Message----- > >>>From: JohnZ [mailto:[EMAIL PROTECTED]] > >>>Sent: Tuesday, October 01, 2002 8:55 PM > >>>To: [EMAIL PROTECTED] > >>>Subject: Confused about MTU size [7:54689] > >>> > >>> > >>>Can some one explain clearly how does MTU size affect windows > >>>applications > >>>where these applications won't work over a network link. I > have > >>>a certain > >>>home user that can establish a vpn tunnel through a DSL to > >>>corporate network > >>>and all applications will work except for email. The only > >>>difference is a > >>>cisco router in between the homeuser and corporate network. > >>>Without this > >>>cisco router (with homeuser directly attached to DSL modem) > >>>there are no > >>>problems. Some one mentioned MTU could be the problem, but if > >>>the frames are > >>>larger then MTU don't they get fragmented and re-assembled at > >>>the other end. > >>>How could MTU size fail single application while everything > >>>else works fine. > >>>Thanks for any help. > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=54821&t=54689 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
