SV: Failover question

David W. Hankins David_Hankins at isc.org
Thu Oct 12 18:31:29 UTC 2006


On Thu, Oct 12, 2006 at 11:50:12AM +0200, Lars Jacobsen wrote:
> > Some folks have made mods to dhcpd so clients are identified by the
> > relay agent option of their choice istead of the actual client
> > identity, then use normal dynamic ranges.

> Well isn´t it the idea of using CID/RID ? 

Not really, no.  The relay agents are only intended so the relay
can put in 'cookies' it can use to make sure the response packet is
delivered to the right place (for any design where the relay may
not be able to figure out what's the right port, or if the chaddr
contents aren't going to tell it much about the appropriate unicast
destination).

Applying uses to this within servers has been informational at best (to
give out different information or to guide administrative 'allow/deny'
choices, lease limits, that kind of thing), as far as the IETF standards
are concerned.  Applying identity information to this as well is, I
suspect, universally frowned upon, even though as I indicated above it
is more or less common operational practice.

Not that I speak for the IETF's standards process, but that has been
my estimation of responses from people who participate there.

> That you as "owner" of the relay agent can decide what CID/RID is going to be relayed and make your decisions based on that.

Yes, but it is not universally accepted that lease ownership decisions
should be based upon this.

> Or are we dealing with more sophisticated setups where the relay agent changes the Client ID(or MAC) ?

No, literally, instead of client-id or chaddr contents, the relay agent
option of choice is used by the server to identify clients with leases.

> Samples or ideas of what and why these folks made of mods is appreciated.

"What?"...You'd have to ask them.  My estimation from the progress I made
in our similar designs is that it is not a small matter of programming,
it's a substantial development effort, as the current sources are very
closely tied to these fields (and the "A or B" decisions are spread
throughout the code).

Why is simple.

You have a port on an aggregator (let's imagine it's an ethernet switch).
You have told the customer he gets one and exactly one device, and any
other choice (applying a hub and connecting two devices) will net him
undefined results.  This means one and exactly one address.  But for
dynamic dns you still need DHCP state keeping, so you don't give him a
static address (besides you want to be able to renumber him automatically
in maint windows by manipulating lease times and leases).

These are, essentially, environments where if someone does connect a
hub to a switch port, you want it to break, and you want them to report
it, so that you can disconnect them from your network for breaching
terms of service.

The simplest answer is to address "remote ends of interfaces" dynamically
or statically rather than the clients upon them.  If one interface has
multiple devices, there will be (intentionally) problems.

> Well this is getting a long thread now and the only problem we realy have is a safe "static-lesase" failover solution, and that's not supported yet by ISC DHCPd.

This I freely admit.  ISC DHCP doesn't really work well if at all for
the requirements you're placing on it.

We were going to have features that might be used to these ends in 3.1.x,
but that development is not being paid for, so it's taking a backseat to
our current DHCPv6 projects.

As it turns out, some of the stuff we're doing for DHCPv6 might be more
or less easily reverse applied to DHCPv4 (the ability to declare host
records by arbitrary DHCP Options and their values), so it may be that
DHCP 4.0.0 allows static bindings of the sort you're asking for.

At some point, I will get back to making the "configurable client
identification" modifications which were intended to solve a different
problem, but could serve the same purpose.

-- 
ISC Training!  October 16-20, 2006, in the San Francisco Bay Area,
covering topics from DNS to DDNS & DHCP.  Email training at isc.org.
-- 
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