(RADIATOR) AddressAllocator DHCP with two DHCPservers

Iain Wade iwade at optusnet.com.au
Wed Apr 16 04:09:00 CDT 2008


I sent a patch to Hugh and this list back in July 2005 which added
support for multiple DHCP server destinations.

Here is a (slightly newer) copy of that patch and my original post.

--Iain

> On 7 Oct 2005, at 07:29, Iain Wade wrote:
>
> > 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
> >
> > <Radiator-dhcp_failover.patch>
> >
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Radiator-dhcp_failover.new.patch
Type: text/x-patch
Size: 12394 bytes
Desc: not available
URL: <http://www.open.com.au/pipermail/radiator/attachments/20080416/145da20e/attachment.bin>


More information about the radiator mailing list