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 kérdés, ezért a portok és a wifi feltételezzük a router az valójában egy router itt van egy példa arra hogy tudod összekötni
https://wiki.mikrotik.com/wiki/Manual:Basic_VLAN_switching#Other_device…
és sokkal részletesebben itt:
https://wiki.mikrotik.com/wiki/Manual:Switch_Chip_Features#Setup_Exampl…
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.
Egészségedre (hülyeséget beszélsz, csináld úgy ahogy az oda van írva.)
Köszönöm hogy legalább megpróbáltad értelmezni.
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.
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
De mégis igaz. Látom hogy switch-et írtál. Ja persze, aki egy switch-et akar routing-ra használni, az így jár. :-D
a 4011 elég jó kis router (és nem switch, mint irtad is) viszont nézd meg a sematikus bekötési rajzát:
van egy 10G uplink port, és 2db 5G switchgroup - egyenként 2.5 gbps uplink-el. Ez SOHA nem fog neked 10G-t routeolni.
A legoptimálisabb eseten is 2.5x2=5G-t :-)
Ha a 10G linket használod routingra a két switch chippel párhuzamosan , akkor azért 5-nél többet tud. Nyilván akinek az a problémája hogy hogyan route-oljon 10G-t, az nem ilyet fog venni :-) Viszont, a témánál maradva, a szükséges 1/2G simán megy. :-)
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:
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.
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?
pvid
for VLAN access ports to assign their untagged traffic to the intended VLAN.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:
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:
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.
hw offload 1db bridge-n lesz, csak szólok...
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!
Lehet hogy megint kicsit érthetetlen voltam. Talán így egyszerűbb. Adott ez a videó:
https://www.youtube.com/watch?v=V9Ks2MaBMoM
Hogyan tudom megoldani, hogy a VLAN20-as hálózatot elérje az 1-es router 2-es portján is?
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.
Rendben, ezt értem és szerintem menni fog. Nagyon szépen köszönöm a segítséged és azoknak is akik írtak még!
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.
1 bridge esetén nem tudod rendesen elkülöníteni a forgalmakat. Tudom hogy a hw offloading csak 1 bridge esetén megy, de nincs más előnye.
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.
É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!
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:
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:
Helyette MINDIG minden vlan-t külön sorba kell tenned:
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:
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.
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.
Ezeket a hibákat látom:
Ú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).
Webfig az alap konfigurációra jó. Használj winbox-ot vagy ssh-t.
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.
Nekem nem engedte bekapcsolni nélküle, de most ezt is megnéztem és igazad van, az MSTP-hez kell a vlan filtering, nem pedig fordítva. Amikor beállítottam, akkor nem néztem hogy miért lesz kötelező az érték.
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:
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.
> LACP-nek köszönhetően az ilyen hálózatok is hibatűrők tudnak lenni.
Na ezzel most megfogtál, mert igazad van. :-D
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/
Az volt az állítás, hogy a faszerkezetű topológia nem hibatűrő. Sehol nem írtam, hogy Force10 VLT-t akarjon Mikrotiken konfigurálni, általános topológia téma volt.
erre reflektáltam amikor ezt írtam: "Nos ennek a második fele nem teljesen igaz."
Mi nem igaz belőle? Az nyilvánvaló, hogy vannak kötöttségek, de attól még hibatűrést (is) megvalósítanak.
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.
Tudom még nem boldogít, de R7-től támogatott a CRS3xx-en
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?
Szerintem ha így bekapcsolnám a vlan filtering-et, akkor szakadna a kapcsolat a routerrel. Holnap kipróbálom ezzel a módszerrel is (most el kell menjek) és jelzem hogy mire jutottam. Valószínűleg ugyanúgy mennie kell, ahogyan jósoltad. Köszi!
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.
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:
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.