From: Stephen Suryaputra <ssuryaextr@gmail.com>
To: netdev@vger.kernel.org
Subject: GRE non-zero TTL and DF=1
Date: Tue, 18 Jan 2022 16:33:04 -0500 [thread overview]
Message-ID: <20220118213248.GA12520@ICIPI.localdomain> (raw)
Hi,
I'm trying to pinpoint the exact scenario that is being prevented by the
decision to set DF=1 when the tunnel parameter ttl is non-zero, i.e. in
this code snippet:
int ip_tunnel_ctl(struct net_device *dev, struct ip_tunnel_parm *p, int cmd)
{
...
switch (cmd) {
...
case SIOCADDTUNNEL:
case SIOCCHGTUNNEL:
...
if (p->iph.ttl)
p->iph.frag_off |= htons(IP_DF);
...
}
...
}
There is a comment in ip_gre.c that it is to prevent recursive network
loop:
"One of them is to parse packet trying to detect inner encapsulation
made by our node. It is difficult or even impossible, especially,
taking into account fragmentation. TO be short, ttl is not solution at all.
Current solution: The solution was UNEXPECTEDLY SIMPLE.
We force DF flag on tunnels with preconfigured hop limit,
that is ALL. :-) Well, it does not remove the problem completely,
but exponential growth of network traffic is changed to linear
(branches, that exceed pmtu are pruned) and tunnel mtu
rapidly degrades to value <68, where looping stops.
Yes, it is not good if there exists a router in the loop,
which does not force DF, even when encapsulating packets have DF set.
But it is not our problem! Nobody could accuse us, we made
all that we could make. Even if it is your gated who injected
fatal route to network, even if it were you who configured
fatal static route: you are innocent. :-)"
It seems to read that when there is a fragmentation, the inner
encapsulation is lost of non-first fragments, but my problems are:
1) I don't see where the inner encapsulation by the self node is being
detected.
2) I don't understand how the tunnel mtu can degrades. In the case of
looping, the mtu stays the same and packet is being recursively
encapsulated and in the end the packets contain only the headers, but
it's still looping forever (in the absence of the detection in (1)).
3) If (1) exists, then I think the looping is finite, e.g. eventually
the node that tunnels will detect itself even in the presence of
fragmentation because the non-first fragments is GRE encapsulated by the
self node again.
Any example topology and scenarios that can shed lights into what the
comment concerns about? What am I missing?
Thanks,
Stephen.
reply other threads:[~2022-01-18 21:33 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20220118213248.GA12520@ICIPI.localdomain \
--to=ssuryaextr@gmail.com \
--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