LAF is enabled by default and it is a global-ipsec-config command - not interface-based. If memory serves, it had to be turned-off(crypto ipsec fragmentation after-encryption) in the days when crypto-maps had to be applied to both tunnel&physical ints. to make ipsec work(..a throwback to remnants-of-CET) Essentially, the ipsec-sa-path mtu would initialize to the lower of the two - tunnel int and physical int; there by causing *un-necessary* fragmentation of mtu/near-mtu sized packets - once *before* encryption and *again* after encryption.
...the *results* obviously were undesirable. ./Randy --- On Sun, 8/28/11, Andrew Jones <[email protected]> wrote: > From: Andrew Jones <[email protected]> > Subject: RE: [c-nsp] Input errors on GRE tunnel interface > To: "Randy" <[email protected]>, "[email protected]" > <[email protected]>, "Ranjith R" <[email protected]> > Date: Sunday, August 28, 2011, 4:33 PM > Make sure you have the following > command on the WAN interfaces: > > crypto ipsec fragmentation before-encryption > > This ensures you only fragment the packet once, instead of > twice, ie without it the router fragments the packet to fit > into the interface mtu, then encrypts it, which then may > require further fragmentation due to the new overheads. > > Cheers, > > Andrew Jones > Alphawest > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] > On Behalf Of Randy > Sent: Monday, 29 August 2011 8:07 AM > To: [email protected]; > Ranjith R > Subject: Re: [c-nsp] Input errors on GRE tunnel interface > > The only thing that is obvious is that you haven't > accounted for the ipsec and gre overheads correctly - ie, > the need to clear df-bit. > > There isn't any such thing as an ideal-mtu. The idea is to > make sure that the the mtu of original packet(payload+tcp > header+ip header) + ipsec-overhead+gre overhead does not > exceed the mtu of the physical interface(not counting the > link-layer header). > > GRE encap will add 24 bytes by default (20 byte ip header + > 4 byte gre header. > enable checksumming will add 4 bytes to above(2byte for > checksum and 2 bytes offset) > add tunnel-keys and that is 4 more bytes. > top it off with sequencing and voila: 4 more bytes. > > IPSEC: > assuming esp-des/3des and md5/sha auth: > > 4 byte SPI+4 byte seq#+8byte IV + pad(variable: > 0-7bytes)+12 bytes(auth) > > assuming esp-aes and md5/sha auth: > > 4 bytes SPI+ 4 byte seq# + 16 byte IV + > pad(variable:0-15bytes) + 12 byte(auth) > > The pad-bytes are required to ensure the pad-length(1 > byte)+next-header(1 byte are right aligned to the 2 byte > boundary. > Pad-bytes are also required to ensure > what-is-being-encrypted(payload+pad-length+next-header) is > an even multiple of 8(des/3/des) or 16(aes) > > As you can probably tell by now; your ideal-mtu and mss > depend on your configuration. > > Overhead for NAT, tcp-options not-included. > > Enough about overheads. WRT throughput - is your > encryption/decryption happening in hardware(AIM-SSL-VPN as > an example..on your 2821) or is it software based. > > Perhaps if you post your configs, you will get useful > pointers from the list. > ./Randy > > --- On Sun, 8/28/11, Ranjith R <[email protected]> > wrote: > > > From: Ranjith R <[email protected]> > > Subject: Re: [c-nsp] Input errors on GRE tunnel > interface > > To: [email protected] > > Date: Sunday, August 28, 2011, 8:55 AM > > Hi All , > > > > > > Could you please provide inputs on this . > > > > Thanks, > > Ranjith > > > > On Sat, Aug 27, 2011 at 11:04 PM, Ranjith R <[email protected]> > > wrote: > > > > > Hi All , > > > > > > As part of a Failover scenario we have the > below > > setup. > > > > > > R1 ( VPN router ) ----- R2 ---------GRE tunnel > > ------------- R3 ( > > > internet router ) ------- Internet > > > > > > GRE tunnel is built over a WAN link which > > supports only 1500 Bytes . > > > > > > We observe high input drops on the physical > > interface of R2 and hight > > > input queue drops on the tunnel interfaces of R2 > and > > R3 routers . On R3 PBR > > > is in place for clearing the DF bit for all > packets > > hitting the physical > > > interface of GRE tunnel without which we face > > connectivity issues for > > > endusers who make use of IPSEC VPN for connecting > to > > client. > > > > > > R1 - cisco 2821 and R3 - Cisco 2911 . > > > > > > There is also high CPU usage on R2 which i > beleive is > > due to the > > > fragmentation / re-assembling happening .What > > should be the ideal IP MTU > > > and MSS value which could cause minimal > fragmenation > > with the current > > > scenario ? > > > > > > Also if we acheive a higher MTU support on the > WAN > > link can we acheive a > > > better performance and lower CPU usage ? > > > > > > > > > Kindly share your thoughts on why the input > queue > > errors are increasing on > > > the tunnel interface . > > > > > > > > > Thanks, > > > Ranjith > > > > > > > > > > > > > > _______________________________________________ > > cisco-nsp mailing list [email protected] > > https://puck.nether.net/mailman/listinfo/cisco-nsp > > archive at http://puck.nether.net/pipermail/cisco-nsp/ > > > > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
