Previous Table of Contents Next

As shown in Figure 7.7, the center of the network is composed of ring routing IPX only. The IP eXchange product permits the use of IPX-only clients when accessing the Internet and other IP-only resources. However, it requires a client software application; this prerequisite negates some of the advantages offered by IP eXchange. In addition, most network cores have migrated to IP only (in contrast to IPX only). As a result, the current and future trends will likely be to continue to use NBT in most installations. IPX/NWLink would still be preferred in large, legacy Novell installations, particularly when applications mandate the need to remain on IPX.

NetBEUI in a Small Network

The use of the NetBEUI protocol typically infers the use of a small network, as NetBEUI cannot be routed. Therefore, the network design is very limited, and the use of WINS servers is optional, as the NetBIOS protocol can operate only in broadcast mode. This type of installation is frequently found in schools and small offices, although basic home networks also may use only NetBEUI/NetBIOS.

In these networks, a single station is elected the Browse Master. All other stations advertise their presence on the network with a broadcast and use a broadcast to locate resources. The election of the Browse Master is also handled via broadcasts, and the network can support several backup Browse Masters. Remember that this type of network was deployed frequently in peer-to-peer environments, not in client/server installations (for which the broadcast model works well).

NBT in a Large Network

The IP protocol exploded onto the Windows networking scene with the growth of the Internet. However, the protocol offers benefits beyond access to the world’s largest network.

The IP protocol is one of the most scalable. New features are being added to the protocol every month, and should the designer wish, it is possible to use IP with up to 1000 hosts on a subnet. However, this design requires specific attention to broadcasts and bandwidth.

Network designers frequently select the IP protocol for Windows installations in modern network design. The obvious benefit is standardization on a single protocol that is supported on all desktop platforms. With NBT, the circle is complete, and Windows-based systems can also operate.

Many of the other topics in this chapter relate to NBT, including WINS and DHCP. Figure 7.8 illustrates one possible example of an NBT network installation for a multinational firm. Note that most firms would include BDC installations and multiple WINS servers.

Designers should note that the SAMBA utility is available for Unix hosts to provide SMB (Server Message Block) services to Windows-based systems. This permits file and print sharing (functions that use the SMB protocol) without the need for the NFS and LPD Unix applications on Windows.

FIGURE 7.8  NBT, NetBIOS, and TCP/IP in a large network

Remote Networking with Windows NT

Remote networking services are incorporated within Windows NT to service dial-up connectivity. Access to the Public Switched Telephone Network (PSTN) is universal and provides an easy method for users to access e-mail and files.

Microsoft’s Windows NT Remote Access Server (RAS) is built upon the Point-to-Point Protocol (PPP), which provides support for multiple upper-layer protocols, including those identified in Table 7.3.

TABLE 7.3 PPP-Supported Protocols and Their RAS Names

Upper-Layer Protocol RAS Notation


Cisco products will also support these encapsulations when running IOS version 11.1 or greater.
Network Design in the Real World: Remote Access

From an administrative perspective, designers should discourage the use of a single server for RAS and traditional file and print functions. While Microsoft scaled RAS to 256 connections on the Alpha platform, it may be even better to consider a dedicated, hardware-based remote access solution, such as the Cisco AS5x00 product line. Security, manageability, and scalability should drive this decision process, yet many RAS installations begin with cost and rapid deployment as driving factors.


This chapter addressed a number of issues related to the common desktop protocols—NetBIOS, AppleTalk, and IPX—and introduced networking with Windows, the most common desktop environment.

Windows networking incorporates a number of standards and proprietary-based services, including WINS, DHCP, DNS, DDNS, NBT, NWLink, and domains, which are important for the designer to understand and consider when architecting the network.

This chapter discussed the following topics:

  The negatives of broadcasts in network designs
  The differences between workgroups and domains
  The use of the LMHOSTS file in NetBIOS networks
  The use of WINS servers in a network and their ability to reduce broadcast traffic in support of NetBIOS systems
  The integration of DNS and DDNS with WINS and NetBIOS networks
  The use of DHCP for address assignment
  The control of DHCP scopes to allocate permanent, manually assigned addresses to servers and routers
  Considerations for selecting a routable protocol for NetBIOS encapsulation
  The functionality of the Browse Master
  The RAS application and the underlying protocol support

In most modern networks, designers need to focus on the Windows environment more than Novell and AppleTalk. However, understanding the mechanisms by which each of the desktop protocols operates will greatly facilitate troubleshooting and support considerations. In addition, designers are frequently called upon to support multiple platform installations or to migrate from AppleTalk and IPX to IP.

While not addressed in this chapter, cost and history also are factors in NetBIOS/Windows network design. The battles between Novell and Microsoft have been effectively rendered moot, and the best outcome from this history is a realization that the best tool for the job makes the most sense.

The issue of thin Windows clients (terminals that display only applications served from a multiuser server) is also outside the scope of this chapter.

In short, much progress has been made in the technology of these tools in recent years. Designers should carefully measure the traffic loads generated by these devices, particularly during traditional peak traffic periods. Thin clients can greatly simplify administrative issues, but it is important to ensure that sufficient capacity to store all data on the server is available, and that all mouse/keyboard and video updates are transmitted efficiently across the network—such datagrams consume a surprising amount of bandwidth.

Previous Table of Contents Next