[c-nsp] Input errors on GRE tunnel interface

[Andrew Jones]

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/