I am interested to know what are the applications out there that sets the DF bit . Does anybdy know and common ones ? The reason for this is because I want to run LFI on my router for the purpose of VoIP. If I understand how LFI works, it will "chop" up large data packets so as to reduce possible jitter. If there are critical applications that don't allow fragmentation, my guess is LFI would cause the packets to be dropped. I don't want that to happen. Any suggestions what I could do besides throwing BW at the equation and turning off LFI altogether ?
Schwantz ""Jim Brown"" wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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. 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) > 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. > > It would be most insightful to see the pre and post registry network > sniffer traces of Outlook traffic. > > 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=54803&t=54689 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
