}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Metody testování výkonu prvku˚ sít’ové infrastruktury ˇ B AKALÁ RSKÁ PRÁCE
Jan Vykopal
Brno, 2006
Prohlášení Prohlašuji, že tato bakaláˇrská práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.
Vedoucí práce: Mgr. David Rohleder ii
Podˇekování Pˇredevším dˇekuji vedoucímu mé práce Mgr. Davidu Rohlederovi za odborné vedení, vstˇrícný pˇrístup a cenné pˇripomínky, které mi pomohly pˇri psaní této práce. Dále pak dˇekuji kolegum ˚ pracujícím na projektu Liberouter za pomoc pˇri testování. V neposlední rˇ adˇe pak mým blízkým, kteˇrí mˇe podporovali a dodávali mi sílu.
iii
Shrnutí Cílem práce je seznámit cˇ tenáˇre se základními dokumenty, které se vˇenují mˇerˇ ení výkonu sítˇe a jejích prvku. ˚ Dále je proveden rozbor existujících testovacích nástroju. ˚ Zjišt’uje se, do jaké míry splnují ˇ požadavky na provádˇení testu˚ uvedené v daných dokumentech. Souˇcástí práce je i návrh a implementace automatizace testování, skriptu˚ ovládajících vybraný testovací nástroj.
iv
Klíˇcová slova BMWG, RFC 2544, IPPM, testovací nástroje, Spirent AX/4000, Tcl, test propustnosti, Liberouter
v
Obsah 1
2
3
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Projekt Liberouter . . . . . . . . . . . . . . . . . 1.2 Obsah práce . . . . . . . . . . . . . . . . . . . . Typy testu˚ . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Dokumenty pracovní skupiny BMWG . . . . . 2.1.1 RFC 1242 . . . . . . . . . . . . . . . . . . 2.1.2 RFC 1944 . . . . . . . . . . . . . . . . . . 2.1.2.1 Test propustnosti . . . . . . . . 2.1.2.2 Test zpoždˇení (latence) . . . . 2.1.2.3 Zjištˇení ztrátovosti . . . . . . . 2.1.2.4 Test back-to-back rámcu˚ . . . 2.1.2.5 Zotavení se po pˇretížení . . . . 2.1.2.6 Zotavení se po restartu . . . . 2.1.3 RFC 2544 . . . . . . . . . . . . . . . . . . 2.1.4 RFC 2285 a RFC 2889 . . . . . . . . . . . 2.1.5 RFC zamˇerˇ ené na testování smˇerovaˇcu˚ 2.2 Dokumenty pracovní skupiny IPPM . . . . . . 2.2.1 RFC 2330 . . . . . . . . . . . . . . . . . . 2.2.2 RFC 2678 . . . . . . . . . . . . . . . . . . 2.2.3 RFC 2679 a RFC 2680 . . . . . . . . . . . 2.2.4 RFC 2681 . . . . . . . . . . . . . . . . . . 2.2.5 RFC 3357 . . . . . . . . . . . . . . . . . . 2.2.6 RFC 3393 . . . . . . . . . . . . . . . . . . 2.3 Srovnání dokumentu˚ skupin BMWG a IPPM . Testovací nástroje . . . . . . . . . . . . . . . . . . . . 3.1 Softwarové testovací nástroje . . . . . . . . . . 3.1.1 DBS 1.2.0 beta 1 . . . . . . . . . . . . . . 3.1.2 IPerf 2.0.2 . . . . . . . . . . . . . . . . . 3.1.3 NetPerf 2.4.2 . . . . . . . . . . . . . . . . 3.1.4 NetPIPE 3.6.2 . . . . . . . . . . . . . . . 3.1.5 NetSpec 5.0 . . . . . . . . . . . . . . . . 3.1.6 RUDE & CRUDE 0.70 . . . . . . . . . . 3.1.7 TReno . . . . . . . . . . . . . . . . . . . 3.1.8 TTCP6 . . . . . . . . . . . . . . . . . . . 3.1.9 DPTT . . . . . . . . . . . . . . . . . . . . 3.2 Hardwarové testovací nástroje . . . . . . . . . 3.2.1 Spirent/Adtech AX/4000 . . . . . . . . 3.2.2 Agilent N2X . . . . . . . . . . . . . . . . 3.2.3 Ixia . . . . . . . . . . . . . . . . . . . . . 3.2.4 Anritsu . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 1 2 3 3 3 3 6 7 8 10 10 11 11 11 12 12 12 14 14 16 16 16 16 18 18 19 19 19 19 19 20 20 20 20 21 21 21 22 22 vi
3.3 Srovnání softwarových a hardwarových nástroju˚ . . . 4 Implementace skriptu˚ na vybraném nástroji . . . . . . . . 4.1 Grafické uživatelské rozhraní . . . . . . . . . . . . . . 4.1.1 Testování propustnosti . . . . . . . . . . . . . . 4.2 Aplikaˇcní programové rozhraní . . . . . . . . . . . . . 4.2.1 Testování propustnosti . . . . . . . . . . . . . . 4.3 Automatizace testování . . . . . . . . . . . . . . . . . 4.3.1 Test propustnosti opakovaˇce sondy FlowMon 4.3.2 Test propustnosti sondy FlowMon . . . . . . . 5 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A Obsah pˇriloženého CD . . . . . . . . . . . . . . . . . . . . Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
23 25 25 26 28 29 29 30 30 32 33 35
vii
Kapitola 1
Úvod V dnešní dobˇe je kladen velký duraz ˚ na používání poˇcítaˇcových a komunikaˇcních technologií ve všech odvˇetvích lidské cˇ innosti. Moderní aplikace neustále vyžadují lepší a výkonˇejší hardware a rychlejší komunikaˇcní kanály, aby zajistily pˇrenos velkých objemu˚ dat. Napˇr. kvalitní multimediální vysílání si vynucuje použití témˇerˇ ideální poˇcítaˇcové sítˇe, takové sítˇe, která by zajišt’ovala neomezenou propustnost dat a jejich nulové zpoždˇení. Jak se mužeme ˚ pˇriblížit této nedosažitelné kvalitˇe sítˇe? Pˇri návrhu sítˇe bychom mˇeli vycházet z pˇredpokladu, že kvalita celku závisí na kvalitˇe jednotlivých prvku. ˚ Nesmíme tedy podcenit výbˇer prvku˚ sít’ové infrastruktury. Kritéria výbˇeru jsou ruznorodá ˚ – od ekonomických pˇres strategická až po cˇ istˇe technická. Poslednˇe zmínˇenými se zabývá tato práce. V prubˇ ˚ ehu nˇekolika desetiletí vznikla celá rˇ ada doporuˇcení a testovacích nástroju, ˚ které se snažily reagovat na prudký rozvoj celého odvˇetví. Napˇr. cˇ asto sklonovaný ˇ a dnes už i nasazovaný protokol IPv6 si vyžádal revizi tˇechto doporuˇcení a úpravu testovacích nástroju. ˚ Pro správce poˇcítaˇcových sítí je duležité ˚ znát základní charakteristiky použitých prvku, ˚ pro vývojáˇre tˇechto prvku˚ je to až životnˇe duležité. ˚ Výsledky testování výkonu jejich produktu˚ za stejných podmínek jako byly testovány ostatní výrobky cˇ asto rozhodují o další práci.
1.1
Projekt Liberouter
Puvodním ˚ cílem projektu Liberouter[3] bylo vyvinout vysokorychlostní smˇerovaˇc na bázi PC s podporou protokolu˚ IPv4 a IPv6 se zcela otevˇrenými zdrojovými kódy (software i firmware). Bˇežné smˇerovaˇce na bázi PC používají standardnˇe vybavený osobní poˇcítaˇc a pˇríslušný software, který pˇrijímá datové pakety, zpracovává je a odesílá do pˇríslušné sítˇe. Veškerá data tedy putují ze sít’ové karty pˇres sbˇernici do pamˇeti. V souˇcasnosti je v bˇežných osobních poˇcítaˇcích rozšíˇrena sbˇernice PCI v ruzných ˚ variantách. Puvodní ˚ šíˇrka sbˇernice je 32 bitu˚ a taktovací frekvence 33 MHz. Novˇejší poˇcítaˇce disponují PCI sbˇernicí o šíˇrce 64 bitu˚ a frekvence 66 MHz. Teoretická propustnost je tedy kolem 1 Gb/s u první verze a 2 Gb/s u druhé. Ovšem tyto hodnoty jsou v praxi nižší. Efektivita využití PCI sbˇernice je malá, velká cˇ ást datových pˇrenosu˚ pˇripadá na režijní operace. Projekt Liberouter jde jinou cestou. Využívá hardwarový akcelerátor COMBO6 obsahující programovatelný hardware (FPGA, hradlová pole). Firmware je naprogramován v jazyce VHDL (VHSIC Hardware Description Language) a pˇrímo vykonává operace, které 1
1.2. OBSAH PRÁCE musejí být provedeny co nejrychleji, napˇr. filtrování paketu. ˚ Data tedy neputují po pomalé sbˇernici, ale jsou zpracována pˇrímo na kartˇe. Ostatní operace, které tolik nespˇechají, má na starosti software poˇcítaˇce. Akceleraˇcní karta je pro operaˇcní systém transparentní. Lze tedy používat bˇežné systémové pˇríkazy jako route aj. Spojení bˇežného osobního poˇcítaˇce a hardwarového akcelerátoru využívá výhod obou paradigmat. Poskytuje výkon drahého hardwarového smˇerovaˇce v cenové hladinˇe softwarového smˇerovaˇce. Postupem cˇ asu se objevily nové aplikace a kromˇe puvodního ˚ projektu Liberouter vznikly další projekty: NIC (sít’ová karta), NIFIC (sít’ová karta s hardwarovým filtrováním, zasíláním a replikací paketu), ˚ FlowMon (pasivní sonda sledující sít’ové rozhraní) a další. Moje práce v projektu Liberouter spoˇcívá v testování nejruznˇ ˚ ejších charakteristik vyvíjených zaˇrízení. Dále mám za úkol vyvinout sadu skriptu˚ pro automatizaci testování, které by pak mohli provádˇet sami vývojáˇri. Celý proces testování by se tak podstatnˇe zjednodušil a zrychlil.
1.2
Obsah práce
Tato práce se skládá z teoretické a praktické cˇ ásti. Teoretickou cˇ ást tvoˇrí pˇrehled duležitých ˚ dokumentu, ˚ které klasifikují a popisují nejruznˇ ˚ ejší typy testu. ˚ Nejprve jsou zrekapitulovány a komentovány dokumenty vydané dvˇema pracovními skupinami celosvˇetové organizace Internet Engineering Task Force (IETF), které se zamˇerˇ ují na mˇerˇ ení výkonu a testování sítí a jejich prvku. ˚ Následuje srovnání tˇechto textu. ˚ Praktickou cˇ ást práce zahajuje rozdˇelení testovacích nástroju˚ na softwarové a hardwarové, jejich popis z pohledu uživatele. Potom je provedeno srovnání tˇechto dvou rozdílných typu˚ nástroju, ˚ dvou rozdílných pˇrístupu˚ k testování. Na základˇe tohoto srovnání jsem si vybral nástroj (konkrétnˇe hardwarový Spirent AX/4000), navrhl a implementoval skripty pro automatizované testování prvku˚ sít’ové infrastruktury pomocí tohoto nástroje.
2
Kapitola 2
Typy testu˚ Výrobci prvku˚ sít’ové infrastruktury mají jasný cíl – prodat co nejvíce svých produktu, ˚ zvítˇezit nad konkurencí. Tvrdý konkurenˇcní boj s sebou pˇrináší i ruzné ˚ zkreslování a zatajování vlastností jednotlivých produktu. ˚ Každý výrobce používá svou sadu testu. ˚ Jednotlivé typy testu˚ a zpusob ˚ jejich provádˇení je navržen tak, aby testovaná zaˇrízení dosahovala co nejlepších výsledku. ˚ Zákazník tedy nemá možnost objektivnˇe porovnávat produkty ruzných ˚ výrobcu. ˚ Máme-li dnes na mysli sít’, je to internet. Již od poˇcátku jeho vývoje bylo užiteˇcné navrhnout a používat standardy. Proto také vzniklo sdružení výzkumníku, ˚ vývojáˇru, ˚ návrháˇru, ˚ výrobcu˚ a uživatelu˚ internetových technologií s názvem Internet Engineering Task Force (IETF) a jeho pracovní skupiny Benchmarking Methodology Working Group (BMWG) a IP Performance Metrics Working Group (IPPM). Obˇe skupiny se snaží popsat ruzné ˚ metodiky provádˇení testu˚ vˇcetnˇe jednoznaˇcné prezentace namˇerˇ ených hodnot. BMWG se zamˇerˇ uje spíše na probematiku testování jednoho cˇ i nˇekolika málo zaˇrízení, zatímco IPPM na testování sítˇe jako celku. Tyto pracovní skupiny vydávají Request For Comments (RFC), což jsou de facto internetové standardy. Dodržování standardu˚ ruznými ˚ produkty výrobcu˚ prvku˚ sít’ové infrastruktury vede ke snadnému porovnávání jejich vlastností a parametru. ˚
2.1
Dokumenty pracovní skupiny BMWG
2.1.1
RFC 1242
Prvním dokumentem, který BMWG publikovala, byl již v roce 1991 RFC 1242 Benchmarking Terminology for Network Interconnection Devices[6]. Kromˇe definic klíˇcových pojmu˚ jako je napˇr. propustnost nebo zpoždˇení, obsahuje i definice zdánlivˇe zˇrejmé: smˇerovaˇc (router), most (bridge) cˇ i konstantní zátˇež. Právˇe na definicích tˇechto elementárních pojmu˚ staví další definice a následující dokumenty. Autoˇri se tedy snaží pˇredcházet nejednoznaˇcnosti pˇri interpretaci. 2.1.2
RFC 1944
O pˇet let pozdˇeji, v roce 1996, byl vydán další duležitý ˚ dokument – RFC 1944 Benchmarking Methodology for Network Interconnect Devices[7]. Obsahuje popis výkonostních testu˚ sít’ových zaˇrízení vˇcetnˇe jednoznaˇcné prezentace výsledku. ˚ To opˇet napomáhá jednoznaˇcnosti 3
2.1. DOKUMENTY PRACOVNÍ SKUPINY BMWG porozumˇení. Dále je kladen duraz ˚ na zopakovatelnost testu. ˚ Výsledky pak mají urˇcitou vypovídací hodnotu. Stejnˇe jako v ostatních dokumentech se i v tomto RFC ve specifikacích duslednˇ ˚ e rozlišuje napˇr. mezi výrazy musí, požaduje, mˇel by, volitelné. Na základˇe míry splnˇení tˇechto požadavku˚ pak testy cˇ ásteˇcnˇe nebo úplnˇe vyhovují specifikacím v tomto dokumentu. To je další duležitá ˚ informace pro uživatele. Následuje popis zapojení testovaného zaˇrízení (DUT, device under test) a zamyšlení nad propojováním ruznorodých ˚ sítí. V celém dokumentu se díváme na testované zaˇrízení jako na blackbox, nezajímá nás vnitˇrní struktura a zapojení a jak se data v daném zaˇrízení zpracovávají. Do zaˇrízení posíláme data (tj. vstupy) a dostáváme data nebo jejich statistiky (tj. výstupy). Na základˇe jejich porovnání prohlásíme, zda zaˇrízení testem prošlo nebo jaké jsou jeho výkonostní charakteristiky. Komplementární pˇrístup, kdy sledujeme, co se dˇeje uvnitˇr zaˇrízení, tj. jak jednotlivé vnitˇrní moduly nakládají s daty, se nazývá whitebox. Tento typ testování se používá pˇri návrhu a ladˇení jednotlivých komponent vyvíjeného zaˇrízení, pˇrístup blackbox pro testování v koneˇcné fázi vývoje produktu.
Obrázek 2.1: Preferované zapojení testovacího a testovaného zaˇrízení (DUT) Další cˇ ást je vˇenována nastavení zaˇrízení. Konfigurace testovaného zaˇrízení musí pˇresnˇe odpovídat konfiguraci uvedené v testovací zprávˇe. Dále se oˇcekává, že budou zprovoznˇeny a do testu zahrnuty všechny protokoly, které daný prvek sít’ové infrastruktury podporuje. Více informací podává dodatek A, který plní pouze informativní funkci, není závazný. Osmá cˇ ást odkazuje na dodatek C, jenž obsahuje definice formátu rámcu˚ a datagramu˚ používaných na Ethernetu. Zvláštní pˇrípady, tzn. definice, které nejsou souˇcástí dodatku C, musí být zahrnuty jako nedílná souˇcást testovací zprávy. Velikost rámcu˚ je další téma tohoto RFC. Všechny popisované testy by mˇely být provedeny nˇekolikrát, nejménˇe s pˇeti ruznými ˚ délkami testovacích rámcu. ˚ Zejména by mˇely být do testování zahrnuty rámce s nejmenší resp. nejvˇetší pˇrípustnou délkou. Interval mezi délkami má být dostateˇcný. Pro ruzná ˚ média jsou urˇceny ruzné ˚ délky. Napˇr. pro Ethernet je to 64, 128, 256, 512, 1024, 1280 a 1518 bajtu. ˚ Dále je diskutována velikost rámcu˚ v závislosti na MTU (Maximum Transmission Unit) a 4
2.1. DOKUMENTY PRACOVNÍ SKUPINY BMWG fragmentaci. Pˇri ovˇerˇ ování pˇríchozích rámcu˚ musíme dbát na to, aby nebyly do celkového poˇctu pˇrijatých zahrnuty napˇr. pakety obsahující smˇerovací informace cˇ i ARP dotazy. V každém pˇrípadˇe bychom mˇeli kontrolovat, zda se shodují délky vyslaných a pˇrijatých rámcu. ˚ V nˇekterých testech záleží i na poˇradí rámcu. ˚ Pokud každý rámec obsahuje unikátní cˇ íslo (rámce pak tvoˇrí sekvenci), mužeme ˚ sledovat poˇradí, v jakém se vrátily zpˇet, zda nedošlo po cestˇe k jejich duplikaci nebo ztrátˇe. V nˇekterých pˇrípadech je užiteˇcné znát výkon testovaného zaˇrízení za urˇcitých podmínek. Napˇr. pokud testujeme propustnost smˇerovaˇce, zamˇerˇ íme se na potenciálnˇe problémovou oblast. Tou muže ˚ být všesmˇerové vysílání a proto každý stý rámec, který vysíláme na smˇerovaˇc, obsahuje všesmˇerovou cílovou adresu (je to tzv. broadcast frame). Nebo mu˚ žeme sledovat, zda smˇerovaˇc odpovídá na dotazy definované protokolem správy sítˇe, napˇr. SNMP. Duležitou ˚ roli hraje též úprava smˇerovacích informací nebo správná funkce bezpeˇcnostních filtru˚ smˇerovaˇce. Tato pravidla rozhodují o pruchodu ˚ paketu smˇerovaˇcem na základˇe zdrojových a cílových adres. Pokud testovací zaˇrízení umožnuje ˇ generovat sít’ový provoz, jenž vyhovuje dané podmínce, mˇeli bychom do testování zahrnout co nejvíce takových podmínek a provozu. ˚ Jestliže splníme tento požadavek, celý testovací proces bude cˇ asovˇe nároˇcný. Pˇred zaˇcátkem testování s dodateˇcnými podmínkami bychom mˇeli testovat zaˇrízení bez tˇechto podmínek a pak teprve každou podmínku zvlášt’. Další cˇ ást textu je zamˇerˇ ena na adresy používané v testovacích paketech. Pro jednoduchost se doporuˇcuje zaˇcít pouze s jedním testovacím tokem dat (je použita právˇe jedna zdrojová a cílová adresa). Autoˇri upozornují ˇ na zˇrejmý fakt, že v reálných sítích je takových toku˚ mnohem víc. Proto je vhodné použít náhodnˇe generované cílové adresy nebo rovnomˇerné rozložení tˇechto adres. Bližsí informace o adresách v IP datagramech nalezneme v dodatku C. Až doposud jsme mˇeli na mysli jednosmˇerný provoz. Avšak v reálné síti je velmi cˇ asté, že data teˇcou obˇema smˇery. Pokud má testované zaˇrízení více portu, ˚ každý port bychom mˇeli testovat zvlášt’. Odhalíme tak pˇrípadnou chybu, která se vyskytuje pouze na nˇekterém z daných portu. ˚ Také bychom mˇeli vytvoˇrit takový provoz, jenž testované zaˇrízení pˇrijme na ruzných ˚ vstupních portech a pošle na stejné výstupní porty ve stejném okamžiku. V tomto dokumentu nejsou nijak specifikovány testy probíhající na ruzných ˚ protokolech a médiích souˇcasnˇe. Podobnˇe je tomu tak u ruzných ˚ délek rámcu˚ v jednom testu. Jediný požadavek je vznesen na použití délek rámcu, ˚ tak jak byly deklarovány v pˇredcházejícím textu. Na propojení více testovaných zaˇrízení sítí nahlížíme jako na jedno zaˇrízení. To je tzv. end-to-end pˇrístup. Musíme ale brát v úvahu, že jsou v síti další prvky, které napˇr. zanáší do pˇrenosu dat urˇcité zpoždˇení. Dále by mˇela být v testech použita maximální rychlost zasílání rámcu˚ dané délky na daném médiu. Konkrétní hodnoty pro konkrétní média udává dodatek B. Napˇr. u hodnot pro Ethernet musíme být obezˇretní. Stuart Johnson upozornuje ˇ ve svém komentáˇri[2] na skuteˇcnost, že speficikace IEEE 802.3 povoluje odchylku hodinového taktu +-0,01 %. Není tedy zaruˇceno, že všechna zaˇrízení zvládnou zpracovat maximální hodnoty uvedené v dodatku 5
2.1. DOKUMENTY PRACOVNÍ SKUPINY BMWG B. Takže ztráta 0,02 % všech zaslaných paketu˚ je povolená. Shlukový provoz (bursty traffic) je dalším tématem tohoto RFC. Autoˇri konstatují, že je tento typ provozu bližší skuteˇcnému a doporuˇcují jej generovat i kromˇe provozu s konstantní zátˇeží. Rámce uvnitˇr shluku mají být poslány po sobˇe s co nejmenší mezerou. Cílem tohoto testu je zjistit takový interval mezi shluky, pˇri kterém není ztracen žádný rámec. Shluky jsou tvoˇreny 16, 64, 256 nebo 1024 rámci. Každá sada testu˚ se skládá z nˇekolika dílˇcích testu. ˚ Postup provádˇení tˇechto dílˇcích testu˚ je následující: 1. pokud je testované zaˇrízení smˇerovaˇc, pošleme smˇerovací informace na vstupní port a poˇckáme 2 sekundy, 2. zašleme rámce, které „nauˇcí“ testované zaˇrízení, kam má posílat testovací rámce; napˇr. protokol ARP plní tuto funkci v rodinˇe protokolu˚ IPv4, 3. spustíme samotný test a cˇ ekáme nejménˇe 60 sekund; v nˇekterých pˇrípadech cˇ asovˇe nároˇcných testu˚ je povoleno tuto dobu zkrátit, ale výsledek je tˇreba ovˇerˇ it testem trvajícím celých 60 sekund, 4. vyˇckáme 2 sekundy na poslední pˇríchozí rámce, 5. nejménˇe 5 sekund ponecháme zaˇrízení na stabilizaci. Po definicích nejruznˇ ˚ ejších podmínek a specifikacích provádˇení testu˚ se koneˇcnˇe dostáváme k popisu samotných testu. ˚ 2.1.2.1 Test propustnosti Tento test má za úkol zjistit propustnost definovanou v RFC 1242, tj. maximální rychlost zasílání paketu, ˚ pˇri které nejsou zahozeny žádné odeslané pakety. Zpusob ˚ provádˇení Do testovaného zaˇrízení vyšleme urˇcitou rychlostí urˇcitý poˇcet rámcu˚ a sledujeme poˇcet rámcu˚ vyslaných nebo zpracovaných testovaným zaˇrízením. Pokud je pocˇ et vyslaných rámcu˚ stejný jako poˇcet pˇrijatých, zvýšíme vysílací rychlost a test opakujeme. Jestliže je poˇcet pˇrijatých rámcu˚ nižší, snížíme rychlost a test opˇet opakujeme. Propustnost je tedy nejvyšší rychlost (v rámcích za sekundu), pˇri níž je roven poˇcet vyslaných a pˇrijatých rámcu. ˚ Testovací zpráva Výsledky testování by mˇely být prezentovány formou grafu. Na ose x jsou vyneseny délky rámcu, ˚ na ose y rychlost v rámcích za sekundu. Graf se skládá nejménˇe ze dvou kˇrivek. První zobrazuje maximální teoretickou rychlost pro dané médium a druhá výsledky testu – namˇerˇ enou propustnost. Další kˇrivky mohou ukazovat výsledky pro urˇcitý testovací tok. Doprovodný text má informovat o použitém protokolu, formátu testovacího toku a typu média. Autoˇri RFC pˇredpokládají, že pokud bude použita pouze jediná hodnota k propagaˇcním úˇcelum, ˚ bude to právˇe ta, pˇri které zaˇrízení dosahuje nejvˇetšího výkonu. Obvykle se 6
2.1. DOKUMENTY PRACOVNÍ SKUPINY BMWG
Obrázek 2.2: Pˇríklad grafu zachycujícího výsledky testu propustnosti dle RFC 1944
tak dˇeje na nejdelších rámcích. Tato hodnota musí být udána v rámcích za sekundu, volitelnˇe pak v bitech cˇ i bajtech za sekundu. Závˇer musí obsahovat nejvyšší namˇerˇ enou hodnotu, velikost rámce, na níž byla zjištˇena, teoretickou maximální rychlost média pro danou velikost rámce a typ protokolu použitého v testu. Ukázku testovací zprávy obsahuje CD pˇriložené k této práci. Technická specifikace (datasheet) zaˇrízení má obsahovat úplnou tabulku výsledku. ˚ Diskuze Dokument pˇresnˇe nespecifikuje, kolik rámcu˚ máme poslat na testované zaˇrízení. Udává jen standardní délku trvání testu 60 sekund a její možné zkrácení. Exaktní pocˇ et vyslaných rámcu˚ lze jednoduše dopoˇcítat z rychlosti zasílání. Zpusob ˚ provádˇení testu je také popsán neurˇcitˇe. Na druhou stranu nám autoˇri ponechávají urˇcitou volnost. V praxi se osvˇedˇcilo používat algoritmus binárního pulení. ˚ Jeho asymptotická složitost je logaritmická. Podstatnˇe se tak zkrátí doba potˇrebná k provedení testu. 2.1.2.2 Test zpoždˇení (latence) Cílem testu zpoždˇení je najít velikost latence, tak jak je definována v RFC 1242. Zde je dule˚ žité rozlišit ruzné ˚ typy zaˇrízení, existují totiž tˇri ruzné ˚ zpusoby ˚ zpracovávání paketu. ˚ 7
2.1. DOKUMENTY PRACOVNÍ SKUPINY BMWG Pokud je celý paket nejprve naˇcten a až poté pˇreposlán na pˇríslušné rozhraní, hovoˇríme o zpusobu ˚ store and forward. Tuto techniku používají pˇredevším pˇrepínaˇce a smˇerovaˇce. Zpoždˇení je pak definováno jako cˇ asový interval mezi pruchodem ˚ posledního bitu vstupního rámce na vstupním portu a pruchodem ˚ prvního bitu výstupního rámce na výstupním portu. Zaˇrízení operující na první vrstvˇe sít’ového modelu ISO/OSI, napˇr. opakovaˇce (huby), provádˇejí bit forwarding – paket je neprodlenˇe zaslán na dané rozhraní. Latence je pak cˇ asový interval mezi pruchodem ˚ prvního bitu vstupního rámce na vstupním portu a prucho˚ dem prvního bitu výstupního rámce na výstupním portu. Cut through je „kombinací“ pˇredchozích zpusob ˚ u. ˚ Paket není naˇcten celý, napˇr. je nacˇ tena jen hlaviˇcka a už je zahájeno pˇreposílání. V RFC 1242 je doporuˇcováno považovat zpoždˇení za cˇ asový interval mezi pruchodem ˚ prvního bitu po preambuli (bitové výplnˇe mezi rámci) vstupního rámce na vstupním portu a pruchodem ˚ prvního bitu výstupního rámce na výstupním portu. Zpusob ˚ provádˇení Pˇred tímto testem je nutné zjistit propustnost pro rámce dané délky (pro Ethernet tedy 64, 128, 256, 512, 1024, 1280 a 1518 bajtu). ˚ Pro každou takovou délku pak vytvoˇríme tok testovacích rámcu, ˚ jenž by mˇel trvat nejménˇe 120 sekund. Do každého toku pak po 60 sekundách vložíme jeden „oznaˇckovaný“ rámec. Zaznamenáme cˇ as, kdy byl tento rámec zcela odeslán. Pˇrijímající cˇ ást testovacího zaˇrízení musí tento rámec rozeznat od ostatních v testovacím toku a zaznamenat cˇ as jeho pˇríchodu. Zpoždˇení je pak rozdíl tˇechto dvou cˇ asu˚ podle výše uvedených definic. Každý test musí být proveden nejménˇe dvacetkrát a výsledná hodnota zpoždˇení je aritmetickým prumˇ ˚ erem všech zjištˇených hodnot. Testovací rámec by mˇel pokaždé smˇerˇ ovat do jiné cílové sítˇe, avšak ta by mˇela být stejná jako u ostatních rámcu˚ v toku. Testovací zpráva Použitá definice latence z RFC 1242 musí být obsažena v testovací zprávˇe. Výsledky mají být v tabulce, která má právˇe tolik rˇ ádku, ˚ kolik ruzných ˚ délek rámcu˚ bylo testováno. Kromˇe délky rámcu˚ sloupce obsahují rychlost, jíž byl posílán testovací tok, dále typ použitého pˇrenosového média a výsledné zpoždˇení. Diskuze Všimnˇeme si, že je tento typ testu, tak jak je zde popsán, cˇ asovˇe nároˇcný. Pokud budeme testovat na Ethernetu, musíme vyjma testu˚ propustnosti provést nejménˇe 7 ˇ testu, ˚ které se skládají z 20 dílˇcích testu. ˚ Cistý cˇ as potˇrebný k provedení testu˚ je nejménˇe 4 hodiny a 40 minut. Nesmíme opomenout cˇ as potˇrebný ke stabilizaci prostˇredí a zaˇrízení, tzn. ke každému dílˇcímu testu musíme dle tohoto RFC pˇriˇcíst celkem 7 sekund. Celkový cˇ as provedení tohoto testu, pokud již známe výsledky testování propustnosti, je témˇerˇ 5 hodin. Uvedené definice zpoždˇení kladou vysoké nároky na pˇresnost cˇ asu. Vzhledem k rychlostem dnešních sítí, které se pohybují v rˇ ádech gigabitu, ˚ musejí být schopny rozlišit velmi malá cˇ asová kvanta – jednotky až zlomky mikrosekund. 2.1.2.3 Zjištˇení ztrátovosti Toto RFC opˇet odkazuje na definici ztrátovosti paketu˚ (frame loss rate) z RFC 1242. Ztrátovost je tedy procentuální údaj, který vyjadˇruje, kolik paketu˚ mˇelo být pˇreneseno, avšak 8
2.1. DOKUMENTY PRACOVNÍ SKUPINY BMWG z duvodu ˚ nedostatku systémových prostˇredku˚ testovaného zaˇrízení tomu tak nebylo. Zpusob ˚ provádˇení Stejnˇe jako v testu propustnosti, tak i v tomto testu vyšleme na testované zaˇrízení urˇcitý poˇcet rámcu˚ urˇcitou rychlostí. Zaˇrízení by mˇelo tyto rámce pˇrijmout a pˇreposlat dále. Ztrátovost spoˇcítáme takto: ztratovost =
(pocet zaslanych ramcu−pocet prijatych ramcu)×100 pocet zaslanych ramcu
Rovnice 2.1.1: Výpoˇcet ztrátovosti V prvním dílˇcím testu by mˇely být rámce zaslány maximální teoretickou rychlostí, kterou dané médium poskytuje. Další dílˇcí testy jsou provádˇeny s postupnˇe se snižující rychlostí (nejvˇetší povolený krok je 10 %) až do té doby, než je ve dvou testech zjištˇena nulová ztrátovost. Autoˇri tohoto dokumentu doporuˇcují dˇelat jemnˇejší kroky než je zmínˇených 10 % maximální rychlosti média. Testovací zpráva Namˇerˇ ené hodnoty by mˇely být zobrazeny v grafu. Na osu x je nanesena rychlost v procentech maximální možné rychlosti použitého média, na osu y ztrátovost v procentech. Obˇe osy musí mít rozsah 0–100 %. Graf muže ˚ obsahovat více kˇrivek, jenž mohou vyjadˇrovat ztrátovost napˇr. pro ruzné ˚ délky rámcu˚ cˇ i použité protokoly.
Obrázek 2.3: Pˇríklad grafu, který znázornuje ˇ výsledky zjištˇení ztrátovosti podle RFC 1944 9
2.1. DOKUMENTY PRACOVNÍ SKUPINY BMWG Diskuze Nˇekteré cˇ ásti testovacího procesu zjištˇení ztrátovosti jsou stejné jako u testu propustnosti. V obou testech zašleme rámce a sledujeme, kolik se jich vrátilo. V testu propustnosti vlastnˇe zjišt’ujeme ztrátovost; hledáme rychlost zasílání, pˇri níž je ztrátovost rovna nule (nebo témˇerˇ nule). Pokud byla namˇerˇ ena vyšší než nula (nebo definovaný práh), tak snížíme rychlost zasílání a konkrétní hodnota ztrátovosti je pro nás nezajímavá. Naopak, když zjišt’ujeme ztrátovost, rychlost je pevnˇe udána krokem jejího snižování. 2.1.2.4 Test back-to-back rámcu˚ Cílem testu je zjistit, v jaké míˇre je testovací zaˇrízení schopno zpracovávat back-to-back rámce. Co jsou to back-to-back rámce? Odpovˇed’ nám opˇet podá RFC 1242. Jsou to rámce pevné délky, které jsou vyslány za sebou. Interval mezi dvˇema po sobˇe jdoucími rámci má být nejmenší povolený na daném médiu. Zpusob ˚ provádˇení Do testovaného zaˇrízení zašleme shluk back-to-back rámcu. ˚ Jestliže je poˇcet pˇrijatých rámcu˚ roven poˇctu odeslaných, zvˇetšíme poˇcet rámcu˚ ve shluku. V opaˇcném pˇrípadˇe poˇcet rámcu˚ snížíme. Test opakujeme. Výsledkem testu je poˇcet rámcu˚ v nejdelším shluku, které zaˇrízení zcela zpracovalo, tzn. nebyl ztracen žádný rámec. Každý dílˇcí test musí trvat nejménˇe 2 sekundy a mˇel by být opakován nejménˇe padesátkrát. Výsledná hodnota je rovna aritmetickému prumˇ ˚ eru dílˇcích namˇerˇ ených hodnot. Testovací zpráva Zpráva by mˇela obsahovat tabulku s výsledky. Poˇcet rˇ ádku˚ je stejný jako poˇcet ruzných ˚ délek rámcu, ˚ které jsme testovali. Sloupce jsou tvoˇreny délkou testovacího rámce a výslednou hodnotou pro každý typ testovacího toku dat. Další sloupec muže ˚ obsahovat pˇrirozenou odchylku. Diskuze K urychlení provádˇení testu mužeme ˚ opˇet využít algoritmus binárního pulení, ˚ jenž byl popsán v diskuzi u testu propustnosti. Pˇredem ale neznáme horní mez, kterou použijeme v tomto algoritmu. Heuristicky mužeme ˚ urˇcit subjektivnˇe nedosažitelnou hodnotu a pokud není zahozen žádný rámec, tak tuto hodnotu napˇr. zdvojnásobíme. Dolní mez nám urˇcuje požadavek, že délka testu je nejménˇe 2 sekundy. Pokud zaˇrízení dosahuje horších výsledku, ˚ než pˇri minimální délce shluku urˇcené právˇe dvousekundovým trváním testu, tak je pomocí tohoto testu nezmˇerˇ íme. 2.1.2.5 Zotavení se po pˇretížení Tento test má za úkol zjistit cˇ as, který potˇrebuje zaˇrízení na zotavení se po pˇretížení. Zpusob ˚ provádˇení Pˇred provádˇením samotného testu musíme znát propustnost pro každou délku rámce, kterou udává tento dokument. Pak zaˇcneme po dobu nejménˇe 60 sekund vysílat rámce 110% rychlostí zjištˇenou v testu propustnosti, pˇríp. maximální rychlostí média, pokud je 110% rychlost vyšší než maximální. Potom snížíme tuto rychlost na polovinu a zaznamenáme cˇ as, ve kterém jsme snížili rychlost a cˇ as, kdy byl naposledy ztraˇ potˇrebný k zotavení se po pˇretížení je pak roven rozdílu tˇechto cen testovací rámec. Cas dvou cˇ asu. ˚ Test by mˇel být nˇekolikrát opakován a výsledná hodnota je pak aritmetický pru˚ mˇer všech dílˇcích testu. ˚ 10
2.1. DOKUMENTY PRACOVNÍ SKUPINY BMWG Testovací zpráva Výsledky testování by mˇely být zachyceny v tabulce. Poˇcet rˇ ádku˚ je stejný jako poˇcet ruzných ˚ délek rámcu, ˚ které jsme testovali. Sloupce jsou tvoˇreny délkou testovacího rámce, propustností pro každý typ toku a namˇerˇ enou hodnotou cˇ asu zotavení se. Diskuze Pˇri vyhodnocování tohoto testu je nutné zaznamenávat cˇ as prvního pˇrijatého paketu po snížení rychlosti na 50 %. Ne všechny testovací nástroje disponují takovou funkcionalitou. Pˇredpokládejme, že je zaˇrízení ve stavu pˇretížení, kdy zahazuje všechny pakety a po snížení rychlosti pˇrejde do normálního stavu, kdy zpracovává všechny pakety. Potom mužeme ˚ cˇ as, kdy se zaˇrízení dostane ze stavu pˇretížení, vypoˇcítat z poˇctu odeslaných paketu˚ poloviˇcní rychlostí, poˇctu pˇrijatých paketu˚ a rychlosti zasílání. 2.1.2.6 Zotavení se po restartu Cílem testu je zjistit, za jak dlouhou dobu po softwarovém a hardwarovém restartu se zaˇrízení zotaví. Zpusob ˚ provádˇení Stejnˇe jako u testu zotavení se po pˇretížení musíme pˇred zahájením samotného testování znát propustnost. Tentokrát však jen rámcu˚ s nejmenší povolenou délkou na daném médiu. Testovací proud složený z nejkratších rámcu˚ posíláme na testované zaˇrízení. To následnˇe restartujeme a sledujeme výstupní port zaˇrízení. Zaznamenáme cˇ as, kdy byl zaslán poslední rámec toku pˇred restartem a první rámec po restartu. Rozdíl tˇechto cˇ asu˚ je hledaná hodnota. Pokud sledujeme reakci zaˇrízení na výpadek napájení, výpadek má trvat 10 sekund. Testovací zpráva Zpráva by mˇela obsahovat tvrzení o cˇ asu zotavení se pro každý typ restartu. Diskuze V dnešní dobˇe, kdy jsou zaˇrízení spravována vzdálenˇe, muže ˚ nastat problém pˇri provedení hardwarového restartu nebo simulovaného výpadku napájení. Zdánlivˇe cˇ asovˇe nenároˇcný test se tak muže ˚ protáhnout o dobu nutnou k fyzické návštˇevˇe místa, kde je zaˇrízení umístˇeno. 2.1.3
RFC 2544
V roce 1999 vyšel RFC 2544 Benchmarking Methodology for Network Interconnect Devices[11], který je v podstatˇe druhým vydáním RFC 1944 až na jednu drobnou zmˇenu. Tou je vˇetší rozsah adres, které organizace IANA pˇridˇelila pracovní skupinˇe BMWG pro potˇreby testování. Autoˇri doporuˇcují používat právˇe tyto adresy (192.18.0.0 až 198.19.255.255), aby se vylouˇcil možný „únik“ testovacích paketu˚ do reálné sítˇe pˇri špatném zapojení. V dalším textu se budu odkazovat právˇe na toto RFC, i když vše podstatné bylo náplní RFC 1944. RFC 2544 jej totiž oficiálnˇe nahrazuje, RFC 1944 je oznaˇceno jako zastaralé. 2.1.4
RFC 2285 a RFC 2889
Tyto stejnojmenné dokumenty (RFC 2285 Benchmarking Methodology for LAN Switching Device[8] a RFC 2889 Benchmarking Methodology for LAN Switching Device[16]) navazují 11
2.2. DOKUMENTY PRACOVNÍ SKUPINY IPPM na pˇredcházející texty. RFC 2285 rozšiˇruje definice v RFC 1242 a RFC 1944 o pojmy z oblasti pˇrepínání, tj. provozu na druhé, linkové vrstvˇe sít’ového ISO/OSI modelu. Zmínˇené dokumenty totiž braly v úvahu spíše zaˇrízení na vyšší (obvykle tˇretí, sít’ové) vrstvˇe, vˇetšinou smˇerovaˇce. Pˇrepínání je však odlišné, napˇr. mohou nastat situace, kdy je jeden vstupní rámec pˇreposlán na desítky výstupních portu˚ zaˇrízení. Nejen takové výkonostní testy jsou popsány v druhém dokumentu, RFC 2889. Metodiky provádˇení tˇechto testu˚ jsou navrženy dukladnˇ ˚ eji než v RFC 1944. Nechybí ani popis, jak má vypadat zpráva o probˇehlém testování. Autoˇri opˇet pˇredcházejí špatné interpretaci cˇ tenáˇrem. 2.1.5
RFC zamˇerˇené na testování smˇerovaˇcu˚
•
RFC 3222 Terminology for Forwarding Information Base (FIB) based Router Performance
•
RFC 4098 Terminology for Benchmarking BGP Device Convergence in the Control Plane
•
RFC 4063 Considerations When Using Basic OSPF Convergence Benchmarks
•
RFC 4062 OSPF Benchmarking Terminology and Concepts
•
RFC 4061 Benchmarking Basic OSPF Single Router Control Plane Convergence
2.2
Dokumenty pracovní skupiny IPPM
2.2.1
RFC 2330
Další pracovní skupina organizace IETF, IP Performance Metrics, postupovala v poˇcátcích stejnˇe jako Benchmarking Methodology Working Group. Nejprve vydala v roce 1998 RFC 2330 Framework for IP Performance Metrics[9]. Stalo se tak v roce 1998. Tento rámcový dokument obsahuje definice používané v dalších RFC skupiny. Dále jsou v nˇem uvedeny obecné požadavky na testy (napˇr. opakovatelnost testu), urˇceny povolené mˇerné jednotky a jejich správné používání, diskutují se chyby mˇerˇ ení (a rozdíly mezi chybami mˇerˇ ení a mˇerˇ enou charakteristikou). Tvurci ˚ dokumentu pohlížejí na danou problematiku komplexnˇeji, uvádˇejí pˇríklad, ve kterém modelují smˇerovaˇc z jednodušších kompoment a na základˇe tohoto modelu urˇcují sledované charakteristiky. Také se zamýšlejí nad „skládáním“ jednotlivých testu˚ (mˇejme cestu skládající se z nˇekolika cˇ ástí, pak výsledné zpoždˇení celé cesty je témˇerˇ rovno souˇctu zpoždˇení jednotlivých cˇ ástí). Další cˇ ást je vˇenována problematice pˇresného cˇ asu v sítích. Následuje rozdˇelení metrik: •
atomické (sigleton),
•
vzorkovací, 12
2.2. DOKUMENTY PRACOVNÍ SKUPINY IPPM •
statistické.
Pˇríkladem atomické metriky je propustnost, i když se tento test skládá z dílˇcích testu. ˚ Vzorkovací metrika opakovanˇe používá atomickou metriku (v pˇredem urˇceném cˇ ase odebírá vzorek). Napˇr. pˇri testování zpoždˇení v jednom smˇeru po dobu jedné hodiny provádíme dílˇcí mˇerˇ ení v cˇ ase urˇceném Poissonovým rozložením. Uvˇedomme si, že napˇr. test zpoždˇení uvádˇený v RFC 2544 je vlastnˇe také vzorkovací metrikou – podle specifikace by se mˇel provádˇet nejménˇe dvacetkrát, tzn. vzorkování je periodické a atomická metrika je tak jeden test zpoždˇení pro urˇcitý typ rámce. Statistiská metrika produkuje hodnoty pomocí statistické funkce aplikované na již namˇerˇ ené hodnoty získané vzorkovací metrikou (napˇr. hodnota aritmetického prumˇ ˚ eru všech vzorku˚ získaných v pˇredchozím pˇríkladˇe). Ve zbylé cˇ ásti textu autoˇri rozebírají výhody a nevýhody používání ruzných ˚ statických rozložení používaných pˇri mˇerˇ ení dané charakteristiky. Poukazují na to, že periodické vzorkování nemusí postihnout veškeré chování testovaného zaˇrízení (dokonce je muže ˚ negativnˇe ovlivnit) nebo na možnost „zneužití“ výrobci, kteˇrí mohou s tímto bˇežnˇe rozšíˇreným a jednoduchým typem vzorkování poˇcítat a zámˇernˇe tak modifikovat chování produktu. Proto navrhují používat jiné než periodické vzorkování. Takové, kde je velikost intervalu mezi jednotlivými mˇerˇ eními náhodná, pˇredem neznámá. Avšak základní vlastnost všech testu˚ uvedená v tomto dokumentu je jejich opakovatelnost. Tu tˇežko mužeme ˚ garantovat, pokud je velikost intervalu zcela náhodná. Proto se používají statistická rozložení, funkce, které zaruˇcí generování „náhodných“ intervalu˚ podle jistých pravidel. Tvurci ˚ dokumentu doporuˇcují používat vzorkování s Poissonovým rozložením, protože není pˇredvídatelné, za jak dlouhou dobu po posledním dílˇcím mˇerˇ ení probˇehne další. Implementace tohoto zpusobu ˚ vzorkování není triviální. Musíme disponovat generátorem pseudonáhodných cˇ ísel, který bude produkovat hodnoty v intervalu 0 až 1 s rovnomˇerným rozložením. Hodnoty pˇredložíme funkci, která spoˇcte výslednou délku intervalu. Poˇckáme daný cˇ as a provedeme mˇerˇ ení (odebereme vzorek). Vygenerujeme další pseudonáhodné cˇ íslo a vypoˇcteme další cˇ as, po který budeme cˇ ekat a pak mˇerˇ it atd. Tato jednoduchá technika má však své nevýhody. Mˇerˇ ení nejsou provádˇena pˇresnˇe po uplynutí spoˇcteného cˇ asu. Samotné mˇerˇ ení totiž trvá nenulový cˇ as. Ve skuteˇcnosti je tedy další test proveden po delší dobˇe než mˇel puvodnˇ ˚ e být. Vzorkování tudíž už nekoresponduje s Poissonovým rozložením. Samozˇrejmˇe, že lze provést další mˇerˇ ení po cˇ ase rovnající se rozdílu délky cˇ ekacího intervalu a cˇ asu mˇerˇ ení, ale to už vyžaduje dodateˇcné režie – musíme mˇerˇ it cˇ as testu (toto mˇerˇ ení nemusí být z nejruznˇ ˚ ejších duvod ˚ u˚ pˇresné). Problém nastane pokud je cˇ as mˇerˇ ení vˇetší než cˇ ekací interval. Pokud mužeme ˚ provádˇet více mˇerˇ ení v jednom cˇ ase (vˇetšinou to neplatí), autoˇri doporuˇcují vygenerovat posloupnost intervalu˚ a jednotlivé cˇ asy mˇerˇ ení na zaˇcátku testování. Tím je pˇredcházející problém vyˇrešen. Pro jistotu bychom mˇeli ovˇerˇ it, zda cˇ asy, ve kterých skuteˇcnˇe probˇehlo mˇerˇ ení, odpovídají Poissonovu rozložení. V dodatku tohoto RFC je uveden zdrojový kód programu v jazyce C, který provádí takový test. Vzorkování s Poissonovým rozložením pˇrináší pˇri správné implementaci jisté výhody oproti periodickému vzorkování za cenu velkých režií. 13
2.2. DOKUMENTY PRACOVNÍ SKUPINY IPPM V další kapitole je diskutována prezentace namˇerˇ ených hodnot formou percentilu. ˚ Následuje rozprava o pravdˇepodobnostech v metrikách. Nedoporuˇcuje se používat tvrzení typu pravdˇepodonost ztráty paketu˚ mezi uzly A a B je 0,73, ale ztratilo se 73 paketu˚ ze 100. První tvrzení vyznívá všeobecnˇe, druhé je pˇresnˇejší. Autoˇri nabádají k užívání tvrzení druhého typu, je pro cˇ tenáˇre srozumitelnˇejší. Na základˇe pˇredloženého resumé mužeme ˚ konstatovat, že tvurci ˚ RFC 2330 využívají v testování statistický aparát, jehož pochopení a implementace klade na tvurce ˚ testovacích nástroju˚ další nároky. Na základech tohoto dokumentu stojí následující RFC pracovní skupiny IP Performance Metrics. 2.2.2
RFC 2678
O rok pozdˇeji, v roce 1999, vyšel RFC 2678 IPPM Metrics for Measuring Connectivity[12]. V tomto dokumentu jsou popsány základní metriky konektivity, tj. dosažitelnosti jednotlivých stroju˚ nebo rozhraní (v jednom stroji muže ˚ být více rozhraní) v urˇcitém cˇ ase cˇ i cˇ asovém intervalu. Kromˇe cˇ asových údaju˚ jsou parametry metrik zdrojové a cílové IP adresy. Dokument rozlišuje následující typy: •
jednosmˇerná konektivita v urˇcitém cˇ asovém okamžiku t,
•
obousmˇerná konektivita v urˇcitém cˇ asovém okamžiku t,
•
jednosmˇerná konektivita v urˇcitém cˇ asovém intervalu dt,
•
obousmˇerná konektivita v urˇcitém cˇ asovém intervalu dt,
•
„obecná“ obousmˇerná konektivita v urˇcitém cˇ asovém intervalu dt.
Poslednˇe zminovaný ˇ typ metriky zkoumá, zda po odeslání paketu˚ urˇcitého typu bude pˇrijata odezva ve formˇe paketu˚ jiného typu. Pˇrecházející obousmˇerné metriky pˇredpokládají pakety stejného typu, proto je tato metrika v jistém smyslu obecná. Hodnotou tˇechto metrik je binární hodnota pravda nebo nepravda. Autoˇri textu si uvˇedomují, že v pˇrípadˇe užití navrhovaných metod provádˇení metrik se spojitým cˇ asovým intervalem dochází v praxi k urˇcité nepˇresnosti a nekonzistenci s definicí: daná metodologie totiž nezkoumá konektivitu v každém cˇ asovém okamžiku, ale jen v urˇcitých cˇ asech v daném intervalu dt. 2.2.3
RFC 2679 a RFC 2680
Ve stejné dobˇe jako RFC 2678 vychází i RFC 2679 A One-way Delay Metric for IPPM[13] a RFC 2680 One Way Packet Loss Metric for IPPM[14]. Tyto dokumenty se vˇenují mˇerˇ ení zpoždˇení resp. ztrátovosti paketu, ˚ mají stejnou strukturu. Definují atomické (singleton) metriky a na nich postavené vzorkovací a statistické, které jsou odvozeny ze vzorkovacích. 14
2.2. DOKUMENTY PRACOVNÍ SKUPINY IPPM Nejprve jsou vyjmenovány nejruznˇ ˚ ejší aspekty, proˇc je vubec ˚ dobré zpoždˇení nebo ztrátovost mˇerˇ it. To ve výše jmenovaných dokumentech skupiny BMWG chybí. Dalším tématem je pˇresný cˇ as a definice souvisejících pojmu. ˚ Pak již následují samotné definice metrik zpoždˇení resp. ztrátovosti, které jsou cˇ lenˇeny následovnˇe (pˇríklad pro atomickou metriku jednosmˇerné zpoždˇení je uveden v závorce): •
název metriky (jednosmˇerné zpoždˇení paketu˚ urˇcitého typu),
•
parametry (zdrojová a cílová IP adresa stroju˚ pˇríp. rozhraní, cˇ as),
•
jednotky (reálné cˇ íslo udávající poˇcet sekund nebo nekoneˇcno),
•
definice (jednosmˇerné zpoždˇení pro pakety urˇcitého typu putující ze zdrojové do cílové adresy je reálné cˇ íslo, které udává cˇ as, který uplyne mezi odesláním prvního bitu paketu z vysílací stanice a pˇrijetím posledního bitu v pˇrijímací stanici; pokud zaslaný paket není pˇrijat, zpoždˇení je rovno nekoneˇcnu),
•
diskuze (napˇr. reálné hodnoty zpoždˇení jsou vˇetší než 0 sekund),
•
metodologie (zajistíme cˇ asovou synchronizaci stanic, sestavíme testovací paket, v cílové stanici se pˇripravíme na pˇríchod tohoto paketu, ve zdrojové stanici umístíme do již sestaveného paketu cˇ asovou známku a odešleme jej; pokud paket dorazí v „rozumném“ cˇ ase, pˇreˇcteme co nejdˇrív jeho cˇ asovou známku a odeˇcteme ji od cˇ asu pˇríchodu paketu, dále musíme vzít v úvahu cˇ as, který uplnyne od vystavení cˇ asové známky a skuteˇcného odeslání resp. pˇrijetí paketu nebo rozdíl v pˇresném cˇ ase obou stanic),
•
chyby a problémy (zde jsou podrobnˇe diskutovány rozdíly v cˇ asování stanic, rozdíly mezi cˇ asem odeslání resp. pˇríjmu na rozhraní a v softwaru a jejich následná kalibrace),
•
prezentace výsledku˚ (popis kalibrace a prostˇredí, v nˇemž bylo provedeno mˇerˇ ení by mˇelo být souˇcástí testovací zprávy, dále pˇresná specifikace použitého paketu, rozpoznávání, kdy je zpoždˇení rovno nekoneˇcnu, výsledky kalibrace, cesta, po které paket prošel).
RFC 2679 definuje kromˇe atomické metriky jednosmˇerné zpoždˇení paketu˚ urˇcitého typu vzorkovací metriku jednosmˇerné zpoždˇení toku paketu˚ s Poissonovým rozložením a odvozené statistické metriky percentily jednosmˇerného zpoždˇení toku paketu˚ s Poissonovým rozložením, jednosmˇerné zpoždˇení toku paketu˚ s Poissonovým rozložením, medián jednosmˇerného zpoždˇení toku paketu˚ s Poissonovým rozložením, minimální jednosmˇerné zpoždˇení toku paketu˚ s Poissonovým rozložením, invertované percentily jednosmˇerného zpoždˇení toku paketu˚ s Poissonovým rozložením. Obdobné metriky pro ztrátovost jsou definovány v RFC 2680. 15
˚ SKUPIN BMWG A IPPM 2.3. SROVNÁNÍ DOKUMENT U 2.2.4
RFC 2681
Tento dokument navazuje obsahem i strukturou na RFC 2679. RFC 2681 Round-trip for Delay Metric for IPPM[15] se zamˇerˇ uje na korektní zjištˇení zpoždˇení „otáˇcky“ (round-trip time) mezi zdrojovým a cílovým uzlem. Autoˇri pohlížejí na celou problematiku komplexnˇeji. Upozornují, ˇ že v mnohých pˇrípadech nelze pouze seˇcíst cˇ asy, které nám poskytnou dvˇe jednosmˇerné metriky. 2.2.5
RFC 3357
V roce 2002 byl vydán RFC 3357 One-way Loss Pattern Sample Metrics[17], který využívá metrik, jenž byly popsány v RFC 2680. Dokument je zamˇerˇ en na zjišt’ování struktury ztrát v daném datovém toku, ne pouze na prosté konstatování, že pakety byly cˇ i nebyly ztraceny ; definuje dvˇe základní metriky vzdálenost ztráty (loss distance) a periodu ztráty (loss period) a další odvozené, statistické metriky. 2.2.6
RFC 3393
RFC 3393 IP Packet Delay Variation Metric for IP Performance Metrics[18] se zabývá definicí metriky jednosmˇerný rozptyl zpoždˇení a z ní odvozených metrik. Autoˇri opˇet odkazují na pˇredcházející dokument, konkrétnˇe RFC 2679. Jednosmˇerný rozptyl zpoždˇení je pak vypoˇcten z rozdílu˚ jednotlivých hodnot jednosmˇerného zpozdˇení.
2.3
Srovnání dokumentu˚ skupin BMWG a IPPM
Výše uvedený pˇrehled dokumentu˚ obou skupin pˇrímo vybízí ke srovnání. Ve svˇetˇe informaˇcních a komunikaˇcních technologií se obˇcas užívají výrazy, které jsou zdánlivˇe zamˇenitelné a tudíž mohou být vykládány pokaždé jinak. Proto obˇe skupiny nejprve definovaly základní pojmy, aby pˇredešly možným zmatkum. ˚ Název pracovní skupiny IP Performance Metrics napovídá, že se bude jednat o mˇerˇ ení výkonostních charakteristik v sítích používající Internet Protocol. Skuteˇcnˇe, dokumenty skupiny se vubec ˚ nezabývají sít’ovými vrstvami, které leží pod IP. Linková a fyzická vrstva jsou pro tato mˇerˇ ení transparentní. Naopak pracovní skupina BMWG se ve svých dokumentech tˇemito vrstvami zabývá. Napˇr. pro ruzná ˚ média definuje jiné parametry testu: ˚ pro Ethernet uvádí jiné délky rámcu˚ než pro Token Ring nebo FDDI. Pˇri testování podle dokumentu˚ BMWG je použito „laboratorní prostˇredí“. Organizace IANA, která se mj. stará o pˇridˇelování IP adres, poskytla BMWG urˇcitý rozsah adres pro potˇreby testování. Testovací a testovaná zaˇrízení jsou zapojena v umˇelé síti, v mnohých pˇrípadech velmi jednoduché (testovací zaˇrízení je pˇrímo pˇripojeno k testovanému). Zato IPPM blíže nespecifikuje zpusob ˚ zapojení a ani nevyluˇcuje testování v reálné síti (jako BMWG), kde muže ˚ být mezi stanicemi, mezi nimiž probíhá mˇerˇ ení, nˇekolik dalších sítí, smˇerovaˇcu˚ nebo pˇrepínaˇcu. ˚ Doporuˇcení BMWG je tedy vhodné používat pˇri vývoji jednoho konkrétního zaˇrízení a metriky IPPM pro charakterizaci sítˇe v bˇežném provozu. 16
˚ SKUPIN BMWG A IPPM 2.3. SROVNÁNÍ DOKUMENT U Tyto metriky jsou dle mého názoru dobˇre vystavˇeny. Pokud je namodelujeme jako tˇri na sobˇe ležící vrstvy, vidíme, že každá další metrika (vzorkovací, statistická) je odvozena od pˇredcházejících. Atomické metriky jsou tedy základem všech ostatních. Vzorkovací metriky neobsahují pouze bˇežné, periodické vzorkování, ale pro praxi výhodnˇejší s Poissonovým, pˇríp. geometrickým rozložením. Jestliže se takto pokusíme modelovat testy definované BMWG, dostaneme nejvýše jen dvˇe vrstvy: atomický, dílˇcí test, který je nˇekolikrát za sebou opakován, tj. probíhá periodické vzorkování (ˇcili jen podmnožina vzorkování, které definuje IPPM). Na druhou stranu jiná vzorkování jsou nároˇcnˇejší na implementaci. Statistický pˇrístup je v tˇechto testech použit pouze do té míry, že je spoˇcten aritmetický prumˇ ˚ er a jeho hodnota je považována za výsledek testu. Metodika jednotlivých testu˚ je v RFC skupiny BMWG popsána vágnˇe. To nám zase ale pˇrináší urˇcitou volnost pˇri provádˇení testu. ˚ V dokumentech skupiny IPPM nalezneme detailnˇejší popis a hlavnˇe je u každého testu diskuze zamýšlející se nad možnými výsledky a upozornující ˇ na chyby, které mohou nastat a ovlivnit celé testování. Dále bych se zastavil u typu˚ testu, ˚ které dané dokumenty skupin specifikují. BMWG popisuje test zpoždˇení, avšak už pomíjí duležitou ˚ charakteristiku sítˇe, kterou je rozptyl zpoždˇení. V dnešní dobˇe rozvoje multimediálních, pˇredevším hlasových a videokonferenˇcních aplikací je potˇreba znát rozptyl zpoždˇení stejnˇe jako napˇr. propustnost. Pˇredevším lidské ucho je ve výsledku k velkým hodnotám rozptylu velmi netolerantní. IPPM vˇenovala mˇerˇ ení rozptylu dokonce celý RFC. Stejnˇe tak metrikám konektivity. Domnívám se, že testování konektivity považovala BMWG za zbyteˇcné, protože se v laboratorním prostˇredí oˇcekává splnˇení tohoto základního požadavku. Avšak v reálných sítích tuto jistotu nemáme. Další rozdíl spatˇruji napˇr. v testu ztrátovosti. V dokumentu BMWG je výsledkem testu kolik procent paketu˚ se ztratilo, tj. sumární informace, zatímco metrika IPPM nám podává informaci o struktuˇre tˇechto ztrát. Naopak RFC skupiny IPPM neobsahují testy typické pro zkoušení jednotlivých zaˇrízení (napˇr. zotavení se po pˇretížení nebo restartu), jsou zamˇerˇ eny na celou sít’. Obˇe skupiny dbají na to, aby byly výsledky testu˚ prezentovány v jednoznaˇcné podobˇe a nedocházelo tak k rozdílné interpretaci namˇerˇ ených hodnot; definují, jak má vypadat testovací zpráva.
17
Kapitola 3
Testovací nástroje V pˇredcházejícím textu jsem zrekapituloval dokumenty zabývající se definicemi nejruznˇ ˚ ejších testu. ˚ V této kapitole budu sledovat, do jaké míry se tyto, mnohdy ideální pˇredstavy, stˇretávají se skuteˇcností. Zamˇerˇ ím se na oblast testovacích nástroju, ˚ které fungují na platformˇe osobních poˇcítaˇcu. ˚ Tuto oblast mužeme ˚ dále rozdˇelit na dvˇe velké skupiny. Softwarové nástroje Programové vybavení, které dokáže produkovat testovací pakety, posílat je na pˇríslušné sít’ové rozhraní poˇcítaˇce a analyzovat pakety pˇricházející na stejné nebo jiné rozhraní, budeme v tomto textu oznaˇcovat termínem softwarový testovací nástroj. Software tedy zajišt’uje veškerou požadovanou funkcionalitu: napˇr. sestavení testovacího paketu urˇcitého druhu s daným obsahem, vytvoˇrení toku z tˇechto paketu˚ podle zadaných parametru, ˚ odeslání tohoho toku na pˇríslušné rozhraní v pˇresném cˇ ase, souˇcasné zpracování pˇríchozích paketu˚ a jejich analýzu. Hardwarové nástroje Pokud je cˇ ást funkcí testovacího nástroje implementována pˇrímo v hardwaru (napˇr. odesílání již pˇripravených paketu˚ v pˇresném cˇ ase nebo analýza pˇricházejících paketu) ˚ a software obstarává spíše konfiguraci testu˚ a výslednou prezentaci namˇerˇ ených hodnot, budeme hovoˇrit o hardwarových testovacích nástrojích. Uvˇedomme si, že takové oznaˇcení není zcela pˇresné – koliduje s oznaˇcením výhradnˇe hardwarových nástroju, ˚ avšak pohybujeme-li se v oblasti vymezené platformou PC, nemuže ˚ tato nejednoznaˇcnost nastat. Pokud jsou urˇcité funkce implementovány pˇrímo v hardwaru, chápejme to tak, že tyto funkce nevyužívají žádné systémové prostˇredky poˇcítaˇce, který ovládá testovací nástroj. Na hardwarovou cˇ ást pohlížejme jako na blackbox.
3.1
Softwarové testovací nástroje
Pˇrehled softwarových testovacích nástroju, ˚ které plní na jednom poˇcítaˇci funkci generátoru paketu˚ a na druhém stroji analyzují pˇríchozí provoz, sestavil ve své diplomové práci[1] Jan Bartonˇ v roce 2004. V dalším textu rozeberu zmˇeny v nových verzích tˇechto nástroju˚ z pohledu uživatele, testera. Jiný relevantní dokument, RFC 2398 Some Testing Tools for TCP Implementors[10] z roku 1998, nepopisuje vyjma zmínˇených další vhodné nástroje. RFC obsahuje výˇcet užiteˇcných programu, ˚ jež ovšem vykonávají pouze urˇcitou cˇ ást funkcí, které by mˇel kvalitní testovací software poskytovat. Napˇr. jeden nástroj jen pˇríjmá pakety, druhý je pouze analyzuje atp. Na závˇer této cˇ ásti bude diskutován nástroj DPTT, který vytvoˇril Jan Bartonˇ v rámci své diplmové práce. 18
3.1. SOFTWAROVÉ TESTOVACÍ NÁSTROJE 3.1.1
DBS 1.2.0 beta 1
Po verzi 1.1.5, která je popsána ve výše zminovaném ˇ pˇrehledu, vyšla pouze první betaverze 1.2.0, která umožnuje ˇ narozdíl od pˇrechozí verze dlouhotrvající testy (dokáže pˇrenést více než 4 GB dat). 3.1.2
IPerf 2.0.2
V kvˇetnu roku 2005 byla uvolnˇena verze 2.0.2. Tato verze má zvláštní statut. Na domovské stránce tohoto softwaru jsou k dispozici ke stažení zdrojové kódy pouze se základní dokumentací. Kromˇe podrobného manuálu, který je tam vystaven pro verzi 1.7.0, chybí i seznam zmˇen. Z pohledu uživatele tedy není zˇrejmé, co se zmˇenilo a tudíž se nemuže ˚ rychle rozhodnout, zda bude instalovat tuto verzi nebo zustane ˚ u pˇredchozí. Jedinou možností (avšak cˇ asovˇe nároˇcnou), jak to zjistit, je dukladnˇ ˚ e prostudovat zdrojové kódy staré a nové verze. 3.1.3
NetPerf 2.4.2
Tento testovací nástroj prodˇelal znaˇcný vývoj (bylo vydáno sedm dalších verzí). Oproti verzi 2.2pl4 byla vylepšena podpora pro operaˇcní systémy Microsoft Windows, MacOS X a FreeBSD. Uživatel nyní muže ˚ specifikovat IP adresy a porty, které bude v testech používat. To je užiteˇcné, pokud je v síti zapojen firewall. Autoˇri také sepsali uživatelskou dokumentaci a ukázkové testovací skripty. Byla pˇridána automatická detekce vytížení procesoru a alternativní zpusob ˚ cˇ asování, což muže ˚ vést k pˇresnˇejšímu testování. Nyní lze specifikovat, zda bude ovládací spojení využívat IPv4 nebo IPv6. Samozˇrejmˇe byly odstranˇeny drobné chyby. 3.1.4
NetPIPE 3.6.2
Od verze 3.3.3 spatˇrily svˇetlo svˇeta další cˇ tyˇri verze. Kvuli ˚ nepˇresnosti se již neprovádí mˇerˇ ení vytíženosti procesoru. Od verze 3.5 by nemˇel nastat problém s velikostí TCP okna v testech na gigabitových sítích. Významnou novinku pˇrinesla verze 3.6.1. Jedná se o podporu obousmˇerného testování. Aktuální verze odstranuje ˇ problémy vysktytující se na 64bitové architektuˇre a pˇreklep, který zpusobil ˚ potíže v nˇekterých linuxových distribucích. 3.1.5
NetSpec 5.0
Po verzi 3.0 se objevila až verze 5.0. Duvodem ˚ takového skoku je zmˇena vývojového týmu. Verze 3.0 již není podporována. Koncepci fungující verze 5.0 a pˇripravované verze 6.0, která je ve fázi návrhu, pˇredstavuje Radhakrishnan R. Mukkai ve své diplomové práci Design of the new and improved NetSpec controller[5]. Hlavní zmˇeny verze 5.0 zahrnují nové zpu˚ soby provádˇení ruzných ˚ fází testu a nový typ démona, který umožnuje ˇ spouštˇet další démony a pˇríkazy na více strojích. 19
3.1. SOFTWAROVÉ TESTOVACÍ NÁSTROJE 3.1.6
RUDE & CRUDE 0.70
Od roku 2002 se neobjevila žádná nová verze. 3.1.7
TReno
Ani u tohoto nástroje jsem nenašel novˇejší verzi. 3.1.8
TTCP6
Pokud nebereme v úvahu verze pro rodinu operaˇcních systému˚ Microsoft Windows, tak i tento nástroj se nijak dále nevyvíjí. 3.1.9
DPTT
Pˇri analýze volnˇe dostupných testovacích nástroju˚ Jan Bartonˇ zjistil, že žádný z výše popsaných nástroju˚ nesplnuje ˇ všechny požadavky udané RFC 2544. Protokol IPv6 podporovaly jen nástroje IPerf a TTCP6, cˇ ásteˇcnˇe NetPerf. Dále uvádí, že na jednom bˇežném osobním poˇcítaˇci s 32bitovou PCI sbˇernicí bˇežící na 33 MHz nelze generovat pakety vˇetší rychlostí než 500 Mb/s. Tato rychlost je pro potˇreby testování prvku˚ sít’ové infrastruktury, které mají operovat na gigabitových rychlostech, zcela nedostateˇcná. Autor navrhl testovací nástroj Distributed Performance Testing Tool (DPTT) pro operaˇcní systém Linux. Tento nástroj má zahrnovat celou sadu testu˚ popsanou v RFC 2544. Jako první test, který se autor rozhodl implementovat, byl test propustnosti do rychlosti 100 Mb/s. Již samotný název nástroje napovídá, že nejspíš pujde ˚ o software pracující na více poˇcítaˇcích. Skuteˇcnˇe, jeden poˇcítaˇc funguje jako mozek (na nˇem bˇeží program dptt), který pˇredává povely ostatním poˇcítaˇcum ˚ (tam naslouchá démon). Ty pak teprve slouží jako generátory a analyzátory paketu. ˚ Pro obousmˇerné testování propustnosti tedy potˇrebujeme pˇet stanic: ovládací, generátor provozu v jednom a druhém smˇeru a analyzátor provozu také v obou smˇerech. Komunikace mezi stanicemi probíhá formou zpráv zasílaných po komunikaˇcní síti, která je samozˇrejmˇe oddˇelena od testovací sítˇe. Nastavení jednotlivých testu˚ provádí ovládací stanice na základˇe pˇredloženého konfiguraˇcního souboru. V závˇeru Bartonovy ˇ diplomové práce se doˇcteme, že uvedený software dokáže mˇerˇ it propustnost s jednoprocentní chybou, což pro stomegabitové sítˇe postaˇcuje. Lepší pˇresnosti nelze na bˇežném PC dosáhnout, aniž bychom použili upravené jádro operaˇcního systému Linux. Autor podotýká, že nepˇresné cˇ asování znemožnuje ˇ implementovat další testy RFC 2544. Problematickou oblastí jsou krátké rámce, které musí nástroj vyslat za sebou v malých, pˇresnˇe definovaných intervalech (jednotky mikrosekund). Dále uvádí, že software lze modifikovat pro testování gigabitových sítí. Pokud bychom nasadili tˇri stroje jako generátor paketu, ˚ dostali bychom se na hranici 1 Gb/s. Uvˇedomme si, že tak ale vzroste poˇcet stroju, ˚ které musíme spravovat a sledovat, zda všechny skuteˇcnˇe fungují. Jestliže zustane ˚ zachována chyba mˇerˇ ení 1 %, v pˇrípadˇe gigabitových sítí se dostáváme až k cˇ íslu 10 Mb/s. Podobnˇe vzroste požadavek na pˇresnost cˇ asování v rˇ ádu zlomku˚ mikrosekund. 20
3.2. HARDWAROVÉ TESTOVACÍ NÁSTROJE
3.2
Hardwarové testovací nástroje
3.2.1
Spirent/Adtech AX/4000
Spirent Communications je jedním z nejvˇetších výrobcu˚ testovacích nástroju˚ komunikaˇcních technologií na svˇetˇe. Testovací nástroj AX/4000 zahrnuje hardware a pˇríslušné softwarové vybavení. Systém umožnuje ˇ testovat funkcionalitu a výkon vysokorychlostních, až desetigigabitových sítí. Jeho návrh bych pˇrirovnal k rozšiˇritelné stavebnici, kterou je možno postupnˇe skládat. Základ tvoˇrí modul, do kterého lze jednoduše vložit kartu s pˇríslušným rozhraním (stejnˇe jako když skládáme osobní poˇcítaˇc). Tato karta obsahuje port pro urˇcité rozhraní, generátor provozu (uživatelem definovaných proudu˚ paketu) ˚ a analyzátor pˇríchozích paketu. ˚ Firma vyrábí ruznˇ ˚ e velké základní moduly. Menší, pˇrenosný modul lze osadit cˇ tyˇrmi kartami, vˇetší až šestnácti. Zpusob ˚ ovládání celého systému je zajímavý. Uživatel tak cˇ iní vzdálenˇe ze svého poˇcítaˇce, jenž je pˇripojen k systému ethernetovou sítí. S jedním nástrojem muže ˚ pracovat více uživatelu. ˚ Standardnˇe dodávaný software je tvoˇren konfiguraˇcními a ovládacími programy s grafickým uživatelským rozhraním (GUI). Tyto programy pracují v operaˇcních systémech Microsoft Windows nebo Sun Solaris. Dále lze dokoupit ovládací knihovnu, která zpˇrístupní systém ve skriptovacím jazyku Tcl a jazyku C. Podle pˇríslušné karty a portu jsou uživateli zpˇrístupnˇeny funkce pro dané rozhraní. Výrobce uvádí, že systém splnuje ˇ požadavky kladené na testy, tak jak to uvádí RFC 2544. Podpora protokolu IPv6 je samozˇrejmostí. 3.2.2
Agilent N2X
Spoleˇcnost Agilent nabízí komplexní testovací nástroj N2X, jež se v mnohém podobá pˇredcházejícímu systému. Architektura je v podstatˇe stejná. Systém je také rozdˇelen na více modulu˚ a karet, které poskytují rozhraní pro ruzné ˚ typy médií. Oproti AX/4000 je pˇridána další úroven, ˇ tzv. controller, hardware ovládající základní moduly, do nichž se pˇripojují karty s pˇríslušným rozhraním. Jednotlivé moduly lze zˇretˇezit, zapojit za sebe (výrobce garantuje rozdíl v synchronizaci do 10 ns) a získat tak testovací prostˇredí s pˇresnˇe požadovaným pocˇ tem portu, ˚ prostˇredí na míru. Moduly se vyrábˇejí v provedení pro dvˇe nebo cˇ tyˇri karty, které mohou být vymˇenˇeny za provozu (tzv. hot swap). Controller je ve skuteˇcnosti poˇcítaˇc (Agilent nabízí tˇri ruznˇ ˚ e výkonné stroje) s operaˇcním systémem Microsoft Windows. Testovací karty jsou rozdˇeleny podle typu testování do tˇechto cˇ tyˇr kategorií: •
generátor a analyzátor paketu˚ (nepodporují smˇerovací a další protokoly),
•
generátor, analyzátor a emulace smˇerovacích a dalších sít’ových protokolu˚ (napˇr. BGP, OSPF, RIP),
•
generátor, analyzátor a emulace smˇerovacích protokolu˚ v rozsáhlých sítích,
•
testování sítí SONET/SDH. 21
3.2. HARDWAROVÉ TESTOVACÍ NÁSTROJE Na každé kartˇe je jeden až šestnáct portu, ˚ v rámci jedné kategorie jsou podporovány ruzné ˚ technologie (metalický a optický Ethernet, OC-3 až OC-192, ATM). Software s grafickým uživatelským rozhraním je rozdˇelen do nˇekolika programových balíku, ˚ zhruba podle kategorií karet. Napˇr. Traffic Generation & Analysis nabízí minimálnˇe stejnou funkcionalitu jako základní software dodávaný k AX/4000. Podpora Tcl skriptu˚ pro automatizaci testování je taktéž zajištˇena. Ani u tohoto produktu nechybí podpora IPv6. Knihovna skriptu˚ QuickTest Scripts obsahuje i testy popsané v RFC 2544. 3.2.3
Ixia
Také firma Ixia vsadila jako pˇredchozí spoleˇcnosti na modulární návrh celého nástroje. Nabízí malý, avšak snadno pˇrenosný systém IXIA 250, který obsahuje vestavˇenou dotykovou obrazovku, klávesnici a touchpad. Jinak je to bˇežný osobní poˇcítaˇc s operaˇcním systémem Microsoft Windows 2000. Do tohoto základního modulu mužeme ˚ vložit až dvˇe testovací karty. IXIA 400T poskytuje cˇ tyˇri a IXIA 1600T šestnáct pozic pro testovací karty. Tato zaˇrízení také obsahují PC se stejným operaˇcním systémem, avšak už chybí vestavˇený displej a ovládací periferie. Stejnˇe jako Agilent NX2, tak i tento nástroj umožnuje ˇ zˇretˇezit jednotlivé moduly (i stejný rozdíl v synchronizaci je garantován) a ovládat je vzdálenˇe pˇres sít’ (více uživatelu˚ muže ˚ pracovat s jedním modulem). Pro komplexní testování velkých a vysokorychlostních sítí je urˇcen modul Optixia XL10 s 10 pozicemi, které mohou být osazeny testovacími kartami pˇrímo za chodu. Celkem muže ˚ být v systému nainstalováno 240 ethernetových metalických portu. ˚ Také 16slotový modul Optixia X16 je vhodný pro veškeré testování na druhé až sedmé vrstvˇe sít’ového ISO/OSI modelu. Rozšiˇrující testovací karty dovedou obsluhovat nejruznˇ ˚ ejší média: metalický a optický Ethernet, OC-3 až OC-192. Ovládací programové vybavení nástroje muže ˚ být ruznorodé, ˚ Ixia nabízí aplikace pro testování na všech vrstvách s výjimkou první, fyzické. Nechybí ani podpora Tcl jako skriptovacího jazyka pro automatizované testy. Software IxScriptMate dokonce nabízí skripty pro automatické testování podle RFC 2544 a RFC 2889. Všechny zminované ˇ nástroje spoleˇcnosti Ixia dovedou pracovat s protokolem IPv6. 3.2.4
Anritsu
Produkty spoleˇcnosti Anritsu se nijak nevymykají trendu v oblasti hardwarových testovacích nástroju. ˚ Stejnˇe jako výše zminované ˇ firmy nabízí nˇekolik základních modulu: ˚ pˇrenosný s vestavˇeným displejem a ovládacími prvky, který poskytuje dvˇe pozice pro testovací karty (MD1231A1), pˇetislotový, jenž také obsahuje poˇcítaˇc (MD1230B) a cˇ trnáctislotový (MT7407A), který se ovládá po síti. Ve všech tˇechto modulech je nainstalován operaˇcní systém Microsoft Windows. Moduly je možné zapojit za sebe a získat tak až 448 portu˚ pro 22
˚ 3.3. SROVNÁNÍ SOFTWAROVÝCH A HARDWAROVÝCH NÁSTROJ U mˇerˇ ení. Maximálnˇe osm vzdálenˇe pˇripojených uživatelu˚ muže ˚ sdílet jeden modul. Testovací karty se vyrábˇejí v provedení pro desetimegabitový až desetigigabitový Ethernet, OC-3 až OC-192. Software ovládá všechny potˇrebné funkce pro testování – generátor a analyzátor nejruz˚ nˇejších druhu˚ paketu, ˚ emulace smˇerovacích a servisních protokolu. ˚ Automatizované testy podle RFC 2544 a RFC 2889 jsou souˇcástí. K systému lze pˇristupovat i prostˇrednictvím Tcl skriptu. ˚ Ani v podpoˇre protokolu IPv6 nezaostává Anritsu za svými konkurenty.
3.3
Srovnání softwarových a hardwarových nástroju˚
Nyní, když už máme základní povˇedomí o softwarových a hardwarových testovacích nástrojích, mužeme ˚ je srovnat. Duležitým ˚ kritériem pˇri výbˇeru je jistˇe jejich cena. Popsané softwarové nástroje jsou volnˇe dostupné napˇr. prostˇrednictvím internetu. Máme tedy možnost je dokonale vyzkoušet a vybrat si pro nás ten nejvhodnˇejší. Oproti tomu hardwarové nástroje nemohou být ze své podstaty zadarmo, ani si je nemužeme ˚ tak lehce vyzkoušet. Už jen souˇcástky, z nichž jsou složeny, stojí tisíce korun. Navíc výroba tˇechto nástroju˚ je velký obchod. Ceny výše popsaných produktu˚ zaˇcínají na nˇekolika stovkách tisíc korun. Co vlastnˇe dostaneme za takovou cenu? Vyplatí se to vubec? ˚ Záleží na oblasti nasazení. Pokud chceme testovat výkon ne pˇríliš rozsáhlé cˇ i rychlé sítˇe nebo jejích prvku, ˚ postaˇcí nám nˇekterý ze softwarových nástroju. ˚ V pˇrípadˇe vysokorychlostních sítí nebo vývoje sít’ových prvku, ˚ je nasazení hardwarového nástroje nutností. Softwarové nástroje totiž nejsou schopny zvládnout rychlost 10 Gb/s (s problémy je dosažitelná gigabitová hranice). Na vinˇe je pomalá sbˇernice PCI a nedostateˇcnˇe pˇresné cˇ asování. Hardwarové nástroje obsahují dostateˇcnˇe rychlé a pˇresné komponenty pro testování desetigigabitovou rychlostí. Uživatel muže ˚ definovat paket pˇresnˇe podle svých pˇrestav, od nejnižších až po nejvyšší sít’ové vrstvy. Tyto pakety pak muže ˚ ruznˇ ˚ e sdružovat do testovacích proudu˚ a vytváˇret tak rozliˇcné testovací scénáˇre nebo pouze spustit výrobcem již napsané scénáˇre zahrnující testy podle ruzných ˚ RFC. Hardwarové analyzátory disponují dostateˇcnou pamˇetí pro pˇríchozí provoz. Pakety jsou verifikovány, zjišt’uje se poˇradí pˇríchodu atd. To vše souˇcasné softwarové nástroje neumožnují. ˇ Souˇcástí všech popsaných hardwarových nástroju˚ je poˇcítaˇc, mnohdy i displej a ovládací periferie. Když testujeme softwarovými nástroji, musíme vyhradit samostatný stroj cˇ i stroje, které jsou vˇetšinou zcela zamˇestnány odesíláním a pˇrijímáním paketu. ˚ Hardwarové nástroje umožnují ˇ vzdálený pˇrístup pˇres sít’ z našeho poˇcítaˇce. Pouze nastavíme parametry testu˚ a sputíme je, aktivitu pˇrevezme nástroj a my mužeme ˚ pokraˇcovat v práci. Softwarový nástroj dovoluje zpracovávat pakety takových typu, ˚ s jakými dokáže pracovat sít’ová karta nainstalována v daném poˇcítaˇci. Hardwarové nástroje umožnují díky své modulární architektuˇre používat nejruznˇ ˚ ejší rozhraní a to i ve víceportovém provedení. Celé zaˇrízení je pro nás blackbox, cˇ erná skˇrínka, kterou ovládáme pomocí dodaného softwaru s grafickým uživatelským rozhraním nebo pˇres aplikaˇcní rozhraní skriptovacím jazykem Tcl. 23
˚ 3.3. SROVNÁNÍ SOFTWAROVÝCH A HARDWAROVÝCH NÁSTROJ U Programové vybavení poskytuje aplikace pro komplexní testování celé sítˇe. Mužeme ˚ testovat jednotlivé prvky infrastruktury, ale i celé sítˇe, smˇerování mezi nimi a nejruznˇ ˚ ejší endto-end aplikace (napˇr. pˇrenos videa v reálném cˇ ase). Pokud náhodou software nesplnuje ˇ naše pˇredstavy, aplikaˇcní programové rozhraní nám umožnuje ˇ vytvoˇrit testy pˇresnˇe podle potˇreby. Softwarové nástroje nabízejí jen malou podmnožinu funkcí komplexních hadwarových rˇ ešení. Je to pochopitelné. Od nˇekolika jednotlivcu, ˚ kteˇrí vyvíjejí tyto nástroje zadarmo nebo ve svém volném cˇ ase, nemužeme ˚ cˇ ekat stejné výsledky jako od rozsáhlého, dobˇre placeného týmu.
24
Kapitola 4
Implementace skriptu˚ na vybraném nástroji Srovnání hardwarových a softwarových testovacích nástroju, ˚ které zakonˇcovalo pˇrecházející kapitolu, vyznˇelo vcelku jasnˇe pro nasazení hardwarových nástroju˚ v oblasti testování vysokorychlostních sítí a sít’ových prvku. ˚ Do této oblasti zcela jistˇe patˇrí zaˇrízení vyvíjená v rámci projektu Liberouter. V souˇcasnosti bˇežnˇe pracují na gigabitové ethernetové síti a ve vývoji jsou produkty podporující rychlost až 10 Gb/s. Žádný z dostupných softwarových nástroju˚ operující na bˇežném poˇcítaˇci není schopen pracovat s takovými rychlostmi. Pˇri práci na projektu používáme dva hardwarové testovací nástroje Spirent AX/4000, které jsou osazeny testovacími kartami pro gigabitový i desetigigabitový Ethernet a OC48 (s maximální pˇrenosovou rychlostí okolo 2,4 Gb/s). Pokud je v dalším textu uvedeno oznaˇcení AX/4000, mám na mysli právˇe tato zaˇrízení. Nyní se podrobnˇe podívejme, jak lze s tímto nástrojem pracovat. Pˇredpokládejme, že je systém pˇripojen do sítˇe a má pˇriˇrazenu IP adresu.
4.1
Grafické uživatelské rozhraní
Pˇri použití dodaného softwaru s grafickým uživatelským rozhraním (GUI), je postup následující: 1. pokud nejsme pˇrímo u poˇcítaˇce s operaˇcním systémem Microsoft Windows nebo Sun Solaris, pˇripojíme se k takovému stroji pomocí vzdálené plochy, 2. spustíme nástroj pro rezervaci jednotlivých portu˚ (ten se vzdálenˇe pˇripojí k modulu AX/4000) a vybereme porty, které chceme používat; ostatní porty jsou volnˇe k dispozici dalším uživatelum, ˚ 3. spustíme samotný ovládací software (ten opˇet komunikuje s AX/4000 po síti), 4. vybereme pˇríslušné porty a nadefinujeme testovací provoz – proud paketu, ˚ který má být vyslán do testované sítˇe cˇ i zaˇrízení; jednoduše strukturované toky sestavíme bˇehem nˇekolika sekund, ty složitejší mohou zabrat až nˇekolik minut, 5. spustíme celý test a pokud nenastavíme dobu trvání, musíme jej i manuálnˇe ukonˇcit, 6. bˇehem provádˇení testu a samozˇrejmˇe po jeho skonˇcení mužeme ˚ sledovat výsledky analýzy pˇrijatého provozu, 25
4.1. GRAFICKÉ UŽIVATELSKÉ ROZHRANÍ 7. po skonˇcení celého testování uvolníme zarezervované porty pro další uživatele. Pokud netestujeme podle doporuˇcení v RFC 2544, tj. testovací nástroj nepracuje jako generátor a analyzátor provozu zároven, ˇ ale napˇr. pouze jako generátor provozu, analýzu musíme provést sami jinými prostˇredky.
Obrázek 4.1: Snímek obrazovky ovládacího softwaru s GUI
4.1.1
Testování propustnosti
Jedním ze základních testu˚ je test propustnosti podle RFC 2544. Cílem testu je zjistit maximální možnou rychlost (propustnost), pˇri které nejsou zahozeny žádné rámce a to pro pakety délky 64, 128, 256, 512, 1024, 1280 a 1518 bajtu, ˚ pokud testujeme na Ethernetu. Jak se tedy provádí tento test pomocí tohoto nástroje? Po krátké úvaze mužeme ˚ rozdˇelit test na sedm dílˇcích testu, ˚ které mají stejné parametry až na délku paketu. ˚ Body 1 až 3 výše zmínˇeného postupu provedeme jedenkrát, na zaˇcátku celého testování. Bod 7 taktéž jednou, ale až na konci testování. Body 4, 5 a 6 budeme vykonávat opakovanˇe. Pˇredem není jasné, kolik tˇechto pokusu˚ bude. Do jisté míry to však ovlivnuje ˇ použitý algoritmus hledání výsledné hodnoty propustnosti. Postupujme podle algoritmu binárního 26
4.1. GRAFICKÉ UŽIVATELSKÉ ROZHRANÍ pulení. ˚ Následuje cˇ tvrtý bod: nadefinujeme proud paketu, ˚ napˇr. IPv4 po Ethernetu s nejkratší možnou délkou, tj. 64 bajtu˚ a rychlostí zasílání rovnou maximální teoretické rychlosti, kterou dané médium povoluje. Software nám usnadnuje ˇ tento krok tím, že umožnuje ˇ nastavit rychlost i v procentech maximální, nemusíme tedy poˇcítat rychlost v paketech za sekundu. Potom provedeme pátý a šestý bod. Software zobrazí poˇcet ztracených paketu, ˚ pˇrijatých poškozených, poˇcet paketu˚ mimo poˇradí a další statistiky. Pokud do analyzátoru dorazily všechny vyslané pakety (nebo se ztratil pouze jen námi tolerovaný poˇcet), zaˇrízení v testu obstálo a mužeme ˚ pˇristoupit k dalšímu dílˇcímu testu, k testování propustnosti paketu˚ délky 128 bajtu. ˚ V opaˇcném pˇrípadˇe vypoˇcítáme podle algoritmu binárního pulení ˚ rychlost, kterou budeme v tomto dílˇcím testu pokraˇcovat. V našem pˇrípadˇe to je 50 % maximální rychlosti média. Tento výpoˇcet musíme provést sami, software to za nás neudˇelá. Pak vyˇckáme dobu udanou RFC a znovu opakujeme body 3 až 6 do té doby, než získáme hledanou hodnotu. Zpracování výsledku˚ testu˚ je plnˇe v rukou uživatele, testera. Software mu to nijak neusnadnuje. ˇ Z uvedeného postupu vyplývá, že uživatel provádí opakovanˇe nˇekteré operace. Tato rutinní práce spoˇcívá v nastavování parametru˚ po provedení jedné cˇ ásti dílˇcího testu (tj. zjišt’ování, zda se neztratily žádné pakety zaslané urˇcitou rychlostí), která podle RFC trvá minimálnˇe 60 sekund. Uživatel se tedy nemuže ˚ smysluplnˇe vˇenovat jiné cˇ innosti, v minutových intervalech vyhodnocuje, poˇcítá a spouští další dílˇcí testy. Zjištoval jsem, kolikrát musí uživatel nejménˇe kliknout myší, než muže ˚ být provedena urˇcitá fáze testu. Výsledky jsou zachyceny v následující tabulce. Rezervace dvou portu˚ a spuštˇení softwaru Definice jednoduchého testovacího proudu paketu˚ jednoho typu Nastavení délky trvání jedné cˇ ásti dílˇcího testu Zmˇena rychlosti zasílání paketu˚ a opˇetovné spuštˇení testu Zmˇena délky testovacích paketu˚ a opˇetovné spuštˇení testu Ukonˇcení testování a uvolnˇení používaných portu˚
9 15 5 5 5 5
Tabulka 4.1: Poˇcet kliknutí myší od spuštˇení softwaru k provedení dané operace Pokud vezmeme v úvahu pro nás nejpˇríznivˇejší variantu (tj. zaˇrízení obstojí na maximální možné rychlosti), od zaˇcátku do konce testování musíme kliknout celkem 69krát. V pˇrípadˇe neúspˇechu musíme k této minimální hodnotˇe pˇriˇcíst 5p kliknutí, kde p je celkový poˇcet cˇ ástí dílˇcích testu. ˚ V praxi se tato promˇenná pohybovala mezi 4 až 8 pro každou testovanou délku rámce. Uvedené hodnoty platí pro jednosmˇerný test propustnosti. V pˇrípadˇe testovaní v obou smˇerech je poˇcet kliknutí vyšší. Témˇerˇ neustálé klikání je jednou z nepˇríjemných nutností, další je provádˇení algoritmu binárního pulení ˚ a vytvoˇrení testovací zprávy silami uživatele. Na tomto pˇríkladu jsem se pokusil ilustrovat, že software s GUI není vhodné pro opakované vykonávání pˇredem definovaných testu. ˚ Ovšem chceme-li vyzkoušet chování zaˇrízení za urˇcitých, i nám nepˇríliš jasných podmínek, pak nám tento software pˇrehlednˇe a s uživatelským pohodlím odhaluje 27
ˇ 4.2. APLIKA CNÍ PROGRAMOVÉ ROZHRANÍ veškeré možnosti nastavení celého testovací nástroje.
4.2
Aplikaˇcní programové rozhraní
Knihovny pro jazyk Tcl a C nejsou souˇcástí standardní výbavy AX/4000. Ovšem nabízejí všechny funkce testovacího nástroje, jak je známe ze softwaru s GUI. Navíc nejsme omezeni jen na platformy Microsoft Windows a Sun Solaris. Tyto knihovny fungují i v Linuxu. Zvolil jsem si Tcl knihovnu fungující v Linuxu, zejména kvuli ˚ dobré podpoˇre zpracování textu v jazyce Tcl a možnosti používat externí linuxové programy. Jak tedy mužeme ˚ ovládat testovací nástroj pomocí této knihovny? Postupujme podle bodu˚ uvedených v kapitole 4.1. První bod je témˇerˇ stejný. Pokud nejsme pˇrímo u stroje, kde je tato knihovna nainstalována, opˇet se vzdálenˇe pˇripojíme k patˇriˇcnˇe vybavenému stroji. Avšak linuxová platforma umožnuje ˇ pˇripojení pˇres vzdálený terminál. Tento zpusob ˚ pˇripojení klade mnohem nižší nároky na výkon sítˇe než pˇripojení prostˇrednictvím vzdálené plochy. Potom musíme naˇcíst Tcl knihovnu a nastavit cestu ke konfiguraˇcním souborum ˚ nástroje. Druhý bod provedeme pomocí dvou jednoduchých pˇríkazu˚ v Tcl. O tˇretím bodu nemá smysl uvažovat. Ostatní body opˇet vykonáme pomocí jednoduchých, intuitivnˇe pojmenovaných pˇríkazu˚ (viz ukázka skriptu).
# nacteni knihovny tclclib load "/home/current/xvykopa1/lib/tclclib/libax4k.so" ax4kpkg # urceni umisteni konfiguracnich souboru ax hwdir "/home/current/xvykopa1/lib/bios" # pripojeni a rezervace portu 1 a 2 ax init -remote ax4000.liberouter.org -user tester -timeout 3 enet lock 1 ax4000.liberouter.org 1 enet lock 2 ax4000.liberouter.org 2 # vytvoreni a nastaveni rozhrani, generatoru a analyzatoru interface create int1 1 -ifmode IPoEther int1 reset int1 set -mode normal generator create gen 1 analyzer create ana 2 gen reset ana reset # definice testovaciho provozu gen seqdefine 1 IPoETHERIPTestPkt ipEthBlk -headerType EII -dstAddr FIXED -fixedAddr 0 gen dgramlen 1 fixed -len 494 gen dist 1 Periodic -bw 10 gen seqsend 1 # spusteni testu, ktery trva 60 sekund ana run after 100 gen run after 60000 gen stop
28
4.3. AUTOMATIZACE TESTOVÁNÍ ana stop # vypis statistik analyzatoru puts [ana stats all]
4.2.1
Testování propustnosti
Skriptovací jazyk Tcl ve spojení s ovládací knihovnou TclClib nám poskytuje vše potˇrebné k realizaci automatizovaného testu propustnosti vˇcetnˇe zpracování výsledku. ˚ Odpadá tedy nutnost ruˇcního nastavování (neustálého klikání) a provádˇení algoritmu binárního pulení. ˚ Výsledný skript nám umožnuje ˇ opakovanˇe provádˇet urˇcitý test prakticky bez nutnosti úˇcasti testera.
4.3
Automatizace testování
Jedním z mých úkolu˚ v projektu Liberouter je vytvoˇrit sadu skriptu˚ pro automatizované testování vyvíjených zaˇrízení vˇcetnˇe zpracování výsledku˚ v podobˇe testovací zprávy. Na zaˇcátku návrhu této sady jsem stanovil základní požadavky: •
skripty budou pracovat v operaˇcním systému Linux,
•
mˇely by používat jen základní Tcl, pˇrípadnˇe jen nˇekolik málo jeho rozšíˇrení,
•
mˇely by spouštˇet pouze programy, které se bˇežnˇe vyskytují v linuxových distribucích,
•
celá sada bude jednoduše rozšiˇritelná o další testy,
•
ke všem testum ˚ bude existovat nápovˇeda a struˇcný popis.
Celá testovací sada je navržena tak, aby s ní mohl uživatel lehce pracovat. Staˇcí naˇcíst pouze jeden skript do Tcl shellu nebo do dalšího skriptu a tester má k dispozici všechny nabízené testy. Platí pravidlo, že jeden typ testu vykonává jedna funkce. Objektový pˇrístup nepˇripadá v úvahu, protože Tcl neumožnuje ˇ ve své základní verzi práci s objekty. Hlavní skript sady testu˚ je tedy množina funkcí. Jen nˇekteré z nich spouští pˇrímo uživatel, ostatní funkce jsou pomocné. Pomocné funkce by mˇely být napsány tak, aby je bylo možné využívat ve více testech (funkcích). Funkce usage vypíše všechny dostupné testy (funkce) a krátký popis. Každý test (funkce vypsaná funkcí usage) muže ˚ být spuštˇen s parametry usage a shortdesc. První parametr vypíše text, který informuje o všech možnostech použití, všech možných nastaveních testu. Druhý parametr zobrazí krátký popis testu. Celou testovací sadu tak muže ˚ jednoduše používat uživatel, který zná jen základy Tcl (napˇr. vývojáˇr testovaného sít’ového prvku). Parametry testu nastaví pomocí argumentu˚ dané funkce (testu). Test je tedy spuštˇen bez nutnosti vytváˇrení, editace a naˇcítání konfiguraˇcních souboru. ˚ Pokroˇcilejší uživatel muže ˚ vytváˇret vlastní Tcl skripty, které budou používat funkce (testy) této sady. Tímto zpusobem ˚ muže ˚ vytváˇret nejruznˇ ˚ ejší soubory testu˚ 29
4.3. AUTOMATIZACE TESTOVÁNÍ pˇresnˇe podle svých potˇreb. Knihovna také nabízí funkci, která naˇcte konfiguraci generátoru uloženou softwarem s GUI. Uvažuji o použití této funkce pˇri nastavování složitˇejšího testovacího provozu. Spojila by se tak pohodlnost práce se softwarem s GUI a efektivita Tcl skriptu. ˚ 4.3.1
Test propustnosti opakovaˇce sondy FlowMon
Prvním testem, který jsem implementoval v rámci této sady testovacích skriptu, ˚ byl test propustnosti opakovaˇce, který je souˇcástí gigabitové pasivní monitorovací sondy FlowMon. Na testu propustnosti závisí další testy uvedené v RFC 2544 (test zpoždˇení, zotavení se po pˇretížení a restartu), proto jsem zaˇcal právˇe ním. Testovací nástroj a sonda je zapojena tak, jak to doporuˇcuje RFC 2544, tj. Spirent AX/4000 je zárovenˇ generátor i analyzátor paketu. ˚ Test je realizován funkcí repeater s argumenty frameLengths a time. První argument je seznam délek ethernetových rámcu˚ v bajtech. Druhý argument udávající délku trvání jedné dílˇcí cˇ ásti testu je nepovinný (implicitnˇe 60 s). Tato funkce inicializuje testovací nástroj, zarezervuje dva gigabitové porty, vytvoˇrí virtuální ethernetové rozhraní, generátor na prvním portu a analyzátor na druhém. Pro každý prvek seznamu, tzn. pro každou zadanou délku rámce provede algoritmus binárního pulení ˚ a získá tak hledanou propustnost. Po zvolenou dobu jsou tedy na zaˇrízení posílány IPv4 datagramy s pevnou zdrojovou a cílovou adresou v ethernetových rámcích s taktéž pevnými adresami. Algoritmus vykonává pomocná funkce, která volá další pomocnou funkci, jež vrací pro danou rychlost zadanou v procentech maximální možné rychlosti ztrátovost v procentech a rychlost v paketech za sekundu. Pomocná funkce ovˇerˇ uje, zda se po skonˇcení dílˇcí cˇ ásti testu vrátily alesponˇ nˇejaké rámce. Pokud se tak nestalo, vypíše chybovou hlášku a test skonˇcí. V pˇrípadˇe úspˇechu je vypsána tabulka jejíž sloupce jsou tvoˇreny délkou rámce, rychlostí v paketech za sekundu a v procentech maximální rychlosti. Poˇcet rˇ ádku˚ je roven poˇctu testovaných délek rámcu. ˚ V soucˇ asnosti pracujeme s kolegou z projektu Liberouter na dalším zpracováním namˇerˇ ených výsledku˚ v podobˇe dokumentu ve formátu DocBook, který bude obsahovat grafy cˇ i tabulky tak, jak to požaduje RFC 2544. Po skonˇcení testování jsou uvolnˇeny používané porty. 4.3.2
Test propustnosti sondy FlowMon
Další test sady zjišt’uje propustnost samotné sondy. Testuje se, zda byly správnˇe rozpoznány všechny toky, které prošly sondou. V tomto pˇrípadˇe tedy není možné použít zapojení doporuˇcované v RFC 2544. AX/4000 pouze generuje sít’ový provoz (narozdíl od pˇredchozího testu, v nˇemž fungoval i jako analyzátor). Program sw_obuf_ctl, jenž je souˇcástí softwarového balíku FlowMon, slouží k zobrazení statistik analyzovaných toku. ˚ Test tedy provˇerˇ uje funkˇcnost celku (hardwarové sondy i softwaru sw_obuf_ctl). V principu je tento test vykonávaný funkcí throughput stejný jako test pˇredcházející. Liší se analýzou pˇrijatých paketu, ˚ možností testovat v obou smˇerech a jiným testovacím provozem. První argument funkce (parametr tohoto testu) je frameLengths. Tento seznam opˇet udává všechny délky paketu, ˚ které chceme testovat. Druhý argument time slouží k urˇcení 30
4.3. AUTOMATIZACE TESTOVÁNÍ doby trvání jedné dílˇcí cˇ ásti testu (také je nepovinný, implicitnˇe 60 sekund). Nepovinný argument ports udává, zda budeme testovat v jednom (implicitní nastavení) nebo obou smˇerech. Inicializace nástroje, rezervace portu, ˚ vytvoˇrení rozhraní a generátoru cˇ i generátoru˚ probíhá stejnˇe jako u pˇredcházejícího testu. Algoritmus binárního pulení ˚ opˇet zajišt’ují pomocné funkce. Rozdíl je však v nastavení testovaného zaˇrízení a v analýze. Pˇred zahájením samotného testování musíme na stroji, ve kterém je instalována sonda, spustit inicializaˇcní skript. Tento skript nastaví mj. cˇ as aktivního a neaktivního toku, který ovlivnuje ˇ chování sondy, klasifikaci toku˚ (zda pˇrijaté pakety ještˇe patˇrí nebo už nepatˇrí k urˇcitému toku) a tedy i analýzu. Na základˇe zadané délky trvání (argument time) vypoˇcítáme pˇríslušné hodnoty tˇechto cˇ asu. ˚ Taktéž program sw_obuf_ctl musí být spuštˇen na stroji, ve kterém je instalována sonda. Pro jednoduchost spouštíme skript na stejném stroji jako je sonda. V tomto pˇrípadˇe však muže ˚ nastat situace, že stroj nemusí z nejruznˇ ˚ ejších duvod ˚ u˚ odpovídat a celé testování je narušeno. Takovému problému lze pomˇernˇe jednoduše pˇredcházet tím, že skript bude spuštˇen na jiném poˇcítaˇci a pomocí programu ssh nebo Tcl rozšíˇrení Expect bude vzdálenˇe spouštˇet potˇrebné programy. Generujeme provoz obsahující 500 toku. ˚ Tento poˇcet je zvolen kvuli ˚ omezení programu sw_obuf_ctl. Každý tok je tvoˇren UDP/IPv4 datagramy v ethernetových rámcích. Toky se liší cílovou adresou, která se postupnˇe zvyšuje (rozsah adres je tedy napˇr. 192.168.0.1 až 192.168.0.500). Pˇri analýze nejprve zjistíme poˇcet pˇríchozích (tj. toky, které sonda zaznamenala) a pˇrijatých toku˚ (tj. toky, které jsou ve výstupním bufferu a budou cˇ teny programem sw_obuf_ctl). Pokud jsou tyto hodnoty ruzné, ˚ pravdˇepodobnˇe byly špatnˇe nastaveny cˇ asy aktivního a neaktivního toku. Skript konˇcí chybovou hláškou. Jinou chybovou hlášku dostaneme, pokud byl poˇcet pˇrijatých toku˚ jiný než poˇcet vyslaných. V opaˇcném pˇrípadˇe skript naˇcte poˇcty bajtu˚ jednotlivých toku, ˚ seˇcte je a porovná s celkovým poˇctem odeslaných. Jestliže se rovnají, sonda na této rychlosti obstála. Manuální provádˇení takové verifikace je velmi zdlouhavá a nezajímavá práce. Jazyk Tcl nám však poskytuje mocné funkce pro práce s textem. Uvedené zpracování, které je v jiných programovacích jazycích obtížnˇe proveditelné, provedeme v Tcl nˇekolika jednoduchými funkcemi (viz zdrojový kód skriptu na pˇriloženém CD). Zbylá cˇ ást funkce throughput je napsána podobnˇe jako odpovídající cˇ ást funkce repeater.
31
Kapitola 5
Závˇer V této práci jsem se pokusil shrnout nejruznˇ ˚ ejší dokumenty vydané pracovními skupinami Benchmarking Methodology Working Group (BMWG) a IP Performance Metrics Working Group (IPPM) celosvˇetové organizace IETF. RFC vytvoˇrené tˇemito skupinami jsou de facto standardy. V oblasti testování výkonu prvku˚ sít’ové infrastruktury, které operují na nižších vrstvách sít’ového ISO/OSI modelu, dominují dokumenty BMWG (napˇr. RFC 2544). Následoval rozbor volnˇe dostupných softwarových testovacích nástroju. ˚ Vˇetšina z nich je pro testování na gigabitových rychlostech nepoužitelná. Nejvˇetší podíl má na tom paradoxnˇe hardware, na kterém tyto nástroje bˇeží. PCI sbˇernice, kterou jsou vybaveny témˇerˇ všechny dnešní poˇcítaˇce, je úzkým hrdlem pro pakety, které míˇrí pˇres sít’ovou kartu na testované zaˇrízení. Nastupující sbˇernice Express PCI by snad mohla tyto nedostatky odstranit. Je to moderní, sériová sbˇernice s mnohem vyšší propustností (až 10 Gb/s) než disponuje PCI. V neposlední rˇ adˇe brání testování vysokorychlostních zaˇrízení nepˇresné cˇ asování v operaˇcních systémech. Právˇe proto se používají hardwarové testovací nástroje. Bez problému dokáží testovat desetigigabitové sítˇe cˇ i jejich prvky. Dále nabízejí plný uživatelský komfort v podobˇe ovládacího software s grafickým uživatelským rozhraním (GUI) a ovládací knihovny nejˇcastˇeji ve skriptovacím jazyce Tcl. Praktická cˇ ást práce je vˇenována hardwarovému testovacímu nástroji Spirent AX/4000. Nejprve jsem se snažil ukázat, že v pˇrípadˇe opakovaného vykonávání stejných testu, ˚ je používání ovládacího softwaru s GUI nepohodlné. Potom jsem pˇredstavil základní myšlenky návrhu skriptu, ˚ které realizují sadu automatizovaných testu. ˚ Dále je naˇcrtnuta implementace prvních testu˚ propustnosti, které již slouží pˇri práci v projektu Liberouter. Na jejich zdokonalení se neustále pracuje. Za zamyšlení jistˇe stojí, jak efektivnˇe vytváˇret zprávu z testování vˇcetnˇe grafu, ˚ tabulek, parametru˚ testovaného zaˇrízení a samotného testu, jestli se vyplatí vˇetší dekompozice pomocných funkcí, které se pak mohou využívat ve více testech a pˇresun inicializace testovaného zaˇrízení z útrob skriptu do definovaného souboru. To vše je otázkou vývoje, stejnˇe jako implementace dalších testu˚ definovaných RFC 2544 nebo testu˚ specifických pro urˇcité prvky sít’ové infrastruktury (napˇr. test správnosti vzorkování toku˚ provádˇené sondou FlowMon). Zdrojový kód prvních testu˚ ve skriptovacím jazyce Tcl je pˇriložen na CD.
32
Pˇríloha A
Obsah pˇriloženého CD Kompaktní disk, který je pˇriložen k této práci, obsahuje následující adresáˇrovou strukturu: •
text
•
sada
•
zpravy
Elektronická verze a zdrojový text této písemné zprávy ve formátu DocBook vˇcetnˇe všech použitých obrázku˚ se nachází v adresáˇri text. Skript obsahující sadu testovacích skriptu˚ je uložen v adresáˇri sada, ukázky reálných testovacích zpráv z testování zaˇrízení v projektu Liberouter v adresáˇri zpravy.
33
Literatura ˇ [1] Barton, ˇ J.: Performance testing of IPv6 devices, CVÚT, Praha, 2004, diplomová práce . 3.1 [2] Johnson, S.: Komentáˇr k RFC 2544, 2005,
. 2.1.2 [3] Internetové stránky projektu Liberouter, . 1.1 [4] AX/4000 Tcl Commands for IP, Spirent Communications, 2005, reference manual . [5] Mukkai, R.: Design of the new and improved NetSpec controller, College of Engineering, Osmania University, Hyderabad, India, 2001, . 3.1.5 [6] Bradner, S.: RFC 1242 Benchmarking Terminology for Network Interconnection Devices, 1991, . 2.1.1 [7] Bradner, S. a McQuaid, J.: RFC 1944 Benchmarking Methodology for Network Interconnect Devices, 1996, . 2.1.2 [8] Mandeville, R.: RFC 2285 Benchmarking Terminology for LAN Switching Devices, 1998, . 2.1.4 [9] Paxson, V. a Almes, G. a Mahdavi, J. a Mathis, M.: RFC 2330 Framework for IP Performance Metrics, 1998, . 2.2.1 [10] Parker, S. a Schmechel, C.: RFC 2398 Some Testing Tools for TCP Implementors, 1998, . 3.1 [11] Bradner, S. a McQuaid, J.: RFC 2544 Benchmarking Methodology for Network Interconnect Devices, 1999, . 2.1.3 [12] Paxson, V. a Mahdavi, J.: RFC 2678 Metrics for Measuring Connectivity, 1999, . 2.2.2 [13] Almes, G. a Kalidindi, S. a Zekauskas, M.: RFC 2679 A One-way Delay Metric for IPPM, 1999, . 2.2.3 [14] Almes, G. a Kalidindi, S. a Zekauskas, M.: RFC 2680 A One-way Packet Loss Metric for IPPM, 1999, , . 2.2.3 [15] Almes, G. a Kalidindi, S. a Zekauskas, M.: RFC 2681 A Round-trip Delay Metric for IPPM, 1999, . 2.2.4 34
[16] Mandeville, R. a Perser, J.: RFC 2889 Benchmarking Methodology for LAN Switching Devices, 2000, . 2.1.4 [17] Koodli, R. a Ravikanth, R.: RFC 3357 One-way Loss Pattern Sample Metrics, 2002, . 2.2.5 [18] Demichelis, C. a Chimento, P.: RFC 3393 IP Packet Delay Variation Metric for IP Performance Metrics (IPPM), 2002, . 2.2.6 [19] Flynt, C.: Tcl/Tk: A Developer’s Guide, Morgan Kaufmann Publishers, 2003, 1-55860802-8.
35
