DHCP - Rebind

Seems I've started a chain of misunderstandings by stating that it is not a Wireshark question.

So @srinu_bel, this site is the right place to come with this type of doubts, although checking the relevant standards is always a good first step.

And @grahamb, as the behaviour of the DHCP servers in question is correct, there is no point in asking server vendor.

Sorry for the confusion.

Dear Sindy,

Thanks for your kind reply.....

I gone through the RFC2131, still I am not fully happy... I have following doubts... I don't know is it right form or not.... I am not in a condition to control on my doubts which are hitting me... If any one can help that would be Gr8....

1) Even second DHCP server receives broadcast request, and not holding the transaction id second will ignore it.... AM I RIGHT ????

2) If ans is yes for above, why client is sent broadcast request??? If i thought client is convay's emergency by broadcasting, Mac id of FF:FF:FF:FF:FF:FF and IP of 255.255.255.255 will be stripped at appropriate layers at urgency will not be conveyed to transport / application layer...

3) How ever first server is holding the all details like Transaction ID, leased time and renewal packet contains the filed of time elapsed. So using these fields server can understand the urgency of the client...

Note:

Yes I can understand Wireshark can tell you what happened, but not why... If we are restricted our self to ask such doubts... We can not shoot any questions... every thing is belongs to some protocol. Am I right sir???

This form contains lot of experts who worked on RFCs / industry etc...

My humble request is kindly allow to ask some out of box query also (up to some extent... )

Regards M Srinivasa Rao [email protected]

@srinu_bel, what exactly is your doubt? Chapter 3.1 of RFC2131 is quite clear:

• the DHCP DISCOVER message indicates to all listening servers that the client needs a configuration, so it must be sent to a broadcast address - at least because at the moment of sending it, the client has no information about the network yet.

• the DHCP REQUEST indicates to all servers which of the offers the client has accepted. It is not mandatory that the client sends the REQUEST to a broadcast address, but it is a simpler way to do it than to inform each server individually, using a unicast message.

And a DHCP server is not obliged to respond to any message just because it has received it (even if it has arrived to its individual address). It may opt to ignore even a DHCP DISCOVER, e.g. because the client's MAC address matches a blacklisted pattern.

Sindy Sir,

1) in local LAN two dhcp servers and client are available 2) Client sent Discovery packet (broadcast) and got IP addr is taken after offer and ack etc... from DHCP SERVER 1..... 3) Now, DHCP Server 1 is down for some reason.... 4) Around 50% of leased time Client sends renewal request (uni cast)... Due to DHCP Server 1 is down... client is not received ACK from DHCP Server-1 with transaction ID -1 5) It is keep on sending uni cast renewal till it reaches to rebinding state (87.5% of leaded time....) 6) Once client reaches to rebind state, it sends renewal request in broad cast mode with transaction ID -1...

Now my doubts is as follows???

1) Why Second DHCP Server is not responded to broad cast renewal request??? If we thought transaction ID -1 is belongs to DHCP server 1 so DHCP server 2 is not responded, why client is sending broad cast renewal request in rebind state....

2) If i thought client is convay's emergency by broadcasting (by Mac id of FF:FF:FF:FF:FF:FF and IP of 255.255.255.255) layer 3 over head will be stripped at appropriate layers. Urgency will not be conveyed to transport / application layer...

3) How ever first server is holding the all details like Transaction ID, leased time and renewal packet contains the filed of time elapsed. So using these fields server can understand the urgency of the client...

4) I feel there is no use of rebind state in which is in broad cast mode... So complete 2nd half of 50% can have renewal state... What do u say sir???

Regards M Srinivasa Rao

Hi Sindy,

100% I am with u...

Still I am not understanding the purpose / motivation / advantage of rebind state ??? Instead of maintaining 3 states (Operational i.e first 50%, Renewal states 50% to 87.5% and finally Rebind state 87.5 to 100%...) it can be two states (Operational i.e first 50%, Renewal states 50% to 100%)

what do u say sir?

As per RFC, section 4.3.2, page 32:

DHCPREQUEST generated during RENEWING state:
...
This message will be unicast, ...
DHCPREQUEST generated during REBINDING state:
….
This message MUST be broadcast

and page 33:

The DHCPREQUEST from a REBINDING client is intended to accommodate
sites that have multiple DHCP servers and a mechanism for
maintaining consistency among leases managed by multiple servers.
A DHCP server MAY extend a client's lease only if it has local
administrative authority to do so.`

Key phrases here: “multiple DHCP servers” AND “mechanism for maintaining consistency among leases managed by multiple servers."

U mean to say multiple DHCP servers are they running in redundant config???

Okk It sounds good… Jaap