Vissza az ingyenes tartalmakra

A Mizu MikroTik sorozat a RouterOS legfontosabb változásairól szól. A sorozatban az új funkciókra koncentrálunk, a javításokat csak nagyon indokolt, sokakat érintő esetben említek meg. Ebben a részben a 7.16 kerül terítékre:

Bridge változások:

1. Fenntartott címek továbbítása. Vannak bizonyos multicast MAC címek (01:80:C2:00:00:0x), amikkel egy-egy protokoll működik, pl. STP, LACP, dot1x, LLDP, stb. Eddig, ha a bridge protocol-mode-ja none volt, tehát nem használtunk pl. RSTP-t, akkor a bridge ezeket a forgalmakat minden esetben továbbította. Mostantól, ha a bridge protocol-mode-ot none-re állítjuk, akkor eldönthető, hogy a fenti üzeneteket továbbítsa a bridge, vagy sem (Forward Reserved mező)

2. Maximálisan tanulható MAC címek száma: be lehet állítani, hogy a bridge összesen hány MAC címet tanulhasson meg. Auto esetén a szabad memóriától függ, de bármilyen egész szám beírható. Személyes véleményem szerint hasznosabb lenne, ha az egy porton megtanulható MAC címek számát lehetne egyszerűen korlátozni – na talán egy következő kiadásban.

3. Kommentek arról, hogy miért jött létre egy dinamikus VLAN bejegyzés: az MVRP megérkezésével nőtt azon funkciók száma, ami bridge-ek VLAN táblájában dinamikus VLAN bejegyzést tud létrehozni. Hogy lássuk egy dinamikus VLAN bejegyzésről, hogy az miért is jött létre, ezek automatikusan kommentet kapnak, ahogy az alábbi képen is látható:

Let’s encrypt: bye-bye HTTP!

Az, hogy a v7-ben tudunk egyszerűen Let’s Encrypt-es certificate-et igényelni, (7.15-től pedig más szolgáltató is megadható lett) az alapvetően egy tök jó dolog. Viszont, ha eddig tanúsítványt igényeltünk, vagy megújítottunk, akkor legalább arra az időre nyitva kellett lennie a TCP 80 (www) szolgáltatásnak a routeren. Ez mostantól megszűnhet, de cserébe az igénylésre/megújításra használt parancson kicsit módosítani kell, és így kell kinéznie:

/certificate/enable-ssl-certificate type=cloud-dns

DNS újdonságok:

Egyrészt DoH (DNS over HTTPS) + Adlist és DoH + statikus FWD bejegyzés támogatás érkezett, másrészt pedig mDNS. Ez utóbbiról: eddig ugye kényelmetlenség volt akkor, ha volt mondjuk két LAN-od, és az egyiken lévő eszközről a neve alapján akartál megszólítani egy másikon lévő eszközt. Mondjuk név alapú megosztások kezelése két LAN, vagy VLAN-ok esetén. Eddig az lehetett a megoldás, ha pl. DNS-be (akár a router DNS-ébe, statikus bejegyzésként) felvetted a LAN oldali eszközeidet, vagy akár olyan script-et futtatál a DHCP lease-ek létrejöttekor, ami a hosztnevet beírta a router DNS bejegyzései közé.

Mostantól a megoldás egyszerűbb: a kulcs az mDNS (multicast DNS), ami alapvetően arra lett kitalálva, hogy egy hálózatban lévő eszközök megtudják egymásról, hogy egy névhez milyen IP tartozik. Pl. Windows-os gépek is ezzel oldják fel egy LAN-on belül egymás neveit (illetve ez az egyik mód rá), de az mDNS kérések egyik hálózatból a másikba nem mennek át. v7.16-tól viszont a routerünk mDNS repeater-ként viselkedhet, azaz egy interfészen bejövő mDNS kérést át tud dobni más interfész(ek)re, és persze a válasszal is ugyanezt teszi.

mDNS repeater beállítása után a 192.168.110.0/24-es hálózatban lévő gépemről el tudom érni név alapon a másik LAN-omon lévő másik gépemet.

„Ez meg melyik portra van dugva?”

Egyszer egy hazai viszonylatban közepesen nagy hálózaton kértek tőlem segítséget, hogy közösen rakjunk rendbe bizonyos dolgokat, szüntessünk meg anomáliákat. Álltunk a rack szekrény előtt és megkérdeztem a rendszergazdát: „Hova megy ez a kábel?” „Nem tudom” „És ez?” „Nem tudom”

Az LLDP egy olyan neighbor discovery protokoll, ami az MNDP-vel szemben sok eszközön ismert és egy rakás olyan plusz dolgot el tud mondani a szomszédos eszközökről, ami hasznos lehet. Melyik eszköz melyik portájára vagyunk csatlakozva, vagy melyik porton érünk el más eszközöket? Mik az interfész képességei? Aktuális link sebesség, duplexitás állapota mondjuk egy access és egy core switch között?

Az LLDP eddig is benne volt a RouterOS-ben, de még nem írtam róla, úgyhogy itt az ideje, mert megint kapott újabb funkciókat, mégpedig VLAN infókat adhat vissza: pl. egy router adott interfészén milyen VLAN-ok vannak, milyen protokollal, milyen IP címmel.

Nagyon hasznos lehet ez az egész, ha mondjuk átveszel egy hálózatot és fel kell térképezni olyan szinten, hogy mi milyen portra van bekötve. Mutatok is három megoldást, amivel ezeket az infókat kinyerheted:

– az új, most még beta állapotú Winbox is megmutatja a portokat a neighbor discovery-ben

– Fogalmam sincs, hogy a Winbox mennyire szereti felfedezni más gyártók LLDP képes eszközeit, ezért mutatok egy általános megoldást is, ami viszont nem ad vissza minden adatot, talán azért, mert egy ideje nem lett fejlesztve az alkalmazás: https://github.com/chall32/LDWin

– A harmadik megoldással pedig az előbb említett plusz infók is megkaphatók, alkalmazás letöltés nélkül, szöveges formátumban. https://alanjmcf.wordpress.com/2022/04/15/lldp-cdp-on-windows-with-no-extra-software/

Az LLDP képességeinek bővítése (IP->Neighbors->Discovery Settings) véleményem szerint nagyon nagy segítséget nyújthat, ha fel kell térképezned egy hálózatot. Mivel az LLDP-t más gyártmányú eszközök is ismerhetik, így jó eséllyel teljes feltérképezést tudunk csinálni. Ugyanakkor nem véletlen, hogy ezek a plusz képességek alapból tiltva vannak a RouterOS-ben és javaslom, hogy a feltérképezés után ezeket állítsd is vissza az alapértelmezett értékekre, azaz kapcsold ki!

Apróságok:

• az IKEv2 multicore támogatását javították, így a key exchange gyorsabb lehet többmagos CPU esetén
• max-sessions beállítási lehetőség a menedzsment szolgáltatásokra (IP->Services) egyelőre csak CLI-n. Az alapértelmezett max konkurens session-szám 20 lett.
• CLI lock-olás a :lock paranccsal
• a netwatch DNS probe lehetőséget kapott
• ax-es (wifi 6-os) eszközökre megérkezett a spectral-scan és a spectral-history

• import futhat a dry-run kapcsolóval, így nem importál, viszont ellenőrzi, hogy van e szintaktikai hiba a fájlban

Vissza az ingyenes tartalmakra