Dell Automatisierungsplattform: NativeEdge-VM kann DHCP-IP nicht von Netzwerkbrücke abrufen

Die folgenden Beobachtungen sind zu sehen, wenn man auf die Situation stößt:

• Eine VM wird bereitgestellt und über eine heterogene Bündelungsschnittstelle (Beispiel: Aktive/Backup-Bündelung mit wlp6s0 für WLAN und enp3s0 für Ethernet)
• Die VM kann keine IP-Adresse mithilfe von DHCP abrufen.
• Innerhalb des VM-Betriebssystems lautet der Status des Schnittstellenlinks AKTIV (ethtool zeigt an, dass der Link erkannt wurde: Ja)
• NetworkManager-Protokolle der VM (mithilfe von journalctl -u NetworkManager -f) enthüllen DHCP DISCOVER Pakete werden gesendet, aber kein DHCP OFFER oder ACK Nachrichten empfangen werden.
• Das manuelle Zuweisen einer statischen IP-Adresse zur VM funktioniert erfolgreich und ermöglicht externe Pings und Gatewaykonnektivität.
• Bei Verwendung eines virtuellen NAT-Netzwerksegments anstelle eines Bridge-Segments wird der VM erfolgreich eine interne/NAT-IP-Adresse über DHCP zugewiesen.

Das Engineering hat bestätigt, dass heterogene Bond-Adapter nur die Erstellung von virtuellen NAT-Netzwerksegmenten unterstützen. Überbrückte virtuelle Netzwerksegmente über eine heterogene Bindung werden nicht unterstützt.

Dies ist eine bewusste Designentscheidung, die getroffen wurde, um sicherzustellen, dass der NativeEdge-Endpunkt erfolgreich und zuverlässig eine Verbindung mit einer größtmöglichen Vielfalt von Wi-Fi Access Points (APs) von Drittanbietern herstellt. Das Problem ergibt sich aus den grundlegenden Unterschieden in der Art und Weise, wie Standard-Ethernet- und 802.11-Netzwerke (Wi-Fi) Layer-2-Datenverkehr verarbeiten:

• Wi-Fi-Bridging-Einschränkung: Der 802.11-Standard erfordert, dass ein Access Point eine einzelne, spezifische MAC-Adresse pro Client-Verbindung authentifiziert. Echtes Network Bridging ermöglicht es, mehrere MAC-Adressen über eine einzige Schnittstelle zu übertragen, was Wi-Fi-APs normalerweise aus Sicherheitsgründen ablehnen.
• Warum DHCP fehlschlägt: Eine VM, die eine IP über DHCP anfordert, verfügt noch nicht über eine routingfähige IP-Adresse. Er überträgt ein DHCP DISCOVER Paket auf dem Data Link Layer (Layer 2) unter Verwendung seiner eigenen eindeutigen virtuellen MAC-Adresse. Wenn der externe DHCP-Server mit einem DHCP- OFFER, zielt es auf diese virtuelle MAC ab. Da diese sekundäre MAC nicht mit dem Wi-Fi-Access Point authentifiziert ist, löscht der Access Point (oder die Weiterleitungsfirewallregeln des Hosts) den nicht authentifizierten Rückverkehr, wodurch der DHCP-Handshake unterbrochen wird.
• Warum eine statische IP-Adresse funktioniert: Beim Zuweisen einer statischen IP umgeht die VM die Notwendigkeit für die Layer-2-DHCP-Übertragung. Der Netzwerkstapel des Hypervisors verwendet Proxy ARP (MAC-NAT) und standardmäßiges Layer-3-Routing. Der Host fängt den ausgehenden Datenverkehr der VM ab, leitet ihn im Namen der VM weiter und maskiert den Datenverkehr hinter der primären, authentifizierten MAC-Adresse des Hosts. Da der Datenverkehr auf Layer 3 ordnungsgemäß geroutet und nicht auf Layer 2 überbrückt wird, fließt die Netzwerkkommunikation.

Diese Einschränkung ist in der aktuellen Dokumentation nicht verzeichnet, wird aber in der kommenden Version zu den Versionshinweisen hinzugefügt.

Verwenden Sie eine der folgenden Methoden, um dieses Problem zu beheben oder zu umgehen:

1. Verwenden Sie ein NAT-Netzwerksegment: Wenn Sie einen heterogenen Bündelungsadapter (gemischtes Wi-Fi und Ethernet) verwenden, konfigurieren Sie das virtuelle Netzwerksegment so, dass NAT anstelle von Bridge verwendet wird.
2. Weisen Sie eine statische IP zu: Wenn eine überbrückte Netzwerkverbindung für die heterogene Bindung unbedingt erforderlich ist, weisen Sie der VM manuell eine statische IP-Adresse zu. Statische IP-Konfigurationen umgehen die DHCP-Einschränkung und ermöglichen einen normalen Datenverkehr.