Dell Automation Platform: NativeEdge VM fails to obtain DHCP IP from network bridge

The following observations are seen when encountering the situation:

• A VM is deployed and connected to a bridged Virtual Network Segment using a heterogeneous bond interface (example: Active/Backup bond using wlp6s0 for Wi-Fi and enp3s0 for Ethernet)
• The VM fails to obtain an IP address using DHCP.
• Inside the VM operating system, the interface link status is UP (ethtool shows Link detected: Yes)
• NetworkManager logs of the VM (using journalctl -u NetworkManager -f) reveal DHCP DISCOVER packets are being sent, but no DHCP OFFER or ACK messages are ever received.
• Manually assigning a static IP address to the VM works successfully, allowing external pings and gateway connectivity.
• Using a NAT virtual network segment instead of a Bridge segment successfully assigns an internal/NAT IP address to the VM using DHCP.

Engineering has confirmed that heterogeneous bond adapters only support the creation of NAT Virtual Network Segments. Bridged Virtual Network Segments over a heterogeneous bond are unsupported.

This is a deliberate design choice made to ensure NativeEdge endpoint successfully and reliably connect to the widest possible variety of third-party Wi-Fi Access Points (APs). The issue stems from the fundamental differences in how standard Ethernet and 802.11 (Wi-Fi) networks handle Layer-2 traffic:

• Wi-Fi Bridging Limitation: The 802.11 standard requires an Access Point to authenticate a single, specific MAC address per client connection. True network bridging allows multiple MAC addresses to pass through a single interface, which Wi-Fi APs typically reject for security reasons.
• Why DHCP Fails: A VM requesting an IP using DHCP does not yet have a routable IP address. It broadcasts a DHCP DISCOVER packet at the Data Link Layer (Layer 2) using its own unique virtual MAC address. When the external DHCP server replies with a DHCP OFFER, it targets that virtual MAC. Because that secondary MAC is not authenticated with the Wi-Fi AP, the AP (or the host's forwarding firewall rules) drops the unauthenticated return traffic, breaking the DHCP handshake.
• Why a Static IP Works: When assigning a Static IP, the VM bypasses the need for the Layer-2 DHCP broadcast. The hypervisor's networking stack uses Proxy ARP (MAC-NAT) and standard Layer-3 routing. The host intercepts the VM's outbound traffic, routes it on the VM's behalf, masking the traffic behind the host's primary, authenticated MAC address. Because the traffic is properly routed at Layer 3 rather than bridged at Layer 2, network communication flows.

There is no record of this limitation in current documentation, but is added to the Release Notes in the upcoming release.

To resolve or work around this issue, use one of the following methods:

1. Use a NAT Network Segment: If using a heterogeneous bond adapter (mixed Wi-Fi and Ethernet), configure the virtual network segment to use NAT instead of Bridge.
2. Assign a Static IP: If a bridged network connection is strictly required on the heterogeneous bond, assign a static IP address to the VM manually. Static IP configurations bypass the DHCP limitation and allow normal traffic flow.