DHCP Relay Explained [Configuration Example]
![DHCP Relay Explained [Configuration Example]](https://learnduty.com/wp-content/uploads/2022/10/image-59.png)
Contents
Topology
- GNS3 Lab:
DHCP Relay Configuration
- DHCP Server configuration:
!## DHCP_Server ##
ip dhcp excluded-address 172.29.20.1
!
ip dhcp pool Pool1
network 172.29.20.0 255.255.255.252
interface Ethernet1/0
ip address 172.29.30.1 255.255.255.252
duplex full
ip route 0.0.0.0 0.0.0.0 172.29.30.2- DHCP Relay Agent configuration:
!## DHCP Relay Agent ##
interface Ethernet1/0
ip address 172.29.30.2 255.255.255.252
duplex full
!
interface Ethernet1/1
ip address 172.29.20.1 255.255.255.252
ip helper-address 172.29.30.1
duplex fullDHCP Relay Debug and Verification
We will configure the Client for DHCP and meanwhile, we will run DHCP debug on the DHCP server and the DHCP Relay Agent:
interface Ethernet1/0
ip address dhcp
duplex full
end
*Oct 23 22:26:46.119: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet1/0 assigned DHCP address 172.29.20.2, mask 255.255.255.252, hostname Client- Debug on the Relay Agent:
On the DHCP Relay Agent, we see a notification of DHCP Discover from the client coming on interface Eth1/1, the Relay Agent checks if it has a DHCP pool for 172.29.20.1, which is not the case. So, it forwards it to the DHCP Server.
*Oct 23 22:20:58.843: DHCPD: Sending notification of DISCOVER:
*Oct 23 22:20:58.843: DHCPD: htype 1 chaddr ca03.2484.001c
*Oct 23 22:20:58.847: DHCPD: remote id 020a0000ac1d140111000000
*Oct 23 22:20:58.847: DHCPD: interface = Ethernet1/1
*Oct 23 22:21:00.991: DHCPD: Forwarding reply on numbered intf
*Oct 23 22:21:01.067: DHCPD: there is no pool for 172.29.20.1
*Oct 23 22:21:01.127: DHCPD: Forwarding reply on numbered intf- Debug on the Relay Server:
On the Debug of the DHCP side, we see a variable called GIADDR: 172.29.20.1 which is populated from the DHCP Relay Agent.
DHCP_Server#
*Oct 23 22:27:21.071: DHCPD: Sending notification of DISCOVER:
*Oct 23 22:27:21.071: DHCPD: htype 1 chaddr ca03.2484.001c
*Oct 23 22:27:21.071: DHCPD: remote id 020a0000ac1d1e0110000000
*Oct 23 22:27:21.075: DHCPD: giaddr = 172.29.20.1
*Oct 23 22:27:21.075: DHCPD: interface = Ethernet1/0
*Oct 23 22:27:21.075: DHCPD: Sending notification of DISCOVER:
*Oct 23 22:27:21.079: DHCPD: htype 1 chaddr ca03.2484.001c
*Oct 23 22:27:21.079: DHCPD: remote id 020a0000ac1d1e0110000000
*Oct 23 22:27:21.079: DHCPD: giaddr = 172.29.20.1
*Oct 23 22:27:21.083: DHCPD: interface = Ethernet1/0
*Oct 23 22:27:21.083: DHCPD: FSM state change INVALID
*Oct 23 22:27:21.087: DHCPD: Workspace state changed from INIT to INVALID
*Oct 23 22:27:21.091: DHCPD: Allocated binding 6817EE2C
*Oct 23 22:27:21.091: DHCPD: Adding binding to radix tree (172.29.20.2)
*Oct 23 22:27:21.091: DHCPD: Adding binding to hash tree 6817EE2C
*Oct 23 22:27:21.095: DHCPD:dhcpd_binding_add_to_mac_hash: index- 170 add binding 6817EE2C
*Oct 23 22:27:21.095: DHCPD: assigned IP address 172.29.20.2 to client 0063.6973.636f.2d63.6130.332e.3234.3834.2e30.3031.632d.4574.312f.30.
*Oct 23 22:27:23.139: DHCPD: Sending notification of DISCOVER:
*Oct 23 22:27:23.139: DHCPD: htype 1 chaddr ca03.2484.001c
*Oct 23 22:27:23.143: DHCPD: remote id 020a0000ac1d1e0110000000
*Oct 23 22:27:23.143: DHCPD: giaddr = 172.29.20.1
*Oct 23 22:27:23.147: DHCPD: interface = Ethernet1/0
*Oct 23 22:27:23.227: DHCPD: Found previous binding
*Oct 23 22:27:23.227: DHCPD: FSM state change INVALID
*Oct 23 22:27:23.227: DHCPD: Workspace state changed from INIT to INVALID
*Oct 23 22:27:23.231: DHCPD: Client is connected via Relay
*Oct 23 22:27:23.231: DHCPD: Sending notification of ASSIGNMENT:
*Oct 23 22:27:23.235: DHCPD: address 172.29.20.2 mask 255.255.255.252
DHCP_Server#
*Oct 23 22:27:23.235: DHCPD: htype 1 chaddr ca03.2484.001c
*Oct 23 22:27:23.235: DHCPD: lease time remaining (secs) = 86400
*Oct 23 22:27:23.239: DHCPD: interface = Ethernet1/0
DHCP Relay Wireshark Capture Analysis
- Capture from DHCP Client toward DHCP relay agent (Broadcast):
- Capture the link between DHCP Relay Agent and DHCP Server (Unicast):
The DHCP client broadcasts on the local link; the relay agent receives the broadcast and transmits it to one or more DHCP servers using Unicast. The IP addresses of the DHCP servers are manually configured in the relay agent.
- The relay agent stores its own IP address, from the interface on which it has received the client’s broadcast, in the GIADDR field of the DHCP packet.
- The DHCP server uses the GIADDR-value to determine the subnet, and subsequently the corresponding address pool, from which to allocate an IP address.
- When the DHCP server replies to the client, it sends the reply to the GIADDR address, again using unicast.
- The relay agent then retransmits the response on the local network, using unicast (in most cases) to the newly reserved IP address, in an Ethernet frame directed to the client’s MAC address. The client should accept the packet as its own, even when that IP address is not yet set on the interface. Directly after processing the packet, the client sets the IP address on its interface and is ready for regular IP communication, directly thereafter.
If the client’s implementation of the IP stack does not accept unicast packets when it has no IP address yet, the client may set the broadcast bit in the FLAGS field when sending a DHCPDISCOVER packet. The relay agent will use the 255.255.255.255 broadcast IP address (and the client’s MAC address) to inform the client of the server’s DHCPOFFER.
Note
What we should remember here is that: According to the GIADDR field, the DHCP server assigns an IP address from the appropriate DHCP Pool: the DHCP Server will check its DHCP Pools and find a match between the subnet of the GIADDR with the DHCP pool network and then assign an available IP address from that pool.
GIADDR: is the IP address of the interface on which the DHCP Relay Agent has received the client’s broadcast.
DHCP Relay for Multiple VLANs
We can check this behavior by adding another DHCP client (in another network), also connected to the DHCP Agent:
- Topology:
We add another Pool to the DHCP server configuration:
DHCP_Server(dhcp-config)#ip dhcp pool Pool2
DHCP_Server(dhcp-config)#network 172.29.40.0 255.255.255.0
DHCP Relay configuration for client 2:
interface Ethernet1/2
ip address 172.29.40.1 255.255.255.0
ip helper-address 172.29.30.1
no shutdown
duplex full
end- Verifications:
Client-2(config-if)#
*Mar 1 00:13:10.343: %DHCP-6-ADDRESS_ASSIGN: Interface Ethernet0/0 assigned DHCP address 172.29.40.2, mask 255.255.255.0, hostname Client-2
Client-2#show ip int brief
Interface IP-Address OK? Method Status Protocol
Ethernet0/0 172.29.40.2 YES DHCP up up- Wireshark capture (Relay Agent toward DHCP_Server):
We can see that the DHCP Relay agent has assigned 172.29.40.1 (interface facing client-2) as the GIADDR:
As you already know, the DHCP relay Agent insert the “giaddr” field in the relayed DHCP packets, so that DHCP server can identify the DHCP pool to be used for the client request.
But, in some cases, the GIADDR field can be is missing or zero, or the DHCP relay agent is selecting a specific DHCP Relay source interface. According to what we saw before, this may cause the DHCP server to select wrong DHCP Pool for the client. To avoid this, Option 82 come into play.
Using a specific source interface for the DHCP Relay
If it is required that multiple relay interfaces share the same IP address or if a relay interface does not have routes to DHCP servers or even if you don’t want to route the Clients network toward the DHCP server, you can specify a DHCP Relay source interface by using the command below on cisco IOS:
ip dhcp-relay source-interface loopback 0
interface Loopback0
ip address 1.1.1.1 255.255.255.255Debug and verification:
- Debug on the DHCP Relay Agent:
*Oct 23 23:58:52.507: DHCPD: Sending notification of DISCOVER:
*Oct 23 23:58:52.511: DHCPD: htype 1 chaddr cc07.31a8.0000
*Oct 23 23:58:52.511: DHCPD: remote id 020a0000ac1d280112000000
*Oct 23 23:58:52.511: DHCPD: interface = Ethernet1/2
*Oct 23 23:58:52.519: DHCPD: giaddr changed to 1.1.1.1
*Oct 23 23:58:52.579: DHCPD: Forwarding reply on numbered intf
*Oct 23 23:58:52.647: DHCPD: there is no pool for 172.29.40.1.- Debug on the DHCP Server:
*Oct 24 00:05:18.911: DHCPD: Sending notification of DISCOVER:
*Oct 24 00:05:18.911: DHCPD: htype 1 chaddr cc07.31a8.0000
*Oct 24 00:05:18.911: DHCPD: remote id 020a0000ac1d280112000000
*Oct 24 00:05:18.915: DHCPD: giaddr = 1.1.1.1
*Oct 24 00:05:18.915: DHCPD: interface = Ethernet1/0
*Oct 24 00:05:18.915: DHCPD: Sending notification of DISCOVER:
*Oct 24 00:05:18.919: DHCPD: htype 1 chaddr cc07.31a8.0000
*Oct 24 00:05:18.919: DHCPD: remote id 020a0000ac1d280112000000
*Oct 24 00:05:18.919: DHCPD: giaddr = 1.1.1.1
*Oct 24 00:05:18.923: DHCPD: interface = Ethernet1/0
*Oct 24 00:05:18.927: DHCPD: Found previous server binding
*Oct 24 00:05:19.003: DHCPD: Found previous binding
*Oct 24 00:05:19.007: DHCPD: Client is connected via Relay
*Oct 24 00:05:19.007: DHCPD: Sending notification of ASSIGNMENT:
*Oct 24 00:05:19.011: DHCPD: address 172.29.40.2 mask 255.255.255.0
*Oct 24 00:05:19.011: DHCPD: htype 1 chaddr cc07.31a8.0000
*Oct 24 00:05:19.015: DHCPD: lease time remaining (secs) = 86400
*Oct 24 00:05:19.015: DHCPD: interface = Ethernet1/0From the Debug, we see that the giaddr is 1.1.1.1 which is the DHCP relay source interface Looback0 specified in the command: ip dhcp-relay source-interface loopback 0.
But, how does the server knows the appropriate DHCP pool if the source interface is not relevant, as a result, the DHCP server cannot choose the Pool based on the GIADDR. Well, Option 82 takes precedence in this case.
Let’s see it more clearly in the Wireshark capture:
- Capture the link between DHCP client and the DHCP Relay agent:
Well, there is nothing special in this capture, just a broadcast of DHCP Discover/Request packets from the client and DHCP Offer and Ack from the Relay Agent.
- Capture the link between DHCP Relay Agent and the DHCP Server:
In this capture:
- We see that the GIADDR is 1.1.1.1 which is the Loopback0 address (DHCP Relay source interface)
- Option 82 Subtion, Link selection is 172.29.40.1 which is the interface corresponding to the client in the DHCP agent.
According to the DHCP Suboption 150, the DHCP will choose the correct DHCP Pool and assign an available address to the client.
To discuss further the use cases of the DHCP Option 82, please refer to the following Post.
