Cisco IOS DHCP Relay Agent

gaby.ochoa · June 27, 2019, 12:02am

Hello guys,
I wanted to ask if this “giaddress” is the same as the “Relay agent IP address” on a wireshark capture. I was unable to find the variable called “giaddress” in my discover packet that was relayed to the dhcp server. Thank you!

lagapidis · June 27, 2019, 3:49pm

Hello Martha

Yes, the giaddr is the same as the Relay agent IP address as described in Wireshark. The official name of the field in the DHCP packet is indeed GIADDR as described in RFC 2131, but Wireshark simplifies this by describing what the field contains.

I hope this has been helpful!

Laz

kent2612 · July 25, 2019, 1:32pm

Hi Rene,

Please explain more on the DORA process that involves UDP 67 and UDP 68?
Thanks,

lagapidis · July 26, 2019, 7:52am

Hello Kenneth

During the exchange of DHCP Discovery, Offer, Request, and Acknowledgement (DORA) packets, the communication between the server and the client in this process takes place at various levels of the OSI model. Although DHCP assigned IP (Layer 3) addresses using, in part, MAC (Layer 2) addresses, DHCP is actually an Application layer protocol. The payload of these exchanged packets are found encapsulated within a UDP datagram.

This means that communication that takes place requires addressing at Layer 4, where UDP operates. For this purpose, UDP ports 67 and 68 are used as the server and client ports respectively. So for a Discovery or Request DHCP message, 67 will be the destination port and 68 will be the source port. For Offer and Acknowledgement messages, those ports will be reversed.

This can be more fully understood by examining Wireshark output of DHCP messages. The following is a capture of a DHCP discover message:

Notice that we see Layer 3 IP information, Layer 4 UDP information (with the expected source and destination port numbers), and the Application Layer information found in the Bootstrap Protocol, which is DHCP. (Bootstrap was DHCP’s predecessor, and this name is still there for legacy purposes, whatever that means.)

I suggest you do a search for DHCP messages on cloudshark to further explore the structure of these messages.

I hope this has been helpful!

Laz

bvesel · October 11, 2019, 4:32pm

Hello NetworkLessons Team.

I’m studying DHCP and have got an unusual scenario…“An engineer enables ip helper-address on interface. But the router isn’t forwarding the DHCP packets that it receives on this interface. How the engineer can resolve this issue?”

Perhaps in this scenario any default option on the router is disabled. Any idea?

fugazz · October 11, 2019, 11:11pm

Hello Boris,
the first thing I can think of is to enable the dhcp service using “service dhcp”.

“service dhcp” is enabled by default
“ip helper-address” needs dhcp service to be enabled in order to function

lagapidis · October 14, 2019, 5:22am

Hello Boris

In addition to what @fugazz mentioned, some other things that may cause a DHCP relay agent to fail include:

There must be a route from the IP address of the interface to the DHCP server
The interface must be up and must be configured with an IP address
The ip helper-address address configured must be that of an active DHCP server

I hope this has been helpful!

Laz

bvesel · October 14, 2019, 9:27am

Thanks you very much.

bvesel · October 14, 2019, 9:39am

Hello Laz

Both explanations have been helpful. Thanks a lot.

maritdelange · December 20, 2019, 3:03am

Is there a specific reason why a router forwards the offer and acknowledgement messages from the server as a broadcast?

lagapidis · December 20, 2019, 10:28am

Hello Marit

All of the communication that takes place between the DHCP relay and the DHCP host occur based on the regular DHCP process as described in this lesson:

Based on this lesson, and on how DHCP functions, both the OFFER and the ACK messages of DHCP are broadcast using the 255.255.255.255 IP address. However, it is true that at least the MAC address of the requesting host is known by both the server and the relay agent after the initial DISCOVERY packet is sent. The reasons behind why both the OFFER and the ACK are broadcast rather than unicast is further explained in this post:

I hope this has been helpful!

Laz

maritdelange · December 21, 2019, 12:58am

Thanks, Laz, I missed that post.

shaan129 · April 18, 2020, 7:37pm

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

lagapidis · April 21, 2020, 7:44am

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:

Make sure that the correct VLAN is configured on the trunk interface of the switch, as well as on the subinterface of the router
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.
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

shaan129 · April 24, 2020, 1:23pm

Thank You Laz i tested & its working

Regards
shaan

anjanchandra.in · August 13, 2020, 7:00pm

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.

lagapidis · August 15, 2020, 8:52am

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

victorgarcia3000 · October 23, 2020, 1:05am

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

lagapidis · October 25, 2020, 7:27am

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

speedychuck · December 2, 2020, 8:39pm

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.