This blog delves into the intricacies of DHCP (Dynamic Host Configuration Protocol) setup within a multi-tenant VXLAN EVPN fabric. VXLAN EVPN offers the capability to segment networks logically within data centers, facilitating the creation of distinct network environments for various tenants. However, the question arises: how can you guarantee that each tenant’s devices seamlessly acquire IP addresses? This is where DHCP becomes indispensable!

In a multi-tenant VXLAN EVPN fabric, maintaining tenant isolation for DHCP services is paramount. It’s imperative to prevent instances where one tenant’s devices inadvertently obtain IP addresses from another tenant’s DHCP server. Option 82 DHCP emerges as a pivotal component, facilitating secure and efficient IP address allocation specifically tailored for tenant devices within the confines of a multi-tenant VXLAN EVPN fabric.

Table of Contents

Assumptions

The information in this document was created from the devices in a CML lab environment.
VxLAN EVPN fabric already configured with VRFs – Green (for shared services), Blue & Orange.
The topology is built on CML.
CML version used for the lab – Version: 2.6.0+build.5.
In a live network environment , ensure that you understand the potential impact of any command or change.

DHCP Configuration

Dynamic Host Configuration Protocol (DHCP), is a client-server protocol that automatically assigns IP addresses and other configuration settings to devices on a network. DHCP relies on broadcast communication, the client broadcasts a DHCP discovery message to find a DHCP server.

The process for DHCP address assignment:

Discovery – DHCP client broadcasts a DHCP DISCOVER message across the network, signaling its requirement for an IP address.
Offer – upon receiving the DHCP DISCOVER message, a DHCP server responds by sending a DHCP OFFER message, suggesting an IP address, subnet mask, default gateway, and additional configuration details.
Request – once the client receives offer from DHCP servers, it selects one and proceeds by sending a DHCP REQUEST message to the server, requesting the configuration that was offered.
Acknowledgement – the server then issues a DHCP ACK message, confirming the lease agreement and providing the final configuration details.

When DHCP clients and servers extend across different subnets or even tenants/VRFs, the standard DHCP process, described above, encounters obstacles. Normally, DHCP operates seamlessly within a single broadcast domain, like a single subnet or VLAN, without requiring any extra configuration or modification of DHCP messages. However, in a multi-tenant setup where DHCP servers cater to multiple subnets, the implementation of a DHCP relay function becomes indispensable.

DHCP relay, in the context of a network, acts as a middleman between DHCP clients and servers when they reside on different network segments. DHCP relay allows devices to intercept DHCP broadcast message, converts the broadcast message into a unicast message, modify them if needed, and then forward them to the server, and vice versa—forwarding DHCP server responses to the clients. DHCP relay plays a crucial role in enabling DHCP functionality.

Using a DHCP server in a multi-tenant VXLAN EVPN fabric with a Distributed Anycast Gateway (DAG) and DHCP relay poses a challenge due to the shared source IP address by multiple network devices for DHCP messages. In this scenario, when a VTEP acts as a DHCP relay, it forwards the client’s DHCP messages to the DHCP server, but typically replaces the source IP in the packet with its own SVI IP address of the network segment. Within a VXLAN EVPN fabric employing a DAG, multiple VTEPs share the same SVI IP (Anycast IP). Consequently, when the DHCP server responds with a DHCP offer or acknowledgment (DHCP ACK), it uses the source IP address it received in the relayed request (the VTEP’s SVI IP). However, due to the shared nature of the SVI IP with DAG, the routing table might not be able to uniquely identify the requesting VTEP. This can result in the DHCP reply being sent to the “closest” Leaf switch instead of the one that originally relayed the request. This situation poses a significant hurdle in DHCP relay functionality.

To address the challenge of DHCP relay in a multi-tenant VXLAN EVPN fabric with a Distributed Anycast Gateway (DAG), here’s an effective strategy:

Unique Loopback Address: Configure a unique loopback interface IP address on each Leaf switch within the relevant VRF (Virtual Routing and Forwarding instance). This loopback address will serve as the source IP for relayed DHCP packets originating from that specific Leaf switch. By using unique loopback addresses, you ensure that each Leaf switch can be uniquely identified in the network.
Option 82: Leverage Option 82 within the relayed DHCP packets in conjunction with the unique loopback address. Option 82, also known as the Relay Agent Information option, provides valuable information for DHCP pool selection and ensures the correct routing of packets within the VXLAN EVPN fabric. Option 82 can include the following information:
- Agent Circuit ID (Suboption 1): Further identifies the specific VTEP within the Leaf switch.
- Agent Remote-ID (Suboption 2): This unique identifier corresponds to the specific Leaf switch that relayed the request.
- VRF name / VPN ID (Suboption 151): Identifies the VXLAN segment / VRF where the client originated the request.
- Link Selection (Suboption 5): Used to identify the DHCP pool from which IP addresses should be assigned.
- Server ID Override (Suboption 11): Used for redirecting DHCP offer and acknowledgment messages to the relay agent, ensuring they are sent back to the correct Leaf switch.

By implementing this strategy, you ensure that DHCP relay functions effectively within your multi-tenant VXLAN EVPN fabric, even in the presence of a Distributed Anycast Gateway (DAG).

DHCP in VxLAN EVPN Fabric — DHCP topology (client and server are on different subnet / VRF)

DHCP Configuration with Client and Server in Different Subnet but in the Same VRF (green vrf)

Configuration Example

!!! Sample configuration of a leaf switch for DHCP address allocation for a client with relay agent
ip dhcp relay information option vpn       ->  injects VRF name/VPN ID as part of option 82
ip dhcp relay information option           ->  enables option 82
!
interface Loopback3                        -> Unique Loop back address to serve as relay agent IP address
  vrf member green
  ip address 10.10.111.3/32 tag 12345
interface Vlan20                           -> VLAN SVI for DHCP server
  no shutdown
  mtu 9216
  vrf member green
  no ip redirects
  ip address 10.10.20.1/24 tag 12345
  fabric forwarding mode anycast-gateway   
!
interface Vlan30                             -> VLAN SVI for DHCP clients 
 no shutdown
  mtu 9216
  vrf member green
  no ip redirects
  ip address 10.10.30.1/24
  fabric forwarding mode anycast-gateway
  ip dhcp relay address 10.10.20.100 
  ip dhcp relay source-interface loopback3   ->  unique Loopback for DHCP relay source
!
!!! Sample DHCP server configuration on IOS-XE catalyst switch

ip dhcp excluded-address vrf green 10.10.30.1 10.10.30.10  -> excluding the first 10 IPs for static assignment
ip dhcp pool 1
 vrf green
 network 10.10.30.0 255.255.255.0
 default-router 10.10.30.1 
!

DHCP Messages

The screenshot of a dhcp process, starting from DHCP client send a discover broadcast message all the way until the client get the IP address.

Step 1: DHCP discover

When a DHCP client, such as a computer or phone, is seeking an IP address, it initiates the process by broadcasting a DHCP Discover message across the network. This message includes the client’s MAC address and signifies its requirement for an IP address.

When the DHCP server is in different subnet, a DHCP relay agent, often a Layer 3 switch configured for DHCP relay, intercepts the broadcasted DHCP Discover message, it may append Option 82 to the message as well. The relay agent transforms the original broadcasted DHCP Discover message into a unicast message directed specifically to the DHCP server. Subsequently, the relay agent forwards the modified message (along with Option 82, if included) to the DHCP server.

Step 2: DHCP offer

Upon receiving the relayed DHCP Discover message, DHCP servers reply to the relay agent’s IP address with a DHCP Offer message. This message includes a proposed IP address, subnet mask, default gateway, and additional configuration details like lease time and DNS server information.

Upon receiving the DHCP Offer message from the DHCP server, the relay agent converts it into a broadcast message and sends it to the requesting client’s Layer 2 segment. This broadcasted DHCP Offer message contains the proposed IP address, subnet mask, default gateway, and other configuration details, ensuring that the client receives the necessary information.

Based on option 82 information and any configured scope mapping, the DHCP server sends a DHCP offer back to the relay agent and then to DHCP client

Step 3: DHCP request

Usually, the client opts for the first DHCP Offer it receives, though other selection mechanisms may be in place. Subsequently, it sends a DHCP Request message back to the selected DHCP server, formally requesting the offered configuration.

The relay agent intercepts the DHCP Request message, it converts the intercepted message from a broadcast to a unicast message and forwards it to the DHCP server. This ensures that the DHCP server receives the request, with the right information, directly and can process it accordingly.

Step 4: DHCP ACK

After receiving the DHCP Request message from the agent/client, the DHCP server responds with a DHCP Acknowledgement (DHCP ACK) message, confirming the lease agreement and furnishing the final configuration details.

Upon intercepting the DHCP ACK message, the relay agent updates it as necessary and forwards it to the requesting client. The client then configures its network interface with the obtained IP address, subnet mask, default gateway, and any other settings received from the DHCP server.

With its network interface configured, the client can now effectively communicate with other devices on the network.

DHCP Acknowledgment message confirming the lease agreement

DHCP Configuration with Client and Server in Different Subnet and VRF

In scenarios where DHCP clients and DHCP servers reside in different tenants/VRFs, the DHCP process follows the same steps as outlined earlier. However, there are slight variations in configuration.

There are two options for configuring a unique IP address for the relay agent:

Unique Loopback IP Address in Each VRF: Assign a unique loopback IP address in each VRF to be used as a relay agent. This approach requires route leaking or external routing to ensure that the loopback IP addresses can reach the DHCP server. While this option provides complete isolation between tenants/VRFs, it may become complex to manage route leaking as the environment grows or the number of tenants/VRFs increases.
Shared Loopback IP Address in the DHCP Server’s VRF: Alternatively, use a single unique loopback IP address in the tenant/VRF where the DHCP server resides. Then, configure the DHCP relay with the command ip dhcp relay address <IP address of the DHCP server> use-vrf <name of the DHCP server VRF> and ip dhcp relay source-interface <the unique loopback interface in the VRF where DHCP server resides> . This option is preferable if all DHCP servers are intended to serve all tenants/VRFs. However, if strict tenant isolation per VRF is required, option 1 would be more suitable.

In summary, option 2 is preferred when DHCP servers are shared among all tenants/VRFs, while option 1 is favored for strict tenant isolation per VRF. A hybrid approach may also be considered based on specific requirements and scenarios.