Gerätenamen herausfinden

© cbpix, 123RF

Finde Nemo

Es war schon immer so: Ethernet-Devices in Linux heißen eth0 und nicht anders. Auf einmal verliert auch diese Wahrheit ihre Gültigkeit, und Linux-Administratoren müssen umlernen. Warum und wie, verrät dieser Teil der Admin-Story.
Seit Jahren erwartet, ist endlich Version 4 des Samba-Servers erschienen, der nun als vollwertige Alternative zu Microsofts Active Directory dienen kann. In der ... (mehr)

Neulich rief ein Kunde an und fragte mich ganz aufgeregt, was denn auf einmal mit seinem System los ist. Plötzlich gebe es kein »eth0« mehr, dafür tauchten auf einmal seltsame Namen wie »em1« oder »p3p1« in der Konsole auf. Was hier passiert ist, möchte er gerne wissen.

Die Erklärung ist recht einfach. Für die Namensgebung verantwortlich ist das regelbasierte Udev-Subsystem. Passen alle Kriterien einer Regel auf ein beim Systemstart gefundenes Netzwerk-Gerät, bekommt das Gerät den in der Regel definierten Namen, überlicherweise etwas wie »ethX« . Hier ein Beispiel:

 

Die Regel besagt, dass ein Netzwerk-Gerät mit der genannten MAC-Adresse als Device-Namen »eth0« bekommen soll und somit als erstes Gerät auf dem System sichtbar ist. Der Name in der Datei ist beliebig. Wer mag, der kann die Karte auch »public« oder »private« nennen. Das Prinzip funktioniert soweit ganz gut. Der Nachteil ist jedoch, dass offenbleibt, um welche Karte auf dem System es sich denn nun genau handelt. Klar ist lediglich, dass es die Karte mit der aufgeführten MAC-Adresse ist, ob dies jedoch auch das erste Netzwerk-Gerät auf dem System ist, ist unklar. Für System-Administratoren ist dieser Umstand immer ein großes Ärgernis. Wer schon einmal vor einem Server mit einem Dutzend Netzwerkports gestanden und dabei nach »eth0« gesucht hat, weiß, wovon ich rede.

Verwechslungsgefahr

Besonders schlimm ist es auch bei Netzwerk-Installationen, bei denen die TFTP-Boot-Anfrage über »eth0« verschickt, der Installer aber später die DHCP-DISCOVER-Meldung über eine andere als »eth0« identifierte Netzwerkkarte versendet. Ein echter Spaß bei der Fehlersuche.

Schön wäre es doch, wenn der Name, den ich auf einem System sehe, identisch mit dem Chassis-Namen wäre, sodass ich direkt sehen kann, ob es sich beispielsweise um einen Onboard-Netzwerkport oder einen Port der externen PCI-Karte handelt. Es gibt Tricks, beispielsweise die LED der Karte mittels »ethtool -p ethX« , blinken zu lassen oder dem Installer mittels »ksdevice=bootif« mitzuteilen, dass die Installation über die Netzwerkkarte erfolgen soll, über die auch das Boot-Image geladen wurde. Schön geht aber definitiv anders.

Anfang 2011 haben deshalb einige Dell-Entwickler ein neues Tool mit dem Namen »biosdevname« unter der GPL veröffentlicht. Biosdevname sorgt dafür, dass das System-BIOS die Anordnung der Netzwerk-Geräte erkennt, und diese Information an das Betriebssystem weiterreicht. Somit weiß das OS dann, ob es sich um eine Onboard-Karte oder einen externen PCI-Adpater handelt. Auch der genaue Port auf dem Motherboard oder der PCI-Karte wird erkannt.

Die neue Namensgebung, auch als Consistent Network Device Naming bekannt, folgt dann folgendem Schema. Für Onboard-Netzwerkarten lauten die neuen Namen nun:

 

beispielsweise »em1« für die erste On-board Karte. Für externe PCI-Karten sieht es folgendermaßen aus:

 

beispielsweise »p2p1« für den ersten Port auf der externen Netzwerkkarte im Slot 2.

Virtuelle Funktionen kommen dann zum Einsatz, wenn die Netzwerkkarte Single Root I/O-Virtualization (SR-IOV) unterstützt. Hiermit ist es möglich, ein einzelnes PCI-Gerät zwischen verschiedenen virtuellen Systemen aufzuteilen, ohne dabei an Performance zu verlieren. Ein virtuelles System bekommt dabei eine virtuelle Funktion des Gerätes zugewiesen. So erscheint beispielsweise eine Netzwerkkarte mit nur einem einzelnen Port mit mehreren Einträgen in der Ausgabe von »lspci« auf dem Hypervisor (Listing 1).

Listing 1

Virtuelle Netzwerk-Interfaces

 

Der erste Eintrag bezieht sich dabei auf die physische, die anderen beiden auf die virtuellen Funktionen der Karte. Jede dieser Funktionen kann dann mittels einer einfachen PCI-Zuweisung an ein virtuelles System weitergereicht werden.

Auf einem System mit aktiviertem »biosdevname« existieren somit die folgenden Geräte-Namen für die oben aufgeführte Netzwerkkarte im PCI-Slot 3: »p3p1« , »p3p1_0« , »p3p1_1« . Die Kennzeichnung für Netzwerktechnologien wie »vlan« oder Aliases bleibt erhalten. So kennzeichnet beispielsweise »p3p1:0« ein Alias für das Netzwerk-Gerät »p3p1« mit mehr als einer einzelnen IPv4-Adresse.

Infos vom BIOS

Woher bekommt nun das Betriebssystem die ganzen Informationen, also beispielsweise in welchem Slot eine Karte steckt, oder welche Ports diese Karte anbietet? Die Lösung ist recht einfach. Das System BIOS (auf aktuellen Dell und HP-Systemen) hält diese Informationen in den beiden Tabellen 9 (für externe PCI-Karten) und 41 (für Onboard-Karten) vor. Das Tool »biosdevname« greift hierauf zurück und schreibt entsprechende Einträge in eine neue Udev-Regel. Diese wiederum ist dann dafür verantwortlich, dass die Netzwerkkarten ihren neuen Namen bekommen. Sollte das System über keine aktuelle Version von SMBIOS verfügen, oder fehlen die Informationen schlichtweg in den entsprechenden Tabellen, so kann »biosdevname« auch Daten der PCI IRQ Routing Tabelle zurückgreifen. Die Tools »dmidecode« und »biosdecode« stellen die Informationen auf Anfrage zur Verfügung. Alternativ hilft auch das Skript in Listing 2 weiter.

Listing 2

Hardware-Check

 

comments powered by Disqus

Artikel der Woche

Setup eines Kubernetes-Clusters mit Kops

Vor allem für Testinstallationen von Kubernetes gibt es einige Lösungen wie Kubeadm und Minikube. Für das Setup eines Kubernetes-Clusters in Cloud-Umgebungen hat sich Kops als Mittel der Wahl bewährt. Wir beschreiben seine Fähigkeiten und geben eine Anleitung für den praktischen Einsatz. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite