Skip to main content

Destination IP Address of DHCP

When DHCP starts the client has no idea about the network it’s currently on. Some clients may store the IP address they were previously on and send this out with the Discovery and Request packets, but the network is not truly set up until after the server has sent it’s final Ack message.
Because of this the server does not know the network’s true broadcast address, however there is an address mapped for this very purpose.
255.255.255.255
If you run arp -a you will see that every interface has the following mapping
  1. 255.255.255.255 ff-ff-ff-ff-ff-ff static
This means that just like a networks broadcast IP this message will be transmitted to all network adapters on the local network segment.
The DHCP server listens for messages heading for port 67 UDP while the DHCP client listens for messages on port 68 UDP
Lets lake a look at a DORA sequence in Wireshark
  1. 148 16.564069 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0xaccba128
  2. 149 16.592933 192.168.0.1 255.255.255.255 DHCP 590 DHCP Offer - Transaction ID 0xaccba128
  3. 150 16.593516 0.0.0.0 255.255.255.255 DHCP 362 DHCP Request - Transaction ID 0xaccba128
  4. 151 16.652333 192.168.0.1 255.255.255.255 DHCP 590 DHCP ACK - Transaction ID 0xaccba128
So what do we see here. In this case both client and server are using the address 255.255.255.255 as the destination address. The client also sends a transaction ID. When the server broadcasts it’s reply it sends back that same ID so the DHCP client can pick out the response that’s meant for it.
It’s easy to assume then that that is the final answer, HOWEVER it’s not quite there yet.
The client may send a request with the broadcast flag cleared. In this situation the server will actually send the request directly to the network adapter that made the request. This is because the client also sends it’s layer 2 address as part of the DHCP packet.
The server will also set the layer 3 address to the intended IP address of the client. So on the surface our DORA trace now looks like this:
  1. 148 16.564069 0.0.0.0 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0xaccba128
  2. 149 16.592933 192.168.0.1 192.168.0.10 DHCP 590 DHCP Offer - Transaction ID 0xaccba128
  3. 150 16.593516 0.0.0.0 255.255.255.255 DHCP 362 DHCP Request - Transaction ID 0xaccba128
  4. 151 16.652333 192.168.0.1 192.168.0.10 DHCP 590 DHCP ACK - Transaction ID 0xaccba128
Note: that the client still sends to 255.255.255.255 until after the ACK stage.
The DHCP protocol requires that a when a server receives a request it SHOULD respond back with the unicast addresses. But, it does go on to say that if unicast transmission is not possible then such a message MAY be sent back to the client as a broadcast message instead.
So to sum up:
Broadcast flag set:
Both client and server use 255.255.255.255 as the destination address.
Broadcast flag not set.
Client uses 255.255.255.255
Server SHOULD address intended for client.
Finally there’s one more thing to consider. What about when a client that’s connected to a network is renewing it’s IP address?
A DHCP client will try renewing it’s address at time T1 which is typically 50% of the lease time. Because the client knows the address og the DHCP server at this point it will try sending directly to the server and the server will respond directly to the client
  1. 32 6.179740 192.168.0.10 192.168.0.1 DHCP 350 DHCP Request - Transaction ID 0x9c8a32fb
  2. 33 6.215039 192.168.0.1 192.168.0.10 DHCP 590 DHCP ACK - Transaction ID 0x9c8a32fb
The above shows a successful RENEW - note that we don’t go through the full DORA process here.
If the server does not respond to the client, the client will keep attempting retries at smaller and smaller intervals (typically half the time remaining until T2) until the time left until T2 is less than a minute.
Then the client will switch to broadcasting the DHCP request on 255.255.255.255 again. Provided the server responds with an ACK passage before the end of the lease period, then the client will carry on using the address and update the lease.

Popular posts from this blog

UPGRADING EOS in the ARISTA Switches

UPGRADING EOS in the ARISTA Switches: EOS is the Firmware for Arista Switches whereas IOS for Cisco. This blog post shows the detailed procedures to follow and to upgrade the EOS in the Arista Switches. This Post was supports for any platform or the Version you are going to upgrade in the Arista Switches. This Post was divided into three parts : Pre-Upgrade Process Upgrade Process Post-Upgrade Process PRE-UPGRADING-PROCESS: 1       1)        Check the Upgrade Path tool by clicking the below link. https://www.arista.com/en/support/mlag-portal/mlaglist and confirm it is in mlag issu compatible 2)       Check if the  STP agent is restartable by giving the command switch-1# show spanning-tree bridge detail | grep agent Stp agent restartable                      :            True NOTE :    A switch can continue supporting MLAG when its peer is offline if the STP agent is restartable. When one peer is offline, data traffic flows from the devices through the

VPC in Cisco Nexus and Failover scenarios.

Etherchannel is the technology that binds multiple physical links in to the single logical link in the switch which fools the spanning tree to be visible as a single port id instead of multiple physical ports id's this causes all the ports to be in the forward state to pass the traffic without creating the loops in the network. We can configure the etherchannel either through static or dynamic. Static ether channel works by manually binding the physical ports into one logical port, this is not recommended because it is not aware the state of the other end physical ports whereas LACP (Link aggregation control protocol) and PAGP (Port aggregation group protocol) are the two dynamic protocols. LACP is the IEEE standard and the PAGP is the Cisco proprietary protocol, LACP is the most commonly used protocol in the networks it works by negotiating with the other end of the ports and would form the portchannel once the set of parameters match on both ends. We can bind max 16 ports to a si

FORTIGATE ACTIVE PASSIVE UPGRADE

FORTIGATE ACTIVE PASSIVE UPGRADE : This blog post shows the detailed procedures to follow and to upgrade the firmware in the Fortigate Firewall. This Post was supports for any platform or the Version you are going to upgrade in the Fortigate Firewall This Post was divided into three parts : Pre-Upgrade Process Upgrade Process Post-Upgrade Process PRE UPGRADE STEPS: 1   1)     Go to the below website and check the Upgrade Path https://docs.fortinet.com/upgrade-tool 2)        Next Login to the Fortigate Console and check the HA Status ( it is to be In sync and higher Priority enabled for the required primary device) 3)        Login to the Console and give the command Config global – get sys ha status Also check session pickup is in enable to avoid session interruptions in failover. 4)        Download all the Firmware’s and the md5 files in the list and check with the software MD5sum.exe to avoid the download errors. NOTE : Must and should configuration backup have t