Cisco IOS DHCP Relay Agent

Thanks, Laz, I missed that post.

Hi ,

I am practicing same scenario like you have explained but instead i have configured sub interface on the router connecting to the LAN but i do not see machines in LAN fetching the ip from the DHCP Server , i have configured helper ip under the 0.10 & for this testing I have switch now between Router & switch and port between switch & router is trunk on switch end and on router encapsulation enabled
Also i am able to reach 12.2 from the router where DHCP is defined

Regards
shaan

Hello Shaan

Based on your description of your topology, the setup should work correctly. I’m assuming that your subinterface of Fa0/0.10 is on VLAN 10. Based on your description, I’ve prepared the following diagram:

When troubleshooting, test the following:

  1. Make sure that the correct VLAN is configured on the trunk interface of the switch, as well as on the subinterface of the router
  2. Test the subinterface and trunk configuration by statically assigning an IP address to the PC, such as 192.168.12.55 255.255.255.0 and attempt to ping the Fa0/0.10 interface. If it is not successful, then there is a problem with the switch/trunk/router configuration.
  3. If the above test is successful, then you should check the relay agent configuration for correctness, and the operation of the DHCP server.

If you need some additional information about the configuration of subinterfaces, take a look at the following lesson:

I hope this has been helpful!

Laz

1 Like

Thank You Laz i tested & its working

Regards
shaan

1 Like

Hi Rene,
Suppose Host A,B & C connected with Router (R1) in 3 different interfaces. R1 is working as a Relay agent. R1 is connected with 3 different DHCP Servers (D1,D2&D3) to provide IP address to Host A,B &C. I mean A will get IP from D1, B will get from D2 & C will get from D3. I will configure 3 ip helper address in R1. Is this scenario feasible ? If yes then how R1 will map the broadcasts to helper addresses accordingly ?

May be configuring a single server with 3 different pools and using single ip-helper in R1, we can solve it. Or using VLAN, we can solve the problem. But my question is, is the said scenario feasible ? if yes then how ?
Thanks in advance.

Hello Anjan

Yes it is feasible because the IP helper address is configured on each interface. You would configure it like so:

  • Interface GE0/1 on which Host A is connected will have an IP helper address of 10.10.10.10
  • Interface GE0/2 on which Host B is connected will have an IP helper address of 10.10.20.10
  • Interface GE0/3 on which Host C is connected will have an IP helper address of 10.10.30.10

So each host, which belongs to a different subnet, will send their DHCP request, and the interface of the router to which it is attached will forward that request to the appropriate DHCP server.

Now this is not a very scalable solution, as it would require a different physical device for each DHCP server (or at least a different VM if you go virtual). Ideally, your suggestion would be the best, to create a single DHCP server, use the same server as the IP helper address, and simply have 3 different pools. This would solve it because the DHCP request from Host A will include the IP address and subnet mask of the interface on which the helper address is configured, and this subnet will inform the DHCP server from which pool to offer addresses. Introducing VLANs would not make a difference in the DHCP scenario.

I hope this has been helpful!

Laz

HI Laz,
I understand that R1 Relays DHCP messages as unicast, but I did not understand why DHCP Server also replies in unicast mode once it is in the same broadcast domain, I thought DHCP Server would follow DHCP messages as broadcast way.
Can you pls help me with this doubts. Thank you

Victor Hugo

Hello Victor

If the DHCP server is in the same network segment/broadcast domain as the client, then once the server receives the DHCPDISCOVER, it knows the MAC address of the client. This is because the MAC address of the client is used as the source MAC address in the Ethernet header of the DHCPDISCOVER message. Since the DHCP server knows the Layer 2 address of the client, there is no need to send a multicast DHCPOFFER message to the client. It can send a unicast DHCPOFFER message using the MAC address of the client as the destination address. In this case, it doesn’t matter what is found in the IP address fields of the IP header, since this communication is functioning at Layer 2, and such connectivity is achievable within the same network segment.

I hope this has been helpful!

Laz

Hi, I’m trying to figure out an issue with a network I’ve been building. DHCP relay isn’t working.

The vlan which the helper address is enabled on is at remote site. I can see from the debug that the DHCP request is being forwarded as unicast message toward the DHCP server.

The DHCP server is located on a core switch elsewhere, and has DHCP snooping enabled on the interface where the DHCP server is.

The interface which the unicast DHCP messages will reach the remote site through does not have DHCP snooping trust set on it.

This particular core switch is not under my control, and before I contact HQ and ask them I have this question-

Does DHCP snooping trust need to be enabled even on an interface that will be sending/receiving unicast (DHCP Relay) messages?

Thanks in advance.
Charles.

Hello Charles

When a port on a switch is configured as untrusted, then in order for any DHCP packets to be received and processed by that port, they must go through a process called packet validation. This essentially means it examines to see if a packet should be dropped or not. According to this Cisco documentation, one of the validation criteria is the following:

If an untrusted port receives a DHCP packet that includes a relay agent IP address that is not 0.0.0.0, it will be dropped unless that packet includes option 82 information

Now the issue gets a bit more complicated due to that pesky DHCP option 82. Option 82 was originally created in order to provide the DHCP relay agent the ability to identify itself and the client that sent the original unmodified DHCP message. But because option 82 is not always understood by all devices, it is often disabled on the switches.

So to answer your question, you should either have option 82 functioning correctly or disable it on the switch, and ensure that the port is trusted.

Your original question sounds concise and simple, but unfortunately, the answer is somewhat complex. You can find more info on these topics at the following links:

I hope this has been helpful!

Laz

Hello Rene;

I found a bit error in the course of DHCP RELAY AGENT.
on Router 1 when it is typed: show ip interface FastEthernet 0/0 the ip address of this interface must be 192.168.12.2 but it is 192.168.12.1 mentionned. May be a typing error
I say that because on the picture the intherface Fa0/0 of the router R1 has for ip adress 192.168.12.2

1 Like

Hello Daoud

Yes, you are correct, thanks for pointing that out. I will let @ReneMolenaar know to make the change.

Thanks again!

Laz

Hi Rene / Team,

One quick query from my practical experience

In my Company , I have a SVI with DHCP relay Agent Configured. Adding to this, I have QIP Tool for IP Address Mgmt
For the sake of Understanding , I am giving some Dummy Subnet with Vlan:

SVI Vlan 100
IP Address - 1.1.1.0/24

I have 3 Queries:

Case 1:

What would be the case if SVI 100 is configured with 1.1.1.0/24 and the subnet is configured as 1.1.1.0/23 in QIP Tool for respective DHCP Servers… Will the clients get IP Address? If so, what range of IPs would they get?

Case 2:
What would be the case if SVI 100 is configured with 1.1.1.0/24 and the subnet is configured as 1.1.1.0/25 in QIP Tool for respective DHCP Servers… Will the clients get IP Address? If so, what range of IPs would they get?

Case 3: I have multiple DHCP Relay Address configured… Which Relay Agent address would be used first by the SVI to reach the DHCP Server or all Servers would be reached at the same time via broadcast?

Please explain all 3 cases. Thanks

Hello Shankar

In your scenario, the SVI VLAN 100 is the interface that is configured as the relay agent, correct? In other words, the SVI VLAN 100 is on the same broadcast domain as the DHCP clients sending out their requests. In such a case, the SVI VLAN 100 will also necessarily function as the default gateway of the specific subnet, and will thus be responsible for routing all packets destined outside of the local subnet.

Now having said that, it is necessary to make sure that the subnet mask of this interface matches the subnet mask of the DHCP server, or in your case the QIP tool. If it doesn’t, then the subnet mask given to the DHCP client may cause connectivity issues.

In case 1, the DHCP client may be given an address such as 1.1.0.25/23 for example. This however is not on the same subnet as the default gateway SVI VLAN 100, at least from the point of view of the SVI. Therefore there will be connectivity issues when attempting to reach outside of the local subnet.

In case 2, you have a similar problem, but it may not be perceived. In this case, the client would get an IP address somewhere in the range of 1.1.1.0 to 1.1.1.127. This would give it communication with the default gateway without any problems. The problem will arise when the host wants to communicate with other hosts on the subnet with addresses like 1.1.1.135. In such a case, traffic would be sent to the default gateway, since from the point of view of the host, this is outside of its subnet. The default gateway would receive this and simply drop it since it perceives the destination as being on the same subnet.

In both cases 1 and 2, the operation will function, but there will be problems with connectivity.

For case 3, it is indeed possible to configure multiple IP helper addresses. According to Cisco, DHCPDISCOVER messages are sent to all the helper addresses configured on an interface. The client will obtain IP addressing information from whichever DHCP server responds first. It’s a similar situation to having two DHCP servers on the same subnet. It’s not ideal, as this can increase DHCP traffic on a network, but it is doable.

I hope this has been helpful!

Laz

1 Like

Hi,
I have the same use case as you described where you have 3 routers and one of them is the DHCP server.
Issue is with matching the POOL using the GIADDR.
The GUEST subnet is 10.124.190.0 /24

DHCP pool on DHCP router (IOS-XE)
ip dhcp pool GUEST_POOL
 vrf GUEST
 network 10.124.190.0 255.255.255.0
 dns-server 169.255.30.2
 default-router 10.124.190.1

GUEST Interface on R1
interface Vlan1021
 description Configured from Cisco DNA-Center
 mac-address 0000.0c9f.feda
 vrf forwarding GUEST
 ip address 10.124.190.1 255.255.254.0
 ip helper-address 169.255.30.2
 no ip redirects
 ip route-cache same-interface
 no lisp mobility liveness test
 lisp mobility 10_124_190_0-GUEST-IPV4
 no autostate
end

Rechability between R1 vlan 1021 and DHCP
BRSB-02-STACK01#ping vrf GUEST 169.255.30.2 source vlan1021
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 169.255.30.2, timeout is 2 seconds:
Packet sent with a source address of 10.124.190.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
BRSB-02-STACK01#

Log message :
Jun  7 14:53:00.589: DHCPD: FSM state change INVALID
Jun  7 14:53:00.589: DHCPD: Workspace state changed from INIT to INVALID
Jun  7 14:53:00.589: DHCPD: classname not set in msg
Jun  7 14:53:00.589: DHCPD: there is no address pool for 10.124.190.1.
Jun  7 14:53:00.589: DHCPD: there is no address pool for 10.124.190.1.
Jun  7 14:53:00.589: DHCPD: Option 125 not present in the msg.
Jun  7 14:53:00.589: DHCPD: Sending notification of ASSIGNMENT FAILURE:
Jun  7 14:53:00.589:   DHCPD: htype 1 chaddr f64e.89c3.fa67
Jun  7 14:53:00.589:   DHCPD: remote id 020a0000ac13131601000bd6
Jun  7 14:53:00.589:   DHCPD: table id 1 = vrf GUEST
Jun  7 14:53:00.589:   DHCPD: giaddr = 10.124.190.1
Jun  7 14:53:00.589:   DHCPD: interface = GigabitEthernet0/0/1.3030
Jun  7 14:53:00.589: DHCPD: Sending notification of ASSIGNMENT_FAILURE:
Jun  7 14:53:00.589:  DHCPD: due to: NO POOL
Jun  7 14:53:00.589:   DHCPD: htype 1 chaddr f64e.89c3.fa67
Jun  7 14:53:00.589:   DHCPD: remote id 020a0000ac13131601000bd6
Jun  7 14:53:00.589:   DHCPD: table id 1 = vrf GUEST
Jun  7 14:53:00.589:   DHCPD: giaddr = 10.124.190.1
Jun  7 14:53:00.589:   DHCPD: interface = GigabitEthernet0/0/1.3030

Error is NO POOL and I don’t understand why…

Thanks for your help!

Hello Jean-Philippe

It took a while for me to see it, but I finally did. The IP address you have on the interface of R1 is 10.124.190.1 255.255.254.0 whereas the DHCP server pool is a /24 subnet. This mismatch is causing the DHCP server to say “I don’t have a pool on this subnet!” Change the subnet on the interface OR on the pool so that they match and you should be OK.

I hope this has been helpful!

Laz

Hi guys,

I have one question plus one suggestion.

Question: Strange log messages after debug on

I have a completely working environment (with the DHCP server having 2 pools, providing IPs to 2 networks - 1 local, 1 via relay).

Screen Shot 2022-06-14 at 22.47.44

All tests are good and connectivity is perfect. But, for some weird reason, I see 2 messages in the debug log that sounds like errors. Actually, I take a look at the Internet, and they are pretty common. Do you know what do they mean? Are they indicators for something I did wrong, or should I just ignore them?

*Jun 15 01:31:38.582: DHCPD: client's VPN is .
*Jun 15 01:31:38.582: DHCPD: No option 125

Suggestion: Improve the lesson to better explain how the DHCP server knows that there is a relay and it must use an specific pool

After viewing the lesson (actually, viewing the video), I had the understanding that the DHCP server knows what pool to use based solely on the fact it received an unicast package, plus by reading the source IP address in the package.

However, after reading the packet capture, it become much clear that there is a field in the DHCP packet that gives additional information about the relay (“Relay agent IP address”). In this case, I also guess the DHCP server will use the usual “Client IP address” and “Client MAC address” fields to get information regarding the client (it the client L2 information will not be on the UDP/IP layers).

So my suggestion here would be to make explicit on the lesson how the DHCP server knows that there is a relay, and which specific pool to use.

I think the video is pretty good (just misses the explanation about the “Relay agent IP address”, which I also suggest to add to the lesson). But the lesson itself (written article) lacks much more information.

Hello Rarylson

Concerning the first Syslog message *Jun 15 01:31:38.582: DHCPD: client's VPN is . This Syslog message is associated with a feature of DHCP that enables a DHCP server to locate the VPN ID of each client. This particular feature is part of DHCP relay support for MPLS VPN.

Specifically, this information is used by the relay agent to tell the DHCP server the VPN for every DHCP request it passes to the DHCP server. It is also used to forward the DHCP replies that the DHCP server sends back to the DHCP relay agent. The VPN ID configured on the incoming interface (or the VRF name if no VPN ID is configured) is contained in the VPN identifier option.

This information is included as a suboption found within DHCP Option 82. When there is no VLAN ID or VRF designated, then the value of “.” is substituted.

The second Syslog message *Jun 15 01:31:38.582: DHCPD: No option 125 has to do with a vendor-specific feature called Auto Image Update. This is a feature that allows network devices, such as switches, routers, access points, and others, to be able to download an image or firmware upgrade automatically from a server on the network.

Option 125 indicates to the client the IP address of primary and backup TFTP or SCP servers from which a new firmware image and a new configuration file can be downloaded. It is a method by which you can achieve mass deployment and configuration of many devices with automatic upgrading without the need to individually upgrade each individual device.

If this option is not set, the Syslog message will simply inform you of that. So both of these messages are not errors and can be safely ignored.

As for your suggestion, I will “relay” (no pun intended :stuck_out_tongue: ) your message to @ReneMolenaar .

Thanks for your contribution!

I hope this has been helpful!

Laz

Hello,

topology

I have an issue when I try to assign an DHCP IP
address on an interface. Bascially, the topology is the following: DHCP Server - DHCP Relay - Two DHCP Clients. The DHCP Relay & the Two DHCP Clients are in a full mesh (with the DHCP Server connected to the DHCP Relay only).

My DHCP client receives the IP address on the interface facing the DHCP Relay only.
However, the any of my two DHCP Clients can receive an IP address when they face each other (DHCP Client to DHCP Client) and I am not sure how to make that happening… Any help would be welcomed…

I did noted that the DHCP allocation is separate from the routing process. I used EIGRP as the routing protocol; so the DHCP Relay has a route back to the pool on the DHCP server.

I created several pools on the DHCP server and referred the ip helper-address 5.5.5.5 on the DHCP Relay (5.5.5.5 is the IP of a loopback created on the DHCP Server).

Note: I did use the command “service dhcp” on the DHCP server to ensure that the service is on (should be enabled per default); so the DHCP server can listen for any Discover messages.

Going through these steps, I was able to have an IP address assigned on Gi0/0 (1.1.2.1) and Gi0/2 (1.1.3.2) on my DHCP clients. So, the different pools were used to allocate these IP addresses.

However, for some reason, I am missing something… I cannot allocate the ip addresses of the pool INTERNAL4 (network 1.1.4.0 255.255.255.0) on the interfaces Gi0/1 of my DHCP clients… Not sure if this would have to do with the Client Identifier and if I should create a Host Pool… If, I would do that, I would need to get the Client-identifier but the one provided in the command applied on the DHCP server are not from these specific interfaces (show ip dhcp binding). I put the output below… Any help would be appreciated.

Thanks

DHCP Server

ip dhcp excluded-address 1.1.1.252
ip dhcp excluded-address 1.1.2.40
ip dhcp excluded-address 1.1.3.40
!
ip dhcp pool INTERNAL1
network 1.1.1.0 255.255.255.0
default-router 1.1.1.252 <== This is the Relay Gateway
dns-server 150.28.1.1
!
ip dhcp pool INTERNAL2
network 1.1.2.0 255.255.255.0
default-router 1.1.1.252 <== This is the Relay Gateway
dns-server 150.28.1.1
!
ip dhcp pool INTERNAL3
network 1.1.3.0 255.255.255.0
default-router 1.1.1.252 <== This is the Relay Gateway
dns-server 150.28.1.1
!
ip dhcp pool R2_CLIENT_POOL
host 1.1.4.10 255.255.255.0
!
ip dhcp pool INTERNAL4
network 1.1.4.0 255.255.255.0
default-router 1.1.1.252 <== This is the Relay Gateway
dns-server 150.28.1.1
!
interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
interface GigabitEthernet0/1
ip address 1.1.1.253 255.255.255.0
!
router eigrp 1
network 0.0.0.0
eigrp router-id 11.11.11.11

Relay

interface GigabitEthernet0/0
ip address 1.1.2.40 255.255.255.0
ip helper-address 5.5.5.5

interface GigabitEthernet0/1
ip address 1.1.1.252 255.255.255.0

interface GigabitEthernet0/2
ip address 1.1.3.40 255.255.255.0
ip helper-address 5.5.5.5
!
router eigrp 1
network 0.0.0.0

Client R2

interface GigabitEthernet0/0
ip address dhcp
interface GigabitEthernet0/1
ip address dhcp
!
router eigrp 1
network 0.0.0.0

Client R3

interface GigabitEthernet0/1
ip address dhcp
interface GigabitEthernet0/2
ip address dhcp
!
router eigrp 1
network 0.0.0.0

Hello Oliver

Keep in mind that even though the two routers are playing the role of DHCP clients, they are still routers. This means that any DHCP requests sent out by the Gi0/1 interfaces reach the other DHCP client and are dropped. The router receiving DHCP requests on its Gi0/1 interface simply drops them. Remember, DHCP messages are broadcast messages, and remain within the network segment unless you configure a DHCP relay agent.

The solution is to make both clients DHCP relay agents so that they can forward those broadcast DHCP requests to the appropriate DHCP server.

Now this solution is highly irregular and should be used only in the lab. Router interfaces in production environments should have statically assigned addresses. If you do use the relay agent on these interfaces, you are making an interface that has not yet received its IP address become a DHCP relay agent. I don’t know what kind of unpredictable results you may have here, but it could be interesting to find out.

Keep us posted on your progress!

I hope this has been helpful!

Laz