Po několika letech vývoje byla vydána nová major verze na Linuxu založeného routerového operačního systému od společnosti MikroTik. RouterOS v7 [PDF] přináší mnohá vylepšení a nové funkce.
Za zmínku stojí například nové linuxové jádro 5.6, kompletně nový IPv6 stack, značně vylepšený výkon BGP, snížení nároků na paměť, podpora technologií WireGuard, ZeroTier a další. Více viz oficiální video:
Tato zprávička byla zaslána čtenářem serveru Root.cz pomocí formuláře Přidat zprávičku. Děkujeme!
Veris. Lenze nevies. IGMP nie je slepa vetva. A to ani z daleka :-) Aktivne sa pouziva na accesovej vrstve ak je swicovana. Koncovy mcast router sa pomocou tohoto protokolu dozvie kde ma akych zaujemcov. Teda zaroven vykonava funkcionalitu IGMP queriera. IGMP snooping zase musia podporovat swice. Od posledneho MCAST routra az po zakaznika sa swice musia ucit na ktorom porte je zaujem o aku skupinu, inak sa k multicastu budu chovat ako k broadcastu. A na to sa vyuziva IGMP snooping. A nie je to ziadna rarita. V kazdej sieti kde sa vyuziva multicat, je aj funkcny IGMP snooping na L2 a nejaky routovaci protokol na L3. Tak napriklad Orange. A taktiez u kazdeho operatora s IPTV. Staci si zapnut wiresharka zaradeneho pred STB. Prepni program a uvidis co vyleti z STB a co pride od routra. V drvivej vecsine pripadov to budu IGMP queries.
Obcas ale existuju scenare, ked sa hodi IGMP querier priamo na swici a kvalitny swic by to mal podporovat.
Existuju aj ine protokoly na riadenie MCASTU na tejto urovni napr. CGMP. Ten je vsak propietarny.
13. 12. 2021, 10:49 editováno autorem komentáře
Tak jasne, ze nevim, proto pisu, ze verim :-) Ty urcite taky nevis, taky jen veris. Za me je budoucnost ve zpetnem prehravani, ne v linearnim. Casem proste IGMP snooping nebude potreba. A jak funguje mi vysvetlovat fakt taky nemusis. Jen me stale prekvapuje, kdo by chtel pouzivat IGMP snooping na RouterOSu, kdyz je ze sve podstaty pouzivan jen na L2 vrstve. A mozna se tu celou dobu bavime uplne zbytecne, protoze IGMP snooping v RouterOSu implementovany uz davno je. Takze abychom se vratili k puvodnimu komentari, funguje tam nebo ne?
Neverim. Viem. Pracujem na pozicii kde ani inu moznost nemam. Multicast nie je len o IPTV.
Ja tu buducnost takto nevidim. Je to o zvykoch ludi a v sietach kde som mal moznost tieto veci pozorovat, to bolo prave o linearnom prehravani. A to aj tam kde bola moznost prehravania z archivu. Mozno tak o 20 rokov ... ale to je dlha doba na cokolvek v tejto brandzi.
V case ked som IGMP Snooping potreboval na ROS tak to tam nebolo. Nastastie islo len o jednorazovu zalezitost a nic co by som musel nasadzovat nejak masovo. Apage!
No to som celkom zvedavy, akymi linkami budes unicastovat desiatky realtime (u live TV nemas tolko casu na kompresiu) 4K streamov spolu s dalsimi desiatkami streamov vo FHD. Tak, ako sa zvysuju kapacitne moznosti sietovych zariadeni a liniek, zvysuju sa aj naroky na nich. Multicast ma stale velmi vyznamne opodstatnenie a kto tvrdi ze nie, nikdy nerobil u backbone ISP.
21. 2. 2022, 21:53 editováno autorem komentáře
Na OpenVPN UDP jsem se peknych par let tesil.
Proto nechapu, proc zase museli neco pokazit :-(
https://help.mikrotik.com/docs/display/ROS/OpenVPN
> auth (sha1 | md5; Default: sha1,md5)
V roce 2021 je default MD5 a SHA1? A nic jineho to ani nepodporuje? Proc ne treba SHA256/512?
Videl jsem to asi 3/4 roku zpatky v beta verzi. Myslel jsem si, ze to ve stabilni verzi bude lepsi.
Mi se to docela osvědčilo, když byl zákazník v Rusku. Typicky používám L2TP/IPsec, ale tam to bylo nepoužitelné. Chvíli to fungovalo velmi špatně, chvíli vůbec. Internet jako takový fungoval na obou stranách v pohodě. S Wireguardem pak už problém nebyl.
Ten paradoxně nastal až pár týdnů po návratu, jak se aktualizoval nainstalovaný klient, který už ani nebyl potřeba. Nějakým způsobem to ve W10 dodrbalo sítě. Šlo se připojit jak ethernetem, tak WiFI, ale netekly data. Jelikož se čas aktualizace přesně kryl s počátkem problémů a neměl jsem to zrovna čas řešit, tak jsem to zkusil odinstalovat a problémy vymizely, takže co se přesně stalo, nevím. Určitě to ale budu testovat dál, protože to nejspíš nebyla poslední cesta do Ruska.
Pokud ten router neslouží jako hračka, ale k seriózní práci, což je firewall, routování a pár dalších drobností, dá se bez MC nebo Byobu dokonce přežít. Jakýkoli zásah mimo jednou dané balíčky výrobce jen zvyšuje riziko nějakého problému, to si někteří nemohou dovolit.
Navíc si dovolím tvrdit, že na přehlednost a dospělost FW u MT nemá nic. Jak bych tolik pravidel umanagoval pro X různých VLAN a sítí na OpenWRT, to si nedovedu představit.
No ja som s tym problemy v OpenWrt, potazmo TurrisOS mal. Je to system, ktory absolutne neberie do uvahy pouzivatelsku konfiguraciu, ide si svoje a nahodne vyresetuje nastavenia pouzivatela, ked sa mu jeho idea zda lepsia. Naposledy (tyzden-dva? naspat) sa rozhodol, ze kedze nastaveny resolver nepodporuje DNSSEC, tak si nastavi svoj a kaslat na to, ze to ma asi dovod.
Ako fakt uz nemam ani naladu, ani vek, aby som riesil nahodne problemy systemov co maju pristupom k preferenciam pouzivatela ako ma Microsoft, takze je objednany dalsi Mikrotik a Turris ide prec.
Kup si Turris, provozuj ho aspoň rok a zjistíš, že za ty prachy a nervy ti to nestojí..
Co update, to problém. V prvních verzích bylo zcela běžné, že co update, tak resetování.. A dělal si to kolikrát samovolně...
Nebo samovolně zavírá některé porty, takže když si chceš zahrát CoD, tak si musíš jít zkontrolovat zda ti to nezavřel router...
TurrisOS patří na smetiště dějin a fakt kdo to obhajuje jako super věc, nebo něco jiného, byl omlátil o hlavu! I zadarmo je to drahé..
To je sice pravda, TurrisOS nie je OpenWRT, a problem je v tom, co ma TurrisOS naviac - schopnost update.
Co si pamatam vanilla OpenWRT, tak tam update znamenal kompletny vymaz, nahodenie noveho release a konfiguracia uplne od znova. Kedze releasy chodili tak v jednotkach ks behom par rokov, tak to vtedy az taky problem nebol. Dnes by to problem bol, pri takychto zariadeniach ocakavam, ze ich viem updatnut a mozem to urobit aj remote -- teda nerozhodi konfiguraciu. Co napriklad Mikrotiky alebo Ubiquiti splnaju, pri TurrisOS je to riziko ale zvycajne sa to da a cisty OpenWRT, tak tam na to rovno zabudnut.
(A nebol to konflikt configu - bol to umyselny override user configu, lebo v CZ.NIC si zmysleli, ze ich nazor na konfiguraciu je dolezitejsi ako potreby pouzivatelov).
Možná jsem měl štěstí, ale zatím mi za léta používání Turrisů (dvou) nic při updatech "neupadlo".
Ale totéž můžu říct o OpenWRT (taky dva), kde mám update v cronu, abych na něj nezapomínal - zatím dva roky zcela bez problému.
Dokud mi běžel Mikrotik, updaty též bez problému.
Asi jsem měl štěstí. (Nebo se nesnažím udělat z routeru ještě "něco silnějšího" a tak ta v podstatě základní konfigurace nemá tendenci se rozsypat.)
To jsi měl docela štěstí.
Já mám Omnii z kampaně a pár kiksů bylo. Ne, že ne. Jednou jsem musel snad dokonce udělat factory reset, abych se do toho dostal. Ale druhou stranu, dělal jsem s tím blbosti...
Přes to všechno jsem více méně spokojený - rozuměj tomu tak, že dokud slouží, tak měnit nebudu, ale koupi novější verze si budu rozmýšlet (ta předpokládaná cena je pro domácí uživatele příliš). Ono je otázka čím to nahradit. Možná skončím tak, že časem pořídím nějaký SBC pro věci, které na Omnii provozuji a tu nechám dělat jen router - Omnia má pouze 32b CPU a mnohý SW podporu 32b již ukončil.
bez přezdívky
Co si pamatam vanilla OpenWRT, tak tam update znamenal kompletny vymaz, nahodenie noveho release a konfiguracia uplne od znova.
ne update znamena pouzit nastroj opkg na aktualizaci jednotlivejch balicku ;-)
pokud aktualizovanej balicek ma novej conf a zjisti ze user ho ma upravenej, zobrazi informaci a novej conf necha jako nazev-opkg...
aktualizuju to pres SSH...
("priznavam" ze opkg nema neco jako "opkg update-vsechny-dostupne-aktualizace", takze mam skript co zjisti dostupne aktualizace a pres xargs jednotlive zauktualizuje + mi mazu nazev-opkg pokud se od minule aktualizace balicku nezmenil, pokud ano, delam rucni merge)
Na zariadeniach kde som mal OpenWRT tento pozostaval z dvoch filesystemov: jeden readonly squash a druhy read--write jffs2, ktory bol overlay.
Na update vsetkych package cez opkg tam nebolo miesto. Aby sa vsetko pomestilo, tak sa musel updatnut squashfs image, co znamenalo presne to, co som popisal vyssie.
Ano, bolo to obmedzenie hw, ale vtedy kazdy hw mal podobne parametre. Setrilo sa na dnesnu dobu az nezdravo, chciet mat podporu ipv6, ipsec a ca-certificates znamenalo ist na hranice mozneho.
Na Turrise som povodne ocenoval, ze ma zbavi takychto veci, ze do 8 GB eMMC sa toho vela zmesti. No, chlapci si nasli nove problemy, ktorymi zabavat pouzivatelov.
> Co si pamatam vanilla OpenWRT, tak tam update znamenal kompletny vymaz, nahodenie noveho release a konfiguracia uplne od znova.
Ne, v adresáři /lib/upgrade/keep.d/ je seznam souborů, které se zachovávají - funguje to tak, že se upgradovacím skriptem (sysupgrade) tyto zabalí do ramdisku, flashne se nový systém a zkopírují se zpátky. A funguje to takhle minimálně od 12.něco, spíš od 10.něco.
Upgradoval jsem takto zatím něco jako 15 zařízení, z toho jedno se při upgradu zaseklo a byl potřeba manuální power cycle (pak naběhlo v pohodě), ostatní se i korektně rebootly a nebyl potřeba žádný zásah.
Na RouterOS se staví i dost velké sítě. Např. aktuální novinka CCR1072-1G-8S+ - 8x10 Gbps zapojených do CPU a routovaných plnou rychlostí za 3000 USD asi nebude mířena na malé sítě. Routerů co mají 2x10 Gbps a spoustu další 1 Gbps portů má Mikrotik spoustu už delší dobu. Switche např. CRS326-24S+2Q+RM - 24x10Gbps+2x40Gbps už také nabízí nějakou dobu a kouzelné je, že všechny routery (a i možno i některé switche) od domácích 10+ let starých po nejvýkonejší se konfigurují stejně.
Ano, tam kde se vám bude scházet 10Gbps nebo rychlejších rozhraní více, tam už musíte dát něco jiného, ale to už se asi nebavíme o malých firemních sítích.
No to je pravda, musí se použít asi tři čudlíčky, takže když jsem to zkoušel se svým psem, nedal to.
Kupříkladu tady to ten člověk udělá za 12m s vysvětlením na obrázcích a popisu všeho.
https://www.youtube.com/watch?v=lS4zeMACT3w
Myslim si zeby to slo aj bez tychto hlupych ubohych zosmiesnujucich komentarov. A kazdy ma tu siet nastavenu inak. Atd. From scratch to mozno zvladne aj skrecok za 12 minut. Provozujem wireguard z ubuntu asi pre 25 pripojenych klientov a nastavenia bolo realne 2 minuty. Aj keby to bolo 12 minut. je to stale nasobne viac.
"Nainstaloval som to a trvalo mi snad 2 hodiny kym som to rozbehal. Na linuxe to mam asi za 2 minuty."
Mimochodem, na Linuxu, jak pán píše, se nastavuje naproto to samé, co na MikroTiku. Pokud s tímto tvrzením pán nesouhlasí, ať prosím napíše, co je na MT navíc.
Prostě je to nastavení naprosto triviální a je to hned, nedá se níc dělat. Hrozně mě to mrzí, ale dělat raketovou vědu z něčeho, co je tak šíleně jednoduché je trapné. Dvě hodiny to může trvat, když z nich bude někdo necelé dvě hodiny souložit.
Pokud máte handshake failed, máte prostě špatně některý z těch klíčů.
Nedalo mi to a kouknul jsem na dokumentaci.
https://help.mikrotik.com/docs/display/ROS/WireGuard
Není tam nic, co by nebylo i v normálním Wireguardu na Linuxu. Chápu, že to nemusí fungovat hned na poprvé, zvlášť při integraci do nějaké složitější sítě, ale viděl bych to spíš na klávesnice-židle problém
To je tím, že to přesunuli z development větve do testing větve, tak je to matoucí. Ale máte očividně prostě nejnovější verzi.
U MikroTiku je ta potíž, že jsou všechny verze minimálně o jednu úroveň posunuté. Pokud máme nestabilní betu, je to v nejlepším totálně nepoužitelná alfa. Tohle, ačkoli je to z development v testing není příliš zralé pro testing, protože každý, kdo to kolem mě má, si vyžral nějakou chybu.
Zkusil bych reboot, případně přeflashnout a je docela šance, že to půjde. Rozhodně také napsat na fóru.
ČLÁNKY DO MAILU