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) protocol in OSDx.

DHCP is a network protocol used to automatically assign and manage IP addresses and other network configuration information to devices on a network. So, you do not need to assign addresses manually, making it more efficient to set up and manage networks.

Glossary 

Here you can find some concepts which are useful to understand how DHCP works and his components. Those concepts might be already familiar. If so, consider going to Configuration or to the Examples.

In OSDx you can configure this 3 components:

Server: this component is in charge of assigning the ip addresses to the client.
Client: this component requests an IP address.
Relay agent: This component is necessary for cases where 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 sent before 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 sent before by the server. When the client receives an offer message, it means that there are one or more servers available in the same subnet. So 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 with the server 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 their memory and will stop the communications between itself and 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 check the server identifiers are the same, it means the server has been chosen. So, the server will sent the information offered in the offer message to the client, then the client will 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, so the server will send this message saying that this IP address is not 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 an the IP address is already assigned in the client, so the client can not use a duplicated IP address.
Release: the client sends this message to the server to release an IP address.

We have two different posibilities to use this service, with or without relay. These possibilities and the differences between their behaviour are described below.

Without relay agent 

This scenario is posible if the DHCP server and the client are in the same subnet. We have two components for this scenario server and client and they will follow the next 4 steps:

Discover: the client broadcast 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 accept 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. So, the relay agent will hop between the subnets until arriving 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 client and server. The steps are the same as in the scenario without this relay agent, but there are 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 enable, the relay agent will broadcast the message and with this flag disabled, the message will be sent in unicast. On the other hand, the client will send the message always in broadcast.

Configuration 

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

Authoritative 

The function of an authoritative DHCP-server is to indicate that it is the primary source for leases assignment on a network. When you configure this option, it means that it has the authority to assign IP addresses on that specific network and that other DHCP-servers should not make assignments on the same network. This option could be configured following 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. So, in cases when the client try 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 this two layers are the same. It they are 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, on this case OSDx will not send any warning message and will beahve as regular situation.

In OSDx, this can be achieved by setting 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. So, we want to classify this 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. This will depend on the identifier sent by the client, ascii and regular expressions could not be used for all 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 this classes to configure the DHCP options explained in this article.

Failover 

The DHCP failover is an option for DHCP-server that allows OSDx to share service availability information and lease settings for clients between two servers. This ensures continuous availability of DHCP service to clients.

In OSDx, this can be achieved by setting 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 usefull 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, as it automatically separates the traffic.

In OSDx, this can be achieved by setting 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, but not every option and feature can be used with VRF enable. Failover can not 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 it is not trivial replicate this scenario. This option does not allow it and release any duplicate lease for the client. OSDx identifies the clients by his MAC address, so this option only allows one lease per MAC address.

In OSDx, this can be achieved by setting 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 give an specific IP address to a client. OSDx identify the clients by his MAC address, so we can manage the leases using MAC addresses.

In OSDx, this can be achieved by setting 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 also for the client. This section will cover some useful operational commands for both components.

Server 

The operational commands for DHCP server are described below:

Show: this command has 3 different options.

Failover: this command will show the differents states of the failover option. It will show his role, his state and his partner state

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

Stats: this command will show differents stats related to the available leases of the different instance of DHCP server.

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

Client 

The operational commands for DHCP client 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, but if not enough time has passed, the lease will not be renewed.

Tip

There are some cases where you make some changes on the DHCP server and you do not see any changes. Try to renew the interfaces and see if your changes are successfull, 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 will show a simple configuration of a DHCP-server and also, will show the configuration for an OSDx client to use DHCP.

First, OSDx needs an interface to listen 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 also 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 could be configured by setting the following command:

set interfaces ethernet eth0 address dhcp

DHCP-server with VRF 

This example is similar to the last example, but there is a difference, this DHCP-server will be configured with VRF.

First, OSDx needs an interface to listen the messages received. For this special case, we will need the interface and also we neet to 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 also the configuration for the 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, the client in OSDx could be configured by setting the 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 