========== DHCP-Sever ========== .. sidebar:: Contents .. contents:: :depth: 3 :local: This chapter covers some aspects related to the :osdx:cfg:`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. .. image:: no_relay.svg 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. .. image:: relay.svg 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: .. code-block:: none 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: .. image:: check-mac.svg 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: .. code-block:: none 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: .. code-block:: none 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: .. code-block:: none 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: .. code-block:: none 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: .. code-block:: none 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: .. code-block:: none 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: 1. ``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. 2. ``Clear``: this command will clear the leases for the chosen instance. Client ------ The DHCP client operational commands are described below: 1. ``Show``: this command will show the state of the leases given for a specific interface. 2. ``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 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: .. code-block:: none 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: .. code-block:: none 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: .. code-block:: none 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: .. code-block:: none 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: .. code-block:: none 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: .. code-block:: none set interfaces ethernet eth0 address dhcp :doc:`Here `, you can find more examples related to ``service dhcp-server``. Command Summary =============== .. osdx:cmdtree:: cfg :maxdepth: 5 service dhcp-server .. osdx:cmdtree:: op service dhcp-server