Tuning NT server for an ISDN based Network

By ServerWatch Staff (Send Email)
Posted Dec 10, 2000


Bart Teunis

Abstract
As one of our costumers changed from NT 3.5x to NT 4.0, they also changed from leased lines to an ISDN based network. The costumer realized that this wasn't a good switch after all but the decision was made based on the cost consequence. On the secondhand they realized that if they implement NT straightforward without any changed to the OS that it could turn out to an expensive solution. So they dropped the question if it was possible to tune the NT servers so that they can control the server tot server communication. We decided for a more or less scientific approach, first literature research and than the fieldwork. It was not very hard to find related articles on this case, but what we saw was that a lot of literature spoke of ISDN modems instead of using ISDN routers, which give more functionality to control your traffic. But we saw possibilities and took our knowledge to the lab. The first thing we did at the lab was verifying the literature values and by reproducing them we started to tune the NT servers. After a few weeks of measurements we came to the following conclusions:

  1. Indeed you can tune a NT server so that you can control server to server traffic
  2. The administrative effort for the administrators would be very large
  3. The lab-environment was too small to make predictions for a large scale network
As one of our costumers changed from NT 3.5x to NT 4.0, they also changed from leased lines to an ISDN based network. The costumer realized that this wasn't a good switch after all but the decision was made based on the cost consequence. On the secondhand they realized that if they implement NT straightforward without any changed to the OS that it could turn out to an expensive solution. So they dropped the question if it was possible to tune the NT servers so that they can control the server tot server communication.

We gave the advice to scale up the lab-environment so that it was better possible to make a prediction of the behavior in a large-scale environment. Further we gave an only recommendation for values of the parameters that should be changed, which was based on our findings that the lab-environment was to small.

Problem definition
By changing to an ISDN network the customer faced the challenge to tune his NT servers so that they where in control of the server-to-server traffic. The choice was made for a single domain structure, so there will be a lot of server-to-server traffic. The question was which parameters had to be changed to get in control of this kind of traffic. Literature: In the literature we found the following items where responsible for server-to-server traffic:

  1. Netlogon Service
  2. NetBIOS name resolution
  3. NetBIOS Browsing
  4. Printers
  5. Server Message Block (SMB)
  6. License management
  7. Domain Name System
  8. Directory Replication

Due to the implementation there where several items we could keep out of the scope of this research. This where the following items:

- Printers, because every geographical location has it's own printer that could not be shared over several geographical locations.
- License Management , there where no applications installed on the servers.
- DNS, there was only one DNS server available for the total network

Knowing this, we focused mainly on the other five items. Found registry settings and parameters:

1 Netlogon service:
Reg. Setting: HKLM\services\CurrentControlSet\Netlogon\parameters
Parameters:
- ChangeLogSize
- Pulse
- PulseConcurrency
- PulseMaximum
- PulseTimeout1
- PulseTimeout2
- ReplicatorGoverner
- DisablePasswordChange - ExpectedDailupDelay1

2 NetBIOS Name Resolution
Reg. Setting HKLM\System\CurrentControlSet\Services\NetBT\parameters\NodeType
Parameters:
- B-node
- P-node
- M-node
- H-node

3 NetBIOS Browsing
Reg. Setting HKLM\System\CurrentControlSet\Services\Browser\Parameters
Parameters:
- MasterPeriodicity
- BackupPeriodicity

4 Server Message Block (SMB)
Reg. Settings HKLM\CurrentControlSet\Services\LanmanWorkstation\Parameters
Parameters:
- KeepConn

5 Directory Replication
Reg. Settings HKLM\System\CurrentControlSet\Services\Replicator\Parameters
Parameters:
- Interval
- Pulse

So with this knowledge we went to the lab for further investigations.

The lab
At our lab we worked with the following setup:



For analyzing our traffic we used :

  • MS SMS networking monitor (network sniffer, software based)
  • HP Internet Advisor (network sniffer, hardware based)

We used both the tools, we used the HP device for quantitative analysis and the SMS tool for the qualitative analysis. The samples were taken for an hour and during the hour we ran several actions scripts. After the hour we stopped our measurement and did our analysis. During this analysis we looked for the following points:

  • What's the kind of traffic
  • What is causing this traffic
  • Is this client-server (LAN traffic ) or server - server (WAN traffic)
  • Does this traffic meet our expectations

What we found
We could find a lot of data in the literature, but what we saw there was that a lot data was generated with a build-in dial up adapter, because we used ISDN based routers half of data we found was not of use. In this article we gave the data, which was of use for our investigation. We could replicate the data found in the literature and we were able to go on with our investigation. Further on we saw a lot of traffic between the two routers, by closer investigation it turned out to be CDP (Cisco Discovery Protocol) traffic. The two routers use this protocol to exchange information. The problem is that when there is a serial line between the two routers, the cost of the traffic is zero and the routers will exchange traffic unlimited. When we could change it into a ISDN connection the cost will raise and the routers will stop exchange the unlimited traffic. So in further measurements we filtered the data for CDP. We found out that the following services were the source of traffic in our situation:

  • NetBIOS browsing
  • Directory Replication
  • Server Message Block
  • Netlogon Service

So to tune the network the settings for these services have to be changed. A few other services used broadcasts for there information exchange but they are not important because we use routers, which are closed for broadcast.

Conclusion
Yes it is possible to use ISDN as transport protocol, but you have to make several changes in the default NT installation. From the lab results we weren't able to gave the proper values because this was a one to one situation and not a one to many, which is the real situation. Further research is needed to get the real values for such a network.

Acknowledgements
The author likes to thank

Tom Greeve at Riser Business Systems, Rotterdam, The Netherlands
Bart Peters Datelnet group NV, 's Hertogenbosch The Netherlands
Jos Kauling, Aad Weesenaar and Robert Dobbelaer at TPG, Den Haag The Netherlands

Page 1 of 1


Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.