Technologie počítačových sítí Ověření přenosu multicastových rámců a rámců řídících protokolů PAgP a LACP pro agregaci linek do virtuálního svazku přes tunelované VLAN pomocí technologie 802.1QinQ Tomáš Kučera, kuc274 Jiří Mikošek, mik343
Obsah 1. Úvod 2. Základní pojmy 3. Multicasty 4. EtherChanell 5. Závěr Abstrakt Cílem tohoto projektu bylo ověřit, jak se chovají multicastové rámce při použití tunelování "QinQ". Druhá část popisuje, jak umožnit použití technologie EtherChannel v "tunelovaných VLAN". 1. Úvod Tento projekt navazuje na práci "Tunelování VLAN a servisních protokolů druhé vrstvy v síti poskytovatele" [1]. Z tohoto důvodu nebudeme podrobně popisovat "technologii tunelování" jako takovou, protože je podrobně popsána v uvedeném projektu. Přesto alespoň připomeneme pár základních pojmů. Pak se zaměříme na konkrétní problémy, na něž jsme hledali řešení. 2. Několik základních pojmů VLAN Virtuální sítě - tyto sítě jsou od sebe odděleny pouze logicky, fyzicky mohou být realizovány na stejném zařízení (přepínači). Ne všechny přepínače jsou ale schopny virtuální sítě podporovat. IEEE 802.1Q Norma, která specifikuje mimo jiné formát rámce procházejícího trunk portem. Rámec je rozšířen o 4B. Ty obsahují informaci, že jde o rámec protokolu 802.1Q, dále informace o VLAN, do kterého rámec patří, volitelně ještě další informace. Starší alternativou IEEE 802.1Q bylo ISL, což je formát firmy CISCO. Dnes už se na nových zařízeních téměř nepoužívá. Access port Režim portu přepínače, který slouží pro připojení koncového zařízení. Tomuto portu může být nastavena příslušnost k jednomé konkrétní VLAN. Zařízení připojené k takovému portu pak nemůže komunikovat s nikým jiným, než s prvky své vlastní VLAN. Trunk port Režim portu, který umožňuje spojit dva přepínače, na kterých jsou provozovány VLAN, jedinou linkou tak, aby rámce po průchodu portem neztratily svoji původní příslušnost k VLAN. Spojit přepínače bychom mohli samozřejmě i pro každý VLAN zvlášť (zvláštní linkou), je ale jasné, že při větším počtu VLAN by to nebyl efektivní postup. Režim "dot1q-tunnel" Speciální režim portu, podporovaný pouze některými přepínači. Tento režim očekává, že na druhé straně linky je port nakonfigurován do režimu trunk. Trunk posílá rámce tagované podle normy 802.1Q. Port v režimu dot1q-tunnel nechá rámce takto označené a navíc si je zařadí do své vlastní VLAN (podle toho, do jaké VLAN je tento port přiřazen). Tunelování VLAN
Tunelování je technologie umožňující přenos rámců určité VLAN přes jinou síť, která může také používat VLAN. Po průchodu touto sítí musí být rámec správně doručen v rámci cílové sítě, to znamená - musí být zachována jeho vlastní příslušnost k VLAN. Příklad použití technologie tunelování Jelikož tato práce navazuje na projekt "Tunelování VLAN a servisních protokolů druhé vrstvy v síti poskytovatele" [1], budeme se držet i jejich ukázkového příkladu. Jde o firmu se dvěma pobočkami, jejichž spojení na druhé vrstvě OSI modelu zajišťuje jiná firma - označená jako poskytovatel. Zákaznická firma používá VLAN. Poskytovatel by rád také používal VLAN, konkrétně za účelem oddělení sítí jednotlivých zákazníků. Nemohlo by se pak stát, že by dva různí zákazníci měli navzájem přístup do svých soukromých sítí. Bez použití technologie tunelování by to však prakticky nebylo možné. Poskytovatel by nebyl schopen odlišit VLAN různých zákazníků, pokud by si je například očíslovali stejně. obr. 1: Testované zapojení realizující tunelování Jak situaci vyřešíme pomocí tunelování VLAN, je vidět z obrázku 1 (převzato z projektu [1]). Na něm jsou 4 přepínače. Horní dva (označené číslem 3550) jsou zařízení poskytovatele. Porty s číslem jedna jsou přiřazeny do VLAN 3 a jsou v režimu "dot1q-tunnel". Porty s číslem 5 jsou v režimu trunk. Druhé dva přepínače jsou od zákazníka. Tato zařízení nemusí o technologii tunelování "nic vědět". Stačí pouze porty vedoucí směrem k poskytovateli, což je z pohledu zákazníka port do switche v jeho druhé pobočce, nastavit do režimu trunk.
3. Multicasty Prvním cílem našeho projektu je ověřit, zda tato technologie nebrání nebo nějak neomezuje vysílání multicastových rámců v sítích zákazníků. K ověření jsme použili zapojení podle obrázku 2. obr. 2: schéma zapojení pro ověření propustnosti multicastových rámců Ke SW1 jsme připojili router, na kterém jsme spustili RIPv2, jako zdroj multicastových rámců. Ke SW2 jsme připojili stanici, kde běžel softwarový packetový analyzátor (Ethereal). Na něm bylo možno sledovat, že rámce přicházejí skutečně "nezměněné", tedy MAC adresa (a samozřejmě i IP adresa) zůstala nezměněna. První závěr tedy zní: Technologie tunelování QinQ nemá na multicastové rámce žádný vliv. 4. Řídící protokoly LACP a PAgP pro spojování linek do svazku Druhým úkolem bylo zjistit, jak může firma poskytovatele umožnit zákazníkům využívat technologii EtherChannel, tedy spojování fyzických linek do jednoho virtuálního svazku. Virtuální svazek umožní sečíst kapacity fyzických linek a zajistit tím vyšší přenosovou rychlost. Tato technologie byla řešena u CISCO zařízení nejdříve jejich vlastním proprietárním protokolem PAgP (Port Aggregation Protokol). Později přidali možnost používat standardizovaný protokol LACP (Link Aggregation Control Protokol). Dnes máme tedy u novějších CISCO přepínačů na výběr z těchto dvou protokolů.
Máme-li zapojení podle obr. 3, není ještě možné EtherChannel využít. Zákazníkovy přepínače (2950) totiž poznají, že je mezi nimi další zařízení, které není nakonfigurováno pro EtherChannel, a proto nejsou schopny EtherChannel zřídit. Výsledkem je vyblokování některých portů pomocí protokolu spanning tree. obr. 3: Fyzické zapojení neboli pohled poskytovatele Řešením je na přepínači poskytovatele (na konkrétních rozhraních vedoucích k přepínačům zákazníka) použít příkaz l2protocol-tunnel point-to-point [pagp lacp] Ten zajistí, že přes přepínače poskytovatele budou řídící protokoly přenášeny a jeho zařízení pro zákazníka "nebudou viditelná". Z pohledu zákazníka jsou přepínače SW1 a SW2 na obrázku 4 propojeny pouze fyzickými linkami.
obr. 4: Logický pohled neboli pohled zákazníka Když zadáme příkaz l2protocol-tunnel point-to-point bez parametrů, budou automaticky doplněny všechny paramatry (pagp, lacp, udld). Když bude zadán např. pouze parametr pagp, bude tunelován pouze protokol PAgP. Pomocí příkazu switchport mode [auto desirable passive active] na přepínači zakazníka navolíme módy portu pro Etherchannel pro PAgP: auto, desirable pro LACP: passive, active Aby byl Etherchannel funkční, je nutné mít alespoň jeden port v tvz. aktivním stavu, tedy buď auto, nebo v případě LACP active. Podrobnější informace lze nalézt v projektu [2]. Konfigurace switche 3550 poskytovatel podle obr. 3 interface FastEthernet0/1 switchport access vlan 4 l2protocol-tunnel point-to-point Konfigurace switchů 2950 - zákazník interface FastEthernet0/1 channel-group 1 mode active
interface FastEthernet0/2 channel-group 1 mode active Klíčové slovo active znamená, že EtherChannel bude používat protokol LACP a na tomto přepínači bude v aktivním stavu. Druhý zákazníkův přepínač může být nakonfigurován stejně, případně může být nastaven do pasivního režimu (použitím klíčového slova passive). Obdobně bychom postupovali i při použití PAgP viz projekt [2]. Ověření funkčnosti EtherChannelu Abychom ověřili, že EtherChannel je skutečně správně vytvořen, testovali jsme mimo jiné jeho propustnost. K oběma přepínačům zákazníka jsme připojili dvě koncové stanice. (Celkem tedy čtyři.) Na stanicích jsme spustili utilitu iperf, která dokáže zjistit propustnost linky. Test jsme spustili tak, aby spolu komunikovaly vždy vzdálene stanice. (Doprava tedy musela přes EtherChannel.) Zjistili jsme, že celková propustnost EtherChannelu je skoro 200 Mbps, což je součet skutečných fyzických rychlostí námi použitých linek. (Používali jsme pro něj dvě linky o rychlosti 100 Mbps.) EtherChannel je samozřejmě možné použít i pro 3 a více fyzických linek. My jsme reálně ověřili funkčnost EtherChannelu sestaveného ze tří fyzických linek. 5. Závěr Ověřili jsme, že technologie tunelování nemá na multicastové rámce žádný vliv. Toto jsme odzkoušeli pomocí protokolu RIPv2 a packetového analyzátoru. Dále jsme nakonfigurovali přepínače tak, aby byly schopny přes tunelované VLAN přenášet rámce řídících protokolů LACP a PAgP a otestovali jsme propustnost sestaveného EtherChannelu. Literatura: 1) Gaura, J., Vavříček, J. : Tunelování VLAN a servisních protokolů 2. vrstvy v síti poskytovatele - semestrální projekt do SPS 2) Jeníček, P., Milata, M. : EtherChannel 802.3ad
Příloha A: Konfigurace přepínače poskytovatele interface FastEthernet0/1 switchport access vlan 4 l2protocol-tunnel point-to-point pagp l2protocol-tunnel point-to-point lacp l2protocol-tunnel point-to-point udld interface FastEthernet0/2 switchport access vlan 5 l2protocol-tunnel point-to-point pagp l2protocol-tunnel point-to-point lacp l2protocol-tunnel point-to-point udld interface FastEthernet0/3 switchport access vlan 5 l2protocol-tunnel point-to-point pagp l2protocol-tunnel point-to-point lacp l2protocol-tunnel point-to-point udld interface FastEthernet0/4 switchport access vlan 4 l2protocol-tunnel point-to-point pagp l2protocol-tunnel point-to-point lacp l2protocol-tunnel point-to-point udld
Příloha B: Konfigurace přepínače zákazníka interface Port-channel1 flowcontrol send off interface FastEthernet0/1 channel-group 1 mode auto interface FastEthernet0/2 channel-group 2 mode auto