Thanks Gert, With your comments I did a little investigating, and found if I remove the virtual-assembly command the application servers now have to handle the fragmentation rather than the router. This has helped quite a bit with the CPU, I'm still having 100% burst but it is staying under 90% most of the time and the average much lower. I may "have to get a bigger boat", but I understand what is happening better.
On Thu, Feb 12, 2015 at 4:42 PM, Gert Doering <[email protected]> wrote: > Hi, > > On Thu, Feb 12, 2015 at 01:45:08PM -0500, Brian Christopher Raaen wrote: > > Currently, using Cisco 3800's. Unfortunately, because the traffic is > UDP, > > mss adjust can't be used to adjust the frame size. The fragmentation is > > unavoidable as this involves VPNs and the applications can't be adjusted > to > > try smaller sized frames. > > "unavoidable" is such a strong word... > > Like, just use bigger MTUs on the paths between the VPN routers, so the > VPN can carry full 1500 byte packets... > > > Are there any documents that show the impact for each platform? I can > find > > pps, throughput, etc... but nothing says how fragments impact things. My > > concern is that a larger router may not be any better in this particular > > regard than what I already have. > > Fragmentation is usually not that bad, reassembly on the IPSEC endpoint is. > > So your second best approach is to ensure that packets *in* the tunnel are > fragmented, so the reassembly is done on the receiving host, not the > VPN endpoint. > > gert > > -- > USENET is *not* the non-clickable part of WWW! > // > www.muc.de/~gert/ > Gert Doering - Munich, Germany > [email protected] > fax: +49-89-35655025 > [email protected] > -- Brian Christopher Raaen Network Architect Zcorum _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
