Praca z VLANami to niewątpliwie chleb powszedni każdego sieciowca. Wiedza na temat działania prywatnych VLANów nie jest już jednak tak powszechna – temat ten pojawia się w ścieżce certyfikacyjnej dopiero na poziomie Professional. I szczerze mówiąc trochę się temu dziwię. Zagadnienie, które na pierwszy rzut oka wydaje się być skomplikowane, okazuje się być proste i zrozumiałe jeśli tylko dobrze mu się przyjrzeć.
Jeśli nie wiesz czym są prywatne VLANy lub chcesz po prostu przypomnieć sobie jak się je konfiguruje to ten artykuł jest dla Ciebie!
Teoria
Jak zapewne dobrze wiesz, głównym powodem istnienia VLANów jest chęć zapanowania nad rozmiarem domen rozgłoszeniowych. Pomimo to obecnie VLANy używa się bardziej z myślą o segmentacji ruchu sieciowego – i nie ma w tym nic złego (jest bezpieczniej, a domeny rozgłoszeniowe są i tak przy okazji pod kontrolą). Wydawałoby się więc, że skoro wrzuciliśmy dane urządzenia do wspólnego kubełka (VLANu) to jak najbardziej powinny się one między sobą komunikować. Tak w istocie jest w większości przypadków. Problematyczna staje się natomiast sytuacja, w której chcielibyśmy dokonać dalszej separacji urządzeń już znajdujących się we wspólnym VLANie. Pamiętajmy, że dobrą praktyką jest stosowanie pojedynczych podsieci per VLAN.
Załóżmy więc, że mamy 200 urządzeń we wspólnym VLANie (i wspólnej podsieci) i chcielibyśmy podzielić je na 4 grupy, które z przyczyn bezpieczeństwa nie mogą się ze sobą komunikować. Oczywiście nie chcemy readresować – raz, że jest to żmudna robota, a dwa, że przyjęty w danej firmie schemat adresacji może nie pozwalać na łatwą i spójną readresację. Właśnie w takich przypadkach przychodzą nam z pomocą prywatne VLANy. Można je sobie wyobrazić jako VLANy zagnieżdżone w… VLANie. Technologia ta została opisana przez Cisco w RFC 5517 i jest na szczęście używana w sporej ilości urządzeń innych producentów (m.in. Arista, Brocade, Extreme, FortiNet, Juniper, MICROSENS, Ubiquiti, Alcatel-Lucent).
Do opisu działania prywatnych VLANów posłużymy się poniższą topologią:
Zawiera ona dwa przełączniki SW1 oraz SW2 połączone ze sobą za pomocą zwykłego trunka tagowanego za pomocą dot1q. Warstwę trzecią moglibyśmy oczywiście realizować bezpośrednio na przełącznikach, ale dla klarowności przykładu routing będzie realizowany na dedykowanym do tego routerze RTR. Do przełączników podłączone jest w sumie 6 hostów oznaczonych od H1 do H6. Wszystkie urządzenia znajdują się we wspólnej podsieci 192.168.1.0/24.
Koncepcja działania prywatnych VLANów
Koncepcja działania prywatnych VLANów jest stosunkowo prosta. Możemy sobie to wyobrazić jako partycjonowanie pojedynczego VLANu (który będziemy w dalszej części nazywać Primary VLANem) na mniejsze sub-VLANy (nazywane Secondary VLANami). Primary VLAN jest więc kolekcją jednego lub więcej Secondary VLANów. Istotny jest fakt, że dla świata zewnętrznego wszystkie urządzenia są widoczne nadal jako przynależące do pojedynczego VLANu (Primary VLANu). Separacja ma natomiast miejsce już lokalnie w LANie, gdzie wszystkie urządzenia nadal zachowują adresację we wspólnej podsieci, a pomimo to są w stanie znajdować się w osobnych, odseparowanych Secondary VLANach. Mamy więc następującą sytuację:
Na obrazku powyżej widzimy trzy Secondary VLANy, oznaczone na czerwono numerami 1-3. Są one zebrane w jeden Primary VLAN oznaczony na niebiesko numerem 4.
Community i Isolated VLANy
Wyróżniamy dwa typy Secondary VLANów:
- Community VLAN – urządzenia podłączone do portów znajdujących się w Community VLANie mogą się ze sobą komunikować, nie mają natomiast możliwości komunikacji z urządzeniami w innych VLANach. Porty przełącznika przypisane do Community VLANu nazywamy community portami i są to porty nietagowane.
- Isolated VLAN – urządzenia podłączone do portów znajdujących się w Isolated VLANie nie mogą się komunikować ani ze sobą ani z jakimkolwiek urządzeniem w innym VLANie. Z uwagi na takie działanie, nie ma sensu tworzyć więcej niż jednego Isolated VLAN. Porty przełącznika przypisane do Isolated VLANu nazywamy isolated portami i są to porty nietagowane.
Co do zasady pojedynczy Primary VLAN może być związany z zero lub więcej Community VLANów i z co najwyżej jednym Isolated VLANem. Z kolei każdy Secondary VLAN musi być związany dokładnie z jednym Primary VLANem. Będąc wyposażonymi w tę wiedzę, przypiszmy utworzone wcześniej grupy hostów do poszczególnych typów Secondary VLANów:
Promiscuous port
Z dotychczasowego opisu prywatnych VLANów wynika, że urządzenia w Secondary VLANach nie mają żadnej możliwości komunikacji z zewnętrznym światem. Jak zatem sprawić by mogłe ony korzystać przykładowo ze wspólnego serwera e-mail czy też drukarki sieciowej? Tutaj z pomocą przychodzi nam trzeci rodzaj portu, tzw. promiscuous port. Ten port jest portem nietagowanym przypisanym do Primary VLANu. Co do zasady urządzenie podłączone do promiscuous portu może się komunikować ze wszystkimi urządzeniami w Secondary VLANach związanych z tym Primary VLANem (i vice versa). Promiscuous porty przypisane do tego samego Primary VLANu mogą też oczywiście komunikować się między sobą.
W naszym przykładzie router RTR pełniący funkcję bramy domyślnej powinien być zatem podłączony do promiscuous portu. Spójrzmy po raz kolejny na naszą topologię, tym razem skupiając się na typach portów:
Na powyższej topologii możemy wyróżnić cztery typy portów na przełącznikach:
- Porty 1,2,3,4 – community porty przypisane do Secondary Community VLANów
- Porty 5,6 – isolated porty przypisane do Secondary Isolated VLANu
- Port 7 – promiscuous port przypisany do Primary VLANu
- Porty 8,9 – porty typu trunk, tagowane za pomocą dot1q
Zasady komunikacji między poszczególnymi typami portów
Podsumujmy zasady komunikacji pomiędzy poszczególnymi portami/VLANami:
- Port przypisany do danego Community VLANu (community port) może komunikować się ze wszystkimi innymi portami w tym samym Community VLANie i ze wszystkimi promiscuous portami w powiązanym Primary VLANie.
- Port przypisany do danego Isolated VLANu (isolated port) może komunikować się ze wszystkimi promiscuous portami w powiązanym Primary VLANie.
- Port przypisany do Primary VLANu (promiscuous port) może komunikować się ze wszystkimi innymi portami w tym samym Primary VLANie oraz ze wszystkimi portami we wszystkich Secondary VLANach związanych z tym konkretnym Primary VLANem.
Prywatne VLANy na wielu przełącznikach
Rozszerzanie zasięgu działania prywatnych VLANów poprzez konfigurację ich na kolejnych przełącznikach jest bardzo proste. Jedyne o co trzeba zadbać to żeby mapowania Primary i Secondary VLANów były spójne oraz żeby poszczególne identyfikatory VLANów były puszczone na trunku między przełącznikami. Z zagadnień czysto teoretycznych na koniec warto wspomnieć o tym jak ruch w prywatnych VLANach jest tagowany właśnie na trunkach:
- Jeśli ramka została otrzymana przez przełącznik na community lub isolated porcie to puszczając tę ramkę trunkiem przełącznik otaguje ją identyfikatorem źródłowego Secondary VLANu.
- Jeśli ramka została otrzymana przez przełącznik na promiscuous porcie to puszczając tę ramkę trunkiem przełącznik otaguje ją identyfikatorem odpowiedniego Primary VLANu.
Biorąc pod uwagę powyższe dwie zasady możemy to rozumować następująco – ruch wychodzący (upstream) z danego Secondary VLANu jest zawsze tagowany identyfikatorem tego Secondary VLANu. Natomiast ruch przychodzący (downstream) do danego Secondary VLANu jest tagowany identyfikatorem odpowiadającego Primary VLANu.
Konfiguracja
Znając już teoretyczne podstawy działania prywatnych VLANów, przejdźmy do konfiguracji. Przykład oparty jest na przełącznikach Cisco serii 3800. Bazować będziemy na zaprezentowanej wcześniej, poniższej topologii:
Pierwszym krokiem w konfiguracji jest przełączenie VTP w tryb transparent – jest to wymagane do działania prywatnych VLANów jeśli nie używamy VTPv3. Następnie tworzymy poszczególne VLANy, nadajemy im nazwy i wskazujemy ich typy. Zwróć proszę uwagę, że w konfiguracji Primary VLANu konfigurujemy dodatkowo powiązania z Secondary VLANami. Dla bycia zwięzłym przedstawiona jest konfiguracja jedynie przełącznika SW1:
SW1(config)# vtp mode transparent
Setting device to VTP Transparent mode for VLANS.
SW1(config)#
SW1(config)# vlan 101
SW1(config-vlan)# name Community1
SW1(config-vlan)# private-vlan community
SW1(config-vlan)# vlan 102
SW1(config-vlan)# name Community2
SW1(config-vlan)# private-vlan community
SW1(config-vlan)# vlan 103
SW1(config-vlan)# name Isolated
SW1(config-vlan)# private-vlan isolated
SW1(config-vlan)# vlan 100
SW1(config-vlan)# name Primary1
SW1(config-vlan)# private-vlan primary
SW1(config-vlan)# private-vlan association 101-103
SW1(config-vlan)# exit
Mając stworzone prywatne VLANy, przejdźmy do przypisywania do nich portów. Przedstawione zostaną 3 przykłady jako, że konfiguracja jest analogiczna na wszystkich portach i zależy jedynie od typu portu. W każdym przypadku konfigurujemy najpierw typ portu (host/promiscuous), a następnie przypisujemy właściwe VLANy.
Przykład konfiguracji community portu gi0/1 na przełączniku SW1:
SW1(config)# interface gi0/1
!wskazanie, ze port jest podlaczony do hosta
SW1(config-if)# switchport mode private-vlan host
!przypisanie portu do Primary VLANu 100 oraz Secondary Community VLANu 101
SW1(config-if)# switchport private-vlan host-association 100 101
Przykład konfiguracji isolated portu gi0/2 na przełączniku SW2:
SW2(config)# interface gi0/2
!wskazanie, ze port jest podlaczony do hosta
SW2(config-if)# switchport mode private-vlan host
!przypisanie portu do Primary VLANu 100 oraz Secondary Isolated VLANu 103
SW2(config-if)# switchport private-vlan host-association 100 103
Przykład konfiguracji promiscuous portu gi0/10 na przełączniku SW1:
SW1(config)# interface gi0/10
!wskazanie, ze port jest typu promiscuous
SW1(config-if)# switchport mode private-vlan promiscuous
!przypisanie portu do Primary VLANu 100 i zmapowanie go z Secondary VLANami 101-103
SW1(config-if)# switchport private-vlan mapping 100 101-103
Jeśli routing w sieci realizujesz na przełącznikach warstwy trzeciej (a co za tym idzie bramą domyślną jest interfejs SVI) to pamiętaj żeby skonfigurować go jako promiscuous w następujący sposób:
SW1(config)# interface Vlan100
SW1(config-if)# private-vlan mapping 100 101-103
SW1(config-if)# ip address 192.168.1.254 255.255.255.0
Weryfikacja
Weryfikacja poprawności konfiguracji prywatnych VLANów jest bardzo prosta i wystarczy do niej jedna komenda: show vlan private-vlan. Listuje ona wszystkie skonfigurowane prywatne VLANy, mapowania Primary i Secondary VLANów oraz przypisane porty:
SW1# show vlan private-vlan
Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
100 101 community Gi0/1, Gi0/2
100 102 community Gi0/3
SW2# show vlan private-vlan
Primary Secondary Type Ports
------- --------- ----------------- ------------------------------------------
100 102 community Gi0/1
100 103 isolated Gi0/2, Gi0/3
Co do samego działania prywatnych VLANów, można łatwo zweryfikować za pomocą pinga czy działa to jak należy. Dla oszczędności miejsca zastąpię listingi rezultatów pingowania prostym obrazkiem, na którym zaznaczone są wszystkie możliwe przepływy danych:
Na powyższej topologii ładnie widać różnicę między Community i Isolated VLANem.
bardzo dobry opis – dzięki
Bardzo dobrze i jasno wyjaśnione – na egzamin jak znalazł!
Private VLAN to koncepcja znana od przeszło dwóch dekad, powoli możemy zacząć nazwać tą technologię \”legacy\”. Obecnie do uzyskania segmentacji sieci niezależnie o adresacji IP coraz częściej używa się sieci overlay realizowanej za pomocą protokołu VXLAN. Początkowo technologia ta była zarezerwowana dla dostawców internetu (ISP) i przy budowaniu datacenter ale coraz mocniej wchodzi w obszar Campus LAN. Świadczy o tym chociażby wsparcie dla tej technologii w najnowszych przełącznikach Cisco Catalyst 3650 i 3850 dedykowanych właśnie do sieci korporacyjnych. Powstają również Design Guide dla budowy takich rozwiązań:
http://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Oct2016/CVD-CampusFabricDesign-2016OCT.pdf
Przewaga VXLANów nad Private LAN jest wiele, jednym z nich jest możliwość tworzenia do 16 milionów segmentów sieci (domen rozgłoszeniowych) całkowicie niezależnie od adresacji IP i fizycznej lokalizacji urządzeń końcowych.
Moim zdaniem to zagadnienie, z powodu jego popularności, z pewnością pojawi się w kolejnej wersji egzaminu CCNP/CCIE w ścieżce R&S.
Co raz bardziej mi się podoba ta stronka 🙂
I o to chodzi Marek! 😀 Dzięki!
Dziękuję za jasny i zrozumiały opis tematu!
Proszę bardzo Michał 🙂
Czyli Promiscuous Port, nie może być trunkiem ? Co jesli chciałbym zastosować router-on-stick, na tym samym łaczu co Promiscuous Port ?
A po za tym bardzo dobry i rzeczowy artykuł.
Dzięki za rozjaśnienie. Czegoś takiego szukałem. 🙂
Co zrobić, gdy router nie obsługuje trybu Promiscous na porcie, a połączenie jest typu Trunk?
Jak obsłużyć też konfigurację, gdy takim łączem między routerem, a switchem przepycham więcej zwykłych vlanów?
Pozdrawiam.
Nie ma edycji, więc odpiszę sobie. Otóż Cisco w artykule \”Configuring Isolated Private VLANs on Catalyst Switches\” wyjaśnia, że Private Vlany należy ciągnąć trunkami między innymi przełącznikami.
W dokumencie \” Cisco Systems\’ Private VLANs: Scalable Security in a Multi-Client Environment\” czyli RFC5517
Tabela1 przedstawia matrycę połączeń między portami pracującymi w różnych trybach oraz zapewnienie, że porty pracujący w różnych trybach mogą był członkami Trunków \”Please note that isolated, community, and promiscuous ports can either be access ports or hybrid/trunk ports (according to the terminology presented in Annex D of the IEEE 802.1Q specification, up to its 2004 revision).\”
Wapaniały artykuł. Doskonała strona. Dziękuję.
Cała przyjemność po naszej stronie Przemek 🙂
Super opis.
Ale mam pytanie. Czy do obsługi PVLAN muszę mieć przełączniki L3, czy mogą też to być przełączniki L2 (lub mieszana konfiguracja)? Wyczytałem gdzieś, że tylko należy stosować L3. Nie miałem okazji zrobić labu z tej technologii. Na co dzień korzystam ze sprzętu Aruba, ale konfiguracja z tego co widziałem jest bardzo zbliżona.
@Krzysiek, wynika raczej, że jeżeli funkcja zostanie zaimplementowana przez producenta na przełączniku L2 to raczej będzie działać. Nie będzie wdrażał takiej funkcji, tylko dla specyfikacji.