(RADIATOR) Radiator and the DHCP allocator

[Iain Wade]

Hi,

The DHCP allocator in Radiator seems to maintain state for the purpose
of storing the constructed HW address and correctly following the
Subnet-Selection RFC. Unfortunately, as implemented currently, a Stop
record sent to a different Radiator instance will not result in a DHCP
release as it cannot lookup that state.

The DHCP allocator can only be pointed at one IP address; I have a
failover cluster of ISC DHCPd servers in different data centres (i.e.
different subnets) and need to be able to parallel send the DISCOVER
to both.

For failover clusters of ISC DHCPd to correctly handle certain split
brain scenarios clients are required to correctly increment the secs
field on retransmissions. This wasn't happening.

I have attached a patch which solves these problems for me. Any
feedback is welcome.

I submit them to the list in the hope that these changes (or some like
them) make their way into future releases.

The patch implements a new flag "Stateless" which cannot be used in
conjunction with Subnet-Selection. When operating in Stateless mode,
the HW address is constructed by using a crc32() of the
Client-Identifier rather than a sequence number (xid). This allows the
Stop record to construct the same address without state (assuming the
Client-Identifier is based on a field which exists in both Auth
records and Acct/Stop records).

It splits the Host field on comma and parallel sends to all hosts
listed for DISCOVER (and subsequent retransmissions if no OFFER is
received). It then talks directly with the first host send an OFFER.

Every time it retransmits a packet it is reconstructed with the secs
field set to the elapsed time since first DISCOVER.

Regards,
--Iain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Radiator-dhcp_failover.patch
Type: application/octet-stream
Size: 12331 bytes
Desc: not available
URL: <http://www.open.com.au/pipermail/radiator/attachments/20051007/59f5fde5/attachment.obj>