Wprowadzenie do Spanning Tree Protocol (STP)

Spanning Tree Protocol jest jednym z podstawowych zagadnień będących przedmiotem egzaminu Cisco CCNA R&S. Na przestrzeni lat stosunek sieciowców do tego protokołu się bardzo zmieniał – niegdyś było to zło konieczne, a dziś z kolei wielu z nas stara się za wszelką cenę eliminować STP z sieci. Pada więc pytanie – czy warto się uczyć STP? Uważam, że tak – warto. Z STP mamy do czynienia praktycznie na co dzień i szybko się to nie zmieni.

W tym artykule przedstawię Ci kluczową wiedzę związaną ze Spanning Tree Protocol. Dowiesz się dlaczego w ogóle potrzebujemy ten protokół i jak on działa. Nadmienię tylko, że polska nazwa to Protokół Drzewa Rozpinającego. Osobiście niezbyt ją lubię więc w tym materiale będę się trzymał angielskiego terminu 🙂 Zaczynajmy!

Dlaczego potrzebujemy Spanning Tree Protocol?

STP to protokół, z którym spotkamy się w sieciach Ethernet. Typowy scenariusz, w którym łączymy ze sobą dwa komputery może wyglądać następująco:

Typowy scenariusz w sieci Ethernet
Typowy scenariusz w sieci Ethernet

Czy komputery będą mogły się ze sobą w tej sytuacji skomunikować? Tak – zakładając, że wszystko jest poprawnie skonfigurowane. W ruch pójdzie więc między innymi ARP.

Problem z taką topologią jest jednak następujący – awaria któregokolwiek z linków efektywnie nam uniemożliwi dalszą komunikację. Jeżeli będzie to awaria kabla pomiędzy przełącznikami to skutki mogą być poważne ponieważ będzie to miało wpływ na komunikację między wieloma hostami. Mamy tu więc do czynienia z pojedynczym punktem awarii (ang. Single Point Of Failure – SPOF). Możemy go wyeliminować np. dodając drugie łącze między przełącznikami:

Redundancja w postaci drugiego linku między przełącznikami
Redundancja w postaci drugiego linku między przełącznikami

Rozwiązując jeden problem stworzyliśmy jednak kolejny – jest nim pętla. Ale jak to? Wynika to wprost z tego w jaki sposób działa Ethernet. Spójrzmy na to na tym krótkim przykładzie:

1. Komputer 1 chce spingować Komputer 2. Aby to uczynić musi jednak znać docelowy MAC adres. Wysyła więc ramkę ARP.

Komputer A wysyła ramkę ARP
Komputer A wysyła ramkę ARP

2. Z jednego z poprzednich artykułów o ARP wiemy już, że jest to ramka rozgłoszeniowa (broadcast). Przełącznik A otrzymując ją wyśle ją zatem wszystkimi swoimi portami – zarówno Gi 0/1 jak i Gi 0/2

Przełącznik A wysyła ramkę typu broadcast wszystkimi pozostałymi portami
Przełącznik A wysyła ramkę typu broadcast wszystkimi pozostałymi portami

3. Przełącznik B otrzyma ramkę ARP na obu swoich portach – zarówno na Gi 0/5 jak i na Gi 0/6. Następnie zajrzy on w jej zawartość. To co teraz nastąpi zależy od tego, na którym porcie ramka pojawiła się wcześniej. To już jest czysta fizyka i jest to w zasadzie nieistotne. 

Załóżmy sobie, że ramka dotarła wpierw na porcie Gi 0/5. Przełącznik B zatem zapisze sobie że adres MAC komputera A jest osiągalny za pośrednictwem interfejsu Gi 0/5.

Przełącznik B otrzymuje ramkę ARP na porcie Gi 0/5
Przełącznik B otrzymuje ramkę ARP na porcie Gi 0/5

A to wszystko po to by chwilę później nadpisać tę informację – po tym jak ARP dotrze na interfejsie Gi 0/6, przełącznik A zastąpi wcześniejszy wpis.

Przełącznik B otrzymuje kolejną ramkę ARP na porcie Gi 0/6

Przełącznik B otrzymuje kolejną ramkę ARP na porcie Gi 0/6

Można tu już dostrzec symptom pierwszego problemu – wpis w tabeli MAC „skacze” między interfejsami. Spójrzmy na to co się dzieje dalej.

4. Przełącznik B otrzymując ramkę na porcie Gi 0/5 wyśle ją wszystkimi pozostałymi portami (przypominam, że mamy tu do czynienia z ramką typu broadcast). Najgorsze jest jednak to, że ta sama ramka dotarła również na intefejsie Gi 0/6 i przełącznik postąpi z nią dokładnie tak samo:

Przełącznik B wysyła ramkę dalej wszystkimi portami z wyjątkiem portu, na którym ją oryginalnie otrzymał
Przełącznik B wysyła ramkę dalej wszystkimi portami z wyjątkiem portu, na którym ją oryginalnie otrzymał

Widzimy więc, że ARP ostatecznie trafi do komputera B – jest to jednak nieistotne. Istotne jest to, że ramka ta się zapętliła – przychodząc na porcie Gi 0/5 przełącznika B została wysłana z powrotem portem Gi 0/6, Przychodząc na porcie Gi 0/6 została wysłana z powrotem portem Gi 0/5. Ale to nie koniec. Teraz przełącznik A otrzyma dwie ramki typu broadcast na swoich portach Go 0/1 i Gi 0/2. Postąpi z tymi ramkami dokładnie tak samo.

Mamy więc do czynienia z pętlą, która w teorii mogłaby trwać w nieskończoność ponieważ ramki Ethernet w przeciwieństwie do pakietów IP nie posiadają pola TTL. Czym więcej będzie w tej sieci ramek rozgłoszeniowych, tym bardziej problem pętli będzie się pogłębiał. Ostatecznie switch w pewnym momencie może nie dać rady z przełączaniem takiej ilości ramek i się po prostu zrestartuje (będziemy mieli do czynienia z tzw. crashem). 

Powstaje pętla, która ostatecznie może doprowadzić nawet do awarii przełączników
Powstaje pętla, która ostatecznie może doprowadzić nawet do awarii przełączników

Jedynym sensownym rozwiązaniem tego problemu jest odłączenie jednego z linków między przełącznikami. Wracamy więc do punktu wyjścia – dołożyliśmy ten kabel wszakże po to aby mieć redundancję 😉

„Czy wiesz że…?”

Oczywiście jako inżynierzy sieciowi mamy znacznie więcej asów w swoich rękawach i w tej sytuacji można by zagregować łącza między przełącznikami w LAG/Etherchannel co rozwiązałoby problem pętli. Oba linki widoczne by były z logicznego punktu widzenia jako pojedyncze łącze, a ramki by były odpowiednio dystrybuowane pomiędzy interfejsami dzięki użyciu CEF. Jest to już jednak temat na poziomie CCNP R&S.

Widzimy już jak powstają pętle. Jasne jest zatem, że będziemy mieli do czynienia z pętlą również w takiej sytuacji:

Typowy scenariusz z przełącznikami połączonymi w trójkąt w celu zapewnienia redundancji w przypadku awarii któregoś z połączeń
Typowy scenariusz z przełącznikami połączonymi w trójkąt w celu zapewnienia redundancji w przypadku awarii któregoś z połączeń

W przypadku gdyby padło pojedyncze łącze między przełącznikami chcemy mieć zapasową ścieżkę. Taki scenariusz jest bardzo typowy nie tylko na egzaminie CCNA R&S, ale również w codziennej pracy. Można się spotkać w naszych topologiach z różnymi rodzajami pętli, ale to właśnie takie trójkąty są tym najbardziej typowym.

Czas rozwiązać postawiony w tym artykule problem. Nadal chcemy mieć redundancję! Ale w tym samym czasie nie chcemy mieć pętli… Radia Perlman zaproponowała więc w 1990 roku aby wykorzystać opracowany przez nią protokół STP (powstała na ten temat genialna książka – Interconnections Second Edition. Ostrzegam jednak, że wchodzi ona na taki poziom zagłębiania się w szczegóły, że mózg może eksplodować od nadmiaru wiedzy…).

W jaki sposób STP radzi sobie z pętlami?

Spanning Tree Protocol na dzień dzisiejszy ma wiele wersji. W tym materiale przyjrzymy się oryginalnej specyfikacji tego protokołu – czyli 802.1D. Podstawa działania STP jest bardzo prosta – zadaniem protokołu jest wykrycie pętli w topologii i zablokowanie jednego (lub więcej) interfejsów w celu wyeliminowania pętli. Jak sama nazwa wskazuje (Protokół Drzewa Rozpinającego) w efekcie otrzymamy topologię drzewa. Dla prostej topologii jak nasz trójkąt takie drzewo może wyglądać następująco:

Topologia z redundantnymi połączeniami, szary link został "wyłączony" przez STP z działania aby zapobiec pętli
Topologia z redundantnymi połączeniami, szary link został „wyłączony” przez STP z działania aby zapobiec pętli

Nic nie stoi na przeszkodzie aby zaszaleć i stworzyć bardziej skomplikowaną siatkę połączeń. Oczywiście topologia poniżej jest niewskazana, ale nie takie rzeczy można czasem znaleźć w sieciach…

Topologia z redundantnymi połączeniami, szare linki zostały "wyłączone" przez STP aby wyeliminować pętle

Topologia z redundantnymi połączeniami, szare linki zostały „wyłączone” przez STP aby wyeliminować pętle

Proces, który doprowadza do takiego stanu jak powyżej nie jest już jednak taki prosty i wyjaśnimy sobie go na przykładowym scenariuszu.

1. Bazować będziemy na topologii trójkąta, która już się wcześniej pojawiła. Adresy MAC przedstawiane są dal prostoty w skróconej formie. Ponadto dopisane zostały priorytety do poszczególnych przełączników – jest to jeden z elementów mechanizmu STP, o którym zaraz sobie powiemy:

Topologia bazowa z przełącznikami połączonymi w trójkąt
Topologia bazowa z przełącznikami połączonymi w trójkąt

Podstawowym komponentem działania STP jest specjalna ramka, którą przełączniki będą między sobą przesyłać. Mowa tu o BPDU (ang. Bridge Protocol Data Unit). W ramce BPDU w polu „Bridge ID” znajdziemy między innymi adres MAC oraz priorytet przełącznika, który taką ramkę nadał:

Pola zawarte w ramce BPDU
Pola zawarte w ramce BPDU

Bridge ID to nic innego jak zestawienie priorytetu danego przełącznika z jego adresem MAC. W przypadku przełącznika A będzie to zatem „32768:AA:AA”. Warto w tym przypadku nadmienić, że priorytet 32768 jest priorytetem domyślnym dla każdego przełącznika.

2. Przełączniki w pierwszym etapie będą wysyłać między sobą ramki BPDU:

Przełączniki przesyłające między sobą BPDU
Przełączniki przesyłające między sobą BPDU

Celem takiej wymiany jest wybranie tzw. root bridge’a czyli korzenia naszego drzewa rozpinającego. Zasada jest taka, że to przełącznik z najniższym Bridge ID zostanie wybrany jako Root Bridge.

3. W naszym przykładzie to przełącznik A zostanie wybrany jako Root Bridge. Wszystkie przełączniki mają równy, domyślny priorytet 32768, zatem czynnikiem rozstrzygającym jest najniższy numerycznie adres MAC:

Przełącznik A zostaje wybrany Root Bridgem
Przełącznik A zostaje wybrany Root Bridgem

4. W STP mamy do czynienia z różnymi statusami portów. Będziemy je poznawać po kolei. Pierwszym z nich jest Designated Port (DP) czyli port w stanie forwarding. Oznacza to po prostu, że jest to zwykły, normalnie działający port. Wszystkie porty przełącznika wybranego jako Root Bridge będą zawsze portami Designated:

Porty na Root Bridge'u uzyskują status Designated Portów
Porty na Root Bridge’u uzyskują status Designated Portów

5. W kolejnym etapie pozostałe przełączniki (B & C) muszą określić na podstawie informacji zawartych w przesyłanych BPDU jaka jest najkrótsza ścieżka do Root Bridge’a. W naszym przykładzie sprawa jest oczywista: najkrótsza droga do Root Bridge’a dla przełącznika B wiedzie przez port Gi 0/3, podczas gdy dla przełącznika C przez port Gi 0/6. Porty te będą miały nadany status Root Port (RP) i również będą w stanie forwarding:

Porty w kierunku Root Bridge'a uzyskują status Root Portów
Porty w kierunku Root Bridge’a uzyskują status Root Portów

Wspomniałem przed chwilą, że zostanie wybrana najkrótsza ścieżka. Doprecyzujmy to teraz. W przypadku STP najkrótsza ścieżka to tak naprawdę ta, którą najszybciej dotrzemy do Root Bridge’a. Musimy zatem wziąć pod uwagę prędkości danych interfejsów. Sprawa ma się bardzo podobnie do tego co ma miejsce w przypadku np. protokołu routingu OSPF. Szybciej dotrzemy do miejsca docelowego wykonując trzy przeskoki po interfejsach 10 Gbit/s niż jeden przeskok na interfejsie 1 Gbit/s.

W STP (802.1D) poszczególne prędkości portów mają przyporządkowane następujące koszty:

  • 10 Mbit/s – koszt 100
  • 100 Mbit/s – koszt 19
  • 1000 Mbit/s – koszt 4

Jeżeli spojrzymy na naszą topologię z tej perspektywy i weźmiemy pod uwagę sumę kosztów interfejsów (wyjściowych na każdym przełączniku) od przełącznika B w kierunku Root Bridge’a to potwierdzi się, że dokonaliśmy dobrego wyboru Root Portu:

Biorąc pod uwagę prędkości poszczególnych interfejsów przełącznik B ma najniższy koszt do Root Bridge'a na porcie Gi 0/3, który przez to staje się Root Portem
Biorąc pod uwagę prędkości poszczególnych interfejsów przełącznik B ma najniższy koszt do Root Bridge’a na porcie Gi 0/3, który przez to staje się Root Portem

Analogicznie sprawa ma się w przypadku przełącznika C. Nadal mamy jednak pętlę. Czas ją wyeliminować.

6. W celu wyeliminowania pętli STP będzie musiało zablokować jeden z portów na łączu między przełącznikiem B oraz C. Który to powinien być port? W pierwszej kolejności zostaną porównane Bridge ID obu przełączników. Switch B ma niższy Bridge ID zatem port po jego stronie uzyska status Designated:

Port Gi 0/4 na przełączniku B uzyskuje status Designated z uwagi na niższy Bridge ID przełącznika B względem przełącznika C
Port Gi 0/4 na przełączniku B uzyskuje status Designated z uwagi na niższy Bridge ID przełącznika B względem przełącznika C

Nie pozostaje nam teraz nic innego jak zablokować port Gi 0/5 na przełączniku C. Port ten będzie miał status Non-Designated Port (NDP) i znajdować się będzie w stanie blocking. Port w stanie blocking nie przesyła żadnych danych poza ramkami BPDU:

Port Gi 0/5 na przełączniku C uzyskuje status Non-Designated i zostaje zablokowany w celu wyeliminowania pętli w sieci
Port Gi 0/5 na przełączniku C uzyskuje status Non-Designated i zostaje zablokowany w celu wyeliminowania pętli w sieci

I w ten oto sposób wyeliminowaliśmy pętlę! Zabawa się jednak dopiero zaczyna…

W tym artykule przedstawiłem Ci podstawowe komponenty składające się na STP.

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

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

Czytalem o STP w innych zrodlach I mialem metlik w glowie. Po tym artykule sie rozjasnilo. Dzieki

Mariusz
Mariusz
4 lat temu

Własnie przerabiam STP i pochodne w ramach przygotowania CCNA. Czytacie mi w myślach. Dzieki

Marek
Marek
4 lat temu

Bardzo fajnie wyjaśnione 🙂

jhony Brawo
jhony Brawo
2 lat temu

Wykonalem ostatnio tako test, ze do jednego 2 sw zarzadzalnych i skonf STP wpialem zwykly „tepy” switch na ktorym wykonalem petle. I ku mojemu zdziwieniu cala siec padla xD zastanawialem sie jak to mozliwe, skoro jest to rstp/stp. I okazuje sie, ze ten dumb SW nie uxzestniczy w STP. A u innych vendorow „loop protection” moze oznaczac autorskie rozwiązanie. I w takim przypadku chyba trzeba pobawic sie limitem broadcastem. Zgadza sie? Moge prosic o komemtarz z twojej strony?
Dzieki 😉

Cezary
Cezary
5 miesięcy temu
Odpowiedź do  jhony Brawo

Możesz zobrazować z tym „tępym” switchem jak to zrobiłeś?