( nagylzs | 2021. 06. 20., v – 19:09 )

Nincs mit! Ha az ilyen single bridge + mutliple vlans konfigban akarsz CAPsMAN-t használni, akkor a következőkre kell figyelned.

Tartsd észben, hogy a CAP és CAPsMAN között is van egyfajta kommunikáció (rádiók, kliensek, konfigok egyeztetése stb) valamint a CAP ezen továbbíthatja az összes adatforgalmat a CAPsMAN-nek, vagy nem (local-forwarding beállítástól függően). Ez a kétfajta kommunikáció két külön beállítást igényel.

A CAP és CAPsMAN közötti kommunikációra a dokumentációjuk azt írja, hogy kétféle lehet: layer 3 vagy layer 2. Ha layer 3 módban használod, akkor a /interface wireless cap menüben megadod a "caps-man-addresses" beállítást ( https://wiki.mikrotik.com/wiki/Manual:CAPsMAN#CAP_Configuration ) és így el tudod érni azt, hogy egy tetszőleges távoli CAPsMAN-nel tartsa a kapcsolatot, és onnan vegye a konfigokat. Ha ezt használod, akkor kézzel be kell írnod a CAPsMAN ip címét minden egyes CAP-nál. Viszont így lehetőséged van arra, hogy egy távoli (teljesen másik hálózatban) levő CAPsMAN-t használj. A dokumentáció a layer2 módról csak annyit ír, hogy olyankor nem kell konfigurálni a CAPsMAN címét, de olyankor azonos layer 2 szegmensen kell hogy legyenek.

Amit viszont nem írnak le egyértelműen az az, hogy a CAP és CAPsMAN közötti kommunikáció is IP csomagokat használ. Az igaz, hogy layer2 módban nem IP alapon találják meg egymást, hanem layer 2 broadcast üzenetben. De ahhoz, hogy a CAP és a CAPsMAN össze tudjanak kapcsolódni, szükségük van mindkét oldalon egy IP címre. (Ha nincs mindkét oldalon IP cím, akkor nem fognak tudni ip csomagokat küldeni egymásnak).

Szóval ami a CAP és CAPsMAN közötti adat egyeztetést illeti, ott az kell, hogy legyen megadva mindkét oldalon egy-egy interface, aminek IP címe is kell hogy legyen, és az interface az ráadásul untagged kell hogy legyen, mert a CAP<->CAPsMAN kommunikáció kizárólag untagged csomagokkal működik.

Szóval akár layer 2 akár layer 3 módban akarod használni, azt úgy tudod megtenni, hogy a CAPsMAN -on és a CAP-on is létrehozol egy olyan vlan interface-t (/interface vlan), ami azonos vlan-hoz tartozik és van IP címe. Ez praktikusan a "management" vagy "base" vlan, amit az eszközök beállítására is használsz. Ez a vlan interface elintézi azt, hogy a kimenő csomagokat taggeli, a bejövőeket meg untaggeli, így a CAP/CAPsMAN driver boldog lesz, mert mindent megkap ami kell neki. A discovery-t is erre az interface-re kell beállítani!

/interface wireless cap
set interfaces=wlan1,wlan2 bridge=BR1 certificate=request enabled=yes discovery-interfaces=BASE_VLAN

Ha a discovery-interfaces beállításba nem egy vlan interface-t írsz bele, hanem mondjuk egy trunk porthoz tartozó interface-t, akkor nem fog menni. Ez azért van, mert a cap/capsman mindig untagged csomagokkal kommunikál.

Nagyon fontos dolog, hogy mindeez csak arra kell, hogy a CAP és a CAPsMAN egyeztessék az adatokat egymás között. Ettől teljesen független az a kommunikáció, ami local fowarding módban a csatlakoztatott wifi kliensek és a wlan eszközök között megy. Ami azt a részét illeti, ott nincsen szükség IP címekre. Sőt, valójában káros lenne ha megadnál IP címeket, mert akkor az (egyébként csak access point-ként használt) router elkezdene route-olni.

A wlan interface-eket a CAP-okon soha ne add hozzá a bridge-hez. A CAP adja hozzá őket magától a megfelelő vlan id-vel. Ezt úgy tudod jól beállítani, hogy a datapath beállításban megadod a vlan-mode=yes és vlan-id=XX értékeket. Sok különböző datapath beállítást fölvehetsz. Példa data path-okra:

/caps-man datapath
add local-forwarding=yes name=datapath-blue vlan-id=10 vlan-mode=use-tag
add local-forwarding=yes name=datapath-green vlan-id=20 vlan-mode=use-tag
add local-forwarding=yes name=datapath-red vlan-id=30 vlan-mode=use-tag

Az is nagyon érdekes dolog, ahogy a CAPsMAN ilyenkor a bridge vlan táblázatokat kezeli. Először is, soha ne csinálj olyat egy CAP eszközön, hogy a vlan táblázatban egy sorba veszel föl több vlan-id -t.

Szóval például ilyet soha ne csinálj:

/interface bridge vlan
add bridge=BR1 tagged=BR1,ether1-trunk vlan-ids=10,20,30

 

Helyette MINDIG minden vlan-t külön sorba kell tenned:

/interface bridge vlan
add bridge=BR1 tagged=BR1,ether1-trunk vlan-ids=10
add bridge=BR1 tagged=BR1,ether1-trunk vlan-ids=20
add bridge=BR1 tagged=BR1,ether1-trunk vlan-ids=30

Ez azért szükséges, mert amikor a CAP provision-öl egy rádiót, és azt látja hogy a datapath-ban vlan-mode=yes van megadva, akkor abba a vlan sorba teszi be, amelyikben benne van a megfelelő vlan id. De ha egy sorban több vlan id-t is megadtál, akkor úgymond "elromlik", mert akkor a vlan táblázatok alapján olyan vlan-okba is engedélyezi a kommunikációt, amibe a datapath beállítás alapján nem lenne szabad. Nem tudom hogy ez bug van nem, mindenesetre érdekes.

Azután ott van az az "érdekesség", hogy ezek olyan **dinamikus** bejegyzések, amiket a CAP belerak egy **statikus** vlan sor belsejébe. Szóval nem azt csinálja hogy létrehoz egy új sort neki, hanem egy létező sorba teszi bele. Ezért ez a vlan sor félig statikus, félig dinamikus lesz.

Ha megnézed a vlan táblázatot az ssid-khez generált slave wlan interface-ekkel, akkor ilyesmit fogsz látni:

 

/interface bridge vlan> print
Flags: X - disabled, D - dynamic
 #   BRIDGE                       VLAN-IDS  CURRENT-TAGGED                       CURRENT-UNTAGGED
 0   BR1                          10        BR1
                                            ether1-trunk
                                            wlan2
                                            wlan1
 1   BR1                          20        BR1
                                            ether1-trunk
                                            wlan24
                                            wlan25
 2   BR1                          30        BR1
                                            ether1-trunk
 3   BR1                          99        BR1
                                            ether1-trunk

Ebben ugye az a vicces, hogy a wlan -os interface-ek valójában dinamikusak, de a "D - dynamic" flag mégse jelenik meg sehol. :-) Csak úgy tudod biztosan megmondani hogy melyik része dinamikus, hogy csinálsz egy /interface bridge export -ot is, és összehasonlítod őket.

 

Azután itt van még az az érdekesség, hogy az összes wlan eszközt tagged member-ként teszi bele. (Látod, wlan2 a "CURRENT-TAGGED" oszlopban van.) Ami első ránézésre meglepő lehet, hiszen (nyilván) nem olyan ssid-t szeretnél csinálni, amiben tagged csomagok mennek.

Nos az a helyzet, hogy valóban nem tagged csomagok mennek benne, viszont az ilyen dinamikusan hozzáadott wlan eszközöknél nem a bridge csinálja az untagging-ot, hanem a wireless driver. A bridge szempontjából nézve a wlan interface-re tagged csomagok mennek, és onnan tagged csomagok érkeznek be. De az "éterben" már nem tagged csomagok lesznek.

(Egyébként azt is meg lehet csinálni hogy az "éterben" is tagged csomagok legyenek, de olyat CAPsMAN nem tud, azt csak minden eszközön külön tudod konfigurálni.)

 

Na, elkopott az ujjam.