Bookmark this page

Resolving Connectivity Issues

Objectives

  • Identify and repair network connectivity issues.

Network Interface Device Naming

In Red Hat Enterprise Linux 8, the udev device manager provides consistent and predictable device naming for network interfaces. By default, udev assigns names based on firmware, topology, and location information. This naming scheme ensures that device names remain consistent, even when hardware is added or removed. The udev device manager determines interface names based on the following scheme hierarchy.

SchemeDescriptionExample
1Device names incorporate firmware or BIOS-provided index numbers for onboard devices. If this information is not available or applicable, then udev uses scheme 2. eno1
2Device names incorporate firmware or BIOS-provided PCI Express (PCIe) hot plug slot index numbers. If this information is not available or applicable, then udev uses scheme 3. ens1
3Device names incorporate the physical location of the connector of the hardware. If this information is not available or applicable, then udev uses scheme 5. enp2s0
4Device names incorporate MAC addresses. Red Hat Enterprise Linux 8 does not use this scheme by default; however, administrators can optionally enable it. enx52540…
5The traditional unpredictable kernel naming scheme. If udev cannot apply any other scheme, then it uses this one. eth0

The first two characters of a device name represent the type of detected interface.

  • en for Ethernet

  • wl for wireless LAN (WLAN)

  • ww for wireless WAN (WWAN)

The subsequent characters in a device name are based on the schema that the udev device manager selected.

  • o for onboard devices. Example: eno1

  • s for PCIe devices. Example: ens1

  • p and s for the bus and slot location. Example: enp2s0

  • x for MAC address-based names. Example: enx525400d5e0fb

The NamePolicy setting in the /usr/lib/systemd/network/99-default.link file controls the naming hierarchy in the previous table.

[root@host ~]# cat /usr/lib/systemd/network/99-default.link | grep NamePolicy
NamePolicy=kernel database onboard slot path

The kernel and database entries indicate that the kernel and udev database are checked for existing device names before new ones are generated. If a persistent name does not already exist, then the system defaults to the onboard, slot, and path schemes. Alternatively, setting the NamePolicy value to mac incorporates MAC addresses in device names.

Custom interface prefixes are defined during the installation process by adding net.ifnames.prefix=<prefix> to the Install Red Hat Enterprise Linux 8 boot entry kernel options. Custom prefixes take precedence over other naming schemes and must not conflict with existing prefixes, including eno and ens.

Note

The biosdevname package provides an alternative device naming scheme (for example, p1p1 for PCIe slot 1 port 1) if none of the preceding options are suitable. In Red Hat Enterprise Linux 8, the biosdevname package is not installed or enabled by default, including on Dell systems.

The /var/log/messages file indicates which devices were detected at boot and which names they were assigned.

[root@host ~]# grep -n eth1 /var/log/messages
758:Jun 14 03:37:56 host NetworkManager[850]: <info>  [1623656276.6346] manager: (eth1): new Ethernet device (/org/freedesktop/NetworkManager/Devices/3)
...output omitted...
761:Jun 14 03:37:56 host NetworkManager[850]: <info>  [1623656276.6410] device (eth1): carrier: link connected
...output omitted...
789:Jun 14 03:37:56 host NetworkManager[850]: <info>  [1623656276.6717] device (eth1): Activation: successful, device activated.

Manually Configuring Network Device Names

Network interface device names are manually set if a device is directly associated with a MAC address. The ethernet.mac-address and ifname parameters associate a MAC address and name the device.

The following example demonstrates manually renaming a network interface to net1.

[root@host ~]# nmcli con mod wired1 ethernet.mac-address 52:54:00:00:fa:0a ifname net1
[root@host ~]# reboot
...output omitted...
[root@host ~]# ip addr
...output omitted...
2: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
   link/ether 52:54:00:00:fa:0a brd ff:ff:ff:ff:ff:ff

Note

You must reboot a system to apply manually configured network interface names.

Resolving Network Interface Configuration Issues

Red Hat Enterprise Linux 8 provides commands to collect high-level networking information. The ip addr show command provides an overview of network interfaces on a system. This command determines whether interfaces are down or configured with the wrong IP addresses.

[root@host ~]# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:00:fa:0a brd ff:ff:ff:ff:ff:ff
    inet 172.25.250.10/24 brd 172.25.250.255 scope global noprefixroute eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::c248:6dfe:ce2c:d5e5/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

The ip route command displays the current routing table. Add the -6 option to show the IPv6 routing table. Validate the default route to ensure that it is directing traffic to the correct gateway address.

[root@host ~]# ip route
default via 172.25.250.254 dev eth0 proto static metric 100
172.25.250.0/24 dev eth0 proto kernel scope link src 172.25.250.10 metric 100

Modifying NetworkManager Connections

Depending on the configuration issue, it might be necessary to modify or create a connection profile. The nmcli con mod command modifies an existing connection.

[root@host ~]# nmcli con mod con0 ipv4.addresses 172.25.250.13/24

Restart a connection to apply any changes.

[root@host ~]# nmcli con down con0
Connection 'con0' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/4)
[root@host ~]# nmcli con up con0
Connection 'con0' successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/6)

Modifying a connection's ifcfg-* file and reloading the connection with nmcli con load also modifies a connection. The nmcli con reload command reloads all connections.

[root@host ~]# nmcli con load /etc/sysconfig/network-scripts/ifcfg-con0

Note

The nmcli command generates an ifcfg-* file when a connection is manually created. Newly attached interfaces have a default connection profile that is associated with them, but do not have an ifcfg-* file until their configurations are modified beyond the default settings.

Alternatively, create a new connection to replace an old one. Turn off the old connection before turning on the new connection. An interface can have only one active connection.

The following example assumes that the con0 connection is initially paired with the eth0 device.

[root@host ~]# nmcli con add con-name con2 type Ethernet ifname eth0
Connection 'con2' (cfd946d5-f3a5-436e-9eea-cc833d807be9) successfully added.
[root@host ~]# nmcli con down con0
Connection 'con0' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/6)
[root@host ~]# nmcli con up con2
Connection 'con2' successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/7)

Resolving DNS Issues

Network connectivity issues are notoriously caused by DNS. The /etc/resolv.conf configuration file contains a system's primary DNS configuration. By default, the NetworkManager service dynamically updates the /etc/resolv.conf file with the DNS settings from active connections.

[root@host ~]# cat /etc/resolv.conf
# Generated by NetworkManager
search lab.example.com example.com
nameserver 172.25.250.254

The output of the host command confirms that DNS servers are reachable and correctly resolving domain names.

[user@host ~]# host redhat.com 172.25.250.254
Using domain server:
Name: 172.25.250.254
Address: 172.25.250.254#53
...output omitted...
redhat.com has address 209.132.183.105
...output omitted...

Note

The host and nslookup commands ignore replies from name servers where the "Recursion Available" (ra) flag is not enabled, unless it is the last available server.

Alternatively, the dig or mdig commands generate a more detailed output than the host command. The mdig command sends multiple queries at once, rather than the single iterative queries from dig.

[root@host ~]# dig redhat.com
; <<>> DiG 9.11.26-RedHat-9.11.26-3.el8 <<>> redhat.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18096
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;redhat.com.			IN	A

;; ANSWER SECTION:
redhat.com.		499	IN	A	209.132.183.105

;; Query time: 1 msec
;; SERVER: 172.25.250.254#53(172.25.250.254)
;; WHEN: Thu Oct 21 15:40:28 EDT 2021
;; MSG SIZE  rcvd: 55

The status: NOERROR value in the HEADER field confirms a successful domain resolution. A failed dig query likely includes the NXDOMAIN value, which indicates that the DNS server cannot resolve the provided domain name.

The dig command provides dozens of optional parameters to customize queries. The +trace option is particularly useful, because it displays which DNS servers were queried to resolve a domain, starting from the root name servers to every subsequent referenced server.

[root@host ~]# dig redhat.com +trace
...output omitted...
.			499674	IN	NS	b.root-servers.net.
...output omitted...
com.			172800	IN	NS	l.gtld-servers.net.
...output omitted...
redhat.com.		172800	IN	NS	a13-66.akam.net.
...output omitted...
redhat.com.		3600	IN	A	209.132.183.105

While the host and dig commands are useful to diagnose DNS servers, they might not accurately reflect how a system resolves a particular domain name. A system might resolve a domain name with sources other than DNS, such as the /etc/hosts file. To mitigate this behavior, the getent host command resolves a domain name exactly how a system would, and does not exclusively check DNS servers.

[root@host ~]# cat /etc/hosts | grep redhat.com
127.0.0.1	redhat.com
[root@host ~]# getent hosts redhat.com
127.0.0.1       redhat.com
[root@host ~]# sed -i '/redhat.com/d' /etc/hosts
[root@host ~]# getent hosts redhat.com
209.132.183.105 redhat.com

In the preceding example, the getent hosts command resolves redhat.com to 127.0.0.1 until the sed command removes the entry from the /etc/hosts file.

Using NetworkManager for Manage DNS Configurations

If a connection is having DNS issues, then run the nmcli con show command to view its DNS configuration.

[root@host ~]# nmcli con show con0 | grep ipv4.dns
ipv4.dns:                               172.25.250.254
ipv4.dns-search:                        --
ipv4.dns-options:                       --
ipv4.dns-priority:                      0

If a fix is required, then the nmcli con mod command modifies a connection's DNS configuration. The changes appear in the /etc/resolv.conf file after the connection is restarted.

[root@host ~]# cat /etc/resolv.conf | grep nameserver
nameserver 172.25.250.254
[root@host ~]# nmcli con mod con0 ipv4.dns 192.168.0.254
[root@host ~]# nmcli con down con0
Connection 'con0' successfully deactivated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/6)
[root@host ~]# nmcli con up con0
Connection 'con0' successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/7)
[root@host ~]# cat /etc/resolv.conf | grep nameserver
nameserver 192.168.0.254

If DHCP is providing an incorrect or malfunctioning DNS server, then set a connection's ignore-auto-dns parameter equal to yes to ignore DNS servers from DHCP.

[root@host ~]# nmcli con mod con0 ipv4.ignore-auto-dns yes

Resolving Firewall Issues

The firewalld daemon might cause network issues by restricting access to network ports. The firewall-cmd command displays and adjusts current firewall settings. Invoking the command with the --list-all-zones option provides a complete overview of the firewalld configuration.

[root@host ~]# firewall-cmd --list-all-zones
...output omitted...
internal
  target: default
  icmp-block-inversion: no
  interfaces:
  sources:
  services: cockpit dhcpv6-client mdns samba-client ssh
  ports:
  protocols:
...output omitted...
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: cockpit dhcpv6-client http https ssh
  ports:
  protocols:
...output omitted...

Adding the --permanent option displays the persistent settings for firewalld. Comparing active firewalld settings with persistent settings can sometimes identify potential problems. The preceding output shows that the ports for the http and https services are not blocked. The following output shows that the port configuration is not persistent.

[root@host ~]# firewall-cmd --list-all-zones --permanent
...output omitted...
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: cockpit dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
...output omitted...

The firewall-cmd --runtime-to-permanent command converts runtime rules into permanent rules.

[root@host ~]# firewall-cmd --runtime-to-permanent
success

The firewalld daemon is built on top of the nftables framework. The nft command interacts with nftables and can access highly detailed firewall information that is unavailable with the firewall-cmd command.

For example, the nft list ruleset prints all of the active underlying firewall rules on a system.

[root@host ~]# nft list ruleset
...output omitted...
chain filter_IN_public_deny {
}

chain filter_IN_public_allow {
        tcp dport 22 ct state { new, untracked } accept
        ip6 daddr fe80::/64 udp dport 546 ct state { new, untracked } accept
        tcp dport 9090 ct state { new, untracked } accept
        tcp dport 443 ct state { new, untracked } accept
}
...output omitted...

The preceding output shows the nftables perspective of which ports are allowed in the "public" interface zone.

References

Consistent Network Interface Device Naming firewall-cmd(1), nft(8), nmcli(1), and resolv.conf(5) man pages

Revision: rh342-8.4-6dd89bd