From: Ido Schimmel <idosch@idosch.org>
To: Jason Zhou <jasonzhou@x.com>
Cc: netdev@vger.kernel.org, Benjamin Mahler <bmahler@x.com>,
Jun Wang <junwang@x.com>
Subject: Re: PROBLEM: Issue with setting veth MAC address being unreliable.
Date: Sun, 14 Jul 2024 15:45:28 +0300 [thread overview]
Message-ID: <ZpPIaNsT3lzEPi4r@shredder.mtl.com> (raw)
In-Reply-To: <CAHXsExwuSyn7eVMqiOcatU5C3WHsdHEnLJcVh-jf2LjmzW2Edg@mail.gmail.com>
On Fri, Jul 12, 2024 at 05:02:13PM -0400, Jason Zhou wrote:
> Hi all,
>
> We have performed our own testing with the MacAddressPolicy set to
> none rather than persistent on CentOS 9, and it fixed the problem we
> were seeing with the MAC address mismatches before and after us trying
> to manually set it.
> So we're pretty confident that the cause is what Ido stated, and that
> we were racing against udev as we did not set a MAC address when
> creating our veth device pair, making udev think it should give out a
> new MAC address.
> We will release a patch on Apache Mesos to mitigate this potential
> race condition on systems with systemd version > 242.
> Thank you so much for the help!
>
> For documenting this issue, I believe that this race condition would
> also be present for the peer veth interface?
Yes, but when creating the veth pair you can set the addresses of both
devices:
# ip link add name bla1 address 00:11:22:33:44:55 type veth peer name bla2 address 00:aa:bb:cc:dd:ee
# ip link show dev bla1
11: bla1@bla2: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff
# ip link show dev bla2
10: bla2@bla1: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:aa:bb:cc:dd:ee brd ff:ff:ff:ff:ff:ff
> We create the peer along with veth and move the peer to another
> namespace, but udev would be notified of its creation, so it will try
> to also overwrite the peer's MAC address.
The peer can be created in the desired namespace with the desired
address:
# ip netns add ns1
# ip link add name bla1 address 00:11:22:33:44:55 type veth peer name bla2 address 00:aa:bb:cc:dd:ee netns ns1
# ip link show dev bla1
10: bla1@if8: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff link-netns ns1
bash-5.2# ip -n ns1 link show dev bla2
8: bla2@if10: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:aa:bb:cc:dd:ee brd ff:ff:ff:ff:ff:ff link-netnsid 0
> However this is not an issue for the loopback interface that comes
> with every namespace creation, as they will not be affected by
> NetworkManager and hence udev will not try to modify them.
> Please correct me if I'm wrong!
AFAICT udev ignores the loopback devices because they have a type of
ARPHRD_LOOPBACK, unlike the veth devices that have a type of
ARPHRD_ETHER.
next prev parent reply other threads:[~2024-07-14 12:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-10 20:45 PROBLEM: Issue with setting veth MAC address being unreliable Jason Zhou
2024-07-11 13:18 ` Ido Schimmel
2024-07-11 14:07 ` Jason Zhou
2024-07-12 21:02 ` Jason Zhou
2024-07-14 12:45 ` Ido Schimmel [this message]
2024-07-16 13:56 ` Jason Zhou
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=ZpPIaNsT3lzEPi4r@shredder.mtl.com \
--to=idosch@idosch.org \
--cc=bmahler@x.com \
--cc=jasonzhou@x.com \
--cc=junwang@x.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.