Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

flannel cross node traffic does not work with latest systemd 242 due to a race #1155

Closed
mcastelino opened this issue Jul 3, 2019 · 5 comments · Fixed by #1485
Closed

flannel cross node traffic does not work with latest systemd 242 due to a race #1155

mcastelino opened this issue Jul 3, 2019 · 5 comments · Fixed by #1485

Comments

@mcastelino
Copy link

mcastelino commented Jul 3, 2019

Expected Behavior

Cross node pod traffic should work, node to pod traffic should work across nodes.

Current Behavior

When running flannel with systemd 242+ there seems to be a race condition between flannel programming the mac address of the flannel.1 interface and systemd programming the mac address on the virtual interface. This results in all cross node traffic being dropped at layer 2 on the destination node due to incorrect destination vtep mac.

With systemd 242 the default policy is setup to be MACAddressPolicy=persistent

/usr/lib/systemd/network/99-default.link

[Link]
NamePolicy=keep kernel database onboard slot path
MACAddressPolicy=persistent

When flannel brings up the interface it programs the mac address and systemd then reprograms it again.

In the trace below you will see

clear@clr-02 ~ $ ip addr show flannel.1
4: flannel.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN group default
    link/ether d6:02:e3:df:ea:7a brd ff:ff:ff:ff:ff:ff
    inet 10.244.1.0/32 scope global flannel.1
       valid_lft forever preferred_lft forever

But the arp tables on remote nodes are setup with a different mac address d6:02:e3:df:ea:7a vs 5e:89:db:49:c6:a4

clear@clr-01 ~ $ ip neigh
10.244.1.0 dev flannel.1 lladdr 5e:89:db:49:c6:a4 PERMANENT

Looking at the netlink traces you see the mac address being changed twice, the first time by flannel and the second time to a different address by systemd based on its default policy

clear@clr-02 ~ $ sudo ip monitor all
[NETCONF]inet flannel.1 forwarding on rp_filter off mc_forwarding off proxy_neigh off ignore_routes_with_linkdown off
[NETCONF]inet6 flannel.1 forwarding off proxy_neigh off ignore_routes_with_linkdown off
[LINK]4: flannel.1: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN group default
    link/ether 5e:89:db:49:c6:a4 brd ff:ff:ff:ff:ff:ff
[LINK]4: flannel.1: <BROADCAST,MULTICAST> mtu 1450 qdisc noop state DOWN group default
    link/ether d6:02:e3:df:ea:7a brd ff:ff:ff:ff:ff:ff
[ADDR]4: flannel.1    inet 10.244.1.0/32 scope global flannel.1
       valid_lft forever preferred_lft forever

Possible Solution

  • The user can setup a specific mac address policy of MACAddressPolicy=none on the flannel* interface on each system which hides the issue, but requires node level changes
    or
  • Flannel can watch for mac address changes on the link and reprogram

Steps to Reproduce (for bugs)

  1. kubeadm init
  2. kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/62e44c867a2846fefb68bd5f178daf4da3095ccb/Documentation/kube-flannel.yml
  3. Ping pod on remote node

Context

Flannel and any flannel based network plugins stop working with systemd 242 (Canal).
This will impact other distributions when they upgrade to systemd 242 and beyond.

Your Environment

@mcastelino mcastelino changed the title cross node traffic does not work with latest systemd 242 due to a race flannel cross node traffic does not work with latest systemd 242 due to a race Jul 3, 2019
@andreaskaris
Copy link

Here's a quick documentation of the workaround (at least this worked in my lab):

cat<<'EOF'>/etc/systemd/network/10-flannel.link
[Match]
OriginalName=flannel*

[Link]
MACAddressPolicy=none
EOF

After this, I rebooted my controllers and workers and flannel's overlay worked.

margamanterola pushed a commit to flatcar-archive/coreos-overlay that referenced this issue Apr 8, 2020
When setting up flannel interfaces, use MACAddressPolicy=none, so that
the MAC Address used is the one set by flannel and not the one assigned
by systemd.

See flannel-io/flannel#1155 for more information.
margamanterola pushed a commit to flatcar-archive/coreos-overlay that referenced this issue Apr 8, 2020
When setting up flannel interfaces, use MACAddressPolicy=none, so that
the MAC Address used is the initial one set by the kernel and not the
one assigned by systemd.

See flannel-io/flannel#1155 for more information.
margamanterola pushed a commit to flatcar-archive/coreos-overlay that referenced this issue Apr 8, 2020
When setting up flannel interfaces, use MACAddressPolicy=none, so that
the MAC Address used is the initial one set by the kernel and not the
one assigned by systemd.

See flannel-io/flannel#1155 for more information.
margamanterola pushed a commit to flatcar-archive/coreos-overlay that referenced this issue Apr 8, 2020
When setting up flannel interfaces, use MACAddressPolicy=none, so that
the MAC Address used is the initial one set by the kernel and not the
one assigned by systemd.

See flannel-io/flannel#1155 for more information.
margamanterola pushed a commit to flatcar-archive/coreos-overlay that referenced this issue Apr 8, 2020
When setting up flannel interfaces, use MACAddressPolicy=none, so that
the MAC Address used is the initial one set by the kernel and not the
one assigned by systemd.

See flannel-io/flannel#1155 for more information.
margamanterola pushed a commit to flatcar-archive/coreos-overlay that referenced this issue Apr 8, 2020
When setting up flannel interfaces, use MACAddressPolicy=none, so that
the MAC Address used is the initial one set by the kernel and not the
one assigned by systemd.

See flannel-io/flannel#1155 for more information.
margamanterola pushed a commit to flatcar-archive/coreos-overlay that referenced this issue Apr 8, 2020
When setting up flannel interfaces, use MACAddressPolicy=none, so that
the MAC Address used is the initial one set by the kernel and not the
one assigned by systemd.

See flannel-io/flannel#1155 for more information.
dongsupark pushed a commit to dongsupark/coreos-overlay that referenced this issue Apr 9, 2020
When setting up flannel interfaces, use MACAddressPolicy=none, so that
the MAC Address used is the initial one set by the kernel and not the
one assigned by systemd.

See flannel-io/flannel#1155 for more information.
margamanterola pushed a commit to flatcar-archive/coreos-overlay that referenced this issue Apr 9, 2020
When setting up flannel interfaces, use MACAddressPolicy=none, so that
the MAC Address used is the initial one set by the kernel and not the
one assigned by systemd.

See flannel-io/flannel#1155 for more information.

In #279 we tried adding the MACAddressPolicy=none setting to the
existing 50-flannel.network file. But the change should have been in a
.link file, not a .network file.
margamanterola pushed a commit to flatcar-archive/coreos-overlay that referenced this issue Apr 9, 2020
When setting up flannel interfaces, use MACAddressPolicy=none, so that
the MAC Address used is the initial one set by the kernel and not the
one assigned by systemd.

See flannel-io/flannel#1155 for more information.

In #279 we tried adding the MACAddressPolicy=none setting to the
existing 50-flannel.network file. But the change should have been in a
.link file, not a .network file.
margamanterola pushed a commit to flatcar-archive/coreos-overlay that referenced this issue Apr 9, 2020
When setting up flannel interfaces, use MACAddressPolicy=none, so that
the MAC Address used is the initial one set by the kernel and not the
one assigned by systemd.

See flannel-io/flannel#1155 for more information.

In #279 we tried adding the MACAddressPolicy=none setting to the
existing 50-flannel.network file. But the change should have been in a
.link file, not a .network file.
margamanterola pushed a commit to flatcar-archive/coreos-overlay that referenced this issue Apr 9, 2020
When setting up flannel interfaces, use MACAddressPolicy=none, so that
the MAC Address used is the initial one set by the kernel and not the
one assigned by systemd.

See flannel-io/flannel#1155 for more information.

In #279 we tried adding the MACAddressPolicy=none setting to the
existing 50-flannel.network file. But the change should have been in a
.link file, not a .network file.
margamanterola pushed a commit to flatcar-archive/coreos-overlay that referenced this issue Apr 9, 2020
When setting up flannel interfaces, use MACAddressPolicy=none, so that
the MAC Address used is the initial one set by the kernel and not the
one assigned by systemd.

See flannel-io/flannel#1155 for more information.

In #279 we tried adding the MACAddressPolicy=none setting to the
existing 50-flannel.network file. But the change should have been in a
.link file, not a .network file.
margamanterola pushed a commit to flatcar-archive/coreos-overlay that referenced this issue Apr 9, 2020
When setting up flannel interfaces, use MACAddressPolicy=none, so that
the MAC Address used is the initial one set by the kernel and not the
one assigned by systemd.

See flannel-io/flannel#1155 for more information.

In #279 we tried adding the MACAddressPolicy=none setting to the
existing 50-flannel.network file. But the change should have been in a
.link file, not a .network file.
@lucab
Copy link

lucab commented Aug 5, 2020

Looking at the cross-references here, I think more people are stepping on this. Perhaps it would be worth carrying the link unit in this repo, so that it's easier for people to notice and install it.

@zcalusic
Copy link

Just got bit by this issue, spent several hours trying to understand why a single node can't communicate with others. At least until flanneld is killed and then it suddenly works.

Tnx for reporting this issue in detail @mcastelino!

Yeah, many will be bitten and pull hair over this...

@vadorovsky
Copy link
Contributor

vadorovsky commented Oct 15, 2021

I think there is a better solution than configuring systemd - netlink library allows to set a peer hardware address when creating a link, which should be a sane workaround. systemd shouldn't touch links with addresses already assigned.

vishvananda/netlink#460 - nah, this PR is not even needed, since we don't set peer during creation

Let me prepare a PR.

vadorovsky added a commit to vadorovsky/flannel that referenced this issue Oct 15, 2021
systemd 242+ assigns MAC addresses for all virtual devices which don't
have the address assigned already. That resulted in systemd overriding
MAC addresses of flannel.* interfaces. The fix which prevents systemd
from setting the address is to define the concrete MAC address when
creating the link.

Fixes: flannel-io#1155
Ref: k3s-io/k3s#4188
Signed-off-by: Michal Rostecki <[email protected]>
manuelbuil pushed a commit to manuelbuil/flannel that referenced this issue Oct 21, 2021
systemd 242+ assigns MAC addresses for all virtual devices which don't
have the address assigned already. That resulted in systemd overriding
MAC addresses of flannel.* interfaces. The fix which prevents systemd
from setting the address is to define the concrete MAC address when
creating the link.

Fixes: flannel-io#1155
Ref: k3s-io/k3s#4188
Signed-off-by: Michal Rostecki <[email protected]>
@SpringHgui
Copy link

Here's a quick documentation of the workaround (at least this worked in my lab):

cat<<'EOF'>/etc/systemd/network/10-flannel.link
[Match]
OriginalName=flannel*

[Link]
MACAddressPolicy=none
EOF

After this, I rebooted my controllers and workers and flannel's overlay worked.

work for me

knisbet pushed a commit to gravitational/flannel that referenced this issue Jan 25, 2022
systemd 242+ assigns MAC addresses for all virtual devices which don't
have the address assigned already. That resulted in systemd overriding
MAC addresses of flannel.* interfaces. The fix which prevents systemd
from setting the address is to define the concrete MAC address when
creating the link.

Fixes: flannel-io#1155
Ref: k3s-io/k3s#4188
Signed-off-by: Michal Rostecki <[email protected]>
(cherry picked from commit 0198d5d)
knisbet pushed a commit to gravitational/flannel that referenced this issue Jan 25, 2022
* vxlan: Generate MAC address before creating a link

systemd 242+ assigns MAC addresses for all virtual devices which don't
have the address assigned already. That resulted in systemd overriding
MAC addresses of flannel.* interfaces. The fix which prevents systemd
from setting the address is to define the concrete MAC address when
creating the link.

Fixes: flannel-io#1155
Ref: k3s-io/k3s#4188
Signed-off-by: Michal Rostecki <[email protected]>
(cherry picked from commit 0198d5d)

* Concern only about flannel ip addresses

Currently flannel interface ip addresses are checked on startup when
using vxlan and ipip backends. If multiple addresses are found, startup
fails fatally. If only one address is found and is not the currently
leased one, it will be assumed that it comes from a previous lease and
be removed.

This criteria seems arbitrary both in how it is done and in its timing.
It may cause failures in situations where it might not be strictly
necessary like for example if the node is running a dhcp client that is
assigning link local addresses to all interfaces. It also might fail at
flannel unexpected restarts which are completly unrelated to
the external event that caused the unexpected modification in the
flannel interface.

This patch proposes to concern and check only ip address within the
flannel network and takes the simple approach to ignore any other ip
addresses assuming these would pose no problem on flannel operation.

A discarded but more agressive alternative would be to remove all
addresses that are not the currently leased one.

Fixes flannel-io#1060

Signed-off-by: Jaime Caamaño Ruiz <[email protected]>
(cherry picked from commit 33a2fac)

* Fix flannel hang if lease expired

(cherry picked from commit 78035d0)

* subnets: move forward the cursor to skip illegal subnet

This PR fixs an issue when flannel gets illegal subnet event in
watching leases, it doesn't move forward the etcd cursor and
will stuck in the same invalid event forever.

(cherry picked from commit 1a1b6f1)

* fix cherry-pick glitches and test failures

* disable udp backend tests since we don't actually have the udp backend in our fork

Co-authored-by: Michal Rostecki <[email protected]>
Co-authored-by: Jaime Caamaño Ruiz <[email protected]>
Co-authored-by: Chun Chen <[email protected]>
Co-authored-by: huangxuesen <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants