Previous Table of Contents Next

Chapter 7
Designing for Windows Networking


ü Examine a client’s requirements and construct an appropriate NetBIOS design solution.
ü Design a source-route-bridged internetwork that provides connectivity for NetBIOS applications and controls NetBIOS explorer traffic.

As the most popular desktop operating environment, Windows holds a substantial position of prominence in modern network designs. Yet this chapter truly encompasses a great deal more than just networking with Windows-based systems and the design criteria for these environments. It also incorporates information regarding the other major desktop protocols—AppleTalk and IPX—as they relate to each other and as they compare to Windows-based systems.

This chapter also discusses the NetBIOS protocol, the foundation of the Windows-based operating systems. NetBIOS-based networks are found in the following operating systems/environments:

  Microsoft LAN Manager
  OS/2 LAN Manager
  MS-DOS with the LAN Manager Client
  Windows for Workgroups
  Windows 95/98
  Windows NT/2000

Also identified in this chapter is the importance of the interoperation of NetBIOS with other protocols. For example, NetBIOS, as a foundation for Windows-based networks, was originally designed to operate over NetBEUI, a non-routable protocol. Both IPX and TCP/IP have been enhanced to support NetBIOS encapsulation, greatly enhancing the protocol’s incorporation into modern large-scale networks and providing designers with a means to support NetBIOS without NetBEUI.

Desktop Protocols

As mentioned in previous chapters, all of the desktop protocols were designed around the client/server model (although Macintosh and Windows platforms could service both functions). This design includes the use of LANs with multiple hosts and typically operates as a single broadcast domain. The client is responsible for locating the server—the GNS process in IPX, for example—and the protocols rely on broadcasts, which adds substantially to the network load.

Unlike NetBEUI, the original underlying protocol for NetBIOS, the other common desktop protocols use routable Layer 3 structures. In Novell networks, these are NCP and SPX packets on top of IPX packets; in Macintosh environments, these are the protocols that comprise AppleTalk. As such, desktop protocols are defined at Layer 3 and above in reference to the OSI model. Most designers work with the desktop protocols as suites rather than addressing the facets of each individual protocol in the stack. This works from an architecture standpoint, as the protocols were designed to operate together, and most desktop issues may be isolated to the access layer of the hierarchical model.


The issue of broadcasts in designs has been raised throughout this book. This is predominately due to the client workstation impact of broadcasts and the overhead on the individual processors caused by receipt of those datagrams. This is not an issue with unicasts, where the destination station performs all processing required by the upper-layer protocols. However, in broadcasts, all nodes in the broadcast domain must process the packet, and the majority of the nodes will discard the information, resulting in waste.

Broadcasts may be measured using two methods: broadcasts per second and broadcasts as a percentage. A good metric is dependent on the number of broadcasts per second—100 being a recommended guideline. Unfortunately, most networkers learned a long time ago that 10 percent broadcast traffic was a threshold and that networks were healthy so long as traffic remained below that value. Yet in practice, using a percentage as a metric is too limited for a number of reasons:

  As theoretical data rates increase, the percentage method permits an increase in the number of broadcasts.
  The percentage method does not consider the true impact of broadcasts in the network. For example, bandwidth is not a concern until collisions, contention, buffering, and other factors are surpassed— none of which relates to broadcasts directly.
  Broadcasts require the host processor to parse the datagram before the packet can be discarded. Since most broadcasts are not destined for a specific host, this is unnecessary overhead.
  The processing of broadcasts can quickly consume processing cycles on the host. At approximately 100 broadcasts per second, a Pentium 90 host is using up to two percent of its processor. While faster processors will also affect this figure, the load from broadcasts does not remain linear. There may be sufficient processor capacity available, but why make it do unnecessary work?

Windows Networks

The NetBIOS protocol is traditionally mapped to the session layer of the OSI model. It relies on names and name queries to locate resources within the network. Thus, network designers should keep the following in mind when architecting Windows-based networks:

  NetBIOS can operate over three lower-layer transports: NetBEUI, NWLink (NetBIOS over IPX), and NetBT (NetBIOS over TCP/IP; commonly referred to as NBT). NetBEUI is not routable.
  Most scalable NetBIOS designs require the use of filters. This mandates a naming convention that lends itself to access lists.
  Cisco routers avail name caching and proxying as enhanced options in NetBIOS networks. Designers should consider these features.

Workgroups and Domains

Groups of computers in Windows-based networks may be organized in one of two logical clusters: workgroups and domains. These groupings are not unlike the zone function in AppleTalk, but there are a few differences.

The basic grouping of machines is a workgroup. Workgroups may be created by any set of workstations, and the cluster does not participate in any authentication or central administration process. Each machine in a work-group may permit access to its resources, and any machine may join the workgroup. Thus the security level in workgroups is quite low, and the model is only suited to small organizations when administration is shared among all the users.

Domains, more formal groupings of computers than workgroups, significantly change the level of security offered to the organization. First, domains are administered via a Primary Domain Controller (PDC). There can be only one PDC for the domain, and it is authoritative for that domain. To provide redundancy, the PDC may be supported by any number of Backup Domain Controllers (BDCs). In practice, most organizations deploy only one or two BDCs in their configurations, although it may be warranted to deploy more. BDCs are typically installed in remote locations to speed local login and authentication while retaining a centralized administrative model.

Previous Table of Contents Next