Bridge gets created while the network interfaces are still being renamed

Bug #1738085 reported by Dawid Wróbel on 2017-12-13

This bug report will be marked for expiration in 36 days if no further activity occurs. (find out why)

6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
bridge-utils (Ubuntu)
Undecided
Unassigned
netplan.io (Ubuntu)
Undecided
Unassigned
systemd (Ubuntu)
Undecided
Unassigned

Bug Description

I have a problem with bridge configuration for the interfaces on my system that I also happen to rename explicitly.

Specifically, I have following network configuration:

# WAN interface
auto wan
iface wan inet dhcp

# LAN interfaces
iface wlan inet manual
iface lan1 inet manual
iface lan2 inet manual
iface lan3 inet manual

# LAN bridge
auto lan
iface lan inet static
        address 10.0.0.1
        netmask 255.255.255.0
        bridge_ports wlan lan1 lan2 lan3

I use systemd .link files for renaming each of the 5 bridged interfaces, e.g.

cat /etc/systemd/network/10-lan1.link
[Match]
MACAddress=90:e2:ba:ae:e8:21

[Link]
Name=lan1

(BTW, I previously used udev rules to handle the renaming, before I migrated to systemd .link files hoping for improvement)

Upon system boot, I see following messages:

Dec 13 16:03:38 trout kernel: [ 2.619999] r8169 0000:03:00.0 lan3: renamed from eth0
Dec 13 16:03:38 trout kernel: [ 2.729493] igb 0000:01:00.0 wlan: renamed from eth1
Dec 13 16:03:38 trout kernel: [ 2.867121] igb 0000:01:00.2 lan2: renamed from eth2
Dec 13 16:03:38 trout kernel: [ 2.879221] igb 0000:01:00.1 lan1: renamed from eth0
Dec 13 16:03:38 trout kernel: [ 2.899203] igb 0000:01:00.3 wan: renamed from eth3
Dec 13 16:03:38 trout kernel: [ 20.572747] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts t
o load br_netfilter if you need this.
Dec 13 16:03:38 trout kernel: [ 20.575364] device lan1 entered promiscuous mode
Dec 13 16:03:38 trout kernel: [ 20.705483] IPv6: ADDRCONF(NETDEV_UP): lan1: link is not ready
Dec 13 16:03:38 trout kernel: [ 21.097073] rename7: renamed from lan
Dec 13 16:04:29 trout systemd-udevd[466]: seq 2799 '/devices/virtual/net/lan' is taking a long time
Dec 13 16:04:59 trout systemd-udevd[540]: error changing net interface name 'lan' to 'lan1': File exists
Dec 13 16:04:59 trout systemd-udevd[540]: could not rename interface '7' from 'lan' to 'lan1': File exists
Dec 13 16:04:59 trout systemd[1]: Started ifup for lan.
Dec 13 16:04:59 trout systemd[1]: sys-subsystem-net-devices-lan1.device: Dev sys-subsystem-net-devices-lan1.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:02.1/0000:01:00.1/net/lan1 and /sys/devices/virtual/net/lan
Dec 13 16:04:59 trout systemd[1]: sys-subsystem-net-devices-lan1.device: Dev sys-subsystem-net-devices-lan1.device appeared twice with different sysfs paths /sys/devices/pci0000:00/0000:00:02.1/0000:01:00.1/net/lan1 and /sys/devices/virtual/net/rename7
Dec 13 16:04:59 trout systemd-udevd[543]: Could not generate persistent MAC address for lan: No such file or directory
Dec 13 16:04:59 trout systemd[1]: Started ifup for lan.
Dec 13 16:04:59 trout systemd[1]: Found device /sys/subsystem/net/devices/lan.
Dec 13 16:04:59 trout kernel: [ 111.797526] device wlan entered promiscuous mode
Dec 13 16:04:59 trout ifup[1753]: /sbin/ifup: waiting for lock on /run/network/ifstate.lan
Dec 13 16:04:59 trout kernel: [ 111.943158] device lan3 entered promiscuous mode
Dec 13 16:05:00 trout kernel: [ 112.240052] r8169 0000:03:00.0 lan3: link down
Dec 13 16:05:00 trout kernel: [ 112.240081] r8169 0000:03:00.0 lan3: link down
Dec 13 16:05:00 trout kernel: [ 112.242397] IPv6: ADDRCONF(NETDEV_UP): lan: link is not ready
Dec 13 16:05:00 trout sh[1689]: Waiting for lan to get ready (MAXWAIT is 32 seconds).
Dec 13 16:05:00 trout CRON[1841]: (root) CMD ([ -x /usr/sbin/dma ] && /usr/sbin/dma -q1)
Dec 13 16:05:01 trout kernel: [ 113.610184] igb 0000:01:00.2 lan2: igb: lan2 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX
Dec 13 16:05:01 trout kernel: [ 113.610324] lan: port 2(lan2) entered forwarding state
Dec 13 16:05:01 trout kernel: [ 113.610365] lan: port 2(lan2) entered forwarding state
Dec 13 16:05:01 trout kernel: [ 113.610486] IPv6: ADDRCONF(NETDEV_CHANGE): lan: link becomes ready

And after the boot process completes, the bridge is not configured as requested:
# brctl show
bridge name bridge id STP enabled interfaces
lan 8000.7085c2026d54 no lan2
                                                        lan3
                                                        wlan
rename7 8000.90e2baaee821 no lan1

Note that while the "rename7" name of the bridge seems to be constant, the interface bridged is not.

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: systemd 229-4ubuntu21
ProcVersionSignature: Ubuntu 4.4.0-103.126-generic 4.4.98
Uname: Linux 4.4.0-103-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.14
Architecture: amd64
Date: Wed Dec 13 16:11:11 2017
InstallationDate: Installed on 2016-07-28 (503 days ago)
InstallationMedia: Ubuntu-Server 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719)
MachineType: To Be Filled By O.E.M. To Be Filled By O.E.M.
ProcEnviron:
 SHELL=/bin/bash
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-103-generic root=/dev/mapper/hostname--vg-root ro
SourcePackage: systemd
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 10/27/2014
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: P1.00
dmi.board.name: QC5000-ITX/PH
dmi.board.vendor: ASRock
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: To Be Filled By O.E.M.
dmi.chassis.version: To Be Filled By O.E.M.
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrP1.00:bd10/27/2014:svnToBeFilledByO.E.M.:pnToBeFilledByO.E.M.:pvrToBeFilledByO.E.M.:rvnASRock:rnQC5000-ITX/PH:rvr:cvnToBeFilledByO.E.M.:ct3:cvrToBeFilledByO.E.M.:
dmi.product.name: To Be Filled By O.E.M.
dmi.product.version: To Be Filled By O.E.M.
dmi.sys.vendor: To Be Filled By O.E.M.

Dawid Wróbel (dawidw) wrote :
description: updated
summary: - Bridge gets created while not all network interfaces were renamed
+ Bridge gets created while not the network interfaces are being renamed
summary: - Bridge gets created while not the network interfaces are being renamed
+ Bridge gets created while the network interfaces are still being renamed
description: updated
Dawid Wróbel (dawidw) wrote :

I previously said that the "rename7" bridge name seemed constant, but after playing around a bit today I noticed that it's not exactly so. For example, I just saw following bridge setup after restarting my server:

bridge name bridge id STP enabled interfaces
lan 8000.7085c2026d54 no lan1
       lan3
       veth0P2CUY
       veth0QOJAX
       veth2MHFCX
       vethS3BS5A
rename10 8000.90e2baaee820 no wlan
rename7 8000.90e2baaee822 no lan2

Dawid Wróbel (dawidw) wrote :

Can anyone please acknowledge this issue and assign it?

Download full text (3.3 KiB)

Hi,
first of all I beg your pardon - while I'm just the one cleaning old bugs - it is bad that you had to wait so long.

Now lets get to your case...

This is a mix of systemd and ifup based network ocnfiguration, and in Artful a lot of this was still in flight.

In Bionic there is a simplified frontend to networkd (or networkmanager) [1] netplan.
I wanted to check your case with this new way to do it.

I have 4 devices, using one as "wan" and 3 for the bridge in netplan looks like:
network:
    version: 2
    ethernets:
        wan:
            dhcp4: true
            match:
                macaddress: 52:54:00:75:f5:3e
            set-name: wan
        lan1:
            match:
                macaddress: 52:54:00:84:a1:87
            set-name: lan1
        lan2:
            match:
                macaddress: 52:54:00:f3:4f:cc
            set-name: lan2
        lan3:
            match:
                macaddress: 52:54:00:ff:11:1a
            set-name: lan3
    bridges:
        br0:
            addresses: [ 10.0.0.1/24 ]
            interfaces:
                - lan1
                - lan2
                - lan3

That will create link files like yours for renaming:
$ cat /run/systemd/network/10-netplan-wan.link
[Match]
MACAddress=52:54:00:75:f5:3e
[Link]
Name=wan
WakeOnLan=off

But also for network configuration:
$ cat /run/systemd/network/10-netplan-wan.network
[Match]
MACAddress=52:54:00:75:f5:3e
Name=wan
[Network]
DHCP=ipv4
[DHCP]
UseMTU=true
RouteMetric=100

Especially also the bridge:
$ cat /run/systemd/network/10-netplan-br0.network
[Match]
Name=br0
[Network]
Address=10.0.0.1/24
$ cat /run/systemd/network/10-netplan-br0.netdev
[NetDev]
Name=br0
Kind=bridge

And the device association to the bridge:
$ cat /run/systemd/network/10-netplan-lan2.network
[Match]
MACAddress=52:54:00:f3:4f:cc
Name=lan2
[Network]
Bridge=br0
LinkLocalAddressing=no

That looks good to me now:
$ networkctl list
IDX LINK TYPE OPERATIONAL SETUP
  1 lo loopback carrier unmanaged
  6 br0 ether routable configured
  7 lan3 ether carrier configured
  8 lan1 ether carrier configured
  9 wan ether routable configured
 10 lan2 ether carrier configured

$ networkctl status
● State: routable
       Address: 10.0.0.1 on br0
                192.168.122.229 on wan
                fe80::e831:94ff:fe76:95f9 on br0
                fe80::5054:ff:fe75:f53e on wan
       Gateway: 192.168.122.1 on wan
           DNS: 192.168.122.1

$ brctl show
bridge name bridge id STP enabled interfaces
br0 8000.ea31947695f9 no lan1
                                                        lan2
                                                        lan3

Please see [1] and man netplan for more, or feel free to write the same in networkd rules as you already started on your own.

But mixing the systems to control devices is not really recommended as you'd run in issues just as the one you have reported.

Therefore I'd consider this...

Read more...

Changed in systemd (Ubuntu):
status: New → Incomplete
Changed in netplan.io (Ubuntu):
status: New → Incomplete
Changed in bridge-utils (Ubuntu):
status: New → Incomplete
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers