Co w sieci siedzi. Zrozumieć i "pokochać"

1 (Pobrane z slow7.pl) Co w sieci siedzi. Zrozumieć i "pokochać" protokół STP. Aby zrozumieć sens stosowania tego typu rozwiązań prześledźmy prosty przykład przedstawiony na poniższym rysunku. Host1 próbuje skomunikować się ze stacją Host2 lecz niestety komputerowi Host1 nie jest znany adres MAC komputera Host2. W tym celu w kierunku switcha S1 zostaje wysłane rozgłoszenie. Ramka broadcast poprze interfejs f0/4 trafia do przełącznika. Przełącznik ruch ten kopiuje na wszystkie aktywne interfejsy z wyjątkiem tego z którego rozgłoszenie zostało otrzymane. Tak więc ruch brodcastowy zostaje wysłany z interfejsu f0/1 w kierunku switcha S2 oraz z interfejsu f0/3 w kierunku przełącznika S3. Rozgłoszenie zostaje odebrane przez przełącznik S2 i przekazane dalej w kierunku switcha S3, w tym samym czasie ten sam ruch zostaje odebrany przez przełącznik S3 (rozgłoszenie otrzymane od S1) i również skopiowane i przesłane dalej lecz tym razem w kierunku switcha S2. Tak więc przełączniki otrzymują kolejne kopie tej samej ramki, które są przesyłane w

2 (Pobrane z slow7.pl) nieskończoność - powstaje pętla. Jeśli Czytelniku czytałeś moje wcześniejsze wpisy bądź Masz wiedzę na temat warstwy 3 modelu ISO/OSI to pewnie wiesz o istnieniu parametru TTL (ang. Time to Live). Mechanizm ten odpowiada za zmniejszenie wartości pola o 1 za każdym razem gdy pakiet na swej drodze napotka router, tak więc w momencie osiągnięcia przez TTL wartości zero, router nie przekaże pakietu do kolejnego urządzenia sieciowego. W warstwie 2 niestety tego typu zabezpieczeń NIE MA. Jedynym sposobem na przerwanie powstałej burzy rozgłoszeniowej (ang. broadcast storm) jest wyłączenie dowolnego z aktywnych interfejsów. Aby zademonstrować sposób działania i skutki powstania burzy rozgłoszeniowej prześledźmy o to taki przykład w którym to w sieci zbudowanej ze switchy występują nadmiarowe linki a na przełącznikach został wyłączony protokół STP. Przyjęta topologia sieci odpowiada rysunkowi powyżej. Aby wykryć i zdiagnozować burzę wykorzystamy polecenie: show processes cpu history. Po wydaniu polecenia zostanie wyświetlony histogram (a tak naprawdę trzy) przedstawiający użycie procesora. Zakres wyświetlonych danych obejmuje ostatnie 72 godziny. Pierwszy wykres obejmuje wykorzystanie procesora w procentach na sekundę w ciągu ostatnich 60 sekund (CPU percent per second - last 60 seconds), drugi wykorzystanie procesora w procentach na minutę w ciągu ostatnich 60 minut (CPU percent per minute - last 60 minutes), trzeci zaś wykorzystanie procesora w procentach na godzinę w ciągu ostatnich 72 godzin (CPU percent per hour - last 72 hours). Na osi x został przedstawiony czas (0 oznacza moment wydania polecenia), zaś na osi y został umiejscowiony poziom wykorzystania procesora. Jak można zaobserwować poniżej w momencie wydania polecenia użycie procesora było na poziomie 4% by w 20 sekundzie skoczyć do 7% i następnie w 50 sekundzie spaść znów do 4% Gwiazdki poniżej budują wykres.

3 (Pobrane z slow7.pl) Na każdym z przełączników zostało wydane polecenie: no spanning-tree vlan 1 nakazujące

4 (Pobrane z slow7.pl) wyłączenie protokołu STP w domyślnej sieci VLAN1. Wydanie polecenia wyłączającego STP na dwóch pierwszych przełącznikach S1 i S2 jeszcze nie powoduje żadnych konsekwencji gdyż by burza broadcastowa mogła wystąpić musi powstać pętla. Wyłączenie protokołu STP na przełączniku S3 inicjuje burzę - mamy do czynienia z pętlą. Nie trzeba długo czekać (wystarczyło 5 sekund) by zauważyć opóźnienie podczas wprowadzania poleceń systemu IOS. Wydanie polecenia pokazującego wykorzystanie procesora ukazuje nam zużycie CPU na poziomie 99-100% (ostatnia minuta).

5 (Pobrane z slow7.pl) Dodatkowo już po minucie zaistnienia burzy dochodzi kolejny problem związany z niestabilnością tablicy adresów MAC. Trwająca burza rozgłoszeniowa powoduje nieustanne aktualizowanie tablic adresów MAC. Każda z aktualizacji oznacza zmianę drogi wysyłania ramek - pamiętaj, że przełącznik celem określenia interfejsu przez który ma wysłać daną ramkę tak by dotarła do miejsca przeznaczenia analizuje wszystkie otrzymane ramki (przypisanie: interfejs przełącznika - adres MAC). W naszym przykładzie oznacza to, że dla przełącznika S1 dany host jest raz dostępny poprzez interfejs f0/1 a raz f0/3. O zmianach tych, które następują bardzo szybko jesteśmy informowani na bieżąco w postaci komunikatów w linii CLI przełącznika.

6 (Pobrane z slow7.pl) Aby burza mogła zostać przerwana należy wyłączyć jeden z interfejsów tak by przerwać powielanie jednych i tych samych ramek. Oczywiście problem burzy rozwiąże ponowne włączenie protokołu STP. I te rozwiązanie zostało wybrane. Po obserwacji zużycia CPU dochodzimy do wniosku - problem z burzą został rozwiązany. Można by zadać pytanie - Gdzie w tym wszystkim protokół STP i w jaki sposób nie dopuszcza on do powstania pętli? Otóż protokół ten domyślnie jest włączony na każdym porcie switcha i jego głównym zadaniem jest zapobieganie sytuacji opisanej powyżej. Realizacja tego zadania odbywa się poprzez czasowe wyłączenie (blokowanie) połączeń pomiędzy przełącznikami, które potencjalnie mogły by być źródłem powstania pętli. Tak więc dzięki zastosowaniu protokołu STP nasza topologia sieciowa mogłaby przybrać o to taką postać.

7 (Pobrane z slow7.pl) Efektem działania protokołu STP jest zablokowanie łącza pomiędzy switchem S1 a S3. Łącze te jest zablokowane czasowo, co oznacza, że w przypadku wystąpienia problemów z innymi łączami zostanie ono przywrócone by zapewnić ciągłość komunikacji. Zablokowanie ruchu sieciowego pomiędzy przełącznikami uniemożliwia powstanie pętli, której następstwem mogłaby być burza rozgłoszeniowa powodująca problemy z komunikacją. Po tym wprowadzeniu na pewno Czytelniku w głowie masz szereg pytań - Jak działa protokół?, Jakie kryteria decydują o zablokowaniu danego łącza? czy Jak dokonać jego prawidłowej konfiguracji? Zanim przejdziemy z opisem dalej by na tak postawione pytania udzielić odpowiedzi, winien jestem jeszcze parę słów wyjaśnienia. Zacznijmy może tak - na uwadze należy mieć fakt, iż protokół STP od dawna już nie jest obowiązującym standardem (z powodu swoich wad) i że w nowoczesnych sieciach po prostu się go NIE STOSUJE. Co nie znaczy, że na swej drodze administratora się z nim nie spotkasz. Tworzenie artykułu dość obszernego i co tu mówiąc tematycznie nie łatwego nie miało by sensu gdyby opierać się tylko na założeniu, że przypadkiem nasze drogi z tym protokołem się nie skrzyżują. Protokół STP i sposób jego działania po prostu warto poznać gdyż stanowi on bazę do poznania bardziej zaawansowanych rozwiązań - takich jak PVST czy RSTP. W wpisie tym przyjąłem założenie w którym to będę odnosić się do protokołu STP a tak naprawdę przełączniki będą działać pod kontrolą PVST czyli STP z obsługą sieci VLAN.

8 (Pobrane z slow7.pl) Tak więc już wiesz że głównym zadaniem protokołu STP jest wykrycie fizycznych pętli i wyeliminowanie ich poprzez wynegocjowanie wolnej od pętli topologii logicznej. Krótko mówiąc STP wykrywa pętle i blokuje nadmiarowe linki, Zapewnia, że między dwoma dowolnymi urządzeniami jest tylko jedna aktywna ścieżka. Działanie protokołu STP opiera się o algorytm drzewa rozpinającego (ang. Spanning Tree Algorithm), to właśnie on jest odpowiedzialny za wyznaczenie drogi wolnej od pętli. Pierwszym z ważnych zadań algorytmu STA jest określenie puntu odniesienia, tzw. root bridge (korzeń drzewa). Korzeniem drzewa zostaje jeden z przełączników, który w dalszych operacjach wyznaczania drogi jest punktem odniesienia dla kolejnych obliczeń. W kolejnym kroku STA określa wszystkie możliwe ścieżki do korzenia jeśli istnieją drogi alternatywne czyli więcej niż jedna ścieżka, wybierana jest najkorzystniejsza, zaś pozostałe drogi są blokowane. Blokowanie odbywa się poprzez wyłączenie ruchu sieciowego na danym porcie przełącznika. Przy czym co należy dodać blokowanie nie dotyczy ramek BPDU (ang. bridge protocol data unit), których zadaniem jest zapewnienie poprawnego działania protokołu poprzez komunikację z innymi przełącznikami (o ramkach BPDU więcej za chwilę). Najważniejsze pojęcia związane z działaniem protokołu STP to: Bridge ID (identyfikator switcha, identyfikator mostu), Path Cost (koszt ścieżki). Identyfikator BID (Bridge ID) jest 8 bajtową liczbą, w skład identyfikatora wchodzi tzw. priorytet oraz adres MAC. BID jednoznacznie identyfikuje każdy przełącznik i jest jedynym kryterium przy wyborze root-a (korzenia). Informacja o wartości BID jest przekazywana podczas wymiany ramek BPDU. Switch o najmniejszej wartości BID staje się root bridge. Jak już wspomniałem BID składa się z dwóch części: priorytet (2 bajty) na urządzeniach Cisco domyślnie 32768 adresu MAC Priorytet najczęściej podaje się dziesiętnie, a MAC w postaci szesnastkowej.

9 (Pobrane z slow7.pl) W protokole STP punkt odniesienia czyli przełącznik root względem, którego będą przeprowadzane obliczenia wybierany jest dla wszystkich VLAN-ów naraz (jeden korzeń w całej sieci). Po dokonanych usprawnieniach i poprawkach np. PVST, należało zmodyfikować BID, tak aby przenosił informację o numerze VLAN gdyż protokół ten wymaga osobnej instancji STP dla każdej sieci VLAN. Dlatego też z dwóch bajtów pozostawiono 4 bity na priorytet, zaś pozostałe 12 bitów przydzielono na identyfikator VID (VLAN ID). W domyślnej konfiguracji priorytet przełącznika jest ustawiony na wartość 32768 ustawienie to powoduje, że w procesie elekcji rootem zostanie przełącznik o najniższym adresie MAC. Wyboru tego nie powinno się pozostawić przypadkowi bo może się okazać, że funkcję tą będzie pełnił najmniej wydajny przełącznik - należy więc ręcznie zdefiniować priorytet na wybranym switchu, który ma zostać rootem (opis w dalszej części wpisu). Koszt ścieżki jest ściśle powiązany z prędkością łącza, została zastosowana zasada, że im wyższa prędkość, tym niższy koszt. Na tej podstawie przełączniki określają, jak daleko mają do korzenia (roota). W pierwotnej wersji protokołu STP (802.1D) koszt był wyliczany jako: 1000/pasmo ścieżki w Mbps. Jak widać poniżej rozwiązanie te okazało się nie wystarczające gdyż po wprowadzeniu nowych standardów przesyłu danych koszt ścieżki zawsze wynosił 1. Taki sam koszt był przypisany łączu o prędkości 1 Gbps jak i łączu dziesięciokrotnie szybszemu. Aby uwzględnić tę zmianę IEEE

10 (Pobrane z slow7.pl) dokonało poprawki zmieniając skalę na nieliniową, tak by koszt uwzględniał faktyczną prędkość łącza. Prędkość łącza 10 Gbps 1 Gbps 100 Mbps 10 Mbps Koszt ścieżki 2 4 19 100 Koszt ścieżki 1 1 10 100 Możemy ręcznie dokonać modyfikacji kosztu ścieżki poprzez zmianę kosztu portu. Zmianę tą jednak wykonujemy jeśli mamy ku temu dobry powód. Zmiana kosztu ścieżki została opisana w dalszej części wpisu. Aby protokół STP mógł działać i pełnić swoją rolę musi mieć możliwość komunikacji z innymi przełącznikami. Komunikacja ta odbywa się dzięki ramkom BPDU. Switch dla każdego swojego portu zapisuje kopię najlepszej ramki BPDU, którą zobaczył na danym porcie. Przez zobaczyć należy rozumieć ramkę którą przełącznik otrzymał bądź zamierza wysłać. Ramka BPDU obejmuje 12 pól i w jej budowie możemy wyróżnić trzy główne części tj.: Cztery pierwsze pola: Identyfikator protokołu, Wersja, Typ komunikatu oraz Flagi odpowiedzialne są za identyfikację ramki BPDU, Kolejne cztery pola (Identyfikator mostu głównego, Koszt ścieżki, Identyfikator mostu, Identyfikator portu) odpowiedzialne są za przesłanie informacji pozwalających ustalić roota oraz wybranie najlepszych ścieżek, Ostanie cztery pola (Wiek komunikatu, Wiek maksymalny, Czas powitania, Opóźnienie przekazania) są polami timerów (zegarów protokołu STP). Ramka BPDU została schematycznie przedstawiona na rysunku poniżej: I poniżej ramka BPDU, która została przechwycona z wykorzystaniem aplikacji Wireshark

11 (Pobrane z slow7.pl) Ramka BPDU jest enkapsulowana w ramce ethernetowej a następnie wysyłana na adres grupowy MAC: 01:80:C2:00:00:00 Adres ten jest odpowiedzialny za obsługę protokołu STP i informacje przesłane za jego pośrednictwem trafią do wszystkich przełączników w obrębie danej domeny rozgłoszeniowej. Zbieżność protokołu STP jest osiągana w trzech krokach: wybór Root Bridge,

12 (Pobrane z slow7.pl) wybór Root Portów, wybór Portów desygnowanych. Po uruchomieniu wszystkich urządzeń w sieci, wszystkie przełączniki rozgłaszają kompletnie niespójne informacje. Dzieje się tak gdyż każdy z switchy uznaje siebie za root-a. W przykładzie poniżej zastosowałem pewne uproszczenie gdyż przyjęto jeden adres MAC na switch a w rzeczywistości scenariusz powinien być rozpatrywany w odniesieniu do każdego z użytych interfejsów. Uproszczenie zastosowałem by na samym początku uczenia się działania protokołu STP nie zostać przytłoczonym zbyt dużą ilością informacji. W dalszej części wpisu będzie rozważana topologia trochę bardziej złożona. Proces elekcji root-a rozpoczyna się od wysłania ramek BPDU w których każdy z przełączników siebie samego wybiera do pełnienia tej roli. Jak widać po poniższym rysunku i analizie przesłanych danych rootem zostanie przełącznik S1 gdyż ten switch ma przypisany najmniejszy priorytet. A jak już wiesz wartość priorytetu ma większą wagę niż adres MAC. Ale wszystko po kolei. Przełącznik S3 po otrzymaniu ramki BPDU od switcha S2 sprawdza zawarte dane w otrzymanej

13 (Pobrane z slow7.pl) ramce BPDU. W kolejnym kroku następuje porównanie swoich danych z danymi otrzymanymi. Wartości priorytetu (32769) są jednakowe więc kryterium, które będzie rozstrzygać o pierwszeństwie będzie adres MAC. Porównując adresy MAC przełącznik S3 uzna switch S2 jako root gdyż otrzymany adres MAC od S2 ma mniejszą wartość niż własny. Informacje zawarte w ramce BPDU zostają prze przełącznik zapisane (zostaną wykorzystane w kolejnym etapie elekcji). Przełącznik S2 ramkę BPDU wysyła w kierunku S1. Porównanie wartości prowadzi do odrzucenia przez przełącznik S1 otrzymanej ramki gdyż wartość priorytetu w ramce BPDU jest wyższa od tej która jest przypisana switchowi S1. Przełącznik S3 na tym etapie uznaje za roota switcha S2. Dlatego w kolejnych ramkach BPDU rozgłasza dane przełącznika S2. Ramki BPDU zostają wysłane w kierunku przełącznika S2 i S1. Przełącznik S1 po raz kolejny otrzymaną ramkę BPDU odrzuca gdyż wartość priorytetu otrzymanego jest większa od własnego priorytetu. Przełącznik S2 otrzymaną ramkę również odrzuca gdyż otrzymane dane pokrywają się z danymi własnymi. Ramki BPDU zostają wysłane z przełącznika S1 do przełączników S2 i S3. Switch S2 po otrzymaniu informacji od S1 uznaje go za roota gdyż dane priorytetu otrzymanego są niższe od własnych. Switch S3 również uaktualnia swoje informacje i za roota przyjmuje przełącznik S1, tak jak w przypadku switcha S2 decyzja ta zostaje podjęta po analizie otrzymanych informacji a konkretnie wartości otrzymanego priorytetu. Rootem zostaje przełącznik S1. Sprawdźmy zatem jak przedstawia się konfiguracja przełączników. Podstawowym poleceniem, które pozwoli nam na uzyskanie informacji na temat protokołu STP jest komenda: show spannig-tree

14 (Pobrane z slow7.pl) Na pierwszy rzut przejrzyjmy konfigurację przełącznika S1. Po wydaniu polecenia: show spannig-tree uzyskujemy dane na podstawie, których możemy stwierdzić, który przełącznik pełni funkcję roota. Dane przełącznika S1, które posłużyły do zbudowania ramki BPDU wysłanej do innych switchy zawarte są w sekcji Bridge ID (punkt 1). Tak więc znajdziemy w nich wartość ustalonego priorytetu (Priority) oraz adres MAC interfejsu biorącego udział w procesie STP. Gdy podczas przeglądania informacji zawartych po wydaniu polecenia: show spannig-tree odnajdziemy komunikat: This bridge is the root oznacza to, że przełącznik ten w procesie STP jest punktem odniesienia dla wszystkich pozostałych przełączników jest przełącznikiem głównym. (punkt 2). Przyjrzyjmy się kolejnemu przełącznikowi i sprawdźmy konfigurację ustawień STP na switchu S2. Jak widać poniżej w sekcji Root ID znajdują się dane wskazujące na przełącznik S1 jako ten który pełni rolę root-a. W sekcji Bridge ID znajdują się dane przełącznika S2. Porównując te dane ze sobą dochodzimy do wniosku iż switch ten nie może pełnić rolę root-a gdyż jego wartość priorytetu jest wyższa od priorytetu przełącznika S1.

15 (Pobrane z slow7.pl) Uważnego Czytelnika pewnie zainteresuje wartość priorytetu przełącznika ustalona na 32769. Jeszcze chwilę temu wspomniałem, że domyślną wartością dla switchy jest wartość 32768. Więc skąd ta różnica wynosząca aż 1? Dodam, że przełącznik S2 oczywiście korzysta z ustawień domyślnych nic w konfiguracji nie zostało zmienione. Wartość domyślna jest powiększona o 1, ponieważ na przełączniku istnieje domyślna sieć VLAN o przypisanym identyfikatorze 1 (sieć VLAN0001 jest skonfigurowana na każdym z przełączników). Oznacza to, że istnienie sieci VLAN ma wpływ na wartość priorytetu. Gdyby na przełączniku został skonfigurowany dodatkowy VLAN o identyfikatorze 20 wartość priorytetu wzrosłaby o tą wartość. Sposób wyliczenia wartości priorytetu przedstawia poniższy rysunek. Poniżej został jeszcze przedstawiony przykład w którym interfejs przełącznika S2 został przeniesiony do sieci VLAN o identyfikatorze 10. Jak widać zmiana położenia interfejsu względem VLANu zmieniła wartość priorytetu. Wartość ta wynosi 32778 (wartość domyślna 32768 + identyfikator sieci VLAN 10).

16 (Pobrane z slow7.pl) Sprawdzenie konfiguracji STP przełącznika S3 utwierdza nas w przekonaniu iż to switch S1 pełni rolę root-a.

17 (Pobrane z slow7.pl) W naszej testowej sieci zaszczytną rolę root-a pełni przełącznik S1. Można by było zapytać - Co się stanie w przypadku gdy go wyłączymy? i Jak w takiej sytuacji zareaguje protokół STP? Aby odpowiedzieć sobie na tak postawione pytania interfejsy f0/1 oraz f0/3 przełącznika S1 zostały wyłączone - co pokazuje poniższy zrzut. Aby sprawdzić konfigurację STP na przełączniku S2 ponownie wydajemy polecenie: show spanning-tree. Wydanie polecenia informuje nas iż ten switch pełni rolę root-a.

18 (Pobrane z slow7.pl) Wydanie tego samego polecenia na przełączniku S3 potwierdza informacje uzyskane w poprzednim kroku - rola root-a została przypisana switchowi S2. I znów można by było zapytać - Czemu funkcja ta została przypisana przełącznikowi S2? Pewnie część z Was już zna odpowiedź. Analiza danych z obu przełączników (sekcja Bridge ID) przekonuje nas iż wartość priorytetu dla obu przełączników jest jednakowa i wynosi 32769. W takim przypadku gdy nie można rozstrzygnąć elekcji przy wykorzystaniu wartości priorytetu decyduje najmniejsza wartość interfejsu adresu MAC. Porównując wartości adresów:

19 (Pobrane z slow7.pl) przełącznik S2-0817.35e3.b500, przełącznik S3-8cb6.4fd8.fa00. dochodzimy do wniosku iż wartość interfejsu MAC przełącznika S2 jest niższa. Przełącznik ten zaczyna pełnić rolę root bridge. Blokowanie ruchu sieciowego odbywa się poprzez czasowe wyłączenie interfejsu przełącznika, który z punktu widzenia protokołu STP spowodowałby powstanie pętli. Informacje o stanie portów uzyskamy również dzięki poleceniu: show spanning-tree Przyjrzyjmy się jeszcze raz konfiguracji STP na przełączniku S1. Na rysunku znajduje się tabela w której pierwszą kolumną jest Interface W kolumnie tej zostały ukazane wszystkie porty przełącznika biorące udział w procesie STP. Druga kolumna przedstawia rolę jaką pełni dany interfejs. W procesie STP jedną z ról jaką może pełnić interfejs jest rola: portu głównego. Root port (port główny) - port ten zawsze znajduje się najbliżej przełącznika pełniącego rolę root-a. Oznacza to, że przełącznik interfejsów w tym stanie nie będzie posiadał lecz rolę tę będą pełniły porty leżące najbliżej niego czyli interfejsy sąsiadów. W naszym scenariuszu będzie to interfejs f0/1 przełącznika S2 oraz interfejs f0/3 przełącznika S3. Sprawdzenie konfiguracji stanu portów na

przełącznikach S2 oraz S3 potwierdza nasze rozważania. Nasza testowa topologia przyjmie więc postać: 20 (Pobrane z slow7.pl)

21 (Pobrane z slow7.pl) Drugą rolą jaką może pełnić port przełącznika jest rola: portu desygnowanego. Designated port jest portem, którego zadaniem jest przekazanie ruch sieciowego w kierunku innych przełączników. Ponieważ rootem został przełącznik S1 tak więc wszystkie jego porty będą znajdować się w tym stanie. Co należy jeszcze wiedzieć o porcie desygnowanym? - to to że w połączeniach point-to-point port pracujący w tym trybie może być tylko jeden. Oznacza to, że nie zajdzie sytuacja w której po obu stronach połączonych ze sobą przełączników, oba porty będą ustawione do pracy w trybie designated.

Portem desygnowanym został również interfejs f0/3 przełącznika S2. 22 (Pobrane z slow7.pl)

Uzupełnijmy więc nasz diagram sieci o nowe informacje. 23 (Pobrane z slow7.pl)

24 (Pobrane z slow7.pl) Przy porcie f0/1 przełącznika S3 w kolumnie Role widnieje skrót Altn (rysunek powyżej) oznacza to, że port pełni rolę portu alternatywnego (ang. alternate port). Port alternatywny jest to port, który może przekazywać ramki ale w tym momencie jest wyłączony (zablokowany) tak by nie powstała pętla. Nazwa alternate port jest używana w protokołach PVST oraz RSTP zaś w przypadku zwykłego STP port ten przyjmuje nazwę non-designated port.

25 (Pobrane z slow7.pl) Tak więc dodajmy kolejne dane do naszego diagramu sieci a dodatkowo uzupełnijmy go o koszt ścieżek (koszt wszystkich ścieżek wynosi 19, gdyż połączenia pomiędzy przełącznikami wynoszą 100 Mbps standard FastEthernet). Po uzupełnieniu wszystkich danych mogą nasunąć się pewne pytania. Pierwsze z nich to - Czy root portem w przypadku przełącznika S2 mógłby zostać interfejs f0/3? Tu w udzieleniu odpowiedzi pomogą nam koszty ścieżek. Odpowiedź brzmi - NIE. Koszt dotarcia do root-a w przypadku użycia interfejsu f0/1 wynosi 19 natomiast koszt dotarcia do S1 przy użyciu portu f0/3 równa się 38 (19 ścieżka S2-S3 +19 ścieżka S3-S1 ). Drugie pytanie - Dlaczego portem blokowanym (alternate port) jest interfejs f0/1 przełącznika S3 a nie interfejs f0/3 switcha S2. Tu by udzielić poprawnej odpowiedzi należy porównać adresy MAC obu użytych interfejsów. Niższy adres MAC posiada przełącznik S2 dlatego interfejs f0/3 został wybrany jak designated port. Trzecie pytanko - A co w przypadku w którym koszt dotarcia do root-a dla obu interfejsów wyniósłby tyle samo? W takim przypadku brany jest pod uwagę tzw. priorytet portu. Dla przełączników Cisco wartość priorytetu domyślnie została ustalona na wartość 128. Wartość priorytetu może wahać się od 0 do 240 lecz musi spełnić jeden warunek wartość priorytetu musi być wielokrotnością liczby 16. Pierwszeństwo oczywiście mają mniejsze wartości.

26 (Pobrane z slow7.pl) I tu również może dojść do sytuacji w której priorytetu portu będą miały przypisane te same wartości - wybór interfejsu dalej nie będzie rozstrzygnięty. W takim przypadku o wyborze interfejsu decyduje numer portu. Priorytet portu w połączeniu z numerem portu nazywany jest identyfikatorem portu. Poniżej przedstawiono zrzut przedstawiający konfigurację STP przełącznika S2. Po wydaniu polecenia: show spanning-tree uzyskamy informację o koszcie (kolumna Cost) i dodatkowo poznamy identyfikator portu (kolumna Prio.Nbr). Np. interfejs f0/1 posiada przypisany priorytet 128 i numer portu wynosi 1 zaś koszt trasy został ustalony na 19. Aby port przełącznika mógł pełnić powierzoną mu rolę musi przejść przez wszystkie stany procesu STP. Stany te ściśle związane są z zegarami STP (został określony czas po jakim port może zmienić swój stan) a głównym ich zadaniem jest uzyskanie topologii wolnej od pętli. Możliwe stany portu zostały przedstawione i opisane poniżej: Disabled (stan wyłączenia) - port jest wyłączony administracyjnie (shutdown), dlatego też odrzuca odbierane na nim ramki a co za tym idzie przełącznik z wykorzystaniem tego interfejsu nie uczy się adresów MAC ani nie odbiera ramek BPDU (brak uczestnictwa w procesie STP) Blocking (stan blokowania) - port jest zablokowany (niedesygnowany) co oznacza, że nie

27 (Pobrane z slow7.pl) przekazuje ramek zawierających dane oraz odrzuca wszystkie ramki z danymi przekazane z innych interfejsów. Proces uczenia się adresów MAC jest wyłączony lecz interfejs odbiera i przetwarza ramki BPDU co oznacza, że stan interfejsu w zależności od zaistniałych warunków może ulec zmianie Listening (stan nasłuchiwania) - w tym stanie port odrzuca wszystkie ramki z danymi oraz nie uczy się adresów MAC. Port w tym stanie jest potencjalnym kandydatem do osiągnięcia funkcji root port bądź designated port dlatego też interfejs odbiera i przetwarza ramki BPDU a dodatkowo transmituje własne. Port przejdzie w stan blokowania gdy nie zostanie spełniony warunek dotarcia do root-a z wykorzystaniem ścieżki o niższym koszcie. Oznacza to, iż przez interfejs ten musi prowadzić droga do mostu głównego o niższym koszcie niż z interfejsów pozostałych. Learning (uczenie się) - port nie przekazuje żadnych ramek z danymi, następuje przygotowanie do tego procesu dlatego też tablica adresów MAC przełącznika wypełnia się adresami MAC. Ramki BPDU są odbierane, przekazywane i transmitowane. Forwarding (stan przekazywania) - port przełącznika stał się częścią topologii oznacza to że przekazuje i odbiera ramki zawierające dane, ramki BPDU są oczywiście odbierane, przekazywane i transmitowane. Przejdźmy zatem do trochę trudniejszego przykładu. Nasza testowa topologia sieciowa została przedstawiona na rysunku poniżej. Tworzą ją trzy przełącznik, które zostały połączone ze sobą tak, że każdy z każdym jest spięty dwoma niezależnymi interfejsami.

28 (Pobrane z slow7.pl) Adresy MAC portów został sprawdzone na każdym ze switchy (rysunek poniżej) i ich wartości zamieszczono na schemacie powyżej.

29 (Pobrane z slow7.pl) Przełączniki zostały uruchomione. Protokół STP rozpoczyna działanie by wyznaczyć trasę, która będzie wolna od pętli. Poniżej na rysunku przedstawiono efekt działania protokołu STP na każdym z przełączników.

30 (Pobrane z slow7.pl)

31 (Pobrane z slow7.pl)

32 (Pobrane z slow7.pl)

33 (Pobrane z slow7.pl)

34 (Pobrane z slow7.pl) Przeglądając powyższą konfigurację procesu STP możemy dojść do następujących wniosków: 1 - przełącznikiem root został wybrany switch S2, 2 - wszystkie interesy przełącznika S2 pełnią rolę portów desygnowanych, 3 - funkcję root port pełnią interfejsy: f0/1 przełącznika S1 oraz f0/1 przełącznika S3, 4 - portami blokowanymi (alternate port) są interfejsy: f0/2 przełącznika S1 oraz f0/2, f0/3, f0/4 przełącznika S3. Celem lepszego zobrazowania wytyczonej ścieżki wszystkie powyższe informacje zostały zebrane na diagramie sieci poniżej. Odpowiedzmy więc sobie na pytanie - Czemu została wytyczono taką drogę przesyłu pakietów? Rozpoczniemy od analizy adresów MAC biorących udział w procesie STP. Najniższy adres MAC posiada interfejs f0/1 przełącznika S2 (0817.35E3.B501). Wszystkie przełączniki mają domyślnie ustaloną wartość priorytetu (32768) i domyślnie istnieje skonfigurowany

35 (Pobrane z slow7.pl) jeden VLAN o identyfikatorze 1. Tak więc wartość priorytetu wyniesie 32769. Przy pomocy wartości priorytetu nie możemy określić, który z przełączników będzie pełnić funkcję root-a. Gdy priorytet na wszystkich przełącznikach wynosi tyle samo, kryterium rozstrzygającym jest adres MAC. Najniższy adres MAC należy do interfejsu f0/1 przełącznika S2 tak więc ten przełącznik zaczyna pełnić funkcję root bridge. Ponieważ przełącznik S2 został root-em wszystkie jego interfejsy pełnią rolę portów desygnowanych. Portem pełniącym rolę root port na przełączniku S1 został interfejs f0/1 gdyż posiada on najniższy adres MAC priorytet portów ma przypisaną domyślną wartość 128 (wszystkie interfejsy, wszystkich przełączników). Interfejsy f0/3 i f0/4 nie mogą pełnić roli root port gdyż koszt dotarcia do przełącznika S2 z poziomu tych portów wyniósłby 38. Koszt dla interfejsu f0/1 wynosi 19. Interfejsy f0/3 i f0/4 pełnią rolę portów desygnowanych. Rola została im przypisana ponieważ ich adresy MAC mają niższa wartość w porównaniu do adresów MAC sąsiada (przełącznik S3). W przypadku przełącznika S3 jako root port został wybrany interfejs f0/1 gdyż adres MAC tego interfejsu jest najniższy a koszt dotarcia do root bridge wynosi 19. Tak jak w przypadku przełącznika S1 dwa jego interfejsy f0/3 oraz f0/4 nie mogły zostać root portami ponieważ koszt dotarcia do mostu z ich wykorzystaniem wynosi 38. Ponieważ interfejsy te są połączone z interfejsami pełniącymi już rolę portów desygnowanych ich stan został określony jako alternate port. Interfejsy te przez protokół STP zostały wyłączone jako te które by powodowały powstanie pętli. Interfejsy, które przez protokół STP zostały również zablokowane to: interfejs f0/2 przełącznika S1 oraz interfejs f0/2 przełącznika S3. Przełączniki S1 i S3 mają już łączność z rootem tak więc każde kolejne fizyczne połączenie z przełącznikiem głównym zostanie zablokowane by uniemożliwić powstanie pętli. Trasa pomiędzy przełącznikami został ustalona. W tym scenariuszu nie ingerowaliśmy w wybór przełącznika głównego wszystkie ustalenia protokołu STP odbyły się z wykorzystaniem domyślnych wartości. Zadajmy pytanie Jakie czynności należy wykonać aby root-em został przełącznik, który sam wybierzemy?

36 (Pobrane z slow7.pl) Zadanie te możemy wykonać na dwa sposoby: pierwszy sposób: wykorzystanie polecenia - spanning-tree vlan <id_vlan> root primary drugi sposób: wykorzystanie polecenia - spanning-tree <id_vlan> priority <wartość> Oba polecenia wydajemy w trybie konfiguracji globalnej. Załóżmy, że zależy nam aby to przełącznik S1 został rootem. Wydajmy więc pierwsze z poleceń. Po wydaniu komendy sprawdźmy efekt jej wykonania. Jak można zauważyć switch S1 został przełącznikiem głównym. Wykorzystajmy drugi z sposobów i sprawmy aby teraz switch S3 uzyskał status root-a. Zostało wydane polecenie: spanning-tree vlan 1 priority 20000 Jak można stwierdzić komenda nie została wykonana gdyż wartość priorytetu musi być wielokrotnością 4096. Poprawmy naszą komendę i spróbujmy wydać polecenie: spanning-tree vlan 1 priority 20480 Tym razem wydanie komendy kończy się sukcesem.

37 (Pobrane z slow7.pl) Sprawdzenie efektów przeprowadzonej konfiguracji przekonuje nas, że przełącznik S3 pełni teraz rolę roota. Jak jest różnica pomiędzy poleceniami? Zacznijmy od końca wykorzystanie polecenia: spanningtree <id_vlan> priority <wartość> wymusza na nas dobranie takiej wartości priorytetu by ta okazała się najniższa a tym samym pozwoliła switchowi na pełnienie roli przełącznika głównego (wartość priorytetu w przypadku PVST jest ustalana w obrębie VLAN-u). W przykładzie z wykorzystaniem komendy: spanning-tree vlan <id_vlan> root primaryswitch sam zadba o takie dobranie wartości priorytetu by stać się przełącznikiem głównym. Powróćmy do naszej początkowej konfiguracji w której to S2 pełni rolę roota i załóżmy, że z jakiś powodów nie odpowiada nam wybór trasy ustalonej pomiędzy switchem S3 i S2. Chcemy aby nowa trasa przesyłu pakietów uwzględniła interfejs f0/3 bądź f0/4 przełącznika S3 a tym samym by podróż pakietów odbywała się poprzez przełącznik S1. Mówiąc może trochę prościej doprowadźmy do sytuacji w której to porty f0/1 oraz f0/2 przełącznika

38 (Pobrane z slow7.pl) S3 zostaną zablokowane. Jak widać na zrzucie poniżej na razie mamy do czynienia z sytuacją odwrotną. Aby zmienić drogę, podróży ramek musimy dokonać takiej modyfikacji kosztu ścieżki aby ta obecnie ustalona okazała się z punktu widzenia protokołu STP mniej korzystna. Dokonamy zmiany kosztu ścieżki dla interfejsów f0/1 oraz f0/2 przełącznika S3. Zmianę kosztu ścieżki dokonujemy za pomocą polecenia: spanning-tree cost <wartość>. Polecenie wydajemy w trybie konfiguracji interfejsu. Wartość kosztu ścieżki z domyślnej 19 została zmieniona na 50. Aby powrócić do wartości domyślnej skorzystaj z polecenia: no spanning-tree cost Po dokonanej zmianie konfiguracji porty f0/1 oraz f0/2 przełącznika zostają zablokowane. Koszt dotarcia za ich pośrednictwem do S2 wynosi 50 i jest wartością wyższą (mniej korzystną pamiętamy, że w przypadku kosztu ścieżki preferowane są wartości niższe) niż w przypadku skorzystania z drogi poprzez przełącznik S1 koszt trasy 19+19=38

Nasza topologia po tej zmianie przybiera następujący kształt. 39 (Pobrane z slow7.pl)

40 (Pobrane z slow7.pl) Przy protokole STP w przypadku wykorzystania wielu łączy fizycznych możemy dokonać również zmiany aktualnie aktywnego kanału przesyłu danych (czytaj interfejsu, który będzie odpowiedzialny za przekazywanie ruchu sieciowego). Zmianę tą dokonujemy za pomocą zmiany priorytetu portu. Powróćmy z powrotem do sytuacji w której to przełącznik S2 został wybrany przez protokół STP do pełnienia roli przełącznika głównego a komunikacja pomiędzy S2 i S3 odbywa się za pomocą interfejsów f0/1 oraz f0/2 przełącznika S3. Konfiguracja zmiany priorytetów przełącznika zostanie wykonana na switchu S3. Jak można zaobserwować poniżej aktywnym interfejsem przełącznika S3, który jest odpowiedzialny za przesyłanie ramek jest port f0/1 (jeszcze w stanie nasłuchiwania) natomiast blokowanym portem jest f0/2. Spróbujmy ten stan rzeczy zmienić i doprowadzić do sytuacji w której interfejsy zamienią się rolami tj. f0/1 będzie portem blokowanym natomiast f0/2 będzie interfejsem obsługującym ruch sieciowy.

41 (Pobrane z slow7.pl) Aby porty zamieniły się swoimi rolami musimy doprowadzić do sytuacji w której protokół STP stwierdzi, że korzystniejszą opcją będzie powierzenie roli root port interfejsowi f0/2. Aby scenariusz taki mógł mieć miejsce musimy zmodyfikować wartość priorytetu portu f0/2 na niższą niż ta która została przypisana interfejsowi f0/1 - oba interfejsy mają ustawioną domyślną wartość priorytetu portu na 128 (oczywiście sytuacja w której zwiększamy wartość priorytetu interfejsu f0/1 na większą niż ta posiadana przez interfejs f0/2 jest również jak najbardziej dozwolona). Wartość priorytetu portu obejmuje zakres od 0 do 255 a niższa wartość przez algorytm STP jest bardziej preferowana. Aby dokonać zmiany wartości priorytetu należy posłużyć się poleceniem: spanning-tree portpriority <wartość_priorytetu>. Polecenie wydajemy w trybie konfiguracji interfejsu, nam zależy aby to interfejs f0/2 stał się portem komunikacyjnym tak więc komenda została wydana w linii poleceń tegoż interfejsu. Po zmianie wartości priorytetu portu f0/2 z 128 na 112 możemy sprawdzić jakie zmiany zaszły w naszej topologii. Zmiana priorytetu doprowadziła do zamiany ról portów. Interfejs f0/1 przełącznika S3 (wyższy

42 (Pobrane z slow7.pl) priorytet) został zablokowany natomiast interfejs f0/2 (niższy priorytet) stał się root portem. Modyfikację priorytetu portu można dokonać dla jednej lub większej liczby sieci VLAN. Modyfikacji tej dokonujemy poprzez dodanie opcjonalnego parametru vlan. Identyfikatory sieci VLAN są definiowane jako lista, której elementy oddzielamy przecinkami. Pominięcie parametru vlan spowoduje ustawienie wartości priorytetu dla wszystkich aktywnych sieci VLAN. Przykładowe polecenie: spanning-tree vlan 1, 10 port-priority 32 spowoduje zmianę priorytetu na 32, wartość ta będzie obowiązywać w sieciach VLAN o identyfikatorze 1 oraz 10 (pamiętamy o warunku: wartość priorytetu portu musi być wielokrotnością liczby 16). Zanim przejdziemy dalej chciałbym przedstawić kilka poleceń systemu IOS, które bezpośrednio odnoszą się do protokołu STP a pozwolą nam one na uzyskanie informacji potrzebnych do zrozumienia omówionych zagadnień a dodatkowo przydadzą w dalszej części wpisu. Za pomocą polecenia: show spanning-tree blockedports poznamy listę interfejsów, które w wyniku działania algorytmu drzewa rozpinającego zostały zablokowane.

43 (Pobrane z slow7.pl) Komendy: show spanning-tree bridge lub show spanning-tree root są odpowiedzialne za udzielenie informacji na temat przełącznika głównego. Za pomocą komend poznamy wartości zegarów STP. Polecenie: show spanning-tree detail dostarcza bardzo szczegółowych informacji o interfejsach w kontekście działania protokołu STP.

44 (Pobrane z slow7.pl)

45 (Pobrane z slow7.pl) Wydanie polecenia: show spanning-tree interface <id_interfejsu> dostarczy skróconych informacji na temat portu uczestniczącego w procesie STP. Informacje te dostarczają podstawowych informacji o protokole STP tj. informują o: bieżącym statucie portu, pełnionej roli, koszcie ścieżki czy priorytecie portu. Wydanie komendy: show spanning-tree summary poinformuje nas o włączeniu takich funkcji jak PortFast, BPDU Guard, filtrowanie BPDU, UplinkFast czy BackboneFast (opis w dalszej części artykułu). A co najważniejsze uzyskamy dane o aktywnej wersji protokołu STP (na zrzucie poniżej przełącznik obsługuje tryb PVST czyli STP z wsparciem dla sieci VLAN).

46 (Pobrane z slow7.pl) Zaś polecenie: show spanning-tree vlan 1 dostarczy nam informacji o parametrach protokołu STP obowiązujących w danej sieci VLAN.

47 (Pobrane z slow7.pl) W protokole STP mamy do czynienia z trzema zegarami (timerami) kontrolującymi przejście portu z jednego stanu do kolejnego. Przyjęte wartości zegarów zostały dobrane na wzorcowym rozmiarze sieci co oznacza, że dla małych sieci wartości te możemy zmienić na krótsze tak by zbieżność sieci została osiągnięta szybciej. Wzorcowy rozmiar sieci został przyjęty na 7 (ramka danych musi przejść drogę przez 7 przełączników) i dla takiej sieci wartości domyślne zegarów zostały przyjęte. Modyfikację zegarów protokołu STP dokonujemy na przełączniku głównym gdyż tylko on jest odpowiedzialny za rozpowszechnienie tych informacji. Propagacja danych odbywa się poprzez wysłanie ramek BPDU (wartości zegarów swoje odzwierciedlenie znajdują w odpowiednich polach ramki BPDU). Do czynienia mamy z następującymi zegarami: Zegar Hello - odpowiedzialny za wyzwalanie okresowych komunikatów powitań. Domyślnie zegar został ustawiony na wartość 2 sekund a jego modyfikacja zawiera się w zakresie od 1 do 10 sekund. Zmiana wartości zegara powoduje wymuszenie na sąsiadach wysyłanie powitań w ustalonym odstępie czasu, oznacza to, że przełącznik główny będzie oczekiwał nadejścia ramek w zdefiniowanym interwale czasu. Modyfikację zegara hello dokonujemy za pomocą polecenia: spanning-tree hello-time <sekundy> Zegar opóźnienia przesyłania (ang. forward delay) odpowiedzialny za czas potrzebny z przejścia z

48 (Pobrane z slow7.pl) stanu nasłuchiwania do stanu uczenia się a także określa czas potrzebny by ze stanu uczenia się przejść do stanu przesyłania. Domyślna wartość zegara została ustawiona na 15 sekund a jego modyfikacja zawiera się w zakresie od 4 do 30 sekund. Wartość tego zegara powinna być starannie dobrana gdyż zależy ona od fizycznych rozmiarów naszej sieci, zbyt szybkie przejście portu z jednego stanu do drugiego może spowodować powstanie pętli. Zmianę wartości zegara dokonujemy za pomocą polecenia: spanning-tree forward-time <sekundy> Zegar maksymalnego wieku (ang. max age) definiuje czas przechowywania jednostki BPDU, która została otrzymana od sąsiada. Po wygaśnięciu tego czasu port przełącznika zaczyna generować ramki BPDU konfiguracji. Wartość domyślna zegara to 20 sekund a zmiana zegara jest możliwa w zakresie od 6 do 40 sekund. Zmianę wartości zegara maksymalnego wieku dokonamy za pomocą polecenia: spanning-tree max-age <sekundy> Wszystkie polecenia dotyczące zmiany domyślnych wartości zegarów protokołu STP dokonujemy w trybie konfiguracji globalnej. W poleceniach tych należy dołączyć dodatkowy parametr vlan odpowiedzialny za definicję zegarów STP w określonych sieciach VLAN. Np. polecenie: spanning-tree vlan 1,10 hello-time <sekundy> spowoduje zmianę częstotliwości wysyłania komunikatów powitań w odniesieniu do sieci VLAN o identyfikatorze 1 oraz 10. Pominięcie parametru vlan (nie zawsze jest dozwolone, zależy od wersji systemu IOS) spowoduje ustawienie wartości zegarów dla wszystkich sieci VLAN bądź wygenerowanie błędu składni polecenia. Jeśli taka sytuacja nastąpi należy użyć i zdefiniować parametr vlan. Zmianę zegarów STP przetestujemy na topologii zamieszczonej poniżej.

49 (Pobrane z slow7.pl) Przełączniki został włączone, algorytm STP wybrał root-a (przełącznik S2), wartości zegarów protokołu STP przyjęły domyślne wartości. Wartość przyjętych czasów poznamy po wydaniu polecenia: show spanning-tree Spróbujmy dokonać modyfikacji wartości zegarów. Modyfikowane interwały czasu zostały ustalone na następujące wartości:

50 (Pobrane z slow7.pl) hello-time - 3 sekundy, forward-time - 8 sekund, max-age - 12 sekund. Aby dostosować zegary do przyjętych wartości zostały wydane polecenia (komendy wydajemy oczywiście na przełączniku głównym a odnoszą się one do domyślnej sieci VLAN 1): Po dokonanej zmianie wartości czasu poszczególnych zegarów, efekt zmian sprawdzimy wydając ponownie polecenie: show spanning-tree Wartości timerów zostały zmodyfikowane. Zmianę zegarów dodatkowo możemy sprawdzić na innym z przełączników (poniżej zrzut konfiguracji protokołu STP przełącznika S1).

51 (Pobrane z slow7.pl) Jest jeszcze jeden ze sposobów aby dostosować zegary protokołu STP. Zastosowanie go nie wymaga od nas ręcznego określania wartości każdego z zegarów. Wcześniej wspomniałem, że wartości zegarów zostały ustanowione na wzorcowej sieci, której średnica odniesienia wynosi 7 przełączników. Załóżmy, że w naszej sieci pracują trzy przełączniki podłączone w trójkąt. Tak więc najdłuższą dostępną drogą jaką może zostać przesłana ramka danych jest ścieżka obejmująca wszystkie trzy przełączniki. Jest to mniej niż przyjęta wartość odniesienia. W naszym scenariuszu możemy przyjąć iż średnica naszej sieci wynosi 3 a dodatkowo by przełączniki jak najszybciej mogły wykryć brak sąsiada czas Hello Time zostaje skrócony do 1 sekundy. Aby wykonać przyjęte założenia należy wydać polecenie: spanning-tree vlan <id_vlan> root primary diameter <średnica_sieci> hello-time 1 Wydanie polecenia spowoduje zmianę domyślnych zegarów protokołu STP na te odpowiadające przyjętej średnicy sieci a dodatkowo ustawi zegar Hello Time na 1 sekundę. Po wydaniu tej komendy switch na którym przeprowadzamy konfigurację zostaje rootem. Zmienione wartości zegarów zostały pokazana na zrzucie poniżej.

52 (Pobrane z slow7.pl) Funkcja ta odpowiada za pominięcie kliku stanów protokołu STP tak by jak najszybciej przejść do trybu w którym będzie można przekazywać ruch sieciowy. Funkcja PortFast stosowana jest w sytuacji w której do portu przełącznika podpięta jest stacja końcowa (komputer, drukarka sieciowa). Oznacza to, że funkcja ta powinna być stosowana tylko w warstwie dostępu. Funkcja ta w żadnym przypadku nie może być wykorzystana na interfejsie do którego podpięty jest inny przełącznik. Wyobraźmy sobie sytuację w której host końcowy zostaje wyłączony (interfejs sieciowy hosta jest nie aktywny) port przełącznika za pomocą którego jest ustanowiona komunikacja z hostem przechodzi w stan nieaktywny. Powtórne włączenie hosta spowoduje uaktywnienie portu przełącznika lecz by mógł on pełnić swoją rolę i poprawnie przesyłać otrzymane ramki musi przejść przez wszystkie stany protokołu STP. Oznacza to, że za nim port zacznie przekazywać ramki (przy domyślnych zegarach STP) minie przynajmniej 30 sekund (15 sekund na nasłuchiwanie i uczenie się kolejne 15 sekund zostanie wykorzystane by przejść z stanu nasłuchiwania do transmitowania). Aby skrócić ten czas i by port przełącznika mógł natychmiast przesyłać dane należy na interfejsie przełącznika do którego host jest podłączony uaktywnić funkcję PortFast. Włączenie tego mechanizmu spowoduje skrócenie stanów nasłuchiwania i uczenia się tak by możliwe było natychmiastowe przesyłanie danych. Po włączeniu mechanizmu PortFast wykrywanie pętli nadal działa, a interfejs przełącznika zostanie zablokowany w sytuacji w której pętla takowa zostanie wykryta. Pojedynczy host w większości przypadków takiej pętli nie utworzy (lecz jest wyjątek). Wyjątkiem tym może być sytuacja w której np. w systemie Windows poprzez dodatkowy interfejs jest zapewniona inna droga połączenia z siecią a dodatkowo na hoście jest uruchomiona funkcja: Połączenia mostkowe. Opisana sytuacja jest dość specyficznym wariantem konfiguracji systemu i spotykana jest niezmiernie rzadko lecz warto o takim wariancie pamiętać.

53 (Pobrane z slow7.pl) Domyślnie na wszystkich portach przełącznika mechanizm PortFast jest wyłączony. Aby go uaktywnić można skorzystać z dwóch rozwiązań. Rozwiązanie pierwsze uaktywnia funkcję PortFast na wszystkich portach pracujących w trybie dostępu (access). Oznacza to, że polecenie pominie interfejsy na których został ustanowiony tryb trunk (łącze magistrali). Aby włączyć PortFast należy w trybie konfiguracji globalnej wydać polecenie: spanning-tree portfast default Drugie rozwiązanie sprowadza się do włączenia funkcji PortFast na każdym z interfejsów z osobna. Polecenie nakazujące włączenie PortFast wydajemy w trybie konfiguracji interfejsu - spanning-tree portfast Jest i trzeci sposób - opis w tekście poniżej. Wyłączenie mechanizmu PortFast odbywa się za pomocą polecenia: no spanning-tree portfast wydanego w trybie konfiguracji interfejsu. Topologia dla scenariusza PortFast przedstawia się następująco:

54 (Pobrane z slow7.pl) Jak widać powyżej pomiędzy wszystkimi przełącznikami zostało zestawione łącze trunk natomiast do dwóch interfejsów - przełącznik S1 port f0/6 oraz przełącznik S3 port f0/18 zostały podłączone hosty. Łącza te pracują w trybie dostępu. Hosty (a raczej interfejsy przełącznika do których są podłączone) zostały przypisane do sieci VLAN o identyfikatorze 10. Polecenie: show interfeces trunk wydane na przełączniku S1 przedstawia wszystkie interfejsy pracujące w trybie magistrali (trunk).

55 (Pobrane z slow7.pl) Dla przypomnienia, również komenda: show interfaces <id_portu> switchport pokaże nam bieżący status portu. Poniżej został ukazany stan interfejsu f0/1 przełącznika S1. Interfejs ten pracuje w trybie trunk (zresztą jak również interfejs f0/3).

56 (Pobrane z slow7.pl) Wydanie tej samej komendy w odniesieniu do interfejsu f0/6 ukaże nam iż interfejs ten został skonfigurowany w trybie dostępu (do portu zostało podłączone urządzenie końcowe).

57 (Pobrane z slow7.pl) Sprawdźmy stan skonfigurowany portów pod kątem mechanizmu PortFast. Wydanie polecenia: show spanning-tree interface <id_portu> portfast uwidoczni status funkcji. Poniżej dla przełącznika S1 i jego interfejsów f0/1 oraz f0/6, mechanizm PortFast jest nieaktywny. Host podłączony do interfejsu f0/6 i należący do sieci VLAN 10 z funkcji PortFast nie korzysta. Uaktywnijmy PortFast korzystając z pierwszego rozwiązania a mianowicie uruchamiając go z wykorzystaniem polecenia: spanning-tree portfast default PortFast powinien zostać uruchomiony na wszystkich interfejsach dostępowych.

58 (Pobrane z slow7.pl) Po wydaniu polecenia jesteśmy ostrzeżeni o konsekwencjach podłączenia do interfejsu na którym została uaktywniona funkcja PortFast przełącznika bądź huba - podłączenie takowego urządzenia spowoduje powstanie pętli. Po uaktywnieniu PortFast sprawdźmy stan mechanizmu. Ponowne wydanie polecenia: show spanning-tree interface <id_portu> portfast ukaże nam włączony interfejs f0/6 przełącznika S1, na którym działa funkcja PortFast. Ten sam efekt zostałby by uzyskany gdybyśmy w trybie konfiguracji interfejsu f0/6 wydali polecenie: spanning-tree portfast Jest jeszcze jeden sposób, który pozwoli nam włączyć PortFast na porcie a mianowicie wykorzystanie polecenia: switchport host Komendę wydajemy w trybie konfiguracji interfejsu. Tak naprawdę wydanie polecenia spowoduje wykonanie trzech osobnych instrukcji (dość wygodne gdyż nie musimy wykonywać tego osobnymi komendami): Uaktywniona zostanie funkcja PortFast, Interfejs przełącznika ustawiany jest w trybie dostępu, Wyłączany jest protokół PAgP odpowiedzialny za zestawienie kanału EtcherChannel (o EtcherChannel możesz przeczytać w moimi wcześniejszym wpisie: http://slow7.pl/sieci-komputerowe/item/112-co-w-sieci-siedzi-agregacja-laczy-przelacz nika). Poniżej na rysunku za pomocą polecenia: switchport host został skonfigurowany interfejs f0/18 przełącznika S3.

59 (Pobrane z slow7.pl) Sprawdzenie stanu mechanizmu PortFast uwidacznia, że interfejs został skonfigurowany poprawnie. Dodatkową weryfikację stanu włączenia bądź wyłączenia funkcji PortFast możemy dokonać za pomocą polecenia: show spanning-tree vlan <id_vlan> Na rysunku poniżej w tabeli w kolumnie Type przy interfejsie f0/18 pojawił się wpis Edge oznaczający aktywność PortFast na danym interfejsie. Poleceniem, które również pozwoli nam na zweryfikowanie stanu PortFast jest polecenie: show spanning-tree detail Po wydaniu polecenia zostanie przedstawiona konfiguracji protokołu STP w odniesieniu do konkretnych interfejsów przełącznika i ich przynależności do konkretnych sieci VLAN. Aby uzyskać informacje w kontekście jednego konkretnego interfejsu można posłużyć się poleceniem: show spanning-tree interface <id_portu> detail

60 (Pobrane z slow7.pl) Poniżej na zrzucie został ukazany stan interfejsu f0/18. Analiza informacji uzyskanych po wydaniu polecenia przekonuje nas iż na porcie tym aktywna jest funkcja PortFast. Dodatkowo można zauważyć, że pomimo uaktywnienia mechanizmu port nadal odbiera i wysyła ramki BPDU. Spowodowane to jest nadal aktywnym wykrywanie ewentualnych pętli. Z mechanizmem PortFast związana jest jeszcze jedna funkcja a mianowicie BPDU Guard. BPDU

61 (Pobrane z slow7.pl) Guard jest funkcją, która chroni interfejs przełącznika przed otrzymywaniem ramek BPDU na portach, na których nie powinny się takowe ramki pojawić. Funkcja ta stanowi jeden z elementów podwyższających bezpieczeństwo naszego przełącznika, gdyż można wyobrazić sobie atak w warstwie drugiej przeprowadzony z wykorzystaniem protokołu STP. Atakujący mógłby wykorzystać zestawione do hosta połączenie aby w miejsce hosta podłączyć przełącznik bądź użyć oprogramowania potrafiącego wygenerować fałszywe ramki BPDU (np. stp-packet, brconfig, scapy czy yersinia) Atak na STP zwykle wiąże się ze zmianą przełącznika głównego na ten kontrolowany przez atakującego. Wspomniane programy mogą zostać wykorzystane do wysłania fałszywych komunikatów STP. Atakujący host poprzez rozgłoszenie komunikatów BPDU stara się wymusić ponowne przeliczenie algorytmu spanning-tree. BPDU generowane przez fałszywego hosta ogłaszają niższe wartości priorytetu tak, aby atakujący host został wybrany jako root. W przypadku powodzenia ataku i wybrania fałszywego przełącznika root-em uzyskujemy dostęp do informacji, które by były nie osiągalne w inny sposób. Jeśli port skonfigurowany jako PortFast i z włączoną opcją BPDU Guard zacznie otrzymywać ramki BPDU, switch automatycznie zablokuje ten port (przełączy go w stan errdisable). Po przejściu portu w ten stan administrator ręcznie musi go uaktywnić (możliwe jest również skonfigurowanie tzw. errdisable timeout czyli czasu, po minięciu którego, port powraca do stanu normalnego funkcjonowania). Aby włączyć BPDU guard na wszystkich portach z włączoną opcją PortFast, korzystamy z polecenia: spanning-tree portfast bpduguard default Polecenie wydajemy w trybie konfiguracji globalnej. BPDU Guard możemy również włączyć na interesującym nas interfejsie z wykorzystaniem polecenia: spanning-tree bpduguard enable Komendę oczywiście wydajemy w trybie konfiguracji interfejsu. Przeprowadźmy więc mały test zbudujmy bardzo prostą konfigurację opartą na schemacie zamieszczonym poniżej. Interfejs f0/3 przełącznika pracuje w trybie dostępu a dodatkowo na porcie została włączona funkcja PortFast oraz BPDU Guard.

62 (Pobrane z slow7.pl) Jak widać poniżej na zrzucie po wydaniu polecenia: show spanning-tree interface f0/3 detail obie funkcje są włączone. W scenariuszu do interfejsu f0/3 jest podłączony host. Aby mieć możliwość wysłania komunikatów BPDU, host zostaje zamieniony na przełącznik. Po dokonanej zmianie nowo podłączony przełącznik zaczyna wysyłać ramki BPDU. Na skutek włączonej funkcji BPDU Guard interfejs f0/3 przełącznika S1 przechodzi do stanu errdisable. Informacje o interfejsach wyłączonych na skutek włączonych mechanizmów zabezpieczeń uzyskamy po wydaniu polecenia: show interfaces status err-disabled Funkcja BPDU Guard zablokowała port.

63 (Pobrane z slow7.pl) Jak wcześniej wspominałem funkcję PortFast oraz BPDU Guard można aktywować globalnie tak by domyślnie oba mechanizmy były włączone. Poniżej na rysunku włączenie obu funkcji na przełączniku S1. Status funkcji poznamy po wydaniu polecenia: show spanning-tree summary totals Z mechanizmem PortFast związana jest także funkcja filtrowania BPDU. Opcja ta zabezpiecza interfejsy w trybie PortFast przed odbieraniem i wysyłanie komunikatów BPDU. Tak więc filtrowanie uniemożliwia wysyłanie i przetwarzanie ramek BPDU na portach przełącznika.

64 (Pobrane z slow7.pl) Opcja ta, może być skonfigurowana globalnie lub na poziomie interfejsu. Filtrowanie domyślnie jest wyłączone na wszystkich interfejsach przełącznika. Aby automatycznie włączyć BPDU filtering na wszystkich interfejsach z aktywnym PortFast korzystamy z polecenia: spanning-tree portfast bpdufilter default Polecenie wydajemy w trybie konfiguracji globalnej. W przypadku interfejsów, które nie korzystają z PortFast filtrowanie nie zostanie włączone. Uruchomienie filtrowania w ten sposób spowoduje wyłączenie wysyłania ramek BPDU w kierunku hostów. W przypadku pojawienia się ramek BPDU interfejs traci status PortFast i filtrowanie BPDU zostaje wyłączone. Włączenie filtrowania BPDU w trybie konfiguracji interfejsu odbywa się za pomocą polecenia: spanning-tree bpdufilter enable Uaktywnienie opcji spowoduje wyłączenie na interfejsie protokołu spanning-tree co może doprowadzić do powstania pętli. Weryfikację filtrowania BPDU przeprowadzimy za pomocą poleceń: show spanning-tree summary oraz show spanning-tree interface <id_interfejsu> detail. Aby jeszcze podwyższyć ochronę protokołu STP można skorzystać z dodatkowej funkcji jaką jest Root guard. Mechanizm ten umożliwia nam kontrolę nad wyborem przełącznika głównego. Kontrola ta realizowana jest poprzez ograniczenie portów przełącznika, na których będzie realizowany proces negocjacji. Na interfejsie przełącznika z skonfigurowaną funkcją Root guard otrzymane komunikaty BPDU z wartościami lepszymi będą ignorowane. Po otrzymaniu takich ramek port switcha przełączy się do stanu root-inconsistent. Oznacza to, że interfejs nie bierze udziału w przekazywaniu ruchu sieciowego. Port zostanie przywrócony do normalnego stanu tylko wtedy gdy na interfejsie przestaną pojawiać się komunikaty BPDU wymuszające na przełączniku zmianę roota. Podsumowując, mechanizm Root guard powinien być włączany na interfejsach przełącznika, do których podłączone są inne switche, które nigdy nie powinny zostać rootami. Root guard uaktywniamy za pomocą polecenia: spanning-tree guard root wydanego w trybie konfiguracji interfejsu. To tradycyjnie już mały przykład. Załóżmy, że mamy o to taką prostą topologię złożoną z dwóch przełączników.

65 (Pobrane z slow7.pl) Przełącznik S1 jest rootem. Oba przełącznik są ze sobą połączone za pomocą interfejsu f0/3. Na przełączniku S1 zostaje uaktywniona funkcja Root guard. Włączenie funkcji zabroni przełącznikowi S2 zostanie przełącznikiem głównym. O włączeniu Root guard dodatkowo jesteśmy poinformowani stosownym komunikatem w linii CLI przełącznika. Dodatkowo weryfikację włączenia funkcji możemy przeprowadzić za pomocą polecenia: show spanning-tree interface <id_interfejsu> detail Na porcie f0/3 przełącznika S1 została uaktywniona funkcja Root guard.

66 (Pobrane z slow7.pl) Wymuśmy sytuację w której to przełącznik S2 będzie chciał zostać root-em. Na przełączniku S2 zostaje wydane polecenie: spanning-tree vlan 1 root primary Efekt wydania polecenia powinien być taki iż przełącznik S2 powinien zacząć pełnić rolę przełącznika głównego. Tak się nie dzieje gdyż mechanizm Root guard uaktywniony na switchu S1 wykrywa ramki BPDU nakazujące zmienić status pełnionej roli i zaczyna blokować interfejs f0/3. Informacja o zablokowaniu portu f0/3 zostaje nam przekazana poprzez komunikat w linii CLI przełącznika. Sprawdzenie statusu portu f0/3 dostarcza nam informacji iż port f0/3 nie działa - status portu został ustanowiony na tzw. stan root inconsistent

67 (Pobrane z slow7.pl) Port f0/3 w stanie root inconsistent będzie tak długo pozostawał aż przestaną napływać ramki BPDU o parametrach STP lepszych niż te które zostały przypisane przełącznikowi S1. Aby zaprzestać wymuszenie zmiany root-a na przełączniku S2 zostaje wydane polecenie: no spanning-tree vlan 1 root primary Po wydaniu polecenia port f0/3 przełącznika S1 przechodzi z stanu blokowania do stanu normalnego funkcjonowania. O fakcie tym jesteśmy poinformowani komunikatem. Ponowne sprawdzenie stanu interfejsu potwierdza otrzymaną informację. Port f0/3 uczestniczy w procesie przekazywania danych. Zostało przywrócone normalne funkcjonowanie portu. Tak więc by zakończyć temat ochrony protokołu STP na koniec krótkie porównanie BPDU guard i Root guard. BPDU guard spowoduje wyłączenie interfejsu przełącznika (stan errdisable) po otrzymaniu komunikatu BPDU jeśli na porcie uaktywniono PortFast. Ponowne włączenie portu musi zostać wykonane przez administratora. Root guard pozwala innym przełącznikom uczestniczyć w STP, uczestnictwo trwa tak długo, póki dane urządzenie nie stara się zostać rootem. Normalne funkcjonowanie portu jest przywracane

68 (Pobrane z slow7.pl) automatycznie po zaprzestaniu otrzymywania ramek BPDU wymuszających zmianę roota a które to mogą być np. efektem przeprowadzanego ataku. Z protokołem STP związana jest jeszcze jedna funkcja - UplinkFast. Mechanizm ten został zaprojektowany z myślą o przełącznikach pracujących w warstwie dostępowej. Przełączniki pracujące w tej warstwie celem redundancji łącz z reguły są połączone wieloma łączami pomiędzy sobą a dodatkowo mają zestawione łącza pozwalające dotrzeć do przełączników pracujących w warstwie dystrybucji. W domyślnej konfiguracji awaria łącza powoduje przejęcie zadań przez inny interfejs przełącznika. Aby port mógł uczestniczyć w przekazywaniu ruchu sieciowego musi przejść wszystkie stany algorytmu STP. Cały proces uzyskania zbieżności może potrwać około 45 sekund bądź dłużej (wszystko zależy od konfiguracji naszej sieci). Mechanizm UplinkFast pozwala interfejsowi będącemu w trybie alternate port pominąć stany listening (stan nasłuchiwania) oraz learning (uczenie się) tak by od razu przejść do przekazywania danych. Z czasu 45 sekund przy ustawieniach domyślnych możemy zejść do 5 sekund przy aktywnym UplinkFast. Aby włączyć UplinkFast na przełączniku należy w trybie konfiguracji globalnej wydać polecenie: spanning-tree uplinkfast Funkcja ta powinna być aktywowana tylko na przełącznikach pracujących w warstwie dostępowej a w żadnym przypadku na switchach pracujących w warstwie dystrybucji bądź rdzenia ponieważ uruchomienie mechanizmu uniemożliwi przełącznikowi zostanie rootem. Włączenie UplinkFast spowoduje ustawienie priorytetu na wartość wynoszącą 49152 (zmiana dotyczy wszystkich sieci VLAN), zmianie również ulegną koszty łączy (koszt zostanie zmieniony na wartość 3019). Dokonane zmiany możemy zaobserwować po wydaniu polecenia: show spanning-tree

69 (Pobrane z slow7.pl) Weryfikację UplinkFast dokonujemy za pomocą polecenia: show spanning-tree summary totals Jak widać poniżej funkcja jest włączona. Wyłączenie UplinkFast następuje po wydaniu polecenia: no spanning-tree uplinkfast Komenda cofa wszystkie modyfikacje priorytetów i kosztów łącza.