Netzwerkadapter - Namen wechseln nach Reboot

[MaLe]

Hallo,

PVE 7.3-6 - wir haben hier einen Server mit Asus Board auf AMD Epyc Basis mit Dual-Gigabit Ethernet onBaord (intel i350). Die beiden Adapter werden mit Namen "eno1" und "eth1" versehen. "eno1" soll verwendet werden und ist als Slave Port der vmbr0 Bridge zugewiesen. Folgendes Problem tritt auf: Bei jedem Boot-Vorgang werden die beiden Adapter getauscht, so dass das Netzwerkabel umgesteckt werden muss. Zudem wird in der GUI des PVE noch ein Adapter "eth0" mit aufgeführt, der gar nicht vorhanden ist. Bin gerade total verwirrt, so ein Problem hatten wir bisher noch nicht. Gibt es da Änderungen im Zuge der letzten Updates?

ip a -> ergibt folgende Ausgabe:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000 link/ether 04:42:1a:1d:a5:22 brd ff:ff:ff:ff:ff:ff altname enp129s0f0 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 04:42:1a:1d:a5:23 brd ff:ff:ff:ff:ff:ff altname enp129s0f1 4: enx068a1f482172: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 06:8a:1f:48:21:72 brd ff:ff:ff:ff:ff:ff 5: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 04:42:1a:1d:a5:22 brd ff:ff:ff:ff:ff:ff inet 192.168.25.20/24 scope global vmbr0 valid_lft forever preferred_lft forever inet6 fe80::642:1aff:fe1d:a522/64 scope link valid_lft forever preferred_lft forever

 

[mr44er]

Zudem wird in der GUI des PVE noch ein Adapter "eth0" mit aufgeführt, der gar nicht vorhanden ist.

Wenn du sicher bist, dass es den wirklich nicht (mehr) gibt, kannst du den via GUI problemlos löschen + apply. Müssten dann sofort verschwinden, möglich wäre dann, dass sich dein Problem damit auch auflöst.

Mich wundert nur, dass ein Chip intel i350 zwei Namen hervorbringt, aber ich habe die 'neue' Benennung eh nicht verstanden, denn die Unterscheidung zwischen onboard/non-onboard haut nicht immer hin.

Idee1: Kannst du mal im BIOS durchspicken, ob es da netzwerktechnisch eine auto-Einstellung gibt, die man besser auf manuell stellt?
Idee2: 4: enx068a1f482172: Ist das eine USB-Nic? Wenn ja könnte die die Würfelung triggern, wenn nein siehe Idee1

 

[Dunuin]

Oder halt gleich mit den hardware-gebundenen Namen "enp129s0f0" und "enp129s0f1" arbeiten. Die sollten ja nach jedem Boot gleich sein, sofern du keine Hardware hinzugefügt/entfernt hast.

 

[mr44er]

Oder halt gleich mit den hardware-gebundenen Namen "enp129s0f0" und "enp129s0f1" arbeiten. Die sollten ja nach jedem Boot gleich sein, sofern du keine Hardware hinzugefügt/entfernt hast.

Die sehe ich ja jetzt erst, na klar.

@MaLe
Wieso sind da eigentlich altnames? Lief das System mal auf anderer Hardware oder mit anderen NICs? Lösch mal alle NICs, also eth0,1 und eno0,1. Du solltest danach instantan die 'richtigen' Namen der NICs zur Verfügung haben und das Problem damit erledigen können.

 

[MaLe]

Vielen Dank für eure Antworten und Vorschläge. Ich werde zunächst den Ansatz mit dem Löschen der NICs testen und hoffe dann die richtigen Namen zu bekommen. Das Gerät lief nie auf anderer Hardware, wurde neu installiert direkt von ISO. Bin mir aber nicht sicher ob die Tauscherei erst nach dem Update auftrat, ich meine ja. Wie auch immer ist die Benennung total Banane.

Zudem ist es so, dass bei den letzten Servern die beiden OnBoard 1G mit enoX benannt wurden, während die zugesteckten Dual-10G Ports bei enpXsXfX blieben. Das Schema enpXsXfX wäre mir sogar lieber, hat man sich inzwischen ja dran gewöhnt.

Ich werde über das Ergebnis berichten.

 

[Dunuin]

Eigentlich sollte PVE immer das "Predictable Naming Scheme" wie enpXsXfX nutzen. Das ist seit ein paar Jahren der Standard mit Systemd, außer man ändert da selbst was, wenn man das alte Schema mit eth0 und Co nutzen möchte. Hast du vielleicht mal ein Script laufen lassen oder zusätzliche Pakete installiert, die da vielleicht dran rumgebastelt haben?

Wenn dir enpXsXfX sowieso lieber ist, dann trag halt "enp129s0f0" und "enp129s0f1" in deine "/etc/network/interfaces" ein.

 

[MaLe]

Danke für die Rückmeldung. Tatsächlich haben die Maßnahmen nicht funktioniert. Die Adapter in der GUI zu löschen funktionierte nur für nicht vorhandene Adapter und sich dann auf die altnames (enp129s0f0/enp129s0f1) in der /etc/network/interfaces zu beziehen, endet im Verlust der Konnektivität. Die Bridge kommt dann nicht hoch. Selbst bei einer Neu-Installation über ISO tauchen im Assistenten schon eno1 und eth1 auf. Wir haben es jetzt so gelöst, dass wir im BIOS den zweiten i350 Adapter und damit den mit eth1 benannten Adapter abgeschaltet haben, so dass nur eno1 erkannt wird und dieser sich nach dem Reboot nicht ändern kann. Per Grub in die Benamung einzugreifen bzw. diese auf alte Konvention umzustellen war hier keine Option.

Wir haben diesen Stress tatsächlich nur mit diesem einen ASUS Serverboard, bisher wurde bei den anderen Serverboards die OnBoard immer mit eno1 und eno2 benannt und blieb auch nach dem Reboot immer in der richtigen Zuordnung. Zugesteckte 10G Karten haben immer die enpXsXfX Benamung. Verstehe ich nicht, hatte mich da aber nie weiter mit beschäftigt.

 

[mr44er]

endet im Verlust der Konnektivität. Die Bridge kommt dann nicht hoch.

Hier dachte ich noch weiter an Bridge ebenfalls löschen bzw. die komplete Netzconfig einmal frisch machen, aber ihr habt ja auch komplett neu installiert.
Wirklich mysteriös.
Was ist das für ein Board genau? Eventuell gibts einen Fix via Firmware?

Unbeantwortet war noch, was das ist:
4: enx068a1f482172: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000

 

[MaLe]

Das Board ist in einem Server Barebone ASUS RS520A-E11-RS12U verbaut.

Den hier mit der MAC benannte Adapter enx068a1f482172 können wir selbst nicht genau zuordnen. Vielleicht USB oder der IPMI OnBoard. Hatte ich mich nicht weiter drum gekümmert.

Bezüglich der Benennung habe ich mir noch mal die Konventionen angeschaut und hier ist es so, dass die OnBoard Adapter immer mit eno (o=OnBoard) benannt werden und die zugesteckten Karten immer als enp (p=Physical location) benannt werden. Insofern alles Ok mit eno1, einzig der eth1 darf so benannt nicht auftauchen und muss eigentlich eno2 heißen.

 

[Zerstoiber]

Hatte ein ähnliches Problem, trotz BIOS-Setting "Consistent Device Naming" kamen Interfaces immer mal durcheinandergewürfelt online.
Da wir mit teils sehr vielen Interfaces arbeiten, ist folgendes eh für den dauerhaften Betrieb einfacher:

https://wiki.debian.org/NetworkInterfaceNames#CUSTOM_SCHEMES_USING_.LINK_FILES

Für jedes Interface wird eine eigene .link Datei angelegt, das Interface wird per MAC-Adresse (die sich ja nicht ändert) auf einen "menschenlesbaren Interfacenamen" geändert

# Liste wird meistens im Editor vorbereitet und dann per SSH copypasta'd. 
# "cat von Marker EOF bis EOF" fügt entsprechend den dazwischen befindlichen Text in das jeweilige File ein.
cat <<EOF> /etc/systemd/network/01-enP1DMZ.link
[Match]
MACAddress=xx:xx:xx:xx:xx
[Link]
Name=enP1DMZ
EOF

cat <<EOF> /etc/systemd/network/02-enP2LAN.link
[Match]
MACAddress=xx:xx:xx:xx:xx
[Link]
Name=enP2LAN
EOF

(Limiterung für den Namen ist scheinbar 15 Zeichen und damit das Proxmox GUI die Interfaces auch richtig erkennt, sollten sie mit "en" anfangen)
-> entsprechend muss man dann natürlich für Proxmox in der /etc/network/interfaces anpassen, da alle vorherigen Interface-Namen mit den neu vergebenen Namen anpassen.

Reboot und hoffen, dass es klappt ;-)

 

[MaLe]

@Zerstoiber : Vielen Dank für die Infos. Das ist wirklich ein sehr schöner Vorschlag. Gerade die zugesteckten Karten mit den enpXXXsXfX Bezeichnungen sind vom Menschen schlecht zu lesen. Zudem kann man (wie vorgeschlagen) den Adapternamen z.B. gleich einer Zone oder einer Aufgabe zuordnen. Bei uns gehen recht viele Server durch und die Benennung ist immer wieder verschieden, eine Standardisierung lässt sich damit ebenfalls erreichen und jeder Techniker weiß was los ist. Ich werde das gleich mal testen, denke das wird auf jeden Fall funktionieren.

Über die neuen Server läuft bei uns immer erst ein Script, dass bestimmte Sachen wie z.B. fartbige Bash, SSH Keys und verschlüsselten Storage einrichtet. Diese Sache kann man da prima integrieren, indem man die Adapter abfragt und gleich die Namen anpasst.

Bezüglich Updates gehe ich davon aus, dass das Update-Fest ist. Geänderte Konfigs werden ja sonst auch beim Update gefunden + abgefragt und können belassen werden.

Wie gesagt - ganz vielen Dank dafür!

​

 

[mr44er]

Schaden kann es auch nie, die letzten Ziffern der MAC jeweils in Portnähe anzubringen. Entweder mit einem feinen Permanent-Marker direkt auf Blech oder Preisetiketten (die dünnen passen exakt!)

 

[Futurematic]

@Zerstoiber : Auch von meiner Seite ein herzliches Dankeschön. Ich hatte exakt das gleiche Problem. Mit deinem Vorschlag war alles bestens. Tatsächlich ist auch der Hinweis mit dem 'en' am Anfang wichtig. Ich hatte es mit 'eth' probiert. Das klappt nicht !.