DHCP-Sever

This chapter covers some aspects related to the service dhcp-server tool, which allows you to configure the Dynamic Host Configuration Protocol (DHCP) in OSDx.

DHCP is a network protocol that automatically assigns IP addresses and other network configuration information to devices on a network and manages them. Since you do not need to assign addresses manually, setting up and managing networks can be done more efficiently.

Glossary 

Here you can find some concepts that are useful to understand DHCP components and how the protocol works. These concepts might already be familiar. If so, consider reading Configuration or Examples.

In OSDx, you can configure these 3 components:

Server: this component is in charge of assigning IP addresses to the client.
Client: this component requests an IP address.
Relay agent: this component is necessary when the server and client are not on the same subnet. The core function of this DHCP relay agent is to convert a broadcast DHCP packet into a unicast one, and forward it to a DHCP server.

The 3 components communicate with each other to send messages. The different types of messages are:

Discover: the client sends this message to explore available servers on the same subnet network.
Offer: the sever sends this message to a client as a reply to the discover message previously sent by the client. This message includes details about the network, including the client’s IP address, the subnet mask, the default gateway’s IP address, the DNS IP address, the duration of the IP lease and the IP address of the DHCP server.
Request: the client sends this message to the server as a reply to the offer message previously sent by the server. When the client receives an offer message, it means that there are one or more servers available in the same subnet. The client will request network configuration data including an IP address for itself. If the client has received several offer messages, the client will choose a server and broadcast it using the identifier of the chosen server. If the server receives this message but it has not been chosen, it will delete the stored network configuration data from its memory and stop communicating with the client.
ACK: the server sends this message as a confirmation to the request message sent by the client. If a server receives this message and checks the server identifiers are the same, it means the server has been chosen. The server will send the information provided in the offer message to the client. The client will then configure his interface with this information.
NAK: the server sends this message notifying that the lease requested in the request message is not longer available. This scenario could happen if an authoritative server receives a request message asking for an IP address from a different subnet. The server will send this message saying that this IP address is no longer available.
Decline: the client sends this message as a reply to the ACK message. This happens when the client refuses to use a lease offered by the server for different reasons. For example, this happens when a server offers a lease and the IP address is already assigned to the client (as the client cannot use a duplicated IP address).
Release: the client sends this message to the server to release an IP address.

We can use this service in two different ways, with or without relay. These possibilities and their behavioural differences are described below.

Without relay agent 

This scenario is possible if the DHCP server and the client are in the same subnet. This scenario is made up of two components (server and client) and follows the next 4 steps:

Discover: the client broadcasts a Discover message looking for a server that can give him a lease.
Offer: the server offers a lease to the client.
Request: the client accepts this lease.
ACK: confirmation sent to the client.

With relay agent 

We need a relay agent in cases where the server and the client are not in the same subnet. The relay agent will hop between subnets until it arrives to the DHCP server. In this scenario, we have 3 components: the client, the server and the relay agent. This agent will act as an intermediary between the client and server. The steps are the same as in the scenario with no relay agent, albeit with some little changes. This agent will send the messages received by the client to the server, but in unicast. Between the relay agent and the client, there are 2 different possibilities. If the broadcast flag is enabled, the relay agent will broadcast the message. With this flag disabled, the message will be sent in unicast. In turn, the client will always broadcast the message.

Configuration 

The DHCP-server has several options and features you can customize. The main ones are described below.

Authoritative 

The function of an authoritative DHCP-server is to indicate that it is the primary source for the assignment of leases on a network. When you configure this option, the authorative DHCP server has the power to assign IP addresses on that specific network (whereas other DHCP-servers on the same network cannot). This option can be configured using one of these commands:

set service dhcp-server options authoritative #This will affect to all the servers configured in the OSDx device
set service dhcp-server shared-network example options authoritative #This will affect to all the servers configured inside of the "example" shared network in the OSDx device
set service dhcp-server shared-network example class your-class options authoritative #This will affect to all the servers configured inside of the "your-class" class in the OSDx device
set service dhcp-server shared-network example subnet your-subnet/mask options authoritative #This will affect to all the servers configured inside of the "your-subnet/mask" subnet in the OSDx device

Check-Mac-Address 

The function of this feature is to check the MAC addresses received in DHCP messages. This option checks that the MAC address received in the DHCP packet is the same as the MAC address received in the ethernet header. In cases where the client tries to send malformed or malicious packets, this will act as an extra security option. To explain this feature, we will use the following diagram:

This diagram uses the OSI model and shows what this feature does. This feature checks if the MAC address received between these two layers is the same. If it is not the same, OSDx will send a warning message and will not send any reply to the client.

Note

If there are one or more relay agents between the communications, the MAC addresses received will be different. In this case, OSDx will not send any warning messages and will behave normally.

In OSDx, this can be achieved by entering the following command:

set service dhcp-server check-mac-address

Class 

This option allows OSDx to have different options and pools for different clients. Imagine we have received messages from different clients and one of them has sent an identifier. We want to classify these clients by this identifier, and give them different IP ranges.

Note

There are 3 options to identify a class in OSDx. Ascii, hexadecimal and using regular expressions. The manner in which is done will depend on the identifier sent by the client. Ascii and regular expressions cannot be used for the client’s identifier.

In OSDx, this can be achieved by setting the following commands:

set service dhcp-server shared-network example class your-class class-identifier ascii your-identifier #First we need to identify a class
set service dhcp-server shared-network example subnet your-subnet/mask class your-class start start-range-class stop stop-range-class  #Then we match this class to a pool ranges
set service dhcp-server shared-network example subnet your-subnet/mask start start-range stop stop-range  #Then we configure another pool to the clients that are not identified with "your-identifier"

Tip

You can also use these classes to configure the DHCP options explained in this article.

Failover 

The DHCP failover is a DHCP-server option that allows OSDx to share service availability information and lease settings to clients between two servers. This ensures DHCP services are continuously available to clients.

In OSDx, this can be achieved by entering the following commands:

set service dhcp-server shared-network example subnet your-subnet/mask failover local-address interface-ip-address #This value must be the interface where DHCP-server is listening to
set service dhcp-server shared-network example subnet your-subnet/mask failover name failover-example
set service dhcp-server shared-network example subnet your-subnet/mask failover peer-address peer-ip-address #This value must be the interface where DHCP-server is listening to for peer DHCP-server
set service dhcp-server shared-network example subnet your-subnet/mask failover status primary/secondary

Note

There is a useful operational command

Local-VRF 

Virtual routing and forwarding (VRF) is a technology that enables multiple instances of a routing table to exist in a virtual router and work simultaneously. This feature enhances network connections by allowing the division of network paths without the need for multiple devices (since it automatically separates the traffic).

In OSDx, this can be achieved via the following command:

set service dhcp-server shared-network example local-vrf your-vrf

Note

In OSDx, this technology could be used to configure a DHCP-server. However, not every option and feature can be used when VRF is enabled. Failover cannot be used if VRF is enabled.

One-Lease-Per-Client 

There are some cases where the DHCP-server has more than one lease per client. These scenarios are not common and replicating them is not trivial. This option does not allow it and deletes any duplicate lease for the client. OSDx identifies the clients by their MAC addresses, so this option only allows one lease per MAC address.

In OSDx, this can be achieved by entering the following command:

set service dhcp-server shared-network example subnet your-subnet/mask options one-lease-per-client

Static-Mapping 

This feature allows OSDx to provide a specific IP address to a client. OSDx identifies the clients by their MAC address, allowing leases to be managed using MAC addresses.

In OSDx, this can be achieved by entering the following command:

set service dhcp-server shared-network example subnet your-subnet/mask static-mapping example ip-address your-ip-address
set service dhcp-server shared-network example subnet your-subnet/mask static-mapping example mac-address your-mac-address

Useful Operational Commands 

In OSDx, there are some useful commands for the server and the client. This section will cover of them.

Server 

The DHCP server operational commands are described below:

Show: this command has 3 different options.

Failover: this command will show the different states of the failover option. It will display the option’s role, state and partner state.

Leases: this command will show the leases given by the instance of the server.

Stats: this command will show different statistics related to the available leases belonging to the different instances of the DHCP server.

Clear: this command will clear the leases for the chosen instance.

Client 

The DHCP client operational commands are described below:

Show: this command will show the state of the leases given for a specific interface.

Renew: this command will try to renew the lease given for a specific interface. If not enough time has passed, the lease will not be renewed.

Tip

Sometimes, you can make changes to the DHCP server without them being shown. Try to refresh the interfaces and see if the changes have been successful. Also check whether enough time has passed for the lease to be renewed. On the other hand, if you want to release an IP address, you only need to delete the specific interface:

delete interfaces ethernet <your-interface> address dhcp

Examples 

DHCP-server 

This example shows a simple DHCP-server configuration. It will also show the OSDx client configuration needed to use DHCP.

First, OSDx needs an interface to listen to the messages received:

set interfaces ethernet eth0 address 10.0.0.1/24

Then, we will configure the DHCP server. To configure a server, we will need a shared-network and a subnet with a pool range to give leases to the clients:

set service dhcp-server shared-network example subnet 10.0.0.0/24 start 10.0.0.5 stop 10.0.0.100

Finally, in OSDx, the client may be configured via the following command:

set interfaces ethernet eth0 address dhcp

DHCP-server with VRF 

Despite being similar to the last example, this DHCP server will be configured with VRF.

First, OSDx needs an interface to listen to the messages received. In this special case, we will need this interface and must create a VRF:

set interfaces ethernet eth0 address 10.0.0.1/24
set interfaces ethernet eht0 vrf EXAMPLE-VRF
set system vrf EXAMPLE-VRF

Then, we will configure the DHCP-server. To configure a server, we will need a shared network, a subnet with a pool range to give leases to the clients, and a configured VRF:

set service dhcp-server shared-network example subnet 10.0.0.0/24 start 10.0.0.5 stop 10.0.0.100
set service dhcp-server shared-network example local-vrf EXAMPLE-VRF

Finally, in OSDx, the client may be configured via following command:

set interfaces ethernet eth0 address dhcp

Here, you can find more examples related to service dhcp-server.

DHCP-Sever

Glossary 

Without relay agent 

With relay agent 

Configuration 

Authoritative 

Check-Mac-Address 

Class 

Failover 

Local-VRF 

One-Lease-Per-Client 

Static-Mapping 

Useful Operational Commands 

Server 

Client 

Examples 

DHCP-server 

DHCP-server with VRF 

Command Summary 

Configuration commands 

Operational commands 