[arch-general] A question about handling a system with two wired network interfaces?

[Tom Gundersen]

Hi Mike,

On Tue, Feb 19, 2013 at 3:32 PM, Mike Cloaked <mike.cloaked at gmail.com> wrote:
> I have a system with two ethernet sockets on the motherboard, and I have
> until very recently been finding that my network at random failed to come
> up during the boot process.

Just to be clear: the problem is still occurring (I am confused by
"until recently")? Was it brought on by the recent udev naming change,
or is it a long-standing problem?

> I have the ethernet cable plugged into only one of the two sockets, and
> assign the names to the interfaces as eno1 and eno2 - because left to its
> own it assigned one of them as name "eno1" and the other to "eth0" or
> "eth1" at random between boots! I was surprised that it chose ethX at all
> for the second name, given this is running with the new naming scheme!

What you are seeing is that udev is able to reliably name one of your
devices (eno1), which (unless you add any custom rules) will always
refer to the same network port between reboots (in particular, it
refers to the first on-board network device). However, the other
device udev is not able to reliably name, so it leaves it alone. This
explains why it still has a name in the kernel namespace (ethX), and
why it alternates between eth0 and eth1.

> However following the hints at:
>
> https://wiki.archlinux.org/index.php/Udev#Network_device
>
> I specify that udev fix the two interface names as eno1 and eno2

It is probably better to use different names than the enoX ones
(though not strictly speaking necessary) if you specify them using
your custom scheme (as outlined in the wiki article you link to). The
reason is that the enoX names have a specific meaning (they are the
on-board devices in the order given by the hardware).

Currently, udev will not give out stable interface names based on mac
addresses even though it can. To overcome this, you could put this
into /etc/udev/rules/80-net-name-slot.rules:

  ACTION=="remove", GOTO="net_name_slot_end"
  SUBSYSTEM!="net", GOTO="net_name_slot_end"
  NAME!="", GOTO="net_name_slot_end"

  NAME=="", ENV{ID_NET_NAME_ONBOARD}!="", NAME="$env{ID_NET_NAME_ONBOARD}"
  NAME=="", ENV{ID_NET_NAME_SLOT}!="", NAME="$env{ID_NET_NAME_SLOT}"
  NAME=="", ENV{ID_NET_NAME_PATH}!="", NAME="$env{ID_NET_NAME_PATH}"
  NAME=="", ENV{ID_NET_NAME_MAC}!="", NAME="$env{ID_NET_NAME_MAC}"

  LABEL="net_name_slot_end"


That should, if the MAC address is reliable, name your ethX device as
something like "enx98fe023fa538". Note, however, that udev will try to
first ascertain if the MAC address can be trusted (for instance, some
machines will randomly assign the MAC at every boot), so if this does
not work for you it (probably) means that udev decided not to trust
the MAC address so did not export the name.


> What I then presumed was that although the same two names are always
> assigned, the hardware mac address to which of the two physical network
> ports was being assigned was being assigned differently to the two names -
> i.e. sometimes being en01 and sometimes being eno2.  Why this matters is
> that I assign a static ip address to eno1 only and don't use eno2. This
> would only be an issue if there was more than one NIC in the system.
>
> The system boots really fast as it has SSD drives, which possibly was not
> allowing enough time for the name assignment, so I then found the advice at:
>
> https://wiki.archlinux.org/index.php/Rename_network_interfaces
>
> where it suggests editing the systemd unit file for in my case
> NetworkManager service - which I then did and this finally seems to have
> fixed the problem though I will still need to boot over a period of days to
> check if the network comes up "every" time now. The wiki page refers to the
> network service file, but I applied this to the NetworkManager service file.
>
> So the question that I hope someone can answer is whether in the case of
> multiple NICs in a system the new network names, although the same "set" of
> names is used for all the cards in the system, will still need this systemd
> unit file amendment - i.e. adding the two lines:
>
> Requires=systemd-udev-settle.service
>  After=systemd-udev-settle.service
>
> to the [unit] section in order to get the correct name associated with the
> same hardware mac address every boot?
>
> If someone who understands these things in detail could confirm if my
> understanding is correct I would appreciate it?

There has been some bugs where network software grab the device before
udev can rename it, which could be solved with the workaround you
reference above. However, I doubt this to be the case with
NetworkManager, as far as I know it is only a problem with
dhcpcd.service (but dhcpcd@<your network device>.service works
correctly).

HTH,

Tom