On ten handshake není úplně triviální a historicky se vyvíjel, cca ruku v ruce s vývojem rychlostí metalického ethernetu. Docela
v kostce je to popsané na wikipedii, ačkoli mi to heslo přijde maličko nepřehledné, asi jak ho postupně upravovalo víc lidí. Odkazy na normu 802.3 a další čtení tam jsou. A je tam napsáno, že v počátečních verzích normy toho autoneg handshaku bylo možno interpretovat některé věci různě, takže konkrétně Cisco nebylo s některými dalšími implementacemi kompatibilní.
V principu ethernetový transceiver posílá po médiu jakýsi předepsaný pravidelný řetízek pulzů, který umí RX strana detekovat a říct "mám link". Na ten prostý řetízek pulzů se později (zpětně kompatibilně) začly enkódovat schopnosti transceiveru. To je základní úroveň: co o sobě síťovka po médiu "ohlašuje" že umí (advertise). A pak je tam zřejmě ještě nějaká vyšší vrstva toho handshaku, kdy se obě strany proti sobě "dohodnou", čím teda pojedou - protože oznamuje se celá množina, vlastně bitmapa, podporovaných variant (rychlosti, duplex a další schopnosti).
"Nastavit natvrdo" může znamenat několik věcí:
A) handshake zůstane zachován, jenom se na daném "natvrdo nastaveném" transceiveru omezí množina oznamovaných schopností. Myšlenka je taková, že handshake skončí dohodou na "natvrdo nastavených" schopnostech.
B) vypne se i ten handshake a fakt se jenom natvrdo nastaví rychlost a duplex. Zbyde detekce linku na bázi surových NLP pulzů (nebo jak se to jmenuje na gigabitu apod.)
C) A zřejmě některé PHY transceivery dokonce umí i vypnout detekci linku na bázi holých NLP pulzů a prostě zapnout TX směr natvrdo - ale když jsem se s tím snažil experimentovat na konkrétním Intelu, tak mi to tuším nefungovalo...
Rozdíl mezi A) a B) je v rychlosti naběhnutí linku. S handshakem to trvá déle. Všiml jsem si toho u nějakých switchů do vlaku, kde funguje jakýsi failover pomocí překlenovacího relé. Je tam specifikovaná lhůta pro překlenutí a dá se stíhat jenom s vyřazeným autoneg handshakem.
Schopnosti dnešních eth transceiverů docela těsně kopíruje linuxový
ethtool. Mrkněte na argumenty autoneg, advertise, speed, duplex, mdix, eee, pause. Ne všechny možnosti jdou navzájem libovolně zkombinovat, třeba "mdix off" se tuším navzájem vylučuje s "autoneg off" (možná jenom u driveru Intel).
Chci říct, že pokud na Ciscu máte možnost nastavit jenom speed a duplex, tak je to docela chudý výběr. Ale zase v tom nelze udělat chybu, pokud je to Cisco proti Ciscu.
Pokud se týče toho ducha, kterého honíte... mám dlouholetou zkušenost, že člověk buď má osciloskop a reflektometr, a pak trochu vidí, co se děje, nebo nemá, a potom tápe :-) Popravdě ono i s tím biografem je to tápání, pokud se ujistíte že kabeláž je v pořádku, doměříte se až na piny švábů že signál prolejzá, a stejně se vyšší vrstvy někde nedohodnou - a ty vyšší vrstvy už jsou černá skříňka, a prostým skopem bez návazné analýzy ani nerozeberete protokol toho handshaku...
Perioda flapování pár sekund nevypadá na Spanning Tree. Ten konverguje v desítkách sekund (cca 30-50s). RSTP teoreticky rychleji, za ideálních okolností, ale... = osobně tipuju že selže buď autoneg handhshake nebo prostá detekce linku (je na hraně).
Pokud skouknete kabely a budou v pořádku, tak je asi jediná možnost zamačknout slzu. Občas se prostě dvě krabičky mezi sebou domluvit nechtějí.
Teoreticky by mohl být analogový problém v napájecím zdroji jedné z krabiček. Pokud je spínaný, odešel v něm Y-cap (nebo je z výroby spíš moc malý) a mezi zeměmi zařízení je VF střídavina (desítky kHz s amplitudou pár set Voltů), mohlo by to zarušit užitečný signál tak, že link nebude držet. Přestože jsou na portech signálová trafa. Oni jsou tam taky nějaké uzemňovací kondíky kvůli EMC, potlačení soufázové složky je konečné atd. Opět námět na kontrolu osciloskopem...
Zobrazit příspěvky
