A Mizu MikroTik sorozat a RouterOS legfontosabb változásairól szól. A sorozatban elsődlegesen az új funkciókra koncentrálunk, a javításokat csak nagyon indokolt, sokakat érintő esetben említek meg. Ebben a részben a v7.18 kerül terítékre:
RIP 802.1br
2022-ben, amikor először írtam a MikroTik 802.1br Port Extension megoldásáról, ez szerepelt a cikkben: „…Ezen kívül viszonylag sok dolog nem működik még együtt ezzel…A lista a későbbiekben változhat…” Hááát, nem változott. Az évek alatt nem sok dolog történt ezzel a funkcióval, így bekerült a „jól hangzott, de félbehagytuk” fiókba. Aztán most meg onnan is kikerült: a 7.18-as verziótól a 802.1br nem létezik a RouterOS-ben. Ha eddig használtad, akkor ésszel frissíts!
Bonding bővülés
A bonding funkciót nagyon sokan használják, ha két MikroTik, vagy egy MikroTik és egy más hálózati eszköz között kettő, vagy több linket kellene egyként kezelni és minél hatékonyabban terheléselosztást végezni rajtuk. 7 féle módon is működhet, két MikroTik eszköz között létrehozva akár egy TCP adatfolyamot is többfelé tud küldeni, de ebbe most nem mennék bele, MikroTik Online Klub tagként a Switching Online tananyagban megtalálod a részleteket.
Annyit viszont hozzá kell tennem, hogy megértsd a változást, hogy két olyan módja van, ami kompatibilis lehet más gyártók eszközeivel (LACP, vagy Static LAG megoldások). Mindkét mód egy hash alapján dönti el, hogy melyik keretet melyik interfészen/linken (bonding nyelven: slave-en) küldi az ellenoldali eszköznek. A hash kiszámításában szerepet játszhatnak forrás és cél MAC címek, forrás és cél IP címek és L4 jellemzők: protokoll és portok. Ezért ha két keretben ugyanaz a forrás és cél MAC és IP, valamint a Layer 4-es jellemzők is, akkor a két keret ugyanazon a slave-en fog menni.
Ez normál forgalmaknál nem is okoz nagy gondot. De mi van akkor, ha ezen az egyben kezelt linken valamilyen enkapszulált forgalmak mennek többnyire? Vagy akár csak azok. Mondjuk PPPoE, 6to4, GRE, vagy IPIP. Akkor ezeknek a kereteknek minden a hash kiszámításához használt jellemzője megegyezik, tehát minden keret ugyanazon a slave-en megy és a bonding-unk maximum backup link menedzsmentre jó. Legalábbis eddig: 7.18-tól kiválasztható olyan hash kiszámítási mód, ami az enkapszulált adatokat veszi figyelembe, azaz mondjuk egy PPPoE keretbe zárt IP csomag Layer3/4 jellemzőit. Így más enkapszulált adatok terheléselosztását is meg tudja valósítani az LACP, vagy Static LAG.
IP változások
Egyrészt kaptunk egy új eszközt: vajon merre megy a csomag, ha több kijárat is van a routeremből? Ez eddig is kideríthető volt többnyire a traceroute-tal, de ha a követlező eszközben az ehhez szükséges ICMP csomagok tiltva vannak, akkor ez nem működik. Most kaptunk egy olyan route eszközt is, ami ezt egyértelműen megadja: ez a check tool
Másrészt a RouterOS /31 támogatást kapott, azaz most már ilyen címeket is használhatunk /30 helyett, ha spórolni kell a publikus IP-kel.
Harmadrészt megérkezett a sokak által jól ismert Fasttrack az IPv6 forgalmakra is. Ha nem tudod, hogy mi az a Fasttrack, akkor ajánlom figyelmedbe az ingyenes MikroTik Gyorstalpaló 11. részét, amiben erről is szó van.
Végül pedig: az IP Pool-ok statisztikai adatokkal bővültek.
Csomagok telepítése pár klikkel.
A RouterOS v7-hez hardvertől függően nagyságrendileg 10-15 opcionális csomag létezik. Ha eddig valamelyiket telepíteni akartuk, akkor ki kellett bogarászni a mikrotik.com-ról a megfelelő zip fájlt, ki kellett belőle a csomag fájlt másolni, feltolni a routerre és újraindítani. Ez utóbbit továbbra sem spóroljuk meg, de az előtte lévő összes többi egyszerűsödik: a „Package List” ablakon a „Check for updates” most már nem csak a letölthető OS-eket mutatja meg, hanem a bezárás után a Package List-ben a letölthető csomagokat is, amiket egy Enable-lel és egy restart-tal installálhatunk is.
eSIM
Megjelent az eSIM-ek kezelése. Ehhez hardveres támogatás is kell, szóval jelen sorok írásakor ezt csak akkor tudod kihasználni, ha
- van egy olyan modemed, ami rendelkezik eUICC modullal,
- vagy van egy fizikai eSIM kártyád és erre tudod a RouterOS-ből letölteni az eSIM profilodat.
Viszont hamarosan várhatóak olyan MikroTik eszközök, amik már rendelkeznek eUICC modullal és így tudsz rajtuk majd eSIM-et használni.
Btrfs, swap
Talán láttad már a napokban bejelentett ROSE Data Server (RDS) terméket, az első nagyteljesítményű storage-networking-container platform mindenes eszközt. Ha lemaradtál róla, itt megtalálod szövegesen , itt pedig videó formátumban a főbb tudnivalóit.
Végre! Évek óta kapjuk az olyan új funkciókat, amik jelzik, hogy a MikroTik helyet kíván foglalni a data centerkben és ment a találgatás, hogy vajon mivel is fognak előállni. Hát megjött az első(?) RDS.
A gyártó szerint valószínűleg csak egy dolog hiányzott ahhoz, hogy a termék piacra dobható legyen: egy modern, copy-on write (CoW) alapú fájlrendszer, ami összevetve mondjuk egy extr4-gyel javítja az adatintegrtiást, a skálázhatóságot és adatvédelmi funkciókat ad fs-szinten. Ez lett a Btrfs, aminek könnyű megjegyezni a nevét: butter FS-nek is szokták hívni. Elérhető a 7.18-as RouterOS-től.
Swap: A 7.17-nél elkerülte a figyelmem, hogy elérhetővé vált a swap-olás. Akkor még a continer csomagban volt ez a funkció, de most kikerült onnan és bármelyik hardveren van rá lehetőség: Készíthetünk swap fájlt, vagy akár swap partíciót is. Ebből persze a kisebb telejesítményű routerek is profitálhatnak, hiszen azokon is tudunk virtuális memóriát kezelni, de azért USB kapcsolat esetén ne várjunk csodát, pláne ha 2.0-ás. Én biztosan fogok kísérletezni nagyobb RAM igényű containerek futtatásával, aztán majd kiderül milyen sebességgel fognak ezek menni.
És még valami: tudtad, hogy fel tudsz mount-olni iso és squashfs image-eket? Igazából már ez is a v7.17 óta megvan, de ez is egy olyan dolog, ami nem biztos, hogy feltűnik egy 433 soros changelog-ban. Eddig én se vettem észre.
Cloud file
Még egyszerűbbé vált az, hogy a fájljaidhoz bárhol, bármikor hozzáférj: a Cloud funkció egy fájlkiterjesztést kapott, amivel egyetlen titkos URL segítségével a routered fájljaihoz hozzáférhetsz bárhonnan. Bentről, kintről, tökmindegy, nem kell hairpin NAT-tal, vagy split DNS kutyafülével foglalkozni. Egy hálózatban több fájlszerver routered is lehet, mert mindegyik saját domain nevet kap – én még nem tapasztaltam ebből kavarodást LAN oldali eléréssel sem. A biztonsági aspektusait még nem vizsgáltam. Egyelőre nem találtam a dokumentációban, de úgy látszik, nem működik minden architektúrán. ARM/ARM64-en igen, MIPSBE-n pl. nem. Talán ezzel is az a helyzet, mint a BTH-val és akkor Tilera-n is működik? Hálás vagyok, ha megírod a tapasztalataidat!
Hozzáférés a fájlokhoz a PC-ről LAN oldalról és mobilnetről, azaz külső hálózatról ugyanazzal az URL-lel.
Hasznos továbbiak:
- Automatic Multicast Tunneling (AMT) támogatás – sajnos jelen sorok írásakor még nincs dokumentáció, így erről bővebben később.
- A VXLAN L3 Hw. offload támogatást kapott ezeken az eszközökön.
- in-interface/in-bridge/in-bridge-port mezők támogatása lett hozzáadva a postrouting jellegű chain-ekhez. Ez a gyakorlatban például azt jelenti, hogy srcnat esetén is használható az „In. Interface” mező
- Új csomag ARM/ARM64-re: iot-bt-extra, amivel USB Bluetooth (LE 4.0+) eszközöket kezelhetünk
- hardveres IPSec gyorsítás a hEX refresh modellen
- syslog szervernek CEF formátumban is mehetnek az adatok, valamit TCP is választható lett
- firmware upgrade a 802.3at/bt PoE out eszközökön, azaz kivételesen a rá kötött PD(-k) is újraindul(nak)
- a wifi interfészek Max Clients mezőt kaptak
About the Author: Kalapos László
