Introduction to DHCP

lagapidis · November 30, 2021, 6:50am

Hello Luis

Whenever you have issues with the DHCP process, you must take a look at each step and examine its parameters. Specifically, according to your post, it seems that the DISCOVER, OFFER, and REQUEST have been sent and received successfully, correct? If that is the case, then you must perform a debug at the very next device where you detect a failed process. For example, since your DISCOVER, OFFER, and REQUEST seem all to be sent and received successfully, the next thing you should do is set up a debug at the DHCP server. and check:

That the the REQUEST is successfully received by the server
That the server does respond with an ACK. If not, the debug should tell you why.
If the server does respond, next do a debug at the relay and see if the ACK reaches it. If so, see if it is relayed, and if not, check to see the reason for the failure.
if the relay does send the ACK, go to the client and see if that ACK is received and if not check to see if it is rejected or not.

In other words, trace the path of the expected packets, and see where the failure takes place. The debugs should tell you the reasons for any failure.

It’s interesting to note that since the DISCOVER, OFFER, and REQUEST are successfully sent and received, the issue is most likely not with any network connectivity (routing, VRFs, access lists etc) it is most likely an issue with DHCP and not with the network.

Your final information about the virtual GNS3 PC working is useful. I suspect this may have to do with the way that Cisco creates a client identifier. Since the DHCP clients were the 3754 and the 7200, they may be creating a client ID that is not understandable by the DHCP server. Take a look at the following lesson to see how this can be tweaked, and see if this was indeed the issue:

Let us know how your troubleshooting process is getting along!

I hope this has been helpful!

Laz

kuldip.nanda · April 12, 2023, 8:10pm

Hi,
While making a DHCP pool can I have client identifier as VLAN ID.

Thanks
Kuldip

lagapidis · April 17, 2023, 7:08am

Hello Kuldip

The client identifier within each DHCP pool must be unique. The identifier typically used by DHCP in Ethernet networks is the MAC address of each client. Using the VLAN ID as the client identifier is not practical because if you have more than one client within a VLAN of a particular ID, the VLAN ID is no longer unique to a particular client. Secondly, there is no mechanism to create a direct correspondence between a VLAN ID and a DHCP pool.

However, you can create a single DHCP pool per VLAN ID and you can number your addresses accordingly. For example, if you have five VLANs on a network with IDs of 12, 13, 14, 15, and 16, you can create DHCP pools using the following addresses:

192.168.12.0/24
192.168.13.0/24
192.168.14.0/24
192.168.15.0/24
192.168.16.0/24

In this way, you have a correspondence between the third octet and the VLAN ID being used. Such arrangements have to be configured manually, as there is no methodology to allow this to occur automatically.

I hope this has been helpful!

Laz

sonti444 · October 16, 2023, 5:02pm

Hi Team,

Can you please guide me here as pc’s are not getting ip addresses from infoblox dhcp sever for pXE imaging?

lagapidis · October 19, 2023, 4:40am

Hello Sonti

Without knowing more information about your particular topology, setup, and network environment, the only thing we can recommend is to proceed with the standard troubleshooting steps you would take in many typical network scenarios. Here are some just to get you started

Check the DHCP Server: Make sure that the Infoblox DHCP server is up and running. You can check this by logging into the Infoblox management console.
Verify the Network Connection: Ensure that the PCs are connected to the network and can reach the DHCP server. You can test this by temporarily assigning static IP addresses and pinging the DHCP server from the PCs.
Confirm DHCP Scope: Verify that the DHCP scope on the Infoblox server is correctly configured and has enough free IP addresses to assign to the PCs.
Check PXE Configuration: Make sure that the PXE settings on the PCs are correctly configured. PXE booting requires the PCs to be set to boot from the network in the BIOS settings.
Inspect DHCP Logs: The DHCP server logs and the Event Viewer (Windows PC) or other log viewing utility on the host, can provide valuable information about why the PCs are not getting IP addresses. You can access these logs from the Infoblox management console.
Firewall Settings: Check if any firewall is blocking the DHCP traffic. You need to ensure that ports 67 and 68 are open on the firewall to allow DHCP traffic.

If you’ve checked all these and are still having issues, it would be helpful to have more information about your setup. Please provide any error messages you’re seeing, and details about how your network is configured.

I hope this has been helpful!

Laz

davidilles · November 23, 2023, 5:17pm

Hello, everyone!

The OCGs mention two additional messages in terms of DHCP.

DHCPNAK - Used by the server to decline the client’s requested IP configuration
DHCPINFORM - Used by the client to ask the server for additional configuration parameters.

Where would these two be used specifically? I was always used to only see the first 4 (DORA) and haven’t heard of these before.

Thank you.

David

lagapidis · December 16, 2023, 5:22am

Hello David

What we typically learn about when we study DHCP is indeed the DORA (Discover, Offer, Request, Ack) messages that DHCP uses. These are the messages typically used to assign network parameters (IP address, subnet mask, default gateway and DNS server) to a host. However, DHCP is a much more complex and versatile tool. It can be used to deliver many MANY more parameters, and can thus have many additional operations. This also means that there are many additional message types used for DHCP’s operation. In RFCs 2132, 3203, 4388, 6926, and 7724, you can see up to 18 message types that DHCP uses.

Specifically, for the message types you mention, I detail some of the possible cases where they are used:

DHCPNAK (DHCP Negative Acknowledgement)
- Purpose: This message is sent by the DHCP server to a client in response to a DHCP request from the client, but only under certain conditions where the request cannot be granted. It’s a signal that the client’s request was invalid or inappropriate.
- Typical Use Cases:
  - When the client’s requested IP address is incorrect or is no longer available (for example, it might have been assigned to another device).
  - If the requested network information does not match the current network configuration (like a mismatch in subnet).
- Client’s Response: Upon receiving a DHCPNAK message, the client is expected to restart the configuration process, typically by sending a new DHCPDISCOVER message to initiate the IP address allocation process again.
DHCPINFORM
- Purpose: The DHCPINFORM message is used by DHCP clients to obtain network configuration information from a DHCP server without acquiring an IP address. This is useful in scenarios where the client already has a statically configured IP address but needs other network configuration information from the server.
- Typical Use Cases:
  - Obtaining network configuration details like Domain Name System (DNS) server addresses, default gateway information, or other configuration parameters when the client’s IP address is already fixed.
- Server’s Response: In response to a DHCPINFORM message, the DHCP server sends a DHCPACK message back to the client, but this DHCPACK does not carry any IP address allocation; instead, it contains the requested network configuration information.

Both DHCPNAK and DHCPINFORM contribute to the flexibility and robustness of DHCP, ensuring that clients can efficiently obtain, update, or verify network configuration information in a dynamic network environment.

For more information, take a look at the Wikipedia page about DHCP. I don’t normally link to Wikipedia, but this is an exceptionally good article that includes a multitude of information about DHCP, the message types, the options, and the operation of the protocol. Looking it over, you will quickly realize how intricate and complex DHCP really is.

I hope this has been helpful!

Laz

hemanttolwani1989 · January 11, 2024, 7:33pm

I am confused about which packets are broadcast and unicast in the DHCP DORA process.

As per the wireshark image in Introduction to DHCP, all processes (Discover, Offer, Request, & Ack) have destination IP & destination mac as broadcast.

DORA Packets are Broadcast or unicast, Will it be decided based on Destination IP or Destination mac?

davidilles · January 12, 2024, 2:42pm

Hello Hemant.

Imagine a very simple topology with just a DHCP server and a client (no relay agents).

I am using routers here but imagine that DHCP-CLIENT is an actual computer while DHCP-SERVER is an actual dedicated DHCP server. The DHCP-SERVER has a DHCP pool for the 192.168.1.0/24 IP space.

For the purpose of simplicity, both reside on the same local subnet. Our goal here is to have DHCP-CLIENT obtain an IP address and other parameters automatically from the DHCP server, so I will issue the ip address dhcp command on its G0/0 interface which will trigger the DHCP process.

DHCP-CLIENT(config)#int G0/0
DHCP-CLIENT(config-if)#ip address dhcp

Here’s the Wireshark capture of the DHCP DORA process.

I am getting the same result as you, all messages are being sent as broadcast. Let’s make one thing clear, first.

DHCPDISCOVER and DHCPREQUEST messages are always sent as broadcast.

The purpose of DHCPDISCOVER is to discover any available DHCP servers and since they may reside on the local subnet, they’re sent as broadcast.

The purpose of DHCPREQUEST is to request the IP parameters received from the DHCP server. It’s sent as a reply to the DHCPOFFER message.

This message is also always sent as broadcast. The client here includes the DHCP server from whom it accepted the offerered IP parameters. This is because the client can receive multiple DHCP offers from multiple DHCP servers, so DHCPREQUEST is a way of requesting the offered IP parameters and also informing which server does the client accept the offer from.

Now to answer your question, which packets can be sent as unicast or broadcast? What does it depend on? We both have tried this DHCP process and we both ended up with 4 broadcast messages.

There are two messages which can be sent as unicast or broadcast and those are DHCPOFFER and DHCPACK.

What determines whether these two messages will be as either unicast or broadcast are the DHCP flags contained within the DHCP packet.

RFC2131

   To work around some clients that cannot accept IP unicast datagrams
   before the TCP/IP software is configured as discussed in the previous
   paragraph, DHCP uses the 'flags' field [21].  The leftmost bit is
   defined as the BROADCAST (B) flag.  The semantics of this flag are
   discussed in section 4.1 of this document.  The remaining bits of the
   flags field are reserved for future use.  They MUST be set to zero by
   clients and ignored by servers and relay agents.  Figure 2 gives the
   format of the 'flags' field.

DHCP uses a field called BootP Flag which tell the server whether the client wants it to send its messages (DHCPOFFER, DHCPACK) as unicast or broadcast. From my packet capture, you can see the following DHCPDISCOVER message:
obrázok
The DHCP-CLIENT told the server to send its DHCP messages as broadcast, that’s why the DHCPOFFER and DHCPACK were sent as broadcast.

Here’s another packet capture of a DHCPDISCOVER message (credits to Jeremy’s IT Lab)

Here the client set the BootP flags to unicast, this tells the server that it can sends its DHCP replies by using unicast, so let’s check of the DHCP server’s messages.

We can see that because the BootP flags were set to Unicast, the server sent its DHCPOFFER message as unicast. This will also apply to its DHCPACK message.

Now, why is it that some clients set this flag to broadcast and some to unicast? It has to do with how the device itself can process packets. Some devices cannot accept any unicast packets before they have obtained an IP address so that’s why sometimes broadcast must be used instead of unicast.

Broadcast messages sent from the DHCP server will have the destination IP set to 255.255.255.255 and the destination MAC will be of the client.

Unicast messages sent from the DHCP server will have the destination IP set to the IP that the DHCP server wants to offer to the client and the destination MAC will be of the client.

Summary

DHCPDISCOVER and DHCPREQUEST packets are sent by the client and are always sent as broadcast.
DHCPOFFER and DHCPACK packets are sent by the server and can be sent either as unicast or broadcast as dictated by the client by using the BootP Flag field.

If anything is unclear to you, please let me know.

David

lagapidis · January 15, 2024, 8:08am

Hello Hemant

The DHCP DORA process typically has the DHCPDISCOVER and DHCPREQUEST messages sent as broadcasts while the DHCPOFFER and DHCPACK are unicast. However, this is not a hard and fast rule. It depends highly on the operating system of the devices in question, and how they are set up. Some use unicast, and some use broadcast. Indeed the definition of DHCP gives freedom to implementers to decide what’s best for their equipment.

So it is not unusual to see broadcast messages for all four types of DHCP messages.

Take a look at these NetworkLessons notes on related topics for more information:

I hope this has been helpful!

Laz

lagapidis · January 16, 2024, 5:06am

Hello David

That’s great and well-written information, thanks for sharing that in such detail!

Laz

jamie.ariss · April 19, 2024, 11:26am

The ENARSI exam (as of April 24) may inquire about whether DHCP offers and acknowledgments are transmitted via unicast or broadcast. While this study material depict them as broadcast and it has been discussed above, but it would be good to have a definitive answer, especially considering its potential inclusion in the exam.

According to RFC 2131, it is stated that:

If unicasting is not possible, the message MAY be sent as an IP broadcast using an IP broadcast address (preferably 0xffffffff) as the IP destination address and the link-layer broadcast address as the link-layer destination address.

Based on this, it seems that the preferred method is unicast and my exam-prep material seems to state this too:

lagapidis · April 22, 2024, 4:34am

Hello Jamie

DHCP is a protocol that has some flexibility in whether it uses unicast or broadcast for some of its messages. The responses in the forum are based on what it can actually do.

Discover and Request messages are sent via broadcast. This is because at this stage the client does not have an IP address, so it broadcasts the message to all devices in the network.
Offer and Acknowledgment messages, on the other hand, can be sent via either broadcast or unicast. According to RFC 2131, if the client has not yet received its IP address, the server will send these messages as a broadcast. However, if the client has received its IP address, the server may (and usually will) send these messages as a unicast.

For the purposes of certification, if a specific question is asked about which is used for which message type without discussing exceptions, then the answer would indeed be:

Discover and Request → Broadcast
Offer and Acknowledgement → Unicast

Thanks for pointing that out and helping us to clarify as well!

I hope this has been helpful!

Laz

chaitanyapr1998 · June 13, 2024, 8:51am

Why DHCP option has “magic cookie” ?

lagapidis · June 17, 2024, 5:30am

Hello Chaitanya

In general networking contexts, a “magic cookie” is a unique value or sequence of bytes used to identify, authenticate, or distinguish data in communication protocols. The term is often used to describe a token or identifier that serves a specific purpose.

In the context of DHCP, the magic cookie helps to differentiate DHCP messages from BOOTP messages.

If you look at a DHCP message, you will see that the Magic Cookie is a field found within DHCP messages. For example, the following Wireshark capture shows a DHCP offer message.

Ignore the red boxes for now, and take a look at the Magic Cookie field about halfway down the pane. It says Magic cookie: DHCP.

DHCP messages are formatted in an identical way to BOOTP messages. (DHCP developed from BOOTP). Without the specific magic cookie value, a host would not be able to differentiate between a BOOTP and a DHCP message.

The Magic Cookie is defined as the first 32 bits of the Options field. If those 32 bits are set to 99.130.83.99 (shown in dotted decimal format), then you know that the message must be interpreted as a DHCP message. This is defined in RFC 2131.

In all modern networks, the Magic Cookie is set to this value, because DHCP has replaced BOOTP virtually everywhere.

I hope this has been helpful!

Laz