Ich betreibe einen Proxmox PVE-Host und versuche, die darauf laufenden Maschinen über VXLAN mit verschiedenen Netzwerken in unserem Labor zu verbinden. Allerdings stoße ich dabei auf seltsame MTU-bezogene Probleme, die ich nicht verstehe.
Zuerst mein Setup. Das grundlegende Layout ist, dass virtuelle Maschinen auf dem PVE-Host über eine Brücke mit einem VXLAN-Tunnel verbunden sind. Auf der anderen Seite des Tunnels habe ich eine physische Maschine im Labor, die als VXLAN-Endpunkt (EP) fungiert. Sie verbindet sich über eine Brücke mit VTEP zu einem ihrer Ethernet-Ports, der wiederum mit dem Switch verbunden ist, der das Netzwerk enthält, in das ich meine VM einfügen möchte.
Auf dem PVE-Host (beispielsweise eine VM und ein VXLAN):
___________ __________ __________ ___________
| VM eth0 | | Bridge | | VXLAN | | Host eno1 |
| 192.168.. |___| ---- |___| VNI 1 |___| 10... |___ to LabNet
| MTU 1500 | | MTU 1550 | | MTU 1550 | | MTU 1600 |
|___________| |__________| |__________| |___________|
Im Labor (der Endpunkt mit einem Tunnel + einem Laborgerät als Beispiel):
___________ __________ __________ __________ ___________
| LabDevice | | EP eth1 | | Bridge | | VXLAN | | EP eth0 |
| 192.168.. |___ lab switch etc ___| ---- |___| ---- |___| VNI 1 |___| 10... |___ to PVE Host
| MTU 1500 | | MTU 1500 | | MTU 1550 | | MTU 1550 | | MTU 1600 |
|___________| |__________| |__________| |__________| |___________|
Jetzt ist mir klar, dass PMTUD hier nicht wirklich funktionieren wird, da die meisten dieser Geräte - da es sich um L2 handelt - keine Rückmeldung geben können. Deshalb habe ich die MTU für die Geräte erhöht, die mit dem VXLAN-Overhead umgehen müssen (dass sie 1600 und nicht 1550 beträgt, hat nichts damit zu tun, ich möchte lediglich den Ist-Zustand genau beschreiben).
Ich habe jedoch immer noch Probleme mit der MTU-Nichtübereinstimmung/dem ICMP-Black Hole:
Problem 1) Irgendetwas in der Kette behauptet, nur eine MTU von 1450 zu unterstützen. Wenn ich versuche, eine Verbindung von VM zu LabDevice über SSH herzustellen, bleibt die Verbindung hängen und läuft dann ab. Wenn ich MTUs über ping -M do -s 1450etwas teste, das irgendwo mit der üblichen Meldung „Fragmentierung erforderlich …“ antwortet, ist die maximale MTU von 1450 gespeichert und nachfolgende SSH-Verbindungsversuche funktionieren (bis der gespeicherte MTU1450-Eintrag abläuft). Der PVE-Host hat zwar Geräte mit einer MTU von 1450, aber keines davon ist mit der VM verbunden.
Problem 2) PMTUD funktioniert nicht einmal für Geräte, die nicht am Tunnel beteiligt sind. Wenn ich die MTU der VM eth0 verringere und sie vom LabDevice aus mit einem Wert pinge, der für die VM zu groß, aber für alles andere OK ist, erhalte ich keine Antwort, obwohl die VM meines Wissens nach mit ICMP-Nachrichten antworten können sollte, die eine erforderliche Fragmentierung erfordern.
Teilweise damit verbunden: Kann ich auf dem PVE-Host und dem Endpunktgerät irgendetwas tun, damit mit dem Endpunkt verbundene Geräte eine reduzierte MTU ermitteln können? Denn es gibt einige Labore, an die ich möglicherweise keine Jumbo Frames senden kann, und ich möchte nicht auf jedem einzelnen Gerät in diesen Laboren eine niedrigere MTU einstellen müssen.
Edit: Vielleicht auch relevant: Ich verwende derzeit kein Multicast, habe die Remote-IPs aber über eingerichtet bridge fdb .... Auch auf dem VM-Host sind die VMs nicht direkt mit der Bridge verbunden, sondern über etwas Veth-Magie.