Průzkum implementací. STP, RSTP a GVRP na Linuxu

Průzkum implementací STP, RSTP a GVRP na Linuxu Lukáš Kuna Abstrakt: Tento dokument si klade za cíl seznámit čtenáře s výsledky testů velmi používaných funkcionalit síťových přepínačů STP, RSTP a GVRP na počítačích s operačním systémem založeném na linuxovém jádře. Od čtenáře předpokládá znalost těchto protokolů a do detailů si nečiní ambice je vysvětlovat, pouze otestovat jejich nejpokročilejší a nejstabilnější implementace v praktických úlohách, které by měly pokrýt většinu očekávaných aplikací. Klíčová slova: STP, RSTP, GVRP, Linux, brctl, rstpctl, rstpd, iproute, VLAN 1 Úvod.............................................................................................................................3 2 Vybrané protokoly........................................................................................................4 2.1 Spanning tree protocol (STP)................................................................................4 2.2 Rapid spanning tree protocol (RSTP)...................................................................4 2.3 GARP VLAN registration protocol (GVRP)........................................................4 3 Použitá zařízení a programové vybavení......................................................................5 3.1 Počítač...................................................................................................................5 3.1.1 Hardware.......................................................................................................5 3.1.2 Software........................................................................................................5 3.2 Přepínače...............................................................................................................5 4 Testy STP.....................................................................................................................6 4.1 Konfigurace STP na Linuxu.................................................................................6 4.2 Analýza stavu STP síťového mostu na Linuxu.....................................................7 4.3 Testy volby kořenu stromu, blokovaných portů a ohodnocení linek....................8 4.3.1 Cíle testů........................................................................................................8 4.3.2 Schéma zapojení............................................................................................8 4.3.3 Testy s původními asymetrickými ohodnoceními linek...............................9 4.3.4 Testy s nastavenými symetrickými ohodnoceními linek..............................9 4.4 Testy nastavení priority portů.............................................................................10 4.4.1 Cíle testů......................................................................................................10 4.4.2 Schéma zapojení..........................................................................................10 4.4.3 Test 1: změny priorit na SW0, kořen stromu na SW0................................10 4.4.4 Test 2: změny priorit na SW0, na SW1 vypnuto STP.................................11 4.4.5 Test 3: změny priorit na SW0, kořen stromu na SW1................................11 4.4.6 Test 4: změny priorit na SW1, kořen stromu na SW1................................11 4.5 Testy času dosažení konvergovaného stavu.......................................................12 4.5.1 Cíle testů......................................................................................................12 4.5.2 Schéma zapojení..........................................................................................12 4.5.3 Test..............................................................................................................12 5 Testy RSTP.................................................................................................................13 5.1 Konfigurace RSTP na Linuxu.............................................................................13 5.2 Analýza stavu RSTP síťového mostu na Linuxu................................................14 květen 2009

1/23

5.3 Testy volby kořenu stromu, blokovaných portů a ohodnocení linek..................15 5.3.1 Cíle testů......................................................................................................15 5.3.2 Schéma zapojení..........................................................................................15 5.3.3 Test..............................................................................................................15 5.4 Testy nastavení priority portů.............................................................................16 5.4.1 Test 1: změny priorit na SW0, kořen stromu na SW0................................16 5.4.2 Test 2: změny priorit na SW0, na SW1 vypnuto STP.................................16 5.4.3 Test 3: změny priorit na SW0, kořen stromu na SW1................................16 5.4.4 Test 4: změny priorit na SW1, kořen stromu na SW1................................16 5.5 Test vynucení verze STP a návratu do RSTP režimu.........................................17 5.6 Test nastavení délky prodlevy pro dosažení konvergovaného stavu..................17 5.7 Test nastavení „edge“ portu................................................................................17 5.8 Test nastavení „p2p“ portu..................................................................................17 5.9 Test vypnutí (R)STP na portu.............................................................................17 6 Testy GVRP................................................................................................................18 6.1 Implementace......................................................................................................18 6.2 Konfigurace GVRP na Linuxu............................................................................18 6.3 Základní funkčnost..............................................................................................18 6.3.1 Cíle testu......................................................................................................18 6.3.2 Schéma zapojení..........................................................................................18 6.3.3 Test..............................................................................................................18 6.4 Redundantní propojení směrovače a přepínače s použitím RSTP......................20 6.4.1 Schéma zapojení..........................................................................................20 6.4.2 Test..............................................................................................................20 6.5 Propustnost GVRP přes linuxový most s použitím RSTP..................................21 6.5.1 Schéma zapojení..........................................................................................21 6.5.2 Test..............................................................................................................21 7 Závěr...........................................................................................................................22 8 Použitá literatura.........................................................................................................23

květen 2009

2/23

1 Úvod Počítače v dnešní době dokáží plnit velkou spoustu úkolů. Množina úkolů, které dokáží zastat, jsou odvislé od nainstalovaných programů a operačního systému. Počítače s operačním systémem linuxového typu dnes umí zastat různé činnosti – kancelářská práce, internetový server, síťový směrovač nebo v omezené míře také multimediální práce a počítačové hry. Mým úkolem v této práci je analyzovat možnosti použití běžného počítače s operačním systémem Linux pro použití jako přepínač – provozovat funkce přepínače nebo přinejmenším s okolními přepínači účelně spolupracovat. Bylo nutno tedy vybrat řešení a protokoly, které vytváří samotnou inteligenci dnešních přepínačů a existuje nějaká jejich implementace pro Linuxový operační systém. Při výběru protokolů pro test jejich implementací na Linuxu jsem volil ty, se kterými se administrátor může setkat při konfiguraci přepínačů nejčastěji, jsou implementovány co nejširší množinou výrobců aktivních prvků a jejichž implementace dosáhla jisté úrovně použitelnosti. Všechny testované protokoly se využívají v sítích dnes dominantního ethernetového typu. Nejspíše bych měl říci, že pro přepínač na Linuxu by se mělo použít korektní označení síťový most, avšak díky zvýšené inteligenci a jisté blízkosti fungování tento pojem volně zaměňuji za přepínač.

květen 2009

3/23

2 Vybrané protokoly 2.1 Spanning tree protocol (STP) Protokol STP slouží pro eliminaci smyček v redundadních přepínaných sítích. Jedná se o protokol spojové vrstvy, který popisuje standard 802.1d. Přepínače vybavené tímto protokolem sledují změny stavu linek na vlastních rozhraních, komunikují se sousedními přepínači a ustanovují stromovou hierarchii s kořenem ve zvoleném tzv. „root bridge“. Od tohoto kořene na základě parametrů ceny linek a priorit určují, přes které porty provoz poteče a přes které nikoliv. Na Linuxu se první podpora STP objevila již v jádrech řady 2.2, samozřejmostí je přítomnost v jádrech řady 2.4 a 2.6. Aktivita celého protokolu probíhá na úrovní jádra, pouze pro konfiguraci se využívá utility projektu Bridge utils1.

2.2 Rapid spanning tree protocol (RSTP) Protože doba konvergence protokolu STP již nesplňovala požadavky na poskytovanou kvalitu služby, vznikl v roce 1998 možný nástupce protokolu, popsaný ve standardu 802.11w. Specifikuje několik mechanismů pro rychlejší dosažení konvergovaného stavu, například mechanismy jako „edge“ a „p2p“ porty nebo princip nabídky a potvrzení. Přepínače vybavené RSTP protokolem dokážou díky zpětné kompatibilitě komunikovat i s přepínači, které zatím implementují pouze STP protokol, což předurčuje RSTP k roli vhodného následníka. Při vhodné topologii a konfiguraci lze dosáhnout několikanásobného urychlení dosažení konvergovaného stavu a snížit tak dobu výpadku na několik málo sekund. I přes uvedené výhody však tento ani žádný jiný mechanismus kromě STP není v linuxovém jádře implementován. Existuje však možnost v externí aplikaci v uživatelském prostoru BPDU zprávy, pomocí kterých přepínače komunikují, ze všech rozhraní odposlouchávat a interagovat s jádrem na zablokování portů. V rámci vývojového repozitáře linuxového jádra sídlí projekt Rapid Spanning Tree Protocol for Linux Ethernet bridge2, kde je vyvíjena aplikace pro zpracování BPDU RTSP protokolu a utilita rstpctl, která slouží pro konfiguraci.

2.3 GARP VLAN registration protocol (GVRP) Protokol GVRP slouží pro automatickou konfiguraci virtuálních sítí (VLAN) skrze fyzickou síť o několika přepínačích. GVRP využívá pro distribuci zaregistrovaných VLANů na jednotlivých portech takzvaných Generic Atribute Registration Protocol (GARP) zprávy, stačí tak nakonfigurovat příslušnost do VLANu na okrajových portech a GVRP protokol se postará o zařazení všech potřebných přepínačů a jejich propojovacích portů do odpovídající virtuální sítě. Protokol GVRP není nepodobný protokolu Vlan Trunking Protocol (VTP) 3, používaném hojně na sítích s Cisco aktivními prvky, nevyžaduje však žádný server (je decentralizovaný) a menší nevýhodou je nemožnost distribuce názvů přenášených virtuálních sítí. GVRP jsem však vybral pro test z důvodů větší otevřenosti a standardizace a hlavně častější implementace na aktivních prvcích mnoha výrobců. Svou roli také hrála skutečnost, že nedávno se částečná implementace objevila přímo v linuxovém jádře 2.6.27.

1 http://bridge.sourceforge.net/ 2 http://git.kernel.org/?p=linux/kernel/git/shemminger/rstp.git;a=summary 3 http://en.wikipedia.org/wiki/VTP květen 2009

4/23

3 Použitá zařízení a programové vybavení 3.1 Počítač 3.1.1 Hardware Pro testy byl zapotřebí počítač, na kterém může fungovat zvolený operační systém a umožňuje využívání několika síťových rozhraní, ať už za pomocí integrovaných síťových karet nebo přídavných karet v provedení dostupném na trhu (proto musel být počítač vybaven především sběrnicí PCI nebo PCI Express). Tyto podmínky však nebyly pro výběr počítače příliš omezující, proto jsem použil jeden z dostupných nepoužívaných počítačů následující konfigurace: ● Intel Celeron 2.66 GHz ● 512 MB RAM ● 80 GB IDE disk ● integrovaná gigabitová síťová karta Intel, doplněny dvě PCI síťové karty Realtek 8139

3.1.2 Software Nainstaloval jsem linuxovou distribuci Debian 5.0 Lenny (stable). Pro požadované testy jsem nainstaloval balíky bridge-utils a vlan. Distribuce obsahovala po instalaci jádro 2.6.26.2, test GVRP vyžadoval instalaci novějšího jádra, minimálně 2.6.27, proto jsem zkompiloval aktuální jádro 2.6.29 a nainstaloval ho. Pro GVRP bylo nutno povolit volbu CONFIG_VLAN_8021Q_GVRP v sekci Networking support – Networking options, pod volbou CONFIG_VLAN_8021Q. Aktivace GVRP na rozhraní vyžadovala aktuálnější verzi utilit iproute, zkompiloval a nainstaloval jsem verzi 20090115. Zdrojové kódy aplikací pro test RSTP jsem stáhnul z GIT repozitáře4, zkompiloval je a zkompilovanou utilitu rstpctl a aplikaci rstpd nainstaloval. Během testů se ukázal problém v koexistenci RSTP a GVRP, aplikace rstpd zhavarovala v případě, že obdržela GVRP rámec, který se hodně podobá rámci (R)STP a aplikace si ho nedokázala korektně odfiltrovat. Proto jsem vytvořil několik oprav, které tento a ještě některé další problémy řeší, k dispozici jsou ke stažení na http://sps.lukas-kuna.cz/rstp-patches/.

3.2 Přepínače Použil jsem dva kusy gigabitového metalického a optického přepínače Cisco SRW2008 (formálně řada Linksys Business Series), které podporují všechny testované technologie, jsou na českém trhu velmi dobře dostupné a za velmi přijatelnou cenu.

4 git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/rstp.git květen 2009

5/23

4 Testy STP Provedl jsem několik testů implementace protokolu STP, prvně se ale podíváme, jak se síťové mosty a STP na linuxových přepínačích konfigurují a jak lze diagnostikovat jejich stav.

4.1 Konfigurace STP na Linuxu Pomocí utility vytvoříme síťový most (bridge): brctl addbr br0

Aktivujeme použití STP: brctl stp br0 on

Ověříme, že rozhraní, která chceme do síťového mostu zařadit, nemají nastavenu žádnou IPv4 a pokud možno také IPv6 adresu a zařadíme je mostu (zde pro eth1 a eth2): brctl addif br0 eth1 brctl addif br0 eth2

Aktivujeme síťové karty a zapneme u nich promiskuitní režim (vyžadován pro korektní běh): ifconfig eth1 up promisc ifconfig eth2 up promisc

Aktivujeme síťový most: ifconfig br0 up

Chceme-li změnit prioritu síťového mostu (zde 32768): brctl setbridgeprio br0 32768

Chceme-li změnit ohodnocení jednotlivých linek (zde nastavení ohodnocení 200000 pro eth1): brctl setpathcost br0 eth1 200000

Utilita umožňuje také změnu priority portu, je však nutno dávat pozor. Během testu jsem zjistil, že malou úpravou této hodnoty se ve skutečnosti nic nezmění. Experimentálně jsem při nastavování velmi malých hodnot zjistil, že priorita musí být zadávaná jako požadovaná hodnota děleno čtyřmi. Proto když chceme nastavit na portu eth1 mostu prioritu 144 (144 / 4 = 36), musíme zadat pro správnou funkčnost: brctl setportprio br0 eth1 36

Chceme-li změnit časovou konstantu, jak dlouho port při konvergenci zůstává v „listening“ a „learning“ stavu, tzv. forward delay (zde na 30 sekund): brctl setfd br0 30

květen 2009

6/23

4.2 Analýza stavu STP síťového mostu na Linuxu Stav síťového mostu, jednotlivých portů a obecně celého STP procesu lze sledovat pomocí výpisu po zadání příkazu (pro most br0): brctl showstp br0

Následuje výpis jako například tento: br0 bridge id 8000.00e07deb4ac9 designated root 7000.001ee5bdacf5 root port 1 path cost 200000 max age 20.00 bridge max age 20.00 hello time 2.00 bridge hello time 2.00 forward delay 15.00 bridge forward delay 15.00 ageing time 300.01 hello timer 0.00 tcn timer 0.00 topology change timer 0.00 gc timer 1.26 flags eth1 (1) port id 8001 state forwarding designated root 7000.001ee5bdacf5 path cost 200000 designated bridge 7000.001ee5bdacf5 message age timer 19.60 designated port 8001 forward delay timer 0.00 designated cost 0 hold timer 0.00 flags eth2 (2) port id 8002 state blocking designated root 7000.001ee5bdacf5 path cost 200000 designated bridge 8000.00226b37b5ac message age timer 18.57 designated port 8001 forward delay timer 0.00 designated cost 200000 hold timer 0.00 flags

Mezi klíčové hodnoty ve výpisu směrem od shora patří (v závorce vždy hodnoty z ukázkového výpisu): ● identifikaci lokálního mostu (8000.00e07deb4ac9), složenou z priority mostu a MAC adresy ● identifikace přepínače, který se stal kořenem stromu (7000.001ee5bdacf5) a jaký port k němu vede (1) a s jakou cenou se k němu dostaneme (200000) ● seznam portů v mostu (eth1 jako port 1, eth2 jako port 2) ● identifikace portů (8001 a 8002), které jsou složeny z priority portu (hexadecimálně první dvě cifry) a pořadového čísla portu ● stavy portů (port 1 forwarding a port 2 blocking) ● ocenění linek (obě 200000)

květen 2009

7/23

4.3 Testy volby kořenu stromu, blokovaných portů a ohodnocení linek 4.3.1 Cíle testů Tato část testu se skláda z více podčástí. V první podčásti jsem dle obrázku 1 zapojil Cisco přepínače (SW1 a SW2) v továrním nastavení a aktivoval STP protokol, na počítači vytvořil síťový most a rovněž aktivoval STP, všechny ohodnocení jsem ponechal na původních hodnotách. Zde je nutno podotknout, že původní nastavení ohodnocení (cost) linek na Linuxu se řídí dle standardu 802.1d a na Cisco přepínači vždy (STP i RSTP) podle standardu 802.1t, tím pádem vzniká asymetrické ohodnocení linek SW0-SW1 a SW0SW2. Pro úplnost jsem tedy provedl test pro původní hodnoty asymetrického ohodnocení na SW0 (Linux), ale především v druhé podčásti s úpravou ohodnocení na SW0 také pro sjednocené hodnoty dle 802.1t tak, aby ohodnocení linky z obou stran na přepínačích bylo identické (symetrické). Protože linka mezi přepínači SW1 a SW2 byla jediná v módu 1G (síťové karty v SW0 tento mód nepodporovaly), upravil jsem ručně toto ohodnocení ručně na hodnotu pro 100M dle 802.1t, abych dosáhl jednotného ohodnocení pro všechny linky vedoucí z Cisco přepínačů a test se zjednodušil (podobně by šlo zřejmě dosáhnout stejného výsledku upravením maximální rychlosti portu).

4.3.2 Schéma zapojení

Obrázek 1: schéma zapojení

květen 2009

8/23

4.3.3 Testy s původními asymetrickými ohodnoceními linek Pro tyto testy jsem na přepínači a síťovém mostu ponechal původní ohodnocení linek, s výjimkou ručně ohodnocené propojky mezi přepínači SW1 a SW2 (pro hodnoty 100M, viz. 4.3.1). Všechny porty linuxového mostu byly tedy ohodnoceny 19 dle normy 802.1d a všechny aktivní porty přepínačů 200000. Tuto konfiguraci ohodnocení jsem otestoval s následujícími kombinacemi priorit mostů a zjistil následující stav kořenů stromů a blokovaných portů:

vých sw0 sw1 sw2

SW0 prio SW1 prio SW2 prio 32768 32768 32768 28672 32768 32768 32768 28672 32768 32768 32768 28672

kořen SW2 SW0 SW1 SW2

blokovaný port SW1 směr SW0 SW1 směr SW2 SW2 směr SW0 SW1 směr SW0

log stp_ 01.txt stp_ 02.txt stp_ 03.txt stp_ 04.txt

Tabulka 1: výsledky testu Z tabulky 1 je zřejmé, že volba kořene stromu proběhla při rovnosti priorit podle nejnižší MAC adresy a v jiných případech dle nejnižší priority. Zablokované porty odpovídají nastaveným ohodnocením linek. Z výpisu diagnostiky STP na Linuxu v souboru stp_01.txt, který je přiložen k dokumentu, je také zřejmé, že cena cesty ke kořenu stromu odpovídá lokálnímu ohodnocení linky (nikoliv odlišné hodnotě ohodnocení z Cisco přepínačů), což lze považovat za správné.

4.3.4 Testy s nastavenými symetrickými ohodnoceními linek V tomto testu jsem sjednotil ohodnocení všech linek na 200000 a provedl test znovu, na závěr jsem vyzkoušel pomocí změny ohodnocení linek ovlivnit zablokování portů – nastavil jsem mezi přepínači SW0 a SW2 ohodnocení na 100000.

vých sw0 sw1 sw2 uživ

SW0 prio SW1 prio SW2 prio 32768 32768 32768 28672 32768 32768 32768 28672 32768 32768 32768 28672 32768 32768 28672

kořen SW2 SW0 SW1 SW2 SW2

blokovaný port SW0 směr SW1 SW1 směr SW2 SW0 směr SW2 SW0 směr SW1 SW1 směr SW0

log stp_ 05.txt

stp_ 06.txt stp_ 07.txt

Tabulka 2: výsledky testu Z tabulky 2 je zřejmé, že volby kořene stromu proběhly v pořádku a ovlivnění blokovaného portu za pomocí změny ohodnocení linek se také zdařilo. Během testu se ale vyskytly případy, kdy se nastavené ohodnocení na linuxovém síťovém mostu při fyzickém výpadku a obnovení linky, která z něj vede, přepnulo zpět do automatického režimu, což nepovažuji za dobrou vlastnost.

květen 2009

9/23

4.4 Testy nastavení priority portů 4.4.1 Cíle testů Tuto sadu testů jsem provedl za účelem ověření ovlivňování blokovaných portů pomocí jejich priorit v případě, že do jedné sítě existuje z přepínače více než jedna cesta a všechny mají stejné ohodnocení linek. V tomto testu jsem nechal ohodnocení linek v původním nastavení, protože výsledky testu neovlivní.



4.4.3 Test 1: změny priorit na SW0, kořen stromu na SW0 Při tomto testu jsem nastavil priority přepínačů tak, aby se stal linuxový most SW0 kořenem. Na přepínači SW1 je zapnuto STP, výchozí priority portů a ohodnocení linek. Cílem je určit, zda se zablokuje na SW1 správný port při manipulaci s prioritami na SW0. kořen

blokovaný port SW0 prio port1 SW0 prio port2

log

vých

SW0

SW1 k portu 2

128

128

port1

SW0

SW1 k portu 1

144

128

stp_ 08.txt

port2

SW0

SW1 k portu 2

128

144

stp_ 09.txt

Tabulka 3: výsledky testu Porty se zablokovaly správně – podle nastavení priorit na portech SW0.

květen 2009

10/23

4.4.4 Test 2: změny priorit na SW0, na SW1 vypnuto STP Na Cisco přepínači SW1 jsem deaktivoval STP a snažil se ovlivnit zablokovaný port na linuxovém mostu SW0, který se tímto stal také kořenem stromu.

vých port1 port2

kořen SW0 SW0 SW0

blokovaný port SW0 port 2 SW0 port 1 SW0 port 2

SW0 prio port1 128 144 128

SW0 prio port2 128 128 144

Log stp_10.txt stp_11.txt

Tabulka 4: výsledky testu Porty se zablokovaly správně – podle nastavení priorit na portech.

4.4.5 Test 3: změny priorit na SW0, kořen stromu na SW1 Na obou přepínačích bylo aktivováno STP, kořen stromu nastaven na SW1, změna priorit probíhala na SW0 za účelem ovlivnění blokovaného portu na tomto linuxovém mostu. Na přepínači SW1 zůstávají priority a ohodnocení linek sobě rovné a po dobu testu neměněné.

vých port1 port2

kořen SW1 SW1 SW1


SW0 prio port1 128 144 128

SW0 prio port2 128 128 144

log stp_12.txt stp_13.txt

Tabulka 5: výsledky testu Změnou priorit na linuxovém mostu nedošlo k žádné změně blokovaného portu, toto je správné chování, lokálním nastavením priorit toto nemohu ovlivnit.

4.4.6 Test 4: změny priorit na SW1, kořen stromu na SW1 V tomto testu jsem měnil priority na portech kořenu SW1, aby linuxový most SW0 při rovností ohodnocení linek musel vybírat blokovaný port podle posílaných priorit.

vých port1 port2

kořen SW1 SW1 SW1


SW1 směr port1 128 144 128

SW1 směr port2 128 128 144

log stp_14.txt stp_15.txt

Tabulka 6: výsledky testu I zde proběhla volba blokovaného portu v pořádku – podle priorit na SW1.

květen 2009

11/23

4.5 Testy času dosažení konvergovaného stavu 4.5.1 Cíle testů Na závěr jsem se rozhodl otestovat, jak dlouho trvá přechod linuxového mostu do konvergovaného stavu a tuto skutečnost ovlivnit pomocí nastavení prodlevy.



4.5.3 Test Po deaktivaci a opětovné aktivaci linuxovéhu mostu (ifconfig br0 down ; ifconfig br0 up) trval ve výchozím nastavení přechod do konvergovaného stavu 30 sekund, přičemž ve stavu „listening“ zůstal 15 sekund a ve stavu „learning“ rovněž 15 sekund. Pomocí volby „forward delay“ je možno tento čas 15 sekund ovlivnit, pokud však zrovna není linuxový most kořenem stromu, tato hodnota se nepoužije, použije se hodnota nastavená na aktuálním kořenu. Pokud se linuxový most stane kořenem, ihned toto nastavení použije a začne se jim řídit. Po zdvojnásobení tohoto intervalu oproti výchozímu stavu (na 30 sekund) zůstal most v každém („listening“ i „learning“) stavu 30 sekund (správně). Tyto výsledky lze považovat za správné, nicméně jsem zjistil, že pokud přejde kořen stromu z linuxového mostu na jiný přepínač, most se „tváří“, že používá novou správnou „forward delay“ z nového kořene, nicméně v „listening“ stavu zůstává stále dvojnásobnou dobu, přičemž v „learning“ již pouze 15 sekund. Toto chování je zřejmě nesprávné a jedná se o chybu.

květen 2009

12/23

5 Testy RSTP Podobně jsem prováděl také testy implementace RSTP protokolu, nejdříve si opět ukažme, jak se RSTP na linuxových přepínačích konfigurují a jak lze zjistit stav síťového mostu a RSTP protokolu.

5.1 Konfigurace RSTP na Linuxu Pro vytvoření síťového mostu a zařazení rozhraní do něj se stále používá utilita brctl, proto postup vychází z konfigurace STP. Doporučuji ověřit, že jste na mostu neaktivovali STP. Teprve až před samotným uvedením mostu do běhu (ifconfig br0 up) doporučuji zapnout aplikaci rstpd a zapnout RSTP: rstpctl rstp br0 on

Nedodržením tohoto postupu se můžete dočkat nepříjemného překvapení v podobě vytvoření smyčky v síti, která Vám spolehlivě dokáže i přetížit celý stroj a problém vyvrcholí většinou spoustou kernel oops a znefunkčněním vzdáleného přístupu v důsledku zablokování všech síťových rozhraní a posléze celého stroje. Chceme-li změnit prioritu síťového mostu (zde 32768): rstpctl setbridgeprio br0 32768

Chceme-li změnit ohodnocení jednotlivých linek (zde nastavení ohodnocení 200000 pro eth1): rstpctl setportpathcost br0 eth1 200000

Na rozdíl od utility brctl lze nastavit utilitou rstpctl prioritu portu očekávaně v dobrém měřítku, když chceme nastavit na portu eth1 mostu prioritu 144 zadáme: rstpctl setportprio br0 eth1 144

Ekvivalentem setfd u utility brctl je u RSTP (zde pro 30 sekund): rstpctl setfdelay br0 30

Vynutit použití staršího protokolu STP lze pomocí (hodnota „normal“ znamená RSTP): rstpctl setforcevers slow

Nastavení edge portu eth1: rstpctl setportedge br0 eth1 yes/no

Nastavení „p2p“ portu pro eth1: rstpctl setportp2p br0 eth1 yes/no/auto

Možnost vypnutí (R)STP na portu na eth1: rstpctl setportnonstp br0 eth1 yes/no

Provedení migračního testu – test možnosti přechodu STP na RSTP na portu eth1, na kterém zůstaly přímo připojeny pouze přepínače s podporou RSTP (oproti předchozímu stavu, kdy některý z přepínačů podporoval pouze STP protokol): rstpctl portmcheck br0 eth1

květen 2009

13/23

5.2 Analýza stavu RSTP síťového mostu na Linuxu Stav síťového mostu, RSTP procesu a portu lze zobrazit pomocí dvojice příkazů: rstpctl showbridge br0 rstpctl showportdetail br0

První z příkazů provede výpis tohoto typu: Bridge: br0 State:enabled BridgeId: 800000e07deb4ac9 Bridge Proirity: 32768 (0x8000) Designated Root: 8000001ee5bdacf5 Root Port: 8001, Root Cost: 200000 Time Since Topology Change: 1076 Max Age: 20 Bridge Max Age: 20 Hello Time: 2 Bridge Hello Time: 2 Forward Delay: 15 Bridge Forward Delay: 15 Hold Time: 3

Zde vidíme úhrnné informace o mostu, priority přepínačů, čas od poslední změny topologie, port směřující ke kořenu, s jakou cenou, apod. Druhý z příkazů vypíše (výpis zkrácen pouze na jeden port): Stp Port eth2: PortId: 8002 in Bridge 'br0': Priority: 128 State: Discarding Uptime: 1042 PortPathCost: admin: Auto oper: 200000 Point2Point: admin: Auto oper: Yes Edge: admin: N oper: N Partner: oper: Rapid PathCost: 200000 Designated Root: 8000001ee5bdacf5 Designated Cost: 200000 Designated Bridge: 800000226b37b5ac Designated Port: 8001 Role: Alternate fdWhile: 15 rcvdInfoWhile: 5 rbWhile: 0 rrWhile: 0 RSTP BPDU rx: 203 CONFIG BPDU rx: 0 TCN BPDU rx: 0

Tento výpis zobrazuje všechny očekávané nastavení každého z portů a jejich aktuální stav.

květen 2009

14/23

5.3 Testy volby kořenu stromu, blokovaných portů a ohodnocení linek 5.3.1 Cíle testů Test proběhl obdobně jako u testu STP, s výjimkou toho, že na linuxovém mostu již nebylo nutno výchozí ohodnocení (200000) měnit, protože je již v souladu s ohodnoceními na přepínači Cisco. Opět jsem však ručně upravil ohodnocení propojky mezi přepínači SW1 a SW2 (jako u testů STP, viz. 4.3.1).



5.3.3 Test V úvodních 4 testech jsem testoval pouze správné zvolení kořenu stromu a blokovaných portů, v posledním testu jsem se snažil ovlivnit umístění blokovaného portu ohodnocením propojení SW0 a SW2 na 150000.

vých sw0 sw1 sw2 uživ

SW0 prio 32768 28672 32768 32768 32768

SW1 prio 32768 32768 28672 32768 32768

SW2 prio 32768 32768 32768 28672 28672

kořen SW2 SW0 SW1 SW2 SW2

blokovaný port SW0 směr SW1 SW1 směr SW2 SW0 směr SW2 SW0 směr SW1 SW1 směr SW0

log rstp_01.txt rstp_02.txt rstp_03.txt rstp_04.txt

Tabulka 7: výsledku testu Všechny testy dopadly dle očekávání.

květen 2009

15/23

5.4 Testy nastavení priority portů Tato sada testů probíhala zcela shodně jako u testů STP. Protože výsledky dopadly v pořádku a zcela shodně jako u STP, přikládám pouze tabulky s měřeními a odkazy na detailní diagnostické výpisy v přiložených souborech.

5.4.1 Test 1: změny priorit na SW0, kořen stromu na SW0 vých port1 port2

kořen SW0 SW0 SW0

blokovaný port SW1 k portu 2 SW1 k portu 1 SW1 k portu 2

SW0 prio port1 128 144 128

SW0 prio port2 128 128 144

log rstp_09.txt rstp_10.txt

Tabulka 8: výsledky testu

5.4.2 Test 2: změny priorit na SW0, na SW1 vypnuto STP V tomto testu stojí pouze za povšimnutí, že si linuxový most musel projít konvergenčním RSTP procesem o délce 30 sekund, protože nebylo možné aplikovat princip nabídky a potvrzení.

vých port1 port2

kořen SW0 SW0 SW0


SW0 prio port1 128 144 128

SW0 prio port2 128 128 144




kořen SW1 SW1 SW1


SW0 prio port1 SW0 prio port2 128 128 144 128 128 144


Tabulka 10: výsledku testu


kořen SW1 SW1 SW1


SW1 směr port1 128 144 128

SW1 směr port2 128 128 144



květen 2009

16/23

5.5 Test vynucení verze STP a návratu do RSTP režimu Pomocí volby setforcevers jsem vyzkoušel přepnutí portu do STP režimu, který rovněž má aplikace rstpd implementován. Ihned po přepnutí začaly přepínače indikovat použití staršího protokolu (detaily v souboru rstp_05.txt). Po opětovném přepnutí do RSTP módu se však hned tento protokol nezačne používat, přechodu by měl napomoct tzv. migrační test (volba portmcheck). Zde však nemám přesný návod, jak tohoto přepnutí na RSTP dosáhnout, v různých případech pomohl rozdílný postup. Nicméně doporučuji zapnout migrační test zapnout nejdříve na Cisco přepínači a bezprostředně na linuxovém mostu, pokud se neustálí spojení na RSTP, opakujte tento postup v opačném pořadí a případně stále dokola až do dosažení indikace RSTP.

5.6 Test nastavení délky prodlevy pro dosažení konvergovaného stavu Díky urychlujícím principům se mi v kruhovém zapojení (obrázek 4) podařilo dosáhnout konvergovaného stavu při fyzickém odpojení kterékoliv linky z SW0 do cca 1 sekundy, při opětovném zapojení do cca 2-3 sekund. V této situaci nemá smysl měnit prodlevu (setfdelay), proto jsem se rozhodl využít přepnutí do STP režimu a otestování zdvojnásobení prodlevy ve stejném zapojení jako u STP (obrázek 3). Při přepnutí do STP režimu trval celý konvergenční proces zhruba 30 sekund (15 sekund „listening“ a 15 sekund „learning“). Co však považuji za zarážející, je to, že při přechodu z „listening“ do „learning“ stavu prošla přes most testovací odezva (ping). Při opakování se toto však nepodařilo nasimulovat, avšak při podrobném testu by se tato vada zřejmě dala zreprodukovat. Při zdvojnásobení prodlevy se nic nestalo, protože linuxový most nebyl aktuálně kořenem, když jsem upravil nastavení a most se jím stal, nastavení se dle diagnostických výpisů aktivovalo a most zůstal v každém z „listening“ a „learning“ stavu 30 sekund. Bohužel reálný stav neodpovídal diagnostice, první polovinu času v „listening“ stavu (15 sekund) přes most data skutečně neprocházely, nicméně v druhé polovině přes most testovací ICMP odezvy procházely, poté během 30ti sekund v „learning“ stavu zase data neprocházely. Výsledky tohoto testu považuji za alarmující.

5.7 Test nastavení „edge“ portu Odpojil jsem páteřní kabel mezi linuxovým mostem a Cisco přepínačem a aktivoval na uvolněném portu linuxového mostu „edge“ vlastnost. Po opětovném zapojení kabelu přešel port rychle do stavu „forwarding“, podle diagnostiky v pořádku zachytil RSTP BPDU a „edge“ režim se dočasně deaktivoval (viz. soubor rstp_06.txt). Linku jsem zkusil přepojit do běžného přepínače bez (R)STP podpory, most přešel rychle do „forwarding“ stavu a indikoval aktivní „edge“ režim (viz. soubor rstp_07.txt).

5.8 Test nastavení „p2p“ portu Znovu jsem odpojil páteřní kabel z jednoho portu linuxového mostu a na obou koncích původního spoje jsem nastavil na portech „p2p“ režim. Po zapojení kabelu linuxový most prošel 15ti sekundami „discarding“ a 15ti sekundami „learning“ stavu, což je očekávané chování.

5.9 Test vypnutí (R)STP na portu Na vybraném portu linuxového mostu jsem vypnul používání (R)STP pomocí volby setportnonstp (utility rstpctl) a zapojil opačný konec kabelu do běžného přepínače (bez podpory STP nebo RSTP). Dle pozorování provozu na portu pomocí utility tcpdump nebyl shledán žádný (R)STP provoz (viz. soubor rstp_08.txt).

květen 2009

17/23

6 Testy GVRP 6.1 Implementace V linuxovém jádře je implementována základní podpora GVRP, která umožňuje zaregistrovat používané virtuální sítě z linuxového směrovače do přilehlého přepínače. Sám linuxový směrovač periodicky neposílá na segment zprávy „Leave all“, které slouží pro zjištění virtuálních sítí od přilehlých přepínačů, protože se získanými informacemi by stejně neuměl nijak naložit (nepotřebuje nijak dynamicky vytvářet virtuální sítě na rozhraních podle okolních přepínačů).

6.2 Konfigurace GVRP na Linuxu Nyní si ukažme, jak obecně GVRP registraci pro jednotlivé rozhraní virtuálních sítí na Linuxu aktivovat. Běžně vytvoříme VLAN: vconfig add eth2 150

Povolíme jeho registraci prostřednictvím GVRP: ip link set eth2.150 type vlan gvrp on

6.3 Základní funkčnost 6.3.1 Cíle testu V tomto testu jsem otestoval základní funkčnost GVRP registrace používaných virtuálních sítí na Linuxu do přilehlého GVRP přepínače Cisco.



6.3.3 Test Při aktivaci VLANu odešle jádro na segment sítě zprávu „Join in“ a při odebrání odesílá zprávu „Leave Empty“. Pokud je na segmentu přítomen GVRP přepínač, který rozesílá periodicky zprávu „Leave all“, obnovuje směrovač registraci virtuální sítě pomocí zprávy „Join in“. Všechny GVRP zprávy jsou odesílány v neznačkovaných rámcích („non-tagged“ ve smyslu standardu 802.1q).

květen 2009

18/23

Funkčnost registrace a odregistrace VLANu 150 ze směrovače do přepínače demonstrují jednoduché diagnostické výpisy z Cisco přepínače. Výpis po aktivaci GVRP na rozhraní virtuální sítě (ip link set eth2.150 type vlan gvrp on): 01Jan2000 01:05:55 %VLANIGVRPAddVlan: Dynamic VLAN Vlan 150 was added by GVRP 01Jan2000 01:05:55 %LINKIUp: Vlan 150 01Jan2000 01:05:55 %VLANIGVRPAddPort: Dynamic port g1 was added to VLAN Vlan 150 by GVRP

Výpis po deaktivaci GVRP na rozhraní virtuální sítě (ip link set eth2.150 type vlan gvrp off): 01Jan2000 01:06:50 %LINKWDown: Vlan 150 01Jan2000 01:06:50 %VLANIGVRPDelPort: Dynamic port g1 was removed from VLAN Vlan 150 by GVRP 01Jan2000 01:06:50 %VLANIGVRPDelVlan: Dynamic VLAN Vlan 150 was removed by GVRP

Virtuální síť je také korektně odregistrována v případě, kdy je rozhraní s virtuální sítí smazáno (vconfig rem eth2.150). Odpovídající provoz jsem zachytil utilitou tshark a lze nalézt v přiloženém souboru gvrp_01.cap.

květen 2009

19/23

6.4 Redundantní propojení směrovače a přepínače s použitím RSTP 6.4.1 Schéma zapojení


6.4.2 Test V tomto testu (obrázek 6) jsem se rozhodl zařadit dvě síťové karty do jednoho síťového mostu a každou síťovou kartu (port mostu) připojit do stejné Cisco přepínače. Pro eliminaci smyčky sem použil protokol RSTP. Na Linuxu při vytvoření mostu vzniká nové rozhraní, na kterém lze přidávat virtuální sítě. Na rozhraní mostu jsem tedy vytvořil rozhraní virtuální sítě 99 a zkusil ji prostřednictvím GVRP propagovat přes most do přepínače. Směrovač v pořádku zaregistroval přes most do přepínače používanou virtuální síť přes aktivní port, přes blokovaný port GVRP zprávy neprošly. Při odpojení kabelu v aktivním propojení RSTP automaticky aktivoval záložní port a poté automaticky směrovač zaregistroval tuto virtuální síť přes záložní port. Přeregistrace probíhala také v souladu s očekáváními také při opětovném připojení kabelu. V ideálním případě přepínač pouze vymění zařazené porty: 01Jan2000 01:56:30 %VLANIGVRPAddPort: Dynamic port g8 was added to VLAN Vlan 99 by GVRP 01Jan2000 01:56:36 %VLANIGVRPDelPort: Dynamic port g1 was removed from VLAN Vlan 99 by GVRP

Pokud se špatně sejde přepnutí portu a GVRP přeregistrace v reakci na „Leave all“ zprávu, může dojít i k celkové přeregistraci virtuální sítě: 01Jan2000 01:53:49 %LINKWDown: Vlan 99 01Jan2000 01:53:49 %VLANIGVRPDelPort: Dynamic port g8 was removed from VLAN Vlan 99 by GVRP 01Jan2000 01:53:49 %VLANIGVRPDelVlan: Dynamic VLAN Vlan 99 was removed by GVRP 01:53:54 %VLANIGVRPAddVlan: Dynamic VLAN Vlan 99 was added by GVRP 01Jan2000 01:53:54 %LINKIUp: Vlan 99 01Jan2000 01:53:54 %VLANIGVRPAddPort: Dynamic port g1 was added to VLAN Vlan 99 by GVRP květen 2009

20/23

6.5 Propustnost GVRP přes linuxový most s použitím RSTP 6.5.1 Schéma zapojení


6.5.2 Test V tomto testu (obrázek 7) jsem chtěl ověřit, zda se jsou schopny dva přepínače domlouvat GVRP zprávami, které procházejí přes linuxový most. Cílem je situace, kdy si přepínače na mostem propojeném segmentu vyměňují registrované virtuální sítě a do toho si linuxový směrovač registruje své virtuální sítě, které potřebuje. Toto zapojení se dá s výhodou použít pro redundantní zapojení směrovače do přepínané infrastruktury, ať už do jednoho nebo více přepínačů – GVRP se postará o registraci virtuálních sítí přes linku, kterou RSTP aktuálně neblokuje. Samotné GARP rámce se odesílají na multicastovou MAC adresu a v jejich průchodnosti linuxovým mostem nebyl shledán problém. Směrovač reagoval na „Leave all“ zprávy všech přímo připojených přepínačů zprávou „Join in“, navíc multicastový rámec se odesílá na všechny porty mostu, takže registrace do všech přepínačů proběhla v pořádku. Funkčnost jsem ověřil také v situacích, kdy jsem odpojoval postupně linky mezi přepínači za účelem, aby byly přepínače nuceny distribuovat dále virtuální sítě registrované z linuxového směrovače. Ukázku GVRP provozu při blokovaném propojení mezi SW1 a SW2 si můžete prohlédnout v přiloženém souboru gvrp_02.cap. Lze v něm velmi dobře vidět, jak každé z připojených zařízení registruje svoje virtuální sítě v reakci na zprávy „Leave all” obou přepínačů.

květen 2009

21/23

7 Závěr Provedené testy ukázaly, že ověřované implementace protokolů STP a RSTP pro eliminaci smyček v redundantních přepínaných oblastech lze v omezené konfiguraci s výhradami použít. U STP se velmi vzácně vyskytly případy, kdy nebyla smyčka eliminována (tento případ se nepodařilo reprodukovat), nepříjemné byly však problémy s vymazáním ručního nastavení ohodnocení portu. Drobné konfigurační problémy ohledně nastavení priorit portů lze přehlédnout. Zvláště u implementace RSTP však lze říci, že se jedná o řešení nešťastné a nedotažené a během testů značně více než u STP docházelo k vytvoření nežádoucích smyček, jejichž existenci měly tyto implementace zabránit. Dle mého názoru slouží toto řešení RSTP pouze jako odrazový můstek pro možnou integraci protokolu přímo do jádra, kde by řešení možná více doznalo na kvalitě a stabilitě. Testovaná implementace protokolu GVRP pro registraci virtuálních síti z linuxového směrovače do přilehlého přepínače prokázala své kvality a lze ji bez výhrad doporučit pro běžné použití.

květen 2009

22/23

8 Použitá literatura [1] Net:Bridge [online]. 2005 [cit. 2009-05-03]. Dostupný z WWW: . [2] Spanning tree protocol [online]. 2002 [cit. 2009-05-03]. Dostupný z WWW: . [3] Multiple Registration Protocol [online]. 2005 [cit. 2009-05-03]. Dostupný z WWW: . [4] Understanding Spanning-Tree Protocol [online]. 1989-1997 [cit. 2009-05-03]. Dostupný z WWW: . [5] Understanding Rapid Spanning Tree Protocol (802.1w) [online]. Oct 24, 2006 [cit. 2009-05-03]. Dostupný z WWW: . [6] Tutorial on VLANs: Part 2 [online]. VIII 12, 2004 [cit. 2009-06-03]. Dostupný z WWW: . [7] Protocol GVRP [online]. [cit. 2009-05-03]. Dostupný z WWW: . [8] Generic VLAN Registration Protocol (GVRP) [online]. 2003 [cit. 2009-05-03]. Dostupný z WWW: .

květen 2009

23/23

Průzkum implementací. STP, RSTP a GVRP na Linuxu

Recommend Documents