# Netzwerk Geräte Name wechselt immer wieder ...

## alexander_ro

Hi,

mein Server hat vier Netzwerkschnittstellen von denen ich zur Zeit nur eine benutze. Jetzt habe ich das Problem das zwar nicht nach jedem booten aber trotzdem recht häufig die Devicenamen der Netzwerkschnittstelle anders vergeben werden. Der Name wechselt zwischen "enp8s0f0" und "enp9s0f0" sehr unpraktisch das ist.

Mit dem alten System für Geräte Namen hatte man Probleme wenn man die Hardware eines Systems verändert hat. Zugegeben nicht perfekt. Mit dem neuen System hat man Probleme wenn man die Hardware verändert und wenn man sie nicht verändert. Es fällt mir schwer da die Verbesserung zu erkennen.   :Rolling Eyes: 

Wie löst Ihr den sowas?

Viele Grüße

Alexander

----------

## py-ro

Das deutet daraufhin, dass ein PCI Gerät mal erkannt und mal nicht erkannt wird. Ich würde das mal Untersuchen.

Ansonsten kannst das neue Schema natürlich abschalten oder eigene Regeln schreiben.

Persönlich bevorzuge ich eigene Regeln, die Interfaces bekommen dann Namen entsprechend Ihrer Verwendung, wie ifint, ifext oder ifmgmt.

Bye

Py

----------

## alexander_ro

Die sind alle fest auf dem Mainboard verbaut. Es werden immer zwei Netzwerkgeräte erkannt.

Das Problem läßt sich dann lösen in dem ich nur in der Konfiguration den Namen des Device ändere. Ich muss dazu kein Netzwerkkabel umstecken. Müsste ich nicht wenn es einmal die eine Karte ist und einmal die andere nicht auch der Stecker vom Netzwerkkabel umgesteckt werden. Die sind doch sicher fest mit dem jeweiligen Device verdrahtet.

----------

## mrsteven

Ich habe ein paar udev-Rules dafür:

```
# Ethernet port

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="fe:ed:de:ad:be:ef", NAME="lan"

# Wireless lan

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:11:22:33:44:55", NAME="wlan"
```

Bei ATTR{address} kommt dann einfach die MAC-Adresse des betreffenden Interfaces hin, siehe Ausgabe von ifconfig. Die ist (solange man sie nicht manuell ändert) sowieso eindeutig.

Das ist mit das erste, was ich nach einer Neuinstallation mache, Namen wie enp00p kann sich ja keiner merken.  :Wink:  Abgesehen davon ist es für meine Anwendungszwecke unerheblich, in welchem PCI-Slot jetzt genau die Karte steckt.

----------

## alexander_ro

Was mich nur wundert ist das sind keine PCI Karten die umgesteckt wurden. Die Netzwerkkarten bzw. die Chips die halt normal auf denen drauf sind sind hier direkt auf dem Mainboard verlötet. Da kann man nichts umstecken und trotzdem ändern sich die Namen. Seltsame Dinge gehen hier vor ...   :Confused: 

Ich probiere das mal mit der MAC Adresse das klingt viel versprechend. Würde es eigentlich stören wenn man hier auch Regeln einträgt für MAC Adressen die nicht auf diesem System vorhanden sind und den gleichen Namen benutzen?

Hintergrund ist das ich öfter mal die System Images zwischen verschiedenen Rechner um tausche und halt dann gerade Netzwerk möglichst ohne was ändern zu müssen (vergisst man gerne) wieder funktionieren soll.

----------

## toralf

Vergleiche doch mal die dmesg  Meldungen - offensichtlich ein timeing - Problem beim Initialisieren der Netzwerkdevices. Ich z.B. verwende auf meinem gehärteten Gentoo :

```
sudo dmesg --notime > dmesg-`uname -r`; sudo lsmod | sort > lsmod-`uname -r`
```

dafür.

----------

## alexander_ro

Das mit den Regeln für verschiedene System in einer Datei scheint zu funktionieren. Habe es gerade mal ausprobiert.

@toralf: Wenn es ein Timing Problem wäre dann würde es aber doch nicht reichen nur die konfiguration zu ändern. Ich müsste doch dann auch das Netzwerkkabel umstecken? Wie könnte ich ein Timingproblem beheben?

----------

## toralf

 *alexander_ro wrote:*   

> Wie könnte ich ein Timingproblem beheben?

 Erst mal herausfinden, was die Ursache ist - dann evtl. auf der Linux Kernel Mailing Liste nachfragen, so würde ich das machen.

----------

## alexander_ro

Ich habe das schon umgebaut auf die Udev Regeln. Aber ich kann die ja nochmal auskommentieren und schauen ob ich die zwei Zustände mal erwische. Das ist nicht so einfach weil ich keine Ahnung habe wann das wieder passiert. Ach die Kernelliste ich weis nu nicht ...

----------

## ChrisJumper

Nun wenn deine beiden Karten zum Beispiel den selben Treiber benötigen, dann kommt es da ganz natürlich zu so einem Zeitproblem. Das kann ganz viele unterschiedliche Zustände haben, da brauchst du dir wirklich keine sorgen zu machen. Eben genau dafür sind die UDEV Regeln ja da.

----------

## alexander_ro

Ja die haben den selben Treiber. Aber war es nicht genau das was dieses neue Namenssystem das da erfunden wurde verhindern sollte?

----------

## ChrisJumper

Nun ja da hast du auch wieder recht:

dort wurde das ja jetzt so beschrieben:

 *Quote:*   

> 1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
> 
> 2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
> 
> 3. Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
> ...

 

Demnach müsste ja Punkt 3 bei dir zutreffen. Ich bin mir da jetzt auch nicht sicher und würde meine Hand dafür ins Feuer legen, aber vielleicht ist es ein altes IRQ Problem,  mit den verbauten PCI Karten. Kannst ja mal schauen ob sich der IRQ verändert der Karte veränderte wenn sich der Name ändert.

```
$ cat /proc/interrupts
```

Also aber auch mit "lspci" schauen welche pci-Adresse der Netzwerkkarte zugewiesen wurde. Auseinanderhakten kannst du die ja physisch und an der Mac-adresse.

----------

## alexander_ro

Ich habe jetzt die verschiedenen Dateien mit dem Muster dieses Merkwürdigen Kommandos erzeugt. Das sudo musste ich entfernen so Teufelszeug benutze ich nicht ...   :Wink: 

```

dmesg --notime > dmesg-`uname -r`; lsmod | sort > lsmod-`uname -r`

```

Bei lsmod gibt es keinen Unterschied. Da die Dateien sehr groß sind auch der diff vom dmesg hier nur mal der Auszug in dem man die Namen und MAC Adressen erkennen kann.

```

725,737c696,707

< e1000e 0000:08:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode

< i801_smbus 0000:00:1f.3: SMBus using PCI interrupt

< e1000e 0000:08:00.0 eth0: (PCI Express:2.5GT/s:Width x4) 00:23:54:1b:2a:4a

< e1000e 0000:08:00.0 eth0: Intel(R) PRO/1000 Network Connection

< e1000e 0000:08:00.0 eth0: MAC: 5, PHY: 5, PBA No: FFFFFF-0FF

< e1000e 0000:08:00.1: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode

< e1000e 0000:08:00.1 eth1: (PCI Express:2.5GT/s:Width x4) 00:23:54:1b:2a:4b

< e1000e 0000:08:00.1 eth1: Intel(R) PRO/1000 Network Connection

< e1000e 0000:08:00.1 eth1: MAC: 5, PHY: 5, PBA No: FFFFFF-0FF

< e1000e 0000:08:00.1 enp8s0f1: renamed from eth1

< systemd-udevd[2022]: renamed network interface eth1 to enp8s0f1

< e1000e 0000:08:00.0 enp8s0f0: renamed from eth0

< systemd-udevd[2021]: renamed network interface eth0 to enp8s0f0

---

> e1000e 0000:09:00.0: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode

> e1000e 0000:09:00.0 eth0: (PCI Express:2.5GT/s:Width x4) 00:23:54:1b:2a:4a

> e1000e 0000:09:00.0 eth0: Intel(R) PRO/1000 Network Connection

> e1000e 0000:09:00.0 eth0: MAC: 5, PHY: 5, PBA No: FFFFFF-0FF

> e1000e 0000:09:00.1: Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode

> e1000e 0000:09:00.1 eth1: (PCI Express:2.5GT/s:Width x4) 00:23:54:1b:2a:4b

> e1000e 0000:09:00.1 eth1: Intel(R) PRO/1000 Network Connection

> e1000e 0000:09:00.1 eth1: MAC: 5, PHY: 5, PBA No: FFFFFF-0FF

> e1000e 0000:09:00.1 enp9s0f1: renamed from eth1

> systemd-udevd[2023]: renamed network interface eth1 to enp9s0f1

> e1000e 0000:09:00.0 enp9s0f0: renamed from eth0

> systemd-udevd[2022]: renamed network interface eth0 to enp9s0f0

```

<edit>

@ChrisJumper: Ja sieht mir auch nach 3. aus das wäre ja soweit auch noch richtig. Ich habe nur leider vorhin vergessen nach dem IRQ zu schauen. Steht der nicht auch irgendwo in den dmesg Ausgaben?

</edit>

----------

## firefly

Also der kernel selbst weißt den beiden Netzwerkkarten immer den gleichen Namen zu

In beiden Ausgaben von dmesg ist es immer:

eth0: Mac: 00:23:54:1b:2a:4a

eth1: Mac: 00:23:54:1b:2a:4b

-> Die beiden Karten werden immer in der gleichen reihenfolge initialisiert.

Erst wenn über udev die devices umbenannt werden sollen kommt unterschiedliche namen raus

eth0: enp8s0f0

eth1: enp8s0f1

bzw

eth0: enp9s0f0

eth1: enp9s0f1

Der Einzige unterschied ist das sich die Zahl an nach "enp" sich verändert.

Falls du das alte namensschema (ethX) haben möchtest kannst du das erreichen wenn du dem kernel beim starten folgenden zusätzlichen parameter mit gibts:

 *Quote:*   

> net.ifnames=0

 

----------

## alexander_ro

Wohl wahr.

Die 08 oder 09 ist die PCI-ID da die der Kernel nicht beachtet zum benennen hat der damit kein Problem aber der Kernel ist es der die unterschiedlichen IDs den Netzwerk Chips zuweist.

Ich habe das jetzt wie vorgeschlagen wurde mit der MAC Adresse gelöst. Das machten die bei Debian auch so und mit der Methode hatte ich nie Probleme das scheint mir daher eine gute Lösung zu sein. Als Namen benutze ich halt eth0 und eth1 das ergibt dann das gleiche.

<edit>

Ähm noch eine Frage: Die Umbenennung des Devices von eth0 nach enp... macht doch udev wieso muss ich das dann dem Kernel sagen. Ich hätte jetzt angenommen das muss man in der udev Konfiguration angeben.

</edit>

----------

## firefly

 *alexander_ro wrote:*   

> 
> 
> <edit>
> 
> Ähm noch eine Frage: Die Umbenennung des Devices von eth0 nach enp... macht doch udev wieso muss ich das dann dem Kernel sagen. Ich hätte jetzt angenommen das muss man in der udev Konfiguration angeben.
> ...

 

Der kernel selber wertet AFAIK diesen parameter nicht selbst aus. Aber andere Programme, die recht früh im boot prozess gestartet werden (und damit unter umständen kein zugriff auf dateien auf einer HDD haben) können auf diese parameter zugreifen.

Und udev tut dies AFAIK so.

----------

## alexander_ro

Kling Einleuchtend ...

Danke euch für die Hilfe ich lasse das jetzt so mit der udev Regel und der MAC-Adresse. Irgendwie erkennt das udev auch weil es mit dieser Regel das umbenennen einfach sein läßt. Zumindest erscheint die zugehörige Meldung nicht mehr im syslog.

----------

## firefly

 *alexander_ro wrote:*   

> 
> 
> Danke euch für die Hilfe ich lasse das jetzt so mit der udev Regel und der MAC-Adresse. Irgendwie erkennt das udev auch weil es mit dieser Regel das umbenennen einfach sein läßt. Zumindest erscheint die zugehörige Meldung nicht mehr im syslog.

 

Ist so gedacht dass eigene regeln die default überschreiben können. Steht auch so unter dem Punkt "I don't like this, how do I disable this?"

 *http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ wrote:*   

> You basically have four options:
> 
>     You create your own manual naming scheme, for example by naming your interfaces "internet0", "dmz0" or "lan0". For that create your own udev rules file and set the NAME property for the devices. Make sure to order it before the default policy file, for example by naming it /etc/udev/rules.d/70-my-net-names.rules
> 
> 

 

----------

## Josef.95

Jo, und wahrscheinlich ist es besser nicht den selben Interface-Namen via udev.rule zu vergeben, wie der Kernel ihn auch nutzt.

Sprich wenn man via udev einen Namen vergibt, dann sollte der möglichst vom Kernel/Treiber vergebenen abweichen (also statt eth0 dann zb etwas wie lan0).

Siehe dazu zb auch im https://www.kernel.org/doc/htmldocs/device-drivers/API-device-rename.html

----------

## alexander_ro

Das haben die nicht wirklich erreicht?

 *Quote:*   

> 
> 
> stable network interface names for all local Ethernet
> 
> 

 

Wo stehen eigentlich diese default Regeln weil bei mir alle Verzeichnisse unter /etc/udev leer sind. Sonst hätte ich einfach diese Regel ausgebaut.

Ich benenne die Geräte ja genauso wie es der Kernel tun würde also ist es ja eigentlich kein konflikt. Es gibt auch keine Meldung mehr das irgendwas umbenannt wird. Das mit dem Kernel Parameter gefällt mir halt nicht so gut weil es vermutlich wieder Probleme macht mit der automatischen Generierung der grub.conf.

Ich habe in irgendeiner Fachzeitschrift gelesen das jemand eine alternative zu udev Entwickelt. Wäre das vielleicht eine Option?

----------

## Josef.95

 *alexander_ro wrote:*   

> Ich benenne die Geräte ja genauso wie es der Kernel tun würde [...]

 

Ja, und genau das sollte man möglichst nicht tun.  Wenn du via udev.rule einen Namen vergibst kannst du nahezu jeden x-beliebigen Namen frei wählen, nur auf den Namen den der Kernel/Treiber auch vergeben würde sollte man nicht ummappen.

Ich mache es hier ebenfalls wie schon von mrsteven hier vorgeschlagen, das sollte aufgrund des eindeutigen Bezeichners einwandfrei funktionieren (hier tut es das).

----------

