[c-nsp] Input errors on GRE tunnel interface
Randy
randy_94108 at yahoo.com
Sun Aug 28 18:07:18 EDT 2011
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/
>
More information about the cisco-nsp
mailing list