0

I'm on an Ubuntu system with a couple of physical NICs and one configured bridge0 interface (to provide internal VMs and containers with access to the rest of the LAN.) I have a MAC address specifically applied to the bridge0 interface, and I have a static IP bound to that MAC on my DHCP server. The bridge0 interface is supposed to always get 192.168.15.150 from the DHCP server, but at the moment this isn't working and I can't figure out why. Of course, this was working as expected for months if not years and just now started behaving differently, and I didn't make any explicit changes to this part of the config.

When the system boots, it gets (the wrong) non-static address from the server, as shown here:

ifconfig output immediately after booting:

lwobker@lwobker-vms:~$ ifconfig
bridge1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.15.249  netmask 255.255.255.0  broadcast 192.168.15.255
        ether 00:17:b6:00:66:e8  txqueuelen 1000  (Ethernet)
        RX packets 468  bytes 110557 (110.5 KB)
        TX packets 305  bytes 53792 (53.7 KB)

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether ac:1f:6b:b3:ad:fa  txqueuelen 1000  (Ethernet)
        RX packets 689  bytes 221475 (221.4 KB)
        TX packets 591  bytes 90791 (90.7 KB)

note that eno1 (which is the physical interface connected towards the DHCP server) does not get an address at all.

Interestingly, if I MANUALLY go into the console and do a dhclient -r followed by a dhclient, the bridge0 interface NOW gets the desired .150 address, and the .249 address somehow "migrates" to the eno1 interface... which makes no sense to me.

ifconfig output AFTER doing the dhclient bounce:

bridge1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.15.150  netmask 255.255.255.0  broadcast 192.168.15.255
        ether 00:17:b6:00:66:e8  txqueuelen 1000  (Ethernet)
        RX packets 47973  bytes 3180002 (3.1 MB)
        TX packets 23345  bytes 571811191 (571.8 MB)

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.15.249  netmask 255.255.255.0  broadcast 192.168.15.255
        ether ac:1f:6b:b3:ad:fa  txqueuelen 1000  (Ethernet)
        RX packets 81247  bytes 15919012 (15.9 MB)
        TX packets 458449  bytes 672351752 (672.3 MB)

/etc/network/interfaces file:

# interfaces(5) file used by ifup(8) and ifdown(8)
auto lo
iface lo inet loopback

# put eno1 and enp2s0 in manual mode becuase it's going to be a bridge slave
iface eno1 inet manual
iface ens2 inet manual

##Bridge  Name ###
auto bridge1
### Bridge Information
iface bridge1 inet dhcp
bridge_ports eno1 ens2
bridge_stp off
bridge_fd 0.0
bridge_waitport 0
# we want to fix the MAC addr assigned to the bridge so it gets the right IP address 
# each time from my DHCP server...
post-up ip link set bridge1 address 00:17:b6:00:66:e8
7
  • 1
    Guess: Your system does a DHCP request before the post-up gets executed, so it uses the random MAC address on the bridge, and then you assign the "right" MAC, which doesn't trigger a second DHCP request. Classic race condition. "It worked before" was because the timing was differently before (or it was just chance).
    – dirkt
    Oct 13, 2021 at 15:46
  • OK, this totally checks out in terms of the cause... is there some way to bind a MAC address to the bridge permanently (or at least before the DHCP request goes out?)
    – ljwobker
    Oct 13, 2021 at 18:33
  • I never tried this on a bridge, but is there a reason you cannot use pre-up instead of post-up to assign the mac address? And if that doesn't work, and assuming systemd (standard on Ubuntu), fiddle with systemd units and dependencies to get it to work, instead of /network/interfaces?
    – dirkt
    Oct 14, 2021 at 8:51
  • 1
    there is - if I use pre-up in place of post-up in the config, the system boots with NEITHER the bridge nor the interface that it tries to clone the MAC address from available at all in ifconfig. I have no idea if this is a bug or by design, but that's the observed behavior
    – ljwobker
    Oct 14, 2021 at 21:58
  • 1
    pre-up with a bridge is tricky: the bridge interface doesn't exist yet, it's created from hooks running also in pre-up context. BUT as any Ethernet-like interface, there's the keyword hwaddress available, including in the dhcp method.
    – A.B
    Oct 17, 2021 at 10:07

0

You must log in to answer this question.

Browse other questions tagged .