[c-nsp] Input errors on GRE tunnel interface
Ranjith R
ranjithrnair at gmail.com
Sun Aug 28 22:14:51 EDT 2011
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/
> >
>
More information about the cisco-nsp
mailing list