Issues connecting to an uplinked SG300-20

[williamcunningham]

I have the following setup:

1 SG300-20 with all our servers (about 6) set to L2 right now.

1 SG300-20 with all our workstations (about 12) set to L2 right now.

1 Procurve L3 switch/router with 2 VLANS (one for VOIP and one for LAN)

The bottom SG300 on the rack (with the servers) is connected to the Procurve (which is at the top of the rack) from its port 5 to the Procurve's port 25.  Port 26 on the Procurve is connected to our WAN (via a sonicwall firewall).  The DHCP and the DNS are all on this switch.

The SG300 above that has the workstations connected to it and is connected to the bottom SG300 with a cable from port 19 to port 20 on the SG300 with the servers (as mentioned above).

The Procurve has all the IP Phones connected to it.  As noted above, it's connected to the switch with the servers via its port 25 to the SG300's port 5.

I seem to have an issue with workstations on the SG300 with all the other workstations getting an IP address.  If I plug one with issues getting an address into either the ProCurve or the switch with the DHCP server on it, it grabs an address immediately.  But it either takes forever or never grabs one if connected to the SG300 with the workstations.

STP is turned on and set to auto in all cases.

Anyone else have this issue?  It seems to clear up/get better if I reboot for a while.  I'm also not seeing a great deal of CRC errors or packet errors.  All well within the 1 percent or less area.

Should I connect the Procurve to each switch and then remove the link between the two SG300's?  

Thanks for any help!

[jeffrrod]

Dear William,

Thank you for reaching the Small Business Support Community.

I would first suggest you to make sure you run the latest firmware release v.1.3.0.62;

http://software.cisco.com/download/release.html?mdfid=283019666&softwareid=282463181&release=1.1.2.0

I would then suggest you to make sure you enable "DHCP Relay" and "Option 82" on the IP Configuration>DHCP Relay settings page.  If "Option 82" is already enabled then disable it and test again.  Connecting both the SG300 to the Procurve would definitely fix the problem I would think.  I'll be looking forward to your reply.

Kind regards,

Jeffrey Rodriguez S. .:|:.:|:.
Cisco Customer Support Engineer

*Please rate the Post so other will know when an answer has been found.

[williamcunningham]

I updated the firmware after getting the switches a few weeks ago, so it's up to date. 

I just performed the following tests with no luck:

1) Enabled DHCP Relay and Option 82 on both switches and rebooted.  No change.  Systems connected to the problematic switch just sit at IDENTIFYING until they eventually return UNIDENTIFIED NETWORK.

2) Enabled DHCP Relay and Option 82 on only the switch connected to the Procurve, leaving the connection between the two switches as such:  port 19 to port 19 between them.  No change.

3) Removed connection between two switches and connected problematic switch directly to correct VLAN on ProCurve.  No change.

I'm wondering if this switch just isn't defective at this point. 

[williamcunningham]

I can uplink the two switches using a cat 5e between ports 17 through 20 successfully. I can also uplink between ports 1-16 on the problematic switch to ports 17 through 20 on the switch that isn't giving me trouble (and that is linked to the ProCurve). 

I reset the problematic swtich to default factory settings and let it get an IP from my DHCP server...which it did successfully with no problem.  I'm guessing this isn't actually a DHCP issue after all. 

I also tried replacing the problematic switch with an old netgear gigabit unmanaged switch and everything worked fine right away.

I'm leaning more towards a faulty switch.  But if anyone can see a reason why no workstation hooked to the problematic switch can successfully connect to the network, hanging at Identifying for a minute or two before returning with UNIDENTIFIED NETWORK, I'd certainly appreciate the advice.

[jeffrrod]

Dear William,

Just in case and double check on the switch performance and functionality, I also suggest you to contact the Small Business Support Center directly to narrow down this issue;

https://www.cisco.com/en/US/support/tsd_cisco_small_business_support_center_contacts.html

Please do not hesitate to reach me back if there is anything I may assist you with in the meantime.

Thanks for your time,

Jeffrey Rodriguez S. .:|:.:|:.
Cisco Customer Support Engineer

*Please rate the Post so other will know when an answer has been found.

[mpyhala]

William,

One way to know for sure if the switch or the configuration is the problem is to swap the configs on the switches and try using the bottom switch on the top. That would be equivalent to testing a new switch. If the switch still has issues when swapped with the other then it is very likely a hardware issue and we will replace it under warranty.

If you still have the same problem after swapping the hardware and configs then you should call support for assistance troubleshooting your network configuration.

- Marty

[williamcunningham]

Thanks folks.  I had the same thought about switching the switches, but I don't want to bring down developers that are on the primary switch.  I'll try to find some time to do off hours though.

[williamcunningham]

Received the replacement for the RMA'd SG300 this afternoon.  It's working much better than the one it's replacing.  Solid so far.  Only concern I have is that compared to the old, unmanaged switch I was using temporarily while awaiting the replacement SG300, the time to connect for clients is a bit slower still.  I went from connecting and getting an IP from the DHCP server in approximately 3 seconds to about 12 seconds.  Not something I'm terribly troubled by, just curious.  Is the overhead of this switch compared to an unmanaged one the culprit behind that delay?

[Tom Watts · Accepted solution]

Hi William, you can disable spanning tree or filter the BPDU or enable port fast manually on client ports which should speed that process up. It is port progression by spanning tree likely causing this delay.

-Tom
Please mark answered for helpful posts

[williamcunningham]

Thanks Tom, that's exactly what it is.  I double checked to make sure I didn't have any loops anywhere, then I disabled STP and it was back to 3 seconds or less.  I'll check into the port fast option.