Thanks Randy .
As i described earlier , the IPSEC VPN router comes behind the GRE tunnel as depicted below R1 ( VPN router ) ----- R2 ---------GRE tunnel ------------- R3 ( internet router ) ------- Internet so if i am correct , we have control only over the IPSEC packets generated from the R1 VPN router , All the return traffic from the IPSEC peer first hit the internet router and then enters the GRE tunnel to reach the R2 , and then R1. I have put a PBR on the physical interface ( for GRE tunnel ) of R3 router to clear the DF bit . I have no checksum / key enabled for GRE interface. The issue is we see lots of input drops on the GRE tunnel interface on both R2 and R3 . Thanks, Ranjith On Mon, Aug 29, 2011 at 6:41 AM, Randy <[email protected]> wrote: > 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/
