toallab-automation/roles/linux-system-roles.network

linux-system-roles/network

Overview

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

• Ethernet interfaces
• Bridge interfaces
• Bonded interfaces
• VLAN interfaces
• MacVLAN interfaces
• Infiniband interfaces
• IP configuration

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.

• For initscripts, profiles correspond to ifcfg files in the /etc/sysconfig/network-scripts/ifcfg-* directory.

• For NetworkManager, profiles correspond to connection profiles as handled by NetworkManager. Fedora and RHEL use the ifcfg-rh-plugin for NetworkManager, which also writes or reads configuration files to /etc/sysconfig/network-scripts/ifcfg-* for compatibility.

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:

• network_provider - The network_provider variable allows to set a specific provider (nm or initscripts) . Setting it to {{ network_provider_os_default }}, the provider is set depending on the operating system. This is usually nm except for RHEL 6 or CentOS 6 systems.

• network_connections - The connection profiles are configured as network_connections, which is a list of dictionaries that include specific options.

Examples of Variables

Setting the variables

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

Options

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

name (required)

The name option identifies the connection profile. 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.

• For NetworkManager, the name option corresponds to the connection.id property option. Although NetworkManager supports multiple connections with the same connection.id, the network role cannot handle a duplicate name. Specifying a name multiple times refers to the same connection profile.

• For initscripts, the name option determines the ifcfg file name /etc/sysconfig/network-scripts/ifcfg-$NAME. Note that the name does not specify the DEVICE but a filename. As a consequence, '/' is not a valid character for the name.

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

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:

• up - the connection profile is activated
• down - the connection profile is deactivated

state: up

• For NetworkManager, this corresponds to nmcli connection id {{name}} up.

• For initscripts, this corresponds to ifup {{name}}.

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

• wait: 0 - initiates only the activation, but does not wait until the device is fully connected. The connection will be completed in the background, for example after a DHCP lease was received.
• wait: <seconds> is a timeout that enables you to decide how long you give the device to activate. The default is using a suitable timeout. Note that the wait option is only supported by NetworkManager.

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

• For NetworkManager, it corresponds to nmcli connection id {{name}} down.

• For initscripts, it corresponds to call ifdown {{name}}.

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:

• NetworkManager deletes all connection profiles with the corresponding connection.id. Deleting a profile usually does not change the current networking configuration, unless the profile was currently activated on a device. Deleting the currently active connection profile disconnects the device. That makes the device eligible to autoconnect another connection (for more details, see rh#1401515).

• initscripts deletes the ifcfg file in most cases with no impact on the runtime state of the system unless some component is watching the sysconfig directory.

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:

• ethernet
• bridge
• bond
• team
• vlan
• macvlan
• infiniband

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.

• autoneg: yes (default) or no [if auto-negotiation is enabled or disabled]
• speed: speed in Mbit/s
• duplex: half or full

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.

For slaves, the slave_type and master properties must be set. Note that slaves should not have ip settings.

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

• For NetworkManager, master will be converted to the connection.uuid of the corresponding profile.

• For initscripts, the master is looked up as the DEVICE from the corresponding ifcfg file.

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

type: vlan

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

type: macvlan

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

autoconnect

By default, profiles are created with autoconnect enabled.

• For NetworkManager, this corresponds to the connection.autoconnect property.

• For initscripts, this corresponds to the ONBOOT property.

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.

• For NetworkManager, mac is the permanent MAC address, ethernet.mac-address.

• For initscripts, mac is the currently configured MAC address of the device (HWADDR).

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.

zone

The zone option sets the firewalld zone for the interface.

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

ip

The IP configuration supports the following options:

• address

  Manual addressing can be specified via a list of addresses under the address option.

• dhcp4 and auto6

  Also, manual addressing can be specified by setting either dhcp4 or auto6. The dhcp4 key is for DHCPv4 and auto6 for StateLess Address Auto Configuration (SLAAC). Note that the dhcp4 and auto6 keys can be omitted and the default key depends on the presence of manual addresses.

• dhcp4_send_hostname

  If dhcp4 is enabled, it can be configured whether the DHCPv4 request includes the hostname via the dhcp4_send_hostname option. Note that dhcp4_send_hostname is only supported by the nm provider and corresponds to ipv4.dhcp-send-hostname property.

• dns and dns_search

  Manual DNS configuration can be specified via a list of addresses given in the dns option and a list of domains to search given in the dns_search option.

• route_metric4 and route_metric6

  • For NetworkManager, route_metric4 and route_metric6 corresponds to the ipv4.route-metric and ipv6.route-metric properties, respectively. If specified, it determines the route metric for DHCP assigned routes and the default route, and thus the priority for multiple interfaces.

• route

  Static route configuration can be specified via a list of routes given in the route option. The default value is an empty list. Each route is a dictionary with the following entries: network, prefix, gateway and metric. network and prefix specify the destination network. Note that Classless inter-domain routing (CIDR) notation or network mask notation are not supported yet.

• route_append_only

  The route_append_only option allows only to add new routes to the existing routes on the system.

  If the route_append_only boolean option is set to yes, the specified routes are appended to the existing routes. If route_append_only is set to no (default), the current routes are replaced. Note that setting route_append_only to yes without setting route has the effect of preserving the current static routes.

• rule_append_only

  The rule_append_only boolean option allows to preserve the current routing rules. Note that specifying routing rules is not supported yet.

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

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

ethtool

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

  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

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

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 master and slave_type:

network_connections:
  - name: br0-bond0
    type: bond
    interface_name: bond0
    master: internal-br0
    slave_type: bridge

  - name: br0-bond0-eth1
    type: ethernet
    interface_name: eth1
    master: br0-bond0
    slave_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

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

      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

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 master device needs to be specified before the slave 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.