You are on page 1of 2

Auto-Negotiation Host/Switch/Router port communicates with other end of link to determine optimal duplex mode/speed Driver then dynamically

ly configs int to values determined for link Speed Rate of the int, usually in Mbps, though switches now support / !/ !! "bps Duplex How data flows# Half $ data can only be transmitted or received at a given time% &ull $ can send/receive simultaneously 'hat (uto)*egotiation does *+, do# when enabled, it D+-S *+, auto)determine config of port on other side then match it (uto)negotiation is a protocol and, like all protocols, it only works if it.s running on both sides of a link /f one side is auto)negotiating but the other isn.t, it cannot determine speed/duplex of other side /f running on both sides, the devices decide together best speed/duplex by advertising its speeds/duplexes at which it can operate Due to Parallel Detection, auto)negotiation 0ust seems to work, when really 1arallel Detection kicks in when auto)negotiation fails to find the protocol running on the other end% Parallel Detection sends the signal being received from the other side to the local 2base), drivers and, if any driver detects the signal, the int is set to that speed -x% /f int "i!/! on Switch ( receives a signal from &a!/! on Switch 3, "i!/! sends the signal to all of its drivers 4 !3ase),, !!3ase),, and !!!3ase),, and the !!3ase), driver recogni5es it and responds, setting "i!/! to !!Mbps6 7 Parallel Detection doesn't determine Duplex Mode because modes of Ethernet have differing levels of duplex support !3ase), 7 originally w/o &ull8 most don.t support !!3ase), 7 supports &ull, but default behavior is usually Half, re9uiring &ull manually set !!!3ase), 7 leave on auto)negotiation ! "ig 7 depend on fiber transceivers or special connectors different from R:);< hen Auto-Negotiating !ails 'hen auto)negotiating fails on !/ !! links, the most common cause is one side of the link was manually set to !!)&ull and the other side defaulted to (uto)*egotiate Results in Duplex Mismatch where the manually set side is !! &ull and, because !!3ase), usually defaults to Half, the auto)negotiate side is set to !! Half

/n above Half/Half, the receiving line 4R26 is always monitored so, if a frame is present on R2, no frames are transmitted out ,2 until R2 is clear /f a frame is received on R2 while ,2 is sending, a collision occurs, the counter increments, and the frame is re)sent after a randomly determined 3ack)+ff Delay

*ot a problem now, as -thernet was designed for a single wire, and switches and twisted pairs exist /n &ull, R2 line isn.t monitored and ,2 is always available, avoiding collisions via independent lines /f one side is in Half, collisions occur on the Half int because &ull sends without checking R2 line ,he reason the Half computer seems slow is because the R2 line rarely 4if ever6 frees up, allowing the ,2 line to send 1roblem won.t appear on &ull int8 only excessive collision counters on the Half int /f you see an int that is auto)negotiating to !!/Half, it means the other side was manually set to !!/&ull 'ith (uto)*egotiation not enabled on both sides, the !!/Half side will fail to (uto)*egotiate, switch to 1arallel Detection to figure out speed 4which it will figure out is !! from the !!/&ull side.s signal having been sent6, but because 1arallel Detection doesn.t handle Duplex Mode, the !!3ase), driver will default to Half =ould.ve been resolved by 0ust setting both sides to (uto)*egotiate =isco switches are set to (uto)*egotiate by default, but you can change Speed ,H-* Duplex "config-if#$speed %&& "config-if#$duplex full