Update RE: UNICAST and BROADCAST mode response

[Vic Berdin]

Hi Simon (and everyone),


Thanks for your reply.

Refering to the "Bootstrap Protocol, bootp flag" setting, upon DISCOVERY
from all clients within our network, I notice that the default is always in
UNICAST mode. However, if a client send a DISCOVERY in BROADCAST mode,
ISC-DHCPd will start to respond in BROADCAST mode as well. The issue I
encounter however, is that from then on, the server will always respond in
BROADCAST mode even if other clients are talking in UNICAST.

I then found out that the issue may be fixed with the use of
'always-unicast' parameter. And in such case, the server goes back to
UNICAST mode after talking to a BROADCAST mode client.

My questions now are:

1. Why does the server stay at BROADCAST mode once a client start talking in
BROADCAST even if other clients that follow are talking in UNICAST
2. Is the 'always-unicast' in dhcpd.conf setting the most ideal solution to
this server behavior?

Again, my server is isc-dhcpd-4.2.1. If additional information or packet
captures are needed, please let me know. 


Thanks in advance,
Vic

----------------------------------------------------------------------

Message: 1
Date: Wed, 1 Jun 2011 08:01:45 +0100
From: Simon Hobson <dhcp1 at thehobsons.co.uk>
Subject: Re: UNICAST and BROADCAST mode response
To: Users of ISC DHCP <dhcp-users at lists.isc.org>
Message-ID: <p06240806ca0b922dd407 at simon.thehobsons.co.uk>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Vic Berdin wrote:

>I notice that my server (isc-dhcpd-4.2.1) can send replies either in 
>BROADCAST or in UNICAST mode (see wireshark screen capture). But 
>most of the time, the replies are in UNICAST. I am familiar with the 
>"always-unicast" config setting. However, if such a parameter is not 
>present, how/when does the server sends its OFFERs/AKCs/NAKs in 
>BROADCAST mode?

In general, if the client is already configured with an IP address, 
then traffic will be unicast, otherwise it will be broadcast.

So when a client first brings up it's interface, it can only 
broadcast as it has no address to use - and responses must also be 
broadcast. However, once it has an address*, the client can use 
unicast and talk directly to the server - and the server can talk 
directly back with unicast.

* Two obvious cases :

1) The client is already connected to the network and is renewing an 
active lease. That's the common case.

2) Technically, clients first bringing up an interface should assume 
they may have moved to a different network and start from scratch by 
broadcasting DHCP Discover packets.
However, many have a shortcut and test to see if they are on the same 
network as before - typically by making ARP requests for the last 
known gateway and checking that the same gateway (by MAC) is at the 
same address and is reachable.
In this case, may be configured to continue using any unexpired lease 
it already has - but may also double check by sending a DHCP Request 
for the address it's about to use. As it has an address that appears 
to be valid, it could do this by unicast and if it gets a positive 
response then the network is good to go.
This latter case is implementation dependant and I don't think it's 
100% RFC compliant - but it does mean clients can carry on even if 
the DHCP server is temporarily unavailable.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.


------------------------------

Message: 2
Date: Wed, 1 Jun 2011 16:59:26 +0800
From: "Vic Berdin" <vic at digi.ph>
Subject: UPDATE: UNICAST and BROADCAST mode response
To: <dhcp-users at lists.isc.org>
Message-ID: <008401cc203a$4b573460$e2059d20$@ph>
Content-Type: text/plain; charset="us-ascii"

Hi everyone,

 

So sorry for being such a trigger happy low life :o). Now I realize the mode
can be set by the client-war, and ISC-DHCPd will happily oblige upon which
mode the client prefers.

 

Best regards,

Vic

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.isc.org/pipermail/dhcp-users/attachments/20110601/e0f87dfa/at
tachment-0001.html>

------------------------------

_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users

End of dhcp-users Digest, Vol 32, Issue 2
*****************************************