Mikrotik VLAN bridge-elve 2 router között...

Sziasztok!

 Az alábbi témában szeretném a segítségeteket kérni. Szeretnék összekötni 2 db Mikrotik router-t VLAN-okkal és szeretném ha az alábbi módon látnák egymást:

 1-es router:
 - 1-es port: WAN
 - 2-es port összekötve a 2-es router-rel
 - 3-as és 4-es port: VLAN 100
 - 5-ös port: VLAN 200
 - wifi1: VLAN 250
 - wifi2: VLAN 250

 2-es router:
 - 1-es port: VLAN 250
 - 2-es port összekötve az 1-es router-rel
 - 3-as és 4-es port VLAN 100
 - 5-ös port: VLAN 200
 - wifi1: VLAN 250
 - wifi2: VLAN 250

 IP tartományok:

 VLAN 100: 192.168.100.0/24
 VLAN 200: 192.168.200.0/24
 VLAN 300: 192.168.250.0/24

 Router1-en legyen a DHCP és mindhárom VLAN-ba osszon IP-t. Az IP-i:
 - VLAN 100: 192.168.100.254
 - VLAN 200: 192.168.200.254
 - VLAN 250: 192.168.250.254

 Értelemszerűen fontos hogy lássák egymást a 2 router-en lévő azonos VLAN-ban lévő gépek. Megoldható hogy a VLAN 100-ból a VLAN 200 és 250 felé lássunk, de vissza nem? Gondolom ez csak tűzfallal lesz lehetséges. Bridge-elve kellene megoldani, hogy ne legyek hardverhez kötve.

Köszönöm előre is a segítséget!

Hozzászólások

Nem igazán volt információdús a válasz, ezeket én is megtaláltam. Külön kértem hogy bridge-elve legyen megoldva és ne switch-elve, hogy ne legyen hardverhez kötve. Szerintem részletesen leírtam hogy mit szeretnék. Erre nincsen külön leírás. Rengeteg videót és leírást átnéztem, ehhez hasonló pont tényleg nincs, vagy még nem találtam meg. Azért köszi.

Bridge-elve kellene megoldani, hogy ne legyek hardverhez kötve.

Szerintem ezt ki kellene fejtened, hogy pontosan mit is szeretnel, es mit miert gondolsz ugy ahogy.

Igyekszem. Megoldja az egyik srác ebben a videóban:

https://www.youtube.com/watch?v=V9Ks2MaBMoM

Nagyon hasonlót készít és az működik is. Ha megnézed az Ő leírását, akkor nála az 1-es router-ben nincsen más eszköz (1-es a WAN, 3-as a trunk), én viszont szeretnék oda is tenni eszközöket. Mondjuk a 2-es portra a VLAN20-ast (maradva az Ő leírásánál). A 4-esre pedig a 40-est. A 2 wifi adapter már könnyű utána hozzáfűzni. Ennél részletesebben nem tudom hogy hogyan kellene kifejtenem, de adj kérlek támpontot. Köszönöm.

Nem ismerem a Mikrotik-et, de kb minden switch képességekkel is rendelkező router tud trunk portot (dot1q vagy tagged), ez kell neked a két router között. A többi port mehet a megfelelő VLAN-ba, mint access port (untagged). A bridge-et felejtsd el, ma már nem használják (kivéve a wifi-n, de azzal külön nem kell foglalkoznod). Az eszközfüggetlenség abban áll, hogy az access portokra bármilyen eszközt rádughatsz.

Szerintem az a megtévesztő, hogy a Mikrotik-nál 2 db chip van benne. Az egyik a switch chip (ez az ami hardverfüggő) és van a router chip (CPU), ami hardverfüggetlen. Amikor bridge-elve oldom meg, akkor az a Mikrotiknál annyit jelent, hogy a CPU számol és naplózható. Valószínűleg ezt nem értette willy sem. Az elvet tudom és értem, de ez Mikrotik, ahol minden kicsit másképp működik. Azért köszönöm.

Pontosan értettem amit kérdeztél. De nem jól állsz hozzá, nincs benne semmilyen előny.  Az első linket ha lejjebb görgeted ott látsz egy olyan megoldást ami ezt takarja. Nagyon nem javasolt. Egyel jobb változat ami 

https://wiki.mikrotik.com/wiki/Manual:Interface/Bridge#Bridge_VLAN_Filt…

De szólok, hogy ez sem teljesen hardver független, de talán teljesíti az igényeidet ha nem tekintjük miket vesztesz azzal a teljesen felesleges igényel amit támasztottál.

*a kényelmetlenséget neked az okozza, hogy izolált hálózatokat szeretnél létrehozni amikor nem rakhatod egy bridge-be őket. Ez megoldható, ha létrehozod a vlan interface-eket a trunk protra és azokat teszed be az egyes bridge-ekbe amiket a vlan-okre létrehoztad. Elég sok szívás előtt állsz 

Érdekes az arroganciád ebben a helyzetben, mikor egy alapvetően igen egyszerű dolgot kérdezel meg, de nem tetszik az alapvetően egyszerű válasz.

Nem működik "kicsit másképp" a MT. Sőt, a felhasználónak pont ugyan úgy kell a konfigurációt megírnia minden eszközre, és az OS dönt, hogy tud-e hardware offload-ot csinálni, vagy CPU-ból kell megoldania a feladatot. Minden switch-ben van CPU is és valamilyen ASIC is (esetleg integrálva egy IC-re), ez nem MT jellegzetesség. Router esetén lehet olyan, hogy csak CPU van (pl. CCR10xx sorozat), nincs mellette külön switch ASIC.

Egy ilyen felállásnál nagyon nem mindegy az eszköz választás, mert a jó switch-ek gyengék CPU-ban (így router-nek nem jók), az erős CPU-s router-ek meg gyengék switch oldalon (így azokon natív HW VLAN-ozás nagy teljesítménnyel általában nincs). De ez minden más gyártónál is így van, nem azonos feladatra szánják az eszközöket. Azért nem mindegy a konkrét eszköz (amit nem specifikáltál), mert ugyan azzal a konfigurációval menni fog az összes fajta eszköz, csak a teljesítményük fog durván eltlérni a hardveres képességek különbsége miatt. Mikrotik switch vonalon durva különbség van a CRS1xx-2xx és a CRS3xx vonal között, az utóbbi az újabb sorozat, jelentős HW gyorsítási (offload) képességekkel.

Amit leírtál, egyébként sima layer 2 switch feladat, VLAN-okkal, és trunk, access port konfigurációkkal.

Az IP tartományok közötti átjárás korlátozás meg layer 3 router feladat, ezt bridge filterrel finoman szólva sem lenne praktikus megoldani (de egy része úgy is menne). Általában igaz lesz, hogy bármely MT switch nem fog tudni 1 GbE sebességgel sem route-olni két VLAN IP tartománya között, ezt vedd figyelembe.

 Általában igaz lesz, hogy bármely MT switch nem fog tudni 1 GbE sebességgel sem route-olni két VLAN IP tartománya között, ezt vedd figyelembe.

Gyakorlatilag bármely MT switch-re igaz, hogy (CPU-n keresztül) route-olni biztosan nem fog 1GbE sebességgel.
Ezt annyival kiegészíteném, hogy (elvileg ROS7-től) a CRS3xx fog tudni wirespeed routing-ot bizonyos körülmények esetén:
https://wiki.mikrotik.com/wiki/Manual:CRS3xx_series_switches#L3_Hardwar…

Ez azért így ebben a formában nem igaz. Az RB4011 1500byte-os csomagoknál majdnem 10Gbit-et tud routing-olni, de ha beleraksz 25 tűzfal szabályt és 64 byte-os mini csomagokat küldesz neki, akkor is majdnem 3Gbit-et tud. (Lásd: https://mikrotik.com/product/rb4011igs_rm#fndtn-testresults ) Mindezt $199-ért. :-D

Szerintem arra gondolt, hogy vlan -t be lehet állítani switch chip-pel és bridge-el is, de a kettőt nem használhatod egyszerre (mert akkor nem működik).

Személyes véleményem a switch chip vs. bridge (CPU) based vlan-ról a hw offloading-ról:

  • VLAN-t akkor használ az ember, ha van egy csomó eszköze és portja. Ha összesen 5 portod/eszközöd van, akkor csak nagyon speciális esetben éri meg vlan-t használni; általában kiváltható tűzfal szabályokkal. A vlan akkor kezd érdekes lenni, ha van jó pár aktív eszközöd (több router és switch), és a különféle "kategóriába" tartozó eszközök hálózatait el akarod egymástól szeparálni.
  • Ez a szeparálás általában nem 100%-os, szükség van a VLAN-ok közötti átjárásra. Ez az átjárás mindig routing-ot jelent, és nem switching-et. A routing az mindig CPU-hoz kötött, szóval a VLAN-ok közötti kommunikáció szempontjából nézve a hw offloading teljesen irreleváns. A hw offload-ból kizárólag akkor tudsz profitálni, ha a VLAN-on belüli belső forgalom nagysága messze meghaladja a VLAN-ok közötti, illetve az internet irányába menő / onnan jövő forgalmat.
  • Természetesen van értelme otthoni felhasználásra is VLAN-okat létrehozni. De ott elsősorban olyan célokra szokás használni, hogy pl. IoT eszközök hálózata el legyen szeparálva PC-től, és ne egy béna soha nem frissített firmware-ű okosporszívón keresztül lopják el az adataidat. Ezekre az otthon felhasználásokra az jellemző, hogy az ilyen okból (értsd: megbízhatatlan eszközök okán) elszeparált hálózatokon egyébként is alig van forgalom. Vagy ha mégis van, akkor az jellemzően nem VLAN-on belüli, hanem az internet felé vagy az internet felől érkezik, ezért általában szinte mindegy, hogy van-e hw offloading vagy nincs.
  • Annál a felhasználási módnál, amibel egy VLAN-on belül sok forgalom van, már megmutatkoznak a hw offload teljesítménybeli előnyei. Különösen nagy előnyt jelenthet a broadcast forgalom korlátozása VLAN-on belülre. Ezeknél a felhasználásoknál sok csomópont van, és sok ethernet port. Egyébként otthon is van ilyen, például otthoni IP kamera rendszer is tud sok csomópontot használni és nagyobb forgalmat generálni. De ezeknél a felhasználásoknál a sok port eleve kizárja azt, hogy az ember egy-két router-t használjon. A router-eknek ne szokott 20-30 portja lenni. Vagy ha mégis, akkor az vagy egy "okos switch" vagy "cloud switch", és valójában nagyrészt switching-re használják; vagy egy adatparkokba való sok processzoros szörny amit otthonra úgyse szerel be senki.

Ha annyira aggódsz az inter-vlan sebesség miatt, akkor vegyél egy 15 ezer forintos vlan képes switch-et (pl. RG260GS), és ezzel automatikusan megoldódik a hw offload kérdése. Erre egyébként is valószínűleg szükséged lesz akkor, ha TÉNYLEG a vlan-on belüli forgalmad a nagy. Szerintem ez a hw offload kérdés dolog túl van hype-olva, legalábbis otthoni felhasználás esetén biztosan.

Szerkesztve: 2021. 06. 15., k – 12:58

Szerintem ez kb ugyanaz a setup mint amit elmagyaraznak a bridge vlan filtering wiki cikkben: https://wiki.mikrotik.com/wiki/Manual:Interface/Bridge#Bridge_VLAN_Filt…

De amugy a recept a kovetkezo:

1. Csinalsz annyi bridge-et mindegyik routeren amennyi VLAN-t akarsz

2. A portoknal beallitod a PVLAN ID-t a megfelelore ha untagged a port, trunk portnal berakod a bridge-be a portot tagged-kent

3. Bekapcsolod a bridge vlan filteringet

4. profit

Szerk: most abba ne menjunk bele hogy ha van bridge, akkor ertelemszeruen arra kell rakni a dhcp service-t mert a fizikai portok ilyenkor slave mode-ba kerulnek es azokkal nem fog menni, de gondolom ezeket mar csak ossze tudod rakni ha a bridge vlan filtering mukodik.

Ezt is próbáltam. Az a baj, hogy a VLAN-on keresztül nem megy a kommunikáció a portok között. Ha belerakom a bridge-be a portokat (pl: ether2, ether3 és vlan100), akkor sem a DHCP nem megy (vlan100-on), sem a portok nem kommunikálnak egymással. Sima bridge-el ez gond nélkül működik. Egyenlőre azt nem értem hogy hogyan lehet a VLAN-on keresztül komminukálni az adott router-en belül. A másik router-rel megy a VLAN. Ezt hogyan kellene változtatnom hogy működjön?

 

/interface bridge
add name=bridge1 vlan-filtering=no
  • Add bridge ports and specify pvid for VLAN access ports to assign their untagged traffic to the intended VLAN.
/interface bridge port
add bridge=bridge1 interface=ether2
add bridge=bridge1 interface=ether6 pvid=200
add bridge=bridge1 interface=ether7 pvid=300
add bridge=bridge1 interface=ether8 pvid=400
  • Add Bridge VLAN entries and specify tagged and untagged ports in them.
/interface bridge vlan
add bridge=bridge1 tagged=ether2 untagged=ether6 vlan-ids=200
add bridge=bridge1 tagged=ether2 untagged=ether7 vlan-ids=300
add bridge=bridge1 tagged=ether2 untagged=ether8 vlan-ids=400
  • In the end, when VLAN configuration is complete, enable Bridge VLAN Filtering.
/interface bridge set bridge1 vlan-filtering=yes

 

Köszi!

Szerintem itt azért nem ment neked a vlan-ok közötti kommunikáció, mert a vlan táblád rossz. A "tagged" részhez nem adtad hozzá a bridge-t. Ennek valahogy így kellene kinéznie:

 

/interface bridge vlan
add bridge=bridge1 tagged=ether2,bridge1 untagged=ether6 vlan-ids=200
add bridge=bridge1 tagged=ether2,bridge1 untagged=ether7 vlan-ids=300
add bridge=bridge1 tagged=ether2,bridge1 untagged=ether8 vlan-ids=400

 

Ha a bridge-t nem adod hozzá tagged member-ként a vlan táblázathoz, akkor az a csomag ami egyik vlan-ból át kellene hogy menjen a másikba, nem tud hol átmenni. Ha ez még így mindig nem világos hogy miért, akkor gondold át ezeket:

  • a bridge arra való, hogy különböző layer 2 hálózatok között képezzen egy hidat
  • ha a te konfigodban megnézed például a vlanid=200 sort, akkor azt látod, hogy ehter6 untagged, ether2 tagged member-je ennek a vlan-nak.
  • ezután tedd föl a kérdést: van másik member ehhez a vlan-hoz? (nincs)
  • akkor átmehet-e a vlanid=200-hoz tartozó csomag mondjuk a vlanid=300-hoz tartozó ether7 portra? Nem mehet át, mert ezek külön layer2 hálózatok. Bár az igaz hogy ez nem fizikailag különálló layer2 hálózat, hanem csak virtuális. De ez nem lényeges. Ha külön vlan-ban vannak, akkor az az alapértelmezés, hogy nincs közöttük átjárás.
  • Az ether2 se biztosít átjárást, mert az egy tagged port. Bár az igaz, hogy az ether2 porton kimehetnek többféle vlan-hoz tartozó csomagok is, de ezek kizárólag tagged csomagok lehetnek, és el vannak különítve. Ami az ether2 porton vlanid=100 csomagként megy ki, az a vezeték másik oldalán is vlanid=100 csomagként érkezik be.
  • Szóval ezek a vlan-ok úgy viselkednek, mintha fizikailag külön hálózati szegmensek lennének, és igazából éppen ezt akartuk elérni, amikor bevezettük a vlan-okat!
  • A kettő közötti átjárást csak akkor tudod biztosítani, ha hozzáadsz egy hidat, tehát tagged=bridge1 is szükséges ahhoz, hogy átjárás legyen a különböző vlan-ok között
  • Viszont ez a "bridge CPU member" azt is jelképezi, hogy a csomag átmegy a switch -ből a CPU-ba, és szoftveres úton van kezelve. Ez teszi lehetővé azt, hogy rendes, szabályokon alapuló csomagszűrést végezz.
  • Ez semmiben nem lassítja a kommunikációt, mivel a vlan-ok közötti adatforgalom ígyis úgyis CPU-ba menne át. Még akkor is, ha egyébként semmiféle szűrést nem alkalmazol, és teljesen szabad átjárást szeretnél 2 vlan között. (Bár ha ez a helyzet, akkor fölmerül a kérdés, hogy minek neked 2 külön vlan?)

Ha esetleg fölmerülne benned az a kérdés, hogy "miért kell hozzáadnom tagged portként a bridge-t, hiszen már megadtam hogy bridge=bridge1", akkor pedig jusson eszedbe a a következő. Egy ilyen eszközt használhatsz router-ként, és switch-ként is. Adott esetben tök jó dolog lehet, hogy mondjuk egy wifis mikrotik router-t be tudsz úgy állítani, hogy wifi access point-ként és vlan képes switch-ként működjön, viszont ne routing-oljon és ne bridge-eljen a különböző vlan-ok között. (Ez egy teljesen életszerű példa.) Ha nem kellene explicit módon hozzáadnod a hidat a vlan táblázathoz, hanem ez automatikus és implicit lenne, akkor sehogy nem tudnál beállítani olyan konfigot, amiben kizárólag switch-ként használod a switch chip-et, és a vlan-ok összekötését meg egy másik eszközre bízod.

Rosszul csinalod ha 1 bridge-be akarod berakni az osszes vlan-t, kulon bridge-eket kell csinalni nekik; itt van az enyembol a bridge config, probald meg ez alapjan atirni (annyi hogy nalam capsman van es az automatikusan beteszi a wifi ssid-ket a megfelelo bridge-re a capsman eszkozon):

 

/interface bridge
add name=bridge-guest protocol-mode=mstp pvid=3 vlan-filtering=yes
add admin-mac=xx:xx auto-mac=no igmp-snooping=yes name=\
    bridge-internal protocol-mode=mstp vlan-filtering=yes
add name=bridge-iot protocol-mode=mstp pvid=2 vlan-filtering=yes
add name=bridge-vpn

...

/interface bridge port
add bridge=bridge-internal comment=defconf interface=ether2
add bridge=bridge-guest comment=defconf ingress-filtering=yes interface=\
    ether4 pvid=3
add bridge=bridge-iot comment=defconf interface=ether5 pvid=2
add bridge=bridge-iot comment=defconf interface=ether6 pvid=2
add bridge=bridge-iot comment=defconf interface=ether7 pvid=2
add bridge=bridge-internal comment=defconf interface=sfp-sfpplus1
add bridge=bridge-internal interface=*E
add bridge=bridge-internal interface=ether3
add bridge=bridge-guest interface=*10 pvid=3
add bridge=bridge-iot interface=*F pvid=2
add bridge=bridge-internal interface=ether8
add bridge=bridge-internal interface=ether9
add bridge=bridge-internal interface=ether10

...

/interface bridge vlan
add bridge=bridge-internal comment=Internal untagged=\
    bridge-internal,*E,ether2,ether3 vlan-ids=1
add bridge=bridge-guest untagged=*10,bridge-guest vlan-ids=3
add bridge=bridge-iot untagged=*F,bridge-iot vlan-ids=2

Szerintem elbeszélünk egymást mellett. Mégegyszer megpróbálok leírni egy nagyon egyszerű változatot. Adott 1 db Mikrotik router, 5 db lan porttal. Szeretném összekötni az ether3, ether4 és ether5 portjait egy VLAN 100-as hálózaton. Egyenlőre ez a VLAN 100 itt jön létre és nem megy sehová, csak összeköti a 3 db portot (ha muszáj mennie, akkor az ether2-n menjen ki). Kellene hozzá 1 db DHCP szerver, ami IP-t is oszt a 3 db gépnek, ami az ether3-tól ether5-ig van rákötve. Fontos hogy az összekötött VLAN interface kikapcsolásánál szűnjön meg a 3 db port között az elérés. Remélem így már érthető. Ha ez megvan, akkor szerintem menni fog a küldés a másik routerre. Lassan nem tartom kizártnak, hogy a Mikrotik csak a switch chip segítségével tudja megoldani, mert nagyon sok leírást néztem, de erre nem találtam még példát. Köszi előre is!

Hm, a Mikrotik eseteben nincs olyan hogy "helyi" VLAN, az a bridge. Csinalsz egy bridge-et amibe berakod azt a 3 db portot es ennyi. Ha ki kell mennie, akkor vagy untagged vagy tagged portokon keresztul tud kimenni.

A VLAN annyit csinal hogy a csomag elejehez hozzabiggyeszt 2 byte-ot, de eszkozon belul ez teljesen felesleges, csak akkor van ertelme ha kimegy az eszkozrol egy masikra, aminek tudnia kell hova tenni azt a csomagot.

A peldaddal elve csinalsz egy bridge-et amibe berakod untagged portkent ether3-5-ig az interface-eket, raultetsz egy dhcp szervert a bridge-re es end of story. 

Azt hiszem kezdem érteni. Vagyis csak simán csinálok egy bridge-t, ahová bedobálom a portokat. Viszont mi mondja meg hogy ha ether2-n megy át a VLAN, akkor az ether3 elérje a másik router-be kötött ether3-at? Ugyanis nálam sajnos nem éri el. (hiába van mindkettő 100-as VLAN-ra állítva). Továbbá a VLAN-ba küldött DHCP-t sem kapja meg az ether3-as port. Hogy tudom összefűzni a "helyi" portot a "távoli" porttal? Illetve hogyan tudnék 1 db DHCP-t használni a helyi és a távoli VLAN 100-ra? Köszi!

Bocs de most nem tudom megnezni a videot, a lenyeg a kovetkezo: egy bridge az egy broadcast domain. Ha egy eszkozon talalhato bridge-et elerhetove akarsz tenni egy masik eszkozon, akkor vagy osszekotod direktben (es akkor az untagged portokat, amikkel oszkototted, azokat belepakolod a bridge-ekbe mindket oldalon) vagy osszekotod vlan-nal. Utobbi esetben a bridge-nek (!) bealitasz egy VLAN ID-t es beleteszel egy tagged portot, es a tagged portra a bridge vlan id-je altal tagelt csomagokat fogja kikuldeni, amit a tuloldalt hasonlo logikaval tudsz kezelni.

A lenyeg az hogy ne csinalj vlan tipusu interface-t mert csak felrevezet (duplan fogja tagelni), oldd meg csak bridge-ekkel a dolgot.

Csak most kapcsolódok be a témába, nem olvastam végig az egészet. Szerintem nem kell minden vlan-nak külön bridge. Elég egyetlen egy bridge-et létrehozni.

A kérdező VLAN-okra akarja tenni a wifi hálózatokat is, ezért a switch chip based vlan filtering nem fog jól működni. Ha rám hallgatsz, akkor CPU/bridge filteringet csinálsz, és egyetlen bridge-be teszed az összes interface-t minden router-en.

De tudod. Nekem van ilyen hálózatom, és remekül működik.

Példa konfig, közvetlenül a korábban említett topic-ból kimásolva alább.

Nálam is ez alapján van beállítva, de nem pont ilyen. (Nálam vannak access és trunk portok is, több router-en és switch-eken is. Plusz van több virtual AP különböző vlan-okon CAPsMAN-nel.) Érdemes bekapcsolni az ingress filteringet is.
 

###############################################################################
# Topic:		Using RouterOS to VLAN your network
# Example:		Switch with a separate router (RoaS)
# Web:			https://forum.mikrotik.com/viewtopic.php?t=143620
# RouterOS:		6.43.12
# Date:			Mar 28, 2019
# Notes:		Start with a reset (/system reset-configuration)
# Thanks:		mkx, sindy
###############################################################################

#######################################
# Naming
#######################################

# name the device being configured
/system identity set name="Router"


#######################################
# VLAN Overview
#######################################

# 10 = BLUE
# 20 = GREEN
# 30 = RED
# 99 = BASE (MGMT) VLAN


#######################################
# Bridge
#######################################

# create one bridge, set VLAN mode off while we configure
/interface bridge add name=BR1 protocol-mode=none vlan-filtering=no


#######################################
#
# -- Trunk Ports --
#
#######################################

# ingress behavior
/interface bridge port

# Purple Trunk. Leave pvid set to default of 1
add bridge=BR1 interface=ether2
add bridge=BR1 interface=ether3
add bridge=BR1 interface=ether4
add bridge=BR1 interface=ether5
add bridge=BR1 interface=ether6
add bridge=BR1 interface=ether7
add bridge=BR1 interface=sfp1

# egress behavior
/interface bridge vlan

# Purple Trunk. These need IP Services (L3), so add Bridge as member
add bridge=BR1 tagged=BR1,ether2,ether3,ether4,ether5,ether6,ether7,sfp1 vlan-ids=10
add bridge=BR1 tagged=BR1,ether2,ether3,ether4,ether5,ether6,ether7,sfp1 vlan-ids=20
add bridge=BR1 tagged=BR1,ether2,ether3,ether4,ether5,ether6,ether7,sfp1 vlan-ids=30
add bridge=BR1 tagged=BR1,ether2,ether3,ether4,ether5,ether6,ether7,sfp1 vlan-ids=99


#######################################
# IP Addressing & Routing
#######################################

# LAN facing router's IP address on the BASE_VLAN
/interface vlan add interface=BR1 name=BASE_VLAN vlan-id=99
/ip address add address=192.168.0.1/24 interface=BASE_VLAN

# DNS server, set to cache for LAN
/ip dns set allow-remote-requests=yes servers="9.9.9.9"

# Yellow WAN facing port with IP Address provided by ISP
/ip address add interface=ether1 address=a.a.a.a/aa network=a.a.a.0

# router's gateway provided by ISP
/ip route add distance=1 gateway=b.b.b.b


#######################################
# IP Services
#######################################

# Blue VLAN interface creation, IP assignment, and DHCP service
/interface vlan add interface=BR1 name=BLUE_VLAN vlan-id=10
/ip address add interface=BLUE_VLAN address=10.0.10.1/24
/ip pool add name=BLUE_POOL ranges=10.0.10.2-10.0.10.254
/ip dhcp-server add address-pool=BLUE_POOL interface=BLUE_VLAN name=BLUE_DHCP disabled=no
/ip dhcp-server network add address=10.0.10.0/24 dns-server=192.168.0.1 gateway=10.0.10.1

# Green VLAN interface creation, IP assignment, and DHCP service
/interface vlan add interface=BR1 name=GREEN_VLAN vlan-id=20
/ip address add interface=GREEN_VLAN address=10.0.20.1/24
/ip pool add name=GREEN_POOL ranges=10.0.20.2-10.0.20.254
/ip dhcp-server add address-pool=GREEN_POOL interface=GREEN_VLAN name=GREEN_DHCP disabled=no
/ip dhcp-server network add address=10.0.20.0/24 dns-server=192.168.0.1 gateway=10.0.20.1

# Red VLAN interface creation, IP assignment, and DHCP service
/interface vlan add interface=BR1 name=RED_VLAN vlan-id=30
/ip address add interface=RED_VLAN address=10.0.30.1/24
/ip pool add name=RED_POOL ranges=10.0.30.2-10.0.30.254
/ip dhcp-server add address-pool=RED_POOL interface=RED_VLAN name=RED_DHCP disabled=no
/ip dhcp-server network add address=10.0.30.0/24 dns-server=192.168.0.1 gateway=10.0.30.1

# Optional: Create a DHCP instance for BASE_VLAN. Convenience feature for an admin.
# /ip pool add name=BASE_POOL ranges=192.168.0.10-192.168.0.254
# /ip dhcp-server add address-pool=BASE_POOL interface=BASE_VLAN name=BASE_DHCP disabled=no
# /ip dhcp-server network add address=192.168.0.0/24 dns-server=192.168.0.1 gateway=192.168.0.1


#######################################
# Firewalling & NAT
# A good firewall for WAN. Up to you
# about how you want LAN to behave.
#######################################

# Use MikroTik's "list" feature for easy rule matchmaking.

/interface list add name=WAN
/interface list add name=VLAN
/interface list add name=BASE

/interface list member
add interface=ether1     list=WAN
add interface=BASE_VLAN  list=VLAN
add interface=BLUE_VLAN  list=VLAN
add interface=GREEN_VLAN list=VLAN
add interface=RED_VLAN   list=VLAN
add interface=BASE_VLAN  list=BASE

# VLAN aware firewall. Order is important.
/ip firewall filter


##################
# INPUT CHAIN
##################
add chain=input action=accept connection-state=established,related comment="Allow Estab & Related"

# Allow VLANs to access router services like DNS, Winbox. Naturally, you SHOULD make it more granular.
add chain=input action=accept in-interface-list=VLAN comment="Allow VLAN"

# Allow BASE_VLAN full access to the device for Winbox, etc.
add chain=input action=accept in-interface=BASE_VLAN comment="Allow Base_Vlan Full Access"

add chain=input action=drop comment="Drop"


##################
# FORWARD CHAIN
##################
add chain=forward action=accept connection-state=established,related comment="Allow Estab & Related"

# Allow all VLANs to access the Internet only, NOT each other
add chain=forward action=accept connection-state=new in-interface-list=VLAN out-interface-list=WAN comment="VLAN Internet Access only"

add chain=forward action=drop comment="Drop"


##################
# NAT
##################
/ip firewall nat add chain=srcnat action=masquerade out-interface-list=WAN comment="Default masquerade"


#######################################
# VLAN Security
#######################################

# Only allow packets with tags over the Trunk Ports
/interface bridge port
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=ether2]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=ether3]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=ether4]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=ether5]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=ether6]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=ether7]
set bridge=BR1 ingress-filtering=yes frame-types=admit-only-vlan-tagged [find interface=sfp1]


#######################################
# MAC Server settings
#######################################

# Ensure only visibility and availability from BASE_VLAN, the MGMT network
/ip neighbor discovery-settings set discover-interface-list=BASE
/tool mac-server mac-winbox set allowed-interface-list=BASE
/tool mac-server set allowed-interface-list=BASE


#######################################
# Turn on VLAN mode
#######################################
/interface bridge set BR1 vlan-filtering=yes

Értem a konfigodat de ugyanakkor nekem átláthatóbb lenne vlan interface-ek nélkül bridge pvid-kkel + a végén a vlan filtering bekapcsolásához minimum RSTP kell.

Puszta kíváncsiságból (illetve gondolom nem ez az összes tűzfalszabály) ha adsz egy IP címet a BR1-nek, azt mindenhonnan eléred?

Az RSTP nálam is be van kapcsolva. Ez a példa a tutorial-ból lett bemásolva, ezért ott nincs bekapcsolva. :-)

> Puszta kíváncsiságból (illetve gondolom nem ez az összes tűzfalszabály) ha adsz egy IP címet a BR1-nek, azt mindenhonnan eléred?

Nekem persze nem ez az összes szabály, ez csak egy példa és ott külön kommentezve van hogy "make it more granular". :-) Ez csak egy működő példa ami a lehető legegyszerűbbre van megírva, hogy könnyen érthető legyen.

Ami a bridge címét illeti: a bridge-nek nálam NINCS LAYER 3 CÍME. Csak a bridge-hez fölvett "/interface vlan" interface-eknek van címe, és a dhcp szerver meg a caching dns szerver is ezekre van rátéve. Ami azt a kérdést illeti hogy ezeket honnan érem el, arra a következő a válasz. A vlan interface egy virtuális dolog, CPU-ban van implementálva. Ha valaki el akar érni egy olyan címet, ami egy ilyen vlan eszközhöz tartozik, akkor a csomagnak ki **kell** jönnie a switch chip-ből, és át kell mennie a CPU-ba. A layer3 tűzfal input szabályai futnak le rá, és ezekkel lehet szabályozni azt, hogy honnan éred el és honnan nem. Mivel a csomagot mindenképpen ki kell másolni a CPU-ba, ezért ez a hw offloading szempontjából irreleváns. (Akkor is ki kellene másolni, ha egyetlen egy tűzfal szabály se lenne.)

Ezt a fajta konfigot szokták úgy hívni hogy "router on a stick" ( https://en.wikipedia.org/wiki/Router_on_a_stick ). A vlan-on belüli forgalom általában nem éri el a router-t, hanem a switch-ekben levő MAC learning table alapján egy (remélhetőleg) optimális úton jutnak el a feladótól a címzettig, kihagyva az összes routing-ot. Ha viszont egyik vlan-ból a másikba akarsz küldeni valamit, akkor az a switch-eken nem tud átmenni, csak a "stick"-en levő router-en át, így az ilyen inter-vlan forgalmat egyetlen egy helyen, a központi router-ben tudod szabályozni.

Most vettem észre hogy nem is a kérdésre válaszoltam. :-) Te azt kérdezted hogy " ha adsz egy IP címet a BR1-nek " akkor elérem-e.

De ennek nem lenne sok értelme, mert ennek a konfignak az a koncepciója, hogy a bridge minden csomagot tagged-ként kezel, és az összes layer 3 (IP) cím mindig olyan interface-en van, ami egy konkrét vlan-hoz tartozik. Ez teszi lehetővé azt, hogy egy cél cím birtokában egyértelműen el lehessen dönteni azt, hogy az melyik vlan-on van, és így normálisan lehessen szabályozni azt, hogy ki mit lát. Ebben a konfigban a bridge a default pvid=1 értékkel van létrehozva. De ennek semmire semmi hatása nincsen, mert bridge szintjén minden csomag tagged, maga a bridge a vlan táblázatban tagged portként van hozzáadva, és layer 3 szinten egyáltalán nincs címe, ezért az a kérdés hogy "elérem-e", csak layer 2 szinten értelmezhető.

De hogy a kérdésedre válaszoljak: ha mégis adnék a bridge-nek címet, akkor arra a címre is tagged csomagok érkeznének be. Ha ezt akarnám szabályozni/korlátozni, akkor valószínűleg külön tűzfal szabályokat kellene hozzáadnom a jelenlegihez, mert a bridge-nek adott IP cím nem lenne rajta egyik interface-list -en se. Szóval ha ilyet csinálnék, akkor a tűzfal szabályok bonyolultabbak (és így lassabbak!) lennének. Szerintem nem nyernék vele semmit.

Hát megemelem a kalapomat először is a részletes válaszért, sajnos/szerencsére ritkán tanulok új dolgokat mostanság. Bár nincs rá szükségem mert az RB4011 megoldja izomból, de lehet kipróbálom ezzel a logikával kiváltani a jelenlegi 3 bridge + CAPSMAN setupomat (nekem a CAPSMAN forwarding miatt is egyszerűbb volt a külön bridge setup). Köszi szépen a választ 

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.

Na, igy mukodik nalam a CAPSMAN + VLAN filtering jelenleg;CAPSMAN forwarding van es igy hogy a bridge-eknek van IP cime, azokon tud futni a DHCP szerver is. Ether8-9-10-en vannak a CAP-ek, amik az internal IP tartomanybol kaptak 1-1 IP cimet, de a wifi SSID-k mint kulon VLAN-okban jonnek be.

# jun/21/2021 17:56:06 by RouterOS 6.48.3
# software id = 
#
# model = RB4011iGS+
# serial number = xxx
/interface bridge add name=bridge-guest protocol-mode=mstp pvid=3 vlan-filtering=yes
/interface bridge add admin-mac=xx auto-mac=no igmp-snooping=yes name=bridge-internal protocol-mode=mstp vlan-filtering=yes
/interface bridge add name=bridge-iot protocol-mode=mstp pvid=2 vlan-filtering=yes
/interface bridge add name=bridge-vpn
...
/caps-man configuration add channel.band=5ghz-n/ac channel.reselect-interval=1h channel.skip-dfs-channels=yes comment="Internal wifi 5G" country=hungary datapath.bridge=bridge-internal datapath.client-to-client-forwarding=yes datapath.local-forwarding=no datapath.vlan-id=1 datapath.vlan-mode=use-tag hide-ssid=no installation=indoor mode=ap name=internal_5g security.authentication-types=wpa2-psk security.disable-pmkid=yes security.encryption=aes-ccm security.group-encryption=aes-ccm ssid=Z0lwireless5
/caps-man configuration add channel.band=2ghz-g/n channel.reselect-interval=1h channel.skip-dfs-channels=yes comment="Internal wifi 2G" country=hungary datapath.bridge=bridge-internal datapath.client-to-client-forwarding=yes datapath.local-forwarding=no datapath.vlan-id=1 datapath.vlan-mode=use-tag disconnect-timeout=5s hide-ssid=no hw-retries=2 installation=indoor mode=ap name=internal_2g security.authentication-types=wpa2-psk security.disable-pmkid=yes security.encryption=aes-ccm security.group-encryption=aes-ccm ssid=Z0lwireless2
/caps-man configuration add channel.band=2ghz-g/n channel.skip-dfs-channels=yes comment="Guest wifi 2G" country=hungary datapath.bridge=bridge-guest datapath.vlan-id=3 datapath.vlan-mode=use-tag installation=indoor mode=ap name=guest_2g security.authentication-types=wpa2-psk security.disable-pmkid=yes security.encryption=aes-ccm security.group-encryption=aes-ccm ssid=Guest
/caps-man configuration add channel.band=2ghz-g/n comment="IOT wifi 2G" country=hungary datapath.bridge=bridge-iot datapath.vlan-id=2 datapath.vlan-mode=use-tag hide-ssid=no installation=indoor mode=ap name=iot_2g security.authentication-types=wpa2-psk security.disable-pmkid=yes security.encryption=aes-ccm security.group-encryption=aes-ccm security.group-key-update=1h ssid=Automatron
/caps-man interface add configuration=internal_2g disabled=no l2mtu=1600 mac-address=xxx master-interface=none name=cap1 radio-mac=xxx
...
/ip pool add name=internal-pool ranges=192.168.10.15-192.168.10.250
/ip pool add name=iot-pool ranges=192.168.1.100-192.168.1.250
/ip pool add name=guest-pool ranges=192.168.192.100-192.168.192.200
/ip dhcp-server add add-arp=yes address-pool=internal-pool disabled=no interface=bridge-internal name=internal-dhcp
/ip dhcp-server add add-arp=yes address-pool=iot-pool disabled=no interface=bridge-iot name=iot-dhcp
/ip dhcp-server add address-pool=guest-pool disabled=no interface=bridge-guest name=guest-dhcp
...
/caps-man access-list add action=accept allow-signal-out-of-range=10s client-to-client-forwarding=yes disabled=no signal-range=-80..120 ssid-regexp="" time=0s-1d,sun,mon,tue,wed,thu,fri,sat
/caps-man access-list add action=reject allow-signal-out-of-range=10s disabled=no signal-range=-120..120 ssid-regexp=""
/caps-man manager set ca-certificate=auto certificate=auto enabled=yes require-peer-certificate=yes upgrade-policy=suggest-same-version
/caps-man manager interface set [ find default=yes ] forbid=yes
/caps-man manager interface add disabled=no interface=ether8
/caps-man manager interface add disabled=no interface=ether9
/caps-man manager interface add disabled=no interface=ether10
/caps-man manager interface add disabled=no interface=bridge-internal
/caps-man provisioning add action=create-enabled comment="5g ssid" hw-supported-modes=ac master-configuration=internal_5g
/caps-man provisioning add action=create-enabled comment="2g ssid-k" hw-supported-modes=gn master-configuration=internal_2g slave-configurations=iot_2g,guest_2g
/interface bridge port add bridge=bridge-internal comment=defconf interface=ether2
/interface bridge port add bridge=bridge-guest comment=defconf ingress-filtering=yes interface=ether4 pvid=3
/interface bridge port add bridge=bridge-iot comment=defconf interface=ether5 pvid=2
/interface bridge port add bridge=bridge-iot comment=defconf interface=ether6 pvid=2
/interface bridge port add bridge=bridge-iot comment=defconf interface=ether7 pvid=2
/interface bridge port add bridge=bridge-internal comment=defconf interface=sfp-sfpplus1
/interface bridge port add bridge=bridge-internal interface=*E
/interface bridge port add bridge=bridge-internal interface=ether3
/interface bridge port add bridge=bridge-guest interface=*10 pvid=3
/interface bridge port add bridge=bridge-iot interface=*F pvid=2
/interface bridge port add bridge=bridge-internal interface=ether8
/interface bridge port add bridge=bridge-internal interface=ether9
/interface bridge port add bridge=bridge-internal interface=ether10
...
/interface bridge vlan add bridge=bridge-internal comment=Internal untagged=bridge-internal,*E,ether2,ether3 vlan-ids=1
/interface bridge vlan add bridge=bridge-guest untagged=*10,bridge-guest vlan-ids=3
/interface bridge vlan add bridge=bridge-iot untagged=*F,bridge-iot vlan-ids=2
...
/ip address add address=192.168.10.1/24 comment=defconf interface=bridge-internal network=192.168.10.0
/ip address add address=192.168.1.1/24 interface=bridge-iot network=192.168.1.0
/ip address add address=192.168.192.1/24 interface=bridge-guest network=192.168.192.0
...
/ip dhcp-server network add address=192.168.10.0/24 comment=defconf dns-server=192.168.10.2 gateway=192.168.10.1 netmask=24
/ip dhcp-server network add address=192.168.1.0/24 dns-server=192.168.1.1 gateway=192.168.1.1
/ip dhcp-server network add address=192.168.192.0/24 dns-server=192.168.192.1 gateway=192.168.192.1
...

Ez szerintem eléggé össze van kutyulva. :-) A vlan táblázatod tartalmaz érvénytelen/törölt interface-eket.

De még mielőtt igazi véleményt mondanék, elküldenéd nekem a következőket?

/interface bridge print
/interface bridge port print
/interface bridge vlan print

Tudom hogy az export alapján is föl kellene tudnom építeni fejben, de így egyszerűbb lenne átlátni. :-)

Kinéztem egy vlan-t és átnéztem azt.

 

/interface bridge add name=bridge-guest protocol-mode=mstp pvid=3 vlan-filtering=yes
/caps-man configuration add channel.band=2ghz-g/n channel.skip-dfs-channels=yes comment="Guest wifi 2G" country=hungary datapath.bridge=bridge-guest datapath.vlan-id=3 datapath.vlan-mode=use-tag installation=indoor mode=ap name=guest_2g security.authentication-types=wpa2-psk security.disable-pmkid=yes security.encryption=aes-ccm security.group-encryption=aes-ccm ssid=Guest
/ip pool add name=guest-pool ranges=192.168.192.100-192.168.192.200
/ip dhcp-server add address-pool=guest-pool disabled=no interface=bridge-guest name=guest-dhcp
/caps-man provisioning add action=create-enabled comment="2g ssid-k" hw-supported-modes=gn master-configuration=internal_2g slave-configurations=iot_2g,guest_2g
/interface bridge port add bridge=bridge-guest comment=defconf ingress-filtering=yes interface=ether4 pvid=3
/interface bridge port add bridge=bridge-guest interface=*10 pvid=3
/interface bridge vlan add bridge=bridge-guest untagged=*10,bridge-guest vlan-ids=3
/ip address add address=192.168.192.1/24 interface=bridge-guest network=192.168.192.0

Ezeket a hibákat látom:

  • A bridge-guest nevű bridge-nek egyetlen egy portja van (saját magán kívül).
  • Ez a port se nem untagged, se nem tagged. Konkrétan hiányzik a vlan táblázatból.
  • Csak azért működik, mert az ingress filtering nincs bekapcsolva. Ezért működik a DHCP-d is: untagged csomagokat küld ki és fogad be. (A frame-types sincs megadva)
  • Szóval az ether4 portod úgy viselkedik mintha semmi köze nem lenne semmiféle vlan-hoz.
  • Mivel egyetelen egy portról van szó, és mivel tagged (trunk) porton sehol nem megy ki és nem jön be csomag, így kívülről nézve ez a router nem is használ vlan-t. :-)
  • Így aztán teljesen értelmetlen bridge-et létrehozni. Jobban járnál ha egyáltalán nem lenne bridge-ed, és a DHCP szervert meg a CAPs manager-t is az ether4 -re tennéd rá. Mindenvéle vlan meg bridge beállítás nélkül.
  • a vlan táblázatodban több sorban érvénytelen/törölt interface-ek vannak
  • az ingress-filtering és a frame-types nincs beállítva több helyen
  • A skip-dfs-channels beállítás 2Ghz-en értelmetlen.

Úgy látom hogy neked minden ethernet portra külön CAP van téve, és minden SSID-hez meg CAP-hoz külön caps manager van. Ha ez így van, akkor nincs szükséged se bridge-re, se vlan-ra. De még az is kérdéses, hogy egyáltalán a caps-man használata indokolt-e. (Igaz hogy egyetlen routeren van az összes wlan config, de igazából minden config csak egyetlen egy cap-on van használva.) Az egész egy nagy katyvasz. :-)

Ha azt szeretnéd elérni, hogy minden CAP rádiója használva legyen minden SSID-re (tehát ténylegesen legyen mesh hálózat / roaming), akkor viszont ez a több bridge-ből álló konfig soha az életben nem fog működni. Hogy miért, abba bele se kezdek. :-)

Csak a guest-et néztem meg de a többi is biztos ilyen.

Ahhoz hogy minden CAP rádiója minden SSID-hez csináljon access point-ot, ez kellene:

A manager-en:

* egyetlen egy bridge, amihez hozzáadod az összes releváns ethernet portot (azokat amikről CAP eszköz elérhető)
* minden ilyen portot hozzáadsz ehhez az egy bridge-hez
* minden ilyen ethernet interface-t tagged portként adod hozzá a vlan táblázathoz, a megfelelő vlan id-kkel
* minden vlan-hoz csinálsz vlan interface-eket a bridge-en belül
* ezekre a vlan interface-ekre teszed rá az IP címeket és a dhcp szervereket
* a bridge-nek NEM ADSZ ip címet
* fölveszel +1 management vlant, és erre egy vlan interface-t címmel együttt. Azért, hogy a CAPsMAN és a CAP ezen keresztül tudjon kommunikálni. Ehhez a vlan-hoz nem kell datapath vagy bármilyen más config, ez csak a maneger fő interface-je lesz.
* a vlan-ok közötti forgalmat a caps manager-en firewall szabályokkal szabályozod
* a caps-man beállításaiban az egyik configot master-nek az összes többit slave-nek állítod be

A CAP -okon:

* csinálsz egy bridge-t
* ehhez hozzáadod az ethernet portot tagged portként (azt amelyikről a caps manager elérhető). Fontos, hogy minden vlan-id -hez külön sort csinálj. Ne egybe!
* a wlan interface-eket NEM ADOD HOZZÁ a bridge-hez, azt majd a CAPS fogja
* viszont itt is fölveszel egy vlan interface-t, és adsz neki címet. Ez a vlan interface ugyan abban a vlan-ban legyen, mint amelyiken a caps-man manager interface-je (ez a discovery-hez kell) - ez csak egy példányban kell, és praktikusan egy olyan technikai/management vlan-on, amihez egyáltalán nem is tartozik ssid
* az összes többi vlan esetében NEM ADSZ HOZZÁ ip címet a CAP-on. Egyáltalán semmit.

Így az összes vlan elérhető lesz az összes CAP-on, és minden provision.-ölt SSID megjelenik az összes CAP-on. A CAP és a CAPsMAN között a management vlan-on megy a kommunikáció, a CAP és az egyéb eszközök között meg vagy úgy jut el az adott vlan-on a csomag, hogy a CAP küldi a megfelelő gateway IP-re (local forwarding), vagy a DTLS protokolon keresztül a management vlan-on megy el a CAPsMAN-hoz és onnan meg tovább.

Na azert annyira talan nem gaz a helyzet, de lehet kicsit tul sokat vagtam ki a konfigbol ami miatt nem volt teljesen ertheto :) Logikailag 3 halozatom van, egy internal, egy guest es egy az okosotthon cuccainak. Ezek kulon subnetekben vannak egymastol eltuzfalazva. Az RB4011-be jon be az internet pppoe-n, es ennek az utolso 3 ethernet portjan vannak a CAP-ek; van 1 ethernet port rajta a guest-nek (ide kapcsolodnak a tesztelesre erkezo dolgok), 2 ethernet portja az okosotthonnak es van meg 2 vagy 3 amin az internal dolgok vannak. A CAP-eken van 4 SSID, 2 az internal networkre, 1 a guestre es 1 az okosotthonra. A fenti setup lehetove teszi, hogy a CAP-eken levo guest wifire kapcsolodott eszkozok becsattanjanak a guest bridge-re (CAPSMAN forwarding + datapath.bridge), es onnan kapnak dhcp-t meg mennek ki az internetre. Osszesen 3 db CAP van, a 4011 a CAPSMAN ami azt a 4 db SSID-t tolja le a CAP-ekre, es amugy minden mukodik gond nelkul, barmilyen hihetetlennek is hangzik :)

Amugy az invalid portok nem tudom honnan jonnek, a webfigben semmilyen invalid dolog nincs: https://ibb.co/Zd0k7Rd

Gondolkozok majd egy kicsit azokon amiket irtal, szerintem ami nalam hianyzik az az eszkozok management vlan-ja (mert a CAP-ek sima untagged portokon mennek az internalra, de a sugarzott SSID-k mar vlan id-kkal jonnek be), de mivel a CAPSMAN forwarding miatt ez a forgalom olyan mintha a 4011-en keletkezett volna, lehet igazabol azokra sincs szukseg (csak akkor meg azon kellene gondolkoznom hogy hogyan maradjanak elkulonitve).

Nem hagy nyugodni, ezért erre is reagálok, de lehet nem kellene. :-)

Az RSTP értelme az, hogy megszüntesse a loop-okat. Az RSTP-nek akkor van értelme, ha sok eszközöd úgy van hálózatba kötve, hogy abban vannak loop-ok. Ha a hálózatod fizikailag úgy néz ki mint egy fa (nincs benne loop), akkor az RSTP (vagy bármilyen spanning tree) alkalmazása tök fölösleges, és igazából még lassít is. De az ilyen hálózatok nem hibatűrők - ha valahol megszakad egy kapcsolat, akkor két részre esik szét a hálózatod, szigetek alakulnak ki. Ezzel szemben az RSTP képes egyben a hálózatot akkor, ha olyan kapcsolat szakadt meg, ami helyettesíthető egy másikkal.

A vlan filtering-nek kb. annyi köze van az RSTP-hez, mint az autógumi típusának a közlekedési táblákhoz. :-)

Ezt csak azért írtam mert a vlan filteringhez kötelező valamilyen protocol mode-ot megadni és a példa configod nem állít be semmit amikor létrehozta a bridge-et és akkor sem amikor beállítja a vlan filteringet :) Nekem most teljesen jól működik a CAPSMAN local forwarding nélkül, holnap megosztom a configot hozzá.

Lehet, hogy kötelező protocol mode-ot megadni (nem kötelező egyébként), de azt simán megadhatod, hogy protocol mode=none. Ilyen sima két eszközös felálláshoz nem kell semmilyen STP megoldás, és tökéletesen működik is ilyen nélkül a VLAN filtering. A kettőnek semmi köze egymáshoz, sem működésben, sem konfigurációban. Ráadásul VLAN környezetben már inkább MSTP-t kell nézegetni (ahol ilyenre van szükség), nem RSTP-t.

Azért ez így nem teljesen igaz, mert LACP-vel is lehet redundanciát produkálni, abban normális esetben ráadásul minden kapcsolat aktív és használható. Nyilván előfordulhatnak topológiák, amikor az STP célravezetőbb (például azért, mert olcsóbb switchek vannak és nem biztosítható a switchek közötti LACP). Ezenkívül gyűrű topológia is lehetséges.

> Azért ez így nem teljesen igaz, mert LACP-vel is lehet redundanciát produkálni, abban normális esetben ráadásul minden kapcsolat aktív és használható.

Na és ki mondott olyat, hogy nem lehet?

> Ezenkívül gyűrű topológia is lehetséges.

A gyűrű az egy nagy loop. ;-)

Nem explicit, hanem implicit írtad:

úgy néz ki mint egy fa [...]. De az ilyen hálózatok nem hibatűrők

Az LACP-nek köszönhetően az ilyen hálózatok is hibatűrők tudnak lenni.

Gyűrű: van kétirányú gyűrű is. Őszintén szólva én még nem csináltam ilyet, de találkoztam vele.

Maradjunk abban, hogy a hibatűrésnek sok esete van.

LACP megoldja, hogy ha egy port nem működik, akkor az adott eszköz még rajta tudjon maradni a hálózaton, a gyűrű meg egyéb mesh megoldások pedig azt oldják meg, hogy ha egy hálózati eszköz kiesik, akkor még a hálózat egybefüggő tudjon maradni. Otthoni hálózaton nem tartom valószínűnek, hogy az utóbbira olyan nagyon nagy szükség lenne.

Az LACP nemcsak port, hanem eszköz kiesését is le tudja kezelni. Ehhez nyilván olyan switch kell, ami olyan LAG-ot tud csinálni, melynek portjai különböző eszközökön vannak. Ilyenek tipikusan a stackelt switchek, magasabb kategóriában van a vPC (Cisco), VLT (Dell/Force10), ...

Nos ennek a második fele nem teljesen igaz. Pont azt rejti el ami itt érdekes lehet. Amiről te beszélsz azt több minden valósítja meg és a gyártófüggetlen megoldása ennek az MLAG (nem mellesleg támogatott /lesz/ és Mikrotik switcheknél is, hogy maradjunk a topicnál) amit te hoztál a példának pl. vPC pl eléggé  megkötött megoldás, még a beköthető switchek típusa is megkötött, nem csak a gyártó, meg némileg több is /L3/ 

Csak érdekesség képpen írom, hogy én úgy valósítottam meg egy helyen cluster számára switch redundanciát Mikrotik CRS3xx-el (ami ugye nem tud MLAG-ot), hogy a szervereken aktív-passzív bond van, és ennek egy-egy lába megy egy-egy különálló switch-be (az LACP dual-aktív, azzal ilyent nem lehet csinálni MT switch esetében az MLAG hiánya miatt), a két switch pedig össze van kötve (trunk port minden érintett VLAN-nal). Ezen felül mindkét switch rá van kötve egy MT router-re (ebből csak egy van), ahol is szintén aktív/passzív bond oldja meg, hogy ne legyen loop, de a switch redundancia életképes legyen. Telejsen jól működik és semmi speciális tudás nem kellett egyik érintett eszköz részéről sem.

Mindenképp el szerettem volna kerülni az STP megoldásokat, mert aránylag lassú reagálásúak mind, aránylag bonyolult megvalósítani (legalábbis MT esetében, MSTP-vel) VLAN környezetben jól, és túl nagy zavart okoznak sokszor, mikor működésbe lépnek.

Ráadásul a szerverek oldalán VLAN interfész párokból vannak a bond interfészek, így meg lehetett oldani, hogy az egyik VLAN esetében az egyik, másik VLAN esetében a másik fizikai interfész legyen az aktív, így a teljes sávszélesség kihasználható interfészenként mindaddig, amíg mindkét switch él. Ha pedig valamelyik elmúlik, akkor mindenki osztozik a maradék sávszélen.

Az a baj, hogy ahogy néztem az igért (és bétában lévő) képességeket, nem minden képesség lesz elérhető minden CRS3xx eszközön...

Plusz, mikor kijön a végleges, stable (nak mondott) R7, akkor én (az eddigi tapasztalataim alapján) rá várok legalább fél-egy évet, mielőtt élesben elkezdek használni R7-tel bevezetett új tudást/képességet...

azert azzal vigyazz, hogy a hw offload, meg a switch chip vlan support meg ilyen dolgok csak bizonyos eszkozoknel mennek, akkor is csak a _jo_ konfiguracio eseten mukodnek. ha rosszul csinalod akkor cpubol fog menni minden, es a sebesseg limitacioid lesznek: vagy a cpu nembirja a lapatot, vagy a switchcip-cpu kozotti 1G-s link fog bedugulni. van erre egy kulon MT wiki oldal is.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Így van, ezért is akartam elkerülni a switch chip használatát, de köszönöm a felhívásod!

Időközben sikerült megoldanom a problémát! Köszönöm mindenkinek, de legfőképpen Z0l-nak! Ha kész vagyok az összes beállítással, akkor megosztom az eredményt, hátha ez később mást is érdekelhet.

Ahogy ígértem, itt a megoldás.

Az 1-es router (192.168.100.254/24) 1-es portjában van a WAN (DHCP-ről kap IP-t), a 3-as és 4-es portjában pedig 1-1 gép. A 2-es router-nek (192.168.100.20/254) a 3-as és 5-ös portjában van 1-1 gép. Mindkét router a 2-es portján van összekötve.  Mindenki lát mindenkit a 100-as VLAN-on keresztül. Tűzfallal innentől lehet blokkolni amit nem akarunk és további VLAN-okat hozzáadni ugyanezzel a módszerrel. Mindegyszer köszönöm mindenkinek a segítséget!

 

1-es router:

/interface bridge

add name=bridge100

/interface vlan

add interface=ether2 name=vlan100 vlan-id=100

/ip pool

add name=dhcp_pool100 ranges=192.168.100.1-192.168.100.253

/ip dhcp-server

add address-pool=dhcp_pool100 disabled=no interface=bridge100 name=dhcp100

/interface bridge port

add bridge=bridge100 interface=ether3 pvid=100

add bridge=bridge100 interface=ether4 pvid=100

add bridge=bridge100 interface=vlan100

/ip address

add address=192.168.100.254/24 interface=vlan100 network=192.168.100.0

/ip dhcp-client

add disabled=no interface=ether1

/ip dhcp-server network

add address=192.168.100.0/24 dns-server=8.8.8.8 gateway=192.168.100.254

/ip firewall nat

add action=masquerade chain=srcnat out-interface=ether1

/system clock

set time-zone-name=Europe/Budapest

/system identity

set name="Router 1"

 

 

2-es router:

/interface bridge

add name=bridge100

/interface vlan

add interface=ether2 name=vlan100 vlan-id=100

/ip pool

add name=dhcp_pool1 ranges=192.168.100.1-192.168.100.253

/interface bridge port

add bridge=bridge100 interface=ether3 pvid=100

add bridge=bridge100 interface=ether5 pvid=100

add bridge=bridge100 interface=vlan100

/ip neighbor discovery-settings

set discover-interface-list=!dynamic

/ip address

add address=192.168.100.20/24 interface=vlan100 network=192.168.100.0

/ip dhcp-server network

add address=192.168.100.0/24 dns-server=8.8.8.8 gateway=192.168.100.254

/ip dns

set servers=8.8.8.8

/ip route

add distance=1 gateway=192.168.100.254

/system identity

set name="Router 2"

/system ntp client

set enabled=yes primary-ntp=82.141.152.3

Orulok ha igy mukodik, de szerintem nem kellene bele a vlan100 interface, hanem helyette a bridge-nek is kellene adnod pvid-t:

/interface bridge

add name=bridge100 pvid=100

Es az interface bridge vlan-nal tudod allitani a tagged/untagged status-t. Gondolom ez a fenti setup megall ha bekapcsolod a bridge vlan filteringet ugye?

Szia!

 Működik vlan filtering-gel, azonban ha kiveszem a bridge100-ból a vlan100 interface-t, akkor megszűnik a kapcsolat a routerrel. Tagged-re az ether2-t állítottam, untagged-re pedig az ether3-at és 4-et, valamint a bridge100-at. Mindegy, a lényeg hogy van egy működő megoldás. Lehet nem szép, de megy. :) Köszönöm szépen a segítséged!

Ha benne hagyod a vlan100 interface-t vlan filteringnel, akkor dupla VLAN taggingot csinal. En a helyedben szorakoznek meg egy kicsit vele hogy menjen vlan interface nelkul mert a dupla tagging visszauthet kesobb.

Ugye a masik routeren is ugyanazt a pvid-t adtad meg a bridge-nek es azon is bekapcsoltad a vlan filteringet? Ugy lenne jo lemodellezni, hogy 2-2 ethernet port mindket eszkozon (1 tagged, 1 untagged), a tagged porton osszekotod a routereket es megnezed hogy elerik-e egymast az untagged portba kotott gepek, illetve ha nem, akkor hol vesznek el a csomagok.

 

szerk: nem adod hozza a vlan-ids paramétert a bridge-hez, azért nem megy a vlan100 interface nélkül.

Ez még nem a kész megoldás. :-)

Konkrétan a bridge-re nem kapcsoltad be a vlan filtering-et (/interface bridge menü, vlan-filtering=yes) ezért bármelyik porton bármilyen packet-et elfogad.  Az igaz, hogy pvid=100 -at megadtad amikor például hozzáadtad az ether3 portot a bridge-hez. De mivel a vlan filtering ki van kapcsolva, ezért a router-ed zokszó nélkül elfogadja azt a packet-et is ezen a porton, aminek bármilyen más vlan tag-je van. Ezért aztán küldhetsz egyik vlan-ból a másikba packet-eket. A VLAN-ok nincsenek elszeparálva, szóval pont az nem működik ami az eredeti cél volt.

Ha a fenti konfiggal bekapcsolod a vlan filteringet, akkor egyáltalán semmi nem fog menni, mert a bridge vlan table üres ( /interface bridge vlan ), nem állítottál be ott semmit. Ezért az összes kimenő csomagot el fogja dobni, az egész router-ed megsüketül.

 

A helyes megoldáshoz ki kell töltened a bridge vlan table-t, és UTÁNA be kell kapcsolnod a vlan filtering-et. Ez a minimum.

Tehát akkor van két router, összekotve, VLAN 100 mindkettőn elérhető, és mindkettőn van egy-egy DHCP szerver, ami a VLAN 100-ban pontosan ugyan abból az IP tartományból oszt címeket. Ergo VLAN 100-ban minden IP címből lehet kettő egy időben. Hát, mondjuk úgy, ez így nem az igazi...

Ha mindenképp szükséges a két DHCP szerver (készülsz arra, hogy elmúlik a két router közötti kapcsolat), akkor legalább oszd ketté az IP tarományt, és az egyik fele legyen az egyik router-en, a másik fele legyen a másik router-en. Így legalább nem lesz IP cím ütközés (igaz, a router-ek kapcsolatának elveszésekor internet nem lesz a 2. router-re kötött eszközökön, de egymással legalább tudnak beszélni addig is).

Ha nem kell a kapcsolat megszakadásával számolni, akkor elég a router 1-en a DHCP szerver, a router 2 gépei a VLAN 100 kapcsolaton keresztül ugyan úgy fognak IP címet kapni.

Viszont így ez a konfig egy tákolás, semmilyen MT ajánlást vagy leírást nem követ, csak addig nyomogattad, míg elérted egyik oldalról a másikat...

 

De, hogy ne csak sima trollnak tűnjek:

Szerintem úgy kellene csinálnod (és mindenki másnak is, aki itt megosztott konfig részletet), hogy 1 bridge van, VLAN filtering engedélyezve. A VLAN-ok definiálva, hozzájuk megadva fixen a trunk portok amik több VLAN-on forgalmaznak, az access portoknél pedig PVID-vel kerülnek a megfelelő VLAN-ba.

/interface bridge
add name=bridge vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=ether2
add bridge=bridge interface=ether3 pvid=100
add bridge=bridge interface=ether4 pvid=100
add bridge=bridge interface=ether5 pvid=200
add bridge=bridge interface=wlan1 pvid=250
add bridge=bridge interface=wlan2 pvid=250
/interface bridge vlan
add bridge=bridge untagged=bridge vlan-ids=1
add bridge=bridge tagged=bridge,ether2 vlan-ids=100
add bridge=bridge tagged=bridge,ether2 vlan-ids=200
add bridge=bridge tagged=bridge,ether2 vlan-ids=250

A router elérése és pl. DHCP szerver működtetése pedig ebben a felállásban a bridge-re ültetett VLAN interfészeken történik:

/interface vlan
add interface=bridge name=vlan100 vlan-id=100
add interface=bridge name=vlan200 vlan-id=200
add interface=bridge name=vlan250 vlan-id=250
/ip address
add address=192.168.100.254/24 interface=vlan100
add address=192.168.200.254/24 interface=vlan200
add address=192.168.250.254/24 interface=vlan250
/ip pool
add name=pool-vlan100 ranges=192.168.100.32-192.168.100.223
add name=pool-vlan200 ranges=192.168.200.32-192.168.200.223
add name=pool-vlan250 ranges=192.168.250.32-192.168.250.223
/ip dhcp-server
add address-pool=pool-vlan100 disabled=no interface=vlan100 name=dhcp-vlan100
add address-pool=pool-vlan200 disabled=no interface=vlan200 name=dhcp-vlan200
add address-pool=pool-vlan200 disabled=no interface=vlan250 name=dhcp-vlan250
/ip dhcp-server network
add address=192.168.100.0/24 dns-server=192.168.100.254 gateway=192.168.100.254
add address=192.168.200.0/24 dns-server=192.168.200.254 gateway=192.168.200.254
add address=192.168.250.0/24 dns-server=192.168.250.254 gateway=192.168.250.254

Ez a konfiguráció működik attól függetlenül, hogy milyen a switch chip, mit tud az adott eszköz offload-olni vagy mit nem. Ha ilyen módon tanulod meg a MT VLAN-ozást, akkor egységesen, minden eszközön a legjobb teljesítményt elérve tudod használni azt.

A második router-re értelem szerűen nem kellenek a DHCP szerver részek, és nyilván más IP címet kell megadni abban az egy VLAN-ban, ahol el szeretnéd érni (a második eszköznek nem kell IP címének lennie az összes VLAN-ban, arra csak azon az eszközön van szükség, amit router funkciót is ellát).

Ha valami nem stimmel, írd meg, fejből írtam a konfigot, nem pötyögtem be két eszközbe.

Szuper! Ezekkel 100%-ban egyet tudok érteni. :-)

 

Annyit tennék hozzá, hogy a második (meg akárhányadik) router-en nemcsak hogy nem kell IP címnek lenni az összes vlan-ban, hanem lehetőleg ne is legyen. Ha több vlan-van hozol létre címeket egy másik router-en is, és ezek a címek olyan vlan interface-eken vannak amik egy bridge-be tartoznak, akkor az a router is elkezd route-olni közöttük. Amiből egy nagy biztonsági lyuk lehet, mert ha valaki ezt fölfedezi, akkor ezen a router-en keresztül át tud szöktetni csomagokat egyik vlan-ból a másikba.

Persze ez ellen is lehet védekezni tűzfal szabályokkal. De az már egy elég idegesítő állapot, amikor a vlan-ok között egyszerre több router is route-ol, és az összes tűzfal szabályodat egyszerre több eszközön kell átnézni.

Az az alapelv, hogy ahol nincs szükség IP címre, ott ne is legyen.

Kicsit későn kapcsolódom be, de ezt érdemes elolvasni:

 

https://forum.mikrotik.com/viewtopic.php?f=23&t=143620

Sokkal érthetőbb, mint a mikrotik hivatalos leírása erről. A példa konfigokat le is lehet tölteni (bejelentkezés után).

Ha ezek után sem világos valami, akkor a két router-ed konfigját másold be ide (/export hide-sensitive), mert így kis részletekben nem annyira lehet átnézni.