Valid HTML 4.01 Transitional

Network Interface Names

James F. Carter <jimc@jfcarter.net>, 2019-05-18

In the last weekly update, I went from kernel 5.0.11 to 5.0.13. Networking became hosed, fortunately only on Jacinth, the main router. Its eth1 connects to the ISP (Frontier FIOS, formerly Verizon, IPv4 only), eth0 connects to the local LAN, wlan1 is controlled by hostapd for Wi-Fi service (902.11n), vnet0 connects to Jacinth's virtual machine Claude, and several tunnels are used by OpenVPN instances with various jobs. All but eth1 and the tunnels are in a bridge, which has Jacinth's own local IP addresses (IPv4 and IPv6).

The symptom was, Jacinth sent DHCP4 and ICMP6 solicitations, ARP, etc. on eth1, which were never answered, as seen by tcpdump. (The ICMP6 router solicitations have not been answered since 2006, but Jacinth sends them anyway.) ICMP4+6 pings going out on eth0 were also not answered. Other hosts on the LAN could ping each other but got no answers from Jacinth. It is likely, but not assured, that Jacinth never received any unicast packets on eth0. Jacinth could ping hosts on vnet0 and wlan1.

The kernel command line includes net.ifnames=0, turning off predictable device names and using whatever the kernel picks. There are udev rules cueing on the MAC address that rename eth-type NICs to the appropriate eth0 and eth1. With kernel 5.0.11 the NICs were reliably renamed (or by luck consistently get the right names). With kernel 5.0.13 there was an error message in syslog saying: eth1: Failed to rename network interface 3 from 'eth1' to 'eth0': File exists and similar for eth0 to eth1. The rule for eth0 says: (eth1 is similar) (wrapping is not in the original)

SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="f4:4d:30:69:e2:1c", \
KERNEL=="eth*", NAME="eth0"

What would be the consequence of failing to swap eth0 with eth1? Jacinth's wickedd-dhcp4 and 6 would send their DHCP solicitations to the local LAN on eth1 (should be eth0), where the ISP's DHCP server isn't. Local LAN hosts trying to connect to Jacinth could not do so because Jacinth eth1 has no IP address. Jacinth would send ARP and ICMP6 neighbor discovery on the wild side eth0 (should be eth1), where the local LAN hosts aren't. Nothing would be answered, as actually seen.

Fixup Strategies

So what can I do about this?

In the transition to kernel 5.0.13 there were several seemingly irrelevant changes to IPv4 and IPv6 networking. But I definitely don't want to get tangled up fixing a difficult issue which the developers of the kernel, systemd and udev have already declared to be deprecated. Here's the official explanation of the device name issue.

Here's a brief summary of the issue.

What NICs are on each host? Hardware devices only, excluding lo, bridges, VM host interfaces, and tunnels.

To summarize, every host has eth0 (to local LAN), some have wlan0 (wireless), and only Jacinth has more than this.

Action Plan

So what action should I take?

Specific Steps in Setup