From: Alarig Le Lay <alarig@swordarmor.fr>
To: lartc@vger.kernel.org
Subject: Does the kernel takes the source address in account while triggering pmtudisc on gre tunnels?
Date: Fri, 26 Feb 2021 13:26:30 +0000 [thread overview]
Message-ID: <20210226132630.GF11371@irc-clt.no.as208627.net> (raw)
Hi,
I have a setup with two tables:
* The GRT for all the traffic and the fullview
* Another table with specific routes for GRE tunnels and OOB-ish
fallback
I’m not using VRFs, just `ip rules`. I’m running an IGP inside the GRE
tunnels (with bird).
It seems to me that Linux isn’t taking the source IP of the tunnels when
looking to the MTU to use, and that the pmtudisc is triggered each time
the route in the GRT is updated.
(For reasons), I have the endpoint route for some tunnels in both the
GRT and the specific table, as this bird output shows:
bird> show route all primary 2001:4640:a14f::2/128 table all
Table master6:
2001:4640:a14f::2/128 unicast [ospf_ipv6 13:45:17.496] E2 (150/26/10000) [45.91.126.96]
via fe80::18f3:7bff:fe0b:ce21 on gre6
Type: OSPF-E2 univ
igp_metric: 26
OSPF.metric1: 26
OSPF.metric2: 10000
OSPF.tag: 0x00000000
OSPF.router_id: 45.91.126.96
Table t6_as62240:
2001:4640:a14f::2/128 unicast [static_tinc_endpoints_ipv6 2020-12-25] * (200)
via 2a0f:9440:1:49::1 on enp1s0
Type: static univ
bird>
The route is well pushed on all the tables:
edge08-clouvider ~ # ip -s -d r g 2001:4640:a14f::2
unicast 2001:4640:a14f::2 from :: via fe80::200:5efe:b975:5804 dev gre3 table main proto bird scope global src 2a0e:f42:fffe:1::20 metric 32 users 2 age 211sec pref medium
edge08-clouvider ~ # ip -s -d r g 2001:4640:a14f::2 from 2a0f:9440:1:49::2
unicast 2001:4640:a14f::2 from 2a0f:9440:1:49::2 via 2a0f:9440:1:49::1 dev enp1s0 table 62240 proto bird scope global src 2a0f:9440:1:49::2 metric 32 users 2 age 5446752sec pref medium
However, a tunnel ending on 2001:4640:a14f::2 will have it’s MTU changed
if the first route is updated even if the last one is actually used,
e.g.:
edge08-clouvider ~ # ip l sh gre6
13: gre6@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1424 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/gre6 2a0f:9440:1:49::2 peer 2001:4640:a14f::2
alias Core: core02
Thus, causing the OSPF neighbor (at the other side of the tunnel) being
stuck in ExStart state.
My rules are very simple, I’m just looking at the source address to
choose the table to use:
edge08-clouvider ~ # ip -6 ru sh
0: from all lookup local
32765: from 2a0f:9440:1:49::/126 lookup 62240
32766: from all lookup main
I want all the traffic to use the GRT, except when it’s sourced from an
IP on the physical interface used for GRE tunnels.
As the route from the table 62240 is very stable (age 5446752sec), the
pmtudisc shouldn’t be triggered if the route from the GRT is updated.
Putting `ip link set gre6 mtu 1448` in a cron is sufficient to work
around the issue, but it’s very dirty.
--
Alarig
reply other threads:[~2021-02-26 13:26 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=20210226132630.GF11371@irc-clt.no.as208627.net \
--to=alarig@swordarmor.fr \
--cc=lartc@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 read-only IMAP folder(s) and NNTP newsgroup(s).