dhcp failover

Tony Aldo tony.aldo at gmail.com
Thu Jul 6 15:34:23 UTC 2006

I'm using HA because the cluster is running other services like ntpd, httpd.
I'm not too concerned about ping not getting through. The DHCP cluster is
going to be serving IP Set Top Boxes running some sort of linux kernel.

The leases are set to expire once a month which is plenty of time to detect
a node failure.

Even so HA is set up to give node 1 priority

I hope its ok now, or atleast not as bad.


On 7/6/06, David W. Hankins <David_Hankins at isc.org> wrote:
> On Thu, Jul 06, 2006 at 10:56:39AM +1000, Glenn Satchell wrote:
> > 2) the dhcp server has an interface on every vlan and you don't use
> > relay agents. This can work using a trunked interface that understands
> > vlan tagging and some magic on your switches, but means that every vlan
> > has to extend to where the dhcp server is. If you have far flung remote
> > vlan's then you probably don't want all the vlan broadcast traffic
> > being forwarded across your WANs.
> I just wanted to point out that there's a known flaw in dhcpd with
> this approach.
> Because not all current i/o transports know the difference between
> broadcast and unicast, the server in the configuration above can't
> distinguish between DHCP clients in RENEW state and DHCP clients in
> REBIND state.
> REBIND is important because in that state we want to perform a check
> to make sure the client is attached to the right network (and NAK on
> that basis if they're not).  In RENEW we can't perform that check
> because we don't know that the message was transmitted by the client
> on the interface being configured (if you're unicasting a packet,
> it can take any route the client chooses).
> When a client moves from one vlan to another, it may enter REBIND
> state in an attempt to verify its address.  The ISC DHCP Server today
> has no choice but to ACK these messages.
> Note also however that all 802.1q vlan subinterfaces will have the
> same, physical interface's MAC address.  So if a client moving between
> networks instead transmitted a RENEW message, it would still reach
> the DHCP Server, and the server would still ACK the message (extending
> its lease, and keeping the client from ever entering REBIND state!).
> The consequence is that Windows XP DHCP Clients roaming between
> VLANs will not succeed in obtaining a new address.  Mac OSX
> clients, it might be pointed out, manage to work around this.
> The relay agent configuration doesn't have this problem because, when
> the client unicasts (RENEW) the relay agent is not involved - when the
> client broadcasts (REBIND), the relay agent is involved.
> Even when the relay agent is similarly used in 802.1q vlanning - it
> is only ever involved when the client is broadcasting.
> --
> David W. Hankins                "If you don't do it right the first time,
> Software Engineer                       you'll just have to do it again."
> Internet Systems Consortium, Inc.               -- Jack T. Hankins

More information about the dhcp-users mailing list