Choose the best protocol for your network

Windows NT supports several network protocols, and the protocol you use can affect your network performance significantly. To choose the best protocol for your network, you must understand the protocols NT supports, how each works, and where each protocol is most effective. Then, consider the resources that are necessary to implement your protocol choice.

NetBEUI
When Microsoft developed Windows for Workgroups (WFW), the NetBEUI protocol was a good choice, and many networks run it even after they convert to NT and Windows 95. The name NetBEUI comes from NetBIOS Extended User Interface, and this name has created confusion since NetBEUI's introduction. NetBIOS is a programming interface, and NetBEUI is a transport protocol. Most Microsoft software and many other packages that run on Windows platforms use the NetBIOS programming interface. Thus, many network administrators continue to use NetBEUI after they install other protocols, because they think the application software can't function without NetBEUI.

IBM developed NetBEUI in the mid-1980s for small workgroups with closely linked computers. NetBEUI was by far the fastest NT protocol available until Microsoft released NT 3.51. Microsoft concentrated its programming effort on speeding up TCP/IP in NT 3.51. TCP/IP has overtaken NetBEUI in popularity because of the computer industry's push to make TCP/IP the standard protocol for business applications.

NetBEUI's ideal users are small businesses or individual departments in larger corporations. NetBEUI is a reasonable choice for small networks. It requires relatively little memory; it's self-tuning, with no user-configurable parameters; and it's compatible with Microsoft networks. NetBEUI is a good choice for DOS clients, because it requires minimal system memory. (Remember, you must run it on the server and the clients.)

One of NetBEUI's disadvantages is that it lacks routing capability (which might be an advantage if you want to isolate traffic on a network segment). It does not scale well, because it uses broadcasts for many functions, including identifying other computers (through NetBIOS broadcasts). The broadcast approach works on small networks, but the network traffic it generates can overwhelm a large network. Although NetBEUI is compatible with Microsoft networks, you must have another protocol if your network includes Novell or UNIX servers.

Is NetBEUI for you? The answer may be yes, if you have a small network. However, be prepared to remove or disable NetBEUI when your network outgrows it.

NWLink
NWLink is Microsoft's version of Novell's IPX/SPX protocol. Networks with Windows clients that access Novell servers use NWLink: for example, a client/server application in which the client runs on NT Workstation or Win95 and the server component, such as a database, runs on a Novell server. Small networks can use NWLink, even without connectivity to a Novell server. NWLink requires less configuration than TCP/IP does. Like TCP/IP, NWLink is routable.

A common problem with NWLink is having the wrong frame type, especially in a mixed-frame environment. A frame is a package of information transmitted as a unit from one network device to another. An Institute of Electrical and Electronics Engineers (IEEE) frame-type specification outlines each option for formatting network data. NT attempts to detect the frame type through its Auto Frame Type Detection (which Screen 1, page 214, shows). However, NT will detect only one frame type, even though the network may be running several. Before version 3.3, NetWare's default was to use frame type 802.3; with version 3.3 and later, NetWare switched to 802.2 as the default. Recent versions of NT (3.5 and later) look first for 802.2 frames and accept this as the default frame type. NT does not continue to search for other frame types. Thus a computer on a mixed-frame network can talk to some but not all of the other computers on the network. You can solve this problem by telling NT to use multiple frame types, as Screen 2, page 214, shows.

TCP/IP
Microsoft is channeling its programming effort into TCP/IP. The corporate world prefers TCP/IP, and you must use it to connect to the Internet, so it's becoming the industry standard. TCP/IP uses more memory and system resources than NWLink or NetBEUI uses; thus it might not be the best choice for small networks. It certainly is not the best choice for DOS clients.

TCP/IP requires more configuration than NWLink or NetBEUI requires. With TCP/IP, network administrators must decide how to assign IP addresses­ and must worry about how to obtain them, because IP addresses are limited until IP6 comes out. The Internet Network Information Center (InterNIC) assigns IP addresses, which currently use 32 bits. This addressing scheme limits the number of available IP addresses (available at http://ds.internic.net). The IP6 specification will introduce 128-bit addresses to ease the availability problem. For now, InterNIC has assigned or reserved almost all of the available IP addresses, and obtaining a range of valid IP addresses is difficult for a small company. You can make up your own IP addresses, but when you connect to the outside world through the Internet, you need a valid InterNIC-assigned IP address. (For information about IP addressing, see Mark Minasi, "You Can't Spell 'Internet' Without 'NT,'" February 1996.)

You must decide whether to assign IP addresses automatically or manually. If you choose automatic assignment, NT can help with the Dynamic Host Configuration Protocol. DHCP is available on NT Server and uses additional system resources. Your Backup Domain Controller (BDC) can run DHCP and perform user validation. When you configure the DHCP server, it automatically handles IP addressing. Screen 3 shows an example DHCP server configuration, including addresses reserved for printers, routers, and other system devices.

If you don't use DHCP, you must manually assign and track IP addresses, making sure the addresses are typed in correctly and troubleshooting problems that occur when people move computers around the network. These tasks are overwhelming in a large organization and can be equally daunting in a small company. Screen 4 shows manually assigning an IP address in the TCP/IP Properties window.

Other Considerations
If you use TCP/IP as your network protocol, you might discover that your computers cannot communicate with one another. If they are on different subnets­that is, they have different IP addresses and are separated by a router­they will not be able to find one another. This problem occurs because applications and the operating system refer to a computer by name (e.g., SERVER1, Accounting2), but TCP/IP requires a network card address rather than a name.

A computer running NetBEUI can find the address for another computer by broadcasting the name of the target computer and then waiting for a response, which will include the target computer's address. Connecting to a computer on another part of the network is not an issue for NetBEUI, because NetBEUI is not routable. A router divides a network into segments, each with its own set of addresses.

Because TCP/IP is routable, you need a way to find addresses for computers on different parts of your network. Broadcast messages don't pass through the routers, so you must know the target computer's address to send a message directly to it. One solution is to keep a list of your network computer names and IP addresses. TCP/IP can use this list, in the form of an LMHOSTS file, to convert a computer name to an IP address and then send a message to the IP address to ask for the network card address. (For more information about LMHOSTS files, see Mark Minasi, "Inside a NetBIOS Name Resolution," March 1997.) However, keeping LMHOSTS files up-to-date is tedious and difficult in a rapidly changing environment, especially if you use DHCP.

Another solution is to install Windows Internet Naming Service. WINS is an automated database of computer names and IP addresses. After you configure the WINS server, your client computers register with the server by giving their names and addresses to the WINS database when they start up. When a client computer needs another computer's address, it asks the WINS server. (For more information about WINS, see David Lafferty, "Setting Your WINS Strategy," October 1997.) An NT server such as a BDC might be a good candidate to function as a WINS server. A WINS server must have a fixed IP address that the DHCP server can automatically pass to clients when they receive their IP addresses from the DHCP server. Think of this process as dialing 411 on the telephone to find other phone numbers through directory assistance.

The More the Merrier?
More is not necessarily better with protocols. A company often starts with a small peer-to-peer network and perhaps uses WFW or Win95. Then, as more users come online, the company adds a server. Thus a company might add NWLink to its network to communicate with a NetWare server. When the Internet becomes important to business, the company adds TCP/IP. But how often does the company's network administrator go back and make sure that only the necessary protocols are running? To many administrators, leaving older protocols in place seems safer, in case users have not converted to TCP/IP.

Running multiple protocols on an NT-based network is a bad idea. Many NT system functions, such as browsing, depend on broadcasts. Each computer announces its presence on the network when it first comes online and every 15 minutes thereafter. Because a computer does not know which protocol the server is listening to, every computer sends out a broadcast on each of its protocols. If your network is running NetBEUI, NWLink, and TCP/IP, your browser service initiates three times as much network traffic. Although the broadcasts stop at the routers, they generate excessive local traffic.

If you want to reduce network traffic, consider disabling older protocols that you no longer use. On NT computers, go to Control Panel, Services, Network; select the Bindings tab. In the Bindings tab window, you can disable any protocols (rather than remove them), as Screen 5 shows. Thus, if one of your users needs a protocol, you can reenable it.

If disabling protocols worries you, run the Network Monitor utility that comes with NT, or run the full version of the utility, which is part of Systems Management Server (SMS). The Network Monitor utility will show you which protocols on your network are generating the most traffic. You can then make an informed decision to eliminate some of them. Your choice will affect your network's productivity, and the decision depends not only on the protocols you need but also on the protocols you can live without.