Netdev List
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Marco Berizzi <pupilla@hotmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: ipsec tunnel asymmetrical mtu
Date: Tue, 11 Jul 2006 16:42:32 +1000	[thread overview]
Message-ID: <20060711064232.GA1490@gondor.apana.org.au> (raw)
In-Reply-To: <BAY103-F290B963EE35123CC2E6DB8B2BE0@phx.gbl>

Hi Marco:

On Mon, Apr 24, 2006 at 09:23:00AM +0000, Marco Berizzi wrote:
> 
> What should I do? Mangling MSS with iptables  --set-mss ?
> Altering MSS to 1440 did the trick. See:
> http://marc.theaimsgroup.com/?l=linux-netdev&m=114373067423528&w=2

Yes that's enough, although proper PMTU would be better.
 
> and here is snmp when the sapgui client has told me that the
> connections has been reset:
> 
> root@Mimosa:/var/log# cat SNMP-CONN-RESET
> Ip: Forwarding DefaultTTL InReceives InHdrErrors InAddrErrors ForwDatagrams 
> InUnknownProtos InDiscards InDelivers OutRequests OutDiscards OutNoRoutes 
> ReasmTimeout ReasmReqds ReasmOKs ReasmFails FragOKs FragFails FragCreates
> Ip: 1 64 79257 0 31 48139 0 0 38799 56650 2 0 2 182 90 2 90 0 124

OK, the number of reassemblies equals the number of FragOKs.  So it does
not look like there is a problem within mimosa, i.e., Linux.

I've looked at your packet dumps again and in fact there is not qualitative
difference between WITHTCPDUMP and WITHOUTTCPDUMP.  What is different is
that the latter seems to have experienced a higher packet loss rate at an
early stage and therefore the sender has already backed off to a very long
retry period.

The fact that tcpdump makes a difference could simply be that it changes
the timing of the fragment tramissions on mimosa which has an impact on
the loss rate between mimosa and pleiadi.

We can say these things for certain:

1) The path between mimosa and pleiadi has a packet loss problem.  A small
   burst of 10 or so fragments is enough to cause at least half of them to
   be lost.  This problem may be specific to IPsec traffic (ISPs often
   discriminate against traffic with protocols other than TCP/UDP).

2) Fragmentation exacerbates the packet loss problem because it increases
   the number of packets and a packet is lost if only one of its fragments
   is lost.

3) The fact that the TCP connections are not using PMTU causes fragmentation
   in the presence of IPsec.

>From what I've seen, there does not appear to be a bug in Linux that could
explain the behaviour change that is seen when you run tcpdump.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

  parent reply	other threads:[~2006-07-11  6:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <BAY103-F21399F30719D1EBD180B04B2CC0@phx.gbl>
2006-04-23  3:51 ` ipsec tunnel asymmetrical mtu Herbert Xu
2006-04-24  9:23   ` Marco Berizzi
2006-04-24  9:26     ` Marco Berizzi
2006-04-26 10:55     ` Herbert Xu
2006-04-26 12:20       ` Marco Berizzi
2006-07-11  6:42     ` Herbert Xu [this message]
2006-07-11  8:31       ` Marco Berizzi
2006-07-11  9:22       ` Marco Berizzi
2006-07-11 10:42         ` Herbert Xu
2006-07-11 10:32       ` Marco Berizzi
2006-07-11 11:54         ` Herbert Xu
2006-05-08  8:28   ` Marco Berizzi
2006-05-18  8:46     ` Marco Berizzi
2006-06-09  8:04       ` Marco Berizzi
2006-06-27  6:45       ` Marco Berizzi
2006-06-27  8:37         ` Herbert Xu
2006-07-11  7:59     ` Herbert Xu
2006-07-11  9:00       ` Marco Berizzi
2006-07-11  9:31         ` Marco Berizzi
2006-07-11 11:21           ` Herbert Xu
2006-07-11  9:48       ` Marco Berizzi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060711064232.GA1490@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=netdev@vger.kernel.org \
    --cc=pupilla@hotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox