012345

}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Objevování sítˇe a mapování topologie v heterogenních IPv4/IPv6 sítích ˇ B AKALÁ RSKÁ PRÁCE

Jan Sochor

Brno, jaro 2011

Prohlášení Prohlašuji, že tato bakaláˇrská práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.

Jan Sochor

Vedoucí práce: RNDr. Petr Holub, Ph.D. ii

Shrnutí Cílem této práce je provedení analýzy ruzných ˚ pˇrístupu˚ k objevování sít’ových zaˇrízení a mapování topologie na IPv4 i IPv6 sítích v prostˇredí zaˇrízení ruzných ˚ výrobcu. ˚ Souˇcástí práce je také prototypová aplikace v jazyce C# využívající zvoleného postupu objevování sítˇe, která vytvoˇrí mapu sítˇe. Uživatelské rozhraní aplikace obsahuje nastavení parametru˚ použitého protokolu a omezení na soubˇežnˇe komunikující vlákna aplikace.

iii

Executive Summay The goal of this bachelor thesis is to research various approaches to discovery of network devices and topology mapping in heterogeneous IPv4/IPv6 based networks. The part of this thesis is also the implementation of a prototype application that scans the network and creates its diagram. This prototype application, named MyNetDiscoverer, is written in C# and make use of two third-party libraries, namely #SNMP and Graph#. Process of network discovery is based on SNMP (Simple Network Management Protocol) that allows active querying of networks nodes. List of used Management Information Bases is mentioned in chapter 4.6. Application is designed such a way that any update of above mentioned third-party libraries should not affect the functionality itself. Because of selected network discovery approach, the MyNetDiscoverer application requires an IP address of the first network node to be queried as an application input. Presence of SNMP on this selected node is crucial as well as correct SNMP community string, which is used for authentication. Otherwise the application fails with the reason of insufficient network data. The application was tested on three networks – one small home network, the second in virutal environment and the other relatively large one with complex topology. The detailed description of the networks used for testing as well as results of testing are available in the chapter 6.2. Also not author-owned icons were used in this thesis as well as in the application itself. They come from a free to use icon pack which is based on Tango Free Desktop Project1 .

1. Used icon pack: http://www.opensecurityarchitecture.org/cms/library/icon-library

iv

Klíˇcová slova poˇcítaˇcová sít’, objevování sítˇe, mapa sítˇe, topologie, IPv4, IPv6, C#, .NET, #SNMP, Graph#

v

Podˇekování Rád bych podˇekoval svému vedoucímu své bakaláˇrské práce a zamˇestnancum ˚ brnˇenské poboˇcky spoleˇcnosti SolarWinds za cenné rady a zpˇrístupnˇení sít’ové laboratoˇre.

vi

Obsah 1 2

3

4

5

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protokoly pro objevování sítí . . . . . . . . . . . . . . . . . . 2.1 Internet Protocol . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Internet Protocol verze 6 . . . . . . . . . . . . . . 2.2 Simple Network Management Protocol . . . . . . . . . 2.2.1 Vývoj protokolu . . . . . . . . . . . . . . . . . . 2.2.2 Existující verze SNMP . . . . . . . . . . . . . . . 2.2.3 Poskytované operace . . . . . . . . . . . . . . . . 2.3 Management Information Base . . . . . . . . . . . . . . 2.3.1 Object Identifier . . . . . . . . . . . . . . . . . . . 2.3.2 Prohlížeˇce MIB . . . . . . . . . . . . . . . . . . . 2.4 Cisco Discovery Protocol . . . . . . . . . . . . . . . . . . 2.5 Link Layer Discovery Protocol . . . . . . . . . . . . . . 2.6 Spanning Tree Protocol . . . . . . . . . . . . . . . . . . . 2.6.1 Varianty protokolu . . . . . . . . . . . . . . . . . 2.6.2 Princip fungování protokolu . . . . . . . . . . . Souˇcasné postupy objevování sítí . . . . . . . . . . . . . . . 3.1 Postupy použitelné v IPv4 . . . . . . . . . . . . . . . . . 3.1.1 Trasování spojení ke všem uzlum ˚ na síti . . . . . 3.1.2 Broadcast s využitím protokolu˚ správy . . . . . 3.1.3 Dotaz na všechny uzly v síti . . . . . . . . . . . . 3.2 Postupy pro IPv6 sítˇe . . . . . . . . . . . . . . . . . . . . 3.2.1 Multicast s využitím protokolu správy . . . . . 3.3 Postupy vhodné pro IPv4 i IPv6 . . . . . . . . . . . . . . 3.3.1 Postup na bázi link-state smˇerovacího protokolu 3.3.2 Postupné dotazování se znalostí výchozího uzlu Návrh vlastního systému . . . . . . . . . . . . . . . . . . . . 4.1 Návrh postupu procházení sítí . . . . . . . . . . . . . . 4.2 Rozsah vytvoˇrené topologie . . . . . . . . . . . . . . . . 4.2.1 Nastavení rˇ etˇezce community . . . . . . . . . . . 4.3 Informace o pˇripojených sousedech . . . . . . . . . . . . 4.4 Indexy v tabulkách Management Information Base . . . 4.5 Využité Management Information Base . . . . . . . . . 4.6 Pˇrehledové tabulky využitých Object Identifier . . . . . 4.7 Návrh postupu získání dat . . . . . . . . . . . . . . . . . 4.8 Dostupná data bez dalšího využití . . . . . . . . . . . . 4.8.1 Smˇerovací tabulky . . . . . . . . . . . . . . . . . 4.8.2 Tunelování verzí IP . . . . . . . . . . . . . . . . . 4.8.3 Virtuální sítˇe a virtuální uzly . . . . . . . . . . . Implementace systému . . . . . . . . . . . . . . . . . . . . . 5.1 Knihovny tˇretích stran . . . . . . . . . . . . . . . . . . . 5.1.1 Knihovny pro práci s SNMP . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 3 3 3 3 4 4 4 5 5 5 5 6 6 6 7 8 8 8 9 10 10 10 11 11 12 14 14 15 15 15 16 17 22 22 22 24 24 24 28 28 28 vii

5.1.2 Knihovny pro grafickou prezentaci . Použité algoritmy . . . . . . . . . . . . . . . 5.2.1 Postup vytváˇrení topologie . . . . . 5.3 Postup implementace . . . . . . . . . . . . . 5.4 Prostˇredí aplikace . . . . . . . . . . . . . . . 6 Srovnání a ovˇerˇení výsledku˚ systému . . . . . . 6.1 Výstupy aplikace . . . . . . . . . . . . . . . 6.2 Srovnání a ovˇerˇ ení topologie . . . . . . . . 6.2.1 Prostˇredí malé IPv4 sítˇe . . . . . . . 6.2.2 Velká sít’ nad IPv4 . . . . . . . . . . 6.2.3 Testování v prostˇredí IPv6 . . . . . . 7 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . A Obsah pˇriloženého DVD . . . . . . . . . . . . . B Návod k použití aplikace . . . . . . . . . . . . . 5.2

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

29 30 31 33 34 37 38 39 39 40 42 46 50 51

viii

1 Úvod Poˇcítaˇcové sítˇe mají v dnešním svˇetˇe nenahraditelné místo a kvuli ˚ rostoucím požadavkum ˚ na propustnost a kvalitu pˇrenosu prochází neustálým vývojem. Rozvoj poˇcítaˇcových sítí ale nesouvisí pouze s pˇripojováním nových lokalit a ve vytváˇrení nových spojení. Nedílnou souˇcástí je také správa již existujících a používaných sítí, která zahrnuje jak údržbu a opravy jednotlivých sít’ových prvku, ˚ tak monitorování sítˇe, kdy jsou výsledky monitorovacích procesu˚ duležité ˚ pro sít’ové optimalizace, rˇ ešení bezpeˇcnostních incidentu˚ a opravy konfiguraˇcních chyb. Tyto aktivity ale vyžadují také pˇrehled o aktuální logické sít’ové topologii. Dostupnost tˇechto informací pˇrináší správci sítˇe možnost rozhodovat o dalších krocích na základˇe skuteˇcných dat z vlastní sítˇe. Cílem práce bylo vytvoˇrení programového nástroje pro objevování aktivních sít’ových prvku˚ v rámci lokální sítˇe a to v prostˇredí zaˇrízení ruzných ˚ výrobcu, ˚ kde mezi požadavky na program byla také možnost exportu získaných dat do pˇrehledného grafického výstupu. Protože podobné, a pˇrevážnˇe proprietární, aplikace pro IPv4 (Internet Protocol verze 4) sítˇe existují1 , bylo mým hlavním úkolem vytvoˇrit alternativu do prostˇredí IPv6 (Internet Protokol verze 6) pˇri zachování plné kompatibility s IPv4. Výsledná aplikace je pak pˇredevším urˇcena správcum ˚ sítˇe a prvoplánovˇe není cílena na bˇežného uživatele. Postupy nastavení a konfigurace jednotlivých sít’ových prvku, ˚ kvuli ˚ jejich rozmanitosti napˇríˇc spektrem výrobcu, ˚ nejsou souˇcástí práce. Na téma vhodného pˇrístupu pˇri objevování prvku˚ sítˇe v prostˇredí IPv6 již bylo napsáno nˇekolik prací [1, 2, 3]. Jejich výsledky se shodují v tvrzení, že nˇekteré postupy používané v IPv4 sítích nelze bez výraznˇejších modifikací využít v prostˇredí IPv6 [4]. Duvodem ˚ jsou vzájemné odlišnosti tˇechto protokolu, ˚ zejména velikosti adresního prostoru [5] a použití odlišných základních protokolu˚ – NDP (Neighbor Discovery Protocol) místo ARP (Address Resolution Protocol). V první fázi bylo potˇreba zjistit, jaké prostˇredky a sít’ové protokoly pro objevování prvku˚ na IPv6 sítí existují a jaká je podpora tˇechto protokolu˚ v sít’ových zaˇrízeních ruz˚ ných výrobcu. ˚ Druhá fáze obnášela potvrzení dostupnosti potˇrebných knihoven pro práci s vybranými protokoly z první fáze a s výbˇerem patˇriˇcných knihoven2 s otevˇreným zdrojovým kódem (open-source) došlo k posunu do fáze tˇretí, zahrnující implementaci tˇechto ˇ knihoven a vytvoˇrení základní funkˇcní kostry programu. Ctvrtá fáze spoˇcívala v nezbytném testování programu ve zkušební laboratoˇri. Zárovenˇ však už probíhala pátá, a zárovenˇ poslední, fáze, která obnášela napojení funkˇcní kostry programu na grafickou knihovnu3 , úpravu programového výstupu a vytvoˇrení jednoduchého prostˇredí k zobrazení a prohlížení generovaných grafu. ˚ Program je napsán s využitím protokolu SNMP (Simple Network Management Protocol), který umožnuje ˇ aktivní dotazování na jednotlivé sít’ové prvky a je proto vzhledem k zamˇerˇ ení programu vhodný. S výhodou bylo využito nˇekolika MIB (Management Information Base)4 , jež popisují data, která program ze sítˇe získává. A pˇrestože další vývoj 1. 2. 3. 4.

Program LANsurveyor od SolarWinds, WhatsUp Gold Network Discovery a další. Knihovna #SNMP (Sharp SNMP) pod licencí Lesser GPL pro jazyk C#. Knihovna Graph# (Graph Sharp) pod Microsoft Public License pro jazyk C#. Pˇrehled nˇekolika standardních MIB: http://www.ieee802.org/1/pages/MIBS.html

1

1. Ú VOD protokolu SNMP stagnuje, držel jsem se pˇri vývoji programu takových postupu, ˚ aby pˇrípadná aktualizace používaných knihoven nevedla k omezení jeho funkˇcnosti. Práce je rozdˇelena do nˇekolika samostatných kapitol, které do jisté míry vychází z postupu rˇ ešení práce. Druhá kapitola obsahuje výˇcet protokolu˚ využitelných k objevování sítí vˇcetnˇe SNMP a ukazuje odlišnosti jednotlivých verzí IP. Ve tˇretí kapitole popisuji souˇ cˇ asné postupy a možnosti samotného objevování sítí. Ctvrtá kapitola pak obsahuje návrh vlastního systému a seznam využitých MIB, vˇcetnˇe typu a množství získávaných dat. Implementace celého systému a zduvodnˇ ˚ ení výbˇeru použitých knihoven tˇretích stran je obsahem páté kapitoly. Souˇcástí páté kapitoly je také popis uživatelského prostˇredí. V šesté kapitole poté ovˇerˇ uji vytvoˇrené topologie a srovnávám vytvoˇrenou aplikaci s komerˇcním produktem LANsurveyor. Popis ovládání aplikace se nachází v pˇríloze B. V práci využívám sadu ikon, které nejsou mým vlastním dílem a ani tvorba tˇechto ikon není souˇcástí mé práce. Jedná se o volnˇe dostupné ikony vycházející ze sady Tango Free Desktop Project5 .

5. Sada ikon: http://www.opensecurityarchitecture.org/cms/library/icon-library

2

2 Protokoly pro objevování sítí 2.1

Internet Protocol

Internet Protocol verze 4 byl standardizován v roce 1981 a tato verze se stala první masivnˇe rozšíˇrenou verzí Internet Protocolu. K adresaci sít’ových uzlu˚ používá 32bitové IP adresy, zapisované jako 4 oktety v desítkové soustavˇe oddˇelené teˇckou a rˇ azené do 5ti tˇríd podle ˇ možností jejich dalšího dˇelení. Cást tˇechto adres je však vyhrazena pro multicast [6] a pro využití v soukromých sítích. Už v devadesátých letech 20. století se objevilo riziko vyˇcerpání IP adres a možného rustu ˚ smˇerovacích tabulek nad kapacity smˇerovaˇcu. ˚ Bylo proto pˇredstaveno nˇekolik úˇcinnˇejších metod rozdˇelování adres – zejména NAT (Network Address Translation, pˇreklad sít’ových adres) a VLSM (Variable-Length Subnet Masking) spoleˇcnˇe s CIDR (Classless Inter-Domain Routing), které eliminovaly omezení plynoucí z pevného rozdˇelení IP adres do tˇríd a pˇrinesly do budoucna možnost šetrnˇejšího zacházení se zbývajícím rozsahem volných IP adres. Protokol spadá pod sít’ovou vrstvu ISO/OSI modelu a k získání adres nižších vrstev využívá obvykle Address Resolution Protocol (ARP). Ten funguje na principu dotazu a odpovˇedi, kdy tazatel vytváˇrí požadavek na hledanou IP adresu a pˇripojuje k nˇemu vlastní identifikaci. Tazateli odpovídá vlastník hledané IP adresy, který do odpovˇedi pˇripojí své adresy na nižších vrstvách. Kvuli ˚ snížení poˇctu ARP dotazu˚ si tazatel ukládá všechny výsledky do doˇcasné tabulky (ARP cache).

2.1.1 Internet Protocol verze 6 Kvuli ˚ nedostaˇcujícímu adresnímu rozsahu Internet Protocolu verze 4 byl navržen nový Internet Protocolu verze 6. Ten pˇrináší rˇ adu vylepšení, kde mezi nejpatrnˇejší patˇrí 128bitová IP adresa (zapisovaná jako osm cˇ tyˇrznakových cˇ ísel v šestnáctkové soustavˇe oddˇelených dvojteˇckou [7]) a dále zmˇeny v protokolové hlaviˇcce. Kromˇe toho došlo také k obmˇenˇe sady využívaných protokolu. ˚ Místo staršího ARP se používá Neighbor Discovery Protocol (NDP), který kromˇe zpˇrístupnˇení adres na nižších vrstvách ISO/OSI modelu v prostˇredí IPv6 umožnuje ˇ také získání platné sít’ové adresy.

2.2

Simple Network Management Protocol

SNMP je protokol pro správu zaˇrízení na IP síti. Používá UDP port 161, vyžaduje ke komunikaci právˇe dvˇe strany a pracuje na principu agenta a správce. Správce posílá agentovi dotazy a pˇrijímá odpovˇedi, pˇriˇcemž jednoho agenta se muže ˚ dotazovat více správcu˚ nezávisle na sobˇe. Agentem je software na spravovaném sít’ovém zaˇrízení, které zasílá správci oznámení a hodnoty. Protokol umožnuje ˇ správci kromˇe cˇ tení i nastavení nˇekterých dostupných hodnot na zaˇrízení. Dostupné hodnoty nedefinuje samotný protokol, ale jsou popisovány v univerzálních MIB (Management Information Base) a adresování prostˇrednictvím OID (Object Identifier). 3

2. P ROTOKOLY PRO OBJEVOVÁNÍ SÍTÍ 2.2.1 Vývoj protokolu První verze (SNMPv1) byla schválena v roce 1988 a témˇerˇ neˇreší bezpeˇcnostní aspekty. Autentizace správce vuˇ ˚ ci agentovi je docílena zasláním nešifrovaného rˇ etˇezce community1 [8]. Ve vˇetšinˇe implementací se využívá nˇekolika rˇ etˇezcu˚ community jako pˇrístupových hesel – u každého je dána úrovenˇ oprávnˇení dle možnosti provést zmˇenu editovatelných hodnot a omezení na rozsah IP adres. Ve výchozím stavu bez dalšího nastavení se ke cˇ tení používá rˇ etˇezec community s hodnotou „public“ a k zápisu hodnot rˇ etˇezec s hodnotou „private“. Bezpeˇcnostní vylepšení a opravy pˇrinesla až druhá verze protokolu (SNMPv2). Nový zpusob ˚ zabezpeˇcení však pro svou složitost nebyl mezi výrobci obecnˇe pˇrijat. Vzniklo proto nˇekolik dalších standardizovaných implementací [9, 10] a postup autentizace správce k agentovi tak ve vˇetšinˇe pˇrípadu˚ zustal ˚ stejný jako v první verzi. Novinkou se staly pouze operace pro získání velkého objemu dat v odpovˇedi na jeden požadavek a vyrˇ ešení bezpeˇcnostních otázek se odložilo do tˇretí verze (SNMPv3). Ta nakonec pˇrinesla kromˇe nˇekolika bezpeˇcnostních modelu˚ i vylepšení v konfiguraci samotného protokolu na dálku [11]. 2.2.2 Existující verze SNMP Bezpeˇcnostní politiky a rozmanitá míra implementace SNMP mezi zaˇrízeními ruzných ˚ výrobcu˚ mˇely za dusledek ˚ vznik více soubˇežnˇe používaných verzí protokolu. Ty se liší pˇrevážnˇe zpusobem ˚ autentizace a pˇrípadným šifrováním, jak uvádí následující tabulka. SNMPv1 SNMPv2p SNMPv2c SNMPv2u SNMPv2* SNMPv3

první verze, autentizace na základˇe rˇ etˇezce community [12] druhá verze protokolu, velmi složitý a komplexní, v souˇcasné dobˇe oznaˇcen za pˇrekonaný [13] druhá verze, k autentizaci využívá rˇ etˇezec community [9] druhá verze, bezpeˇcnost založená na uživatelích [10] není standardizován IETF, založen na SNMPv2u tˇretí verze, implementuje šifrování a bezpeˇcnost založenou na uživatelích [14]

2.2.3 Poskytované operace GetRequest a SetRequest Správce agentovi zasílá krátké zprávy s požadavkem na získání nebo nastavení specifikované hodnoty, odpovˇed’ agenta by mˇela být atomická a obsahuje potvrzení požadavku. GetNextRequest a GetBulkRequest Slouží k procházení celých MIB. Agent na takový požadavek odpovídá hodnotou, která v MIB následuje po hodnotˇe v požadavku. Operace GetBulkRequest byla pˇredstavena až v SNMPv2 a jako odpovˇed’ posílá vˇetší množství hodnot najednou. 1. V angliˇctinˇe je rˇ etˇezec community oznaˇcován jako „community string“.

4

2. P ROTOKOLY PRO OBJEVOVÁNÍ SÍTÍ Trap a InformRequest Pˇredstavují jedinou komunikaci, kterou zaˇcíná agent a informuje tak správce o zmˇenách v síti. Protože SNMP protokol funguje nad nepotvrzovaným UDP, není doruˇcení Trap zprávy garantováno. InformRequest proto pˇri doruˇcení navíc posílá potvrzení.

2.3

Management Information Base

Management Information Base (MIB) popisuje objekty a hodnoty, které mohou být spravovány. Je to hierarchická datová struktura, složená ze sady SNMP objektu˚ a jejich relací a podle funkce muže ˚ zaˇrízeni implementovat více samostatných MIB. Struktura databáze je urˇcena pravidly SMI (Structure of Management Information, definovanými v RFC 1155 [15] a RFC 2578 [16]), která obsahují i datové typy jednotlivých hodnot. 2.3.1 Object Identifier Každá MIB má pˇriˇrazený svuj ˚ identifikátor, a kvuli ˚ potˇrebˇe adresace hodnot má svuj ˚ identifikátor i každý SNMP objekt v rámci MIB. Ty tvoˇrí globální jmenný strom (SNMP Global Naming Tree). Celý strom se dˇelí do tˇrí hlavních vˇetví a položky první úrovnˇe stromu jsou pˇriˇrazeny organizacím, které je spravují. Management Branch zahrnuje standardní MIB podporované vˇetšinou výrobcu, ˚ Experimental Branch obsahuje testovací MIB a MIB ve vývoji a pod poslední Private Branch spadají proprietární MIB jednotlivých výrobcu˚ 2 . 2.3.2 Prohlížeˇce MIB Pro lepší pˇrehled nad strukturou jednotlivých MIB a vyhledávání v celé struktuˇre globálního stromu existuje nˇekolik univerzálních prohlížeˇcu. ˚ Pˇri návrhu systému jsem využíval 3 online prohlížeˇc SNMP Object Navigator , OID Repository4 a desktopový SnmpB5 .

2.4

Cisco Discovery Protocol

Jedná se o proprietární protokol spoleˇcnosti Cisco a všechna zaˇrízení Cisco [17] jej v soucˇ asné dobˇe podporují. Funguje nad druhou vrstvou ISO/OSI modelu (vrstvou datových spoju) ˚ a není závislý na použití dalších protokolu˚ ani zpusobu ˚ fyzického propojení. Sít’ové rozhraní však musí podporovat SNAP (Subnetwork Access Protocol), což vˇetšina používaných pˇrenosových technologií6 splnuje ˇ [17]. Obˇe komunikující strany posílají v pravidelných intervalech stavové zprávy, ve kterých souseda informují o svém stavu a o stavu svých rozhraní (vˇcetnˇe pˇriˇrazených adres na rozhraních, základní identifikace systému i virtuálních sítí). Tyto informace jsou posílány jako multicast7 [18] a také ukládány do tabulek, kde jsou pak pˇrístupné pˇres SNMP v CISCO-CDP-MIB. 2. 3. 4. 5. 6. 7.

Pˇrehled proprietárních MIB: http://www.oidview.com/mibs/detail.html Dostupný online: http://tools.cisco.com/Support/SNMP/do/BrowseOID.do Dostupný online: http://www.oid-info.com Ke stažení: http://sourceforge.net/projects/snmpb V prostˇredí Ethernetu, Frame Relay a ATM je CDP podporováno. CDP využívá multicast adresu 01:00:0c:cc:cc:cc.

5

2. P ROTOKOLY PRO OBJEVOVÁNÍ SÍTÍ

2.5

Link Layer Discovery Protocol

Link Layer Discovery Protocol (LLDP) je standardizovaný protokol [19] (není tak závislý na specifickém výrobci a pˇredstavuje tak vhodný prostˇredek do prostˇredí zaˇrízení ruz˚ ných výrobcu) ˚ a podobnˇe jako Cisco Discovery Protocol používá ke komunikaci vrstvu datových spoju. ˚ Standard je spravován Institutem pro elektrotechnické a elektronické inženýrství (IEEE) pod oznaˇcením 802.1ab. Definuje zpusob, ˚ jakým sít’ová zaˇrízení v prostˇredí Ethernetu mohou informovat své sousedy o vlastním nastavení, a umožnuje ˇ samotnému zaˇrízení pˇristupovat k informacím z vyšších vrstev ISO/OSI modelu. Protokol funguje nad specifickou multicast adresou8 v nespojovaném, jednosmˇerném a pouze informace propagujícím režimu. Sousední uzly tak nemohou ostatní o data požádat, ale cˇ ekají na pravidelné oznámení. V dusledku ˚ toho LLDP neˇreší monitorování zmˇen stavu˚ mezi uzly [21]. Vylepšení LLDP-MED (Media Endpoint Discovery) umožnuje ˇ automatické zjištˇení sít’ových politik (virtuální lokální sítˇe a klasifikaci sít’ového provozu z pohledu kvality služeb) a pˇrináší vylepšenou správu topologie VoIP stanic. Vˇetšina protokolových dat je adresována v LLDP-MIB a je tak pˇrístupná pˇres SNMP.

2.6

Spanning Tree Protocol

Spanning Tree Protocol (STP) operuje na druhé vrstvˇe ISO/OSI, vrstvˇe datových spoju. ˚ V první rˇ adˇe slouží k detekci cyklu˚ ve fyzickém propojení sít’ových uzlu, ˚ ale prostˇrednictvím své konfigurace umožnuje ˇ také ruˇcní vypnutí vybrané linky a disponuje i seznamem náhradních spoju˚ pro pˇrípad výpadku nˇekterého z aktivních spoju. ˚ IEEE tento protokol, principem založený na algoritmu Radie Perlman [22] z roku 1985, standardizoval s oznaˇcením 802.1d. Pro vzdálenou správu prostˇrednictvím SNMP je vˇetšina protokolových informace dostupná v rámci BRIDGE-MIB. Z obsažených tabulek lze získat adresy na úrovni vrstvy datových spoju˚ (MAC adresy) pˇrímo pˇripojených sousedních uzlu˚ podporujících STP. 2.6.1 Varianty protokolu V roce 2001 byl pˇredstaven první z jeho nástupcu˚ jako RSTP se standardem 802.1w. Jeho hlavním vylepšením je výraznˇe zkrácená reakˇcní doba na zmˇeny v topologii, principiálnˇe však zustal ˚ beze zmˇeny. Další verzí je Per-VLAN Spanning Tree (PVST a PVST+) uvedený firmou Cisco jako proprietární protokol. Ten je urˇcen zejména do prostˇredí Virtuálních LAN (VLAN), kdy sestavuje topologický strom pro každou VLAN samostatnˇe. Kromˇe toho existuje i Rapid Per-VLAN Spanning Tree (R-PVST), který kombinuje výhody RSTP a PVST. Poslední verzí je pak Multiple Spanning Tree Protocol (MSTP) standardizovaný jako IEEE 802.1q. V pohledu vytváˇrení více instancí se podobá proprietárnímu PVST. Nevytváˇrí však instance pro každou VLAN, ale formuje Multiple Spanning Tree oblasti, které jsou principiálnˇe propojeny dalším STP. Na síti využívající Virtuální LAN tak na jednom uzlu muže ˚ soubˇežnˇe fungovat nˇekolik instancí STP. V SNMP odpovˇedích z tabulek BRIDGE-MIB se tak muže ˚ v každá MAC 8. V IEEE 802.1ab byly navrženy adresy: 01:80:c2:00:00:00, 01:80:c2:00:00:03 a 01:80:c2:00:00:0e [20].

6

2. P ROTOKOLY PRO OBJEVOVÁNÍ SÍTÍ adresa pˇrímého souseda objevit vícekrát. 2.6.2 Princip fungování protokolu Protokol v rámci sítˇe nejdˇríve výbˇerem nejmenšího identifikátoru zaˇrízení urˇcí koˇrenový uzel. K identifikaci uzlu˚ používá tzv. Bridge ID, skládající se z osmi bajtu. ˚ První dva jsou urˇceny ruˇcním nastavením priority a unikátním cˇ íslem. Zbylých šest je dáno adresou na vrstvˇe datových spoju˚ (MAC adresa). Tyto adresy jsou jedinou souˇcástí celého protokolu STP, které lze pˇri objevování sítˇe využít. Následnˇe jsou všechna sít’ová rozhraní oznaˇcena jedním ze tˇrí stavu˚ (koˇrenový, oznacˇ ený a blokovaný) podle vzdálenosti od koˇrenového uzlu. Na každém zaˇrízení je právˇe jedno rozhraní nejblíže koˇrenovému uzlu vybráno jako koˇrenový port. V rámci každého segmentu sítˇe se dále vybere koˇrenovému uzlu nejbližší uzel a jeho rozhraní pˇripojující tento segment je pak považováno za oznaˇcené. Všechna zbylá rozhraní jsou blokovaná.

7

3 Souˇcasné postupy objevování sítí V souˇcasné dobˇe existuje nˇekolik použitelných postupu, ˚ jak lokální sít’ prozkoumat a jak z ní získat nutné informace pro vytvoˇrení obrazu celé nebo cˇ ásteˇcné topologie. Tyto postupy lze pak rozdˇelit do nˇekolika skupin dle jejich použitelnosti, možného nasazení v závislosti na verzi IP a pˇrípadné potˇreby dalších protokolu. ˚ Pˇresnost vytvoˇrené topologie však závisí na požadavcích a úˇcelu, za jakým je sít’ objevována. U postupu˚ využívajících protokolu˚ pro vzdálenou správu je možné v souˇcasnosti víceménˇe ekvivalentnˇe vybírat ze tˇrí nejpoužívanˇejších protokolu: ˚ SNMP, WMI (Windows Management Instrumentation) a NetBIOS (Network Basic Input/Output System).

3.1

Postupy použitelné v IPv4

3.1.1 Trasování spojení ke všem uzlum ˚ na síti Metoda trasování spojení ke všem sít’ovým uzlum ˚ z pohledu potˇrebné podpory prostˇredí patˇrí mezi nejjednodušší a relativnˇe málo pˇresné metody objevování sítˇe. Metoda využívá sít’ovou utilitu ping, která v prostˇredí IPv4 pracuje nad ICMP (Internet Control Message Protocol) v režimu dotazu a odpovˇedi (ICMP echo request a ICMP echo reply). V prostˇredí IPv6 sítí se místo ICMP využívá ICMPv6. Zmínˇené protokoly ICMP a ICMPv6 slouží k získání informací o spojení se vzdáleným sít’ovým uzlem (zejména round-trip time a packet loss). Samotné získání dat spoˇcívá v trasování1 spojení utility ping. K tomu využívá pole Time-to-Live (TTL, nˇekdy také oznaˇcováno jako hop limit nebo hop count) v hlaviˇcce IP paketu, jehož hodnota je snížena pˇri každém pˇreposlání mezi uzly v síti. Pokud je hodnota TTL snížena na nulu, je paket zahozen. Uzel, který paket zahodil, informuje puvodního ˚ odesílatele zasláním ICMP paketu s informací o vypršení platnosti (ICMP Time Exceeded). Z tˇechto odpovˇedí lze pak sestavit cestu, kudy putují pakety mezi odesílatelem a pˇríjemcem. Vytvoˇrení topologie lokální sítˇe tímto postupem však obnáší trasování spojení ke všem potenciálnˇe aktivním sít’ovým uzlum. ˚ To v pˇrípadˇe cˇ asto používané 24bitové masky sítˇe znamená trasování 254 ruzných ˚ spojení, v pˇrípadˇe kratší masky sítˇe ještˇe výraznˇe více. Kdyby trasování jednoho spojení trvalo sekundu, postupné získání všech výsledku˚ trasování bez paralelního zpracování by zabralo více než 4 minuty. Proto není možné efektivnˇe využít tuto metodu ve vˇetších sítích a nelze podobný postup použít ani v sítích IPv6, kde v rámci lokální sítˇe muže ˚ existovat pˇres 18 × 1018 stanic. Zásadní nevýhody Hlavní nevýhodou celého postupu je relativní nepˇresnost získané topologie. Zejména ve smyslu nepˇresných informací o propojení vzdálených uzlu˚ – kvuli ˚ zpusobu ˚ trasování spojení z jednoho zdroje se jeví výsledná topologie jako strom, což nemusí být pravda. Linky, 1. V prostˇredí operaˇcních systému˚ UNIX a Linux k tomu lze využít pˇríkaz traceroute. Na systému Windows pak podobnˇe pˇríkaz tracert.

8

ˇ 3. S OU CASNÉ POSTUPY OBJEVOVÁNÍ SÍTÍ

které nebyly využity pˇri trasování jednotlivých spojení, totiž ve výsledku zcela chybí. Podobnˇe tímto postupem nelze získat ani informace o mezilehlých zaˇrízeních, které pracují na nižších vrstvách ISO/OSI modelu, jako je pˇrepínaˇc, most nebo rozboˇcovaˇc. Další nevýhodou je nemožná detekce zaˇrízení, jež nesnižují hodnotu TTL a snaží se být vuˇ ˚ ci provozu v síti transparentní. Takový sít’ový uzel totiž nikdy nezašle informaci o zahození paketu. Výhody Pˇredností tohoto postupu vytváˇrení obrazu sít’ové topologie je nezávislost na ostatních protokolech kromˇe IP. Pˇrestože podle RFC 1122 [6] musí každý aktivní uzel na ICMP echo request odpovˇedˇet, nˇekteré spoleˇcnosti považují tuto povinnost za bezpeˇcnostní riziko a jejich produkty tuto cˇ ást požadavku˚ RFC 1122 ignorují. Ze stejného duvodu ˚ muže ˚ dojít ke ztrátˇe ICMP paketu˚ pˇri pruchod ˚ pˇres sít’ový firewall. Tyto situace tak pˇredstavují riziko vedoucí k chybˇejícím uzlum ˚ ve výsledné topologii, tím se v dusledku ˚ stává nevyužití jiného protokolu souˇcasnˇe i nevýhodou. 3.1.2 Broadcast s využitím protokolu˚ správy Jedná se o další postup, jak získat data k vytvoˇrení obrazu sít’ové topologie. Z pohledu využitého protokolu jej lze je rozdˇelit do dvou samostatných fází. V první fázi využívá IP broadcast k objevení všech dostupných uzlu, ˚ které podporují vybraný protokol správy. V druhém kroku vytváˇrí spojení prostˇrednictvím vybraného protokolu (z výše zmínˇeného SNMP, WMI a NetBIOS) ke všem uzlum ˚ objeveným v prvním kroku2 . Pˇresnost a chybovost vytvoˇrené topologie závisí na datech získaných z odpovˇedí kontaktovaných uzlu˚ ve druhé fázi. Duležitou ˚ roli hraje také míra implementace použitého protokolu na dotazovaných sít’ových uzlech a možnosti samotného protokolu. Výhody V porovnání s metodou trasování spojení se jedná o efektivní zpusob ˚ získání zdrojových topologických dat. V pˇrípadˇe použití paralelního dotazování muže ˚ být takový postup navíc velmi rychlý. Nevýhody Jedna nevýhoda plyne už z použití protokolu správy. V ideálním pˇrípadˇe podporují vyˇ braný protokol všechny sít’ové uzly, ale takové situace jsou velmi vzácné. Casto vybraný protokol podporuje pouze malá podmnožina aktivních uzlu˚ a chybˇející informace je tak tˇreba ze získaných dat co nejlépe odvodit. Míra odvoditelnosti se odvíjí od množství dat zpˇrístupnˇených vybraným protokolem správy. Druhou nevýhodou jsou ruzné ˚ reakce sít’ových uzlu˚ na IP broadcast. Vˇetšina implementací agentu˚ 3 jednotlivých protokolu˚ obsahuje nastavení, které ovlivnuje ˇ na jakých ad2. V nˇekterých situacích lze oba kroky provést najednou – dotaz na požadovaná data lze pˇripojit k IP broadcastu použitému k objevení dostupných uzlu. ˚ 3. Agentem se rozumí program na sít’ovém uzlu, který odpovídá na obdržené požadavky.

9


resách uzel odpoví na protokolové požadavky. Z bezpeˇcnostních duvod ˚ u˚ mezi tˇemito adresami muže ˚ broadcast chybˇet. Z reakce uzlu tak nelze spolehlivˇe zjistit, zda uzel vybraný protokol správy nepodporuje nebo na tyto požadavky odpovídá pouze z urˇcitých adres. Poslední nevýhodou jsou pak samotné vlastnosti IP broadcastu. Jednak je podporován pouze v IPv4, ale hlavnˇe neprochází do smˇerovaˇcem oddˇelených segmentu˚ sítˇe. Tato metoda objevování sítˇe je tak celkovˇe použitelná pouze v prostˇredí malých síti. 3.1.3 Dotaz na všechny uzly v síti Metoda dotazu na všechny uzly je víceménˇe variací dvou pˇredchozích postupu˚ a také využívá nˇekterý z protokolu˚ správy. Postup spoˇcívá ve snaze navázat spojení pˇres vybraný protokol se všemi dostupnými uzly. Nespoléhá se na IP broadcast, ale podobnˇe jako v metodˇe trasování spojení zkouší všechny adresy z rozsahu lokální sítˇe. Zpracovatelnost získaných informací k vytvoˇrení obrazu topologie se podobnˇe jako v pˇredchozí metodˇe odvíjí od použitého protokolu. Výhody Díky vytváˇrení spojení na konkrétních adresách nehrozí, že by pˇri použití této metody chybˇely odpovˇedi dostupných aktivních uzlu, ˚ které podporují vybraný protokol, jako tomu bylo v pˇredchozím pˇrípadˇe – pokud totiž uzel odpoví alesponˇ na jedné ze svých adres, metoda ji využije (protože projde všechny existující adresy). Bude-li vybraný protokol podporovat alesponˇ nutné minimum sít’ových uzlu, ˚ bude výsledná topologie mnohem pˇresnˇejší než pˇri využití metody trasování spojení. Nevýhody První nevýhodou je fakt, že protokoly správy mohou být zaˇrízeními na síti filtrovány. Zásadní nevýhodou, která znemožnuje ˇ širší použití metody dotazování na všechny uzly v sítí, je však množství sít’ových adres – stejnˇe jako v postupu trasování. Efektivnˇe tak lze tuto metodu použít pouze v prostˇredí menších sítí nad IPv4.

3.2

Postupy pro IPv6 sítˇe

V oblasti postupu˚ objevování sítˇe je nejvˇetším rozdílem mezi verzemi IP adresní rozsah. V IPv6 tak není možné efektivnˇe vytvoˇrit spojení postupnˇe se všemi uzly na lokální síti. Navíc je zcela bˇežné, že jeden uzel má pˇriˇrazeno nˇekolik IP adres bez ohledu na poˇcet rozhraní. Nˇekteré postupy použitelné v prostˇredí IPv6 sítí jsou stejnˇe tak vhodné i pro starší IPv4 a uvádím je proto až v podkapitole Postupy nezávislé na verzi IP. 3.2.1 Multicast s využitím protokolu správy Multicast s využitím protokolu správy je víceménˇe ekvivalentem metody popsané v kapitole 3.1.2. Postup získávání dat ze sítˇe zustává ˚ stejný, odlišností jsou pouze nutné modifikace plynoucí z rozdílných verzí IP. 10


Využívá se IP multicast nad adresou „ff02::1“, kterou lze adresovat všechny uzly lokální sítˇe. Protože tento multicast, stejnˇe jako broadcast v IPv4, neprojde pˇres sít’ové smˇerovaˇce za hranice lokální sítˇe, seznam nevýhod se v porovnání s IPv4 variantou neliší.

3.3

Postupy vhodné pro IPv4 i IPv6

3.3.1 Postup na bázi link-state smˇerovacího protokolu Link-state smˇerovací algoritmy používají ke smˇerování vlastní vytvoˇrenou mapu sítˇe na každém uzlu. Tato mapa navíc obsahuje informace o linkách, které propojují jednotlivé uzly. Je-li taková mapa adekvátní pro vytvoˇrení kostry a následné smˇerování, je urˇcitˇe vhodná i k vytvoˇrení topologické mapy celé sítˇe. Samotné získání mapy v rámci link-state protokolu probíhá ve tˇrech krocích. V prvním kroku si každý uzel vytvoˇrí seznam pˇripojených linek obohacený o podrobnˇejší informace jako je maximální propustnost spojení. V druhém kroku uzly posílají svým sousedum ˚ linkstate oznámení, které obsahuje vytvoˇrený seznam linek. Když uzel pˇrijme takové oznámení se seznamem linek, pˇreposílá jej dále všem svým sousedum ˚ s výjimkou pro uzel, od kterého toto oznámení obdržel. Nekontrolovatelné záplavˇe sítˇe se brání znaˇckováním poslaných oznámení – pokud uzel obdrží oznámení, které již dˇríve získal, už je znova sousedním uzlum ˚ neposílá. Tˇretí krok pak spoˇcívá ve vytvoˇrení samotné mapy, což lze ze seznamu uzlu˚ a hran provést jednoduše. Až na konci nastupují algoritmy pro hledání nejkratších cest, které se vkládají do smˇerovacích tabulek.

Nevýhody Protože smˇerovací protokoly cˇ asto pracují pouze s informacemi o sít’ové vrstvˇe ISO/OSI modelu, výsledná topologie postrádá jakékoliv informace o pˇrepínaˇcích nebo jiných mezilehlých uzlech, které pracující pouze na nižších vrstvách ISO/OSI. Další nevýhodou je pak samotná podpora vybraného smˇerovacího protokolu mezi jednotlivými sít’ovými uzly. Napˇríklad v situacích, kdy je cˇ ást sítˇe obsluhována jiným smˇerovacím protokolem, nedojde k objevení celé sítˇe, ale pouze její omezené cˇ ásti.

Open Shortest Path First Protocol Jedním z nejznámˇejších link-state smˇerovacích protokolu˚ je protokol OSPF. Data z jeho protokolových tabulek lze získat bud’ jako log pˇri prubˇ ˚ ehu vytváˇrení mapy sítˇe nebo prostˇrednictvím protokolu˚ správy (napˇríklad pro SNMP existuje pˇrímo OSPF-MIB). Jeho omezením je však použitelnost v prostˇredí ruzných ˚ verzí IP. Protokol OSPF podporuje sice obˇe verze IP, avšak tato podpora se liší mezi jednotlivými verzemi OSPF. Novˇejší OSPFv3 pˇrinesla podporu IPv6 na úkor starší IPv4. Pro zajištˇení podpory obou verzí IP je potˇreba na síti soubˇežnˇe využívat OSPFv2 a OSPFv3. Vytváˇrené mapy sítˇe jsou ale samostatné a pro získání výsledné topologie je tˇreba provést jejich sjednocení. Taková operace je však kvuli ˚ absenci informací druhé vrstvy ISO/OSI problematická. 11


3.3.2 Postupné dotazování se znalostí výchozího uzlu Posledním z cˇ asto používaných postupu˚ získání topologie sítˇe je metoda založená na postupném dotazování. Informace ze sítˇe získává prostˇrednictvím vybraného protokolu správy, kdy se získaná data využívají už pˇri samotném pruchodu ˚ sítí. Jako vstupní informaci tento postup vyžaduje adresu jednoho z uzlu, ˚ který podporuje vybraný protokol správy a na který vytvoˇrí první spojení. Opakováním stejného postupu na adresy získané z odpovˇedi vstupního a dalších uzlu˚ lze v ideálním pˇrípadˇe projít celou sít’. Výhody Vytváˇrením spojení pouze na adresy získané ze sítˇe se minimalizuje poˇcet zbyteˇcných spojení a zkracuje se tak nutná doba pro zpracování. Situacím, kdy probˇehne pokus o navázání spojení s uzlem, který vybraný protokol nepodporuje, se však vyhnout nelze. Navíc díky pˇrímé adresaci jednotlivých uzlu˚ není tato metoda omezena pouze na lokální sít’. V situaci, kdy se podaˇrí od smˇerovaˇce získat adresy sousedu˚ z jiných podsítí, lze objevování sítˇe rozšíˇrit na tyto oblasti. Takové rozšíˇrení je ale vázané na podporu ze strany sítˇe – závisí na možnosti komunikovat s uzly v jiných podsítích. Nevýhody První nevýhoda plyne ze samotného postupu, který jako vstup vyžaduje adresu jednoho z dostupných uzlu. ˚ V situacích, kdy o pˇripojené síti nejsou známy žádné informace muže ˚ být tato potˇreba kritická.

Obrázek 3.1: Ukázka bariéry sít’ových uzlu. ˚ Zásadní nevýhodou je však nutná dostateˇcná podpora vybraného protokolu správy mezi sít’ovými uzly. V tomto pˇrípadˇe duležitou ˚ roli hraje i rozmístˇení uzlu˚ bez podpory vybraného protokolu. V nˇekterých postaveních totiž mužou ˚ tvoˇrit bariéru, která zpusobí ˚ výrazné chyby v celé výsledné topologii jako na obrázku 3.1. Uzly oznaˇcené cˇ ervenou barvou nepodporují žádný protokol správy, ostatní neoznaˇcené uzly ano. Pokud bude výchozím bodem pro vytvoˇrení topologie uzel cˇ . 1, uzly 5 a 6 ve výsledné topologii budou zcela chybˇet. Duvodem ˚ je fakt, že o existenci uzlu˚ cˇ íslo 5 a 6 ví pouze cˇ ervenˇe oznaˇcené uzly 3 a 4 bez podpory protokolu˚ správy, ze kterých nelze tuto informaci získat. Pˇri vhodnˇejším rozložení uzlu˚ bez podpory protokolu˚ správy, podobnˇe jako na obrázku 3.2, tento problém nenastává nebo je alesponˇ z velké cˇ ásti eliminován.

12


Obrázek 3.2: Ukázka sítˇe bez bariéry.

13

4 Návrh vlastního systému Pˇri výbˇeru metody získání zdrojových dat jsem bral v potaz pˇresnost získané topologie a navíc jsem se nechtˇel omezit pouze na sít’ovou vrstvu ISO/OSI modelu. Z toho duvodu ˚ jsem se rozhodl pro využití metody postupného dotazování. V související volbˇe použitého protokolu správy jsem upˇrednostnil SNMP popsané v kapitole 2.2 pˇred WMI (Windows Management Instrumentation) a NetBIOS (Network Basic Input/Output System). Zejména pro velké množství standardních i proprietárních MIB, které jsou prostˇrednictvím SNMP dostupné. Duležitou ˚ roli ve výbˇeru sehrála i širší podpora SNMP mezi zaˇrízeními ruzných ˚ výrobcu˚ v porovnání s WMI a NetBIOS.

4.1

Návrh postupu procházení sítí

Zvolený postup procházení sítí pˇres postupné dotazování vyžaduje pro zaˇcátek alesponˇ jeden uzel jako vstup. Takové omezení jsem se rozhodl akceptovat – ve vˇetšinˇe pˇrípadu˚ je totiž k dispozici seznam výchozích bran pro jednotlivá sít’ová rozhraní, které lze s úspˇechem využít jako vstupní, startovní uzly. S pˇrihlédnutím k tomuto faktu je situace, kdy navržený postup nebude schopný žádný vstupní uzel nalézt, zcela výjimeˇcná. Další volbou je pˇrístup k vytváˇrení sít’ové topologie podle jednotlivých verzí Internet Protokolu: •

Pruchod ˚ bez ohledu na verze IP a vytvoˇrení celé topologie najednou.

•

Vytvoˇrení samostatné topologie pro IPv4 a samostatnˇe pro IPv6. Následné mapování odpovídajících uzlu˚ z obou topologií podle MAC adresy (na vrstvˇe datových spoju˚ ISO/OSI), jako detekce dual-stack rozhraní.

Obrázek 4.1: Ukázka nespojité topologie pro jednu verzi IP. Modré uzly využívají pouze IPv6, šedé podporují pouze IPv4 a zelenožluté jsou uzly s podporou IPv4 i IPv6. Rozhodl jsem se využít první z možných postupu˚ a tedy nerozlišovat mezi verzemi IP, pˇrestože lze považovat takový postup ze implementaˇcnˇe složitˇejší. Hlavním duvodem ˚ byl odhad možných problému˚ s nespojitými topologiemi, které se mohou pˇri rozdˇelení získávání topologie podle verzí IP objevit. Detekovat na síti všechny oddˇelené segmenty sítˇe používající jeden protokol lze velmi obtížnˇe a to pouze s využitím dalších protokolu. ˚ Pˇríkladem budiž sít’ z obrázku 4.1, kde modˇre oznaˇcené stanice pˇredstavují uzly využívající pouze IPv6, bez oznaˇcení (šedý odstín) jsou uzly podporující pouze IPv4 a zelenožlutou barvou jsou oznaˇcené uzly s podporu jak IPv4, tak IPv6. 14

4. N ÁVRH VLASTNÍHO SYSTÉMU Pokud by objevování sítˇe zaˇcínalo na uzlu cˇ íslo 1, s použitím postupu oddˇelených topologií a bez použití dalších vylepšení bude IPv4 topologie správnˇe obsahovat uzly 1 a 3–5. Topologie pro IPv6 však bude obsahovat pouze uzly 1, 2 a 3, pˇrestože správnˇe by mˇela obsahovat ještˇe uzly 6–8.

4.2

Rozsah vytvoˇrené topologie

Souˇcástí návrhu je také oˇcekávaný rozsah vytvoˇrené topologie. Vzhledem k výše popsanému využitému postupu procházení sítí existují dva ruzné ˚ pˇrístupy: •

Omezení objevované sítˇe podle zadané IP adresy a sít’ové masky.

•

Procházení sítí bez omezení. V takovém pˇrípadˇe je hranice vytvoˇrené topologie urcˇ ena daty získanými prostˇrednictvím SNMP.

S využitím prvního postupu by v sítích s vˇetším množstvím podsítí bylo pro získání kompletní topologie potˇreba spouštˇet objevování sítˇe vícekrát a vytvoˇrené obrazy sítˇe v hraniˇcních bodech spojovat. Rozhodl jsem se proto využít druhý zmínˇený postup, který na úkor vˇetšího množství potˇrebného cˇ asu vytvoˇrí celou topologii najednou. 4.2.1 Nastavení rˇetˇezce community Duležitou ˚ roli pˇri urˇcení rozsahu vytvoˇrené topologie hraje rˇ etˇezec community. Se zvoleným pˇrístupem totiž postup procházení sítí zastaví až ve chvíli, kdy kontaktuje všechny zjištˇené sít’ové uzly. Pˇri návrhu jsem vybíral ze tˇrí zpusob ˚ u˚ zadání tohoto autentizaˇcního rˇ etˇezce: •

Zadání jednoho rˇ etˇezce community pro všechny sít’ové uzly.

•

Zadání rˇ etˇezce community pro každý uzel samostatnˇe.

•

Zadání více rˇ etˇezcu˚ s urˇcením poˇradí, v jakém budou použity.

Kvuli ˚ jednoduchosti následné implementace jsem se rozhodl využít první možnost, tedy použití stejného rˇ etˇezce community k autentizaci vuˇ ˚ ci všem sít’ovým uzlum. ˚ A to pˇresto, že takový postup neˇreší situace, kdy je cˇ ást sítˇe nakonfigurována s využitím odlišného rˇ etˇezce community – bylo by proto vhodnˇejší použít tˇretí zmínˇený postup. Ten využívá seznam zadaných rˇ etˇezcu˚ takovým zpusobem, ˚ že v pˇrípadˇe neúspˇechu pˇri navazování spojení vytváˇrí nové spojení s dalším rˇ etˇezcem v poˇradí.

4.3

Informace o pˇripojených sousedech

Na síti bez datového provozu jednotlivé uzly nemají o pˇripojených sousedních uzlech žádné informace, vˇedí pouze o existenci neurˇcitých zaˇrízení na druhé stranˇe linky u každého aktivního rozhraní. Další podrobnosti o sousedech získávají až z hlaviˇcek datové komunikace a prostˇrednictvím dalších protokolu˚ jako je CDP, LLDP, LLTD (Link Layer Topology Discovery) a další. 15

4. N ÁVRH VLASTNÍHO SYSTÉMU Samotný seznam sousedu˚ na rozhraních je v IPv4 udržován pomocí ARP, v prostˇredí IPv6 pak s využitím NDP. Tyto protokoly slouží k pˇrekladu adres a jsou potˇrebné pro adresaci a vlastní pˇrenos dat po síti. Seznam sousedu˚ tak pˇredstavuje spíš ARP/NDP cache, cˇ asto omezenou krátkou životností každého záznamu. Jednotlivé záznamy obsahují IP adresu, MAC adresu (adresace vrstvy datových spoju˚ modelu ISO/OSI) a identifikaci rozhraní, na kterém je sousední uzel nepˇrímo pˇripojen. Proto lze ze seznamu sousedu˚ vytvoˇrit pouze logickou topologii, informace o mezilehlých uzlech operujících na vrstvˇe datových spoju˚ v seznamu sousedu˚ chybí. V prostˇredí vˇetších sítí se využívá STP. Ten v rámci detekce cyklu˚ ve fyzickém propojení ukládá do svých tabulek Bridge ID pˇripojených sousedu. ˚ Z tˇechto záznamu˚ lze tak vytvoˇrit seznam pˇrímo pˇripojených zaˇrízení na druhé vrstvˇe ISO/OSI bez ohledu na IP adresaci. Ve výsledku takový seznam obsahuje MAC adresy pˇrímo pˇripojených uzlu. ˚ Podpora STP napˇríˇc zaˇrízeními ruzných ˚ výrobcu˚ je dobrá, z dražších pˇrepínaˇcu˚ používaných ve vˇetších sítích STP podporují všechny. Z dalších protokolu˚ jsem se rozhodl využít CDP, který si vytváˇrí vlastní cache s informacemi o pˇrímo pˇripojených sousedech. Mezi tˇemito informacemi je ale také IP adresa, pˇrestože z pohledu modelu ISO/OSI patˇrí o vrstvu výš. Seznam pˇrímých sousedu˚ vytvorˇ ený z CDP tabulek tak obsahuje MAC adresu, IP adresu a identifikátor lokálního rozhraní, pˇres které je soused dostupný. Protože se jedná o proprietární protokol Cisco a zaˇrízení jiných výrobcu˚ jej nepodporují (s výjimkou pˇrepínaˇcu˚ Hewlett-Packard z doby pˇred rokem 20061 ), využívám také údaje z LLDP. Ty sice obsahují pouze MAC adresy pˇripojených uzlu˚ a identifikaci sít’ového rozhraní, zato podpora ze strany dalších výrobcu˚ je lepší. LLDP je podporováno ve vˇetšinˇe zaˇrízení Hewlett-Packard, Extreme Networks a 3Com [24].

4.4

Indexy v tabulkách Management Information Base

Všechny získávané informace jsou uloženy v tabulkách spadající pod jednotlivé MIB. Z dokumentace každé takové tabulky lze zjistit, jakým zpusobem ˚ jsou indexovány jednotlivé hodnoty. Pˇres jeden OID je dostupná právˇe jedna hodnota ze záznamu v tabulce. Každá hodnota v tabulce tak musí mít vlastní identifikátor, pˇres který je adresovatelná, svuj ˚ tzv. index. Indexem se tady rozumí ta cˇ ást OID, o kterou OID vybrané hodnoty pˇresahuje OID celé tabulky. Pokud by mˇela tabulka OID napˇríklad 1.2.3.4, každý záznam v takové tabulce bude mít vlastní identifikátor ve tvaru X, jako svuj ˚ index. Protože indexy mají v dokumentaci cˇ asto urˇcenou pˇridanou hodnotu, mohla by jeho hodnota být pro více záznamu˚ v tabulce stejná. V nˇekterých tabulkách jsou proto indexy vícestupnové, ˇ napˇr. X.Y.Z. Skuteˇcné OID jsou tak ve tvaru 1.2.3.4.X.Y.Z, protože identifikátor celé tabulky pˇredstavuje prefix identifikátoru˚ jednotlivých tabulkových hodnot. Rozdˇelení celého identifikátoru na jednotlivé cˇ íselné položky vedoucí ke zjištˇení hodnot X,Y a Z v práci dále oznaˇcuji jako tzv. parsování indexu. V nˇekterých tabulkách jsou indexy vytváˇreny z dat, která nejsou v tabulce samotné dostupné ke cˇ tení, nebo v ní úplnˇe chybí. Protože ale výrobci sít’ových zaˇrízení principy tvorby indexu˚ dodržují, je cˇ asto možné ze zvolených tabulek spolehlivˇe získat i tyto na 1. Od roku 2006 pˇrepínaˇce Hewlett-Packard ProCurve podporují LLDP. [23]

16

4. N ÁVRH VLASTNÍHO SYSTÉMU první pohled nedostupné hodnoty. Pˇríklad .1.3.6.1.2.1.4.34.1.3.1.4.10.199.6.212 = INTEGER: 2 .1.3.6.1.2.1.4.34.1.3.1.4.127.0.0.1 = INTEGER: 1 Pˇríklad ukazuje cˇ ást odpovˇedi sít’ového uzlu pro dotaz na tabulku ipAddressTable z IP-MIB. Prefix 1.3.6.1.2.1.4.34.1.3 je OID pro získání identifikátoru sít’ového rozhraní, ke kterému se váží záznamy se stejným indexem. Zbytek vráceného OID je dˇríve zminovaný ˇ index. V pˇrípadˇe ipAddressTable je souˇcástí indexu druh adresy, délka adresy a sít’ová adresa samotná, která v této tabulce jinak není dostupná pro cˇ tení. Zpracováním hodnot, které oznaˇcuji jako parsování, lze z indexu 1.4.10.199.6.212 vyˇcíst, že se jedná o IPv4 adresu 10.199.6.212.

4.5

Využité Management Information Base

Vzhledem k ruznorodosti ˚ potˇrebných dat k vytvoˇrení topologie jsem se rozhodl stahovat data z nˇekolika oddˇelených MIB. Protože každý výrobce vˇenuje jinou pozornost ruz˚ ným protokolum ˚ a samotnému SNMP, nemusí být všechna získaná data dobˇre použitelná. Muže ˚ tak dojít k situaci, kdy uzel napˇríklad podporuje LLDP, ale v odpovˇedí získaných pˇres SNMP to nedává znát. Pˇrestože práce je zamˇerˇ ena do prostˇredí heterogenních sítí a tedy mezi zaˇrízení ruz˚ ných výrobcu, ˚ rozhodl jsem se využít také jednu MIB z privátní vˇetve MIB spoleˇcnosti Cisco. Zaˇrízení Cisco se ve vˇetších sítích vyskytují cˇ asto a prostˇredky potˇrebné na vytvorˇ ení dotazu do další MIB jsou v porovnání s možným rizikem zanesení nepˇresnosti do vytváˇrené topologie zanedbatelné. SNMPv2-MIB je systémová báze, koˇrenový OID je 1.3.6.1.2.1.1. V tabulkách obsahuje pˇrevážnˇe statické informace o samotném uzlu. Rozhodl jsem se použít dotaz pouze na OID 1.3.6.1.2.1.1.1.0, které obsahuje textový rˇ etˇezec struˇcnˇe identifikující dotazovaný uzel. Pro další hodnoty, které jsou dostupné v této MIB totiž nemám využití. Získaná hodnota vypadá napˇríklad jako „Cisco IOS Software, C3750 Software (C3750IPSERVICESK9-M), Version 12.2(50)SE3, RELEASE SOFTWARE (fc1)“ nebo „Linux lab-zenoss 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686“. IF-MIB obsahuje tabulky s informacemi o sít’ových rozhraních dotazovaného uzlu. Koˇrenový OID celé báze je 1.3.6.1.2.1.2. Co se poˇctu OID týˇce, jedná se o jednu z nejmenších MIB. Obsahuje pouze tzv. ifNumber, které udává poˇcet disponibilních rozhraní dotazovaného uzlu a je dostupné pˇres OID 1.3.6.1.2.1.2.1.0, a samotný seznam rozhraní jako ifTable. Ten je dostupný pˇres 1.3.6.1.2.1.2.2 a jako identifikátor v rámci tabulky používá tzv. ifIndex. Stejný ifIndex používají v indexech i další MIB a lze tak tento identifikátor dobˇre využít pro párování dat z ruzných ˚ tabulek. Ze seznamu rozhraní využívám, kromˇe samotného identifikátoru, textový název rozhraní dostupný pˇres OID 1.3.6.1.2.1.2.2.1.2, adresu druhé vrstvy ISO/OSI modelu 17

4. N ÁVRH VLASTNÍHO SYSTÉMU dostupnou jako 1.3.6.1.2.1.2.2.1.6 a pˇres 1.3.6.1.2.1.2.2.1.8 stav, ve kterém se rozhraní nachází. Seznam stavu˚ rozhraní je urˇcen celoˇcíselnou hodnotou z výˇctem omezeného rozsahu. Každá hodnota má tak specifický význam, které se mezi jednotlivými MIB liší. Nejˇcastˇejší hodnoty stavu v IF-MIB jsou: 1

aktivní rozhraní

2

neaktivní rozhraní

4

neznámý stav

IP-MIB slouží jako základní MIB pro celý IP. Dostupná je pˇres koˇrenové OID 1.3.6.1.2.1.4 a obsahuje tabulky s kompletním nastavením IP, od pˇriˇrazení adres na jednotlivá rozhraní až po smˇerovací informace. Vˇetšina tabulek nerozlišuje mezi verzemi IP a obsahuje tak data jak pro IPv4, tak pro IPv6. Nˇekteré naopak obsahují pouze IPv4, další zase pouze informace o IPv6. Z celé IP-MIB používám data ze cˇ tyˇr tabulek. První dvˇe obsahují seznamy IP adres, které má uzel pˇriˇrazeny na svých sít’ových rozhraních. Jedna je dostupná jako 1.3.6.1.2.1.4.34 jako tzv. ipAddressTable a obsahuje adresy pro obˇe verze IP. Druhá je vývojovˇe starší, obsahuje pouze IPv4 adresy a je dostupná jako 1.3.6.1.2.1.4.20 pod oznaˇcením ipAddrTable. V souˇcasné dobˇe je ipAddrTable oznaˇcena jako zavržená2 , ale na starších zaˇrízeních je tato tabulka cˇ asto naplnˇena hledanými daty a její novˇejší ekvivalent obsahuje pouze malou cˇ ást nebo vubec ˚ žádné informace. Proto jsem se rozhodl využívat data z obou tˇechto tabulek. U novˇejších zaˇrízení naopak dochází k opaˇcnému jevu, kdy je prázdná starší ipAddrTable. Tabulky ipAddressTable a ipAddrTable se tak vzájemnˇe doplnují. ˇ Obˇe tyto tabulky jako souˇcást indexu záznamu˚ používají pˇriˇrazené IP adresy a protože v novˇejší ipAddressTable není hodnota samotné IP adresy dostupná ke cˇ tení, zjišt’uji tuto IP adresy s využitím parsování indexu. Z konkrétních hodnot potom ukládám pouze identifikátor rozhraní dostupný jako OID 1.3.6.1.2.1.4.34.1.3 nebo 1.3.6.1.2.1.4.20.1.2, ke kterému získaná IP adresa patˇrí. Ve spojení s informacemi z IF-MIB tak mám k dispozici kompletní adresaci dotazovaného uzlu. Dále využívám tabulku ipNetToPhysicalTable dostupnou pˇres OID 1.3.6.1.2.1.4.35 a ipNetToMediaTable jako 1.3.6.1.2.1.4.22. Také tyto tabulky poskytují podobné informace, obˇe obsahují párování IP a MAC adres, které se do tabulek dostává z výsledku provedených ARP a NDP dotazu. ˚ Stejnˇe jako u dˇríve zmínˇených tabulek novˇejší ipNetToPhysicalTable obsahuje informace pro obˇe verze IP, zatímco starší ipNetToMediaTable disponuje pouze údaji z prostˇredí IPv4 a je považována za zavrženou, podobnˇe jako ipAddrTable. Tabulky ipNetToPhysicalTable a ipNetToMediaTable se také podobným zpusobem ˚ doplnují. ˇ K využívání dat z obou tˇechto tabulek, pˇresnˇeji jedné IP a MAC adresy sousedního sít’ového uzlu a identifikaci na kterém rozhraní je pˇripojen, jsem se rozhodl ze stejného duvodu, ˚ jako u ipAddressTable a ipAddrTable. Identifikátor rozhraní a samotná IP adresa jsou však dostupné opˇet pouze jako souˇcást indexu, jeho parsování je tak pro získání 2. Pojem „zavržený“ je pˇrekladem z anglického „deprecated“.

18

4. N ÁVRH VLASTNÍHO SYSTÉMU potˇrebných dat nutné. Zbývající hodnota s MAC adresou je dostupná pˇres OID 1.3.6.1.2.1.4.35.1.4, respektive 1.3.6.1.2.1.4.22.1.2. Ve výsledku z dat z IP-MIB získám seznam všech adres na rozhraních dotazovaného uzlu a seznam sousedu˚ na tˇretí vrstvˇe ISO/OSI modelu. IPV6-MIB je ekvivalentem IP-MIB do prostˇredí IPv6, její koˇrenové OID je 1.3.6.1.2.1.55. V souˇcasné dobˇe jsou nˇekterá data, dˇríve adresovatelná pouze prostˇrednictvím IPV6-MIB, dostupná také v tabulkách IP-MIB, která by mˇela být nezávislá na jednotlivých verzích IP. Protože však nˇekteré sít’ové uzly v tabulek v rámci IP-MIB neobsahují všechny informace o IPv6, rozhodl jsem se využívat také vybrané tabulky z IPV6-MIB. V první rˇ adˇe využívám tabulku se seznamem sít’ových rozhraní, které na dotazovaném uzlu podporují IPv6, pojmenovanou jako ipv6IfTable. Dokumentace k IPV6-MIB totiž na rozdíl od IP-MIB neˇríká, že by identifikace jednotlivých rozhraní mˇela odpovídat zavedené identifikaci v IF-MIB. A pˇrestože ve všech pozorovaných pˇrípadech jsou identifikátory sít’ových rozhraní shodné, rozhodl jsem se na tuto vlastnost nespoléhat. Poˇcet rozhraní, které IPv6 podporují je dostupný pˇres OID 1.3.6.1.2.1.55.1.3, v poli oznaˇceném jako ipv6Interfaces. Ve spojení s daty z ipv6IfTable lze získat ke každému záznamu fyzickou MAC adresu rozhraní pˇres OID 1.3.6.1.2.1.55.1.5.1.8, jeho status z OID 1.3.6.1.2.1.55.1.5.1.10 a krátký textový popis jako OID 1.3.6.1.2.1.55.1.5.1.2. Samotný identifikátor jednotlivých rozhraní je dostupný pouze v indexu a k jeho získání je tak tˇreba provést parsování indexu získaných hodnot. Mezi nejfrekventovanˇejší stavové hodnoty v ipv6IfTable patˇrí: 1

aktivní rozhraní

2

neaktivní rozhraní

3

neaktivní rozhraní se špatnˇe pˇriˇrazeným identifikátorem

4

neznámý stav

Další využívanou tabulkou z IPV6-MIB je ipv6AddrTable s OID 1.3.6.1.2.1.55.1.8. Ta obsahuje seznamy IPv6 adres, které jsou pˇriˇrazeny jednotlivým sít’ovým rozhraním. Identifikátor rozhraní, ke kterému záznam s adresou patˇrí, je dostupný pouze v indexu a je tak opˇet tˇreba využít jeho parsování. Stejná situace se opakuje i se samotnou IPv6 adresou, její záznam v ipv6AddrAddress s OID 1.3.6.1.2.1.55.1.8.1.1 je v dokumentaci oznaˇcen jako nedostupný a je dostupná pouze jako souˇcást indexu. Z hodnot v tabulce ipv6AddrTable tak využívám jenom ipv6AddrStatus pod OID 1.3.6.1.2.1.55.1.8.1.5, který rˇ íká, zda je adresa platná. Pokud není, záznam se stává pro úˇcely vytvoˇrení topologie sítˇe nevyužitelný. Poslední tabulkou, kterou jsem se rozhodl pro vytvoˇrení topologie využít je ipv6NetToMediaTable dostupná jako 1.3.6.1.2.1.55.1.12. Jedná se víceménˇe o ekvivalent ipNetToPhysicalTable z IP-MIB, obsahuje také mapování mezi IP a MAC adresami sousedních uzlu. ˚ Podobnˇe je i zde identifikátor rozhraní a IP adresa dostupná pouze v indexu a bez jeho parsování jsou data nevyužitelná. Z pˇrímo dostupných hodnot tabulky využívám pouze fyzickou adresa pro druhou vrstvu ISO/OSI modelu jako OID 1.3.6.1.2.1.55.1.12.1.2. 19

4. N ÁVRH VLASTNÍHO SYSTÉMU RFC1213-MIB je dostupná pˇres koˇrenové OID 1.3.6.1.2.1.3 a nyní je již oznaˇcená jako zavržená. Pˇresto jsem se rozhodl obsah jediné tabulky, kterou disponuje, využít. Tou tabulkou je atTable a obsahuje párování IPv4 a MAC adres podle výsledku˚ ARP odpovˇedí, které dotazovaný uzel získal. Obsahovˇe ji lze pˇrirovnat k zeštíhlené ipNetToMediaTable z IP-MIB. Vˇe vˇetšinˇe pˇrípadu˚ jsou obsahy tabulek identické, ale pro pˇrípad chyby v odpovˇedi sít’ového uzlu využívám atTable jako doplnkovou ˇ tabulku pro získání seznamu sousedu˚ na sít’ové vrstvˇe ISO/OSI. Z konkrétních hodnot obsahuje identifikaci rozhraní, na kterém je sousední uzel pˇripojen, jeho MAC adresu a jeho IPv4 adresu. Žádné další informace v atTable uloženy nejsou. Jako index pro záznamy používá identifikátor rozhraní a IP adresu, ale protože jsou obˇe tyto hodnoty dostupné jako samostatné datové položky, parsovat hodnoty z indexu˚ není nutné. CISCO-IETF-IP-MIB s OID 1.3.6.1.4.1.9.10.86 je poslední MIB, kterou využívám k získání druhovˇe stejných dat, jako výše popsané MIB. Jejím specifikem je fakt, že není standardizovaná, ale patˇrí do privátního rozsahu spoleˇcnosti Cisco a je proto dostupná pouze v zaˇrízeních Cisco. Využívám data z tabulky cIpAddressTable, která je dostupná pˇres OID 1.3.6.1.4.1.9.10.86.1.1.2 a je dalším ekvivalentem ipAddressTable z IP-MIB. A to vˇcetnˇe dostupnosti samotné IP adresy, jež v tabulce není urˇcená ke cˇ tení, ale její hodnota je souˇcástí indexu. Dále používám tabulku cInetNetToMediaTable jako OID 1.3.6.1.4.1.9.10.86.1.1.3, která obsahovˇe odpovídá dˇríve zmínˇené ipNetToPhysicalTable. Jak cIpAddressTable, tak cInetNetToMediaTable využívám jako obsahový doplnˇek k tabulkám z IP-MIB. Mou snahou je snížení rizika zanesení chyby do vytváˇrené topologie, pokud by jedna z datovˇe ekvivalentních tabulek obsahovala neúplná data. CISCO-CDP-MIB má koˇrenové OID 1.3.6.1.4.1.9.9.23 a slouží ke správˇe CDP na sít’ových zaˇrízeních Cisco. Protokol CDP jsem se rozhodl využít k získání adres skuteˇcných pˇrímo pˇripojených uzlu˚ za úˇcelem pozdˇejších úprav celého seznamu sousedu. ˚ K dotazum ˚ využívám cache tabulku cdpCacheTable dostupnou jako 1.3.6.1.4.1.9.9.23.1.2.1, pˇresnˇeji záznam cdpCacheAddressType s OID 1.3.6.1.4.1.9.9.23.1.2.1.1.3 a cdpCacheAddress adresovatelnou pˇres OID 1.3.6.1.4.1.9.9.23.1.2.1.1.4. Pokud je hodnota v poli cdpCacheAddressType rovna jedné, je v cdpCacheAddress uložena IP adresa. V pˇrípadˇe výskytu jiného typu adresy je vhodné uloženou adresu považovat za irelevantní a pˇri zpracování ji vynechat. Identifikace rozhraní, ke kterému je soused s adresou v cdpCacheAddress pˇripojen, je dostupná pouze v indexu tabulky, takže je potˇreba opˇet využít jeho parsování. Výsledný seznam pˇrímých sousedu˚ tak obsahuje pouze IP adresu a identifikaci rozhraní, což je pro urˇcení spojení ve vytvoˇrené topologii dostaˇcující. LLDP-MIB je adresovatelná pˇres OID 1.0.8802.1.1.2 a obsahuje všechny tabulky a nastavení LLDP. Ve stromu MIB je zaˇrazena stranou od standardních MIB, ale sít’ová zaˇrízení nˇekterých výrobcu˚ LLDP-MIB disponují. Data z LLDP jsem se rozhodl použít také k urˇcení pˇrímo pˇripojených uzlu˚ k dotazovaném uzlu, stejnˇe 20

4. N ÁVRH VLASTNÍHO SYSTÉMU jako cache CDP. Za tímto úˇcelem využívám skupinu tabulek oznaˇcenou jako lldpLocalSystemData a dostupnou pˇres OID 1.0.8802.1.1.2.1.3, a dále skupinu oznacˇ enou jako lldpRemoteSystemsData, která má OID 1.0.8802.1.1.2.1.4. Na rozdíl od CDP cache je výstupem z LLDP cache seznam MAC adres místo IP adres. Z tabulek lldpLocalSystemData a lldpRemoteSystemsData pˇres OID 1.0.8802.1.1.2.1.3.2 a 1.0.8802.1.1.2.1.4.1.1.5 získávám seznam lokálních MAC adres dotazovaného uzlu a seznam MAC adres jeho sousedních uzlu. ˚ Seznam lokálních adres používám pouze ke kontrole vuˇ ˚ ci získaným datum ˚ z IF-MIB, která považuji za duvˇ ˚ eryhodnˇejší, a v pˇrípadˇe nesrovnalostí zapisuji do aplikaˇcních záznamu. ˚ Seznam MAC adres sousedních uzlu˚ ve spojení se seznamem sousedu˚ na sít’ové vrstvˇe ISO/OSI, jenž je výstupem napˇríklad z IP-MIB, dává kompletní informace o adresaci pˇrímých sousedu˚ dotazovaného uzlu. Tyto údaje lze s úspˇechem využít pˇri vytváˇrení obrazu sít’ové topologie. BRIDGE-MIB disponuje tabulkami z prostˇredí sít’ových pˇrepínaˇcu˚ a daty z STP, koˇrenové OID celé MIB je 1.3.6.1.2.1.17. Získaná data využívám k vytvoˇrení seznamu pˇrímo pˇripojených sít’ových uzlu, ˚ stejným zpusobem ˚ jako v pˇrípadˇe CISCO-CDPMIB a LLDP-MIB. Z BRIDGE-MIB využívám konkrétnˇe tabulky dot1dStpPortTable s OID 1.3.6.1.2.1.17.2.15, která obsahuje STP cache, a dot1dTpFdbTable dostupnou jako OID 1.3.6.1.2.1.17.4.3. Pokud dotazovaný uzel tyto tabulky neobsahuje, vrací v odpovˇedích prázdné výsledky. Data jsou do tabulky dot1dStpPortTable doplnována ˇ zárovenˇ se stavovými zmˇenami v STP a obsahují záznamy pro segmenty sítˇe, které se úˇcastní v STP. Rozhodl jsem se proto využít a zpracovat hodnotu dot1dStpPortDesignatedRoot, která je dostupná pˇres 1.3.6.1.2.1.17.2.15.1.6 a obsahuje Bridge ID koˇrenového uzlu na segmentu, a dot1dStpPortDesignatedBridge dostupnou jako OID 1.3.6.1.2.1.17.2.15.1.8 s Bridge ID uzlu na druhé stranˇe stejného segmentu. Z tˇechto získaných Bridge ID vždycky jedno patˇrí dotazovanému uzlu a druhé jeho pˇrímému sousedovi. Protože Bridge ID jsou složeny z MAC adres a z vlastního pˇriˇrazeného identifikátoru, lze takto z nevlastních Bridge ID vytvoˇrit seznam MAC adres pˇrímo pˇripojených uzlu. ˚ Ve spojení s daty z IP-MIB lze takový seznam dobˇre využít k vytváˇrení sít’ové topologie. Druhou tabulkou je dot1dTpFdbTable zpˇrístupnující ˇ záznamy z tzv. CAM tabulky, jež obsahuje statické i dynamické párování MAC adres a identifikaci rozhraní, na kterém je uzel s vybranou MAC adresou pˇripojen. Tyto dynamické záznamy jsou vytváˇreny pomocí Backward Learning Algorithm, který využívá procházejícího datového provozu a na základˇe obsahu hlaviˇcek rámcu˚ automaticky plní zmínˇenou CAM tabulku – ukládá se zdrojová adresa pˇrijatého rámce spoleˇcnˇe s rozhraním, po kterém rámec do pˇrepínaˇce pˇrišel. Pokud pozdˇeji pˇrijde rámec adresovaný pro uzel, jehož záznam je v CAM tabulce uveden, je odeslán z pˇrepínaˇce skrze uložené rozhraní. V opaˇcném pˇrípadˇe se rámec posílá na všechny rozhraní kromˇe vstupního. Z dot1dTpFdbTable jsem se rozhodl získávat pouze MAC adresy s OID 1.3.6.1.2.1.17.4.3.1.1 jako dot1dTpFdbAddress. Další využití získaných adres pˇri vytváˇrení obrazu sít’ové topologie je opˇet podmínˇeno seskupením s daty z IP-MIB, se21

4. N ÁVRH VLASTNÍHO SYSTÉMU znam samotných adres bez urˇceného propojení je nevyužitelný. Q-BRIDGE je poslední MIB, kterou jsem mˇel v plánu využít. Je dostupná prostˇrednictvím OID 1.3.6.1.2.1.17.7 a podobá se výše zmínˇené BRIDGE-MIB. Stejným zpuso˚ bem jako v pˇrípadˇe BRIDGE-MIB lze využít získaná data, která bez provázání s dalšími MIB ztrácí pˇri vytváˇrení sít’ové topologie svou použitelnost. Pˇresnˇeji jsem se rozhodl použít tabulku dot1qTpFdbTable s OID 1.3.6.1.2.1.17.7.1.2.2, která je obdobou tabulky dot1dTpFdbTable z BRIDGE-MIB a zpˇrístupnuje ˇ záznamy v CAM tabulce. Odlišný je pouze zpusob ˚ zpˇrístupnˇení samotné MAC adresy, která jako položka dot1qTpFdbAddress a OID 1.3.6.1.2.1.17.7.1.2.2.1.1 není dostupná ke cˇ tení, ale její hodnota je souˇcástí indexu záznamu˚ v tabulce. K jejímu získání je tak tˇreba provádˇet parsování indexu ostatních dat ze stejné tabulky v odpovˇedi dotazovaného uzlu.

4.6

Pˇrehledové tabulky využitých Object Identifier

V tabulce 4.1 uvádím pˇrehledný seznam OID využívaných k získání základních informací o sít’ovém uzlu vˇcetnˇe seznamu sít’ových rozhraní a pˇriˇrazených adres druhé i tˇretí vrstvy ISO/OSI modelu. Tabulka 4.2 obsahuje seznam identifikátoru, ˚ které jsem se rozhodl použít k získání seznamu pˇrímo pˇripojených uzlu. ˚ Seznam hodnot, které získávám s využitím metody parsování indexu je uveden v tabulce 4.3.

4.7

Návrh postupu získání dat

Získávaná data z odpovˇedí sít’ového uzlu lze rozdˇelit do cˇ tyˇr skupin – rˇ etˇezec popisující samotný uzel, seznam sít’ových rozhraní, seznam sousedu˚ na sít’ové vrstvˇe a seznam pˇrímo pˇripojených sousedních uzlu. ˚ Metoda získání informací o rozhraních a popisujícího rˇ etˇezce je vˇcetnˇe zdrojových MIB jsou uvedena v postupu 4.1. Postup 4.2 pak popisuje získání obou seznamu sousedu, ˚ zárovenˇ zohlednuje ˇ identifikaci rozhraní, pˇres které je sousední uzel pˇripojen. Informace o pˇrímo pˇripojených sousedech jsou vkládány podle typu získané adresy do dvou oddˇelených seznamu, ˚ pˇriˇcemž IP adresy získané z cache CDP lze využít jako pˇrímé sousedy i jako sousedy na úrovni sít’ové vrstvy. Metoda makeValuesUnique na 7. rˇ ádku postupu 4.1 a v postupu 4.2 provádí mazání duplicitních hodnot ze seznamu. Po jejím provedení je každá dˇríve vložená hodnota v seznamu právˇe jednou.

4.8

Dostupná data bez dalšího využití

S pˇrihlédnutím k charakteristice vybraných dat získaných prostˇrednictvím SNMP jsem došel k závˇeru, že nˇekterá, na první pohled zajímavá data pˇri vytváˇrení topologie sítˇe nevyužiji. Bud’ s tématem objevování sítí souvisí pouze okrajovˇe, nebo by jejich využití nepˇrineslo požadovaný efekt. 22

4. N ÁVRH VLASTNÍHO SYSTÉMU Require: r získává data z MIB, b je popis dotazovaného uzlu, is je seznam rozhraní 1. b ⇐ r.getDescription(SNMPv2-MIB) 2. for all i ∈ r.getInterfaces(IF-MIB) do 3. i.mac ⇐ r.getInterfaceMAC(IF-MIB, i.id) 4. i.ip.add(r.getIPsOnInterface(IP-MIB, ipAddressTable, i.id)) 5. i.ip.add(r.getIPsOnInterface(IP-MIB, ipAddrTable, i.id)) 6. i.ip.add(r.getIPsOnInterface(CISCO-IETF-IP-MIB, i.id)) 7. i.ip.makeValuesUnique() 8. is.add(i) 9. end for 10. for all i ∈ r.getInterfaces(IPV6-MIB) do 11. i.mac.add(r.getInterfaceMAC(IPV6-MIB)) 12. i.ip.add(r.getIPsOnInterface(IPV6-MIB)) 13. is.add(i) 14. end for Postup 4.1: Získaní dostupných informací o uzlu a jeho rozhraních. Require: r získává data z MIB, n je seznam sousedu˚ na sít’ové vrstvˇe, is seznam rozhraní dp je seznam IP adres pˇrímých sousedu˚ a dm seznam MAC adres pˇrímých sousedu˚ 1. mibs ⇐ new Array(IP-MIB, IPV6-MIB, CISCO-IETF-IP-MIB, RFC1213-MIB) 2. for all i ∈ is do 3. for all mib ∈ mibs do 4. for all nbr ∈ r.getNeighborsOnInterface(mib, i) do 5. nbr.mac ⇐ r.getNeighborMAC(mib, nbr.id) 6. nbr.ip ⇐ r.getNeighborIP(mib, nbr.id)) 7. n[i].add(nbr) 8. end for 9. end for 10. for all nbr ∈ r.getNeighborsOnInterface(CISCO-CDP-MIB, i) do 11. nbr.ip ⇐ r.getNeighborIP(CISCO-CDP-MIB, nbr.id)) 12. n[i].add(nbr) 13. end for 14. n[i].makeValuesUnique(ip) 15. end for 16. 17.

dp.addRange(r.getIPsOfDirectNeighbors(CISCO-CDP-MIB))

18.

dm.addRange(r.getMACsOfDirectNeighbors(LLDP-MIB)) 20. dm.addRange(r.getMACsOfDirectNeighbors(BRIDGE-MIB)) 21. dm.addRange(r.getMACsOfDirectNeighbors(Q-BRIDGE)) 22. dm.makeValuesUnique() 19.

Postup 4.2: Získaní informací o sousedních uzlech.

23

4. N ÁVRH VLASTNÍHO SYSTÉMU 4.8.1 Smˇerovací tabulky V prostˇredí IPv6 jsou ve smˇerovacích tabulkách cesty ukládány cˇ asto s využitím tzv. linklocal adres, které nelze jednoduše využít k získání informace o dalším uzlu na cestˇe. Konkrétnˇe se jedná o tabulky ipv6RouteNextHop a ipv6RouteTable z IPV6-MIB. 4.8.2 Tunelování verzí IP K detekci klasických tunelu˚ typu 4to6 a 6to4 pˇres sítˇe využívající druhou verzi IP lze s úspˇechem využít data dostupná v TUNNEL-MIB a tabulce tunnelIfTable pod OID 1.3.6.1.2.1.10.131.1.1.1. Adresa odesílajícího uzlu v tunelu je dostupná pˇres OID 1.3.6.1.2.1.10.131.1.1.1.1.9, jako tzv. tunnelIfLocalInetAddress. Pokud se jedná o point-topoint tunel, adresa druhé strany je pˇrístupná jako tunnelIfRemoteInetAddress a OID 1.3.6.1.2.1.10.131.1.1.1.1.10. Protože tunely v praxi cˇ asto propojují relativnˇe vzdálené sítˇe, rozhodl jsem se nevˇenovat objevování tunelu˚ velkou pozornost a do vytváˇrené topologie sítˇe jsem tyto informace nezahrnul. 4.8.3 Virtuální sítˇe a virtuální uzly Vzhledem ke znaˇcnému rozsahu oblasti virtuálních sítí jsem se rozhodl tuto problematiku pˇri vytváˇrení sít’ové topologie prakticky neˇrešit. Pˇresto jsou informace ohlednˇe nastavení virtuálních sítí prostˇrednictvím SNMP dostupné, i když vˇetšina výrobcu˚ využívá k popsání dostupných hodnot vlastní privátní MIB. Problematika objevení virtuálních sít’ových uzlu˚ odpovídá nˇekterým variantám tzv. multihomingu. Obecnˇe existuje nˇekolik jeho variant, kdy pro každou z nich platí jiné možnosti objevení na síti. S tˇemito situacemi se potýká i topologie vytvoˇrená podle mého návrhu. Mezi problematické patˇrí následující: Jedno rozhraní a více IP adres pˇredstavuje situaci, která je zcela bˇežná v prostˇredí IPv6 sítí. Sít’ový uzel je na jednom fyzickém rozhraní dostupný pˇres více odlišných IP adres. Pokud jsou k dispozici informace o MAC adrese (druhá vrstva ISO/OSI), lze záznamy spojit na základˇe této shody. Jestli se jedná o identický uzel, lze alternativnˇe rozhodnout s využitím SNMP, pokud je podporováno na všech zmínˇených IP adresách. V opaˇcném pˇrípadˇe takovou situaci není možné dobˇre podchytit a vede to k nepˇresnostem ve vytvoˇrené topologii. Více rozhraní a více IP adres pˇrináší do obrazu vytváˇrené topologie problém, pokud dotazovaný uzel nedisponuje podporou SNMP a jeho rozhraní mají odlišné MAC adresy. V takovém pˇrípadˇe totiž chybí jakákoliv informace o tom, že zjištˇené IP adresy patˇrí jednom uzlu a nejedná se o vˇetší množství samostatných sít’ových uzlu. ˚ Tuto situaci nelze zvolenými prostˇredky rˇ ešit. Více rozhraní s jedinou IP adresou je pˇríkladem situace cˇ asto oznaˇcované jako klasický multihoming. Tento stav lze ve výsledné topologii spolehlivˇe zobrazit jenom v situaci, kdy vybraný uzel podporuje SNMP a ve svých odpovˇedích o takovém stavu 24

4. N ÁVRH VLASTNÍHO SYSTÉMU informuje. V opaˇcném pˇrípadˇe lze nˇekdy odlišit jednotlivá rozhraní podle MAC adres, ale pˇresnost jejich rozmístˇení ve výsledné topologii závisí na informacích dalších získaných od sousedu˚ takového uzlu. Ve zmínˇených situacích muže ˚ zvolený postup vytváˇrení sít’ové mapy generovat nesprávná topologická data. Protože se ale nejedná o pˇríliš frekventované situace, zanesené chyby ve výsledku nevadí.

25

4. N ÁVRH VLASTNÍHO SYSTÉMU

OID

MIB

Pojmenování

1.3.6.1.2.1.1.1 1.3.6.1.2.1.2.1 1.3.6.1.2.1.2.2 1.3.6.1.2.1.2.2.1.2 1.3.6.1.2.1.2.2.1.6 1.3.6.1.2.1.2.2.1.8 1.3.6.1.2.1.4.34 1.3.6.1.2.1.4.34.1.3 1.3.6.1.2.1.4.20 1.3.6.1.2.1.4.20.1.1 1.3.6.1.2.1.4.20.1.2 1.3.6.1.2.1.4.35 1.3.6.1.2.1.4.35.1.4 1.3.6.1.2.1.4.22 1.3.6.1.2.1.4.22.1.2 1.3.6.1.2.1.55.1.3 1.3.6.1.2.1.55.1.5 1.3.6.1.2.1.55.1.5.1.2 1.3.6.1.2.1.55.1.5.1.8 1.3.6.1.2.1.55.1.5.1.10 1.3.6.1.2.1.55.1.8 1.3.6.1.2.1.55.1.8.1.5 1.3.6.1.2.1.55.1.12 1.3.6.1.2.1.55.1.12.1.2 1.3.6.1.4.1.9.10.86.1.1.2 1.3.6.1.4.1.9.10.86.1.1.3 1.3.6.1.2.1.3.1 1.3.6.1.2.1.3.1.1.1 1.3.6.1.2.1.3.1.1.2 1.3.6.1.2.1.3.1.1.3

SNMPv2-MIB IF-MIB IF-MIB IF-MIB IF-MIB IF-MIB IP-MIB IP-MIB IP-MIB IP-MIB IP-MIB IP-MIB IP-MIB IP-MIB IP-MIB IPV6-MIB IPV6-MIB IPV6-MIB IPV6-MIB IPV6-MIB IPV6-MIB IPV6-MIB IPV6-MIB IPV6-MIB CISCO-IETF-IP-MIB CISCO-IETF-IP-MIB RFC1213-MIB RFC1213-MIB RFC1213-MIB RFC1213-MIB

sysDescr ifNumber ifTable ifDescr ifPhysAddress ifOperStatus ipAddressTable ipAddressIfIndex ipAddrTable ipAdEntAddr ipAdEntIfIndex ipNetToPhysicalTable ipNetToPhysicalPhysAddress ipNetToMediaTable ipNetToMediaPhysAddress ipv6Interfaces ipv6IfTable ipv6IfDescr ipv6IfPhysicalAddress ipv6IfOperStatus ipv6AddrTable ipv6AddrStatus ipv6NetToMediaTable ipv6NetToMediaPhysAddress cIpAddressTable cInetNetToMediaTable atTable atIfIndex atPhysAddress atNetAddress

Tabulka 4.1: Použité OID pro získání základních informací o uzlu.

26

4. N ÁVRH VLASTNÍHO SYSTÉMU

OID

MIB

Pojmenování

1.3.6.1.4.1.9.9.23.1.2.1 1.3.6.1.4.1.9.9.23.1.2.1.1.3 1.3.6.1.4.1.9.9.23.1.2.1.1.4 1.0.8802.1.1.2.1.3 1.0.8802.1.1.2.1.3.2 1.0.8802.1.1.2.1.4 1.0.8802.1.1.2.1.4.1.1.5 1.3.6.1.2.1.17.2.15 1.3.6.1.2.1.17.2.15.1.6 1.3.6.1.2.1.17.2.15.1.8 1.3.6.1.2.1.17.4.3 1.3.6.1.2.1.17.4.3.1.1 1.3.6.1.2.1.17.7.1.2.2

CISCO-CDP-MIB CISCO-CDP-MIB CISCO-CDP-MIB LLDP-MIB LLDP-MIB LLDP-MIB LLDP-MIB BRIDGE-MIB BRIDGE-MIB BRIDGE-MIB BRIDGE-MIB BRIDGE-MIB Q-BRIDGE

cdpCacheTable cdpCacheAddressType cdpCacheAddress lldpLocalSystemData lldpLocChassisId lldpRemoteSystemsData lldpRemChassisId dot1dStpPortTable dot1dStpPortDesignatedRoot dot1dStpPortDesignatedBridge dot1dTpFdbTable dot1dTpFdbAddress dot1qTpFdbTable

Tabulka 4.2: Použité OID pro zjištˇení pˇrímo pˇripojených sousedu. ˚

OID

MIB

Pojmenování

1.3.6.1.2.1.4.22.1.3 1.3.6.1.2.1.4.34.1.2 1.3.6.1.2.1.4.35.1.3 1.3.6.1.2.1.55.1.5.1.1 1.3.6.1.2.1.55.1.8.1 1.3.6.1.2.1.55.1.12.1.1 1.3.6.1.4.1.9.10.86.1.1.2.1.2 1.3.6.1.4.1.9.10.86.1.1.3.1.2 1.3.6.1.4.1.9.9.23.1.2.1.1.1 1.3.6.1.2.1.17.7.1.2.2.1.1

IP-MIB IP-MIB IP-MIB IPV6-MIB IPV6-MIB IPV6-MIB CISCO-IETF-IP-MIB CISCO-IETF-IP-MIB CISCO-CDP-MIB Q-BRIDGE

ipNetToMediaNetAddress ipAddressAddr ipNetToPhysicalNetAddress ipv6IfIndex ipv6AddrEntry ipv6NetToMediaNetAddress cIpAddressAddr cInetNetToMediaNetAddress cdpCacheIfIndex dot1qTpFdbAddress

Tabulka 4.3: Seznam OID získávaných parsováním indexu.

27

5 Implementace systému Navrženou a požadovanou funkcionalitu vytvoˇrené aplikace lze rozdˇelit do cˇ tyˇr samostatných bloku˚ podle úrovnˇe na které pracují: •

Správa prostˇredku˚ SNMP, aktivní dotazování

•

Zpracování dat získaných pˇres SNMP

•

Vytvoˇrení sít’ové topologie z dostupných dat

•

Zobrazení vytvoˇrené topologie a ovládání programu

Volba použitého programovacího jazyka pˇri implementaci byla z vˇetší cˇ ásti urˇcena zadáním a zadavatelem práce, firmou SolarWinds. Sám jsem tak volil pouze mezi C++ a jazykem C#. S pˇrihlédnutím k poslednímu implementaˇcnímu bloku, který obnáší vytvoˇrení a obsluhu jednoduchého uživatelského rozhraní a interpretaci získaných dat, a znalosti .NET frameworku jsem se rozhodl pro C# a vývojové prostˇredí Microsoft Visual Studio 2010. Vlastní program jsem pojmenoval MyNetDiscoverer, což vystihuje zamˇerˇ ení programu a zárovenˇ odkazuje na využití .NET frameworku, který je tak i požadavkem pro spuštˇení vytvoˇrené aplikace.

5.1

Knihovny tˇretích stran

Vzhledem k navržené funkcionalitˇe aplikace jsem se rozhodl využít jako souˇcást vytvoˇreného programu knihovny tˇretích stran, které usnadní samotnou implementaci a zabrání zbyteˇcnému znovuvytváˇrení již existujícího kódu. V návrhu implementaˇcních bloku˚ jsou dvˇe vhodná místa, kde by jejich využití mohlo být pˇrínosné. Prvním z nich je obsluha samotného SNMP, která by mˇela pro vytváˇrenou aplikaci být naprosto transparentní – aplikace využívá pouze data, která jsou prostˇrednictvím tohoto protokolu pˇrístupná, nikoli ˇ ezec community, jehož zpusob vlastností samotného protokolu. Retˇ ˚ nastavení v aplikaci MyNetDiscoverer je popsán v kapitole 4.2.1, a cˇ asový limit pro získání odpovˇedi sít’ového uzlu lze považovat za nastavení protokolu. Druhým prvkem, který lze dobˇre nahradit knihovnou tˇretí strany, je zobrazování vytvoˇrené topologie sloužící k vizuální prezentaci zpracovaných dat. Pro nalezení vhodného rozložení vrcholu˚ takovým zpusobem, ˚ aby se ve výsledné topologii nepˇrekrývaly ani nehromadily na stranách, je použití propracované knihovny témˇerˇ nutné. Takový problém rˇ eší nˇekolik známých algoritmu, ˚ jejichž implementace by cˇ inila vytvoˇrenou aplikaci zbyteˇcnˇe složitou, a nejsou proto souˇcástí práce. Bez této funkcionality by však využití grafické prezentace získaných dat bylo znaˇcnˇe omezené. 5.1.1 Knihovny pro práci s SNMP Mezi základní požadavky na zvolenou knihovnu jsem kromˇe podpory IPv6 pro dotazování a cenové dostupnosti zaˇradil potˇrebu soubˇežného dotazování na více sít’ových uzlu. ˚ Celkem se mi podaˇrilo nalézt tˇri knihovny, které z vˇetší nebo menší cˇ ásti splnovaly ˇ mé nároky a požadavky. 28

5. I MPLEMENTACE SYSTÉMU SNMP++ První knihovnou je projekt SNMP++ pod licencí BSD. Je psán v jazyce C++ a disponuje pˇrehlednou dokumentací. Vzhledem k odlišnému programovacímu jazyku, vyšším cenám dalších produktu˚ stejného autora a z obavy z pˇrípadného budoucího zpoplatnˇení této knihovny jsem se rozhodl využít alternativy. Net-SNMP Druhou knihovnou pak je Net-SNMP, distribuována pod BSD-like licencí podobnˇe jako SNMP++. Stejnˇe tak je psaná v programovacím jazyce C++, ale dokumentace v nˇekterých místech pusobí ˚ neuceleným dojmem. Pˇrestože disponuje obsáhlým API (Application Programming Interface), rozhodl jsem se kvuli ˚ odlišnému programovacímu jazyku dát pˇrednost následující knihovnˇe. #SNMP Knihovna #SNMP1 je jako jediná ze tˇrí zmínˇených knihoven psána pˇrímo v jazyce C# a je dostupná pod licencí LGPL. Bohužel dokumentace #SNMP je nedostateˇcná, omezuje se pouze na pár krátkých pˇríkladu˚ a ukázkových prográmku, ˚ které jsou dostupné pˇri stažení zdrojových kódu˚ celé knihovny. Diskusní fórum na webových stránkách knihovny je cˇ asto navštˇevované a lze proto pˇredpokládat aktivnˇejší komunitu uživatelu˚ nˇež v pˇrípadˇe dvou výše zmínˇených knihoven. Proto jsem ze srovnání tˇrí uvedených knihoven vybral jako nejvhodnˇejší právˇe #SNMP v poslední verzi 6.0, pˇrestože je slabá dokumentace velkým omezením. 5.1.2 Knihovny pro grafickou prezentaci Výbˇer grafické knihovny k zobrazení vytvoˇrené topologie jsem rˇ ešil v pozdˇejších fázích implementace aplikace. Od takové knihovny jsem vyžadoval bud’ možnost pˇrímého napojení v prostˇredí jazyka C# nebo jednoduché volání binárního souboru se zobrazovanými daty jako parametrem. Graphviz Graphviz je software s dostupnými zdrojovými kódy pod tzv. Eclipse Public License. Je psán v jazyce C a podporuje velké množství výstupních grafických formátu˚ 2 . Podobnˇe podporuje i nˇekolik druhu˚ výstupních grafu˚ a jeho použití je relativnˇe dobˇre dokumentované. Jako vstupní data pro vytvoˇrení grafu˚ vyžaduje zápis v jazyce DOT3 , který lze však velmi jednoduše programovˇe generovat. Využití Graphviz jako binárního programu ke generování vytvoˇrených grafu˚ je ve výsledku docela snadné. Po konzultaci s pracovníky spoleˇcnosti SolarWinds, jakožto zadavateli tématu práce, kteˇrí Graphviz používají v nˇekterém ze svých projektu, ˚ mi ale bylo doporuˇceno pokusit se najít a využít knihovnu pˇrímo do prostˇredí C#. 1. Domovská stránka knihovny #SNMP: http://sharpsnmplib.codeplex.com 2. Pˇrehled grafických formátu: ˚ http://www.graphviz.org/content/output-formats 3. Krátký tutoriál jazyka DOT: http://www.graphviz.org/content/dot-language

29

5. I MPLEMENTACE SYSTÉMU Graph# Vybral jsem knihovnu Graph#4 ve verzi 1.0, která je psaná pˇrímo v jazyce C#. Z prostˇredí .NET frameworku využívá relativnˇe nový grafický subsystém WPF (Windows Presentation Foundation) z roku 2006, který se mimo jiné používá i v prostˇredí Microsoft Silverlight. Podpora pro Silverlight v samotné knihovnˇe Graph# však prozatím chybí, ale je uvedena mezi plánovanými vylepšeními. Knihovna Graph# disponuje také nˇekolika algoritmy, které automaticky seskládají sít’ové uzly ve vytvoˇrené topologii, z nejznámˇejší je v knihovnˇe Graph# implementován algoritmus Fruchterman-Reingold a Sugiyama. Z jednodušších postupu uspoˇrádání grafu implementuje jednoduchý stromový a kruhový graf, které pˇri zobrazení topologií menších sítí poskytují adekvátní výsledky. Jako zdroj informací pˇri použití knihovny slouží diskusní fórum na webových stránkách knihovny. Vlastní dokumentace ke knihovnˇe bohužel v souˇcasné dobˇe neexistuje a její funkce je suplována nˇekolika ne pˇríliš povedenými tutoriály. Tyto tutoriály ale vˇetšinou nepíší samotní autoˇri knihovny Graph#, ale nadšenci z komunity vybudované kolem knihovny. Sám jsem vycházel z návodu [25], kde je na rozdíl od ostatních tutoriálu˚ k Graph# uveden i krátký samodokumentující pˇríklad použití.

5.2

Použité algoritmy

Z vlastních postupu, ˚ které ve vytvoˇrené prototypové aplikaci využívám, stojí za zmínku dva výraznˇejší. Postup 5.1 vychází z metody objevování sítí se znalostí výchozího uzlu a využívám jej pˇri vlastním pruchodu ˚ sítí a k získání dat potˇrebných k následnému vytvorˇ ení obrazu sít’ové topologie. Aplikace uživateli automaticky nabízí pˇredvyplnˇený seznam IP adres, které by mohly sloužit jako výchozí bod pro objevování dostupných sítí. Tento seznam je vytváˇren z adres výchozích bran pro všechny rozhraní stanice, na které je aplikace spuštˇena. Metoda processing (zpracování uzlu) na 10. rˇ ádku trvá z celého postupu pruchodu ˚ sítí nejdéle, a to zejména kvuli ˚ sít’ové komunikaci. Protože však zpracování jednoho sít’ového uzlu je zcela nezávislé na zpracování ostatních uzlu, ˚ lze tento úsek s výhodou provádˇet paralelnˇe ve více soubˇežných vláknech. Pˇri sériovém zpracování uvedeného postupu 5.1 by získání výsledku na vˇetší síti zabralo velké množství cˇ asu. Pokud by totiž na síti bylo napˇríklad sto aktivních sít’ových uzlu˚ a SNMP dotaz na každý uzel by trval kolem pˇeti sekund, což je na vytíženˇejší sítí bˇežná hodnota5 , celkový cˇ as na pruchod ˚ celou sítí by byl pˇres osm minut. Využívám paralelního dotazování takovým zpusobem, ˚ že fronta s uzly ke zpracování slouží jako synchronizaˇcní mechanismus. Pˇríkaz lock v postupu 5.1 uvozuje vstup do kritické sekce a pˇríkaz release znaˇcí uvolnˇení zámku. Fronta uzlu˚ ke zpracování je tak používána nejvýše jedním vláknem souˇcasnˇe, ostatní vlákna musí na uvolnˇení zámku poˇckat. Duležité ˚ je však správné nastavení maximálního poˇctu najednou vytváˇrených spojení, aby nedošlo k zahlcení sítˇe vlastními požadavky. Aplikace MyNetDiscoverer ve výchozím 4. Domovská stránka knihovny Graph#: http://graphsharp.codeplex.com 5. Priorita zpracování SNMP požadavku a zaslání odpovˇedi je na sít’ových uzlech nízká. Uzel tak muže ˚ odpovˇedˇet s cˇ asovým odstupem vˇetším nˇekolika sekund.

30

5. I MPLEMENTACE SYSTÉMU Require: q je prázdná fronta, s je adresa prvního uzlu 1. q.enqueue(s) 2. loop 3. lock q 4. if q je prázdná then 5. release q 6. return 7. end if 8. p ⇐ q.dequeue() 9. release q 10. p.processing() 11. lock q 12. for all n ∈ seznam sousedu˚ uzlu p do 13. if uzel n ještˇe nebyl zpracován then 14. q.enqueue(n) 15. end if 16. end for 17. release q 18. end loop Postup 5.1: Pruchod ˚ sítí se znalostí výchozího uzlu. nastavení omezuje poˇcet soubˇežných spojení na deset, což se pˇri testování aplikace, dále popsaného v 6. kapitole, ukázalo jako vhodná volba. 5.2.1 Postup vytváˇrení topologie Použitím postupu 5.2 vytváˇrím ze získaných sít’ových dat grafovou reprezentaci celé topologie. O její zobrazení se následnˇe stará využitá grafická knihovna Graph#. Metoda createFromNodes v postupu 5.2 na 1. rˇ ádku vytváˇrí topologii na úrovni sít’ové vrstvy, k tomu využívá seznamy sousedu˚ získané z ARP a NDP tabulek. Pro pˇrehlednost implementace, snazší ladˇení chyb a kontrolu vytvoˇrené topologie navíc oznaˇcím všechny uzly v topologii pˇrirozenými cˇ ísly. Dále s využitím informace o použitých fyzických adresách na sít’ových rozhraních každého uzlu metoda mergeSameNodes slouˇcí identické uzly. Pokud uzel SNMP nepodporuje nebo na SNMP dotaz neodpovˇedˇel, využívám ke spojení adresu, na které se jej aplikace snažila kontaktovat. Pˇreuspoˇrádání propojených uzlu˚ pro vyjádˇrení pˇrímého sousedství dvou uzlu˚ zajišt’uje metoda makeDirectNeighbor z 5. rˇ ádku postupu 5.2. Pˇríklad její cˇ innosti je uveden na obrázku 5.1, kde jsou zelenožlutou barvou oznaˇceny uzly n a modrou barvou uzly d. Pˇredpokladem k takovému pˇrerovnání je informace o více pˇripojených sousedech na stejném rozhraní, což v obrázku pˇredstavují spojující se šedé linky, a zárovenˇ informace o pˇrímém sousedovi, která je v obrázku znázornˇena teˇckovanou cˇ arou. Seznam pˇrímých sousedu˚ získávám z dat CDP, LLDP, STP a tabulek pˇrepínaˇcu. ˚ V takové situaci lze pˇredpokládat, že uzly cˇ . 3 a 4 s uzlem cˇ . 1 komunikují pˇres uzel cˇ íslo 2. Pˇríklady s uzly 1-4 a 5-8 se liší pouze informací o dalším propojení mezi uzly 2,3 a 4, respektive 6,7 a 8. Použitý pˇresun 31

5. I MPLEMENTACE SYSTÉMU Require: l je seznam všech sít’ových uzlu, ˚ tp vytváˇrená topologie 1. tp.createFromNodes(l) 2. tp.mergeSameNodes() 3. for all n ∈ všechny uzly v tp do 4. for all d ∈ seznam pˇrímých sousedu˚ n do 5. tp.makeDirectNeighbor(n,d) 6. end for 7. end for 8. for all n ∈ všechny uzly v tp do 9. for all i ∈ seznam rozhraní uzlu n do 10. if poˇcet sousedu˚ na rozhraní i ≥ 1 then 11. tp.createUnknownNode(n,i) 12. end if 13. end for 14. end for 15. tp.mergeUnknownNodes() Postup 5.2: Vytvoˇrení sít’ové topologie ze získaných dat. však pˇredpokládá úplné propojení zmínˇených 4 uzlu˚ a pˇrípadná spojení mezi uzly 1,3 a 4, respektive 5,7 a 8 jsou proto odebrána. Operace createUnknownNode na 11. rˇ ádku rˇ eší situace, kdy sít’ové uzly podporují SNMP a poskytnou informace o svých sousedech na sít’ové vrstvˇe ISO/OSI, ale nepodporují ani jeden z dále používaných protokolu˚ a chybí tak informace o pˇrímo pˇripojených sít’ových uzlech. Pokud je na nˇekterém rozhraní sít’ového uzlu pˇripojen více než jeden soused, aplikace vytvoˇrí nový „neznámý“ uzel s ikonou obláˇcku a pˇripojené sousedy pˇrepojí. A to i v pˇrípadˇe, že by takový stav odpovídal fyzické topologii (napˇríklad u Frame Relay nebo pˇri použití koaxiálního kabelu), protože aplikace nemuže ˚ výsledek spolehlivˇe ovˇerˇ it. Ukázka takového pˇrepojení je v obrázku 5.2. Proceduru mergeUnknownNodes, na 15. rˇ ádku, lze oznaˇcit za volitelnou, pˇresto jsem

Obrázek 5.1: Pˇreuspoˇrádání pˇrímých sousedu˚ uzlu˚ cˇ . 1 a 2, respektive 5 a 6. 32

5. I MPLEMENTACE SYSTÉMU

Obrázek 5.2: Pˇrepojení více sousedu˚ na jednom rozhraní. se ji rozhodl cˇ ásteˇcnˇe implementovat. V prubˇ ˚ ehu vytváˇrení tzv. „neznámých“ uzlu˚ muže ˚ dojít k situaci, kdy se ve výsledné topologii více neznámých uzlu˚ objeví jako sousední. Protože jejich existence není podložena pˇresnými daty, lze takové sousedící uzly slouˇcit do jednoho.

5.3

Postup implementace

Na úrovni jmenných prostoru˚ jsem program rozdˇelil do nˇekolika dalších, funkˇcnˇe oddˇelených bloku. ˚ Jako prefix pro pojmenování jmenných prostoru˚ využívám zkratku vytvoˇrenou z vlastního pˇríjmení. Sochi.Constants jsem využil k uložení všech využívaných OID pro jednotlivé MIB. K tomu jsem si napsal tˇrídu Constants, kde jsem všechny OID ještˇe na jednotlivých úrovních rozdˇelil do podtˇríd. Navíc jsem je na první úrovni ještˇe rozdˇelil podle pˇribližného rozsahu jejich obsahu na jednoduché OID, které se využívají pˇri rozebírání získaných odpovˇedí a obsahují pouze jednu hodnotu, a skupinové OID, které zahrnují cˇ asto celé dotazované tabulky. Sochi.Exceptions obsahuje definice používaných nestandardních výjimek. Sochi.Status zahrnuje pouze nˇekolik výˇctových typu, ˚ které pˇrispívají k pˇrehlednosti vytvoˇreného kódu. Mezi nimi je typ adresy, status rozhraní a další 3 vyloženˇe implementaˇcní typy. Sochi.Storage slouží k ukládání dat, které se podaˇrilo ze sítˇe získat. Obsahuje pouze tˇri základní tˇrídy a to Agent, která obsahuje informace (sít’ovou adresu, port a SNMP rˇ etˇezec community) pro pˇripojení k vybranému sít’ovému uzlu, Node a Interface. Tˇrída Interface slouží k uložení informací o jednom rozhraní – obsahuje textový popisek rozhraní, jeho MAC adresu a seznam pˇriˇrazených sít’ových adres. Tˇrída Node potom pˇredstavuje jednotlivé sít’ové uzly, kdy obsahuje vlastní jméno nebo textový popisek, seznam tˇríd Interface jako vlastních rozhraní, seznam sousedu˚ a sít’ovou adresu, na které bych uzel kontaktován. Sochi.Inquire využívám k obsluze knihovny #SNMP a kontrole vrácených dat. Obsahuje pouze tˇrídu Inquirer, která v rámci kontroly získaných dat také posílá tzv. GetNextRequest požadavky na další cˇ ásti záznamu˚ z SNMP, pokud v odpovˇedích ještˇe ne33

5. I MPLEMENTACE SYSTÉMU byly obdrženy všechny hodnoty pro požadované OID. Dále provádí promazání záznamu, ˚ které podle svého OID nepatˇrí pod puvodní ˚ dotazované OID. Sochi.Parse disponuje pouze tˇrídou Parser, jenž mˇela sloužit pouze ke zpracování získaných dat z SNMP. V pozdˇejších fázích implementace se však ukázalo jako vhodné obohatit tuto tˇrídu o nˇekolik statických metod, které se využívají i v dalších jmenných prostorech. Tˇrída Parser využívá vlastní typ výjimek, ParserException. Sochi.Handle obsahuje tˇrídy Handler a LoadingState. Tˇrída Handler slouží ke správˇe programových vláken a cˇ eká na jejich ukonˇcení. Tˇrída LoadingState se využívá pouze jako pomocná tˇrída pro pˇredání argumentu˚ vláknu a pro kontrolu ukonˇcení vlákna. Sochi.Topology je implementaˇcnˇe nejzajímavˇejším jmenným prostorem. Jediná tˇrída v jmenném prostoru, Topologer, rˇ eší kompletní pˇremˇenu získaných sít’ových dat do struktury grafu a využívá výše uvedený postup 5.2. Sochi.Display slouží k obsluze knihovny Graph# a obsahuje více ruzných ˚ tˇríd, které jsou k obsluze grafické knihovny potˇreba. Dále popisuje také uživatelské prostˇredí celé prototypové aplikace. Sochi.Logs jsem využil k zaznamenávání veškerých informací, které program ze sítˇe získal. Ty jsem využíval zejména pˇri vývoji samotné aplikace, ale díky rozdˇelení do samostatných souboru˚ jsou dobˇre použitelné i dále jako kontrola dat získaných pˇres SNMP od jednotlivých sít’ových uzlu. ˚ V obrázku 5.3 je zjednodušený diagram tˇríd pro celou aplikaci, kde tˇrídy Application a Window jsou standardní tˇrídy z prostˇredí .NET frameworku. Specifickým prvkem v diagramu je zcela statická tˇrída Log, kterou využívají témˇerˇ všechny ostatní tˇrídy. Spojení vedoucí do tˇrídy Log jsou v diagramu tˇríd vynechána, protože jejich zanesení do jednoho diagramu by vytvoˇrilo zbyteˇcný zmatek. Podrobnˇejší dokumentace celého projektu je k dispozici na pˇriloženém DVD. Pˇriložené DVD obsahuje také zdrojové kódy celé aplikace a projektový soubor pro otevˇrení v editoru Microsoft Visual Studio 2010.

5.4

Prostˇredí aplikace

Prostˇredí aplikace MyNetDiscoverer se skládá ze 3 hlavních cˇ ástí – vrchní lišty s nastavením aplikace, stavové lišty u spodního okraje okna a hlavního šedého boxu, ve kterém se zobrazuje výsledná topologie. Okno aplikace MyNetDiscoverer po spuštˇení je na obrázku 5.4. Celé uživatelské prostˇredí vytvoˇrené aplikace je detailnˇeji popsáno v následujících devíti odstavcích. 1.

Výbˇerové pole s pˇrednastavenými adresami výchozích bran pro všechna sít’ová rozhraní. Na obrázku 5.5 je vysunutý seznam nabízených adres. Ruˇcnˇe lze zadat odlišnou adresu.

2.

Nastavení SNMP rˇ etˇezce community. Aplikace využívá stejný rˇ etˇezec community pro všechny dotazované uzly. 34


Obrázek 5.3: Diagram tˇríd aplikace MyNetDiscoverer. 3.

ˇ Císlo portu, na kterém bude proveden pokus o pˇripojení na SNMP. Ve výchozím stavu je pˇrednastaveno cˇ íslo portu 161, jakožto standardní SNMP port.

4.

Maximální poˇcet programových vláken, které budou soubˇežnˇe aktivní. Tímto nastavením lze zabránit zahlcení sítˇe vlastními SNMP požadavky.

5.

ˇ Casový limit v milisekundách pro obdržení odpovˇedi od kontaktovaného sít’ového uzlu. Pokud odpovˇed’ vˇcas nedorazí, aplikace považuje uzel za nedostupný prostˇrednictvím SNMP a z informací o takovém uzlu má pouze adresu, na které se jej snažila kontaktovat.

6.

Tlaˇcítka „Save to file“ a „Load from file“ slouží k uložení získané topologie do souboru, respektive naˇctení topologie ze souboru. Díky této funkcionalitˇe je možné odložit detailní prostudování vytvoˇrené topologie na pozdˇeji, což pˇrispívá k základnímu uživatelskému komfortu pˇri použití aplikace.

7.

Slouží ke zvˇetšování a zmenšování zobrazené topologie.

8.

Pˇreddefinovaný výbˇer algoritmu, ˚ které jsou k dispozici pro uspoˇrádání zobrazené topologie. Pˇri zobrazení velké sítˇe a výbˇeru nˇekterého z nároˇcnˇejších algoritmu˚ muže ˚ 35


Obrázek 5.4: Oˇcíslovaná úvodní obrazovka aplikace MyNetDiscoverer. pˇreuspoˇrádání trvat déle než pár sekund. 9.

Zobrazuje aktuální stav programu a informuje o spotˇrebovaném cˇ ase pro naˇctení topologie.

Obrázek 5.5: Výbˇer z pˇrednastavených adres výchozích bran.

36

6 Srovnání a ovˇerˇení výsledku˚ systému Vytvoˇrenou aplikaci jsem testoval již bˇehem vývoje, a to ve tˇrech ruzných ˚ sítích. V první fázi, která obnášela základní zprovoznˇení knihovny #SNMP, jednoduché dotazování na SNMP tabulky hodnot a kontroly získávaných dat, jsem k testování využíval výhradnˇe domácí sít’ s jediným smˇerovaˇcem Asus WL500GP. Celá domácí sít’ je postavena pouze na IPv4 a bˇežnˇe se na ni vyskytuje 3 až 8 aktivních sít’ových uzlu. ˚ Z kontroly získávaných dat jsem však zjistil, že nˇekteré hodnoty smˇerovaˇc Asus vrací se špatnými daty – z nejvˇetších chyb lze zmínit tvrzení, že všechny jeho sousední uzly jsou „pˇripojeny“ pˇres loopback rozhraní, což je zˇrejmý nesmysl. Ukázka takového chování v záznamu zpracovaných SNMP odpovˇedí je vidˇet v poznámce 6.1. Node name: Linux asus 2.4.20 #109 Fri Oct 17 09:11:33 CEST 2008 Available interfaces: 1: lo [040000000000][Up] with 127.0.0.1 2: eth0 [001731D693E4][Up] with 0.0.0.0 3: eth1 [001731D693E4][Up] with no IP address assigned 4: vlan0 [001731D693E4][Up] with no IP address assigned 5: vlan1 [001731D693E4][Up] with 94.112.189.36 6: br0 [001731D693E4][Up] with 192.168.1.1 Network layer neighbors: On interface 1: [00015C3116F8][Unknown] with 94.112.188.1 On interface 1: [001FE218616B][Unknown] with 192.168.1.17 On interface 1: [00028A95A91A][Unknown] with 192.168.1.67 On interface 1: [001DE069A53D][Unknown] with 192.168.1.117 On interface 1: [0019DBCD1EA0][Unknown] with 192.168.1.232 On interface 1: [00030D74CADA][Unknown] with 192.168.1.241 Poznámka 6.1: Záznam zpracovaných odpovˇedí smˇerovaˇce Asus. Rozhodl jsem se proto pozdˇeji kromˇe domácího uzlu použít pro testování také virtuální sít’. K tomu jsem využil zdarma dostupný nástroj VirtualBox1 a smˇerovaˇcu˚ OpenWrt. Projekt OpenWrt je postaven na linuxovém jádˇre a je také volnˇe dostupný, pouze jsem na vytvoˇrené virtuální sít’ové uzly musel doinstaloval podporu SNMP. S pokraˇcujícím vývojem aplikace MyNetDiscoverer jsem shledal virtuální sít’ jako nedostaˇcující, protože jednotlivé virtuální OpenWrt uzly nepodporují další protokoly pro objevení sítˇe, jako je CDP nebo LLDP. Tˇretím prostˇredím, kde jsem provádˇel testování programu ve vˇetší míˇre, je sít’ová laboratoˇr spoleˇcnosti SolarWinds, jakožto zadavatele tématu práce. Hlavním duvodem ˚ pro testování aplikace v laboratoˇri SolarWinds byla kontrola funkcionality v prostˇredí IPv6 a v prostˇredí obou verzí IP a mezi zaˇrízeními ruzných ˚ výrobcu. ˚ Kvuli ˚ dalšímu testování na malých sítích jsem však opˇet využil i domácího smˇerovaˇce Asus.

1. Domovský stránka projektu VirtualBox: http://www.virtualbox.org

37

ˇ ˚ SYSTÉMU 6. S ROVNÁNÍ A OV Eˇ RENÍ VÝSLEDK U

6.1

Výstupy aplikace

Výstupem aplikace MyNetDiscoverer je grafické zobrazení získané sít’ové topologie. Každý uzel je v topologii zobrazen jako jeden ze tˇrí obrázku˚ podle dostupných informací a poˇctu vlastních sít’ových rozhraní – pokud má uzel právˇe jedno sít’ové rozhraní, zobrazí se s ikonou stolního poˇcítaˇce. Pokud má uzel vˇetší poˇcet rozhraní, zobrazí se s ikonou pˇrepínaˇce a pokud k uzlu nejsou žádné dostupné informace, je zobrazen jako obláˇcek.

Obrázek 6.1: Domácí sít’ se zobrazeným tooltipem jednoho z uzlu. ˚ Protože tento uzel neodpovˇedˇel na SNMP, zobrazené informace jsou získány z tabulek sousedních uzlu. ˚ V zájmu zachování pˇrehlednosti zobrazované topologie a snaze o udržení stˇrízlivého množství textového výstupu jsem se rozhodl u každého sít’ového uzlu po naˇctení zobrazovat pouze tzv. rychlý pˇrehled obsahující seznam IP adres, na kterých byl kontaktován a na které byly zasílány SNMP dotazy. Podrobné informace o jednotlivých uzlech jsou dostupné jako tzv. tooltip nad obrázkem každého uzlu, jak je vidˇet v obrázku 6.1. Tento tooltip se zobrazí až po najetí myší nad vybraný sít’ový uzel a obsahuje seznam dostupných rozhraní, seznam sousedu˚ na sít’ové vrstvˇe ISO/OSI a dále seznamy pˇrímo pˇripojených sousedu. ˚ Na prvním rˇ ádku tooltipu je navíc uvedeno identifikaˇcní cˇ íslo, které bylo pro vybraný uzel pˇriˇrazeno pˇri vytváˇrení topologie. Samostatnˇe nenese žádnou informaci, lze jej ale využít pˇri zpˇetné kontrole zdrojových záznamu˚ 2 . V pˇrípadˇe uzlu, ˚ které vznikly spojením nˇekolika jiných sít’ových uzlu˚ na základˇe stejných MAC adres, je v rychlém pˇrehledu uvedeno více sít’ových adres, a v tooltipu jsou pod sebou informace pro všechny existující sít’ové uzly získané pˇred jejich slouˇcením.

ˇ 2. Císlovaný seznam uzlu˚ a jejich sousedu˚ v logu je uložen v souboru _items.log.

38


6.2

Srovnání a ovˇerˇení topologie

K ovˇerˇ ení topologie vytvoˇrené aplikací MyNetDiscoverer jsem využil dvou porovnání – jednak vycházím ze znalosti skuteˇcného fyzického zapojení a dále porovnávám výsledek s výstupem komerˇcního produktu SolarWinds LANsurveyor. Ten však podporuje pouze IPv4 a k objevení všech uzlu˚ na síti kromˇe SNMP využívá také utilitu ping3 , s jejímž využitím vytvoˇrí spojení na všechny existující sít’ové adresy v rozsahu sítˇe. Lze proto oˇcekávat, že topologie vytvoˇrená aplikací LANsurveyor bude v prostˇredí IPv4 fakticky pˇresnˇejší, protože aplikace MyNetDiscoverer nevyhledá uzly, o kterých se nedozví ze získaných SNMP odpovˇedí. 6.2.1 Prostˇredí malé IPv4 sítˇe Jako testovací prostˇredí pro porovnání výsledku˚ v malé síti využívající IPv4 jsem využil domácí sít’. V dobˇe testování se skládala z centrálního smˇerovaˇce Asus WL500GP, který sloužil zárovenˇ jako pˇrepínaˇc a pˇrístupový bod Wi-Fi, cˇ tyˇr pracovních stanic pˇripojených pˇres kabelové linky a dvou stanic pˇripojených pˇres Wi-Fi. Smˇerovaˇc byl pˇripojen do dvou sítí a mˇel pˇriˇrazeny adresy 94.112.189.36 a 192.168.1.1, pˇriˇcemž adresa domácí sítˇe byla 192.168.1.0/24.

Obrázek 6.2: Obraz topologie domácí sítˇe vytvoˇrený aplikací MyNetDiscoverer. Výstup z aplikace MyNetDiscoverer pro domácí sít’ je uveden na obrázku 6.2. Díky agresivnímu cˇ asovému limitu (500 ms) pro SNMP odpovˇedi se podaˇrilo celou topologii naˇcíst bˇehem necelých sedmi sekund. Vytvoˇrená topologie odpovídá informacím, které 3. Aplikace LANsurveyor mimo jiné podporuje také metodu objevování sítˇe s využitím vlastních LANsurveyor Reponders.

39


bylo možné ze sítˇe prostˇrednictvím SNMP zjistit. Jak jsem zmínil v úvodu této kapitoly, smˇerovaˇc Asus WL500GP pˇres SNMP vrací nesprávné informace o rozhraní, na kterém je sít’ový uzel pˇripojen.

Obrázek 6.3: Topologie domácí sítˇe vytvoˇrená aplikací LANsurveyor. Na obrázku 6.3 je topologie vytvoˇrená aplikací LANsurveyor pˇri využití utility ping. Naˇctení a vytvoˇrení této topologie trvalo sice pˇres dvacet sekund, ale výsledek díky seskupení uzlu˚ podle adresy sítˇe pusobí ˚ pˇrehlednˇeji. Bˇehem intervalu mezi testováním aplikací MyNetDiscoverer a LANsurveyor došlo k odpojení sít’ových uzlu˚ s IP adresami 192.168.1.67 a 192.168.1.69 a pˇripojení 192.168.1.3, což vysvˇetluje objevení odlišných pˇripojených stanic. Objevení uzlu s adresou 94.112.188.55 aplikací LANsurveyor bylo docíleno využitím utility ping. Protože o jeho existenci dotazovaný uzel Asus nemá žádný záznam, aplikace MyNetDiscoverer se o takovém uzlu nemohla dozvˇedˇet. V rámci testování jsem se rozhodl provést taky porovnání s topologií vytvoˇrenou aplikací LANsurveyor bez využití programu ping. Ve výslední topologii zobrazené na obrázku 6.4 chybí informace o všech pˇripojených sít’ových uzlech. Z porovnání vyplývá, že v prostˇredí malých IPv4 sítí muže ˚ aplikace MyNetDiscoverer konkurovat komerˇcnímu produktu LANsurveyor. Získané topologie se liší pouze seskupením uzlu˚ podle sít’ové masky. 6.2.2 Velká sít’ nad IPv4 Testování na velké síti probíhalo v laboratoˇri SolarWinds. Protože se však jedná o rozsáhlou sít’, k porovnání vytvoˇrené topologie jsem využil pouze sít’ s adresou 10.199.4.0/24. Skuteˇcná topologie vybrané podsítˇe je uvedena v obrázku 6.5, který mi poskytli pracovníci spoleˇcnosti SolarWinds. V této topologii však nˇekterá zaˇrízení chybí a navíc v ní nejsou 40


Obrázek 6.4: Obraz domácí sítˇe vytvoˇrený aplikací LANsurveyor bez využití utility ping.

zaneseny informace o stavech zobrazených zaˇrízení – nˇekteré uzly mohou být napˇríklad vypnuty. Aplikaci MyNetDiscoverer trvalo vytvoˇrení topologie sítˇe pˇribližnˇe 14 minut. V obrázku 6.6, který cˇ ást výsledné topologie zobrazuje, je však uvedena jiná cˇ asová hodnota – to je zpusobeno ˚ naˇcítáním zdrojových dat pˇri vytváˇrení obrazu z dˇríve uloženého souboru místo ze sítˇe. Vytvoˇrit sít’ovou topologii zabralo aplikaci LANsurveyor více než hodinu – obrázek 6.7. Zásadním rozdílem mezi touto topologií a výsledkem aplikace MyNetDiscoverer je rozdˇelení uzlu˚ podle adresy sítˇe. Liší se však taky úrovní detailu, kdy aplikace LANsurveyor napˇríklad zobrazuje místo generických ikon sít’ových uzlu˚ logo výrobce. V obou topologiích se objevují podobné nepˇresnosti vuˇ ˚ ci skuteˇcné topologii uvedené v obrázku 6.5. Napˇríklad uzel s adresou 10.199.4.1 v obou pˇrípadech chybí a naopak se objevují uzly 10.199.4.254 a 10.199.250.204. Protože testování obou aplikací neprobíhalo souˇcasnˇe, nˇekteré odlišnosti mezi topologiemi mohly být zpusobeny ˚ pˇripojením nebo odpojením nˇekterých uzlu. ˚ V pˇrípadˇe sítˇe 10.199.4.0/24 se aplikaci MyNetDiscoverer podaˇrilo objevit pˇribližnˇe 60 % sít’ových uzlu, ˚ které byly uvedeny ve skuteˇcné topologii. V pˇrípadˇe aplikace LANsurveyor byla úspˇešnost 50 %, ale s pˇrihlédnutím k nepˇresnostem ve referenˇcním obrazu topologie nelze tˇemto cˇ íslum ˚ pˇrikládat velkou váhu. Z hlediska pˇresnosti vytvoˇrené topologie jsou obou aplikací srovnatelné. Díky využití paralelního dotazování je však aplikace MyNetDiscoverer výraznˇe rychlejší – v pˇrípadˇe laboratorní sítˇe SolarWinds aplikace MyNetDiscoverer vyžadovala pouze cˇ tvrtinu cˇ asu, který potˇreboval LANsurveyor. 41


6.2.3 Testování v prostˇredí IPv6 Otestování aplikace MyNetDiscoverer v prostˇredí IPv6 sítˇe bylo opˇet provedeno v laboratoˇri SolarWinds. Protože však v IPv6 cˇ ásti laboratoˇre není k dispozici spolehlivý zdroj informací o propojení uzlu˚ a program LANsurveyor IPv6 nepodporuje, nebylo možné provést v tomto prostˇredí žádné porovnání. Topologie vytvoˇrena aplikací MyNetDiscoverer je uvedena na obrázku 6.8 a pˇrestože by podle pracovníku˚ spoleˇcnosti SolarWinds takový výsledek mˇel odpovídat skuteˇcnému zapojení, nelze to spolehlivˇe ovˇerˇ it. Podrobnˇejší informace a zdrojové záznamy vytvoˇrených topologií jsou k dispozici na pˇriloženém DVD.

42


Obrázek 6.5: Skuteˇcná topologie podsítˇe 10.199.4.0/24 laboratoˇre SolarWinds.

43


Obrázek 6.6: Topologie velké sítˇe vytvoˇrená aplikací MyNetDiscoverer.

Obrázek 6.7: Topologie velké sítˇe vytvoˇrená aplikací LANsurveyor. 44


Obrázek 6.8: Malá sít’ v laboratoˇri SolarWinds využívající IPv4 a IPv6.

45

7 Závˇer Výsledkem práce je prototypová aplikace MyNetDiscoverer, která na základˇe zadaných parametru˚ s využitím SNMP vytvoˇrí obraz sít’ové topologie. Jako vstup vyžaduje adresu nˇekterého z dostupných sít’ových uzlu, ˚ který zárovenˇ podporuje SNMP. Po spuštˇení aplikace je uživateli nabídnut seznam IP adres sít’ových uzlu, ˚ které lze využít jako první dotazovaný uzel. Zdrojem tˇechto informací jsou výchozí brány pro jednotlivá rozhraní, jak je uvedeno v kapitole 5.2. Ukládání vytvoˇrených topologií do souboru a naˇcítání ze souboru˚ je aplikací také podporováno. V rámci rešeršní cˇ ásti práce jsem vytvoˇril seznam dostupných metod pro objevování sítí rozdˇelený podle použitelnosti v prostˇredí sítí IPv4 a IPv6. Pˇri samotné implementaci jsem si vyzkoušel práci s knihovnami #SNMP a Graph#, paralelní zpracování požadavku˚ vˇcetnˇe synchronizace vláken a programování obsluhy jednoduchého uživatelského rozhraní. Pˇrestože program splnil základní požadavky zadání práce, v budoucnu by bylo možné napˇríklad zlepšit postup objevování koncových stanic, rozšíˇrit program o zjišt’ování dostupných sít’ových služeb [26] nebo pˇridat funkcionalitu pro generování statistik a sledování zmˇen sít’ové topologie. Souˇcástí dalšího vývoje aplikace by mohl být také export topologie do nˇekterých standardních formátu˚ typu XML nebo jazyka DOT.

46

Literatura [1] HSIEH, I., KAO, S. Topology Discovery for Coexisting IPv6 and IPv4 Networks. In ICIS-COMSAR Proceedings of the 5th IEEE/ACIS international Conference on Computer and information Science and 1st IEEE/ACIS international Workshop on Component-Based Software Engineering, Software Architecture and Reuse. Washington: IEEE Computer Society, 2006, p. 89–95. [2] LUO, J., FAN, M., YE, D. Research on Topology Discovery for IPv6 Networks. In Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing. Eighth ACIS International Conference on. Qingdao: SNPD, 2007, p. 804–809. [3] WADDINGTON, D. G., CHANG, F., VISWANATHAN, R., YAO, B. Topology discovery for public IPv6 networks. SIGCOMM Computer Communication Review, 2003, vol. 33, no. 3, p. 59–68. [4] GUANLAN, C., QIN, Z., YAN, M., HONGLI, K. A new topology discovery solution for IPv4 & IPv6 coexisting networks. In International Conference on Advanced Intelligence and Awarenss Internet (AIAI 2010). Beijing, 2010, p. 208–212. [5] DURAND, A. Deploying IPv6. IEEE Internet Computing, 2001, vol. 5, no. 1, p. 79–81. [6] RFC 1122. Requirements for Internet Hosts – Communication Layers [online]. BRADEN, R. October 1989 [quot. 2011-04-10]. 116 p. Dostupný z WWW: . [7] RFC 4291. IP Version 6 Addressing Architecture [online]. HINDEN, R., DEERING, S. February 2006 [quot. 2011-04-10]. 25 p. Dostupný z WWW: . [8] MAURO, D. R., SCHMIDT, K. J. Essential SNMP. Sebastopol: O’Reilly Media, 2005. ISBN 978-0-596-00840-6. [9] RFC 1901. Introduction to Community-based SNMPv2 [online]. CASE, J., MCCLOGHRIE, K., ROSE, M., WALDBUSSER, S. January 1996 [quot. 2011-04-12]. 8 p. Dostupný z WWW: . [10] RFC 1910. User-based Security Model for SNMPv2 [online]. WATERS, G. February 1996 [quot. 2011-04-12]. 44 p. Dostupný z WWW: . [11] BLUMENTHAL, U., WIJNEN, B. Security Features of SNMPv3. The Simple Times: The Quarterly Newsletter of SNMP Technology, Comment, and Events, 1997, vol. 5, no. 1, [quot. 2011-04-15]. Dostupný z WWW: . ISSN: 1060-6080. [12] RFC 1157. A Simple Network Management Protocol (SNMP) [online]. CASE, J., FEDOR, M., SCHOFFSTALL, M., DAVIN, J. May 1990 [quot. 2011-04-11]. 36 p. Dostupný z WWW: . 47

ˇ 7. Z ÁV ER

[13] KOZIEROK, C. M. The TCP/IP guide: a comprehensive, illustrated Internet protocols reference. San Francisco: No Starch Press, 2005, on p. 1080. ISBN 9781593270476. [14] RFC 3414. User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) [online]. BLUMENTHAL, U., WIJNEN, B. December 2002 [quot. 2011-04-12]. 88 p. Dostupný z WWW: . [15] RFC 1155. Structure and Identification of Management Information for TCP/IP-based Internets [online]. ROSE, M., MCCLOGHRIE, K. May 1990 [quot. 2011-04-16]. 22 p. Dostupný z WWW: . [16] RFC 2578. Structure of Management Information Version 2 (SMIv2) [online]. MCCLOGHRIE, K., PERKINS, D., SCHOENWAELDER J. April 1999 [quot. 2011-04-19]. 43 p. Dostupný z WWW: . [17] Cisco Discovery Protocol. In Cisco Systems: Technology support [online]. San Jose: Cisco Systems [cit. 2011-05-01]. Dostupný z WWW: . [18] Catalyst Token Ring Switching Implementation Guide. San Jose: Cisco Systems, last modif. 2002-10-02 [quot. 2011-03-03]. Dostupný z WWW: . [19] IEEE Std. 802.1AB-2005. Station and Media Access Control Connectivity Discovery [online]. May 2005 [quot. 2011-04-23]. 158 s. Dostupný z WWW: . ISBN 07381-4688-9. [20] IEEE Std. 802.1AB-2009. Station and Media Access Control Connectivity Discovery [online]. September 2009 [quot. 2011-04-24]. 190 p. Dostupný z WWW: . ISBN 978-0-7381-6038-2. [21] Using Link Layer Discovery Protocol in Multivendor Networks. In Cisco Systems: Cisco IOS and NX-OS Software [online]. San Jose: Cisco Systems, 2007, last modif. 2011-02-07 [quot. 2011-03-20]. Dostupný z WWW: . [22] PERLMAN, R. Interconnections. Boston: Addison-Wesley, 2000. ISBN 0-201-63448-1. [23] Alternative Features for Link Aggregation and Device Discovery (End of Support for FEC and CDP). Roseville: Hewlett-Packard Company, last modif. 2006-01-24 [quot. 2011-03-12]. Dostupný z WWW: . [24] 3Com Switch 4800G Gigabit Family Datasheet. Marlborough, March 2009 [quot. 2011-05-10]. Dostupný z WWW: . 48

ˇ 7. Z ÁV ER

[25] BARBER, S. Pretty Cool Graphs In WPF. Last modif. 2010-08-03 [quot. 2011-02-06]. Dostupný z WWW: . [26] HELAL, S. Standards for service discovery and delivery. IEEE Pervasive Computing, 2002, vol. 1, no. 3, p. 95–100.

49

A Obsah pˇriloženého DVD •

Text práce

•

Spustitelná aplikace MyNetDiscoverer

•

Dokumentace k aplikaci MyNetDiscoverer

•

Zdrojové kódy aplikace MyNetDiscoverer

•

Projekt do editoru Microsoft Visual Studio

•

Záznam z testování na domácí síti s IPv4

•

Záznam z testování na IPv4 síti SolarWinds

•

Záznam z testování na malé sítí s IPv6

50

B Návod k použití aplikace Po spuštˇení aplikace MyNetDiscoverer se objeví hlavní okno aplikace, jako je na obrázku 5.4. Všechny parametry objevování sítˇe jsou zobrazeny jako formuláˇrové prvky a jsou pˇredvyplnˇeny výchozími hodnotami. Pˇred spuštˇením vlastního objevování sítˇe je tˇreba zkontrolovat a pˇrípadnˇe zmˇenit IP adresu prvního uzlu a použitý rˇ etˇezec community. Podle provozu na síti je tˇreba také vhodnˇe nastavit cˇ asový limit pro odpovˇedi jednotlivých sít’ových uzlu˚ – na malé síti postaˇcí hodnoty okolo 3000 ms, v prostˇredí vˇetších sítí je vhodnˇejší hodnota mezi 10000 ms a 20000 ms. Pro úspˇešné získání sít’ové topologie musí uzel dostupný pˇres zadanou IP adresu podporovat SNMP. Zásadní je také úspˇešná autentizace vuˇ ˚ ci dotazovanému uzlu s využitím zadaného rˇ etˇezce community. V pˇrípadˇe zadání nedostupné IP adresy nebo pˇri chybné autentizaci je objevování topologie po prvních pokusech o navázání spojení ukonˇceno pro nedostatek informací získaných ze sítˇe. Po spuštˇení objevování sítˇe je v pravé cˇ ásti stavové lišty poˇcítán spotˇrebovaný cˇ as. Pokud dojde pˇri vytváˇrení topologie k chybˇe nebo se nepodaˇrí ze sítˇe získat potˇrebná topologická data, aplikace zobrazí v dialogovém oknˇe upozornˇení. V opaˇcném pˇrípadˇe se výsledná topologie zobrazí ve stˇrední cˇ ásti aplikaˇcního okna. Pˇri najetí myší nad nˇekterý sít’ový uzel se zobrazí podrobnˇejší informace o tomto sít’ovém uzlu. Pomocí ovládacího prvku na levém okraji prostˇrední cˇ ásti okna je možné zobrazenou topologii pˇribližovat a oddalovat. Dále je možné všechny sít’ové uzly v topologii pˇri podržení levého tlaˇcítka myši pˇresouvat. Stejným zpusobem ˚ je možné posunovat celou topologii. V levé cˇ ásti stavové lišty je potom umístˇen výbˇer algoritmu˚ k automatickému uspoˇrádání sít’ových uzlu. ˚ K pˇreuspoˇrádání topologie dojde pˇri zmˇenˇe používaného algoritmu. V pˇrípadˇe velké topologie však muže ˚ v prubˇ ˚ ehu pˇreuspoˇrádání celé topologie dojít ke zpomalení odezvy aplikaˇcního rozhraní.

Záznamy vytvoˇrené topologie Pˇri naˇcítání topologie ze sítˇe jsou vytváˇreny záznamy všech získaných dat. Ty jsou ukládány do adresáˇre s náhodnˇe generovaným jménem v podadresáˇri Logs a jsou dˇeleny do souboru˚ podle zdrojového sít’ového uzlu. Navíc jsou v tomto adresáˇri vytvoˇreny 4 další soubory: _runtime.log obsahuje stavové zprávy jednotlivých aplikaˇcních vláken. _topology.log obsahuje v cˇ itelném formátu podrobnˇejší informace o všech uzlech. _items.log je pomocným souborem k vytvoˇrené topologii. _serialized.log je soubor obsahující celou topologii v binárním formátu. Stejný soubor aplikace MyNetDiscoverer vytvoˇrí pˇri ukládání topologie do souboru. 51

B. N ÁVOD K POUŽITÍ APLIKACE

Ukládání a naˇcítání topologie ze souboru Vytvoˇrenou topologii je možné uložit do souboru pro pozdˇejší zobrazení. K tomu slouží ovládací tlaˇcítka v pravém horním roku aplikaˇcního okna. Dˇríve uloženou topologii je možné stejným zpusobem ˚ také naˇcíst.

Postup instalace Protože aplikace MyNetDiscoverer kvuli ˚ vytváˇreným záznamum ˚ potˇrebuje v prubˇ ˚ ehu objevování sítˇe zapisovat data do souboru, není možné ji spustit pˇrímo z pˇriloženého DVD. Aplikaci však není tˇreba instalovat, staˇcí zkopírovat spustitelný soubor na zapisovatelný disk. Ke spuštˇení aplikace MyNetDiscoverer je vyžadován Microsoft .NET framework 3.5 nebo novˇejší.

52

012345

Recommend Documents