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=64950&t=64931 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
