At work I have Dell PowerConnect 3024 managed 10/100 switches. Currently I have a gigabit backbone at work connecting all of the switches. When I transfer files between machines however it runs at speeds slower than 10 mb. The switches have a spanning tree algorithm on them, but we have it turned off. Should this be turned on at all to improve speed? Does anyone know of any reason my network could be running so slowly? I don't think it is a bad NIC either because when I only have the servers attached to the switches the speed is still really slow. From what I know about spanning trees, it will find the quickest routes between machines cutting down on lag and transfer time. Could this spanning tree being off cause this problem that I am having?
-
We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.
10/100 Switch issues
- Thread starter Moonark
- Start date
The spanning-tree protocol can be an important mechanism in a switched/bridged network, since it works to eliminate the debilitating effects of topology loops, which, if left unchecked, can drop a network. With STP disabled, a loop in your topology could be causing this type of problem.
Are your gigabit links copper or fiber?
Are your gigabit links copper or fiber?
Spanning-tree is pretty important (well...ungodly important is more like it) in a switched network. I'd turn it on. If you did have a loop in your network spanning-tree would block ports to prevent it. without spanning tree frames just get endlessly forwarded and never die = net-no-worky. I can't see how spanning-tree would hurt or improve performance.
Check all links like server, client and inter-swith links for errors. You should have ZERO physical errors on full-duplex links. If you do then there is some kind of duplex mismatch or cabling problems (gigE requires cat5e or better). The duplex mismatches occur when you let the switch autonegotiate the speed/duplex and force the nic to something like 100/full. I'd recommend using autonegotiate on both sides, makes your life WAY easier.
hope this helps
ps - how are the switches connected to each other? Do the form a triangle or a line? A triangle would create a loop and spanning-tree would be required.
Check all links like server, client and inter-swith links for errors. You should have ZERO physical errors on full-duplex links. If you do then there is some kind of duplex mismatch or cabling problems (gigE requires cat5e or better). The duplex mismatches occur when you let the switch autonegotiate the speed/duplex and force the nic to something like 100/full. I'd recommend using autonegotiate on both sides, makes your life WAY easier.
hope this helps
ps - how are the switches connected to each other? Do the form a triangle or a line? A triangle would create a loop and spanning-tree would be required.
I have the main switches in the server room connected via cables on the back....I can't remember with the name of them are but they join 2 switches together... The others go off the Gigabit ports of the main units... the switches that branch off are only connected to the main and not to each other.
I'd check duplex settings. Sometimes ports set to autodetect don't "sync" up correctly and can cause the network to run very slowly. Try forcing the port and the nic to 100 full duplex and try the speed again.
Also, what kind of gigabit core switch do you have? Possibly the Dell 5012?? I'd run each of the 3024s to the core switch via your 1000BaseT ports. I'm assuming that
<< connected via cables on the back >>
means a stacking port or something, and that wouldn't provide you with the best possible performance.
Also, what kind of gigabit core switch do you have? Possibly the Dell 5012?? I'd run each of the 3024s to the core switch via your 1000BaseT ports. I'm assuming that
<< connected via cables on the back >>
means a stacking port or something, and that wouldn't provide you with the best possible performance.
The stacking ports usually combine the switches backplanes, so instead of 2-24 port units, you would have 1-48 port unit. In this situation you would only have 1 uplink to the core (unless you're doing a trunk), which would mean that the stack would have just the one link for 48 ports vs the link for 24 ports.
In general stacking bad.
They use proprietary signaling and are very difficult to troubleshoot. I've seen many a problem with cisco's "gigastack" aka "gigacrap" type connections as well as the Bay 450s. Don't know much about dell.
Here's something you could try - take the interswitch links out of the picture by doing your tests on a single switch. If the server is attached to switch one then attach a machine to switch one and test. Also enable spanning-tree, it is there to help. If you do have a loop then no amount of help on this board will ever help you find it. With spanning-tree you can find your loop.
They use proprietary signaling and are very difficult to troubleshoot. I've seen many a problem with cisco's "gigastack" aka "gigacrap" type connections as well as the Bay 450s. Don't know much about dell.
Here's something you could try - take the interswitch links out of the picture by doing your tests on a single switch. If the server is attached to switch one then attach a machine to switch one and test. Also enable spanning-tree, it is there to help. If you do have a loop then no amount of help on this board will ever help you find it. With spanning-tree you can find your loop.
I have a long shot for ya to check out......
Check your switch configs for "Flow Control." If you still have the manuals, check out the recommended roles for using flow control. In some of the old 3COM switches (for example), they would work fine for lower-traffic access switches, but if you aggregated the hierarchy into a port of the same switch, it decided there was too much traffic for a single workstation, and started "Flow Control" that all but shut down the port.
Once upon a time, I tested a newly-released switch (company shall remain nameless). In the first go-round, it tested so poorly, I thought the analyzer was broken (~90%+ packet drop under load). I verified the analyzer was working by running the smae tests on a known-good reference switch. SO....I called the manufacturer, gave 'em the bad news. They replicated the settings I used, and came up with the same results. In the follow-up phone call, they told me to set the Flow Control "ON" (and some other minor parms). I retested the same switch, with FC on, and it passed with zero packet drop and throughput was well within the expected range (very high).
Whichever your switch is set for, try the other setting.
Also check for code upgrades.
FWIW
Scott
Check your switch configs for "Flow Control." If you still have the manuals, check out the recommended roles for using flow control. In some of the old 3COM switches (for example), they would work fine for lower-traffic access switches, but if you aggregated the hierarchy into a port of the same switch, it decided there was too much traffic for a single workstation, and started "Flow Control" that all but shut down the port.
Once upon a time, I tested a newly-released switch (company shall remain nameless). In the first go-round, it tested so poorly, I thought the analyzer was broken (~90%+ packet drop under load). I verified the analyzer was working by running the smae tests on a known-good reference switch. SO....I called the manufacturer, gave 'em the bad news. They replicated the settings I used, and came up with the same results. In the follow-up phone call, they told me to set the Flow Control "ON" (and some other minor parms). I retested the same switch, with FC on, and it passed with zero packet drop and throughput was well within the expected range (very high).
Whichever your switch is set for, try the other setting.
Also check for code upgrades.
FWIW
Scott
Garion
Platinum Member
It does sound like a speed/duplex mismatch. If one is talking at half duplex and one at full, all kinds of enjoyable things can happen. Rule of thumb - If it's a server, HARD-SET IT! In fact, the more you can hard-set the better. If you can lock 'em all at 100Full, more power to you.
A few things to try:
Can you transfer at high speeds from server-to-server? Try and copy some files around via the console.
Can you transfer at high speeds between two workstations on the same switch? Try putting an FTP server on one or two and pulling some files around and see what you come up with.
Whenever you have performance problems you can typically isolate it to one part of the network - If server to server is fast and client-to-client is fast, then there's a problem between the client and the server, probably a broadcast storm eating your backplane and backbone. If one of those two tests is slow, then check the paramaters on the switch to make sure the port speeds are configured right.
As Spidey mentioned, STP is critical. It's far too easy for some yahoo to accidentally plug in both of the ports under their desk to the hub they aren't supposed to have down there. Voila, instant network outage.
- G
A few things to try:
Can you transfer at high speeds from server-to-server? Try and copy some files around via the console.
Can you transfer at high speeds between two workstations on the same switch? Try putting an FTP server on one or two and pulling some files around and see what you come up with.
Whenever you have performance problems you can typically isolate it to one part of the network - If server to server is fast and client-to-client is fast, then there's a problem between the client and the server, probably a broadcast storm eating your backplane and backbone. If one of those two tests is slow, then check the paramaters on the switch to make sure the port speeds are configured right.
As Spidey mentioned, STP is critical. It's far too easy for some yahoo to accidentally plug in both of the ports under their desk to the hub they aren't supposed to have down there. Voila, instant network outage.
- G
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes + WCL Discussion Threads
- Started by Tigerick
- Replies: 25K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 24K
-
-
