Capacity Planning for Your Windows NT Server Network

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.

First Presented at TechEd 1996

On This Page

Session Objectives
Network Capacity Planning Procedure
Characterizing Services
Protocol Differences
Analyzing DHCP Traffic
Analyzing WINS Client Traffic
Analyzing Logon Validation Traffic
Analyzing Browser Traffic
Analyzing File Session Traffic
Analyzing Account Synchronization Traffic
Analyzing Trust Relationship Traffic
Analyzing Directory Replication Traffic
Analyzing WINS Replication Traffic
Optimizing DHCP Traffic
WINS Client to Server
Optimizing File Session Traffic
Optimizing Domain Traffic
Optimizing Browser Traffic
Optimizing Directory Replication Traffic

Session Objectives

Before analyzing the traffic that is present on the network, it is important to ensure that each Windows NT Server computer on the network is functioning optimally. This was accomplished in the first part of this session "Capacity Planning Your Windows NT Server Network".

The second part of the "Capacity Planning Your Windows NT Server Network" session will focus on capacity planning a Windows NT Server network, making sure the network traffic that is generated on the network is essential, and there is enough network bandwidth to accomplish the requirements the network is to provide.

One of the most common goals of network capacity planning is ensuring adequate network bandwidth for user generated traffic for logon validation, file and printer access, and client/server application access.

Network Capacity Planning Procedure

Before attempting to capacity plan the network traffic present on a network, it is important to have a strategy, or procedure, to follow. In part one of this session, a six step process was presented for capacity planning a Windows NT Server computer. This same strategy works for capacity planning network traffic on a Windows NT Server network.

While capacity planning network traffic, it is important to remember the following guidelines:

• Determine the goal of the planning. Is it to reduce overall traffic, or is the goal to reduce traffic during a specific network function, such as directory services database synchronization? Keep in mind the goals and requirements of the business.

• Capture the traffic relevant to the specific network function. It is recommended to first capture on an isolated network, to determine base traffic patterns for the specific network function.

• Analyze the captured data to identify what traffic is relevant to the specific function, and how that function affects the overall network traffic patterns.

• If necessary, optimize the network traffic through specific tools, dependent upon the function.

• Capture and analyze traffic related to the optimized service to determine if the optimization accomplished the desired goal.

• Predict how each of the network functions that generate network traffic will affect the overall network traffic, helping to identify potential problems, such as a WAN link that will not be able to accommodate the predicted traffic.

The remainder of this seminar will focus on these procedures to capacity plan the following network services/functions:

• DHCP

• WINS client to server

• User logon validation

• Browsing

• User file session activity

• Directory services database synchronization

• Trust relationships

• Directory replication

• WINS server to server

Network Monitor

Having a proper tool for capture and analysis is important for capacity planning network traffic. Microsoft's Network Monitor is a software-based network protocol analyzer. It is included as part of Microsoft Systems Management Server, although it can be installed and used separately from Systems Management Server. Network Monitor requires no special hardware, other than a network adapter card that supports being placed into promiscuous mode. There is a list of Network Monitor tested and supported network adapters included in the Release Notes for Systems Management Server version 1.1, as well as on CompuServe, MSN and on Microsoft's World Wide Web server.

Using Network Monitor

The method used to start Network Monitor depends on how it was installed. If it was installed as part of Systems Management Server, use the SMS Network Monitor icon in the Systems Management Server program group. If Network Monitor was installed as a stand alone application, use the Network Monitor icon in the Network Analysis Tools program group.

The Network Monitor Interface

The first windows to appear in Network Monitor is the Capture Window. Normal Windows interface menus and toolbar options are available to control the usage of Network Monitor. The Capture Window is divided into four major areas.

In the upper left is the Graph Pane. It displays the current activity as a set of bar charts indicating the % of Network Utilization, the Frames Per Second, Bytes Per Second, Broadcasts Per Second, and Multicasts Per Second during the capture process. This gives a quick snapshot of the type of activity on the network.

In the middle left is the Session Statistics Pane. It displays the summary of the conversations between two hosts, as well as which host is initiating broadcasts and multicasts.

Across the bottom of the window is the Station Statistics Pane. It displays a summary of the total number of frames initiated by a host, the number of frames and bytes sent and received, as well as the number of broadcast and multicast frames initiated.

Finally, in the upper right corner is the Total Statistics Pane. This area displays statistics for the traffic detected on the network as a whole, the statistics for the frames captured, per second utilization statistics, and network adapter card statistics.

Capturing Data

Capturing data with Network Monitor is an easy process. Selecting Start from the Capture menu will begin the capture process, as will pressing F10, or choosing the Start Capture button on the tool bar (it looks the play button on a CD player). As data is being captured, information will appear in each of the four sections of the Capture Window.

When the desired amount of information has been collected, the collection process can be discontinued by choosing Stop from the Capture menu, as will pressing SHIFT+F10, or choosing the Stop Capture button on the tool bar (it looks the stop button on a CD player).

Saving Data

If the captured data needs to be saved, it can be done by choosing Save As from the File menu. A standard Save Data As dialog box will appear allowing the selection of drive and directory to save the data, as well as the ability to name the captured data file.

Analyzing Data with Network Monitor

To view the data that has been captured, simply choose Display Captured Data from the Capture menu, press F12, or choose the Display Captured Data tool bar button (it looks like a pair of glasses).

When viewing captured data, the Capture window displays a summary of all frames captured. A display filter can be set to filter frames of interest, such as those from a particular host, or using a particular protocol. Colors can be added to highlight specific frames.

The Network Monitor Capture window has three panes. To view all three panes simultaneously, double click any frame.

Summary Pane (Top)

This pane lists all frames that are included in the current view of the captured data. When a frame is highlighted in the Summary pane, Network Monitor displays the frame's contents in the Detail and Hex panes.

You can sort (by clicking the mouse), move, and resize the six columns in the Summary pane. These columns include:

• Frame — All frames captured during one capture session are numbered in order of capture time. The frame number appears in this column.

• Time— This column displays the frame's capture time relative to the beginning of the capture process. Can be configured to display the time elapsed from the previous frame.

• Source Address— Displays the hardware address of the computer that sent the frame.

• Destination Address—Displays the hardware address of the target computer.

• Protocol— The protocol used to transmit the frame.

• Description— A summary of the frame's contents. The summary information can show the first protocol used in that frame, the last protocol used in that frame, or an automatic selection.

• Source Other Address—An additional identifying address for the originator of the frame, other than the MAC address. This might be an IP or IPX address.

• Destination Other Address—Same as above, except for the destination of the frame.

Detail Pane (Middle)

This pane displays protocol information for the frame currently highlighted in the Summary pane. When a frame contains several protocol layers, the Detail pane displays the outermost level first.

When selecting a protocol in the Detail pane, the associated hex strings for the current frame are highlighted (in the same color as that used for the protocol) in the Hex pane. If a protocol has a "+" beside it, more information can be displayed in the Detail pane by clicking on the protocol or by highlighting the protocol and pressing ENTER. When the protocol information is expanded, a line of data appears for each property associated with that frame.

Hex Pane (Bottom)

This pane displays in hexadecimal format the content of the selected frame. When information is highlighted in the Detail pane, the corresponding hexadecimal data appears highlighted in the Hex pane. This is often where analysis may center, especially when attempting to determine the appropriate API call used in a transaction.

Characterizing Services

Before capturing network traffic, you must identify a procedure for capturing and analyzing the data. Characterizing a Windows NT Server service is the process of determining what traffic is generated by a service, and at what intervals. To characterize a service, you will want to follow a few guidelines:

1. Use an isolated network. This allows complete characterization and timing, without other traffic from interfering or skewing the results. The best way to capture network traffic related to a specific network function is to stop all network traffic that is not related to the desired process. This allows for a clean network for analysis of the traffic of interest.

2. Use a network capturing and analysis tool, such as Network Monitor. Use a tool that captures network traffic, and can present it in a form for analysis.

3. Start the capture function, then initiate the network traffic relative to the service to be characterized. For example, if analyzing logon validation traffic, it is easy to force the traffic to occur; simply logoff and logon at a client computer.

4. Stop the capture, and display the traffic when the service has completed its job. Network Monitor allows analysis immediately after the capture, or the data can be saved for later analysis.

5. Identify each frame in the capture, ensuring it is part of the traffic generated by the service, and not from another function.

By performing these steps, a guide of how the service operates can be created. Repeating these steps additional times may be necessary to ensure the validity of the data. Make sure that the service and/or computers are returned to the same state as the initial test to provide for consistent test results.

Protocol Differences

The network traffic a specific function will generate is somewhat dependent upon the protocol used. Some protocols base much of their traffic on broadcasts (NetBEUI), while others use more directed frames (TCP/IP). While this may have an affect on the overall network traffic, it certainly will have an impact on a wide area network, depending upon whether or not broadcasts are being forwarded by the routers in the enterprise.

If the broadcasts are not being forwarded, some functions will operate fine on the local network, but not have complete functionality throughout the entire enterprise.

If the broadcast traffic is being sent throughout the enterprise, complete functionality is available, but at the cost of increased traffic on the WAN.

The majority of Microsoft's corporate accounts either have, or will be, migrating to TCP/IP as their protocol of choice. With this in mind, this session focuses on the traffic generated in a TCP/IP enterprise. While most of the traffic will be similar, there will be differences between the traffic analysis presented here if the network was using NWLink IPX/SPX or NetBEUI as the protocol.

Following is a comparison between four common causes of network traffic using TCP/IP and NWLink IPX/SPX (802.2). These tests were done using two 80486 computers, one 33MHz, the other 66MHz. Each had 16 MB RAM.

Network function	TCP/IP	NWLink IPX/SPX (802.2)
PDC Bootup	88 frames, 12,785 bytes, and 60.5 seconds.	116 frames, 15,962 bytes, and 70.7 seconds.
Windows 95 Client Bootup	66 frames, 9,760 bytes, and 25.2 seconds.	85 frames, 11,377 bytes, and 29.5 seconds.
User Logon Validation	39 frames, 6,538 bytes, and 2.5 seconds	35 frames, 6,586 bytes, and 2.5 seconds.
File Transfer of a 2MB File	2,225 frames, 2,190,944 bytes, and 9.8 seconds.	2,273 frames, 2,226,518 bytes, and 11.6 seconds.

Analyzing DHCP Traffic

In an IP network environment, the first thing a host must do is to initialize TCP/IP. To do so, the host must have a properly configured IP address and subnet mask. These values can be configured manually by a network administrator, or be assigned automatically using DHCP.

DHCP traffic does not provide a significant use of network bandwidth during normal periods of usage. There are two common phases of DHCP that generate network traffic: IP address lease, and IP address renewal.

DHCP Frames

When a new DHCP client initializes, its first step is to acquire an IP address using DHCP. This process results in a conversation between the DHCP client and server consisting of four packets. Each frame is 342 bytes in size (older Microsoft clients used 592 byte DHCP frames).

Packets	Description
DHCP Discover	The first frame is the client computer's broadcast of a DHCP Discover packet in an attempt to locate a DHCP server. The client has no knowledge of any DHCP servers, so it must broadcast in order to find one.
DHCP Offer	Once a DHCP Server has received the Discover packet, and determined that it can accommodate the client's request, it responds with a DHCP Offer message identifying the IP address the client can lease.
DHCP Request	The client computer will select an offer and respond back to the DHCP server with a DHCP Request frame indicating it is accepting the offer.
DHCP ACK	Once a DHCP server has received the client's Request, it responds with a DHCP ACK message, providing the lease life, and any optional TCP/IP parameters.

Note: For more information on IP address lease packets, see Appendix D: DHCP Packets

These four frames take about one-quarter of a second, and about 1,368 bytes of network traffic.

Lease Renewal

Whenever a DHCP client reboots, it must renew its IP address with its DHCP server. When renewing an IP address using DHCP, the conversation is a simple one consisting of the last two packets of the IP address lease phase. The client computer will request a renewal of its current IP address with a DHCP Request packet, and if successful, the DHCP server responds with a DHCP ACK packet.

DHCP clients also renew their IP address lease at one-half of the TTL, which is a configurable length. At this time, the client issues a DHCP Request packet to its DHCP server, and the server will respond with a DHCP ACK, if the address is still valid for the client. The only difference between the DHCP Request and ACK packets for a renewal and those of the acquisition, is that the conversation is directed, and not broadcast, since the client and server already know about each other.

These two frames will total 684 bytes in size, and only take 50 milliseconds to complete.

Analyzing WINS Client Traffic

Once a computer has initialized its IP address, the next thing it would do is register NetBIOS names. This can be done either through b-node broadcasts, or using a NetBIOS Name Server, such as WINS. All NetBIOS over TCP/IP name service functions use UDP Port 137.

Name Registration

NetBIOS names need to be registered for every service or application that supports NetBIOS. Examples include Workstation and Server services, Network Monitor as an application, and special names to indicate roles on the network, such as a primary domain controller or a backup domain controller. The actual number of names depends on the specific network services and applications the client computer initializes. Typically, a client would initialize three or four names. Each name can be up to 15 characters in length, with a 16th character that designates the service or application that owns the name. If the name is fewer than 15 characters, it is space padded through 15 characters.

Each name registered generates a total of 214 bytes of network traffic, and takes generally well under 100 milliseconds to complete.

Name Renewal

When a name is successfully registered with the WINS Server, it responds with a success message which includes a TTL (time to live). The TTL indicates when the client will be required to refresh the name. Refreshing a name registers it again for another TTL period. The TTL determines the amount of traffic that is generated via WINS for name renewals.

The default configuration for the WINS server establishes a renewal interval of 96 hours, so the server assigns a TTL of 345,600 seconds, or four days. As a result, this pattern will be repeated every two days, as WINS clients renew their names every one-half TTL.

Name Resolution

In order to access a resource or service on a computer, it will be necessary to resolve the name into an address. This process is called name resolution. For TCP/IP networks, name resolution converts a computer or host name into an IP address for IP level communications. The process of resolving NetBIOS names into IP addresses is called NetBIOS name resolution. WINS acts as a NetBIOS name server to provide this resolution of registered names into IP addresses.

To resolve a NetBIOS name, the client sends a Name Query Request to the WINS server. This request contains the name to be resolved, as well as a flag indicating it is a query.

If the name queried is registered in the WINS database, the WINS server responds with a Name Query Response frame. It includes a flag to indicate a response to the query, and the IP address of the registered owner of the name.

Name resolution is normally a two frame conversation, requiring almost 200 bytes of traffic. The time to resolve can be as quick as a couple of milliseconds, depending upon network traffic.

If the name is not registered with WINS, the WINS server will respond with a "Requested name does not exit" message. The client will then resort to b-node broadcasts in an attempt to resolve the name, assuming the target host is not a WINS client.

Name Release

Once a name has been registered by a computer, the name is owned by that host until it releases the name. When a host stops a service, or shuts down, it releases the name. Releasing a name makes it available for another computer to register.

The actual release process involves a Release Request being sent to the WINS server (same 110 bytes as a registration), and the WINS server returning a success message of 104 bytes. This message designates the successful release of the name by assigning a TTL of 0.

There will be two messages (one request and one response) for each name that the client computer has registered.

Note: For more information on names registered during WINS Name Registration, see Appendix E: Names Registered During WINS Name Registration.

Analyzing Logon Validation Traffic

One of the first functions a network needs to provide for users is logon validation. This is accomplished by the set of domain controllers for the domain the user is requesting validation.

Finding a Logon Server

The first step in the logon process is finding a domain controller to validate the user account. This is accomplished using one of the following two methods:

• Querying WINS for all registered domain controllers in the domain.

• Broadcasting a request to the mailslot NETLOGON.

This request is broadcast at the physical layer (Ethernet), and a subnet broadcast at the IP level. UDP port 138 (NetBIOS Datagram Service) is used to service the request.

The destination NetBIOS name is the domain name being logged into, with a <00> in the 16th position. For example, if attempting to find a logon server in the domain DOMAIN0, the request would be sent to "DOMAIN0 <00>" with spaces padded through 15 characters, then <00>. This frame will be around 260 bytes, depending upon computer name.

Each logon server registered in the domain running the NetLogon service will respond to the client, indicating it can accommodate the logon request. This is done via a directed reply to the requesting computer name using the mailslot \MAILSLOT\TEMP\NETLOGON.

Included in this frame is the Source IP Address and computer name of the logon server. This frame will be around 230 bytes, again depending upon computer name.

Using WINS

If the client computer is configured as an H-node WINS client , it will send a query to the WINS server for the domain name, appended with a <1C> as the 16th character. This is a standard query to WINS of 92 bytes.

In response to the query, the WINS server returns a frame that includes the IP address of all registered domain controllers in the WINS database for that domain. This frame will vary in size, depending upon the number of domain controllers registered in the domain. For two domain controllers, a response is 116 bytes.

The client would then send a directed message to each server listed in the WINS response asking if it can validate the logon request.

Validating the Logon Request

During the next part of the logon validation process, the client computer takes the first response to its NETLOGON request, and initiates the following traffic between itself and the logon server:

• The client resolves the NetBIOS name of the selected logon server, either by querying WINS, or by broadcast.

• A TCP session is established with the logon server using the TCP three-way handshake process.

• A NetBIOS session is established with the logon server.

• SMB protocol negotiation occurs.

• SMB tree connection to \\logonserver\IPC$ is established.

This process generates 11 frames, and approximately 1,280 bytes of traffic.

At process completion, the client initiates a conversation with the logon server using remote API calls to validate the logon. The first API called is NetWkstaUserLogon, which requests logon validation. The server then responds with a success or failure message. The second API called is NetRemoteTOD, to get the server's time information to determine the time zone offset for proper calculation of file date and time stamping. The server then responds with the correct time as kept at the domain controller. This set of two API calls and responses, totals four frames, and approximately 765 bytes.

After the specific user account has been validated, logon scripts, user profiles, or system policies may be executed. This would result in additional network traffic. For example, a user logging onto the domain from a Windows 95 client computer would generate an additional 35 frames. These 35 frames show the client computer establishing a session with the primary domain controller, connecting to the NETLOGON share, and executing a logon script or system policy. This process will add another few seconds to the logon process of the client, as well as the frames required to perform the transfer.

Finally, the connection to IPC$ would be disconnected, and the NetBIOS and TCP sessions would be terminated. This would take another five frames and approximately 360 bytes of traffic total.

Analyzing Browser Traffic

After a user has successfully logged onto the network, network resource access is generally the next step. To assist users in the process of locating network resources, Microsoft networking implements a network function called the Browser.

Browser Packet Properties

The browsing process is based almost entirely upon broadcast packets, the majority of which are very similar. These properties include:

• Frame sizes are generally between 200 and 300 bytes in size.

• MAC layer broadcasts and IP layer subnet broadcasts using UDP Port 138 (NetBIOS Datagram Service).

Types of Browser Traffic

The browser service generates a lot of traffic on the network. While this may impact the available network bandwidth, the traffic browsing generates makes it easier for users to find network resources and servers. This is accomplished by servers locating the master browser so they can be added to the browse list. Master browsers need to communicate with each other so users can access servers and resources in different domains on the network. Backup browsers need to receive updated browse lists from the master browsers to make sure they have complete lists to offer to clients. Clients need to determine which servers are backup browsers to receive current browse lists. All this generates network traffic.

Host Announcements

A computer that can provide resources on the network will generally announce itself every 12 minutes, though during initialization, the frequency is much higher to ensure the addition into the browse list. This announcement is around 243 bytes in size.

Retrieving a Browse list

After the client has announced itself, the user might desire to connect to a shared resource. In order to do so, the client needs to retrieve a list of available resources. This process involves finding the local master browser to retrieve a list of backup browsers, contacting a backup browser, and then connecting to and retrieving the browse list.

To find the local master browser, the client sends a "Get Backup List Request" to the domain name with a <1D> appended as the 16th character. This request is around 215 bytes in size.

The local master browser responds with a "Get Backup List Response" that lists the available backup browsers. This frame will vary in size. A list of two servers was 234 bytes.

The client then connects to one of the backup browsers in the list, and retrieves the browse list. This entire process took 19 frames and just over 2,150 bytes.

Following is a description of the different types of browser service traffic:

Types of Traffic	Description
Browser Announcements	There are various announcement messages for the browser service. Computers with Server components will announce themselves to the Master Browser for their local domain. This is done with a Host Announcement. The purpose of this announcement is to identify itself as a member of the network that may be providing resources. Once a browser computer has initialized, it must determine who is the master browser for its domain. This is done with an Announcement Request. Announcement Requests are also used to force Host Announcements from browser computers when a new master browser computer initializes. The master browser will respond to a Announcement Request with a Local Master Announcement. This announcement identifies the master browser of the domain. When a master browser has been elected, it must announce itself as the master browser for the domain. This is done using a Workgroup Announcement, which serves to announces the domain. This is how a master browser learns of other master browsers on the local subnet.
Browser Elections	Whenever a master browser cannot be found, the computer that detects the absence of the master browser will force an election to establish a new master browser. When an election is performed, the host that initiated the election sends an Election frame, indicating it is forcing an election, and with its election criteria. All browser computers receive this election frame, and if a host has a higher election criteria, it responds with an election packet with its criteria. Eventually, the computer with the highest criteria wins the election, and assumes the role of the master browser.
Subnet Browsing	Users often require accessing resources on other subnets in a wide area environment. In order to provide this, each domain elects a master browser on each subnet. These master browsers all exchange browse lists with the domain master browser every 15 minutes. This update of browse information is then provided to the client computers through backup browsers.
Browser Queries	When a user attempts to display a list of network resources, a backup browser is used to get that list. In order to find a backup browser, the client must first send a "Get Backup List Request" to the master browser of their subnet. The master browser responds with a list of backup browsers. Finally, the client selects a backup browser from the list, and establishes a session to retrieve the current browse list.

Note: For more information on browser traffic, see Appendix F: "Browser Traffic".

Analyzing File Session Traffic

One of the goals of analyzing and optimizing the traffic generated by the Windows NT Server services is to provide as much network bandwidth as possible for users accessing files, printers, and applications. Each application used will generate unique patterns of traffic, but file session activity is consistent, and thus can be measured and analyzed easily.

Following is a list of the types of traffic generated by file session activities:

File Session Activities	Description
Resolving IP Addresses	Traffic is generated by a client attempting to resolve an IP address into a hardware address. To resolve an IP address generates two small frames of about 60 bytes each.
Establishing a TCP session	Traffic is generated when establishing a TCP session between the client and server computers. To establish a TCP session generates three small frames of 60 bytes each.
NetBIOS Session Establishment	Traffic is generated by a client that is attempting to establish a NetBIOS session with a server computer. To establish a NetBIOS session generates two small frames totaling 186 bytes.
SMB Protocol Negotiation	Traffic is generated during SMB Protocol Negotiation between the client and server computers to determine what SMB commands can be used. To negotiate SMB protocols, two frames of varying size are used (339 bytes for Windows for Workgroups 3.11 and 364 bytes for Windows 95), depending on SMB levels understood by the client.
Connection Sequence	Traffic is generated during the actual connection request to the shared resource and the response between the client and server computers. To connect to a shared resource, two frames of varying size are used, generally around 350 bytes
Disconnecting a Session	Traffic is generated when a session is terminated. To disconnect a session, two small frames are used that are 93 bytes each.

Note: The preceding frames listed were mentioned earlier in the course.

For more information on file session traffic, see Appendix G: "File Session Traffic".

To establish a session and a file connection, there will be about 11 frames totaling 1,000 bytes of network traffic. Once the sessions and connection has been established, the traffic generated between the client and server computers will vary depending upon the type of file or print activity, and the application used.

Analyzing Account Synchronization Traffic

In a Windows NT Server network, user logon validation requests are processed by either the primary domain controller or a backup domain controller. Often logon validation is handled by a backup domain controller. This is because the client accepts the first response to its query, and uses that server to perform validation. Primary domain controllers are typically busier than backup domain controllers, thus preventing the PDC from replying as quickly as a BDC.

To ensure that each backup domain controller in the domain properly validates each user logon request, it is important that each backup domain controller has an exact copy of the directory services database maintained on the primary domain controller. This happens through the NetLogon service's ability to perform directory services synchronization.

Synchronization of the Windows NT databases occurs during the following times:

• When a backup domain controller is installed or restarted into the domain.

• When forced by the administration using Server Manager.

• Automatically by the domain controllers, depending upon Registry configuration.

Finding the Primary Domain Controller

After the backup domain controller has successfully initialized its protocol, registered itself as a member of the Domainname <1C> group name and completed initializing its networking services, it needs to find the primary domain controller to update its directory services database.

Querying for the Primary Domain Controller

To find the primary domain controller, the client queries WINS by sending a request for Domainname <1B>. This name is only registered by a primary domain controller. The WINS server then returns the IP address of the primary domain controller. These two frames total 196 bytes of traffic.

The backup domain controller then sends a "Query for Primary DC" message to the owner of the Domainname <1B> address returned by WINS. This is done to determine the name of the primary domain controller. This message is sent as a second class mailslot to \MAILSLOT\NET\NETLOGON. This frame is approximately 270 bytes.

Primary Domain Controller Response

The primary domain controller then responds to the backup domain controller with a "Response to Primary Query" frame. The primary domain controller's name is listed as Primary DC Name, as well as the domain name. This frame is approximately 275 bytes.

To discover the name of the primary domain controller takes four frames, and about 545 bytes of traffic.

Verifying the Directory Services Database

Once the backup domain controller has found the primary domain controller, it will proceed verifying its version of the directory services database. To complete this process, it must establish a session with the primary domain controller to prepare for verification and synchronization of the directory services database. This takes about 11 frames and 1,200 bytes of traffic.

Establishing a Secure Channel

The final step is to establish a secure channel with the primary domain controller. Before the backup domain controller can verify that its user accounts database version is up to date, it must establish a secure channel with the primary domain controller. This is done using eight frames totaling 1,550 bytes.

Verifying the Database

The next RPC Request frame will be duplicated numerous times, each with the same operation number. There will be a minimum of three frames that are NetrDatabaseDeltas (Operation Number 0x7). These frames are used to tell the primary domain controller the serial number, or version ID, of each of the databases at the backup domain controller. They are also used to request updates to the directory services database. These six frames total approximately 1,344 bytes.

Periodic Updates of the Databases

By default, the primary domain controller verifies its databases every five minutes, looking for changes to any of the three databases. When a change is noticed, it sends a message to all backup domain controllers that need the notification, indicating that an update has been made to one of the databases. The PDC maintains a table of each BDC, and the version ID of each of their databases. If a BDC has an up-to-date database, it is not notified of the update.

When a new user account is added to the user account database, the primary domain controller detects the change. At the point when the change is detected, the following sequence of events occur:

• The PDC announces a change to the SAM with a frame of approximately 390 bytes.

• The BDC connects to IPC$ of the PDC.

• The BDC establishes a secure channel to the PDC, and uses the NetLogon service to verify the account database.

• The BDC uses SMB or RPC calls (depending on the size of the update) to transfer the updated data.

This entire process could take as few as 12 frames, and under one second to complete (for the addition of two users). These 12 frames totaled 4,411 bytes of data in a test environment with full information for one user account, including full name, comment, and group membership. The second user did not have a full name or comment created. Two frames, one 1,138 bytes and the other 462, transferred the two user accounts.

Analyzing Trust Relationship Traffic

In a typical enterprise environment, MIS often requires centralized administration of user accounts, while individual departments control access of distributed resources. In this environment, establishing an accounts domain, with multiple resource domains is a good solution. Trust relationships are a necessary component of this solution as they allow user accounts from the accounts domain to have access to resources in the resource domains.

Establishing trust relationships is an administrative task and does generate some network traffic. The following table list types of trust relationships traffic:

Traffic generated by:	Description:
Trusting Domain	Traffic is generated when a trusted domain permits the new domain to trust its accounts, and the trusting domain accepts the offer. This entire process can take over 100 frames, and three second to complete. The total network traffic may be over 15,000 bytes.
Trusted Account	Traffic is generated when a trusting domain imports trusted accounts to assign permissions to local resources. This entire process can take over 100 frames, over 24,000 bytes of data, and ten seconds to complete.
Pass Through Authentication	Traffic is generated when a user in a trusted domain attempts to access a resource in a trusting domain. The traffic generated by a trusting domain controller requesting validation by a trusted domain controller requires around 3,700 bytes of traffic, 20 frames, and 200 milliseconds to complete.

Note: For more information on trust relationship traffic, see Appendix C: Establishing Trust Relationships.

Analyzing Directory Replication Traffic

The Directory Replicator service for Windows NT Server allows automatic replication, or duplication, of a directory tree between multiple computers, without the intervention of a network administrator. It is most commonly used for replicating user logon scripts from the primary domain controller of a domain to backup domain controllers, ensuring that no matter which domain controller a user is validated by, the user can execute its logon script.

Replication

The directory replication process occurs as the export server detects changes in its export tree (by default the REPL$ sharename). It then notifies everyone in its export list that there have been changes made to the export tree. This announcement is approximately 340 bytes in size.

The import server(s) then make an SMB connection to the export server. It will take around nine frames and 1,286 bytes to establish the session. The import server will then verify the directory using 22 frames and 3,710 bytes. If an update of files is required, this connection is used to copy the updated files from the export server to the import server. The number of frames will vary depending on the amount of data that needs to be replicated between the two computers.

Pulses

Every so often, the export server notifies the import servers running as a export server, and indicates the first level directories in its export tree. This message serves as a notice to synchronize if the export server has changes, or simply a pulse if no changes are detected. By default, this message is generated to each import domain and/or server in the export server's export list every five minutes, but can be adjusted

Analyzing WINS Replication Traffic

WINS Replication

In many organizations, it is likely that one WINS server will not be sufficient to offer the required level of fault tolerance and load. Even though a single WINS server can support 10,000 WINS clients, it is always a good idea to have a backup server. WINS supports the ability of having multiple WINS servers for clients to register and query, while allowing these servers to replicate, or share, their databases with each other. The benefit of this database sharing is that eventually each WINS server will know about all the other WINS clients that have registered with its WINS partners. This offers better name resolution for clients.

WINS Record Sizes

Each entry into the WINS database will vary in size, depending upon the type of entry being added. The amount of data stored for a normal (unique) client computer with a single network adapter card is between 40 and 280 bytes, depending on if the client has configured a scope id (which can be up to 255 characters). A client without a configured scope id would require 40 bytes in the database for each name registered.

If the client is multihomed (having multiple network adapters configured for TCP/IP), the amount of data stored will vary depending upon the number of IP addresses configured for the computer. It will range from 40 bytes up to 280 bytes per host.

If the name registered is an internet group name, such as domainname <1C>, it can be up to 480 bytes if it contains it maximum number of registered hosts (which is 25).

WINS Replication

When configuring a replication partner, the first step in the process is to add the other WINS server as a replication partner. This can be accomplished by using WINS Manager. When adding another WINS server as a replication partner, the following sequence of events occur:

• The local WINS server establishes a TCP/IP session with the destination WINS server over TCP port 135.

• This session is a normal TCP 3-way handshake, requiring three packets totaling 160 bytes.

• RPC calls are used to verify the partner relationship. The entire process utilizes approximately 18 frames, totaling just over 2,000 bytes (in a test environment). In each of these frames, the first 54 bytes are normal Ethernet, IP, and TCP packet headers, with the remaining containing the RPC call.

Once the replication partner relationship has been configured and verified, data can be transferred. This transfer will involve sending records between the WINS servers. This transfer used TCP port 42.

The number of records to be transferred may be different with every replication event. With a sample database of 22 records, the total transfer took two seconds and 14 total frames, including session establishment frames. One data frame contained all 22 names to be added to the partner's database. This frame was 1,158 bytes in size, with the final 1,104 bytes representing the actual records.

A later update of the database, involving only three records, took less than one second and used 26 frames. 12 frames were used to verify the database. The three data records were contained in one frame, devoting 168 bytes for the three records.

Optimizing DHCP Traffic

The implementation of the Dynamic Host Configuration Protocol does not significantly increase the amount of network traffic. The entire process of a acquiring an IP address lease through DHCP takes a total of four packets, generally 342 bytes in size. This process, on a clean network (no other network traffic using bandwidth), takes less than one second (~300 milliseconds).

DHCP conversations generally occur in the following instances:

• A DHCP client initializes for the first time (all four frames).

• An automatic renewal, which is only done every one-half lease life (three days by default, so every 18 hours), takes two packets (DHCP Request and DHCP ACK), and approximately 200 milliseconds.

• When a client is moved to a new subnet (DHCP Request, DHCP NACK, then the four frames as if a new client).

• When a DHCP client replaces its network adapter card (all four frames).

• Whenever a client manually refreshes or releases its address with IPCONFIG.

Lease Duration

To reduce the amount of traffic generated by DHCP, it is possible to adjust the lease duration for IP address leases. This is done using DHCP Manager, and adjusting the Lease Duration in the Scope Properties dialog box. Increasing the lease life from the default of three days to, say 30 days, would certainly reduce the frequency of renewals by the DHCP clients on the network. It is recommended to use short lease lives when the number of clients that will be using DHCP to acquire IP addresses is close to the number of IP addresses that can be assigned via DHCP. If the number of DHCP available IP addresses is much larger than the number of DHCP hosts, then longer lease periods make more sense.

DHCP Thresholds

If an internetwork consists of routers that support BOOTP-relay and RFC 1542, these routers will forward the DHCP Discover messages to all other subnets to which the router is connected. Most newer router software supports configuring the number of retries that must occur before the router forwards the local request to other subnets. If the local DHCP server is busy, and does not answer the request immediately, configuring this parameter to three would allow for two requests from the client that would stay on the local subnet, and then upon the third request, it would be forwarded to other subnets in an attempt to find a DHCP server.

WINS Client to Server

WINS client to server traffic generally consists of name registrations, renewals, resolutions and releases. Of these, it is possible to configure WINS Manager to adjust the renewal rate of WINS clients.

Time To Live

Upon registering a name with a WINS server, the client is given a TTL (Time To Live) for that name. By default, this TTL is 96 hours. The TTL indicates the amount of time the name is reserved for the client's IP address. Microsoft's implementation of WINS configures the client computers to automatically renew their registered names every one-half of the TTL. With default configuration, this would occur every 48 hours. Thus, if a WINS client registered six names (for various network services) at startup, it would renew these same six names every 48 hours. The registration packets, as well as the renewal packets, are fairly small in size. The actual size will vary depending upon the computer and domain names configured for the WINS client, but will generally be about 110 bytes in size. The response message from the WINS server is 104 bytes in size.

Using WINS Manager to lengthen the Renewal Interval will reduce the frequency of client name renewal attempts to one-half of the configured Renewal Interval. However, since this is not a large amount of traffic, it is recommended to keep the default of four days in most instances.

Stop Unnecessary Services

Names are registered for each service that provides NetBIOS support. Stopping unnecessary services from starting will reduce the number of names registered, and renewed. For example, if not using NetDDE, stopping it would prevent it from registering, renewing, and releasing upon shutdown.

Optimizing File Session Traffic

Understanding the traffic generated by file sessions is important, not only to know what is looks like, but because other services use the same characteristics as part of the traffic they generate.

File session activity does generate network traffic. It generally does not generate a lot of activity to establish the session and connection, but what occurs after the connection is made will probably generate much more significant amounts of traffic on the network.

The entire process of establishing a TCP session, NetBIOS session, SMB protocol negotiation, and a tree connection took 10 frames and a total of 238 milliseconds from a Windows 95 client to the Windows NT Server 3.51 computer. This conversation used 1,169 bytes of network traffic.

The process of disconnecting a session is even less traffic, taking five frames, 360 bytes, and seven milliseconds.

Recommendations for Optimization

There is not a lot that can be done to optimize file session connection/disconnection traffic. Probably the best thing to do is to remove any excess protocols, as connection requests are sent over all protocols simultaneously. Removing protocols not needed will reduce the number of packets on the network.

Optimizing Domain Traffic

Optimizing directory services traffic often involves controlling the amount of traffic generated during directory services database synchronization. This will require determining a balance between providing logon validation for users and WAN bandwidth for user access.

In larger organizations, a single domain may be implemented over multiple physically distinct locations. In this environment, it may be important to ensure that user logon validation requests are able to be handled, regardless of the status of the WAN link. In this case, it would be necessary to place a backup domain controller at each remote site to ensure users could log on and become validated in the event the WAN link becomes unusable. A Windows 95 client logon sequence took 39 frames and 6,538 bytes of data.

If a backup domain controller is located at each remote site, it is important to ensure that the process of synchronizing the directory services account database does not utilize the entire WAN bandwidth. Using the entire WAN for account synchronization would effectively prevent user access to remote resources and applications during synchronization. A periodic update of two users generated 28 frames and 5,654 bytes of traffic.

Database Synchronization over a WAN

Directory service database synchronization takes, on average, 1K per change. On a 56K point-to-point circuit, it would take about 24 hours to fully synchronize a 30,000 user SAM.

There were several enhancements made to Windows NT 3.5 in order to reduce the frequency of full synchronization events, as well as allow for controlling the amount of data transferred during synchronization. These enhancement make it is less likely that a full synchronization event will occur in Windows NT 3.5x.

It is also important to remember that by default, if the NetLogon service change log becomes full and starts wrapping, a backup domain controller would force a full synchronization event to occur. This could happen if the WAN link is somewhat unstable, resulting in partially completed synchronization events. In this case, the remote backup domain controller will need to force a full synchronization in order to ensure a valid directory services database.

ReplicationGovernor

Probably the most commonly modified NetLogon parameter is HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services

Netlogon\Parameters\ReplicationGovernor. This parameter controls the percentage of network bandwidth the NetLogon service may use at any one instance while performing directory services synchronization. The default value for this parameter is 100%, meaning that during a synchronization event, 100% of the network bandwidth can be used by the NetLogon service, while the primary domain controller is buffering 128K of data at a time. This can be very disastrous in a WAN environment, where users are also competing for the same bandwidth. By adding this parameter, and configuring it to a value of 50, the NetLogon service will only buffer 50% as much data (64K) for transmission, and only have synchronization messages on the network 50% of the time.

Other NetLogon parameters that can help control the amount of network traffic generated during directory services account synchronization events are listed in the following table:

Netlogon parameters	Description
Pulse	Controls how often the primary domain controller looks for changes to its directory services database, and sends synchronization messages to the backup domain controllers that need updating. The default value is five minutes, and can be increased to a maximum of 60 minutes.
PulseMaximum	Controls how often the primary domain controller will send a pulse message to each backup domain controller, even if its directory services database is up to date. The default value is every two hours, and can be increased to every 24 hours, reducing the number of pulse messages.
ChangeLogSize	Controls the number of changes to the directory services database before a full synchronization event occurs. The default value is 64K, which equates to about 2,000 changes (changes average 32 bytes each). In an environment with a large number of users that are frequently changing passwords, it is possible for this limit to be met, causing a full synchronization event to occur. This generates excess traffic, as more information is sent to the backup domain controllers than is really necessary.

By performing proper analysis of your directory services during synchronization, and then implementing proper optimization techniques, it is possible to reduce the traffic generated during these events, providing for more network bandwidth to users.

Optimizing WINS Server to Server Traffic

WINS database replication generates network traffic, and is of concern especially in wide area networks with slow link speeds. Each entry, on average consumes about 50 bytes of disk space. When replicating database entries between WINS servers, these entries are accumulated and delivered in the fewest number of packets possible. When using WINS Manager to force replication of a sample database of 14 records, the total transfer took one second and 14 total frames, including session establishment frames. One data frame contained all 14 names to be added to the partner's database. This frame was 758 bytes in size, with the final 704 bytes representing the actual data records. A later, periodic update transferred 35 records in a total of 12 frames. The 35 records were sent in two TCP segments of 1460 and 268 bytes respectively. The remainder of the frames were session establishment and WINS control frames.

WINS replication partners can be configured as either push and/or pull partners. Push partners send announcements to their configured partners when a specific number of database entries have changed. Pull partners request updates when notified by the push partner, and at configured intervals

When using WINS Manager to add another WINS server as a pull partner, the other WINS server requests changes after a specific version number. You can configure replication to occur at a specific time interval. For example, you might configure WINS to send pull requests every 30 minutes for local WINS servers, every hour for remote WINS servers connected via high-speed links (T1 or higher), and every six hours for remote WINS server connected via slow-links (56kbps).

When configuring Push notifications, which informs the Pull partner that there are updated records, configure WINS to initiate the push notification after a specific number of record updates have been accumulated. The default value is 20. There will be no designated time interval of initiating Push notifications and replications. Increasing the number of database updates required before sending a Push notification will reduce the frequency of WINS replication, and 'batch' more records in a single transfer operation.

Optimizing Browser Traffic

All computers that have a server component announce themselves to the browse master as browsing entity. This uses one frame and about 250 bytes. This process will be repeated every 12 minutes to ensure the computer remains in the browse list. Disabling the server component on all computers not to be used as servers will remove this traffic.

In a routed TCP/IP environment, a master browser for each domain is elected on each subnet. All master browsers for a single domain exchange a browse list with the domain's domain master browser every 15 minutes. This exchange includes not only the local computers for the local domain, but also other domain's that have been announced on each subnet.

Retrieving a browse list takes around six frames, two to determine the list of backup browsers, and four to retrieve a list of domains and servers in the local domain.

Registry Updates

Most of the traffic generated by browsing is initiated automatically by the appropriate browsing computers, the domain master browser, the master browsers, and the backup browsers. Until Windows NT 3.51 Service Pack 2, there was little that could be done to optimize the effect the Computer Browser service had on the network. However, with Service Pack 2, two new parameters can be configured to control the amount of network traffic generated by the browser.

Browsing entries are found in the Registry under HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Browser

Parameters.

MasterPeriodicity

MasterPeriodicity specifies how frequently a master browser contacts the domain master browser. The default is 900 seconds (fifteen minutes), with a minimum of 300 seconds (five minutes), and a maximum value of FFFFFFFF (4 billion seconds). This parameter is added as a REG_DWORD, and can be changed dynamically without rebooting the computer. This parameter should be added on the master browsers. This parameter does affect WAN traffic, as each subnet that a domain has a member on has a master browser for the domain on that subnet.

BackupPeriodicity

BackupPeriodicity specifies how frequently a backup browser contacts the master browser. Adding this parameter as a REG_DWORD, using a default of 720 seconds (twelve minutes) and the same ranges as MasterPeriodicity, requires restarting your computer. This parameter does not affect the WAN, since this traffic is always within a subnet.

Controlling the amount of traffic generated by the browsing functions of Windows NT Server can have a large impact on network utilization, especially over WAN links.

Optimizing Directory Replication Traffic

The Directory Replicator service on Windows NT Server provides the ability to automatically duplicate a source tree to multiple other computers. This process can involve a number of packets, depending on the amount of data to be replicated. However, by default, the export server only checks every five minutes for data to be replicated (and can be configured at higher intervals), so it is infrequent network activity. This process generates very little network activity unless data on the export server has changed.

A sample directory containing 16 files and 426,000 bytes of data took 1,425 frames and approximately 42 seconds to replicate, whereas deleting 1 file from that same export list took only 251 frames and 48 seconds to verify and update.

Directory Structure

The best way to reduce the amount of traffic generated by the Directory Replicator service is to use a flat, shallow directory structure. Having very large (deep) and frequently changing top-level replicated directories is very taxing on the Directory Replicator service. The Directory Replicator service checks, and then copies, an entire top-level directory if any file in that directory has changed. Because some file is likely to change in large directories, the Directory Replicator is constantly rechecking and recopying these directories. It would generate far traffic if multiple, shallower top-level directories were used in place of a smaller number of deep directory structures. This would put as many of the files as possible in directories where changes are very infrequent.

Server Manager

You can prevent the export server from replicating directories during the day by adding a lock to the directory. This can be done using Server Manager, or Control Panel Server. From the Server Properties dialog box, choose Replication. In the Directory Replication dialog box, under Export Directories, choose Manage. Then select the directory, and choose Add Lock. This can be used to help control the traffic to times when there is less user generated network traffic.

Also in the Directory Replication dialog box is the "Wait Until Stabilized" option for each exported directory. The "Wait Until Stabilized" option causes the import server to recopy the entire subtree whenever any file in that subtree changes. With this option disabled, the import server will check the time/date/name/attributes/size of each file individually, and copy only those files which have changed.

Registry Parameters

Directory replication entries are found in the Registry under HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Replicator \Parameters. The two most common parameters to modify to control the Directory Replicator service are Interval and Pulse.

• The Interval parameter determines how often the originating server (called the export server) checks for updates to its specified directory structure, and sends notifications to its target computers (called import servers) to retrieve the new data. The default value for Interval is 5 (minutes). You can increase this to 60 minutes or more (on the export server) to reduce the frequency of replication. Of course, this will also increase the replication delay for each individual change.

• The Pulse parameter acts as a counter to control how often an import server contacts an export server. If an import server fails to hear from the export server after <Pulse> * <Interval> minutes, it will send a message to the export server asking for an update. The default value of Interval is 5 minutes (as described above), while the default value of Pulse is 2. These parameters mean that if the import server has not heard from the export server after 10 minutes, it will initiate communications with the export server. Increasing the Pulse parameter will increase the time intervals for the import server to contact the export server, allowing more time for the export server to contact the import server.

Summary of Windows NT Network Traffic

Now that we have discussed the network traffic patterns for some of the Windows NT Server services and common functions, here is a summary of these traffic patterns:

Service	Traffic	Frequency
DHCP	Acquire IP Address - 4 frames and 1,368 bytes.	Once per client.
	Renew IP Address lease - 2 frames and 684 bytes.	Every startup and at 1/2 Lease Life.
WINS Client to Server	Registration - 2 frames and 214 bytes.	Once per service or application at startup.
	Renewal - 2 frames and 214 bytes.	Once per service or application every 1/2 TTL.
	Resolution - 2 frames and 196 bytes.	Varying frequencies.
Logon Validation	Preparation - 15 frames and 2,000 bytes.	Once per user logon.
	Validation sequence - 4 frames and 760 bytes.	Once per user logon.
	Session breakdown - 5 frames and 360 bytes.	Once per user logon.
	Scripts, policies, profiles - varying amount of traffic.	Once per user logon.
Browser	Host Announcement - 1 frame and 243 bytes.	Once per 'server' computer every 12 minutes.
	Local Master Announcement - 1 frame and 250 bytes.	After each Announcement Request or Election.
	Workgroup Announcement - 1 frame and 250 bytes.	Every 15 minutes.
	Elections - many frames and 235 bytes each.	After each computer capable of becoming the master browser initializes.
	Finding a backup browser - 2 frames and about 450 bytes.	Once per browsing computer at initial browse attempt.
File Sessions	Address resolution - 2 frames and 120 bytes.	At each attempt to communicate with another TCP/IP host (when aged from ARP cache).
	TCP Session - 3 frames and 180 bytes.	Once per first connection to each target TCP host.
	NetBIOS Session - 2 frames and 186 bytes.	Once per first NetBIOS connection to a target computer.
	SMB Protocol Negotiation - 2 frames and about 350 bytes.	Once per first SMB connection to a target computer.
	Connection Sequence - 2 frames and about 350 bytes.	Once per network resource access.
	Session Disconnection - 5 frames and 360 bytes.	Once per final connection to TCP host has been disconnected.
Directory Services Database Synchronization	Finding the PDC - 4 frames and about 545 bytes.	Once per BDC bootup.
	Establish session - 11 frames and 1,200 bytes.	Every synchronization event.
	Establish secure channel - 8 frames and 1,550 bytes.	Every synchronization event.
	Verify the databases - 6 frames and 1,350 bytes.	Every synchronization event.
	PDC Update notice - 1 frame and about 400 bytes.	Every synchronization event.
Establishing a Trust Relationship	About 100 frames and 15,000 bytes of traffic.	Once per each trust relationship created.
Importing Trusted Accounts	About 100 frames and 24,000 bytes of traffic for 11 trusted accounts.	Each attempt to import a trusted account into a trusting domain.
Pass Through Authentication	20 frames and about 3,700 bytes of traffic.	Once for the first attempt to access a resource on a trusting computer, or logon to a trusted domain from a trusting computer.
Directory Replication	Announcement - 1 frame and about 340 bytes.	Once per importing domain or server for every update of the export tree.
	Establish session - 9 frames and about 1,300 bytes.	Once from each import server every update event.
	Verify directory - 22 frames and about 3,700 bytes.	Once from each import server every update event.
	Update directory - various amounts of network traffic.	Once from each import server every update event.
WINS Replication	Database verification - 12 frames and about 900 bytes.	Once per update request to each replication partner.
	Database update - about 14 frames and about 2,100 bytes (varies with number of updates).	Once per update request to each replication partner.

Predicting Network Traffic

Now that proper analysis and optimization of the network has been accomplished, it should be possible to proceed onto the final step of the planning and implementation process. That is predicting what affect a new server or service will have on the overall network traffic on the network.

Once you have a good idea what traffic each service or function generates on the network, predicting the affect of the implementation of another server providing that service should be a fairly easy process. To properly predict the affect a service or server will have on network traffic, you will need to follow a few requirements:

• Careful identification and analysis of the traffic associated with a specific function, in order to properly project the amount of traffic a service will generate.

• Identification of the service to be implemented on the network.

• Determining the variables associated with implementing the service. For example, if analyzing the affect of implementing DHCP, you will need to know how many DHCP servers will be installed, how many DHCP clients will be used, and how long the lease duration is:

• Speculating the network traffic impact of implementing the service.

• Understanding that predicting network traffic is not an exact science, but a process to help understand and plan for network traffic.

Following are two examples of predicting network traffic. Use the previous section titled "Summary of Windows NT Network Traffic" to determine the basic traffic patterns of the various Windows NT Server services.

Example 1

A company has decided to move to DHCP to centrally manage their use of IP addresses. They have 100 clients that can use DHCP to acquire addresses. They will start with one DHCP server, and a default lease life of seven days. To determine how much traffic this will generate, complete the following:

• Lease Acquisition:

  • 1 client and one server: four frames and 1,368 bytes.

  • Total network traffic to acquire IP address for 100 clients: 400 frames and 136,800 bytes of traffic. Even if all clients were simultaneously attempting to acquire addresses, this would still only be 10% (1,094,400 bits) of a 10Mb Ethernet cable.

  • Frequency: once per client.

• Lease Renewal:

  • 1 client: two frames and 1,368 bytes.

  • Total network traffic to renew IP address for 100 clients: 200 frames and 68,400 bytes of traffic. Even if all clients were simultaneously attempting to renew their address, this would still only be 5% (547,200 bits) of a 10Mb Ethernet cable.

  • Frequency: every client startup process. If client is not restarted, every 3.5 days per client.

Example 2

A company has decided to add a new domain that will have a primary domain controller and three backup domain controllers. To determine how much traffic this will generate, complete the following:

• Booting:

  • Booting a PDC generates 88 frames and 12,800 bytes of traffic.

  • Booting a BDC generates 78 frames and 11,600 bytes of traffic.

  • Total network traffic to boot one PDC and three BDC's: 47,600.

  • Frequency: every restart of all four computers.

• Synchronizing the accounts list, assuming five changes per hour:

  • Announcement of change: 1 frame and about 400 bytes.

  • Total announcement traffic: 3 frames and about 1,200 bytes.

  • Frequency: every 10-15 minutes.

  • BDC attempting to find the PDC: 4 frames and about 545 bytes.

  • BDC establishing session with PDC: 11 frames and 1,200 bytes.

  • BDC establishing secure channel with PDC: 8 frames and 1,550 bytes.

  • BDC verifying and updating the database: 7 frames and 2,560 bytes for two account changes.

  • Total synchronization traffic: 30 frames and 5,855 bytes per BDC. Three BDC's require a total of 90 frames and 17,565 bytes of traffic.

  • Frequency: after every announcement of changes to one of the databases.