About DHCP in MAAS

Docs
1

Errors or typos? Topics missing? Hard to read? Let us know.

The Dynamic Host Control Protocol (DHCP) enables MAAS to manage bare-metal servers. Lots of MAAS issues result from misunderstanding or misuse of DHCP, so it’s worth an in-depth look. Let’s review DORA, DHCP traffic, DHCP relays, and MAAS DHCP management.

Why DHCP?

DHCP automates IP address assignment for connected devices. Manually configuring IP addresses, subnet masks, gateways, and other network parameters for each device is time-consuming and error-prone. By contract, DHCP dynamically allocates unique IP addresses to devices as they join a network, and reclaims them when the device leave, based on pre-set parameters.

DORA

DHCP uses the DORA protocol, which stands for Discover, Offer, Request, and Acknowledge:

  • Discover (D): When a device connects to a network, it sends out a broadcast request, seeking a DHCP server. The initial DISCOVER message is unique because it doesn’t contain any destination information in its payload.

  • Offer (O): In response, the DHCP server offers an IP address (from its allocated pool) to the requesting device.

  • Request (R): The requesting device acknowledges the offer and claims the IP address by sending a “Request.”

  • Acknowledge (A): Finally, the DHCP server acknowledges the request, removing the offered IP address from its available pool.

The exchange something like this:

image
image482×675 52.2 KB

Besides the standard DORA sequence, there are additional potential responses such as NACK and DECLINE. A DHCP server sends a NACK when the client takes too long to request, and a DECLINE is used if the offered IP configuration doesn’t suit the client. We can safely ignore these infrequent responses for now.

DORA ensures that devices receive unique IP addresses, preventing conflicts and enabling efficient communication on the network.

Note: If you’re using MAAS for your DHCP server (recommended), it employs the next-server parameter to guide machines to their Network Bootstrap Programme (NBP). This parameter specifies the IP of a TFTP or HTTP boot server capable of providing the NBP. It’s advisable to let MAAS manage your DHCP configuration.

DHCP traffic

Let’s take a brief look at a typical DHCP packet exchange, which plays a pivotal role in dynamically assigning IP addresses and network configuration. This process typically unfolds as follows:

# DHCP Discover
Ethernet Header: DA=FF-FF-FF-FF-FF-FF, SA=<Client MAC>
IP Header: SIP=0.0.0.0, DIP=255.255.255.255
DHCP Payload: Client MAC=<Client MAC>

# DHCP Offer
Ethernet Header: DA=FF-FF-FF-FF-FF-FF, SA=<DHCP Server MAC>
IP Header: SIP=<DHCP Server IP>, DIP=255.255.255.255
DHCP Payload: Offered IP=<Offered IP>, Client MAC=<Client MAC>,
Subnet Mask=<Subnet Mask>, Router IP=<Router IP>, 
DNS=<DNS Server 1 IP, DNS Server 2 IP>, IP Lease Time=<Time>s,
DHCP Server Identifier=<DHCP Server IP>

# DHCP Request
Ethernet Header: DA=FF-FF-FF-FF-FF-FF, SA=<Client MAC>
IP Header: SIP=0.0.0.0, DIP=255.255.255.255
DHCP Payload: Client MAC=<Client MAC>, 
Requested IP Address=<Offered IP>, 
DHCP Server Identifier=<DHCP Server IP>

# DHCP Ack
Ethernet Header: DA=FF-FF-FF-FF-FF-FF, SA=<DHCP Server MAC>
IP Header: SIP=<DHCP Server IP>, DIP=255.255.255.255
DHCP Payload: Offered IP=<Offered IP>, Client MAC=<Client MAC>,
Subnet Mask=<Subnet Mask>, Router IP=<Router IP>, 
DNS=<DNS Server 1 IP, DNS Server 2 IP>, IP Lease Time=<Time>s,
DHCP Server Identifier=<DHCP Server IP>

A couple of key insights:

  • In both the OFFER and the ACK messages, the DHCP server provides all necessary configuration parameters, including IP address, subnet mask, router location, DNS server IPs, lease time, and the identity of the DHCP server itself.

  • It’s worth noting that the requesting client refrains from utilising the offered IP address until it receives the ACK message. Even in the DHCP Request, where the client knows the offered IP, the Source IP (SIP) remains 0.0.0.0 until confirmation is received.

With this fundamental understanding of DHCP in place, we can explain how MAAS manages DHCP.

MAAS and DHCP

In the realm of MAAS, DHCP involves two players: the MAAS server itself and the network clients. These clients must implement the DHCP protocol stack, and know what to do with the NEXT-SERVER information:

  • DHCPDiscover: This broadcast message acts as a beacon, signalling the presence of a DHCP server within the MAAS-managed network. Clients initiate this discovery to locate the MAAS DHCP server, a critical step in the provisioning process. Notably, if a client does not receive a DHCP response, it may resort to assigning itself an Automatic Private IPv4 address (APIPA), preserving the integrity of the network.

  • DHCPOffer: The MAAS DHCP server responds to the discovery with an Offer message, extending an IPv4 address lease that goes beyond just the IP address itself. As we’ve explored in previous MAAS discussions, this lease encompasses a rich array of configuration parameters, ensuring that clients are fully equipped for network operation.

  • DHCPRequest: The DHCP exchange within MAAS continues to build, much like a snowball rolling downhill. In this phase, the client responds to the Offer with a formal Request, accepting the offered lease and solidifying its role in the network.

  • DHCPAcknowledgment: If all criteria align when the Request reaches the MAAS DHCP server, it responds with an Acknowledgement. This signifies that the client can lease the provided IP address and associated configuration parameters for a specified duration.

  • DHCPNak: In situations where the client experiences delay or if a different DHCP server has already claimed the offered IP address, the MAAS DHCP server may issue a Nak. This prompts the client to begin the orchestration anew, returning to the Discover stage to ensure network integrity.

  • DHCPDecline: Should a client discover that the offered lease contains configuration settings incompatible with its needs, it retains the option to Decline the offer. This triggers a fresh start, commencing from the Discovery phase.

  • DHCPRelease: When a client concludes its use of an IP address within the MAAS-managed network, it can gracefully exit by sending a Release message. This informs the MAAS DHCP server, enabling it to reclaim the released IP address for future assignments.

  • DHCPInform: In a relatively recent addition, the DHCPInform message allows clients with existing IP addresses to efficiently obtain additional configuration parameters related to their address from the MAAS DHCP server. This feature enhances the flexibility and adaptability of MAAS-managed networks.

It’s crucial to note that, shortly before a lease expires, most DHCP clients within MAAS proactively renew their leases. This typically involves a streamlined exchange between the client and the MAAS DHCP server, usually without a full DORA sequence. Importantly, this renewal process occurs directly between the client and the server, bypassing network-wide broadcasts and ensuring network stability within the MAAS ecosystem.

DHCP IP address allocation in MAAS

In the realm of MAAS, dynamic IP address assignment is a critical aspect of network management. MAAS employs DHCP (Dynamic Host Configuration Protocol) for this purpose, providing three distinct methods of IP address allocation to requesting clients:

  1. Manual or Static Allocation:

    • In this method, the DHCP server, integrated into MAAS, assigns a specific, user-defined IP address to a client.
    • The assigned IP address remains constant until the client actively releases it, ensuring predictability for certain devices within the network.

  2. Dynamic Allocation:

    • MAAS dynamically allocates IP addresses from a defined pool or scope. These addresses can change over time, depending on network dynamics and availability within the scope.
    • Clients may receive different IP addresses during subsequent DHCP requests, offering flexibility and efficient use of available addresses.

  3. Automatic Allocation:

    • This method combines elements of both static and dynamic allocation. MAAS assigns an IP address from its defined scope but maintains a record of the client-to-IP address mapping.
    • When a client initiates a new request, the MAAS DHCP server aims to reassign the same IP address to that specific client, promoting consistency in addressing.

Regardless of the allocation method chosen, the DHCP server’s scope, which defines the range of IP addresses under its control and available for assignment, must be meticulously configured by the user within the MAAS environment.

DHCP, operating within the MAAS ecosystem, operates in a “connectionless” manner, primarily utilising UDP (User Datagram Protocol) for communication. Typically, DHCP messages are transmitted as broadcast packets, targeting no specific device initially. However, these messages rapidly transition to targeted communications. The payload of these messages contains critical information, including the IP address of the DHCP server and the MAC address of the requesting client. This efficient approach reduces the processing burden on other network devices by avoiding the need for complete decoding of every DHCP message. Note that for specific targeting of a UDP packet at a particular server, unicast message types can be employed.

For a DHCP client within MAAS, the prospect of acquiring its previous IP address upon a new request hinges on several factors, including scope, allocation method, network topology, and server authority:

  • Scope Size: A larger scope of addresses within the DHCP server increases the likelihood of the requested address being available again.

  • Allocation Method: The allocation method used by the DHCP server also plays a pivotal role. Static allocation guarantees the same address, automatic allocation makes it highly likely, while dynamic allocation introduces variability that makes predictability impossible.

  • Topology: Network topology is a critical consideration. If the MAAS DHCP server relies on DHCP relays to manage some or all of its addresses, the probability of reusing the same IP address diminishes.

  • Authority: The authority of the DHCP server affects the probability of address reassignment. An authoritative DHCP server, such as the one within MAAS, will respond to any unanswered DHCPDiscover messages but will allocate addresses only from its defined scope.

In the dynamic landscape of MAAS-powered networks, understanding these DHCP allocation methods and their intricacies is paramount to efficient IP address management and network operation.

Multiserver DHCP

In the realm of network management, the coexistence of multiple DHCP (Dynamic Host Configuration Protocol) servers on the same network segment can resemble the clash of titans. Surprisingly, when well-managed, this arrangement can function harmoniously, avoiding conflicts, dropped packets, or IP address request failures. However, the successful operation of multiple DHCP servers within the MAAS ecosystem hinges on understanding and configuring IP address scopes effectively. Let’s delve into this intriguing arena.

IP address scopes: Three configurations to consider

  1. Adjacent Scopes:

    • In this setup, IP addresses are allocated from segments of the same subnet. For instance, one server may oversee the range 192.168.14.2 – 192.168.14.187, while another manages 192.168.14.200 – 192.168.14.247.
    • This is the most common and reliable approach when dealing with multiple DHCP servers in close proximity.

  2. Heterogeneous Scopes:

    • Here, DHCP servers operate on different subnets, such as 192.168.14.2 – .253 for one server and 10.17.22.3 – .98 for another.
    • While feasible, this configuration poses significant setup challenges and complexities in management.

  3. Overlapping Scopes:

    • In this scenario, multiple servers can offer the same IP address, necessitating intricate coordination between DHCP servers to prevent conflicts.
    • Typically, it’s advisable to avoid overlapping scopes in most MAAS applications due to potential complexities.

Adjacent and heterogeneous scopes essentially function similarly. These servers operate independently, serving clients on a first-come, first-served basis from their respective IP address pools.

Understanding the DHCP dance

In this choreography, a DHCP client initiates a DHCPRequest, and one or both servers may respond based on factors like server load and available IP addresses. There’s also the possibility that neither server responds if both have exhausted their address pools. However, with meticulous network planning and designating one server as authoritative, these situations can be minimised or eradicated.

The Solution: Server Conflict Detection (SCD)

In some DHCP implementations, an invaluable feature called Server Conflict Detection (SCD) emerges as the saviour in the clash of titans. SCD leverages ICMP Echo messages (pings) to ascertain whether an IP address is in use before leasing it to a client. When all DHCP servers on a subnet employ SCD, IP address scope overlap becomes a non-issue.

Strikingly, the creators of DHCP themselves recommended ping checks on both ends—in RFC 2131, it’s stated: “As a consistency check, the allocating server SHOULD probe the reused address before allocating the address, e.g., with an ICMP echo request, and the client SHOULD probe the newly received address, e.g., with ARP.”

Despite this, DHCP servers often operate in a loosely-coupled manner, with each server and client independently verifying IP address availability. From an architectural perspective, it might seem logical for DHCP servers to collaborate and coordinate IP address assignments. However, this level of coordination is usually unattainable within a MAAS networking environment, where an external DHCP source beyond the MAAS administrator’s control is often present.

The battle against competing DHCP servers in MAAS

In the world of MAAS, the clash of DHCP servers is a recurring challenge. Instances of multiple DHCP servers on the same subnet, utilising identical scopes or overlapping scopes, can lead to collisions, thwarting devices’ ability to obtain IP addresses. Typically, this manifests as machines that can power on but fail to complete the commissioning process due to DHCP-related IP address conflicts.

MAAS acknowledges this concern and incorporates conflict detection mechanisms. For instance, if MAAS manages a non-empty subnet, it can detect existing IPs and avoid duplicate assignments. However, a couple of caveats exist: when a previously-assigned NIC is inactive, or when at least one rack controller lacks access to the IP-assigned machine, detection may not occur before IP duplication.

Additionally, MAAS monitors the subnet ARP cache’s capacity, rechecking the oldest IPs in the cache to identify available addresses.

Embracing SCD for a smoother experience

To enhance configuration performance, enabling Server Conflict Detection (SCD) across all DHCP providers on the network is beneficial. SCD imposes minimal overhead and offers a significant advantage in preventing DHCP conflicts. In the realm of large, bare-metal networks, DHCP conflicts need not be one of the issues plaguing network administrators. Properly configured and coordinated DHCP servers can facilitate smoother network operation, fostering an environment where the clash of DHCP titans is tamed, and devices obtain IP addresses seamlessly.

DHCP relays

DHCP relays are specialised routers, bridging larger networks. The relay intercepts the DHCPRequest broadcast packet and encapsulates it into a routed unicast packet addressed for the DHCP server on a different network segment. When a DHCPOffer is returned, the relay strips it back into a suitably-constructed broadcast packet. In this way, neither the DHCP server nor the requesting client need know anything about the intervening segments.

2

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.