Mikrotik - RX overruns

re-ady

Ahoj, dokážete mi někdo pomoci vyřešit problém? :-) Máme vysílač, jako spoj jsme použili 60GHz LHG, když se připojím přes ethernet přímo na spoj, naměřím cca 500Mb/500Mb. Za tím máme switch (mikrotik ccs), a za switchem naměřím už jen cca 40-50Mb. Na switchi je u portu, do kterého je koenktivita zapojená, vysoká hodnota RX overruns. Nevíte někdo kde to vzniká? Jak to opravit? Všude nejnovější firmware mám. Předem děkuju za pomoc, P.

cerva

Zapni si flowcontrol mezi switchem a LHG. Problém vzniká při switchování při přechodu z rychlého iface na pomalejší, kdy switche s malým bufferem začnou zahazovat packety příliš brzy a TCP pak reaguje přílišným snížením rychlosti.

midnight_man

Ak má všetko na 1G prečo je s tým problém?

re-ady

Flow control zapnuté máme, zahazuje to stejně... Myslíš, že by pomohla výměna switche? Dokud všude byly tupé switche, vše bylo ok. V momentě, kdy jsme začali nasazovat mikrotik CSS nebo CRS, začaly problémy...

kozlicek

Flow control zapnuté máme, zahazuje to stejně... Myslíš, že by pomohla výměna switche? Dokud všude byly tupé switche, vše bylo ok. V momentě, kdy jsme začali nasazovat mikrotik CSS nebo CRS, začaly problémy...

v crs a css je na ethernetu defaultne auto u flow control.dej to na off.tohle sem taky zazil.postupne nahrazujeme vse ubnt switchema.tam problemy nejsou.

dalibortoman

Flow control zapnuté máme, zahazuje to stejně... Myslíš, že by pomohla výměna switche? Dokud všude byly tupé switche, vše bylo ok. V momentě, kdy jsme začali nasazovat mikrotik CSS nebo CRS, začaly problémy...

pokud ten datovy tok switchem prichazi a odchazi rozhranim se stejnou linkovou rychlosti (dejme tomu vsechny porty maji link 1gbps), pak by ten problem s RX overruny nastavat nemusel. Za podminky, ze HW switche stiha plnou rychlost linky (ten 1gbps). Pokud pouzivas HW switch chip pak by stihat mel. Pokud ale jedes softwarove (bridge resp v novych ROSech bridge s vyplym offloadingem), tak CPU to stihat nebude, takze se zaplni fronta pro ulozeni prichozich packetu a nove packety ji budou prepisovat - vznikne overrun chyba

hapi

kde mikrotik ukazuje overrun? já tam widim jenom overflow. Navíc jestli máš zapnutý FC tak tam snad vidíš i rx pause ne?

hapi

Flow control zapnuté máme, zahazuje to stejně... Myslíš, že by pomohla výměna switche? Dokud všude byly tupé switche, vše bylo ok. V momentě, kdy jsme začali nasazovat mikrotik CSS nebo CRS, začaly problémy...

píše CCS takže switch a pakety se nepřepisují, pokud neni místo, zahazují se. To by si taky mohl dopadnout tak že než by se odeslal paket tak by ho přepsal jinej příchozí a ten za chvíli dalším příchozím takže odchozí by nebyl žádnej.

re-ady

Jedná se o mikrotik switch se SwOS, takže pakety asi opravdu zahazuje. Bohužel máme zde kombinaci 1G a 100Mb linek, možná proto to vzniká. Zkusím tedy vyměnit switch za úplně jiný. Jen ještě otázka - tenhle typ chyby (RX Overruns) nemůže být třeba špatným kabelem od konektivity? Koncovka, nebo něco podobného? Díky.

re-ady

kde mikrotik ukazuje overrun? já tam widim jenom overflow. Navíc jestli máš zapnutý FC tak tam snad vidíš i rx pause ne?

SwOS - záložka errors - přímo tam je sloupec RX Overruns . RX pause jsou čisté...

petrbacina

Není to ničím jiným než tím Mikrotik switchem. S čímkoliv jiným ti to pojede jako z praku. Bohužel Mikrotik pustil do světa další paskvil. Úplně zmršili vlastně celou řadu CRS a CSS. Na 1Gb to funguje celkem slušně, ale jakmile tam zamotáš 100Mb, tak jsi v háji.

dalibortoman

píše CCS takže switch a pakety se nepřepisují, pokud neni místo, zahazují se. To by si taky mohl dopadnout tak že než by se odeslal paket tak by ho přepsal jinej příchozí a ten za chvíli dalším příchozím takže odchozí by nebyl žádnej.

to je jen slovickareni.

V realu je ta fronta realizovana jen pointery na skb a samozrejme pred prepisem dojde k uvolneni mista v kruhovem buferu s pointery (resp k uvolneni pameti na kterou ten pointer miri a pak se ta pozice v bufferu prepise odkazem na jinou pamet)

re-ady

OK, zítra vyměním switch a dám vědět. Pokud to opravdu pomůže, tak budu z Mikrotiku již po několikátý zklamanej :-)

ispic

Vítej v klubu :)

dalibortoman

OK, zítra vyměním switch a dám vědět. Pokud to opravdu pomůže, tak budu z Mikrotiku již po několikátý zklamanej :-)

alespon mel MT koule na to, ze implementoval ten counter. Jinak by ses o problemu tak snadno nedozvedel. Proste poradny switch musi mit buffery jinak je pouzitelny jen tam kde ztratovost nevadi nebo k ni nema jak dojit (link speed dovnitr i ven je stejna - a i v tomto pripade muze vzniknout problem kdyz zapojeno vic portu nez 2).

re-ady

Tak pro zajímavost - switch mikrotik vyměněn za hloupý 1G switch hp, okamžitě vše začalo fungovat jak má....

petrbacina

Jsem ti to říkal, prostě switche od Mikrotiku jsou šrot ať si říká kdo chce co chce. Minimálně ty nové s čipy Marvell Prestera. Ty starší ještě celkem OK, i když trpí na packetloss. Myslím, že hlavní problém nebude ani tak v HW jako v SW.

3com

Řešil jsem něco podobného na jednom místě. Už delší dobu se mi tam děla chybovost na eth konektoru příjmu konektivity RB911 Lite5 dual (Příjmová wireless část byla stoprocentní s ccq 90-100 bez jediné chyby a ping 100% bez kolísání. Za ním byl switch RB260GS, proběhla výměna za RB750Gr3 všechny porty do hw switche a problém stále stejný, zkoušel jsem všechny možné změny i ve Flow Control a různé verze MK až po nejnovější. Nejhorší bylo, že to dělalo jenom někdy nahodile a třeba hodinu v kuse pak týden klid... Až později jsem vypozoroval, že se to dělo při špičce venkovní teploty, když byly špičky veder, bez ohledu na tok dat přes daný prvek. Výměna příjmového RB911 to vyřešila.. (Vadný kus, který při zvýšené teplotě v okolí začal na eth chybovat ikdyž byl jenom cca 12měsíců starý... <--- ia0 -->eth.jpg<--- ia0 --> Vedlejší záložka chybujícího eth: Tx Stats byla bez jediné chyby vždy.