When a network is created and DHCP is enabled on a subnet within the network, the network is scheduled to one or more DHCP agents in the environment. In most environments, DHCP agents are configured on controllers or dedicated network nodes. In more advanced environments, such as those utilizing network segments and leaf/spine topologies, DHCP agents may be needed on compute nodes.

A DHCP agent is responsible for creating a local network namespace that corresponds to each network that has been scheduled to that agent. An IP address is then configured on a virtual interface inside the namespace, along with a dnsmasq process that listens for DHCP requests on the network. If a dnsmasq process already exists for the network and a new subnet is added, the existing process is updated to support the additional subnet.

Most instances rely on DHCP to obtain their associated IP address. DHCP follows the following stages:

•  A DHCP client sends a DHCPDISCOVER broadcast packet that requests IP information from a DHCP server.
• A DHCP server responds to the request with a DHCPOFFER packet. The packet contains the MAC address of the instance that makes the request, the IP address, the subnet mask, lease duration, and the IP address of the DHCP server. A Neutron network can be scheduled to multiple DHCP agents simultaneously, and each DHCP server may respond with a DHCPOFFER packet. However, the client will only accept the first one.
• In response to the offer, the DHCP client sends a DHCPREQUEST packet back to the DHCP server, requesting the offered address.
• In response to the request, the DHCP server will issue a DHCPACK packet or acknowledgement packet to the instance. At this point, the IP configuration is complete. The DHCP server sends other DHCP options such as name servers, routes, and so on to the instance.

Network namespaces associated with DHCP servers are prefixed with qdhcp, followed by the entire network ID. DHCP namespaces will only reside on hosts running the neutron-dhcp-agent service. Even then, the network must be scheduled to the DHCP agent for the namespace to be created on that host. In this example, the DHCP agent runs on the controller01 node.

To view a list of namespaces on the controller01 node, use the ip netns list command that's shown here:

The two namespaces listed in the output directly correspond to two networks for which a subnet exists and DHCP is enabled:

An interface exists within the qdhcp namespace for the network MyVLANNetwork, which is used to connect the namespace to the virtual network infrastructure:

The interface ns-6c15d7b8-87 within the namespace is one end of a veth interface. The IP address assigned to the ns-6c15d7b8-87 interface, 192.168.206.2/24, has been automatically assigned by Neutron and was procured from the subnet's allocation pool.

When using the Linux bridge driver, the other end of the interface, known as the peer, is connected to a bridge that corresponds to the network and is represented by the tap6c15d7b8-87 interface, as shown in the following screenshot:

In the preceding screenshot, the bridge labeled brq7745a4a9-68 corresponds to the network MyFlatNetwork, as evidenced by the untagged interface eth2 connected to the bridge. The interface tapd1848f67-2e is the other end of the veth interface which is connected to the DHCP namespace for the network MyFlatNetwork.