thanks for the feedback. to add a little more insight, bandwidth is more expensive in de than in the u.s., so we are using adsl. our de facilities use adsl with t-1 speeds for downloads but only 160kbps for uploads. the de site in question is hosting an ftp server that u.s. users access to get data files and copy them back to the states. they are several hundred megs in size and can take 4-8 hours to complete, depending on what else is going on. it appears to be the single largest consumer of wan uplink bandwidth. there are complaints of the amount of time required to complete an ftp but the folks do understand the math ... i suggested international overnite delivery as an option as there is a point where a tape is actually faster.
the question was somewhat rhetorical. no right or wrong answer but i was interested in hearing different operational perspectives. cheers! ----- Original Message ----- From: Priscilla Oppenheimer Date: Thursday, May 29, 2003 12:57 pm Subject: RE: question on operational efficiency of vpn's [7:69739] > Good questions. I wish some others would pipe in so you would get > a bigger > sample space, but I'll pipe in since nobody else did yet! > > What do the rest of you think? The exec summary is that we're > wondering how > common it is to adjust host MTU to avoid fragmentation with VPN > and IPSec. > > See below..... > > garrett allen wrote: > > > > 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 would your goal be if you were to adjust each host's MTU? > Would it > matter much if utilization on the WAN links was reduced by 3-5%? > Are you > approaching a high utilization on the WAN links already? > > How much does throughput get affected by the fragmentation? Do you > have some > measurements before and after? I think the throughput would be > less due to > the fragmentation, but maybe not enough less to matter. How about the > response time? Although response time doesn't matter too much with a > non-interactive application, it could matter it if went way up > (which it > probably didn't though). > > Here's the most important question: Have the users noticed? Are they > complaining? If no, don't wory about it. And if yes, then are the > complaintsreally because of the fragmentation or more because of > the overhead inherent > in IPSec? > > You say you tested with FTP. Is that the application the users use > the most? > You should definitely test with their own applications. You may > find that > their favorite applications don't have the problem anyway. For > example, a > lot of HTTP implementations don't fill a 1500-byte packet anyway. > They use > shorter packets because the user's perceived performance is better if > smaller chunks of data appear on the screen quickly, rather than > waiting for > 1500 bytes at a time. > > > 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? > > Maybe if you ghost the images and there's an easy way to make the > change on > every host it might be worth it, but you have to consider whether the > benefits are worth the cost. Design is all about making tradeoffs > and it's > not dead. > > Perhaps you will decide not to make any optimization, but the fact > that you > are considering it and the tradeoffs with manageability, and making > before-and-after measurements, etc. means that you are doing > design work. > > Also, think back on the project. Didn't you do some design work before > implementing an 8 city (3 u.s./5 e.u.) VPN solution? It sounds > like you were > in a big rush so I'm sure you didn't do a full design, which was > Chuck'spoint I guess (that and building up his own confidence). On > the other hand, > it sounds to me like you didn't kill all your good instincts > regarding the > importance of planning, analysis, brainstorming, recognizing > tradeoffs,considering the consequences of decisions, understanding > users' needs (all > aspects of design). > > Priscilla > > > > > thanks in advance for your insights. now, if i could just > > remember > > how to enable the hub ports on a 2507 ... > > > > cheers! > Nondisclosure violations to [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=69825&t=69739 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
