Jak na trable s příliš mnoha cestami

Je vaše síť ve stavu neustálých změn? Jsou v ní kombinovány přepínače na druhé vrstvě obsluhující některé seg...


Je vaše síť ve stavu neustálých změn? Jsou v ní kombinovány přepínače na druhé
vrstvě obsluhující některé segmenty a zařízení na třetí vrstvě a možná na
čtvrté vrstvě obsluhující ty ostatní? Máte někde ve vaší síti implementovány
virtuální LANy? Pokud vám to zní povědomě, přidejte protokol spanning tree do
seznamu věcí, o kterých musíte přemýšlet.
Není neobvyklé mít v síti jak přepínače na druhé vrstvě s 10 Mb/s nebo 100 Mb/s
spoji k lokálním uživatelům, tak i 100Mb nebo gigabitové ethernetové spoje k
přepínači na třetí nebo čtvrté vrstvě. V tomto scénáři jsou segmenty druhé
vrstvy v podstatě propojeny stejně, jako kdyby se použily bridge. Jestliže
disponuje síť propojená pomocí mostů záložními spoji k jiným LAN, potřebujete
použít protokol spanning tree, abyste zajistili správné fungování těchto linek,
kdy jedna bude v záložním modu vůči druhé. VLANy tento problém zvyšují, protože
každý VLAN v podstatě představuje síť propojenou pomocí mostů. Proto
potřebujete konfigurovat oddělené implementace spanning tree pro každou VLAN.
Když povýšíte na přepínače na třetí vrstvě, problém se spanning tree zmizí,
protože máte co do činění se sítěmi se směrováním a nikoli se sítěmi spojenými
pomocí mostu. Vaším cílem by proto mělo být zbavit se protokolu spanning tree
přechodem na plně směrované sítě založené na přepínačích na třetí nebo čtvrté
vrstvě.
My jsme jednoho dne přinesli do naší laboratoře různé přepínače, abychom
zjistili, jestli jsou zde nějaké podobnosti ve způsobu, kterým dodavatelé
implementují algoritmus spanning tree. Zkoumali jsme devět přepínačů od pěti
dodavatelů a nalezli jsme téměř tolik rozdílů, kolik bylo dodavatelů. Máme-li
výsledek shrnout do krátkého poučení, pak se dá říci asi tolik, že musíte
udělat určitou práci, abyste zajistili, že je ve vašich různých přepínačích na
druhé vrstvě spanning tree nastaven správně.
Podle našich testů přepínačů od firem Cisco, Nbase-Xyplex, Foundry, Olicom a
Anritsu je jasné, že většina dodavatelů implementuje spanning tree odlišně.
Například někteří dodavatelé vás nechají povolit nebo zablokovat tento protokol
i na jednotlivých portech, takže port 5 může mít spanning tree povolen a port 6
nikoliv. Ale zdá se, že všichni dodavatelé mají přinejmenším stejné implicitní
filtry.
Problémy na straně klienta
Celkový problém s protokolem spanning tree spočívá v tom, že je to pomalý
protokol a často nedokáže držet krok s rychlostí dnešních sítí. Například pro
zjišťování, zda data jdou tak, jak se předpokládá, používá spanning tree pakety
BPDU (bridge protokol data unit), které obsahují informace o portech, adresách,
prioritách a režii. Ale některé klienty Novellu a Microsoftu se připojují na
port přepínače tak rychle, že spanning tree nemá čas poslat BPDU paket. Tak
vzniká možnost, že pakety budou poslány na porty, na které by neměly jít, čímž
se obchází ochrana, kterou má spanning tree poskytovat.
Obdobně uživatel VLANu, který se přesouvá od jednoho přepínače ke druhému, může
pocítit zpoždění, když se nový port dovídá o novém umístění uživatele. V
rozsáhlých sítích propojených mosty je možné, když dojde k dostatečnému
zpoždění, že jsou data ztracena a musejí být znovu poslána. A vysílací provoz
na síti propojené mosty má vždy sílu zpomalit síť, když protokoly jako spanning
tree nereagují dostatečně rychle.
Když jsme testovali funkci protokolu spanning tree v laboratoři, naše
novellovské klienty neuspěly při spojení s přepínači některých dodavatelů.
Jediný způsob, jak jsme nakonec navázali spojení, byl zablokovat spanning tree
na těch portech přepínače, které byly napojeny na příslušné klienty. Také jsme
občas zažili samovolné restarty NT serveru.
Částečné řešení
Na svých webových stránkách má Microsoft a Novell opravy pro některé přepínače,
které trpí těmito problémy. Opravy obvykle zahrnují zablokování portu, což jsme
udělali, nebo nastavení parametrů v registry, které řídí časové nastavení
klientů s ohledem na následující server.
Zablokování spanning tree na jednotlivých portech by nemělo způsobit žádné
problémy, pokud zablokujete pouze klientské porty ležící proti hlavním linkám.
A zablokování klientských portů je jistě snazší než se trápit s kontrolami
časového nastavení v registry.
Naše stanice s Windows NT a Microsoft TCP/IP klientem neměla žádné problémy se
spojením během 150 přihlášení a pokusů o spojení v DHCP módu s povoleným
spanning tree. Nicméně webovská stránka podpory NT zmiňuje nějaké potenciální
problémy DHCP spanning tree a navrhuje k jejich zamezení zablokovat klientský
port spanning tree.
Úplné řešení problémů
Při našich testech jsme spolupracovali s inženýry z Netcom Systems, tvůrci
analyzátoru výkonu SmartBits. Společně s nimi jsme sledovali klienta
přihlašujícího se do a odhlašujícího se z NT a NetWare serverů. Nastavili jsme
analyzátor SmartBits tak, aby posílal 1 000 paketů za sekundu se všesměrovou
adresou z jednoho modulu portu SmartBits k portu na přepínači 1. Nastavili jsme
čítače tak, aby sledovaly čas mezi tím okamžikem, kdy port začne vysílat
pakety, a tím, kdy začnou přicházet na přijímací port. To jsme provedli pro tři
různé porty každého přepínače a vypočítali průměrnou dobu.
Průměrná doba se zablokovaným spanning tree byla asi o 4 sekundy kratší, než
když byl protokol povolen. Tento výsledek lze zhruba očekávat v malé síti, v
rozsáhlejší síti by zpoždění mohlo být větší. Čtyřsekundové zpoždění v rozsáhlé
síti by skutečně mohlo působit problémy uživatelům snažícím se připojit ke
zdrojům serveru. Například, když se klient snaží přihlásit na DHCP server a je
vystaven čtyřsekundovému zpoždění, klient nemusí dostat IP adresu, a tudíž se
nepřihlásí k žádnému ze síťových serverů.
Poté jsme zkusili několik testů v reálném světě a získali jsme naprosto stejné
výsledky. Zvýšili jsme počet pracovních stanic na přepínači 1 a začali jsme se
přihlašovat na servery připojené na přepínač 2. Přes některé přepínače jsme se
přihlásit nemohli. Novell doporučuje změnit nastavení časů pro přihlašování na
klientu. Jak je uvedeno výše, v rozsáhlých sítích s tisícovkami uzlů to není
možné. Zablokování spanning tree port po portu je mnohem jednodušší.
Dlouhodobé a dokonce lepší řešení z pohledu administrátora je přejít na
přepínače na třetí nebo čtvrté vrstvě a vyhnout se VLANům. Dnes není žádný
důvod vracet se ke spojování pomocí mostů, když je naprosto rozumné vybudovat
směrovanou rychlou síť používající přepínače na třetí nebo čtvrté vrstvě.
Krátce řečeno, můžete si zjednodušit život, když se při používání protokolu
spanning tree budete držet produktů jednoho dodavatele, takže nebudete muset
poznávat rozmary implementací různých firem. Nebo, pokud by dodavatel našel
způsob, jak se jinak vypořádat ze záložními spoji, odstranilo by to potřebu
ochrany před smyčkami pomocí spanning tree potom by tento protokol mohl
následovat Arcnet do knih o síťové historii.
Přejděte na 3. vrstvu
Proč byste kupovali přepínače pro druhou vrstvu, které vyžadují spanning tree,
když můžete získat přepínač pro třetí/čtvrtou vrstvu, který je schopen
směrování na úrovni portů bez tohoto protokolu? Jednou větou, svou roli tu
hraje ekonomika. Přepínače na druhé vrstvě jsou levnější než jejich protějšky
pracující na vrstvě třetí a čtvrté.
Abyste dosáhli největšího užitku z hlediska členění sítě, museli byste nejspíš
všechny přepínače na druhé vrstvě ve své síti nahradit přepínači na třetí/
čtvrté vrstvě. Takový krok nemusí být realizovatelný, ale můžete je začít
nahrazovat postupně.
Když vaše síť roste nebo se obnovuje, začněte kupovat přepínače na třetí vrstvě
a implementovat přepínání podle portů. Možná, že už přepínače na třetí vrstvě
máte, ale nasadili jste je jako zařízení druhé vrstvy. Opět, udělejte skok na
třetí vrstvu.
Někteří prodejci tvrdí, že používání spanning tree v sítích spojených mosty na
druhé vrstvě je zásadně to samé, jako mít směrovače na třetí vrstvě nevěřte
tomu. Je pravděpodobné, že prodejce, který to tvrdí, neprodává přepínače na
třetí vrstvě.
Nedá se nic dělat: dokud jsou kolem nás přepínače na druhé vrstvě a VLANy,
budete zřejmě o protokolu spanning tree potřebovat vědět podstatně víc, než
byste asi chtěli.
K čemu je vlastně dobrý protokol spanning tree
K čemu vlastně slouží protokol spanning tree a jak ho můžete využít ve své
síti? V síti se záložními spoji mezi LANy spojenými pomocí mostů je vždy jeden
hlavní spoj, kterým prochází všechen síťový provoz. Další pak slouží jako
rezervní spoj. Když první spojení spadne, je spanning tree tím algoritmem,
který se o této poruše dozví a zajistí, aby se spustilo záložní spojení.
Bez spanning tree by bylo možné, že by byly oba spoje současně aktivní, což by
mohlo mít za následek vznik nekonečné smyčky v LAN. Je tomu tak proto, že v LAN
spojené pomocí mostů musí být z bodu A do bodu B pouze jedna cesta. Pokud je
zde více než jedna cesta, je možné a dokonce pravděpodobné že se budou stejné
pakety pohybovat dopředu a zpět různými směry kvůli způsobu, jakým se plní
tabulky interního mostu nebo přepínače.
Protokol spanning tree je implicitně povolen na přepínačích většiny dodavatelů,
ale asi budete muset změnit některá nastavení. Změna nastavení může být
obtížným úkolem, protože je tento protokol dost složitý; standard 802.1D, jehož
je součástí, má 378 stran. Ale přidání přepínačů do sítě bez rekonfigurace může
vést k pomalému přihlašování uživatelů, neúspěšným spojením a neoprávněnému
pohybu uživatelů mezi VLANy.
9 2632 / pen









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.