[pve-devel] [PATCH ifupdown2] patch: fix bond mac address at boot.

DERUMIER, Alexandre alexandre.derumier at groupe-cyllene.com
Thu Oct 19 11:39:17 CEST 2023

-------- Message initial --------
De: Thomas Lamprecht <t.lamprecht at proxmox.com>
À: Proxmox VE development discussion <pve-devel at lists.proxmox.com>,
Alexandre Derumier <aderumier at odiso.com>
Objet: Re: [pve-devel] [PATCH ifupdown2] patch: fix bond mac address at
Date: 19/10/2023 10:53:22

Am 01/09/2023 um 11:12 schrieb Alexandre Derumier:
> since systemd v241, like for bridge, the bond mac is setup
> randomly at boot, instead inherit from first slave.
> Then, on next ifreload, ifupdown2 was already fixing it,
> but with an down/up of the bond (with potentials impact on the
> network).

>>Hmm, we now got a few reports in the forum that get quite a few
>>"Received packet on bond0 with own address as source" warnings
>>after upgrading to ifupdown2 to the version that just ships this
>>patch here:

mmmm, that's strange.
Does it occur only once ? (when ifupdown2 is upgraded && reload it

Do you known which bond mode is used here ?

BTW, I had send another patch fixing it at systemd level directly (and
fixing another bug)

>>Seem like the switches send the ECTP loopback packages sometimes
>>back over the other link due both having the same MAC address,
>>Wolfgang thinks that shouldn't matter though..

That's strange, because with or without this patch,  both links have
the same mac anyway.  (same random mac generated   vs same mac
inherited from first real interface).

For me, it's look like more a config problem at the physical switch
where no port group/port channel/... 

I don't see any error like this on my network with lacp bond.

(and the current patch is really fixing bugs on reload, where physical
switch can block ports in protection if the mac is switching)

More information about the pve-devel mailing list