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. A dnsmasq process is spawned in a network namespace that corresponds to 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.
Note
When DHCP is not enabled on a subnet, a dnsmasq process is not spawned. An IP address is still associated with the Neutron port that corresponds to the interface within the instance, however. Without DHCP services, it is up to the user to manually configure the IP address on the interface within the guest operating system through a console session.
Most instances rely on DHCP to obtain their associated IP addresses. DHCP goes through the following stages:
- A DHCP client sends a
DHCPDISCOVERbroadcast packet that requests IP information from a DHCP server. - A DHCP server responds to the request with a
DHCPOFFERpacket. The packet contains the MAC address of the instance that makes the request, IP address, subnet mask, lease duration, and IP address of the DHCP server. A Neutron network can be scheduled to multiple DHCP agents simultaneously, and each DHCP server may respond with aDHCPOFFERpacket. However, the client will only accept the first one. - In response to the offer, the DHCP client sends a
DHCPREQUESTpacket back to the DHCP server, requesting the offered address. - In response to the request, the DHCP server issues a
DHCPACKor 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 begin with qdhcp in their names, followed by the network UUID. 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 this host. In this example, the DHCP agent runs on the controller node.
To view a list of namespaces on the controller node, type ip netns in the host prompt, as follows:
Figure 5.31
The two namespaces correspond to the two networks that DHCP is enabled for:
Figure 5.32
Within the qdhcp namespace, there exists an interface that is used to connect the namespace to the network, as shown in the following figure:
Figure 5.33
The IP address assigned to the interface within the namespace, 192.168.204.50/24, is automatically assigned by Neutron and procured from the subnet's allocation pool.
The ns-971fda0d-ea interface within the namespace is one end of a veth cable. When using the LinuxBridge driver, the other end of the cable is connected to a bridge that corresponds to the network and is represented by the tap971fda0d-ea interface, as shown in the following figure:
Figure 5.34
In the preceding screenshot, the bridge labeled "brq34265955-56" corresponds to the MyUserNetwork network, which is a VXLAN network. The tap971fda0d-ea interface is the other end of the veth cable connected to the DHCP namespace.
To observe an instance requesting a DHCP lease, start a packet capture within the corresponding DHCP network namespace using the following command:
# ip netns exec <namespace> tcpdump -i any -ne port 67 or port 68
As an instance starts up, it will send broadcast packets that will be answered by the DHCP server within the namespace:
Figure 5.35
A similar output can be observed by performing the capture on the tap interface of the instance on the compute node:
Figure 5.36
Using the dhcpdump utility, we can observe a more verbose output of the DHCP lease cycle:
root@controller01:~# ip netns exec qdhcp-34265955-56be-4486-853d-2f0ed5cebb44 dhcpdump -i ns-971fda0d-ea
The DHCPDISCOVER packet is shown in the following figure:
Figure 5.37
The DHCPOFFER packet is as follows:
Figure 5.38
Here's what the DHCPREQUEST packet looks like:
Figure 5.39
Finally, here's the DHCPACK packet:
Figure 5.40
If an instance is unable to procure its address from DHCP, it may be helpful to run a packet capture from various points in the network to see where the request or reply is failing.
Using tcpdump or dhcpdump, one can capture a DHCP request and response packets on the UDP ports, 67 and 68, from the following locations:
- Within the DHCP namespace
- On the physical interface of the network and/or compute nodes
- On the tap interface of the instance
- Within the guest operating system
Further investigation may be required once the node responsible for dropping traffic is identified.