Cisco IOS DHCP Relay Agent

[lagapidis (Lazarus Agapidis)]

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:

DHCP Snooping

Hello Manuel Rene describes what option 82 does in this post very well. As to why you should disable option 82, when DHCP snooping is enabled on a switch, option 82 is enabled by default. That is, any DHCP request packets that are sent from a host will enter the switch and will have option 82 information ADDED to the request before it is sent on to the DHCP server. Specifically, enabling DHCP snooping on the switch adds the giaddr value of 0.0.0.0 in the DHCP packet. However, the DHCP server…

DHCP Snooping

Security - Configuring DHCP Snooping  [Support]

I hope this has been helpful!

Laz

[daoudes80 (Daoud A)]

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

[lagapidis (Lazarus Agapidis)]

Hello Daoud

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

Thanks again!

Laz

[shankhar.raaman (Shankar R)]

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

[lagapidis (Lazarus Agapidis)]

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

[jp.savaria (Jean-Philippe Savaria)]

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!

[lagapidis (Lazarus Agapidis)]

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

[rarylson (Rarylson F)]

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).

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.

[lagapidis (Lazarus Agapidis)]

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 ) your message to @ReneMolenaar .

Thanks for your contribution!

I hope this has been helpful!

Laz

[olivier.d19851 (Olivier DONZE)]

Hello,

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

[lagapidis (Lazarus Agapidis)]

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

[san_rohit47 (Rohit Patil)]

Hi Everyone, let’s assume that there are 3 host machines all of them broadcast DHCP discover on lan, when the relay agent converts the broadcast to the unicast but how does the relay agent senda the appropriate offer from DHCP server because Mac address is local to the lan segment? So how does the relay agent router know when host it should send the offer back to?

[lagapidis (Lazarus Agapidis)]

Hello Rohit

The DHCP relay agent uses the GIADDR (Gateway IP Address) field in the DHCP packet to know where to send the DHCP offer back to. When a DHCP relay agent receives a DHCP discover message from a client, it inserts its own IP address (the IP address of the interface that received the DHCP discover message) into the GIADDR field and then forwards the message to the DHCP server.

When the DHCP server receives this message, it uses the GIADDR to determine the subnet from which the request came and the IP address that it should offer. The server then sends a DHCP offer back to the relay agent, again using the GIADDR field to determine where to send it.

The relay agent then broadcasts the offer on the local network, and the client that originally sent the discover message receives it. The client’s MAC address is included in the Client Identifier field of the DHCP packet, so the client knows that the offer is for it, and other hosts know that the offer is not for them.

So, the GIADDR is used so that the DHCP server knows the subnet from which the original request was made (so it knows what IP address to offer, and to what subnet to send the offer). Once the offer gets to the relay agent, it can use the MAC address of the originating host which is found in the Client Identifier Field of the DHCP OFFER message so that the correct host will receive it and process it.

I hope this has been helpful!

Laz