DHCP failure on NIC teaming situation

In a lot of cases, InfraSIM runs inside a virtual machine, which is on vmware solution. And you have a robust network, which builds virtual switch on multiple physical adapters to form a NIC teaming. (Reference: VMware Virtual Networking Concepts) This makes qemu (InfraSIM virtual node) fails to get DHCP OFFER packet.

To simplify the model:

• You have a DHCP server, physically connected to your ESXi
• Two physical adapters vmnic0 and vmnic1 compose the vSwitch, that's the so-called NIC teaming
• On the vSwitch a port group exists, no VLAN ID assigned, a virtual machine connects to the port group
• Virtual machine's adapter ens192 connects to a br0 port, and a tap device tap0 is created by qemu bridge helper to transmit ethernet packet between br0 and qemu

You shall encounter the failure, and you can capture packet, by tcpdump on linux and pktcap-uw on vsphere (>=5.5), on every capture point to verfiy this:

• DHCP DISCOVERY: this is a broadcast packet, you see it go along until DHCP server
• DHCP OFFER: this is sent by DHCP server, to offer an available IP to QEMU, in NIC teaming situation, this packet appears at br0 but never goes to tap0
• DHCP REQUEST: suppose to be sent by DHCP client after receiving DHCP OFFER, but you won't see this packet in this case
• DHCP ACK: acknowledge by server that specific IP is reserved, you won't see this packet here too

Without nic teaming, everything goes well:

Trying to figure it out...

P.S. accept promisc mode and forged transimits for nested ESXi from William Lam