[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120716072305.GJ1869@secunet.com>
Date: Mon, 16 Jul 2012 09:23:05 +0200
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Timo Teras <timo.teras@....fi>
Cc: "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: iptables CLAMP MSS to PMTU not working?
On Mon, Jul 16, 2012 at 09:20:58AM +0300, Timo Teras wrote:
> On Mon, 16 Jul 2012 08:49:46 +0300 Timo Teras <timo.teras@....fi> wrote:
>
> > Looking at the changelog, this would likely be side effect of:
> >
> > commit 261663b0ee2ee8e3947f4c11c1a08be18cd2cea1
> > Author: Steffen Klassert <steffen.klassert@...unet.com>
> > Date: Wed Nov 23 02:14:50 2011 +0000
> >
> > ipv4: Don't use the cached pmtu informations for input routes
> >
> > At least from performance side, it would be better if CLAMPMSS to PMTU
> > would clamp to the learned, cached mtu.
>
> Actually, this is worse. Since XFRM is ignored - it breaks
> fragmentation for IPsec targets.
>
> Could this be reverted?
I did this patch to avoid to propagate learned PMTU informations.
It restores the behaviour we had before we moved the PMTU informations
to the inetpeer. Unfortunately CLAMPMSS really wants to have the PMTU
informations of an input route, which is not possible any more after
this patch.
Anyway, this patch seems to be obsolete in the net-next tree, as
the cached pmtu informations are back in the route. So we should remove
the check for an output route from ipv4_mtu() in the net-next tree.
This should bring CLAMPMSS back to work, at least for upcoming
kernel versions.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists