{
    "mode": "man",
    "parameter": "Netplan",
    "section": "5",
    "url": "https://www.chedong.com/phpMan.php/man/Netplan/5/json",
    "generated": "2026-10-06T01:25:29Z",
    "synopsis": "netplan [COMMAND|help]",
    "sections": {
        "NAME": {
            "content": "netplan - YAML network configuration abstraction for various backends\n",
            "subsections": []
        },
        "SYNOPSIS": {
            "content": "netplan [COMMAND|help]\n",
            "subsections": []
        },
        "COMMANDS": {
            "content": "See netplan help for a list of available commands on this system.\n",
            "subsections": []
        },
        "DESCRIPTION": {
            "content": "Distribution  installers,  cloud  instantiation,  image builds for particular devices, or any\nother way to deploy an operating system put its desired network configuration into YAML  con‐\nfiguration  file(s).   During  early  boot,  the  Netplan \"network renderer\" runs which reads\n/{lib,etc,run}/netplan/*.yaml and writes configuration to /run to hand off control of devices\nto the specified networking daemon.\n\n• Configured devices get handled by systemd-networkd by default, unless explicitly marked  as\nmanaged by a specific renderer (NetworkManager)\n\n• Devices not covered by the network configuration do not get touched at all.\n\n• Usable in initramfs (few dependencies and fast)\n\n• No persistent generated configuration, only original YAML configuration\n\n• Parser  supports  multiple configuration files to allow applications like libvirt or lxd to\npackage expected network configuration (virbr0, lxdbr0), or to change  the  global  default\npolicy to use NetworkManager for everything.\n\n• Retains  the flexibility to change back ends/policy later or adjust to removing NetworkMan‐\nager, as generated configuration is ephemeral.\n",
            "subsections": [
                {
                    "name": "General structure",
                    "content": "Netplan configuration files use the YAML (http://yaml.org/spec/1.1/current.html) format.  All\n/{lib,etc,run}/netplan/*.yaml are considered.  Lexicographically later files  (regardless  of\nin  which directory they are) amend (new mapping keys) or override (same mapping keys) previ‐\nous ones.  A file in /run/netplan completely shadows a file with same name  in  /etc/netplan,\nand a file in either of those directories shadows a file with the same name in /lib/netplan.\n\nThe  top-level  node in a Netplan configuration file is a network: mapping that contains ver‐\nsion: 2 (the YAML currently being used by curtin, MAAS, etc.  is version 1), and then  device\ndefinitions  grouped  by their type, such as ethernets:, modems:, wifis:, or bridges:.  These\nare the types that our renderer can understand and are supported by our back ends.\n\nEach type block contains device definitions as a map where the  keys  (called  \"configuration\nIDs\") are defined as below.\n"
                },
                {
                    "name": "Device configuration IDs",
                    "content": "The  key  names below the per-device-type definition maps (like ethernets:) are called \"ID\"s.\nThey must be unique throughout the entire set of configuration files.  Their primary  purpose\nis  to serve as anchor names for composite devices, for example to enumerate the members of a\nbridge that is currently being defined.\n\n(Since 0.97) If an interface is defined with an ID  in  a  configuration  file;  it  will  be\nbrought  up  by  the  applicable renderer.  To not have Netplan touch an interface at all, it\nshould be completely omitted from the Netplan configuration files.\n\nThere are two physically/structurally different classes of device  definitions,  and  the  ID\nfield has a different interpretation for each:\n\nPhysical devices\n\n(Examples:  Ethernet,  modem, Wi-Fi) These can dynamically come and go between reboots\nand even during runtime (hot plugging).  In the generic case, they can be selected  by\nmatch: rules on desired properties, such as name/name pattern, MAC address, driver, or\ndevice paths.  In general these will match any number of devices (unless they refer to\nproperties  which are unique such as the full path or MAC address), so without further\nknowledge about the hardware these will always be considered as a group.\n\nIt is valid to specify no match rules at all, in which case the ID field is simply the\ninterface name to be matched.  This is mostly useful if you want to keep simple  cases\nsimple, and it's how network device configuration has been done for a long time.\n\nIf there are match: rules, then the ID field is a purely opaque name which is only be‐\ning used for references from definitions of compound devices in the configuration.\n\nVirtual devices\n\n(Examples:  veth, bridge, bond, vrf) These are fully under the control of the configu‐\nration file(s) and the network stack.  I.  e.  these devices are being created instead\nof matched.  Thus match: and set-name: are not applicable for these, and the ID  field\nis the name of the created virtual device.\n\nYAML configuration"
                },
                {
                    "name": "Top-level configuration structure",
                    "content": "The general structure of a Netplan YAML file is shown below.\n\nnetwork:\nversion: NUMBER\nrenderer: STRING\nbonds: MAPPING\nbridges: MAPPING\ndummy-devices: MAPPING\nethernets: MAPPING\nmodems: MAPPING\ntunnels: MAPPING\nvirtual-ethernets: MAPPING\nvlans: MAPPING\nvrfs: MAPPING\nwifis: MAPPING\nnm-devices: MAPPING\n\n• version (number)\n\nDefines  what version of the configuration format is used.  The only value supported\nis 2.  Defaults to 2 if not defined.\n\n• renderer (scalar)\n\nDefines what network configuration tool will be used to set up  your  configuration.\nValid values are networkd and NetworkManager.  Defaults to networkd if not defined.\n\n• bonds (mapping)\n\nCreates and configures link aggregation (bonding) devices.\n\n• bridges (mapping)\n\nCreates and configures bridge devices.\n\n• dummy-devices (mapping) – since 0.107\n\nCreates and configures virtual devices.\n\n• ethernets (mapping)\n\nConfigures physical Ethernet interfaces.\n\n• modems (mapping)\n\nConfigures modems\n\n• tunnels (mapping)\n\nCreates and configures different types of virtual tunnels.\n\n• virtual-ethernets (mapping) – since 0.107\n\nCreates and configures Virtual Ethernet (veth) devices.\n\n• vlans (mapping)\n\nCreates and configures VLANs.\n\n• vrfs (mapping)\n\nConfigures Virtual Routing and Forwarding (VRF) devices.\n\n• wifis (mapping)\n\nConfigures physical Wi-Fi interfaces as client, adhoc or access point.\n\n• nm-devices (mapping)\n\nnm-devices are used in situations where Netplan doesn't support the connection type.\nThe  raw  configuration expected by NetworkManager can be defined and will be passed\nas is (passthrough) to the .nmconnection file.  Users will  not  normally  use  this\ntype of device.\n\nAll the properties for all the device types will be described in the next sections.\n"
                },
                {
                    "name": "Properties for physical device types",
                    "content": "These  properties  are  used  with physical devices such as Ethernet and Wi-Fi network inter‐\nfaces.\n\nNote: Some options will not work reliably for devices matched by name only  and  rendered  by\nnetworkd,  due  to interactions with device renaming in udev.  Match devices by MAC when set‐\nting options like: wakeonlan or *-offload.\n\n• match (mapping)\n\nThis selects a subset of available physical devices by various hardware  properties.\nThe following configuration will then apply to all matching devices, as soon as they\nappear.  All specified properties must match.\n\n• name (scalar)\n\nCurrent  interface name.  Globs are supported, and the primary use case for match‐\ning on names, as selecting one fixed name can be more easily achieved with  having\nno  match:  at  all  and  just  using  the ID (see above).  (NetworkManager: as of\nv1.14.0)\n\n• macaddress (scalar)\n\n6-byte permanent MAC address of the device in the  form  XX:XX:XX:XX:XX:XX  or  20\nbytes  for InfiniBand devices (IPoIB).  Globs are not allowed.  This doesn't match\nvirtual MAC addresses for veth, bridge, bond, vlan, ...\n\n• driver (scalar or sequence of scalars) – sequence since 0.104\n\nKernel driver name, corresponding to the DRIVER  udev  property.   A  sequence  of\nglobs is supported, any of which must match.  Matching on driver is only supported\nwith networkd.\n\nExamples:\n\n• All cards on second PCI bus:\n\nnetwork:\nethernets:\nmyinterface:\nmatch:\nname: enp2*\n\n• Fixed MAC address:\n\nnetwork:\nethernets:\ninterface0:\nmatch:\nmacaddress: 11:22:33:AA:BB:FF\n\n• First card of driver ixgbe:\n\nnetwork:\nethernets:\nnic0:\nmatch:\ndriver: ixgbe\nname: en*s0\n\n• First card with a driver matching bcmgenet or smsc*:\n\nnetwork:\nethernets:\nnic0:\nmatch:\ndriver: [\"bcmgenet\", \"smsc*\"]\nname: en*\n\n• set-name (scalar)\n\nWhen  matching  on unique properties such as path or MAC, or with additional assump‐\ntions such as \"there will only ever be one Wi-Fi device\", match rules can be written\nso that they only match one device.  Then this property can be used to give that de‐\nvice a more specific or desirable name than the default from udev ifnames.  Any  ad‐\nditional  device  that  satisfies  the match rules will then fail to get renamed and\nkeep the original kernel name (and dmesg will show an error).\n\n• wakeonlan (boolean)\n\nEnable wake on LAN.  Off by default.\n\n• emit-lldp (boolean) – since 0.99\n\n(networkd back end only) Whether to emit LLDP packets.  Off by default.\n\n• receive-checksum-offload (boolean) – since 0.104\n\n(networkd back end only) If set to true (false), the hardware offload for  checksum‐\nming of ingress network packets is enabled (disabled).  When unset, the kernel's de‐\nfault will be used.\n\n• transmit-checksum-offload (boolean) – since 0.104\n\n(networkd  back end only) If set to true (false), the hardware offload for checksum‐\nming of egress network packets is enabled (disabled).  When unset, the kernel's  de‐\nfault will be used.\n\n• tcp-segmentation-offload (boolean) – since 0.104\n\n(networkd  back end only) If set to true (false), the TCP Segmentation Offload (TSO)\nis enabled (disabled).  When unset, the kernel's default will be used.\n\n• tcp6-segmentation-offload (boolean) – since 0.104\n\n(networkd back end only) If set to true (false), the TCP6 Segmentation Offload  (tx-\ntcp6-segmentation)  is enabled (disabled).  When unset, the kernel's default will be\nused.\n\n• generic-segmentation-offload (boolean) – since 0.104\n\n(networkd back end only) If set to true (false), the  Generic  Segmentation  Offload\n(GSO) is enabled (disabled).  When unset, the kernel's default will be used.\n\n• generic-receive-offload (boolean) – since 0.104\n\n(networkd  back  end only) If set to true (false), the Generic Receive Offload (GRO)\nis enabled (disabled).  When unset, the kernel's default will be used.\n\n• large-receive-offload (boolean) – since 0.104\n\n(networkd back end only) If set to true (false), the Large Receive Offload (LRO)  is\nenabled (disabled).  When unset, the kernel's default will be used.\n\n• openvswitch (mapping) – since 0.100\n\nThis  provides additional configuration for the openvswitch network device.  If Open\nvSwitch is not available on the system, Netplan treats the presence  of  openvswitch\nconfiguration as an error.\n\nAny  supported  network device that is declared with the openvswitch mapping (or any\nbond/bridge that includes an interface with an openvswitch  configuration)  will  be\ncreated in openvswitch instead of the defined renderer.  In the case of a vlan defi‐\nnition  declared the same way, Netplan will create a fake VLAN bridge in openvswitch\nwith the requested vlan properties.\n\n• external-ids (mapping) – since 0.100\n\nPassed-through directly to Open vSwitch\n\n• other-config (mapping) – since 0.100\n\nPassed-through directly to Open vSwitch\n\n• lacp (scalar) – since 0.100\n\nValid for bond interfaces.  Accepts active, passive or off (the default).\n\n• fail-mode (scalar) – since 0.100\n\nValid for bridge interfaces.  Accepts secure or standalone (the default).\n\n• mcast-snooping (boolean) – since 0.100\n\nValid for bridge interfaces.  False by default.\n\n• protocols (sequence of scalars) – since 0.100\n\nValid for bridge interfaces or the network section.  List of protocols to be  used\nwhen  negotiating  a  connection  with  the controller.  Accepts OpenFlow10, Open‐\nFlow11, OpenFlow12, OpenFlow13, OpenFlow14, and OpenFlow15.\n\n• rstp (boolean) – since 0.100\n\nValid for bridge interfaces.  False by default.\n\n• controller (mapping) – since 0.100\n\nValid for bridge interfaces.  Specify an external OpenFlow controller.\n\n• addresses (sequence of scalars)\n\nSet the list of addresses to use for the  controller  targets.   The  syntax  of\nthese   addresses   is   as   defined   in  ovs-vsctl(8).   Example:  addresses:\n[tcp:127.0.0.1:6653, \"ssl:[fe80::1234%eth0]:6653\"].\n\n• connection-mode (scalar)\n\nSet the connection mode for the controller.  Supported options are  in-band  and\nout-of-band.  The default is in-band.\n\n• ports (sequence of sequence of scalars) – since 0.100\n\nOpen  vSwitch  patch ports.  Each port is declared as a pair of names which can be\nreferenced as interfaces in dependent virtual devices (bonds, bridges).\n\nExample:\n\nopenvswitch:\nports:\n- [patch0-1, patch1-0]\n\n• ssl (mapping) – since 0.100\n\nValid for global openvswitch settings.  Options for configuring  SSL  server  end‐\npoint for the switch.\n\n• ca-cert (scalar)\n\nPath to a file containing the CA certificate to be used.\n\n• certificate (scalar)\n\nPath to a file containing the server certificate.\n\n• private-key (scalar)\n\nPath to a file containing the private key for the server.\n"
                },
                {
                    "name": "Properties for all device types",
                    "content": "• renderer (scalar)\n\nUse the given networking back end for this definition.  Currently supported are net‐\nworkd  and NetworkManager.  This property can be specified globally in network:, for\na device type (in e.g.  ethernets:) or for a particular device definition.   Default\nis networkd.\n\n(Since  0.99) The renderer property has one additional acceptable value for VLAN ob‐\njects (i.e.  defined in vlans:): sriov.  If a VLAN is defined with the sriov render‐\ner for an SR-IOV Virtual Function interface, this causes Netplan to set up  a  hard‐\nware VLAN filter for it.  There can be only one defined per VF.\n\n• dhcp4 (boolean)\n\nEnable DHCP for IPv4.  Off by default.\n\n• dhcp6 (boolean)\n\nEnable  DHCP for IPv6.  Off by default.  This covers both stateless DHCP - where the\nDHCP server supplies information like DNS name servers but not the IP address -  and\nstateful DHCP, where the server provides both the address and the other information.\n\nIf  you are in an IPv6-only environment with completely stateless auto-configuration\n(SLAAC with RDNSS), this option can be set to cause the interface to be brought  up.\n(Setting  accept-ra  alone is not sufficient.)  Auto-configuration will still honour\nthe contents of the router advertisement and only use DHCP if requested in the RA.\n\nNote that rdnssd(8) is required to use RDNSS with networkd.  No  extra  software  is\nrequired for NetworkManager.\n\n• ipv6-mtu  (scalar) – since 0.98 > Set the IPv6 MTU (only supported with networkd back end).\nNote > that needing to set this is an unusual requirement.  > > Requires feature: ipv6-mtu\n\n• ipv6-privacy (boolean)\n\nEnable IPv6 Privacy Extensions (RFC 4941) for the specified  interface,  and  prefer\ntemporary addresses.  Defaults to false - no privacy extensions.  There is currently\nno way to have a private address but prefer the public address.\n\n• link-local (sequence of scalars)\n\nConfigure  the  link-local  addresses to bring up.  Valid options are ipv4 and ipv6,\nwhich respectively allow enabling IPv4 and IPv6  link  local  addressing.   If  this\nfield  is  not defined, the default is to enable only IPv6 link-local addresses.  If\nthe field is defined but configured as an empty set, IPv6 link-local  addresses  are\ndisabled as well as IPv4 link- local addresses.\n\nThis feature enables or disables link-local addresses for a protocol, but the actual\nimplementation  differs per back end.  On networkd, this directly changes the behav‐\niour and may add an extra address on an interface.  When  using  the  NetworkManager\nback end, enabling link-local has no effect if the interface also has DHCP enabled.\n\nExamples:\n\n• Enable only IPv4 link-local: link-local: [ ipv4 ]\n\n• Enable all link-local addresses: link-local: [ ipv4, ipv6 ]\n\n• Disable all link-local addresses: link-local: [ ]\n\n• ignore-carrier (boolean) – since 0.104\n\n(networkd  back  end only) Allow the specified interface to be configured even if it\nhas no carrier.\n\n• critical (boolean)\n\nDesignate the connection as \"critical to the system\", meaning that special care will\nbe taken by to not release the assigned IP  when  the  daemon  is  restarted.   (not\nrecognised by NetworkManager)\n\n• dhcp-identifier (scalar)\n\n(networkd  back end only) Sets the source of DHCP (v4) client identifier.  If mac is\nspecified, the MAC address of the link is used.  If this option is  omitted,  or  if\nduid is specified, networkd will generate an RFC4361-compliant client identifier for\nthe interface by combining the link's IAID and DUID.\n\n• dhcp4-overrides (mapping)\n\n(networkd  back  end  only) Overrides default DHCP behaviour; see the DHCP Overrides\nsection below.\n\n• dhcp6-overrides (mapping)\n\n(networkd back end only) Overrides default DHCP behaviour; see  the  DHCP  Overrides\nsection below.\n\n• accept-ra (boolean)\n\nAccept  Router  Advertisement  that  would have the kernel configure IPv6 by itself.\nWhen enabled, accept Router Advertisements.  When disabled, do not respond to Router\nAdvertisements.  If unset use the host kernel default setting.\n\n• ra-overrides (mapping) – since 1.1\n\n(networkd back end only) Overrides default IPv6 Router Advertisement (RA) behaviour;\nsee the IPv6 Router Advertisement Overrides section below.\n\n• addresses (sequence of scalars and mappings)\n\nAdd static addresses to the interface in addition to the ones received through  DHCP\nor  RA.   Each sequence entry is in CIDR notation, i.e.  of the form addr/prefixlen.\naddr is an IPv4 or IPv6 address as recognised by inetpton(3) and prefixlen the num‐\nber of bits of the subnet.\n\nFor virtual devices (bridges, bonds, VLAN) if there is  no  address  configured  and\nDHCP  is  disabled,  the  interface may still be brought online, but will not be ad‐\ndressable from the network.\n\nIn addition to the addresses themselves one can specify configuration parameters  as\nmappings.  Current supported options are:\n\n• lifetime (scalar) – since 0.100\n\nDefault:  forever.  This can be forever or 0 and corresponds to the PreferredLife‐\ntime option in the Address section of systemd-networkd.   Currently  supported  on\nthe networkd back end only.\n\n• label (scalar) – since 0.100\n\nAn  IP  address label, equivalent to the ip address label command.  Currently sup‐\nported on the networkd back end only.\n\nExamples:\n\n• Simple: addresses: [192.168.14.2/24, \"2001:1::1/64\"]\n\n• Advanced:\n\nnetwork:\nethernets:\neth0:\naddresses:\n- \"10.0.0.15/24\":\nlifetime: 0\nlabel: \"maas\"\n- \"2001:1::1/64\"\n\n• ipv6-address-generation (scalar) – since 0.99\n\nConfigure method for creating the address for use with RFC4862  IPv6  Stateless  Ad‐\ndress Auto-configuration.  Possible values are eui64 or stable-privacy.\n\n• ipv6-address-token (scalar) – since 0.100\n\nDefine  an  IPv6  address  token for creating a static interface identifier for IPv6\nStateless Address Auto-configuration.  This is mutually exclusive with ipv6-address-\ngeneration.\n\n• gateway4, gateway6 (scalar)\n\nDeprecated, see Default routes.  Set default gateway for IPv4/6, for manual  address\nconfiguration.   This  requires setting addresses too.  Gateway IP addresses must be\nin a form recognised by inetpton(3).  There should only be a single gateway per  IP\naddress  family  set  in  your global configuration, to make it unambiguous.  If you\nneed multiple default routes, please define them via routing-policy.\n\nExamples\n\n• IPv4: gateway4: 172.16.0.1\n\n• IPv6: gateway6: \"2001:4::1\"\n\n• nameservers (mapping)\n\nSet DNS servers and search domains, for manual address configuration.  There are two\nsupported fields: addresses: is a list of IPv4 or IPv6 addresses  similar  to  gate‐\nway*, and search: is a list of search domains.\n\nExample:\n\nnetwork:\nethernets:\nid0:\n[...]\nnameservers:\nsearch: [lab, home]\naddresses: [8.8.8.8, \"FEDC::1\"]\n\n• macaddress (scalar)\n\nSet   the   device's   MAC   address.    The   MAC  address  must  be  in  the  form\n\"XX:XX:XX:XX:XX:XX\".  The following special options are also accepted: permanent and\nrandom.  In addition to these options, the NetworkManager renderer also accepts sta‐\nble, stable-ssid (Wi-Fi only) and preserve.\n\nNote: This will not work reliably for devices matched by name only and  rendered  by\nnetworkd,  due  to  interactions with device renaming in udev.  Match devices by MAC\nwhen setting MAC addresses.\n\nExample:\n\nnetwork:\nethernets:\nid0:\nmatch:\nmacaddress: 52:54:00:6b:3c:58\n[...]\nmacaddress: 52:54:00:6b:3c:59\n\n• mtu (scalar)\n\nSet the Maximum Transmission Unit for the interface.  The default  is  1500.   Valid\nvalues depend on your network interface.\n\nNote:  This  will not work reliably for devices matched by name only and rendered by\nnetworkd, due to interactions with device renaming in udev.  Match  devices  by  MAC\nwhen setting MTU.\n\n• optional (boolean)\n\nAn  optional  device is not required for booting.  Normally, networkd will wait some\ntime for device to become configured before proceeding with booting.  However, if  a\ndevice is marked as optional, networkd will not wait for it.  This is only supported\nby networkd, and the default is false.\n\nExample:\n\nnetwork:\nethernets:\neth7:\n# this is plugged into a test network that is often\n# down - don't wait for it to come up during boot.\ndhcp4: true\noptional: true\n\n• optional-addresses (sequence of scalars)\n\nSpecify  types  of addresses that are not required for a device to be considered on‐\nline.  This changes the behaviour of back ends at boot time to avoid waiting for ad‐\ndresses that are marked optional, and thus consider the interface as \"usable\"  soon‐\ner.  This does not disable these addresses, which will be brought up anyway.\n\nExample:\n\nnetwork:\nethernets:\neth7:\ndhcp4: true\ndhcp6: true\noptional-addresses: [ ipv4-ll, dhcp6 ]\n\n• activation-mode (scalar) – since 0.103\n\nAllows specifying the management policy of the selected interface.  By default, Net‐\nplan brings up any configured interface if possible.  Using the activation-mode set‐\nting  users  can  override  that behaviour by either specifying manual, to hand over\ncontrol over the interface state to the administrator or (for networkd back end  on‐\nly)  off to force the link in a down state at all times.  Any interface with activa‐\ntion-mode defined is implicitly considered optional.   Supported  officially  as  of\nnetworkd v248+.\n\nExample:\n\nnetwork:\nethernets:\neth1:\n# this interface will not be put into an UP state automatically\ndhcp4: true\nactivation-mode: manual\n\n• routes (sequence of mappings)\n\nConfigure static routing for the device; see the Routing section below.\n\n• routing-policy (sequence of mappings)\n\nConfigure policy routing for the device; see the Routing section below.\n\n• neigh-suppress (scalar) – since 0.105\n\nTakes a boolean.  Configures whether ARP and ND neighbour suppression is enabled for\nthis bridge port.  When unset, the kernel's default will be used.\n\n• hairpin (scalar) – since 1.0\n\nTakes a boolean.  Configures whether traffic may be sent back out of the bridge port\non which it was received.  When this flag is false, then the bridge does not forward\ntraffic back out of the receiving port.  When unset, the back end default is used.\n\n• port-mac-learning (scalar) – since 1.0\n\nTakes a boolean.  Configures whether MAC address learning is enabled for this bridge\nport.   When unset, the kernel default is used.  Currently supported on the networkd\nback end only.\n"
                },
                {
                    "name": "DHCP Overrides",
                    "content": "Several DHCP behaviour overrides are available.  Most currently only have any effect when us‐\ning the networkd back end, with the exception of use-routes and route-metric.\n\nOverrides only have an effect if the corresponding dhcp4 or dhcp6 is set to true.\n\nIf both dhcp4 and dhcp6 are true, the networkd back end  requires  that  dhcp4-overrides  and\ndhcp6-overrides  contain the same keys and values.  If the values do not match, an error will\nbe shown and the network configuration will not be applied.\n\nWhen using the NetworkManager back end, different values may be specified for dhcp4-overrides\nand dhcp6-overrides, and will be applied to the DHCP client processes  as  specified  in  the\nNetplan YAML.\n\n• dhcp4-overrides, dhcp6-overrides (mapping)\n\nThe dhcp4-overrides and dhcp6-override mappings override the default DHCP behaviour.\n\n• use-dns (boolean)\n\nDefault:  true.   When true, the DNS servers received from the DHCP server will be\nused and take precedence over any statically configured ones.  Currently only  has\nan effect on the networkd back end.\n\n• use-ntp (boolean)\n\nDefault:  true.   When true, the NTP servers received from the DHCP server will be\nused by systemd-timesyncd and take precedence over any statically configured ones.\nCurrently only has an effect on the networkd back end.\n\n• send-hostname (boolean)\n\nDefault: true.  When true, the machine hostname will be sent to the  DHCP  server.\nCurrently only has an effect on the networkd back end.\n\n• use-hostname (boolean)\n\nDefault:  true.  When true, the hostname received from the DHCP server will be set\nas the transient hostname of the system.  Currently only has an effect on the net‐\nworkd back end.\n\n• use-mtu (boolean)\n\nDefault: true.  When true, the MTU received from the DHCP server will  be  set  as\nthe  MTU  of  the  network  interface.  When false, the MTU advertised by the DHCP\nserver will be ignored.  Currently only has an effect on the networkd back end.\n\n• hostname (scalar)\n\nUse this value for the hostname which is sent to the DHCP server, instead  of  ma‐\nchine's hostname.  Currently only has an effect on the networkd back end.\n\n• use-routes (boolean)\n\nDefault:  true.   When  true, the routes received from the DHCP server will be in‐\nstalled in the routing table normally.  When set to false, routes  from  the  DHCP\nserver  will  be  ignored: in this case, the user is responsible for adding static\nroutes if necessary for correct network operation.  This allows users to avoid in‐\nstalling a default gateway for interfaces configured via DHCP.  Available for both\nthe networkd and NetworkManager back ends.\n\n• route-metric (scalar)\n\nUse this value for default metric for automatically-added  routes.   Use  this  to\nprioritise  routes for devices by setting a lower metric on a preferred interface.\nAvailable for both the networkd and NetworkManager back ends.\n\n• use-domains (scalar) – since 0.98\n\nTakes a boolean, or the special value route.  When true, the domain name  received\nfrom  the DHCP server will be used as DNS search domain over this link, similar to\nthe effect of the Domains= setting.  If set to route,  the  domain  name  received\nfrom  the  DHCP  server  will  be  used  for routing DNS queries only, but not for\nsearching, similar to the effect of the Domains= setting when the argument is pre‐\nfixed with ~ (tilde).\n\nRequires feature: dhcp-use-domains\n"
                },
                {
                    "name": "IPv6 Router Advertisement Overrides",
                    "content": "Overrides for IPv6 Router Advertisement (RA) behaviour (only  supported  with  networkd  back\nend).\n\n• ra-overrides (mapping) – since 1.1\n\nThe ra-overrides mappings override the default IPv6 Router Advertisement behaviour.\n\n• use-dns (boolean)\n\nDefault:  true.  When true, the DNS servers received from the Router Advertisement\nwill be used.  Currently only has an effect on the networkd back end.\n\n• use-domains (scalar)\n\nTakes a boolean, or the special value route.  When true, the domain name  received\nfrom  the  Router  Advertisement will be used as DNS search domain over this link.\nIf set to route, the domain name received from the IPv6 RA will be used for  rout‐\ning DNS queries only, but not for searching.  Defaults to false.\n\n• table (scalar)\n\nThe  routing  table number for routes received in the IPv6 RA.  Allowed values are\npositive integers starting from 1.  Some values are already in  use  to  refer  to\nspecific routing tables: see {/etc,/usr/share}/iproute2/rttables.\n"
                },
                {
                    "name": "Routing",
                    "content": "Complex  routing  is possible with Netplan.  Standard static routes as well as policy routing\nusing routing tables are supported via the networkd back end.\n\nThese options are available for all types of interfaces.\n"
                },
                {
                    "name": "Default routes",
                    "content": "The most common need for routing concerns the definition of default routes to reach the wider\ninternet.  Those default routes can only defined once per IP family  and  routing  table.   A\ntypical example would look like the following:\n\nnetwork:\nethernets:\neth0:\n[...]\nroutes:\n- to: default # could be 0.0.0.0/0 optionally\nvia: 10.0.0.1\nmetric: 100\non-link: true\nadvertised-mss: 1400\n- to: default # could be ::/0 optionally\nvia: cf02:de:ad:be:ef::2\neth1:\n[...]\nroutes:\n- to: default\nvia: 172.134.67.1\nmetric: 100\non-link: true\n# Not on the main routing table,\n# does not conflict with the eth0 default route\ntable: 76\n\n• routes (mapping)\n\nThe  routes block defines standard static routes for an interface.  At least to must\nbe specified.  If type is local or nat a default scope of host is assumed.  If  type\nis  unicast and no gateway (via) is given or type is broadcast, multicast or anycast\na default scope of link is assumed.  Otherwise, a global scope is the  default  set‐\nting.\n\nFor  from,  to  and via, both IPv4 and IPv6 addresses are recognised, and must be in\nthe form addr/prefixlen or addr.\n\n• from (scalar)\n\nSet a source IP address for traffic going through the route.  (NetworkManager:  as\nof v1.8.0)\n\n• to (scalar)\n\nDestination address for the route.\n\n• via (scalar)\n\nAddress to the gateway to use for this route.\n\n• on-link (boolean)\n\nWhen set to true, specifies that the route is directly connected to the interface.\n(NetworkManager: as of v1.12.0 for IPv4 and v1.18.0 for IPv6)\n\n• metric (scalar)\n\nThe relative priority of the route.  Must be a positive integer value.\n\n• type (scalar)\n\nThe  type  of  route.   Valid  options  are unicast (default), anycast, blackhole,\nbroadcast, local, multicast, nat, prohibit, throw, unreachable or xresolve.\n\n• scope (scalar)\n\nThe route scope, how wide-ranging it is to the network.  Possible values are glob‐\nal, link, or host.  Applies to IPv4 only.\n\n• table (scalar)\n\nThe table number to use for the route.  In some scenarios, it may be useful to set\nroutes in a separate routing table.  It may also be used to refer to routing poli‐\ncy rules which also accept a table parameter.  Allowed values are  positive  inte‐\ngers starting from 1.  Some values are already in use to refer to specific routing\ntables: see /etc/iproute2/rttables.  (NetworkManager: as of v1.10.0)\n\n• mtu (scalar) – since 0.101\n\nThe MTU to be used for the route, in bytes.  Must be a positive integer value.\n\n• congestion-window (scalar) – since 0.102\n\nThe congestion window to be used for the route, represented by number of segments.\nMust be a positive integer value.\n\n• advertised-receive-window (scalar) – since 0.102\n\nThe  receive  window to be advertised for the route, represented by number of seg‐\nments.  Must be a positive integer value.\n\n• advertised-mss (scalar) – since 1.1\n\nThe Maximum MSS ('Maximal Segment Size') to advertise to these  destinations  when\nestablishing TCP connections.  If it is not given, Linux uses a default value cal‐\nculated from the first hop device MTU.  Must be a positive integer.\n\n• routing-policy (mapping)\n\nThe  routing-policy  block defines extra routing policy for a network, where traffic\nmay be handled specially based on the source IP, firewall marking, etc.\n\nFor from, to, both IPv4 and IPv6 addresses are recognised, and must be in  the  form\naddr/prefixlen or addr.\n\n• from (scalar)\n\nSet a source IP address to match traffic for this policy rule.\n\n• to (scalar)\n\nMatch on traffic going to the specified destination.\n\n• table (scalar)\n\nThe  table  number to match for the route.  In some scenarios, it may be useful to\nset routes in a separate routing table.  It may also be used to  refer  to  routes\nwhich  also accept a table parameter.  Allowed values are positive integers start‐\ning from 1.  Some values are already in use to refer to specific  routing  tables:\nsee /etc/iproute2/rttables.\n\n• priority (scalar)\n\nSpecify  a  priority  for the routing policy rule, to influence the order in which\nrouting rules are processed.  A higher number  means  lower  priority:  rules  are\nprocessed in order by increasing priority number.  Specifying an explicit, unique,\npriority  for each routing policy rule is strongly recommended and is mandatory on\nthe NetworkManager back-end.\n\n• mark (scalar)\n\nHave this routing policy rule match on traffic that has been marked by  the  ipta‐\nbles firewall with this value.  Allowed values are positive integers starting from\n1.\n\n• type-of-service (scalar)\n\nMatch this policy rule based on the type of service number applied to the traffic.\n\n(yaml-auth)= ## Authentication\n\nNetplan  supports advanced authentication settings for Ethernet and Wi-Fi interfaces, as well\nas individual Wi-Fi networks, by means of the auth block.\n\n• auth (mapping)\n\nSpecifies authentication settings for a device of type  ethernets:,  or  an  access-\npoints: entry on a wifis: device.\n\nThe auth block supports the following properties:\n\n• key-management (scalar)\n\nThe  supported  key  management  modes are none (no key management); psk (WPA with\npre-shared key, common for home Wi-Fi); psk-sha256 (WPA2 with pre-shared key, com‐\nmon for home Wi-Fi); eap (WPA with EAP, common for enterprise  Wi-Fi);  eap-sha256\n(used  with  WPA3-Enterprise);  eap-suite-b-192  (used  with WPA3-Enterprise); sae\n(used by WPA3); and 802.1x (used primarily for wired Ethernet connections).\n\n• password (scalar)\n\nThe password string for EAP, or the pre-shared key for WPA-PSK.\n\nThe following properties can be used if key-management is eap or 802.1x:\n\n• method (scalar)\n\nThe EAP method to use.  The supported EAP methods are tls (TLS),  peap  (Protected\nEAP), leap (Lightweight EAP), pwd (EAP Password) and ttls (Tunnelled TLS).\n\n• identity (scalar)\n\nThe identity to use for EAP.\n\n• anonymous-identity (scalar)\n\nThe  identity  to  pass over the unencrypted channel if the chosen EAP method sup‐\nports passing a different tunnelled identity.\n\n• ca-certificate (scalar)\n\nPath to a file with one or more trusted certificate authority (CA) certificates.\n\n• client-certificate (scalar)\n\nPath to a file containing the certificate to be used by the client during  authen‐\ntication.\n\n• client-key (scalar)\n\nPath to a file containing the private key corresponding to client-certificate.\n\n• client-key-password (scalar)\n\nPassword  to  use  to decrypt the private key specified in client-key if it is en‐\ncrypted.\n\n• phase2-auth (scalar) – since 0.99\n\nPhase 2 authentication mechanism.\n"
                },
                {
                    "name": "Properties for device type ethernets",
                    "content": "Status: Optional.\n\nPurpose: Use the ethernets key to configure Ethernet interfaces.\n\nStructure: The key consists of a mapping of Ethernet interface IDs.  Each ethernet has a num‐\nber of configuration options.  You don't need to define each interface by their  name  inside\nthe  ethernets mapping.  You can use any ID that describes the interface and match the actual\nnetwork card using the match key.  The general configuration structure for Ethernet is  shown\nbelow.\n\nnetwork:\nethernets:\ndevice-id:\n...\n\ndevice-id is the interface identifier.  If you use the interface name as the ID, Netplan will\nmatch that interface.\n\nConsider  the  example below.  In this case, an interface called eth0 will be configured with\nDHCP.\n\nnetwork:\nethernets:\neth0:\ndhcp4: true\n\nThe device-id can be any descriptive name your find  meaningful.   Although,  if  it  doesn't\nmatch  a real interface name, you must use the property match to identify the device you want\nto configure.\n\nThe example below defines an Ethernet connection called isp-interface (supposedly an external\ninterface connected to the Internet Service Provider) and uses match to apply the  configura‐\ntion to the physical device with MAC address aa:bb:cc:00:11:22.\n\nnetwork:\nethernets:\nisp-interface:\nmatch:\nmacaddress: aa:bb:cc:00:11:22\ndhcp4: true\n\nEthernet device definitions, beyond common ones described above, also support some additional\nproperties that can be used for SR-IOV devices.\n\n• link (scalar) – since 0.99\n\n(SR-IOV devices only) The link property declares the device as a Virtual Function of\nthe selected Physical Function device, as identified by the given Netplan ID.\n\nExample:\n\nnetwork:\nethernets:\nenp1: {...}\nenp1s16f1:\nlink: enp1\n\n• virtual-function-count (scalar) – since 0.99\n\n(SR-IOV  devices only) In certain special cases VFs might need to be configured out‐\nside of Netplan.  For such configurations virtual-function-count can  be  optionally\nused to set an explicit number of Virtual Functions for the given Physical Function.\nIf  unset,  the  default is to create only as many VFs as are defined in the Netplan\nconfiguration.  This should be used for special cases only.\n\nRequires feature: sriov\n\n• embedded-switch-mode (scalar) – since 0.104\n\n(SR-IOV devices only) Change the operational mode of the embedded switch of  a  sup‐\nported  SmartNIC  PCI  device  (e.g.   Mellanox  ConnectX-5).   Possible  values are\nswitchdev or legacy, if unspecified the vendor's default configuration is used.\n\nRequires feature: eswitch-mode\n\n• delay-virtual-functions-rebind (boolean) – since 0.104\n\n(SR-IOV devices only) Delay rebinding of SR-IOV virtual functions to its driver  af‐\nter changing the embedded-switch-mode setting to a later stage.  Can be enabled when\nbonding/VF LAG is in use.  Defaults to false.\n\nRequires feature: eswitch-mode\n\n• infiniband-mode (scalar) – since 0.105\n\n(InfiniBand  devices  only) Change the operational mode of a IPoIB device.  Possible\nvalues are datagram or connected.  If unspecified the kernel's default configuration\nis used.\n\nRequires feature: infiniband\n\n(yaml-modems)= ## Properties for device type modems\n\nStatus: Optional.\n\nPurpose: Use the modems key to configure modem interfaces.  GSM/CDMA modem  configuration  is\nonly supported for the NetworkManager back end.  systemd-networkd does not support modems.\n\nStructure: The key consists of a mapping of modem IDs.  Each modem has a number of configura‐\ntion options.  The general configuration structure for Modems is shown below.\n\nnetwork:\nversion: 2\nrenderer: NetworkManager\nmodems:\ncdc-wdm1:\nmtu: 1600\napn: ISP.CINGULAR\nusername: ISP@CINGULARGPRS.COM\npassword: CINGULAR1\nnumber: \"*99#\"\nnetwork-id: 24005\ndevice-id: da812de91eec16620b06cd0ca5cbc7ea25245222\npin: 2345\nsim-id: 89148000000060671234\nsim-operator-id: 310260\n"
                },
                {
                    "name": "Requires feature: modems",
                    "content": "• apn (scalar) – since 0.99\n\nSet  the carrier APN (Access Point Name).  This can be omitted if auto-config is en‐\nabled.\n\n• auto-config (boolean) – since 0.99\n\nSpecify whether to try and auto-configure the modem by doing a lookup of the carrier\nagainst the Mobile Broadband Provider database.  This may not work for all carriers.\n\n• device-id (scalar) – since 0.99\n\nSpecify the device ID (as given by the WWAN management  service)  of  the  modem  to\nmatch.  This can be found using mmcli.\n\n• network-id (scalar) – since 0.99\n\nSpecify  the Network ID (GSM LAI format).  If this is specified, the device will not\nroam networks.\n\n• number (scalar) – since 0.99\n\nThe number to dial to establish the connection  to  the  mobile  broadband  network.\n(Deprecated for GSM)\n\n• password (scalar) – since 0.99\n\nSpecify  the  password  used  to authenticate with the carrier network.  This can be\nomitted if auto-config is enabled.\n\n• pin (scalar) – since 0.99\n\nSpecify the SIM PIN to allow it to operate if a PIN is set.\n\n• sim-id (scalar) – since 0.99\n\nSpecify the SIM unique identifier (as given by the WWAN  management  service)  which\nthis  connection applies to.  If given, the connection will apply to any device also\nallowed by device-id which contains a SIM card matching the given identifier.\n\n• sim-operator-id (scalar) – since 0.99\n\nSpecify the MCC/MNC string (such as 310260 or 21601) which  identifies  the  carrier\nthat  this  connection  should apply to.  If given, the connection will apply to any\ndevice also allowed by device-id and sim-id which contains a SIM card provisioned by\nthe given operator.\n\n• username (scalar) – since 0.99\n\nSpecify the username used to authenticate with the carrier  network.   This  can  be\nomitted if auto-config is enabled.\n"
                },
                {
                    "name": "Properties for device type wifis",
                    "content": "Status: Optional.\n\nPurpose: Use the wifis key to configure Wi-Fi access points.\n\nStructure:  The key consists of a mapping of Wi-Fi IDs.  Each wifi has a number of configura‐\ntion options.  The general configuration structure for Wi-Fi is shown below.\n\nnetwork:\nversion: 2\nwifis:\nwlp0s1:\naccess-points:\n\"networkssidname\":\npassword: \"\"\n\nNote that systemd-networkd does not have native support Wi-Fi, so you need wpasupplicant  in‐\nstalled if you let the networkd renderer handle Wi-Fi.\n\n• access-points (mapping)\n\nThis  provides pre-configured connections to NetworkManager.  Note that users can of\ncourse select other access points/SSIDs.  The keys of the mapping are the SSIDs, and\nthe values are mappings with the following supported properties:\n\n• password (scalar)\n\nEnable WPA/WPA2 authentication and set the passphrase for it.  If neither this nor\nan auth block are given, the network is assumed to be open.  The setting\n\npassword: \"S3kr1t\"\n\nis equivalent to\n\nauth:\nkey-management: psk\npassword: \"S3kr1t\"\n\n• mode (scalar)\n\nPossible access point modes are infrastructure (the default), ap (create an access\npoint to which other devices can connect), and adhoc (peer to peer networks  with‐\nout a central access point).  ap is only supported with NetworkManager.\n\n• bssid (scalar) – since 0.99\n\nIf specified, directs the device to only associate with the given access point.\n\n• band (scalar) – since 0.99\n\nPossible  bands are 5GHz (for 5GHz 802.11a) and 2.4GHz (for 2.4GHz 802.11), do not\nrestrict the 802.11 frequency band of the network if unset (the default).\n\n• channel (scalar) – since 0.99\n\nWireless channel to use for the Wi-Fi connection.  Because channel numbers overlap\nbetween bands, this property takes effect only if the band property is also set.\n\n• hidden (boolean) – since 0.100\n\nSet to true to change the SSID scan technique for connecting to hidden Wi-Fi  net‐\nworks.  Note this may have slower performance compared to false (the default) when\nconnecting to publicly broadcast SSIDs.\n\n• wakeonwlan (sequence of scalars) – since 0.99\n\nThis  enables WakeOnWLan on supported devices.  Not all drivers support all options.\nMay be any combination of any, disconnect, magicpkt, gtkrekeyfailure, eapidenti‐\ntyreq, fourwayhandshake, rfkillrelease or tcp (NetworkManager only).  Or the ex‐\nclusive default flag (the default).\n\n• regulatory-domain (scalar) – since 0.105\n\nThis can be used to define the radio's regulatory domain, to make use of  additional\nWi-Fi  channels  outside  the  \"world  domain\".  Takes an ISO/ IEC 3166 country code\n(like  GB)  or  00  to  reset   to   the   \"world   domain\".    See   wireless-regdb\n(https://git.kernel.org/pub/scm/linux/kernel/git/sforshee/wireless-\nregdb.git/tree/db.txt) for available values.\n\nRequires  dependency:  iw,  if it is to be used outside the networkd (wpasupplicant)\nback end.\n"
                },
                {
                    "name": "Properties for device type bridges",
                    "content": "Status: Optional.\n\nPurpose: Use the bridges key to create Bridge interfaces.\n\nStructure: The key consists of a mapping of Bridge interface names.  Each bridge has  an  op‐\ntional list of interfaces that will be bridged together.  The interfaces listed in the inter‐\nfaces  key (enp5s0 and enp5s1 below) must also be defined in your Netplan configuration.  The\ngeneral configuration structure for Bridges is shown below.\n\nnetwork:\nbridges:\nbr0:\ninterfaces:\n- enp5s0\n- enp5s1\ndhcp4: true\n...\n\nWhen applied, a virtual interface of type bridge called br0 will be created in the system.\n\nThe specific settings for bridges are defined below.\n\n• interfaces (sequence of scalars)\n\nAll devices matching this ID list will be added to the bridge.  This may be an empty\nlist, in which case the bridge will be brought online with no member interfaces.\n\nExample:\n\nnetwork:\nethernets:\nswitchports:\nmatch: {name: \"enp2*\"}\n[...]\nbridges:\nbr0:\ninterfaces: [switchports]\n\n• parameters (mapping)\n\nCustomisation parameters for special bridging options.  Time intervals may  need  to\nbe expressed as a number of seconds or milliseconds: the default value type is spec‐\nified  below.   If  necessary,  time  intervals can be qualified using a time suffix\n(such as s for seconds, ms for milliseconds) to allow for more control over its  be‐\nhaviour.\n\n• ageing-time, aging-time (scalar)\n\nSet  the  period  of time to keep a MAC address in the forwarding database after a\npacket is received.  This maps to the AgeingTimeSec= property  when  the  networkd\nrenderer  is  used.  If no time suffix is specified, the value will be interpreted\nas seconds.\n\n• priority (scalar)\n\nSet the priority value for the bridge.  This value should be a  number  between  0\nand 65535.  Lower values mean higher priority.  The bridge with the higher priori‐\nty will be elected as the root bridge.\n\n• port-priority (mapping)\n\nSet the port priority per interface.  The priority value is a number between 0 and\n63.   This  metric  is  used  in the designated port and root port selection algo‐\nrithms.\n\nExample:\n\nnetwork:\nethernets:\neth0:\ndhcp4: false\neth1:\ndhcp4: false\nbridges:\nbr0:\ninterfaces: [eth0, eth1]\nparameters:\nport-priority:\neth0: 10\neth1: 20\n\n• forward-delay (scalar)\n\nSpecify the period of time the bridge will remain in Listening and Learning states\nbefore getting to the Forwarding state.  This field maps to  the  ForwardDelaySec=\nproperty  for  the  networkd  renderer.  If no time suffix is specified, the value\nwill be interpreted as seconds.\n\n• hello-time (scalar)\n\nSpecify the interval between two hello packets being sent out from  the  root  and\ndesignated  bridges.   Hello  packets  communicate  information  about the network\ntopology.  When the networkd renderer is used,  this  maps  to  the  HelloTimeSec=\nproperty.   If  no time suffix is specified, the value will be interpreted as sec‐\nonds.\n\n• max-age (scalar)\n\nSet the maximum age of a hello packet.  If the last hello  packet  is  older  than\nthat  value,  the bridge will attempt to become the root bridge.  This maps to the\nMaxAgeSec= property when the networkd renderer is used.   If  no  time  suffix  is\nspecified, the value will be interpreted as seconds.\n\n• path-cost (mapping)\n\nSet the per-interface cost of a path on the bridge.  Faster interfaces should have\na  lower  cost.   This  allows a finer control on the network topology so that the\nfastest paths are available whenever possible.\n\nExample:\n\nnetwork:\nethernets:\neth0:\ndhcp4: false\neth1:\ndhcp4: false\nbridges:\nbr0:\ninterfaces: [eth0, eth1]\nparameters:\npath-cost:\neth0: 100\neth1: 200\n\n• stp (boolean)\n\nDefine whether the bridge should use Spanning Tree Protocol.  The default value is\ntrue, which means that Spanning Tree should be used.\n"
                },
                {
                    "name": "Properties for device type dummy-devices",
                    "content": "Status: Optional.\n\nPurpose: Use the dummy-devices key to create virtual interfaces.\n\nStructure: The key consists of a mapping of interface names.  Dummy devices are  virtual  de‐\nvices that can be used to route packets to without actually transmitting them.\n\nnetwork:\ndummy-devices:\ndm0:\naddresses:\n- 192.168.0.123/24\n...\n\nWhen applied, a virtual interface called dm0 will be created in the system.\n\nSee the \"Properties for all device types\" section for the list of properties that can be used\nwith this type of interface.\n"
                },
                {
                    "name": "Properties for device type bonds",
                    "content": "Status: Optional.\n\nPurpose: Use the bonds key to create Bond (Link Aggregation) interfaces.\n\nStructure:  The key consists of a mapping of Bond interface names.  Each bond has an optional\nlist of interfaces that will be part of the aggregation.  The interfaces listed in the inter‐\nfaces key must also be defined in your  Netplan  configuration.   The  general  configuration\nstructure for Bonds is shown below.\n\nnetwork:\nbonds:\nbond0:\ninterfaces:\n- enp5s0\n- enp5s1\n- enp5s2\nparameters:\nmode: active-backup\n...\n\nWhen applied, a virtual interface of type bond called bond0 will be created in the system.\n\nThe specific settings for bonds are defined below.\n\n• interfaces (sequence of scalars)\n\nAll devices matching this ID list will be added to the bond.\n\nExample:\n\nnetwork:\nethernets:\nswitchports:\nmatch: {name: \"enp2*\"}\n[...]\nbonds:\nbond0:\ninterfaces: [switchports]\n\n• parameters (mapping)\n\nCustomisation parameters for special bonding options.  Time intervals may need to be\nexpressed  as  a number of seconds or milliseconds: the default value type is speci‐\nfied below.  If necessary, time intervals can be qualified using a time suffix (such\nas s for seconds, ms for milliseconds) to allow for more control over its behaviour.\n\n• mode (scalar)\n\nSet the bonding mode used for the interfaces.  The default  is  balance-rr  (round\nrobin).   Possible  values  are balance-rr, active-backup, balance-xor, broadcast,\n802.3ad, balance-tlb and balance-alb.  For Open vSwitch active-backup and the  ad‐\nditional modes balance-tcp and balance-slb are supported.\n\n• lacp-rate (scalar)\n\nSet  the  rate  at  which LACPDUs are transmitted.  This is only useful in 802.3ad\nmode.  Possible values are slow (30 seconds, default), and fast (every second).\n\n• mii-monitor-interval (scalar)\n\nSpecifies the interval for MII monitoring (verifying if an interface of  the  bond\nhas  carrier).   The default is 0; which disables MII monitoring.  This is equiva‐\nlent to the MIIMonitorSec= field for the networkd back end.  If no time suffix  is\nspecified, the value will be interpreted as milliseconds.\n\n• min-links (scalar)\n\nThe minimum number of links up in a bond to consider the bond interface to be up.\n\n• transmit-hash-policy (scalar)\n\nSpecifies  the transmit hash policy for the selection of ports.  This is only use‐\nful in balance-xor, 802.3ad and balance-tlb modes.  Possible  values  are  layer2,\nlayer3+4, layer2+3, encap2+3 and encap3+4.\n\n• ad-select (scalar)\n\nSet  the  aggregation  selection  mode.  Possible values are stable, bandwidth and\ncount.  This option is only used in 802.3ad mode.\n\n• all-members-active (boolean) – since 0.106\n\nIf the bond should drop duplicate frames received on inactive ports, set this  op‐\ntion to false.  If they should be delivered, set this option to true.  The default\nvalue is false and is the desirable behaviour in most situations.\n\nAlias: all-slaves-active\n\n• arp-interval (scalar)\n\nSet  the interval value for how frequently ARP link monitoring should happen.  The\ndefault value is 0, which disables ARP monitoring.  For  the  networkd  back  end,\nthis  maps  to  the ARPIntervalSec= property.  If no time suffix is specified, the\nvalue will be interpreted as milliseconds.\n\n• arp-ip-targets (sequence of scalars)\n\nIP addresses of other hosts on the link which should be sent ARP requests in order\nto validate that a port is up.  This option is only used when arp-interval is  set\nto a value other than 0.  At least one IP address must be given for ARP link moni‐\ntoring  to function.  Only IPv4 addresses are supported.  You can specify up to 16\nIP addresses.  The default value is an empty list.\n\n• arp-validate (scalar)\n\nConfigure how ARP replies are to be validated  when  using  ARP  link  monitoring.\nPossible values are none, active, backup, and all.\n\n• arp-all-targets (scalar)\n\nSpecify  whether  to use any ARP IP target being up as sufficient for a port to be\nconsidered up; or if all the targets must be up.  This is only  used  for  active-\nbackup mode when arp-validate is enabled.  Possible values are any and all.\n\n• up-delay (scalar)\n\nSpecify  the delay before enabling a link once the link is physically up.  The de‐\nfault value is 0.  This maps to the UpDelaySec= property for the networkd  render‐\ner.   This option is only valid for the miimon link monitor.  If no time suffix is\nspecified, the value will be interpreted as milliseconds.\n\n• down-delay (scalar)\n\nSpecify the delay before disabling a link once the link has been  lost.   The  de‐\nfault  value  is 0.  This maps to the DownDelaySec= property for the networkd ren‐\nderer.  This option is only valid for the miimon link monitor.  If no time  suffix\nis specified, the value will be interpreted as milliseconds.\n\n• fail-over-mac-policy (scalar)\n\nSet whether to set all ports to the same MAC address when adding them to the bond,\nor how else the system should handle MAC addresses.  The possible values are none,\nactive and follow.\n\n• gratuitous-arp (scalar)\n\nSpecify  how  many ARP packets to send after failover.  Once a link is up on a new\nport, a notification is sent and possibly repeated if this value is set to a  num‐\nber  greater  than  1.   The default value is 1 and valid values are between 1 and\n255.  This only affects active-backup mode.\n\nFor historical reasons, the misspelling gratuitious-arp is also accepted  and  has\nthe same function.\n\n• packets-per-member (scalar) – since 0.106\n\nIn  balance-rr  mode, specifies the number of packets to transmit on a port before\nswitching to the next.  When this value is set to 0, ports are chosen  at  random.\nAllowable  values  are between 0 and 65535.  The default value is 1.  This setting\nis only used in balance-rr mode.\n\nAlias: packets-per-slave\n\n• primary-reselect-policy (scalar)\n\nSet the reselection policy for the primary port.  On failure of the  active  port,\nthe  system  will use this policy to decide how the new active port will be chosen\nand how recovery will be handled.  The possible  values  are  always,  better  and\nfailure.\n\n• resend-igmp (scalar)\n\nIn  modes  balance-rr,  active-backup, balance-tlb and balance-alb, a failover can\nswitch IGMP traffic from one port to another.\n\nThis parameter specifies how many IGMP membership reports are issued on a failover\nevent.  Values range from 0 to 255.  0 disables sending membership reports.   Oth‐\nerwise, the first membership report is sent on failover and subsequent reports are\nsent at 200ms intervals.\n\n• learn-packet-interval (scalar)\n\nSpecify  the  interval  between  sending learning packets to each port.  The value\nrange is between 1 and 0x7fffffff.  The default value is 1.  This option only  af‐\nfects  balance-tlb and balance-alb modes.  Using the networkd renderer, this field\nmaps to the LearnPacketIntervalSec= property.  If no time suffix is specified, the\nvalue will be interpreted as seconds.\n\n• primary (scalar)\n\nSpecify a device to be used as a primary port, or preferred device  to  use  as  a\nport  for  the bond (i.e.  the preferred device to send data through), whenever it\nis available.  This only affects active-backup, balance-alb and balance-tlb modes.\n\n(yaml-tunnels)= ## Properties for device type tunnels\n\nStatus: Optional.\n\nPurpose: Use the tunnels key to create virtual tunnel interfaces.\n\nStructure: The key consists of a mapping of tunnel interface names.  Each tunnel requires the\nidentification of the tunnel mode (see the section mode  below  for  the  list  of  supported\nmodes).  The general configuration structure for Tunnels is shown below.\n\nnetwork:\ntunnels:\ntunnel0:\nmode: SCALAR\n...\n\nWhen  applied,  a virtual interface called tunnel0 will be created in the system.  Its opera‐\ntion mode is defined by the property mode.\n\nTunnels allow traffic to pass as if it was between systems on the  same  local  network,  al‐\nthough  systems  may be far from each other but reachable via the Internet.  They may be used\nto support IPv6 traffic on a network where the ISP does not provide the service, or to extend\nand \"connect\" separate local networks.  See Tunnelingprotocol  (https://en.wikipedia.org/wi‐\nki/Tunnelingprotocol) for more general information about tunnels.\n\nThe specific settings for tunnels are defined below.\n\n• mode (scalar)\n\nDefines  the  tunnel mode.  Valid options are sit, gre, ip6gre, ipip, ipip6, ip6ip6,\nvti, vti6, wireguard, vxlan, gretap and ip6gretap modes.  In addition, the  Network‐\nManager back end supports isatap tunnels.\n\n• local (scalar)\n\nDefines  the  address  of the local endpoint of the tunnel.  (For VXLAN) This should\nmatch one of the parent's IP addresses or make use of the networkd special values.\n\n• remote (scalar)\n\nDefines the address of the remote endpoint of the tunnel or multicast group  IP  ad‐\ndress for VXLAN.\n\n• ttl (scalar) – since 0.103\n\nDefines the Time To Live (TTL) of the tunnel.  Takes a number in the range 1..255.\n\n• key (scalar or mapping)\n\nDefine  keys  to  use  for the tunnel.  The key can be a number or a dotted quad (an\nIPv4 address).  For wireguard it can be a base64-encoded private key or (as of  net‐\nworkd  v242+)  an absolute path to a file, containing the private key (since 0.100).\nIt is used for identification of IP transforms.  This is only required for  vti  and\nvti6 when using the networkd back end.\n\nThis field may be used as a scalar (meaning that a single key is specified and to be\nused  for  input,  output  and  private key), or as a mapping, where you can further\nspecify input/output/private.\n\n• input (scalar)\n\nThe input key for the tunnel\n\n• output (scalar)\n\nThe output key for the tunnel\n\n• private (scalar) – since 0.100\n\nA base64-encoded private key required for WireGuard tunnels.   When  the  systemd-\nnetworkd  back  end  (v242+)  is used, this can also be an absolute path to a file\ncontaining the private key.\n\n• private-key-flags (sequence of scalars) – since 0.107\n\nPrivate key flags used by NetworkManager.  Possible values are: agent-owned,  not-\nsaved and not-required.\n\nagent-owned:  a user-session secret agent is responsible for providing and storing\nthis secret.\n\nnot-saved: this secret should not be saved but should be requested from  the  user\neach time it is required.\n\nnot-required:  this  flag  hints that the secret is not required and should not be\nrequested from the user.\n\nExample:\n\nnetwork:\nrenderer: NetworkManager\ntunnels:\nwg0:\nmode: wireguard\nport: 5182\nkey:\nprivate-key-flags:\n- agent-owned\npeers:\n- keys:\npublic: rlbInAj0qV69CysWPQY7KEBnKxpYCpaWqOs/dLevdWc=\nallowed-ips: [0.0.0.0/0, \"2001:fe:ad:de:ad:be:ef:1/24\"]\nkeepalive: 23\nendpoint: 1.2.3.4:5\n\n• keys (scalar or mapping)\n\nAlternate name for the key field.  See above.\n\nExamples:\n\nnetwork:\ntunnels:\ntun0:\nmode: gre\nlocal: ...\nremote: ...\nkeys:\ninput: 1234\noutput: 5678\n\nnetwork:\ntunnels:\ntun0:\nmode: vti6\nlocal: ...\nremote: ...\nkey: 59568549\n\nnetwork:\ntunnels:\nwg0:\nmode: wireguard\naddresses: [...]\npeers:\n- keys:\npublic: rlbInAj0qV69CysWPQY7KEBnKxpYCpaWqOs/dLevdWc=\nshared: /path/to/shared.key\n...\nkey: mNb7OIIXTdgW4khM7OFlzJ+UPs7lmcWHV7xjPgakMkQ=\n\nnetwork:\ntunnels:\nwg0:\nmode: wireguard\naddresses: [...]\npeers:\n- keys:\npublic: rlbInAj0qV69CysWPQY7KEBnKxpYCpaWqOs/dLevdWc=\n...\nkeys:\nprivate: /path/to/priv.key\n\nWireGuard specific keys:\n\n• mark (scalar) – since 0.100\n\nFirewall mark for outgoing WireGuard packets from this interface, optional.\n\n• port (scalar) – since 0.100\n\nUDP port to listen at or auto.  Optional, defaults to auto.\n\n• peers (sequence of mappings) – since 0.100\n\nA list of peers, each having keys documented below.\n\nExample:\n\nnetwork:\ntunnels:\nwg0:\nmode: wireguard\nkey: /path/to/private.key\nmark: 42\nport: 5182\npeers:\n- keys:\npublic: rlbInAj0qV69CysWPQY7KEBnKxpYCpaWqOs/dLevdWc=\nallowed-ips: [0.0.0.0/0, \"2001:fe:ad:de:ad:be:ef:1/24\"]\nkeepalive: 23\nendpoint: 1.2.3.4:5\n- keys:\npublic: M9nt4YujIOmNrRmpIRTmYSfMdrpvE7u6WkG8FY8WjG4=\nshared: /some/shared.key\nallowed-ips: [10.10.10.20/24]\nkeepalive: 22\nendpoint: 5.4.3.2:1\n\n• endpoint (scalar) – since 0.100\n\nRemote endpoint IPv4/IPv6 address or a hostname, followed by a colon  and  a  port\nnumber.\n\n• allowed-ips (sequence of scalars) – since 0.100\n\nA  list of IP (v4 or v6) addresses with CIDR masks from which this peer is allowed\nto send incoming traffic and to which outgoing traffic for this peer is  directed.\nThe catch-all 0.0.0.0/0 may be specified for matching all IPv4 addresses, and ::/0\nmay be specified for matching all IPv6 addresses.\n\n• keepalive (scalar) – since 0.100\n\nAn interval in seconds, between 1 and 65535 inclusive, of how often to send an au‐\nthenticated  empty  packet to the peer for the purpose of keeping a stateful fire‐\nwall or NAT mapping valid persistently.  Optional.\n\n• keys (mapping) – since 0.100\n\nDefine keys to use for the WireGuard peers.\n\nThis field can be used as a mapping, where you can further specify the public  and\nshared keys.\n\n• public (scalar) – since 0.100\n\nA base64-encoded public key, required for WireGuard peers.\n\n• shared (scalar) – since 0.100\n\nA  base64-encoded  pre-shared key.  Optional for WireGuard peers.  When the sys‐\ntemd-networkd back end (v242+) is used, this can also be an absolute path  to  a\nfile containing the pre-shared key.\n\nVXLAN specific keys:\n\n• id (scalar) – since 0.105\n\nThe VXLAN Network Identifier (VNI or VXLAN Segment ID).  Takes a number in the range\n1..16777215.\n\n• link (scalar) – since 0.105\n\nNetplan ID of the parent device definition to which this VXLAN gets connected.\n\n• type-of-service (scalar) – since 0.105\n\nThe Type Of Service byte value for a VXLAN interface.\n\n• mac-learning (scalar) – since 0.105\n\nTakes a boolean.  When true, enables dynamic MAC learning to discover remote MAC ad‐\ndresses.\n\n• ageing, aging (scalar) – since 0.105\n\nThe lifetime of Forwarding Database entry learned by the kernel, in seconds.\n\n• limit (scalar) – since 0.105\n\nConfigures maximum number of FDB entries.\n\n• arp-proxy (scalar) – since 0.105\n\nTakes  a boolean.  When true, bridge-connected VXLAN tunnel endpoint answers ARP re‐\nquests from the local bridge on behalf of remote Distributed Overlay Virtual  Ether‐\nnet (DOVE) clients.  Defaults to false.\n\n• notifications (sequence of scalars) – since 0.105\n\nTakes  the  flags l2-miss and l3-miss to enable netlink LLADDR and/or netlink IP ad‐\ndress miss notifications.\n\n• short-circuit (scalar) – since 0.105\n\nTakes a boolean.  When true, route short circuiting is turned on.\n\n• checksums (sequence of scalars) – since 0.105\n\nTakes the flags udp, zero-udp6-tx, zero-udp6-rx, remote-tx and remote-rx  to  enable\ntransmitting  UDP checksums in VXLAN/IPv4, send/receive zero checksums in VXLAN/IPv6\nand enable sending/receiving checksum offloading in VXLAN.\n\n• extensions (sequence of scalars) – since 0.105\n\nTakes the flags group-policy and  generic-protocol  to  enable  the  \"Group  Policy\"\nand/or \"Generic Protocol\" VXLAN extensions.\n\n• port (scalar) – since 0.105\n\nConfigures  the default destination UDP port.  If the destination port is not speci‐\nfied then Linux kernel default will be used.  Set to 4789 to get the  IANA  assigned\nvalue.\n\n• port-range (sequence of scalars) – since 0.105\n\nConfigures  the  source port range for the VXLAN.  The kernel assigns the source UDP\nport based on the flow to help the receiver to do load balancing.  When this  option\nis  not set, the normal range of local UDP ports is used.  Uses the form [LOWER, UP‐\nPER].\n\n• flow-label (scalar) – since 0.105\n\nSpecifies the flow label to use in outgoing packets.  The valid range is 0-1048575.\n\n• do-not-fragment (scalar) – since 0.105\n\nAllows setting the IPv4 Do not Fragment (DF)  bit  in  outgoing  packets.   Takes  a\nboolean value.  When unset, the kernel default will be used.\n"
                },
                {
                    "name": "Properties for device type virtual-ethernets",
                    "content": "Status: Optional.\n\nPurpose: Use the virtual-ethernets key to create virtual Ethernet interfaces.\n\nStructure: The key consists of a mapping of veth interface names.  Each veth requires a peer.\nIn  order to have a fully working veth pair, both devices must be defined, i.e., only setting\nthe peer key with the peer name is not enough, the peer interface must also  be  defined  and\nset  the  first one as its peer.  The general configuration structure for virtual Ethernet is\nshown below.\n\nnetwork:\nvirtual-ethernets:\nveth0:\npeer: veth1\nveth1:\npeer: veth0\n\nWhen applied, two virtual interfaces called veth0 and veth1 will be created in the system.\n\nVirtual Ethernet devices act as tunnels forwarding traffic from one interface to  the  other.\nThey  can  be  used  to  connect two separate virtual networks such as network namespaces and\nbridges.  It's not possible to move virtual-ethernets to different namespaces through Netplan\nat the present moment.\n\nThe specific settings for virtual-ethernets are defined below.\n\n• peer (scalar)\n\nDefines the virtual-ethernet peer.  The peer interface must also be a virtual-ether‐\nnet device.\n\nBelow is a complete example that uses a pair of virtual Ethernet devices to create a link be‐\ntween two bridges:\n\nnetwork:\nversion: 2\nrenderer: networkd\nvirtual-ethernets:\nveth0-peer1:\npeer: veth0-peer2\nveth0-peer2:\npeer: veth0-peer1\n\nbridges:\nbr0:\ninterfaces:\n- veth0-peer1\nbr1:\ninterfaces:\n- veth0-peer2\n"
                },
                {
                    "name": "Properties for device type vlans",
                    "content": "Status: Optional.\n\nPurpose: Use the vlans key to create VLAN interfaces.\n\nStructure: The key consists of a mapping of VLAN interface names.  The interface used in  the\nlink  option (enp5s0 in the example below) must also be defined in the Netplan configuration.\nThe general configuration structure for VLANs is shown below.\n\nnetwork:\nvlans:\nvlan123:\nid: 123\nlink: enp5s0\ndhcp4: yes\n\nThe specific settings for VLANs are defined below.\n\n• id (scalar)\n\nVLAN ID, a number between 0 and 4094.\n\n• link (scalar)\n\nNetplan ID of the underlying device definition on which this VLAN gets created.\n\nExample:\n\nnetwork:\nethernets:\neno1: {...}\nvlans:\nen-intra:\nid: 1\nlink: eno1\ndhcp4: yes\nen-vpn:\nid: 2\nlink: eno1\naddresses: [...]\n"
                },
                {
                    "name": "Properties for device type vrfs",
                    "content": "Status: Optional.\n\nPurpose: Use the vrfs key to create Virtual Routing and Forwarding (VRF) interfaces.\n\nStructure: The key consists of a mapping of VRF interface names.  The interface used  in  the\nlink  option (enp5s0 in the example below) must also be defined in the Netplan configuration.\nThe general configuration structure for VRFs is shown below.\n\nnetwork:\nrenderer: networkd\nvrfs:\nvrf1:\ntable: 1\ninterfaces:\n- enp5s0\nroutes:\n- to: default\nvia: 10.10.10.4\nrouting-policy:\n- from: 10.10.10.42\n\n• table (scalar) – since 0.105\n\nThe numeric routing table identifier.  This setting is compulsory.\n\n• interfaces (sequence of scalars) – since 0.105\n\nAll devices matching this ID list will be added to the VRF.  This may  be  an  empty\nlist, in which case the VRF will be brought online with no member interfaces.\n\n• routes (sequence of mappings) – since 0.105\n\nConfigure  static  routing for the device; see the Routing section.  The table value\nis implicitly set to the VRF table.\n\n• routing-policy (sequence of mappings) – since 0.105\n\nConfigure policy routing for the device; see the Routing section.  The  table  value\nis implicitly set to the VRF table.\n\nExample:\n\nnetwork:\nvrfs:\nvrf20:\ntable: 20\ninterfaces: [ br0 ]\nroutes:\n- to: default\nvia: 10.10.10.3\nrouting-policy:\n- from: 10.10.10.42\n[...]\nbridges:\nbr0:\ninterfaces: []\n"
                },
                {
                    "name": "Properties for device type nm-devices",
                    "content": "Status: Optional.  Its use is not recommended.\n\nPurpose:  Use the nm-devices key to configure device types that are not supported by Netplan.\nThis is NetworkManager specific configuration.\n\nStructure: The key consists of a mapping of NetworkManager connections.  The  nm-devices  de‐\nvice  type is for internal use only and should not be used in normal configuration files.  It\nenables a fallback mode for unsupported settings, using the passthrough mapping.  The general\nconfiguration structure for NM connections is shown below.\n\nnetwork:\nversion: 2\nnm-devices:\nNM-db5f0f67-1f4c-4d59-8ab8-3d278389cf87:\nrenderer: NetworkManager\nnetworkmanager:\nuuid: \"db5f0f67-1f4c-4d59-8ab8-3d278389cf87\"\nname: \"myvpnconnection\"\npassthrough:\nconnection.type: \"vpn\"\nvpn.ca: \"path to ca.crt\"\nvpn.cert: \"path to client.crt\"\nvpn.cipher: \"AES-256-GCM\"\nvpn.connection-type: \"tls\"\nvpn.dev: \"tun\"\nvpn.key: \"path to client.key\"\nvpn.remote: \"1.2.3.4:1194\"\nvpn.service-type: \"org.freedesktop.NetworkManager.openvpn\"\n"
                },
                {
                    "name": "Back end-specific configuration parameters",
                    "content": "In addition to the other fields available to configure interfaces, some back ends may require\nto record some of their own parameters in Netplan, especially if the Netplan definitions  are\ngenerated  automatically by the consumer of that back end.  Currently, this is only used with\nNetworkManager.\n\n• networkmanager (mapping) – since 0.99\n\nKeeps the NetworkManager-specific configuration parameters used  by  the  daemon  to\nrecognise connections.\n\n• name (scalar) – since 0.99\n\nSet the display name for the connection.\n\n• uuid (scalar) – since 0.99\n\nDefines the UUID (unique identifier) for this connection, as generated by Network‐\nManager itself.\n\n• stable-id (scalar) – since 0.99\n\nDefines  the stable ID (a different form of a connection name) used by NetworkMan‐\nager in case the name of the connection might otherwise change, such as when shar‐\ning connections between users.\n\n• device (scalar) – since 0.99\n\nDefines the interface name for which this connection applies.\n\n• passthrough (mapping) – since 0.102\n\nCan be used as a fallback mechanism to missing key-file settings.\n"
                }
            ]
        },
        "SEE ALSO": {
            "content": "netplan-generate(8), netplan-apply(8), netplan-try(8), netplan-get(8),  netplan-set(8),  net‐\nplan-info(8),  netplan-ip(8), netplan-rebind(8), netplan-status(8), netplan-dbus(8), systemd-\nnetworkd(8), NetworkManager(8)\n",
            "subsections": []
        },
        "AUTHORS": {
            "content": "Mathieu Trudel-Lapierre  (<cyphermox@ubuntu.com>);  Martin  Pitt  (<martin.pitt@ubuntu.com>);\nLukas Märdian (<slyon@ubuntu.com>).\n\nIntroduction to Netplan(5)",
            "subsections": []
        }
    },
    "summary": "netplan - YAML network configuration abstraction for various backends",
    "flags": [],
    "examples": [],
    "see_also": [
        {
            "name": "netplan-generate",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/netplan-generate/8/json"
        },
        {
            "name": "netplan-apply",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/netplan-apply/8/json"
        },
        {
            "name": "netplan-try",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/netplan-try/8/json"
        },
        {
            "name": "netplan-get",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/netplan-get/8/json"
        },
        {
            "name": "netplan-set",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/netplan-set/8/json"
        },
        {
            "name": "plan-info",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/plan-info/8/json"
        },
        {
            "name": "netplan-ip",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/netplan-ip/8/json"
        },
        {
            "name": "netplan-rebind",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/netplan-rebind/8/json"
        },
        {
            "name": "netplan-status",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/netplan-status/8/json"
        },
        {
            "name": "netplan-dbus",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/netplan-dbus/8/json"
        },
        {
            "name": "networkd",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/networkd/8/json"
        },
        {
            "name": "NetworkManager",
            "section": "8",
            "url": "https://www.chedong.com/phpMan.php/man/NetworkManager/8/json"
        }
    ]
}