classic.ISPforum.cz

okoun píše:FSC error by neměl být to že se nedohodně master slave, pokud se nedohodne tak se neslinkuje, FSC by měl být nějaký HW průs... tedy chip nebo kabel nebo poe, prostě nějaká HW srágora

vtip je v tom, ze oni se dohodnou a obe strany pak skonci jako Master. Netusim jestli by se spravne slinkovat nemely (uz je to nejaky patek, co jsem procital prislusnou normu), vim jen ze v pripade te Alcomy jde o bezny problem MP jednotek. A pokud na tom Racomu lze Slave vynutit, pak je to jednodussi zkusit nez menit kabel/konektor apod. I kdyz je dobre vedet jak se pri tom prepinani jednotka chova - aby to neskocilo nedostupnym radiem

Druha vec je jestli par FCS za mesic ma smysl resit.

nu ale kde se na mikrotiku zjistí jeslti se dohodnul jako master nebo jako slave? já to nevidím nikde...

okoun píše:nu ale kde se na mikrotiku zjistí jeslti se dohodnul jako master nebo jako slave? já to nevidím nikde...

prvne jsem se s tim problemem setkal na vetsim mnozstvi instalaci typu Cisco switch - Alcoma. Na Ciscu slo vypsat obsah registru ze sitovek a tam bylo videt, co si o tom mysli switch.
Ono neni tak uplne jasny jak ta negociace ma vypadat a zarizeni jako switche vzdy chteji IMHO byt Masterem. Resp pri negociaci ma vetsi vahu ten, kdo je tzv. multiport zarizeni. Akorat netusim, co se ma stat kdyz oba budou stejneho typu (vahy).

A to, ze nezjistis na MT jak presne dopadla negociace (chtelo by to vystup z ethtool) je sumak - potreboval bys to vedet z obou stran.

okoun píše:nu ale kde se na mikrotiku zjistí jeslti se dohodnul jako master nebo jako slave? já to nevidím nikde...

dole na ethernetu je videt jestli je mk slave

racom asi nevie master slave...

robi to len obcas, na druhe strane RB1200 ani jeden fcs....

KoZLiCeK píše:

okoun píše:nu ale kde se na mikrotiku zjistí jeslti se dohodnul jako master nebo jako slave? já to nevidím nikde...

dole na ethernetu je videt jestli je mk slave

slave (yes | no) Whether interface is configured as a slave of another interface (for example Bonding)

Slave/Master o kterem se tady bavime je soucast negociace 1gbps ethernetu mezi 2 ma zarizenimi. A MT jej IMHO nikde nereportuje.
Jak jiz jsem psal jde o to, kdo bude generovat hodinovy signal z vlastniho hodinoveho obvodu a kdo se na nej bude jen synchronizovat (tj bude jej rekonstruovat z prijatych bitu a synchrpnizovat si podle toho vlastni hodiny)

Nové alcomy nám to nedělají. Racom též ne. A když už, tak jen čas od času jedna dvě chyby bez vlivu na provoz.

Blbý je, že takové MP90 to nepřežijí ... čas od času FCS error, jenže čas od času (většinou o víkendu) je jich tolik najednou, že port přestane přenášet data. Link je, pomůže disable/ enable na CCR. Verze ROS vliv nemá, je tam už třetí.

Alcomou to ovšem nebude (alespoň ne přímo), bývala ve switchi dlouhá léta bez problému. Jen se přehodil patchkabel do CCR.

Zajimave na RB260GS mi to dela taktez FCS errory na sfp sachte, ktera je proti TL-SG5412F
vsechny 3ks RB260GS

Cheprer píše:Zajimave na RB260GS mi to dela taktez FCS errory na sfp sachte, ktera je proti TL-SG5412F
vsechny 3ks RB260GS

IMHO bud problem se signalem (moc slaby nebo prehulene) nebo vadne SFP moduly

Dalibor Toman píše:

Cheprer píše:Zajimave na RB260GS mi to dela taktez FCS errory na sfp sachte, ktera je proti TL-SG5412F
vsechny 3ks RB260GS

IMHO bud problem se signalem (moc slaby nebo prehulene) nebo vadne SFP moduly

Všechny sfp? Signál sem měřil power metrem je to mezi -6az-8,5dBi.

Také jsem řešil u zákazníka na CCR1036 - zařízení bylo nedostupné a v logu FCS errory, podle monitoringu k tomu docházelo cca 1-2 týdně, nejčastěji v odpoledních/večerních hodinách, kdy poklesl provoz na minimum/nulu. Začalo se to stávat až s firmwarem cca 3-4 měsíce zpět (a ani nejnovější stable firmware v tu dobu problém nevyřešil), předtím zde zařízení běželo bez problémů 2+ roků s pravidelnými updaty ROSu. Proměření optické trasy se provedlo, vše ok, výměna SFP na obou stranách spoje (na druhé straně Cisco-compatible switch) a dělalo to stále. Hotfix bylo shodit WAN port např. restartem převodníku či shodit port na switchi na ISP straně. Sepsáno a s supout.rif souborem posláno na Mikrotik Support, na nic nepřišli.

Nyní výměna CCR za RB3011, SFP až v Mikrotiku, konfigurace identická, poslední stable ROS, již 2 týdny běží v pořádku, snad bude i nadále. Naštěstí investice do RB není tak dramatická.

tak dnes rano jsem měl dobrý probuzení 2 summit narrow spoje lehly na FCS nemoc zajímavy je že jeden je připojen do x86mikrotiku kterej je propojenej s 3011 a do 3011 je zapojenej druhej narrow a oba dělaj stejnej problem FCS erory na 100mb a když dam 10 mb tak to trocha jede ale zase vagon tx collision
at dělám co dělám tak to nejde nijak vyřešit

Do te 3011 je taky starej UNI spoj a ten jede v pohodě

ROS rb3011 je 6.44

A dělají to oba stejně jo?
Vím, že pokud to dělalo SDV, tak odešel ETH port na SDV a v Summitu mi ho výměnili a na dobu opravy mi dali servisní jednotku. Od výměny "ťuk ťuk" je to OK. Zkus se podívat na kabel, jestli ti v něm nekoroduje pár. Pršelo a pokud praskla izolace, tak ti zatekla voda, pak zmrzla a pří rozmrznutí se ti něco zkratuje.

Tak zatím je to tak že jsem odpojil x86 stroj v kterým je asi vadná RB44