Top Ten Corporate IS Gotchas: Network Design

In a perfect world, all networks would be designed from the ground up to accomodate all possible phases of future growth which would, of course, be predictable. As I've said in other documents, though, this is not a perfect world. Network designs grow and change over time, components become obsolete, new technologies are deployed and old ones removed, and in all cases there is a good reason that something was implemented, once upon a time.

Networking is both the easiest and the hardest field in computing. It's the easiest because, unlike many other fields, it's actually possible to tell what's 'really' going on. Things actually work according to the standards, nearly all of the time -- if they don't, then they violate the standards and fail to work in some obvious manner. It's the hardest, though, because many of the technologies are unfamiliar even to experienced computer technicians, and the actual design of a network involves interplay between a large number of components simultaneously.

Nonetheless, this document lists a series of items to check in your own network that can improve the throughput, reliability, and even simplicity of the network, making it more able to function at peak performance. If you click on Network Neighborhood and get that annoying flashlight, or sometimes have trouble logging in, or if things seem unreasonably slow, read through this document.

Network Protocols

A complete discussion of network protocols is well beyond the scope of this documents. For the purposes of this section we'll focus primarily on the three protocols supported for Windows Networking. A brief discussion of each appears here.

Network protocols are, at their core, a convention: an agreement among computer hardware and software vendors that information will be transmitted this way, in this format, in this manner. Each protocols has its own advantages and disadvantages. All three of them can carry Windows file sharing information, enabling you to find computers, map network drives, share printers, etc. Think of them as three separate radio stations, each broadcasting on its own frequency. All three of them can be picked up and received, coexisting on the airwaves without interfering with each other. Or, at least, that's the theory.

NetBEUI

The simplest protocol is called NetBEUI. It's essentially a paper-thin wrapper around the NetBIOS protocol used by Windows to map drives, share printers, and locate servers. It is non-routable, meaning that it cannot cross 'broadcast domains' -- in short, this usually rules out its use across most kinds of wide-area networks, such as two offices connected together. It's designed for very small networks, and has slightly lower overhead than the other protocols. In general, I do not recommend its use on any sort of corporate network.

IPX/SPX

Next is IPX/SPX, often called simply IPX. This protocol was originally used with the old Novell networking standard, and is somewhat obsolete. Nonetheless, it is supported for the use of Windows networking, though not encouraged. IPX is routable, so it can cross network boundaries; however, not all routers support passing IPX traffic across them, so it often can add an extra cost and configuration time required when setting up inter-office links.

There is also a hidden gotcha with the IPX protocol. Unlike NetBEUI and TCP/IP, which always use a single frame type, IPX can use any of four different frame types. A frame type is a method for representing data on an ethernet line, and while they can coexist peacefully on the same network line, they are mutually incomprehensible. A packet sent via IPX on the 802.2 packet type is not visible to a system that can only hear the 802.3 frame type. This feature was introduced into Novell because some old network cards could only handle certain frame types. The idea was that the Novell server would understand all of the frame types that were in use on the network, and take care of any routing issues.

Here's the rub. Windows can only understand one frame type with IPX -- it has to pick one of the four and the others are incomprehensible. By default, Windows is set to a frame type of 'Auto', telling it to auto-detect. If it can't auto-detect, it'll pick 802.2 as its default frame type. In a network where only one frame type is running, this is perfectly fine. However, if you have a Novell server running, it more than likely has more than one frame type bound to it, or if that frame type isn't 802.2 (which it probably isn't -- 802.3 was the most popular), then you have a recipe for disaster.

Here's why. Windows will try to auto-detect the packet type. However, if more than one network protocols is in use, it stands a chance of detecting a different protocol than the protocol another Windows machine finds. Even if the novell server has only one protocol bound to it, there's still the chance one Windows machine will fail to notice a packet before it defaults to 802.2. Then you have that one machine generating 802.2 packets... which another machine might detect. And so forth.

Why does this matter? Because it is vitally important for Windows networking to function properly that every machine in a domain be able to see every other machine in a domain. The reasons for this are explained later. If the IPX frame types don't match, then you wind up with a 'net-split', with part of your network on one protocol and part of it on the other. This is bad, especially if you're on the side without a domain controller.

If you want to run Windows networking over IPX, it is important that you hard-wire the frame type in the IPX/SPX protocol properties. Yes, this contradicts Microsoft's documentation, but it's not pretty when the frame types don't match. Actually, my real suggestion is that you not use IPX/SPX unless you are using Novell prior to version 4, and even then I suggest that you 'un-bind' Microsoft Networking from it if you also have TCP/IP installed.

TCP/IP

TCP/IP is the protocol used on the Internet to carry information, and it is emerging as the dominant networking protocol by far. Nearly every system out there has the ability to speak TCP/IP, and those that don't are either incredibly obsolete or rapidly struggling to add that support. If you want to add Internet connectivity or Intranet connectivity to your network, you have few options but to add TCP/IP to your network protocol list.

TCP/IP is the only one of the network protocols that is not almost entirely self-configuring. Instead, its address must be manually input into the system, which adds the task of managing the addresses. Nonetheless, it's emerging as the dominant standard because of the influence of the Internet, and many services have started to rely heavily upon its presence.

In fact, TCP/IP is enough of the dominant protocol that most of the rest of this document will assume that you are using it, except where specifically noted otherwise. Windows 2000 actually requires its use if you want to migrate to the Active Directory; it must at least be installed in order for a domain controller to be set up.

If you aren't using TCP/IP yet, you need to add it, and get rid of all other network protocols that you don't absolutely need. Otherwise, you'll find it almost impossible to migrate to Windows 2000, and many newer services will not be available to you in the future.

Browsing

When you double-click on Network Neighborhood, or view the entire network in My Network Places, you are viewing the 'browse list'. This is a dynamically maintained list of all the NetBIOS hosts on the network that are capable of providing network services. It is maintained by a computer called the 'master browser'.

You can't select which computer is the browse master. Windows determines that automatically by staging a 'browser election'. When a browser election occurs, all potential master browsers dump their credentials out onto the network for everyone to see, sort of like what a presidential debate is supposed to be. If a system sees credentials better than it has, it concedes the election; if a system does not see credentials better than it has, it concludes that it won. It's an elegant system.

Unfortunately, you have the occasional 'Florida' situation, where not all ballots get counted. If computers can't see one another, then they can't see the other credentials. They might conclude that they, in fact, are the winner, at the same time that another system concludes the same thing. You can end up with two master browsers (a browsing conflict), and when that occurs, the network is divided into two separate chunks. If your side doesn't contain a domain controller, then you'll find it very hard to log in.

One final note about browsing. Microsoft states that browser elections are 'rigged', so that the domain controller will always win. While this is supposedly the case, I've seen situations where a lowly Windows 95 laptop takes on the Master Browser role, usually after the domain controller gets shut down and restarted. The primary domain controller is not necessarily the master browser.

Multiple Network Protocols

As mentioned above, it is absolutely critical that all Windows machines in the same domain and on the same network segment be able to communicate with one another, and further, that they be able to see one another's broadcasts. The reason for this is described above under 'Browsing'. If this does not happen, chaos can erupt. No one wants that.

Windows typically will pick one network protocol which it will use for browsing and browser elections. If this is the same protocol everyone else is using, then life is good. However, if different systems pick different protocols, then the potential for browsing conflicts arises.

You should have exactly one protocol on your network, if possible. If it is not possible (for example, if you have print servers that only speak NetBEUI, or old Novell servers that require IPX/SPX), then you should un-bind Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks and the Server and Workstation Services from everything but TCP/IP (or whichever protocol you pick).

Duplicate IP Addresses

These should be avoided at all costs. If Windows sees a duplicate IP address, it shuts down TCP/IP networking on that interface until (usually) it is rebooted. The two best ways to avoid IP address conflicts are the use of DHCP (described later) and the keeping of an accurate and up-to-date IP map for your network. Using DHCP doesn't keep you from having to write down the addresses for anything that doesn't use DHCP, however.

Netmask Problems

A full description of what netmasks actually mean and do is beyond the scope of this document. However, the important thing to remember is this: unless you really, really know what you're doing, all systems on the same network segment should have the same netmask, and it should be the right netmask. The number of times when I've intentionally used a different netmask on one host than I did on another I can count on one hand.

A special problem arises with non-Windows hosts and netmasks. Even though Windows understands netmasks, it considers the 'broadcast address' on a network segment to be not the highest address in the block, but instead 'all 255's' at the end. Exactly how many 255's is based on the 'class' of the address -- something else that's beyond the scope of the document.

For example, if you type 'route print' at the command prompt, you might see something like this:

  Network Address          Netmask  Gateway Address        Interface
          0.0.0.0          0.0.0.0    10.66.141.158    10.66.141.154
    10.66.141.152  255.255.255.248    10.66.141.154    10.66.141.154
    10.66.141.154  255.255.255.255        127.0.0.1        127.0.0.1
   10.255.255.255  255.255.255.255    10.66.141.154    10.66.141.154
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1
        224.0.0.0        224.0.0.0    10.66.141.154    10.66.141.154
  255.255.255.255  255.255.255.255    10.66.141.154          0.0.0.0

In the above example, the valid range of addresses is from 10.66.141.152 through 10.66.141.159, with the lowest and highest addresses reserved. The highest address is reserved for the broadcast address: 10.66.141.159, which is the address non-windows hosts will use. However, in the example above, notice the line 10.255.255.255. That is the broadcast address Windows will use. This is technically incorrect according to the RFC's; however, since all Windows hosts do it, there's no real problem.

The problem comes when you have a non-Windows host doing Windows networking, such as a Unix box running Samba, some print servers, etc. These hosts will use the 'correct' broadcast address of 10.66.141.159, so those broadcasts won't be see by Windows, which is listening for 10.255.255.255. In some cases, you will have to hard-code the broadcast address for the purposes of Windows networking so that the system can correctly participate. You might even have to put in an incorrect netmask to get it to function properly in this environment. It's sad but true.

Another problem can potentially arise if you use a netmask that's larger than the class. For example, 192.168.16.0 is a class 'C' address, and is considered to have 254 usable addresses. The broadcast address is 192.168.16.255 by this criterion, and that's what Windows uses. However, it's perfectly possible and legal, according to the networking standards, to put four of these together, so your address range goes from 192.168.16.1 through 192.168.19.254. Notice the issue. The 'real' broadcast address is 192.168.19.255, while Windows will be using 192.168.16.255. This wouldn't be a problem; however, consider a workstation with the address of 192.168.17.56. By the rules of IP, that system is on the same segment, since it's in that same larger address range. But Windows would consider its broadcast address to be 192.168.17.255. Even though they're on the same network block, 192.168.16.45 would not see 192.168.17.56's broadcasts, because of this issue.

To summarize -- don't take multiple Class A, Class B, or Class C addresses and aggregate them if you want to run Windows networking over them. Bad Things Will Happen.

Windows Internet Name Service (WINS)

WINS is an unusual beast, designed to deal with some of the problems that arise in wide-area networks over TCP/IP. Normally, not only browsing but name resolution (taking a name like '\\server1' and determining that machine's IP address) occur through broadcast messages. In essence, the originator shouts, "I'm looking for server1", and server1 responds, "That's me!".

The problem is this: broadcasts aren't forwarded through routers, normally. Even when they are, if the IP segments aren't similar enough for Windows's trick (shown above) of using a larger netmask than might be strictly proper, then the workstations won't see each other's broadcasts. Also, broadcasts of this nature consume bandwidth. For a local area network, it's typically a tiny fraction of the total capacity, but for a slower inter-office link it might be a much higher percentage.

WINS provides a centralized repository for this information. When a system is configured to use WINS, it contacts the WINS server when it boots up in order to register its address information. Basically, it tells the WINS server, "this is my name, this is my address, this is a list of services I can provide". The WINS server stores this information in its database. When another computer needs to find a resource or a server, it contacts the WINS server requesting the information. Much cleaner than all the broadcasts that get echoed throughout the entire network.

Even on a local area network, WINS provides a much cleaner solution, since name registration and release are performed by a central authority, not left as a 'free-for-all'. It makes administration easier, as well, since this database can be viewed using the WINS Administrative Tool on the server.

When configuring WINS, there is one important rule to remember: all workstations on the same segment or in the same 'domain/workgroup' must share the same WINS servers. If multiple servers are specified, they must be specified in the exact same order on each machine. If this does not happen, chaos ensues.

A client which has a 'WINS Server' configured, either in the network control panel or obtained through DHCP, is said to be WINS-enabled. In other words, it uses broadcasts only as a last resort, performing all of its registration and lookup of names through the WINS server. WINS-enabled clients do not normally broadcast their names when they start up. Instead, they discreetly contact the WINS server to register their names. Non-WINS enabled clients shout it out via a broadcast for all to hear.

On a single-segment network, either method will work just fine, so long as all the systems agree on which method will be used. If it's not consistent, then two different sets of information will be created. The WINS server is supposed to listen broadcasts to keep its database consistent, but the systems doing broadcast, since they can't access the WINS database, can't see those machines that registered quietly with the WINS server. Instead, they only hear the name registrations for those systems that are using broadcasts. If a domain controller is using WINS, then those systems not using it might well not be able to see it.

A further complication arises due to browsing. Even when WINS is enabled, browser elections are still conducted using broadcasts, but with a twist. The winner of the election will, when it wins the election, discreetly inform the WINS server of its victory if it's configured to use WINS. Of course, if it's not WINS-enabled, then it won't register in this manner. However, WINS-enabled clients will look for the master browser via the WINS database. They will receive the address of the last WINS-enabled master browser to have won an election... not the current one. Unable to locate the master browser, these clients may be unable to locate domain controllers, and will refuse to allow network logons.

Browsing and WINS is a classic problem in Windows networking. The fact that browsing absolutely has to happen via broadcast adds an additional set of requirements for configuring a Windows network. WINS has the ability, of course, to replicate its database to another WINS server, to attempt to keep the databases consistent. At first glance, this might seem like a solution to the 'WINS Server Order' problem: just configure them to replicate to one another. However, WINS replication cannot be configured to be very fast. You can set a minimum of 4 items that must change before a 'push' trigger is generated, and a minimum delay of several minutes for pull replication. The trouble with this is that the master browser entry changes every time there is an election -- but might well not get replicated to the other server. This is why it's important, even with replication, to make sure all systems get configured with the same WINS settings.

Disable Potential Master Browsers

By default, every computer in a Windows network the provides any services at all is a potential master browser. This includes any Windows NT or 2000 computer system, as well as any Windows 95/98/Me computer that has File and Printer Sharing for Microsoft Networks installed.

Windows 95/98/Me are perfectly good master browsers in a small workgroup enviroment, where they may be the only type of computers in the network. That's why the functionality was installed. However, these systems were never intended to function in that capacity in a domain environment. Browser elections are 'rigged' to supposedly always allow Windows NT to win, and to give preference to servers and, especially, domain controllers. However, this doesn't always work in practice. In the field, any potential master browser has the ability to, under some circumstances, become the master browser.

This isn't that big of a problem except when WINS is added to the equation. When a Windows 95/98/Me machine wins an election, it doesn't know enough to register itself with the WINS server. Instead, it broadcasts to the network indicating it has won the election. Sometimes this broadcast gets picked up; sometimes it doesn't. This causes havoc. In addition, workstations can lock up, get rebooted, suffer from power failures, get turned off by users, or get unplugged from the network (in the case of laptops), often without any warning. In short, no Windows 95/98/Me machine should ever become a master browser in a Windows NT Domain network.

The trouble is, the "potential master browser" option is on by default. It was designed to be self-configuring and self-tuning, and so there is really only one parameter than can be configured: whether or not the system can become a potential master browser. If you have at least one network server, then the ability to be a potential master browser should be disabled on all Windows 95/98/Me computers in your network. If you have at least two servers, then the ability to be a potential master browser should be disabled on everything in your network except those servers.

There is an option to configure this through the 'File and Printer Sharing for Microsoft Networks' component in the Network control panel in the Advanced tab; it's labelled "Browse Master". However, this option does not always directly control browsing. It doesn't seem to draw from the registry entry properly, and so I strongly recommend changing this directly in the registry itself.

Disabling Browsing on a Windows 95/98/Me System

Select Start, then Run, then type "regedit" and click OK.
Navigate to the following location:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\VxD\VNETSUP
Look for a value named "MaintainServerList" in the right-hand pane of the window. If it doesn't exist, then the system is not a potential master browser.
There are three possible values for MaintainServerList. "0" means the system will never become a master browser (Disabled). "1" means the system will always try to be a master browser (Enabled). "2" means the system will participate in elections and, if it wins, will become the master browser (Auto). You want to set it to "0" (Disabled).
Close the Regedit utility and reboot.

Disabling Browsing on a Windows NT/2000/XP Machine

Select Start, then Run, then type "regedit" and click OK.
Navigate to the following location:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\
Services\Browser\Parameters
Look for a value named "MaintainServerList" in the right-hand pane of the window. If it doesn't exist, then the system is not a potential master browser.
There are three possible values for MaintainServerList. "No" means the system will never become a master browser (Disabled). "Yes" means the system will always try to be a master browser (Enabled). "Auto" means the system will participate in elections and, if it wins, will become the master browser (Auto). You want to set it to "No" (Disabled).
Close the Regedit utility. Open the Services Control Panel or Administrative Tool.
Locate the Computer Broser service. Double-click it and set it to be Disabled.
Close the window and reboot.

You'll want to have at least two potential master browsers on the network. If you don't, then when the master browser reboots, the browse list may be lost. If you have to select a workstation, try to select a Windows NT, 2000, or XP machine to act as the 'backup' master browser. If you don't have at least two Windows NT, 2000, or XP machines, then you should probably avoid using WINS unless you have to.

Implement DHCP

Finally, one of the best things you can do to improve your network is to implement DHCP. DHCP (Dynamic Host Configuration Protocol) allows a server or router to assign IP addresses to clients. But more than that, it also permits the default gateway, DNS servers, WINS server, and domain name to be assigned as well. Just about everything except Windows Domain Membership can be assigned, making it so a system works 'out of the box' when plugged into the network.

There are several advantages to this:

Instead of having to keep track of addresses yourself, you simply set up a range of addresses to be assigned.
You can use the DHCP console to track which client machine is assigned which IP address and, potentially, find ones that are not being dynamically assigned.
Your network becomes more consistent -- the same set of settings gets applied to all machines.
In the event that something changes -- DNS servers change, WINS servers change, or you have to re-map your IP segment, it's as simple as making the change and having the users reboot.
Mobile or notebook computers can be assigned a dynamic address by DHCP. When they're not connected to the network, they don't have the address, and so it won't interfere with, say, remote dial-in or VPN connectivity.

It's strongly recommended that you use a Windows NT or 2000 server as a DHCP server for multiple reasons:

Using a server means that you have a graphical interface to administer it, and to view which clients have been assigned which address.
The database is persistent -- it's stored on the hard disk, and in the event of a reboot or power failure, the server remembers which addresses have been assigned to which clients. This reduces the chance of a duplicate IP assignment.
Windows DHCP permits the assignment of static mappings. With this, an IP address can be reserved for a given workstation by its MAC address, and it will always get that address. You get the accountability of static addresses with the consistency and central management of DHCP.
When Windows 2000 assigns an address through DHCP, it can automatically handle the forward and reverse DNS mappings, even for clients that do not support dynamic DNS.

One important caveat: Do not set up multiple DHCP servers on the same range. They do not share information with each other. This means that DHCP server #1 can assign 192.168.1.100 to one client, and DHCP server #2 can assign 192.168.1.100 to another client, causing an address conflict. It is, however, perfectly valid to have two DHCP servers, so long as:

The IP address ranges for each server do not overlap, and
The IP address ranges are both on the same subnet, and
The options being assigned are consistent and identical on both servers, and
The IP address range being assigned by each server is large enough to independently handle all of the workstations.

Having two servers means that if one goes down, the other can easily take over. It provides a measure of fault-tolerance, and is highly recommended if you have multiple servers and enough IP address space to accomodate all of your workstations.

Active Directory Gotchas

When working with Windows 2000, the Active Directory replaces the traditional method of Windows authentication. Active Directory uses Kerberos, LDAP, and many other industry standard protocols in order to provide networking services. However, there are several things to keep in mind.

First, unless you are running the Active Directory client on every workstation in your company -- including any devices such as Linux boxes and print servers that act as if they were Windows servers -- you will need to continue running NetBIOS. While the Active Directory client is available for Windows 95/98/Me and Windows NT 4.0, it is far more common that you are only fully running Active Directory once your entire network consists of Windows 2000 and Windows XP. Until that time, you are running NetBIOS in addition to active directory, using PDC emulation mode. All workstations and servers should have the 'Enable NetBIOS' setting selected.

Second, DNS is critical to the life of Active Directory. You should make sure of the following:

All workstations and servers should have the same DNS servers listed, in the same order.
All DNS servers should be controlled by you, and should support dynamic update. This means that using your ISP's DNS servers is not a good idea.
All DNS servers should either have the zone whose name is the same as your domain explicitly, or know how to reach it on one of your DNS servers.
All DNS servers should have dynamic update enabled.
If you have multiple DNS servers, they should be set to replicate with one another. Active Directory Integrated zones accomplish this. If you do not use Active Directory Integrated zones, then the first DNS server listed should be the primary, with the others polling from it as secondaries.
The primary DNS domain name of all systems, but most especially the domain controllers, should be the same as that of the domain.
In general, if you have an Internet domain, you should not name your Internet domain the same as your active directory domain. One of my favorite ways to do this is to place an 'ad.' in front of the domain. For example: ad.enter-networks.net.

This page Copyright ©2003 by Enter-Networks.Net. All Rights Reserved. All trademarks referenced herein are trademarks of their respective vendors. Prices and features listed subject to change without notice. All prices are in US Dollars.