Skip navigation
Login   |   Register
Cisco Learning Home > Certifications > Routing & Switching (CCNA) > Discussions

_Communities

This Question is Answered 1 Helpful Answer available (2 pts)
23503 Views 26 Replies Latest reply: Oct 30, 2009 8:10 PM by Scott Morris - CCDE/4xCCIE/2xJNCIE RSS 1 2 Previous Next

Currently Being Moderated

DHCP Process

Oct 30, 2008 7:24 AM

Haja 3 posts since
Jul 9, 2008

 

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!

 

 

  • Conwyn 9,677 posts since
    Sep 10, 2008
    Currently Being Moderated
    1. Oct 30, 2008 7:48 AM (in response to Haja)
    Re: DHCP Process

     

    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.

     

     

    Join this discussion now: Login / Register
  • Scott Morris - CCDE/4xCCIE/2xJNCIE 8,427 posts since
    Oct 7, 2008
    Currently Being Moderated
    2. Oct 28, 2009 5:13 PM (in response to Conwyn)
    Re: DHCP Process

    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

    Join this discussion now: Login / Register
  • B Haines 660 posts since
    Jun 28, 2008
    Currently Being Moderated
    Re: DHCP Process

    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

    Join this discussion now: Login / Register
  • Conwyn 9,677 posts since
    Sep 10, 2008
    Currently Being Moderated
    5. Nov 6, 2008 5:30 AM (in response to Haja)
    Re: DHCP Process

     

    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

     

     

    Join this discussion now: Login / Register
  • Conwyn 9,677 posts since
    Sep 10, 2008
    Currently Being Moderated
    7. Nov 6, 2008 6:30 AM (in response to Haja)
    Re: DHCP Process

     

    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

     

     

    Join this discussion now: Login / Register
  • Scott Morris - CCDE/4xCCIE/2xJNCIE 8,427 posts since
    Oct 7, 2008
    Currently Being Moderated
    8. Oct 29, 2009 10:43 AM (in response to Conwyn)
    Re: DHCP Process

    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

    Join this discussion now: Login / Register
  • vinlata 107 posts since
    Aug 19, 2009
    Currently Being Moderated
    Re: DHCP Process

    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)

    Join this discussion now: Login / Register
  • SystemsGM 96 posts since
    Sep 6, 2009
    Currently Being Moderated
    10. Oct 28, 2009 4:56 PM (in response to Haja)
    Re: DHCP Process

    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)

    Join this discussion now: Login / Register
  • vinlata 107 posts since
    Aug 19, 2009
    Currently Being Moderated
    11. Oct 28, 2009 5:07 PM (in response to SystemsGM)
    Re: DHCP Process

    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?

    Join this discussion now: Login / Register
  • Scott Morris - CCDE/4xCCIE/2xJNCIE 8,427 posts since
    Oct 7, 2008
    Currently Being Moderated
    12. Oct 28, 2009 5:51 PM (in response to SystemsGM)
    Re: DHCP Process

    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

    Join this discussion now: Login / Register
  • Martin 13,898 posts since
    Jan 16, 2009
    Currently Being Moderated
    13. Oct 28, 2009 6:28 PM (in response to Haja)
    Re: DHCP Process

    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.

    Join this discussion now: Login / Register
  • Scott Morris - CCDE/4xCCIE/2xJNCIE 8,427 posts since
    Oct 7, 2008
    Currently Being Moderated
    14. Oct 28, 2009 6:48 PM (in response to Martin)
    Re: DHCP Process

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

     

     

    Scott

    Join this discussion now: Login / Register

Actions

More Like This

  • Retrieving data ...

Bookmarked By (2)