Duplex negotiation problems info

Either your standard is to hardcode EVERYTHING or leave EVERYTHING Auto. Auto-negotiation did not work 100% when it first came out which is why a lot of places hard code the settings, but now it is not an issue any more. On a side note, the newer versions of Cisco hardware and software now support a setting of "speed auto, duplex full". This works great if your clients are configured for 100/Full and you want to migrate to auto/auto. With this setting, the switch basically will auto negotiate full duplex with the other end if it configured for auto, and default to full duplex is the other end is hard coded to 100/full. This setting is not supported on all hardware platforms, and only on the software release in the last few years, so you will need to test this before deployment.

Scott

Many people espouse hardcoding infrastructure and servers, and leaving desktops auto.

Unfortunately, it -is- still an issue. There are still autonegotiation failures, including some known to involve Cisco equipment. (e.g., I seem to recall mixing Cat6500 + some 3COM switches is a problem.) The failures these days -mostly- involve older equipment, but "older" might mean in terms of design rather than manufacturing date -- and there is still a lot of equipment in the field that was manufactured several years ago. Also, I read about autonegotiation failures involving some of the cheap consumer-level switches.

We hardcode both ends (switch and unit plugged into switch port) - on ports with servers and communications equipment.

We do not hardcode Desktop ports.

Walter said: :Unfortunately, it -is- still an issue. There are still autonegotiation

:failures, including some known to involve Cisco equipment. :(e.g., I seem to recall mixing Cat6500 + some 3COM switches is :a problem.) The failures these days -mostly- involve older equipment,

I am now working on the Auto/Auto at both ends scenario until it is proven not to work. So far at my present location I have had no cases where there has been an auto/Auto problem.

I believe (although I have no numbers) that in the environments in which I operate that there will be /far/ fewer errored packets if we go for Auto/Auto than if we try to use manual methods. The latter are known to me to produce a significant number of mismatched connections in practise and I cannot recall a single case ever from my own experience where Auto/Auto has failed.

I know that if I do a sh int right now I will see cases where there are mismatches since we do not micro manage PC moves and changes. Auto/Auto would fix that.

0 output errors, 0 collisions, 0 interface resets 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 output errors, 0 collisions, 0 interface resets 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 output errors, 0 collisions, 0 interface resets 25530 input errors, 617 CRC, 0 frame, 0 overrun, 0 ignored 0 output errors, 0 collisions, 0 interface resets 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 output errors, 0 collisions, 0 interface resets 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 output errors, 0 collisions, 0 interface resets 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 output errors, 0 collisions, 0 interface resets

There we go. Probably a duplex issue.

I'll have to say I agree with you. In my current environment we've chosen to hard code for all servers, and we have found various cases where the server administrator forgot to hard code and that server operated that way with many errors for months in that degraded state. I'm going to migrate us to an auto-neg solution for ease of management and less overall errors (even if caused by human error). I will be using the function previously mentioned so the switches will default to full/100mb when it can't negotiate. When you have an environment with

200 servers, and more than 1000 users, its a bit difficult to micromanage everything; and manually setting speed/duplex on that many devices can cause more problems than its worth with today's enhancements to auto-neg.

I have been working with Cisco gear for more than 12 years and I've only seen an auto neg problem once and that was probably 10 years ago, but I tend to work in pure Cisco environments - and from what I understand the auto-neg does not have any problems any longer in pure Cisco networks.

I had a Pix 525 running 7.0.4 fail to work correctly with hardcoded speed and duplex when connecting to a 10/100 interface 6500 blade. Both sides were hardcoded but the Pix decided to negotiate anyway. The Pix decided on 100/half (why 100 I'm not sure) and the 6500 used

100/full. OOW collisions like you can't imagine. In the end it was discovered that the onboard Ethernet ports of 500 series Pixs and the v7.0.4 code had a rather serious bug. The work around was to switch "inside" to one of the quad-enet cards in the chassis.

Hardcoding doesn't always work, as demonstrated above. Even with that little snafu (and others) I will continue to hardcode infrastructure ports. I'm not so worried about servers. I don't care about desktops. This method works for me in most cases.

J

The analysis of link speed does not use the link pulses that are used to determine duplex, so even when the duplexes are hardcoded mismatched, speed can still be negotiated.

It's surprising that the hardware or drivers are not more intelligent by now (the NWAY standard goes back to mid-90s)--after all the errors are obvious. You would expect drivers not to be configurable at all and see the message 'Please wait....negotiating best connection setting.....' The switch side might throw the towel in though and disable the port!

or set the switch ports to half duplex and have device set to auto. - but no full duplex unless you use the cases you list.

he has some Cat 5500s - old kit, no longer manufactured.

the other depressing fact is that anywhere with a fair amount of history probably still has some old kit that doesnt work with auto negotiate (or even some new stuff).