Chapter 9. Networking

9.1. NetworkManager

9.1.1. Legacy network scripts support

Network scripts are deprecated in Red Hat Enterprise Linux 8 and are no longer provided by default. The basic installation provides a new version of the ifup and ifdown scripts which call NetworkManager through the nmcli tool. In Red Hat Enterprise Linux 8, to run the ifup and the ifdown scripts, NetworkManager must be running.

Note

Custom commands in /sbin/ifup-local, ifdown-pre-local and ifdown-local scripts are not executed.

If any of these scripts are required, the installation of the deprecated network scripts in the system is still possible with the following command:

~]# yum install network-scripts

The ifup and the ifdown scripts link to the installed legacy network scripts.

Calling the legacy network scripts shows a warning about their deprecation.

9.1.2. NetworkManager supports SR-IOV virtual functions

In Red Hat Enterprise Linux 8, NetworkManager allows configuring the number of virtual functions (VF) for interfaces that support single-root I/O virtualization (SR-IOV). Additionally, NetworkManager allows configuring some attributes of the VFs, such as the MAC address, VLAN, the spoof checking setting and allowed bitrates. Note that all properties related to SR-IOV are available in the sriov connection setting. For more details, see the nm-settings(5) man page.

9.1.3. NetworkManager supports a wildcard interface name match for connections

Previously, it was possible to restrict a connection to a given interface using only an exact match on the interface name. With this update, connections have a new match.interface-name property which supports wildcards. This update enables users to choose the interface for a connection in a more flexible way using a wildcard pattern.

9.1.4. NetworkManager supports configuring ethtool offload features

With this enhancement, NetworkManager supports configuring ethtool offload features, and users no longer need to use init scripts or a NetworkManager dispatcher script. As a result, users can now configure the offload feature as a part of the connection profile using one of the following methods:

  • By using the nmcli utility
  • By editing key files in the /etc/NetworkManager/system-connections/ directory
  • By editing the /etc/sysconfig/network-scripts/ifcfg-* files

Note that this feature is currently not supported in graphical interfaces and in the nmtui utility.

9.1.5. NetworkManager now uses the internal DHCP plug-in by default

NetworkManager supports the internal and dhclient DHCP plug-ins. By default, NetworkManager in Red Hat Enterprise Linux (RHEL) 7 uses the dhclient and RHEL 8 the internal plug-in. In certain situations, the plug-ins behave differently. For example, dhclient can use additional settings specified in the /etc/dhcp/ directory.

If you upgrade from RHEL 7 to RHEL 8 and NetworkManager behaves differently, add the following setting to the [main] section in the /etc/NetworkManager/NetworkManager.conf file to use the dhclient plug-in:

[main]
dhcp=dhclient

9.1.6. The NetworkManager-config-server package is not installed by default in RHEL 8

The NetworkManager-config-server package is only installed by default if you select either the Server or Server with GUI base environment during the setup. If you selected a different environment, use the yum install NetworkManager-config-server command to install the package.

9.2. Packet filtering

9.2.1. nftables replaces iptables as the default network packet filtering framework

The nftables framework provides packet classification facilities and it is the designated successor to the iptables, ip6tables, arptables, and ebtables tools. It offers numerous improvements in convenience, features, and performance over previous packet-filtering tools, most notably:

  • lookup tables instead of linear processing
  • a single framework for both the IPv4 and IPv6 protocols
  • rules all applied atomically instead of fetching, updating, and storing a complete rule set
  • support for debugging and tracing in the rule set (nftrace) and monitoring trace events (in the nft tool)
  • more consistent and compact syntax, no protocol-specific extensions
  • a Netlink API for third-party applications

Similarly to iptables, nftables use tables for storing chains. The chains contain individual rules for performing actions. The nft tool replaces all tools from the previous packet-filtering frameworks. The libnftables library can be used for low-level interaction with nftables Netlink API over the libmnl library.

The iptables, ip6tables, ebtables and arptables tools are replaced by nftables-based drop-in replacements with the same name. While external behavior is identical to their legacy counterparts, internally they use nftables with legacy netfilter kernel modules through a compatibility interface where required.

Effect of the modules on the nftables rule set can be observed using the nft list ruleset command. Since these tools add tables, chains, and rules to the nftables rule set, be aware that nftables rule-set operations, such as the nft flush ruleset command, might affect rule sets installed using the formerly separate legacy commands.

To quickly identify which variant of the tool is present, version information has been updated to include the back-end name. In RHEL 8, the nftables-based iptables tool prints the following version string:

$ iptables --version
iptables v1.8.0 (nf_tables)

For comparison, the following version information is printed if legacy iptables tool is present:

$ iptables --version
iptables v1.8.0 (legacy)

9.2.2. Arptables FORWARD is removed from filter tables in RHEL 8

The arptables FORWARD chain functionality has been removed in Red Hat Enterprise Linux (RHEL) 8. You can now use the FORWARD chain of the ebtables tool adding the rules into it.

9.2.3. Output of iptables-ebtables is not 100% compatible with ebtables

In RHEL 8, the ebtables command is provided by the iptables-ebtables package, which contains an nftables-based reimplementation of the tool. This tool has a different code base, and its output deviates in aspects, which are either negligible or deliberate design choices.

Consequently, when migrating your scripts parsing some ebtables output, adjust the scripts to reflect the following:

  • MAC address formatting has been changed to be fixed in length. Where necessary, individual byte values contain a leading zero to maintain the format of two characters per octet.
  • Formatting of IPv6 prefixes has been changed to conform with RFC 4291. The trailing part after the slash character no longer contains a netmask in the IPv6 address format but a prefix length. This change applies to valid (left-contiguous) masks only, while others are still printed in the old formatting.

9.2.4. New tools to convert iptables to nftables

This update adds the iptables-translate and ip6tables-translate tools to convert the existing iptables or ip6tables rules into the equivalent ones for nftables. Note that some extensions lack translation support. If such an extension exists, the tool prints the untranslated rule prefixed with the # sign. For example:

| % iptables-translate -A INPUT -j CHECKSUM --checksum-fill
| nft # -A INPUT -j CHECKSUM --checksum-fill

Additionally, users can use the iptables-restore-translate and ip6tables-restore-translate tools to translate a dump of rules. Note that before that, users can use the iptables-save or ip6tables-save commands to print a dump of current rules. For example:

| % sudo iptables-save >/tmp/iptables.dump
| % iptables-restore-translate -f /tmp/iptables.dump
| # Translated by iptables-restore-translate v1.8.0 on Wed Oct 17 17:00:13 2018
| add table ip nat
| ...

9.3. Changes in wpa_supplicant

9.3.1. journalctl can now read the wpa_supplicant log

In Red Hat Enterprise Linux (RHEL) 8, the wpa_supplicant package is built with CONFIG_DEBUG_SYSLOG enabled. This allows reading the wpa_supplicant log using the journalctl utility instead of checking the contents of the /var/log/wpa_supplicant.log file.

9.3.2. The compile-time support for wireless extensions in wpa_supplicant is disabled

The wpa_supplicant package does not support wireless extensions. When a user is trying to use wext as a command-line argument, or trying to use it on old adapters which only support wireless extensions, will not be able to run the wpa_supplicant daemon.

9.4. A new data chunk type, I-DATA, added to SCTP

This update adds a new data chunk type, I-DATA, and stream schedulers to the Stream Control Transmission Protocol (SCTP). Previously, SCTP sent user messages in the same order as they were sent by a user. Consequently, a large SCTP user message blocked all other messages in any stream until completely sent. When using I-DATA chunks, the Transmission Sequence Number (TSN) field is not overloaded. As a result, SCTP now can schedule the streams in different ways, and I-DATA allows user messages interleaving (RFC 8260). Note that both peers must support the I-DATA chunk type.

9.5. Notable TCP features in RHEL 8

Red Hat Enterprise Linux 8 is distributed with TCP networking stack version 4.18, which provides higher performances, better scalability, and more stability. Performances are boosted especially for busy TCP server with a high ingress connection rate.

Additionally, two new TCP congestion algorithms, BBR and NV, are available, offering lower latency, and better throughput than cubic in most scenarios.

9.5.1. TCP BBR support in RHEL 8

A new TCP congestion control algorithm, Bottleneck Bandwidth and Round-trip time (BBR) is now supported in Red Hat Enterprise Linux (RHEL) 8. BBR attempts to determine the bandwidth of the bottleneck link and the Round-trip time (RTT). Most congestion algorithms are based on packet loss (including CUBIC, the default Linux TCP congestion control algorithm), which have problems on high-throughput links. BBR does not react to loss events directly, it adjusts the TCP pacing rate to match it with the available bandwidth. Users of TCP BBR should switch to the fq queueing setting on all the involved interfaces.

Note that users should explicitly use fq and not fq_codel.

For more details, see the tc-fq man page.

9.7. Network interface name changes

In Red Hat Enterprise Linux 8, the same consistent network device naming scheme is used by default as in RHEL 7. However, certain kernel drivers, such as e1000e, nfp, qede, sfc, tg3 and bnxt_en changed their consistent name on a fresh installation of RHEL 8. However, the names are preserved on upgrade from RHEL 7.

9.8. The -ok option of the tc command removed

The -ok option of the tc command has been removed in Red Hat Enterprise Linux 8. As a workaround, users can implement code to communicate directly via netlink with the kernel. Response messages received, indicate completion and status of sent requests. An alternative way for less time-critical applications is to call tc for each command separately. This may happen with a custom script which simulates the tc -batch behavior by printing OK for each successful tc invocation.