Cisco IOS DHCP Relay Agent

Hi Nilesh,

Yes you can have more than a DHCP server in your network, and normally it should have non-overlapping scopes.
For example:
DHCP server 1: -
DHCP server 2: -

If you want to have 2 different networks with 2 different DHCP servers for each network, it is always recommended to use a VLAN for each of the network.

Not sure what your 2nd question for the secondary IP because I don’t have the full configuration of your router.

Hope this can help.

Thanks Rene!
could you please let me know how to configure the IP helper-address over the tunnel ? in case if I have two routers or more.


Dear Mike,

Such requests of new lessons, you can post them here: Lesson ideas
Lessons ideas will be voted and Rene can pick up the topics and write lessons.


19 posts were merged into an existing topic: Cisco IOS DHCP Relay Agent


I have one doubt :

When a DHCP Server is on the same subnet, only the Discover msg is a broadcast, the offer, request and the ack are unicast. But when the the DHCP Server is on a different subnet and therefore separated by a router, the DORA msgs between the DHCP client and the Relay agent are all broadcast ? and between the Relay agent and the DHCP server all unicast ?

Hello Juan

When the DHCP server is in the same subnet, the following communications take place:

  • DHCPDISCOVER is broadcast on both layer 2 and layer 3 (MAC and IP)
  • DHCPOFFER as a response to the discover is unicast. It uses the MAC address of the original sender as the destination MAC and the proposed IP address as the destination IP (even though the DHCP client does not yet have an IP address assigned. This doesn’t matter since communication is happening at Layer 2 for now since we are on the same subnet)
  • DHCPREQUEST is also broadcast on both Layer 2 and Layer 3. Take a look at this sample wireshark capture of a DHCP Request. Notice the destination MAC and the destination IP are broadcast addresses:
  • DHCPACK from DHCP server to client is also unicast.

Now in the case of a relay agent, refer to the diagram from the lesson. All traffic between the relay agent R1 and the DHCP client H1 remains the same as that described above. However, as stated in the lesson by Rene, the traffic between the R1 and the DHCP server that exists on another subnet is unicast.

I hope this has been helpful!



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!

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!


1 Like

Hi Rene,

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

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!


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?

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
1 Like

Hello Boris

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

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

I hope this has been helpful!


1 Like

Thanks you very much.

Hello Laz

Both explanations have been helpful. Thanks a lot.

1 Like

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

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 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!


1 Like

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


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 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!


1 Like