Technology, Support, and News Forum

[mnemonicj Profile]

I want my computers to check the DHCP server on my Windows 2008 server and if I have assigned the MAC address of that computer to a static IP address, use that IP address. If there is no IP address assigned to the computer's MAC address, I want the computer to use my router as a DHCP server and get a dynamic IP from the router.

The reason I want to do this is because I want my client machines to use the server to get static IPs when connected to my network, but be able to use DHCP when they are connected to another network without having to change the network settings on the computer. I also want guest computers and my media center to be able to rely on the router for an IP address at all times, especially when my server is down and can't provide an IP address or DNS forwarding.

Is it possible to do this? I have looked around and I can't find an issue quite like mine.

[Weaver Profile Website]

mnemonicj,

To answer your question briefly: The precise behavior you desire is not easily possible given a Windows Server 2008 DHCP Server and a run of the mill DHCP server from a SOHO router. The problem you will encounter is due to the simplicity of the DHCP Process itself.

Not so brief answer (Bear with me):

To understand a little bit more about the problem it is important to understand the fundamentals at work. Dynamic Host Configuration Protocol is a protocol whose server and client transition through states of a finite state machine. The FSM can get a little overwhelming and is only for DHCP server/client programmers and protocol junkies. An easier way to think about DHCP is with a four letter acronym: DORA.

(D)iscover
(O)ffer
(R)equest
(A)cknowledge

(D)iscover - Client network interface sources a UDP datagram with source IP and port of 0.0.0.0:68 to destination source and port 255.255.255.255:67. As the datagram is destined for 255.255.255.255 this datagram is ultimately turned into a broadcast frame on the Ethernet broadcast domain (your LAN) and every network interface (device, workstation, etc.) "sees it." The source MAC address is the client's MAC address. This (D)iscover is asking any and every device (only DHCP servers will take further action) on the LAN to (O)ffer an IP address. The client inserts a transaction ID (XID) to keep track of future responses.

(O)ffer - Any and every DHCP server on the broadcast domain (your LAN) sees the (D)iscover *and responds* (with very few exceptions) back with an (O)ffer. The offer is a UDP datagram with source IP of the server and port, say 192.168.1.1:67 and destination 255.255.255.255:68. It is destined for 255.255.255.255:68 so that 1) it will be turned into a broadcast frame on your network and 2) the client will thus see it. In the offer is both the transaction ID (XID) and an IP address that the server is offering. It is important to note that if there are multiple DHCP servers on the network, then multiple DHCP servers will generate (O)ffers. The client generally picks the first received and proceeds.

(R)equest - The client chooses an (O)ffer and then generates a (R)equest UDP datagram with source 0.0.0.0:68 and destination 255.255.255.255:67. In the (O)ffer is the transaction ID and the (R)equested IP address from the (O)ffer. It is destined to 255.255.255.255:67 (after all, client knows the IP of DHCP server at this point from the (O)ffer) so that *other* DHCP servers can see the (R)equest and withdraw any (O)ffers they may have on the table to that client.

(A)cknowledge - All servers receive the (R)equest as it is broadcast, however only the server that sent the (O)ffer (kept track of with transaction ID) will send an (A)cknowledge. Sourced from the server with source address 192.168.1.1:67 (going with our example) and destined for 255.255.255.255:68 the (A)cknowledge is a final acknowledgement/authorization telling the client to go ahead and use the address and the options along with it (lease time, router, dns, etc.)

Prior to assigning and using the address most DHCP clients will issue a Gratuitous ARP Request (GARP Request) to ensure that no other network interface on the broadcast domain is assigned that address.

What does all of this mean?

First and foremost you should be thinking there is more to DHCP than meets the eye. See the additional resources at the bottom for further reading. More specifically, you should realize that when you have multiple DHCP servers on the same broadcast domain it makes for some interesting behavior.

There are only a few ways to configure multiple DHCP servers on the same broadcast domain serving the same IP subnetwork without encountering problems. Oftentimes this is referred to as the 80/20 rule.

Assuming your router is 192.168.1.1 and Windows Server 2008 server is 192.168.1.10

• Configure *both* your router and your server with the same scope - for example 192.168.1.100 - 192.168.1.199. On the Windows server side this is easy. On the router side you may have to fidget with "start address" and "number of addresses" or something similar.
• Exclude from distribution .100 - .179 on the router and .180 - .199 on the server. On the Windows server side this is easy. On the router side you may have to fidget with "start address" and "number of addresses" or something similar.
• This leaves distribution on the server at .100 - .179 and on the router at .180 - .199. Non-overlapping.
• Configure your reservations on both the router and the server. This is very important and without doing so you will not be able to guarantee always being able to meet your stated objective. If your router does not support reservations you will need to obtain one that does support reservations.

With the aforementioned configuration:

• With both DHCP servers up: Non-reservation DCHP clients will get an address from the DHCP server that responds back first. If the router responds back first it will be in the .180 - .199 range. If the Windows server responds back first it will be in the .100 - .179 range. A DCHP client with a DHCP reservation will get the proper reserved address regardless of which DHCP responds first.
• With Windows server down: Non-reservation DHCP clients will get an address from the router in the .180 - .199 range. DHCP clients with reservations will get the proper reserved address.
• With the router down: First and foremost no Internet access. Non-reservation DHCP clients will get an address from the Windows server in the .100 - .179 range. DHCP clients with reservations will get the proper reserved address.
• Interesting Case: Both DHCP servers up and the router consistently responding back first: Eventually the smaller pool of the router may fill up if you have a lot of devices on your LAN. At the point which the router no longer has addresses to lease it will stop sending (O)ffers allowing the Windows server (O)ffers to arrive at DHCP clients. Clients will then lease from Windows server pool.

DHCP was implemented when network security, redundancy, and reliability were vastly different than today. As such, it is quite basic presenting some interesting limits requiring interesting workarounds to achieve objectives.

Additional Resources:
http://en.wikipedia.org/wiki/Dynamic_Ho ... n_Protocol
http://www.tcpipguide.com/free/t_DHCPGe ... achine.htm

-Weaver

[mnemonicj Profile]

Weaver, thank you for the detailed answer. I had read about the 80/20 rule before, but I wasn't sure it could benefit me. The idea seems to work except for that fact that I want client machines to be automatically assigned to the domain controller as the DNS server and the guest machines and my media center to use the ISP's DNS servers.

I have tried to assign a secondary DNS server to the DHCP scope and let the Domain Controller handle all DHCP requests, but the client machines end up having random network issues because as a domain client, they should not be using any DNS server besides a DNS server on the domain.

I am upgrading my server from Windows Server 2008 x86 to Windows Server 2008 R2, so I will worry get back to this when my server is back up and running again.
!
Thanks for the help

[Weaver Profile Website]

The idea seems to work except for that fact that I want client machines to be automatically assigned to the domain controller as the DNS server and the guest machines and my media center to use the ISP's DNS servers.

I have tried to assign a secondary DNS server to the DHCP scope and let the Domain Controller handle all DHCP requests, but the client machines end up having random network issues because as a domain client, they should not be using any DNS server besides a DNS server on the domain.

What reason for having "client machines" use the DC for DNS and "guest machines" use ISP DNS servers? This sort of behavior can be accomplished reliably using DHCP, but not on the same broadcast domain due to the limitations of DHCP itself as described above. Specifically, you will not be able to control which DHCP server responds "first." Why not just have everyone use domain controller DNS? Then configure your domain controller to use your ISP DNS servers as forwarders instead of using root hints.

However, in your specific case you can exploit the fact that you want to use static reservations for everything "yours" to make this work. In Windows server you can specify specific DHCP options in *each* reservation. If you can replicate this functionality in your router then you can configure each reservation to use domain controller DNS and then set the scope options to use ISP DNS. If your router cannot mirror the DHCP functionality of WIndows server DHCP in this regard, then you should not do it as you will have inconsistencies among your DHCP servers.

In an enterprise environment this sort of functionality would be achieved by using a managed switch with support for 802.1q VLANs. Consumer grade switches and routers will not support this capability.

Very briefly, you would create a VLAN (and IP subnetwork) for your own data network, say VLAN 10 and then a second VLAN (and second IP subnetwork) as your guest network, say VLAN 20.

• Note that VLAN 10 and VLAN 20 would be different IP subnetworks, say 192.168.10.0/24 and 192.168.20.0/24 respectively.
• When on VLAN 10 devices would get DHCP from a DHCP server on VLAN 10 handing out the DNS servers of the domain controller.
• When on VLAN 20 devices would get DHCP from a DHCP server on VLAN 20 handing out the DNS servers of the ISP.
• Your switch and router would have to support 802.1q VLANs and and 802.1q trunk would need to be configured between the switch and the router in a "router on a stick" arrangement.
• You will need business grade equipment to accomplish the aforementioned tasks.

The bigger question then becomes "how do I ensure my devices are on my VLAN and guests are on the guest VLAN?"

• VLAN's can be set on a per port basis on a supported switch. Say ports 1 - 8 on VLAN 10, 9 - 15 on VLAN 20, and port 16 is an 802.1q trunk to the router. In this arrangement you would ensure that all of your stuff was plugged into 1 - 8, all guests were on 9 - 15.
• You could implement (again on a supported switch) an 802.1x/MAC authentication system where a network device would have to pass 802.1x authentication in order to be allowed on to VLAN 10, otherwise they are dumped to VLAN 20 by default. MAC authentication bypass is a means for you to configure a list of "allowed" MAC addresses that do not need to successfully authenticate 802.1x to be placed on VLAN 10. This has the effect of you just needing to keep the switch up to date with the list of "allowed" MAC's on VLAN 10.
• You will need business grade equipment to accomplish the aforementioned tasks.

Just about all of what I mentioned above is not possible with consumer grade equipment and not easy or cheap to do in general. However, I wanted to convey that there are methods to achieve the goal and that enterprises face this exact sort of predicament solving it in the mentioned manners.

-Weaver

[mnemonicj Profile]

What reason for having "client machines" use the DC for DNS and "guest machines" use ISP DNS servers? This sort of behavior can be accomplished reliably using DHCP, but not on the same broadcast domain due to the limitations of DHCP itself as described above. Specifically, you will not be able to control which DHCP server responds "first." Why not just have everyone use domain controller DNS? Then configure your domain controller to use your ISP DNS servers as forwarders instead of using root hints.

However, in your specific case you can exploit the fact that you want to use static reservations for everything "yours" to make this work. In Windows server you can specify specific DHCP options in *each* reservation. If you can replicate this functionality in your router then you can configure each reservation to use domain controller DNS and then set the scope options to use ISP DNS. If your router cannot mirror the DHCP functionality of WIndows server DHCP in this regard, then you should not do it as you will have inconsistencies among your DHCP servers.

That is the way I have it set up now, every machine on my network uses my domain controller for DHCP and the DNS server and my domain controller has forwarders to my ISPs DNS servers. It works great, except when my domain controller is down. When my domain controller is down for any reason ( replacing and rebuilding a bad hard drive in my data RAID, maintenance, OS upgrade, etc.) my network has nothing to resolve DNS requests so nothing can connect to the Internet.

I guess I just need to set up my router as a backup DHCP server and it on manually when my domain controller is down. It's not too much of a problem, but I like to set up my computers to do things for me automatically, especially if my domain controller is only going to be down for 10 minutes while guests or my media center PC are using the Internet.

Thanks for your help. I appreciate the knowledge.

[Weaver Profile Website]

That is the way I have it set up now, every machine on my network uses my domain controller for DHCP and the DNS server and my domain controller has forwarders to my ISPs DNS servers. It works great, except when my domain controller is down. When my domain controller is down for any reason ( replacing and rebuilding a bad hard drive in my data RAID, maintenance, OS upgrade, etc.) my network has nothing to resolve DNS requests so nothing can connect to the Internet.

This is why you are able to set primary and secondary DNS servers. They are not used in a round-robin manner. They are used in a "always use primary, if primary down, use secondary" manner.

In the event your DHCP server (domain controller) goes down, Windows client will not attempt to renew the lease until 50% remains. If it fails they try again when 25% remains (not quite sure on the 25% but you get the point). As long as your DHCP server is back up by the time leases expire you will not have a DHCP problem.

In the event that your primary DNS server (domain controller) goes down, Windows client will realize that their primary DNS server (domain controller) is down and move the the next one in the list (I would advise 8.8.8.8, 8.8.4.4, Google's public DNS, OpenDNS is nice too). Eventually, when your primary DNS comes back online Windows clients will begin using it.

-Weaver