From: Timo Teras <timo.teras@iki.fi>
To: Hannes Frederic Sowa <hannes@stressinduktion.org>
Cc: netdev@vger.kernel.org
Subject: Re: ip_forward_use_pmtu and forwarding to xfrm'ed gre
Date: Wed, 8 Jul 2015 21:51:56 +0300 [thread overview]
Message-ID: <20150708215156.7007eb09@vostro> (raw)
In-Reply-To: <1436377198.3846.46.camel@stressinduktion.org>
Hi,
On Wed, 08 Jul 2015 19:39:58 +0200
Hannes Frederic Sowa <hannes@stressinduktion.org> 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 <hannes@stressinduktion.org> wrote:
> >
> > > On Wed, 2015-07-08 at 16:30 +0300, Timo Teras wrote:
> > > If above idea does not work, we could simply add an option to gre
> > > driver to set skb->ignore_df, but I don't like that much.
> >
> > This is not acceptable. The gre driver has two operating modes: DF
> > and non-DF mode (which is triggered by 'ttl inherit' or 'ttl
> > <number>' option on tunnel creation). The DF mode intentionally
> > sets DF on all tunnel packets so the pmtu is learned and relayed up
> > the stack. In non-DF mode the tunnel packets DF is derived from
> > encapsulated packet.
> >
> > Basically this info could be used. If the target is gre1 in DF
> > mode, we
> > should be trusting the pmtu. Otherwise the existing internal
> > mechanism breaks.
> >
> > Thoughts?
>
> 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 also make the exception just for GRE
interface in the DF mode. Or some sort of per-interface flag that is
set internally by the driver.
> (Although I am in favor of admins just correcting the mtu by hand and
> documenting this as you proposed earlier. I really don't know if it is
> worth the effort to propagate those information.).
The problem with GRE + DF is that the internal packet is no-DF and
potentially fragmented, but the tunneled packets (fragments) do have DF
set. So no interim router can defrag+frag if needed. This means pmtu
must be honored. And on nbma gre tunnels (target tunnel address depends
on encapsulated packet's address) the path mtu needs to be propagated
back to the sender.
In this configuration ip_forward_use_pmtu needs to be enabled (system
wide, per-interface config, or implicitly by interface flags). Or
alternatively the trusted pmtu needs to be propagated via alternate
mechanism. But that might be quite tricky to implement.
I believe other tunnels have similar mechanism. E.g. ipip tunnels seems
to share same DF vs. non-DF mode based on 'ttl' setting.
next prev parent reply other threads:[~2015-07-08 18:52 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-08 13:30 ip_forward_use_pmtu and forwarding to xfrm'ed gre Timo Teras
2015-07-08 15:52 ` Hannes Frederic Sowa
2015-07-08 16:17 ` Timo Teras
2015-07-08 17:39 ` Hannes Frederic Sowa
2015-07-08 18:51 ` Timo Teras [this message]
2015-07-09 14:48 ` Timo Teras
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=20150708215156.7007eb09@vostro \
--to=timo.teras@iki.fi \
--cc=hannes@stressinduktion.org \
--cc=netdev@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).