It's good that we're getting a discussion going on this. We all understand the theory. The real question is an operational one. Is it worth the trouble to configure every host for a lower MTU? In his case, he doesn't need to, as it is working, albeit with fragmentation, but should he do it in order to improve efficiency, reduce link utilization, increase throughput? Is it worth the tradeoff?
DoctorTCP sounds intriguing but I don't think it would reduce the management hassle too much, though I don't know much about it. One final comment: I'm surpised that MTU Discovery isn't the default for most applications. I would have thought it was. Good point about the need to allow the ICMP Frag Needed But DF Bit Set message back in through firewalls if you are doing MTU Discovery. Priscilla One testlab wrote: > > Hi Garret, > > I've some experience of this also. With TCP, the "don't > fragment bit is set" > so when a 1500 byte frame hits the VPN tunnel, the VPN device > sends an ICMP > message back to the host saying "I need to fragment your packet > but you are > telling me not to fragment" because it needs to add extra > header. The host > will then try a lower MTU until the packet gets through. This > is how "MTU > path discovery works". This relies on your hosts (or IP stack) > supporting > MTU discovery and also upon ICMP messages being allowed back to > your host > (firewall?). If you have both of these then you are laughing > and we have > gotten away with this more often that not. If not you might > have to manually > reduce the MTU down on their hosts and/or Proxy Server using > something like > DoctorTCP. > > Regards > > ""garrett allen"" wrote in message > news:[EMAIL PROTECTED] > > just finished an 8 city (3 u.s./5 e.u.) vpn deployment. we > were in a > > bit of a rush and now that we have finished the initial > deployment we > > have the luxury of time to think things through a little more > > clearly. one oversight that we made in our haste to deploy > we just > > confirmed - the overhead associated with ipsec is causing > packet > > fragmentation for packets exiting one location and destined > for > > another over the vpn tunnels. i don't have the traces in > front of me > > but we did run a trace on an ftp session and confirmed it. > on an ftp > > session between vpn locations you see the following pattern > of packets > > received on the destination network: > > packet 1 - 1460 bytes > > packet 2 - 120 bytes > > packet 3 - 1460 bytes > > packet 4 - 120 bytes > > &c. > > > > they probably started life as 1500 bytes, the ipsec overhead > forced a > > fragment, which appears as the second, smaller packet. the > solution > > is to make all host mtu's slightly smaller, say 1460. this > avoids > > fragmentation and results in an actual wan bandwidth savings > of > > something like 3-5%, although it appears counter intuitive. > the > > question i have is this - is it worth it to adjust each hosts > mtu and > > take on that task? what are considered operational best > practices - > > optimize wan or lan packet sizes and throughput. take on > more server > > administration or ... given the recent thread on the death of > design > > maybe the issue is moot? > > > > thanks in advance for your insights. now, if i could just > remember > > how to enable the hub ports on a 2507 ... > > > > cheers! > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=69893&t=69739 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
