Add br0 to Ubuntu desktop using nmcli

addbr0ubunmcli.md

Add a bridge interface to Ubuntu desktop using nmcli

Had to do this for some advanced networking with KVM, and couldn't figure out how to do it using the Nework Manager gui. Did find an article later that showed how to do it with nmtui, but it's so much easier to record what you did when using the cli.

In the examples below "eth0" is the name of my physical interface. By default on Ubuntu and most distributions that will almost certainly be different, for example: "eno1", "ens1", or "enp2s0".

To see what everything looks like before starting:

$ nmcli con show

I renamed "Wired Connection 1' to the name of my physical interface:

$ sudo nmcli con mod 'Wired Connection 1' con-name eth0

So let's start out by creating the bridge itself:

$ nmcli con add ifname br0 type bridge con-name br0

Now add the physical interface as its slave:

$ nmcli con add type bridge-slave ifname eth0 master br0

Disable STP:

$ nmcli con mod br0 bridge.stp no

Now down the physical interface:

$ nmcli con down eth0

For this machine I want a static address:

$ nmcli con mod br0 ipv4.addresses 10.1.1.16/24
$ nmcli con mod br0 ipv4.gateway 10.1.1.1
$ nmcli con mod br0 ipv4.dns '10.1.1.1,8.8.8.8,8.8.4.4'

Don't forget to set your search domain:

$ nmcli con mod br0 ipv4.dns-search 'example.com'

Then tell Network Manager this will be a manual connection:

$ nmcli con mod br0 ipv4.method manual

Finally, bring up the new bridge interface:

$ nmcli con up br0

Run nmcli device show to confirm your changes, and then restart NetworkManager (sudo systemctl restart NetworkManager.service) to make sure the configuration sticks.

Thank you! work on Fedora 37

The line:

nmcli con add type bridge-slave ifname ens3 master br0

for your example should be:

nmcli con add type bridge-slave ifname eth0 master br0

Autoconnect can also be turned off for the physical interface so NetworkManager doesn't fall back to it if the bridge is restarted or something e.g.:

nmcli con mod eth0 connection.autoconnect no

Thanks! Unfortunately setting connection.autoconnect no killed networking on the next reboot, but that may be a function of how I originally set things up (or something I did since). My current connection list:

me@mine:~$ nmcli con show
NAME               UUID                 TYPE      DEVICE  
br0                1e...  		bridge    br0     
docker0            15...		bridge    docker0 
lxcbr0             11...  		bridge    lxcbr0  
virbr0             e9...  		bridge    virbr0  
bridge-slave-eth0  89...  		ethernet  eth0    

@plembo Hmm, I think you deleted the connection I was talking about. Here is mine:

NAME                  UUID         TYPE       DEVICE  
br0                   8a...        bridge     br0
lo                    bd...        loopback   lo
bridge-slave-enp10s0  96...        ethernet   enp10s0
vnet2                 94...        tun        vnet2
enp10s0               a8...        ethernet   --

On my machine, that connection with name=enp10s90,device=-- was the one I was setting to autoconnect=no, otherwise I found that when the bridge was down, name=enp10s90 would automatically start, claim the enp10s0 device, and prevent the bridge from (re)-starting.

You, or potentially your management tools, appear to have deleted that connection entirely, which seems like a valid alternate way of solving the problem :-)

The other related thing I've found very helpful to know is that sometimes if a VM or something is up, and the bridge networking is manipulated (brought down and up for some reason), to reconnect the VM the VM's connection simply has to be re-bridged:

# should show the ethernet interface + each VM's interface attached to the bridge
sudo brctl show
# if not:
sudo brctl addif br0 <vm's interface eg. virbr0 or vnetn>

I also don't do this step:

Finally tell Network Manager this will be a manual connection:
$ nmcli con mod br0 ipv4.method manual

I have no problem with the bridge interface obtaining its IP dynamically through DHCP just like the primary ethernet interface did. It can certainly be set to manual -- it just isn't necessary for bridging.

Not using manual mode means you can probably also skip this step:

nmcli con mod br0 ipv4.dns-search

as the router will assign the appropriate values to the bridge interface via DHCP.

The line:

nmcli con add type bridge-slave ifname ens3 master br0

for your example should be:

nmcli con add type bridge-slave ifname eth0 master br0

It might be worth clarifying that the value for ifname here should be the underlying device name as shown by ip addr, NOT the name of the network manager connection associated with the interface.

Could you explain the reason for disabling STP?

Could you explain the reason for disabling STP?

STP exists to shut down bridge ports if a bridging loop is created by mistake. At least in the typical use case for this configuration - bridging virtual machines to one of your host NICs - it is virtually impossible to accidentally create a loop. Further, leaving it enabled will cause your physical NIC to broadcast STP packets to the rest of the network and some datacentre and enterprise networks will consider STP packets on an access port to be malicious and shut down the port.

In most scenarios leaving it enabled is harmless, but personally I would almost always disable it unless I was doing something funky enough that an accidental bridging loop was plausible.

Thanks for this how-to.

If it's useful or any help, in my case, I left ipv4.method in auto, cause I cannot (or not know how) set addresses inside the guest machines before install, with ipv4.addresses and ipv4.gateway at "".

In addition, I had to open NM GUI and restrict bridge-slave-eth0 to the device eth0 (I don't know how to set it using the CLI).

Note: I now set net.ifnames=0 in grub for all my machines, , to ensure my device names are "predictable" (so the first ethernet device will be "eth0" and not "ens1", "eno1 or anything else).

Am I missing something ? net.ifnames=0 disables predictable names. device names like eth0 change based on the probing order of the interface where as names (set with net.ifnames=1 ) such as enp3s0 are predictable and remain the same across boots.

hi, im trying to follow your steps to create the bridge and everything seems ok until i try to turn the br0 to up. i get this error message:
"Error: Connection activation failed: Connection 'br0' is not available on device br0 because device is strictly unmanaged" i have googled a bit of course and tried a few things but still cannot bring it up , what am i missing ? any suggestions ? thanks

PRETTY_NAME="Ubuntu 22.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.4 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

thanks,

Can you provide the output of ip addr, nmcli con show and nmcli con show br0 ?

hi, im trying to follow your steps to create the bridge and everything seems ok until i try to turn the br0 to up. i get this error message: "Error: Connection activation failed: Connection 'br0' is not available on device br0 because device is strictly unmanaged" i have googled a bit of course and tried a few things but still cannot bring it up , what am i missing ? any suggestions ? thanks

Google actually knows the answer to your problem but finding it depends... Switching over to network-manager needs a bit of work before it can be used. I'll try to summarize the steps needed:

• install network-manager ( apt install network-manager )
• remove netplan that comes with Ubuntu by default. Do apt search netplan , then do apt purge to all those that come up as installed ( along the lines of apt purge netplan.io libnetplan0 )
• apt autoremove to get rid of remaining orphaned stuff
• edit /etc/NetworkManager/NetworkManager.conf file. There's [ifupdown] section, set managed=true
• do touch /etc/NetworkManager/conf.d/10-globally-managed-devices.conf , this creates empty file and overrides settings in the same named file in /usr/lib/NetworkManager/conf.d directory
• check if /etc/network/interfaces file is empty/comments only
• (re)start network-manager ( systemctl start NetworkManager ), see if nmcli behaves any different
• it may require restart (and prayer) that there's nothing else hindering nmcli now.

I haven't tried removing netplan from Desktop before (on Desktop it ships configured to give Network Manager control over all network devices, while it gives control to systemd-networkd on Server). I'd be interested to hear if removing netplan entirely cleaned up the "strictly unmanaged" error b3to is experiencing.