WAN Design at Shinozaki Automotive Corp

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

By Thomas Schenkman and Michael Shinozaki, MCS—New York

Editor's Note This article is excerpted from "Optimizing Network Traffic," which is part of the Microsoft Press Notes From the Field series that outlines the best system management practices and procedures. For more information on this and other Microsoft Press books, go to https://www.microsoft.com/mspress/.

The procedure for acquiring a dynamically assigned Transmission Control Protocol/Internet Protocol (TCP/IP) address is widely documented, as are other networking services such as Windows Internet Naming Service (WINS) and the Internet's Domain Name Service (DNS). Not much has been written, however, about how to implement these network services together while designing an enterprise wide area network (WAN). This chapter is designed to fill the gap, although it obviously cannot cover every topic and technology needed to design a fully redundant, high performance enterprise network. Still, through explanation and examples of network topology, it should help you understand and overcome some of the more common design problems.

On This Page

In Focus
The Wide Area Network
Case Study: Shinozaki Automotive
Needs Analysis—Defining a Method and an Approach
The Wide Area Network Technologies
Dynamic Host Configuration Protocol
Windows Internet Name Service
Browser Service
Domain Name Service
Domain Architecture Planning
More Information

In Focus

Enterprise

Shinozaki Automotive, Corp., a reseller of automotive parts, rebuilt engines, and transmissions, headquartered in Lindenhurst, NY.

Network

The Shinozaki network consists of 750 retail offices, four regional warehouses, and a headquarters site.

Challenge

Develop a WAN design that connects the offices in such a way as to provide network capabilities relevant to the sites' various line-of-business applications and practices.

Solution

A frame relay inter-exchange carrier, a centralized infrastructure design for DNS and for WINS (with a primary and a backup WINS server at headquarters), and a single user account domain model with centralized administration.

What You'll Find In This Chapter

• Methods for implementing network services together to achieve a WAN design sensitive to your specific business needs.

• How to gather information from your enterprise and use it to assess various configuration and carrier options to create a design that meets business needs, and is affordable, practical, and manageable.

• A discussion of the major network services, their processes and characteristics so that you can better understand the criteria and tradeoffs involved in network design.

The Wide Area Network

The first section of this chapter focuses on the WAN and the subject of topologies, using an example case study to demonstrate some of the methods and concepts used in WAN design.

The big topic in WAN implementation is cost. Many enterprises have already upgraded their local area networks (LANs) from 10 Mbps Ethernet to 100 Mbps Ethernet, and boosted their infrastructures with new switching technologies. When a single network segment can no longer support higher packet transmission rates, the segment can simply be divided, reducing the number of nodes and lowering segment utilization. For most LAN upgrades cost is easy to measure: you add up the best prices you can get on hubs, switches and routers. Once you pay for the equipment and implement it, the upgrade is mostly paid for.

When you "step outside," to WAN design, things change, first of all by becoming more expensive. WANs are too distributed to be served by the less expensive LAN technologies such as Ethernet and Token Ring. Instead, WANs require costlier high-speed transmission, so to contain WAN costs, architects must carefully analyze available technologies, plan exactly where to place systems, and implement the correct WAN topologies.

Case Study: Shinozaki Automotive

To provide you with a working example of the challenges of efficient WAN design, the first part of this chapter focuses on the fictional Shinozaki Automotive Corporation, a reseller of automotive parts, rebuilt engines, and transmissions, headquartered in Lindenhurst, NY. Shinozaki has 15 retail stores in each state, and one warehouse in each of four regions: Northeast, Northwest, Southeast, and Southwest.

Shinozaki employs approximately 19,500 full and part-time employees. Most of the executive staff, finance, and procurement departments (about 3,000 people) are at the Lindenhurst headquarters. Each regional warehouse employs about 350 people to take inventory, and to receive, track, price, and ship products. They use networked personal computers. Each retail office employs about 20 people, who perform tasks ranging from sales to automotive technical assistance. Each retail office has about 20 Windows NT Workstations and one local Windows NT Server for file and print services. These systems are connected to their regional warehouse for technical specifications, product availability, and purchasing.

Needs Analysis—Defining a Method and an Approach

To perform a technical needs analysis of data communications you need to understand what services and connectivity users (and systems) need to perform day-to-day functions productively and cheaply. A good place to start is the enterprise's availability requirements, and you can understand them by looking at how physical sites relate logically. From this point of view Shinozaki's 755 physical sites are of only three types: headquarters (1), retail offices (750), and regional warehouses (4).

Large-enterprise WAN design is not as straightforward as calculating server utilization or LAN transmission speeds, because most WANs require you to analyze many if not all of the enterprise's systems and users. Here is the logical process Shinozaki used:

• Discovery of needed network services: messaging, file and print, fax, database

• Discovery of needed protocols: Systems Network Architecture (SNA), TCP/IP, Internetwork Packet Exchange/Sequenced Packet Exchange (IPX/SPX—used by Novell Netware)

• Discovery of systems maintenance traffic: login, password changes, Dynamic Host Configuration Protocol (DHCP), WINS, replication

• Discovery of LAN locations

• Review of connectivity requirements

• Review of systems management requirements

• Review of available/potential WAN technologies: Integrated Services Digital Network (ISDN), Asynchronous Transfer Mode (ATM), frame relay

• Topology and general service design

• Carrier selection

Discovery of Needed Network Services

Retail Office Discovery

Shinozaki's retail offices need local file and print services. They do not yet have electronic messaging, but are planning to in the near future. Each retail office client requires Internet access. Each retail office manager needs access to the payroll and human resource databases once a week to update employee payroll information. Retail office sales people need access to their regional warehouse's system to check on product availability. And retail offices send daily accounting and sales summaries to headquarters.

Retail office needs summary:

• Electronic messaging. Messaging, calendar, and workflow applications during all business hours.

• File and print services. Large files and technical diagrams must be stored on local file and print server. File and print services do not require much connectivity, but user profiles and account administration must be centralized.

• Internet access. Connectivity to vendors' technical Web sites, sales systems, etc., during all business hours.

• Human resources systems. Connectivity for weekly payroll data transmission.

• Warehouse connectivity. Access to warehouse databases during business hours.

• Accounting and sales. Connectivity for daily transmission of summary files.

• Systems management. Remote control of routers, hubs, workstations, and servers via WAN links for troubleshooting and upgrading system components.

Regional Warehouse Discovery

Regional warehouses need essentially the same connectivity as retail offices. Retail office users need access to the warehouses' parts and stock availability databases. Warehouse users need Internet connectivity, electronic messaging, file and print services, and access to the headquarters databases.

Regional warehouse needs summary:

• Retail office connectivity. See retail office list.

• Electronic messaging. Messaging, calendar, and workflow applications during all business hours.

• File and print services. Each warehouse has a data center for file and print servers, stock and order databases, etc.

• Internet access. For numerous warehouse systems during all business hours.

• Human resources systems. Connectivity for weekly payroll data transmission.

• Accounting and sales. Connectivity for daily transmission of summary files.

• Systems management. Remote control of routers, hubs, workstations, and servers via WAN links for troubleshooting and upgrading system components.

Headquarters Discovery

The headquarters location needs to meet the data requirements of the retail locations and the warehouse locations, which use connectivity to headquarters for the line of business applications described above. Headquarters systems and clients also need Internet connectivity.

Note: In many enterprise WANs, various systems split T1 circuits and channels to supply voice and data over the same connection for services such as voice over frame relay. Applications of this type are not discussed in this chapter, although you may need to consider these services during your needs analysis.

Discovery of Network Protocols

The fewer protocols you implement over the WAN, the less it costs to manage and troubleshoot component systems. In a perfect world, you could simply choose a protocol (such as TCP/IP) that is available on most network operating systems, and services would accommodate it. It seldom works out this simply in the real world, however, where designers are confronted with a complex mix of legacy systems, broadcast technologies, and hardware/software technologies.

Although a single routable protocol simplifies management, it is not a requirement for enterprise systems, where gateways and tunneling can encapsulate protocols into a single routable WAN technology. You need to weigh the benefits of these solutions against the cost of managing a more complex system. No matter how many protocols you use, you need to calculate the network transmission speeds of the various communicating systems.

Shinozaki was happy to find that it could use only TCP/IP for application connectivity.

Discovery of Systems Maintenance Traffic

To calculate the maintenance traffic required in most Windows NT networks, you need to calculate the traffic associated with WINS, DNS, DHCP, and the browser service. (The method described in this section is covered fully in the Microsoft Windows NT Enterprise course.)

All systems maintenance and management traffic is important at this level of implementation. Although in a small network Simple Network Management Protocol (SNMP) may place few demands on the network, at a company the size of Shinozaki it represents the traffic of over 750 connected offices and nodes. Other services such as Novell Service Advertising Protocol (SAP) can also create considerable traffic on this scale.

This chapter focuses on topology and implementation of services. For explanations of network traffic considerations and calculations, see the Microsoft Windows NT Enterprise course and chapters 1 – 3 of this book.

Discovery of LAN Locations

Not all segments of the telecommunications world are created equal. You have to analyze each site to see what services are available. This becomes more difficult but equally important in international enterprises, where branch offices may be located in regions with fewer connectivity options. Exchange carriers can help you during this phase. The AT&T G-INOS service, for instance, allows you to access a database, enter the phone numbers of each of your branch offices, then see various connectivity technologies, prices, and topologies. If you have to discuss options or negotiate arrangements with exchange carriers, start the process early in the design phase.

Review of Connectivity Requirements

Understanding the connectivity requirements is crucial to WAN design. The Shinozaki study has so far identified key service connectivity requirements. Some of these services require connectivity only periodically (for example, the retail office weekly payroll update) and others (for example, messaging) require constant connectivity during business hours. To meet these needs, Shinozaki has a choice: use separate technologies—dial-in access for payroll, and a dedicated service for the Internet and messaging systems—or design the WAN to supply enough access for all services and reduce the number of systems to manage.

A primary need is that certain services (such as T1 and frame relay) require continuous connectivity. You need to identify these services and calculate the traffic they can be expected to generate. You also need to calculate traffic for foreseeable network expansion, such as upgrading to Windows 2000, messaging applications, and client-server applications, and provide for this increase in the communications capability.

How can you do this? Often, you can derive estimates by analyzing services currently in place. For example, if your branch offices have local file and print servers, you can calculate the potential authentication traffic by analyzing a baseline of the current login volume. If these locations currently dial in to an Internet Service Provider (ISP) for Web connectivity, you can further assess potential traffic by tracking what Web sites are used and how often. This data can also help you lower the expected Web traffic by incorporating products such as proxy servers in the design.

Review of Systems Management Requirements

System management concerns itself with servers, workstations, WAN links, and software maintenance. These tasks generate costs and requirements that you need to consider when creating a network design. Numerous vendors supply management tools: Cisco Systems and 3COM corporation offer products for managing routers, hubs, and switches, and carriers such as AT&T and Bell Atlantic provide tools and techniques for analyzing systems utilization, maintenance, and downtime.

How management is implemented can vastly affect the uptime and management costs of these systems. How management systems are designed and implemented in the topology will determine their overall performance and effectiveness. You can consider centralizing management at headquarters or regionalizing it by having management nodes and personnel in selected locations.

Review of Available WAN Technologies

When the needs analysis is complete, you can begin reviewing and assessing WAN technologies such as ATM and frame relay. There are plenty of books and online sources that explain how these technologies work and how much they cost. And you should work with local carriers to see how their implementations can serve your organization's needs. Technologies are discussed in more detail in later sections.

Topology and General Service Design

If you haven't gathered the data discussed so far, you will probably have a hard time defining the shape or topology of the enterprise network you need. Technology and need have driven each other forward in this area, as they have in so many others. Not too long ago, the dedicated links needed to connect offices across the country into a large distributed enterprise would have been prohibitively costly. Multi-drop topologies were used to reduce the cost of specific designs until X.25 and frame relay came along and made reliable connection distance-insensitive. As the need for connectivity evolved, so did technology, which in turn impelled designers to distribute processes and data even more, and so on.

Carrier Selection

Talk to carriers. Investigate their costs, how well their solutions will integrate with other services (voice and video), their quality of service, and their management. Carrier services are discussed in later sections.

The Wide Area Network Technologies

Now it's time to look at technologies and examples of how to use them to implement a large distributed system that meets your organization's requirements.

Review of WAN Topologies

Most large-enterprise WANs comprise many different technologies ranging from dial-up networking with analog modems to high-speed ATM backbones. These technologies are discussed below.

Point-to-Point and Point-to-Many Connections

Point-to-point topologies connect two locations using a carrier's network. This technology was one of the few available in the early 1970s and 1980s, and is still widely used in WANs. Here is an example of point-to-point connection:

Figure 7.1: Point-to-point topology.

Point-to-many topologies connect a single location to multiple locations, usually via a packet switched cloud such as X.25 or frame relay, as illustrated below:

Figure 7.2: Point-to-many topology.

Dedicated Links

Dedicated links are typically point-to-point connections ranging from 56 Kbps to 274 Mbps. They tend to be distance sensitive—the larger the distance between connecting networks, the higher the connection cost. Choosing the correct topology can lower costs associated with dedicated links as illustrated below:

Figure 7.3: Dedicated links.

In this example, the Detroit and California offices connect by dedicated line to the New York office. If the carrier charges per-mile this may be significantly more expensive than the following topology.

Figure 7.4: Multi-drop topology (a).

At first glance this appears to be cost effective, but there are other things to consider. The Detroit–New York link now has to provide transmission speed appropriate to the California office, too. This is often referred to as a multi-drop topology. Another example, illustrated below, shows two offices (California and Seattle) connecting to New York through the Detroit office. The Seattle and California links are each purchased for 64 Kbps; the Detroit–New York link is purchased as a fractional T1 of 512 Kbps.

Figure 7.5: Multi-drop topology (b).

Commonly used dedicated link speeds.

	Carrier Line	Speed
DS-0		64 Kbps
DS-1	T1	1.544 Mbps
DS-3	T3	44.736 Mbps

Packet Switched Services

Services such as frame relay, X.25, and ATM provide permanent connectivity similar to that of dedicated 64 Kbps and T1 links. Various customers share the carrier network using virtual circuits to connect customer locations and provide them with a private network. Since the carrier can share out the services backbone (also known as a cloud) this arrangement usually costs less than a dedicated link.

Frame Relay

Frame relay and X.25 Services are very similar. A frame relay network uses nodes (processors) to route packets of user data to their destination within the frame relay cloud. Each location is connected to the frame relay carrier by dedicated services such as T1. This is usually far less expensive than a dedicated connection to distant locations, because carriers' frame relay clouds are usually distance insensitive—meaning that you do not pay more to move data further.

The connection to the frame relay cloud (T1 and 64 Kbps) is referred to as a port, and the ports for the sites in the network are connected via a private virtual circuit (PVC).

Figure 7.6: PVCs and ports in frame relay WAN configuration.

When you are assessing PVCs as WAN design possibilities you need to know their burst rate (how much they can carry at one time) and the committed information rate (CIR)—the minimum transmission rate guaranteed by the carrier. The CIR tells you the lowest rate you can expect when the frame relay network is congested. If you can live with that, you know the worst case will be OK, and when the network is not congested you can achieve higher transmission rates.

Figure 7.7: Frame relay cloud WAN configuration without PVCs.

The single most common mistake in designing a frame relay network is over-subscription, which is when the sum of PVC's and their CIR's exceed the connecting rate of the destination port.

To notify end-nodes of congestion, the Forward Explicit Congestion Notification (FECN) and Backward Explicit Congestion Notification (BECN) bits are used. These are useful if receiving and sending nodes can throttle transmission rates, but not all routers/protocols can do this.

TCP/IP is another factor. It sometimes resends transmitted packets, not aware that the network is congested. This can exacerbate the problem, with the original retransmissions and then with the transmission of management and raster image processor (RIP) packets to re-discover what appears to be disconnected routers and nodes. These problems can flood WAN links, making them temporarily inoperable.

Inter-Exchange Vs Intra-Exchange Carriers

Some WANs span a state, others span the globe. Inter-exchange carriers can connect sites outside of their geographic range; intra-exchange carriers usually cannot, but they usually offer a low cost solution for WANs within their range. Often, the most cost-effective solution is to combine inter- and intra-exchange carriers although this can complicate troubleshooting and management. The next section reviews some potential design solutions for the Shinozaki WAN.

Review of Connectivity Needs

Shinozaki sites belong to three categories: retail offices, headquarters, and regional warehouses. All sites need connectivity during business hours for messaging, database, and Internet access (not yet considered). Messaging and database needs require WAN connectivity. At Shinozaki, calculations of basic remote management services showed that each retail office needed a WAN connection averaging 96 Kbps.

Regional warehouses need messaging and database access to headquarters, but they have generally larger data access requirements with 350 persons per site. The baseline calculation for each of these sites is about 2300 Kbps.

(Details on establishing baselines are in the Microsoft Windows NT Enterprise course.)

Connectivity of the Retail Office Locations

For the 750 retail office locations, frame relay is probably the most efficient connectivity method. This decision is based on analyzing the expected cost of dedicated lines in various topologies, then calculating equipment and maintenance costs. Further, the frame relay should be one of two topologies.

Figure 7.8: Shinozaki regional warehouse configuration.

• Use PVCs to connect the retail offices to their respective regional warehouse, and either larger PVCs or a high-speed backbone (ATM or SONET) to connect warehouses to headquarters. Transmissions from the retail offices to headquarters are routed via the links connecting the warehouses and headquarters.

• Use PVCs to connect each retail office and regional warehouse directly to headquarters. Requests from retail offices to their respective regional warehouses would be routed through headquarters. Because requests destined to the warehouses do not require higher levels of connectivity, this may significantly improve costs and performance for a company as large as Shinozaki by lowering the requirements on certain WAN links.

Here is what the second topology looks like:

Figure 7.9: Shinozaki retail office configuration.

The first topology segments the corporate network into more connectivity points than does the second, making it easier to provide higher levels of redundancy. Redundancy can be engineered into either topology, of course, by using multiple PVC connections for each office, dial-on-demand backup links, etc.

Case Study Design

After weighing volume pricing and service options, Shinozaki decided to use the topology shown above—a frame relay inter-exchange carrier. Each retail office connects via 96 Kbps CIR PVCs with a 128 Kbps port to the headquarters site. The regional warehouse locations each connect directly with headquarters. ATM or T3 links will support the high traffic volumes generated by retail offices routing through headquarters.

Dynamic Host Configuration Protocol

The second part of this chapter discusses implementation details regarding specific Microsoft network services such as WINS, DHCP, and Windows NT domains.

Administrators have to assign and maintain IP address information and help users who are unable to configure their own computers for internetworking. DHCP was established to relieve this burden by providing reliable, simple TCP/IP network configuration, preventing address conflicts, and helping to conserve the use of IP addresses by centralizing address allocation management. DHCP dynamically configures computer IP addresses; the system administrator controls IP address use by assigning lease durations that specify how long a computer can hold an assigned IP address before having to renew the lease with the DHCP server.

The DHCP client and server services for Windows NT are implementations of Request for Comments (RFCs) 1533, 1534, 1541, and 1542. The DHCP process has four primary stages: discovery, offer, request, and acknowledgment. (Renewal is a repeat of the last two stages.)

Network Design Issues

Access

The first major design issue is to make sure client workstations can access the DHCP server. Workstations broadcast an IP datagram to discover the DHCP server, and this requires that they be on the same segment, because most IP routed environments do not forward broadcast messages across router links. To avoid this, the DHCP server must either be directly connected to the workstation's segment (multi-homed device) or the intervening router must support the DHCP Relay Agent protocol (RFC 1542).

Security

While DHCP eases some TCP/IP administrative effort, it does expose the network to a denial-of-service threat (which is non-destructive). A misconfigured or maliciously configured DHCP (rogue) server can issue incorrect configuration information to DHCP clients, causing them to lose IP connectivity. A misconfigured host cannot contact a default router, causing clients to receive host unreachable messages. You can find out if this is happening by executing "IPCONFIG /ALL" from the command line. If the IP configuration information is incorrect, disable the rogue server, then issue an "IPCONFIG /RELEASE" and "IPCONFIG /RENEW" command to obtain correct information. In a widely distributed network, it may then take several replication cycles to flush all of the "bad" address information from the WINS system.

You can also provide authentication of the source and contents of DHCP messages. For example, clients may be subject to denial of service attacks through the use of bogus DHCP servers, or may simply be misconfigured due to unintentionally instantiated DHCP servers. Some administrators constrain the allocation of addresses to authorized hosts to avoid denial of service attacks in "hostile" environments where the network medium is not physically secured, such as wireless networks or college residence halls. (For more information, see "Authentication for DHCP Messages," 11/22/1996, https://ds.internic.net/internet-drafts/draft-ietf-dhc-authentication-03.txt.)

One Segment, One Subnet

This configuration has a single network segment with a single defined IP subnet. The DHCP server and client are both on the segment.

Two Segments, Two Subnets (Routed), Internal Router

This configuration uses a multi-homed Windows NT Server (connected to more than one segment) and an external router that connects the local segments to the WAN. The server must be configured with the DHCP relay agent. This is because the DHCP server process binds to one adapter only, so the relay agent is used to forward the request internally to the other adapter. This permits the DHCP server to service DHCP broadcast requests without using resources on the main router. Windows NT Server 4.0 provides an internal DHCP relay agent.

Two Segments, Two Subnets (Routed), External Router: (DHCP RELAY)

This configures the router as a DHCP relay agent. A relay agent conforms to RFC 1542 and relays DHCP packets to the remote side even though they are broadcast packets. Before relaying a DHCP message from a DHCP client, the agent examines the gateway IP address (GIADDR) field. If the field has an IP address of 0.0.0.0, the agent fills it with the router's IP address. All communications between the relay agent and the DHCP server are directed User Datagram Protocol (UDP)-datagrams; the communications between the DHCP client and its DHCP relay agent are IP broadcast datagrams.

When the DHCP server receives the message, it examines the Relay IP address field to see if it has a DHCP scope (a pool of IP address) that can be used to supply an IP address lease. If the DHCP server has multiple scopes, the address in the Relay IP address field identifies the correct scope from which to offer an IP address lease. This process allows one DHCP server to manage different scopes for subnets.

When the DHCP server receives the DHCPDISCOVER message, it sends a DHCPOFFER directly to the relay agent identified in the GIADDR field, and the agent relays the message to the DHCP client. The client's IP address is still unknown, thus it has to be a broadcast on the local subnet. Similarly, a DHCPREQUEST message is relayed from client to server and a DHCP message is relayed from server to client, according to RFC 1542.

If you use the Cisco Systems BOOTP relay's "IPHELPER Address" to forward both BOOTP and DHCP requests, you must include the "No IP Forward UDP Port 137" and "No IP Forward UDP Port 138" commands in the interface configuration.

Multiple Subnets per Segment

When multiple subnets are cast on a single segment, the DHCP server cannot dynamically assign IP addresses to multiple subnets.

The most common situation in which multiple subnets per segment are employed is when a router link connects a bridged or switched series of segments to a routed network. Now the downstream bridged or switched segments represent a single logical segment at the subnet level and must exceed the maximum available host count on a given subnet. You should subnet a physical segment space rather than casting multiple subnets on it. If you cannot avoid this, then you can implement DHCP by using supernetting, a proposed extension of the DHCP protocol that allows you to bind multiple address scopes to a single receiving interface or relay agent GIADDR, then chooses an address randomly from the available scopes.

DNS Compatibility

The second major DHCP issue is architectural conflict with the Domain Name System (DNS). DNS employs a statically defined resource table that associates IP addresses with host names. In a DHCP environment where IP addresses are pooled and randomly assigned to any host on a given subnet, the DNS rapidly diverges from the actual IP-name relationship. You can fix this by either permanently assigning IP addresses to hosts in the DHCP server configuration or by devising a method by which the host-to-IP-address relationship can be dynamically learned. One of the proposals for Dynamic DNS links the DHCP server with the DNS database. Now, instead of each workstation registering itself with a name resolver such as WINS, the DHCP server registers the device when the IP address is issued. (For more information, see https://ds.internic.net/internet-drafts/draft-ietf-dhc-dhcp-dns-02.txt).

Q and A: Operational Implementation

Do I have to use DHCP?

No. DHCP merely eases many of the administrative burdens involved with TCP/IP-based networks.

How many DHCP servers do I need?

This depends on the number of arriving requests, the rate at which the server can process them, and the available network bandwidth between the clients and the server. If you configure fewer, centrally managed servers, you reduce server resource consumption but increase network bandwidth consumption. The DHCP server can process 600 lease requests per minute.

Where should I put them?

Placing DHCP servers in branch offices reduces the WAN bandwidth utilization, but each DHCP server consumes a baseline amount of server resources. The number and placement of DHCP servers is entirely based upon the individual environmental constraints. If you have plenty of WAN bandwidth, then you can configure fewer servers and maintain and control then centrally; if you are short on WAN bandwidth, you can distribute servers to the field, but be prepared for additional administrative burdens. The balance must be found case-by-case.

Lease Management

[This is excerpted from the Microsoft Windows NT Resource Kit]

To define appropriate values for lease duration, you should consider the frequency of these events for your network:

• Change to DHCP options and default values

• Network interface failures

• Computer removals for any purpose

• Subnet changes by users because of office moves, laptop computers docked at different workstations, and so on

These types of events cause IP addresses to be released by the client or cause leases to expire at the DHCP server. In either case, the IP addresses are returned to the free address pool to be reused.

Another important factor is the ratio between connected computers and available IP addresses. For example, the demand for reusing addresses is low in a network where 40 computers share a class C address (with 254 available addresses), so a long lease time, such as two months, is appropriate. But if 230 computers share the same address pool, demand for available addresses is much greater, so a lease time of a few days works better. Short lease duration requires that the DHCP server be available when the client seeks to renew the lease. Backup servers are especially important when using short durations.

Although infinite leases are allowed, use them cautiously. Even a relatively stable environment has a certain amount of turnover among clients: portable computers are added and removed, desktop computers are moved from one office to another, and network cards are replaced. If a client with an infinite lease is removed from the network, and the DHCP server is not notified, that IP address can't be reused. A long lease duration, such as six months, is better, because it ensures that addresses are ultimately recovered.

DHCP conversation summary.

Src Addr	Dst Addr	Protocol	Description	Src IP Addr	Dst IP Addr
DHCP-C	*BROADCAST	DHCP	Discover (xid=5DBE14EA)	0.0.0.0	IP Broadcast
DHCP-S	*BROADCAST	DHCP	Offer (xid=5DBE14EA)	DHCP-S	IP Broadcast
DHCP-C	*BROADCAST	DHCP	Request (xid=1EFC37B4)	0.0.0.0	IP Broadcast
DHCP-S	*BROADCAST	DHCP	ACK (xid=1EFC37B4)	DHCP-S	IP Broadcast

Case Study DHCP Design

Shinozaki saw that DHCP traffic generated over the WAN links for client address leases would be relatively small in comparison to the WAN utilization of Internet and database services. After comparing the WAN costs for centralized DHCP services and the administrative costs of managing DHCP on local servers in each location, they decided on a centralized infrastructure design.

In a centralized DHCP approach clients cannot acquire/renew IP addresses when either the DHCP server or the WAN links between the remote LAN and the centralized DHCP servers are unavailable. Shinozaki reduced this risk by making sure that lease durations did not exceed potential DHCP server or WAN link downtime. Centralized servers at headquarters provide addresses for requesting clients at retail offices, regional warehouses, and headquarters.

Windows Internet Name Service

WINS registers NetBIOS names, challenges those names for uniqueness, replies to names queries, and replicates the names database between WINS servers. NetBIOS naming provides a user-friendly method for identifying network resources—users are much better at remembering server names than they are at remembering IP addresses. A names resolver (NBNS) resolves NetBIOS names to the underlying transport protocol (TCP/IP, IPX, etc.) and an address resolution protocol resolves the transport protocol to the media access control (MAC) address.

Figure 7.10: Windows Internet Naming Service (WINS) process.

NetBIOS over TCP/IP and NetBIOS Names Service (NBNS)

Windows NT networking is based on a NetBIOS programming interface encapsulated in the TCP/IP, IPX/SPX, or 802.2 LLC (NetBEUI) packets. The NBNS provides name registration and resolution. Registration establishes a unique name for each network node; resolution resolves a TCP/IP address for a NetBIOS name. Hosts register a NetBIOS name with the NBNS either on startup or by subsequent broadcast message to the NetBIOS name cache on each LAN machine. RFCs 1001 and 1002 describe how NetBIOS over TCP/IP (NBT) is implemented.

Name types registered by hosts.

Name Type	Description
Unique	Single entry pair with a name and address.
Group	Addresses a group of machines on a subnet via the broadcast address.
Internet Group	Registers 25 name/address pairs under a single group name (for example, domain name): the PDC address, the most recently locally learned 24 name pairs, then any entries replicated from other WINS servers. This is significant in WINS network design issues, because you can configure this list to optimize domain controller communications within a domain..
Multi-homed	Registers 25 addresses under a single name. The receiving client matches first on the subnet, then the network, then chooses randomly from the returned addresses.

A Windows NT computer can use one or more of the following methods to resolve host names in TCP/IP networks.

Windows Internet Name Service

Windows NT computers can use WINS if one or more WINS servers are available that contain a dynamic database mapping computer names to IP addresses and if the NBT names resolver is WINS-enabled. WINS servers provide point-to-point name resolution services that can overcome subnet broadcast limitations and avoid global broadcasts.

Broadcast Name Resolution

Windows NT computers can also use IP-level broadcasts for name resolution services on the network, which is a mode of operation (NetBIOS over TCP/IP) defined in RFC 1001/1002 as b-node. Each computer in the broadcast area has to challenge attempts to register a duplicate name and respond to name queries for its registered name.

WINS Proxy

In a mixed environment of WINS and non-WINS enabled devices, a WINS proxy agent can relay broadcast name registration/resolution requests to a WINS server. WINS proxies do not save WINS registration information, nor do they participate in PUSH/PULL replication. They can, however, cache data that results from proxy activity.

DNS Name Resolution

DNS provides a way to look up name mappings when connecting a computer to foreign hosts using NetBIOS over TCP/IP or Windows Sockets applications such as File Transfer Protocol (FTP). DNS is a distributed database designed to relieve the traffic problems that arose with the exploding growth of the Internet in the early 1980s.

The NBT node defines the order in which names services are utilized. These are:

• b-node, which uses broadcasts to resolve names.

• p-node, which uses point-to-point communications with a name server to resolve names in this sequence: NetBIOS Name Cache, WINS, LMHOSTS, HOSTS, DNS.

• m-node, which uses b-node first, then (if the broadcast fails) p-node, in this sequence: NetBIOS Name Cache, broadcast, WINS, LMHOSTS, HOSTS, DNS.

• h-node (default), which uses p-node first for name queries, and then b-node if the name service is unavailable or if the name is not registered in the WINS database, in this sequence: NetBIOS Name Cache, WINS, broadcast, LMHOSTS, HOSTS, DNS.

WINS Implementation

Performance

In one minute, a WINS server can typically service 1500 name registrations and about 4500 queries. This is no built-in limit to the number of records that a WINS server can replicate or store. Using these numbers, and planning for large-scale problems (such as a power outage) where many computers will come back on line simultaneously, the conservative recommendation is to include one WINS server and a backup for every 10,000 computers on the network.

Performance studies for registrations and queries show that 10,000 totally random name registrations on a table with two indices takes about 70 secs (7 msec/registration) and totally random name queries take up around 20 msec (2 msec/query). Also, it takes from 2 - 4 seconds to scan the entire database sequentially using an index. The performance of the database engine should continue to improve as buffer cache management and other aspects of the JET engine are refined. Logging can be expected to slow the registration by another 10%.

Two factors can particularly enhance WINS server performance: using two processors on the computer and using NT File System (NTFS) as the file system.

After you establish WINS servers in the network, you can adjust the renewal interval (in the WINS Server Configuration dialog box). Setting it to reduce the number of registrations can boost server response time.

Network Design Issues

In previous versions of WINS, it was not recommended to run a WINS server on a multi-homed machine. This is now recommended provided that:

• Windows NT Server 3.51 with SP4 or greater is installed.

• All attached subnets are not on disjoint networks. Clients must be able to use any of the IP addresses from WINS. MS-DOS Transmission Control Protocol (TCP) clients use only the first address in a list.

• WINS replication initiates replication using the Windows Sockets (Winsock) interface. A replication session can occur on any of the interfaces depending on IP routing. For this reason you need to define each interface as a replication partner.

The Internet Group Lists have a 25-entry limit. When there are more than 25 backup domain controllers (BDCs), a workstation can discover and set up its initial secure channel with a non-local domain controller (that is, across the WAN). This happens if the local domain controller is no longer on the current top 24 Internet group list and the BDC is on a different local subnet than the requesting workstation.

Replication Design

Simple

Figure 7.11: "Simple" replication design.

The simple configuration has two WINS servers, each serving half the workstation population for primary and secondary WINS addressing. This provides fault tolerance and load sharing WINS service for 5,000 well connected workstations.

Mesh

Figure 7.12: Mesh replication design.

In a fully meshed model, each WINS server replicates directly with every other WINS server, so every server contains a complete copy of the WINS database. Thus a single WINS server failure does not prevent other servers from replicating. This works well for a small number of WINS servers (fewer than 7), but as servers increase it becomes difficult to maintain the large number of replication paths. The more replication partners there are, the harder it is to troubleshoot in the event of a failure.

Hub

Figure 7.13: Hub replication design.

A hub-based model minimizes the number of hops needed to replicate data to each server. This creates less WAN traffic than the full mesh, but it provides a single failure point for replications and introduces a hop to the replication system that increases the time required to come to convergence.

Hub with Redundancy

Figure 7.14: Hub with redundancy replication design.

The simple hub's weakness is overcome by the hub with redundancy design, which adds a second central hub that provides a primary and backup replication path for each local WINS server. You can set the replication pull time on the primary paths to a shorter time interval than is used on the backup path.

Multi-tiered

Figure 7.15: Multi-tiered replication design.

A multi-tiered design uses a central WINS hub to provide replication to regional WINS hubs, which can fan out to local site WINS servers if needed.

DNS Non-replicating WINS

Figure 7.16: DNS non-replicating WINS design for massive environments.

This design is intended to support massive environments (>100,000). The local WINS server replicates only with the regional WINS servers and there is no inter-regional replication. All workstations are pointed to the lowest level WINS server as their primary and to the regional WINS server as their secondary. This model assumes little or no inter-field office connectivity, so any inter-field office traffic must pass through the regional centers. Workstations must be DNS-enabled to make cross-region names queries.

The Data Center tier WINS servers can be replaced with DNS servers by implementing DNS sub-domains. Multiple DNS hierarchies can be constructed for extremely large international corporations. Regionalizing the WINS system reduces the resource requirements on the overall WINS environment (database size, replication traffic, etc.) by segmenting the WINS namespace.

The DNS segmentation must be coordinated with the Windows NT domain structure, because WINS servers do not replicate data across regional lines. This means the domain Internet Group Name would contain and return only entries that exist within a regional WINS database. If the domain crossed regional lines, each region would contain only a partial list of domain controllers for the split domain.

Administration

Members of the Account Operators group and the Server Operators can view the WINS database and add or delete static mappings, but only members of the Administrators Local group can configure the server. To prevent affecting WINS server performance, other users cannot browse the database.

WINS replication is independent of the Windows NT Security Model. Replication partners do not need to be in the same domain or a trusted domain. The ability to replicate with a partner is determined by the replication partner setting. If the replicate only with partner option is set (default), the partner server must have a predefined IP address. A decentralized WINS management allows problems to fall through the cracks.

In contrast, a DNS environment is usually managed in a distributed fashion where each organizational unit manages its own delegated zone. WINS is a flat namespace, so central coordination is essential.

The database backs up to the local backup directory every 24 hours. Normal file system backups cannot copy the WINS database while the WINS service is active. The backup copy must be on a local drive. Administrators have to log on to the local WINS server to initiate backup from the WINSADMN tools menu.

Q&A: WINS

How many servers do I need?

Each WINS server can effectively serve 10,000 clients with low demands on both network bandwidth and server resources. Every WINS environment (even with fewer than 10,000 clients) should have at least two WINS servers—a primary and a secondary (as backup).

Case Study WINS Design

After studying all these details and relationships, Shinozaki decided to implement a centralized WINS server solution with a primary and a backup WINS server at headquarters. The WAN topology means that clients and servers will lose connectivity to resources in both the regional warehouses and the headquarters if the WAN link becomes unavailable, and this means no name resolution. Choosing m-node, however, both reduces connectivity issues locally during link failure and prevents name resolution over the WAN link (via WINS) for local resources.

Browser Service

The browsing facility collects, views, and distributes a list of all available domains and servers. The server process running on workstations and servers releases a subnet broadcast message (for example, announce packet) received by each subnet's master browser (MB). The MBs report their browse lists to the Domain Master Browser on the domain's PDC, which consolidates all the MB lists and returns new items to each MB. Thus each MB maintains a complete browse list for its network and domain. Since the browser system provides only a list of server names, a name-to-address resolution system is still required.

The browser is designed to speed query resolution and to provide a cache from which to fill the list boxes from network browsing utilities such as Server Manager. Without the browsing system, computers can still be accessed by manually entering a computer name in the drop-down list box of most utilities. The name-to-IP address resolution is then handled in the normal manner (WINS, etc.).

Viewing available network resources is known as browsing. When a user selects "Connect Network Drive" from File Manager, the File Manager code requests a list of available network resources from an available browser server. Any computer running the browser service (Windows NT, Windows for Workgroups, etc.) can be a browser server. A non-browser server periodically announces itself to the MB, with a directed mailslot write to <DOMAIN><1D>. Initially, each non-browser announces itself every minute; as the server runs, the announcement time extends to 12 minutes.

There are five defined types of browser servers.

Potential Browser Server

These represent the vast majority of browser servers. They can be promoted to either backup browser (by the local MB) or master browser status, but by default they remain dormant in the domain.

Backup Browser

Backup browser servers maintain a list of servers retrieved from the MB server, calling the MB every 12 minutes to get the latest browse and domain lists and forcing an election if they cannot find the MB. They cache these lists and return the list of servers to any clients that send them a remote NetServerEnum application programming interface (API) call.

Local Master Browser

Local master browsers (LMBs) receive server announcements from Windows NT Workstation and Server, Windows for Workgroups, and LAN Manager servers. They also return lists of local subnet backup browsers to clients. When a computer with its MaintainServerList parameter set to Auto starts, the LMB tells it whether to become a backup browser.

When a browser server is elected to LMB status and its browse list is empty, it can force all servers to register with it by broadcasting an AnnouncementRequest packet. All computers with a server component that receive this packet must answer within a 30-second period that is randomized to prevent flooding the LMB (losing replies) and the network.

LMBs must announce their domain, which they do by broadcasting a WkGroupAnnouncement request to <01><02>_MSBROWSE_<02><01>. This announcement contains the domain name and the name of the domain MB.

Preferred Master Browser Server (PMB)

Any browser server can be configured as a preferred master browser (PMB) server. PMBs function as normal backup MBs, but they force a browser election when the browser is started. If conditions are equal, PMBs are given an advantage in elections. This allows administrators to configure several computers as DMBs and to pick a set of computers that can be DMBs.

Domain Master Browser (DMB)

The browser service running on the PDC in a Windows NT Server domain has a special role—domain master browser (DMB). All DMBs register a unique browser name of <DOMAIN><1B> with the WINS server, which uses the name to build a table of all WAN domains. DMBs periodically query the WINS server for a list of the members of <DOMAIN><1B>, using a two-part process: an API call asking for the domain controller on each <DOMAIN><1B> name, followed by an attempt on <DOMAIN><1C>. The returned list contains both the domain names and the associated DMB names.

Each DMB merges this list into its local domain browse list, which it then propagates to the LMBs on each subnet via the normal replication mechanism. If the DMB did not collect, consolidate, and re-distribute browsing information across subnet boundaries, LMBs would contain only the information that they have directly learned from their subnet.

The LMB for each subnet announces itself to the PDC using a directed datagram that identifies the LMB by name. The PDC sends it a NetServerEnum API to collect its subnet list of servers.

Browser Implementation

Network Design Issues

The highest ranked potential browser server, as determined by election, serves as the segment's LMB. The DMB on the PDC coordinates the browse lists of the LMBs on each subnet. The LMBs update the backup master browsers (BMBs) on their local subnets. On TCP/IP-based networks, the browsing facility determines the list of devices on a local subnet by using a subnet broadcast datagram requesting a local announcement. If subnet broadcasts on UDP port 138 are forwarded to a remote device (any device not on the local subnet), then that device is included in the list of local subnet devices. If the remote device has a higher browser value than any local device (for example, it's the PDC), then it attempts to become the MB for the local segment even though it does not actually exist on the local segment.

You can detect this situation by looking for excessively long browsing query times and incomplete or incorrect browsing lists. Standard diagnostic tests for improperly sealed subnet boundaries are:

• Check the actual router configuration files for UDP forwarding (or flooding) of subnet broadcasts on UDP ports 137 and 138.

  Cisco systems' routers forward to these ports by default when the DHCP relay agent configuration ip helper address option is used. To disable this feature, use the no ip forward UDP port 137 and no ip forward UDP port 138 interface commands on every interface on which the ip helper command is also applied.

• If you don't know the router configuration or the protocol implementation, you can determine the UDP forwarding state with a protocol trace. Use Network monitor on the workstation, filter a capture for BROWSER protocol packets, and check for MasterAnnounce or GetBackupServer responses (which are subnet broadcast packets) originating from the PDC (which is not on the local subnet).

Multi-homed Servers

The browser system can be multi-homed as long as the PDC is not multi-homed and parallel to other domain controllers. The PDC has a hard coded preference to win the browser election. If you put the PDC in the position occupied by a BDC, it attempts to be the LMB on every segment and the DMB for the environment. You can use a NetMon trace to see if this is happening: every time a workstation needs the browse list, the trace will show three unanswered requests for the GetBackupServer list, followed by an election request.

Browser Implementation Recommendations

• Reduce the number of potential browser servers on any given subnet by setting the MaintainServerList value to No. Make sure that devices configured for browser operations are generally available (application servers, etc.).

• Reduce the number of protocols on each workstation. A browser name is registered for each protocol.

• Reduce the number of browser entries by hiding the server service on workstations. Issue the net config server /hidden: YES command from a command prompt. The server will stay hidden until the command is re-issued and set to NO.

Domain Name Service

Domain Name Service (DNS) and Berkeley Internet Naming Daemon (BIND) are the standard name-to IP-address resolution methods used on the Internet. DNS provides a naming hierarchy based on the concepts of Scope-of-Authority (SOA), zones, domains, and delegation.

Each node in this hierarchy has a DNS that is authoritative for its zone. This primary DNS is known as a primary master. A zone contains all devices that are directly defined under that DNS server's SOA. All zones under a node constitute its domain. For example, on the Internet, Microsoft is a member of the com domain.

Delegation of authority allows nodes below a particular node be authoritative for their zone. The "Microsoft" DNS is authoritative for all nodes below it. The "Microsoft" domain administrator registers its name and addresses with the administrator of the "com" domain. The administrator of the ".com" DNS places a pointer to the "Microsoft" domain in its database and the administrator of the "Microsoft" domain places a pointing record to the ".com" domain in its database.

When someone in "microsoft.com" requests service from a device in "ds.internic.net" (for example, FTP an RFC), they send a DNS query to their defined DNS server, which makes a query on behalf of the requesting workstation to the "com" DNS which refers the local DNS to the address of the "root." The local DNS server then queries "root," which refers to the address of "net" and so on. In practice, the resolution process is more direct since many of these addresses are cached.

There are two types of queries:

• The called DNS server returns a reference to another DNS ("I don't know, but I know someone who does").

• The called DNS server makes the referral query on behalf on the calling DNS ("I don't know, but I'll forward your query to someone who does")

The DNS database is basically two flat files, one containing the names-to-address records and the other containing address-to-name records. (There are also some other records such as mail records, alias records, DNS pointers, etc). The DNS administrator creates and maintains these files. For more information on the theory and usage of DNS, see the white paper onhttps://www.microsoft.com called "DNS and Microsoft Windows NT4.0" by Scott B. Suhy and Glen Wood.

The DNS system defines domains and subdomains of host namespace. The master name server is authoritative for the domain. Primary name servers originate source data for the global name service via boot and database files. Secondary name servers obtain copies of the zone information by a file copying process called a zone transfer. Name servers can also obtain data from cache entries that are learned from responses to queries forwarded to other name servers.

The DNS system's primary records are explained below.

Name Server (NS)

• List of other DNS servers to which queries should be delegated, including name servers that exist both above and below the current DNS tree node (parents and children).

  <domain> IN NS <nameserver>
  Example: @ IN NS nameserver1.microsoft.com

• Mail Exchange (MX):

  Pointer to the mail server.
  <domain> IN MX <preference><mailserver host>
  Example: @ IN MX 1 mailserver1

• Host

  Standard name to address record.
  <host> IN A <ip address>
  Example: rhino IN A 157.55.200.43

• Canonical Name or Alias (CNAME):

  The CNAME allows the DNS administrator to alias a hostname.
  <host name> IN CNAME <host name>
  Example: ftp CNAME fileserver2

• Pointer Record (PTR)

  Static map of IP addresses to host name within the reverse lookup file.
  <address in reverse order>in-addr.arpa IN PTR <host name>
  e.g. 51.200.55.157.in-addr.arpa IN PTR mailserver1.microsoft.com

1. WINS:

   Static map to a WINS server to which WINS NetBIOS names queries should be delegated.
   <domain> IN WINS <IP address of WINS server>
   Example: @ IN WINS 157.55.200.81

2. WINS Reverse lookup (WINS-R):

   Static map to a WINS server for reverse address to name resolution.
   <domain> IN WINS-R <domain to append to returned NetNBIOS Name>
   Example: @ IN WINS-R microsoft.com

Integration of the DNS and WINS

The DNS can be configured with a special $WINS directive that instructs it to pass through WINS server queries for names that can't be found in the DNS database. The algorithm for passing through queries is:

DNS attempts to resolve the name to an IP address using standard DNS records.

If that fails, the domain suffix is stripped off, and a NetBIOS name is formed by space padding the hostname and appending 0x00 as the 16th character. The WINS server configured for the host running the DNS software is then sent a standard NetBIOS name query for that name.

The WINS server returns a Name Query Response, and if it was successful the DNS returns a standard DNS response to the original client using the information obtained from WINS.

Here is an example:

1. Host "A" sends a DNS query for beetle.microsoft.com to the DNS. The DNS checks its records and finds no match.

2. The DNS sends a NetBIOS Name Query to its WINS server for "BEETLE<00>" (BEETLE followed by 9 spaces and hex 00).

3. The WINS server locates the (dynamically registered) IP address for BEETLE and returns it to the DNS in a NetBIOS Name Query Response.

4. The DNS returns the resource record to Host "A" as a DNS response.

The WINS name service is dynamic, which allows it to extend the DNS and provide relief from some of the manual labor normally associated with DNS administration.

Q&A: Name Service

Why use WINS when DNS is available?

First, when DHCP is used, the relationship between the host name and the underlying IP address can change at any time. Second, the Microsoft networking facility currently registers more than just host names for resource location in the name server: user names (used by the messenger service), domain names (which are mapped to a group ID containing all of the DCs). WINS is the recommended NetBIOS Name Service.

Domain Architecture Planning

Domain architecture planning is more than simply choosing a domain structure—it is defining a framework in which to implement complex distributed computing. It involves balancing distributed data storage and bandwidth, control and flexibility, and security and openness. Some basic information must be available to various systems (network addresses, names, user IDs, etc.) so the designer must decide whether the information should be consolidated, which increases remote bandwidth requirements, or distributed, which increases remote resource utilization and administration of data replication. The primary factors influencing the domain design are:

• Business model (user activity profile and network administration)

• processing load

• Processing capacity

Domain Processing Overview

People often get tied up in the Windows NT domain planning and excessively complicate the process. The Windows NT domain system is merely a distributed transactional database that happens to store and distribute security information. It performs two basic functions: distributed transactional authentication, and single-master database replication. This database (like every distributed database) has several engineering parameters:

• CPU: Cryptographic algorithms are numerically intensive

• CPU: Compression algorithms are numerically intensive

• Storage requirements: How much disk space?

• Memory Requirements: How big is the working set?

• Transaction load: authentication/sec, database updates

• Replication: How much data to how many systems?

Authentication Modeling

If everyone in a 20,000-user "enterprise" logs on in a 30 minute period, and the requests are fairly evenly distributed, the network load generated is approximately 11 logons/sec, 220 Kb/sec. (no profiles, single-master domain). Network I/O determines the latency of the challenge-response process, packet acknowledgments, and SID return sets, and network latency affects not only the arrival rate but the holding time as well.

SAM Replication Modeling

The Windows NT domain system is a replicated single-master database (single master in database terms, one authoritative source with one or more read-only replicas). The resource load generated by domain replication is characterized by:

• Single-master database hierarchy

• Non-partitioned database—full replicas in each system

• Both full and record-wise partial replication

• Configurable number of simultaneous replication processes

• Configurable available bandwidth throttling

• Max additions during original system load

• Max changes on Mondays (or after holiday weekend)

SAM replication is driven by two factors. The frequency of periodic data refresh (which is controlled by the configured user account expiration interval and the 7-day machine account expiration interval) and administrative actions (such as user/machine account additions/subtractions/modifications, and manually ordered replications).

Basic capacity modeling requires determining the size of the full SAM (plus an engineering "pad"), then calculating the time required to complete full replication to all BDCs with varying available bandwidth and varying concurrent replication partners. If the replication can be completed in the administrative window available for SAM replication, then the normal partial replication should occur without difficulty.

For example, if you have calculated (or measured) a 20-MB SAM and you assume 56 Kbps to 200 field offices taken 10 at a time:

((20,000 KB x 1.2 (overhead) x 8 bits/byte)/56 Kbps)/60 sec/min = 57 min or ~1 hr/10 offices ~ 20 hours

Physical transmission requirements for a 20 MB file replication.

SAM Size	Link Speed	Offices	Concurrent	Time
20 MB	56 Kb	200	10	20 hrs
20 MB	128 Kb	200	10	8.3 hrs
20 MB	56 Kb	200	20	10 hrs
20 MB	128 Kb	200	20	4.2 hrs

This displays the physical transmission requirements for any 20-MB full file replication. The time column indicates that you should avoid domain replication during the heaviest transaction period, and schedule it around the heaviest loading periods for authentication and business traffic.

Startup Traffic

Both workstation and servers generate startup traffic. This basic process can be viewed by focussing on workstation startup traffic, assuming that servers tend to remain on and that there are significantly fewer servers than workstations. When a workstation first starts up, it must initiate a series of actions to join the network community. If the network uses DHCP, the workstation must obtain or confirm an IP lease from a DHCP server. Then it must register its NetBIOS names with the network (each share and service requires a NetBIOS name registration). Once the workstation is registered with the network, it begins a NetLogon sequence that enables the user to register with a domain server.

The startup process involves two separate logons, one between the workstation and its resource domain controller, and the other between the user and the authentication domain (in a single domain the resource and the authentication domains are the same). When the workstation's NetLogon process starts, it discovers the domain controller, establishes the secure channel, and performs a NULL user logon (~12KB). When the user performs an interactive logon (Ctrl-ALT-DEL prompt), the user credentials are passed to the authentication domain along this secure channel (~3KB).

This much of the process generates workstation traffic between 15,000 and 20,000 bytes (depending on certain factors such as number of permanent connections, shares, etc.).

Amount of traffic for service during startup.

Service	Generated Traffic
DHCP	3084 bytes
Name registrations	856 bytes
Browser announcements	2000 bytes
Null user logon (wrkstn)	6637 bytes
User logon	3000 bytes
Permanent drive map	1634 bytes per drive

This number is affected by the number of shares on the workstation, the number of permanent connections (shares) that the workstation must establish, the number of protocols running on the workstation, and whether the workstation participates in browsing. If users are configured to use server-based, non-cached profiles, then additional network resources are required to transfer the profiles at startup. If the workstation runs more than one protocol, more time is required because NetBIOS names need to be registered with each running protocol.

Various combinations of services can be divided between local and remote servers. For example:

Single Domain with no local BDC:

• All startup traffic traverses the WAN.

Single Domain with local BDC:

• All startup traffic is local but complete domain SAM must be replicated to the local BDC. The replication traffic can be minimal with partial replication and low user account volatility.

Master Domain with local resource controller:

• 15 K of the startup traffic remains local, 3 K traverses the WAN. The resource domain replication traffic is minimal if the computer account base is stable.

Planning the Network

Before planning the network, you need to account for the expected business traffic and the peak operating loads, and to keep in mind that the bottleneck is the available capacity of the slowest link in the path. If analysis shows that the maximum throughput of the network for business traffic will be 32 Kb/sec., and the network will be implemented using 56 Kbps lines, then you have about 24 Kbps of bandwidth available during business hours. Of course, at times when the network is not busy (evenings, weekends, holidays), you can use the entire bandwidth for maintenance work. It's a good idea to plan major migrations, updates, and modifications during these off-peak hours.

Case Study Domain Model

Shinozaki designed its domain model with centralized administration. Though user account domain controllers are in the branch offices, most domain controllers are at headquarters, with the exception of one domain controller at each of the regional warehouses. It is a relatively large enterprise but it can still be designed into a single user account domain.

More Information

• Microsoft Windows NT Server 4.0 Enterprise Technologies Training. by Microsoft Press. ISBN 1-57231-710-8.

• Enterprise Networking, by Daniel Minoli. ISBN 0-89006-621-3.

• The Simple Book, by Marshall T. Rose. ISBN 0-13-451659-1.

• DNS and BIND, by Paul Albitz and Cricket Liu. ISBN 1-56592-236-0.

• How to Manage Your Network Using SNMP, by Marshall T. Rose and Keith McCloghrie.

• The Basics Book of Frame Relay, by Motorola Press University. ISBN 0-201-56377-0.

• The Open Book, by Marshall T. Rose. ISBN 0-13-643016-3.

• TCP/IP Explained, by Phillip Miller. ISBN 1-55558-166-8.

• RFC 1001 and RFC 1002: Protocol Standard for a NetBIOS Service on a TCP/UDP Transport.

• RFC 1541: Dynamic Host Configuration Protocol.