Dell Automation Platform: NativeEdge VM kan geen DHCP IP ophalen van netwerkbridge

De volgende observaties worden gezien bij het tegenkomen van de situatie:

• Een VM wordt geïmplementeerd en verbonden met een overbrugd virtueel netwerksegment met behulp van een heterogene bindingsinterface (bijvoorbeeld: Actieve/back-upverbinding met behulp van wlp6s0 voor Wi-Fi en enp3s0 voor Ethernet)
• De VM kan geen IP-adres verkrijgen met behulp van DHCP.
• Binnen het VM-besturingssysteem is de interfacekoppelingsstatus OMHOOG (ethtool toont link gedetecteerd: Ja)
• NetworkManager-logboeken van de VM (met journalctl -u NetworkManager -f) onthullen DHCP DISCOVER Er worden pakketten verzonden, maar geen DHCP OFFER of ACK Berichten worden nooit ontvangen.
• Het handmatig toewijzen van een statisch IP-adres aan de VM werkt met succes, waardoor externe pings en gatewayconnectiviteit mogelijk zijn.
• Met behulp van een virtueel NAT-netwerksegment in plaats van een Bridge-segment wijst u met behulp van DHCP een intern/NAT IP-adres toe aan de VM.

Engineering heeft bevestigd dat heterogene bindingsadapters alleen ondersteuning bieden voor het maken van virtuele NAT-netwerksegmenten. Overbrugde virtuele netwerksegmenten over een heterogene binding worden niet ondersteund.

Dit is een bewuste ontwerpkeuze die is gemaakt om ervoor te zorgen dat het NativeEdge-eindpunt met succes en betrouwbaar verbinding maakt met de breedst mogelijke verscheidenheid aan Wi-Fi-toegangspunten (AP's) van derden. Het probleem komt voort uit de fundamentele verschillen in de manier waarop standaard Ethernet- en 802.11-netwerken (Wi-Fi) omgaan met Layer-2-verkeer:

• Wi-Fi Bridging-beperking: De 802.11-standaard vereist dat een Access Point één specifiek MAC-adres per clientverbinding verifieert. Door echte netwerkoverbrugging kunnen meerdere MAC-adressen via één interface worden doorgegeven, wat Wi-Fi AP's doorgaans om veiligheidsredenen weigeren.
• Waarom DHCP mislukt: Een VM die een IP-adres aanvraagt met behulp van DHCP heeft nog geen routeerbaar IP-adres. Het zendt een DHCP uit DISCOVER pakket op de Data Link Layer (Layer 2) met behulp van zijn eigen unieke virtuele MAC-adres. Wanneer de externe DHCP-server antwoordt met een DHCP OFFER, richt het zich op die virtuele MAC. Omdat die secundaire MAC niet is geverifieerd met de Wi-Fi AP, laat de AP (of de forwarding firewall-regels van de host) het niet-geverifieerde retourverkeer vallen, waardoor de DHCP-handshake wordt verbroken.
• Waarom een statisch IP-adres werkt: Bij het toewijzen van een statisch IP-adres omzeilt de VM de noodzaak voor de Layer-2 DHCP-uitzending. De netwerkstack van de hypervisor maakt gebruik van Proxy ARP (MAC-NAT) en standaard Layer-3-routering. De host onderschept het uitgaande verkeer van de VM, leidt dit namens de VM en maskeert het verkeer achter het primaire, geverifieerde MAC-adres van de host. Omdat het verkeer op de juiste manier wordt gerouteerd op laag 3 in plaats van overbrugd op laag 2, stroomt de netwerkcommunicatie.

Deze beperking is niet opgenomen in de huidige documentatie, maar wordt toegevoegd aan de releaseopmerkingen in de volgende release.

Gebruik een van de volgende methoden om dit probleem op te lossen of te omzeilen:

1. Gebruik een NAT-netwerksegment: Als u een heterogene bindingsadapter (gecombineerde Wi-Fi en Ethernet) gebruikt, moet u het virtuele netwerksegment configureren om NAT te gebruiken in plaats van Bridge.
2. Een statisch IP-adres toewijzen: Als een overbrugde netwerkverbinding strikt vereist is op de heterogene binding, wijst u handmatig een statisch IP-adres toe aan de VM. Statische IP-configuraties omzeilen de DHCP-beperking en maken een normale verkeersstroom mogelijk.