Piattaforma di automazione Dell: La macchina virtuale NativeEdge non riesce a ottenere l'IP DHCP dal bridge di rete

Quando si incontra la situazione, si osservano le seguenti osservazioni:

• Una VM viene implementata e connessa a un segmento di rete virtuale con bridge utilizzando un'interfaccia di collegamento eterogenea (esempio: Collegamento attivo/di backup mediante wlp6s0 per Wi-Fi e enp3s0 per Ethernet)
• La VM non riesce a ottenere un indirizzo IP utilizzando DHCP.
• All'interno del sistema operativo della VM, lo stato del collegamento di interfaccia è UP (ethtool mostra Link rilevato: Sì)
• Log NetworkManager della VM (utilizzando journalctl -u NetworkManager -f) rivelano il DHCP DISCOVER i pacchetti vengono inviati, ma non DHCP OFFER oppure ACK i messaggi non vengono mai ricevuti.
• L'assegnazione manuale di un indirizzo IP statico alla VM funziona correttamente, consentendo ping esterni e connettività gateway.
• L'utilizzo di un segmento di rete virtuale NAT anziché di un segmento Bridge assegna correttamente un indirizzo IP interno/NAT alla VM utilizzando DHCP.

Il reparto Engineering ha confermato che le schede Bond eterogenee supportano solo la creazione di segmenti di rete virtuale NAT. I segmenti di rete virtuale con bridging su un bond eterogeneo non sono supportati.

Si tratta di una scelta di progettazione deliberata per garantire che l'endpoint NativeEdge si connetta in modo corretto e affidabile alla più ampia varietà possibile di punti di accesso Wi-Fi (AP) di terze parti. Il problema deriva dalle differenze fondamentali nel modo in cui le reti Ethernet standard e 802.11 (Wi-Fi) gestiscono il traffico Layer-2:

• Limitazione del bridging Wi-Fi: Lo standard 802.11 richiede un punto di accesso per autenticare un singolo indirizzo MAC specifico per connessione client. Il vero bridging di rete consente a più indirizzi MAC di passare attraverso un'unica interfaccia, che i punti di accesso Wi-Fi in genere rifiutano per motivi di sicurezza.
• Perché DHCP non riesce: Una VM che richiede un IP tramite DHCP non dispone ancora di un indirizzo IP instradabile. Trasmette un DHCP DISCOVER al livello di collegamento dati (livello 2) utilizzando il proprio indirizzo MAC virtuale univoco. Quando il server DHCP esterno risponde con un DHCP OFFER, si rivolge a quel MAC virtuale. Poiché l'indirizzo MAC secondario non è autenticato con l'access point Wi-Fi, l'access point (o le regole del firewall di inoltro dell'host) elimina il traffico di ritorno non autenticato, interrompendo l'handshake DHCP.
• Perché funziona un IP statico: Quando si assegna un IP statico, la VM ignora la necessità della trasmissione DHCP di livello 2. Lo stack di rete dell hypervisor utilizza Proxy ARP (MAC-NAT) e il routing Layer 3 standard. L'host intercetta il traffico in uscita della VM, lo instrada per conto della VM, mascherando il traffico dietro l'indirizzo MAC primario autenticato dell host. Poiché il traffico viene instradato correttamente al layer 3 anziché con bridge al layer 2, i flussi di comunicazione di rete aumentano.

Non vi è alcuna registrazione di questa limitazione nella documentazione corrente, ma verrà aggiunta alle note di rilascio nella prossima versione.

Per risolvere il problema, utilizzare uno dei seguenti metodi:

1. Utilizzare un segmento di rete NAT: Se si utilizza un adattatore Bond eterogeneo (misto Wi-Fi ed Ethernet), configurare il segmento di rete virtuale in modo che utilizzi NAT anziché Bridge.
2. Assegnare un IP statico: Se è strettamente necessaria una connessione di rete con bridge sul collegamento eterogeneo, assegnare manualmente un indirizzo IP statico alla VM. Le configurazioni IP statiche ignorano la limitazione DHCP e consentono il normale flusso di traffico.