Egy sokak által nem kedvelt és kevésbé értett technológiát veszünk ma górcső alá. Ez pedig nem más, mint a Private VLAN (továbbiakban PVLAN).
Képzeljük el az alábbi topológiát. 4 switchünk van (3 db L3-as (SW1-SW3) és egy db L2-es (SW4), ez a bejegyzés végén nyer értelmet, egyelőre teljesen mindegy), illetve 5 db routerünk, amelyek a kliensek szerepét töltik majd be. Két community és egy isolated VLAN lesz definiálva (lásd a kép alján), illetve egy promiscuous port, amelyre a VLAN default gateway-e kerül (R5). Nem kell megijedni, átnézzük, mik ezek a szerepek, és hogyan is működik ez az egész.
Első lépésként nézzük meg, miért találták ki a Private VLAN technológiát, milyen előnyöket kínál számunkra.
Cisco “best practice”, hogy egy VLAN-hoz egy IP subnetet definiálunk, azaz a VLAN és az adott subnet “párban vannak”. Ez azt jelenti, hogy pl. a VLAN100-hoz a 192.168.100.0/24 tartozik, a VLAN101-hez a 192.168.101.0/24, stb. (nem kell, hogy /24 legyen természetesen, de ez a leggyakoribb, és persze lehet Class A, B, C is, csak példának írtam fent a 192.168.x.x-et).
Megjegyzés: természetesen megoldható egy VLAN-hoz több subnetet definiálni az ún. secondary subnetek segítségével.
Tehát a lényeg, hogy ez az 1-1 összerendelés sok esetben pazarló IP cím gazdálkodást eredményez (kevés kliens van a subnetben, és ezért ellövünk /24-eket).
Képzelj el egy kis céget, ahol a különböző munkaügyi osztályokat (IT, HR, pénzügy, stb.) külön VLAN-ba teszed, hogy elkülönítsd őket (VLAN-ok között átjárás alapesetben nincs, ehhez Layer3-as eszköz (router, L3 switch) szükséges). Ha 5 VLAN-t definiálsz, máris ellőttél 5 db IP subnetet. A VLAN-ok közötti kommunikációt ACL-lel tudod szűrni a Layer3-as eszközön. Na itt jön képbe a Private VLAN technológia. A lényege, hogy ún. primary és secondary VLAN-okat definiálunk. A külvilág számára csak a primary VLAN látszik majd (ehhez rendeljük az IP tartományt), de logikailag több VLAN-unk van, amelyek között a forgalom szűrhető. Ha a fenti ábrát nézed, az összes gép a 192.168.1.0/24 IP tartományban lesz , mégsem tudnak majd egymással kommunikálni, mert más Secondary VLAN-ban lesznek. Azaz IP subneteket spórolunk. A Private VLAN technológiát SP (Service Provider) környezetben is lehet alkalmazni, az ügyfelek elszeparálására. Hiába vannak a kliensek egy IP subnetben az SP switchen, mégsem tudnak kommunikálni egymással.
Néhány fogalmat definiálnunk kell, hogy tovább haladhassunk a technológia boncolgatásában. Ezek a primary VLAN, community VLAN, isolated VLAN és promiscuous portok leírásai.
- Primary VLAN: elsődleges VLAN. Ehhez a VLAN-hoz tartozik az IP subnet. Ehhez a VLAN-hoz rendelünk másodlagos VLAN-okat (association)
- Secondary VLAN: két típusát különböztetjük meg.
- Community: az egy community VLAN-ba tartozó gépek tudnak egymással kommunikálni. Egy primary VLAN-hoz több community VLAN tartozhat. Két különböző community VLAN kliensei NEM tudnak egymással kommunikálni.
- Isolated: az ebben lévő gépek nem tudnak sem a community VLAN-ban lévő gépekkel, sem a többi isolated VLAN-ban lévő géppel kommunikálni. Ebből következik, hogy egy primary VLAN-hoz csak egy isolated VLAN-t tudunk definiálni.
- Promiscuous port: olyan eszközöket definiálunk ide, amelyeket a secondary VLAN-okból el lehet érni. Default gateway, NAS, stb. A promiscuous portoknál megadható, hogy mely secondary subnetekből érhessük el őket (ez interfacenként külön konfigurálható).
Elveszítetted a fonalat? Nem csodálom. Leírva bonyolult, ezért csináltam egy ábrát, amelyen látod, ki kivel tud kommunikálni a mi topológiánkban.
Jól láthatóak a szabályok, azaz:
- Egy adott community VLAN-ba tartozó gépek egymással kommunikálhatnak (R1-R2)
- Két külön community VLAN-ba tartozó gépek egymással NEM kommunikálhatnak (R2-R3)
- Az isolated VLAN-ba tartozó gép (R4) csak a promiscuous porttal kommunikálhat, más géppel nem. Bár az ábrán nem látszik, az isolated VLAN-ban lévő gépek egymással sem kommunikálhatnak (ezért lehet csak egy ilyen VLAN egy primary VLAN-hoz társítva)
- A promiscuous port (R5) bárkivel kommunikálhat (másik promiscuous porttal is természetesen, ha van ilyen).
Remélem így már érthetőbb.
Amíg egy switchen kell konfigurálni a PVLAN-t, nincs nagy trükk és nincs probléma. De mi van akkor, ha több switch érintett (ahogy a mi topológiánkban is)?
Egy megjegyzés gyorsan: VTPv1 és VTPv2 esetén transparent módban kell lennie a switchnek, hogy a Private VLAN-t engedélyezni tudd. VTPv3 már támogatja alapból, sőt, le is tudja szórni a teljes VTP domainban a VLAN-okat és a primary-secondary kapcsolatokat, ez megkönnyíti a konfigurációt.
Első és legfontosabb, és sokan nem jól gondolják/tudják: nincs “dupla taggelés”. Tehát mikor a frame átmegy a trunkön két switch között, nem kerül rá a primary és secondary VLAN tag egyszerre. Csak a másodlagos VLAN tag kerül alkalmazásra. Miért? Gondolj bele: a primary-secondary VLAN mapping mindkét switchen konfigurálva van. Mi értelme lenne a primary VLAN taget használni, mikor a másik switch is tudja, hogy az adott secondary VLAN community vagy isolated, és hogy melyik primary VLAN-hoz tartozik? Semmi. Ezért csak a secondary VLAN ID tag kerül bele a dot1q headerbe.
Ha az adott frame promiscuous portról érkezett, akkor természetesen a primary VLAN ID-val taggeljük, mikor kiküldjük a trunk-ön.
Még egy megjegyzés: ha csak egy switchünk van, ott nincs taggelés (minek lenne, a switch tudja a primary-secondary összekapcsolást, és azt is, melyik portja melyik VLAN-ban van). Tehát a tag csak akkor kerül képbe, amikor trunk porton kell átmennie a frame-nek.
Nézzük, hogy néz ez ki a technológia a gyakorlatban.
A rossz hír, hogy ez a feature virtuális platformokon (IOL, IOU, IOSv) nem támogatott. Vagyis fel lehet konfigurálni, csak nem működik. Elfogadja a switch a parancsokat, de nem továbbítja a frame-ket. Tehát valós hardver kell hozzá, ami nekem most nincs kéznél 🙂 . Minden rosszban van valami jó, ezek miatt a korlátozások miatt nincs a CCIE lab vizsgán Private VLAN (csak a Written blueprintben van benne), mert ők sem tudják virtuális platformon használni. Persze ettől még egy CCNP SWITCH/TSHOOT Simletben feltűnhet lazán, és a valós életben is, és ugye mi nem a papírra gyúrunk, hanem a tudásra 🙂 .
Alább a konfiguráció.
Első lépés: VTP transparent mód.
! SW1-SW4-en felkonfigurálni ! SW1#conf t Enter configuration commands, one per line. End with CNTL/Z. SW1(config)#vtp mode transparent Setting device to VTP Transparent mode for VLANS. SW1(config)#end SW1#
Következik a VLAN-ok definiálása (először a secondary, aztán a primary!), majd a primary-secondary párosítás:
!SW1-SW4-en felkonfigurálni ! SW1(config)#vlan 101 SW1(config-vlan)#private-vlan community SW1(config-vlan)#name COMM1 SW1(config-vlan)#vlan 102 SW1(config-vlan)#name COMM2 SW1(config-vlan)#private-vlan community SW1(config-vlan)#vlan 103 SW1(config-vlan)#private-vlan isolated SW1(config-vlan)#name ISOLATED SW1(config-vlan)#vlan 100 SW1(config-vlan)#name PRIMARY SW1(config-vlan)#private-vlan primary SW1(config-vlan)#private-vlan association 101-103 SW1(config-vlan)#end
Tegyük a megfelelő interface-ket a megfelelő VLAN-okba. Kérlek figyeld a kommenteket a konfigurációban.
!SW1 - E0/0 a 101-es community VLAN-ba kerül. Primary-Sec: 100-101 conf t interface Ethernet0/0 switchport private-vlan host-association 100 101 switchport mode private-vlan host duplex auto end ! ! ! ! !SW2 conf t interface Ethernet0/0 switchport private-vlan host-association 100 101 switchport mode private-vlan host duplex auto end ! ! ! ! !SW3 conf t interface Ethernet0/0 switchport private-vlan host-association 100 102 switchport mode private-vlan host duplex auto end ! ! ! ! !SW4. E0/0 isolated, de konfig szinten nincs különbség. conf t interface Ethernet0/0 switchport private-vlan host-association 100 103 switchport mode private-vlan host duplex auto ! E0/1 promiscuous port. A 100-as primary VLAN-hoz a 101-103 secondary-t mappelem ! azaz ezek a seondary VLAN-ok tudnak kommunikálni ezzel a promiscuous porttal. interface Ethernet0/1 switchport private-vlan mapping 100 101-103 switchport mode private-vlan promiscuous duplex auto end
Igazából ennyi a konfiguráció. A lényeg, hogy mindig meg kell adni a primary és secondary VLAN-t is az interface konfig alatt.
Néhány show parancs kimenet. A show int status pl. tök érdekes, mert mindkét VLAN-t írja.
SW4#sh int status
Port Name Status Vlan Duplex Speed Type
Et0/0 connected 100,103 auto auto unknown
Et0/1 connected 100 auto auto unknown
Et0/2 connected 1 auto auto unknown
Et0/3 connected trunk auto auto unknown
SW4#
Mondhatnám, hogy ennyi, de egy kevésbé ismert részletet még megmutatnék. Ez már szigorúan haladóknak, az ötösért megy 🙂 . Való életben szinte soha nem használjuk, de létezik két speciális trunk:
- Promiscuous PVLAN Trunk
- Isolated PVLAN Trunk
Mutatom is a módosított topológiánkat, amelyeken elmagyarázom a működésüket. SW4 már nincs a primary VLAN domainben, és R1 lett a promiscuous eszközünk.
Promiscuous PVLAN Trunk
Az esetben használjuk, ha a promiscuous porton lévő eszköz felé is trunk van konfigurálva a switchen, de az az eszköz nem támogatja a PVLAN feature-t. Pl. egy router, amely “router-on-a-stick” megoldással több VLAN-t fogad. Ez esetünkben R1. Ilyen esetben a switch, mikor kiküldi a keretet a trunk porton, a secondary VLAN ID taget kicseréli a primary VLAN ID-ra. Miért? Mert a router nem támogatja a PVLAN feature-t, nem ismeri a secondary VLAN-okat, csak a primary subnet van rajta felvéve (emlékszel, a külvilág az egészből csak a primary VLAN-t látja!).
Isolated PVLAN Trunk
A másik eset SW3-SW4 között van. SW4 a módosított rajzon nem támogatja a PVLAN-t (pl. egy Catalyst 2950-es switch), tudja viszont az ún. “protected port” feature-t. A protected port a PVLAN kicsiben, szűréseket tud csinálni a portok között, de csak egy switchen értelmezhető. SW3, mielőtt kiküldi SW4 felé a frame-t, a primary VLAN ID-t kicseréli az Isolated Secondary VLAN ID-ra. Miért? Mert SW4 nem támogatja a PVLAN-t, viszont protected portként szűri a forgalmat.
Kérdések, észrevételek? Várom őket kommentben!
