Co jsou to VLAN a jak fungují, implementace v Mikrotiku
V dnešním článku bych rád uživatelsky vysvětlil, co jsou to VLANy, jak fungují a následně popsal způsoby implementace v Mikrotiku a jeho RouterOS.
Úvod
Jelikož jsem zjistil, že v implementaci a znalostech VLAN "plove" docela hodně lidí, včetně mnoha uživatelů Poradny, rozhodl jsem se, že na toto téma napíšu článek, ve kterém se pokusím uživatelsky vysvětlit, oč jde, jak to funguje, proč a jak se to používá a nakonec bych rád zabrousil (bez vybrušování 
) do mírně specifické implementace v Mikrotiku.
Trocha nutné teorie
V první řadě: co je to VLAN? Je to zkratka "Virtual Local Area Network", čili Virtuální síť, jejíž standard je definován jako IEEE 802.1q. Hezký název, ale věřím, že mnohým z vás to nic neřekne. Budeme se držet nejčastější implementace, kterou je implementace na bázi ISO/OSI Layer2 ethernet portu (pro úplnost, další možnosti je implementace na základě ověření Radius nebo podle MAC adresy, což je "metoda Radius pro chudé"). Technicky vzato, jedná se o logické rozdělení (nejen) fyzických portů switche do různých, navzájem oddělených "virtuálních switchů", kdy zařízení připojená k virtuálnímu switchi A nebudou moci jakkoli komunikovat se zařízeními připojenými k virtuálnímu switchi B. Tyto virtuální switche a jejich porty se v rámci fyzického switche odlišují tzv. VLAN ID, tedy identifikátorem VLAN, což je číslo v rozsahu od 1 do 4096, každé z nich reprezentuje jeden virtuální switch.
Dobře, ale k čemu mi budou virtuální switche, když nakonec je stejně budu potřebovat nějak řízeně propojit, nebo budu potřebovat "roztáhnout" tyto virtuální switche přes více fyzických switchů, nebo dokonce switchů umístěných v odlehlých místech? Mít speciální propoj pro každou VLAN je velmi nepraktické, někdy i nemožné či extrémně nákladné. Pro takové případy existuje řešení, které popíšu v následujícím odstavci.
Každý fyzický port switche je možné nastavit do dvou režimů, které se jmenují ACCESS a TRUNK.
Access port je takový port, který má přiřazenu právě jednu VLAN ID (dále už jen VLAN) a zároveň tato VLAN není tagovaná (co to je, to vysvětlíme dále). Typické použití je pro koncová zařízení, jako PC, tiskárny apod.
Trunk port je takový port, který má přiřazeny alespoň dvě VLAN a logicky platí, že jedna z nich nemusí být tagovaná a zbytek tagován být musí. Obecně se ale počítá spíše s tím, že tagované jsou všechny VLAN (více dále).
Pokud má trunk port mix tagovaných a netagovaných VLAN, jedná se o tzv. Hybridní port. Čistý trunkport se používá na propojení routerů, switchů a případně serverů. Hybridní port je specifický a používá se k připojení zařízení, která při svém startu nemají informaci o tom, že budou použity VLANy, typicky se jedná o Wifi AP připojené ke Wireless kontrolérům, jež konfiguraci do AP "ládují" až během jejich startu.
Tagování je proces, kterým switch (i připojené koncové zařízení) opatřuje všechny odchozí pakety VLAN tagem. Naopak u portů, které jsou typu Access, dochází na straně switche k odstranění těchto tagů. A právě tagy na paketech určují, do kterého virtuálního switche daný paket patří. Z tohoto důvodu je u Trunkportů nutné, aby každý paket měl "vyplněnou" VLAN. V případě Access portu je příchozí (z pohledu switche) paket opatřen tagem podle toho, do jaké VLAN daný port patří (a logika switche jej následně na tomto základě zpracuje. Podobně to funguje u Hybrid portů, kde příchozí pakety jsou buďto již opatřeny VLAN tagem, nebo ne, a pak je switch otaguje na základě toho, jaké PVID má port nastaveno - což je poslední parametr, který je pro nastavení VLAN u portu důležitý. Pokud switch obdrží na vstupu portu paket, který patří do jiné VLAN než má port nastavené a zároveň se nejedná o hybridní port, NEBO pokud se objeví tagovaný paket na Access portu, bude takový paket zahozen.
Vzato prakticky:
- zařízení připojená Access portem "neví", že něco jako VLAN v síti funguje. Switch naopak všechny pakety, jdoucí na toto zařízení, tagů zbavuje.
- zařízení připojená k Trunk portu "musí vědět," že v síti jsou nasazeny VLANy, a tedy musí tagovat. Switch pouze kontroluje, zda tagy v paketech odpovídají nakonfigurovaným tagům na portu switche.
- zařízení připojená k Hybrid portu fungují i v případě, že o VLAN "neví", nicméně pouze ve VLAN, na kterou je na daném portu switche nastaveno PVID. Aby mohla využít dalších VLAN, musí začít tagovat. Switch u VLANy s PVID je schopen fungovat obojakým způsobem, tedy tagy odebírat i ponechávat.
Tento odstavec je asi nejdůležitější "praktické" shrnutí, na jehož bázi a znalosti budete schopni vytvořit téměř jakoukoli konfiguraci týkající se VLAN.
Vzorový příklad
Mějme větší síť ve dvou budovách, sestavenou ze dvou switchů, s implementovanou bezdrátovou sítí realizovanou pomocí kontroléru a několika AP, která obsahuje 3 segmenty: segment pro standardní uživatele, segment pro hosty a segment pro nebezpečné pokusy šíleného ajtíka. Do všech tří sítí jsou zavedeny bezdrátové sítě, jejichž SSID budiž "Users", "Guests" a "ITMordor" (jejich jména jsou významově popisná ). Všechny sítě budou připojeny do internetu pomocí jednoho routeru, který bude ve firewallu zohledňovat, ze které sítě komunikace přichází.
Jak je patrno, jde o klasické řešení pro VLAN. Určíme si jednotlivé VLAN-ID:
- uživatelská VLAN: 100
- hostovská VLAN: 120
- ajtíkova VLAN: 500
- management VLAN: 10
Proč je tam najednou čtvrtá síť? Tuto síť využijeme pro všechna zařízení, která budou použita pro vlastní sestavení sítě, tedy v této VLAN budou umístěny IP adresy switchů, wifi kontroléru a APček. Důvod je prostý - běžní uživatelé na tato zařízení přistupovat nepotřebují, naopak je žádoucí, aby management byl omezen na jednoznačně daná zařízení a uživatele, kteří budou mít fyzický přístup do této sítě.
Nyní sestavíme kostru sítě. Tou budou switche a router. Protože tyto komponenty budou součástí všech sítí, musí být členy všech VLAN. Toho docílíme tím, že použijeme vzájemné propojení pomocí Trunkportů, které budou obsahovat všechny VLANy. V našem případě využijeme pro propoj switchů optických modulů v portech 25 switchů a propoj s routerem pomocí portu č.1 switche A. Router připojíme pomocí LAN portu, na kterém také nastavíme totožný Trunk. Protože nastavujeme čistý trunk, nemusíme řešit PVID. Tím je kostra hotova.
Pokračujeme dalším krokem, nastavením Access portů pro počítače a další síťová zařízení v jednotlivých sítích. Na switchi A vyhradíme port č.2 pro VLAN 10, což bude management port pro správce sítě. Porty 3-8 na obou switchích plus port č.1 a 2 na switchi B zařadíme do ajtíkovy VLAN 500. Porty 9-20 na obou switchích budou vyhrazeny pro uživatelskou VLAN. Hostovská VLAN nebude mít přiřazeny žádné access porty, protože pro hosty v zasedacích místnostech se počítá pouze s pokrytím wifi. Na obou switchích tak máme rezervu 4 portů, které ponecháme v defaultní VLAN1 (nebo pro tyto účely můžeme vytvořit VLAN 4000, což je z pohledu bezpečnosti vhodnější řešení).
Na routeru nakonfigurujeme všechny sítě (doporučuji např. 192.168.100.0/24, 192.168.120.0/24, 10.5.0.0/24 a 192.168.10.0/24, což je řešení vhodné z hlediska mnemotechniky) pro dané VLANy v trunkportu, nastavíme DHCP scopes pro všechny sítě, nastavíme DNS a firewall.
Tím máme hotovu jednodušší část. Přikročíme k implementaci a zapojení bezdrátové sítě. K tomuto účelu využijeme dosud nepřiřazené porty 20-24 switche. Zapojení WLC do portu 21 switche A bude mít dvě varianty: Pokud je WLC pouhý administrátor nastavení AP, postačí, když bude připojen Access portem do management VLAN 10. Pokud ovšem zajišťuje spojení klientům (např. řeší přístup k internetu apod.), je nutné jej připojit Trunkportem, se všemi potřebnými VLAN tak, aby přes něj mohla proudit komunikace do potřebné sítě; v takovém případě bude ovšem nutné vytvořit ještě další "interní" VLAN pro síť mezi AP a WLC, my pro jednoduchost budeme uvažovat pouze základní řešení spočívající v pouhé administraci AP). Na samotném WLC pak zkonfigurujeme tři bezdrátové sítě, které budou mít nastaven tagging svých paketů do adekvátních VLAN 100, 120 a 500, čímž zajistíme, že bezdrátová komunikace bude po přechodu z AP zařazena do správné sítě na switchích.
K dispozici máme 5 AP, z nichž 2 kusy umístíme v budově A (porty 22 a 23) a 3 kusy v budově B (porty 21-23). Tyto porty nastavíme jako Hybrid porty, kde VLANy 100,120 a 500 budou tagged a VLAN 10 bude untagged. PVID nastavíme na VLAN 10. Tím zajistíme, že APčko bude při svém startu, kdy ještě "neví", že má používat VLANy, připojeno (jako access port) do VLAN 10, ve které je umístěn WLC, ze kterého získá během startu konfiguraci a seznam VLAN.
Výsledek bude vypadat takto:
Na závěr této kapitoly zrekapitulujeme, co jsme vytvořili:
- Spojili jsme dva switche a jeden router do jednoho logického celku
- tento celek jsme rozdělili na 4 samostatné virtuální sítě
- všechny sítě jsou připojeny k internetu, volitelně lze na routeru routovat i mezi těmito virtuálními sítěmi (a to třeba tak, že z management sítě lze dosáhnout všechny ostatní, ale obráceně to neplatí)
- přiřadili jsme porty k jednotlivým sítím a pro speciální zařízení typu AP jsme ustavili další trunkporty
Aplikace VLAN v Mikrotiku
Donedávna (do verze 6.41, ve které došlo k zásadním změnám) platilo, že Mikrotik řešil VLANy prakticky výlučně na úrovni svého procesoru, tj. pro každou VLAN bylo třeba na úrovni RouterOS vytvořit bridge, do které se přidaly access porty. Trunkport se pak řešil tak, že se tvořily virtuální ethernet porty nad fyzickým portem Mikrotiku, kterým se přiřazovalo VLAN ID a následně došlo k přidání do Bridge. Platilo, že pokud port neměl nastavenou VLAN, byl brán za access port a samotná VLAN byla emulovaná Bridgem. V našem případě by tedy např. port 1 switche A měl vytvořeny 3 virtuální adaptéry. Jde tedy o řešení analogické Linuxovým systémům, kde jsou VLANy řešeny právě takovým způsobem.
Níže je názorný příklad starého konceptu, ve kterém je použit malý Mikrotik v režimu sekundárního routeru, kdy jedna (hostovská) bezdrátová síť je vysunuta na rozhraní WAN a v LAN je "skryta" vnitřní síť organizace s privátní wifi. Zároveň je port ethernet2 použit jako trunkport k vyvedení obou sítí na další AP v rámci komplexu budov. Stav je tedy takový, že ve VLAN1 je WAN port Ethernet1, port bezdrátu Guest a trunkport E2. Ve VLAN2 alias LAN jsou pak porty E3 a E4, bezdrát Private a konečně opět trunkport E2. Výpis konfigurace níže popisuje vytvoření obou Bridgů, vytvoření dvou virtuálních VLAN portů nad rozhraním E2 s ID 1 a 2 a následné rozřazení portů do bridgů.
/interface bridge
add name=bridge_vlan1_WAN
add name=bridge_vlan2_LAN
/interface vlan
add interface=ether2 l2mtu=1594 name=vlan1_e2 vlan-id=1
add interface=ether2 l2mtu=1594 name=vlan2_e2 vlan-id=2
/interface bridge port
add bridge=bridge_vlan1_WAN interface=ether1
add bridge=bridge_vlan1_WAN interface=vlan1_e2
add bridge=bridge_vlan1_WAN interface=wlan_GUEST
add bridge=bridge_vlan2_LAN interface=vlan2_e2
add bridge=bridge_vlan2_LAN interface=wlan_PRIVATE
add bridge=bridge_vlan2_LAN interface=ether3
add bridge=bridge_vlan2_LAN interface=ether4Nové paradigma od verze 6.41 zavádí u zařízení, která toho jsou po HW stránce schopna, tzv. HW offloading, tj. řešení VLAN operací na úrovni čipsetu switche (tam, kde to nelze, bude vše řešit nadále procesor) a v rámci jednoho Bridge - tedy velmi podobně, jak je to řešeno ve switchích konkurenčních značek. Velká výhoda tkví v tom, že nyní není problém s protokoly běžícími na L2, jako je STP/RSTP, stejně tak IGMP snooping.
Konfigurace tedy vypadá následovně - všechny porty jsou v jednom bridgi, je nastaven HW offloading (funguje pouze pro některé modely Mikrotik, zejména ty s gigabitovými porty). Vše podstatné se děje v menu Bridge - nejprve do bridge přidáme všechny porty a následně si nastavíme, do které VLAN bude port patřit. Pokud vycházíme z defaultní konfigurace, je Bridge1 již vytvořen, zkontrolujeme jen, že jsou v něm všechny potřebné porty a úvodní vytváření bridge přeskočíme, v takovém případě ale musíme ručně ponastavovat PVID u všech portů, které nejsou čistým trunkem. Zároveň je třeba nastavit ručně PVID u Bridge1.
#-------------------------------------------------------
# Vytvoříme Bridge
#-------------------------------------------------------
/interface bridge
add name=bridge1 igmp-snooping=no protocol-mode=none pvid=10
/interface bridge port
add bridge=bridge1 interface=ether1 hw=yes
add bridge=bridge1 interface=ether2 hw=yes pvid=10
add bridge=bridge1 interface=ether3 hw=yes pvid=500
add bridge=bridge1 interface=ether4 hw=yes pvid=500
add bridge=bridge1 interface=ether5 hw=yes pvid=500
add bridge=bridge1 interface=ether6 hw=yes pvid=500
add bridge=bridge1 interface=ether7 hw=yes pvid=500
add bridge=bridge1 interface=ether8 hw=yes pvid=500
add bridge=bridge1 interface=ether9 hw=yes pvid=100
add bridge=bridge1 interface=ether10 hw=yes pvid=100
add bridge=bridge1 interface=ether11 hw=yes pvid=100
add bridge=bridge1 interface=ether12 hw=yes pvid=100
add bridge=bridge1 interface=ether13 hw=yes pvid=100
add bridge=bridge1 interface=ether14 hw=yes pvid=100
add bridge=bridge1 interface=ether15 hw=yes pvid=100
add bridge=bridge1 interface=ether16 hw=yes pvid=100
add bridge=bridge1 interface=ether17 hw=yes pvid=100
add bridge=bridge1 interface=ether18 hw=yes pvid=100
add bridge=bridge1 interface=ether19 hw=yes pvid=100
add bridge=bridge1 interface=ether20 hw=yes pvid=100
add bridge=bridge1 interface=ether21 hw=yes pvid=10
add bridge=bridge1 interface=ether22 hw=yes pvid=10
add bridge=bridge1 interface=ether23 hw=yes pvid=10
add bridge=bridge1 interface=ether24 hw=yes pvid=4000
add bridge=bridge1 interface=sfp-sfpplus1 hw=yes
add bridge=bridge1 interface=sfp-sfpplus2 hw=yes pvid=4000
#-------------------------------------------------------
# Rozdělíme porty dle VLAN
#-------------------------------------------------------
/interface bridge vlan
add bridge=bridge1 tagged=sfp-sfpplus1,ether1,ether22,ether23 untagged=ether9,ether10,ether11,ether12,ether13,ether14,ether15,ether16,ether17,ether18,ether19,ether20 vlan-ids=100
add bridge=bridge1 tagged=sfp-sfpplus1,ether1,ether22,ether23 vlan-ids=120
add bridge=bridge1 tagged=sfp-sfpplus1,ether1,ether22,ether23 untagged=ether3,ether4,ether5,ether6,ether7,ether8 vlan-ids=500
add bridge=bridge1 tagged=sfp-sfpplus1,ether1,ether22,ether23 untagged=ether2 vlan-ids=10
add bridge=bridge1 untagged=ether24,sfp-sfpplus2 vlan-ids=4000
#-------------------------------------------------------
# Nastavíme IP adresu
#-------------------------------------------------------
/ip address
add address=192.168.1.2/24 interface=bridge1 network=192.168.1.0
#-------------------------------------------------------
# Nakonec aktivujeme samotné VLANy
#-------------------------------------------------------
/interface bridge set bridge1 vlan-filtering=yes
A jak to vypadá z pohledu GUI? Vše je opět vidět v menu Bridge, rozkliknutím jednotlivých VLAN ID vidíte porty které jsou tagged i které jsou untagged a zároveň i porty, které jsou aktivní. Vpravo je vidět aktivace samotného režimu VLAN (VLAN Filtering) a PVID pro Bridge1:
Obecně doporučuji začínat vždy s čistým zařízením, nepoužívat výchozí konfiguraci, základem je mít WinBox.
Další informace najdete na MKT wiki: https://wiki.mikrotik.com/wiki/Manual:Interface/Bridge
Závěr
V příloze najdete ukázkovou konfiguraci switche A, kterou stačí nahrát do switche (drag&drop do okna "Files" - pokud je v něm složka "flash", tak rovnou do ní) a pomocí příkazu v konzoli naimportujte:
/import flash/pnet.rscPokud nemáte soubor ve flash, použijte:
/import pnet.rscPro jistotu doporučuji po každém nahrání ještě restart zařízení. Switch bude dostupný jen na portech, které jsou ve VLAN10 (tam, kam je přes PVID zařazen samotný bridge, viz direktiva, kterou jsme bridge1 vytvořili).
Doufám, že se vám můj článek líbil a že informace z něj někdy použijete.
P.S.: omluva na závěr, až nyní jsem si všiml, že mám na obrázku switchů obráceně pořadí portů, port1 je fyzicky umístěn v dolní řadě (naznačen je barevně nahoře, jako trunk) - myslím ale, že to na výsledku až tak moc nemění.
Zkus tam prosím někde zvýraznit, že potřebuješ "chytré" switche s managementem. Neuděláš to s libovolným switchem.
Jinak je to hodně odborně napsané i na běžné ajťáky ve firmách.
Ve spoustě firem se s příchodem GDPR musí řešit situace, kdy se do sítě připojují firemní "návštěvníci". Bude se muset zajistit a zdokumentovat opatření, jak jsou odděleni "návštěvníci" od firemní části sítě. Nemusí jít jen o návštěvníky, ale i o subdodavatele částí informačních systémů, kde je třeba zajistit, aby měl takový člověk přístup pouze ke konkrétní věci, kam přístup potřebuje. Nestačí to pouze na úrovni přihlašovacích údajů ke konkrétnímu serveru.
Tohle se dá řešit různě:
1. do firemní sítě je vůbec nepustím. Různé konzultační a auditorské firmy apod. to pak musí řešit např. vlastním mobilním připojením. Zvlášť u přátel vedení tohle bude problém.
2. vytvořím novou fyzicky oddělenou síť - to sebou nese velké náklady
3. použitím VLAN vytvořím novou oddělenou "viruální" síť v existující síti, ve které se hosté dostanou pouze ven na internet a přitom se nedostanou do vnitřní sítě.
Já to hodně rychle přestal číst :) Ale je mi jasné, že všichni nemohou rozumět všemu.
Já zatím nejsem schopen udělat ani druhou WLAN (wifi lan) pro hosty, prostě se mi to nedaří a nedaří. Mám ale starší verzi routerOS (5.26?) a opravdu se mi nechce dělat upgrade… po špatných zkušenostech z minula, kdy mi z Mikrotiku zůstala jen cihla.
Do února, než mi to někdo uděláte přímo na místě, to bude muset vydržet. To té doby jsou hosté bez internetu - respektive, pokud něco opravdu musíme řešit na hostově notebooku, připojím ho kabelem, předtím fyzicky odpojím všechno z ostatních RJ-45 portů, což je mimořádně otravné.
Upgrade verze systému se není potřeba bát, funguje to. A když je z Mikrotiku "cihla", dá se vždycky použít Netinstall (a pomocí Etherboot nahrát do Mikrotiku nový SW).
On to ale v důsledku taky může být Mikrotik RB941 za 500 peněz..
Jinak nechtěl jsem řešit výstavbu sítě jako takovou, článek byl a je mířen jen na samotné zpracování VLAN.
Mikrotik za 500 + pokud potřebuješ nějaký switch a chceš na něm řešit VLAN, tak by měl být spravovatelný, aby ti šly příslušné VLAN na odpovídající porty switche. Nebo mi něco uniká?
Uniká.
Technicky můžeš použít Mikrotiky jako trunkporty (core switche) a běžně switche (za 200Kč) jako access porty. Obecně dnes ale v malých firmách to je spíše o oddělení wifin apod., takže si vystačíš i jen s Mikrotiky. A právě takových instalací mám asi nejvíce. Typicky hospoda, kde máš jedno připojení. které sdílí majitel se svou kanceláří plus veřejná wifi síť z několika AP. Právě problém více AP VLANy řeší velmi elegantně.
Vidíš a konkrétní příklad takové jednoduché implementace třeba pro hospodu mi tam chybí.
tohle mne zaujalo, na to máte nějaký výklad od právníka, nebo nějakého odborného asistenta ke GDPR nebo jste o tom někde jen četl?
dovedu si představit scénáře, kde úroveň oprávnění je jedné co odděluje třetí stranu od nějakých dat. například konzultační firmu, která nasazuje na stejném aplikačním serveru třeba pátou aplikaci, vedle čtyř dalších, kde dvě jsem nasazoval já a dvě jiná konzultační firma (některé firmy vám to nedovolí abyste si to nasadili sami).
Tady ani tak nejde o pravníky s jejich výklady, jako spis o interní audit, případně kontrolu v případě průšvihu. A hlavně pak poimplementační vzdálený přístup dané firmy k datům.
Chápu, že je obtížné, aby nějaká externí firma měla práva k administraci databáze a současně neměla přístup k datům.
ano ale admin práva do DB a izolovat síť skrze VLAN jsou dvě různé věci :) samozřejmě pokud pak nabízí podporu tak ta práva mít musí, na druhou stranu já zažil praxi, že firma má admin práva k DB pouze dočasně po dobu nasazení aplikace a pak vždy jen dočasně na vyžádání (a ještě to musí vysvětlit a obhájit).
Přesně tak. Současně by externí firma měla mít i vzdálený přístup na vyžádání a ten by měl být síťově omezený (k tomu se právě VLAN hodí) pouze na to, co nutně potřebuje.
Ještě obtížněji je řešitelná situace, kdy pro správu daného řešení je nutné přihlásit se na vzdálenou plochu windows počítače, na kterém ta aplikace běží. Pak pokud je ten počítač součástí nějaké sítě, má daný uživatel otevřený přístup ke všemu v sítí - obrazně řečeno, pochopitelně mezi ním ještě stojí uživatelské účty, ale může prostě zkoušet různé služby v dané síti.
tak za první asi by bylo vidět že tam zkouší účty a navíc bych očekával že ten systém je dostatečně zabezpečen, například skrze FW.
Ale jo, pěkné.
Tlesky, tlesk !
Super navod, ale priklanam su ku konstruktivnej kritike...zbytocne moc zlozity na uvod do vlanov. Navyse v tejto problematike mame nejake nedoriesene otazky...vid moj nedavny problem v kombinacii s UBNT, kde si mi tvrdil, ze to je zle a ze tak to nemoze fungovat a ono mi to napriek tomu funguje prave tak;o). Netreba zabudat, ze kazdy vyrobca ma svoju vlastnu implementaciu VLAN, takze obcas chvilu trva aj profikovi, aby sa z toho vysomaril.
Osobne by som zacal s praktickou ukazkou na urovni domaceho AP a tak, aby to pochopil aj L-Core;o).
Typicky priklad je domace AP (AP v krcme), kde treba oddelit domacu siet od hosti. MT sice umoznuje pomerne vela moznosti ako to urobit, ale ist na to cez VLAN je tiez cesta. Navyse k takemuto prikladu mozeme pridat dalsi...oddelit manazment od pracovnikov (deti od rodicov) a pod.
Az nasledne by som pridaval zlozitejsie kombinacie brana---ap----switch---ap a pod.
Jednoduchý příklad máš uveden v pre-641 příkladu. Principy jsou stále tytéž. "Hlavní" příklad názorně ilustruje všechny varianty připojení a rozhodně jej nepokládám za složitý - takové označení bych si dovolil např. pro setup Q-in-Q (tedy VLANy ve VLANě)
edit: a v případě jediného zařízení nedávají vlany moc smysl, tam stačí rozdělit porty do bridgů.
Aj ked sa pojde prevazne na wifi, vytvorim si svoju a hostovsku, kadej priradim iny rozsah, ale pre istotu by som chcel aj ethernet porty, tak si napr vytvorim bridg firma, kam dam eth2-3, a guest kde dam eth4-5 a kazdemu priradim rozsah z wifi a je to ?
Díky za skvělé vysvětlení a návod. Mám to ale bohužel udělané ve verzi před 6.41 a rád bych to předělal do nového konceptu, protože to strašně zatěžuje procesor. Mohl bys mi, prosím, doporučit nějaký postup, jak to postupně za provozu "přepíchat" do nového tagovaného bridge? Mám tam asi 30 vlan, tedy asi 300 vlanových interfaců, musím nějak postupně a musí fungovat všechny vlany v trunku, tedy jak ve starých bridgích tak v novém tagovaném. Prostě mám strach, abych vytvořením tagovaného bridge nepřerušil doposud funkční provoz.
bez výpadku to nevidím jako reálné. Jakákoli chyba a jsi tak jako tak v háji.
to je mi samozřejmě jasný, dotaz směřoval spíš tím směrem, jestli lze nastavit tagovaný bridge v koexistenci se starým řešením... krátké výpadky jednotlivých vlan přežiju, ale "všechno vylejt a znova nastavit" mě bude stát asi tak 3 hodiny provozu, což úplně nechci...
Pokud jednou provedeš upgrade RouterOS, staré řešení nebude dobré a bude potřeba to překopat. Zkus toto řešení z jednoho diskuzního fóra (je to v posledním příspěvku). Jen je potřeba upozornit, že toto řešení podporují jen některé přepínací čipy (jak v článku výše upozorňoval jeho autor).
díky za tip, mám to na CRS326, tam by to fungovat mělo. Jestli jsem to z toho článku správně pochopil, tak si můžu připravit nový tagovaný bridge a zkoušet to můžu jenom zapnutím/vypnutím vlan-filteringu. To by mohla být cesta... zkusím to a kdyžtak sem pak popíšu zkušenosti
V případě použití nastavení z tohoto článku to bude fungovat také, ale bude to silně zatěžovat CPU. Při použití konfigurace z fóra je to rychlejší (dle možností osazených čipů) a bez zatížení samotného CPU. Jen by nebylo dobré tato dvě řešení kombinovat dohromady, protože pak se to mlátí mezi sebou.
Díky za užitečný návod, ale ...
Je zde detailně popsaná konfigurace switche, ale já mám problém s nastavením routeru. Vyjmul jsem port eth5 z defaultní bridge, vytvořil jsem vlan interfacy nad tímto portem eth5 a na ně jsem pověsil příslušné dhcp servery, k čemuž jsem připojil trunk port ze switche. Paket sniffer na routeru vidí dhcp pakety s vlanid 99, přijmuvší ze switche, ale na portu vlan99eth5 router se tyto pakety neobjeví a DHCP server nemá na co odpovídat.
Předem díky komukoliv za radu, co dělám blbě.
DHCP server VŽDY NA BRIDGE! I kdyby měl být v bridgi jen jen iface.
Zadrbal jsem úplně mrtě času nad tím, když jsem chtěl mít management IP na mikrotiku v rámci jedné vlany.... prostě žádný návod včetně tohoto mě nefunoval.... Musí se přidat bridge1 do do tagged interfacu a pak dané vlaně nad bridgem jde už asiciovat ip a funguje to.
Díky za super článek. S jeho pomocí jsem zprovoznil svou první VLANu
Jen tu trochu chybí nějaké moudro ohledně toho routeru. Tím jsem totiž začal.
V kombinaci s wiki Mikrotiku se to nakonec snad zdařilo, ač nevím, zda jsem udělal vše dle "správných" zvyklostí:
- bylo potřeba přidat bridge1 mezi tagované porty (jako psal předchozí komentář)
- bylo potřeba vytvořit VLAN interfaces na bridge1 a přidat jim IP adresy
- následně jsem si vytvořil DHCP pro tyto vytvořené VLAN interfaces (nejsem si jistý, zda je to správně s ohledem na předchozí koment... ale funguje to)
Ještě dotaz k článku:
Proč přidělujeme bridge1 IP adresu 192.168.1.2? Nemělo by to být ze sítě 192.168.10.0/24, když jsme si tento rozsah na routeru mnemotechnicky zvolili?
ad IP adresa: to je samozřejmě typografická chyba
co se týká vlan ifaces, pak jsi ale přešel do režimu VLANy řízené procesorem (L3 switch), výše uvedené řešení je konfigurace pro switchchip (L2).
Podle prvního obrázku jsem nabyl dojmu, že trunk porty jsou prostě trunk a tím je hotovo. Až později v 1. příkladu sw řízení -(starší verze) jsem zjistil, že i trunk porty musí mít definovány VLAN. Je to tak?
Z posledního screenshotu zase vyplývá, že konfigurace Access&trunk&hybrid je jiná ne v teoretickém úvodu. Tam se prostě řeklo, že konkrétní port se definuje Acc/Tr/Hy a je hotovo. Na obrázku z toho mám pocit, portům nepřiřazuji vlan, ale že vlanům přiřazuji porty . A že typ portu je až výsledkem toho v jakých je vlanech a ne, pouhým určením, že to bude konrtétně třeba access.
Také mi neuniklo (stále z toho posledního obrazku)
- že jeden Tagged porty mohou být ve víc vlanech (celkem logické, jen jinak řečeno, že portem prochází víc vlanů - podstata VLAN)
- že jeden port může být zařazen do Untagged jen jedenkrát (jinak řečeno, že má nejvýš jednu VLAN)...patrně access
článek byl výživný, nedal se prolétnout bleskem. Například zkratka WLC je pro neznalého překvapení.
Co s porty, které nejsou v žádné VLAN, ty se jeví jako mrtvé?
Ještě když koukám na nové paradigma:
Zdá se mi tam redundantní zápis (2 pohledy říkající totéž.):
1. V sekci Vytvoříme Bridge je zbytečné PVID, vždyť tato informace je obsažena v sekci Rozdělíme porty dle VLAN v poli Untagged. chybějící PVID stejně nebudou v untagged=čistý trunk
2. V sekci sekci Rozdělíme porty dle VLAN je pole untagged zbytečné , tato informace je již v sekci Vytvoříme Bridge v PVID . (mimo případy, kdy by šlo o hybridní trunk, pokud senepletu)
A poslední dotaz:
Hybridní porty jsou podmnožinou trunkových (když aspoň jedna (právě jedna-víc nelze) z vlan je netagovaná)?
-Trunk: aspoň 2 VLAN, 1 znich nemusí být tagovaná a zbytek tagován být mu.
+
-Pokud má trunk port mix tagovaných a netagovaných VLAN, jedná se o tzv. Hybridní port.
Čili právě v situaci, kdy jedna není tagovaná, přechází trunk do hybridního? Navíc 1 netagovaná vlan na portu je maximum.
Pokud switch obdrží na vstupu portu paket, který patří do jiné VLAN než má port nastavené a zároveň se nejedná o hybridní port, NEBO pokud se objeví tagovaný paket na Access portu, bude takový paket zahozen.
Co když daný port uvedu jednou jako tagged a podruhé jako untagged u stejné VLAN? Co to udělá? Má to nějaký smysl?