Tuning NT server for an ISDN based Network
Digg
DZone
Reddit
Slashdot
StumbleUpon
del.icio.us
Facebook
FriendFeed
Furl
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:
- Indeed you can tune a NT server so that you can control server to server traffic
- The administrative effort for the administrators would be very large
- The lab-environment was too small to make predictions for a large scale network
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:
- Netlogon Service
- NetBIOS name resolution
- NetBIOS Browsing
- Printers
- Server Message Block (SMB)
- License management
- Domain Name System
- 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
