Die Benennung von Netzdevices in den Default-Einstellungen von udev zeigen in einzelnen Fällen nicht vorhersehbare Ergebnisse (falsche Zuordnung der Netzwerkkarten zu Devicenamen bzw. deren sporadische Vertauschung). Auch wenn man in diesem Zusammenhang immer von „predictable“ (vorhersagbaren) Devicenamen liest, sind sie es dennoch nicht immer.

udev verwendet in der Standardkonfiguration die BusID einer Netzwerkkarte zur Bildung eines Devicenamen z. B. enp0s7. Allerdings ändert sich diese, wenn eine beliebige Steckkarte installiert oder entfernt oder eine Onboard-Schnittstelle aktiviert oder deaktiviert wird.

Mit dem Base-Update 2.7.9 wurde das Verhalten des udev insofern geändert, dass die Devicenamen von der Mac-Adresse der Netzwerkkarte abgeleitet werden, z. B. enx0b2cde5f97.

Zudem zeigen sich weiterhin „Race Conditions“ in Form von vertauschten Zuordnungen von Netzwerkkarten zu Netzwerken, wenn im laufenden System für die Netzwerkschnittstellen ethX-Namen verwendet werden. Unbeherschbar scheinen die insbesondere, wenn ein Kernelmodul mehrere der im System verbauten Netzwerkkarten bedient.

Wirkliche Abhilfe schafft hier nur der konsequente Verzicht auf ethX-Devices im laufenden System, also mit von der MAC-Adresse abgeleiteten Devicenamen.

#------------------------------------------------------------------------------
# Ethernet card drivers:
#
# Name            Kernel   Bus        Description
[...]
# -----------------------------------------------------------------------------
ETH_DRV_N='1'                     # number of ethernet drivers to load
ETH_DRV_1='skge'                  # driver name
ETH_DRV_1_OPTION=''               # additional option, e.g. 'io=0x340' for ne
 
#------------------------------------------------------------------------------
# Ether networks used with IP protocol:
#------------------------------------------------------------------------------
 
IP_ETH_N='1'                      # number of ip ethernet networks
IP_ETH_1_NAME=''                  # optional: other device name than ethX
IP_ETH_1_IPADDR='192.168.100.233' # IP address of your n'th ethernet card
IP_ETH_1_NETWORK='192.168.100.0'  # network of your LAN
IP_ETH_1_NETMASK='255.255.255.0'  # netmask of your LAN

Bei zwei Netzwerkkarten und Netzwerken sah das so aus:

#------------------------------------------------------------------------------
# Ethernet card drivers:
#
# Name            Kernel   Bus        Description
[...]
# -----------------------------------------------------------------------------
ETH_DRV_N='2'                     # number of ethernet drivers to load
ETH_DRV_1='skge'                  # driver name
ETH_DRV_1_OPTION=''               # additional option, e.g. 'io=0x340' for ne
ETH_DRV_2='sky2'                  # driver name
ETH_DRV_2_OPTION=''               # additional option, e.g. 'io=0x340' for ne
 
#------------------------------------------------------------------------------
# Ether networks used with IP protocol:
#------------------------------------------------------------------------------
 
IP_ETH_N='2'                      # number of ip ethernet networks
IP_ETH_1_NAME=''                  # optional: other device name than ethX
IP_ETH_1_IPADDR='192.168.1.1'     # IP address of your n'th ethernet card
IP_ETH_1_NETWORK='192.168.1.0'    # network of your LAN
IP_ETH_1_NETMASK='255.255.255.0'  # netmask of your LAN
IP_ETH_2_NAME=''                  # optional: other device name than ethX
IP_ETH_2_IPADDR='192.168.2.1'     # IP address of your n'th ethernet card
IP_ETH_2_NETWORK='192.168.2.0'    # network of your LAN
IP_ETH_2_NETMASK='255.255.255.0'  # netmask of your LAN

Beim Boot wurden die Netzwerkkartenmodule in der angegebenen Reihenfolge geladen, wobei das zuerst angegebene Modul zu eth0, das nächste zu eth1 usw. wurde.

Waren bei den „Ether networks“ keine Devicenamen explizit angegeben, wurden dem ersten Netzwerk eth0, dem zweiten eth1 usw. zugeordnet.

Mit dem Base-Update 2.7.7 wurde auf udev umgestellt und die ETH_DRV-Sektion der Base-Konfiguration hat keine Bedeutung mehr und wird durach das Base-Update 2.7.8 aus der Base-Konfiguration automatisch entfernt. Beim Boot werden nun für alle vorhandenen physikalischen Netzwerkkarten die notwendigen Module geladen, also auch für Netzwerkkarten, die vorher zwar auch schon vorhanden waren, aber nicht benutzt wurden, für die in der Base-Konfiguration aber kein Modul angegeben war.

Dies erfordert nun eventuell Anpassungen in der Konfiguration:

Die initiale Benennung beim Bootvorgang durch udev, der Kernel selbst benutzt immer eth0, eth1, usw., richtet sich nach der Einstellung der Kerneloption net.ifnames. Diese wird in den append-Zeilen der /etc/lilo.conf vorgenommen.

Erstmalig mit eiskernel 2.19.0 wurde diese Option mit „net.ifnames=0“ gesetzt, davor fehlte diese Option gänzlich.

Seit eiskernel 2.26.1 wird die Option auf „net.ifnames=0“ gesetzt, falls sie bislang nicht in /etc/lilo.conf„ gesetzt war, oder sie wird in der vorgefundenen Einstellung (net.ifnames=0 bzw. net.ifnames=1) übernommen.

Die Base-Konfiguration ab Base 2.7.8 setzt diese Option in Abhängigkeit von der Anzahl vorhandener Netzwerkkarten:

• 1 Netzwerkkarte: net.ifnames=0
• mehr als eine Netzwerkkate: net.ifnames=1

Die Base-Konfiguration ruft lilo und fordert zum Reboot auf, falls diese Einstellung geändert wurde.

Jede manuelle Änderung an der lilo.conf erfordert einen Aufruf von lilo und anschließendem Reboot, damit die Änderung wirksam wird.

Je nachdem, welchen Wert net.ifnames hat, werden die Netzwerkkarten initial von udev nach folgendem Schema benannt:

• net.ifnames=0: eth0, eth1, …
• net.ifnames=1: z. B. enp0s9, enp0s25, enx0b2cde5f97, …: Die Devicenamen werden aus Typ der Netzwerkkarte, PCI-Slot, MAC-Adresse… gebildet. Statt der Prefixe enp und enx kommen auch eno, und ens als Prefixe vor.
  • Base 2.7.7 und 2.7.8:: z. B. enp0s9, enp0s25, …: Die Devicenamen werden aus Typ der Netzwerkkarte, PCI-Slot, … gebildet. Statt des Prefixes enp kommen auch eno und ens als Prefixe vor.
  • Base >= 2.7.9:: z. B. enx0b2cde5f97, …: Die Devicenamen werden aus Mac-Adresse der Netzwerkkarte gebildet. Statt des Prefixes enx kommen auch eno und ens als Prefixe vor.

Im laufenden System existiert unter /sys/class/net ein Unterverzeichnis für jede Netzwerkschnittstelle, wobei der Verzeichnissname mit dem aktuell verwendeten Device-Namen identisch ist. Wenn für eine Netzwerkkarte eine udev-Regel aktiv ist, entspricht der aktuelle Name nicht unbedingt dem von udev vergebenen eindeutigen Namen.

Wie udev die Netzwerkkarten eindeutig benennen würde, kann mit folgendem Befehl ermittelt werden:

# udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null
ID_NET_NAME_MAC=enx01027fb230b7
ID_NET_NAME_PATH=enp2s11

# udevadm test-builtin net_id /sys/class/net/eth1 2>/dev/null
ID_NET_NAME_MAC=enx97f4a47ab801
ID_NET_NAME_PATH=enp5s2

# udevadm test-builtin net_id /sys/class/net/enp2s5 2>/dev/null
ID_NET_NAME_MAC=enx102c6da726ef
ID_NET_NAME_PATH=enp2s5

Die entscheidende Information ist in der Zeile ID_NET_NAME_PATH zu finden. Beim letzten Beispiel fand keine spezielle Umbenennung statt, der Devicename im laufenden Betrieb und der Namensvorschlag von udev sind identisch.

Hinweis: Wird ein Kernel älter als Version 2.19.1 genutzt, ist mit Base 2.7.7 in der /etc/lilo.conf in den append-Zeilen „net.ifnames=0“, ab Base 2.7.8 „net.ifnames=0“ bei einer Netzwerkkarte und „net.ifnames=1“ bei mehr als einer Netzwerkkarte zu ergänzen. Anschliessend ist lilo aufzurufen und zu rebooten. Seit Base 2.7.10 wird generell „net.ifnames=1“ gesetzt!

Existiert nur eine Netzwerkkarte im System, muss ETH_1_NAME auf eth0 gesetzt sein oder leer gelassen werden; die Angabe einer MAC-Adresse ist in diesem Fall nicht erforderlich:

#------------------------------------------------------------------------------
# Ether networks used with IP protocol:
#------------------------------------------------------------------------------
 
IP_ETH_N='1'                           # number of ip ethernet networks
IP_ETH_1_NAME=''                       # optional: other device name than ethX
IP_ETH_1_IPADDR='192.168.1.1'          # IP address of your n'th ethernet card
IP_ETH_1_NETWORK='192.168.1.0'         # network of your LAN
IP_ETH_1_NETMASK='255.255.255.0'       # netmask of your LAN
IP_ETH_1_MACADDR=''                    # Mac address of your n'th ethernet card

In diesem Fall wird keine udev-Regel erzeugt. Bei einem Tausch dieser Netzwerkkarte gegen eine andere Netzwerkkarte ist keine Neukonfiguration notwendig.

Wird diese Hardwarekonfiguration durch Ausbau einer weiteren Netzwerkkarte erst hergestellt, so dass sich nun nur noch eine Netzwerkkarte im System befindet, muss IP_ETH_1_NAME wieder auf eth0 gesetzt oder leer gelassen werden! Die Base-Konfiguration ist unbedingt aufzurufen, damit die geänderte Konfiguration in die Systemdateien übernommen wird.

Nehmen wir also mal an, es gäbe eine Onboard-Schnittstelle mit Realtek-Chipsatz (Modul r8169) und eine Intel-Netzwerkkarte (Modul e1000e), wobei aber die Intel-Netzwerkkarte mit dem Netzwerk verbunden ist.

Beide Module werden nun beim Boot geladen, wobei die Reihenfolge nicht unbedingt vorhersehbar ist. Die zuerst geladene Karte wird somit zu eth0 und die zweite zu eth1. Ist eth0 wie früher die Intel-Karte, dann ist alles wie vorher und die Umstellung auf udev macht keine Probleme; wird jedoch die Realtek-Schnittstelle zu eth0, hat der Server nun keine Verbindung zum Netzwerk mehr.

Abhilfe schafft das Blacklisten des r8169-Moduls in der Module-Sektion der Base-Konfiguration.

#------------------------------------------------------------------------------
# Kernel modules treatment:
#------------------------------------------------------------------------------
MODULE_N='1'                           # number of modules to be treated
MODULE_1_NAME='r8169'                  # name of module to be treated
MODULE_1_ACTIVE='yes                   # active 'yes' or 'no'
MODULE_1_ACTION='blacklist'            # action to apply to this module
MODULE_1_STRING=''                     # option(s) for module

Nun wird das r8169-Modul beim Boot nicht mehr geladen.

Kann die Netzwerkkarte von mehr als einem Modul angesprochen werden, müssen sämtliche Module blackgelistet werden, damit die Netzwerkkarte nicht verwendet wird:

#------------------------------------------------------------------------------
# Kernel modules treatment:
#------------------------------------------------------------------------------
MODULE_N='2'                           # number of modules to be treated
MODULE_1_NAME='r8169'                  # name of module to be treated
MODULE_1_ACTIVE='yes                   # active 'yes' or 'no'
MODULE_1_ACTION='blacklist'            # action to apply to this module
MODULE_1_STRING=''                     # option(s) for module
MODULE_2_NAME='r8168'                  # name of module to be treated
MODULE_2_ACTIVE='yes                   # active 'yes' or 'no'
MODULE_2_ACTION='blacklist'            # action to apply to this module
MODULE_2_STRING=''                     # option(s) for module

Nun werden die Module r8169 und r8168 beim Boot nicht mehr geladen.

Eine andere Möglichkeit diesen Anwendungsfall aufzulösen, wird im Abschnitt Zuordnung von Netzwerkkarten zu Netzwerken mittels udev-Regeln (mehr Netzwerkkarten als Netzwerke) beschrieben.

Es existieren Netzwerkkarten z. B. Realtek-Karten, die von mehreren Modulen bedient werden können. Im Falle von Realtek-Karten sind dies oft die Module r8168 und r8169.

Ein lspci -vv auf der Kommandozeile zeigt dies dann für die Schnittstelle so an:

eis# lspci -vv
[...]
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 0c)
        Subsystem: ASUSTeK Computer Inc. Device [1043:8554]
[...]
        Kernel driver in use: r8169
        Kernel modules: r8169, r8168
[...]

Nun kann es gewünscht sein, selbst zu bestimmen, welches Modul hier anstatt des vom Kernel gewählten, verwendet werden soll, was man wieder mit Blacklisten erreicht. Im folgenden Beispiel wird der r8169 blacklisted und somit der r8168 verwendet:

#------------------------------------------------------------------------------
# Kernel modules treatment:
#------------------------------------------------------------------------------
MODULE_N='1'                           # number of modules to be treated
MODULE_1_NAME='r8169'                  # name of module to be treated
MODULE_1_ACTIVE='yes                   # active 'yes' or 'no'
MODULE_1_ACTION='blacklist'            # action to apply to this module
MODULE_1_STRING=''                     # option(s) for module

Hinweis: Wenn nach einem Kernelupdate eine vermeintlich blacklistete Netzwerkkarte wieder auftaucht, kann es sein, dass diese nun erst auch von einem weiteren Modul unterstützt wird. In diesem Fall wäre dieses Modul nun auch zu blacklisten.

Befinden sich im Server mehrere Netzwerkkarten, die von dem gleichen Modul bedient werden, ist die Zuordnung zu den Devices nicht vorhersehbar. Abhilfe schafft die Verwendung von ethX-Devicenamen in der Base-Konfiguration, die beim Boot garantiert nicht in Benutzung sind; bei X vorhandenen Netzwerkkarten wäre eth(X-1) und höher nutzbar:

#------------------------------------------------------------------------------
# Ether networks used with IP protocol:
#------------------------------------------------------------------------------
 
IP_ETH_N='2'                           # number of ip ethernet networks
IP_ETH_1_NAME='eth2'                   # optional: other device name than ethX
IP_ETH_1_IPADDR='192.168.1.1'          # IP address of your n'th ethernet card
IP_ETH_1_NETWORK='192.168.1.0'         # network of your LAN
IP_ETH_1_NETMASK='255.255.255.0'       # netmask of your LAN
IP_ETH_1_MACADDR='00:0e:17:56:9b:10'   # Mac address of your n'th ethernet card
IP_ETH_2_NAME='eth3'                   # optional: other device name than ethX
IP_ETH_2_IPADDR='192.168.2.1'          # IP address of your n'th ethernet card
IP_ETH_2_NETWORK='192.168.2.0'         # network of your LAN
IP_ETH_2_NETMASK='255.255.255.0'       # netmask of your LAN
IP_ETH_2_MACADDR='12:de:54:a3:0c:0f'   # Mac address of your n'th ethernet card

Ab Base 2.7.9 ist die Benutzung der eindeutigen durch udev vergebenen Devicenamen wie enx000e17569b10 (Base 2.7.7/2.7.8: enp0s9 oder enp0s25) angeraten, was allerdings zu Problemen mit Paketen führt, die nur ethX-Devices in ihrer Konfiguration zulassen:

#------------------------------------------------------------------------------
# Ether networks used with IP protocol:
#------------------------------------------------------------------------------
 
IP_ETH_N='2'                           # number of ip ethernet networks
IP_ETH_1_NAME='enx000e17569b10'        # optional: other device name than ethX
IP_ETH_1_IPADDR='192.168.1.1'          # IP address of your n'th ethernet card
IP_ETH_1_NETWORK='192.168.1.0'         # network of your LAN
IP_ETH_1_NETMASK='255.255.255.0'       # netmask of your LAN
IP_ETH_1_MACADDR='00:0e:17:56:9b:10'   # Mac address of your n'th ethernet card
IP_ETH_2_NAME='enx12de54a30c0f'        # optional: other device name than ethX
IP_ETH_2_IPADDR='192.168.2.1'          # IP address of your n'th ethernet card
IP_ETH_2_NETWORK='192.168.2.0'         # network of your LAN
IP_ETH_2_NETMASK='255.255.255.0'       # netmask of your LAN
IP_ETH_2_MACADDR='12:de:54:a3:0c:0f'   # Mac address of your n'th ethernet card

Hinweis: Ab Base 2.7.8 ist das im folgenden beschriebene Vorgehen (bis auf den Sonderfall „Mehrere Netzwerkkarten werden vom gleichen Modul bedient“) wegen geänderter Kerneloption beim Boot nicht mehr notwendig, wenn in der Base-Konfiguration der Parameter ETH_x_MACADDR auf die richtige Netzwerkkarte verweist. Eine zufällige Zuordnung bzw. Vertauschung der Netzwerkkarten tritt dadurch nicht mehr auf.

Mit dem Base-Update 2.7.3 wurde die Netzwerkkonfiguration um den Parameter MACADDR ergänzt, womit eine eindeutige Zuordnung von Netzwerkkarte und Netzwerk mittels udev-Regeln möglich wird. Werden mehr als eine Netzwerkkarte erkannt, werden nach Abschluss der Base-Konfiguration für jedes definierte Netzwerk eine udev-Regeln erstellt.

Im folgenden Beispiel sind also zwei Netzwerkkarten vorhanden, die von eth0 und eth1 bedient werden.

#------------------------------------------------------------------------------
# Ether networks used with IP protocol:
#------------------------------------------------------------------------------
 
IP_ETH_N='2'                           # number of ip ethernet networks
IP_ETH_1_NAME='eth0'                   # optional: other device name than ethX
IP_ETH_1_IPADDR='192.168.1.1'          # IP address of your n'th ethernet card
IP_ETH_1_NETWORK='192.168.1.0'         # network of your LAN
IP_ETH_1_NETMASK='255.255.255.0'       # netmask of your LAN
IP_ETH_1_MACADDR='00:0e:17:56:9b:10'   # Mac address of your n'th ethernet card
IP_ETH_2_NAME='eth1'                   # optional: other device name than ethX
IP_ETH_2_IPADDR='192.168.2.1'          # IP address of your n'th ethernet card
IP_ETH_2_NETWORK='192.168.2.0'         # network of your LAN
IP_ETH_2_NETMASK='255.255.255.0'       # netmask of your LAN
IP_ETH_2_MACADDR='12:de:54:a3:0c:0f'   # Mac address of your n'th ethernet card

Die Netzwerkkarte mit der MAC '00:0e:17:56:9b:10' wird dadurch an eth0, die mit der MAC '12:de:54:a3:0c:0f' an eth1 gebunden, unabhängig davon, in welcher Reihenfolge die Module geladen werden.

Leider wird man feststellen, dass es sporadisch zu Vertauschungen der Netzwerkinterfaces kommt. Dies rührt aus einer Race Condition, wie sie in https://github.com/systemd/systemd/issues/2657 beschrieben wird.

Wird das Modul für das ETH_2-Netzwerk als erstes geladen, belegt es zunächst eth0 und wird dann mittels udev zu eth1 umbenannt. Wird nun das zweite Netzwerkkarten-Modul geladen, bevor diese Umbenennung geschehen ist, belegt dieses eth1 und die Umbenennung für das erste Modul schlägt fehl. Gleichermaßen wird dann auch die Umbenennung des zweiten Moduls nach eth0 blockiert. In /var/log/messages finden sich dann Meldungen folgender Art:

Nov  6 09:40:24 eis kernel: <27>udevd[1508]: Error changing net interface name eth0 to eth1: File exists
Nov  6 09:40:24 eis kernel: <28>udevd[1508]: could not rename interface '2' from 'eth0' to 'eth1': File exists
Nov  6 09:40:24 eis kernel: <27>udevd[1689]: Error changing net interface name eth1 to eth0: File exists
Nov  6 09:40:24 eis kernel: <28>udevd[1689]: could not rename interface '3' from 'eth1' to 'eth0': File exists

Scheinbar gibt es nur eine Möglichkeit, dieses Problem zu lösen: Verwendung von ethX-Devicenamen in der Base-Konfiguration, die beim Boot garantiert nicht in Benutzung sind; bei X vorhandenen Netzwerkkarten wäre eth(X-1) und höher nutzbar, also etwa folgende Konfiguration:

#------------------------------------------------------------------------------
# Ether networks used with IP protocol:
#------------------------------------------------------------------------------
 
IP_ETH_N='2'                           # number of ip ethernet networks
IP_ETH_1_NAME='eth2'                   # optional: other device name than ethX
IP_ETH_1_IPADDR='192.168.1.1'          # IP address of your n'th ethernet card
IP_ETH_1_NETWORK='192.168.1.0'         # network of your LAN
IP_ETH_1_NETMASK='255.255.255.0'       # netmask of your LAN
IP_ETH_1_MACADDR='00:0e:17:56:9b:10'   # Mac address of your n'th ethernet card
IP_ETH_2_NAME='eth3'                   # optional: other device name than ethX
IP_ETH_2_IPADDR='192.168.2.1'          # IP address of your n'th ethernet card
IP_ETH_2_NETWORK='192.168.2.0'         # network of your LAN
IP_ETH_2_NETMASK='255.255.255.0'       # netmask of your LAN
IP_ETH_2_MACADDR='12:de:54:a3:0c:0f'   # Mac address of your n'th ethernet card

Die Netzwerkkarte mit der MAC '00:0e:17:56:9b:10' wird dadurch an eth2, die mit der MAC '12:de:54:a3:0c:0f' an eth3 gebunden, unabhängig davon, in welcher Reihenfolge die Module geladen werden.

Bei Installation des 2.7.3er-Base-Updates wurden die MAC-Adressen in der Base-Konfiguration automatisch auf die aktuellen Werte gesetzt.

Ab Base 2.7.9 ist die Benutzung der eindeutigen durch udev vergebenen Devicenamen wie enx000e17569b10 (Base 2.7.7/2.7.8: enp0s9 oder enp0s25) angeraten, was allerdings zu Problemen mit Paketen führt, die nur ethX-Devices in ihrer Konfiguration zulassen:

#------------------------------------------------------------------------------
# Ether networks used with IP protocol:
#------------------------------------------------------------------------------
 
IP_ETH_N='2'                           # number of ip ethernet networks
IP_ETH_1_NAME='enx000e17569b10'        # optional: other device name than ethX
IP_ETH_1_IPADDR='192.168.1.1'          # IP address of your n'th ethernet card
IP_ETH_1_NETWORK='192.168.1.0'         # network of your LAN
IP_ETH_1_NETMASK='255.255.255.0'       # netmask of your LAN
IP_ETH_1_MACADDR='00:0e:17:56:9b:10'   # Mac address of your n'th ethernet card
IP_ETH_2_NAME='enx12de54a30c0f'        # optional: other device name than ethX
IP_ETH_2_IPADDR='192.168.2.1'          # IP address of your n'th ethernet card
IP_ETH_2_NETWORK='192.168.2.0'         # network of your LAN
IP_ETH_2_NETMASK='255.255.255.0'       # netmask of your LAN
IP_ETH_2_MACADDR='12:de:54:a3:0c:0f'   # Mac address of your n'th ethernet card

Wird eine Netzwerkkarte entfernt, so dass sich nun nur noch eine Netzwerkkarte im System befindet, muss IP_ETH_1_NAME wieder auf eth0 gesetzt oder leer gelassen werden! Die Base-Konfiguration ist unbedingt aufzurufen, damit die geänderte Konfiguration in die Systemdateien übernommen wird.

Hinweis: Ab Base 2.7.8 ist das im folgenden beschriebene Vorgehen (bis auf den Sonderfall „Mehrere Netzwerkkarten werden vom gleichen Modul bedient“) wegen geänderter Kerneloption beim Boot nicht mehr notwendig, wenn in der Base-Konfiguration der Parameter ETH_x_MACADDR auf die richtige Netzwerkkarte verweist. Eine zufällige Zuordnung bzw. Vertauschung der Netzwerkkarten tritt dadurch nicht mehr auf. Ebenso müssen ungenutzte Netzwerkkarten nicht blackgelistet werden.

Sind zwei Netzwerkkarten vorhanden, die z. B. mit den Modulen sky2 und skge angesprochen werden, der Server mit der an der skge-Karte mit dem Netzwerk verbunden ist, also die Netzwerkkonfiguration etwa so aussieht:

#------------------------------------------------------------------------------
# Ether networks used with IP protocol:
#------------------------------------------------------------------------------
 
IP_ETH_N='1'                           # number of ip ethernet networks
IP_ETH_1_NAME=''                       # optional: other device name than ethX
IP_ETH_1_IPADDR='192.168.1.1'          # IP address of your n'th ethernet card
IP_ETH_1_NETWORK='192.168.1.0'         # network of your LAN
IP_ETH_1_NETMASK='255.255.255.0'       # netmask of your LAN
IP_ETH_1_MACADDR='00:0e:17:56:9b:10'   # Mac address of your n'th ethernet card

Nun existiert also eine udev-Regel, die die skge-Karte (mit der angegebenen Phantasie-MAC) an eth0 bindet. Für die sky2-Karte existiert keine udev-Regel, da ja kein zweites Netzwerk definiert ist.

Wird nun beim Boot zufälligerweise das sky2-Modul vor dem skge-Modul geladen, bekommt dieses dann automatisch eth0 zugewiesen, womit die für die skge-Netzwerkkarte angelegte udev-Regel nicht mehr greift, der Server steht also nun ohne Netzwerk da.

Hier hilft wiederum, das sky2-Modul blackzulisten (s. o.), oder aber auch für diese Karte ein Netzwerk zu konfigurieren, damit für das sky2-Modul ebenfalls eine udev-Regel existiert.

Eine zweite Möglichkeit ist die  Verwendung von ethX-Devicenamen in der Base-Konfiguration, die beim Boot garantiert nicht in Benutzung sind; bei X vorhandenen Netzwerkkarten wäre eth(X-1) und höher nutzbar::

#------------------------------------------------------------------------------
# Ether networks used with IP protocol:
#------------------------------------------------------------------------------
 
IP_ETH_N='1'                           # number of ip ethernet networks
IP_ETH_1_NAME='eth2'                   # optional: other device name than ethX
IP_ETH_1_IPADDR='192.168.1.1'          # IP address of your n'th ethernet card
IP_ETH_1_NETWORK='192.168.1.0'         # network of your LAN
IP_ETH_1_NETMASK='255.255.255.0'       # netmask of your LAN
IP_ETH_1_MACADDR='00:0e:17:56:9b:10'   # Mac address of your n'th ethernet card

Nun existiert also eine udev-Regel, die die skge-Karte (mit der angegebenen Phantasie-MAC) an eth2 bindet. Alle weiteren Netzwerkkartenmodule belegen dann eth0, eth1 usw. und stören die Funtkion des oben definierten Netzwerkes nicht. Blacklisten ungenutzter Netzwerkkarten wäre in diesem Fall nicht mehr nötig, aber dennoch ratsam.

Ab Base 2.7.9 ist die Benutzung der eindeutigen durch udev vergebenen Devicenamen wie enx000e17569b10 (Base 2.7.7/2.7.8: enp0s9 oder enp0s25) angeraten, was allerdings zu Problemen mit Paketen führt, die nur ethX-Devices in ihrer Konfiguration zulassen:

#------------------------------------------------------------------------------
# Ether networks used with IP protocol:
#------------------------------------------------------------------------------
 
IP_ETH_N='1'                           # number of ip ethernet networks
IP_ETH_1_NAME='enx000e17569b10'        # optional: other device name than ethX
IP_ETH_1_IPADDR='192.168.1.1'          # IP address of your n'th ethernet card
IP_ETH_1_NETWORK='192.168.1.0'         # network of your LAN
IP_ETH_1_NETMASK='255.255.255.0'       # netmask of your LAN
IP_ETH_1_MACADDR='00:0e:17:56:9b:10'   # Mac address of your n'th ethernet card

Wird eine Netzwerkkarte entfernt, so dass sich nun nur noch eine Netzwerkkarte im System befindet, muss IP_ETH_1_NAME wieder auf eth0 gesetzt oder leer gelassen werden! Die Base-Konfiguration ist unbedingt aufzurufen, damit die geänderte Konfiguration in die Systemdateien übernommen wird.

Es existieren eine Reihe von Paketen, die in ihrer Konfiguration auf Netzwerk-Devicenamen referenzieren:

• bridge
  • Erfordert in der Paketkonfiguration ab Version 2.5.1 die Parameter BRIDGE_X_DEVICE_Y_NAME auf die neuen Devicenamen zu setzen.
• brute_force_blocking
  • Von eth0-eth3 abweichende Devicenamen für Netzwerkkarten im Parameter BFB_EXTERNAL_INTERFACE können ab Version 0.8.4 des Paketes eingetragen werden.
• dhcpc
  • Mit Erscheinen des Base-Updates 2.7.9 wurde mit Version 2.6.0 eine angepasste Version des dhcpc-Paketes bereitgestellt, in der die alle möglichen Devicenamen eingetragen werden können..
• dsl
  • Erfordert den neuen Devicenamen unter PPPOE_NET einzutragen.
• eisgraph
  • Ab Version 1.2.3 des Paketes sind beliebige Devicenamen für Netzwerkkarten möglich. Dies erfordert im eisgraph-Menü zunächst die Target-Liste neu zu erzeugen und dann in der Paketkonfiguration den/die Devicenamen für das/die Netzwerktarget(s) (EISGRAPH_TARGET_X) auszutauschen.
• iftop
  • Von eth0-eth2 abweichende Devicenamen für Netzwerkkarten im Parameter IFTOP_INTERFACE können ab Version 0.1.5 des Paketes eingetragen werden.
• ipv6
  • Von ethX abweichende Devicenamen für den Parameter IPV6_TUNNEL_IPV4IF können in der aktuellen Version des Paketes nicht eingetragen werden. Das Paket muss überarbeitet werde
• minidlna
  • Erfordert in der Paketkonfiguration die Parameter MINIDLNA_NIC_X auf die neuen Devicenamen zu setzen.
• nagios
  • Sind z. b. in Konfigurationsparametern wie NAGIOS_SERVICE_X_CHECK_OPTION Devicenamen angegeben, sind diese durch die neuen Devicenamen zu ersetzen.
• openvpn2
  • Erfordert in der Paketkonfiguration den Parameter OPENVPN2_MASQ_IF auf den neuen Devicenamen zu setzen.
• vlan (Paket derzeit nicht verfügbar)
• vnstat
  • Ab Version 2.0.2 des Paketes können beliebige Devicenamen in der Paketkonfiguration im Parameter VNSTAT_X_DEV eingegeben werden.

• Blacklisten von Modulen für nicht benutzte Netzwerkkarten.
• Blacklisten von unerwünschten Modulen für eine bestimmte Netzwerkkarte, wenn diese von mehreren Modulen angesprochen werden kann, da nicht vorhersehbar ist, welches Modul der Kernel bevorzugt.
• Verwendung eindeutiger Devicenamen (ETH_x_NAME) statt eth0, eth1, …, oder eth(X-1) (wobei X die Zahl der Netzwerkkarten ist); aber nur, wenn sich mehrere Netzwerkkarten im System befinden.
  
• Beim Austausch einer Netzwerkkarte muss die MAC-Adresse in der Base-Konfiguration angepasst werden.
• Aufruf der Base-Konfiguration, wenn Netzwerkkarten ausgebaut werden und sich dadurch nur noch eine Netzwerkkarte im System befindet.
• Bei Änderung von Devicenamen daran denken, dass die Konfiguration von anderen Paketen, die Netzwerk-Devicenamen benutzen, angepasst werden muss.

In der Netzwerkkonfiguration der Base-Konfiguration wird die MAC-Adresse bequem aus einem Auswahldialog ausgewählt. Die folgende Beschreibung beschreibt die Ermittlung einer MAC-Adresse auf der Kommandozeile.

Um die MAC-Adresse einer Netzwerkkarte feststellen zu können, muss der zugehörige Treiber geladen sein.

Zunächst muss die BUS-ID der Karte ermittelt werden:

eis # lspci -vv | grep "Ethernet"
02:05.0 Ethernet controller: 3Com Corporation 3c940 10/100/1000Base-T [Marvell] (rev 12)
02:0b.0 Ethernet controller: Intel Corporation 82557/8/9/0/1 Ethernet Pro 100 (rev 0c)

Filtern der Ausgabe von dmesg nach der BUS-ID 02:05.0; wegen nicht geladenem Modul ergibt dies für die 3Com-Netzwerkkarte nur rudimentäre Informationen:

eis # dmesg | grep "02:05.0"
[    0.000000] pci 0000:02:05.0: [10b7:1700] type 0 class 0x000200
[    0.000000] pci 0000:02:05.0: reg 10: [mem 0xf7eec000-0xf7eeffff]
[    0.000000] pci 0000:02:05.0: reg 14: [io  0xd800-0xd8ff]
[    0.000000] pci 0000:02:05.0: supports D1 D2
[    0.000000] pci 0000:02:05.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.000000] pci 0000:02:05.0: PME# disabled

Filtern der Ausgabe von dmesg nach der BUS-ID:02:0b.0:

eis # dmesg | grep "02:0b.0"
[    0.000000] pci 0000:02:0b.0: [8086:1229] type 0 class 0x000200
[    0.000000] pci 0000:02:0b.0: reg 10: [mem 0xf7eeb000-0xf7eebfff]
[    0.000000] pci 0000:02:0b.0: reg 14: [io  0xdf00-0xdf3f]
[    0.000000] pci 0000:02:0b.0: reg 18: [mem 0xf7ec0000-0xf7edffff]
[    0.000000] pci 0000:02:0b.0: reg 30: [mem 0xf7eb0000-0xf7ebffff pref]
[    0.000000] pci 0000:02:0b.0: supports D1 D2
[    0.000000] pci 0000:02:0b.0: PME# supported from D0 D1 D2 D3hot D3cold
[    0.000000] pci 0000:02:0b.0: PME# disabled
[    0.000000] pci 0000:02:0b.0: Firmware left e100 interrupts enabled; disabling
[    0.000000] e100 0000:02:0b.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
[    0.000000] e100 0000:02:0b.0: PME# disabled
[    0.000000] e100 0000:02:0b.0: eth0: addr 0xf7eeb000, irq 23, MAC addr 00:0e:17:56:9b:10
[    0.000000] e100 0000:02:0b.0: eth0: NIC Link is Up 100 Mbps Full Duplex

Die wesentlichen Informationen sind:

• Netzwerkkarte (Zeile 2)
• Modul e100 (Zeile 11)
• Device eth0 (Zeile 13) - durch eventuell vorhandene udev-Regeln wird der Device-Name möglicherweise im Fortgang des Bootprozesses noch geändert.
• MAC 00:0e:17:56:9b:10 (Zeile 13)

Der lspci -vv Kommandozeilebefehl zeigt u. a. auch die für eine bestimmte Hardware zuständigen Module an:

eis# lspci -vv
[...]
04:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 0c)
Subsystem: ASUSTeK Computer Inc. Device [1043:8554]
[...]
Kernel driver in use: r8169
Kernel modules: r8169, r8168
[...]

Die wesentlichen Informationen sind:

• Geladenes Modul r8169 (Zeile 6)
• Mögliche Module r8168 und r8169 (Zeile 7)