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

Průzkum implementacíSTP, RSTP a GVRP na LinuxuLukáš KunaAbstrakt: Tento dokument si klade za cíl seznámit čtenáře s výsledky testů velmipoužívaných funkcionalit síťových přepínačů STP, RSTP a GVRP na počítačíchs operačním systémem založeném na linuxovém jádře. Od čtenáře předpokládá znalosttěchto protokolů a do detailů si nečiní ambice je vysvětlovat, pouze otestovat jejichnejpokročilejší a nejstabilnější implementace v praktických úlohách, které by mělypokrýt většinu očekávaných aplikací.Klíčová slova: STP, RSTP, GVRP, Linux, brctl, rstpctl, rstpd, iproute, VLAN1 Úvod.............................................................................................................................32 Vybrané protokoly........................................................................................................42.1 Spanning tree protocol (STP)................................................................................42.2 Rapid spanning tree protocol (RSTP)...................................................................42.3 GARP VLAN registration protocol (GVRP)........................................................43 Použitá zařízení a programové vybavení......................................................................53.1 Počítač...................................................................................................................53.1.1 Hardware.......................................................................................................53.1.2 Software........................................................................................................53.2 Přepínače...............................................................................................................54 Testy STP.....................................................................................................................64.1 Konfigurace STP na Linuxu.................................................................................64.2 Analýza stavu STP síťového mostu na Linuxu.....................................................74.3 Testy volby kořenu stromu, blokovaných portů a ohodnocení linek....................84.3.1 Cíle testů........................................................................................................84.3.2 Schéma zapojení............................................................................................84.3.3 Testy s původními asymetrickými ohodnoceními linek...............................94.3.4 Testy s nastavenými symetrickými ohodnoceními linek..............................94.4 Testy nastavení priority portů.............................................................................104.4.1 Cíle testů......................................................................................................104.4.2 Schéma zapojení..........................................................................................104.4.3 Test 1: změny priorit na SW0, kořen stromu na SW0................................104.4.4 Test 2: změny priorit na SW0, na SW1 vypnuto STP.................................114.4.5 Test 3: změny priorit na SW0, kořen stromu na SW1................................114.4.6 Test 4: změny priorit na SW1, kořen stromu na SW1................................114.5 Testy času dosažení konvergovaného stavu.......................................................124.5.1 Cíle testů......................................................................................................124.5.2 Schéma zapojení..........................................................................................124.5.3 Test..............................................................................................................125 Testy RSTP.................................................................................................................135.1 Konfigurace RSTP na Linuxu.............................................................................135.2 Analýza stavu RSTP síťového mostu na Linuxu................................................14květen 2009 1/23

5.3 Testy volby kořenu stromu, blokovaných portů a ohodnocení linek..................155.3.1 Cíle testů......................................................................................................155.3.2 Schéma zapojení..........................................................................................155.3.3 Test..............................................................................................................155.4 Testy nastavení priority portů.............................................................................165.4.1 Test 1: změny priorit na SW0, kořen stromu na SW0................................165.4.2 Test 2: změny priorit na SW0, na SW1 vypnuto STP.................................165.4.3 Test 3: změny priorit na SW0, kořen stromu na SW1................................165.4.4 Test 4: změny priorit na SW1, kořen stromu na SW1................................165.5 Test vynucení verze STP a návratu do RSTP režimu.........................................175.6 Test nastavení délky prodlevy pro dosažení konvergovaného stavu..................175.7 Test nastavení „edge“ portu................................................................................175.8 Test nastavení „p2p“ portu..................................................................................175.9 Test vypnutí (R)STP na portu.............................................................................176 Testy GVRP................................................................................................................186.1 Implementace......................................................................................................186.2 Konfigurace GVRP na Linuxu............................................................................186.3 Základní funkčnost..............................................................................................186.3.1 Cíle testu......................................................................................................186.3.2 Schéma zapojení..........................................................................................186.3.3 Test..............................................................................................................186.4 Redundantní propojení směrovače a přepínače s použitím RSTP......................206.4.1 Schéma zapojení..........................................................................................206.4.2 Test..............................................................................................................206.5 Propustnost GVRP přes linuxový most s použitím RSTP..................................216.5.1 Schéma zapojení..........................................................................................216.5.2 Test..............................................................................................................217 Závěr...........................................................................................................................228 Použitá literatura.........................................................................................................23květen 2009 2/23

1 ÚvodPočítače v dnešní době dokáží plnit velkou spoustu úkolů. Množina úkolů, které dokáží zastat, jsouodvislé od nainstalovaných programů a operačního systému. Počítače s operačním systémem linuxovéhotypu dnes umí zastat různé činnosti – kancelářská práce, internetový server, síťový směrovač nebo vomezené míře také multimediální práce a počítačové hry. Mým úkolem v této práci je analyzovat možnostipoužití běžného počítače s operačním systémem Linux pro použití jako přepínač – provozovat funkcepř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čů aexistuje nějaká jejich implementace pro Linuxový operační systém. Při výběru protokolů pro test jejichimplementací 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ž implementacedosáhla jisté úrovně použitelnosti. Všechny testované protokoly se využívají v sítích dnes dominantníhoethernetové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šakdíky zvýšené inteligenci a jisté blízkosti fungování tento pojem volně zaměňuji za přepínač.květen 2009 3/23

4.2 Analýza stavu STP síťového mostu na LinuxuStav síťového mostu, jednotlivých portů a obecně celého STP procesu lze sledovat pomocí výpisu pozadání příkazu (pro most br0):brctl showstp br0Následuje výpis jako například tento:br0bridge id8000.00e07deb4ac9designated root 7000.001ee5bdacf5root port 1 path cost 200000max age 20.00 bridge max age 20.00hello time 2.00 bridge hello time 2.00forward delay 15.00 bridge forward delay 15.00ageing time 300.01hello timer 0.00 tcn timer 0.00topology change timer 0.00 gc timer 1.26flagseth1 (1)port id 8001 state forwardingdesignated root 7000.001ee5bdacf5 path cost 200000designated bridge 7000.001ee5bdacf5 message age timer 19.60designated port 8001 forward delay timer 0.00designated cost 0 hold timer 0.00flagseth2 (2)port id 8002 state blockingdesignated root 7000.001ee5bdacf5 path cost 200000designated bridge 8000.00226b37b5ac message age timer 18.57designated port 8001 forward delay timer 0.00designated cost 200000 hold timer 0.00flagsMezi 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í linek4.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, žepů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 SW0-SW2. 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čiSW1 a SW2 byla jediná v módu 1G (síťové karty v SW0 tento mód nepodporovaly), upravil jsem ručně totoohodnocení ručně na hodnotu pro 100M dle 802.1t, abych dosáhl jednotného ohodnocení pro všechny linkyvedoucí z Cisco přepínačů a test se zjednodušil (podobně by šlo zřejmě dosáhnout stejného výsledkuupravení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 linekPro 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éhomostu 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 zjistilnásledující stav kořenů stromů a blokovaných portů:SW0 prio SW1 prio SW2 prio kořen blokovaný port logvých 32768 32768 32768 SW2 SW1 směr SW0 stp_ 01.txtsw0 28672 32768 32768 SW0 SW1 směr SW2 stp_ 02.txtsw1 32768 28672 32768 SW1 SW2 směr SW0 stp_ 03.txtsw2 32768 32768 28672 SW2 SW1 směr SW0 stp_ 04.txtTabulka 1: výsledky testuZ tabulky 1 je zřejmé, že volba kořene stromu proběhla při rovnosti priorit podle nejnižší MAC adresy av 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í zCisco přepínačů), což lze považovat za správné.4.3.4 Testy s nastavenými symetrickými ohodnoceními linekV tomto testu jsem sjednotil ohodnocení všech linek na 200000 a provedl test znovu, na závěr jsemvyzkoušel pomocí změny ohodnocení linek ovlivnit zablokování portů – nastavil jsem mezi přepínači SW0 aSW2 ohodnocení na 100000.SW0 prio SW1 prio SW2 prio kořen blokovaný port logvých 32768 32768 32768 SW2 SW0 směr SW1 stp_ 05.txtsw0 28672 32768 32768 SW0 SW1 směr SW2sw1 32768 28672 32768 SW1 SW0 směr SW2sw2 32768 32768 28672 SW2 SW0 směr SW1 stp_ 06.txtuživ 32768 32768 28672 SW2 SW1 směr SW0 stp_ 07.txtTabulka 2: výsledky testuZ tabulky 2 je zřejmé, že volby kořene stromu proběhly v pořádku a ovlivnění blokovaného portu zapomocí 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řifyzické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 prioritv 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.2 Schéma zapojeníObrázek 2: schémazapojení4.4.3 Test 1: změny priorit na SW0, kořen stromu na SW0Při tomto testu jsem nastavil priority přepínačů tak, aby se stal linuxový most SW0 kořenem. Napřepínači SW1 je zapnuto STP, výchozí priority portů a ohodnocení linek. Cílem je určit, zda se zablokuje naSW1 správný port při manipulaci s prioritami na SW0.kořen blokovaný port SW0 prio port1 SW0 prio port2 logvých SW0 SW1 k portu 2 128 128port1 SW0 SW1 k portu 1 144 128 stp_ 08.txtport2 SW0 SW1 k portu 2 128 144 stp_ 09.txtTabulka 3: výsledky testuPorty 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 STPNa Cisco přepínači SW1 jsem deaktivoval STP a snažil se ovlivnit zablokovaný port na linuxovém mostuSW0, který se tímto stal také kořenem stromu.kořen blokovaný port SW0 prio port1 SW0 prio port2 Logvých SW0 SW0 port 2 128 128port1 SW0 SW0 port 1 144 128 stp_10.txtport2 SW0 SW0 port 2 128 144 stp_11.txtTabulka 4: výsledky testuPorty se zablokovaly správně – podle nastavení priorit na portech.4.4.5 Test 3: změny priorit na SW0, kořen stromu na SW1Na obou přepínačích bylo aktivováno STP, kořen stromu nastaven na SW1, změna priorit probíhala naSW0 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é.kořen blokovaný port SW0 prio port1 SW0 prio port2 logvých SW1 SW0 port 1 128 128port1 SW1 SW0 port 1 144 128 stp_12.txtport2 SW1 SW0 port 1 128 144 stp_13.txtTabulka 5: výsledky testuZmě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 SW1V 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.kořen blokovaný port SW1 směr port1 SW1 směr port2 logvých SW1 SW0 port 1 128 128port1 SW1 SW0 port 1 144 128 stp_14.txtport2 SW1 SW0 port 2 128 144 stp_15.txtTabulka 6: výsledky testuI 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 stavu4.5.1 Cíle testůNa závěr jsem se rozhodl otestovat, jak dlouho trvá přechod linuxového mostu do konvergovaného stavua tuto skutečnost ovlivnit pomocí nastavení prodlevy.4.5.2 Schéma zapojeníObrázek 3: schéma zapojení4.5.3 TestPo deaktivaci a opětovné aktivaci linuxovéhu mostu (ifconfig br0 down ; ifconfig br0 up) trval vevýchozím nastavení přechod do konvergovaného stavu 30 sekund, přičemž ve stavu „listening“ zůstal 15sekund 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. Pokudse linuxový most stane kořenem, ihned toto nastavení použije a začne se jim řídit. Po zdvojnásobení tohotointervalu oproti výchozímu stavu (na 30 sekund) zůstal most v každém („listening“ i „learning“) stavu 30sekund (správně).Tyto výsledky lze považovat za správné, nicméně jsem zjistil, že pokud přejde kořen stromu z linuxovéhomostu 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 RSTPPodobně jsem prováděl také testy implementace RSTP protokolu, nejdříve si opět ukažme, jak se RSTPna linuxových přepínačích konfigurují a jak lze zjistit stav síťového mostu a RSTP protokolu.5.1 Konfigurace RSTP na LinuxuPro vytvoření síťového mostu a zařazení rozhraní do něj se stále používá utilita brctl, proto postupvychází z konfigurace STP. Doporučuji ověřit, že jste na mostu neaktivovali STP. Teprve až před samotnýmuvedením mostu do běhu (ifconfig br0 up) doporučuji zapnout aplikaci rstpd a zapnout RSTP:rstpctl rstp br0 onNedodržením tohoto postupu se můžete dočkat nepříjemného překvapení v podobě vytvoření smyčky vsíti, která Vám spolehlivě dokáže i přetížit celý stroj a problém vyvrcholí většinou spoustou kernel oops aznefunkč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 32768Chceme-li změnit ohodnocení jednotlivých linek (zde nastavení ohodnocení 200000 pro eth1):rstpctl setportpathcost br0 eth1 200000Na 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 144Ekvivalentem setfd u utility brctl je u RSTP (zde pro 30 sekund):rstpctl setfdelay br0 30Vynutit použití staršího protokolu STP lze pomocí (hodnota „normal“ znamená RSTP):rstpctl setforcevers slowNastavení edge portu eth1:rstpctl setportedge br0 eth1 yes/noNastavení „p2p“ portu pro eth1:rstpctl setportp2p br0 eth1 yes/no/autoMožnost vypnutí (R)STP na portu na eth1:rstpctl setportnonstp br0 eth1 yes/noProvedení migračního testu – test možnosti přechodu STP na RSTP na portu eth1, na kterém zůstalypří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 eth1květen 2009 13/23

5.2 Analýza stavu RSTP síťového mostu na LinuxuStav síťového mostu, RSTP procesu a portu lze zobrazit pomocí dvojice příkazů:rstpctl showbridge br0rstpctl showportdetail br0První z příkazů provede výpis tohoto typu:Bridge: br0 State:enabledBridgeId: 8000­00e07deb4ac9 Bridge Proirity: 32768 (0x8000)Designated Root: 8000­001ee5bdacf5Root Port: 8001, Root Cost: 200000Time Since Topology Change: 1076Max Age: 20 Bridge Max Age: 20Hello Time: 2 Bridge Hello Time: 2Forward Delay: 15 Bridge Forward Delay: 15Hold Time: 3Zde vidíme úhrnné informace o mostu, priority přepínačů, čas od poslední změny topologie, portsměř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: 128State: Discarding Uptime: 1042PortPathCost: admin: Auto oper: 200000Point2Point: admin: Auto oper: YesEdge: admin: N oper: NPartner:oper: RapidPathCost: 200000Designated Root: 8000­001ee5bdacf5Designated Cost: 200000Designated Bridge: 8000­00226b37b5acDesignated Port: 8001Role:AlternatefdWhile: 15 rcvdInfoWhile: 5rbWhile: 0 rrWhile: 0RSTP BPDU rx: 203CONFIG BPDU rx: 0TCN BPDU rx: 0Tento 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í linek5.3.1 Cíle testůTest proběhl obdobně jako u testu STP, s výjimkou toho, že na linuxovém mostu již nebylo nutnovýchozí ohodnocení (200000) měnit, protože je již v souladu s ohodnoceními na přepínači Cisco. Opět jsemvšak ručně upravil ohodnocení propojky mezi přepínači SW1 a SW2 (jako u testů STP, viz. 4.3.1).5.3.2 Schéma zapojeníObrázek 4: schéma zapojení5.3.3 TestV ú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 SW2na 150000.SW0 prio SW1 prio SW2 prio kořen blokovaný port logvých 32768 32768 32768 SW2 SW0 směr SW1 rstp_01.txtsw0 28672 32768 32768 SW0 SW1 směr SW2 rstp_02.txtsw1 32768 28672 32768 SW1 SW0 směr SW2 rstp_03.txtsw2 32768 32768 28672 SW2 SW0 směr SW1 rstp_04.txtuživ 32768 32768 28672 SW2 SW1 směr SW0Tabulka 7: výsledku testuVš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 zcelashodně jako u STP, přikládám pouze tabulky s měřeními a odkazy na detailní diagnostické výpisyv přiložených souborech.5.4.1 Test 1: změny priorit na SW0, kořen stromu na SW0kořen blokovaný port SW0 prio port1 SW0 prio port2 logvých SW0 SW1 k portu 2 128 128port1 SW0 SW1 k portu 1 144 128 rstp_09.txtport2 SW0 SW1 k portu 2 128 144 rstp_10.txtTabulka 8: výsledky testu5.4.2 Test 2: změny priorit na SW0, na SW1 vypnuto STPV tomto testu stojí pouze za povšimnutí, že si linuxový most musel projít konvergenčním RSTP procesemo délce 30 sekund, protože nebylo možné aplikovat princip nabídky a potvrzení.kořen blokovaný port SW0 prio port1 SW0 prio port2 logvých SW0 SW0 port 2 128 128port1 SW0 SW0 port 1 144 128 rstp_11.txtport2 SW0 SW0 port 2 128 144 rstp_12.txtTabulka 9: výsledky testu5.4.3 Test 3: změny priorit na SW0, kořen stromu na SW1kořen blokovaný port SW0 prio port1 SW0 prio port2 logvých SW1 SW0 port 1 128 128port1 SW1 SW0 port 1 144 128 rstp_13.txtport2 SW1 SW0 port 1 128 144 rstp_14.txtTabulka 10: výsledku testu5.4.4 Test 4: změny priorit na SW1, kořen stromu na SW1kořen blokovaný port SW1 směr port1 SW1 směr port2 logvých SW1 SW0 port 1 128 128port1 SW1 SW0 port 1 144 128 rstp_15.txtport2 SW1 SW0 port 2 128 144 rstp_16.txtTabulka 11: výsledky testukvěten 2009 16/23

5.5 Test vynucení verze STP a návratu do RSTP režimuPomocí volby setforcevers jsem vyzkoušel přepnutí portu do STP režimu, který rovněž má aplikace rstpdimplementován. Ihned po přepnutí začaly přepínače indikovat použití staršího protokolu (detaily v souborurstp_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ělnapomoct tzv. migrační test (volba portmcheck). Zde však nemám přesný návod, jak tohoto přepnutí naRSTP dosáhnout, v různých případech pomohl rozdílný postup. Nicméně doporučuji zapnout migrační testzapnout nejdříve na Cisco přepínači a bezprostředně na linuxovém mostu, pokud se neustálí spojení naRSTP, 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 stavuDíky urychlujícím principům se mi v kruhovém zapojení (obrázek 4) podařilo dosáhnout konvergovanéhostavu při fyzickém odpojení kterékoliv linky z SW0 do cca 1 sekundy, při opětovném zapojení do cca 2-3sekund.V této situaci nemá smysl měnit prodlevu (setfdelay), proto jsem se rozhodl využít přepnutí do STPrež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 15sekund „learning“). Co však považuji za zarážející, je to, že při přechodu z „listening“ do „learning“ stavuprošla přes most testovací odezva (ping). Při opakování se toto však nepodařilo nasimulovat, avšak připodrobné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ž jsemupravil nastavení a most se jím stal, nastavení se dle diagnostických výpisů aktivovalo a most zůstalv 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 dataneprocházely.Výsledky tohoto testu považuji za alarmující.5.7 Test nastavení „edge“ portuOdpojil jsem páteřní kabel mezi linuxovým mostem a Cisco přepínačem a aktivoval na uvolněném portulinuxové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. souborrstp_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“ portuZnovu jsem odpojil páteřní kabel z jednoho portu linuxového mostu a na obou koncích původního spojejsem 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 portuNa vybraném portu linuxového mostu jsem vypnul používání (R)STP pomocí volby setportnonstp (utilityrstpctl) 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 GVRP6.1 ImplementaceV 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 sezí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 LinuxuNyní 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 150Povolíme jeho registraci prostřednictvím GVRP:ip link set eth2.150 type vlan gvrp on6.3 Základní funkčnost6.3.1 Cíle testuV tomto testu jsem otestoval základní funkčnost GVRP registrace používaných virtuálních sítí na Linuxudo přilehlého GVRP přepínače Cisco.6.3.2 Schéma zapojeníObrázek 5: schémazapojení6.3.3 TestPři aktivaci VLANu odešle jádro na segment sítě zprávu „Join in“ a při odebrání odesílá zprávu „LeaveEmpty“. 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 vneznač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):01­Jan­2000 01:05:55 %VLAN­I­GVRPAddVlan: Dynamic VLAN Vlan 150 was added byGVRP01­Jan­2000 01:05:55 %LINK­I­Up: Vlan 15001­Jan­2000 01:05:55 %VLAN­I­GVRPAddPort: Dynamic port g1 was added to VLANVlan 150 by GVRPVýpis po deaktivaci GVRP na rozhraní virtuální sítě (ip link set eth2.150 type vlan gvrp off):01­Jan­2000 01:06:50 %LINK­W­Down: Vlan 15001­Jan­2000 01:06:50 %VLAN­I­GVRPDelPort: Dynamic port g1 was removed fromVLAN Vlan 150 by GVRP01­Jan­2000 01:06:50 %VLAN­I­GVRPDelVlan: Dynamic VLAN Vlan 150 was removedby GVRPVirtuální síť je také korektně odregistrována v případě, kdy je rozhraní s virtuální sítí smazáno (vconfigrem 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 RSTP6.4.1 Schéma zapojeníObrázek 6: schéma zapojení6.4.2 TestV tomto testu (obrázek 6) jsem se rozhodl zařadit dvě síťové karty do jednoho síťového mostu a každousíťovou kartu (port mostu) připojit do stejné Cisco přepínače. Pro eliminaci smyčky sem použil protokolRSTP. Na Linuxu při vytvoření mostu vzniká nové rozhraní, na kterém lze přidávat virtuální sítě. Narozhraní mostu jsem tedy vytvořil rozhraní virtuální sítě 99 a zkusil ji prostřednictvím GVRP propagovatpř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řesblokovaný port GVRP zprávy neprošly. Při odpojení kabelu v aktivním propojení RSTP automatickyaktivoval 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:01­Jan­2000 01:56:30 %VLAN­I­GVRPAddPort: Dynamic port g8 was added to VLANVlan 99 by GVRP01­Jan­2000 01:56:36 %VLAN­I­GVRPDelPort: Dynamic port g1 was removed fromVLAN Vlan 99 by GVRPPokud se špatně sejde přepnutí portu a GVRP přeregistrace v reakci na „Leave all“ zprávu, může dojít ik celkové přeregistraci virtuální sítě:01­Jan­2000 01:53:49 %LINK­W­Down: Vlan 9901­Jan­2000 01:53:49 %VLAN­I­GVRPDelPort: Dynamic port g8 was removed fromVLAN Vlan 99 by GVRP01­Jan­2000 01:53:49 %VLAN­I­GVRPDelVlan: Dynamic VLAN Vlan 99 was removed byGVRP01:53:54 %VLAN­I­GVRPAddVlan: Dynamic VLAN Vlan 99 was added by GVRP01­Jan­2000 01:53:54 %LINK­I­Up: Vlan 9901­Jan­2000 01:53:54 %VLAN­I­GVRPAddPort: Dynamic port g1 was added to VLANVlan 99 by GVRPkvěten 2009 20/23

6.5 Propustnost GVRP přes linuxový most s použitím RSTP6.5.1 Schéma zapojeníObrázek 7: schéma zapojení6.5.2 TestV tomto testu (obrázek 7) jsem chtěl ověřit, zda se jsou schopny dva přepínače domlouvat GVRPzprávami, které procházejí přes linuxový most. Cílem je situace, kdy si přepínače na mostem propojenémsegmentu 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řeslinku, kterou RSTP aktuálně neblokuje.Samotné GARP rámce se odesílají na multicastovou MAC adresu a v jejich průchodnosti linuxovýmmostem 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ícmulticastový rámec se odesílá na všechny porty mostu, takže registrace do všech přepínačů proběhlav pořádku.Funkčnost jsem ověřil také v situacích, kdy jsem odpojoval postupně linky mezi přepínači za účelem, abybyly 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émsouboru gvrp_02.cap. Lze v něm velmi dobře vidět, jak každé z připojených zařízení registruje svojevirtuální sítě v reakci na zprávy „Leave all” obou přepínačů.květen 2009 21/23

7 ZávěrProvedené testy ukázaly, že ověřované implementace protokolů STP a RSTP pro eliminaci smyčekv redundantních přepínaných oblastech lze v omezené konfiguraci s výhradami použít. U STP se velmivzá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 sejedná 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 dopř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ý zWWW: .květen 2009 23/23