What is LFI? Sorry for my ignorance. Is it an IP thing or a data-link-layer thing?? If it's a data-link-layer thing, then it's not a problem.
The DF bit only affects IP fragmentation. As far as what applications set the DF bit, it's more common than you might think. DNS often does. Quite a few HTTP implementations set it. I just ran a capture on the network I'm on today and most of the traffic had it set! You could try a test on your network too? Maybe lots of people could try this so we could get a better idea. I think one reason that setting the DF bit is common is because IP fragmentation and reassembly is a bad idea. It causes extra work on the device doing the fragmentation and the end host that reassembles. Also, the packets remain fragmented until they reach the end host. So even though there may be some Ethernet networks in the path (even Gigabit which has its jumbo frames feature), the packets remain small. Fragmenting at the data-link-layer across a pt-to-pt virtual circuit is more efficient and less problematic. PPP and Frame Relay have features for this. _______________________ Priscilla Oppenheimer www.troubleshootingnetworks.com www.priscilla.com Schwantz wrote: > > 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=54817&t=54689 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]