How to restart network services without restarting the server

networkingwindows-server-2008-r2

I've been an IT professional for county government over 2 1/2 years and this problem has occurred 3 times. I can fix it by restarting the primary server, but I would like to fix it without having to take that route. Here's the situation. On our primary server (from here on out called Server1) we have software running called Springbrook (fund accounting and utility billing enterprise software). The users access Springbrook via mapped drives to Server1. I place shortcut on their desktops that pulls the software from the mapped drive. Sometimes, I don't know why, 3 or more users lose access to Server1, which causes them to lose access to Springbrook. The rest of us can still access Server1. By losing access to Server1 I mean PC A cannot ping, RD to, or access shares on Server1. Ping tells me the remote host is unreachable, RD gives the same message, and when I try to explore the mapped drive the message tells me the network path is not available. If I restart Server1 then those 3 users can suddenly access Server1 again.

I assume the only thing happening is that a network service is restarting, but I don't know if it's the NetLogon service, an AD service, or it may be something else I'm not aware of. Restarting the users' PCs doesn't solve the problem. Nor does rejoining the PC to the domain fix the issue; it's always restarting Server1 that fixes the issue.

This doesn't happen often. Like I said, in the 2 1/2 years I've been here it's happened 3 times. Out of those 3 times it hasn't been the same PCs either. I would like to know how to prevent it or at least how to fix it without restarting the server completely.

AD domain. Windows Server 2008 R2 server. Sonicwall TZ210 firewall. Netgear 24 port gig switch. PCs hook into Netgear gig 5 port switches.

Thanks.

EDIT: Thanks for the answers so far. Poor question writing on my part. I failed to mention that the affected PCs can communicate with other PCs on the network, even Server2 (we have to DCs). Server1 can't ping to the affected PCs either.

Best Answer

I found the answer to the problem! For this year anyway. :)

The problem occurred again yesterday morning and at lunch, but this time it was just one PC that wasn't in the affected group last week. During the problem I did the following:

Restarted the switch in her department - didn't work.
Enabled then disabled her network adapter and the server adapter - didn't work
Updated the driver on her PC this did work for the morning.

The monster reared its ugly head again at lunch.

Went to the server, collected wireshark packets between the affected PC and the server. Then, I restarted the server because I know that works. That fixed the issue. I was only able to read through the collected data for a few minutes because other issues came up (I'm the only IT pro - one man crew) that occupied my time for the rest of the shift. Thought about it through the night. Came in this morning, collected network traffic just to see if there were any network process hogs and couldn't find anything bloating the "pipe." Then it hit me: check the kaspersky logs on the server. I checked the network attack blocker logs and found that last week Kaspersky detected dos.generic.synflood "attacks" from the 3 affected machines last week and the affected machine yesterday. When Kaspersky detects things like that, it will cut off communication with the attacking node for 60 minutes. The logs gave the exact time of the issue and the time matched up with the time affected users called me about the issue. I tracked the logs back 30 days and noticed those logs were clean of attacks.

I set the network attack blocker to only block the attacking node for 1 minute. I'm also going to investigate what the synflood attacks could be. At least for now I know why those machines were disconnected from the server. Of course now, I need to figure out the source of those dos.generic.synflood attacks.

Related Solutions

Linux – How to get linux to honor new netmask without hard restart of networking subsystem

First things first, do not use ifconfig and route. These commands are generally regarded as obsolete today; they were written too long ago when Linux had a very different network stack, and have been patched ever since. The very idea of interface aliases (e.g. ethX:YY) in order to have multiple addresses is obsolete today, they still exist mostly to please ifconfig itself. Today, the ip command should satisfy all your needs.

Now, understand your original situation: Your eth0 interface originally had two active scopes: /24 and /27. 172.16.45.3 was the primary address for the /24 scope, while 172.16.45.21 was the primary address for the /27 scope (because it is listed first). When you issued the ifconfig command to change the prefix of the first address, it deleted it and reinserted it as a secondary address in the /27 scope. So now you should have something like this:

inet 172.16.45.21/27 brd 172.16.45.31 primary   eth0:11
inet 172.16.45.22/27 brd 172.16.45.31 secondary eth0:12
inet 172.16.45.3/27  brd 172.16.45.31 secondary eth0

It doesn't matter that eth0 should be primary, or that it looks like it should be primary (another reason not to use ifconfig). It was inserted latter in the /27 scope, so it is a secondary address. This also means that outbound packets will be addressed 172.16.45.21, and that if you bring eth0:11 down using ifconfig, all your addresses will be taken down together. This is how it works.

The only way to fix this is to remove all addresses from the interface and reinsert them in the correct order. Then, the first address added (in the /27 scope) will be the primary address in that scope, and further addresses will all be secondaries.

The addressing was already broken from the beginning, there wasn't much you could do in this situation. Your best solution is to just restart the network service.

One possible workaround is to change the source routing address. This will have almost the same effect of changing the primary address. In your case:

ip route change 172.16.45.0/27 dev eth0 src 172.16.45.3

In this case, packets going to 172.16.45.0/27 will have the source address set to 172.16.45.3. You will need another command if you also want to change the source of packets passing through the gateway.

1 Year DHCP Lease

Technically there is nothing wrong with this lease time, especially if in the school the computers and devices on the network rarely change. However, the general rule of thumb is that your leases should be long enough to reduced network bandwidth and server load in the event that you have a large amount of devices who could potentially need leases.

So technically, no there is nothing wrong with this, the system is designed to support it, but from a usability and maintenance viewpoint it may get to be confusing and hard to maintain if you have to eventually go in an kill old leases when machines come or go. Especially if you want to make any network changes within a year as well.

In the past I have typically stuck to lease times of about a day but no more than a week. It really isn't that much load and a properly loaded DHCP server or servers should be able to handle that load just fine.

Best Answer

Related Solutions

Linux – How to get linux to honor new netmask without hard restart of networking subsystem

1 Year DHCP Lease

Related Topic