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.
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:
- Right-click on the DHCP server and select
Properties.
- Select the Advanced tab.
- 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.