 Using subnet masks to organize fixed IP systems
At the office we had an interesting problem. We build custom racks
with as many as ten computers each that end up being delivered to
customer sites. The folks in the office need to be able to find them by
IP address and by Windows workgroup and system name, too. Add to that
the fact that we don't want to add lots of internal routers, and that we
periodically ship one rack out and start on a new one, and you have
interesting problems. We would regularly have a computer in one rack
or on someone's desk start sending signals out that would mess up the
rack by presenting itself as one of the systems in the rack. This was
bad for both ends, because the server would suddenly have one too many
clients talking to it, and the guy up in his office would have no idea
what he had just connected to, except that it wasn't the other box at
his desk. The solution we finally came up with was to use normal DHCP
for our permanent internal systems just like before, but would define
fixed IP ranges for each of the racks and their computers. The problem
with this was that we wanted easily identifiable network addresses for
host and client systems in the rack. NAT (Network address translation)
is used to map the internal network to a non-routable set of addresses
that are all translated through one central router. This was all dandy,
except that we needed more than the typical 256 addresses of a class C
network so we could more easily keep the racks grouped by address. Even
though we didn't really need 65,536 network addresses, we changed our
LAN to a class B network. With a class B network, we could assign the
third IP number to a specific rack, and know that the entire network
could still talk without having to resort to adding temporary routers.
It also made it possible to set all the rack server IP addresses to the
same fourth digit, making them easier to identify. Finally, we also
assigned a specific third digit to each of the software developers so
they would not collide with any of the real servers while testing. The
entire switch was invisible to everyone, since their systems still
worked fine on the normal internal LAN. Once they rebooted, they got an
address in the same DHCP space as they always did. The only difference
for the regular users was that their subnet mask changed from
255.255.255.0 to 255.255.0.0. Now it's really easy to find what we're
looking for once we know that Rack A is assigned 2 as it's third digit,
and servers are always at a fourth digit of 210. Since we use 10.100.*.*
on our LAN, we know that 10.100.2.210 is Rack A's host. Confusion has
been reduced, and more importantly, interference between hosts and
developers testing new host software has dropped to zero.
|