Help! New Switch = IT Disaster

Hi, On a small Windows 2003 Domain with about a dozen XP Pro SP3 clients, I replaced a TP Link unmanaged 24 port GB switch with a Dell PowerConnect 2824 Web Managed switch. After installation I was able to log into our server, our firewall, the switch itself, and was working from a nearby workstation client. All seemed in order. The lights on the switch indicated good connections from those clients which had been moved to the new switch that I had not actually visited and checked.

This morning several workstations were unable to access the network. Each one indicated Limited or No connectivity, and assigned a private IP address, though the lights on the switch indicated a good connection. Long story short, I checked the switch configuration (where I had done nothing fancy but the interface showed up and active connections on the port with affected clients), cables, tested connections between office data ports and the wiring closet with a tester. After a couple of hours and still no clue what the problem was, I attempted to go back to the beginning and removed the new switch and reconnected the previous unmanaged switch. This caused no change in the situation.

Finally, I took a functioning workstation that was able to access the network and moved it to an office with a client that was unable to access the network. When the workstations were switched, the workstation was able to access the network. So that indicated the connection between the office and the wiring closet was good and the problem was with the workstation, as unlikely as that was under the circumstances.

I replaced the NIC in two of the affected workstations. No change. I ran "netsh int ip reset" on two of the workstations. No change. Everything has been rebooted at least once. Where do I go from here? I have replaced switches before and never run into any issues such as this. Initially I thought perhaps I had caused a surge on the LAN while connecting the new switch, but that appears not to be the case. All suggestions much appreciated. Thanks!
westoneAsked:
Who is Participating?
 
pony10usConnect With a Mentor Commented:
Are the offending workstations obtaining a valid IP address after doing the release/renew? If not then my next thought would be to look at the firewall log for any issues.
0
 
Craig BeckCommented:
Have you checked DHCP?
0
 
pony10usCommented:
You may also want to check the port based authentication.  

The Port Based Authentication page contains fields for configuring port based authentication and for enabling Guest VLANs. To open the Port Based Authentication page, click Switch / Network Security / Port Based Authentication.
0
Worried about phishing attacks?

90% of attacks start with a phish. It’s critical that IT admins and MSSPs have the right security in place to protect their end users from these phishing attacks. Check out our latest feature brief for tips and tricks to keep your employees off a hackers line!

 
westoneAuthor Commented:
Not specifically. DHCP is run on our firewall. All clients are set to automatically get network settings from DHCP, no static addressing. The functioning workstations appear to be getting their numbers okay, and can access the internet, meaning the firewall is available, where the DHCP server resides.

If a workstation is rebooted it refreshes its settings with the DHCP server, correct? Though if that's not the case, it would fit the circumstances: Leases run out at different times, and if DHCP is not available they are unable to access the network.

I just took a look in the firewall and see nothing out of the ordinary with the DHCP.
0
 
westoneAuthor Commented:
@ pony10us: The Dell PowerConnect switch is not connected to the network. I took it out of the loop and went back to the previous switch in the course of troubleshooting this problem. The power connect switch is out but the problem remains.

While still running the PowerConnect switch, I looked at the Port based authentication page, but did not set anything up there.
0
 
pony10usCommented:
On a workstation with the "problem" try doing a release/renew.

ipconfig /release

ipconfig /renew
0
 
westoneAuthor Commented:
Release & Renew, and Repair in the Network connections interface yielded no change.
0
 
Craig BeckConnect With a Mentor Commented:
Can you confirm the DHCP scope size is large enough for the number of clients you have?
0
 
westoneAuthor Commented:
No, the OS on the offending workstations is assigning a private address, such as when DHCP is not available. As mentioned previously, from the steps I have taken I am satisified that the physical connection between the office data port and the wiring closet is okay (as shown by installing another workstation without the problem in place of one with the problem, and the replacement workstation operates okay in that location).

I will look at the firewall log.
0
 
westoneAuthor Commented:
Okay, a look at the logs revealed the issue, which is exactly what craigbeck suggested as I was increasing the scope.

The pool of available addresses was more than adequate for what we have here, but far less than twice what is needed. The log was full of "No Available Leases" messages.

I thought the client was recognized by the MAC address of the NIC. Obviously the new switch triggered new leases for each client while existing ones remained in effect. What happened? Something about the new switch caused the clients to be seen as new clients by the firewall?
0
 
pony10usCommented:
What sounds like happened was during the swap of the switches the workstations were placed in what was considered a different subnet.  This could be caused by the configuration of the managed switch.

The DHCPNak message occurs when the IP address requested is not available or the client has been physically moved to a different subnet that requires a different IP address. After receiving a DHCPNak message, the client returns to the Initializing state and begins the lease process again.

If the lease expires or a DHCPNak message is received, the DHCP client must immediately discontinue using its current IP address. If this occurs, communication over TCP/IP stops until a new IP address is obtained by the client.

A good source for understanding DHCP is:  http://technet.microsoft.com/en-us/library/cc958935.aspx
0
 
westoneAuthor Commented:
Well, something along those lines happened. I had configured the switch with the same subnet, etc. before placing it on the network. Anyhow, Thanks for the help I had used up all my knowledge, and I learned something new.
0
 
Craig BeckCommented:
The clients weren't on a different VLAN - they were just on a new switch.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.