{"id":80,"date":"2018-10-17T03:24:10","date_gmt":"2018-10-17T03:24:10","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw92\/index.php\/2018\/10\/17\/have-a-plan-for-netplan\/"},"modified":"2018-10-17T03:24:10","modified_gmt":"2018-10-17T03:24:10","slug":"have-a-plan-for-netplan","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw92\/index.php\/2018\/10\/17\/have-a-plan-for-netplan\/","title":{"rendered":"Have a Plan for Netplan"},"content":{"rendered":"

Ubuntu changed networking. Embrace the YAML.<\/em><\/p>\n

\nIf I’m being completely honest, I still dislike the switch from eth0,
\neth1, eth2 to names like, enp3s0, enp4s0, enp5s0. I’ve learned to accept
\nit and mutter to myself while I type in unfamiliar interface names. Then I
\ninstalled the new LTS version of Ubuntu and typed vi
\n\/etc\/network\/interfaces. Yikes. After a technological lifetime of entering
\nmy server’s IP information in a simple text file, that’s no longer how
\nthings are done. Sigh. The good news is that while figuring out Netplan for
\nboth desktop and server environments, I fixed a nagging DNS issue I’ve had
\nfor years (more on that later).\n<\/p>\n

\nThe Basics of Netplan<\/h3>\n

\nThe old way of configuring Debian-based network interfaces was based on the
\nifupdown package. The new default is called Netplan, and
\nalthough it’s not
\nterribly difficult to use, it’s drastically different. Netplan is sort of
\nthe interface used to configure the back-end d\u00e6mons that actually
\nconfigure the interfaces. Right now, the back ends supported are
\nNetworkManager and networkd.\n<\/p>\n

\nIf you tell Netplan to use NetworkManager, all interface configuration
\ncontrol is handed off to the GUI interface on the desktop. The
\nNetworkManager program itself hasn’t changed; it’s the same GUI-based
\ninterface configuration system you’ve likely used for years.\n<\/p>\n

\nIf you tell Netplan to use networkd, systemd itself handles the interface
\nconfigurations. Configuration is still done with Netplan files, but once
\n“applied”, Netplan creates the back-end configurations systemd requires. The
\nNetplan files are vastly different from the old \/etc\/network\/interfaces
\nfile, but it uses YAML syntax, and it’s pretty easy to figure out.\n<\/p>\n

\nThe Desktop and DNS<\/h3>\n

\nIf you install a GUI version of Ubuntu, Netplan is configured with
\nNetworkManager as the back end by default. Your system should get IP
\ninformation via DHCP or static entries you add via GUI. This is usually not
\nan issue, but I’ve had a terrible time with my split-DNS setup and
\nsystemd-resolved. I’m sure there is a magical combination of configuration
\nfiles that will make things work, but I’ve spent a lot of time, and it
\nalways behaves a little oddly. With my internal DNS server resolving domain
\nnames differently from external DNS servers (that is, split-DNS), I get random
\nlookup failures. Sometimes ping will resolve, but
\ndig will not. Sometimes
\nthe internal A record will resolve, but a CNAME will not. Sometimes I get
\nresolution from an external DNS server (from the internet), even though I
\nnever configure anything other than the internal DNS!\n<\/p>\n

\nI decided to disable systemd-resolved. That has the potential to break DNS
\nlookups in a VPN, but I haven’t had an issue with that. With
\nresolved
\nhandling DNS information, the \/etc\/resolv.conf file points to 127.0.0.53 as
\nthe nameserver. Disabling systemd-resolved will stop the automatic creation
\nof the file. Thankfully, NetworkManager itself can handle the creation and
\nmodification of \/etc\/resolv.conf. Once I make that change, I no longer have
\nan issue with split-DNS resolution. It’s a three-step process:\n<\/p>\n

    \n
  1. \nDo sudo systemctl disable systemd-resolved.service.\n<\/li>\n
  2. \nThen sudo rm \/etc\/resolv.conf (get rid of the symlink).\n<\/li>\n
  3. \nEdit the \/etc\/NetworkManager\/NetworkManager.conf file, and in the
    \n[main]
    \nsection, add a line that reads DNS=default.<\/li>\n<\/ol>\n

    \nOnce those steps are complete, NetworkManager itself will create the
    \n\/etc\/resolv.conf file, and the DNS server supplied via DHCP or static entry
    \nwill be used instead of a 127.0.0.53 entry. I’m not sure why the
    \nresolved
    \nd\u00e6mon incorrectly resolves internal addresses for me, but the above method
    \nhas been foolproof, even when switching between networks with my
    \nlaptop.\n<\/p>\n

    \nNetplan CLI Configuration<\/h3>\n

    \nIf Ubuntu is installed in server mode, it is almost certainly configured to
    \nuse networkd as the back end. To check, have a look at the
    \n\/etc\/netplan\/config.yaml file. The renderer should be set to
    \nnetworkd
    \nin order to use the systemd-networkd back end. The file should look
    \nsomething like this:<\/p>\n

    network:
    \n version: 2
    \n renderer: networkd
    \n ethernets:
    \n enp2s0:
    \n dhcp4: true<\/p>\n

    Important note:<\/em> remember that with
    \nYAML files, whitespace matters, so the indentation is important. It’s also
    \nvery<\/em> important to remember that after making any changes, you need to
    \nrun sudo netplan apply so the back-end configuration files are
    \npopulated.<\/p>\n

    \nThe default renderer is networkd, so it’s possible you won’t have that line
    \nin your configuration file. It’s also possible your configuration file will
    \nbe named something different in the \/etc\/netplan folder. All .conf files
    \nare read, so it doesn’t matter what it’s called as long as it ends with
    \n.conf. Static configurations are fairly simple to set up:<\/p>\n

    network:
    \n version: 2
    \n renderer: networkd
    \n ethernets:
    \n enp2s0:
    \n dhcp4: no
    \n addresses:
    \n – 192.168.1.10\/24
    \n – 10.10.10.10\/16
    \n gateway4: 192.168.1.1
    \n nameservers:
    \n addresses: [192.168.1.1, 8.8.8.8]<\/p>\n

    \nNotice I’ve assigned multiple IP addresses to the interface. Netplan does
    \nnot support virtual interfaces like enp3s0:0, rather multiple IP
    \naddresses can be assigned to a single interface.\n<\/p>\n

    \nUnfortunately, networkd doesn’t create an \/etc\/resolv.conf file if you
    \ndisable the resolved d\u00e6mon. If you have problems with split-DNS on a
    \nheadless computer, the best solution I’ve come up with is to disable
    \nsystemd-resolved and then manually create an \/etc\/resolv.conf file. Since
    \nheadless computers don’t usually move around as much as laptops, it’s likely
    \nthe \/etc\/resolv.conf file won’t need to be changed. Still, I wish
    \nnetworkd
    \nhad an option to manage the resolv.conf file the same way
    \nNetworkManager
    \ndoes.\n<\/p>\n

    \nAdvanced Network Configurations<\/h3>\n

    \nThe configuration formats are different, but it’s still possible to do more
    \nadvanced network configurations with Netplan:\n<\/p>\n

    \nBonding:<\/em><\/p>\n

    network:
    \n version: 2
    \n renderer: networkd
    \n bonds:
    \n bond0:
    \n dhcp4: yes
    \n interfaces:
    \n – enp2s0
    \n – enp3s0
    \n parameters:
    \n mode: active-backup
    \n primary: enp2s0<\/p>\n

    \nThe various bonding modes (balance-rr,
    \nactive-backup, balance-xor,
    \nbroadcast, 802.3ad, balance-tlb and
    \nbalance-alb) are supported.\n<\/p>\n

    \nBridging:<\/em><\/p>\n

    network:
    \n version: 2
    \n renderer: networkd
    \n bridges:
    \n br0:
    \n dhcp4: yes
    \n interfaces:
    \n – enp4s0
    \n – enp3s0<\/p>\n

    \nBridging is even simpler to set up. This configuration creates a bridge
    \ndevice using the two interfaces listed. The device (br0) gets address
    \ninformation via DHCP.\n<\/p>\n

    \nCLI Networking Commands<\/h3>\n

    \nIf you’re a crusty old sysadmin like me, you likely type
    \nifconfig to see
    \nIP information without even thinking. Unfortunately, those tools are not
    \nusually installed by default. This isn’t actually the fault of Ubuntu and
    \nNetplan; the old ifconfig toolset has been deprecated. If you want to use
    \nthe old ifconfig tool, you can install the package:<\/p>\n

    sudo apt install net-tools<\/p>\n

    \nBut, if you want to do it the “correct” way, the new “ip” tool is the proper
    \nway to do it. Here are some equivalents of things I commonly do with
    \nifconfig:\n<\/p>\n

    \nShow network interface information.<\/em>\n<\/p>\n

    \nOld way:<\/p>\n

    ifconfig<\/p>\n

    \nNew way:<\/p>\n

    ip address show<\/p>\n

    \n(Or you can just do ip a, which is actually less typing than
    \nifconfig.)\n<\/p>\n

    \nBring interface up.<\/em>\n<\/p>\n

    \nOld way:<\/p>\n

    ifconfig enp3s0 up<\/p>\n

    \nNew way:<\/p>\n

    ip link set enp3s0 up<\/p>\n

    \nAssign IP address.<\/em>\n<\/p>\n

    \nOld way:<\/p>\n

    ifconfig enp3s0 192.168.1.22<\/p>\n

    \nNew way:<\/p>\n

    ip address add 192.168.1.22 dev enp3s0<\/p>\n

    \nAssign complete IP information.<\/em>\n<\/p>\n

    \nOld way:<\/p>\n

    ifconfig enp3s0 192.168.1.22 net mask 255.255.255.0 broadcast
    \n \u21aa192.168.1.255<\/p>\n

    \nNew way:<\/p>\n

    ip address add 192.168.1.22\/24 broadcast 192.168.1.255
    \n \u21aadev enp3s0<\/p>\n

    \nAdd alias interface.<\/em>\n<\/p>\n

    \nOld way:<\/p>\n

    ifconfig enp3s0:0 192.168.100.100\/24<\/p>\n

    \nNew way:<\/p>\n

    ip address add 192.168.100.100\/24 dev enp3s0 label enp3s0:0<\/p>\n

    \nShow the routing table.<\/em>\n<\/p>\n

    \nOld way:<\/p>\n

    route<\/p>\n

    \nNew way:<\/p>\n

    ip route show<\/p>\n

    \nAdd route.<\/em>\n<\/p>\n

    \nOld way:<\/p>\n

    route add -net 192.168.55.0\/24 dev enp4s0<\/p>\n

    \nNew way:<\/p>\n

    ip route add 192.168.55.0\/24 dev enp4s0<\/p>\n

    \nOld Dogs and New Tricks<\/h3>\n

    \nI hated Netplan when I first installed Ubuntu 18.04. In fact, on the
    \nparticular server I was installing, I actually started over and installed
    \n16.04 because it was “comfortable”. After a while, curiosity got the better
    \nof me, and I investigated the changes. I’m still more comfortable with the
    \nold \/etc\/network\/interfaces file, but I have to admit, Netplan makes a
    \nlittle more sense. There is a single “front end” for configuring networks,
    \nand it uses different back ends for the heavy lifting. Right now, the only
    \nback ends are the GUI NetworkManager and the systemd-networkd
    \nd\u00e6mon. With
    \nthe modular system, however, that could change someday without the need to
    \nlearn a new way of configuring interfaces. A simple change to the
    \nrenderer line would send the configuration information to a new back end.\n<\/p>\n

    \nWith regard to the new command-line networking tool (ip vs.
    \nifconfig),
    \nit really behaves more like other network devices (routers and so on), so that’s
    \nprobably a good change as well. As technologists, we need to be ready and
    \neager to learn new things. If we weren’t always trying the next best thing,
    \nwe’d all be configuring Trumpet Winsock to dial in to the internet on our
    \nWindows 95 machines. I’m glad I tried that new Linux thing, and while it
    \nwasn’t quite as dramatic, I’m glad I tried Netplan as well!\n<\/p>\n

    Source<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

    Ubuntu changed networking. Embrace the YAML. If I’m being completely honest, I still dislike the switch from eth0, eth1, eth2 to names like, enp3s0, enp4s0, enp5s0. I’ve learned to accept it and mutter to myself while I type in unfamiliar interface names. Then I installed the new LTS version of Ubuntu and typed vi \/etc\/network\/interfaces. … <\/p>\n

    Continue reading “Have a Plan for Netplan”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-80","post","type-post","status-publish","format-standard","hentry","category-linux"],"_links":{"self":[{"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/posts\/80","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/comments?post=80"}],"version-history":[{"count":0,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/posts\/80\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/media?parent=80"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/categories?post=80"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw92\/index.php\/wp-json\/wp\/v2\/tags?post=80"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}