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
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.
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
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.
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
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
- 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
- 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
- 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
- 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
- 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.
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
- 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).