[c-nsp] Input errors on GRE tunnel interface

Sun Aug 28 22:41:28 EDT 2011

perhaps you didn't read my-response in its entirety.
As mentioned before, post your configs(R1,R2,R3) publicly or privately
./Randy

From: Ranjith R <ranjithrnair at gmail.com>
Subject: Re: [c-nsp] Input errors on GRE tunnel interface
To: "Randy" <randy_94108 at yahoo.com>
Cc: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>, "Andrew Jones" <Andrew.Jones at alphawest.com.au>
Date: Sunday, August 28, 2011, 7:14 PM

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 <randy_94108 at yahoo.com> 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 <Andrew.Jones at alphawest.com.au> wrote:

> From: Andrew Jones <Andrew.Jones at alphawest.com.au>
> Subject: RE: [c-nsp] Input errors on GRE tunnel interface
> To: "Randy" <randy_94108 at yahoo.com>, "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>, "Ranjith R" <ranjithrnair at gmail.com>
> 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: cisco-nsp-bounces at puck.nether.net
> [mailto:cisco-nsp-bounces at puck.nether.net]
> On Behalf Of Randy
> Sent: Monday, 29 August 2011 8:07 AM
> To: cisco-nsp at puck.nether.net;
> 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 <ranjithrnair at gmail.com>
> wrote:
>
> > From: Ranjith R <ranjithrnair at gmail.com>
> > Subject: Re: [c-nsp] Input errors on GRE tunnel
> interface
> > To: cisco-nsp at puck.nether.net
> > 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 <ranjithrnair at gmail.com>
> > 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  cisco-nsp at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-nsp
> > archive at http://puck.nether.net/pipermail/cisco-nsp/
> >
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>