hledat:

5.6  Testování a ověřování kompatibility prvků páteřní sítě

Cílem práce tohoto projektu je určit a ověřit možnosti a podmínky pro vzájemnou spolupráci zařízení a programového vybavení různých výrobců. Poznatky při testování se stávají výchozím stavem pro další spolupracující skupiny a jedním z podkladů při výběrových řízeních. V roce 1999 jsme se zaměřili na schopnost spolupráce LAN přepínačů s protokolem 802.1q a 802.1p, schopnost ATM přepínačů zajistit potřebnou kvalitu služeb pro přenos emulovaných E1 okruhů a výběr verze IOS směrovačů firmy Cisco Systems pro používané aplikace.

Kompatibilita protokolů 802.1q a 802.1p v LAN přepínačích

V Ostravě jsme testovali spolupráci LAN přepínačů při použití trunku s protokolem 802.1q a nastavení QoS protokolu 802.1p. Pro testy byla zapůjčena technika ČVUT Praha, MU Brno, VUT Brno a VŠB-TU Ostrava.

K dispozici jsme měli tyto přepínače:

• Accelar 1200 firmy Nortel Networks
• Accelar 1100 firmy Nortel Networks
• BayStack 450 firmy Bay Networks
• Summit 48 firmy Extreme Networks
• Catalyst 5500 firmy Cisco Systems
• Catalyst 2924 XL firmy Cisco Systems

Testování probíhalo postupným propojením trunků mezi jednotlivými přepínači a měřením průchodnosti. Zátež byla generována programem netperf ze čtyř počítačů s rozhraními Fast Ethernet připojených do dvou virtuálních sítí (VLAN) na obou přepínačích. Při měření průchodnosti byly zjištěny pouze minimální rozdíly a hodnoty se pohybovaly od 93,5 Mb/s do 94,5 Mb/s.

Při těchto testech jsme ověřili, že všechna zkoumaná zařízení navzájem spolupracují bez problémů.

Zařízení firmy Cisco však vykazují jistá omezení. Norma 802.1q umožňuje použít pro VLAN identifikační číslo od 1 do 4095. Přepínače Catalyst však podporují pouze hodnoty 1 až 1000. Toto omezení je důsledkem kompatibility se soukromým protokolem firmy Cisco Inter-Switch Link (ISL).

U řad Catalyst 5000 a Catalyst 6000 lze vyšší identifikační číslo přemapovat na nižší - například

set vlan mapping dot1q 3001 isl 701

Nižší řada Catalyst 2900XL však tuto možnost zatím nenabízí.

Na druhou stranu zařízení firmy Cisco podstatným způsobem rozšiřuje použití spanning tree. Norma definuje používání jediné instance STP pro všechny virtuální sítě. Při použití redundantních L2 spojů pak není možné rozložit zátěž na více linek a záložní trasy se použijí pouze v případě poruchy. U přepínačů Catalyst lze nastavit různé parametry spanning tree pro různé virtuální sítě a redundantní spoje využít ke statickému rozložení zátěže.

Při konfiguraci jsme také narazili na problém s odlišným názvoslovím používaným firmou Cisco. U všech ostatních výrobců jsou používány pojmy značkovaná (tagged) a neznačkovaná virtuální síť. V trunku musí být všechny sítě značkovány a všechny pakety, které neobsahují značku, jsou přiřazeny do implicitní (neznačkované) virtuální sítě. U přepínačů firmy Cisco se tyto pojmy nepoužívají a funkci neznačkované sítě plní virtuální síť označovaná jako nativní.

Při použití trunku s protokolem 802.1q mezi přepínači různých výrobců se jako nejvýhodnější jeví nastavit jako neznačkovanou (nativní) virtuální síť nepoužívanou síť. Všechny virtuální sítě, které jsou používány pro přenos dat, by měly být značkovány.

Při použití trunků, ať už na bázi Ethernetu (802.1q nebo ISL) nebo ATM, se mohou vyskytnout problémy při napojení na starší přepínače, které sice podporují více virtuálních sítí, ale mají pouze jedinou tabulku MAC adres bez informace o příslušnosti k síti. Typickým příkladem je poměrně rozšířený SuperStack 1000 firmy 3Com. V případě, že se tomuto přepínači v tabulkách vyskytne stejná MAC adresa v různých virtuálních sítích, začne docházet ke střídavému přepínání zhruba po 5 vteřinách a tím k výpadkům v komunikaci.

Na směrovačích firmy Cisco jsou MAC adresy všech podrozhraní shodné s MAC adresou hlavního rozhraní a nedají se změnit. Při kombinaci s přepínači s jedinou tabulkou adres je však nutné zajistit jedinečnost MAC adres i na rozhraních. V tomto případě je patrně jediná možnost použití BVI (bridge virtual interface), u kterého je možné nastavit libovolnou mac adresu.

Běžná konfigurace:

...
!
interface FastEthernet 0/0.5
  description Statni vedecka knihovna
  ip address 194.212.41.33 255.255.255.224
  encapsulation dot1Q 5
!
interface FastEthernet 0/0.6
  description Arcibiskupstvi
  ip address 194.108.49.37 255.255.255.252
  encapsulation dot1Q 6
!
...

není funkční a musí se změnit takto:

...
bridge irb
...
!
interface FastEthernet 0/0.5
  description Statni vedecka knihovna
  encapsulation dot1Q 5
  bridge-group 5
!
interface FastEthernet 0/0.6
  description Arcibiskupstvi
  encapsulation dot1Q 6
  bridge-group 6
!
...
!
interface BVI5
  description Statni vedecka knihovna
  mac-address 00e0.ffff.0005
  ip address 194.212.41.33 255.255.255.224
!
interface BVI6
  description Arcibiskupstvi
  mac-address 00e0.ffff.0006
  ip address 194.108.49.37 255.255.255.252
!
...
!
bridge 5 protocol ieee
  bridge 5 route ip
bridge 6 protocol ieee
  bridge 6 route ip
!
...

Přes všechny zmíněné odchylky v implementaci protokolů komunikovala všechna použitá zařízení bez nejmenších problémů a v případě, že se použijí identifikační čísla do 1000 (což v praxi úplně postačuje) nic nebrání jakékoliv kombinaci testovaných zařízení.

Zároveň s testováním kompatibility trunků s protokolem 802.1q bylo naplánováno testovat i kompatibilitu QoS a protokolu 802.1p. V době testování měl tento protokol každý výrobce implementován jinak. Čtyři různé priority se označují hodnotami od 0 do 7. Jeden výrobce používal sudé hodnoty, druhý liché a na zařízeních Cisco nebyly implementovány vůbec. Postupem času byly pro všechna zařízení vyvinuty nové verze software, které tyto problémy řeší. Plánujeme další kolo testů, které by přineslo nové poznatky.

Kompatibilita ATM přepínačů pro provoz pobočkových ústředen

V Brně je budována optokabelová síť, která propojuje všechny významné lokality brněnských vysokých škol. Tato síť byla od počátku stavěna jako datová síť s použitím ATM přepínačů Centillion 100 (C 100) a 5000BH firmy BayNetworks. Nyní se však uvažuje o vzájemném propojení pobočkových ústředen jednotlivých fakult a případně i napojení na ústředny vysokých škol v jiných městech. Protože v síti TEN-155 CZ jsou použity ATM přepínače Cisco LS1010, bylo potřeba ověřit možnost spolupráce těchto zařízení pro požadované služby.

Ve spolupráci Ústavu telekomunikací fakulty elektrotechniky a informatiky VUT a Ústavu výpočetní techniky Masarykovy univerzity byly provedeny experimenty s úkolem ověřit reálné vlastnosti přenosových tras pro přenos hlasových služeb.

Pro vzájemné propojování pobočkových ústředen se zpravidla využívají datové okruhy E1. Proto se experimenty soutředily hlavně na testování permanentího virtuálního okruhu 2 Mb/s. Tímto okruhem byla propojena dvě přenosová zařízení PCM30U. Protože na použitých zařízeních od firmy BayNetworks neexistují moduly pro emulaci E1 okruhů, byly pro připojení přenosových zařízení PCM30U použity pouze ATM přepínače LS1010. Přenosová trasa mezi nimi obsahovala tři přepínače C100 a dva přepínače 5000BH. Kromě běžného provozu byla navíc generována zátěž pomocí analyzátoru HP Internet Advisor, připojeného k jednomu z přepínačů C100.

Na této trase bylo provedeno měření vlastností emulovaného E1 okruhu podle doporučení ITU-T G.821 a G.826. Dále jsme měřili jitter toleranci a přenosovou funkci jitteru dle doporučení ITU-T G.823. Při testech s použitím měřící techniky HP 37717 nebyly pozorovány žádné bitové chyby, zpoždění ani jiné problémy a všechny naměřené hodnoty odpovídaly příslušným doporučením ITU-T.

Testy ověřily, že zařízení použitá v ATM síti brněnských vysokých škol ve spolupráci s páteřní technikou TEN-155 CZ jsou schopna zajistit potřebnou kvalitu služeb pro přenos emulovaných E1 okruhů. Je tedy možné i zde pokračovat v dalších úkolech v oblasti telefonie v rámci projektu TEN-155 CZ.

Verze IOS směrovačů Cisco pro VoIP

Se stále rostoucí potřebou testování hlasových služeb v rámci projektu TEN-155 CZ, bylo třeba najít nejvhodnější verzi IOS pro směrovače firmy Cisco Systems. Cílem byla nejen spolupráce mezi směrovači a ústřednami, ale i efektivní spolupráce s aplikacemi na PC.

Efektivní využití přenosového pásma mezi směrovači bylo zajištěno ve všech verzích. Ty umožňovaly digitalizaci a komprimaci hovoru v kodeku dle doporučení G.729 s výslednou přenosovou rychlostí 8 kb/s. Při spolupráci s aplikacemi na PC (například NetMeeting nebo Net2Phone) však bylo možné použít pouze kodek dle doporučení G.711 s výslednou přenosovou rychlostí 64 kb/s. Pro jeden hovor je tedy zapotřebí šířka pásma větší než 70 kb/s. Tato šířka pásma se však nedá zaručit na pomalejších linkách.

Dalším problémem bylo statické nastavení kodeku na směrovači, které způsobovalo, že v případě rozdílného nastavení nebylo možno hovor spojit.

Oba tyto problémy řešila až verze IOS 12.0.5T1, která nabízí širokou škálu možností digitalizace a komprimace - viz tabulka 5.4. Umožňuje automatický výběr pomocí protokolu H.245 podle potřeb aplikace. U aplikací pro PC je možno s touto verzí IOS uskutečnit hovor s nároky na šířku pásma kolem 10 kb/s s možností uživatelského nastavení.

Nastavení směrování hovoru je na směrovačích možno nakonfigurovat staticky nebo dynamicky. Pro dynamické směrování je potřeba mít nakonfigurovaný gatekeeper, na který se směrovače obracejí s žádostí o uskutečnění spojení. Další funkcí gatekeeperu je evidence hovorů, ověření oprávnění a kontrola počtu hovorů aby nedošlo k překročení šířky pásma. Bez něj evidence hovorů není možná.

Gatekeeper se bohužel nepodařilo zprovoznit. Drtivá většina požadavků na spojení končila hlášením "bus error" a následným restartem směrovače, na kterém byl gatekeeper provozován. Po konzultaci s pracovníky firmy Cisco Systems jsme došli k závěru, že tato funkce bude použitelná až v další verzi IOS. Odstranění problému trvalo dosti dlouho, takže nová verze (12.0.7T) byla k dispozici až koncem roku a nestačili jsme ji vyzkoušet. Po domluvě s kolegy pracujícími na projektu Hlasové služby jsme testování naplánovali na leden 2000.

Porovnání verzí IOS směrovačů Cisco při použití protokolu WCCP

WCCP (Web Cache Coordination Protocol) je protokol navržený firmou Cisco Systems pro spolupráci vyrovnávacího serveru Cisco Cache Engine se směrovačem. Nyní však tento protokol podporují i produkty jiných společností, mimo jiné i program Squid.

Ve spolupráci se skupinou Optimalizace provozu WWW cache pod vedením Ing. Jana Haluzy byly vyzkoušeny různé verze IOS směrovačů firmy Cisco Systems, které v nynější době podporují WCCP protokol verze 2. Nová verze protokolu mimo jiné umožňuje spolupráci jednoho vyrovnávacího serveru s více směrovači a zabezpečení komunikace heslem. Tato verze je však podporována pouze na zařízeních Cisco Cache Engine 500 a 550. Ostatní produkty nabízejí jen verzi 1.

Na směrovačích je podpora protokolu WCCP verze 2 zabudována ve verzích IOS 12.0.5T1 a 12.0.7T. Tyto verze IOS mají odlišnou syntaxi pro konfiguraci WCCP protokolu a i v případě použití WCCP verze 1 nabízí několik funkcí pro zefektivnění práce směrovače.

Konfigurace směrovače bez podpory WCCP verze 2:

...
ip wccp enable
ip wccp redirect-list 161
...
interface ATM1/0.2 multipoint
  ip web-cache redirect
...

Konfigurace směrovače s podporou WCCP verze 2:

...
ip wccp version 1
ip wccp web-cache redirect-list 161
...
interface ATM1/0.2 multipoint
  ip wccp redirect exclude in
  ip wccp web-cache redirect out
...

V obou konfiguracích je nadefinován přístupový seznam, který určuje, pro které zdroje a pro které klienty má směrovač použít vyrovnávací server. Tímto přístupovým seznamem jsou posuzovány všechny žádosti o spojení služby na port 80 ze všech rozhraní. Při větším počtu položek seznamu a stále rostoucí WWW komunikaci stoupá i zátěž procesoru směrovače.

Při použití IOS s podporou WCCP verze 2 je možné v konfiguraci na rozhraní zakázat přesměrování dotazů bez kontroly přístupovým seznamem. To má za následek podstatně nižší zátěž procesoru a efektivnější práci směrovače. IOS verze 12.0.5T1 bohužel vykazuje některé chyby, které znemožňují její použití. Jako bezproblémová se jeví verze 12.0.7T, která je v současnosti provozována v několika uzlech TEN-155 CZ.

Verze IOS jak bez podpory protokolu WCCP verze 2 tak i s jeho podporou byly testovány ve spolupráci s příslušně konfigurovaným programem Squid. Obě verze pracovaly spolehlivě a nepozorovali jsme žádné problémy.

předchozí

obsah

následující