DHCP Relay Configuration in Enterprise SONiC

In modern data center networks, Dynamic Host Configuration Protocol (DHCP) plays a critical role in automating IP address assignment to network devices. However, DHCP’s reliance on broadcast traffic creates challenges in routed environments where broadcast domains are separated by Layer 3 boundaries. This is where DHCP Relay becomes essential.

As someone who’s implemented DHCP Relay across various network platforms, I can attest that Enterprise SONiC provides a robust and flexible implementation that addresses the common challenges network engineers face. In this article, I’ll walk you through the fundamentals of DHCP Relay in SONiC, its configuration options, and some advanced features that make it particularly well-suited for modern data center architectures.

Understanding DHCP Relay

DHCP packets are typically broadcast messages that cannot traverse across different subnets. When DHCP clients and servers reside in different subnets, DHCP Relay agents become necessary to forward these broadcast packets between the networks.

The DHCP Relay agent converts broadcast packets to unicast and forwards them to the DHCP server. This process enables clients to obtain IP addresses from DHCP servers that aren’t on the same subnet.

Figure 1: DHCP Relay operation

As shown in the diagram, the DHCP Relay agent intercepts broadcast DHCP requests from clients, converts them to unicast packets, and forwards them to the configured DHCP server. The server’s response is then relayed back to the client.

Basic DHCP Relay Configuration

In Enterprise SONiC, DHCP Relay is configured at the interface level. This can be a physical interface (Ethernet), a logical interface (VLAN), or a Port-Channel. Here’s the basic syntax for configuring DHCP Relay:

ip dhcp-relay <ipaddr1> { { [ vrf-name <vrfName> ] } { [ <ipaddr2> { [ <ipaddr3> [<ipaddr4> ] ] } ] } }

To remove a DHCP Relay configuration:

no ip dhcp-relay [ <ipaddr1> { [ <ipaddr2> { [ <ipaddr3> [ <ipaddr4> ] ] } ] } ]

Let’s look at a simple example where we configure DHCP Relay on a VLAN interface:

sonic(config)# interface Vlan 100
sonic(conf-if-Vlan100)# ip dhcp-relay 10.3.3.125

This configuration will relay DHCP requests from clients in VLAN 100 to the DHCP server at IP address 10.3.3.125.

Verification Commands

After configuring DHCP Relay, you can verify your configuration using these commands:

show ip dhcp-relay brief
show ip dhcp-relay detailed <interface id>
show ip dhcp-relay statistics

These commands provide information about the DHCP Relay configuration, its operational status, and statistics about relayed packets.

Important Consideration for VXLAN EVPN Fabrics

When implementing DHCP Relay in VXLAN EVPN fabrics, it’s mandatory to assign an IP address (IPv4 or IPv6) on the IRB VLAN (VXLAN VNI VLAN) interface. Without this IP address, the DHCP Relay function won’t work properly in the overlay network.

Advanced DHCP Relay Features

Enterprise SONiC offers several advanced DHCP Relay features that provide flexibility in complex network environments:

Source Interface Selection

By default, the source IP address in relayed packets is automatically determined by the routing stack based on the outgoing interface. However, you can explicitly specify a source interface for DHCP Relay packets:

ip dhcp-relay source-interface { <intfName> | <pchName> | <vlanName> | <loName> }

To remove this configuration:

no ip dhcp-relay source-interface

For example:

sonic(conf-if-Vlan100)# ip dhcp-relay source-interface Loopback1

This configuration ensures that all DHCP packets relayed from VLAN 100 will use the IP address of Loopback1 as the source address.

VRF Support

Enterprise SONiC supports forwarding DHCP client requests to a server located in a different VRF. This is particularly useful in multi-tenant environments where clients and servers might reside in different virtual routing domains.

For example, a client can be connected to an interface in the default/global VRF, while the DHCP server resides in a user VRF. Similarly, a client can be in a user VRF while the server is in the default VRF.

To support such deployments, you can specify the VRF name in which the DHCP server resides:

sonic(conf-if-Ethernet0)# ip dhcp-relay 11.0.0.1 vrf-name VrfRed
sonic(conf-if-Ethernet0)# ip dhcp-relay src-intf Loopback0
sonic(conf-if-Ethernet0)# ip dhcp-relay link-select

In this example, DHCP requests from clients on Ethernet0 will be relayed to the DHCP server at 11.0.0.1 in the VrfRed VRF. The source interface for these relayed packets will be Loopback0, which must belong to VrfRed.

It’s important to note that when clients and servers are in different VRFs, link-selection must be enabled. This ensures that the DHCP server’s response is correctly received by the relay agent.

Option 82 Link-selection Sub-option

In typical DHCP deployments, the ‘giaddr’ field in relayed packets is used both to identify the client subnet and to communicate with the relay agent. However, in networks where clients and servers are in different routing domains, there’s a need to differentiate between the client subnet and the relay agent address.

The link-selection sub-option provides a mechanism to explicitly specify the subnet on which the DHCP client resides, which can be different from the ‘giaddr’ value:

ip dhcp-relay link-select

To remove this configuration:

no ip dhcp-relay link-select

For example:

sonic(conf-if-Ethernet0)# ip dhcp-relay 11.0.0.1 12.0.0.1
sonic(conf-if-Ethernet0)# ip dhcp-relay source-interface Loopback1
sonic(conf-if-Ethernet0)# ip dhcp-relay link-select

In this configuration, the relay agent adds the link-selection sub-option to specify the client subnet, and the DHCP server uses this value (instead of giaddr) to assign the DHCP lease. The relay agent sets the ‘giaddr’ value to its own IP address, which is reachable from the DHCP server.

DHCP Relay with Static Anycast Gateway (SAG)

Static Anycast Gateway allows multiple switches to simultaneously route packets using a common gateway address in an active-active router configuration. Since identical SAG IP addresses are configured on multiple leaf switches, these addresses cannot be used to route DHCP server responses to the correct leaf.

In this scenario, it’s recommended to use the link-selection option with a source interface:

sonic(conf-if-Vlan10)# ip dhcp-relay 172.0.0.1
sonic(conf-if-Vlan10)# ip dhcp-relay source-interface Loopback1
sonic(conf-if-Vlan10)# ip dhcp-relay link-select

In this example, the SAG gateway ‘192.168.0.1’ is configured on VLAN10. For relaying packets to the DHCP server, the ‘giaddr’ is set to the Loopback1 IP address ‘55.55.55.55’. The DHCP server uses the link-selection sub-option to identify the client subnet to be leased. The response from the DHCP server is sent to the Loopback IP, which is unique to the originating leaf switch.

Conclusion

DHCP Relay in Enterprise SONiC provides a comprehensive solution for forwarding DHCP requests across different subnets in modern data center networks. With support for VRF-aware relay, source interface selection, and link-selection sub-options, it addresses the complex requirements of multi-tenant environments and overlay networks.

The configuration is straightforward, with all commands applied at the interface level. The verification commands provide clear visibility into the operational status and statistics of the DHCP Relay function.

When implementing DHCP Relay in VXLAN EVPN fabrics or with Static Anycast Gateway, be sure to follow the specific recommendations to ensure proper operation. With these advanced features, Enterprise SONiC’s DHCP Relay implementation offers the flexibility and functionality needed for modern data center architectures.

• CLOS Architecture in Data Centers with Enterprise SONiC
• Host Attachment Models in Enterprise SONiC: Single-homed, Dual-homed, and ECMP
• Basic Configuration and Management of SONiC Devices
• Zero Touch Provisioning in Enterprise SONiC: Automating Network Deployment
• L2 Switching Configuration in SONiC: VLANs and Port Channels – STORDIS GmbH