At 4:57 PM +0000 5/29/03, Priscilla Oppenheimer wrote: >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.....
The behavior below is to be expected with tunnels present. Indeed, you can't necessarily rely on manually setting the MTU to avoid fragmentation, if your path takes you through other organizations that might be doing their own tunneling. Fragmentation is almost always bad. The only time I ever deliberately introduced it was in a third world environment with extremely bad lines, with poor LAP-B throughput even at the IP MTU minimum. I had to turn on the X.25 packet layer above LAP-B to get additional fragmentation down to 128 bytes--a very special case. It's bad not so much due to the additional packets created and the small additional amount of bandwidth they create. There are other reasons it's bad for both routers and hosts. Routers have to work harder to fragment, computing new headers, buffering the fragments while the earlier fragments go out, etc. Depending on your IOS and platform, it definitely can put you into a slower forwarding path -- sometimes process switching, sometimes fast switching. The path has much to do with the assumptions of switching modes about the relationship between input and output packet buffers. See "Inside Cisco IOS Architecture" for further detail. Fragments also take more work for the host to reassemble, and, because they may interleave with fragments of other packets, can cause more out-of-sequence delivery. The best way to avoid fragmentation is to use MTU Path Discovery in the end hosts. http://www.isi.edu/in-notes/rfc1191.txt. > >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 complaints >really 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's >point 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). Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=69815&t=69739 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
