In-Depth

Return to Sender

When moving subnets from Unix JOIN to Win2K DHCP, this admin got a crash course on the intricacies of IP addressing and the pure beauty of the superscope.

• By Nicholas Zavalishin
• May 01, 2001

So there I am sitting in my cube, minding my own business, and my boss approaches me. Word has come down from “management” that we’re going to migrate from Unix JOIN DHCP (JOIN is a Unix DHCP product that can be used to manage DHCP for multiple subnets in a single place) to Windows 2000 DHCP. I thought to myself, “This’ll be a piece of cake, right?” Sure, I’ve set up DHCP on an NT machine before—no problem. Boy, was I wrong.

I’ve installed Win2K Advanced Server so many times, I can do it in my sleep. Our company has deployed many Win2K servers and we’ve even migrated about a half-dozen Windows NT 4.0 Terminal servers to Win2K with minimal difficulties. So I dutifully accepted the mission and promptly set off to find the Unix boys and pick their brains about JOIN. After a crash course, I was armed with enough information on JOIN to begin what I thought would be an easy process.

I’ll be the first to admit that the DHCP servers I have previously set up have been straightforward and “cookie cutter” in nature; now the true test was upon me. Prior to implementing Win2K DHCP, all our DHCP requests were handled by a single Unix JOIN machine across our WAN. This server issued IP addresses for four locations of varying size. Now, the “powers that be” wanted two Win2K servers in different locations of the WAN. The overall environment comprised both PC and NC clients.

To give you a general idea of the network topology, there are two main locations and two satellite locations off of one of the main locations. In each of the two main locations, there are several physical routers. Each of the routers has numerous logical subnets defined in their routing tables (Figure 1).

Figure 1. The network topology comprised two main locations and two satellite locations off one of the main locations. In each of the two main locations, there are several physical routers.

OK, so Unix JOIN is fairly straightforward. JOIN has a single simple text file that’s used to segregate the individual physical and logical subnets. It’s setup in a tabular form (See Table 1). So the JOIN text file would look something like Table 2.

Table 1. JOIN has a single, simple text file that’s used to segregate the individual and logical subnets.

Table 2. JOIN’s tabular text file determines the appropriate scope to issue IP addresses from the physical router gateway that’s given in the giaddr field of the DHCP request.

When a DHCP request is received by the Unix JOIN server, the text file is queried to determine the appropriate scope to issue the IP address from the physical router gateway that’s given in the giaddr field of the DHCP request. Then JOIN will issue and catalogue IP addresses much like an NT server would.

Enter Win2K. A Win2K Advanced Server was installed at each of the two main locations. DHCP services were installed, so it was time to begin the configuration. It soon became painfully obvious that there was going to be a need for Win2K DHCP to have the logic to determine from which scope to issue the IP address. As of Windows NT 4.0 SP 2, there’s been a feature in DHCP called superscopes. I’d never had a need for such a beast; honestly, I thought superscopes were nothing more than a glorified bookkeeping folder for scopes. Again, I was wrong.

I decided to tackle the main location with the two satellite locations first. This side of the WAN was set up with four physically routed subnets. Two of these routers were set up to route between each of the two satellite locations and the main location. On one of these routers, the physical subnet and the logical subnet were the same, and DHCP would simply issue an IP address from the subnet from which it received the information from the giaddr field—nice and simple. The second satellite router had a physical subnet with a different logical subnet. Unix JOIN has little problem resolving this thanks to its handy text file, which distinguishes the scope from the physical router.

Enter the Superscope
Here’s where some of the Win2K DHCP logic needed to be implemented. First, I constructed the scope from which the IP addresses will be issued. I entered in all the appropriate option information (i.e. DNS and WINS servers, default gateway and so on). I then created a “dummy” scope that contains the IP address of the router. In other words, with a physical router IP of 192.200.141.1, I created a scope of 192.200.141.1 to 192.200.141.1 and excluded 192.200.141.1. This is the address that would be in the giaddr field. A superscope can then be created and the two scopes added to it. I added the scope that the addresses would be issued from and then added the “dummy” scope for the physical router. This would force the DHCP to look in this particular superscope, bypassing any other superscopes on the server. The DHCP server would first attempt to issue an IP address from the scope containing the 141 subnet and find that there were no addresses to issue. It’s at this point that the next available scope in the superscope would be tapped for an IP address. Obviously, finding an address available (we hoped), the server would respond with a DHCP offer from the correct logical subnet.

The other satellite router could simply use a scope because the physical and logical subnets were the same. The main router in this location also called for a bit of fancy superscoping. The IP address of the DHCP server itself wasn’t on a subnet from which the server was issuing IP addresses. Now what? Well, just as I assigned a “dummy” IP scope for the routers, I did the same for the superscope that was issuing address for the main router; only this time, the “dummy” scope had to be for the server itself.

Why wasn’t that necessary for the other two satellite routers? Because the two satellite routers had a bit of help from the router itself. Since DHCP is inherently a broadcast message, it must be herded to its correct destination.

An IP helper address was added to the packets being broadcast from the routers that would point them to the DHCP server. This essentially converted the DHCP broadcast into a Unicast, paving the way right to the DHCP server. Why not just do the same thing for the main router? It was tried. We had some of the best people working on the answer, not only in my company but also at Microsoft. It just wouldn’t work. The DHCP server wouldn’t issue addresses to any subnet on the main router with the IP helper address on it. The solution that Microsoft presented was adding the “dummy” IP scope in the superscope for the DHCP server itself. By adding a single IP scope for the DHCP server itself, subsequently excluding that IP from the scope, and placing this scope into the superscope for the main router, we were able to funnel the DHCP broadcast from the main router to the correct superscope.

The Win2K DHCP server on the other side of the WAN was set up in a similar fashion. This server needed the use of superscopes, but not to the extent that the first one did.

Loose Ends
The Win2K DHCP server was still having difficulty assigning IP addresses from the main router in this location. The DHCP requests were received by the server, but the DHCP Offer wasn’t getting back to the client which issued the request. The DHCP server was unable to resolve back to the logical subnets. To fix this, we had to statically assign an IP address for each of the logical subnets to the NIC on the DHCP server. This allowed the DHCP server to resolve back to the client on the logical subnet.

So, with the Win2K DHCP server ready to go live, there was one more feature that had to be enabled on the server. When we shut down the Unix JOIN service, the majority of the clients would have IP addresses assigned to them that weren’t due to have their leases expired for several days. There would be no need for these clients to contact a DHCP server for several days, so how could we make sure that the Win2K DHCP server didn’t issue an address that has already been leased to a client by Unix JOIN?

There were many possible approaches. One is to write a script to force a release and renewal, but I personally like to live by the theory of Occam’s Razor—simply put, if there are multiple solutions to a given scenario, always pick the simplest. Win2K DHCP services would PING an IP address prior to issuing it. This is accomplished through the DHCP MMC:

1. Right-click on the DHCP server and select Properties.
2. Select the Advanced tab.
3. Increment the value in the box next to “conflict detection attempts.” The default value for this is 0. This isn’t the best setting, since the server will simply issue an address without checking to see if it’s already in use. (Figure 2).

Figure 2. Setting the conflict detection attempts to a number greater than zero ensured that the Win2K DHCP server wouldn’t issue an address that had already been leased to a client by Unix JOIN.

If the DHCP server determines that the IP address about to issued has already been handed out, it marks that address as “bad” and moves on to the next available address. This process will continue until the DHCP server finds an address it can issue. The “bad” addresses will remain marked for one hour, after which they’ll be placed back into the available issuing pool. These addresses may remain marked as bad until the client that was originally issued this address by Unix JOIN needs its lease renewed. At this point, the Win2K DHCP server will grant the client its IP address and make the appropriate changes in the DHCP tables.

Final Thoughts
Eventually, all the clients that were issued IP addresses from Unix JOIN were picked up by the Win2K DHCP server. Overall, the process was not painless, but a true learning experience. Although Win2K server is a rock-solid operating system, anybody who has worked with it for any length of time can verify that you need to roll up your sleeves and get your hands dirty to make it really sing and dance. The solutions may not always be apparent, but they exist.