Below are a collection of example netplan configurations for common scenarios. If you see a scenario missing or have one to contribute, please file a bug against this documentation with the example using the links at the bottom of this page. Thank you!
To configure netplan, save configuration files under
/etc/netplan/ with a
.yaml extension (e.g.
/etc/netplan/config.yaml), then run
sudo netplan apply. This command parses and applies the configuration to the system. Configuration written to disk under
/etc/netplan/ will persist between reboots.
To let the interface named ‘enp3s0’ get an address via DHCP, create a YAML file with the following:
network: version: 2 renderer: networkd ethernets: enp3s0: dhcp4: true
To instead set a static IP address, use the addresses key, which takes a list of (IPv4 or IPv6), addresses along with the subnet prefix length (e.g. /24). Gateway and DNS information can be provided as well:
network: version: 2 renderer: networkd ethernets: enp3s0: addresses: - 10.10.10.2/24 gateway4: 10.10.10.1 nameservers: search: [mydomain, otherdomain] addresses: [10.10.10.1, 188.8.131.52]
Wireless devices use the ‘wifis’ key and share the same configuration options with wired ethernet devices. The wireless access-point name and password should also be specified:
network: version: 2 renderer: networkd wifis: wlp2s0b1: dhcp4: no dhcp6: no addresses: [192.168.0.21/24] gateway4: 192.168.0.1 nameservers: addresses: [192.168.0.1, 184.108.40.206] access-points: "network_ssid_name": password: "**********"
The addresses key can take a list of addresses to assign to an interface:
network: version: 2 renderer: networkd ethernets: enp3s0: addresses: - 10.100.1.38/24 - 10.100.1.39/24 gateway4: 10.100.1.1
Interface aliases (e.g. eth0:0) are not supported.
Netplan supports both networkd and Network Manager as backends. You can specify which network backend should be used to configure particular devices by using the
renderer key. You can also delegate all configuration of the network to Network Manager itself by specifying only the
network: version: 2 renderer: NetworkManager
Bonding is configured by declaring a bond interface with a list of physical interfaces and a bonding mode. Below is an example of an active-backup bond that uses DHCP to obtain an address:
network: version: 2 renderer: networkd bonds: bond0: dhcp4: yes interfaces: - enp3s0 - enp4s0 parameters: mode: active-backup primary: enp3s0
Below is an example of a system acting as a router with various bonded interfaces and different types. Note the ‘optional: true’ key declarations that allow booting to occur without waiting for those interfaces to activate fully.
network: version: 2 renderer: networkd ethernets: enp1s0: dhcp4: no enp2s0: dhcp4: no enp3s0: dhcp4: no optional: true enp4s0: dhcp4: no optional: true enp5s0: dhcp4: no optional: true enp6s0: dhcp4: no optional: true bonds: bond-lan: interfaces: [enp2s0, enp3s0] addresses: [192.168.93.2/24] parameters: mode: 802.3ad mii-monitor-interval: 1 bond-wan: interfaces: [enp1s0, enp4s0] addresses: [192.168.1.252/24] gateway4: 192.168.1.1 nameservers: search: [local] addresses: [220.127.116.11, 18.104.22.168] parameters: mode: active-backup mii-monitor-interval: 1 gratuitious-arp: 5 bond-conntrack: interfaces: [enp5s0, enp6s0] addresses: [192.168.254.2/24] parameters: mode: balance-rr mii-monitor-interval: 1
To create a very simple bridge consisting of a single device that uses DHCP, write:
network: version: 2 renderer: networkd bridges: br0: dhcp4: yes interfaces: - enp3s0
A more complex example, to get libvirtd to use a specific bridge with a tagged vlan, while continuing to provide an untagged interface as well would involve:
network: version: 2 renderer: networkd ethernets: enp0s25: dhcp4: true bridges: br0: addresses: [ 10.3.99.25/24 ] interfaces: [ vlan15 ] vlans: vlan15: accept-ra: no id: 15 link: enp0s25
Then libvirtd would be configured to use this bridge by adding the following content to a new XML file under
/etc/libvirtd/qemu/networks/. The name of the bridge in the
<network> <name>br0</name> <bridge name='br0'/> <forward mode="bridge"/> </network>
To configure multiple VLANs with renamed interfaces:
network: version: 2 renderer: networkd ethernets: mainif: match: macaddress: "de:ad:be:ef:ca:fe" set-name: mainif addresses: [ "10.3.0.5/23" ] gateway4: 10.3.0.1 nameservers: addresses: [ "22.214.171.124", "126.96.36.199" ] search: [ example.com ] vlans: vlan15: id: 15 link: mainif addresses: [ "10.3.99.5/24" ] vlan10: id: 10 link: mainif addresses: [ "10.3.98.5/24" ] nameservers: addresses: [ "127.0.0.1" ] search: [ domain1.example.com, domain2.example.com ]
This allows setting up a default route, or any route, using the “on-link” keyword where the gateway is an IP address that is directly connected to the network even if the address does not match the subnet configured on the interface.
network: version: 2 renderer: networkd ethernets: addresses: [ "10.10.10.1/24" ] routes: - to: 0.0.0.0/0 via: 188.8.131.52 on-link: true
Route tables can be added to particular interfaces to allow routing between two networks:
In the example below, ens3 is on the 192.168.3.0/24 network and ens5 is on the 192.168.5.0/24 network. This enables clients on either network to connect to the other and allow the response to come from the correct interface.
Furthermore, the default route is still assigned to ens5 allowing any other traffic to go through it.
network: version: 2 renderer: networkd ethernets: ens3: addresses: - 192.168.3.30/24 dhcp4: no routes: - to: 192.168.3.0/24 via: 192.168.3.1 table: 101 routing-policy: - from: 192.168.3.0/24 table: 101 ens5: addresses: - 192.168.5.24/24 dhcp4: no gateway4: 192.168.5.1 routes: - to: 192.168.5.0/24 via: 192.168.5.1 table: 102 routing-policy: - from: 192.168.5.0/24 table: 102
Networkd does not allow creating new loopback devices, but a user can add new addresses to the standard loopback interface, lo, in order to have it considered a valid address on the machine as well as for custom routing:
network: version: 2 renderer: networkd ethernets: lo: match: name: lo addresses: [ 184.108.40.206/32 ]
For networks where DHCP is provided by a Windows Server using the dhcp-identifier key allows for interoperability:
network: version: 2 ethernets: enp3s0: dhcp4: yes dhcp-identifier: mac