Synopsis: NetworkManager bad. Systemd good. Netplan a curve ball. Make a yaml.
I just completed a fresh (minimal) install of Ubuntu 18.04 Desktop. I used the new LTS release as an excuse to redo my workstation to simplify and unify since my use case flipped from more KVM virtual machines to more LXD containers. In fact I’ve gone from over provisioning 8 KVM VM’s to a much higher density of 20 containers when really getting into things (on a 4 core XEON 64GB).
I used Open VSwitch for my last setup. But OVS didn’t go too smooth on this new install and I’m a bit pressed at the moment to work my way through it (looking at you with stink eye netplan). So, I’ll stick with the standard, yet easy and fast, linux bridging using bridge-utils.
First up, I’ve got some mixed opinions on this push by many Linux Distros to make NetworkManager (NM) the main tool for network…um…management. On my laptop, brilliant and it makes sense as jumping around from wifi, to ethernet, using VPNs etc is a breeze with the NetworkManager gui and use of profiles. BUT it is a REAL PAIN with bridging. On a server and workstation, I think it adds more pain then it’s worth. So it makes sense to to use systemd.network (netd)
(edit: Ubuntu 18.04 Desktop defaults to NetworkManager and Server defaults to systemd.network).
But wait there is more and another curve ball introduced to the new 18.04 LTS and it’s called Netplan (would you like to know more?). After a quick read about it (re OVS not working) I get why it exists, but geez another level of complexity (or just yet another markup language to learn)..great!
OK! so netplan is a renderer and is used to configure NM or networkd but to quote the website linked above “Using networkd as a renderer does not let devices automatically come up using DHCP; each interface needs to be specified in a file in /etc/netplan for its configuration to be written and for it to be used in networkd.” (I think this also applies to OVS). Yep and I’m using DHCP so learn yaml for short.
Sleeves up.
make sure you bridge-utilites installed
mike@obsidian:~]$sudo apt install bridge-utilites -y
Make a backup the yaml file 01-network-manager-all.yaml
[mike@obsidian:~]$cd /etc/netplan/ [mike@obsidian:netplan]$ sudo cp cp 01-network-manager-all.yaml 01-network-manager-all.yaml-NM
Find the name of your active network interface, using ip is probably the easiest, the active one is the one with the ip address in the same subnet as your network (in my case its enp7s0
$ ip a
Open the yaml file for editing
[mike@obsidian:netplan]$sudo vi 01-network-manager-all.yaml
and change its contents to read
#Let networkd manage all devices on this system network: version: 2 renderer: networkd ethernets: enp7s0: dhcp4: no dhcp6: no bridges: br0: interfaces: [enp7s0] dhcp4: true dhcp6: no br1: interfaces: [enp7s0] dhcp4: true dhcp6: no
* Don’t copy and pass the above, WP striped the proper yaml formatting so it won’t work. I have a properly formatted example in my gist over at github If you are interested
Found a great resource on more properties you could declare in this file specific to your network (static IP, VLANS, bonds, routes etc). Check it out
Generate the required configuration for the renderers.
mike@obsidian:~]$sudo netplan generate
Apply all configuration for the renderers, restarting them as necessary.
mike@obsidian:~]$sudo netplan apply
Check your handy work.
mike@obsidian:~]$ networkctl list IDX LINK TYPE OPERATIONAL SETUP 1 lo loopback carrier unmanaged 2 enp7s0 ether carrier configured 3 enp0s31f6 ether off unmanaged 4 enp65s0f0 ether off unmanaged 5 enp65s0f1 ether off unmanaged 6 br0 ether routable configured 7 virbr0 ether no-carrier unmanaged 8 virbr0-nic ether off unmanaged 9 lxdbr0 ether routable unmanaged
That should be enough ping out from the host and use br0 as the interface for lxd and KVM and the guest OS will pull valid IP settings from your network DHCP server and be able to ping out and be accessible from the local network (even pull down an install image from the network tftp server if you have set your KVM up fro network boot).
As always. Beer and profit.
Just found this other site the other day, it covers a few other setups in Netplan in an easy to understand way. Check it out
This page over on cloud-init (a use case where I think Netplan truely makes sense) kicks ass and is worthy of some time and study.https://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html#examples
hi… thanks for good manual. Have you any idea how to assign/clone/spoof to bridge interface mac-address of physical interface? I need it to get proper configuration from dhcp-server.
Hey Igor,
I added this additional switch to my network file to spoof/clone the mac of the physical interface.
bridges:
br0:
interfaces: [eno1]
dhcp4: yes
dhcp6: no
macaddress: 00:00:00:00:00:00
when I ran netplan-generate it gave me no errors so I ran netplan apply which also ran without any errors,but the bridge still had the same mac.
So I ran ip link set br0 address 00:00:00:00:00:00 && systemctl restart systemd-networkd
This worked perfectly and my br0 can get an IP from the corporate DHCP server 🙂
This settings survived a reboot as well.
The link i used is here https://bugs.launchpad.net/netplan/+bug/1718607 (Looks like a bug not sure if its fixed.)
Thanks a lot for the notes. Makes life easier.
Nice, thanks! So is there a way to configure OVS bridges with netplan (instead of linux bridges)?
Your first command doesn’t seem to work properly on Ubuntu 18.04.3
“mike@obsidian:~]$sudo apt install bridge-utilites -y”
I was able to run successfully this command: sudo apt install bridge-utils
Interesting post & lots of informative links. Your instructions seem to instruct readers to edit the .yaml file in /etc/netplan. When I open that file in my system (Ubuntu 18.04.4 LTS – server) I see instructions at the top of the file stating it SHOULD NOT be edited. Cryptically, it says
“This file is generated from information provided by the datasource. Changes to it will not persist across an instance reboot.”
It also refers to cloud-init’s network configuration capabilities.
Any idea what this means? I’m struggling with an issue (https://askubuntu.com/questions/1222752/how-to-get-out-of-a-netplan-rabbit-hole) that sounds similar to yours.
Seamus,
Unless you are using cloud-init to provision or manage a virtual machine or lxc image, you can ignore the “do not edit” header in the file.