LAN / WAN Trouble

[skhips]

I am the "apprentice" in our IT department and am desperate to try and help the bigger boys at work solve a problem that has them baffled so if any can it will be greatly appreciated.

We are responsible for a small domain on a WAN that is made up of only

4 x Workstations, PDC, BDC in location A.
1 x Workstaion in location B.
Using NT 4, CISCO Routers and a 64kbit rented line.

In location A everyone is running fine, using DHCP, IP addresses are 100.11.*.* subnet mask is 255.255.0.0 (I believe this means we have Class B IP addresses). And DHCP is setup on PDC and BDC), we are using fibre on an Ethernet network.

To get to location B the data goes from the LAN onto a CISCO router, then a leased line, then a CISCO router in location B, back onto fibre (ethernet) and to the only workstaion at location B.

At location B a static IP address is been used 100.12.*.* Subnet mask 255.255.0.0.

THE PROBLEM: (At last you shout).

Log on and off at location B takes 3 minutes (way to slow!!)

(A logon script runs for the network drives, ok in location A but this seems to be one of the things running dead slow)

THINGS TRIED:

1. Dragged a large file from Location A which arrived within the expected time frame thus hopefully proving the line and bandwidth is ok.( Vey basic I know but seemed a quick and easy test for an approximate result).

2. Removed Workstation and router from loc B and installed at Loc A so that we were eliminating the line. Problem still there so not a line problem.

CONCERNS:

1. System was installed by contractors, no support available.
2. Allegdly the Loc B machine has to be static due to the routers, would it be a router issue to have the second octet as 12 as opposed to 11 like the rest of the network (or could of been purely for tidiness on a diagram).

Here goes my main thought that cooking at the moment,
IF the router needs to see the second octet in location B as 12 isnt a subnet mask of 255.255.0.0 masking the first and second octet out, if so would this cause some routing searching or delaying (jumping at straws here) problems and thus result in the log on being so slow but badwidth ok once connected.

Long winded sorry, I hopethe right info is there,

Many thanks for any help.

http://www.PCGuide.com/ubb/frown.gif

[mjc]

Not really a networking guru myself but that sounds like a possible explaination, also check for uneeded protocols on B. It really does sound like it is looking for something instead of finding it right off like it should.

Hang on I'm sure some of the more experienced network folks will show up and say I'm all wet...but hey, I don't mind...

------------------
mjc
Links list:Computer Links (http://www.dreamwater.org/tech/mjc/index.htm)

Celts are the men that heaven made mad, For all their battles are merry and their songs are all sad.

[Ghost_Hacker]

.....IF the router needs to see the second octet in location B as 12 isnt a subnet mask of 255.255.0.0 masking the first and second octet out, if so would this cause some routing searching or delaying (jumping at straws here) problems and thus result in the log on being so slow but badwidth ok once connected.


No,the subnet mask simply says what part of the IP address is the network address and what part is the host address. In your case 255.255.0.0 says that the first 2 octlets make up the network address. So 100.11.0.0 and 100.12.0.0 are 2 different networks. (As they should be.... they are located in 2 different locations serperated by a router at each end.)

I would ask have you connected the "problem" workstation to the network at location A? (using the IP information from location A and not the router from location B)What happened?

If I was troubleshooting your network some questions I would have asked myself is:

"why there is not a BDC at location B?"
"Do the 2 locations belong to 2 seperate domains?"
"Do you have any WINS servers on your network?"

Good luck http://www.PCGuide.com/ubb/smile.gif




[This message has been edited by Ghost_Hacker (edited 12-02-2001).]

[skhips]

It is one Domain. (This is also a concern is the second octet is different should it be on a different domain or should it still log on ok to the .11 server)

I believe Wins is enabled on the PDC and BDC.

It has been planned this way by external contractors.

Many thanks for your help so far, hope I can get to the bottom of this.

http://www.PCGuide.com/ubb/smile.gif

[Ghost_Hacker]

First,the best way to find out what is going on with the communications between location A and B is to run a network sniffer. "Etherreal" and "Windump" are both good,free network sniffers that can be ran on Windows. You would run the sniffer at both locations and when done the trace would show you the communications taking place between the two locations.

Second, since both locations belong to the same domain I would think about installing a BDC at location B. Then using the "setprfdc" tool from the NT resource kit to set the prefered domain controller for the workstation ( Or use an LMhost file with the "#PRE" option. Either of these methods will prevent the workstation from using the DCs from location A for network authentication .) However, Micorsoft recommends you use RRAS for domain controllers that replicate across slow WAN links. If you choose not to use RRAS take a look at the following information from Microsoft KB article Q207552.

"The ReplicationGovernor Parameter
You may need to reduce the value of the ReplicationGovernor parameter. This
parameter defines both the size of the data transferred on each call to the
PDC, and the frequency of those calls. For example, setting the
ReplicationGovernor parameter to 50% uses a 64-KB buffer rather than a
128-KB buffer, and has a replication call outstanding on the network only a
maximum of 50 percent of the time.

This entry should be changed only if replication occurs across a slow WAN.
Adjusting the ReplicationGovernor parameter does two things:
a.. Reduces the size of the buffer used on each call from the BDC to the
PDC, which ensures that a single call does not occupy the WAN link for too
long.


b.. Causes Netlogon essentially to "sleep" between calls, which allows
other programs to gain access to the WAN link between calls to the PDC.


You can add the ReplicationGovernor parameter to a BDC using the following
registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Netlogon\Parameters
ReplicationGovernor: REG_DWORD
Range: 0-100 percent
Default: 100
NOTE: This parameter must be set individually on each BDC.

Do not set the ReplicationGovernor parameter too low, or replication may
never complete. A value of 0 causes Netlogon to never replicate, and the
Security Accounts Manager (SAM)/Local Security Authority (LSA) database
become completely out of synchronization.

It is also possible to configure different replication rates that are
dependent on the time of day using a script file with the AT command (for
example, NET STOP NETLOGON, REGINI SCRIPTFILE, NET START NETLOGON). The
script file should contain the path to the ReplicationGovernor parameter and
the new registry entries. Regini.exe is part of the Windows NT Resource Kit.

For additional information, please see the following articles in the
Microsoft Knowledge Base:
Q142692 Minimizing WAN Traffic
Q140422 Domain Synchronization Over a Slow WAN Link
Q140552 How to Optimize Windows NT to Run Over Slow WAN Links w/TCP/IP"


As things are now if the WAN link goes down you'll not be able to login to the network domain from location B as there will be no domain controller available there. I also belive that your slow login is directly attributed to the fact that authenication takes place across a WAN link.( which is why I asked if you had tested the workstation by simply "hooking" it up to the network at location A.) However, I don't know how your login scripts are written nor if your using roaming profiles both of which can play a factor.


Hope this helps some. You will have a better idea what is causing your problem after you run the sniffers.

Good luck http://www.PCGuide.com/ubb/smile.gif


EDIT: It is one Domain. (This is also a concern is the second octet is different should it be on a different domain or should it still log on ok to the .11 server)......


That is an option, but it should also work with different subnets belonging to one domain. Again I would suggest an extra BDC at location B.



[This message has been edited by Ghost_Hacker (edited 12-03-2001).]