Mac and PC DHCP clients moving from one wired subnet to a second wired subnet do not receive an IP address from the DHCP server from the second subnet. Instead, the DHCP server assigns the IP address that was assigned when they were wired into the first subnet. This prevents network connectivity.
Mac A is wired into Subnet 1, to which the DHCP server issues IP address 192.168.0.11, from Scope 1. Mac A disconnects the Ethernet cable from Subnet 1 and plugs the Ethernet cable into Subnet 2. Mac A receives IP address 192.168.0.11 from the DHCP server. No network connectivity is possible at this point, as the IP address (and associated TCP/IP parameters) is incorrect for Subnet 2. If Mac A disconnects the Ethernet cable from Subnet 2 and connects the Ethernet cable to Subnet 1, the IP address received will be 192.168.0.11 and network connectivity is resumed.
* For the sake of this example there are no other DHCP clients in use other than the DHCP clients specified in this example. When discussing the parameters returned to the DHCP client by the DHCP server, these parameters will be referred to as “IP address”. “IP address” means IP address as well as all other associated TCP/IP information, DNS domain name, router, DNS servers, etc.
Mac A is wired into Subnet 1, to which the DHCP server issues IP address 192.168.0.11, from Scope 1.
Mac A disconnects the Ethernet cable from Subnet 1 and plugs the Ethernet cable into Subnet 2. Mac A receives IP address 192.168.1.11 from the DHCP server.
Mac A disconnects the Ethernet cable from Subnet 2 and plugs the Ethernet cable into Subnet 3. Mac A receives IP address 192.168.2.11 from the DHCP server.
Mac A disconnects the Ethernet cable from Subnet 3 and plugs the Ethernet cable into Subnet 4. Mac A receives IP address 192.168.3.11 from the DHCP server.
Mac OS X Snow Leopard, Lion / Windows 7 Enterprise, SP1 (tested in both Workgroup and Domain configuration)
Ethernet port set to obtain IP address via DHCP
Windows Server 2008 R2, SP1
DHCP server joined to Active Directory domain in Windows Server 2008 R2 forest functional level
DHCP server static IP address : 192.168.0.5
Scope 1 – 192.168.0.11-.99 (issued to Subnet 1 DHCP clients)
Scope 2 – 192.168.1.11-.99 (issued to Subnet 2 DHCP clients)
Scope 3 – 192.168.2.11-.99 (issued to Subnet 3 DHCP clients)
Scope 4 – 192.168.3.11-.99 (issued to Subnet 4 DHCP clients)
Router A – Relay agent for Subnets 1 and 2 set to 192.168.0.5.
Router B – Relay agent for Subnet 3 set to 192.168.0.5
Router C – Relay agent for Subnet 4 set to 192.168.0.5
My interpretation of a Microsoft Technet article (http://technet.microsoft.com/en-us/library/cc757614(v=ws.10).aspx) is that DHCP superscopes must be associated with logical networks that are managed by a single router.
If a router is managing multiple logical networks, a superscope could be used. If a superscope is used, it should only include logical networks the router manages. Stated another way, the superscope should only include logical networks for which the router has a configured DHCP relay agent.
If a router is managing only one network, a superscope would not be needed, but could be used. If a superscope is used, it should only include the single logical network the router manages.
In this example, there are three routers managing a total of four logical networks, being supplied IP addresses from a single DHCP server configured to use a single DHCP superscope. This configuration will not provide the desired behavior.
The desired behavior can be achieved by taking a number of approaches.
The first, and perhaps simplest solution, would be to eliminate the superscope by creating all scopes at the DHCP root level.
A second solution would be to remove Scopes 3 and 4 from the superscope, leaving the scopes at the DHCP root level. This would leave the remaining scopes (Scopes 1 and 2) managed by a single router (Router A).
I did not extensively test the second solution, but should work, given my interpretation of the Technet article. The first solution worked in two real-world scenarios.