Does anyone use anycast DHCP service?

Mailman List Mirror (Read Only)
1

Assuming your DHCP servers are properly clustered, simply have your
routers relay all requests to both servers. Here's instructions
on setting up ISC DHCPD for redundant (pooled) servers:
Failover with ISC DHCP

..

Works great, no single point of failure, no anycast.

It may very well work *most* of the time, or during controlled
failover, but it looks pretty creaky to me. Some thoughts:

1) No third-party "witness" service for the cluster, making
split-brain scenarios a very real possibility.

2) Multi-master databases are quite challenging in practice. This one
appears to rely on timestamps from the system clock for conflict
detection, which has been shown to be unreliable time and again in the
application space.

3) There are single points of failure. You've traded hardware as a
single point of failure for "bug-free implementation of clustering
code on both DHCP servers" as a single point of failure. In general,
software is far less reliable than hardware.

I think it would be far more reliable to simply have two independent
DHCP servers with mutually exclusive address ranges, and have one
system be secondary and "delay" its responses by 2s so it always
"loses" when the primary is up and running well.

Yes, you lose the ability for clients to get the same IP during a
lease refresh if the primary is down, but that is a small price to pay
for simplicity and robustness.

2

In a message written on Mon, Aug 13, 2012 at 08:54:09AM -0500, Ryan Malayter wrote:

1) No third-party "witness" service for the cluster, making
split-brain scenarios a very real possibility.

The ISC implementation is designed to continue to work with a "split
brain". I believe the Microsoft solution is as well, but I know
less about it. There's no need to detect if the redundant pair
can't communicate as things continue to work. (With some caveats,
see below.)

2) Multi-master databases are quite challenging in practice. This one
appears to rely on timestamps from the system clock for conflict
detection, which has been shown to be unreliable time and again in the
application space.

You are incorrect. The ISC implementation divides the free addresses
between the two servers. The client will only interact with the
first to respond (literally, no timestamps involved). Clients
talking to each half of a split brain can continue to receive
addresses from the shared range, no timestamps are needed to resolve
conflicts, because the pool was split prior to the loss of
server-to-server communication.

There is a down-side to this design, in that if half the brain goes
away half of the free addresses become unusable with it until it
resynchronizes. This can be mitigated by oversizing the pools.

3) There are single points of failure. You've traded hardware as a
single point of failure for "bug-free implementation of clustering
code on both DHCP servers" as a single point of failure. In general,
software is far less reliable than hardware.

Fair enough.

However I suspect most folks are not protecting against hardware
or software failures, but rather circuit failures between the client
and the DHCP servers.

I've actually never been a huge fan of large, centralized DHCP
servers, clustered or otherwise. Too many eggs in one basket. I
see how it may make administration a bit easier, but it comes at
the cost of a lot of resiliancy. Push them out to the edge, make
each one responsible for a local network or two. Impact of an
outage is much lower. If the router provides DHCP, the failure
modes work together, router goes down so does the DHCP server.

I think a lot of organizations only worry about the redundancy of
DHCP servers because the entire company is dependant on one server
(or cluster), and the rest of their infrastructure is largely
non-redundant.

3

I think it would be far more reliable to simply have two independent
DHCP servers with mutually exclusive address ranges, and have one
system be secondary and "delay" its responses by 2s so it always
"loses" when the primary is up and running well.

Yes, you lose the ability for clients to get the same IP during a
lease refresh if the primary is down, but that is a small price to pay
for simplicity and robustness.

That depends on your scenario. In some situations it is important to
get the same IP. In other situations, using potentially double the
address space is unacceptable.

If these points are not a problem for you, I certainly agree that two
independent servers are potentially more reliable than a clustered
setup.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

4

I think it would be far more reliable to simply have two independent
DHCP servers with mutually exclusive address ranges, and have one
system be secondary and "delay" its responses by 2s so it always
"loses" when the primary is up and running well.

Yes, you lose the ability for clients to get the same IP during a
lease refresh if the primary is down, but that is a small price to pay
for simplicity and robustness.

That depends on your scenario. In some situations it is important to
get the same IP. In other situations, using potentially double the
address space is unacceptable.

As some have noted, your environment may dictate which is better (HA with software considerations, or retention of IP lease information).

Example:

In an ISP environment, I would suggest that you consider prefix delegation for IPv6 (--assuming you plan on IPv6 at some point ).

For traditional IPv4 networks (ISP), changing the WAN side IP address occurs often enough that it's annoying, but tolerable. When we consider IPv6, changing the WAN side IP is also reasonable (IA_NA). But if you plan on supplying the home network a prefix delegation (IA_PD), you get into some problems if you wind up renumbering the home network.

Not sure if this example fits your profile, but at this point, I would not consider a deployment of any major system without considerations of IPv6.

Regards,

Victor Kuarsingh

5

The ISC implementation is designed to continue to work with a "split
brain". I believe the Microsoft solution is as well, but I know

...

You are incorrect. The ISC implementation divides the free addresses
between the two servers. The client will only interact with the
first to respond (literally, no timestamps involved). Clients
talking to each half of a split brain can continue to receive
addresses from the shared range, no timestamps are needed to resolve
conflicts, because the pool was split prior to the loss of
server-to-server communication.

There is a down-side to this design, in that if half the brain goes
away half of the free addresses become unusable with it until it
resynchronizes. This can be mitigated by oversizing the pools.

Glad to hear it is a better design than my first skimming of the
documentation indicated. Essentially,an ISC DHCPD cluster is basically
two independent servers, with the added optimization of replicating
reservations from one system to the other so it can answer renewals
when possible. I still wonder what happens when a renewal happens
during failover, and then the original server comes back on-line, and
a renewal of the same address happens during startup. Hopefully any
node joining a cluster waits until it is fully synchronized before
answering queries.

I've seen so many two-node "HA pair" setups go horribly sideways
during my IT career, I usually assume the worst. Firewalls, load
balancers, stackable switches, databases, SANs, you name it. They all
usually survive the "pull the plug on one node" test during QA, but
that's about it.