1 2 Previous Next 26 Replies Latest reply: Oct 30, 2009 8:10 PM by Scott Morris - CCDE/4xCCIE/2xJNCIE RSS

    DHCP Process

    Haja

       

      Hi!

       

       

      I have a query on DHCP process.

       

       

      In the Network Academy CCNA course, I learnt that the DHCP process is as follow:

       

       

      - Client Discover (Broadcast)

      - Server Offer (Unicast)

      - Client Request (Broadcast)

      - Server Ack (Unicast)

       

       

      However, I recently learnt that in Windows and Linux environment the DHCP process is as follow:

       

       

      - Client Discover (Broadcast)

      - Server Offer (Broadcastt)

      - Client Request (Broadcast)

      - Server Ack (Broadcast)

       

       

      The reason given for this is that the client's TCP/IP is not fully functional till after Server Acknowledgement is received.

       

       

      Why is there a difference between the processes? Hope someone can help me with this problem.

       

       

      Thanks in advance!

       

       

        • 1. Re: DHCP Process
          Conwyn

           

          Hi Haja

           

           

          Here is a Cisco DHCP server in action. Look at the last line

           

           

           

           

           

          Regards Conwyn

           

           

           

           

           

          Router#

          *Mar 1 00:05:03.927: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d

          63.3430.312e.3033.6363.2e30.3030.302d.4661.302f.30 on interface FastEthernet0/0.

          *Mar 1 00:05:03.931: DHCPD: Allocate an address without class information (10.0

          .0.0)

          *Mar 1 00:05:05.931: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d63.343

          0.312e.3033.6363.2e30.3030.302d.4661.302f.30 (10.0.0.2).

          *Mar 1 00:05:05.931: DHCPD: broadcasting BOOTREPLY to client c401.03cc.0000.

          *Mar 1 00:05:05.935: DHCPD: DHCPDISCOVER received from client 0063.6973.636f.2d

          63.3430.312e.3033.6363.2e30.3030.302d.4661.302f.30 on interface FastEthernet0/0.

          *Mar 1 00:05:05.935: DHCPD: Sending DHCPOFFER to client 0063.6973.636f.2d63.343

          0.312e.3033.6363.2e30.3030.302d.4661.302f.30 (10.0.0.2).

          *Mar 1 00:05:05.939: DHCPD: broadcasting BOOTREPLY to client c401.03cc.0000.

          *Mar 1 00:05:06.215: DHCPD: DHCPREQUEST received from client 0063.6973.636f.2d6

          3.3430.312e.3033.6363.2e30.3030.302d.4661.302f.30.

          *Mar 1 00:05:06.219: DHCPD: No default domain to append - abort update

          *Mar 1 00:05:06.219: DHCPD: Sending DHCPACK to client 0063.6973.636f.2d63.3430.

          312e.3033.6363.2e30.3030.302d.4661.302f.30 (10.0.0.2).

          *Mar 1 00:05:06.219: DHCPD: broadcasting BOOTREPLY to client c401.03cc.0000.

           

           

          • 2. Re: DHCP Process
            Scott Morris - CCDE/4xCCIE/2xJNCIE

            It's great to see the DHCP messages, but I know when I was first looking at this stuff they weren't incredibly helpful in the IP exchange part!

             

             

            It is correct that broadcasts are seen through the acknowledgement because up until the time of acceptance, the client really doesn't have an IP address from which to unicast things!

             

             

            Renewals will follow a slightly different process.

             

             

            A great document I had used (hopefully still good link) is http://gaia.cs.umass.edu/ethereal-labs/labs/Ethereal_DHCP.pdf

             

             

            Best of luck!

             

             

            Scott

            • 3. Re: DHCP Process
              B Haines

              Scott,

              Thanks for the link. I am buying that book. It has incredible reviews! Last edition that I was able to locate is 2006 but should be fine as the theory has not really changed. Here is a link for anyone else interested!

               

              http://product.half.ebay.com/Computer-Networking_W0QQprZ50789841QQtgZinfo

              • 4. Re: DHCP Process
                Haja

                Thank you Scott Morris!

                 

                In the excerpt that you shared, the packets captured by ethereal shows that the DHCP process is broadcast regardless of whether it is a server (router) or client. But, Cisco states the replies from the server is unicast. Why is that so? Is it a mistake or is there any other reason for their stand?

                • 5. Re: DHCP Process
                  Conwyn

                   

                  Hi Haja

                   

                   

                  it was my Debug (actually Cisco debug and not Ethereal) rather than Scott's but I would say the book is wrong and it is broadcast.

                   

                   

                  I will let Cisco justify their own textbooks.

                   

                   

                   

                   

                   

                  Regards Conwyn

                   

                   

                  • 6. Re: DHCP Process
                    Haja

                     

                    Thanks Conwyn!

                     

                     

                    • 7. Re: DHCP Process
                      Conwyn

                       

                      Hi Haja

                       

                       

                      All the DHCP traffic below is using broadcast (UDP src=67/8)

                       

                       

                      Regards Conwyn

                       

                       

                      Server

                      *Mar 1 00:15:10.967: IP: s=0.0.0.0 (FastEthernet0/0), d=255.255.255.255, len 604, rcvd 2

                      *Mar 1 00:15:10.967: UDP src=68, dst=67

                      **Mar 1 00:15:12.971: IP: s=10.0.0.1 (local), d=255.255.255.255 (FastEthernet0/0), len 328, sending broad/multicast

                      *Mar 1 00:15:12.971: UDP src=67, dst=68

                      *Mar 1 00:15:13.079: IP: s=0.0.0.0 (FastEthernet0/0), d=255.255.255.255, len 604, rcvd 2

                      *Mar 1 00:15:13.079: UDP src=68, dst=67

                      *Mar 1 00:15:13.083: IP: s=10.0.0.1 (local), d=255.255.255.255 (FastEthernet0/0), len 328, sending broad/multicast

                      *Mar 1 00:15:13.087: UDP src=67, dst=68

                       

                       

                      Client

                      *Mar 1 00:15:10.375: IP: s=0.0.0.0 (local), d=255.255.255.255 (FastEthernet0/0), len 604, sending broad/multicast

                      *Mar 1 00:15:10.375: UDP src=68, dst=67

                      *Mar 1 00:15:12.647: IP: s=10.0.0.1 (FastEthernet0/0), d=255.255.255.255, len 328, rcvd 2

                      *Mar 1 00:15:12.647: UDP src=67, dst=68

                      *Mar 1 00:15:12.651: IP: s=0.0.0.0 (local), d=255.255.255.255 (FastEthernet0/0), len 604, sending broad/multicast

                      *Mar 1 00:15:12.651: UDP src=68, dst=67

                      *Mar 1 00:15:12.771: IP: s=10.0.0.1 (FastEthernet0/0), d=255.255.255.255, len 328, rcvd 2

                      *Mar 1 00:15:12.771: UDP src=67, dst=68

                      *Mar 1 00:15:15.879: %DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/0 assigned DHCP address 10.0.0.4, mask 255.255.255.0, hostname client

                       

                       

                      • 8. Re: DHCP Process
                        Scott Morris - CCDE/4xCCIE/2xJNCIE

                        While it is unfortunate that sometimes books have errors in them, it does indeed happen! My guess is that the person writing did/saw a capture of a re-leasing (takes place half-way through a lease or when you do an ipconfig /renew) which there may well be unicast packets since the client really does have an IP address.

                         

                         

                        Unfortunately that doesn't help us much in learning things from scratch! Another option is to check out RFC 2131 which describes the DHCP process in detail. This may be WAY more than you care to know about, but you can skim through it for the general process.

                         

                         

                        HTH,

                         

                         

                        Scott

                        • 9. Re: DHCP Process
                          vinlata

                          Hi Scott,

                           

                          While going through cisco prep center for my ccent exam this Friday, I got confused about the dhcp process and type of message within the dhcp process.

                           

                          From CBT nugget ccent training video, only the first dhcp discovery from client to server is a broadcast message as the client try to locate its dhcp server, so it broadcast the message to the entire network, the rest of the communication should be a unicast message as both server and client already knew which receipient to send message to, and I agree with that. But on most of other cisco's material saying there are other reply messages from server were also broadcast type, why?

                           

                          Client ------------------------------->Server

                                   dhcp discovery (broadcast)

                              

                                   <-------------------------------

                                   dhcp offer (unicast)

                           

                                   --------------------------------->

                                   dhcp request (unicast)

                                

                                   <--------------------------------

                                    dhcp ack (unicast)

                          • 10. Re: DHCP Process
                            SystemsGM

                            What you must understand is that the DISCOVER is must a BROADCAST, cause it does not know where the DHCP Server MAC address.

                             

                            So you show this info, here is the correct information.

                             

                            - Client Discover (Broadcast) - It does not know where to go for the DHCP

                            - Server Offer (Unicast) - The DHCP server replies, now you know where it is located and the MAC address, so it sends a UNICAST. Server send an address.

                            - Client Request (Unicast) - Same for the second point. The Client then examine the IP ADDRESS and says yes I would like this address, so reply to MAC

                            - Server Ack (Unicast) - Same here it know the MAC for the client so it ACK using UNICAST

                             

                            Remember:

                             

                            Unicast - One to One (Know destination MAC address)

                             

                            Broadcast - One to Many (Don't know destination MAC address)

                            • 11. Re: DHCP Process
                              vinlata

                              your understanding just like mine, but on cisco prep center and cisco tv for ccent https://learningnetwork.cisco.com/docs/DOC-1642, it said dhcp offer message from dhcp server was a broadcast address?

                              • 12. Re: DHCP Process
                                Scott Morris - CCDE/4xCCIE/2xJNCIE

                                Well....  Funny thing about all this.  Check out the debugs above (that Conwyn provided).

                                 

                                Notice that one says it's sending the offer out and lists a specific MAC address (which implies unicast)

                                 

                                The other one sayd it's sending a broadcast packet out, and shows the destination address as 255.255.255.255 (which implies broadcast).

                                 

                                So now you see where the confusion arises and how everyone is all messed up! 

                                 

                                From an IP standpoint, it's a broadcast.  From a MAC-address standpoint it's a unicast.  Now, the big question.  WHY?!?!?

                                 

                                Because.  (just kidding)

                                 

                                Because the original station who asked for an IP address doesn't yet know who it is.  So if a packet (IP) came back destined for the newly assigned IP address, even if the MAC address matched, it would get dropped as "not mine".  But a broadcast received MUST be processed by the stack.

                                 

                                The fact that it's unicast to the MAC just assures you don't confuse any other workstations. 

                                 

                                So NOW we have the whole story and can figure out why some books are misleading but not entirely inaccurate (just not the whole truth!)...

                                 

                                HTH,

                                 

                                Scott

                                • 13. Re: DHCP Process
                                  Martin

                                  I am not sure if this helps:

                                   

                                  DHCP sends broadcast DHCPOFFER per client's request to broadcast IF the server is on the same network.

                                  If the server is on different network, DHCPOFFER is a UNICAST packet to DHCP relay agent on port 67 udp form which DHCPDISCOVER came when hosts initialy did boot up.

                                  • 14. Re: DHCP Process
                                    Scott Morris - CCDE/4xCCIE/2xJNCIE

                                    That is true.  but then the relay agent will follow the same process of L2-unicast/L3-broadcast back to the client.

                                     

                                     

                                     

                                    Scott

                                    1 2 Previous Next