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

Transkript

1 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 Vybrané protokoly Spanning tree protocol (STP) Rapid spanning tree protocol (RSTP) GARP VLAN registration protocol (GVRP) Použitá zařízení a programové vybavení Počítač Hardware Software Přepínače Testy STP Konfigurace STP na Linuxu Analýza stavu STP síťového mostu na Linuxu Testy volby kořenu stromu, blokovaných portů a ohodnocení linek Cíle testů Schéma zapojení Testy s původními asymetrickými ohodnoceními linek Testy s nastavenými symetrickými ohodnoceními linek Testy nastavení priority portů Cíle testů Schéma zapojení Test 1: změny priorit na SW0, kořen stromu na SW Test 2: změny priorit na SW0, na SW1 vypnuto STP Test 3: změny priorit na SW0, kořen stromu na SW Test 4: změny priorit na SW1, kořen stromu na SW Testy času dosažení konvergovaného stavu Cíle testů Schéma zapojení Test Testy RSTP Konfigurace RSTP na Linuxu Analýza stavu RSTP síťového mostu na Linuxu...14 květen /23

2 5.3 Testy volby kořenu stromu, blokovaných portů a ohodnocení linek Cíle testů Schéma zapojení Test Testy nastavení priority portů Test 1: změny priorit na SW0, kořen stromu na SW Test 2: změny priorit na SW0, na SW1 vypnuto STP Test 3: změny priorit na SW0, kořen stromu na SW Test 4: změny priorit na SW1, kořen stromu na SW Test vynucení verze STP a návratu do RSTP režimu Test nastavení délky prodlevy pro dosažení konvergovaného stavu Test nastavení edge portu Test nastavení p2p portu Test vypnutí (R)STP na portu Testy GVRP Implementace Konfigurace GVRP na Linuxu Základní funkčnost Cíle testu Schéma zapojení Test Redundantní propojení směrovače a přepínače s použitím RSTP Schéma zapojení Test Propustnost GVRP přes linuxový most s použitím RSTP Schéma zapojení Test Závěr Použitá literatura...23 květen /23

3 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 /23

4 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 utils 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 w. 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 bridge 2, 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 květen /23

5 3 Použitá zařízení a programové vybavení 3.1 Počítač 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 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 , test GVRP vyžadoval instalaci novějšího jádra, minimálně , proto jsem zkompiloval aktuální jádro 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 Zdrojové kódy aplikací pro test RSTP jsem stáhnul z GIT repozitáře 4, 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 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 /23

6 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 br Chceme-li změnit ohodnocení jednotlivých linek (zde nastavení ohodnocení pro eth1): brctl setpathcost br0 eth 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 /23

7 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 e07deb4ac9 designated root ee5bdacf5 root port 1 path cost max age bridge max age hello time 2.00 bridge hello time 2.00 forward delay bridge forward delay ageing time 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 ee5bdacf5 path cost designated bridge ee5bdacf5 message age timer 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 ee5bdacf5 path cost designated bridge b37b5ac message age timer designated port 8001 forward delay timer 0.00 designated cost 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 ( e07deb4ac9), složenou z priority mostu a MAC adresy identifikace přepínače, který se stal kořenem stromu ( ee5bdacf5) 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ě ) květen /23

8 4.3 Testy volby kořenu stromu, blokovaných portů a ohodnocení linek 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) Schéma zapojení Obrázek 1: schéma zapojení květen /23

9 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 ). Všechny porty linuxového mostu byly tedy ohodnoceny 19 dle normy 802.1d a všechny aktivní porty přepínačů 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ů: SW0 prio SW1 prio SW2 prio kořen blokovaný port log vých SW2 SW1 směr SW0 stp_ 01.txt sw SW0 SW1 směr SW2 stp_ 02.txt sw SW1 SW2 směr SW0 stp_ 03.txt sw SW2 SW1 směr SW0 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é Testy s nastavenými symetrickými ohodnoceními linek V tomto testu jsem sjednotil ohodnocení všech linek na 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 SW0 prio SW1 prio SW2 prio kořen blokovaný port log vých SW2 SW0 směr SW1 stp_ 05.txt sw SW0 SW1 směr SW2 sw SW1 SW0 směr SW2 sw SW2 SW0 směr SW1 stp_ 06.txt uživ SW2 SW1 směr SW0 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 /23

10 4.4 Testy nastavení priority portů 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í Schéma zapojení Obrázek 2: schéma zapojení 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 port1 SW0 SW1 k portu stp_ 08.txt port2 SW0 SW1 k portu stp_ 09.txt Tabulka 3: výsledky testu Porty se zablokovaly správně podle nastavení priorit na portech SW0. květen /23

11 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. kořen blokovaný port SW0 prio port1 SW0 prio port2 Log vých SW0 SW0 port port1 SW0 SW0 port stp_10.txt port2 SW0 SW0 port stp_11.txt Tabulka 4: výsledky testu Porty se zablokovaly správně podle nastavení priorit na portech 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é. kořen blokovaný port SW0 prio port1 SW0 prio port2 log vých SW1 SW0 port port1 SW1 SW0 port stp_12.txt port2 SW1 SW0 port 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 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. kořen blokovaný port SW1 směr port1 SW1 směr port2 log vých SW1 SW0 port port1 SW1 SW0 port stp_14.txt port2 SW1 SW0 port 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 /23

12 4.5 Testy času dosažení konvergovaného stavu 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 Schéma zapojení Obrázek 3: schéma zapojení 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 /23

13 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 br Chceme-li změnit ohodnocení jednotlivých linek (zde nastavení ohodnocení pro eth1): rstpctl setportpathcost br0 eth 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 /23

14 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: e07deb4ac9 Bridge Proirity: (0x8000) Designated Root: ee5bdacf5 Root Port: 8001, Root Cost: 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: Point2Point: admin: Auto oper: Yes Edge: admin: N oper: N Partner: oper: Rapid PathCost: Designated Root: ee5bdacf5 Designated Cost: Designated Bridge: b37b5ac 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 /23

15 5.3 Testy volby kořenu stromu, blokovaných portů a ohodnocení linek 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 ) Schéma zapojení Obrázek 4: schéma zapojení 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 SW0 prio SW1 prio SW2 prio kořen blokovaný port log vých SW2 SW0 směr SW1 rstp_01.txt sw SW0 SW1 směr SW2 rstp_02.txt sw SW1 SW0 směr SW2 rstp_03.txt sw SW2 SW0 směr SW1 rstp_04.txt uživ SW2 SW1 směr SW0 Tabulka 7: výsledku testu Všechny testy dopadly dle očekávání. květen /23

16 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 Test 1: změny priorit na SW0, kořen stromu na SW0 kořen blokovaný port SW0 prio port1 SW0 prio port2 log vých SW0 SW1 k portu port1 SW0 SW1 k portu rstp_09.txt port2 SW0 SW1 k portu rstp_10.txt Tabulka 8: výsledky testu 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í. kořen blokovaný port SW0 prio port1 SW0 prio port2 log vých SW0 SW0 port port1 SW0 SW0 port rstp_11.txt port2 SW0 SW0 port rstp_12.txt Tabulka 9: výsledky testu Test 3: změny priorit na SW0, kořen stromu na SW1 kořen blokovaný port SW0 prio port1 SW0 prio port2 log vých SW1 SW0 port port1 SW1 SW0 port rstp_13.txt port2 SW1 SW0 port rstp_14.txt Tabulka 10: výsledku testu Test 4: změny priorit na SW1, kořen stromu na SW1 kořen blokovaný port SW1 směr port1 SW1 směr port2 log vých SW1 SW0 port port1 SW1 SW0 port rstp_15.txt port2 SW1 SW0 port rstp_16.txt Tabulka 11: výsledky testu květen /23

17 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 /23

18 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 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 Schéma zapojení Obrázek 5: schéma zapojení 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 /23

19 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 :05:55 %VLAN I GVRPAddVlan: Dynamic VLAN Vlan 150 was added by GVRP 01 Jan :05:55 %LINK I Up: Vlan Jan :05:55 %VLAN I GVRPAddPort: 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): 01 Jan :06:50 %LINK W Down: Vlan Jan :06:50 %VLAN I GVRPDelPort: Dynamic port g1 was removed from VLAN Vlan 150 by GVRP 01 Jan :06:50 %VLAN I GVRPDelVlan: 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 /23

20 6.4 Redundantní propojení směrovače a přepínače s použitím RSTP Schéma zapojení Obrázek 6: schéma zapojení 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: 01 Jan :56:30 %VLAN I GVRPAddPort: Dynamic port g8 was added to VLAN Vlan 99 by GVRP 01 Jan :56:36 %VLAN I GVRPDelPort: 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ě: 01 Jan :53:49 %LINK W Down: Vlan Jan :53:49 %VLAN I GVRPDelPort: Dynamic port g8 was removed from VLAN Vlan 99 by GVRP 01 Jan :53:49 %VLAN I GVRPDelVlan: Dynamic VLAN Vlan 99 was removed by GVRP 01:53:54 %VLAN I GVRPAddVlan: Dynamic VLAN Vlan 99 was added by GVRP 01 Jan :53:54 %LINK I Up: Vlan Jan :53:54 %VLAN I GVRPAddPort: Dynamic port g1 was added to VLAN Vlan 99 by GVRP květen /23

21 6.5 Propustnost GVRP přes linuxový most s použitím RSTP Schéma zapojení Obrázek 7: schéma zapojení 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 /23

22 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 /23

23 8 Použitá literatura [1] Net:Bridge [online] [cit ]. Dostupný z WWW: < en/net:bridge>. [2] Spanning tree protocol [online] [cit ]. Dostupný z WWW: < [3] Multiple Registration Protocol [online] [cit ]. Dostupný z WWW: < [4] Understanding Spanning-Tree Protocol [online] [cit ]. Dostupný z WWW: < 2/stpapp.htm>. [5] Understanding Rapid Spanning Tree Protocol (802.1w) [online]. Oct 24, 2006 [cit ]. Dostupný z WWW: < [6] Tutorial on VLANs: Part 2 [online]. VIII 12, 2004 [cit ]. Dostupný z WWW: < [7] Protocol GVRP [online]. [cit ]. Dostupný z WWW: < [8] Generic VLAN Registration Protocol (GVRP) [online] [cit ]. Dostupný z WWW: < květen /23