Průzkum možnosti testování Service Level Agreement (SLA) v Cisco IOS

Transkript

1 Průzkum možnosti testování Service Level Agreement (SLA) v Cisco IOS Marek Wija, WIJ003 Jan Staroba, STA458 Abstrakt: Service Level Agreement (SLA) je v našem jazyce pojem překládaný jako dohoda o úrovni poskytované služby. Jedná se o smlouvu uzavřenou obvykle mezi poskytovatelem internetových služeb a zákazníkem. Smyslem dohody je garantovat požadovanou úroveň kvality nabízené služby. Cílem této práce je prozkoumat a vyhodnotit možnosti testovacích nástrojů v oblasti SLA, jež v sobě integrují síťové prvky CISCO, shrnout základní konfiguraci nečastěji používaných testů a násladně také otestovat zmíněné funkce na vzorové topologii. Klíčová slova: SLA, CISCO, IOS, router, VoIP, IP, TCP, UDP, ICMP, 1 Úvod Proč chtít SLA? Definice splnitelných záruk Měření kvality služby SLA a bezpečnost SLA v prostředí CISCO IOS Technologické pozadí IP SLA Používané metriky Cisco IOS IP SLA Postup konfigurace Testovací topologie Seznámení s topologií Konfigurace Analýza kvality služby pomocí UDP Jitter operace Nastavení Responderu Nastavení IP SLA Senderu Výpis konfigurace operace UDP Jitter Analýza kvality služby pomocí TCP Connect operace Nastavení Responderu Nastavení IP SLA Senderu Výpis konfigurace operace TCP Connect Analýza kvality služby pomocí ICMP Path Echo operace Nastavení IP SLA Senderu Výpis konfigurace operace ICMP Echo Path Výsledky provedených testů Výpis statistiky operace UDP Jitter Výpis statistiky operace TCP Connect Výpis statistiky operace ICMP Echo Path Závěr Použitá literatura /14

2 1 Úvod V první části této práce se nejprve teoreticky seznámíme se samotným pojmem SLA obecně a jeho významem v dnešním síťovém prostředí. Je třeba si uvědomit, zda-li a proč dohodu o úrovni poskytované služby potřebujeme. V úvodní části také rozebereme princip funkce SLA z pohledu směrovače CISCO, který naváže na modelovou testovací topologii. 1.1 Proč chtít SLA? Nejprve se pokusme porozumět tomu, proč se vůbec SLA ve společnostech uplatňuje. SLA je běžným právním dokumentem, který obsahuje předpokládaný rozsah a úroveň služby a také případné postihy za její nedodržení. Prvotním cílem tohoto dokumentu ovšem není penalizovat dodavatele služby, ale naopak preventivně předcházet tomu, aby nedocházelo k chybám při jejich poskytování v důsledku rozdílnosti vzájemných očekávání. Na tyto preventivní mechanismy by se při tom měli soustředit jak zákazník, tak i dodavatel služby, protože nedostatečným plněním úrovně poskytovaných služeb může dojít k mnohem větším finančním škodám, než jsou penále zakotvené v SLA. Vztah smlouvy o poskytování služby a metrik SLA. 1.2 Definice splnitelných záruk Dodavatelé se většinou před potenciálními zákazníky předhánějí v kvalitě a schopnostech svých nabízených služeb. Někteří uvádějí čísla typu 99,999 %, která znamenají, na kolik procent bude jejich služba v požadované kvalitě a intenzitě dostupná zákazníkovi. Každému by však na první pohled mělo být jasné, že se jedná pouze o reklamní slogan, který lze v praxi jen těžko uplatit. Existují zde dva problémy, proč neslibovat svému zákazníkovi několika devítkové číslo záruk. Prvním jsou výluky, mezi něž patří například plánovaná údržba operačního systému, upgrade a jiné další situace, kterým jednoduše zamezit nelze. Tyto zdánlivě nepříliš náročné operace se navíc většinou opakují a logicky tím dodavateli zabrání ve splnění záruk v téměř stoprocentních hodnotách. Dalším problémem je, že různí zákazníci mají různé hardwarové a softwarové vybavení, různé rychlosti sítí apod. Z těchto důvodů je možno říci, že záruka 99,999% je dnes velmi nereálná. Nabídka operátorů na trhu se po určité době ustálila a nyní se shodují, že běžným standardem pro dostupnost služeb je hodnota 99,5 %. Dostupnost se obvykle měří a vyhodnocuje 1x za měsíc, kdy hodnota 99,5 % znamená maximální dobu trvání výpadku 3,6 hodiny. Standardní dostupnost 99,5 % u služeb konvergovaných IP sítí nemusí být pro některé typy provozu dostačující. Zvláště u kritických aplikací a informačních systémů, na kterých závisí chod podniku, je požadována dostupnost vyšší. Zdroje informačního systému jsou v síti určitým způsobem rozmístěny, na subjektivně vnímanou kvalitu služeb má proto vliv i topologie. 2/14

3 1.3 Měření kvality služby Měření je další z klíčových oblastí SLA. Kdo má ale měřit, zda procesy fungují tak, jak byly specifikovány? V běžných případech nechává tento úkol poskytovatel outsourcingových služeb na interních zaměstnancích. I přesto je ovšem nutné mít v SLA jasně definováno, kdo, jak a kdy bude procesy monitorovat, kontrolovat a oznamovat výsledky zákazníkovi. Stále častějšími jsou ale případy, kdy je úkolem měření pověřena třetí strana, která provádí nezávislé kontroly, jejichž výsledky potom v určitých časových intervalech hlásí oběma smluvním stranám. Ty na základě těchto reportů poté provádějí vzájemné vyúčtování. S měrěním kvality je úzce spojeno jeho časové rozpětí. To znamená časový úsek, ve kterém je outsourcingová služba monitorována. Všeobecně platí, že pokud je doba měření delší, dodavatel služeb dosáhne lepších výsledků. To je v konečném důsledku výhodou pro dodavatele i pro příjemce služby, jelikož čím déle probíhá konkrétní služba, tím se zvyšuje její výkonnost pro zákazníka. Nejčastější časový horizont, který je používán pro měření kvality, rozsahu a intenzity outsourcingové služby, je měsíční. Tento horizont je také dán frekvencí plateb zákazníka. V tomto případě je možné dodavateli zaplatit za jeho služby dle dohody SLA, kde většinou bývají stanoveny platby paušální za servisní úroveň služby a následně mohou být odečteny srážky za nedodržení této úrovně, popřípadě přičteny bonusy za tzv. motivační úroveň, která se většinou v praxi pohybuje nad 99 %. V praxi se ale může stát, že zákazník bude vyžadovat hlášení častěji. V tomto případě si zákazník musí uvědomit, že tato nadstandartní hlášení znamenají vyšší náklady pro dodavatele outsourcingových služeb, a tedy i on bude muset zaplatit za tuto dodatečnou službu. 1.4 SLA a bezpečnost Průnik pojmů služby elektronické komunikace, bezpečnost a SLA zřejmě nemá smysl hledat v oblasti technických aspektů bezpečnosti komunikace. Do SLA se bezpečnost promítá zejména snahou o snížení možnosti chyby vlivem lidského faktoru a to pomocí jednoznačného popisu odpovědností v oblasti servisních a procesních metrik. Uvážíme-li, že řešení výpadku či snížené úrovně služeb představuje mimořádný stav, je důležité, aby jeho zvládnutí nebylo doprovázeno bezpečnostními riziky. Například na straně zákazníka i poskytovatele je potřebné jednoznačně definovat osoby, které jsou oprávněny vzájemně komunikovat a řešit nestandartní stavy. Cílem tohoto kroku je zamezit neautorizovaným požadavkům, které souběžně aktivují procesy, v jejichž důsledku může dojít ke zbytečným zásahům do fungujících systémů. 2 SLA v prostředí CISCO IOS Společnost Cisco implemetuje dohodu o kvalitě služby ve svých zařízeních pod názvem Cisco IOS IP Service Level Agreement, zkráceně IP SLA. Tento modul je základním jádrem softwarového řešení, jež nabízí svým zákazníkum možnost analyzovat kvalitu služeb a aplikací běžících nad protokolem IP. K Cisco IP SLA lze přistupovat hned několika způsoby a to přes rozhraní textové konzoli (CLI) nebo pomocí protokolu Simple Network Management Protocol (SNMP) a aplikace Cisco Round-Trip Time Monitor. 2.1 Technologické pozadí IP SLA Princip funkce Cisco IOS IP SLA je založen na aktivním monitorování aktuálního provozu. Proces posílá testovací data skrze celou síť a to mezi více cílovými objekty nebo sití s mnoha různými cestami. Simuluje tak běžné síťové služby postavené nad IP protokolem a v reálném čase sbírá informace o síti. Nahromaděná data obsahují informace jako jsou doba odezvy, dostupnost cíle, zpoždění, ztráta packetů a mnoho dalších. Podrobněji si je rozebereme později. Takovýto provoz dokáže IP SLA generovat jak mezi dvěmi Cisco zařízeními tak například mezi jedním Cisco zařízením a vzdáleným síťovým aplikačním serverem. 3/14

4 Packety, které jsou generovány k samotným testům lze konfigurovat na úrovni nastavení aplikační vrstvy a IP adres. Máme tak možnost nastavit zdrojovou i cílovou ip adresu packetu, čísla portů u UDP/TCP, Type Of Services nebo například URL webovou adresu. 2.2 Používané metriky Cisco IOS IP SLA Vyhodnocování dílčích testů probíhá na základě několika výkonových metrik. Ty jsou vybrány dle možností druhé síťové vrstvy. Delay zpoždění Jitter kolísání Packet loss ztráta packetu Packet sequencing správné řazení packu Path cesta dle počtu přeskoků Connectivity dostupnost Server or website download time čas potřebný ke stažení cíle Voice quality scores kvalita přenosu hlasu Jak již bylo zmíněno, k výsledným analýzám Cisco IOS IP SLA je možné přistupovat i skrze protokol SNMP a využít některý z nástrojů pro grafické zobrazení výsledků testů, tvorbu grafů, statistik a podobně. O smyslu použitých metrik více napoví následující obrázek. Cisco IOS IP SLAs Overview 4/14

5 2.3. Postup konfigurace Než přikročíme ke konkrétní konfiguraci některého z modelových případů, ukážeme si, jakými kroky taková konfigurace projde a na co je třeba nezapomenout. Opět připomínám, že testování provozu zde probíhá na základě posílání generovaných packetů. Nejprve tedy zařízení (sender) vygeneruje a odešle testovací packet k cíli (responder). Ten v závislosti na konkrétní předdefinované IP SLA operaci vyhodnotí packet, označí jej časovým razítkem a odešle zpět. Z hodnoty obsažené v časovém razítku se následně vypočítají výsledky testu. Základní body konfigurace: Zaktivovat cílové zařízení (responder). Nastavit požadovaný typ Cisco IP SLA operace. Nastavit vlastnosti již vybrané Cisco IP SLA operace. Vymezit hraniční stavy pro danou operaci (treshold). Přidat test do plánovače úloh a nastavit čas startu a periodu opakování. Zobrazit výsledky testu pomocí CLI nebo jiného nástroje. Cisco IP SLA nabízí tyto operace: Cisco IOS IP SLAs Operation Použití operace UDP Jitter Hlasové a datové sítě, nejpoužívanější test. ICMP Path Jitter Hlasové a datové sítě. UDP Jitter for VoIP Sítě s užíváním VoIP. UDP Echo Test konektivity, výkon aplikací nad IP protokolem. ICMP Echo Test konektivity, výkon aplikací nad IP protokolem. ICMP Path Echo Test konektivity, identifikuje cestu sítí. HTTP Výkonnost web serveru. TCP Connect Doba připojení k zařízení, výkon serveru. FTP Výkonost FTP serveru. Dynamic Host Configuration Protocol Doba odezvy DHCP serveru. Domain Name System (DNS) Výkonnost služeb DNS serveru. Data Link Switching Plus (DLSw+) Doba odpovědi mezi DLSw+ uzly. Frame Relay Měření kvality pro WAN sítě. Tabulka 1: Dostupné Cisco IOS IP SLA Operace 5/14

6 3. Testovací topologie Testovaní funkčnosti a schopností IP SLA je v laboratorních podmínkách velmi problematické, jelikož není v našich silách dosáhnout alespoň zdánlivé objektivity výsledků testů. Většina operací by měla běžet dlouhodobě, po dobu několika dnu a týdnů. Zvolili jsme tedy malou testovací topologii, na které demonstrativně předvedeme základní konfiguraci Cisco IP SLA. Jak již bylo v předchozí kapitole zmíněno, možností k testování sítě je velké množství, avšak princip a základní myšlenka konfigurace je stále stejná. Vybrali jsme tedy tři testovací operace, na kterých jsme vyzkoušeli funkčnost služby. Výsledky našeho zkoumání a podrobné výpisy konfigurace jsou uvedeny níže v textu. 3.1 Seznámení s topologií K základní konfiguraci Cisco IP SLA si vystačíme se dvěma routery Cisco řady 2800 a jedním koncovým zařízením, kterým je v našem případě běžné PC. Směrovače řady 2800 byly použity z důvodu absence IOSu s podporou IP SLA na ostatních routerech, které jsme měli v laboratoři k dispozici. Je třeba také podotknout, že uvedená konfigurace se drobně liší v syntaxi oproti zápisu uvedenému v manuálu Cisco IOS IP SLA Configuration Guide. Je to tak nejspíše z důvodu odlišné verze IOSu. Rozdíly v syntaxi jsou skutečně velmi malé a na podstatu konfigurace, kterou se tento dokument snaží vystihnout, nemají vliv. Testovací topologie. Jak je patrné z obrázku, jeden z routerů slouží pouze jako Responder a druhý jako zdroj testovacích packetů. Routery jsou propojeny seriovou linkou a koncové zařízení běžným ethernetem. Nad uvedenou topologií běžel směrovací protokol OSPF. 4. Konfigurace Podívejme se na lehký úvod do konfigurace. Testovací operace, které jsme vybrali pro tento účel jsou následující: UDP Jitter Operation TCP Connect Operation ICMP Path Echo Operation Zvolili jsme právě tyto typy testů, protože každý pracuje na jiném protokolu. Konfigurace se však nijak zásadně neliší a drží se stanovených zásad, které lze shrnout do třech bodů. Nejprve je potřeba nakonfigurovat Responder stranu, dále samotný test a na závěr test spustit pomocí plánovače. To vše si podrobněji ukážeme v následující kapitole. 6/14

7 4.1 Analýza kvality služby pomocí UDP Jitter operace Operace IP SLA UDP Jitter byla primárně vytvořena pro diagnostiku sítě, kde běží aplikace v reálném čase, jako například Voice Over IP, Video Over IP a další podobné síťové aplikace. Cisco uvádí, že tento test je hlavním pilířem IP SLA a v praxi je nejpoužívanější. Tuto informaci se nám však nepodařilo ověřit. Slovo Jitter znamená v překladu kolísání, z čehož lze snadno vyvodit, že tento test měří nerovnoměrnou změnu prodlevy packetů na síti. Služby VoIP jsou na prodlevu (delay) packetů velmi citlivé a je tedy velmi praktické situaci na síti sledovat. Tento test samozřejmě umí mnohem více. Vedle sledování kolísání prodlevy umožňuje měřit také: Per-direction packet-loss Per-direction delay (one-way delay) Round-trip delay (average round-trip time) Přistupme tedy k samotné konfiguraci Nastavení Responderu Konfigurace tzv. odpovídající strany je velmi snadná. Popíšeme ji krok po kroku, přičemž vycházíme z neprilegovaného režimu Cisco routeru. 1. enable 2. configure terminal 3. ip sla monitor responder 4. exit Zde si dovoluji upozornit na drobné odlišnosti v syntaxi. Klíčové slovo monitor není potřeba na některých verzích IOSu uvádět Nastavení IP SLA Senderu Pro přehlednost konfigurace odesílající strany uvedeme jen základní konfiguraci a zmíníme jen některé rozšiřující konfigurační možnosti. Podrobný výčet všech dostupných parametrů lze najít v dokumentaci. Nejprve nastavíme samotnou testovací operaci. 1. enable 2. configure terminal 3. ip sla monitor číslo instance 4. udp-jitter dest-ipaddr cílová adresa dest-port cílový port 5. frequency čas v sekundách, po kterém bude následovat opětovné odeslání testovacích dat 6. exit Dále zbývá jen přidat zkonfigurovanou operaci do plánovače. 1. ip sla monitor schedule číslo instance life čas v sekundách start-time now 2. exit 7/14

8 Parametr start-time lze nastavit v těchto hodnotách: hh:mm[:ss] [month day day month] pending now after hh:mm:ss] Výpis konfigurace operace UDP Jitter Výpis konfigurace danné operace lze provést příkazem: show ip sla configuration 1 Číslo 1 na konci příkazu značí číslo instance IP SLA. IP SLAs, Infrastructure Engine-II. Entry number: 1 Owner: Tag: Type of operation to perform: udp-jitter Target address/source address: / Target port/source port: 80/0 Request size (ARR data portion): 32 Operation timeout (milliseconds): 5000 Packet Interval (milliseconds)/number of packets: 20/100 Type Of Service parameters: 0x0 Verify data: No Vrf Name: Control Packets: enabled Schedule: Operation frequency (seconds): 10 (not considered if randomly scheduled) Next Scheduled Start Time: Start Time already passed Group Scheduled : FALSE Randomly Scheduled : FALSE Life (seconds): 60 Entry Ageout (seconds): never Recurring (Starting Everyday): FALSE Status of entry (SNMP RowStatus): Active Threshold (milliseconds): 5000 Distribution Statistics: Number of statistic hours kept: 2 Number of statistic distribution buckets kept: 1 Statistic distribution interval (milliseconds): Analýza kvality služby pomocí TCP Connect operace IP SLA TCP Connect operace slouží k měření času, potřebného k navázání TCP spojení mezi dvěmi zařízeními. Lze jej provozovat mezi dvěma routery nebo mezi routerem a koncovým zařízením. V našem testu jme použili první možnost. Při testování se měří doba, která uplyne od odeslání požadavku o TCP spojení, až do doby přijetí potvrzující informace o navázání spojení. Test lze aplikovat na libovolný port a slouží zejména k ověření dostupnosti služeb běžících na vzdáleném serveru jako např. Telnet, FTP, SQL databáze, HTTP server a podobně Nastavení Responderu Opět je potřeba nakonfigurovat odpovídající stranu. Postup je stejný jako v předchozím případě. 1. enable 2. configure terminal 3. ip sla monitor responder 4. exit 8/14

9 4.2.2 Nastavení IP SLA Senderu Konfigurace bude opět obdobná jako v předchozím případě. 1. enable 2. configure terminal 3. ip sla monitor číslo instance 4. tcp-connect dest-ipaddr cílová adresa dest-port cílový port 5. frequency čas v sekundách, po kterém bude následovat opětovné odeslání testovacích dat 6. exit Opět je potřeba přidat zkonfigurovanou operaci do plánovače. 1. ip sla monitor schedule číslo instance life čas v sekundách start-time now 2. exit Výpis konfigurace operace TCP Connect IP SLAs, Infrastructure Engine-II. Entry number: 3 Owner: Tag: Type of operation to perform: tcp-connect Target address/source address: / Target port/source port: 80/0 Operation timeout (milliseconds): 30 Type Of Service parameters: 0x0 Control Packets: enabled Schedule: Operation frequency (seconds): 35 (not considered if randomly scheduled) Next Scheduled Start Time: Pending trigger Group Scheduled : FALSE Randomly Scheduled : FALSE Life (seconds): 3600 Entry Ageout (seconds): never Recurring (Starting Everyday): FALSE Status of entry (SNMP RowStatus): notinservice Threshold (milliseconds): 25 Distribution Statistics: Number of statistic hours kept: 2 Number of statistic distribution buckets kept: 1 Statistic distribution interval (milliseconds): 20 History Statistics: Number of history Lives kept: 0 Number of history Buckets kept: 15 History Filter Type: None 9/14

10 4.3 Analýza kvality služby pomocí ICMP Path Echo operace IP SLA ICMP Path Echo je poslední ze tří námi testovaných operací. Tato funkce zaznamenává každý přeskok, který je na cestě sítí potřeba k dosažení cíle. Měří tedy časy jednotlivých skoků, čímž lze například snadno vysledovat, kde se v síti nachází úzké místo a provoz je brzděn. Pro názornost přikládáme obrázek vyjmutý z Cisco manuálu. Jak je z obrázku patrné, tentokráte test neprobíhal mezi dvěma routery, ale mezi routerem a koncovým zařízením v podobě běžného PC. Odpadá tedy konfigurace Responderu v podobě routeru a přejdeme rovnou ke konfiguraci IP SLA Senderu Nastavení IP SLA Senderu 1. enable 2. configure terminal 3. ip sla monitor číslo instance 4. path-echo dest-ipaddr cílová adresa source-ipaddr případná zdrojová adresa 5. frequency čas v sekundách, po kterém bude následovat opětovné odeslání testovacích dat 6. threshold čas v milisekundách, nastavení mezní hodnoty 7. timeout čas v milisekundách 8. exit ICMP Echo Path Parametry timeout a threshold jsme zde nastavili kvůli simulování překročení povolené hranice a vyvolání varování. Dále následuje obvyklé nastavení plánovače. 1. ip sla monitor schedule číslo instance life čas v sekundách start-time now 2. exit 10/14

11 4.3.2 Výpis konfigurace operace ICMP Echo Path IP SLAs, Infrastructure Engine-II. Entry number: 4 Owner: Tag: Type of operation to perform: path-echo Target address/source address: / Request size (ARR data portion): 28 Operation timeout (milliseconds): 5000 Type Of Service parameters: 0x0 Verify data: No Loose Source Routing: Disabled Vrf Name: LSR Path: Schedule: Operation frequency (seconds): 10 (not considered if randomly scheduled) Next Scheduled Start Time: Start Time already passed Group Scheduled : FALSE Randomly Scheduled : FALSE Life (seconds): 300 Entry Ageout (seconds): never Recurring (Starting Everyday): FALSE Status of entry (SNMP RowStatus): Active Threshold (milliseconds): 5000 Distribution Statistics: Number of statistic hours kept: 2 Number of statistic paths kept: 5 Number of statistic hops kept: 16 Number of statistic distribution buckets kept: 1 Statistic distribution interval (milliseconds): 20 History Statistics: Number of history Lives kept: 0 Number of history Buckets kept: 15 Number of history Samples kept: 16 History Filter Type: None 5. Výsledky provedených testů Samotné testování sítě by postrádalo smysl, pokud bychom neměli k dispozici nástroj na shrnutí výsledků dílčích testů. Pro naše účely jsme si vystačili s výpisem statistik na běžnou konzoli. IP SLA dovoluje statistiky pravidelně ukládat, archivovat a dále administrovat. Lze je ukládat přímo v paměti routeru nebo odesílat na jiné externí zařízení. Pro naše krátkodobé testy však bohatě postačil detailní výpis právě proběhlé operace. Slouží k tomu následující příkaz: show ip sla statistics aggregated V tomto výpisu jsou zahrnuty veškeré nakonfigurované testy IP SLA. Pro výběr výpisu statistiky konkrétního tesu IP SLA, je třeba uvést na konec příkazu odpovídající číslo instance. V následujících podkapitolách jsou tedy uvedené detailní statistiky každého ze tří prováděných testů. 11/14

12 5.1 Výpis statistiky operace UDP Jitter Type of operation: udp-jitter Voice Scores: MinOfICPIF: 0 MaxOfICPIF: 0 MinOfMOS: 0 MaxOfMOS: 0 RTT Values: Number Of RTT: 200 RTT Min/Avg/Max: 10/10/12 milliseconds Latency one-way time: Number of Latency one-way Samples: 0 Source to Destination Latency one way Min/Avg/Max: 0/0/0 milliseconds Destination to Source Latency one way Min/Avg/Max: 0/0/0 milliseconds Source to Destination Latency one way Sum/Sum2: 0/0 Destination to Source Latency one way Sum/Sum2: 0/0 Jitter Time: Number of Jitter Samples: 198 Source to Destination Jitter Min/Avg/Max: 1/1/2 milliseconds Destination to Source Jitter Min/Avg/Max: 1/1/2 milliseconds Source to destination positive jitter Min/Avg/Max: 1/1/1 milliseconds Source to destination positive jitter Number/Sum/Sum2: 36/36/36 Source to destination negative jitter Min/Avg/Max: 1/1/2 milliseconds Source to destination negative jitter Number/Sum/Sum2: 34/35/37 Destination to Source positive jitter Min/Avg/Max: 1/1/2 milliseconds Destination to Source positive jitter Number/Sum/Sum2: 52/53/55 Destination to Source negative jitter Min/Avg/Max: 1/1/2 milliseconds Destination to Source negative jitter Number/Sum/Sum2: 54/55/57 Interarrival jitterout: 0 Interarrival jitterin: 0 Packet Loss Values: Loss Source to Destination: 0 Loss Destination to Source: 0 Out Of Sequence: 0 Tail Drop: 0 Packet Late Arrival: 0 Packet Skipped: 0 Number of successes: 2 Number of failures: 2 Failed Operations due to over threshold: 0 Failed Operations due to Disconnect/TimeOut/Busy/No Connection: 0/0/0/2 Failed Operations due to Internal/Sequence/Verify Error: 0/0/0 Distribution Statistics: Bucket Range: 0 to < 20ms Avg. Latency: 10 ms Percent of Total Completions for this Range: 100 % Number of Completions/Sum of Latency: 2/20 Sum of RTT squared low 32 Bits/Sum of RTT squared high 32 Bits: 200/0 Operations completed over thresholds: 0 Ve výpise si můžeme všimnout zejména časů dosažení cíle packetu, průměrného času, počty překročení limitů nebo úspěšnosti doručení packetu. 12/14

13 5.2 Výpis statistiky operace TCP Connect Round Trip Time (RTT) for Index 3 Type of operation: tcp-connect Number of successes: 7 Number of failures: 2 Failed Operations due to over threshold: 0 Failed Operations due to Disconnect/TimeOut/Busy/No Connection: 0/0/0/2 Failed Operations due to Internal/Sequence/Verify Error: 0/0/0 Distribution Statistics: Bucket Range: 0 to < 20ms Avg. Latency: 12 ms Percent of Total Completions for this Range: 100 % Number of Completions/Sum of Latency: 7/84 Sum of RTT squared low 32 Bits/Sum of RTT squared high 32 Bits: 1008/0 Operations completed over thresholds: 0 Zde jasně vidíme kolik packetů dorazilo k cíli, kolik ne a z jakého důvodu. Naměřené chyby jsou uměle vytvořením fyzickým přerušením konektivity v průběhu testu. 5.3 Výpis statistiky operace ICMP Echo Path Round Trip Time (RTT) for Index 5 Path Index: 1 Hop in Path Index: 1 Type of operation: path-echo Number of successes: 25 Number of failures: 3 Failed Operations due to over threshold: 3 Failed Operations due to Disconnect/TimeOut/Busy/No Connection: 0/0/0/0 Failed Operations due to Internal/Sequence/Verify Error: 0/0/0 Target Address Distribution Statistics: Bucket Range: 0-19 ms Avg. Latency: 121 ms Percent of Total Completions for this Range: 100 % Number of Completions/Sum of Latency: 28/3392 Sum of RTT squared low 32 Bits/Sum of RTT squared high 32 Bits: /0 Operations completed over thresholds: 3 Zde si můžeme povšimnout překročení povolené hranice threshold. Tento jev byl nasimulován posíláním ICMP packetů nadměrné velikosti na cílovou stanici v průběhu testu. To zapříčilo zahlcení linky a překročení stanovených limitů. 6. Závěr Jak je vidět z předchozího textu, Cisco IOS IP SLA je velmi schopný nástroj se spoustou možností nastavení a velmi dobrým výpisem statistik. Nebylo však v našich silách prozkoumat opravdu všechny jeho možnosti. Tento stručný nástin by však měl pomoci v základní orientaci konfigurace jednotlivých testovacích operací a určitého vyhodnocení testů. Testovat však nástroj sloužící k vyhodnocování kvality sítě v laboratorních podmínkách postrádá smysl a hlavně objektivitu. V praxi a ostrém provozu budou zajisté velmi využity operace testující kvalitu služby z pohledu VoIP a podobných real-time aplikací, výkon http serveru a podobně. Otázkou zůstává, kdy a kde 13/14

14 služeb IP SLA využívat a zda-li se i v menší síti vyplatí obětovat mírně vyšší provozní zátěž způsobenou generovanými packety za podrobné informace o jejím chodu. 7. Použitá literatura [1] Cisco IOS IP SLAs Configuration Guide [online] [cit ]. Dostupný z WWW: < [2] HORA, Michal. IT Outsorcing [online] [cit ]. Dostupný z WWW: < 14/14