Thomas.will: Praxisfall korrigiert: Eintrag war in interfaces, Apply hat ihn entfernt

2026-10-25T17:48:35Z

Praxisfall korrigiert: Eintrag war in interfaces, Apply hat ihn entfernt

← Nächstältere Version		Version vom 25. Oktober 2026, 17:48 Uhr
Zeile 73:		Zeile 73:
	== Praxisfall: eine Adresse fehlt in der Konfiguration ==		== Praxisfall: eine Adresse fehlt in der Konfiguration ==

	Auf einem Proxmox-Host lief eine IPv6-Adresse auf einer SDN-verwalteten VLAN-Bridge, die aber ~~nirgends~~ in ~~einer~~ Konfigurationsdatei ~~eingetragen~~ war ~~– sie war irgendwann nur live per~~ <code>~~ip addr add~~</code> ~~gesetzt~~ worden. Proxmox zeigte darum in der Weboberfläche für die ganze SDN-Zone einen roten Fehler.		Auf einem Proxmox-Host lief eine IPv6-Adresse auf einer SDN-verwalteten VLAN-Bridge, die aber in keiner Konfigurationsdatei mehr auftauchte. Sie war ursprünglich ordentlich in <code>/etc/network/interfaces</code> eingetragen worden – stand dort aber irgendwann nicht mehr drin, lief auf dem Interface selbst jedoch munter weiter. Proxmox zeigte darum in der Weboberfläche für die ganze SDN-Zone einen roten Fehler.

			Die wahrscheinlichste Erklärung für das Verschwinden: Unter ''Node → Network'' schreibt Proxmox bei jedem Klick auf "Apply Configuration" die Datei <code>/etc/network/interfaces</code> komplett neu – und zwar nur aus seiner eigenen Liste bekannter Interfaces (die physischen NICs, Bonds, die Haupt-Bridge). Eine von SDN zur Laufzeit erzeugte VLAN-Bridge wie <code>vmbr0vXXXX</code> gehört nicht zu dieser Liste. Ein von Hand ergänzter Eintrag für so eine Bridge übersteht darum das nächste "Apply" in diesem Dialog nicht, selbst wenn er vorher jahrelang anstandslos funktioniert hat.

	Der Befund mit <code>ifquery --check</code>:		Der Befund mit <code>ifquery --check</code>:
Zeile 91:		Zeile 93:
	=== Die Lösung: eine eigene Datei, nicht die verwaltete ===		=== Die Lösung: eine eigene Datei, nicht die verwaltete ===

	Proxmox ~~schreibt seine~~ SDN-~~Konfiguration in~~ <code>/etc/network/interfaces.d/sdn</code> ~~und ersetzt diese Datei bei jedem Klick auf "Apply" komplett~~. Ein Eintrag von Hand ~~dort wäre beim~~ nächsten Apply ~~wieder weg~~.		Zwei Proxmox-Dialoge schreiben Netzwerkdateien komplett neu und sind damit als Ablageort für eigene Einträge ungeeignet: ''Node → Network'' mit "Apply Configuration" erzeugt <code>/etc/network/interfaces</code> neu (nur aus seiner eigenen Geräteliste), und die SDN-Oberfläche erzeugt bei ihrem "Apply" <code>/etc/network/interfaces.d/sdn</code> neu. Ein Eintrag von Hand in einer der beiden Dateien übersteht den nächsten Klick auf "Apply" im jeweiligen Dialog nicht – ganz gleich, wie lange er vorher anstandslos lief.

	Die Hauptdatei <code>/etc/network/interfaces</code> liest aber alle Dateien in <code>/etc/network/interfaces.d/</code> ein:		Die Hauptdatei <code>/etc/network/interfaces</code> liest aber alle Dateien in <code>/etc/network/interfaces.d/</code> ein:

Thomas.will: Neuer Artikel: ifupdown2, SDN-Praxisfall

2026-10-25T17:35:17Z

Neuer Artikel: ifupdown2, SDN-Praxisfall

Neue Seite

'''ifupdown2''' ist das Werkzeug, mit dem Debian und Proxmox VE die Netzwerkschnittstellen aus <code>/etc/network/interfaces</code> aufbauen. Es ist der Nachfolger des klassischen <code>ifupdown</code>-Pakets und bringt zwei Dinge mit, die im Praxisbetrieb viel wert sind: Teiländerungen am Netz ohne Verbindungsabbruch, und eine Prüfung, ob die laufende Konfiguration noch zu dem passt, was in den Dateien steht.

== Woher es kommt ==

Debian bringt standardmäßig weiter das alte <code>ifupdown</code> mit. <code>ifupdown2</code> liegt seit Debian 10 als eigenes Paket in den Repos, ist aber nicht vorinstalliert:

<syntaxhighlight lang="bash">
apt install ifupdown2
</syntaxhighlight>

Dabei wird das klassische <code>ifupdown</code> automatisch entfernt, denn beide vertragen sich nicht parallel.

'''Proxmox VE''' setzt <code>ifupdown2</code> dagegen von Haus aus ein, mit einem eigenen Fork (Paketname <code>ifupdown2</code>, Versionszusatz <code>+pmxNN</code>). Der Grund: Proxmox baut darauf seine SDN-Funktion (Software Defined Networking) auf, die VLANs und virtuelle Netze live über die Oberfläche verwaltet.

== Installation auf einem normalen Debian ==

Vor der Installation prüfen, was gerade läuft:

<syntaxhighlight lang="bash">
dpkg -l | grep -E "ifupdown2?\b"
systemctl status networking
</syntaxhighlight>

Die Installation selbst ist ein einziger Befehl:

<syntaxhighlight lang="bash">
apt update
apt install ifupdown2
</syntaxhighlight>

Dabei entfernt <code>apt</code> automatisch das alte <code>ifupdown</code>-Paket (die beiden können nicht gleichzeitig installiert sein) und übernimmt die bestehende <code>/etc/network/interfaces</code> unverändert – die Syntax ist weitgehend kompatibel.

'''Vorsicht bei einem entfernten Server (SSH):''' Der Wechsel selbst reißt die Verbindung normalerweise nicht ab, weil <code>ifupdown2</code> beim Einrichten die aktuell aktiven Schnittstellen übernimmt, statt sie neu aufzubauen. Trotzdem gilt wie bei jeder Netzwerkänderung aus der Ferne: vorher eine Konsole bereithalten (IPMI, Hypervisor-Konsole, physischer Zugang), falls <code>/etc/network/interfaces</code> Fehler enthält, die erst beim nächsten <code>ifreload</code> oder Neustart auffallen.

Nach der Installation die Probe aufs Exempel:

<syntaxhighlight lang="bash">
ifquery --check -a # alle Schnittstellen auf einen Blick
ifreload -a # übernimmt Änderungen, ohne unveränderte Schnittstellen anzufassen
</syntaxhighlight>

Wer ganz sichergehen will, plant den ersten <code>ifreload -a</code> in einem Wartungsfenster und hat eine zweite Zugangsmöglichkeit parat.

'''Auf Proxmox VE''' ist <code>ifupdown2</code> schon Teil der Standardinstallation, dort ist nichts weiter zu tun.

== Die wichtigsten Befehle ==

{| class="wikitable"
! Befehl !! Zweck
|-
| <code>ifup</code> / <code>ifdown</code> || einzelne Schnittstelle hoch- bzw. herunterfahren
|-
| <code>ifreload -a</code> || alle Schnittstellen neu einlesen, nur das anwenden, was sich geändert hat – kein harter Netz-Neustart
|-
| <code>ifquery <iface></code> || zeigt, was für diese Schnittstelle konfiguriert ''ist''
|-
| <code>ifquery --check <iface></code> || vergleicht Konfiguration gegen den tatsächlich laufenden Zustand
|}

Der letzte Befehl ist im Alltag der nützlichste. Ein Beispiel von einem funktionierenden Proxmox-Bridge-Interface:

<syntaxhighlight lang="text">
# ifquery --check vmbr0v3233
auto vmbr0v3233
iface vmbr0v3233 [pass]
bridge-ports bond0.3233 pr_vlan3233 (tap5008i9) [pass]
bridge-fd 0 [pass]
bridge-stp no [pass]
</syntaxhighlight>

Jede Zeile wird einzeln geprüft und mit <code>[pass]</code> oder <code>[fail]</code> markiert. Das ist weit genauer als ein bloßes "Interface ist up".

== Praxisfall: eine Adresse fehlt in der Konfiguration ==

Auf einem Proxmox-Host lief eine IPv6-Adresse auf einer SDN-verwalteten VLAN-Bridge, die aber nirgends in einer Konfigurationsdatei eingetragen war – sie war irgendwann nur live per <code>ip addr add</code> gesetzt worden. Proxmox zeigte darum in der Weboberfläche für die ganze SDN-Zone einen roten Fehler.

Der Befund mit <code>ifquery --check</code>:

<syntaxhighlight lang="text">
# ifquery --check vmbr0v3240
auto vmbr0v3240
iface vmbr0v3240 [fail]
bridge-ports bond0.3240 pr_vlan3240 (tap5008i1) [pass]
bridge-fd 0 [pass]
bridge-stp no [pass]
address 2001:db8:f240::aaaa/64 [fail]
</syntaxhighlight>

Die Adresse lief, war aber nicht deklariert – <code>ifquery</code> hat genau das aufgedeckt, Zeile für Zeile.

=== Die Lösung: eine eigene Datei, nicht die verwaltete ===

Proxmox schreibt seine SDN-Konfiguration in <code>/etc/network/interfaces.d/sdn</code> und ersetzt diese Datei bei jedem Klick auf "Apply" komplett. Ein Eintrag von Hand dort wäre beim nächsten Apply wieder weg.

Die Hauptdatei <code>/etc/network/interfaces</code> liest aber alle Dateien in <code>/etc/network/interfaces.d/</code> ein:

<syntaxhighlight lang="text">
source /etc/network/interfaces.d/*
</syntaxhighlight>

Eine zusätzliche, eigene Datei mit anderem Namen bleibt von SDN unberührt und ergänzt dieselbe Schnittstelle nur um eine weitere Adressfamilie:

<syntaxhighlight lang="text">
# /etc/network/interfaces.d/custom-vmbr0v3240
iface vmbr0v3240 inet6 static
address 2001:db8:f240::aaaa/64
</syntaxhighlight>

Kein <code>ifreload</code> nötig, um das zu prüfen – <code>ifquery --check</code> liest die Dateien einfach neu ein:

<syntaxhighlight lang="text">
# ifquery --check vmbr0v3240
iface vmbr0v3240 inet6 static [pass]
address 2001:db8:f240::aaaa/64 [pass]

auto vmbr0v3240
iface vmbr0v3240 [pass]
bridge-ports bond0.3240 pr_vlan3240 (tap5008i1) [pass]
bridge-fd 0 [pass]
bridge-stp no [pass]
</syntaxhighlight>

Alles auf <code>[pass]</code>, und die Adresse übersteht jetzt auch einen Neustart des Hosts, ohne dass ein künftiges SDN-"Apply" sie wieder löscht.

== Merksatz ==

Wer auf einem Proxmox- oder Debian-System mit <code>ifupdown2</code> eine Schnittstelle von Hand ergänzen will, die auch von einem automatischen System (SDN, einem Konfigurationswerkzeug, einem Skript) verwaltet wird: niemals in die verwaltete Datei schreiben, sondern eine eigene Datei danebenlegen. <code>ifquery --check</code> zeigt zuverlässig, ob am Ende alles zusammenpasst.

[[Kategorie:Netzwerk]]
[[Kategorie:Proxmox]]
[[Kategorie:Linux]]

Ifupdown2 in der Praxis - Versionsgeschichte

Thomas.will: Praxisfall korrigiert: Eintrag war in interfaces, Apply hat ihn entfernt

Thomas.will: Neuer Artikel: ifupdown2, SDN-Praxisfall