This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

DHCP - Rebind

0
  1. During rebind state in DHCP, Client is send the broadcast request with same transaction id...
  2. Second server is available in the network but not responding ....
  3. After completion of leased time, client is sending discover packet then second server is responding...

Is this behavior is ok ??? Why second server is not alloting new Ip to client, when it is sending DHCP broadcast request??

Regards

asked 25 May '16, 22:07

srinu_bel's gravatar image

srinu_bel
20151620
accept rate: 0%

edited 26 May '16, 02:37

grahamb's gravatar image

grahamb ♦
19.8k330206


One Answer:

0

Strictly speaking this is not a Wireshark question. RFC 2131 has the details on page 13, but roughly, the second DHCP server behaves properly when it reacts to DHCP Discovery but not to DHCP Request. And it doesn't matter that the Request is sent to a broadcast address - the purpose of sending the Request to a broadcast address is to inform those DHCP servers whose Offer the client hasn't accepted that they may cancel the reservation.

answered 26 May '16, 01:48

sindy's gravatar image

sindy
6.0k4851
accept rate: 24%

Well, I guess this question falls in the realm of 'protocol analysis', so it should be ok.

(26 May '16, 04:45) Jaap ♦

Can Any one tell where to post such doubts???

(26 May '16, 21:16) srinu_bel

Maybe a forum for the vendor of the DHCP server software.

As is often noted on this site, Wireshark can tell you what happened, but not why.

(27 May '16, 02:36) grahamb ♦

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.

(27 May '16, 05:35) sindy

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]

(27 May '16, 19:54) srinu_bel

@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.

(28 May '16, 00:06) sindy

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

(30 May '16, 01:58) srinu_bel
1

If I get you right, you actually seek a redundancy scenario - if the DHCP server A fails, a DHCP server B should assume its role and respond to clients' renewal requests for leases provided by DHCP server A.

But such redundancy is not embedded into the DHCP protocol itself, as it is not the primary purpose of running several DHCP servers on the same LAN. You would need one of two mechanisms:

  1. either the client would give away its current DHCP settings shortly after the renewal request would fail, even though the lease has not expired yet, and start from scratch by sending a new DHCP Discover

  2. or the DHCP servers A and B would work as an active/standby cluster, sharing a common IP address and synchronising state information, and the standby one would monitor the other one's health and would become active if the other one would go down.

The first option has two disadvantages: the client would rarely get the same IP address it has got before, and it is not likely you would be able to change the behaviour of all your clients this way. So the second option could both provide a better user experience and be easier to implement.

(30 May '16, 06:51) sindy

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?

(30 May '16, 20:43) srinu_bel

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."

(31 May ‘16, 01:14) Jaap ♦

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

(31 May ‘16, 01:31) srinu_bel
1

I mean “mechanism for maintaining consistency among leases managed by multiple servers."

What you say can be implemented in multiple ways, the RFC is specific.

(31 May ‘16, 01:53) Jaap ♦

Okk It sounds good… Jaap

(31 May ‘16, 01:59) srinu_bel
showing 5 of 13 show 8 more comments