Usunięcie protokołu Spanning Tree z określonego portu nie powinno powodować żadnych kłopotów, pod warunkiem jednak, że do portu podłączony jest klient, a nie serwer. W każdym razie jedno jest pewne - dużo łatwiej jest usunąć z portu protokół, niż grzebać w Registry.

Stacja robocze Windows NT (klienci sieci Microsoft opartej na TCP/IP) nie miały podczas testowania żadnych kłopotów z nawiązywaniem łączności z serwerem (ogółem 150 logowań) wtedy, gdy w sieci zainstalowano protokół Spanning Tree, a stacje korzystały z usług serwera DHCP (DHCP - dynamiczne przypisywanie numerów IP zgłaszającym się do pracy stacjom).

Trzeba tu jednak wspomnieć, że witryna webowa Microsoftu wspomina o tym, że mieszanka protokołów DHCP i Spanning Tree może być nieraz przyczyną określonych kłopotów. Na stronie tej umieszczono jednocześnie prostą poradę, którą dobrze już znamy: z portu obsługującego klienta należy usunąć protokół Spanning Tree.

Testowanie

Do obserwowania klientów uruchamiających sesje łączności z serwerami Windows NT i NetWare (oczywiście z użyciem protokołu Spanning Tree) użyto analizatorów SmartBits (Netcom Systems). Analizator SmartBits generował 1000 pakietów na sekundę (zawierających adres rozgłoszeniowy, czyli kierowanych do wszystkich stanowisk pracy zainstalowanych w danej podsieci) i wysyłał je do portu jednego z przełączników.

Parametr SmartCounters (urządzenie monitorujące ruch pakietów) skonfigurowano w taki sposób, aby mierzyć czas, jaki upływa od momenty wysłania pakietu przez port nadający do momentu, gdy pakiet ten dociera do portu przeznaczenia. Pomiary takie robiono w odniesieniu do trzech portów zainstalowanych w przełączniku. Tak uzyskane wyniki dodawano i dzielono przez trzy, otrzymując wartość średnią. I co te wartości mówią? Wynika z nich, że po wyłączeniu protokołu Spanning Tree pakiety docierają do miejsca przeznaczenia o 4 sekundy później. Testowa sieć była niewielka. Można przypuszczać, że w dużych sieciach LAN różnica będzie jeszcze większa.

Inny test symulował sytuację, jaką można spotkać z rzeczywistych sieciach LAN. Kilka stacji podłączono do przełącznika numer 1 i następnie próbowano nawiązywać łączność z serwerem dołączonym do przełącznika numer 2. W przypadku niektórych przełączników próby takie kończyły się niepowodzeniem. Novell dał w tym momencie testującym taką radę: należy zmienić konfigurację klienta, wybierając inne opcje zarządzające procesem logowania się klienta do serwera. Jak już wspomniano wcześniej, w dużych sieciach LAN, w których pracują tysiące klientów, metoda ta nie ma racji bytu.

Pozostaje więc metoda polegająca na usuwaniu protokołu Spanning Tree z poszczególnych portów.

Na dłuższą metę istnieje jeszcze lepsze rozwiązanie - szczególnie z punktu widzenia administratora sieci - trzeba zrezygnować z sieci VLAN i zdać się wyłącznie na przełączniki warstw 3 i 4. Może to być nawet do zaakceptowania, biorąc pod uwagę fakt, że węzły sieci warstw 3 i 4 najnowszej generacji pracują nieporównanie szybciej niż tego samego typu urządzenia produkowane kilka lat temu.

Podsumowując nasze rozważania o protokole Spanning Tree, „porada dnia” mogłaby brzmieć następująco: jeśli już zdecydujemy się na wdrożenie do sieci lokalnej tej technologii, to kupujmy przełączniki produkowane przez jedną firmę. Nie będziemy wtedy musieli wertować kilku dokumentacji i tracić czasu na poznawanie tajników konfigurowania protokołu Spanning Tree, różnych przy różnych produktów. A może producenci znajdą wreszcie jakiś sposób na to, aby zapasowe połączenia nie przyczyniały się do powstawania pętli pakietów, co wyeliminowałoby potrzebę stosowania protokołu Spanning Tree. Technologią tą można by nie zawracać sobie dłużej głowy, podobnie jak sieciami Arcnet, które dawno odeszły do lamusa.