I have a Cisco SG200-26, and it appears to cause random network problems like timeouts, etc. Error logs on the switch do not indicate any problems.

I replaced the switch with a different switch, and the network problems no longer happen. I'd like to extensively test the switch in a way which would really put a big load on all the ports without the need to use 26 computers to flood the switch.

I was thinking about using VLANs to create small LAN segments, connecting them with patch cables in daisy chains, and putting one computer on port 1 with a second computer on port 26. I would then copy a big file between the two computers to see how it goes. I don't know how to setup switch ports and VLANs to make it work. Maybe it is not possible to do; you tell me.

To explain in detail, I would set ports 1 and 2 as VLAN 10, connect a computer on port 1, connect a patch cable between ports 2 and 3, which would be VLAN 11. Port 4 would also be VLAN 11, and would be patched to port 5 in VLAN 12. Port 6, also VLAN 12 would be patched to port 7 in VLAN 13... and so on until we reach port 26, where we have the second computer.

I hope that such a setup will make the traffic between ports 1 and 26 to go through all the ports in between. How should I do it, and, in case it can't be done, please explain why it can't be done. Thank you.

  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can post and accept your own answer. – Ron Maupin Jan 5 at 3:03

Judging by your switch, I'd say you don't have the budget for a real ethernet tester like those from Fluke Networks.

Your switch is Layer 2 (L2) only and doesn't support routing, so you'd need an external router (L3) to move packets between the VLANs. I would conjecture that your random network issues were caused by either bad cabling or mismatch on speed/duplex between the switch and your systems.

You can look at using iperf configured on a server, and then have each of your client computers run a test from their respective ports to the server (one at a time), then look for interface error counters being incremented to help isolate any issues or misconfiguration.

  • 2
    From the text he's planning on bridging vlans together with access ports, so there would be a planned 'native vlan mismatch'. There shouldn't be any routing required for this test. iperf is a good suggestion though. – cpt_fink Jun 16 '15 at 3:45

There are a few problems with your premise.

First, connecting switch ports to switch ports will either end up disabling the switch ports or causing a spanning-tree loop. Switches send BPDUs to determine the switch topology. Properly configured switches will have the access ports set to portfast and bpduguard. This configuration will disable the ports in order to prevent spanning-tree loops.

As suggested by @generalnetworkerror, bad cabling or duplex mismatch are good places to investigate. Be sure to clear the counters, test the switch with some sort of traffic generator(s) on the original cabling, then look at the individual interface counters.

It is also very possible that you have one of the counterfeit Cisco products that are far more pervasive than anyone wants to believe. It doesn't matter that you bought this switch as new from a reputable Cisco dealer since these fakes have found their way far deeper into the distribution pipeline than anyone will admit. The counterfeiters have done a very good job at copying all the telltales, including the chip stamps and holograms. Many counterfeit devices are out in production networks, running things just fine, but some cause these sorts of problems until they are sent back to Cisco for warranty work, where they are discovered as fakes.


Networking equipment is not typically stress tested for throughput by end users, rather POST test are done. Power On Self Test, or burn in's are done. Basically, you plug in the power supplies and let the things run for 24 or 48 hours. Interface hw errors typically show themselves immediately upon install. If there are problems with non-power related hardware, the device will typically simply not function properly. Most hardware problems are from shipping and most gear is stress tested for throughput at the manufacturing stage.

Software can have issues such as memory leaks and bugs which are typically known and documented, provided that you are not running bleeding edge code.

So, try and run tried and tested code and POST test your gear. That's what I have seen done in practice.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.