Elijah Savage wrote: > > I have been trying to follow this, and I still do not see why > we should > get away from the old Cisco switch courses that if you set both > sides to > 100 full duplex if they are capable you will be fine. I have > not seen > any situation where hard setting both sides caused problems (am > I > missing something?). Question I ask is why even fool with the > unpredictable auto negotiate.
Setting both sides manually to 100 full works (as long as you don't have Cat 3 cabling), but it's not a maintainable solution. Say you get laid off (heaven forbid) without a chance to document your procedures. Your replacement, fresh out of the newer Cisco courses, has the job of replacing a NIC in a workstation or server. She doesn't set the speed and duplex manually, since there *should* be no need. The switch is set to manual. This means, as John has said, that it may not participate in autonegotiation. Why should it? It knows what it should be since you manually configured it. The behavior is undefined in the specs, but that would be OK behavior and is something we see in the real world. The new NIC doesn't see any autonegotiation going on and decides that the device at the other end must be so old that it doesn't support autonegotiation and, in fact, if it's that old, it must be 10 half. The NIC sets itself to 10 half. You have a mismatch. Priscilla > > Someone help me out here what am I missing. > > -----Original Message----- > From: John Neiberger [mailto:[EMAIL PROTECTED] > Sent: Monday, March 10, 2003 2:59 PM > To: [EMAIL PROTECTED] > Subject: Re: 10 half or 100 full [7:64931] > > The problem is that neither behavior is proper! :-) The only > method > mentioned in the standard is autonegotiation. Any other > setting, > including > manually setting the speed and duplex, is non-standard and > undefined. > > I'm not aware of the frame-level details of Nway negotiation so > I'm not > sure > what you'd need specifically to see the traffic but it would > probably > have > to be some sort of transparent device that sits between the NIC > and the > switch. > > >>> Scott Roberts 3/10/03 12:31:46 PM >>> > I see what you're saying now. what would be nice to see is what > traffic > there is on a protocol analyzer. I would think that #2 should > be the > situation and your #1 is not the proper negotiation. > > I've never tried to cpature auttonegotiation with an analyzer > before, I > wonder if you can even capture that stuff? > > scott > > ""John Neiberger"" wrote in message > news:[EMAIL PROTECTED] > > No, that's not at all what I was referring to. I'm speaking > of the > behavior > > of switch interfaces when they're set to AUTO. Nortel > switches (at > least > > the ones that we used) and some older Cisco switches like the > 2924XL > seemed > > to behave like Option #1 below, while the 2950 behaves like > Option #2. > > > > If both the switch and the device are using Option #1 you'll > be fine. > If > you > > then upgrade to a Catalyst 2950 that uses Option #2, you'll > have all > sorts > > of issues that need to be resolved. > > > > We've had a mixture of 2924XL and Bay 303/310 switches at our > branchse > for > > quite a while with no issues. When we started replacing the > Bays with > > Catalyst 2950s we started having all sorts of problems, and > it took > quite > a > > bit of research into FastEthernet NWAY/Autonegotiation to > determine > the > > problem. > > > > Just a forewarning. :-) > > > > >>> Scott Roberts 3/10/03 12:12:48 PM >>> > > if I understand what you're saying, I think its always been > like that, > cisco > > hasn't changed it. > > > > you're refering to the fact that the IOS switch don't let you > change > the > > speed? I think thats strange also, the set based switch can > allow you > to > > change speed, but after the IOS "upgrading" of switches they > don't > allow > you > > to change a 10/100 at the switch, but rather require you to > configure > the > > desktop to 10 or 100 speed manually. > > > > I suppose the idea is that everyone should be using > autonegotiation > > according to cisco. > > > > scott > > > > ""John Neiberger"" wrote in message > > news:[EMAIL PROTECTED] > > > I wanted to mention that we've been in the process of > upgrading our > > > switches, as well, and I discovered that since we've > started using > the > new > > > Cisco switches we've been having all sorts of problems > getting the > speed > > and > > > duplex settings set correctly. > > > > > > We've discovered that if you have relatively new NICs with > updated > > drivers, > > > set both sides to AUTO. Never, ever, set only one side to > AUTO. I'd > also > > > avoid manually configuring the speed and duplex unless you > have to > do so > > to > > > fix a specific problem. Here's why: > > > > > > There is no standardized behavior for 100BaseTX when you > manually > > configure > > > settings! The only setting mentioned in the specification > is AUTO; > the > > > behavior of the NIC with any other setting is up to the > vendor and > not > > > everyone handles it the same way. Cisco appears to have > changed the > way > > > they handle it, which is the cause of a lot of our problems. > > > > > > If you hard-set the speed and duplex there are two ways to > handle > this: > > > > > > 1. Use the configured settings and still participate in > autonegotiation > > > only offering the configured settings. > > > > > > 2. Use the configured settings and do not participate in > autonegotiation > > > > > > Cisco's new switches seem to use option #2, while a great > number of > our > > end > > > devices use option #1. Why is this a problem? Here's what > happens > when > > you > > > connection an option #1 device to an option #2 device: > > > > > > #1 participates in autonegotiation, only offer the > configured > settings. > > > #2 does not participate in autonegotiation at all and will > forcefully > use > > > the configured settings. > > > #1, seeing that there's nothing on the other side using > auto assumes > it > is > > > connected to a HUB, and just might set itself to 10/Half > regardless > of > the > > > manually configured settings! > > > > > > As you can guess, this is bad mojo. The moral of the story > is that > you > > > should try to start using AUTO on BOTH sides if you're > using newer > Cisco > > > switches, in particular the 2950 series. In some cases > this won't > work > > and > > > you'll have to resort to manual settings. > > > > > > HTH, > > > John > > > > > > > > > >>> Priscilla Oppenheimer 3/10/03 10:58:56 AM >>> > > > Mike Momb wrote: > > > > > > > > To all, > > > > > > > > We recently replaced our Nortel switches and routers with > Cisco > > > > 2980 switches and 6509 routers. We have two buildings, 10 > > > > floors each and a router in each building. We have a > > > > combination of NT and Novell servers. After replacing > all > > > > this equipment, we have noticed that when we access files > on > > > > the NT servers, the speed is acceptable. When we access > files > > > > on the Novell servers, it is very very slow. Could the > > > > switches or routers be configured incorrectly for IPX. Is > > > > there something that we can change. On Cisco's web page > it > > > > mentioned something about enabling ipx > > > > broadcast-fastswitching. Any input or comments would be > > > > appreciated. > > > > > > I doubt that ipx broadcast-fastswitching will help you > unless you > are > > using > > > an ipx helper-address. With ipx helper-address (just like ip > > helper-address) > > > you can tell a router to forward a broadcast, which it > normally > doesn't > > do. > > > This would be useful for some rare IPX application that sent > broadcasts > > that > > > needed to reach the other side of the router. In typical IPX > networks, > > > there's no such need. When there is a need, you can speed > it up with > the > > ipx > > > broadcast-fastswitching command. > > > > > > You titled your message "10 half or 100 full." I think this > was a > Freudian > > > slip. I bet your problem is related to a full-duplex > mismatch. > Perhaps > the > > > NICs in the NT servers negotiated correctly but the NICs in > the > Novell > > > servers did not and you have a mismatch. > > > > > > With a mismatch, the full duplex side will send whenever it > wants. > The > > half > > > duplex will get upset if it sees the other side sending > while it is > also > > > sending and will backoff and retransmist, leaving behind a > CRC-errored > > runt. > > > That side will reports a collision. The other side will > report runts > and > > CRC > > > errors. > > > > > > So, look for lots of Ethernet errors when you do a show int > or show > port. > > > > > > Also feel free to send us the output of various show > commands and > your > > > router config. There are some IPX gurus on this list. > > > > > > _______________________________ > > > > > > Priscilla Oppenheimer > > > www.troubleshootingnetworks.com > > > www.priscilla.com > > > > > > > > > > > > > > > > > thanks > > > > Mike > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=65070&t=64931 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
