DHCP Failover

J-Dubs

I'm banging my head against the wall with DHCP this week. If you don't have DHCP clustering available to you (ie. a SBS network), MS suggests to use the 80/20 rule for failover in their technet article. If DHCP server1 (80% of addresses) fails, how does the client know to resolve to DHCP server2 (20% of addresses), won't the client send the renewal request to Server1 and get no response and just keep plugging away with its original lease? Also, the article doesn't talk about what conflict detection should be set at for this scenario.

I tried to set things up initially with the same scope on both servers with no exclusions and conflict detection set to 3, and I disabled "disablerogueserver" on the SBS box to keep the DHCP service from shutting down when it found another DHCP server on the network. This works, but the DHCP leases on each machine start filling up with "Bad Address" leases.

TIA,

-J

dales

I think that failover only really comes into play when a lease expires completely, otherwise the client will revert to 169.254.x.x. As your rightly point out a dhcp client will try to renew its lease after 50% of its lease has expired and then again 50% of the time remaining i.e. 8 day lease will try to renew at 4 days and 2 days and 1 days then fall to 169. at which point the remaining functioning dhcp server will allocate an address from its remaining pool.

dynamik

SBS is kind of goofy. AFAIK, it's really intended to work alone. I think you may be introducing some unnecessary variables into your studies. Don't you have any Standard or Enterprise editions to play around with? You can download a trial from MS.

How many clients are on this network?

Why did you use an identical scope on each machine with no exclusions?

To answer your question, it'll find the other server when it needs to by using broadcasts.

J-Dubs

I'm playing with my work network and my home network.

The work network has the SBS machine and an Enterprise machine, 30 clients.

The identical scope came from an SBS article that I read a while ago, I didn't think it was the best idea when I read it but as you said "SBS is kind of goofy" so I went with it. After all, this was the article that explained why the DHCP service on the SBS box would shut down when the other machine's DHCP scope was activated.

Typically, how many cycles does it take to find the secondary server? I would think that first cycle it would get no ACK from the primary, second cycle (5 min later) it would assign 169.254, and third cycle it would broadcast DHCP discover. This totals up to 10 minutes, am I wrong, and if so where?

-J

NetAdmin2436

J-Dubs wrote:

I'm playing with my work network and my home network.

I would not play or do any labs on a live production network. Your just asking for trouble.

If you can't afford multiple computers for a bigger home lab you can always throw on VMware or virtual PC on a decent computer. SBS is a different animal and doesn't really play nice with other servers, so definitely go download a standard or enterprise evaluation version from MS as Dynamik described.

Here's a technet article that describes the 80/20 rule. Notice the excluded addresses?
http://technet.microsoft.com/en-us/library/cc739076.aspx

As long as you understand the theory and thinking behind the 80/20 rule, I wouldn't bang your head anymore.

J-Dubs

I was using the "playing" term quite loosely. I have a small subnet set up at work for testing, so I'm not messing around with our production network. I've got plenty of VM's on the home lab with Microsoft Virtual Server, one thing that I didn't find was a way to create a virtual modem to virtual modem connection with my VM's for the RAS labs, is this possible? It's tough to find boxes with modems anymore. The technet article that you linked to is actually the one that I was referring to in my op.

-J

dynamik

I think you can safely avoid labbing modem exercises. Setting up a VPN is very similar, and simply reading about the differences should be sufficient.

royal

The piece about APIPA is not true. I figured I would type it out but why bother when it's nicely stated how it works in the following doc:
http://technet.microsoft.com/en-us/library/cc780760.aspx

Renewing a Lease

The DHCP client first attempts to renew its lease when 50 percent of the original lease time, known as T1, has passed. At this point the DHCP client sends a unicast DHCPRequest message to the DHCP server that originally granted its lease. If the server is available, and the lease is still available, the server responds with a unicast DHCPAck message and the lease is renewed.

If the original DHCP server is available, but the client’s current lease is no longer available, the DHCP server responds with a DHCPNack message, and the client immediately starts the process to obtain a new lease. This can happen if the client has changed subnets or if the DHCP server cannot fulfill the lease request for some other reason.

If there is no response from the DHCP server, the client waits until 87.5 percent of the lease time has passed (known as T2). At T2, the client enters the rebinding state, and broadcasts a DHCPRequest message to attempt to renew the lease from any available DHCP server. If no DHCP server is available by the time the lease expires, the client immediately unbinds itself from the existing lease and starts the process to obtain a new lease, beginning with a DHCPDiscover message.

As for conflict detection, no need to enable it in most circumstaances as long as you're Windows 2000+ as clients will do conflict detection themselves. I'd probably only enable conflict detection in two circumstances. The first being 9x clients and the second being moving scopes to a new server and not wanting the server to start doing a massive handouts that are already in use.

J-Dubs

That explains it extremely well, thank you.

-J