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: 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 on your system. 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 keyfiles 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. For further details, see Configuring an ethtool offload feature by using nmcli . 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: 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 , ebtables , and ipset tools. It offers numerous improvements in convenience, features, and performance over 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 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: For comparison, the following version information is printed if legacy iptables tool is present: 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: 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: 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. For more information about this, see the Red Hat Knowledgebase solution How to configure TCP BBR congestion control algorithm . 9.6. VLAN-related changes 9.6.1. IPVLAN virtual network drivers are now supported In Red Hat Enterprise Linux 8.0, the kernel includes support for IPVLAN virtual network drivers. With this update, IPVLAN virtual Network Interface Cards (NICs) enable the network connectivity for multiple containers exposing a single MAC address to the local network. This allows a single host to have a lot of containers overcoming the possible limitation on the number of MAC addresses supported by the peer networking equipment. 9.6.2. Certain network adapters require a firmware update to fully support 802.1ad The firmware of certain network adapters does not fully support the 802.1ad standard, which is also called Q-in-Q or stacked virtual local area networks (VLANs). Contact your hardware vendor on details how to verify that your network adapter uses a firmware that supports the 802.1ad standard and how to update the firmware. As a result, with the correct firmware, configuring stacked VLANs on RHEL 8.0 work as expected. 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 ipv6 , netmask , gateway , and hostname kernel parameters have been removed The ipv6 , netmask , gateway , and hostname kernel parameters to configure the network in the kernel command line are no longer available since RHEL 8.3. Instead, use the consolidated ip parameter that accepts different formats, such as the following: For further details about the individual fields and other formats this parameter accepts, see the description of the ip parameter in the dracut.cmdline(7) man page on your system. 9.9. 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. 9.10. The PTP capabilities output format of the ethtool utility has changed Starting with RHEL 8.4, the ethtool utility uses the netlink interface instead of the ioctl() system call to communicate with the kernel. Consequently, when you use the ethtool -T <network_controller> command, the format of Precision Time Protocol (PTP) values changes. Previously, with the ioctl() interface, ethtool translated the capability bit names by using an ethtool -internal string table and, the ethtool -T <network_controller> command displayed, for example: With the netlink interface, ethtool receives the strings from the kernel. These strings do not include the internal SOF_TIMESTAMPING_* names. Therefore, ethtool -T <network_controller> now displays, for example: If you use the PTP capabilities output of ethtool in scripts or applications, update them accordingly.

Commands:
# yum install network-scripts
[main] dhcp=dhclient
iptables --version iptables v1.8.0 (nf_tables)
iptables --version iptables v1.8.0 (legacy)
| % iptables-translate -A INPUT -j CHECKSUM --checksum-fill | nft # -A INPUT -j CHECKSUM --checksum-fill
| % 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 |
ip= IP_address : peer : gateway_IP_address : net_mask : host_name : interface_name : configuration_method
Time stamping parameters for <network_controller> : Capabilities: hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE) software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
Time stamping parameters for <network_controller> : Capabilities: hardware-transmit software-transmit