I just finished troubleshooting an issue where the link between a small workgroup switch and the switch upstream in the LDF kept going down. The workgroup switch was setup amongst a small group (10) of users and they'd basically reboot the switch when the issue occurred.
Manually setting the speed and duplex states on both switches resolved the issue. So, I've gotta ask doesn't this seem a little ridiculous to you? I mean, after all these years we're still having to manually configure these settings to maintain reliability on the switches? Seems pretty freak'in crazy to me...
Are you guys experiencing similar problems or was this an isolated case? I'm not hands-on with the gear as often as I used to be and would like your perspectives...
Flame on...Josh
Here we've seen some issues on cisco switches where the autodetect speed interface and duplex did not worked properly or caused some weird troubles ...
Alain
Alain,
Thanks for the comment. I've gotten into the habit of pretty much never using the auto-detect settings, but in this recent case I was a user on the network and ended up walking the local network admin through the issue and needed changes.
I guess I went on this rant because this has been a feature within switching technology for a long, long time to still be having these types of issues...
Josh
As far back as I can remember, if the device that was connecting to the switch supported hard coding the speed and duplex, I would set both ends up manually. Along with that, spanning-tree portfast on all end point devices unless there wasn't a need for STP then portfast on all switch ports.
Luis
We've been fighting this issue for years & there is still no simple solution. The issues arise when you control only one end of the link. This is most often the case with servers.
By hard-coding a link, you are assuming the end devices will never change (physically or settings).
Sadly this is not the case & often the device is reset back to defaults or replaced with newer hardware & a mismatch results. To combat this, (at least with server links), we have standardized on auto <-> auto. It is important to verify there are no FCS, collisions or CRC errors at install time.
This is also where Orion is very important in monitoring these links for errors & sending alerts when something changes.
After all these years, there is still no simple solution to this age old problem, which is exasperated by having unmanaged devices on the other end of the link.
We are still hardcoding most of our links. I think were like most companies now as well expanding into Blade servers and these cisco switches are a whole new beast, ie you have to set the IP addresses on the switches Via the web interface (IBMblades) even though you have IOS access to the switch. also with the bladedenters most of the servers ive run into are set to autonegotiate and none of the server admins have ever even went into the flowcontrol or other settings so we typically have to go and make recommendations there as well
We were and are experiencing a lot of these problems. Especially with Cisco devices (connections between routers and switches) and also on our network borders with our ISP's equipment.
As mention above it is best diagnosed with Orion, looking at packet errors. Resolving is often black magic with tries and misses (sometimes even the combination speed 100 and duplex auto works the best !?) ;->
Yes, Orion tells us of receive errors on a link and then we know... if the bandwidth utilization is not particularly high, it's the speed/duplex setting. If it's two Cisco boxes, cdp (syslog) will tell you. But usually for us it's servers connected to Cisco switches. This only seems to be an issue for us on fastethernet links, not gig. We hard set all of our fastethernet to full/100 and let gig autonegotiate... in the areas where we have control... -Debbi