Na Styku SieciNa Styku Sieci
Aa
  • Start
  • Routing & Switching
  • Wireless
  • Certyfikacja
  • Wokół sieci
Czytasz: Tagowanie dot1Q w praktyce
Udostępnij
Na Styku SieciNa Styku Sieci
Aa
Szukaj
  • Start
  • Kategorie
    • Routing & Switching
    • Wireless
    • Certyfikacja
    • Wokół sieci
  • Linki
    • Tagi
    • Kontakt
Routing & Switching

Tagowanie dot1Q w praktyce

Damian Michalak
Damian Michalak 26 maja 2017 Komentarze: 7

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!

W artykule:
Wstęp i założeniaScenariusz 1Scenariusz 2Scenariusz 3Scenariusz 4Scenariusz 5Scenariusz 6

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.

Powiązane publikacje

Czym jest APIPA?
Jak działa komunikacja DNS?
Ataki i ochrona w warstwie drugiej – ARP
DHCP dla IPv4 – czym jest i jak działa?
Czym jest domena rozgłoszeniowa i kolizyjna?

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!

TAGI: access port, dot1Q, native vlan mismatch, tagowanie, trunk port, VLAN, Wireshark
Damian Michalak 26 maja 2017
Udostępnij ten materiał
Facebook Twitter Whatsapp Whatsapp LinkedIn
Poprzedni artykuł Prywatne VLANy (PVLAN) od A do Z
Następny artykuł Format ramki Ethernet – krótka historia w trzech odsłonach
Komentarze: 7
Zaloguj się
guest

guest

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

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

0
0
Odpowiedz
Damian
Autor
Damian
3 lat temu

Tak Ogi – przełącznik po otrzymaniu ramki na danym porcie zdejmuje z niej tag i przekazuje tą ramkę dalej do procesowania w VLANie do którego ona przynależy. Pozdrawiam 🙂

0
0
Odpowiedz
ogi
ogi
3 lat temu

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

0
0
Odpowiedz
Marek
Marek
2 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

0
0
Odpowiedz
Damian Michalak
Autor
Damian Michalak
1 rok temu
Odpowiedź do  Marek

Cześć Marek, oto odpowiedzi:

  1. Zgadza się – tablice ARP hostów są zapełnione, natomiast tablice CAM na przełącznikach są czyszczone przed każdym testem. W scenariuszu 1, host 1 próbując pingować host 2, zna docelowy adres MAC (bo tablica ARP jest wypełniona). Wysyła zatem ramkę do SW1. SW1 otrzymując ramkę, nie zna lokalizacji hosta 2 (bo ma wyczyszczoną tablicę CAM). Jest to więc unknown unicast – SW1 wysyła tą ramkę wszystkimi portami, poza tym, na którym ją otrzymał. Czyli ramka zostaje przesłana dalej portem Gi0/2. Przy okazji SW1 zapisał w tablicy CAM lokalizację hosta 1 (switche wypełniają tablicę CAM źródłowymi adresami MAC znalezionymi w ramkach). Dlatego też SW1 nauczy się adresu MAC hosta 2, gdy ten wyśle ICMP reply z powrotem do hosta 1.
  2. Dokładnie tak – przypisanie VLANu do portu typu access jest zaklasyfikowaniem całego ruchu otrzymywanego na takim porcie, do wskazanego VLANu. Jeżeli mamy switchport access vlan 20, to ruch orzymywany na takim porcie traktujemy jako ruch w VLANie 20. Natomiast w przypadku trunków ruch zostanie zaklasyfikowany do VLANu wynikającego z taga dot1Q. Jeżeli ruch jest nieotagowany, to switch potraktuje go jako przynależący do VLANu natywnego.
0
0
Odpowiedz
Marek
Marek
9 miesięcy 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.

0
0
Odpowiedz
Dominik
Dominik
1 rok temu

Kolega Marek zadal bardzo dobre pytanie, podbijam

0
0
Odpowiedz

NA STYKU SIECI

Tworzymy społeczność sieciowców skupioną dookoła rozwiązań oraz certyfikacji firmy Cisco Systems.
Przydatne linki
  • Tagi
Nasze projekty
  • Szkoła Sieci

© Na Styku Sieci 2022 - powered by Alvortech

  • Kontakt
Witaj ponownie!

Zaloguj się na swoje konto

Zapomniałeś/aś hasło?