VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ FAKULTA INFORMAČNÍCH TECHNOLOGIÍ CASE-STUDY CCNP IP SERVICE LEVEL AGREEMENT TECHNOLOGY. Bc. Vladimír Veselý xvesel38

Transkript

1 VYSOKÉ UČENÍ TECHNICKÉ V BRNĚ FAKULTA INFORMAČNÍCH TECHNOLOGIÍ CASE-STUDY CCNP IP SERVICE LEVEL AGREEMENT TECHNOLOGY Bc. Vladimír Veselý xvesel38

2 OBSAH 1 Úvod Abstrakt Prohlášení IP Service Level Agreement Co to je? Jak to vypadá? Co všechno to může měřit? Příklad nasazení IP SLA u zákazníka Popis problému Konfigurace Výsledky Závěr Bibliografie ÚVOD 1.1 ABSTRAKT Tato případová studie si klade za cíl seznámit čtenáře s technologií IP SLA, sloužící nejen k proměřování výkonu sítě. 1.2 PROHLÁŠENÍ Tímto čestně prohlašuji, že práce ani žádná její část není plagiátem a že jsem poctivě uvedl všechny bibliografické prameny (ať už elektronické či literární) z nichž jsem čerpal. Práce byla vypracována samostatně v rámci stáže u firmy Anect a.s. (1), pod vedením Ing. Tomáše Kudely, kterému tímto děkuji za profesionální odborné vedení, které předcházelo a provázelo proces tvorby tohoto dokumentu. Svým vlastnoručním podpisem stvrzuji pravdivost tohoto prohlášení. X Vladimír Veselý

3 2 IP SERVICE LEVEL AGREEMENT 2.1 CO TO JE? IP SLA je proprietální technologií (2) obsažena v Cisco IOSu, která umožňuje měření a monitorování síťového provozu (zpoždění, jitter, výpadky a ztráty paketů). Pod tímto názvem se vyskytuje od verze IOSu 12.3, přičemž byla postupně předcházena nástroji s obdobnou funkčností RTR (Response Time Reporter) a SAA (Service Assurence Agent). Oproti nástrojům, které výsledky svých analýz vztahují k pasivnímu sledování sítě, IP SLA využívá proaktivního přístupu, kdy si samo generuje testovací pakety, jejichž postup sítí pak pozoruje. Výhodou je tedy unifikovanost výsledků, možnost simulace budoucího růstu sítě či podpora ze strany HW Cisco zařízení, která zaručuje reálné výsledky. 2.2 JAK TO FUNGUJE A VYPADÁ? IP SLA měří výkon sítě mezi dvěma body pomocí formálních testovacích paketů, což odráží i samotná architektura, ve které existuje: IP SLA Source generuje pakety podle požadovaného typu měření (ICMP echo, UDP jiter, atd.), analyzuje a uchovává výsledky, které jsou pak dostupné z CLI či přes SNMP; IP SLA Responder reaguje na testovací pakety (vkládá časová razítka a další relevantní údaje), responder může být podle typu měření buď aplikační server či jiné Cisco zařízení.

4 Zařízení typu Source tedy vysílá pakety, do kterých vkládá časová razítka (a další relevantní údaje), přičemž zařízení typu Responder doplňuje tyto informace o statistiky, které během zpracování testovacího paketu provedlo. Paket se pak s informacemi vrací zpět k zařízení typu Source. Výše uvedený obrázek ukazuje proces tvorby 4 časových razítek a jejich reprezentaci ve výsledku: T1 = čas vyslání testovacího paketu sourcem; T2 = čas přijetí paketu responderem; T3 = čas odeslání zpracovaného paketu responderem; T4 = čas přijetí paketu sourcem; = čas zpracování celého testovacího paketu HW responderu; RTT (round trip time) = odezva mezi dvěma zařízeními; Tento systém umožňuje analyzovat provoz v závislosti na směru (jednosměrné/obojsměrné), ale i pozorovat směrovou ztrátu paketů. Buď jsou výsledky měření dostupné přes CLI rozhraní Cisco zařízení, anebo pomocí SNMP trapů k lepšímu zpracování.

5 2.3 CO VŠECHNO TO MŮŽE MĚŘIT? Následující tabulka ukazuje jen hlavní směry měření, během konfigurace IP SLA je možno vyspecifikovat detaily (druhy výsledků, překročení prahů, způsob statistického zpracování) jednotlivých metod. Rozbor všech alternativ by byl však příliš obsáhlý a nad rámec této práce, proto čtenáře odkazuji na (3), kde jsou schopni si dohledat všechny podrobnosti. Sledování dostupnosti ICMP Echo Měří odezvu mezi dvěma body (PING). ICMP Path Echo Oproti výše uvedenému provádí před měřením ještě hledání cesty k cíly a do výsledku zahrnuje i odezvu mezi jednotlivými uzly (TRACEROUTE). ICMP Jitter Oproti ICMP Echo přidává k sledování i jitter statistiky jako zpoždění či ztrátovost paketů. (PING + JITTER) ICMP Path Jitter TRACEROUTE + JITTER UDP Echo Na rozdíl od ICMP variant zahrne do měření i zpoždění, které vzniká zpracováváním paketu v HW zažízení (buffery, doba příimu a vyslání paketu). UDP Jitter To samé co UDP Echo, jen s rozšířením o jitterové statistiky a výsledky s mikrosekundovou přesností. Sledování významných aplikačních služeb TCP Connect Sleduje dostupnost navázání TCP spojení. HTTP Sleduje dostupnost mezi klientem, který server žádá o http stránku. Sbírají se celkem tři časové údaje (doba překladu jména na adresu DNS, doba navázání TCP spojení a konečně doba zaslání web stránky). FTP Sleduje round-trip čas mezi klientem a FTP serverem při stahování souboru. DHCP Sleduje čas nutný k úplnému vyjednání a přidělení IP adresy mezi klientem a DHCP serverem. DNS Sleduje dobu nutnou k překladu jména na adresu či zpět pomocí služby DNS. Sledování hlasových služeb VoIP UDP Jitter Při sledování generuje VoIP pakety různých kodeků (G.711ALAW, G.711ULAW, G.729A) a jako výsledek vrací hodnoty parametrů MOS (subjektivní hodnocení kvality poslechu) a ICPIF. VoIP RTP Operation Oproti výše zmíněnému je schopno sledovat opravdový hlasový tok a jeho ztrátovost. VoIP Call Setup Sleduje dobu nutnou k ustavení hovoru. VoIP Gateway Registration Delay Sleduje dobu a další relevantní data nutná k zaregistrování brány gatekeeperovi.

6 3 PŘÍKLAD NASAZENÍ IP SLA U ZÁKAZNÍKA 3.1 POPIS PROBLÉMU Významný zákazník plánuje zkvalitnění služeb VoIP poskytovaných svým zaměstnancům. Organizace je členěna na mnoho poboček rozsetých po celé republice s centrální správou umístěnou v hlavním městě. Kromě posílení kvality stávajících linek se rozhodl škálovat svou topologii tak, aby co nejlépe od sebe odstínil hlasový provoz od ostatního při zachování výkonu sítě. Topologie obsahuje záložní redundantní spoje ke každé významné lokalitě, rozhodl se tedy tohoto faktu využít k podmíněnému směrování využívající výsledků technologie IP SLA. Směrování v MPLS VPN VoIP bude rozšířeno o podmínku splnění kvalitativního parametru MOS (Mean opinion score) telefonního hovoru v návaznosti na kumulativní hodnotu jitter v definovaném časovém rozmezí. Na základě výsledku podmínky bude vložena explicitní statická cesta na záložní PE směrovač, pokud hodnota MOS poklesne pod definovanou přijatelnou hranici. Z libovolného hlavního směrovače U v územních pobočkách (Jeseník, Šumperk, Brno, atd.) bude u zvolené výchozí implicitní cesty na směrovač A v případě výhodnější metriky generované protokolem OSPF a nesplnění podmínky výsledku měření IP SLA v této cestě, cesta změněna pro hlasový provoz na PE směrovač B.

7 3.2 KONFIGURACE Nejjednoduší je konfigurace responderu, zde stačí zařízení oznámit, aby reagovalo na IP SLA testovací pakety: A(config)#ip sla responder Nyní přistoupíme k nakonfigurování zařízení typu source a rozboru vkládaných příkazů: U(config)#ip sla monitor 282 U(config-sla)#type jitter dest-addr <IP adresa A> dest-port codec g729a U(config-sla)#vrf SiemensVOIP U(config-sla)#frequency 120 U(config-sla)#exit U(config)#ip sla monitor schedule 282 life forever start-time now U(config)#ip sla monitor reaction-configuration 282 react jitteravg threshold-type immediate threshold-value action-type trapandtrigger U(config)#track 282 rtr 282 reachability U(config)#ip route vrf SiemensVOIP <IP adresa PE B> track VÝSLEDKY Nejprve zkontrolujeme, že IP SLA sondy v pořádku procházejí a jsou zpracovávány responderem: A#sh ip sla responder IP SLAs Responder is: Enabled Number of control message received: 4 Number of errors: 0 Recent sources: [18:21: GMT+1 Mon Nov ] [18:19: GMT+1 Mon Nov ] [18:17: GMT+1 Mon Nov ] [18:13: GMT+1 Mon Nov ] Recent error sources: A nýní přistupme k analýze fungování pro zařízení typu source: U#sh ip sla monitor operational-statistics Entry number: 282 Modification time: 15:24: MEZ Tue Nov Number of Octets Used by this Entry: Number of operations attempted: Number of operations skipped: Current seconds left in Life: Forever Operational state of entry: Active Last time this entry was reset: Never Connection loss occurred: FALSE Timeout occurred: FALSE Over thresholds occurred: FALSE Latest RTT (milliseconds): 6 Latest operation start time: 10:29: MEZ Mon Dec Latest operation return code: OK Voice Scores: ICPIF Value: 11 MOS score: 4.06

8 RTT Values (milliseconds): NumOfRTT: 1000 RTTAvg: 6 RTTMin: 6 RTTMax: 11 RTTSum: 6383 RTTSum2: Packet Loss Values: PacketLossSD: 0 PacketLossDS: 0 PacketOutOfSequence: 0 PacketMIA: 0 PacketLateArrival: 0 InternalError: 0 Busies: 0 PacketSkipped: 0 Jitter Values (milliseconds): MinOfPositivesSD: 1 MaxOfPositivesSD: 1 NumOfPositivesSD: 39 SumOfPositivesSD: 39 Sum2PositivesSD: 39 MinOfNegativesSD: 1 MaxOfNegativesSD: 1 NumOfNegativesSD: 39 SumOfNegativesSD: 39 Sum2NegativesSD: 39 MinOfPositivesDS: 1 MaxOfPositivesDS: 5 NumOfPositivesDS: 56 SumOfPositivesDS: 62 Sum2PositivesDS: 88 MinOfNegativesDS: 1 MaxOfNegativesDS: 5 NumOfNegativesDS: 56 SumOfNegativesDS: 62 Sum2NegativesDS: 88 Jitter Avg: 1 JitterSD Avg: 1 JitterDS Avg: 1 Interarrival jitterout: 0 Interarrival jitterin: 0 One Way Values (milliseconds): NumOfOW: 1000 OWMinSD: 0 OWMaxSD: 1 OWSumSD: 214 OWSum2SD: 214 OWMinDS: 6 OWMaxDS: 11 OWSumDS: 6169 OWSum2DS: OWAvgSD: 0 OWAvgDS: 6

9 4 ZÁVĚR Technologie IP SLA byla popsána jak z teoretického, tak i z praktického hlediska na konkrétním realizovaném případě použití v praxi. Dalším z hezkých a účelových způsobů použití je např. dynamický failover (4) statické defaultgateway v případech, kdy je znemožněno použití směrovacích protokolů jako OSPF. Na čtenáři je, aby si našel i další případy využití tohoto malého, avšak mocného nástroje. 5 BIBLIOGRAFIE 1. ANECT a.s. [Online] 2. Cisco IOS IP SLA. [Online] [Citace: ] 0aecd8017f8c9_ps6602_Products_White_Paper.html. 3. Cisco IOS IP SLA Command reference. [Online] [Citace: ] 4. Dynamic Failover with IP SLA. [Online] 5. Cisco IOS IP SLA User Guide. [Online] [Citace: ] 86a00802d5efe_ps6602_Products_White_Paper.html.