SYSTEMD.NET-NAMING-SCHEME(7)

BEZEICHNUNG
systemd.net-naming-scheme - Benennungsschema für Netzwerkgeräte

BESCHREIBUNG

Netzwerkschnittstellennamen und MAC-Adressen können auf Basis bestimmter gleichbleibender Schnittstellenattribute erstellt werden. Dies ist möglich, wenn es genug Informationen über das Gerät gibt, um diese Attribute zu erstellen und die Verwendung dieser Information konfiguriert wurde. Diese Seite beschreibt die Schnittstellenbenennung, d.h. welche möglichen Namen erstellt werden können. Diese Namen werden durch das in systemd-udevd.service(8) eingebaute net_id und als udev(7)-Eigenschaften (ID_NET_NAME_ONBOARD=, ID_NET_LABEL_ONBOARD=, ID_NET_NAME_PATH=, ID_NET_NAME_SLOT=) exportiert.

Namen und MAC-Adressen werden aus verschiedenen gleichbleibenden Metadatenattributen abgeleitet. Neuere Versionen von systemd-udevd(8) berücksichtigen mehr dieser Attribute und verbessern (und damit ändern) die für die gleichen Geräte verwandten Namen und Adressen. Verschiedene Versionen dieser Erstellungsregeln werden »Benennungsschema« genannt. Das Standard-Benennungsschema wird zum Kompilierungszeitpunkt ausgewählt. Normalerweise wird dies die neuste implementierte Version sein, aber es ist auch möglich, dies auf eine ältere Version zur Erhaltung der Kompatibilität zu setzen. Dies könnte beispielsweise für Distributionen nützlich sein, die neuere Versionen von Systemd in stabilen Veröffentlichungen integrieren, ohne das Benennungschema zu ändern. Das Benennungschema kann auch mittels des Kernelbefehlszeilenschalters net.naming_scheme= außer Kraft gesetzt werden, siehe systemd-udevd.service(8). Verfügbare Benennungsschemas werden nachfolgend beschrieben.

Nachdem die Udev-Eigenschaften erstellt worden sind, können Geräte anhand dieser Eigenschaften und den geeigneten Udev-Regeln tatsächlich umbenannt werden. Siehe die Beschreibung von NamePolicy= und MACAddressPolicy= in systemd.link(5).

Beachten Sie, dass das Konzept der Netzwerkschnittstellenbenennung zwar primär im Kontext von systemd-udevd.service relevant ist, aber der Container-Verwalter systemd-nspawn(1) sie auch bei der Benennung von Schnittstellennamen in Betracht zieht, siehe unten.

RICHTLINIEN

Alle Namen beginnen mit einem Zwei-Zeichen-Präfix, das den Schnittstellentyp kennzeichnet.

Tabelle 1. Zwei-Zeichen-Präfix basierend auf dem Typ der Schnittstelle
Präfix | Beschreibung
en | Ethernet
ib | InfiniBand
sl | IP über serielle Leitung (Slip)
wl | Schnurloses lokales Netzwerk (WLAN)
ww | Schnurloses Weitverkehrsnetz (WWAN)
mc | Management Component Transport Protocol (MCTP)

Das eingebaute udev(7) net_id exportiert die folgenden Geräteeigenschaften:

ID_NET_NAME_ONBOARD=PräfixoNummer, ID_NET_NAME_ONBOARD=PräfixdNummer
    Dieser Name wird basierend auf der numerischen Anordnungsinformation, die durch die Firmware für Geräte auf dem Mainboard angegeben wird, gesetzt. Abhängig von dem Firmware-Typ werden verschiedene Schemata verwandt, wie in nachfolgender Tabelle dargestellt.

    Tabelle 2. Mainboard-Benennungsschema
    Format | Beschreibung
    PräfixoNummer | PCI-Mainboard-Index
    PräfixdNummer | DeviceTree-Alias-Index

    Hinzugefügt in Version 243.

ID_NET_LABEL_ONBOARD=Kennzeichen
    Diese Eigenschaft wird basierend auf der durch die Firmware von Geräten, die auf dem Mainboard sind, gegebenen textuellen Kennzeichnung gesetzt. Dies ist nur für PCI-Geräte verfügbar.

    Hinzugefügt in Version 243.

ID_NET_NAME_MAC=PräfixxAABBCCDDEEFF
    Dieser Name besteht aus dem Präfixbuchstaben x und den 12 hexadezimalen Ziffern der MAC-Adresse. Er ist verfügbar, falls das Gerät über eine konstante MAC-Adresse verfügt. Da dieser Name auf einem Attribut der Karte selbst basiert, bleibt er »stabil«, selbst wenn das Gerät (sogar zwischen Maschinen) verschoben wird, aber ändert sich, wenn die Hardware ersetzt wird.

    Hinzugefügt in Version 243.

ID_NET_NAME_SLOT=Präfix[PDomäne]sSlot[fFunktion][nPort_Name|dGer_Port], ID_NET_NAME_SLOT=PräfixvSlot, ID_NET_NAME_SLOT=PräfixxSlot, ID_NET_NAME_SLOT=Präfix[PDomäne]sSlot[fFunktion][nPort_Name|dGer_Port]bnumber, ID_NET_NAME_SLOT=Präfix[PDomäne]sSlot[fFunktion][nPort_Name|dGer_Port]uPort…[cKonfiguration][iSchnittstelle], ID_NET_NAME_SLOT=Präfix[PDomäne]sSlot[fFunktion][nPort_Name|dGer_Port]vSlot, ID_NET_NAME_SLOT=Präfix[PDomäne]sSlot[fFunktion][nPort_Name|dGer_Port]rSlot,ID_NET_NAME_SLOT=Präfix[PDomäne]sSlot[fFunktion][nPort_Name|dGer_Port]SSfnum
    Diese Eigenschaft beschreibt die Slot-Position. Verschiedene Schemata werden abhängig vom Bus-Typ verwandt. Diese beschreibt die nachfolgende Tabelle. Im Falle von USB-, BCMA- und SR-VIO-Geräten besteht der komplette Name aus dem Präfix, dem PCI-Slot-Kennzeichner und dem USB- oder BCMA- oder SR-VIO-Slot-Kennzeichner. Die ersten zwei werden in der nachfolgenden Tabelle durch »…« angezeigt.

    Tabelle 3. Slot-Benennungsschema
    Format | Beschreibung
    Präfix [PDomäne] sSlot [fFunktion] [nPort_Name | dGer_Port] | PCI-Slot-Nummer
    Präfix vSlot | VIO-Slot-Nummer (IBM PowerVM)
    Präfix XNummer | VIF Schnittstellennummer (Xen)
    … bNummer | Broadcom-Bus- (BCMA) Kernnummer
    … uPort… [cKonfiguration] [iSchnittstelle] | USB-Port-Nummerkette
    …vSlot | SR-VIO-Slot-Nummer
    … rSlot | SR-IOV-Slot-Nummer
    … SSfnum | Hilfs-Unterfunktions- (SF-)Nummer

    Die PCI-Domäne wird nur vorangestellt, wenn sie nicht 0 ist. Alle multifunktionalen PCI-Geräte werden die fFunktion-Nummer im Gerätenamen tragen, einschließlich der Funktion-0-Geräte. Für nicht-multifunktionale Geräte wird die Nummer unterdrückt, falls sie 0 ist. Der Port-Name Port_Name wird verwandt oder die Port-Nummer dGer_Port, falls der Name nicht bekannt ist.

    Für BCMA-Geräte wird die Kernnummer unterdrückt, wenn diese 0 ist.

    Für USB-Geräte wird die komplette Kette von Port-Nummern der Hubs zusammengesetzt. Falls der Name länger als die maximale Anzahl von 15 Zeichen ist, wird der Name nicht exportiert. Die Werte der normalen USB-Konfigurationsnummer 1 und Schnittstellennummer 0 werden unterdrückt.

    Der Name von virtuellen SR-IOV-Geräten basiert auf dem Namen der übergeordneten Schnittstelle, gefolgt von v und der virtuellen Gerätenummer, wobei alle führenden Nullen entfernt werden. Die Busnummer wird ignoriert.

    Der Darsteller von virtuellen SR-IOV-Geräten basiert auf dem Namen der physischen Geräte-Schnittstelle, gefolgt von r und der Anzahl der virtuellen Geräte, die mit dem jeweiligen Darsteller verbunden sind, wobei alle führenden Nullen entfernt werden. Der Name des physischen Ports und die Busnummer werden ignoriert.

    Hilfs-Unterfunktions- (SF-)Netzwerkgeräte, bei denen das übergeordnete Netzwerkgerät ein Hilfsgerät ist, das das Sysfs-Attribut sfnum offenlegt (derzeit mlx5_core SFs), werden basierend auf der zugrundeliegenden PCI-Funktion benannt (der PF oder für VF-SF der PF hinter der VF), wobei eine Endung S und die benutzerdefinierte Unterfunktionsnummer aus sfnum angehängt wird. Dies ist analog zur Benennung der Geräte der virtuellen Funktion SR-IOV mit der Endung v.

    Falls die PCI-Funktion der übergeordneten SF selbst eine virtuelle Funktion SR-IOV (VF-SF) ist, liegt die Wurzel des Namens bei der PF und beide Endungen werden aneinandergehängt, wobei die Endung v vor der Endung S kommt (z.B. »enp193s0f0v0S88«). Die PF, die VF und die SF bilden daher eine stabile, hierrarchische Sequenz, unabhängig von der der VF unterliegenden PCI-Bus/Geräte/Funktionsnummerierung.

    In einigen Konfigurationen kann eine übergeordnete PCI-Bridge eines angegebenen Netzwerk-Controllers einem Steckplatz zugewiesen sein. In diesen Fällen wird diese Geräteeigenschaft nicht erstellt, um Benennungskonflikte zu vermeiden.

    Hinzugefügt in Version 243.

ID_NET_NAME_PATH=PräfixcBuskennung, ID_NET_NAME_PATH=PräfixaLieferantModelliInstanz, ID_NET_NAME_PATH=PräfixiAdressenPort_Name, ID_NET_NAME_PATH=PräfixuPort… ID_NET_NAME_PATH=Präfix[PDomäne]pBussSlot[fFunktion][nphys_Port_Name|dGer_Port], ID_NET_NAME_PATH=Präfix[PDomäne]pBussSlot[fFunktion][nphys_Port_Name|dGer_Port]bNummer, ID_NET_NAME_PATH=Präfix[PDomäne]pBussSlot[fFunktion][nphys_Port_Name|dGer_Port]uPort…[cKonfig][iSchnittstelle],ID_NET_NAME_PATH=Präfix[PDomäne]pBussSlot[fFunktion][nphys_Port_Name|dGer_Port]SSfnum
    Diese Eigenschaft beschreibt den Geräteinstallationsort. Verschiedene Schemata werden abhängig vom Bustyp verwandt, wie in der nachfolgenden Tabelle beschrieben. Für BCMA- und USB-Geräte muss die PCI-Pfadinformation bekannt sein und der vollständige Name besteht aus dem Präfix, der PCI-Slot-Kennzeichnung und dem USB- oder BCMA-Ort. Die ersten zwei Teile werden in der nachfolgenden Tabelle durch »…« angezeigt.

    Tabelle 4. Pfadbenennungsschema
    Format | Beschreibung
    Präfix cBuskennung | CCW- oder gruppierte CCW-Gerätekennzeichner
    Präfix aHändler Modell iInstanz | ACPI-Pfadnamen für ARM64-Plattformgeräte
    Präfix iAdresse nPort-Name | Netdevsim (simulierte Netzwerkgeräte) Gerätenummer und Port-Name
    Präfix [PDomäne] pBus sSlot [fFunktion] [nphys_Port_Name | dGer_Port] | Geographischer PCI-Ort
    … bNummer | Broadcom-Bus- (BCMA) Kernnummer
    … uPort… [cKonfiguration] [iSchnittstelle] | USB-Port-Nummerkette
    … SSfnum | Hilfs-Unterfunktions- (SF-)Nummer

    CCW- und gruppierte CCW-Geräte gibt es in IBM-System-Z-Großrechnern. Alle einleitenden Nullen und Punkte werden unterdrückt.

    Für PCI-, BCMA- und USB-Geräte werden die gleichen Regeln wie oben für Slot-Namen beschrieben verwandt.

    Hinzugefügt in Version 243.

GESCHICHTE

Das folgende »Benennungsschema« wurde definiert (dies kann zum Zeitpunkt des Systemstarts mittels des oben dargestellten Kernelbefehlszeilenschalters net.naming_scheme= ausgewählt werden):

v238
    Dies ist das in Systemd 238 implementierte Benennungsschema.

    Hinzugefügt in Version 243.

v239
    Die Benennung für mit SR-IOV und NPAR erstellte virtuelle Netzwerkgeräte und für Geräte, deren PCI-Netzwerk-Controller keine Slot-Nummer zugeordnet ist, wurde geändert.

    Virtuelle SR-IOV Geräte werden basierend auf der übergeordneten Schnittstelle mit einer Endung »vPort« benannt, wobei Port die virtuelle Gerätenummer ist. Vorher wurden solche virtuellen Geräte benannt, als ob sie komplett unabhängig wären.

    Das neunte und spätere virtuelle NPAR-Geräte folgen dem für die ersten acht NPAR-Partitionen verwandten Benennungsschema. Früher wurden solche Geräte nicht umbenannt und die Vorgabe des Kernels (»ethN«) wurde verwandt.

    Es werden auch Namen für PCI-Geräte erstellt, bei denen der PCI-Netzwerk-Controller selbst keine zugeordnete Slot-Nummer hat, aber eines seiner übergeordneten Geräte hat eine. Früher wurden solche Geräte nicht umbenannt und die Vorgabe des Kernels wurde verwandt.

    Hinzugefügt in Version 243.

v240
    Das Präfix »ib« und gleichbleibende Namen für Infiniband-Geräte werden eingeführt. Früher wurden solche Geräte nicht umbenannt.

    Das ACPI-Indexfeld (in ID_NET_NAME_ONBOARD= verwandt) wird jetzt auch genutzt, falls sein Wert 0 ist.

    Es wurde eine neue Benennungsrichtlinie NamePolicy=keep eingeführt. Mit dieser Richtline wird das Netzwerkgerät nicht erneut umbenannt, falls sein Name bereits im Anwendungsraum (user space) gesetzt wurde. Früher wurde diese Bennungsrichtlinie implizit angewandt und jetzt muss sie explizit erbeten werden. Effektiv bedeutet dies, dass Netzwerkgeräte entsprechend ihrer Konfiguration umbenannt werden, falls keep nicht als Benennungsrichtlinie in der .link-Datei festgelegt ist, auch wenn sie bereits umbenannt worden sind. Siehe systemd.link(5) für eine Beschreibung von NamePolicy=.

    Hinzugefügt in Version 243.

v241
    MACAddressPolicy=persistent wurde erweitert, um MAC-Adressen basierend auf dem Gerätenamen zu setzen. Früher basierten Adressen nur auf ID_NET_NAME_*-Attributen, was bedeutete, dass für virtuelle Geräte niemals Schnittstellennamen erstellt wurden. Jetzt bekommen die meisten Geräte dauerhafte Adressen, insbesondere auch Bridges.

    Beachten Sie: Wenn der Anwendungsraum keine MAC-Adresse für ein Bridge-Gerät setzt, dann wird der Kernel anfänglich eine zufällige Adresse zuweisen und diese dann ändern, wenn das erste Gerät zu der Bridge enslaved wird. Mit dieser Änderung der Benennungsrichtlinie erhalten Bridges eine dauerhafte MAC-Adresse basierend auf dem Bridge-Namen anstatt des ersten Gerätes, das enslaved ist.

    Hinzugefügt in Version 243.

v243
    Unterstützung für die Umbenennung von Netdevsim-Geräten (simulierten Netzwerkgeräten) wurde hinzugefügt. Früher wurden diese Geräte nicht umbenannt.

    Früher wurde der zweibuchstabige Schnittstellentyppräfix ID_NET_LABEL_ONBOARD= vorangestellt. Dies ist jetzt nicht mehr der Fall.

    Hinzugefügt in Version 243.

v245
    Wenn systemd-nspawn(1) den Namen für die Rechnerseite des mit --network-veth vom Container-Namen erstellten Netzwerkschnittstellennamens ableitet, schnitt es bisher das Ergebnis nach 15 Zeichen ab, falls es länger war (da dies die maximale Länge für Netzwerkschnittstellennamen ist). Ab jetzt werden die letzten 4 Zeichen auf einen 24-Bit-Hash-Wert des vollständigen Schnittstellennamens gesetzt, falls der Schnittstellenname länger als 15 Zeichen wäre. Auf diese Art sollten Schnittstellennamenkollisionen zwischen mehreren, ähnlich benannten Containern (die sich nur in der Containernamen-Endung unterscheiden) weniger wahrscheinlich werden — sie sind allerdings weiterhin möglich, da der 24-Bit-Hash-Wert sehr klein ist.

    Hinzugefügt in Version 245.

v247
    Wenn ein PCI-Steckplatz einer PCI-Bridge zugeordnet ist, die über mehrere nachgeordnete Netzwerk-Controller verfügt, dann könnte der gleiche Wert der Eigenschaft ID_NET_NAME_SLOT für alle diese Controller abgeleitet werden. Dadurch können Benennungskonflikte auftreten, falls die Eigenschaft als der Gerätename ausgewählt wird. Jetzt wird diese Situation erkannt und keine Eigenschaft ID_NET_NAME_SLOT erstellt.

    Hinzugefügt in Version 247.

v249
    PCI-Hotplug-Positionsnamen für den S390-PCI-Treiber sind hexadezimale Darstellungen des Geräteattributs function_id. Dieses Attribut wird nun dazu verwandt, ID_NET_NAME_SLOT zu bauen. Vorher wurden alle Positionsnamen als dezimale Zahlen ausgewertet, was entweder zu einem false-Wert der Eigenschaft ID_NET_NAME_SLOT führen konnte oder zu gar keinem.

    Einige Firmware- und Hypervisor-Implementierungen berichten unrealistisch hohe Werte für den eingebauten Index. Um die Erstellung von gefälschten eingebauten Schnittstellennamen zu vermeiden, wurden Indexwerte größer als 16381 ¹⁴-1) ignoriert. Für S390-PCI-Geräte sind Indexwerte bis 65535 (2¹⁶-1) gültig. Um dies zu berücksichtigen, wurde diese Begrenzung auf 65535 erhöht.

    Die udev(7)-Regel NAME= ersetzt »:«, »/« und »%« durch einen Unterstrich (»_«) und lehnt Zeichenketten ab, die nur Ziffern enthalten.

    Hinzugefügt in Version 249.

v250
    Es wurde ein Namensschema für Xen-Netfront-»vif«-Schnittstellen, basierend auf der gästeseitigen VIF-Nummerngruppe aus der Xen-Konfiguration (oder die Schnittstellen mit Index in AWS EC2), hinzugefügt.

    Hinzugefügt in Version 250.

v251
    Seit Version v247 setzen wir nicht mehr ID_NET_NAME_SLOT, falls wir erkennen, dass ein PCI-Gerät, das einem PCI-Steckplatz zugeordnet ist, eine PCI-Bridge ist, da dies einen Benennungskonflikt hervorrufen würde, wenn es mehrere Kind-Geräte auf dieser Bridge gibt. Jetzt wird dies nicht mehr so strikt gesehen und wir werden die Steckplatz-Informationen verwenden, um den Namen darauf basierend zu erstellen, aber nur, falls das PCI-Gerät mehrere Funktionalitäten hat. Dies ist sicher, da eine separate Funktionsnummer ein Teil des Gerätenamens für Geräte mit mehreren Funktionen ist. Beachten Sie, dass diese Änderung in v255 zurückgenommen wurde, siehe unten.

    Hinzugefügt in Version 251.

v252
    Benennungsschema für Plattformgeräte mit Devicetree-Alias hinzugefügt.

    Hinzugefügt in Version 252.

v253
    Setzt ID_NET_NAME_PATH für nicht über einen PCI-Bus verbundene USB-Geräte.

    Hinzugefügt in Version 253.

v254
    Für virtuelle SR-IOV-Geräte-Darsteller wurde die Benennung geändert, optional bei der Kompilierung setzbar. Die Endung »rSlot« wurde hinzugefügt, um virtuelle SR-IOV-Geräte-Darsteller zu unterscheiden, die an einer einzelnen physischen Geräteschnittstelle hängen. Aufgrund eines Fehlers war dieses Schema in Systemd Version 254 nicht das Standardschema.

    Hinzugefügt in Version 255.

v255
    Die Benennung wurde für virtuelle SR-IOV-Gerätedarsteller geändert, um standardmäßig die in v254 eingeführte Änderung zu aktivieren.

    Falls erkannt wird, dass einem Slot zugeordnetes PCI-Gerät eine PCI-Brücke ist, wird nicht mehr ID_NET_NAME_SLOT gesetzt. Dies nimmt eine Änderung zurück, die in v251 eingeführt wurde.

    Hinzugefügt in Version 255.

v257
    Die PCI-Slot-Nummer wird jetzt aus der Sysfs-Datei firmware_node/sun gelesen.

    Das auf Devicetree-Alias basierende Namenschema wurd erweitert, um Alias für einzelne Schnittstellen von Controllern mit mehreren Ports zu unterstützen.

    Hinzugefügt in Version 257.

v258
    Wenn keine Umbenennung angefordert wird, ist die Eigenschaft ID_NET_NAME jetzt zu der Eigenschaft INTERFACE äquivalent.

    Hinzugefügt in Version 258.

v259
    Das auf Devicetree-Alias basierende Namenschema wurd erweitert, um WLAN-Geräte zu unterstützen.

    Hinzugefügt in Version 259.

v260
    MCTP-Schnittstellen werden jetzt mit dauerhafte Namen dem Präfix mc zugewiesen.

    Hinzugefügt in Version 260.

v261
    Für Hilfs-Unterfunktionen- (SF-)Netzwerkgeräte (wie »mlx5_core«) werden jetzt stabile Namen erzeugt. Der Name wird aus dem Pfad der übergeordneten physischen PCI-Funktion mit der Endung »Ssfnum« gebildet, wobei sfnum die Benutzer-definierte SF-Nummer ist (der Wert, der an devlink port add … sfnum N übergeben wurde, durch den Kernel als Sysfs-Attribut auf dem Hilfsgerät offengelegt). Dies ist zu der für virtuelle Funktionen SR-IOV verwandten Endung »vN« analog; für SFs, die auf SR-IOV VFs betrieben werden (VF-SF), werden die zwei Endungen zusätzlich zum Basisnamen der PF aneinandergehängt.

    Hinzugefügt in Version 261.

Beachten Sie, dass latest zur Kennzeichnung des neusten bekannten Schemas (für diese konkrete Version von Systemd) verwandt werden kann.

BEGRENZUNG DER VERWENDUNG BESTIMMTER SYSFS-ATTRIBUTE

Beim Erstellen von Namen für Netzwerkkarten benutzen einige Benennungsschemata Daten, die aus vom Kernel befüllten Sysfs stammen. Dies bedeutet, das sich der Netzwerkkartenname immer noch ändern kann, wenn eine neue Kernelversion ein neues Sysfs-Attribut hinzufügt, obwohl ein bestimmtes Benennungschema aus udev(7) gewählt wurde. Falls beispielsweise der Kernel beginnt, phys_port_name zu setzen, wird udev(7) die Endung »nphys_port_name« an den Gerätenamen anhängen.

ID_NET_NAME_ALLOW=LOGISCH
    Diese udev(7)-Eigenschaft setzt eine Rückfallrichtlinie zum Lesen eines Sysfs-Attributs. Falls auf 0 gesetzt wird udev(7) standardmäßig kein Sysfs-Attribut lesen, außer es wurde explizit als erlaubt aufgelistet, siehe unten. Falls auf 1 gesetzt, kann udev(7) jedes Sysfs-Attribut verwenden, außer es wurde explizit verboten. Die Vorgabe ist 1.

    Hinzugefügt in Version 256.

ID_NET_NAME_ALLOW_Sysfsattr=LOGISCH
    Diese udev(7)-Eigenschaft sagt explizit aus, dass udev(7) das angegebene Sysfsattr verwenden soll, wenn es den Dateinamen zusammensetzt.

    Hinzugefügt in Version 256.

Mit diesen Optionen können Benutzer eine Liste der erlaubten oder verbotenen Sysfs-Attribute setzen. Um eine List der erlaubten Attribute zu setzen, muss der Benutzer ID_NET_NAME_ALLOW=0 für das Gerät setzen und dann alle erlaubten Attribute mit den Optionen ID_NET_NAME_ALLOW_Sysfsattr=1 auflisten. Im Falle der Liste der verbotenen Attribute muss der Benutzer eine Liste der verbotenen Attribute mit den Optionen ID_NET_NAME_ALLOW_Sysfsattr=0 bereitstellen.

BEISPIELE

Beispiel 1. Verwendung Udevadms test-builtin zur Anzeige von Geräteeigenschaften

    $ udevadm test-builtin net_id /sys/class/net/enp0s31f6
    …
    Verwendung des Vorgabe-Schnittstellen-Benennungsschemas 'v243'.
    ID_NET_NAMING_SCHEME=v243
    ID_NET_NAME_MAC=enx54ee75cb1dc0
    ID_OUI_FROM_DATABASE=Wistron InfoComm(Kunshan)Co.,Ltd.
    ID_NET_NAME_PATH=enp0s31f6
    …

Beispiel 2. PCI-Ethernet-Karte mit Firmware-Index »1«

    ID_NET_NAME_ONBOARD=eno1
    ID_NET_NAME_ONBOARD_LABEL=Ethernet Port 1

Beispiel 3. PCI-Ethernet-Karte in einem Slot mit Firmware-Indexnummer

    # /sys/devices/pci0000:00/0000:00:1c.3/0000:05:00.0/net/ens1
    ID_NET_NAME_MAC=enx000000000466
    ID_NET_NAME_PATH=enp5s0
    ID_NET_NAME_SLOT=ens1

Beispiel 4. PCI-Ethernet-Multifunktionskarte mit 2 Ports

    # /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/enp2s0f0
    ID_NET_NAME_MAC=enx78e7d1ea46da
    ID_NET_NAME_PATH=enp2s0f0

    # /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.1/net/enp2s0f1
    ID_NET_NAME_MAC=enx78e7d1ea46dc
    ID_NET_NAME_PATH=enp2s0f1

Beispiel 5. PCI-WLAN-Karte

    # /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlp3s0
    ID_NET_NAME_MAC=wlx0024d7e31130
    ID_NET_NAME_PATH=wlp3s0

Beispiel 6. PCI-IB-Host-Adapter mit 2 Ports

    # /sys/devices/pci0000:00/0000:00:03.0/0000:15:00.0/net/ibp21s0f0
    ID_NET_NAME_PATH=ibp21s0f0

    # /sys/devices/pci0000:00/0000:00:03.0/0000:15:00.1/net/ibp21s0f1
    ID_NET_NAME_PATH=ibp21s0f1

Beispiel 7. Eingebautes USB-3G-Modem

    # /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.6/net/wwp0s29u1u4i6
    ID_NET_NAME_MAC=wwx028037ec0200
    ID_NET_NAME_PATH=wwp0s29u1u4i6

Beispiel 8. USB-Android-Telephon

    # /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/net/enp0s29u1u2
    ID_NET_NAME_MAC=enxd626b3450fb5
    ID_NET_NAME_PATH=enp0s29u1u2

Beispiel 9. s390-gruppierte CCW-Schnittstelle

    # /sys/devices/css0/0.0.0007/0.0.f5f0/group_device/net/encf5f0
    ID_NET_NAME_MAC=enx026d3c00000a
    ID_NET_NAME_PATH=encf5f0

Beispiel 10. Setzen einer Liste erlaubter Attribute zum Lesen von Sysfs-Attributen zur Benennung von Netzwerkkarten

    /etc/udev/hwdb.d/50-net-naming-allowlist.hwdb
    net:naming:drvirtio_net:*
      ID_NET_NAME_ALLOW=0
      ID_NET_NAME_ALLOW_ACPI_INDEX=1
      ID_NET_NAME_ALLOW_ADDR_ASSIGN_TYPE=1
      ID_NET_NAME_ALLOW_ADDRESS=1
      ID_NET_NAME_ALLOW_ARI_ENABLED=1
      ID_NET_NAME_ALLOW_DEV_PORT=1
      ID_NET_NAME_ALLOW_FUNCTION_ID=1
      ID_NET_NAME_ALLOW_IFLINK=1
      ID_NET_NAME_ALLOW_INDEX=1
      ID_NET_NAME_ALLOW_LABEL=1
      ID_NET_NAME_ALLOW_PHYS_PORT_NAME=1
      ID_NET_NAME_ALLOW_TYPE=1

Beispiel 11. Setzen einer Liste verbotener Attribute, so dass die angegebenen Sysfs-Attribute ignoriert werden

    /etc/udev/hwdb.d/50-net-naming-denylist.hwdb
    net:naming:drvirtio_net:*
      ID_NET_NAME_ALLOW=1
      ID_NET_NAME_ALLOW_DEV_PORT=0
      ID_NET_NAME_ALLOW_PHYS_PORT_NAME=0

SIEHE AUCH

udev(7), udevadm(8), systemd-udevd.service(8), Vorhersagbare Netzwerkschnittstellennamen[1], systemd-nspawn(1)

ANMERKUNGEN

1.  Vorhersagbare Netzwerkschnittstellennamen
    https://systemd.io/PREDICTABLE_INTERFACE_NAMES

ÜBERSETZUNG
Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 (https://www.gnu.org/licenses/gpl-3.0.html) oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer (debian-l10n-german@lists.debian.org).