Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování
Monitoring network infrastruktury pomocí SNMP protokolu a nástrojů .NET Bakalářská práce
Autor:
Martin Hakr Informační technologie, Správce IS
Vedoucí práce:
Praha
Ing. Michal Rada
Červen, 2009
Prohlášení: Prohlašuji, ţe jsem bakalářskou práci zpracoval samostatně a s pouţitím uvedené literatury.
V Plzni dne
Martin Hakr
Poděkování Děkuji panu Ing. Michalovi Radovi za odborné vedení mé práce, za spolupráci a čas, který mi během vypracování této práce věnoval.
Anotace Bakalářská práce se zabývá monitoringem síťové infrastruktury pomocí protokolu SNMP a platformy .NET. V práci je popsán princip SNMP protokolu a jeho moţné pouţití pro monitorování aktivních prvků Cisco. Monitorovanými zařízeními jsou přepínače Cisco Catalyst. Cílem práce je vytvořit aplikaci, která bude pomocí SNMP protokolu získávat data ze síťových prvků a prezentovat je v běţném webovém prohlíţeči. V práci jsou popsány základní charakteristiky platformy .NET. Pro vytvoření aplikace jsou pouţity technologie ASP.NET a programovací jazyk C#.
Annotation Baccalaureate thesis occupies with monitoring network infrastructure using SNMP protocol and platform .NET. Principle and utilization of SNMP protocol to monitor active network components Cisco are described. Monitored devices are switches Cisco Catalyst. Objective of this thesis is developing application, which will be able to communicate with network components and present data regarding these components in common web browser. Basic characteristics of platform .NET are described. Application is developed by using technology ASP.NET and programming language C#.
Obsah Úvod
7
1.
8
2.
3.
4.
SNMP protokol 1.1.
Vznik a historie
8
1.2.
SNMP filozofie
8
1.3.
SNMP sada operací
9
1.4.
Management Information Base (MIB)
10
1.5.
Formát SNMP zprávy
12
1.6.
Nástroje s podporou SNMP
15
1.7.
Slabé stránky SNMP protokolu a jeho alternativy
16
Monitoring síťové infrastruktury
18
2.1.
Vyuţití sítě
18
2.2.
Zpoţdění (latency)
18
2.3.
Nástroje pouţívané pro monitoring sítě
19
Poţadavky na aplikaci Switch monitoring
20
3.1.
Účel aplikace Switch monitoring
20
3.2.
Monitorované zařízení
21
3.3.
Konfigurační módy Cisco switchů
22
3.4.
Konfigurace SNMP agenta
23
Vytvoření aplikace Switch monitoring
25
4.1.
Vývojářské prostředí a nástroje
25
4.1.1.
Platforma .NET
25
4.1.2.
Technologie ASP.NET
26
4.1.3.
Programovací jazyk C#
27
4.2.
Součásti aplikace switch monitoring
28
4.3.
Webová část aplikace Switch monitoring
29
4.3.1.
Úvodní stránka default.aspx
30
4.3.2.
Stránka monitorSimple.aspx
42
4.3.3.
Stránka monitorChassis.aspx
53
4.3.4.
Windows Forms část aplikace
54
Závěr
56
Seznam pouţité literatury
58 5
Klasické zdroje
58
Elektronické zdroje
59
Seznam pouţitého softwaru
61
Seznam příloh
62
6
Úvod Monitoring síťové infrastruktury je široký pojem, pod nímţ si lze představit sledování, měření a vyhodnocování veličin spojených s datovou komunikací. Monitorování můţe být prováděno soustavně, nebo v určitých intervalech. Vhodným řešením pro monitoring síťových prvků je pouţití SNMP protokolu. Tento protokol byl navrţen pro účel správy směrovačů tehdy vznikající sítě Internet. Postupem času se protokol velmi rozšířil a díky kladnému přijetí a podpoře výrobců síťových komponent se stal efektivním nástrojem pro správu a monitorování datových sítí. První kapitola této práce se zabývá filozofií SNMP protokolu, principem funkčnosti a jeho moţným pouţitím. Je zde popsán formát SNMP zpráv, které si vyměňují monitorovaná zařízení se správcovskou stanicí. Na několika konkrétních příkladech je znázorněna SNMP zpráva, jejíţ formát a obsah je zachycen pomocí protokolového analyzátoru. Dále je zde navrţeno několik dostupných softwarových nástrojů, vyuţívajících protokol SNMP ke správě a diagnostice síťových prvků. Cílem této práce je vytvořit aplikaci, která bude pomocí SNMP protokolu komunikovat s aktivními síťovými prvky. Konkrétně jde o síťové přepínače Cisco Catalyst. V této práci je popsána základní konfigurace, nutná pro monitorování těchto zařízení pomocí protokolu SNMP. Aplikace bude monitorovat jednotlivé porty Cisco přepínačů, a získané informace bude prezentovat v běţném webovém prohlíţeči. Účel a myšlenka vedoucí k vytvoření této aplikace je zmíněna ve třetí kapitole. K vytvoření aplikace jsou pouţity nástroje platformy .NET. Nejzákladnější vlastnosti této platformy jsou charakterizovány na začátku čtvrté kapitoly. Konkrétně je aplikace vytvořena pomocí technologie ASP.NET a programovacího jazyka C#. V další části čtvrté kapitoly je popsána samotná aplikace Switch monitoring. Text je prokládán nejdůleţitějšími částmi zdrojových kódů, jejichţ princip je vţdy vysvětlen. Kompletní zdrojové kódy aplikace jsou přiloţeny na CD. V práci je pouţito několik UML diagramů, vysvětlujících princip konkrétní části programu. V přílohách jsou obrázky s výstupem, který aplikace Switch monitoring zobrazuje ve webovém prohlíţeči.
7
1. SNMP protokol Simple network management protocol je, jak jeho název napovídá, jednoduchý, velmi rozšířený a standardizovaný protokol, který se pouţívá k získávání a nastavování hodnot ze síťových zařízení. Jde o aplikační protokol, zaloţený na modelu klient/server.
1.1.
Vznik a historie
Za vznikem SNMP protokolu stojí pracovní výbor IAB (Internet Architecture Board). Tento výbor byl svolán na konci 80. let a jeho úkolem bylo vytvoření protokolu pro správu směrovačů Internetu, který by nahradil nesčetná řešení od různých výrobců, v té době dostupná (KLAŠKA, 2000). Vznikl jako varianta protokolu SGMP (Simple Gateway Monitoring Protocol), který slouţil pro výměnu informací mezi směrovači a branami v té době vznikající sítě Internet. SNMP protokol se stal široce přijímaným a podporovaným standardem pro správu sítě. Většina výrobců hardwaru a síťových komponent začala implementovat do své architektury SNMP agenty, stejně jako většina operačních systémů (BIGELOW, 2004). V současné době existuje SNMP protokol ve třech verzích. SNMPv1, SNMPv2, umoţňující autentizaci pomocí community stringu a SNMPv3, který k autentizaci pouţívá jméno, heslo a šifrování.
1.2.
SNMP filozofie
Komunikace pomocí SNMP protokolu je zaloţena na modelu klient/server. Protokol tedy definuje dva typy zařízení na síti, těmi jsou SNMP manager a SNMP agent (KLAŠKA, 2000). SNMP manager je program běţící na síťové stanici, který dotazuje jednotlivé SNMP agenty pomocí SNMP operací. Smyslem managera je získávat potřebné informace o určitém zařízení, poskytované agentem. SNMP agent je program běţící na síťovém zařízení a odpovídající na dotazy managera. Agent tedy nepřetrţitě sleduje a sbírá informace o všech dostupných stavech a funkcích daného zařízení. Kaţdý SNMP agent spravuje databázi pojmenovanou MIB Management Information Base (BIGELOW, 2004).
8
MIB je hierarchicky uspořádaná stromová struktura objektů, které jsou předmětem správy. MIB tedy definuje objekt a jeho stav, který je moţné na daném zařízení monitorovat, popřípadě řídit. Manager se ve vyslaném poţadavku odkazuje na určitý objekt, reprezentující určitý stav na daném zařízení. Agent při obdrţení poţadavku projde celou stromovou strukturu MIB, aţ nalezne objekt, obsahující potřebná data a následně je předá zpět managerovi. SNMP pracuje jako dotazovací protokol, z toho vyplývá, ţe u monitorovacích systémů zaloţených na SNMP, manager periodicky odesílá dotazy na agenty a ti mu odpovídají. Tomuto modelu monitorování se říká polling aktivita managera, nebo zkráceně polling. Pojem polling lze definovat jako proces kontrolování prvků v předem definovaném pořadí (FAIBEL, 1996). Z důvodu zatíţení sítě není vhodné provádět polling s velkou frekvencí. Agent také můţe vyslat informace bez vyţádání managera. Zpráva nesoucí tento typ informací je nazývána trap a je vyslána v případě splnění nějaké podmínky (např. hardwarová porucha). Tento model se nazývá trap aktivita agenta. Kombinací polling aktivity managera a trap aktivity agenta lze docílit velice dobré efektivity.
1.3.
SNMP sada operací
SNMP manager a agenti mezi sebou komunikují pomocí omezené sady operací. Tyto operace se pouţívají k vytváření poţadavků a odesílání informací mezi managerem a agenty (BIGELOW, 2004). SNMP je tedy asynchronní protokol pracující systémem poţadavek/odpověď. Protokol pracuje jen s pěti typy operací: GetRequest – manager se pomocí této operace dotazuje agenta na hodnotu jednoho či více objektů. Kdyţ agent obdrţí zprávu typu GetRequest, zkontroluje, zda nejsou v paketu chyby, nalezne dotazované hodnoty ve své MIB struktuře a odešle paket GetResponse zpět managerovi. Jde o příkaz typu read. GetResponse – tento typ zprávy vysílá agent jako odpověď na zprávu typu GetRequest. Kdyţ se v paketu poţadavku vyskytne chyba, paket GetResponse vrací chybovou hlášku. Pokud agent najde ve své MIB databázi poţadované hodnoty, vrací je zpět managerovi.
9
GetNextRequest – jde o ţádost o další data. Zprávu GetNextRequest posílá manager v případě, ţe chce získat informace o více objektech agenta. Tyto objekty jsou obvykle umístěny v tabulce. Manager se začne dotazovat na první objekt a pokračuje, dokud nejsou přečteny všechny objekty v tabulce. Agent vrací pakety GetResponse po kaţdém paketu GetNextRequest. SetRequest – tento typ operace se pouţívá pro nastavení hodnot objektů v SNMP agentovi. Agent přijme zprávu typu SetRequest, nastaví hodnotu pro definovaný objekt a posílá paket GetResponse, jako potvrzení úspěšné operace. Pokud dojde k chybě, odesílá agent chybovou hlášku. Ne všichni výrobci hardwaru a síťových zařízení podporují u svých produktů operace typu SetRequest. U takového zařízení potom nejde pomocí SNMP protokolu provádět management, ale pouze monitoring. Jde o příkaz typu write. Trap – agent odesílá SNMP trap managerovi jako upozornění v případě, ţe nastane nějaká definovaná událost. Na zprávu typu trap není očekávána ţádná odpověď. Z důvodu, ţe mohou být zprávy typu trap posílány z mnoha různých agentů, nese zpráva v hlavičce paketu OID a adresu agenta. Výrobci definují vlastní typy zpráv trap, které jsou specifické právě pro jejich zařízení (KLAŠKA, 2000).
1.4.
Management Information Base (MIB)
Jak je popsáno v předchozí kapitole, MIB databázi spravuje kaţdý SNMP agent běţící na konkrétním zařízení. Tato hierarchicky uspořádaná struktura hodnot popisuje sadu objektů, jeţ jsou předmětem správy daného zařízení. Agent můţe pracovat s více MIB databázemi, v závislosti na spravovaném zařízení (BIGELOW, 2004). Stejně jako v standardních databázích i MIB popisuje jak strukturu, tak formát dat objektu. MIB databáze podléhají pravidlům SMI Structure of Management Information (ŠMRHA, 1994). Jsou definovány v dokumentech RFC1155, RFC1212 a RFC1215. Kaţdý SNMP objekt má jedinečné jméno, pomocí kterého se na něj manager odkazuje v dotazu (KLAŠKA, 2000). Síťové komponenty a hardware obsahují objekty, společné pro více zařízení, ale také objekty specifické pouze pro konkrétního výrobce popřípadě konkrétní zařízení. Z tohoto důvodu byla vytvořena databáze objektů jako hierarchická stromová struktura SNMP Global Naming Tree. Kaţdý uzel stromu má označení sloţené z textového 10
popisu a číselného integeru. Výrobcům hardwaru jsou přidělovány subtree (podstromy) a ti potom mohou vytvářet svou vlastní neomezeně velkou strukturu objektů. Všechny uzly a objekty v MIB struktuře jsou očíslovány, aby bylo moţné přistupovat ke kaţdému objektu pomocí jeho unikátního čísla. Jméno uzlu nebo objektu vyjádřené sekvencí číselných integerů se nazývá OID (Object Identifier). Z obrázku 1.1 je patrné, ţe objekty v MIB databázi jsou uspořádány podobně jako soubory na pevném disku počítače. Umístění souboru na pevném disku udává plná cesta, objekt v MIB databázi specifikuje OID. Kořenový uzel root nemá ţádný popis a obsahuje další poduzly. Podstrom iso(1), ccitt(0) a join-iso-ccitt(2) .
Obrázek 1.1 - Stromová struktura Management Information Base
Objekty v MIB databázi mohou být skalární, nebo sloupcové. Například objekt hostName, v podstromu Cisco je určen pomocí objekt identifikátoru .1.3.6.1.4.1.9.2.1.3.0, kdy nula na konci OID říká, ţe jde o skalární hodnotu. Pomocí takovýchto skalárních objektů by bylo nemoţné adresovat objekty, jejichţ počet nelze dopředu určit. Jde například o IP adresy ve směrovací tabulce. Proto SNMP definuje i takzvané sloupcové objekty, kde jsou data strukturovaná do tabulek. Tabulky jsou uspořádány do řádků a sloupců. Poloţky v tabulce jsou jiţ skalární hodnoty. SNMP operace přesto nelze provádět nad tabulkou jako celkem, ale pouze nad jednotlivými skalárními hodnotami. Z toho vyplývá, ţe identifikace poloţky v takové tabulce musí být provedena pomocí indexu. Index je poslední číselná hodnota v OID. K sloupcovým objektům přistupujeme 11
pomocí SNMP operace GetNextRequest, kdy projdeme celou tabulku hodnot. To znamená, ţe SNMP manager se začne dotazovat na objekt s indexem 1 a pokračuje, dokud nenačte všechny objekty v tabulce. Skalární objekty mohou mít několik typů hodnot: Integer – jednoduché celé číslo omezené velikostí 32 bitů. Counter – tato hodnota je vlastně počítadlo. Jde o nezáporný integer, jehoţ hodnotu SNMP agent zvyšuje, nastane-li nějaká definovaná událost na zařízení. Při dosaţení maximální hodnoty se pokračuje znovu od nuly. Gauge – obdoba typu counter, ale hodnota nikdy nemůţe překročit maximální hodnotu. SNMP agent můţe hodnotu typu gauge zvyšovat i sniţovat. Tento typ se pouţívá tam, kde hodnota sledované veličiny můţe klesat i vzrůstat. IPAddress – tento ty se pouţívá pro 32 bitové IP adresy TimeTicks – hodnota tohoto typu udává čas v setinách sekundy, který uplynul od určité doby. Jde o 32 bitový nezáporný integer. OctetString – pouţívá se pro vyjádření řetězce znaků, pomocí sekvence oktetů (Bytů). S tímto typem se můţeme setkat například u jména zařízení – hostName.
1.5.
Formát SNMP zprávy
Protokol SNMP pracuje na principu vyměňování zpráv mezi managerem a agenty (BIGELOW, 2004). SNMP zprávy jsou zapouzdřeny do datové části IP paketu. Zprávy jsou předávány pomocí nepotvrzovaného spojení UDP (User Datagram Protokol) na portu 161 a 162. Komunikace je díky nepotvrzovanému spojení velmi jednoduchá a odolná proti chybám (KLAŠKA, 2000).
Obrázek 1.2 – Zapouzdření SNMP zprávy
12
Samotná SNMP zpráva se skládá z hlavičky a dat v PDU (Protocol Data Unit). Hlavička zprávy obsahuje verzi SNMP protokolu a community string, představující velice primitivní formu zabezpečení. Community string je pouţit místo uţivatelského jména a hesla pro přístup k objektům agenta. Na monitorovaném nebo spravovaném zařízení lze většinou nastavit community string pro dva typy přístupu – read-write a read-only. Většina výrobců nastavuje defaultně na svých zařízeních community string „public“ pro přístup pouze pro čtení, a „private“ pro plný přístup. Datová část SNMP zprávy v sobě nese informace o typu operace a OID objektu, na který se ve zprávě dotazuje. Jedná-li se o operaci GetResponse, nese zpráva v poloţce value hodnotu, která je informací o stavu dotazovaného objektu. Jde li o dotazovací zprávu (GetRequest, nebo GetNextRequest), směřující od managera k agentovi, je hodnota value null. Dále jsou v datové části SNMP zprávy poloţky request-id, pro spárování dotazu s odpovědí, error-status a error-index pro indikaci a určení typu chyb.
Obrázek 1.3 – obsah SNMP zprávy GetResponse
Na obrázku 1.3 je obsah SNMP zprávy GetResponse zachycený protokolovým analyzátorem Wireshark. Jde o zprávu, kterou vrací agent (Cisco přepínač Catalyst), jako odpověď na dotaz GetRequest. Předmětem dotazu je objekt hostName, tedy jméno switche specifikované pomocí OID 1.3.6.1.4.1.9.2.1.3.0. V hlavičce zprávy vidíme, ţe je pouţit SNMP protokol verze 2c. Community string je také přenášen v hlavičce zprávy a není nijak šifrovaný. Jde o slabou stránku protokolu, protoţe heslo pouţívané pro komunikaci s agentem můţe být snadno odchyceno. Tento nedostatek řeší SNMP verze 3, která ale
13
není tak rozšířena a podporována výrobci komponent, jako verze 2. V datové části zprávy vrací agent hodnotu dotazovaného objektu, v tomto konkrétním případě jméno switche CZ-CR-C2950B. Datovým typem objektu hostName je OctetString. SNMP zpráva typu trap má stejný formát hlavičky jako ostatní SNMP zprávy, ale formát datové části (PDU) se liší. Sloţení datové části zprávy typu trap se liší i u jednotlivých verzí SNMP protokolu. SNMP verze 1 obsahuje v PDU poloţku enterprise, pro identifikaci objektu, který zprávu vygeneroval. Dále agent-address, pro identifikaci zařízení, odkud je zpráva trap posílána. Také jsou zde poloţky generic-trap, specific-trap a time-stamp, pro identifikaci typu, kódu a času zprávy. Proměnné, které předávají informace o konkrétním trapu, jsou v části variable-bindings. Na obrázku 1.4 je zachycena zpráva trap, kterou posílá agent (Cisco přepínač Catalyst), jako reakci na pokus o neautorizovaný přístup do konfigurace zařízení. V tomto případě je pouţit SNMP protokol verze 1.
Obrázek 1.4 – obsah SNMP zprávy trap (verze 1)
SNMP zprávy trap ve verzi 2 mají odlišný formát datové části od verze 1. Obsahují zde poloţky request-id, error-status a error-index, mající stejný význam jako u zpráv GetRequest a GetResponse. Na obrázku 1.5 je obsah trap zprávy, kterou posílá Cisco přepínač, jako reakci na ztrátu spojení na jednom z jeho portů. V části variable-bindings
14
jsou poloţky, nesoucí informace o události, která zapříčinila odeslání tohoto trapu. Zde lze vyčíst, ţe došlo k události linkDown na portu FastEthernet0/11.
Obrázek 1.5 – obsah SNMP zprávy trap (verze 2c)
1.6.
Nástroje s podporou SNMP
Existuje velké mnoţství softwarových nástrojů vyuţívajících protokol SNMP. Tyto nástroje pouţívají administrátoři pro monitoring a management síťových zařízení. Jejich pomocí odesílá administrátor SNMP poţadavky agentům a přijímá od nich odpovědi. Styl odesílání a přijímání zpráv závisí na konkrétním nástroji. Nástroje jsou GUI (Graphical User Interface), nebo CLI (Command Line Interface). Mezi nástroje s grafickým rozhraním patří například Paessler SNMP Tester. V tomto programu stačí zadat IP adresu monitorovaného zařízení, community string, verzi SNMP protokolu a OID dotazovaného objektu. Po odeslání program zobrazí odpověď, kterou obdrţel od agenta. Dalším nástrojem s podporou SNMP je iReasoning MIB Browser, který v sobě kombinuje prohlíţeč MIB databází a SNMP tester. Tento program umoţňuje procházet MIB databáze, zobrazovat popisy jednotlivých objektů a rovnou odesílat dotazy na tyto objekty agentům. Následně je odpověď od agenta zobrazena v části result table. Net-SNMP je softwarový balíček, který kromě jiného obsahuje řádkového klienta, pomocí kterého lze odesílat a přijímat SNMP zprávy. Net-SNMP pracuje na Unixových
15
systémech i na systémech Microsoft Windows. Po instalaci lze odesílat a přijímat zprávy přímo z příkazové řádky systému. Je zapotřebí dodrţovat danou syntaxi. Příkaz musí obsahovat typ zprávy, verzi protokolu, community string a OID dotazovaného objektu. Například dotaz na objekt hostName odesílaný na Cisco přepínač má následující tvar: snmpget -v 2c -c Public 172.16.64.10 .1.3.6.1.4.1.9.2.1.3.0
Obrázek 1.6 – dotaz a odpověď pomocí nástroje Net-SNMP
Parametr -v udává verzi protokolu, parametr -c udává community string, za ním následuje jméno nebo IP adresa zařízení a OID dotazovaného objektu.
1.7.
Slabé stránky SNMP protokolu a jeho alternativy
Mezi slabé stránky SNMP protokolu patří hlavně jeho zabezpečení. Jak jiţ bylo popsáno v předchozích kapitolách, o nějakém zabezpečení se téměř nedá ani hovořit. Community string, který je heslem a uţivatelským jménem zároveň, je přenášen nešifrovaně v hlavičce protokolu a můţe dojít k jeho odchycení. Na druhou stranu lze tento problém eliminovat logickým oddělením sítí a nastavením přístupů mezi nimi. V praxi se to řeší pomocí VLAN (Virtual Local Area Network), kdy je síť rozdělena na nezávislé části s odděleným provozem. Mezi těmito virtuálními sítěmi lze nastavit přístupy pomocí ACL (Access Control Lists) a tím zajistit, ţe do virtuální sítě, kde jsou aktivní síťové prvky, lze přistupovat pouze z konkrétního rozsahu adres. Při správné segmentaci sítě je zajištěno, ţe do administrace síťových prvků lze přistupovat pouze z VLANy, v níţ jsou
16
jen administrátorské stanice a běţný uţivatel nemá moţnost zachytávat provoz mezi těmito sítěmi. Další slabou stránku monitoringu pomocí SNMP protokolu můţe představovat zbytečné zatíţení sítě. SNMP agenti jsou pasivní a čekají na povel od managera (BIGELOW, 2004). Kdyţ obdrţí dotaz na stav nějakého objektu, odpovídají zprávou GetResponse. Monitoring je tedy nutné provádět pomocí periodicky se opakujících dotazů na agenty (polling). Mezi agenty a managerem s určitou frekvencí putují pakety s dotazy a odpověďmi. Při velké frekvenci těchto dotazů můţe docházet k zatíţení sítě. Na druhou stranu pouţití pasivních agentů zabírá jen velmi malou část systémových zdrojů zařízení a tyto zdroje pak mohou být lépe vyuţity pro jejich primární účely. To je určitě jeden z důvodů velkého rozšíření a podpory od výrobců hardwaru a síťových komponent. Z důvodu zefektivnění monitoringu a managementu vznikl standard RMON (Remote Monitoring). RMON pouţívá inteligentní agenty, kteří provádějí veškeré aktivní zpracování. Princip RMON standardu je tedy opačný neţ je tomu u SNMP. Model klient/server je zde obrácen. Agent vykonává veškeré operace, shromaţďuje a aktualizuje data. Správcovská stanice slouţí pouze pro prezentaci dat, která dostává od agentů. Tím se sniţuje zatíţení sítě. Kromě SNMP a RMON existují samozřejmě i další standardy pro správu sítí. Například protokol DMI (Desktop Management Interface), vytvořený ve spolupráci předních výrobců hardwaru, nebo protokol WBEM (Web Based Enterpise Mamagement).
17
2. Monitoring síťové infrastruktury Monitoring síťové infrastruktury je nezbytnou součástí správy a administrace bezproblémové a vysoce dostupné sítě. Díky monitoringu lze rozpoznat rozdíly mezi správným a chybným chováním sítě. Při řešení problému v síti je nutné porovnávat aktuální výkon oproti známému standardnímu výkonu. Standardní výkon udává běţné chování sítě při bezproblémovém chodu. Pokud se aktuální výkon liší od standardního, lze tento rozdíl vyhodnotit a na jeho základě investigovat vzniklý problém. Stanovení standardního výkonu a jeho aktualizace je tedy nezbytnou sloţkou monitoringu datových sítí. (BIGELOW, 2004)
2.1.
Využití sítě
Vyuţití datové sítě lze definovat jako procentuální počet bitů procházejících sítí, děleno celkovým počtem bitů, které můţe síť přenášet (BIGELOW, 2004). Počet bitů, které můţe síť přenášet, se označuje jako šířka pásma. Počet bitů procházejících sítí se označuje jako propustnost. Pro šířku pásma se také pouţívá výraz bandwidth a jde o mnoţství dat, které lze přenést konkrétní přenosovou technologií. Vyjadřuje se většinou v megabitech za sekundu (Mb/s). Větší šířka pásma znamená větší potenciální schopnost přenosu dat (FEIBEL, 1996).
Využití sítě = (propustnost / šířka pásma) x 100% Pokud je šířka pásma 100 Mb/s a propustnost 20 Mb/s, vyuţití sítě je 20 procent. Vyuţití sítě je vhodné znát ve formě minimálních, maximálních a průměrných hodnot.
2.2.
Zpoždění (latency)
Zpoţdění je čas potřebný pro odeslání zprávy zdrojovým uzlem a její přijetí cílovým uzlem. Zahrnuje zpoţdění na přenosové trase a na zařízeních, které jsou její součástí (KLAŠKA, 2006). Rozlišuje se mezi zpoţděním jednosměrným a obousměrným.
18
Obousměrné zpoţdění zahrnuje dobu cesty paketu ze zdroje k cíly a z cíle zpět ke zdroji. Tomuto zpoţdění se říká round trip latency, nebo round trip time (RTT), a v praxi se pouţívá nejčastěji, protoţe lze změřit z jednoho síťového uzlu. Jitter je pojem pouţívaný pro rozptyl zpoţdění. Stejně jako samotné zpoţdění je i rozptyl zpoţdění důleţitým parametrem sítě, zvláště pro určité druhy aplikací. Například pro provoz IP telefonie jsou doporučené maximální hodnoty RTT = 250 ms, jitter = 50 ms.
2.3.
Nástroje používané pro monitoring sítě
Základní nástroje pro monitoring sítě jsou integrovány ve většině operačních systémů. Pro zjištění dostupnosti síťového uzlu se vyuţívá příkaz ping. Ping je zkratkou pro Packet Internet Groper a pouţívá se pro výměnu zpráv typu echo a echo replay, coţ představuje jedno z nejjednodušších schémat pro monitorování sítě (FEIBEL, 1996). Příkaz ping pouţívá protokol ICMP (Internet Control Message Protocol), který zasílá na cílový uzel zprávu typu echo. Pokud je cílový uzel dostupný odpovídá zprávou typu echo replay. Příjem zprávy echo replay tedy znamená dostupnost spojení s cílovým uzlem. Dalším základním nástrojem diagnostiky sítě je traceroute. Dokáţe zmapovat cestu, kterou paket urazil od zdroje k cílovému uzlu. Nejčastější pouţití tohoto programu je pro zjištění problému způsobujícího nedostupnost cílového uzlu. Existuje spousta dalších programů, které lze pouţít pro monitoring a diagnostiku sítí. Například nástroj MRTG (Multi Router Traffic Grapher), který byl vyvinut pro monitorování zatíţení síťových prvků. Jde o open source nástroj, který vyuţívá SNMP protokol, pro logování jakéhokoliv objektu SNMP agenta pomocí jeho OID. Sesbíraná data nástroj zobrazuje ve formě grafů.
19
3. Požadavky na aplikaci Switch monitoring Nápad vytvořit aplikaci Switch monitoring vznikl na základě praxe s administrací sítě postavené na přepínačích Cisco. Poţadavkem bylo vytvořit aplikaci, která bude poskytovat vizualizaci síťových switchů, informace o jednotlivých portech a zařízeních na nich připojených. Účelem je poskytovat informace o jednotlivých portech switchů. Aplikace bude v reálném čase říkat, které porty jsou vyuţity, a které ne. Dále to, jaká zařízení jsou na jednotlivých portech připojena. V případě nevyuţitého portu bude prezentována historie o tom, kdy byl port naposledy vyuţit.
3.1.
Účel aplikace Switch monitoring
Informace poskytované aplikací Switch monitoring velmi usnadní kaţdodenní rutinní práci síťového správce. Zvláště ve větších podnicích, které jsou „stále v pohybu“, je téměř nemoţné udrţovat stoprocentně aktuální evidenci o tom, které zařízení je kam připojeno. Ať uţ z důvodu častého přemisťování zařízení nebo neustálého rozrůstání sítě. Konkrétně v mém případě dochází stále k navyšování počtu síťových přípojek v kancelářích i ve výrobních prostorech. Tyto zásuvky jsou potom podle potřeby v síťových rozvaděčích propojeny s porty switchů. Samozřejmě zapojeny do switche mají být pouze ty zásuvky, do kterých je připojeno nějaké zařízení. V praxi ale díky častému stěhování počítačů, tiskáren a dalších zařízení, které potřebují síťové připojení, dochází k tomu, ţe i nevyuţité zásuvky jsou propojeny se switchem. Po čase dojde k tomu, ţe všechny porty switche jsou propojeny s různými zásuvkami. Kdyţ je pak potřeba připojit nové zařízení, není kam. Přitom ale některé porty switche nejsou vyuţity, jsou pouze propojeny se zásuvkou, do které na druhé straně, není nic připojeno. Bez stoprocentně aktuální evidence (zařízení-zásuvka-port-switch), která ale není v dynamickém prostředí reálná, je nutné fyzicky kontrolovat zásuvky, zdali jsou vyuţity nebo ne. To je velice časově náročné a neefektivní. Další moţností, je odpojit port, který není právě aktivní, coţ signalizuje LED dioda přímo na switchi. To také není ideální, protoţe zařízení připojené na port switche můţe být zrovna v tu dobu vypnuté. Uţivatel odpojeného zařízení se pak doţaduje urychlené nápravy a celý postup se opakuje stále dokola: fyzické procházení zásuvek, odpojení v tu chvíli neaktivního portu s rizikem dalšího nechtěného „odříznutí“ vypnutého zařízení. Jakékoliv odpojování portů „naslepo“ tedy není vhodným řešením. 20
Proto aplikace Switch monitoring bude dávat informace i o historii. Konkrétně u kaţdého portu, který zrovna není aktivní, bude informace o datu jeho poslední aktivity. Pak bude moţné efektivně vyuţívat kaţdý port switche a při přepojování a oţivování zásuvek nepodstupovat riziko nechtěného odpojení zařízení od sítě. Pomocí několika kliknutí myši bude moţné získat informace o vyuţití portů switche včetně historie. To by měl být hlavní účel aplikace Switch monitoring.
3.2.
Monitorované zařízení
Cílem SNMP dotazů, pomocí nichţ bude aplikace Switch monitoring získávat informace, budou přepínače Cisco Catalyst různých řad. Konkrétně to budou SNMP agenti, kteří jsou součástí kaţdého přepínače. Přepínače Cisco Catalyst jsou vybaveny operačním systémem, který se nazývá IOS (Internetwork Operating System). Tento operační systém je společný pro různé řady switchů a routerů od firmy Cisco. IOS je samozřejmě upraven na míru konkrétním zařízením a je uloţen v paměti v podobě souboru s příponou bin. Verzi IOSu určuje konkrétní typ přepínače. Cisco přepínače mají v zásadě čtyři druhy paměti. Jsou to paměti typu ROM, Flash, NVRAM a RAM. Paměť ROM (Read Only Memory) je nezávislá na napájení a lze z ní pouze číst. V této paměti jsou uloţeny procesy, které se spouštějí při startu přepínače. Paměť typu Flash je nezávislá na napájení a lze do ní zapisovat. V této paměti je uloţen IOS. Paměť NVRAM (Non-Volatile Random Access Memory) je stejně jako Flash zapisovatelná a nezávislá na napájení. Je v ní uloţena startovací konfigurace (startup-config) přepínače. RAM (Random Access Memory) je zapisovatelná paměť, která je však závislá na napájení. Jde o rychlou operační paměť rozdělenou na hlavní paměť procesoru a sdílenou paměť. V hlavní části je uloţena běţící konfigurace (running-config) přepínače a sdílená část slouţí jako buffer pro aktuálně zpracovávané operace. Konfigurace přepínačů se provádí z příkazové řádky – CLI (Command Line Interface) pomocí konfiguračních příkazů IOSu. Ke switchi se lze připojit několika způsoby. Pro základní konfiguraci přepínače se pouţívá připojení pomocí sériového kabelu. Po provedení základní konfigurace a zapojení switche do sítě se pouţívá pro připojení do konfigurace IOSu protokol telnet nebo ssh. Konfigurační příkazy se ukládají do běţící konfigurace (running-config) a provádějí se okamţitě. Běţící konfigurace je uloţena v paměti RAM, která se po vypnutí smaţe. Pokud chceme mít změny konfigurace
21
zachovány i po restartu přepínače, je nutné zkopírovat running-config do startovací konfigurace (startup-config). Přepínače je moţné rozdělit podle různých faktorů. Například podle vrstvy OSI modelu, na které pracují, můţeme zařízení rozdělit na layer 2 switche (C2950, C2960, C3550, atd.) a na layer 3 switche (C4500, C6500, atd.). Nebo můţeme switche dělit na modulární a nemodulární. Poţadavkem na aplikaci Switch monitoring je, aby byla schopna monitorovat různé typy switchů, bez jakýchkoliv změn do zdrojového kódu. Konkrétně bude aplikace monitorovat 34 switchů Cisco Catalyst z řad C4510, C2950, C2960, C3550 a C3560. Nemodulární switche mají 8, 24, nebo 48 portů. Modulární C4510 mají 10 slotů, z nichţ je 6-8 osazeno kartami, které mají 48 metalických portů. Proto bude součástí aplikace databáze, která bude určovat informace o tom, jaké switche mají být monitorovány. Pro kaţdý switch bude v databázi také jakási šablona, podle níţ aplikace pozná, o jaký typ switche jde, a jaké porty má monitorovat.
3.3.
Konfigurační módy Cisco switchů
Rozhraní IOSu je rozděleno do několika módů. V jednotlivých módech lze zadávat různé příkazy pro získávání informací, popřípadě změnu nastavení přepínače. IOS poskytuje odlišné sady příkazů pro kaţdý mód. Základními módy jsou uţivatelský, privilegovaný a konfigurační. V uţivatelském módu lze provádět pouze omezené příkazy a tento mód je dostupný ihned po přihlášení do switche. V privilegovaném módu lze zobrazovat různé informace o zařízení (příkaz show) a lze z něj přistupovat do dalších konfiguračních módů. Pro přístup do privilegovaného módu slouţí příkaz enable. Konfiguračních módů je několik. Základním je globální konfigurační mód, ve kterém se nastavují vlastnosti, které ovlivní funkci celého zařízení. Do globálního konfiguračního módu se přistupuje pomocí příkazu configure terminal. Z globálního konfiguračního módu lze přistoupit do dalších konfigurací, například do konfigurace konkrétního portu (interface configuration). Přístup do konfigurace interfacu se provede příkazem interface plus jméno interfacu. Pro přestup z módu vyšší úrovně do módu niţší úrovně slouţí příkaz exit. Pro návrat do privilegovaného módu z jakékoliv vyšší úrovně slouţí klávesová zkratka Ctrl+z. Příkazy lze zadávat i zkráceně, stačí zadat jednoznačnou část příkazu, která není společná s ţádným jiným příkazem dostupným v konkrétním módu. Tak lze například příkaz configure terminal, zadat pomocí zkráceného conf t. Příkazy lze také doplňovat pomocí
22
klávesy Tab. Stačí napsat několik začátečních písmen a příkaz doplnit stisknutím klávesy Tab. Zadáním otazníku, lze zobrazit seznam příkazů i s jejich popisem, které lze v konkrétním módu provést. Otazník se dá pouţít s kombinací začátečních písmen, kdy bude zobrazena nápověda pouze pro příkazy začínající na tyto písmena.
Obrázek 3.1 – módy IOSu Cisco přepínače
Na obrázku 4.1 je vidět přechod mezi jednotlivými módy v IOSu switche. V jakém módu se nacházíme prozrazuje prompt, coţ je krátký text na začátku řádky. Po přihlášení do správy přepínače se dostáváme do uţivatelského módu, prompt je ve tvaru jméno zařízení plus znak >. Za příkazem enable, následuje privilegovaný mód, který poţaduje při přístupu heslo. Privilegovaný mód je uveden promptem ve tvaru jméno zařízení plus znak #. Příkazem conf t, coţ je zkráceně configure terminal, se dostáváme do globálního konfiguračního módu přepínače, prompt je ve tvaru jméno zařízení plus (config). Konfigurační mód konkrétního portu je na poslední řádce a lze ho rozeznat podle promptu ve tvaru jméno zařízení plus (config-if).
3.4.
Konfigurace SNMP agenta
Popis konfigurace Cisco switchů není náplní této práce, proto je zde dále charakterizováno pouze nastavení umoţňující přístup a komunikaci se SNMP agentem. Jak bylo zmíněno v kapitole o SNMP protokolu, místo uţivatelského jména a hesla se při komunikaci pouţívá community string. Aby bylo moţné odesílat a přijímat zprávy mezi managerem a agentem, je nutné nastavit na přepínačích community string. Ten lze nastavit
23
v globálním konfiguračním módu pomocí příkazu snmp-server community s následujícími parametry: SWITCH(config)#snmp-server community Public ro SWITCH(config)#snmp-server community Private rw První příkaz nastavuje slovo Public jako community string s přístupem pouze pro čtení, to určuje parametr ro (read-only). Druhý příkaz nastavuje slovo Private jako community string s plným přístupem. Dále je ještě moţné místo parametrů ro a rw pouţít parametr view, za nímţ následuje název MIB objektu, k nastavení přístupu pouze na tento objekt. SNMP agent můţe posílat zprávy typu trap, bez dotazu managera, jako reakci na nějakou konkrétní událost. Konfigurace je následující: SWITCH(config)#snmp-server enable traps snmp authentication SWITCH(config)#snmp-server host 137.40.179.208 version 2c Public Prvním příkazem je nastaveno odesílání trap zpráv jako reakce na pokus o neoprávněný přístup do konfigurace zařízení. Tuto událost definuje parametr authentication. Událostí, na které přepínač reaguje odesíláním trap zpráv, je celá řada a jsou rozděleny do několika kategorií, v závislosti na pouţitém zařízení. Dalšími událostmi, společnými pro všechny přepínače, mohou být například linkdown, linkup, coldstart, warmstart, atd. Události lze samozřejmě v příkazu libovolně kombinovat. V druhém příkazu je nastavena IP adresa, na kterou se mají trap zprávy posílat, tedy IP adresa stanice, na které běţí SNMP manager. Za parametrem version je definována verze SNMP protokolu a dále community string, který je nastaven na slovo Public.
24
4. Vytvoření aplikace Switch monitoring 4.1.
Vývojářské prostředí a nástroje
Aplikace Switch monitoring je postavena na platformě .NET společnosti Microsoft. Konkrétně je pro vývoj pouţito prostředí Microsoft Visual Web Developer 2008 Express Edition a Microsoft Visual C# 2008 Express Edition.
4.1.1.
Platforma .NET
Platforma .NET vyuţívá pro vývoj aplikací určených pro operační systémy Microsoft Windows společné řízené běhové prostředí CLR (Common Language Runtime). CLR vykonává základní sluţby jako například správa paměti, správa procesů a zabezpečení kódu (PUŠ, 2004). Dále společné běhové prostředí CLR obsahuje knihovnu tříd .NET framework, která obsahuje kolekci objektově orientovaných typů, pouţívaných pro vývoj aplikací. CLR tedy velmi usnadňuje vývoj aplikací. Aplikace, které nepouţívají systém společného běhového prostředí, jsou zkompilovány přímo pro danou platformu (operační systém). Zdrojový kód aplikace je při kompilaci převeden do strojového kódu počítače. Tím se docílí poměrně rychlého běhu aplikace, ale pouze pro danou platformu. Velkou nevýhodou tohoto systému je nekompatibilita mezi platformami a to i na úrovni odlišných verzí operačních systémů. Často se při pouţívání tohoto typu aplikací objevují problémy způsobené chybou přístupu do operační paměti. Pouţití společného běhového prostředí tuto nevýhodu odstraňuje. CLR při převodu zdrojového kódu do strojového kódu počítače přidá ještě jednu mezivrstvu. Při kompilaci je tedy zdrojový kód převeden do mezikódu MSIL (Microsoft Intermediate Language) a tento mezikód je poté jiţ na cílovém operačním systému převeden běhovým prostředím do strojového kódu (KOVÁŘ, 2006). Převod z mezikódu se provádí vţdy při spuštění aplikace. To vyţaduje vyšší nároky na výkon stanice, ale při výkonu dnešních počítačů tato nevýhoda není nijak zásadní. Naopak velkou výhodu je to, ţe se programátor nemusí starat o uvolňování nepotřebných programových zdrojů z paměti. Tuto práci vykonává prostředí CLR a je pojmenována Garbage Collector.
25
Dalšími důleţitými vlastnostmi platformy .NET jsou společné jazykové specifikace CLS (Common Language Specification) a společný typový systém CTS (Common Type System).
Tyto
vlastnosti
umoţňují
vývoj
.NET
aplikací
v několika
různých
programovacích jazycích vyšší úrovně (MACDONALD a SZPUSZTA, 2006). Tyto programovací jazyky jsou například Visual Basic .NET, C#, Managed C++, F#, J#, atd. Všechny programovací jazyky musí obsahovat kompilátor, který je schopen kompilovat zdrojové kódy do mezikódu MSIL. Aplikace Switch monitoring je napsána v programovacím jazyce C#. Platforma .NET umoţňuje vytvářet aplikace různých typů. Switch monitoring je tvořen dvěma částmi. Jednou z nich je formulářová aplikace pro Windows, která vyuţívá knihovny Windows.Forms a je vytvořena pomocí nástroje Microsoft Visual C# 2008 Express Edition. Druhou část tvoří webová aplikace postavená na technologii ASP.NET, vytvořená nástrojem Microsoft Visual Web Developer 2008 Express Edition.
4.1.2.
Technologie ASP.NET
ASP.NET je technologie určená pro webové aplikace. Její princip je zcela odlišný od starších skriptovacích technologií, kterými jsou například PHP nebo klasické ASP. ASP.NET stejně jako všechny technologie postavené na platformě .NET vyuţívá společné běhové prostředí CLR, coţ přináší všechny výše popsané výhody. Technologie ASP.NET umoţňuje úplné pouţití objektově orientovaného modelu programování. Tento model obsahuje architekturu řízenou událostmi, zaloţenou na ovládacích prvcích. Ovládací prvky jsou v ASP.NET rozděleny do dvou skupin. Jsou to klasické ovládací prvky HTML, které se zachovaly z důvodu zpětné kompatibility a serverové ovládací prvky, které běţí na straně serveru a lze s nimi manipulovat pomocí kódu. ASP.NET není omezen pouţitím jednoho programovacího jazyka. Webová část aplikace switch monitoring je napsána v jazyce C#. Kompilace ASP.NET aplikací se provádí ve dvou etapách. V první etapě se zdrojový kód zkompiluje do mezikódu MSIL, této etapě se říká předběţná kompilace (precompiling). Vznikne tak zkompilovaný soubor s kódem MSIL, který se nazývá assembly. Druhá úroveň kompilace se nazývá JIT (just-in-time) a provede se těsně před tím, neţ se stránka skutečně vykoná (MACDONALD a SZPUSZTA, 2006). V této etapě se mezikód MSIL zkompiluje do nízko úrovňového strojového kódu. Kompilace do strojového kódu můţe být provedena aţ poté, kdyţ kompilátor zná typ operačního systému
26
a hardwarovou platformu, na které aplikace poběţí. Aplikace ASP.NET potřebují pro svou funkčnost IIS (Internet Information Services). Webová část aplikace Switch monitoring běţí na Microsoft Windows Serveru 2003, jehoţ součástí je IIS 6.0.
4.1.3.
Programovací jazyk C#
Zdrojové kódy aplikace Switch monitoring jsou napsané jazykem C#. Tento programovací jazyk byl vyvinutý pro platformu .NET firmou Microsoft. C# v sobě kombinuje vlastnosti některých starších programovacích jazyků a přidává k nim další nové vlastnosti. Vychází hlavně z jazyků Java a C++. Je silně objektově orientovaný a je Microsoftem označován jako hlavní programovací jazyk (PUŠ, 2004). Jde o case-sensitive jazyk, coţ znamená, ţe rozlišuje v kódu velká a malá písmena. Datové typy proměnných vyuţívané jazykem C# jsou stejné jako u ostatních jazyků určených pro platformu .NET. To je dáno pouţitím společného typového systému CTS. Datový typ proměnné tedy určuje, jaké operace lze s proměnnou vykonávat a jak je proměnná uloţena v paměti. Datové typy lze rozdělit do dvou skupin. Jsou to hodnotové typy (value types) a referenční typy (reference types).
Referenční typy jsou často nazývány jako odkazové. Proměnné
hodnotového typu mají svou hodnotu uloţeno přímo v paměti, které se říká zásobník (stack). Do skupiny hodnotových proměnných patří všechny číselné datové typy (Int, Uint, Byte, Sbyte, atd.). Referenční datové typy mají své hodnoty uloţeny v oblasti paměti, která se nazývá spravovaná halda (managed heap). V zásobníku (stack) je pak uloţena pouze reference, coţ je adresa paměti, kde je hodnota uloţena. Mezi referenční typy patří řetězce (String) a všechny třídy. Objektově orientovaný způsob programování přináší mnoho výhod v porovnání s klasickým strukturovaným přístupem. Programy napsané v objektově orientovaném jazyce mají přehlednější zdrojové kódy, jsou srozumitelnější a jdou mnohem snadněji spravovat (KOVÁŘ, 2005). Pokud je v programu potřeba něco vylepšit, provede se úprava několika objektů a zbytek zůstává v původním stavu. Program lze rozloţit na dílčí části – objekty, které vykonávají dílčí úkoly, mají definované vstupy a výstupy (rozhraní), pomocí nichţ komunikují s ostatními objekty. Princip objektově orientovaného programování byl odvozen z elektroniky, kde máme součástky, které mezi sebou komunikují definovaným rozhraním, vnitřek je před okolním světem ukryt. Důleţitým pojmem v objektově orientovaném programování je třída. Třída je šablona pro vytváření objektů. O objektu říkáme, ţe je instancí třídy. Třída tedy definuje co má objekt z dané třídy obsahovat
27
a jakou bude provádět činnost. Objekt, který je instancí třídy má nějaký stav. Stavům se také říká atributy. Tento stav je vyjádřen pomocí datových typů, které jsou většinou skryty před ostatními částmi programu. Ty mohou k stavu objektu přistupovat pouze přes definované rozhraní. Této vlastnosti se v objektově orientovaném programování říká zapouzdření. Kaţdá třída definuje metody, coţ jsou operace, které můţe objekt z dané třídy odvozený vykonávat. Dalším důleţitým pojmem je konstruktor. Konstruktor musí definovat kaţdá třída. Jde o kód, který se postará o první nastavení hodnot atributů všech nově vznikajících objektů.
4.2.
Součásti aplikace switch monitoring
Aplikaci Switch monitoring tvoří dvě části a databáze. Jedná se o webovou část a Windows Forms aplikaci. Windows Forms aplikace v pravidelných časových intervalech získává data ze switchů a zapisuje je do databáze. Provádí tedy polling aktivitu, o které je zmínka v kapitole o SNMP. Konkrétně Windows Forms aplikace kaţdou hodinu odešle SNMP dotazy na všechny přepínače a data získaná z odpovědí od SNMP agentů zapíše do tabulek databáze. Webová část aplikace se stará o zobrazení dat. Zobrazuje data jednak z databáze, tak i data, která získává ze SNMP agenta v době zobrazení stránky. Tím je zajištěna aktuálnost zobrazovaných dat. V databázi je pro kaţdý přepínač samostatná tabulka, do které se ukládají data získaná ze SNMP agentů. Dále jsou v databázi také tabulky, ze kterých aplikace Switch monitoring pozná, které přepínače má monitorovat. V těchto tabulkách je také uloţena pro kaţdý switch jakási šablona, podle které aplikace pozná, kolik portů daný switch obsahuje, a které porty se mají monitorovat. LAN
SNMP
SNMP
Windows Forms část
Webová část
SQL
SQL Databáze
Obrázek 4.1 – součásti aplikace
28
HTTP
4.3.
Webová část aplikace Switch monitoring
Webová část aplikace Switch monitoring se skládá z několika stránek. Je to úvodní stránka default.aspx, která zobrazuje seznam všech monitorovaných switchů (viz příloha – úvodní stránka default.aspx). Switche jsou zde rozděleny do několika skupin, tak aby byly seskupeny podle jejich fyzického umístění. Pro kaţdou skupinu je pouţita jedna tabulka, ve které je výpis switchů z konkrétní části továrny. Těchto částí je celkem pět (hall1, hall2, 1st floor, gates, tent). Dále jsou ještě switche v kaţdé tabulce uspořádány podle umístění v datovém rozvaděči. Tak například v tabulce 1st floor jsou switche rozděleny do skupin A: Hub Room a CR/D: Computer Room. Řádek tabulky reprezentující konkrétní switch obsahuje jméno switche a ikonku, která je na základě kladné odpovědi na ping zelená, nebo v případě nedostupnosti přepínače červená. Umístění kurzoru myši nad ikonku zobrazí titulek s hodnotou odezvy na příkaz ping (TTL). Kliknutím na jméno switche dojde k přesměrování na stránku s informacemi o konkrétním switchi.
Na úvodní stránce lze
také pomocí check boxu určit, zda mají být na další stránce, která reprezentuje konkrétní přepínač, zobrazeny informace o MAC adresách zařízeních, připojených k jednotlivým portům. Načtení MAC tabulky a přiřazení adres ke konkrétnímu portu je poněkud sloţitější, a proto i časově náročnější. Z tohoto důvodu je defaultně nastaveno zobrazování stránky s konkrétním switchem bez informací o MAC adresách. V případě potřeby lze zobrazení a přiřazení MAC adres jednotlivým portům zvolit pomocí check boxu, coţ způsobí, ţe načtení stránky je zhruba o 5 aţ 10 vteřin delší. Do úvodní stránky default.aspx je také pomocí HTML tagu iframe vnořena stránka macSearch.aspx, která díky pravidelnému ukládání všech MAC adres do databáze pomocí Windows Forms části aplikace Switch monitoring, umoţňuje rychlé vyhledávání zařízení připojených do sítě. Další stránkou webové části aplikace Switch monitoring je monitorSimple.aspx. K přesměrování na tuto stránku dojde kliknutím na jméno switche z úvodní stránky default.aspx, v případě ţe se jedná o nemodulární Cisco switch. Na této stránce jsou informace o jednom konkrétním switchi. V úvodním řádku je zobrazeno jméno switche a informace o tom, kolik jeho portů je aktivních (up) a kolik portů je neaktivních (down). Dále jsou na stránce monitorSimle.aspx dvě tabulky. První tabulka odpovídá fyzickému uspořádání portů konkrétního switche. U nemodulárních Cisco switchů jsou porty uspořádány ve dvou řadách. Stejně tak je tomu i v první tabulce na stránce monitorSimple.aspx tak, aby tabulka co nejvíce připomínala čelní pohled na konkrétní
29
switch. Barvu pozadí kaţdé buňky určuje stav portu. V případě ţe je port aktivní, je barva pozadí zelená, v případě ţe je port neaktivní, je barva pozadí červená. Stejné informace o portech jsou zobrazovány na čelním panelu kaţdého switche pomocí LED diod uspořádaných do dvou řad. V kaţdé buňce reprezentující konkrétní port je zobrazeno zkrácené jméno portu. Umístění kurzoru myši nad buňku zobrazí titulek s informacemi o portu. Jsou to informace o zařazení portu do virtuální sítě (VLAN), MAC adresa zařízení připojeného na port switche, popřípadě jméno zařízení, kterému MAC adresa patří. Druhá tabulka na stránce monitorSimple.aspx zobrazuje přehled informací o jednotlivých portech switche. Kaţdému portu odpovídá jeden řádek. Informace jsou uspořádány do sloupců port, status, VLAN, last up. Za jménem portu následuje status, který určuje barvu celého řádku, stejně jako v první tabulce (zelená – aktivní, červená – neaktivní). Další sloupec zobrazuje číslo virtuální sítě (VLAN) do které je port přiřazen. V posledním sloupci je v případě neaktivního portu zobrazen datum a čas, kdy byl port naposledy aktivní (viz příloha – stránka monitorSimple.aspx). V případě zvolení zobrazení informací o MAC adresách na jednotlivých portech, jsou v druhé tabulce navíc dva sloupečky – MAC address a Name, které zobrazují MAC adresu zařízení připojeného na konkrétním portu a jméno zařízení s příslušnou MAC adresou (viz příloha – stránka monitorSimple.aspx kompletní zobrazení). Z důvodu odlišného uspořádání portů u modulárních Cisco switchů, je pouţita další stránka monitorChassis.aspx. Tato stránka poskytuje stejné informace jako výše popisovaná stránka monitorSimpe.aspx. Rozdílné je pouze zobrazení první tabulky, která se de facto skládá z několika tabulek uspořádaných pod sebou. Tyto tabulky představují karty, které jsou fyzicky umístěné v konkrétním modulárním Cisco přepínači (viz příloha stránka monitorChassis.aspx).
4.3.1.
Úvodní stránka default.aspx
V této kapitole budou popsány nejdůleţitější části zdrojového kódu úvodní stránky aplikace Switch monitoring default.aspx. Platforma ASP.NET a vývojové prostředí Microsoft Visual Web Developer umoţňují psát kód stránky dvěma způsoby. První způsob je inline code (přímý kód), který se podobá tradičnímu ASP a veškerý zdrojový kód se ukládá do jednoho souboru s příponou aspx (MACDONALD a SZPUSZTA, 2006). Pouţití tohoto modelu je vhodné v případě, ţe jde o krátký a jednoduchý zdrojový kód. Pro
30
sloţitější a delší kódy je pouţití metody přímého kódu velmi nepřehledné. Druhým způsobem je pouţití code-behind (kód v pozadí), kdy je kaţdá webová stránka rozdělena do dvou souborů s příponami aspx a cs. V souboru s příponou aspx jsou definovány ovládací prvky a soubor s příponou cs obsahuje zdrojový kód. Tento způsob je mnohem více přehledný, protoţe odděluje uţivatelské rozhraní od programovací logiky. Pro všechny stránky webové části aplikace Switch monitoring je pouţit způsob code-behind. Zdrojový kód úvodní stránky je tedy rozloţen do dvou souborů. Je to soubor default.aspx, kde jsou definovány ovládací prvky a soubor default.aspx.cs se zdrojovým kódem. První řádek v souboru default.aspx obsahuje direktivu Page, která specifikuje pouţitý programovací jazyk atributem Language a soubor obsahující kód atributem CodeBehind. <%@Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs" Inherits="SwitchMonitoring._Default" CodeFile="Default.aspx.cs" %>
Úvodní stránka default.aspx obsahuje několik webových ovládacích prvků. Jde o vestavěné ovládací prvky, které jsou součástí FCL (Framework Class Library) a jsou definovány ve jmenném prostoru System.Web.UI.WebControls (KOVÁŘ, 2006). Prvním ovládacím prvkem na úvodní stránce je CheckBox, coţ je zaškrtávací pole, kterým je moţné nastavit, zda má být ze switche staţena i informace o MAC adresách, které jsou připojené za jednotlivými porty. Atributem Runat=“server“ se určuje, ţe jde o plnohodnotný a funkční ovládací prvek na straně serveru, se kterým jde manipulovat pomocí zdrojového kódu (MACDONALD a SZPUSZTA, 2006). Atribut AutoPostBack určuje jestli se má stránka odeslat na server, jakmile dojde ke změně stavu ovládacího prvku. Jedinou událostí ovládacího prvku CheckBox je OnCheckedChanged, která spustí při změně stavu ovládacího prvku blok kódu v souboru default.aspx.cs.
Dalšími ovládacími prvky úvodní stránky jsou tabulky Table. Pro kaţdou lokalitu, ve které jsou rozmístěny switche, je pouţita jedna samostatná tabulka. Je tedy pouţito celkem pět ovládacích prvků typů Table definovaných tak, ţe všechny řádky a buňky tabulky budou vytvořeny dynamicky pomocí kódu v části default.aspx.cs. Těchto pět tabulek je na stránce umístěno v buňkách jedné nadřazené tabulky, která jiţ ovšem není ovládací prvek, ale klasický HTML prvek. ASP.NET samozřejmě umoţňuje pouţití 31
klasických HTML ovládacích prvků, s nimiţ ovšem nejde manipulovat
pomocí
zdrojového kódu.
Do úvodní stránky aplikace Switch monitoring je vloţena pomocí HTML tagu iframe další stránka, která umoţňuje vyhledávání MAC adres v databázi, přiřazuje k těmto adresám jméno switche a název portu, kde bylo zařízení s danou MAC adresou naposledy aktivní a také datum a čas poslední aktivity. Atributy tagu iframe jsou src, ten definuje adresu vnořené stránky, dále width a height, ty definují šířku a výšku vnořeného rámu. <iframe src="macSearch.aspx" width="100%" height="200">
V souboru default.aspx.cs je zdrojový kód úvodní stránky. Ten zajistí naplnění a zobrazení tabulek definovaných v souboru default.aspx, jako ovládací prvky typu Table. Pro zařazení a roztřídění síťových switchů do příslušných lokalit a racků jsou pouţity tři databázové tabulky. Tyto tabulky jsou pojmenovány locality, racks a switch_list. V tabulce locality jsou uloţeny jména lokalit, ve kterých jsou umístěny switche. Kaţdá lokalita má své ID, podle něhoţ lze z druhé databázové tabulky racks určit datové racky, které spadají do této lokality. V tabulce racks je tedy seznam všech datových rozvaděčů. V poslední databázové tabulce switch_list je seznam všech monitorovaných switchů. Příslušnost
32
kaţdého switche do konkrétního racku určuje id_racks. Pouţití těchto databázových tabulek umoţňuje libovolné přidávání nebo ubírání switchů a racků do monitoringu, aniţ by bylo nutné jakkoli zasahovat do zdrojového kódu aplikace Switch monitoring.
Obrázek 4.2 – tabulky zařazující switch do racku a lokality
Na začátku kaţdého souboru s příponou .cs, obsahujícího obsluţný kód stránky, je vţdy část, ve které se importují jmenné prostory pouţitím příkazu using. Tento příkaz umoţňuje pouţívat třídy ze jmenného prostoru, aniţ by se museli psát celé dlouhé názvy tříd (MACDONALD a SZPUSZTA, 2006). Například naimportování jmenného prostoru System.Web.UI, umoţní pouţívat dále v kódu Page, namísto vypisování celého dlouhého názvu System.Web.UI.Page. using using using using using
System; System.Collections.Generic; System.Web; System.Web.UI; System.Web.UI.WebControls;
V další části souboru default.aspx.cz jsou deklarovány veřejné proměnné úvodní stránky. Jsou zde pouţity jednorozměrné a dvourozměrné pole celočíselného datového typu int, dále pole odkazového řetězcového typu string. Pole je datová struktura, která obsahuje více poloţek stejného datového typu (KOVÁŘ, 2005). K jednotlivým poloţkám pole se přistupuje pomocí indexu, coţ je celočíselná proměnná. První prvek pole má index 0, poslední prvek má index n-1, v případě ţe má pole n prvků. Deklarovaná pole jsou v další části kódu naplněna daty z databáze a posléze jsou pouţita pro naplnění tabulek úvodní stránky. public public public public public
string[] switche; string[,] switcheArray; int[] pocetSwitchu; string[] porty; int[,] portyArray;
33
Další pouţitou veřejnou proměnnou je booleovský typ, který můţe nabývat dvou hodnot. Jsou to hodnoty false, nebo true. V tomto případě je pouţita proměnná bool bMAC, která je inicializovaná na výchozí hodnotu false. Tato proměnná odráţí stav ovládacího prvku CheckBox ze souboru default.aspx. public bool bMAC = false;
Změnu hodnoty booleovské proměnné obsluhuje metoda CheckedChanged/(), která se vykoná vţdy po změně stavu ovládacího prvku CheckBoxMAC. V této metodě je pouţit příkaz if/else, který v případě splnění podmínky CheckBoxMAC.Checked (zaškrtnuté políčko), nastaví hodnotu bMAC na true, v případě ţe podmínka není splněna (políčko není zaškrtnuté), nastaví hodnotu bMAC na false. Proměnná bMAC je dále v kódu předána jako parametr URL odkazu na další stránku. protected void CheckBoxMAC_CheckedChanged(object sender, EventArgs e) { if (CheckBoxMAC.Checked) { bMAC = true; } else { bMAC = false; } }
CheckBoxMAC.Checked true
false
bMAC = true
bMAC = false
Obrázek 4.3 – diagram činnosti události CheckedChanged
34
Metoda Page_Load/() se zavolá automaticky vţdy při načtení stránky. Je zde pouţit příkaz if, který na základě podmínky !IsPostBack spustí další metody, které dynamicky naplní tabulky deklarované v souboru default.aspx. Vlastnost IsPostBack má při prvním poţadavku na stránku hodnotu false. Tím je zajištěno, ţe SQL dotazy a naplňování tabulek deklarované v metodách NaplnTabulku1stFloor/() a dalších, bude spuštěno pouze při prvním volání úvodní stránky. protected void Page_Load(object sender, EventArgs e) { if (!IsPostBack) { NaplnTabulku1stFloor(); NaplnTabulkuHall1(); NaplnTabulkuHall2(); NaplnTabulkuTent(); NaplnTabulkuGates(); } }
Metody naplňující tabulky vyuţívají třídy deklarované v samostatném souboru SQLDotaz.cs. Jsou to třídy SQLdotazCount (viz příloha – třída SQLdotazCount) a SQLdotazArray (viz příloha – třída SQLdotazArray). Z těchto tříd jsou v metodách NaplnTabulku1stFloor() a dalších, vytvořeny objekty, pomocí nichţ jsou z databázových tabulek vyselektovány switche patřící do příslušné lokality a racku.
SQLdotazCount
SQLdotazArray
- select: string - vysledek: string - what: string - connectionString: string - error: string - ok: bool
- select: string - vysledekArray: string[] - what: string - connectionString: string - error: string - count: int
+ <property> ErrorMessage(): string + UdelejDotazCount(): void +DejVysledek(): string
+ <property> ErrorMessage(): string + UdelejDotazArray(): void +DejVysledek(): string[]
Obrázek 4.4 – diagram tříd SQLdotazCount a SQLdotazArray
V metodě NaplnTabulku1stFloor() je vytvořena proměnná connectionString, která představuje připojovací řetězec k databázi SwitchMonitoring, běţící na Microsoft SQL serveru. string connectionString = "Data Source=SQLSERVER;Initial Catalog=SwitchMonitoring;User ID=scan;Password=password";
35
Další proměnnou je řetězec locality, jehoţ hodnota definuje lokalitu, podle které se v databázi SQL dotazem vyhledají switche a racky odpovídající této hodnotě. string locality = "1st Floor";
V další části kódu metody NaplnTabulku1stFloor() je definován SQL dotaz jako řetězcová proměnná jménem select. Tento SQL dotaz zjistí počet racků z databázové tabulky racks, jejichţ id_locality odpovídá id záznamu z tabulky locality s příslušným jménem (1st Floor). Dále je vytvořen objekt pocetRacku1stFloor, který je instancí třídy SQLdotazCount.
Konstruktorem objektu pocetRacku1stFloor je SQL dotaz, předaný
pomocí proměnné select, řetězec pocet, představující název dotazované entity a dále connectionString, který objektu předává připojovací řetězec k databázi. Dále je v kódu volaná metoda UdelejDotazCount(), nově vytvořeného objektu. Tato metoda pomocí kódu deklarovaného v souboru SQLdotaz.cs (viz příloha – třída SQLdotazCount) vykoná SQL dotaz. V další části je vytvořena proměnná pocetRacku typu int, do které je pomocí metody int.Parse() a metody DejVysledek() naparsován výsledek SQL dotazu, jenţ představuje počet racků v lokalitě 1st Floor. string select = "SELECT COUNT(id) AS pocet FROM racks WHERE id_locality = (SELECT id FROM locality WHERE name = '" + locality + "')"; SQLdotazCount pocetRacku1stFloor = new SQLdotazCount(select, "pocet", connectionString); pocetRacku1stFloor.UdelejDotazCount(); int pocetRacku = int.Parse(pocetRacku1stFloor.DejVysledek());
Obdobným způsobem je v další části kódu metody NaplnTabulku1stFloor() vytvořen objekt racky1stFloor, který je instancí třídy SQLdotazArray deklarované v souboru SQLdotaz.cs (viz příloha – třída SQLdotazArray). V tomto bloku kódu je vytvořena proměnná racky typu pole řetězců string[], do které jsou pomocí metod UdelejDotazArray() a DejVysledek() objektu racky1stFloor uloţeny jména racků z lokality 1st Floor. string selectRacky = "SELECT name FROM racks WHERE id_locality = (SELECT id FROM locality WHERE name = '" + locality + "')"; SQLdotazArray racky1stFloor = new SQLdotazArray(selectRacky, "name", pocetRacku, connectionString); racky1stFloor.UdelejDotazArray(); string[] racky = new string[pocetRacku]; racky = racky1stFloor.DejVysledek();
36
Po vykonání bloků kódu popsaných výše je znám počet a jména racků v konkrétní lokalitě. Dalším úkolem je zjistit jména switchů v příslušných rozvaděčích. Protoţe počet racků v různých lokalitách můţe být odlišný, popřípadě se můţe v průběhu času změnit, je třeba zajistit, aby byl kód, zjišťující počet a jména switchů v příslušném racku, vykonán právě tolikrát, kolik je v lokalitě racků. Proto je v další části kódu pouţit cyklus for, který vykonává blok příkazů opakovaně, v závislosti na proměnné, zvané čítač (KOVÁŘ, 2005). Vykonání příkazu for začíná inicializací čítače, coţ je řídící proměnná cyklu, která se určitým způsobem aktualizuje a řídí, kdy cyklus skončí. Po inicializaci řídící proměnné následuje vyhodnocení podmínky, která většinou obsahuje hodnotu čítače. Pokud se podmínka vyhodnotí jako true, následuje provedení bloku příkazů v těle cyklu. Po provedení těla cyklu následuje aktualizace čítače, který se většinou inkrementuje o jednotku. Následuje opětné vyhodnocení podmínky a celý cyklus se opakuje, dokud není podmínka vyhodnocena jako false. V těle příkazu for, který nahraje do proměnných jména switchů patřících do příslušného racku a lokality, jsou obdobným způsobem jako ve výše popisovaném bloku kódu, vytvořeny objekty z tříd SQLdotazArray a SQLdotazCount. Jelikoţ je v kaţdé lokalitě několik racků a v kaţdém racku je několik switchů, je pouţito dvourozměrné pole switchArray [i, j], jehoţ index prvního rozměru i udává rack a index druhého rozměru j udává switch. Ze stejného důvodu jsou pouţity dva cykly for, kdy první cyklus uloţí jména všech switchů z daného racku do jednorozměrného pole switche a druhý vnořený cyklus for zajistí uloţení všech switchů z dané lokality do dvourozměrného pole switcheArray. for (int i = 0; i < pocetRacku; i++) { //Blok příkazů zajišťující vytvoření objektů a vykonání SQL dotazů //Obdobně jako v předchozích blocích kódu switche = new string[pocetSwitchu[i]]; switche = switche1stFloor.DejVysledek(); for (int j = 0; j < switche.Length; j++) { switcheArray[i, j] = switche[j]; } }
37
Jako podmínka pro vykonávání prvního cyklu je i < pocetRacku, kdy i je inicializováno na hodnotu nula a s kaţdou další interací je inkrementováno o jednotku. To zajistí vykonání bloku kódu v těle cyklu právě tolikrát, kolik je racků v příslušné lokalitě. Podmínkou druhého vnořeného cyklu je j < switche.Length, kde Length udává počet záznamů jednorozměrného pole switche. To zajistí uloţení a zařazení všech switchů v dané lokalitě do dvourozměrného pole. Na obrázku 4.5 je znázorněn diagram činnosti výše popsaného bloku kódu.
int i = 0 i < pocetRacku i++ false true Vytvoř objekty SQL dotaz Ulož proměnnou
int j = 0
j < switche.Length false true
j++
Ulož proměnnou
Obrázek 4.5 – diagram činnosti vnořených cyklů for
38
Po vykonání výše popsaných bloků kódu je znám počet a jména racků v konkrétní lokalitě i počet a jména switchů v kaţdém racku. Tato data byla pomocí SQL dotazů uloţena do veřejných proměnných. Dále je také v proměnné portyArray uloţen počet portů kaţdého konkrétního switche. Tento údaj je dále v kódu pouţit v podmínce, podle které se vytvoří odkaz na další stránku aplikace Switch monitoring. V následujícím bloku kódu je zajištěno dynamické naplnění tabulky. Jsou zde pouţity opět dva cykly for, kdy první cyklus vytvoří řádek tabulky se jménem racku. Tento cyklus se opakuje tolikrát, kolik je v lokalitě racků a jeho podmínkou je i < pocetRacku. Druhý cyklus je vnořen do prvního, a kaţdá jeho interace vytvoří řádek tabulky se jménem switche. Podmínkou druhého cyklu je j < pocetSwitchu[i]. Řádek reprezentující switch je sloţen ze dvou buněk. V první buňce je ikonka, která je zelená v případě ţe switch odpovídá na ping, nebo červená, v případě ţe switch neodpovídá. V druhé buňce je jméno switche, které je zároveň hypertextovým odkazem na další stránku. for (int i = 0; i < pocetRacku; i++) { //kód vypisující řádky se jmény racků for (int j = 0; j < pocetSwitchu[i]; j++) { //kód vypisující řádky a buňky se jménény switchů } }
Samotné vytvoření řádků a buněk tabulky je realizováno pomocí tříd TableRow a TableCell z jmenného prostoru System.Web.UI.WebControls. Nejprve je vytvořen objekt radka a bunka. Poté je atributem ColumnSpan = 2 objektu bunka nastaven přesah buňky v tomto řádku, přes dvě buňky v řádcích následujících. Atributem Text = racky[i] je do buňky vepsán název racku z proměnné racky[]. Atributy Font.Bold a Width je nastaveno tučné písmo a šířka buňky. Dále je příkazem Cells.Add(bunka) přidána buňka do řádku a příkazem Rows.Add(radka) je přidána řádka do tabulky Tabulka1stFloor, která je deklarovaná v souboru Default.aspx. TableRow radka = new TableRow(); TableCell bunka = new TableCell(); bunka.ColumnSpan = 2; bunka.Text = racky[i]; bunka.Font.Bold = true; bunka.Width = 250; radka.Cells.Add(bunka); Tabulka1stFloor.Rows.Add(radka);
39
V předchozím odstavci je popsán kód, který vypíše řádek tabulky se jménem racku. Vypsání dalších řádků tabulky je ošetřeno obdobným způsobem s drobnými odlišnostmi. Řádky reprezentující jednotlivé switche se skládají z dvou buněk, a proto zde není pouţit atribut ColumnSpan = 2, naopak jsou vytvořeny dva objekty z třídy TableCell, které jsou následně přidány do objektu třídy TableRow. Do první buňky je na základě podmínky if/else přidána ikona, znázorňující svojí barvou stav switche. Pro zjištění stavu switche je vytvořen objekt ping, který je instancí třídy CMDping, deklarované v samostatném souboru CMDcommand.cs (viz příloha - třída CMDping).
CMDping - command: string - vysledek: string + <property> Ping(): bool + <property> TTL(): string +SendPing(): void
Obrázek 4.6 – diagram třídy CMDping
Tato třída vyuţívá další třídy ze jmenného prostoru System.Diagnostics, umoţňující pouţití příkazového řádku MS Windows cmd.exe. Konstruktorem objektu ping je textový řetězec obsahující klasický příkaz ping s parametrem /n 1, který zajistí odeslání pouze jedné zprávy Echo Request na switch, jehoţ jméno je získáno z proměnné switcheArray[i, j]. Pouţití parametru /n 1 urychluje načítání úvodní stránky default.aspx. CMDping ping = new CMDping("/c ping " + switcheArray[i, j] + " /n 1"); ping.SendPing();
V dalším bloku kódu je vytvořen objekt image, kterému je na základě podmínky if/else atributem ImageUrl předán obrázek s příponou gif. Atribut ToolTip = ping.TTL zobrazí popisek s dobou odezvy switche. Image image = new Image(); if (ping.Ping) { image.ImageUrl = "green-recent.gif"; image.ToolTip = ping.TTL; bunkaSwitchStatus.Controls.Add(image); } else { image.ImageUrl = "red-recent.gif"; bunkaSwitchStatus.Controls.Add(image); }
40
Druhá buňka v řádce reprezentující switch obsahuje text se jménem switche. Tento text je zároveň hypertextový odkaz na další stránku aplikace Switch monitoring. Pro vytvoření
odkazu
je
pouţita
třída
HyperLink
ze jmenného
prostoru
System.Web.UI.WebControls, ze které je vytvořen objekt odkaz. Text odkazu je získán z proměnné switcheArray[,], kde jsou uloţena jména všech switchů v dané lokalitě. Index i udává pořadové číslo racku v lokalitě, index j udává pořadové číslo switche v racku. Díky pouţití dvou cyklů for, z nichţ první se opakuje i krát (počet racků v lokalitě) a druhý j krát (počet switchů v racku), je zajištěno pouţití správného jména switche z dvourozměrného pole switcheArray[,]. Dále je v tomto bloku kódu pouţita podmínka if/else, která na základě počtu portů konkrétního switche vytvoří URL na další stránku. Jestliţe se jedná o nemodulární switch, který má maximálně 48 metalických portů, dojde k vytvoření odkazu na stránku monitorSimple.aspx. Jedná-li se o modulární switch, vytvoří se odkaz na stránku monitorChassis.aspx. V obou případech jsou součástí adresy parametry, které slouţí pro předávání informací ze stránky na server. První parametr je vţdy oddělen znakem otazník ?, další parametry jsou odděleny znakem ampersand &. Prvním parametrem adresy je jméno switche z proměnné switchArray[,], na základě kterého dojde na další stránce k odeslání SNMP dotazů na konkrétní switch. Druhý parametr MAC předá proměnnou bMAC, která určuje, zda má být staţena MAC tabulka z konkrétního switche. TableCell bunkaSwitch = new TableCell(); HyperLink odkaz = new HyperLink(); odkaz.Text = switcheArray[i, j]; odkaz.ForeColor = System.Drawing.Color.White; odkaz.Font.Underline = false; if (portyArray[i, j] > 48) odkaz.NavigateUrl = "monitorChassis.aspx?switchName=" + switcheArray[i, j] + "&MAC=" + bMAC; else odkaz.NavigateUrl = "monitorSimple.aspx?switchName=" + switcheArray[i, j] + "&MAC=" + bMAC; bunkaSwitch.Controls.Add(odkaz);
Naplnění zbývajících tabulek úvodní stránky default.aspx je zajištěno dalšími metodami, které jsou identické s metodou NaplnTabulku1stFloor(). Naplnění tabulky je graficky naznačeno v příloze (diagram činnosti naplnění tabulky).
41
4.3.2.
Stránka monitorSimple.aspx
Stránka monitorSimple.aspx zobrazuje informace o jednom konkrétním přepínači, jehoţ jméno je předáno z úvodní stránky default.aspx jako parametr v URL. Stránka monitorSimple.aspx obsahuje několik webových ovládacích prvků. Jde opět o vestavěné ovládací prvky, definované ve jmenném prostoru System.Web.UI.WebControls. První dva webové ovládací prvky jsou typu Label a pomocí kódu v souboru monitorSimple.aspx je vytvořen text v těchto prvcích. První Label se jménem Nadpis zobrazuje jméno switche a informaci o tom kolik z jeho portů je zrovna aktivních. Druhý Label se jménem Datum zobrazuje datum a čas načtení stránky.
Další ovládací prvky jsou dvě tabulky Table. První tabulka TabulkaBarevna uspořádáním buněk připomíná switch z čelního pohledu. Kaţdá buňka představuje jeden port switche a svojí barvou určuje, zda je port aktivní či nikoli. Druhá tabulka TabulkaKomplet zobrazuje detailnější informace. Pro kaţdý port switche je vygenerována jedna řádka se jménem portu, stavem portu, zařazením do virtuální sítě, poslední aktivitou portu, popřípadě MAC adresou a jménem zařízení připojeném za konkrétním portem.
Dynamické naplnění těchto webových ovládacích prvků obstarává kód v souboru monitorSimple.aspx.cs. Kód, který získává data ze SNMP agenta konkrétního switche a prezentuje je v podobě přehledných tabulek v internetovém prohlíţeči, obsahuje něco málo přes 800 řádků, proto zde budou popsány pouze důleţité části. Kompletní zdrojové kódy všech součástí aplikace Switch monitoring jsou přiloţeny na CD. Kód v souboru monitorSimple.aspx.cs je rozdělen do několika metod, které postupně vykonávají dílčí kroky, jejichţ cílem je zobrazení informací uspořádaných v tabulkách. Nejprve je pomocí 42
metody NactiPredanyParametr() získáno jméno switche, které je parametrem v adrese stránky. Dále jsou metodou NactiTemplatesDB() získány z databáze informace o konkrétním switchi. V metodě NactiDataZeSwitche() je zajištěna komunikace se SNMP agentem konkrétního switche. Další metoda NactiHistoryDB() načte z databáze informace o poslední aktivitě portů, která jsou do databáze ukládána Windows Forms částí aplikace Switch monitoring. Další dvě metody NactiMACZeSwitche() a NactiMACReport() jsou volány pouze v případě, ţe je ze stránky Default.aspx předán parametr MAC=true. Poslední metoda NaplnTabulku() zajišťuje naplnění obou tabulek deklarovaných v souboru monitorSimple.aspx.
Diagram
činnosti
viz
příloha
(diagram
činnosti
stránky
monitorSimple.aspx). Metoda NactiPredanyParametr() vyuţívá objekt Request, který umoţňuje číst hodnoty zasílané prostřednictvím webového poţadavku (KOVÁŘ, 2007). Tento objekt je instancí třídy System.Web.HttpRequest, a zajišťuje přečtení dat z adresy a jejich následné uloţení do proměnných. private void NactiPredanyParametr() { jmenoPredanyAdresou = Request.Params["switchName"]; bMAC = bool.Parse(Request.Params["MAC"]); }
Metada NactiTemplatesDB() načte z databáze informace o konkrétním switchi. Jde o hodnoty ve sloupcích port_count a zacatek_nazvy z tabulky switch_list. Čtení dat z databáze je zajištěno stejným způsobem jako v souboru default.aspx.cs. V SQL dotazech je pouţito jméno switche získané metodou NactiPredanyParametr(). SELECT port_count FROM switch_list WHERE name = '" + jmenoPredanyAdresou
Hodnota port_count reprezentuje počet portů konkrétního switche. Hodnota zacatek_nazvy je pouţita z důvodu, ţe některé informace o portech switche jsou poskytovány SNMP agentem ve formě sloupcových (tabulkových) objektů. Pro kaţdý port switche je v této tabulce záznam, ke kterému je moţno přistoupit pomocí indexu na konci objekt identifikátoru. Takový přístup je pro účel této stránky nepouţitelný, proto jsou odesílány SNMP zprávy typu GetNextRequest, které získají postupně všechny hodnoty sloupcového objektu. Záznamy jsou načítány kompletně jeden po druhém. To znamená, ţe 43
SNMP agent vrací informace o všech interfacech switche (i virtuálních). Řazení těchto záznamů je u kaţdého typu switche jiné, proto je potřeba znát hodnotu zacatek_nazvy, určující od kterého objektu bude program data od SNMP agenta zpracovávat. Například pro osmy-portový switch Catalyst C2960 (C117) je v databázové tabulce switch_list hodnota 2 ve sloupci zacatek_nazvy a hodnota 8 ve sloupci port_count, coţ určuje, ţe program má zpracovat a zobrazit informace o portech Fa0/1 aţ Fa0/8. Port Fa0/1 má index 10001, jeho název je vrácen jako třetí odpověď SNMP agenta. Odpovědi jsou počítány od nuly, proto řádku s názvem portu Fa0/1 odpovídá hodnota 2 ve sloupci zacatek_nazvy. (viz obrázek 4.7)
Obrázek 4.7 – sloupcové objekty SNMP agenta
Komunikace se switchem, respektive SNMP agentem daného switche, je ošetřena v metodě NactiDataZeSwitche(). V této metodě jsou na SNMP agenta zaslány zprávy typu GetRequest a GetNextRequest, které se dotazují na objekty s těmito OID: 1.3.6.1.2.1.31.1.1.1.1 – jméno interfacu, sloupcový objekt typu string. 1.3.6.1.4.1.9.2.2.1.1.2 – stav interfacu, sloupcový objekt typu integer. Objekt s hodnotou 1 je ve stavu connected, s hodnotou 0 ve stavu not connected. 1.3.6.1.4.1.9.9.68.1.2.2.1.2 – zařazení interfacu do virtuální sítě, sloupcový objekt typu integer. Hodnota objektu udává ID virtuální sítě. 1.3.6.1.4.1.9.2.1.3.0 – jméno zařízení (host name), skalární objekt typu string. 44
Pomocí těchto objektů lze ze SNMP agenta získat data potřebná k naplnění tabulek. Aplikace Switch monitoring vyuţívá open source utilitu Net-SNMP, která umoţňuje odesílání a přijímání SNMP zpráv z příkazové řádky. Net-SNMP tedy musí být nainstalována na webovém serveru, hostujícím aplikaci Switch monitoring. V první části metody NactiDataZeSwitche(), jsou pomocí Net-SNMP příkazu, odeslány dotazy na objekty switche a odpověď je následně uloţena do proměnných typu string. Nejprve je definován příkaz, který je uloţen do proměnné command. Jde o NetSNMP příkaz typu snmpwalk vyuţívaný pro získání hodnot sloupcových objektů. Parametry příkazu definují verzi pouţitého SNMP protokolu, community string SNMP agenta, jméno dotazovaného zařízení a OID dotazovaného objektu. Následně je vytvořen objekt sInfoN, jehoţ konstruktor cmd určuje, ţe proces spuštěný tímto objektem bude vyuţívat
příkazový
řádek
MS
Windows.
Druhý
konstruktor
předává
příkaz
z proměnné command. Vlastnosti objektu RedirectStandardOutput, UseShellExecute a CreateNoWindow definují přesměrování výstupního streamu dat, pouţití příkazové řádku systému a spuštění procesu v novém okně. Objekt processN je instancí třídy Process, která umoţňuje spouštět lokální i vzdálené systémové procesy. Tento objekt zajistí vykonání příkazu a uloţení odpovědi do proměnné nazvy. Zpracováním popisovaného bloku kódu tedy dojde k uloţení odpovědi SNMP agenta do proměnné typu string. Tato odpověď obsahuje jména všech interfaců daného switche. command = "/c snmpwalk -v 2c -c CommunityString " + jmenoSwitcheDB + " .1.3.6.1.2.1.31.1.1.1.1"; ProcessStartInfo sInfoN = new ProcessStartInfo("cmd", command); sInfoN.RedirectStandardOutput = true; sInfoN.UseShellExecute = false; sInfoN.CreateNoWindow = true; Process processN = new Process(); processN.StartInfo = sInfoN; processN.Start(); nazvy = processN.StandardOutput.ReadToEnd();
Obdobný blok kódu je pouţit pro načtení dalších objektů SNMP agenta. Do proměnné stavy jsou uloţeny stavy (0/1) všech interfaců. Do proměnné VLANy jsou uloţeny ID virtuálních sítí všech interfaců. Do proměnné nazevSwitche je uloţena odpověď na host name konkrétního switche. Data z těchto proměnných je nyní nutné vhodným způsobem upravit a roztřídit tak, aby je bylo moţné v další části programu prezentovat ve formě přehledných tabulek.
45
Obrázek 4.8 – uloţení dat ze switche do proměnných
Na obrázku 4.8 je naznačen obsah jednotlivých proměnných. Z obrázku je také patrné indexování sloupcových objektů. Například index 10001 na konci OID reprezentuje port se jménem Fa0/1. Z odpovědi na druhý SNMP dotaz lze podle stejného indexu určit, ţe tento port je aktivní (1) a odpověď na třetí dotaz říká, ţe je port zařazen do virtuální sítě s ID 10. V další části kódu metody NactiDataZeSwitche() je text z jednotlivých proměnných rozdělen do polí hodnot. Cílem je vytvořit pro kaţdou skupinu hodnot (názvy, stavy, VLANy) proměnnou typu pole, kdy jednotlivé poloţky pole budou obsahovat hodnotu, vztahující se pouze ke konkrétnímu portu (Fa0/1, 1, 10). Déle je potřeba pro kaţdou skupinu hodnot vytvořit pomocnou proměnnou typu pole, která bude obsahovat index OID. Podle této proměnné bude moţné spárovat data vztahující se ke konkrétnímu portu (10001 = Fa0/1 = 1 = 10).
46
Nejprve je text z proměnné nazvy rozdělen do pole hodnot poleNazvy pomocí metody String.Split(). Tato metoda projde textový řetězec, který rozdělí podle definovaného separátoru. Separátorem je ‘\n‘ coţ je znak konce řádky. Do proměnné poleNazvyIndexT je stejným způsobem rozdělen text, z důvodu pozdějšího vyuţití indexu OID pro spárování hodnot. poleNazvy = nazvy.Split('\n'); poleNazvyIndexT = nazvy.Split('\n');
Poloţky proměnné poleNazvy obsahují vţdy jeden řádek textu z proměnné nazvy. poleNazvy[0] = IF-MIB::ifName.1 = STRING: Vl1 poleNazvy[1] = IF-MIB::ifName.60 = STRING: Vl60 poleNazvy[3] = IF-MIB::ifName.10001 = STRING: Fa0/1 ... poleNazvy[11] = IF-MIB::ifName.10501 = STRING: Nu0 Nyní je potřeba z kaţdé poloţky proměnné poleNazvy odstranit nepotřebný text. Pouţitím cyklu for se provede blok kódu pro kaţdou poloţku proměnné poleNazvy. Poslední poloţka je vţdy prázdná, proto i < (poleNazvy.Length – 1). Pomocí metody String.Substring() je text kaţdé poloţky proměnné poleNazvy přepsán textem, který určuje pozice znaku v původním textu (startIndex), a počet znaků (length). Začínající znak textu, který je potřeba přepsat, je nalezen pomocí metody String.LastIndexOf(), jenţ podle poslední dvojtečky v původním textu najde první písmeno názvu portu, a předá metodě String.Substring() jeho pozici v původním textu. Obdobným způsobem je předán i počet znaků (length), který je vypočten jako rozdíl pozice posledního znaku v původním textu a pozice prvního znaku názvu portu. for (int i = 0; i < (poleNazvy.Length - 1); i++) { poleNazvy[i] = poleNazvy[i].Substring(poleNazvy[i].LastIndexOf(":") + 2, poleNazvy[i].LastIndexOf("\r") (poleNazvy[i].LastIndexOf(":") + 2)); poleNazvyIndexT[i] = poleNazvyIndexT[i].Substring(poleNazvyIndexT[i].LastIndexOf(".") + 1, poleNazvyIndexT[i].LastIndexOf(" =") (poleNazvyIndexT[i].LastIndexOf(".") + 1)); poleNazvyIndex[i] = int.Parse(poleNazvyIndexT[i]); }
47
Kaţdá poloţka proměnné poleNazvy obsahuje po vykonání výše popsaného bloku kódu pouze název portu bez zbytečného textu, který byl vrácen v odpovědi SNMP agenta. poleNazvy[0] = Vl1 poleNazvy[1] = Vl60 poleNazvy[3] = Fa0/1 ... poleNazvy[11] = Nu0 Stejným způsobem jsou upraveny a rozděleny do proměnných typu pole i ostatní skupiny hodnot (stavy, VLANy). Pro kaţdou skupinu hodnot je také vytvořena pomocná proměnná s indexem OID. Další metodou v souboru monitorSimple.aspx.cs je metoda NactiHistoryDB(). Tato metoda zajišťuje načtení dat o poslední aktivitě portu z databáze. V databázi je pro kaţdý switch jedna tabulka, do které Windows Forms část aplikace Switch monitoring ukládá kaţdou hodinu aktuální stav monitorovaných portů. Ke kaţdému záznamu samozřejmě ukládá datum a čas. Úkolem metody NactiHistoryDB() je pro kaţdý port switche, který je v době zobrazení stránky neaktivní, vyhledat v databázi datum a čas jeho poslední aktivity. Tento údaj je uloţen do proměnné poleHistoryDB, která je opět typu pole řetězcových hodnot. V metodě je pouţit cyklus for a několik podmínek if a if/else. for (int i = 0; i < pocetPortuDB; i++) { if (poleStavy[i + zacatekNazvyDB] == "1") { poleHistoryDB[i] = ""; } if (poleStavy[i + zacatekNazvyDB] == "0") { // SQL dotaz SELECT datetime FROM + jmenoSwitcheDB + WHERE nazev = '+ poleNazvy[i + zacatekNazvyDB] +' AND stav ='1' ORDER BY datetime DESC"; if (reader.Read()) { if (reader[0] == null) { poleHistoryDB[i] = "Out Of History"; } else { poleHistoryDB[i] = reader[0].ToString(); }
48
Blok příkazů v cyklu for se provede tolikrát, kolik je na switchi monitorovaných portů. První podmínka if v případě aktivního portu (poleStavy[i + zacatekNazvyDB] == "1"), uloţí do proměnné poleHistoryDB prázdný řetězen a cyklus pokračuje další interací. V případě ţe cyklus vykonává interaci odpovídající neaktivnímu portu, dojde k vykonání SQL dotazu. V ukázce kódu je uveden pouze samotný dotaz, kompletní kódy jsou přiloţeny na CD. V případě ţe SQL dotaz vrací hodnotu null, je do proměnné poleHistoryDB uloţen řetězec Out Of History, říkající, ţe port nebyl v době monitorování nikdy aktivní. V případě ţe port byl v době monitorování aktivní, dojde k uloţení data a času
poslední
aktivity
do
proměnné
poleHistoryDB.
Po
dokončení
metody
NactiHistoryDB(), obsahuje proměnná poleHistoryDB pro kaţdý port switche jednu hodnotu, která je buď prázdná (aktivní port) nebo obsahuje text Out Of History (port nebyl aktivní po celou dobu monitorování switche) nebo obsahuje text s datem a časem poslední aktivity (neaktivní port, který byl v minulosti alespoň jednou aktivní). Další dvě metody deklarované v souboru monitorSimple.aspx.cs jsou provedeny pouze v případě, ţe je poţadavkem zobrazit MAC adresy zařízení připojených za jednotlivými porty. Načtení MAC adres ze SNMP agenta konkrétního switche je ošetřeno v metodě
NactiMacZeSwitche().
Načtení
adres
je
poněkud
sloţitější
z důvodu
komplikovaného uspořádání adres v objektech SNMP agenta. MAC adresy jsou uloţeny ve sloupcových objektech, ale jsou rozděleny do skupin podle virtuálních sítí. Znamená to, ţe je nutné odeslat SNMP dotazy pro kaţdou virtuální síť odděleně. To je časově náročné, proto jsou odeslány dotazy pouze tolikrát, kolik je na monitorovaných portech switche nastaveno různých virtuálních sítí. Navíc je nutné pro kaţdou virtuální síť odeslat dotaz na tři odlišné OID. 1.3.6.1.2.1.17.4.3.1.1 – sloupcový objekt typu Hex-STRING 1.3.6.1.2.1.17.4.3.1.2 – sloupcový objekt typu INTEGER 1.3.6.1.2.1.17.1.4.1.2 – sloupcový objekt typu INTEGER Virtuální síť, jejíţ MAC adresy chceme získat ze switche, je nutné uvést v NetSNMP příkazu. ID virtuální sítě je v příkazu uvedeno se znakem zavináče za community stringem SNMP agenta. snmpwalk -v 2c -c CommunityString@21 C117 1.3.6.1.2.1.17.4.3.1.1 49
SNMP dotaz na první OID vrátí v odpovědi všechny MAC adresy, se kterými switch pracuje v dané virtuální síti. Na obrázku 4.9 jsou odpovědí na první SNMP dotaz vráceny čtyři MAC adresy. Poslední MAC adresa 00 E0 4B 19 5E 3F lze pomocí OID indexu 63 spárovat s odpovědí na další SNMP dotaz. V druhé odpovědi OID indexu 63 odpovídá hodnota 2. V třetí odpovědi OID indexu 2 odpovídá hodnota 10002, pomocí které lze z dat získaných metodou
NactiDataZeSwitche() určit ţe MAC adresa
00 E0 4B 19 5E 3F je připojena za portem Fa0/2.
Obrázek 4.9 – načtení MAC adres ze SNMP agenta
Zpracování odpovědí SNMP agenta je zajištěno stejným způsobem, jako v metodě NactiDataZeSwitche(). Nejprve jsou zprávy rozděleny do polí hodnot po jednotlivých řádcích. Následně jsou z textu kaţdé řádky odstraněny nepotřebné znaky. Nakonec jsou pomocí několika cyklů for a podmínek if hodnoty spárovány a seřazeny, poté jsou do proměnné poleMACaddress uloţeny MAC adresy. Metoda NactiMACReport() slouţí k získání jména zařízení podle MAC adresy, která byla zjištěna metodou NactiMacZeSwitche(). Jméno zařízení je získáno z CSV souboru, který obsahuje jména a MAC adresy zařízení, připojených na síti. Tento CSV soubor se automaticky neaktualizuje. Naplnění a aktualizaci dat v tomto souboru je nutné provést ručně, například exportem z DNS serveru. Z tohoto důvodu nelze zajistit, ţe pro kaţdou MAC adresu bude nalezeno jméno zařízení. Vzhledem k tomu ţe se jedná pouze o doplňkovou funkci aplikace Switch monitoring, je tento způsob získání jména zařízení dostačující.
50
Provedením všech výše popsaných metod jsou všechna potřebná data ze switche načtena, upravena a uloţena do proměnných. Nyní ještě zbývá tyto data prezentovat v podobě dvou tabulek. Tento úkol zajišťuje metoda NaplnTabulku(). Ta vygeneruje řádky a buňky tabulek TabulkaKomplet a TabulkaBarevna, deklarovaných v souboru monitorSimple.aspx. Stejně jako v úvodní stránce default.aspx jsou pro generování tabulek pouţity třídy TableRow a TableCell z jmenného prostoru System.Web.UI.WebControls. TabulkaKomplet zobrazuje informace o portech switche v řádcích, kdy kaţdému monitorovanému portu odpovídá jeden řádek. Naplnění tabulky zajišťuje několik cyklů for a podmínek if. for (int i = 0; i < pocetPortuDB; i++) { TableRow newRadek = new TableRow(); //sloupecek s nazvem portu TableCell newBunkaPort = new TableCell(); //obarveni radky zelene nebo cervene podle up/down for (int j = 0; j < (poleStavy.Length - 1); j++) { if (poleNazvyIndex[i + zacatekNazvyDB] == poleStavyIndex[j]) { if (poleStavy[j] == "1") { newBunkaPort.Text = "" + poleNazvy[i + zacatekNazvyDB] + "
"; } if (poleStavy[j] == "0") { newBunkaPort.Text = "" + poleNazvy[i + zacatekNazvyDB] + "
"; } } nazvyV[i] = poleNazvy[i + zacatekNazvyDB]; //dalsi sloupecky (status, VLAN, MAC address, Name, Last Up) }
První cyklus for zajistí provedení bloku kódu tak, aby byl pro kaţdý monitorovaný port switche vygenerován jeden řádek i < pocetPortuDB. Druhý vnořený cyklus zajistí nalezení odpovídajícího stavu portu z proměnné poleStavy, podle indexu OID uloţeného v proměnných poleNazvyIndex a poleStavyIndex. Tento cyklus projde a porovná všechny poloţky proměnné poleStavyIndex s proměnnou poleNazvyIndex pomocí podmíny if. V případě ţe je první podmínka vyhodnocena jako true, je nalezen odpovídající stav portu. Jestliţe je tento stav jedna if (poleStavy[j] == "1"), znamená to, ţe jde o aktivní port a jméno tohoto portu bude v tabulce zobrazeno zeleným písmem jméno portu
. Jestliţe jde o neaktivní port, stav se rovná nule if (poleStavy[j] == "0"), bude jméno portu zobrazeno červeným písmem jméno portu
. Formátovací styly jsou nastaveny 51
v souboru StyleSheet.css. Obdobným způsobem jsou vygenerovány i další buňky nesoucí informace o konkrétním portu. Do proměnné nazvyV jsou uloţeny jména portů, tyto pomocné proměnné jsou vytvořeny i u dalších buněk řádky, z důvodu snadnějšího generování druhé tabulky. Při generování druhé tabulky pak jiţ není nutné provádět porovnání a párování hodnot podle OID indexů. Druhou tabulku je potřeba vygenerovat tak, aby její vzhled odpovídal fyzickému uspořádání portů. Cisco switche mají porty uspořádány ve dvou řadách. Číslování portů je řešeno tak, ţe v horní řadě jsou lichá označení (Fa0/1, Fa0/3, atd.) a v dolní řadě sudá označení portů (Fa0/2, Fa0/4, atd.).
Obrázek 4.10 – uspořádání portů for (int i = 0; i < 2; i++) { TableRow novyRadek = new TableRow(); for (int j = 0; j < (pocetPortuDB / 2); j++) { TableCell novaBunka = new TableCell(); if (i == 0) { novaBunka.Text = nazvyV[j * 2]; //další kód pro obarvení buňky } if (i == 1) { novaBunka.Text = nazvyV[(j * 2) + 1]; //další kód pro obarvení buňky } novyRadek.Cells.Add(novaBunka); } TabulkaBarevna.Rows.Add(novyRadek); }
V kódu generujícím řádky a buňky tabulky TabulkaBarevna jsou opět pouţity cykly for a podmínky if. První cyklus zajistí vygenerování dvou řádků. Druhý cyklus
52
naplní
řádku
buňkami,
jejichţ
počet
odpovídá
polovině
portů
switche
j < (pocetPortuDB / 2). Podmínky if zajistí vygenerování buněk s lichým označením portu do prvního řádku tabulky (i == 0) a buněk se sudým označením portu do druhého řádku tabulky (i == 1). V metodě NaplnTabulku() je také zajištěno vytvoření textu v ovládacím prvku Label definovaném v souboru monitorSimple.aspx. Tento text obsahuje jméno switche předané jako parametr v adrese, jméno switche ze SNMP agenta (host name) a informaci o počtu aktivních a neaktivních portů. int upPorty = 0; int downPorty = 0; for (int i = 0; i < stavyV.Length; i++) { if (stavyV[i].Contains("connected")) upPorty++; if (stavyV[i].Contains("-")) downPorty++; }
Pro tento účel jsou vytvořeny proměnné upPorty a downPorty typu int. Tyto proměnné jsou v cyklu for inkrementovány vţdy, kdyţ index interace cyklu i odpovídá příslušnému stavu portu v proměnné stavyV[i]. Obsah těchto proměnných je poté spolu s dalšími vygenerován ve formě textu do ovládacího prvku se jménem Nadpis. Nadpis.Text = " " + jmenoPredanyAdresou + " | " + nazevSwitche + " | up / down : " + upPorty.ToString() + " / " + downPorty.ToString();
4.3.3.
Stránka monitorChassis.aspx
Stránka monitorChassis.aspx zobrazuje informace o modulárním switchi. Modulární switche obsahují sloty, které mohou být osazeny kartami s optickými nebo metalickými porty. Stránka monitorChassis.aspx obsahuje stejné ovládací prvky jako stránka monitorSimple.aspx. Také kód zajišťující naplnění těchto ovládacích prvků pracuje na stejném principu jako kód v souboru monitorSimple.aspx.cs. Pouze v metodě NaplnTabulku() je nutné vytvořit pro kaţdou kartu modulárního switche jednu 53
samostatnou tabulku, tak aby barevná tabulka na stránce monitorChassis.aspx odpovídala rozloţení portů modulárního switche.
4.3.4.
Windows Forms část aplikace
Windows Forms část aplikace Switch monitoring vykonává polling, coţ znamená, ţe v pravidelných časových intervalech získává data ze switchů a ukládá je do databáze. Tato část aplikace je vytvořena pomocí nástroje Microsoft Visual C# 2008 Express Edition. Tento nástroj umoţňuje vytvářet aplikace určené pro operační systémy Microsoft Windows. Aplikace obsahují ovládací prvky, které mohou být stejné, nebo podobné webovým ovládacím prvkům technologie ASP.NET. Zdrojový kód Windows Forms aplikací je uloţen v souborech s příponou cs. Aplikace zajišťující pravidelný sběr dat ze switchů obsahuje dva ovládací prvky typu Label ze jmenného prostoru System.Windows.Forms. Tyto ovládací prvky jsou spíše informativní, a obsahují informaci o počtu monitorovaných portů a aktuální čas. Dalším ovládacím prvkem je Timer. Timer se pouţívá v aplikacích, kde je potřeba vykonávat určitou činnost bez reakce na uţivatelskou událost (KOVÁŘ, 2006). Timer má tedy uplatnění v případech, kdy je potřeba v pravidelných časových intervalech vykonávat určitou část kódu. V aplikaci Switch monitoring Timer spouští v hodinových intervalech kód, který pomocí SNMP komunikace získává data ze switchů a ukládá je do databáze. Událost timer1_Tick() obsahuje dvě podmínky. První podmínka je pouze informativní, druhá podmínka v kaţdou celou hodinu spustí metodu ZapisDat(), která zajistí získání, úpravu a uloţení dat do databáze. private void timer1_Tick(object sender, EventArgs e) { DateTime dt = DateTime.Now; casNow.Text = dt.ToLongTimeString(); if ((dt.Minute == 59) & (dt.Second == 58)) { status.Text = "Zápis dat ze switchů!"; } if ((dt.Minute == 0)&(dt.Second == 0)) { ZapisDat(); } }
54
Získávání dat ze switchů je zaloţeno na stejném principu jako u webové části aplikace Switch monitoring, s tím rozdílem, ţe zde jsou postupně načteny data ze všech monitorovaných switchů. Opět je zde vyuţit open source nástroj Net-SNMP, pomocí něhoţ lze odesílat a přijímat SNMP zprávy v příkazovém řádku. Také zpracování dat získaných ze SNMP agentů jednotlivých switchů je stejné jako u webové části aplikace. Nejprve jsou zprávy rozděleny do proměnných typu pole a poté jsou z jednotlivých poloţek pole odstraněny nepotřebné znaky. Poslední metoda Windows Forms části aplikace ukládá data do databáze, na rozdíl od webové části, kde jsou data prezentována v tabulkách. V databázi je pro kaţdý switch připravena jedna tabulka, jejíţ jméno je shodné se jménem switche. SQL příkazem INSERT INTO je do těchto tabulek uloţen datum a čas záznamu, název portu switche, stav portu a MAC adresa zařízení připojeného za tímto portem. string strCommand = "INSERT INTO " + jmenoSwitche[indexSwitche] + "\n" + "(\n" + "datetime,\n" + "nazev,\n" + "stav,\n" + "mac\n" + ")\n" + "VALUES" + "(\n" + "'" + dt.ToString("yyyy/MM/dd HH:mm:ss") + "',\n" + "'" + nazvyV[i] + "',\n" + "'" + stavyV[i] + "',\n" + "'" + poleMACaddress[i] + "'\n" + ")\n";
Z důvodu zajištění přesné historie aktivity portů jednotlivých switchů je zapotřebí, aby Windows Forms část aplikace byla neustále spuštěna. Proto jsou části kódu aplikace zajišťující sběr, zpracování a uloţení dat ošetřeny výjimkami, které v případě nedostupnosti některého ze switchů zajistí pokračování programu. Dojde li k chybě při načítání dat ze switche, způsobené jeho nedostupností, je tento switch vynechán a program pokračuje načítáním dat z dalších switchů.
55
Závěr Cílem této práce bylo vytvořit aplikaci, která bude pomocí protokolu SNMP komunikovat s aktivními síťovými prvky Cisco a získané hodnoty prezentovat v běţném webovém prohlíţeči. Aplikace je pojmenována Switch monitoring. Nejprve jsou popsány moţnosti pouţití SNMP protokolu na několika konkrétních příkladech. Pomocí protokolového analyzátoru je v práci rozebrán obsah SNMP zpráv a dále jsou navrţeny dostupné nástroje umoţňující SNMP komunikaci mezi zařízením a správcovskou stanicí. Myšlenka vedoucí k vytvoření aplikace monitorující porty Cisco switchů je zdůvodněna v kapitole 3. Jsou zde také popsány Cisco switche a konfigurace, jeţ je potřebná pro komunikaci s SNMP managerem. Nakonfigurování Cisco přepínačů pro účel monitorování SNMP managerem je velmi jednoduché a zahrnuje několik jednoduchých příkazů. V další části práce je rozebrán princip funkčnosti aplikace Switch monitoring. Aby aplikace byla schopna splňovat všechny stanovené funkce, je rozdělena do dvou programových částí, vyuţívajících databázi. Windows Forms část aplikace se stará o sběr a ukládání dat ze switchů do databázových tabulek v pravidelném časovém intervalu, stanoveném na jednu hodinu. Zvolení hodinového intervalu je optimálním řešením mezi datovou potřebou aplikace na jedné straně a zatěţováním síťových prvků spolu a nadměrně narůstajícím objemem databázových tabulek na straně druhé. Jedním z mnoha moţných vylepšení aplikace Switch monitoring by byla moţnost změny tohoto intervalu bez nutnosti zásahu do zdrojového kódu. Pro tento účel by musela být hodnota intervalu uloţena v databázi spolu s informacemi o konkrétních přepínačích. Webová část aplikace Switch monitoring obstarává zobrazení informací o jednotlivých přepínačích ve webovém prohlíţeči. Z důvodu rychlého načítání stránek jsou umoţněny dvě varianty zobrazení. Zvolením rychlé varianty lze docílit načtení stránky zhruba za jednu vteřinu na úkor chybějících informací o MAC adresách připojených za jednotlivými porty konkrétního switche. Dalším moţným vylepšením by bylo zrychlení načítání stránky s kompletními informacemi včetně MAC adres. Zrychlení by bylo moţné dosáhnout změnou intervalu ukládání dat ze switchů do databáze. Windows Forms část aplikace by musela ukládat data ze všech switchů například v minutovém intervalu. Poté by bylo moţné webovou částí aplikace zobrazovat data přímo
56
z databázových tabulek. Data by byla maximálně jednu minutu neaktualizována, coţ není zásadní omezení. Pouţitím tohoto modelu by odpadla komunikace webové části aplikace se SNMP agenty jednotlivých switchů, čímţ by se sníţil čas načítání stránek. Na druhé straně by velice rychle narůstal objem dat v databázových tabulkách, které by bylo nutné vhodným způsobem promazávat. Bakalářská práce obsahuje všechna fakta, potřebná k vytvoření aplikace komunikující s aktivními síťovými prvky pomocí SNMP protokolu. Cíl práce byl splněn vytvořením funkční aplikace Switch monitoring, jeţ vykonává všechny stanovené funkce.
57
Seznam použité literatury Klasické zdroje [1] BIGELOW, Stephen J. Mistrovství v počítačových sítích- správa, konfigurace, diagnostika a řešení problémů. 2004. ISBN: 80-251-0178-9 [2] FEIBEL, Werner. Encyklopedie počítačových sítí. 1996. ISBN: 80-85896-67-2 [3] MACDONALD, Mathew – SZPUSZTA, Mario. ASP.NET 2.0 a C# - tvorba dynamických stránek profesionálně. 2006. ISBN: 80-86815-38-2 [4] PROSICE, Jeff. Programování v Microsoft.NET - webové aplikace v .NET Framework, C# a ASP.NET. 2003. ISBN: 80-7226-879-1 [5] SHARP, John. Microsoft Visual C# 2005 - krok za krokem. 2006. ISBN: 80-251-1156-3 [6] ŠMRHA, Pavel – RUDOLF, Vladimír. Internetworking pomocí TCP/IP. 1994. ISBN: 80-85828-09-X
58
Elektronické zdroje [1] KLAŠKA, Luboš. Vznik a principy SNMP. Svět sítí [online]. Červen 2000 [cit. 8. března 2009] URL: < http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=23&clanekID=29 > [2] KLAŠKA, Luboš. Model Manager - Agent. Svět sítí [online]. Červen 2000 [cit. 8. března 2009] URL: < http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=23&clanekID=29 > [3] KLAŠKA, Luboš. SNMP objekty a MIB. Svět sítí [online]. Červen 2000 [cit. 10. března 2009] URL: < http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=23&clanekID=31 > [4] KLAŠKA, Luboš. Formát SNMP zpráv. Svět sítí [online]. Červen 2000 [cit. 14. března 2009] URL: < http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=23&clanekID=32 > [5] KLAŠKA, Luboš. Základní kvalitativní parametry sítě. Svět sítí [online]. Prosinec 2006 [cit. 4. dubna 2009] URL: < http://www.svetsiti.cz/view_list.asp?rubrika=Tutorialy&temaID=23 > [6] KOVÁŘ, Dušan. MSIL – Microsoft Intermediate Language. Programování se zaměřením na .NET a jazyk C# [online]. Srpen 2006 [cit. 24. května 2009]. URL: < http://projektysipvz.gytool.cz/ProjektySIPVZ/Default.aspx?uid=498 > [7] KOVÁŘ, Dušan. Objektově orientované programování. Programování se zaměřením na .NET a jazyk C# [online]. Říjen 2005 [cit. 26. května 2009]. URL: < http://projektysipvz.gytool.cz/ProjektySIPVZ/Default.aspx?uid=498 > [8] KOVÁŘ, Dušan. Webové ovládací prvky. Programování se zaměřením na .NET a jazyk C# [online]. Říjen 2006 [cit. 6. června 2009]. URL: < http://projektysipvz.gytool.cz/ProjektySIPVZ/Default.aspx?uid=653 > 59
[9] KOVÁŘ, Dušan. Pole. Programování se zaměřením na .NET a jazyk C# [online]. Listopad 2005 [cit. 6. června 2009]. URL: < http://projektysipvz.gytool.cz/ProjektySIPVZ/Default.aspx?uid=93 > [10] KOVÁŘ, Dušan. Cyklus for. Programování se zaměřením na .NET a jazyk C# [online]. Listopad 2005 [cit. 7. června 2009]. URL: < http://projektysipvz.gytool.cz/ProjektySIPVZ/Default.aspx?uid=98 > [11] KOVÁŘ, Dušan. Objekt Request. Programování se zaměřením na .NET a jazyk C# [online]. Leden 2007 [cit. 23. června 2009]. URL: < http://projektysipvz.gytool.cz/ProjektySIPVZ/Default.aspx?uid=828 > [12] KOVÁŘ, Dušan. Časovač. Programování se zaměřením na .NET a jazyk C# [online]. Březen 2006 [cit. 25. června 2009]. URL: < http://projektysipvz.gytool.cz/ProjektySIPVZ/Default.aspx?uid=285 > [13] PUŠ, Petr. Poznáváme C# a Microsoft .NET – 1. díl. Ţivě.cz [online]. Listopad 2004 [cit. 24. května 2009]. URL: [14] PUŠ, Petr. Poznáváme C# a Microsoft .NET – 2. díl. Ţivě.cz [online]. Prosinec 2004 [cit. 27. května 2009]. URL:
60
Seznam použitého softwaru Microsoft Visual Web Developer 2008 Express Edition Microsoft Visual C# 2008 Express Edition Microsoft SQL Server Management Studio Express Net-SNMP MIB Browser KS-Soft Wireshark Network Protocol Analyzer PhotoFiltre Microsoft Office Visio 2007 Microsoft Office Word 2003
61
Seznam příloh 1. Úvodní stránka default.aspx 2. Stránka monitorSimple.aspx 3. Stránka monitorSimple.aspx kompletní zobrazení 4. Stránka monitorChassis.aspx 5. Třída SQLdotazCount 6. Třída SQLdotazArray 7. Třída CMDping 8. Diagram činnosti naplnění tabulky 9. Diagram činnosti stránky monitorSimple.aspx 10. Zdrojové kódy aplikace Switch monitoring (CD)
62
Příloha 1 Úvodní stránka default.aspx
Příloha 2 Stránka monitorSimple.aspx
Příloha 3 Stránka monitorSimple.aspx kompletní zobrazení
Příloha 4 Stránka monitorChassis.aspx
Příloha 5 Třída SQLdotazCount public class SQLdotazCount { private string select; private string vysledek; private string what; private string connectionString; private string error; private bool ok = true; public SQLdotazCount(string select, string what, string connectionString) { this.select = select; this.what = what; this.connectionString = connectionString; } public void UdelejDotazCount() { SqlConnection connection = new SqlConnection(connectionString); try { connection.Open(); SqlCommand command = new SqlCommand(select, connection); SqlDataReader reader = command.ExecuteReader(); while (reader.Read()) { vysledek = reader[what].ToString(); } reader.Close(); } catch (Exception ex) { error = ex.Message; ok = false; } finally { connection.Close(); } } public string DejVysledek() { return vysledek; } public string ErrorMessage { get { return error; } } }
Příloha 6 Třída SQLdotazArray public class SQLdotazArray { private string select; private string[] vysledekArray; private string what; private string error; private int count; private string connectionString; public SQLdotazArray(string select, string what, int count, string connectionString) { this.select = select; this.what = what; this.count = count; this.connectionString = connectionString; } public void UdelejDotazArray() { vysledekArray = new string[count]; SqlConnection connection = new SqlConnection(connectionString); try { connection.Open(); SqlCommand command = new SqlCommand(select, connection); SqlDataReader reader = command.ExecuteReader(); int i = 0; while (reader.Read()) { vysledekArray[i] = reader[what].ToString(); i++; } reader.Close(); } catch (Exception ex) { error = ex.Message; } finally { connection.Close(); } } public string[] DejVysledek() { return vysledekArray; } public string ErrorMessage { get { return error; } } }
Příloha 7 Třída CMDping public class CMDping { private string command; private string vysledek; public CMDping(string command) { this.command = command; } public void SendPing() { ProcessStartInfo sInfoNazev = new ProcessStartInfo("cmd", command); sInfoNazev.RedirectStandardOutput = true; sInfoNazev.UseShellExecute = false; sInfoNazev.CreateNoWindow = true; Process processNazev = new Process(); processNazev.StartInfo = sInfoNazev; processNazev.Start(); vysledek = processNazev.StandardOutput.ReadToEnd(); } public bool Ping { get { if (vysledek.Contains("TTL")) { return true; } else { return false; } } } public string TTL { get { return vysledek.Substring(vysledek.IndexOf("TTL="), 7); } } }
Příloha 8 Diagram činnosti naplnění tabulky
Řádek locality
int i = 0 i < pocetRacku i++ false true Řádek rack
int j = 0
j < pocetSwitchu[i] false true ping.Ping true
false
Ikona zelená
Ikona červená
portyArray[i, j] > 48 true
false
URL: monitorChasiss.aspx
URL: monitorSimple.aspx
j++
Příloha 9 Diagram činnosti stránky monitorSimple.aspx
NactiPredanyParametr
NactiTemplatesDB
NactiDataZeSwitche
NactiHistoryDB
bMAC
true
false
NactiMACZeSwitche
NactiMACReport
NaplnTabulku
Příloha 10 Zdrojové kódy aplikace Switch monitoring (CD)
