I've also run into something similar when I was using encrypted GRE tunnels, where both GRE and IPSec add overhead. However in this case it is slightly more complicated as the you can not use MTU path discovery and have to manually decrease MTU size.
Reason for using gre with Ipsec .. to remote sites needed to be connected securely and pass EIGRP. 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=69857&t=69739 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
