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 ÚvodPočí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=summary3 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 HardwarePro 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 SoftwareNainstaloval 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čePouž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

http://sps.lukas-kuna.cz/rstp-patches/

4 Testy STPProvedl 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 LinuxuPomocí 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 eth1brctl addif br0 eth2

Aktivujeme síťové karty a zapneme u nich promiskuitní režim (vyžadován pro korektní běh):ifconfig eth1 up promiscifconfig 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 LinuxuStav 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 br0Ná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 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č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í

květen 2009 8/23

Obrázek 1: schéma zapojení

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é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ů:

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 linekV 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.

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

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.txt

Tabulka 1: výsledky testu

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.txt


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 SW0Př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.

Porty se zablokovaly správně – podle nastavení priorit na portech SW0.

květen 2009 10/23


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


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 mostu

SW0, který se tímto stal také kořenem stromu.

Porty 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 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é.

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 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.

I zde proběhla volba blokovaného portu v pořádku – podle priorit na SW1.

květen 2009 11/23

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.txt


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.txt


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.txt


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 TestPo 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 RSTPPodobně 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 LinuxuPro 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 onNedodrž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 LinuxuStav síťového mostu, RSTP procesu a portu lze zobrazit pomocí dvojice příkazů:rstpctl showbridge br0rstpctl showportdetail br0

První z příkazů provede výpis tohoto typu:

Bridge: br0 State:enabledBridgeId: 800000e07deb4ac9 Bridge Proirity: 32768 (0x8000)Designated Root: 8000001ee5bdacf5Root 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: 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: 128State: Discarding Uptime: 1042PortPathCost: admin: Auto oper: 200000Point2Point: admin: Auto oper: YesEdge: admin: N oper: NPartner: oper: RapidPathCost: 200000Designated Root: 8000001ee5bdacf5Designated Cost: 200000Designated Bridge: 800000226b37b5acDesignated Port: 8001Role: AlternatefdWhile: 15 rcvdInfoWhile: 5rbWhile: 0 rrWhile: 0RSTP BPDU rx: 203CONFIG BPDU rx: 0TCN 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 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 SW2 na 150000.

Všechny testy dopadly dle očekávání.

květen 2009 15/23


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 SW0

Tabulka 7: výsledku testu

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

5.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 procesem

o délce 30 sekund, protože nebylo možné aplikovat princip nabídky a potvrzení.



květen 2009 16/23

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 rstp_09.txtport2 SW0 SW1 k portu 2 128 144 rstp_10.txt


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.txt


koř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.txt

Tabulka 10: výsledku testu

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 rstp_15.txtport2 SW1 SW0 port 2 128 144 rstp_16.txt


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 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 stavuDí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“ portuOdpojil 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“ portuZnovu 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 portuNa 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 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 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 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 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 testuV 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 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 „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

GVRP01Jan2000 01:05:55 %LINKIUp: Vlan 15001Jan2000 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 15001Jan2000 01:06:50 %VLANIGVRPDelPort: Dynamic port g1 was removed from

VLAN Vlan 150 by GVRP01Jan2000 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.2 TestV 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 GVRP01Jan2000 01:56:36 %VLANIGVRPDelPort: Dynamic port g1 was removed from

VLAN 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 i

k celkové přeregistraci virtuální sítě:01Jan2000 01:53:49 %LINKWDown: Vlan 9901Jan2000 01:53:49 %VLANIGVRPDelPort: Dynamic port g8 was removed from

VLAN Vlan 99 by GVRP01Jan2000 01:53:49 %VLANIGVRPDelVlan: Dynamic VLAN Vlan 99 was removed by

GVRP01:53:54 %VLANIGVRPAddVlan: Dynamic VLAN Vlan 99 was added by GVRP01Jan2000 01:53:54 %LINKIUp: Vlan 9901Jan2000 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.2 TestV 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ěrProvedené 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: <http://www.linuxfoundation.org/

en/Net:Bridge>.[2] Spanning tree protocol [online]. 2002 [cit. 2009-05-03]. Dostupný z WWW:

<http://en.wikipedia.org/wiki/Spanning_tree_protocol>.[3] Multiple Registration Protocol [online]. 2005 [cit. 2009-05-03]. Dostupný z WWW:

<http://en.wikipedia.org/wiki/Multiple_Registration_Protocol>.[4] Understanding Spanning-Tree Protocol [online]. 1989-1997 [cit. 2009-05-03]. Dostupný z WWW:

<http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/sw_ntman/cwsimain/cwsi2/cwsiug2/vlan2/stpapp.htm>.

[5] Understanding Rapid Spanning Tree Protocol (802.1w) [online]. Oct 24, 2006 [cit. 2009-05-03]. Dostupný z WWW: <http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml>.

[6] Tutorial on VLANs: Part 2 [online]. VIII 12, 2004 [cit. 2009-06-03]. Dostupný z WWW: <http://www.commsdesign.com/showArticle.jhtml?articleID=26806955>.

[7] Protocol GVRP [online]. [cit. 2009-05-03]. Dostupný z WWW: <http://www.javvin.com/protocolGVRP.html>.

[8] Generic VLAN Registration Protocol (GVRP) [online]. 2003 [cit. 2009-05-03]. Dostupný z WWW: <http://www.daxnetworks.com/Technology/TechDost/TD-092805.pdf>.

květen 2009 23/23

průzkum implementací stp, rstp a gvrp na linuxu

Documents