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.
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:
The remainder of this seminar will focus on these procedures to capacity plan the following network services/functions:
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.
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 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 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).
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.
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.
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:
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.
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.
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:
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.
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. |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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:
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.
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.
The browsing process is based almost entirely upon broadcast packets, the majority of which are very similar. These properties include:
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.
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.
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".
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.
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:
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
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
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.
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 multi-homed (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).
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:
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.
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:
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.
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 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.
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.
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.
Understanding the traffic generated by file sessions is important, not only to know what it 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.
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 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.
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.
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 |
|
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.
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.
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.
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 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 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.
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.
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.
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.
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.
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 - Renew IP Address lease - |
Once per client. Every startup and at 1/2 Lease Life. |
WINS Client to Server |
Registration - 2 frames and 214 bytes. Renewal - 2 frames and 214 bytes. Resolution - 2 frames and 196 bytes. |
Once per service or application at startup. Once per service or application every 1/2 TTL. Varying frequencies. |
Logon Validation |
Preparation - 15 frames and 2,000 bytes. Validation sequence - 4 frames and 760 bytes. Session breakdown - 5 frames and 360 bytes. Scripts, policies, profiles - varying amount of traffic. |
Once per user logon. Once per user logon. Once per user logon. Once per user logon. |
Browser |
Host Announcement - 1 frame and 243 bytes. Local Master Announcement - 1 frame and 250 bytes. Workgroup Announcement - 1 frame and 250 bytes. Elections - many frames and 235 bytes each. Finding a backup browser - 2 frames and about 450 bytes. |
Once per 'server' computer every 12 minutes. After each Announcement Request or Election. Every 15 minutes. After each computer capable of becoming the master browser initializes. Once per browsing computer at initial browse attempt. |
File Sessions |
Address resolution - 2 frames and 120 bytes. TCP Session - 3 frames and 180 bytes. NetBIOS Session - 2 frames and 186 bytes. SMB Protocol Negotiation - 2 frames and about 350 bytes. Connection Sequence - 2 frames and about 350 bytes. Session Disconnection - 5 frames and 360 bytes. |
At each attempt to communicate with another TCP/IP host (when aged from ARP cache). Once per first connection to each target TCP host. Once per first NetBIOS connection to a target computer. Once per first SMB connection to a target computer. Once per network resource access. Once per final connection to TCP host has been disconnected. |
Directory Services Database Synchronization |
Finding the PDC - 4 frames and about 545 bytes. Establish session - 11 frames and 1,200 bytes. Establish secure channel - 8 frames and 1,550 bytes. Verify the databases - 6 frames and 1,350 bytes. PDC Update notice - 1 frame and about 400 bytes. |
Once per BDC bootup. Every synchronization event. Every synchronization event. Every synchronization event. 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. Establish session - 9 frames and about 1,300 bytes. Verify directory - 22 frames and about 3,700 bytes. Update directory - various amounts of network traffic. |
Once per importing domain or server for every update of the export tree. Once from each import server every update event. Once from each import server every update event. Once from each import server every update event. |
WINS Replication |
Database verification - 12 frames and about 900 bytes. Database update - about 14 frames and about 2,100 bytes (varies with number of updates). |
Once per update request to each replication partner. Once per update request to each replication partner. |
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:
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.
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:
Lease Renewal:
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:
Synchronizing the accounts list, assuming five changes per hour: