Hello,
On Wed, 8 Jul 2015 21:51:56 +0300
Timo Teras wrote:
> On Wed, 08 Jul 2015 19:39:58 +0200
> Hannes Frederic Sowa wrote:
> >
> > At least we know which interface the packet would leave. Should we
> > override this behavior on a per-interface basis?
>
> That would be one option. We could
Hi,
On Wed, 08 Jul 2015 19:39:58 +0200
Hannes Frederic Sowa wrote:
> On Wed, 2015-07-08 at 19:17 +0300, Timo Teras wrote:
> > On Wed, 08 Jul 2015 17:52:32 +0200
> > Hannes Frederic Sowa wrote:
> >
> > > On Wed, 2015-07-08 at 16:30 +0300, Timo Teras wrote:
> > > If above idea does not work, we
Hello,
On Wed, 2015-07-08 at 19:17 +0300, Timo Teras wrote:
> On Wed, 08 Jul 2015 17:52:32 +0200
> Hannes Frederic Sowa wrote:
>
> > On Wed, 2015-07-08 at 16:30 +0300, Timo Teras wrote:
> > > This probably is due to the way how the xfrm+gre work together. On
> > > first packet, the gre tunnel dr
On Wed, 08 Jul 2015 17:52:32 +0200
Hannes Frederic Sowa wrote:
> On Wed, 2015-07-08 at 16:30 +0300, Timo Teras wrote:
> > This probably is due to the way how the xfrm+gre work together. On
> > first packet, the gre tunnel driver updates pmtu for the inner flow,
> > which is expected to be honored
Hello,
On Wed, 2015-07-08 at 16:30 +0300, Timo Teras wrote:
> Hi,
>
> It seems ip_forward_use_pmtu commit log says:
> Tunnel and ipsec output paths clear IPCB again, thus
> IPSKB_FORWARDED
> won't be set and further fragmentation logic will use the path mtu
> to determine the fragmen