Select Page

Ausgangspunkt ist ein Proxmox 6.4, die Netzwerkschnittstellen eth0 und eth1 sind zu bond0 verbunden, welches für die Bridge vmbr0 verwendet wird, um die VMs an das Netzwerk anzuschließen. Die von Proxmox geschriebene Netzwerkkonfigurations-Datei /etc/network/interfaces sieht wie folgt aus:

auto eth0
iface eth0 inet manual

auto eth1
iface eth1 inet manual

auto bond0
iface bond0 inet manual
        bond-slaves eth0 eth1
        bond-miimon 100
        bond-mode 802.3ad
        bond-lacp-rate 1
        bond-updelay 200
        bond-downdelay 200
        bond-xmit_hash_policy layer3+4

auto vmbr0
iface vmbr0 inet static
        address 192.0.2.30/24
        gateway 192.0.2.1
        bridge-ports bond0.20
        bridge-stp off
        bridge-fd 0

Unter Proxmox 6 funktioniert die gezeigte Netzwerkkonfiguration problemlos, unter Proxmox 7 wird bond0 nicht aktiviert. Die Folge ist, dass auch vmbr0 nicht aktiviert wird und der Host nicht erreichbar ist.

Als Ursache des Problems stellte sich heraus, dass die in Debian Bullseye und somit in Proxmox 7 enthaltene Version von ifupdown keine Netzwerkschnittstellen in ein Bond aufnimmt, welche mit auto gekennzeichnet sind, da es diese Schnittstellen als bereits verwendet ansieht.

Es gibt zwei Ansätze, dieses Problem zu beheben. Die erste Möglichkeit ist, die beiden Zeilen auto eth0 und auto eth1 zu entfernen. Anschließend versteht auch die in Debian Bullseye / Proxmox 7 enthaltene Version von ifupdown die Konfigurationsdatei. Allerdings müsste anschließend auf die Verwendung des Proxmox-internen Konfigurationstools verzichtet werden, denn dieses wird die Zeilen bei der nächsten Änderung wieder hinzufügen.

Die zweite Möglichkeit ist die Installation von ifupdown2ifupdown2 kann mit der von Proxmox geschriebenen Konfigurationsdatei einschließlich der Zeilen auto eth0 und auto eth1 problemlos umgehen und ist seit Proxmox 7 auch der Standard bei Neuinstallationen. Allerdings kann auch die Umstellung von Bestandssystemen auf ifupdown2 dazu führen, dass das Netzwerk nicht mehr funktioniert.

Als erstes sollte sichergestellt werden, dass in der Datei /etc/network/interfaces keine Zeile vorhanden ist, welche mit source-directory beginnt:

source-directory /etc/network/interfaces.d

Wenn eine solche Zeile vorhanden ist, kann sie durch folgende ersetzt werden:

source /etc/network/interfaces.d/*

Jetzt kann ifupdown2 installiert werden:

apt install ifupdown2

Dabei wird ifupdown automatisch deinstalliert. Die Ausgabe von dpkg -l ifupdown zeigt jedoch, dass das Paket zwar gelöscht (remove) wurde, jedoch nicht “vollständig gelöscht” (purge):

rc ifupdown 0.8.36+pve1 amd64 high level tools to configure network interfaces

Solange das Paket in diesem Zustand bleibt, wird alles wie bisher funktionieren. Es besteht aber die Gefahr, dass das Paket zu einem späteren Zeitpunkt vollständig entfernt wird, beispielsweise durch den Aufruf von aptitude purge '~c'. Dieser Befehl kann nach einem Upgrade dazu genutzt werden, alle deinstallierten Pakete mit noch vorhandenen Konfigurationsdateien vollständig zu löschen. Wenn ifupdown vollständig entfernt wird, wird dies ifupdown2 beschädigen. Daher ist es besser, die vollständige Löschung sofort durchzuführen und anschließend das Problem zu beheben, bevor es später versehentlich passiert.

Die Ursache des entstehenden Problems ist, dass das Post-Remove-Skript von ifupdown die Systemd-Unit networking.service deaktiviert. Das Post-Install-Skript ifupdown2 würde die Unit wieder aktivieren, allerdings wird es vor dem Post-Remove-Skript aufgerufen und ist damit wirkungslos. Es muss also dafür gesorgt werden, dass das Skript nach der Deinstallation ein weiteres Mal läuft.

Mit den folgenden drei Befehlen kann dies zusammen mit der Umstellung erreicht werden:

apt install ifupdown2
apt purge ifupdown
apt install --reinstall ifupdown2

Der dritte Befehl wird das Post-Install-Skript von ifupdown2 ein zweites Mal aufrufen und reparieren, was der zweite Befehl gelöscht hat.

Zur Sicherheit sollte überprüft werden, dass die Systemd-Unit networking.service wirklich auf enabled steht: systemctl status networking.service Sollte dies nicht der Fall sein, so kann die Unit mit systemctl enable networking.service auch manuell wieder aktiviert werden.

Eine unter Proxmox 6 funktionierende Netzwerkkonfiguration muss unter Proxmox 7 nicht funktionieren. Die Installation von ifupdown2 verhindert Probleme mit der Konfigurations-GUI. Wenn das Problem mit dem Post-Remove-Skript sofort gelöst wird, vermeidet dies spätere Probleme.

Jens Meißner
Jens Meißner arbeitet seit 2018 als Linux-Consultant bei B1 Systems und beschäftigt sich mit den Themen Netzwerk, Virtualisierung, Automatisierung und Monitoring. Am liebsten benutzt er Debian, interessiert sich neben Linux aber auch für FreeBSD und OpenBSD.
This site is registered on wpml.org as a development site. Switch to a production site key to remove this banner.