Actually, Fred, the problem is that some NICs will check for an autonegotiating partner even if they are hard coded, while other NICs do not. Newer Cisco switches completely disable autonegotiation if you hardset the speed and duplex, while many NIC manufacturers decided it was a great idea to still check for an autonegotiating partner regardless of speed/duplex setting. These NICs *will* fall back to half duplex if they do not detect autonegotiation on the wire. I've seen the documentation that proves this and I've seen it demonstrated almost daily for months now.
The problem arose when Cisco changed their switch behavior. The 2924XL used to behave the same way as most NICs do now. Even if you hard set the speed and duplex they would be friendly with other NICs that checked for autonegotiation. In other words, they still participated in autonegotiation but they only offered the speed and duplex they were configured for to the link partner. Newer Cisco switches do not do this. Nway (autonegotiation) is disabled completely if you hardset the speed and duplex. If you set the switch to 100/Full it will stay at 100/Full no matter what. If you subsequently attach certain NICs to that port and you hardset the NIC to 100/Full it will still check the link for an autonegotiating partner. When it doesn't detect one it makes the faulty assumption that full duplex is not possible and it falls back to half duplex. To make matters worse, most NICs don't report this. When you check their speed and duplex settings they'll still report 100/Full. Every 2950, 2948G, 2980G, and 6500 in our network behaves in the newer fashion, while probably 98% of the PC and server NICs in our network still check for the presence of Nway signalling. It took months of troubleshooting involving several people of different backgrounds in our department along with resources from Novell and Cisco to figure out what was going on, and the real answer actually came from responses I had on Usenet by people who really understood Nway and the fast ethernet standard. The only method for setting speed and duplex mentioned in the standard is the use of autonegotiation. The behavior of NICs when auto is not used is unspecified. There are basically two common behaviors among NICs when you disable autonegotiation and the real problems occur when you have a mix of NICs with different philosophies. John >>> "Reimer, Fred" 7/23/03 12:53:14 PM >>> "I never recommend hard-coding 100/Full on newer switches like the 2950 and 6500. It might work but you're just asking for problems. With the majority of the NICs in our PCs, if you hardset both sides to 100/full you will get a duplex mismatch when the PC NIC falls back to half duplex when autonegotiation fails. This behavior is relatively new, and was not present in the 2924XL, the forerunner of the 2950." I'd have to disagree with you there. If you hard-code a device it can't "fail" autonegotiation. The two are diametrically opposed. It's any oxymoron. Illogical to the nth degree. And this behavior is >notstay>> "Reimer, Fred" 7/23/03 12:31:16 PM >>> They don't happen to be autonegotiation issues, do they? Cisco used to have a nice write-up on autonegotiation troubleshooting and best practices that recommended hard-coding everything except for transient devices. Some crack-head at Cisco decided to update that recently and now I suppose their "official" stance is to use autonegotiation, ostensibly because they follow the standard correctly, so as long as everyone else does it should work! I have not met a Cisco engineer yet that agrees with that though. Hard-code your speed and duplex, unless it is for ports in an area like a conference room where you will have transient devices. Fred Reimer - CCNA Eclipsys Corporation, 200 Ashford Center North, Atlanta, GA 30338 Phone: 404-847-5177 Cell: 770-490-3071 Pager: 888-260-2050 NOTICE; This email contains confidential or proprietary information which may be legally privileged. It is intended only for the named recipient(s). If an addressing or transmission error has misdirected the email, please notify the author by replying to this message. If you are not the named recipient, you are not authorized to use, disclose, distribute, copy, print or rely on this email, and should immediately delete it from your computer. -----Original Message----- From: John Neiberger [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 23, 2003 12:58 PM To: [EMAIL PROTECTED] Subject: Catalyst 2950: The Spawn of the Devil? [7:72821] All those who consider any version of this platform beware. As far as I can tell there are no reliable software versions for this switch that do not suffer from connectivity bugs. We thought 12.1(13)EA1b solved our problems so we started rolling out this version. Upon reloading we have a number of users complaining and we're not able to resolve the connectivity issue. Granted, this particular problem is between the 2950 and an old NIC but I'm sure we're not the only company with a few older NICs in the network. If you're considering replacing existing switches with the 2950 prepare yourself for deluge of conenctivity problems. You have been warned! [Side note to Cisco: How hard is it to build an access switch that works?? We're on 12.1(13)EA1b and we still have BASIC connectivity bugs??? This is ridiculous. Bugs in the more obscure portions of the code are to be expected, but shouldn't the connectivity bugs be given a little higher priority? When we buy a new switch it would be nice if *all* of our end users could actually connect to the network. Maybe we'll go back to using Nortel switches. ] -- -- Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=72842&t=72821 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
