Dell Automation-plattform: Den virtuella datorn NativeEdge kan inte hämta DHCP IP från nätverksbryggan

Följande observationer ses när man stöter på situationen:

• En virtuell dator distribueras och ansluts till ett bryggat Virtual Network segment med hjälp av ett heterogent bindningsgränssnitt (exempel: Aktiv/säkerhetskopierad bindning med wlp6s0 för Wi-Fi och enp3s0 för Ethernet)
• Den virtuella datorn kan inte hämta en IP-adress med DHCP.
• I operativsystemet för den virtuella datorn är gränssnittslänkens status UPP (ethtool visar Länken upptäcktes: Ja)
• NetworkManager-loggar för den virtuella datorn (med journalctl -u NetworkManager -f) avslöjar DHCP DISCOVER paket skickas, men ingen DHCP OFFER eller ACK meddelanden tas emot.
• Manuell tilldelning av en statisk IP-adress till den virtuella datorn fungerar korrekt, vilket tillåter externa pingar och gatewayanslutning.
• Om du använder ett virtuellt NAT-nätverkssegment i stället för ett Bridge-segment tilldelas en intern/NAT IP-adress till den virtuella datorn med hjälp av DHCP.

Teknikerna har bekräftat att heterogena bindningskort endast stöder skapandet av NAT Virtual Network segment. Överbryggade Virtual Network segment över en heterogen bindning stöds inte.

Det här är ett medvetet designval som gjorts för att säkerställa att NativeEdge-slutpunkten kan anslutas till så många Wi-Fi-åtkomstpunkter från tredje part som möjligt. Problemet beror på de grundläggande skillnaderna i hur vanliga Ethernet- och 802.11-nätverk (Wi-Fi) hanterar Layer-2-trafik:

• Wi-Fi-bryggningsbegränsning: 802.11-standarden kräver en åtkomstpunkt för att autentisera en enda, specifik MAC-adress per klientanslutning. Äkta nätverksbryggning gör det möjligt för flera MAC-adresser att passera genom ett enda gränssnitt, vilket Wi-Fi-åtkomstpunkter vanligtvis avvisar av säkerhetsskäl.
• Varför DHCP misslyckas: En virtuell dator som begär en IP-adress med DHCP har ännu ingen dirigerbar IP-adress. Den sänder en DHCP DISCOVER paket på Data Link Layer (Layer 2) med hjälp av sin egen unika virtuella MAC-adress. När den externa DHCP-servern svarar med en DHCP OFFERriktar den in sig på den virtuella MAC-datorn. Eftersom den sekundära MAC-MAC-instansen inte autentiseras med Wi-Fi-åtkomstpunkten släpper åtkomstpunkten (eller värdens brandväggsregler för vidarebefordran) den oautentiserade returtrafiken, vilket bryter DHCP-handskakningen.
• Varför en statisk IP fungerar: När du tilldelar en statisk IP-adress kringgår den virtuella datorn behovet av Layer-2 DHCP-sändningen. Hypervisorns nätverksstack använder Proxy ARP (MAC-NAT) och standard Layer-3-routning. Värden fångar upp den virtuella datorns utgående trafik, dirigerar den för den virtuella datorns räkning och maskerar trafiken bakom värdens primära, autentiserade MAC-adress. Eftersom trafiken dirigeras korrekt på Layer 3 i stället för att bryggas på Layer 2 flödar nätverkskommunikationen.

Det finns inga uppgifter om den här begränsningen i den aktuella dokumentationen, men den läggs till i viktig information i den kommande versionen.

Använd någon av följande metoder för att lösa eller kringgå problemet:

1. Använd ett NAT-nätverkssegment: Om du använder ett heterogent bindningskort (blandat Wi-Fi och Ethernet) konfigurerar du det virtuella nätverkssegmentet så att NAT används i stället för Bridge.
2. Tilldela en statisk IP-adress: Om en bryggad nätverksanslutning är absolut nödvändig på den heterogena bindningen tilldelar du en statisk IP-adress till den virtuella datorn manuellt. Statiska IP-konfigurationer kringgår DHCP-begränsningen och tillåter normalt trafikflöde.