Tagowanie dot1Q w praktyce

Cześć! Dzisiaj przyjrzymy się bliżej tagowaniu dot1Q. W tym materiale przedstawiam sześć dość specyficznych scenariuszy, których przerobienie dobrze sprawdza Twoją wiedzę na temat działania portów typu access, trunków oraz procesu tagowania. Zapraszam!

Nie będę skupiał się na tym, aby przekazać Ci czym są VLAN’y, ani nie będę wprowadzał Cię w pojęcia access lub trunk, zakładam, że masz już tą wiedzę, którą po przeczytaniu tego artykułu tylko sobie zweryfikujesz lub rozszerzysz.

Scenariusze które zobaczysz raczej nie są takimi jakie spotkasz na codzień w pracy w środowisku sieciowym, lecz wydają się bardzo dobre na sprawdzenie wiedzy choćby na rozmowie rekrutacyjnej. Skupimy się bardziej na podejściu praktycznym z wyjaśnieniami, niż na czystej teorii.

Wstęp i założenia

Spójrzmy na problemy z jakimi zmierzymy się w tym materiale:

Sześć topologii testowych które zostaną omówione w tym materiale.

Powyższe topologie są bardzo proste, lecz mają dość specyficzne konfiguracje, będziemy się starać odpowiedzieć sobie na pytanie, czy host H1 (po lewej stronie) jest w stanie komunikować się z hostem H2 (po prawej stronie)?

Pakiety przechwycane były na wszystkich portach każdego przełącznika Wireshark’iem, co dawało w wyniku 4 pliki .pcap które zostały przechwycone na każdy scenariusz.

Budowa każdej topologii w szczegółach: z opisami nazw hostów, adresacją IP, i numerami portów.

Adresacja, którą będę się posługiwać do adresowania hostów będzie pochodzić z sieci 10.0.0.0/24. Tablica ARP hostów będzie wypełniona, będziemy zatem obserwować komunikację między tymi hostami bezpośrednio na pakietach ICMP, bez generowania pakietów ARP.

Środowisko, na którym będę testował wszystkie przypadki to VIRL (Cisco Virtual Internet Routing Lab), za symulowanie hostów zaś odpowiadają routery z podstawową konfiguracją adresów IP.

Tablice CAM (Content Addressable Memory) w przełącznikach są czyszczone przed każdym z testów. Switche wypełniają tablicę CAM źródłowymi adresami MAC znalezionymi w ramkach.

Scenariusz 1

W tym scenariuszu wszystkie porty przełącznika mamy ustawione jako porty typu access, ale jak widać poniżej przypisane im VLAN’y nie są zgodne.

Topologia ze scenariusza pierwszego.

Skonfigurujmy przełączniki zgodnie z topologią, będzie to bardzo prosta konfiguracja, i zakładam, że komendy te są dla ciebie oczywiste, lecz dla szybkiego przypomnienia:

SW1(config)# vlan 10
SW1(config-vlan)# exit
SW1(config)# vlan 20
SW1(config-vlan)# exit
SW1(config)# int gi 0/1
SW1(config-if)# sw mode access
SW1(config-if)# switchport access vlan 20
SW1(config)# int gi 0/2
SW1(config-if)# sw mode access
SW1(config-if)# switchport access vlan 20
SW2(config)# vlan 10
SW2(config-vlan)# exit
SW2(config)# vlan 20
SW2(config-vlan)# exit
SW2(config)# int gi 0/1
SW2(config-if)# sw mode access
SW2(config-if)# switchport access vlan 10
SW2(config)# int gi 0/2
SW2(config-if)# sw mode access
SW2(config-if)# switchport access vlan 10

Sprawdźmy zatem teraz, czy możemy spingować hosta drugiego:

Komenda ping z H1 do H2.

Rezultat jest jak najbardziej pozytywny.

Przeanalizujmy tę sytuację, i dowiedzmy się, czemu tak jest:

Scenariusz 1 z opisami.
  • H1 – ramka wychodząca z hosta pierwszego nie jest tagowana.
  • SW1 – na porcie access Gi0/1 przychodzi ramka będąca w VLAN’ie 20. Przełącznik nie znając lokalizacji hosta docelowego, rozsyła tę ramkę na wszystkich portach znajdujących się w VLAN’ie 20, oraz trunkami w których VLAN ten jest VLAN’em dozwolonym. Ramka opuści SW1 i będzie nieotagowana.
  • SW2 – ramka przychodząc bez tagu na port 2 przełącznika znajdującego się w VLAN’ie 10, przełącznik słusznie uznaje tę ramkę jako przynależną do VLAN’u 10, i rozgłasza ją dalej zgodnie ze wspomnianą wcześniej logiką.
  • H2 – W ten oto sposób ramka trafia do hosta drugiego.

Komunikacja odwrotna przebiega analogicznie.

Przeanalizujmy teraz packet capture, i jak wyglądają te ramki w Wireshark’u:

Przechwyt ramek z Wireshark’a.

Dobrze jest wyfiltrować sobie tylko pakiety ICMP. Można to zrobić wpisując icmp w filtrze wyszukiwania. Widzimy ramkę wychodzącą portem Gi0/2 na SW1. W tym scenariuszu oczywiście nie znajdujemy żadnych tagów.

Scenariusz 2

Przejdźmy teraz do drugiego przypadku. W tym scenariuszu między przełącznikami mamy już zestawionego trunk’a, przy czym mamy native vlan mismatch. Po lewej stronie ustawiony jako VLAN20, po prawej natomiast jako VLAN10.

Topologia ze scenariusza drugiego.

Przejdźmy szybko przez konfigurację, ustawienia portów access są takie same jak w poprzednim przypadku, dodamy jeszcze tylko konfigurację trunka i native vlanów:

SW1(config)# int gi 0/2
SW1(config-if)# switchport trunk encapsulation dot1q
SW1(config-if)# switchport mode trunk
SW1(config-if)# switchport trunk native vlan 20
SW2(config)# int gi 0/2
SW2(config-if)# switchport trunk encapsulation dot1q
SW2(config-if)# switchport mode trunk
SW2(config-if)# switchport trunk native vlan 10

Sprawdzamy pingowanie:

Komenda ping z H1 do H2.

Tym razem też mamy sukces. Komunikacja działa.

Weźmy teraz tę komunikację pod lupę:

Scenariusz 2 z opisami.
  • H1 – ramka wychodząca z hosta pierwszego nie jest tagowana.
  • SW1 – przełącznik odbierając ją na porcie 1 klasyfikuje ją jako przynależną do VLAN’u 20. Ramka ta naastępnie zostanie przesłana trunkiem. Jako, że na 2 porcie mamy ustawiony VLAN natywny jako 20, to ramka ta nie zostanie otagowana.
  • SW2 – do drugiego przełącznika zatem trafia nieotagowana ramka, którą to ten przełącznik zaklasyfikuje jako przynależną do VLAN’u 10. Powodem oczywiście jest ustawiony z tej strony VLAN natywny. Dalej już ramka zostanie przekazana portem accessowym do hosta 2.
  • H2 – W ten oto sposób ramka trafia do hosta drugiego.

Komunikacja zwrotna zachodzi w analogiczny sposób, dlatego ją pominiemy.

W packet capture z tego scenariusza również nie znajdziesz żadnych tagów.

Scenariusz 3

Przejdźmy do trzeciego przypadku. Jest on bardzo podobny do poprzedniego, jedyna różnica jest taka, że zostały zamienione miejscami vlany natywne na trunk’u.

Topologia ze scenariusza trzeciego.

Konfiguracja jest podobna jak w poprzednim przypadku, więc tym razem nie będę jej już prezentował.

Pingujemy:

Komenda ping z H1 do H2.

Ping nie dochodzi.

Coś zaczyna się dziać, przeanalizujmy zatem ruch ramki:

Scenariusz 3 z opisami.
  • H1 – ramka wychodząca z hosta pierwszego nie jest tagowana.
  • SW1 – przełącznik odbierając ramkę na porcie 1 klasyfikuje ją jako przynależną do VLAN’u 20. Ramka ta następnie zostanie przesłana dalej trunkiem. Jako, że na drugim porcie mamy ustawiony vlan natywny jako 10, ramka ta zostanie otagowana tagiem 20. Potwierdza to packet capture z Wireshark’a. Widzimy otagowaną ramkę wychodzącą portem 2 na SW1:
Przechwyt ramek z Wireshark’a.
  • SW2 – drugi przełącznik otrzymuje ramkę otagowaną jako VLAN 20, na porcie na którym mamy skonfigurowany VLAN natywny także jako 20. Przełącznik zdejmuje tag, i rozsyła ramkę dalej wszystkimi portami przynależnymi do VLAN’u 20. Ponieważ port w stronę hosta 2 należy do VLAN’u 10, to ramka nie opuszcza tego przełącznika.
  • H2 – Widzimy zatem, że host 1 nie ma możliwości skomunikowania się z hostem 2.

Sytuacją w drugą stroną jest analogiczna, zatem ją pomijamy.

Scenariusz 4

Przejdźmy teraz do przypadku czwartego. W tym scenariuszu sytuacja jest trochę bardziej skomplikowana, ponieważ tym razem host drugi podłączony jest do portu ustawionego jako trunk, z natywnym VLAN’em 10.

Topologia ze scenariusza czwartego.

Konfigurujemy urządzenia zgodnie z topologią.

Przechodzimy do pingowania:

Komenda ping z H1 do H2.

W tym przypadku również widzimy, że ping nie działa.

Spójrzmy na przebieg komunikacji:

Scenariusz 4 z opisami. Komunikacja od H1 do H2.
  • H1 – ramka wychodząca z hosta pierwszego nie jest tagowana.
  • SW1 – pierwszy przełącznik odbierając ramkę na porcie pierwszym klasyfikuje ją jako przynależną do VLAN’u 10. Ramka ta następnie zostaje przesłana dalej trunkiem. Jako, że na drugim porcie mamy ustawiony VLAN natywny jako 10, ramka ta nie zostanie otagowana.
  • SW2 – drugi przełącznik otrzymuje nieotagowaną ramkę na porcie na którym mamy skonfigurowany VLAN natywny jako 20. Przełącznik SW2 zatem zaklasyfikuje tę ramkę jako przynależną do VLAN’u 20. Dalej switch 2 puści tę ramkę trunkiem w stronę hosta 2. Ponieważ ramka przynależy do VLAN’u 20, a VLAN natywny jest tu ustawiony jako 10, to zostanie ona otagowana.
  • H2 – W rezultacie host 2 odrzuci tę ramkę, gdyż nie obsługuje on tagowania. H1 nie ma zatem możliwości skomunikowania się z H2.

Co ciekawe komunikacja zwrotna zadziała.

Prześledźmy ją:

Scenariusz 4 z opisami. Komunikacja zwrotna od H2 do H1.
  • H2 – host drugi wysyła nieotagowaną ramkę.
  • SW2 – ramka ta wchodzi na porcie 1 przełącznika SW2 i zostaje zakwalifikowana jako przynależna do VLAN’u 10, z uwagi na ustawienia VLAN’u natywnego. Dalej ramka ta zostaje puszczona trunkiem w stronę SW1 i zostaje otagowana tagiem 10, ponieważ VLAN natywny na tym porcie jest ustawiony jako 20.
  • SW1 – pierwszy przełącznik otrzymuje ramkę otagowaną jako VLAN 10 na porcie na którym mamy skonfigurowany VLAN natywny także jako 10. Przełącznik zdejmuje tag i rozsyła ramkę dalej wszystkimi portami przynależnemi do VLAN’u 10.
  • H1 – Nieotagowana ramka wychodzi portem accesowym w stronę hosta 1 i z powodzeniem do niego trafia.

Scenariusz 5

Spójrzmy teraz na kolejny scenariusz. Różni się on od poprzedniego tym, że w tym przypadku VLAN’y natywne na trunku między przełącznikami są zgodne i są ustawione jako VLAN 20.

Topologia ze scenariusza piątego.

Konfigurujemy urządzenia.

Testujemy:

Komenda ping z H1 do H2.

Test kończy się powodzeniem.

Spójrzmy na ruch ramki w tej topologii:

Scenariusz 5 z opisami.
  • H1 – ramka wychodząca z hosta pierwszego nie jest tagowana.
  • SW1 – pierwszy przełącznik odbierając ramkę na porcie 1 klasyfikuje ją jako przynależną do VLAN’u 10, ramka ta następnie zostanie przesłana trunkiem. Jako, że na drugim porcie mamy ustawiony VLAN natywny jako 20, ramka ta zostanie otagowana tagiem 10.
  • SW2 – do drugiego przełącznika zatem trafia otagowana ramka. Tag zostaje zdjęty i dalej ramka zostanie przekazana trunkiem do hosta 2. Tylko, że ramka przynależy do VLAN’u 10, a VLAN 10 jest na tym trunku ustawiony jako natywny.
  • H2 – ramka ta nie zostanie otagowana, i z powodzeniem zostanie odebrana przez hosta drugiego.

Ruch zwrotny również dociera.

Scenariusz 6

Przejdźmy do ostatniego w tym artykule problemu. Szósty scenariusz jest stosunkowo prosty, mamy 3 porty w trybie access z ustawionym VLAN’em 10, oraz jeden trunk z ustawionym vlanem natywnym również jako 10.

Topologia ze scenariusza szóstego.

Zanim przeanalizujemy tę sytuację, skonfigurujmy szybko urządzenia.

Sprawdźmy czy się pinguje:

Komenda ping z H1 do H2.

Mamy sukces, komunikacja dociera.

Analiza:

  • H1 – ramka wychodząca z hosta pierwszego oczywiście nie jest tagowana.
  • SW1 – na pierwszym przełączniku przychodzi ona na porcie access’owym będącym w VLAN’ie 10. Przełącznik rozsyła tę ramkę wszystkimi ramkami w VLAN’ie 10. Ramka opuści zatem SW1 i będzie nieotagowana.
  • SW2 – przechodząc bez tag’a na port drugiego przełącznika znajdujący się w VLAN’ie 10, przełącznik słusznie uznaje tę ramkę jako przynależną do VLAN’u 10 i przesyła ją dalej trunkiem w stronę hosta 2.
  • H2 – Jako, że VLAN natywny jest ustawiony jako VLAN 10, ta ramka nie zostaje otagowana, i z powodzeniem dociera do hosta 2.

Komunikacja zwrotna zadziała analogicznie czego dowodem jest na hoście H1 ping reply. W Wireshark’u nie uświadczymy żadnych tagów.

Artykuł ten możesz również obejrzeć w formie filmiku na YouTube:

Link do pobrania plików .pcap: niestety jest już niedostępny.

P.S. Podziękowania dla Macieja Żurawskiego, autora prezentowanych w tym artykule topologii!

Komentarze: 7
Otrzymuj powiadomienia z tej dyskusji
Powiadom mnie o
guest

7 - Ilość komentarzy
Sortuj wg najlepszych
Sortuj wg najnowszych Sortuj wg najstarszych
Inline Feedbacks
View all comments
ogi
ogi
4 lat temu

czas 9:34 – czy na pewno zostanie zdjęty tag10 ?
Pozdrawiam
~ogi~

ogi
ogi
4 lat temu

Ok, dziękuję za wyjaśnienie
Pozdrawiam
~ogi~

Marek
Marek
3 lat temu

Na wstępie zaznaczę, że rewelacyjne podejście do tematu. Bardzo podobają mi się poruszane tematy. Mam jednak pewne braki dlatego byłbym wdzięczny za wyjaśnienie paru kwestii.
1. W okolicach 1:15 było wspomniane, że tablice ARP hostów są zapełnione ale tablice CAM puste. Z tego wynika jak jest wspomniane, że Switche nie znają lokalizacji docelowych (znają ją natomiast host tak?). W okolicach 2:35 jest wspomniane, że switch wysyła ramkę na wszystkie porty w Vlanie 20 i trunk. Jak się domyślam jest to rozgłoszenie. Skoro było wspomniane, że nie ma tutaj rozgłoszeń ARP to w takim razie jakie rozgłoszenie wysyła Switch aby zapełnić swoją tablicę CAM? Skoro nie ARP to jakie? A może switch zapełania tablice CAM na podstawie protokołu STP gdyż mamy tam stan Learning
2. Skoro przełączniki nie tagują ramek bo mają np. Native VLAN lub po prostu dany port należy do danego VLANU ale jest w trybie access to na jakiej podstawie switche to klasyfikują do odpowiednich VLANOw. Chodzi o to, że jak dany port poprzez switch port acces vlan zaklasyfikujemy do konkretnych vlanow to switch na podstawie tego wie?

Bylbym bardzo wdzieczny z odpowiedz

Marek
Marek
2 lat temu
Odpowiedź do  Damian Michalak

Dzięki Damian, odpaliłem sobie to na GNS3 i w końcu zrozumiałem. Nie wpadłem na to, że transmisja UNICAST może być wysyłana wszystkimi portami oprócz tego, z którego przyszła. Myślałem, że to się tyczy tylko broadcast. W każdym razie pobawiłem się również w Wiresharku i praktycznie wszystkie protokoły odsiałem i dowiedziałem się, że co tylko przyjdzie na port switcha to on się od razu tego uczy. Z reguły były to usługi typu SSDP, MDNS, itd. Switch wysyła ARP Broadcast kiedy mu damy vlan do zarządzania i sobie pingniemy inny. Chociaż dziwi mnie fakt, że nie bierze też do tablicy ARP komputerów.

Dominik
Dominik
3 lat temu

Kolega Marek zadal bardzo dobre pytanie, podbijam