3

I have an ubuntu server 14.04 virtual machine with 2 network interfaces

  • eth0 - for web management, SSH
  • eth1 - for incoming span network analysis

I've configured the machine with udev rules (to ensure consistency and proper binding of mac-addresses to logical network interfaces names.

  • I'm doing it only once when installing the server
  • writing these rules in /etc/udev/rules.d/70-persistent-net.rules

    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:f5:aa:02", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="eth1"
    SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:f5:aa:f8", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="eth0"
    

enter image description here


This setup works as expected until new network interfaces are added to the machine. It's important to remind that the new interfaces are not added to the udev rules. (because I'm only doing it's once in the setup process)

I'm expecting the new network interfaces names to be any generic name (such as eth3/p2p1/em1/...) as long as the name is not occupied by a udev rule.

This is what I experience after adding the interfaces and booting up the machine:

enter image description here

  1. my udev rule was ignored/conflicted and named rename3
  2. eth0 got hijacked. one of the new interfaces is now eth0. this is super-problematic security-wise (can lead to data-leakage)

This is the related flow I've found in /var/log/messages

systemd-udevd[126]: starting version 204

...

vmxnet3 0000:04:00.0 eth0: NIC Link is Up 10000 Mbps
vmxnet3 0000:0b:00.0 eth1: NIC Link is Up 10000 Mbps
vmxnet3 0000:13:00.0 eth2: NIC Link is Up 10000 Mbps
vmxnet3 0000:1b:00.0 eth3: NIC Link is Up 10000 Mbps

...

vmxnet3 0000:0b:00.0 rename3: renamed from eth1
vmxnet3 0000:13:00.0 eth1: renamed from eth2
systemd-udevd[396]: renamed network interface eth1 to rename3
systemd-udevd[405]: renamed network interface eth2 to eth1
  • IMO It's a race-condition. The driver/kernel occupy the names. later when my udev rules execute, the occupied names fallback to rename*

Question,

Is there a way to change the order and prioritize udev-rules before the driver/kernel occupy the name of the interface?

NOTE - these workarounds (POC-level) worked for me:

  • using a different naming convention in udev rules ( e.g. management0 and span0) - worked without problems since it's not colliding with default.
  • script to run @ boot - will redefine the udev rules on hardware changes - worked, but requires an additional reboot (naive approach) - worked without problems

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.