Chapter 9. Networking
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
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.
Custom commands in
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
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
By editing key files in the
By editing the
Note that this feature is currently not supported in graphical interfaces and in the
9.1.5. NetworkManager now uses the internal DHCP plug-in by default
NetworkManager supports the
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
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
9.1.6. The NetworkManager-config-server package is not installed by default in RHEL 8
NetworkManager-config-server package is only installed by default if you select either the
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
iptables as the default network packet filtering framework
nftables framework provides packet classification facilities and it is the designated successor to the
ipset 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
- 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
- more consistent and compact syntax, no protocol-specific extensions
- a Netlink API for third-party applications
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
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)
Arptables FORWARD is removed from filter tables in RHEL 8
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
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
This update adds the
ip6tables-translate tools to convert the existing
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
ip6tables-restore-translate tools to translate a dump of rules. Note that before that, users can use the
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
journalctl can now read the
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
9.3.2. The compile-time support for wireless extensions in
wpa_supplicant is disabled
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
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,
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 How to configure TCP BBR congestion control algorithm article.
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
bnxt_en changed their consistent name on a fresh installation of RHEL 8. However, the names are preserved on upgrade from RHEL 7.
hostname kernel parameters have been removed
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.
-ok option of the
tc command removed
-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