26. Network Analysis and Optimisation

Frames on the network are either broadcast, multicast or directed frames.

NWLink and NetBEUI tend to base traffic on broadcasts whereas TCP/IP is recommended as it uses broadcasts less.

The version of NetMon that comes with NT is the simple version that only captures packets coming to and from the computer. The version that comes with SMS also does remote capturing, top users, distinguishes between protocols and devices etc. Promiscuous mode means that the network adapter accepts all frames on the network cable regardless of the destination address. This is very CPU intensive.

The Capture window has four sections:

Graph - indicates Network Utilization, Frames/Bytes/Broadcasts and Multicasts per second
Session Statistics - summary of conversations between two hosts
Total Statistics - traffic on the whole network
Station Statistics - the total number of frames initiated by a host.

Use Start and Stop capture and use filtering to decide which protocols to capture. You can save the capture to a .cap file for later study.

You can also filter when displaying the capture file. There are three panes in the capture summary, the Summary Pane, the Detail Pane and the Hexadecimal Pane.

Client Initialisation

An approximate breakdown of client traffic is shown below:

Intranet browsing - 48%
Browser - 31%
File Session - 12%
Logon Validation - 6%
DNS - 1%
WINS - 1%
DHCP - 1%

The four frames used in DHCP are 342 bytes long and are detailed thus:

DHCP Discover - a broadcast by the client to locate a DHCP server.
DHCP Offer - the server responds with an offer of an IP address.
DHCP Request - the client selects the offer and responds saying that it has done so.
DHCP ACK - the server responds with an acknowledgement plus other TCP/IP parameters.

If you look at the frame itself you will see that the UDP source port is 68(BOOTP client) and that the UDP destination port is 67 (BOOTP server).

Renewal of an IP address lease can occur at startup using the DHCP Request and DHCP ACK frames, or it can occur half-way through the lease duration period in which case the DHCP Request and DHCP ACK frames are directed straight to the DHCP server rather than broadcast. There will be three attempts at renewal before starting the entire lease process from scratch as if it were a new client. The default lease period is 3 days and can be adjusted in DHCP Manager, short leases are suitable if you are short of IP addresses.

Once clients have their IP address they then register their NetBIOS name either using b-node broadcasts or a WINS server if one is present. The WINS server is good for the network as all the traffic is directed to it rather than wasteful broadcast. UDP port 137 is used for the name service functions. A NetBIOS name needs to be registered for each application that requires such as Network Monitor, Server services and so on. One computer may have 3 or 4 NetBIOS names. A name registration request is 110 bytes and the WINS server responds with a response message of 104 bytes indicating success or failure depending on whether the name has been registered plus a Time to Live (TTL) value indicating when the name needs to be reregistered. To release a name a 110 byte release request is sent to the server and the WINS server responds with a success frame (104 bytes) indicating a TTL of 0.

To resolve a NetBIOS name a 98 byte Name Query Request is sent to the WINS server. A 98 byte Name Query Response frame is sent either with a success and IP address of the name, or a failure indicating that the name does not exist in its database. On a failure, the client resorts to b-node broadcasts. Resolved names remain in the name cache for 10 minutes by default.

Optimising WINS traffic can be done by disabling unnecessary services (as each requires a name), increase the time that a NetBIOS name remains in the cache by increasing the registry setting HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\CacheTimeout thereby reducing WINS queries for frequently used services. A static text file called LMHOSTS resides in winntroot\system32\drivers\etc\ and this lists IP addresses against NetBIOS names. This file can be preloaded into the name cache.

Establishing a session requires the following steps:

ARP - an ARP request is a broadcast frame of 60 bytes requesting a MAC address for a particular IP address. The target computer identifies its IP address and sends back a 60 byte ARP reply containing its hardware address.
TCP - a TCP session offers a guarranteed delivery service. Using a sequenced frame (60 bytes) one station sends two sequence numbers, the other station responds with two sequence numbers acknowledging the first stations sequence numbers and then the first station acknowledges the second station's numbers. This is called a Three-way Handshake and just needs to be done once as many file connections can occur over this session.
NetBIOS Session - One station sends a Session Request frame with the destination and source names. The other station returns a Positive Session Response if the name is correct.
Server Message Block (SMB) Protocol Negotiation - the client sends a list of all the dialects that it understands to the server. The server responds with the highest level of dialect (e.g. number 5) which might include things like Long File Names, UNI code support etc.
SMB session setup and Tree Request - this request from the client includes the share name, username and the password. The server responds with a success mesasage.
Data transfer
Session Termination - the client requests the Tree ID of the remote drive to be disconnected. This Tree ID was assigned by the server in the first place. The server disconnects. Then the client requests the server to close the TCP session, followed by the server requesting the client closes its session and a final acknowledgement from the client.

To find a Logon Server an NT client broadcasts with the domain name as the NetBIOS name with <00> as the 16th character. Each logon server in the domain will respond with a directed reply containing the IP address and computer name of the logon server. This is done using the mailslot \Mailslot\Temp\Netlogon.

If, on the other hand, the client computer is an h-node WINS client then it sends a 92 byte query to the WINS server for the domain name with a 1C as the 16th character. The WINS server replies with the IP addresses of up to 25 domain controllers in its database, the locally registered servers first. The client then sends a validate request to each server which responds with a directed reply using NETLOGON. The client responds to the first server to respond to its request.

Validation occurs in three steps:

The client retrieves a list of trusted domains.
A secure channel is setup between the domain controller and the client.
An API (RPC) call frame and a response frame carry out the validation.

Client-Server Traffic

Browser traffic is broadcast traffic and most routers are not configured to forward browser broadcasts, using WINS gets around this problem.

A computer with resources broadcasts an announcement every 12 minutes. For a client to find the local master browser it sends a Get Backup List Request with <1D> as the 16th character. The master browser sends a Get Backup List Response listing the available backup browsers. If there is no response from the master browser the client sends an Election frame. The client connects to a backup browser and obtains a browser list from which it selects a server to connect to.

The Browsing process occurs on each configured protocol independent of each other. Rather than have the browsing process duplicated it is best to minimise the protocols being used. Another way to minimise browser traffic is to disable the Server service on computers that are not required to share their resources, this minimises the number of entries in the browser list and it also reduces the number of browser announcements on the network.

When an IP client wants to resolve a TCP/IP host name such as teacher.exam.com into an IP address it sends a DNS query to a DNS server. If the server has the name in the database then it sends a response containing the IP address for the name. If the name does not exist then there is either a Name does not exist response or, if recursion is configured, the server forwards the request to another DNS server. If the second DNS server has the entry it responds to the first DNS server which in turn responds to the client. The standard UDP port for DNS is 53. You can setup the DNS server to query a WINS server so gaining the advantage of dynamic registrations as well as the static list in the DNS server. When a DNS server queries a WINS server, the WINS server always responds to the DNS server.

To increase the TTL for the cache start DNS Manager, select the zone and click Properties from the DNS menu. In the Zone Properties box click the SOA Record tab and modify the Minimum Default TTL. The TTL can be set for an individual record and also for the WINS records.

TCP port 80 is used for connecting to a Web server. The Web server's name is resolved first of all normally using a DNS lookup, then a session is setup using TCP port 80. The client then makes an HTTP GET request for a page on the server using port 1076. The Web server responds with the number of frames required to transfer the page plus graphic files etc. associated with the page. One page could involve a large number of GET commands and TCP sessions using different port numbers.

You can enable Windows NT Challenge/Response Security on IIS (off by default). With security enabled each initial request is responded to with a Status Code set to Unauthorised and the WWW-Authenticate field is set to NTLM for Windows NT Challenge/Response Security. The session terminates but another is set up and the client sends its unencoded information to the server. The server responds with an encryption key which the client uses and then sends back along with its encrypted authentication. The requested files are then downloaded.

Keep Web pages small and make sure that the client has a large cache locally to minimise network traffic.

Server to Server traffic

An approximate breakdown of Server to Server traffic is shown below:

Browser - 51%
Directory Services - 31%
WINS Replication - 8%
Trust Relationships - 5%
Directory Replication - 4%
DNS - 1%

Accounts are validated by either the BDC or the PDC but the PDC is the only one to make changes to the account database. Synchronisation occurs on three databases the Security Accounts Manager (SAM) accounts database, the SAM built-in database (containing the built-in groups) and the Local Security database (LSA) (containing the secrets used for the Trust relationships, account passwords and account policy settings).

The BDC finds the PDC by using a WINS query for Domainname <1B> and then when it receives the IP address it sends a Query for the Primary DC and the PDC responds with its own name as well as the domain name.

The next stage is the BDC establishes a session as described earlier then it establishes a secure channel using the following steps:

Create a named pipe open request to NetLogon so that API calls can be made to the NetLogon service.
Create an RPC connection between the two domain controllers using RPC bind and RPC bind acknowledgement frames.
The BDC issues a NetrServerReqChallenge to request verification that the BDC exists at the PDC.
The BDC uses a NetrServerAuthenticate2 call to verify its account password at the PDC.
Once verified the database verification proceeds.
Three RPC Client Call frames (NetrDatabaseDeltas) are issued to tell the PDC the serial numbers of the databases.
The PDC responds with three RPC Server Response frames.

The PDC verifies its 3 databases every 5 minutes and when it sees a change it notifies each BDC with an Announce Change to UAS or SAM to the NETLOGON mailslot. The BDC checks the version numbers and if the PDC version numbers are newer the BDC connects to IPC$ and establishes a secure channel (if it has been broken). Next a named pipe open request is made for NetLogon and an RPC session and the BDC uses the NetLogon Service to verify the account database. Then the updated data is transferred using SMB or RPC.

As well as the ReplicationGoverner parameter described earlier there are four other NetLogon parameters that can be used to optimise the network traffic:

Pulse - how often the PDC looks for changes in in its directory services database, the default being 5 minutes.
PulseMaximum - how often the PDC sends a pulse message to each BDC even if the databases are up to date, the default being two hours.
ChangeLogSize - controls the number of changes to the user accounts database before a full synchronisation occurs.
PulseConcurrency - controls the number of BDCs the PDC simultaneously sends announcements to when a synchronisation event occurs.

Establishing a trust takes the following steps:

The Trust is permitted
The trusting PDC determines the trusted PDC using WINS and NETLOGON queries.
TCP and NetBIOS sessions are set up with the PDC of the trusted domain and establishes SMB protocols.
The trusting PDC has a failed attempt at connecting to the IPC$ of the trusted PDC to check that the account has been created in the trusted domain.
The session is terminated.
The trusting PDC retrieves a list of backup browsers and servers in the trusted domain.
The trusting PDC connects to a domain controller in the trusted domain and retrieves the domain name of the trusted domain by performing various calls on the LSA of the trusted domain controller.
The trusting PDC updates its LSA database.
The trusting PDC queries the WINS for all the domain controllers of the trusted domain.
The trusting PDC logs on as a special account Interdomain Trust User Account and the trust has been established.

When accounts are added to a local group in the trusting domain from the trusted domain then traffic is generated as the trusting domain controller connects to the IPC$ of the trusted domain controller, queries the LSA and queries the SAM for a list of trusted accounts.

Validating the trusted domain user account takes the following steps:

The domain controller in the trusting domain must contact a domain controller in the trusted domain so TCP and NetBIOS sessions are established and the SMB protocols agreed.
A null session to IPC$ of the trusted domain controller.
The domain controller of the trusting domain establishes a named pipe session with the domain controller of the trusted domain.
Three API calls NetrServerReqChallenge, NetrServerAuthenticate2 and NetrLogonSamLogon using RPC are sent to the NetLogon service of the target server. The third API requests logon validation.

When a trust is already setup, pass-through authentication takes the following steps:

A NetrLogonSamLogon request initiates pass-through authentication.
Next a NetrLogonSamLogon request is sent from the trusting domain controller to the trusted domain controller.
The trusted domain controller responds with a NetrLogonSamLogon response which is then passed back to the client via the client's local domain controller.

Traffic can be minimised by adding appropriate users to a global group first and then adding the global group to the local group, rather than adding individual users to the local group. This is because the lookup for a SID for a global group is less network intensive than several SIDs (one for each user).

Any computer with a server component announces itself every 12 minutes so that it can be included in the browser list. A computer which has the potential to be a master browser sends a broadcast Announcement Request frame. A local master browser will respond to this with a Local Master Announcement if none exists then an election frame is broadcast. Eligible hosts respond with an Election Response and after 4 responses the host with the highest criteria wins and sends a Local Master Announcement to let the browser computers know that it is the master browser.

One of the roles of the domain master browser is to gather a list of other domains. To do this, every 15 minutes each master browser announces itself to all the other master browsers using a Workgroup Announcement frame directed to the NetBIOS name of <01><02>_MSBROWSE_<02><01>. If the receiving master browser checks its list and sees that it comes from a new domain it then adds the domain to its list. Another way of getting a list of domains is by the master browsers regular 12 minute contact with the WINS server and querying it for all registered domain names.

In TCP/IP network there is a master browser for each subnet in each domain. The browse list is retrieved from the domain master browser by master browsers every 12 minutes. The backup browsers then retrieve the browse list from their local master browsers using the same session setup process as a client retrieving a browse list from the backup browser.

As well as reducing services running and the number of protocols there are two parameters that can be adjusted to help optimise server browser traffic. These parameters are in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Browser\Parameters and are called MasterPeriodicity which uses a REG_DWORD to decide how often the master browser contacts the domain master browser, and BackupPeriodicity which specifies how frequently a backup browser contacts the master browser. The default for both these parameters is 720 seconds.

A single WINS server can support up to 10,000 clients but backup WINS servers are recommended as they offer backup and faster name resolution. Another WINS server is added as a Replication Partner in WINS Manager then the following steps occur:

TCP port 135 is used as the local WINS server establishes a session with the backup WINS server.
4 RPC frames initialise the WINS database.
A new TCP session is started and validation, request and response RPC frames are used to validate the credentials of the requesting WINS server.
A new TCP session using port 42 is set up to verify the partnership and request the initial replication.

Subsequent database record transfers use TCP port 42.

WINS replication partners can be configured as a Push partner or a Pull partner. Push partners send announcements to their partners when a specific number of database entries have changed (the default is 20). Pull partners request updates when notified by the push partner at configured intervals.

When Directory Replication takes place the Export server sends a notification every 5 minutes to all the import computers in its export list. Directory replication follows these steps:

The Export server uses the NetBIOS datagram service on UDP port 138 to broadcast that changes have occurred in it's export tree (share name REPL$).
The import computers make SMB connections to the REPL$ share.
The import computer checks that the computers clocks are within 10 minutes of each other with a NetrRemoteTOD call.
The import computer creates a file open to \Winreg and named pipe session to verify the export computer's registry parameters such as whether all files are to be replicated and when.
The directory is then verified by the import computer.
On the first time that replication occurs there is an additional step where the import computer queries the export tree to find the files.

A shallow export directory means less work for the replicator service. You can also lock certain directories from being replicated during busy parts of the day. This is achieved in Server Manager. Select Server Properties, Replication, under Export Directories choose Manage select the directory and Add Lock.

In HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Replicator\Parameters you can modify Interval to vary how often the export server checks for updates. The default is 5 minutes. The Pulse parameter controls how often an import computer contacts the export server for an update. The default value is 2 minutes.

In a DNS situation a zone is a database file that contains records for a particular domain. DNS server to server traffic is made up of zone transfers where a secondary zone server receives a copy of the database file from the primary name server.

The secondary name server queries the primary name server to see that it is active and to retrieve the parameters for zone database replication. The frame is a DNS query for Start of Authority (SOA).
The primary server responds with the parameters.
The secondary server then starts a TCP session on port 53 requesting a zone transfer by designating the Question Type field as Request for Zone Transfer.
The primary responds with the information.

In DNS Manager in the SOA Record tab the Zone Properties dialog box allows you to adjust the Refresh Interval (the amount of time the secondary waits before querying the primary - default 60 minutes), Retry Interval (the amount of time the secondary waits before retrying a zone transfer - default 10 minutes) and Expire Time (the amount of time that the secondary will continue to respond to name queries if it cannot connect to the primary).

Go to 27. Troubleshooting NT in the Enterprise

Home

Disclaimer