Hallo,
ich habe ein Problem mit meiner PVE 8.0.4 Netzwerkkonfiguration,
das direkt nach/seit dem Upgrade von PVE7.4.17 per (pve7to8) aufgetreten ist.
Seitdem verhält sich das Netzwerk anders als unter PVE7 und nicht wie erwartet.
Änderungen habe seitdem ich nicht vorgenommen, lediglich temporär zur Ursachenermittlung.
Dieses PVE ist mein Homelab und wurde ursprünglich mal auf einem Debian Basissystem installiert (später auch PBS)
und läuft dort seitdem unaufällig und hat auch bisherige Upgrades (jeweils mit "pveoldtonew" Script) überstanden.
Das Homelab befindet sich im lokalen Netz zusammen mit anderen Devices.
Es gibt eine physische NIC (eno0), bei Bedarf wird per USB eine weitere angesteckt (aktuell nicht der Fall).
Die o.g. NIC wurde zur Bridge vmbr0 definiert (zu vmbr0 ist auch das Gateway definiert),
die VMs hängen ebenfalls alle mit am vmbr0.
Zum Problem:
Die VMs selbst arbeiten normal, auch Netzwerkmässig,
"nur" PVE8 (bzw. das Debian Basissystem) hat Probleme mit der Konnektivität ins Internet.
Ich kann aus PVE heraus zwar mein Gateway und andere lokalen Devices erfolgreich anpingen (auch VMs),
und auch von lokalen Devices und VMs erfolgreich zur PVE pingen, aber ich kann keine IP Adressen im Internet anpingen. Aus dem lokalen Netz (ausser PVE selbt) und aus dem VMs jedoch schon.
Soweit ich das bisher ermitteln konnte liegt das Problem daran, dass PVE nicht über seine vmbr0 IP Adresse sendet,
sondern über eine "link-local" Adresse aus dem 169er Bereich, die von der NIC eno1 stammt.
Keine Ahnung warum sich die NIC überhaupt eine solche zugewiesen hat, das war vor dem Upgrade noch nie so.
Zu dieser NIC hat sich dann auch noch eine "default" Route aktiviert, weshalb PVE darüber sendet.
Wenn ich die falschen Route(n) lösche und eine eigene default Route aktiviere, funktioniert es für den Moment.
Entsprechende Schritte dieser "Fehlerkorrektur" zu automatisieren (Neustart) bringen aber nichts,
denn mit jedem "tap123xyz" Device das sich mit dem Starten von VMs hinzugesellt,
erhalten diese Devoces ebenfalls sofort "link-local" Adressen aus dem 169er Bereich.
Und zu diesen aktivieren sich ebenfalls default Routen.
Ich verstehe nicht, wie das kommt.
Laut Log werden die Adressen jeweils kurz nach einer Aktion von Avahi zugewiesen.
Avahi war aber schon unter PVE 7 in Verwendung.
Das Problem besteht aber auch nach Deaktivierung des Avahi Dienstes weiter.
Meine "etc/network/interfaces" sieht so aus (Unwesentliches weggelassen):
auto lo
iface lo inet loopback
iface eno1 inet manual
#das ist meine physische NIC
auto vmbr0
iface vmbr0 inet static
address 192.168.18.219/24
gateway 192.168.18.99
bridge-ports eno1
bridge-stp off
bridge-fd 0
#das ist meine Bridge mit Zugang zum Gateway bzw. WAN
Das Devoce eno1 hatte ich zwischenzeitlich in der "etc/network/interfaces" ans Ende gesetzt,
weil ich mir davon erhoffte, dass die Bridge beim Senden bvevorzugt wird.
Ich meine, das hat auch einen Neustart lang gehalten, inzwischen steht eno1 wieder oben.
Hier ein Paar Beispiele und Ausgaben (Unwichtiges weggelassen)
Nach dem Start (ohne laufende VMs) zeigt "ifconfig"…
eno1: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500
inet 169.254.28.164 netmask 255.255.0.0 broadcast 169.254.255.255
inet6 fe80::fab1:56ff:fe9d:b4a3 prefixlen 64 scopeid 0x20<link>
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Lokale Schleife)
vmbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.18.219 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 fe80::fab1:56ff:fe9d:b4a3 prefixlen 64 scopeid 0x20<link>
ether f8:b1:56:9d:b4:a3 txqueuelen 1000 (Ethernet)
…und es werden folgende Routen angezeigt:
# route:
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 255.255.255.255 UH 0 0 0 eno1
default 0.0.0.0 0.0.0.0 U 0 0 0 eno1
link-local 0.0.0.0 255.255.0.0 U 0 0 0 eno1
192.168.18.0 0.0.0.0 255.255.255.0 U 0 0 0 vmbr0
# ip route show:
0.0.0.0 dev eno1 scope link
default dev eno1 scope link
169.254.0.0/16 dev eno1 proto kernel scope link src 169.254.28.164
192.168.18.0/24 dev vmbr0 proto kernel scope link src 192.168.18.219
Nach dem aktivieren der ersten VM zeigt "ifconfig" dann zusätzlich folgende Devices…
tap166101i0: flags=-28349<UP,BROADCAST,RUNNING,PROMISC,MULTICAST,DYNAMIC> mtu 1500
inet 169.254.19.166 netmask 255.255.0.0 broadcast 169.254.255.255
ether 0e:cd:bf:6d:71:1d txqueuelen 1000 (Ethernet)
tap166101i1: flags=-28349<UP,BROADCAST,RUNNING,PROMISC,MULTICAST,DYNAMIC> mtu 1500
inet 169.254.63.243 netmask 255.255.0.0 broadcast 169.254.255.255
ether 82:13:c7:eb:c8:c8 txqueuelen 1000 (Ethernet)
…und es werden folgende Routen angezeigt:
# route:
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 255.255.255.255 UH 0 0 0 tap166101i1
0.0.0.0 0.0.0.0 255.255.255.255 UH 0 0 0 tap166101i0
0.0.0.0 0.0.0.0 255.255.255.255 UH 0 0 0 eno1
default 0.0.0.0 0.0.0.0 U 0 0 0 tap166101i1
link-local 0.0.0.0 255.255.0.0 U 0 0 0 eno1
link-local 0.0.0.0 255.255.0.0 U 0 0 0 tap166101i0
link-local 0.0.0.0 255.255.0.0 U 0 0 0 tap166101i1
192.168.18.0 0.0.0.0 255.255.255.0 U 0 0 0 vmbr0
# ip route show:
0.0.0.0 dev tap166101i1 scope link
0.0.0.0 dev tap166101i0 scope link
0.0.0.0 dev eno1 scope link
default dev tap166101i1 scope link
169.254.0.0/16 dev eno1 proto kernel scope link src 169.254.28.164
169.254.0.0/16 dev tap166101i0 proto kernel scope link src 169.254.19.166
169.254.0.0/16 dev tap166101i1 proto kernel scope link src 169.254.63.243
192.168.18.0/24 dev vmbr0 proto kernel scope link src 192.168.18.219
Hat irgendwer eine Idee was da los ist und wie sich das beheben lässt?
Diese PVE Instanz ist mein Homelab, auf dem ich das Upgrades getestet habe.
Das aktuelle Upgrade auf PVE8 lief im Prinzip durch (pve7to8 zeigte weder vorher noch nachher Fehler).
Beim ersten Updateaufruf zeigte sich jedoch, dass einige von "polkit" abhängige Pakete nicht mitaktualisiert werden konnten (polkit konnte sich nicht konfigurieren weil es nicht auf das Vorhandesein des Benutzers bzw. die Gruppe polkit:root testen konnte).
Soweit ich erinnere, kam polkit mal im Zuge einer grafischen Benutzerumgebung mit auf das Homelab.
Nach der Deinstallation von Polkit, wurde ein anderer Rechtemanager aktiv.
Ich gehe jedoch nicht davon aus, dass das irgendwas mit dem geschilderten Problem zu tun hat.
Das geschilderte Netzwerkproblem besteht direkt seit dem Upgrade und sowohl nach der Deinstallation von Polkit weiter als auch nach Reinstallation von Polkit und aller zuvor wegen polkit Abhängigkeit deinstallierten Pakete (während hilfsweiser Anlegung eines polkit:root Benutzers).
Für Hinweise bin ich dankbar. Ich kann das Homelab zwar jederzeit neu hochziehen,
aber ich gehe lieber den Ursachen auf den Grund und lerne überdies gern dazu.
Gruss Yummiweb
NACHTRAG:
Mir ist grad aufgefallen, dass auf dem physischen NIC ein "DYNAMIC" gesetzt ist und auch auf den "tap…" Devices.
Bei denen steht aber auch ein "PROMISC", weshalb mir schon überhaupt nicht klar ist, warum die sich eine Adresse ziehen.
Unter PVE7 sahen die Zeilen eher so aus:
physische NIC:
flags=4163<UP,BROADCAST,RUNNING,MULTICAST>
tap:
flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>
ich habe ein Problem mit meiner PVE 8.0.4 Netzwerkkonfiguration,
das direkt nach/seit dem Upgrade von PVE7.4.17 per (pve7to8) aufgetreten ist.
Seitdem verhält sich das Netzwerk anders als unter PVE7 und nicht wie erwartet.
Änderungen habe seitdem ich nicht vorgenommen, lediglich temporär zur Ursachenermittlung.
Dieses PVE ist mein Homelab und wurde ursprünglich mal auf einem Debian Basissystem installiert (später auch PBS)
und läuft dort seitdem unaufällig und hat auch bisherige Upgrades (jeweils mit "pveoldtonew" Script) überstanden.
Das Homelab befindet sich im lokalen Netz zusammen mit anderen Devices.
Es gibt eine physische NIC (eno0), bei Bedarf wird per USB eine weitere angesteckt (aktuell nicht der Fall).
Die o.g. NIC wurde zur Bridge vmbr0 definiert (zu vmbr0 ist auch das Gateway definiert),
die VMs hängen ebenfalls alle mit am vmbr0.
Zum Problem:
Die VMs selbst arbeiten normal, auch Netzwerkmässig,
"nur" PVE8 (bzw. das Debian Basissystem) hat Probleme mit der Konnektivität ins Internet.
Ich kann aus PVE heraus zwar mein Gateway und andere lokalen Devices erfolgreich anpingen (auch VMs),
und auch von lokalen Devices und VMs erfolgreich zur PVE pingen, aber ich kann keine IP Adressen im Internet anpingen. Aus dem lokalen Netz (ausser PVE selbt) und aus dem VMs jedoch schon.
Soweit ich das bisher ermitteln konnte liegt das Problem daran, dass PVE nicht über seine vmbr0 IP Adresse sendet,
sondern über eine "link-local" Adresse aus dem 169er Bereich, die von der NIC eno1 stammt.
Keine Ahnung warum sich die NIC überhaupt eine solche zugewiesen hat, das war vor dem Upgrade noch nie so.
Zu dieser NIC hat sich dann auch noch eine "default" Route aktiviert, weshalb PVE darüber sendet.
Wenn ich die falschen Route(n) lösche und eine eigene default Route aktiviere, funktioniert es für den Moment.
Entsprechende Schritte dieser "Fehlerkorrektur" zu automatisieren (Neustart) bringen aber nichts,
denn mit jedem "tap123xyz" Device das sich mit dem Starten von VMs hinzugesellt,
erhalten diese Devoces ebenfalls sofort "link-local" Adressen aus dem 169er Bereich.
Und zu diesen aktivieren sich ebenfalls default Routen.
Ich verstehe nicht, wie das kommt.
Laut Log werden die Adressen jeweils kurz nach einer Aktion von Avahi zugewiesen.
Avahi war aber schon unter PVE 7 in Verwendung.
Das Problem besteht aber auch nach Deaktivierung des Avahi Dienstes weiter.
Meine "etc/network/interfaces" sieht so aus (Unwesentliches weggelassen):
auto lo
iface lo inet loopback
iface eno1 inet manual
#das ist meine physische NIC
auto vmbr0
iface vmbr0 inet static
address 192.168.18.219/24
gateway 192.168.18.99
bridge-ports eno1
bridge-stp off
bridge-fd 0
#das ist meine Bridge mit Zugang zum Gateway bzw. WAN
Das Devoce eno1 hatte ich zwischenzeitlich in der "etc/network/interfaces" ans Ende gesetzt,
weil ich mir davon erhoffte, dass die Bridge beim Senden bvevorzugt wird.
Ich meine, das hat auch einen Neustart lang gehalten, inzwischen steht eno1 wieder oben.
Hier ein Paar Beispiele und Ausgaben (Unwichtiges weggelassen)
Nach dem Start (ohne laufende VMs) zeigt "ifconfig"…
eno1: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500
inet 169.254.28.164 netmask 255.255.0.0 broadcast 169.254.255.255
inet6 fe80::fab1:56ff:fe9d:b4a3 prefixlen 64 scopeid 0x20<link>
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Lokale Schleife)
vmbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.18.219 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 fe80::fab1:56ff:fe9d:b4a3 prefixlen 64 scopeid 0x20<link>
ether f8:b1:56:9d:b4:a3 txqueuelen 1000 (Ethernet)
…und es werden folgende Routen angezeigt:
# route:
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 255.255.255.255 UH 0 0 0 eno1
default 0.0.0.0 0.0.0.0 U 0 0 0 eno1
link-local 0.0.0.0 255.255.0.0 U 0 0 0 eno1
192.168.18.0 0.0.0.0 255.255.255.0 U 0 0 0 vmbr0
# ip route show:
0.0.0.0 dev eno1 scope link
default dev eno1 scope link
169.254.0.0/16 dev eno1 proto kernel scope link src 169.254.28.164
192.168.18.0/24 dev vmbr0 proto kernel scope link src 192.168.18.219
Nach dem aktivieren der ersten VM zeigt "ifconfig" dann zusätzlich folgende Devices…
tap166101i0: flags=-28349<UP,BROADCAST,RUNNING,PROMISC,MULTICAST,DYNAMIC> mtu 1500
inet 169.254.19.166 netmask 255.255.0.0 broadcast 169.254.255.255
ether 0e:cd:bf:6d:71:1d txqueuelen 1000 (Ethernet)
tap166101i1: flags=-28349<UP,BROADCAST,RUNNING,PROMISC,MULTICAST,DYNAMIC> mtu 1500
inet 169.254.63.243 netmask 255.255.0.0 broadcast 169.254.255.255
ether 82:13:c7:eb:c8:c8 txqueuelen 1000 (Ethernet)
…und es werden folgende Routen angezeigt:
# route:
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 0.0.0.0 255.255.255.255 UH 0 0 0 tap166101i1
0.0.0.0 0.0.0.0 255.255.255.255 UH 0 0 0 tap166101i0
0.0.0.0 0.0.0.0 255.255.255.255 UH 0 0 0 eno1
default 0.0.0.0 0.0.0.0 U 0 0 0 tap166101i1
link-local 0.0.0.0 255.255.0.0 U 0 0 0 eno1
link-local 0.0.0.0 255.255.0.0 U 0 0 0 tap166101i0
link-local 0.0.0.0 255.255.0.0 U 0 0 0 tap166101i1
192.168.18.0 0.0.0.0 255.255.255.0 U 0 0 0 vmbr0
# ip route show:
0.0.0.0 dev tap166101i1 scope link
0.0.0.0 dev tap166101i0 scope link
0.0.0.0 dev eno1 scope link
default dev tap166101i1 scope link
169.254.0.0/16 dev eno1 proto kernel scope link src 169.254.28.164
169.254.0.0/16 dev tap166101i0 proto kernel scope link src 169.254.19.166
169.254.0.0/16 dev tap166101i1 proto kernel scope link src 169.254.63.243
192.168.18.0/24 dev vmbr0 proto kernel scope link src 192.168.18.219
Hat irgendwer eine Idee was da los ist und wie sich das beheben lässt?
Diese PVE Instanz ist mein Homelab, auf dem ich das Upgrades getestet habe.
Das aktuelle Upgrade auf PVE8 lief im Prinzip durch (pve7to8 zeigte weder vorher noch nachher Fehler).
Beim ersten Updateaufruf zeigte sich jedoch, dass einige von "polkit" abhängige Pakete nicht mitaktualisiert werden konnten (polkit konnte sich nicht konfigurieren weil es nicht auf das Vorhandesein des Benutzers bzw. die Gruppe polkit:root testen konnte).
Soweit ich erinnere, kam polkit mal im Zuge einer grafischen Benutzerumgebung mit auf das Homelab.
Nach der Deinstallation von Polkit, wurde ein anderer Rechtemanager aktiv.
Ich gehe jedoch nicht davon aus, dass das irgendwas mit dem geschilderten Problem zu tun hat.
Das geschilderte Netzwerkproblem besteht direkt seit dem Upgrade und sowohl nach der Deinstallation von Polkit weiter als auch nach Reinstallation von Polkit und aller zuvor wegen polkit Abhängigkeit deinstallierten Pakete (während hilfsweiser Anlegung eines polkit:root Benutzers).
Für Hinweise bin ich dankbar. Ich kann das Homelab zwar jederzeit neu hochziehen,
aber ich gehe lieber den Ursachen auf den Grund und lerne überdies gern dazu.
Gruss Yummiweb
NACHTRAG:
Mir ist grad aufgefallen, dass auf dem physischen NIC ein "DYNAMIC" gesetzt ist und auch auf den "tap…" Devices.
Bei denen steht aber auch ein "PROMISC", weshalb mir schon überhaupt nicht klar ist, warum die sich eine Adresse ziehen.
Unter PVE7 sahen die Zeilen eher so aus:
physische NIC:
flags=4163<UP,BROADCAST,RUNNING,MULTICAST>
tap:
flags=4419<UP,BROADCAST,RUNNING,PROMISC,MULTICAST>
Last edited:
