RB5009 - vysoká latence (100Mbps port)

vecino

Asi to bude pro vás banální věc, ale mě to dnes chvíli trvalo než jsem zjistil co je zdrojem problému. Můžete mi někdo vysvětlit proč se to děje?

Popis: RB5009 - uplink SFP+ 10G ... na ostatních portech je mix Mikrotik / UBNT 60GHz PtP spojů. Dnes začaly lítat z monitoringu alerty, že je vysoká latence v řádech cca 4 - 110ms na všem co je za těmi spoji. Zdroj problému byl, že na jednom LHG60 spadnul port z 1Gbit na 100Mbps (traffic tam bývá cca kolem 150Mbit) a díky tomu kravilo celý 5009. To mě docela rozsekalo ... jako chápu asi ten přechod / náraz z 1Gbit -> 100Mbps, ale proč to "sundá" celej router? Tohle byl u MK problém kdysi dávno a myslel jsem, že to je HW i SW vyřešené.

Nějaký tipy jak to ošetřit? Pochopitelně padající port vyřeším, aby linkoval na 1Gbps, ale děsí mě, že se to stane znovu třeba na jiným spoji. Díky

Edit: 5009 má long-term 7.21.4

selic

vecino Bohužel je to vlastnost toho switch čipu.
Jediný rychlý fix je script, který hlídá linkovou rychlost na portech a v případě, že některý port spadne na 100Mb, tak nahodí na konkrétní port nějakou qos quee s omezením na 80-90Mbit a zároveň pošle mail s varováním na dohled.
Pak blbne jenom konkrétní port a neshodí to úplně všechno.

Jodle

vecino přitom “ fixed 2.5G-baseT link-partner-advertising on RB5009“ v RouterOS 7.21beta2” a ty máš novější? Ale to je asi jiný problém.

Jinak když zakážeš 100TX tak to asi nenastane (chcípne jen spadlý LAN).

:if ([/interface ethernet get etherX speed] = "100Mbps") do={
/interface ethernet disable etherX
}

Nebo

/interface ethernet set etherX advertise=1G-full

k3ny

to bude asi vyplacanej buffer. pouzivas bridge a hw-offloading na portech?

vecino

k3ny Ne bridge tam vůbec není. Jsou tam tři vlany Interfaces - vlan (ano jdou přes CPU) a zbytek jsou fyzický porty.

vecino

selic Ano tak jsem to jako rychlý fix udělal, ale je to teda jako za krále klacka. Myslel jsem si, že tyhle časy máme za sebou a vono ne. 🙂

pgb

Jede, tohle je klasika. Stejně se to chovalo i na hexech, jen mě nikdo nebral moc vážně 😉. Podívej se na internal CPU flow control. Měl jsem na to video

Jinak jediný co pomohlo bylo mít vše na 1G, netpower na to třeba netrpí. Shapovaci třída pomůže, když zabrání ucpání.

vecino

pgb Jo Petře to je přesně ono. Hmm tak to fakt čumím no - myslel jsem že 5009 je už "jinde". Jak jsem psal všechno mám na 1G mimo uplinku ten je 10G, ale spadnutí portu na 100M je chyba té jednotky, konektoru, patch kabelu,... a to se úplně ovlivnit nedá (prostě se to může stát). A nyní přesně už vím jak ten celej router bude kravit a ovlivní všechno za ním. 😀

Každopádně díky všem za reakce / postřehy, 👍

vecino

Ano je tam long-term 7.21.4 viz můj první post. Ano tohle je jiný problém.

To umrtvení portu je sice hodně radikální, ale také řešení. 🙂

Mám to v monitoringu s alerty, takže bych o tom měl vědět okamžitě. Můj post byl primárně o tom, že mě překvapilo že i dnes v roce 2026 + i u relativně aktuálního hw za což 5009 považuju se tohle děje. Každopádně díky za postřehy.

pgb

vecino vylepši si dohled ... dohledujeme porty stylem že link up/down+ eth rate musí být vždy stejná jako poslední uložená - nesmí klesnout. Takže upgrade z 100>1G je OK, pád z 1G>dolů vyvolá alert. Porty které nemají být monitorovány mají specifický popis...

Jodle

“post byl primárně o tom, že mě překvapilo že i dnes v roce 2026 + i u relativně aktuálního hw za což 5009 považuju se tohle děje“

Mě překvapilo, že dodnes nedodali Wi-Fi 7…

To který před půl rokem oznámili, jsem myslím ještě na pultech neobjevilo :-)

Asi jedou na marže a na R&D kašlou. Teltonika má vyšší obrat (2024).