Priscilla Oppenheimer wrote:
>
> At 06:12 PM 4/13/01, Irwin Lazar wrote:
>
> >I know a few years ago several interface cards, especially those from
Intel,
> >had a heck of a time auto negotiating with Cisco Catalyst 5xxx's, but I'd
> >imagine these problems are resolved by now. (It shows you how long it has
> >been since I've actually touched a real network. :-) )
>
> Not much has changed! Auto-negotation seems to still be a disaster. We hear
> complaints about it not working all the time. Does anyone have a technical
> answer (or URL) that explains why it behaves so badly? Just trying to
> learn. Thanks......
>
I wouldn't go so far as to characterize it as a disaster, as it does
usually work. More specifically, speed almost always negotiates or
auto-senses correctly. And if it didn't, someone would investigate
immediately and correct it. Duplex negotiation is done after the speed
is set, and that sometimes incorrectly auto-negotiates. When that happens,
everything does work, but there will be a performance impact that is
totally dependent on the probability of simultaneous traffic in both
directions. Hence, a workstation with a single-tasking user may not
exhibit a symptom, while a server could be severely impacted. As others
have mentioned here in previous posts, look for "late collisions" on the
half-duplex side.
Some specific reasons I know of or have experienced that cause
autonegotiation to fail:
a) Older drivers for 10/100 NICs that just didn't do it right -- I ran
into this with the Compaq Netflex III. Updated driver solved it.
b) Early 10/100 NICs based on the National Semiconductor DP83840 chip
failed to negotiate duplex correctly, if the cable length was between
35-41 meters (a typical office length!). NatSemi corrected this flaw in
the DP83840A version, but all the existing products were stuck with this
limitation. Not only did this include some desktop NICs, but also
some early Cat5000 blades. See CCO bug IDs CSCdj53500 and CSCdj53272.
c) Say one side, the switch, is set for auto-negotiate, and the other
side, a desktop, is set to 10/half. Everything negotiates fine.
Now what if the desktop changes its setting on the fly to 100Mbps.
The 100Mbps fast link pulses produce enough signal in the frequency
band of the 10Mbps link pulses, such that the 10Mb side never sees a
loss of signal, so it doesn't realize there is a need to re-negotiate!
One way this happens is when the desktop O/S changes it while booting.
Even more subtle and less noticed is if the speed doesn't change but
the O/S changes the duplex.
The fix is to have the O/S driver momentarily drop signal whenever speed
or duplex are modified. I recall 3Com 3C905 PCI cards and their driver
producing this symptom. Workaround: pull the cable out/in or cycle the
port. See CCO bug ID CSCdk28412.
If anyone would like to read more than you want to know about
auto-negotation,
read http://www.scyld.com/expert/NWay.html, written by Bill Bunch of
National Semiconductor. NatSemi contributed the technique to 802.3u.
If you want to read about conformance testing, including auto-negotiation,
peruse:
http://www.iol.unh.edu/testsuites/fe/index.html at
http://www.iol.unh.edu/consortiums/fe/index.html
If you're into hardware chipsets, then follow the links at:
http://www.scyld.com/expert/100mbps.html
And as a great place to start on anything about Ethernet, Charles Spurgeon's
site at U. Texas is still great: http://wwwhost.ots.utexas.edu/ethernet/
Marty Adkins Email: [EMAIL PROTECTED]
Mentor Technologies Phone: 240-568-6526
133 National Business Pkwy WWW: http://www.mentortech.com
Annapolis Junction, MD 20701 Cisco CCIE #1289
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=659&t=515
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
