Dell-automatiseringsplatform: NativeEdge VM kan ikke hente DHCP IP fra netværksbroen

Følgende observationer ses, når man støder på situationen:

• En VM udrulles og forbindes til et broforbundet virtuelt netværkssegment ved hjælp af en heterogen bindingsgrænseflade (eksempel: Aktiv/Backup obligation ved hjælp af wlp6s0 til Wi-Fi og enp3s0 til Ethernet)
• VM'en kan ikke hente en IP-adresse ved hjælp af DHCP.
• Inde i VM-operativsystemet er interfacelinkstatus UP (ethtool viser Link registreret: Ja)
• NetworkManager-logfiler for VM'en (ved hjælp af journalctl -u NetworkManager -f) afslører DHCP DISCOVER Der sendes pakker, men der sendes ingen DHCP OFFER eller ACK Beskeder modtages nogensinde.
• Manuel tildeling af en statisk IP-adresse til VM'en fungerer korrekt, hvilket muliggør eksterne pings og gatewayforbindelse.
• Brug af et virtuelt NAT-netværkssegment i stedet for et Bridge-segment tildeler en intern/NAT-IP-adresse til VM'en ved hjælp af DHCP.

Engineering har bekræftet, at heterogene bindingsadaptere kun understøtter oprettelsen af NAT Virtual Network Segments. Brobyggede virtuelle netværkssegmenter over en heterogen binding understøttes ikke.

Dette er et bevidst designvalg, der er foretaget for at sikre en vellykket og pålidelig NativeEdge-slutpunkt til det bredest mulige udvalg af Wi-Fi-adgangspunkter (AP'er) fra tredjeparter. Problemet skyldes de grundlæggende forskelle i, hvordan standard Ethernet- og 802.11 (Wi-Fi)-netværk håndterer Layer-2-trafik:

• Begrænsning af Wi-Fi-brobygning: 802.11-standarden kræver et adgangspunkt for at godkende en enkelt, specifik MAC-adresse pr. klientforbindelse. Ægte netværksbro gør det muligt for flere MAC-adresser at passere gennem en enkelt grænseflade, som Wi-Fi AP'er typisk afviser af sikkerhedsmæssige årsager.
• Hvorfor DHCP fejler: En VM, der anmoder om en IP ved hjælp af DHCP, har endnu ikke en IP-adresse, der kan dirigeres. Det sender en DHCP DISCOVER på Data Link Layer (Layer 2) ved hjælp af sin egen unikke virtuelle MAC-adresse. Når den eksterne DHCP-server svarer med en DHCP OFFER, er den målrettet mod den virtuelle MAC. Da den sekundære MAC ikke er godkendt med Wi-Fi AP, dropper AP (eller værtens firewallregler for videresendelse) den ikke-godkendte returtrafik, hvilket bryder DHCP-håndtrykket.
• Hvorfor en statisk IP fungerer: Når der tildeles en statisk IP, omgår VM'en behovet for Layer-2 DHCP-udsendelsen. Hypervisorens netværksstak bruger Proxy ARP (MAC-NAT) og standard Layer-3-routing. Værten opfanger VM'ens udgående trafik, dirigerer den på VM'ens vegne og maskerer trafikken bag værtens primære, godkendte MAC-adresse. Da trafikken dirigeres korrekt ved lag 3 i stedet for brobygges ved lag 2, flyder netværkskommunikationen.

Der er ingen registrering af denne begrænsning i den aktuelle dokumentation, men den føjes til produktbemærkningerne i den kommende version.

Du kan løse eller løse problemet ved at bruge en af følgende metoder:

1. Brug et NAT-netværkssegment: Hvis du bruger en heterogen bindingsadapter (blandet Wi-Fi og Ethernet), skal du konfigurere det virtuelle netværkssegment til at bruge NAT i stedet for Bridge.
2. Tildel en statisk IP: Hvis der kræves en broforbundet netværksforbindelse på den heterogene binding, skal du tildele en statisk IP-adresse til VM'en manuelt. Statiske IP-konfigurationer omgår DHCP-begrænsningen og tillader normal trafikstrøm.