Network fails when bridge enables


since an update of two days ago my server is unable to start a bridge. The same server and version in a VM does work.

My config:




NAME='Ethernet Connection I219-LM'


default - br0

The server is in a datacenter and the Remote Console/KVM isn’t always available. I do have a rescue system where I can mount the disk and restore a network config that does work, but without the bridge.
Since it happened with the latest tumbleweed update, I don’t think it’s hardware related.

What did change with the update was that the interface enp-s31f6 was eth0 before.

Is there another file somewhere perhaps that is still pointing to eth0 that could cause this?

I’m at a loss atm…

Do you have net.ifnames=0 as a grub kernel option?

Have a read here:

What about the output from;

brctl show

Thank. I tried the net.ifnames=0

That brings back the eth0 but it still fails when loading the bridge. So this isn’t the problem.

So the output from brctl or are you using NM?

brctl show

I didn’t install brctl. I read it was deprecated. I used ip and even Yast to build the br0 device

But I can’t show any output like that or bridge vlan since I lose connection when the bridge tries to start.

When I had the Remote Console KVM and I still had server access the server didn’t hang or rebooted always. I noticed there was no internet connectivity. Also route n didn’t show the default route.

When I tried to add one, it said it was a duplicate. Yet, it didn’t work.

Not using NM.

I would suggest just using YaST lan again, blow away the existing bridge and re-create…

Simply returning the naming convention to what was before may not be enough…
You have to inspect the whole dependency chain to verify everything hands off to the next correctly.
Short of that…
Just create a new bridge configured however you wish(must have a different name like br5) and then configure your VMs to use the new bridge device. There won’t be any kind of system penalty having unused bridge devices. Or, once a working device has been created, delete it so that the name label can be re-used (although I wouldn’t necessarily re-use unless I was totally convinced the old device had been fully removed).

I don’t know if any official statement has been made deprecating brctl (unlike for instance ipconfig).
There should not be any problem using brctl or expecting brctl to be made available (through the bridge-utils package) for the forseeable future, it’s only if you’re scripting the creation or management of bridge devices that you might want to use ip or bridge instead so your scripts can live on without any concern for maintenance and obsolescence. To me, brctl is useful because its command options are simple, intuitive and easy to remember.

I also don’t know that there is any concept of a bridge device “starting,”
It’s a static configuration bound to an ordinary network interface so it either works or doesn’t and is “instant” when the underlying network interface is functional.


I did this muchos times already. Isn’t working. (but with the same name)

I didn’t figure it was actually starting something, yet it’s odd it fails like that and a couple of times even rebooted. The service provider offered to swap the hardware, but I am not quit yet there. I can’t imagine how this would be a hardware failure.

I’ll create a new bridge with a new name. See how that goes, tnx.

A bridge with a different name doesn’t work either :frowning:

Just to clarify explicitly - when you used ‘net.ifnames=0’ to get the traditional Ethernet device naming again (ie eth0) did you also make sure to reflect that with the bridge configuration?


It might also be interesting to start the server without the bridge, then stop wicked and create the bridge manually and see if this works as expected.Maybe a regression with wicked somehow?

Something funky with the arp cache or the interface mac address?

So if you remove the bridge and manually remove (or move) the configuration files, then try and re-create, still no joy?

I wonder if using the ip command and YaST has confused the system somewhere.

Nope, same thing when it’s eth0

I tried this too. What exactly does Wicked do?

It’s just a (SUSE-specific) systemd-controlled framework used for ‘automated’ network configuration at boot. Alternative management frameworks are systemdnetworkd.service and NetworkManager (each with their own strengths).

Post the results of the following, assuming you have bridge-utils installed…Or, if you’re using ip or bridge instead the equivalent that displays all configured bridge devices

brctl show

Describe whether you are using YaST or some other tool to create your bridge device.

I agree that there is really no way that hardware should be an issue, provided that you have working hardware… ie a functioning network card that recognized by the operating system.

BTW - Do you have libvirt installed, and are you using it to manage your virtualization?


At the moment I can’t even download brctl. is having issues so it seems.

Going to look for a mirror first

You can probably do the same with ip and bridge commands (instead of brctl), you’ll just end up displaying a lot of unnecessary information

ip show
bridge show

Based on what is in the ip and bridge man pages…
Particularly with the ip utility you can probably use options to narrow down what is displayed but could accidentally block relevant data


Although I wouldn’t necessarily discourage any idea,
In general bridge devices are pretty universal…
It should not matter how a bridge device is created using any utility or virtualization technology,
The bridge device should be recognizable and usable by any application or virtualization.

Which reminds me…
I don’t think my earlier question was answered, is libvirt installed and being used?

I’m beginning to suspect by the way that virtualization was not installed using the YaST “Install hypervisor and tools” module,
This is another case where virtualization was installed using the Software Manager.