I previously mentioned that with newer hardware autonegotiation might be the way to go. Here are some snippets from a discussion of this very issue by people more NIC-savvy than me. It should be noted that NWAY refers to the autonegotiation mechanism. Along with other information, this discussion caused me to look at autonegotiation of speed and duplex settings in a new light.
> but most people agree that auto-negotiation > (while being a good idea) is not the way to configure a reliable network. Oh no, they do not. Most people that really know this stuff actually agree that nway is usually the way to go, and if problems arise masking them is not the best solution. FOr instance, one of the well-known guys strongly supporting NWAY as the only real way to configure is Donald Becker, the guy writing almost all linux nic drivers. > What are (if any) the advantages or issues in choosing half or full duplex > on the server card connected to a 100mps switch and the workstation cards > connected at 100 mps as well. In my opinion you're better off setting both ends of the link to "auto" and let the NIC/switch negotiate. This is the only *correct* way to guarantee that a link will work. For a long time its been an unwritten "networking law" to always disable "auto-whatever" and force the settings, and while this may have been true for old networking gear (and is still definitely true for frame types!), its simply not the case anymore. Unless your gear is more than six years old, it should be able to negotiate the correct speed and duplex on its own. If you connect a server and switch port together with each set to auto and they *don't* negotiate a full duplex link, then you most likely have a wiring issue and forcing either or both ends to FD is only asking for trouble as it will mask the underlying problem. > Ive connected over 80 compaq servers into these switches, ranging from > single FD connections to 4 Dual port cards in a backup server. All these > were set to 100mb full duplex. The only time we had a problem was when a > server engineer left the server setting to autonegotiate. In that case you were plain lucky that it works in the combination 450T/your compaq cards, and it may fail without notice with the next update or different NIC you use. Let me explain: When two 100BaseTX devices get connected, they default to autonegotiation. First of all they try to detect if the other device does auto (NWAY) or not. By default, it would detect that, and now both devices will try to agree on the highest common speed. SO far, so good. What happens when you manually set one or both of the two devices is beyond any standard, and is completely up to the vendor. Basically, there are two possibilities, and both are equally used throughout the different vendors: a. The manually configured device still has nway enabled, but offers only the speed and duplex setting it's configured for. Some devices also offer the configured *and* lower settings. In that case, negotiation with a device that's still set for full autonegotiation could work. b. The device disables nway completely, and hardcoded simply tries to establish the LINK with it's configured setting. In that case, if the remote device is set to full autonegotiation, it *will* without a doubt fall back to half duplex, as it assumes a HUB is connected, which does not do NWAY. In case you set the fist device to FD in that case, you'll have a mismatch. THat's the worst case scenario, i.e. setting only one side manually to FD while leaving the other side set at auto. Now, if you have one side that uses a. from above, and the other device uses b., you're in trouble, *even* when both devices are set manually to FD. One of them possibly *regardless that you set it to FD*, fall back to HD as it doesn't detect a NWAY capable device on the other end. That's why I said the only guarantted working manual configuration is HD. Sure enough, FD *could* work depending on the devices in use, but it can stop working with the next driver, firmware or hardware revision. Simply put, the only guaranteed and standarized way to make full duplex work is autonegotiation. > It may not adhere to best practice or be the recommended way of doing > things, but with the 450T switches it works. Then they're broken and are not certified 100BaseTX devices. > Ive always been under the impression that autonegotiation was to be watched > carefully and not trusted in all ethernet network environments. No. Again, autonegotitaion is *the only* way to connect 100BaseTX devices according to the IEEE standard. Anything else means leaving the standard and can and does lead to unpredictable results. > So what works well with one setup, doesn't mean it will be the > same elsewhere with different equipment. This in itself is enough for us to > not rely on the technology. We have to keep the speed of the Networks at > top performance, as people's lives may depend on it (I'm not being dramatic, > we have systems installed in Operating Rooms in many hospitals). So if > there is even a remote possibility of a problem, we will avoid it by > "nailing" down the speed and duplex. This way we do not have to depend on a > added variable that we can not fully control. Well, actually you're simply lucky up to now because of your pretty closed environment. There is well known gear out there that even when manually configured to FD *will* fall back to HD anyways if it doesn't detect a NWAY capabale partner on the other side. As most gear disables NWAY completely when configured manually, you know what that means? It's simply impossible in such a configuration to manually configure FD. > Not all the "standards" out there are used, and the nway issue should be > boiled down to this. Try nway, if it works, great no further configuration > is necessary. If you have speed or data corruption issues, try "nailing" > the ports on the PCs, server(s) and switch(s). If the problems go away, > then use this configuration. And that's what I don't agree with in that generality. If nway doesn't work, there's something wrong, and that something is *not* nway. It's either cabling, broken gear, wrong settings and so on. Disabling nway is simply a method of masking existing problems that may well (and often do) come back at you later. In 60% of all cases it's bad cabling or signal interference. Personally, I prefer to solve problems instead of simply masking them. Okay, that's enough for now. That ought to spur some discussion! Regards, John Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=58927&t=58904 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
