To jeden z tych protokołów, które po prostu działają, są niezawodne, a jedyne problemy, które pojawią się, wynikają nie z błędów w działaniu protokołu, co w designie naszej sieci. Po co właściwie nam ten protokół? Jako że pracuje on w warstwie 2, czyli warstwie łącza danych rozwiązuje problem z ramkami oraz redundancją. Oczywiście wszyscy chcemy mieć redundancję, jednak ze względu na obsługę ramek typu broadcast oraz unknown unicast (wszystkie te ramki są wysyłane przez switch poprzez wszystkie interfejsy oprócz tego, na którym otrzymaliśmy daną ramkę) bardzo łatwo zdestabilizować tablice mac adresów (jeden adres nadawcy ramki pojawią się na różnych interfejsach) oraz wywołać broadcast storm (switche rozsyłają pakiety oraz je duplikują na wszystkich interfejsach). Ze względu na brak mechanizmu kontroli jak długo ramka może istnieć w sieci (w L3 mamy TTL) raz wysłane dane mogą krążyć w sieci LAN na zawsze (routery nie przekazują takich pakietów na zewnątrz sieci).

Co więc robi STP, aby zapobiec temu wszystkiemu? Tworzy drzewo połączeń pomiędzy switchami, umożliwiając komunikację pomiędzy nimi wyłącznie jedną ścieżką (po wykryciu awarii jest możliwe przepuszczenie ruchu alternatywną ścieżką, jednak w danym okresie czasu tylko jedna ścieżka jest możliwa).

Elekcja root switcha

Jak każde drzewo również STP potrzebuje swojego korzenia (root’a), od które wszystko będzie się dalej rozchodzić. Jak tego dokonać? Podczas elekcji switche komunikują się za pomocą specjalnych ramek BPDU – Bridge Protocol Data Unit, które zawierają Bridge ID składający z priorytetu + rozszerzonego identyfikatora systemu (identyfikator vlanu) oraz adresu MAC.

Proces elekcji wygrywa switch z najniższym BID. Od teraz wszystkie porty wychodzące od tego switcha,będą portami desygnowanymi i będą przekazywać cały ruch.  W naszej topologii S3 został wybrany rootem. Ponieważ wszystkie switche mają ten sam priorytet 32769, porównujemy adresy MAC. Porty z S1 oraz S2 w stronę S3 są portami typu root. Dlaczego? Ponieważ posiadają najniższy koszt dotarcia do root switcha.

W przypadku połączenia pomiędzy S1 i S2 z jednej strony mamy port typu designed oraz z drugiej strony port typu blocking.  Co istotne port w stanie blocking nie przepuszcza ruchu, ale nadal odbiera i interpretuje ramki BPDU. Dlaczego? Ponieważ standardowo root rozsyła co sekundy ramki BDPU, które są przekazywane dalej w ramach drzewa STP. Jeżeli switch nie otrzyma takiej ramki w czasie 20s (10x 2s – typowy dead interval) rozpoczyna rekalkulację drzewa STP, aby umożliwić dalszą komunikację w sieci.

Stany portów w spanning-tree

Stany STP w skrócie informują, co port ma zrobić z otrzymanymi ramkami, czy powinien je dyskretnie odrzucić, przetworzyć czy przesłać dalej. O ile switch może przełączyć port przesyłający dane w stan blokowania, a o tyle przełączenie portu odrzucającego dane do portu przesyłającego dane wymaga przejścia przez kilka stanów blocking -> listening -> learning -> forwarding.

Port w stanie Listening usuwa wszystkie stare adresy MAC, które ma w tabeli, ponieważ mogłyby one powodować pętle. Dodatkowo jak w stanie blocking dyskretnie odrzuca wszystkie pakiety.

Port w stanie Learning nadal nie przekazuje dalej danych, ale wpisuje do tablicy odebrane źródłowe adresy MAC.

Role portów w Spanning-tree protocol!

Stany portów w STP są nierozerwalnie związane z ich rolami. W tabeli uwzględniłem również ich występowanie, ponieważ część roli jest nowością dodaną w RSTP

Ewolucja spanning-tree PVST+

Skoro Spanning-tree zabiega powstawaniu pętli poprzez umożliwienie przesyłania danych wyłącznie poprzez porty desygnowane oraz root, a pozostałe przełączając w stan blokowania, pozbawiamy się w ten sposób możliwości wykorzystania pełnej przepustowości switcha lub chociaż realizacji prostego równoważenia ruchu.

O tym samym pomyślało Cisco i stworzyło PVSTP+ czyli udoskonalenie protokołu STP tworząc instancję spanning tree dla każdego vlanu. Dzięki temu odpowiednio manipulując kosztami, możemy przesyłać dane z różnych vlanów poprzez różne linki, zapewniając sobie równoważenie obciążenia ruchu w sieci, nadal nie rezygnując z redundancji.

Przyspieszamy spanning-tree – RSTP

Pomimo tego, że STP działa świetnie, są sytuacje kiedy objawiają się jego niedoskonałości. Dla przykładu, kiedy padnie nam port typu desygnowanego, STP potrzebuje ok 50s!, aby przełączyć się ze stanu blokowania do przekazywania pakietów (20s oczekiwania na pakiety BPDU, 15s nasłuchiwania, 15s na uczenie się). 50s w XXI wieku to jak wieczność!

W celu rozwiązania tego problemu powstał protokół RSTP, którego działanie jest stosunkowo proste. Po wyborze root switcha wysyła on pakiet BPDU poprzez wszystkie porty i przełącza je w tryb discarding. Jeśli sąsiadujący switch zechce komunikować się poprzez dany port, odeśle pakiet BPDU i port zostanie odblokowany. Prawda, że proste? Dodatkowo przełączenie portu ze stanu odrzucania pakietów do stanu przekazywania jest w zasadzie wykonywane w czasie kilku sekund (MaxAge wynosi 3x Hello).

Cisco oczywiście stworzyło udoskonalenie RSTP, umożliwiając skorzystanie z zalet PVST+ dzięki czemu mamy Rapid PVST+

Multiple Spanning Tree Protocol (MSTP)

MSTP to inspirowany wydanym przez Cisco protokołem MISTP Multiple Instance STP. Stworzony przez IEEE pozwala na przypisanie kilku VLAN’ów do jednej instancji STP, co jest bardzo wygodne gdy posiadamy kilka-kilkanaście VLAN i nadal chcemy zachować pełną kontrolę nad ruchem w swojej sieci.

W urządzeniach Cisco MSTP jest implementowane jako MST i pozwala na utworzenie do 16 instancji RSTP.

Co jeszcze umie STP?

Postęp jest czym absolutnie pożądanym i oczekiwanym nawet w przypadku rzeczy, które działają dobrze. Dlatego również STP posiada kilka dodatków przyspieszających jego pracę oraz zwiększających bezpieczeństwo sieci.

Portfast – Porty te przechodzą natychmiastowo w stan przekazywania i zostają portami desygnowami, ponieważ są to zazwyczaj porty, pod które są podpięci użytkownicy końcowi, którzy nie powinni powodować zmian w naszej instancji STP.

BPDUguard – Ustawia się na porty, które  nie powinny otrzymywać BDPU. Jeśli port otrzyma ramkę BDP, natychmiast przełączy się w stan error-disable.

BPDU filter – Ustawia się na portach, które nie powinny przesyłać pakietów BPDU. Jeśli ustawimy BPDU filter, na tym samym porcie co BPDUguard to ten drugi zostanie nadpisany.

Root Guard – W odróżnieniu od innych udoskonaleń root guard nie może być używany globalnie i musi być przypisany bezpośrednio do interfejsu. Root guard zapobiega przejściu portu ze stanu desygnowanego do root.