linux-system-roles/network

Coverage Status
CI Testing
Code Style: black
Language grade: Python

Overview

The network role enables users to configure network on the target machines.
This role can be used to configure:

Introduction

The network role supports two providers: nm and initscripts. nm is
used by default in RHEL7 and initscripts in RHEL6. These providers can be
configured per host via the network_provider variable. In
absence of explicit configuration, it is autodetected based on the
distribution. However, note that either nm or initscripts is not tied to a certain
distribution. The network role works everywhere the required API is available.
This means that nm requires at least NetworkManager’s API version 1.2 available.
For initscripts, the legacy network service is required as used in Fedora or RHEL.

For each host a list of networking profiles can be configured via the
network_connections variable.

Note that the network role primarily operates on networking profiles
(connections) and not on devices, but it uses the profile name by default as
the interface name. It is also possible to create generic profiles, by creating
for example a profile with a certain IP configuration without activating the
profile. To apply the configuration to the actual networking interface, use the
nmcli commands on the target system.

Warning: The network role updates or creates all connection profiles on
the target system as specified in the network_connections variable. Therefore,
the network role removes options from the specified profiles if the options are
only present on the system but not in the network_connections variable.
Exceptions are mentioned below.

Variables

The network role is configured via variables starting with network_ as
the name prefix. List of variables:

Examples of Variables

Setting the variables

network_provider: nm
network_connections:
  - name: eth0
    #...
network_allow_restart: yes

Options

The network_connections variable is a list of dictionaries that include the
following options. List of options:

name (usually required)

The name option identifies the connection profile to be configured. It is not
the name of the networking interface for which the profile applies, though we
can associate the profile with an interface and give them the same name. Note
that you can have multiple profiles for the same device, but only one profile
can be active on the device each time. For NetworkManager, a connection can
only be active at one device each time.

You can also use the same connection profile multiple times. Therefore, it is possible
to create a profile and activate it separately.

Note: The network role will only change the profiles that are specified in the
network_connections variable. Therefore, if only the ports of a profile are specified
to be removed from the controller and the controller is not specified, then the
controller profile will remain on the system. This can happen, if for example all ports
are removed from a bond interface.

Note: To remove all profiles on a system that are not specified in the
network_connections variable, add an entry without a name and persistent_state: absent. This will match and remove all remaining profiles:

network_connections:
  - name: eth0  # profiles to keep/configure on the system
    [...]

  - persistent_state: absent  # remove all other profiles

state

The state option identifies what is the runtime state of each connection profile. The
state option (optional) can be set to the following values:

state: up

When the state option is set to up, you can also specify the wait option (optional):

Note that state: up always re-activates the profile and possibly changes the
networking configuration, even if the profile was already active before. As
a consequence, state: up always changes the system.

state: down

You can deactivate a connection profile, even if is currently not active. As a
consequence, state: down always changes the system.

Note that if the state option is unset, the connection profile’s runtime state will
not be changed.

persistent_state

The persistent_state option identifies if a connection profile is persistent (saved on
disk). The persistent_state option can be set to the following values:

persistent_state: present (default)

Note that if persistent_state is present and the connection profile contains
the type option, the profile will be created or updated. If the connection profile is
incomplete (no type option), the behavior is undefined. Also, the present value
does not directly result in a change in the network configuration. If the state option
is not set to up, the profile is only created or modified, not activated.

For NetworkManager, the new connection profile is created with the autoconnect
option enabled by default. Therefore, NetworkManager can activate the new
profile on a currently disconnected device. (rh#1401515).

persistent_state: absent

The absent value ensures that the profile is not present on the
target host. If a profile with the given name exists, it will be deleted. In this case:

Note: For profiles that only contain a state option, the network role only activates
or deactivates the connection without changing its configuration.

type

The type option can be set to the following values:

type: ethernet

If the type is ethernet, then there can be an extra ethernet dictionary with the following
items (options): autoneg, speed and duplex, which correspond to the
settings of the ethtool utility with the same name.

Note that the speed and duplex link settings are required when autonegotiation is
disabled (autoneg: no).

type: bridge, type: bond, type: team

The bridge, bond, team device types work similar. Note that team is not
supported in RHEL6 kernels, and has been deprecated in RHEL 9.

For ports, the port_type and controller properties must be set. Note that ports
should not have ip settings.

The controller refers to the name of a profile in the Ansible
playbook. It is neither an interface-name nor a connection-id of
NetworkManager.

As controller refers to other profiles of the same or another play, the order of the
connections list matters. Profiles that are referenced by other profiles need to be
specified first. Also, --check ignores the value of the controller and assumes it
will be present during a real run. That means, in presence of an invalid controller,
--check may signal success but the actual play run fails.

The team type uses roundrobin as the runner configuration. No further
configuration is supported at the moment.

type: vlan

Similar to controller, the parent references the connection profile in the ansible
role.

type: macvlan

Similar to controller and vlan, the parent references the connection profile in
the ansible role.

type: wireless

The wireless type supports WPA-PSK (password) authentication, WPA-EAP (802.1x)
authentication, WPA3-Personal SAE (password) authentication and Enhanced Open (OWE).

nm (NetworkManager) is the only supported network_provider for this type.

If WPA-EAP is used, ieee802_1x settings must be defined in the
ieee802_1x option.

The following options are supported:

autoconnect

By default, profiles are created with autoconnect enabled.

mac

The mac address is optional and restricts the profile to be usable only on
devices with the given MAC address. mac is only allowed for type
ethernet or infiniband to match a non-virtual device with the
profile. The value of the mac address needs to be specified in hexadecimal notation
using colons (for example: mac: "00:00:5e:00:53:5d"). To avoid YAML parsing mac
addresses as integers in sexagesimal (base 60) notation (see
https://yaml.org/spec/1.1/#id858600), it is recommended to always quote the value
with double quotes and sometimes it is necessary.

mtu

The mtu option denotes the maximum transmission unit for the profile’s
device. The maximum value depends on the device. For virtual devices, the
maximum value of the mtu option depends on the underlying device.

interface_name

For the ethernet and infiniband types, the interface_name option restricts the
profile to the given interface by name. This argument is optional and by default the
profile name is used unless a mac address is specified using the mac key. Specifying
an empty string ("") means that the profile is not restricted to a network interface.

Note: With persistent interface naming,
the interface is predictable based on the hardware configuration.
Otherwise, the mac address might be an option.

For virtual interface types such as bridges, the interface_name is the name of the created
interface. In case of a missing interface_name, the name of the profile name is used.

Note: The name (the profile name) and the interface_name (the device name) may be
different or the profile may not be tied to an interface at all.

match

Settings to specify devices or systems matching a profile. Currently, only the path
setting is implemented.

The settings support a list of patterns which support the following modifiers and
wildcards:

Special modifiers for match settings:

Wildcard patterns for match Settings:
In general these work like shell globs.

path

The path setting is a list of patterns to match against the ID_PATH udev property
of devices. The ID_PATH udev property represents the persistent path of a device. It
consists of a subsystem string (pci, usb, platform, etc.) and a subsystem-specific
identifier. The ID_PATH of a device can be obtained with the command
udevadm info /sys/class/net/$dev | grep ID_PATH= or by looking at the path property
exported by NetworkManager (nmcli -f general.path device show $dev). The path
setting is optional and restricts the profile to be activated only on devices with a
matching ID_PATH. The path setting is only supported for ethernet or infiniband
profiles. It supports modifiers and wildcards as described for match settings.

zone

The zone option sets the firewalld zone for the interface.

Ports to the bridge, bond or team devices cannot specify a zone.

ip

The IP configuration supports the following options:

Note: When route_append_only or rule_append_only is not specified, the network
role deletes the current routes or routing rules.

Note: Ports to the bridge, bond or team devices cannot specify ip settings.

ethtool

The ethtool settings allow to enable or disable various features. The names
correspond to the names used by the ethtool utility. Depending on the actual
kernel and device, changing some options might not be supported.

The ethtool configuration supports the following options:

  ethtool:
    features:
      esp_hw_offload: yes|no  # optional
      esp_tx_csum_hw_offload: yes|no  # optional
      fcoe_mtu: yes|no  # optional
      gro: yes|no  # optional
      gso: yes|no  # optional
      highdma: yes|no  # optional
      hw_tc_offload: yes|no  # optional
      l2_fwd_offload: yes|no  # optional
      loopback: yes|no  # optional
      lro: yes|no  # optional
      ntuple: yes|no  # optional
      rx: yes|no  # optional
      rx_all: yes|no  # optional
      rx_fcs: yes|no  # optional
      rx_gro_hw: yes|no  # optional
      rx_udp_tunnel_port_offload: yes|no  # optional
      rx_vlan_filter: yes|no  # optional
      rx_vlan_stag_filter: yes|no  # optional
      rx_vlan_stag_hw_parse: yes|no  # optional
      rxhash: yes|no  # optional
      rxvlan: yes|no  # optional
      sg: yes|no  # optional
      tls_hw_record: yes|no  # optional
      tls_hw_tx_offload: yes|no  # optional
      tso: yes|no  # optional
      tx: yes|no  # optional
      tx_checksum_fcoe_crc: yes|no  # optional
      tx_checksum_ip_generic: yes|no  # optional
      tx_checksum_ipv4: yes|no  # optional
      tx_checksum_ipv6: yes|no  # optional
      tx_checksum_sctp: yes|no  # optional
      tx_esp_segmentation: yes|no  # optional
      tx_fcoe_segmentation: yes|no  # optional
      tx_gre_csum_segmentation: yes|no  # optional
      tx_gre_segmentation: yes|no  # optional
      tx_gso_partial: yes|no  # optional
      tx_gso_robust: yes|no  # optional
      tx_ipxip4_segmentation: yes|no  # optional
      tx_ipxip6_segmentation: yes|no  # optional
      tx_nocache_copy: yes|no  # optional
      tx_scatter_gather: yes|no  # optional
      tx_scatter_gather_fraglist: yes|no  # optional
      tx_sctp_segmentation: yes|no  # optional
      tx_tcp_ecn_segmentation: yes|no  # optional
      tx_tcp_mangleid_segmentation: yes|no  # optional
      tx_tcp_segmentation: yes|no  # optional
      tx_tcp6_segmentation: yes|no  # optional
      tx_udp_segmentation: yes|no  # optional
      tx_udp_tnl_csum_segmentation: yes|no  # optional
      tx_udp_tnl_segmentation: yes|no  # optional
      tx_vlan_stag_hw_insert: yes|no  # optional
      txvlan: yes|no  # optional
    coalesce:
      adaptive_rx: yes|no  # optional
      adaptive_tx: yes|no  # optional
      pkt_rate_high: 0  # optional mininum=0 maximum=0xffffffff
      pkt_rate_low: 0  # optional mininum=0 maximum=0xffffffff
      rx_frames: 0  # optional mininum=0 maximum=0xffffffff
      rx_frames_high: 0  # optional mininum=0 maximum=0xffffffff
      rx_frames_irq: 0  # optional mininum=0 maximum=0xffffffff
      rx_frames_low: 0  # optional mininum=0 maximum=0xffffffff
      rx_usecs: 0  # optional mininum=0 maximum=0xffffffff
      rx_usecs_high: 0  # optional mininum=0 maximum=0xffffffff
      rx_usecs_irq: 0  # optional mininum=0 maximum=0xffffffff
      rx_usecs_low: 0  # optional mininum=0 maximum=0xffffffff
      sample_interval: 0  # optional mininum=0 maximum=0xffffffff
      stats_block_usecs: 0  # optional mininum=0 maximum=0xffffffff
      tx_frames: 0  # optional mininum=0 maximum=0xffffffff
      tx_frames_high: 0  # optional mininum=0 maximum=0xffffffff
      tx_frames_irq: 0  # optional mininum=0 maximum=0xffffffff
      tx_frames_low: 0  # optional mininum=0 maximum=0xffffffff
      tx_usecs: 0  # optional mininum=0 maximum=0xffffffff
      tx_usecs_high: 0  # optional mininum=0 maximum=0xffffffff
      tx_usecs_irq: 0  # optional mininum=0 maximum=0xffffffff
      tx_usecs_low: 0  # optional mininum=0 maximum=0xffffffff
    ring:
      rx: 0  # optional mininum=0 maximum=0xffffffff
      rx_jumbo: 0  # optional mininum=0 maximum=0xffffffff
      rx_mini: 0  # optional mininum=0 maximum=0xffffffff
      tx: 0  # optional mininum=0 maximum=0xffffffff

ieee802_1x

Configures 802.1x authentication for an interface.

Currently, NetworkManager is the only supported provider and EAP-TLS is the only
supported EAP method.

SSL certificates and keys must be deployed on the host prior to running the role.

bond

The bond setting configures the options of bonded interfaces (type bond).
See the kernel documentation for
bonding
or
your distribution nmcli documentation for valid values. It supports the
following options:

Examples of Options

Setting the same connection profile multiple times:

network_connections:
  - name: Wired0
    type: ethernet
    interface_name: eth0
    ip:
      dhcp4: yes

  - name: Wired0
    state: up

Activating a preexisting connection profile:

network_connections:
  - name: eth0
    state: up

Deactivating a preexisting connection profile:

network_connections:
  - name: eth0
    state: down

Creating a persistent connection profile:

network_connections:
  - name: eth0
    #persistent_state: present  # default
    type: ethernet
    autoconnect: yes
    mac: "00:00:5e:00:53:5d"
    ip:
      dhcp4: yes

Specifying a connecting profile for an ethernet device with the ID_PATH:

network_connections:
  - name: eth0
    type: ethernet
    # For PCI devices, the path has the form "pci-$domain:$bus:$device.$function"
    # The profile will only match the interface at the PCI address pci-0000:00:03.0
    match:
      path:
        - pci-0000:00:03.0
    ip:
      address:
        - 192.0.2.3/24
  - name: eth0
    type: ethernet
    # Specifying a connecting profile for an ethernet device only with the PCI address
    # pci-0000:00:01.0 or pci-0000:00:03.0
    match:
      path:
        - pci-0000:00:0[1-3].0
        - &!pci-0000:00:02.0
    ip:
      address:
        - 192.0.2.3/24

Deleting a connection profile named eth0 (if it exists):

network_connections:
  - name: eth0
    persistent_state: absent

Configuring the Ethernet link settings:

network_connections:
  - name: eth0
    type: ethernet

    ethernet:
      autoneg: no
      speed: 1000
      duplex: full

Creating a bridge connection:

network_connections:
  - name: br0
    type: bridge
    #interface_name: br0  # defaults to the connection name

Configuring a bridge connection:

network_connections:
  - name: internal-br0
    interface_name: br0
    type: bridge
    ip:
      dhcp4: no
      auto6: no

Setting controller and port_type:

network_connections:
  - name: br0-bond0
    type: bond
    interface_name: bond0
    controller: internal-br0
    port_type: bridge

  - name: br0-bond0-eth1
    type: ethernet
    interface_name: eth1
    controller: br0-bond0
    port_type: bond

Configuring VLANs:

network_connections:
  - name: eth1-profile
    autoconnet: no
    type: ethernet
    interface_name: eth1
    ip:
      dhcp4: no
      auto6: no

  - name: eth1.6
    autoconnect: no
    type: vlan
    parent: eth1-profile
    vlan:
      id: 6
    ip:
      address:
        - 192.0.2.5/24
      auto6: no

Configuring MACVLAN:

network_connections:
  - name: eth0-profile
    type: ethernet
    interface_name: eth0
    ip:
      address:
        - 192.168.0.1/24

  - name: veth0
    type: macvlan
    parent: eth0-profile
    macvlan:
      mode: bridge
      promiscuous: yes
      tap: no
    ip:
      address:
        - 192.168.1.1/24

Configuring a wireless connection:

network_connections:
  - name: wlan0
    type: wireless
    wireless:
      ssid: "My WPA2-PSK Network"
      key_mgmt: "wpa-psk"
      # recommend vault encrypting the wireless password
      # see https://docs.ansible.com/ansible/latest/user_guide/vault.html
      password: "p@55w0rD"

Setting the IP configuration:

network_connections:
  - name: eth0
    type: ethernet
    ip:
      route_metric4: 100
      dhcp4: no
      #dhcp4_send_hostname: no
      gateway4: 192.0.2.1

      dns:
        - 192.0.2.2
        - 198.51.100.5
      dns_search:
        - example.com
        - subdomain.example.com
      dns_options:
        - rotate
        - timeout:1

      route_metric6: -1
      auto6: no
      gateway6: 2001:db8::1

      address:
        - 192.0.2.3/24
        - 198.51.100.3/26
        - 2001:db8::80/7

      route:
        - network: 198.51.100.128
          prefix: 26
          gateway: 198.51.100.1
          metric: 2
        - network: 198.51.100.64
          prefix: 26
          gateway: 198.51.100.6
          metric: 4
      route_append_only: no
      rule_append_only: yes

Configuring 802.1x:

network_connections:
  - name: eth0
    type: ethernet
    ieee802_1x:
      identity: myhost
      eap: tls
      private_key: /etc/pki/tls/client.key
      # recommend vault encrypting the private key password
      # see https://docs.ansible.com/ansible/latest/user_guide/vault.html
      private_key_password: "p@55w0rD"
      client_cert: /etc/pki/tls/client.pem
      ca_cert: /etc/pki/tls/cacert.pem
      domain_suffix_match: example.com

Configuring Enhanced Open(OWE):

network_connections:
  - name: wlan0
    type: wireless
    wireless:
      ssid: "WIFI_SSID"
      key_mgmt: "owe"

Invalid and Wrong Configuration

The network role rejects invalid configurations. It is recommended to test the role
with --check first. There is no protection against wrong (but valid) configuration.
Double-check your configuration before applying it.

Compatibility

The network role supports the same configuration scheme for both providers (nm
and initscripts). That means, you can use the same playbook with NetworkManager
and initscripts. However, note that not every option is handled exactly the same
by every provider. Do a test run first with --check.

It is not supported to create a configuration for one provider, and expect another
provider to handle them. For example, creating profiles with the initscripts provider,
and later enabling NetworkManager is not guaranteed to work automatically. Possibly,
you have to adjust the configuration so that it can be used by another provider.

For example, configuring a RHEL6 host with initscripts and upgrading to
RHEL7 while continuing to use initscripts in RHEL7 is an acceptable scenario. What
is not guaranteed is to upgrade to RHEL7, disable initscripts and expect NetworkManager
to take over the configuration automatically.

Depending on NetworkManager’s configuration, connections may be stored as ifcfg files
as well, but it is not guaranteed that plain initscripts can handle these ifcfg files
after disabling the NetworkManager service.

Limitations

As Ansible usually works via the network, for example via SSH, there are some
limitations to be considered:

The network role does not support bootstraping networking configuration. One option
may be
ansible-pull.
Another option maybe be to initially auto-configure the host during installation (ISO
based, kickstart, etc.), so that the host is connected to a management LAN or VLAN. It
strongly depends on your environment.

For initscripts provider, deploying a profile merely means to create the ifcfg
files. Nothing happens automatically until the play issues ifup or ifdown
via the up or down states – unless there are other
components that rely on the ifcfg files and react on changes.

The initscripts provider requires the different profiles to be in the right
order when they depend on each other. For example the bonding controller device
needs to be specified before the port devices.

When removing a profile for NetworkManager it also takes the connection
down and possibly removes virtual interfaces. With the initscripts provider
removing a profile does not change its current runtime state (this is a future
feature for NetworkManager as well).

For NetworkManager, modifying a connection with autoconnect enabled may result in the
activation of a new profile on a previously disconnected interface. Also, deleting a
NetworkManager connection that is currently active results in removing the interface.
Therefore, the order of the steps should be followed, and carefully handling of
autoconnect property may be necessary. This should be improved in
NetworkManager RFE rh#1401515.

It seems difficult to change networking of the target host in a way that breaks
the current SSH connection of ansible. If you want to do that, ansible-pull might
be a solution. Alternatively, a combination of async/poll with changing
the ansible_host midway of the play.

TODO The current role does not yet support to easily split the
play in a pre-configure step, and a second step to activate the new configuration.

In general, to successfully run the play, determine which configuration is
active in the first place, and then carefully configure a sequence of steps to change to
the new configuration. The actual solution depends strongly on your environment.

Handling potential problems

When something goes wrong while configuring networking remotely, you might need
to get physical access to the machine to recover.

TODO NetworkManager supports a
checkpoint/rollback
feature. At the beginning of the play we could create a checkpoint and if we lose
connectivity due to an error, NetworkManager would automatically rollback after
timeout. The limitations is that this would only work with NetworkManager, and
it is not clear that rollback will result in a working configuration.

Want to contribute? Take a look at our contributing
guidelines
!