Dell-automatiseringsplattform: NativeEdge VM kan ikke hente DHCP IP fra nettverksbro

Følgende observasjoner ses i møte med situasjonen:

• En virtuell maskin distribueres og kobles til et brokoblet virtuelt nettverkssegment ved hjelp av et heterogent bindingsgrensesnitt (eksempel: Aktiv/backup-obligasjon ved hjelp av wlp6s0 for Wi-Fi og enp3s0 for Ethernet)
• VM-en kan ikke hente en IP-adresse ved hjelp av DHCP.
• Inne i VM-operativsystemet er grensesnittkoblingsstatusen UP (ethtool viser kobling oppdaget: Ja)
• NetworkManager-logger for den virtuelle maskinen (ved hjelp av journalctl -u NetworkManager -f) avsløre DHCP DISCOVER pakker sendes, men ingen DHCP OFFER eller ACK meldinger blir stadig mottatt.
• Manuell tilordning av en statisk IP-adresse til den virtuelle maskinen fungerer uten problemer, og tillater ekstern ping og gateway-tilkobling.
• Hvis du bruker et NAT-virtuelt nettverkssegment i stedet for et brosegment, tilordnes en intern/NAT-IP-adresse til den virtuelle maskinen ved hjelp av DHCP.

Teknisk avdeling har bekreftet at heterogene bindingsadaptere bare støtter oppretting av virtuelle nettverkssegmenter for NAT. Brobaserte virtuelle nettverkssegmenter over et heterogent bånd støttes ikke.

Dette er et bevisst designvalg som er tatt for å sikre at NativeEdge-endepunktet kobles til et bredest mulig utvalg av tredjeparts Wi-Fi-tilgangspunkter (AP-er). Problemet stammer fra de grunnleggende forskjellene i hvordan standard Ethernet- og 802.11 (Wi-Fi)-nettverk håndterer Layer-2-trafikk:

• Begrensning for Wi-Fi-brobygging: 802.11-standarden krever et tilgangspunkt for å autentisere en enkelt, spesifikk MAC-adresse per klienttilkobling. Ekte nettverksbroer lar flere MAC-adresser passere gjennom et enkelt grensesnitt, som Wi-Fi-AP-er vanligvis avviser av sikkerhetsgrunner.
• Hvorfor DHCP mislykkes: En VM som ber om en IP ved hjelp av DHCP, har ennå ikke en rutbar IP-adresse. Den kringkaster en DHCP DISCOVER pakke på datalinklaget (lag 2) ved hjelp av sin egen unike virtuelle MAC-adresse. Når den eksterne DHCP-serveren svarer med en DHCP OFFER, er den rettet mot den virtuelle MAC. Fordi den sekundære MAC ikke er autentisert med Wi-Fi AP, slipper AP (eller vertens brannmurregler for videresending) den ikke-autentiserte returtrafikken, og bryter DHCP-håndtrykket.
• Hvorfor en statisk IP fungerer: Når du tilordner en statisk IP, omgår VM-en behovet for Layer-2 DHCP-kringkasting. Nettverksstakken for hypervisoren bruker Proxy ARP (MAC-NAT) og standard Layer-3-ruting. Verten fanger opp VM-ens utgående trafikk, ruter den på VM-ens vegne, og maskerer trafikken bak vertens primære, godkjente MAC-adresse. Fordi trafikken rutes riktig på lag 3 i stedet for å være brokoblet på lag 2, flyter nettverkskommunikasjonen.

Denne begrensningen finnes ikke i gjeldende dokumentasjon, men den legges til i produktmerknadene i den kommende versjonen.

Hvis du vil løse eller omgå dette problemet, kan du bruke én av følgende metoder:

1. Bruk et NAT-nettverkssegment: Hvis du bruker en heterogen bindekort (blandet Wi-Fi og Ethernet), konfigurerer du det virtuelle nettverkssegmentet til å bruke NAT i stedet for Bridge.
2. Tilordne en statisk IP: Hvis det strengt tatt kreves en nettverkstilkobling på den heterogene bindingen, tilordner du en statisk IP-adresse til den virtuelle maskinen manuelt. Statiske IP-konfigurasjoner omgår DHCP-begrensningen og tillater normal trafikkflyt.