VM getting a DHCP address

DHCP requests are broadcast requests sent by the VM to its boradcast domain. If a DHCP server exists in this domain, it will respond back providing a DHCP IP lease following the DHCP protocol. In openstack, the same procedure is followed. A VM starts by sending its DHCP request to its boardcast domain which goes through br-int. Since this is broadcast, it exists br-int as well to br-tun and gets sent to all hosts in the environment using the dedicated tunnel ID for the network.

Once the request reaches the network node, it then reaches a network namespace created specifically to allow the dhcp request to be handled. This DHCP namespace name is qdhcp-{UUID} . The qdhcp namespace looks as follows

Individually, it looks like this

As you can see, the dhcp namespace has a tap interface which is attached to the br-int bridge on the network node. The tap interface is attached to a dnsmasq process. dnsmasq is a service that does manythings (obviously dns included). But it also allows providing dhcp addresses when acting as a dhcp server

On the network node, if you do a ps -ef | grep dns you will see the following

If you would like to see the dhcp namespaces on the network node, you can use ip netns

and if you go inside any of these namespaces, you will see the tap interface that is attached to the dnsmasq process

The IP attached to the dhcp namespace is assigned by default to the tap interface. Note that when you look into the flow rules on br-tun for any compute host, you may find an entry for the MAC address of this tap interface. This is used to prevent sending the dhcp request to every compute host and network host in the environment. Since the flow rules will direct the dhcp request to the VXLAN port that is connecting the compute host to the network node only.