eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·
Bakalá°ská práce
Automatické rozpoznávání topologie sít¥
Luká² He°bolt
Vedoucí práce:
Ing. Michal Medvecký
Studijní program: Softwarové technologie a management, Bakalá°ský
Obor: Softwarové inºenýrství
7. ledna 2010
iv
v
Pod¥kování Na tomto míst¥ bych rád pod¥koval Ing. Michalu Medveckému za jeho cenné rady a £as, který této práci v¥noval. Dále bych rád pod¥koval Dominiku Pant·£kovi za poskytnutí testovacího prost°edí.
vi
vii
Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).
V Praze dne 7. 1. 2010
.............................................................
viii
Abstract This paper is attend to methods of reconstruction physical network topology. It is focus on heterogeneous network background and data mining with SNMP. The beginning of this paper is focus on protocols which are appropriate for getting data from network machines. During the project a method based on analysis of CAM tables is drawn up. This method is able to rebuild network topology. This method is implemented and tested in conclusion.
Abstrakt Tato práce se v¥nuje metodám rekonstrukce fyzické topologie sít¥. Je zam¥°ena na heterogenní sí´ové prost°edí a na získávání dat pomocí protokolu SNMP. Za£átek práce je v¥nován dostupným protokol·m vhodným pro získávání dat, která jsou k rekonstrukci sít¥ pot°ebná. V pr·b¥hu práce je navrºena metoda zaloºená na analýze CAM tabulek, která dokáºe danou topologii rekostruovat. Na záv¥r je tato metoda implementována a otestována.
ix
x
Obsah 1 Úvod
1
2 Úvod do problematiky
3
2.1
Referen£ní ISO/OSI model . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Protokolová rodina TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.3
Rozdíly v mapování logické a fyzické topologie . . . . . . . . . . . . . . . . . .
4
2.4
Cíl projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3 Analýza 3.1
Protokoly pro správu sít¥ 3.1.1
3.1.2
3.2
7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The Simple Network Management Protokol
7
. . . . . . . . . . . . . . .
7
3.1.1.1
Úvod
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.1.1.2
Komunikace pomocí SNMP . . . . . . . . . . . . . . . . . . .
8
3.1.1.3
Formát zpráv SNMP . . . . . . . . . . . . . . . . . . . . . . .
8
3.1.1.4
Bezpe£nost protokolu SNMP
CMIP a CMOT ( CMIP over TCP/IP)
. . . . . . . . . . . . . . . . . .
13
. . . . . . . . . . . . . . . . .
14
3.1.2.1
CMIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.1.2.2
CMOT
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
Návrch °e²ení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4 Implementace
23
4.1
Výb¥r implementa£ního prost°edí . . . . . . . . . . . . . . . . . . . . . . . . .
23
4.2
Neobvyklé £ásti implementace . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.3
Net-snmp
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.4
Graphviz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
5 Testování
29
6 Záv¥r
33
Literatura
35
A Seznam pouºitých zkratek
37 xi
xii
OBSAH
B Instala£ní a uºivatelská p°íru£ka
39
B.1
Instalace programu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
B.2
Syntaxe kon gura£ního souboru . . . . . . . . . . . . . . . . . . . . . . . . . .
39
C Obsah p°iloºeného CD
41
Seznam obrázk· 2.1
Porovnání ISO/OSI modelu a TCP/IP . . . . . . . . . . . . . . . . . . . . . .
3.1
SNMPv1 formát paketu
3.2
Topologie sít¥ po provedení kroku 1-3
. . . . . . . . . . . . . . . . . . . . . .
20
3.3
Výsledná topologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.1
P°íklad jazyka DOT
27
5.1
Test bez koncových za°ízení
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.2
Test s koncovými za°ízeními . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vastní zpracování
xiii
5 10
xiv
SEZNAM OBRÁZK
Seznam tabulek 3.1
CMISE sluºby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.2
P°íklad £. 1 - tabulky CAM
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.3
P°íklad £. 2 - tabulky CAM
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
3.4
P°íklad £. 2 - upravené tabulky CAM . . . . . . . . . . . . . . . . . . . . . . .
20
B.1
CMISE sluºby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
xv
xvi
SEZNAM TABULEK
Kapitola 1
Úvod Historie po£íta£ových sítí sahá aº do 60. let 20. století a jiº v této dob¥ za£ínají první pokusy s propojením po£íta£·. Od té doby pro²ly po£íta£ové sít¥ sloºitým vývojem, aº do dne²ní podoby. Dnes zasahují do na²eho ºivota, a aniº si to v¥t²ina lidí uv¥domuje, stávají se jeho sou£ástí. V kaºdé v¥t²í rm¥ existuje po£íta£ová sí´, kterou zam¥stnanci vyuºívají k mezi remní komunikaci. Tyto sít¥ jsou sice p°ipojeny k internetu, ale nejv¥t²í p°enos dat probíhá prav¥ v rámci remní komunikace. Proto je kladen velký d·raz na jejich spolehlivost. Mnoho lidí si p°esto myslí, ºe po vybudování po£íta£ové sít¥ a jejím zprovozn¥ní práce administrátora kon£í. Opak je ale pravdou. Po£íta£ová sí´ je jako ºivý organizmus, který se neustále vyvíjí, a správce po£íta£ové sít¥ se o n¥j musí starat. Kaºdý správce by m¥l také znát její fyzickou topologii. V p°ípad¥, ºe správce po£íta£ové sít¥ ji i zárove¬ navrhoval, bude znát její fyzické propojení. Problém nastává, pokud ji nenavrhoval nebo v p°ípad¥, ºe si podrobn¥ nezdokumentoval v²echny zm¥ny, které v pr·b¥hu jeho p·sobení nastaly. V tento moment by bylo dobré, kdyby m¥l tento £lov¥k k dispozici nástroj, který mu bude schopen pomoci a alespo¬ £áste£n¥ mu nazna£it, jak je to v²echno propojené. Takové nástroje lze v¥t²inou získat od výrobc· sí´ových za°ízení, ale v¥t²ina t¥chto nástroj· bude limitována pouºitím v homogenním prost°edí. To znamená, ºe v²echny související za°ízení musí být od jednoho výrobce. Na poli open-source projekt· podobný nástroj chybí. A práv¥ to byl impuls k tomu, aby vznikla tato bakalá°ská práce, která by m¥la slouºit jako základ projektu, který bude um¥t rozpoznat topologii v heterogenním prost°edí. A práv¥ proto, ºe se jedná o opensource projekt, budu nadále uvaºovat, ºe se pohybujeme v prost°edí, které je ²í°eno v rámci licenci GNU/GPL. Jsem p°esv¥d£en, ºe mé úsilí tedy vyvinout nástroj na automatické rozpoznání topologie sít¥ v heterogenním prost°edí, m·ºe být v praxi efektivn¥ zuºitkováno, £emuº nasv¥d£uje i fakt, ºe jsem jiº na²el pro svou práci uplatn¥ní v konkrétní nejmenované
1
2
KAPITOLA 1. ÚVOD
rm¥. Práce je strukturována na teoretickou a praktickou £ást. Nejd°íve popí²i rozdíly mezi fyzickou a logickou topologií. Poté se budu v¥novat protokol·m, které jsou vhodné pro rekonstrukci sít¥ a podrobn¥ je zanalyzuji. Dále p°ejdu k vlastnímu výzkumu, který byl v této oblasti nezbytný a dokládá ho program na p°iloºeném CD. Nakonec bych se rád v¥noval praktickému uplatn¥ní topologie sít¥ v heterogenním prost°edí, protoºe práv¥ prakti£nost a vyuºitelnost povaºuji v dne²ním sv¥t¥ inovací za nejd·leºit¥j²í.
Kapitola 2
Úvod do problematiky 2.1 Referen£ní ISO/OSI model Referen£ní model ISO/OSI vypracovala organizace ISO jako hlavní £ást snahy o standardizaci po£íta£ových sítí nazvané OSI a v roce 1984 ho p°ijala jako mezinárodní normu ISO 7489. Úlohou referen£ního modelu je poskytnout základnu pro vypracování norem pro propojování systému. Norma nespeci kuje implementaci systém·, ale uvádí v²eobecné principy sedmivrstvé sí´ové architektury. Popisuje pouze jednotlivé vrstvy a jejich funkce. ISO/OSI model de nuje sedm následujících vrstev: 1.
Fyzická vrstva
- de nuje prost°edky pro p°enos jednotlivých bit·. Proud bit· m·ºe
být seskupen do kódových slov a p°eveden na fyzický signál, který je poslán na p°enosové médium. Fyzická vrstva poskytuje elektrické, mechanické a procedurální rozhraní pro p°enosové medium. De nuje tvar a vlastnosti elektrických konektor·, vysílací frekvence, modulaci signálu. 2.
Spojová vrstva - poskytuje funkce k p°enosu dat mezi jednotlivými sí´ovými jednotkami a detekuje, p°ípadn¥ opravuje chyby vzniklé na fyzické vrstv¥.
3.
Sí´ová vrstva
- poskytuje funkce k zaji²t¥ní p°enosu dat r·zné délky od zdroje k
p°íjemci skrze jednu p°ípadn¥ n¥kolik vzájemn¥ propojených sítí p°i zachování kvality sluºby, kterou poºaduje p°enosová vrstva. Sí´ová vrstva poskytuje sm¥rovací funkce a také reportuje o problémech p°i doru£ování dat. 4.
Transportní vrstva
- zaji²´uje p°enos dat mezi koncovými uzly. Jejím ú£elem je
poskytnout takovou kvalitu p°enosu, jakou poºadují vy²²í vrstvy. 5.
Rela£ní vrstva
- organizuje a synchronizuje dialog mezi spolupracujícími rela£ními
vrstvami obou systém· a °ídí vým¥nu dat mezi nimi. Umoº¬uje vytvo°ení a ukon£ení rela£ního spojení, synchronizaci a obnovení spojení, oznamovaní výjime£ných stav·.
3
4
KAPITOLA 2. ÚVOD DO PROBLEMATIKY
6.
Prezenta£ní vrstva
- transformuje data do tvaru, které pouºívají aplikace. Formát
dat (datové struktury) se m·ºe li²it na obou komunikujících systémech, navíc dochází k transformaci pro ú£el p°enosu dat niº²ími vrstvami. Vrstva se zabývá jen strukturou dat, ale ne jejich významem, který je znám jen vrstv¥ aplika£ní. 7.
Aplika£ní vrstva - poskytuje aplikacím p°ístup ke komunika£nímu systému a umoºnit tak jejich spolupráci.[4]
2.2 Protokolová rodina TCP/IP Model ISO/OSI byl vypracován jako v²eobecný návod pro implementaci sí´ové komunikace. Na proti tomu protokolová rodina TCP/IP je jiº p°ímá implementace tohoto modelu. Na rozdíl od ISO/OSI modelu je rozd¥lena pouze do £ty° vrstev. 1.
Linková vrstva
- je £asto popisována jako kombinace fyzické a spojové vrstvy. Pri-
márn¥ se stará o doru£ování rámc· mezi dv¥ma sousedními body. Je speci cká pro kaºdou sí´ v závislosti na implementaci, ale vzhledem k tomu, ºe fyzické mapovaní sít¥ budeme provád¥t pouze na lokálních sítích a ty jsou dnes z devadesáti procent realizovány pomocí technologie Ethernet. Budu proto v dal²ím textu uvaºovat, ºe se pohybujeme práv¥ na takto realizovaných sítích. 2.
Sí´ová vrstva - odpovídá t°etí vrstv¥ ISO/OSI modelu. Tato vrstva obsahuje skupinu metod a protokol· pot°ebných k doru£ení paket· od odesilatele k adresátovi. Odesilatel i adresát mají unikátní sí´ovou adresu (IP adresa).
3.
Transportní vrstva - je zodpov¥dná za zapouzd°ení blok· dat do datagram·, vhodných pro p°enos p°es sí´. Poskytuje spojov¥ orientovanou sluºbu (TCP) a nespojov¥ orientovanou sluºbu (UDP).
4.
Aplika£ní vrstva - poskytuje p°ímý p°ístup aplikací k sí´ové komunikaci.[2]
2.3 Rozdíly v mapování logické a fyzické topologie Pokud se na po£íta£ovou sí´ budeme dívat z pohledu 3. vrstvy, je to pohled na logické propojení jednotlivých segment·. To znamená, ºe tato topologie mívá velmi málo spole£ného se skute£ným fyzickým propojením jednotlivých £ástí. Chceme-li rekonstruovat sí´ na této vrstv¥, musíme najít v²echna za°ízení, která minimáln¥ s touto vrstvou pracují. Na²t¥stí nám auto°i protokolové rodiny TCP/IP dali do rukou dostate£n¥ mocné nástroje pro zmapování celé sít¥. Mezi n¥ pat°í ICMP a IGMP protokoly. Na v¥t²in¥ systém· jsou pak tyto protokoly
2.4. CÍL PROJEKTU
5
Obrázek 2.1: Porovnání ISO/OSI modelu a TCP/IP
implementovány (nap°. ping, traceroute). Díky tomu se stává mapování topologie na t°etí vrstv¥ jednoduchou úlohou. Pro mapování úplné fyzické topologie bychom m¥li zjistit propojení v²ech za°ízení na síti. To znamená, ºe bychom m¥li objevit a následn¥ zakreslit v²echny za°ízení, které pracují alespo¬ na první vrstv¥ ISO/OSI modelu. V reálném sv¥t¥ je v²ak n¥co takového nemoºné. Proto se musíme uchýlit k drobnému zjednodu²ení, posuneme ná² pohled o jednu vrstvu vý²e. Tímto posunutím se nám sice skryjí v²echny opakova£e, mosty, rozbo£ova£e a dal²í za°ízení pracující na první vrstv¥, ale na druhou stranu se v dne²ní dob¥ tyto za°ízení moc nepouºívají. V p°ípad¥, ºe se stále je²t¥ n¥kde pouºívají, musíme se smí°it s jistým zjednodu²ením námi rozpoznané topologie. Proto se p°i mapování fyzické topologie snaºíme zrekonstruovat propojení p°epína£· (za°ízení usm¥r¬ující tok rámc· na druhé vrstv¥), které se na dané síti vyskytují a jejich následné propojení s koncovými body. Mnou navrºená a pouºitá metoda je zaloºena na analýze dat, které nám p°epína£ m·ºe poskytnout. Tady p°icházejí na °adu protokoly, ur£ené pro správu sít¥ a sí´ových za°ízeních. Jak uº z jejich názvu vyplývá, primárn¥ mají slouºit ke spravování za°ízeních na síti, dokáºou v²ak také spoustu informací o konkrétním za°ízení získat, a proto se nechají vyuºít pro získávání dat, pot°ebných pro mapování topologie (V kapitole protokoly pro správu sít¥ porovnávám dva nej£ast¥ji implementované protokoly).
2.4 Cíl projektu Prvním cílem projektu je prozkoumat dostupné protokoly, kterými je moºno získat informace z p°epína£e. To není tak jednoduchý úkol, jak se m·ºe zdát, jelikoº kaºdý výrobce sí´ových za°ízení má tendenci vyvíjet vlastní proprietární protokol, který bude z uºivatelského hlediska co nejednodu²í na pouºití. Na druhou stranu nás v²ak bude nutit vyuºívat výrobky pouze od
6
KAPITOLA 2. ÚVOD DO PROBLEMATIKY
jednoho výrobce. Nutno uznat, ºe v¥t²ina správc· se rozhodne nej£ast¥ji pro jednoho výrobce a jeho za°ízení poté kupuje, ale nemusí to tak být vºdy. A proto je pot°eba po£ítat s tím, ºe se budeme pohybovat v heterogenním prost°edí. V následující kapitole se tedy rozepí²i a dvou obecn¥ de novaných protokolech, porovnám jejich klady a zápory a následn¥ si jeden z nich vyberu. Druhým cílem je navrhnout postup, který s vyuºitím vybraného protokolu bude schopný zrekonstruovat fyzickou topologii. A kone£n¥ t°etím cílem je navrhnutou metodu implementovat. P°i implementaci je také nutné vybrat programovací jazyk, který nám zajistí rychlý vývoj a zárove¬ nebude p°esp°íli² zat¥ºovat systém. Dále se budeme muset vyrovnat s problémy, které nám práce na reálných za°ízeních p°iná²í.
Kapitola 3
Analýza Tato kapitola je v první °ad¥ v¥novaná protokol·m pro správu sít¥, s nimiº je moºné získávat informace ze sí´ových za°ízení. Druhá £ást obsahuje vlastní návrch °e²ení projektu.
3.1 Protokoly pro správu sít¥ 3.1.1
The Simple Network Management Protokol
3.1.1.1 Úvod Protokol SNMP byl navrºen jako náhrada star²ího protokolu SGMP. Jedná se o ²iroce roz²í°ený protokol pro správu sítí. Komunikace v SNMP je zaloºena na modelu klient-server. SNMP je protokol aplika£ní vrstvy ISO/OSI modelu, a nej£ast¥ji se sním setkáme v protokolové rodin¥ TCP/IP, ale n¥která za°ízení podporují p°enos pomocí jiných protokol·(nap° IPX/SPX, DDP). SNMP de nuje dva typy za°ízení - manager a agent.
• SNMP Manager
- m·ºe být jednoduchý SNMP browser, který pouze stáhne data
z agenta, nebo m·ºe být sou£ástí NMS (Network Management System), a poskytovat mocné gra cké prost°edí.
• SNMP Agent
- je malý program b¥ºící na sí´ovém za°ízení (router, switch, tiskárna,
. . . ), který sbírá informace o b¥hu za°ízení a odpovídá na dotazy managera.
Za°ízení jsou monitorována pomocí SNMP p°íkaz· (read, write, trap, . . . ). P°kazy read a write probíhají synchronn¥, tj. manager po²le p°íkaz a agent na n¥j odpovídá. P°íkaz trap je asynchronní a agent ho odesílá bez p°edchozího vyºádání managerem, jako reakci na de novanou událost (vysoká teplota, link down, link up). Pro p°enos dat se pouºívají SNMP Protocol Data Units (PDUs), které jsou nej£ast¥ji zapouzd°eny v UDP datagramech. Pro jednozna£nou identi kaci objekt·, o které má manager od agenta zájem se pouºívá velmi
7
8
KAPITOLA 3. ANALÝZA
dob°e speci kovaná syntaxe jmen. Jméno objektu je v této syntaxi jednozna£n¥ de nováno objektovým identi kátorem (OID). Objekty identi kovány pomocí OID udrºuje agent v databázi MIB (Management Information Base). Kaºdé za°ízení, které implementuje SNMP musí o sob¥ poskytovat základní informace de novaná v RFC jako povinné.
3.1.1.2 Komunikace pomocí SNMP Komunikace probíhá pomocí SNMP PDU, které jsou zapouzd°eny v UDP paketech. Mezi agentem a konzolí jsou podporovány následující operace:
• get
- Vyºádání si informace od agenta o atributech speci kovaného objektu
• get-next
- To samé jako get, ale po zaslání odpov¥di p°echází na dal²í objekt. Tímto
zp·sobem lze projít celý MIB strom.
• set
- Nastavení hodnoty atributu speci kovanému objektu.
• trap
- Asynchronní zaslání informace agentem na p°edem speci kovanou adresu. [3]
3.1.1.3 Formát zpráv SNMP Protokol SNMPv1
1 byl prvn¥ p°ijat v roce 1988 jako sada dokument· speci kující protokol
a strukturu dat v MIB. Ta byla v roce 1991 nahrazena strukturou MIB-2 a jako taková je platná dodnes. V protokolu SNMPv1 byly speci kovány tyto druhy zpráv:
• get-request - Jde o poºadavek zasílaný agentovi. V poºadavku musí být speci kováno OID.
• get-next-request
- ádost o získání hodnoty prom¥nné objektu, bez p°esné znalosti
OID. V p°ípad¥ ºe není OID zadáno správn¥ agent odpoví nejbliº²ím vy²²ím OID. Takto lze projít celou strukturu MIB.
• set-request
- Tento typ zprávy nastavuje hodnotu prom¥nné v objektu a umoº¬uje
tak °ídit sí´ové za°ízení.
• get-response
- Na základ¥ poºadavk· p°ijatých ve zprávách get nebo set provede
za°ízení poºadovanou operaci a odpoví pomocí zprávy get-response. Zpráva obsahuje i p·vodní poºadavek takºe je zaji²t¥no párování zpráv.
• trap
- Tuto zprávu zasílá agent jako reakci na významnou událost (restart za°ízení,
p°etíºení za°ízení,). Tato zpráva není potvrzována. 1
Simple Network Management Protocol version 1
3.1. PROTOKOLY PRO SPRÁVU SÍT
Protokol SNMPv2
9
2 byl rozpracován v letech 1991-1993 a £áste£n¥ p°epracován v roce
1995. Vznik této verze protokolu byl poznamenán neshodami ve vývojové skupin¥ ohledn¥ zabezpe£ení protokolu. Ob¥ verze pak doplnily zprávy:
• get-bulk-request
- Tato zpráva funguje podobn¥ jako get-next-request, av²ak umoº-
¬uje vyºádat si celou skupinu informací £ímº se komunikace výrazn¥ urychluje.
• inform
- Tato zpráva slouºí k vým¥n¥ informací mezi managery.
Ve verzi SNMPv3
3 jiº nejsou de novány ºádné nové typy zpráv.
Verzi SNMPv1 byla zaji²t¥na atomicita operací set a get. Od verze SNMPv2 byl poºadavek atomicity zru²en. Tedy v p°ípad¥, kdy není moºno z n¥jakého d·vodu zpracovat v²echny poºadavky, jsou zpracovány jen ty, u kterých to moºné je, a výsledek odeslán. V p°ípad¥ SNMPv1 dochází ke zpracování celého poºadavku nebo ni£eho. Formát PDU v SNMPv1 se d¥lí na dv¥ £ásti - hlavi£ku a t¥lo zprávy. Pro PDU typu getrequest, set-request, get-next-request, get-response, mají jednotlivé £ásti následující podobu:
PDU hlavi£ka • verze - Ur£uje verzi protokolu pro zaji²t¥ní kompatibility. Velikost je 4 byty a ve verzi SNMPv1 má hodnotu 0.
• skupina
- Ur£uje skupinu, ve které je odesílat a p°íjemce. Jedná se o základní auten-
tizaci, kterou SNMP nabízí.
PDU t¥lo • PDU type
- ur£uje typ PDU (0 - get-request,1 - get-next-request,2 - get-response ,3
- set-request).
• Request ID
- unikátní £íslo slouºící pro párování poºadavku a odpov¥di.
• Error Status
- pole pouºívané v get-response PDU k oznámení, ºe do²lo k chyb¥(V
PDU typu request vºdy rovno 0).
• Error Index - v p°ípad¥, ºe do²lo k chyb¥ toto pole obsahuje ukazatel na objekt, který zp·sobil chybu (V PDU typu request vºdy rovno 0).
• Variable Bindings - mnoºina dvojic jméno-hodnota identi kující MIB objekt. V p°ípad¥, ºe se jedná o set-request-PDU nebo get-response-PDU obsahuje jejich hodnotu.
10
KAPITOLA 3. ANALÝZA
SNMP Message (Sequence) SNMP SNMP Community Version String (Integer) (Octet String)
Request ID (Integer)
Error Error Index (Integer) (Integer)
SNMP PDU (GetRequest, SetRequest, atd.) VarbindList (Sequence) Varbind (Sequence) Object Identifier (OID)
Value (Integer, Octet String, atd.)
Obrázek 3.1: SNMPv1 formát paketu
Zpráva trap má hlavi£ku shodnou jako p°edchozí PDU. T¥lo obsahuje následující poloºky:
• PDU type
- Schodné s p°edchozími rámci.
• Enterprise
- Identi kátor skupiny, která ur£uje typ objektu odesílající trap.
• Agent Address
- IP adresa agenta, který odesílá trap. IP adresa je známa ze sí´ové
vrstvy, av²ak tento údaj výrazn¥ usnad¬uje logování.
• Generic Trap
- Hodnota speci kující jeden z mnoha p°edde novaných obecných
druh· trapu.
• Speci c Trap
- Hodnota ur£ující speci cký druh trapu (závisí na implementaci).
• Time Stamp - Mnoºství £asu, které uplynulo od doby, kdy byl objekt odesílající trap, inicializován.
• Variable Bindings
- Schodné s p°edchozími rámci.
Jak jsem jiº zmi¬oval vý²e vznik SNMPv2 byl poznamenán neschopností vývojové skupiny domluvit se na zp·sobu zabezpe£ení protokolu. Coº v d·sledku vedlo ke vzniku dvou verzí protokolu ozna£ovaných jako SNMPv2c a SNMPv2u (). SNMPv2c p°evzala zabezpe£ení od svého p°edch·dce zaloºenou na tzv. community stringu, který ur£uje zda má £len dané skupiny právo na p°ístup k daným informacím. Toto heslo není nijak ²ifrováno, a proto m·ºe dojít ke snadnému odposlechu. Verze SNMPv2u (user-based) umoº¬uje ov¥°ení integrity a pravosti zpráv. Více se o moºnostech zabezpe£ení v kapitole Security. Ob¥ verze schodn¥ implementují nový formát zprávy get-bulk-request, který výrazn¥ urychluje získávání dat od agenta. Podoba hlavi£ky v této zprávy se odvíjí od pouºité verze protokolu. V p°ípad¥ SNMPv2u do²lo z bezpe£nostních d·vod· k významným zm¥nám v hlavi£ce, která nyní obsahuje tyto poloºky: 2 3
Simple Network Management Protocol version 2 Simple Network Management Protocol version 3
3.1. PROTOKOLY PRO SPRÁVU SÍT
• Version
11
- Ur£uje verzi protokolu pro zaji²t¥ní kompatibility. Ve verzi SNMPv2c má
hodnotu 2.
• Model number
- Nastaveno na 1 pro identi kaci User-based zabezpe£ení.
• Quality of Service - Indikuje jestli je zapnuta kontrola integrity a/nebo autenti kace. • Agent Identi er
- Identi kace agenta odesílajícího zprávu. Zabra¬uje útok·m zalo-
ºeným na opakování odposlechnutých paket·.
• Agent Number of Boots
- Po£et start·/restart· agenta od doby nastavení Agent
ID.
• Agent Time Since Last Boot • Maximum Message Size
- Doba od posledního startu agenta.
- Maximální velikost zprávy, jakou m·ºe odesílatel této
zprávy p°ijmout.
• User Lenght • User Name
- Délka pole User Name.
- Jméno uºivatele, který odesílá zprávu.
• Authentication Digest Lenght • Authentication Digest
- Délka pole Authentication Digest.
- Pole zaji²´ující pravost zprávy v p°ípad¥, ºe je pouºita
autenti kace. (Digest)
• Context Selector
- et¥zec zaji²´ující kontext zprávy.
V p°ípad¥ SNMPv2c nedo²lo k ºádným zm¥nám oproti první verzi protokolu. V hlavi£ce zprávy má pak poloºka verze hodnotu 1. T¥lo PDU get-bulk-request má de novány následující poloºky:
• PDU type
- Schodné jako v p°ípad¥ SNMPv1.
• Request ID
- Schodné jako v p°ípad¥ SNMPv1.
• Variable Bindigs
- Schodné jako v p°ípad¥ SNMPv1.
Ke konci devadesátých let se za£alo pracovat na verzi SNMPv3, která m¥la vy°e²it problémy spojené s existencí více verzí SNMPv2. Návrh SNMPv3 vyuºíval mnoho £ástí které byly vytvo°eny pro protokol SNMPv2, v£etn¥ typ· PDU a jejich formátu. Hlavní formát zprávy v SNMPv3 zachovává ideu zapouzd°ení zprávy do wraperu, který obsahuje hlavi£ku a zapouzd°ené PDU. Nicmén¥ tento koncept je ve verzi 3 dále vylep²en.
12
KAPITOLA 3. ANALÝZA
Hlavi£ka byla rozd¥lena na pole, která se starají o zabezpe£ení, a na v²eobecné poloºky. V²eobecné poloºky jsou stejné ve v²ech implementacích SNMPv3, poloºky mající na starost zabezpe£ení mohou být upraveny podle SNMPv3 bezpe£nostního modelu, a zpracovány modulem, který má na starost zabezpe£ení. Toto °e²ení p°iná²í zna£nou exibilitu, která zabra¬uje problém·m, jeº m¥l SNMPv2. Celkový formát SNMPv3 (obrázek XXX) zprávy je popsán v RFC 3412, popisujíc odesílání a zpracování zpráv ve verzi 3. Význam jednotlivých poloºek je následující.
• Message Version • Message ID
- Verze SNMP zprávy. Pro SNMPv3 je hodnota 3.
- íslo pouºívané k párování poºadavk· a odpov¥dí. Pouºití tohoto pole
je podobné jako u Request ID. Toto pole bylo vytvo°eno pro srovnávání nezávisle na obsahu PDU, coº brání n¥kterým druh·m útok·.
• Maximum Message Size
- Maximální velikost zprávy, kterou muºe odesílatel této
zprávy p°ijmout. Minimální velikost je 484.
• Message Flags
- P°íznaky, které kontrolují zpracovávání zprávy. Sou£asná podstruk-
tura vypadá takto:
Reserved - Rezervované pole pro moºné budoucí pouºití. Reportable Flag
- V p°ípad¥, ºe je nastaveno na 1, za°ízení, které tuto zprávu
obdrºelo, musí odeslat Report-PDU, kdykoli podmínky p°estoupí mez v dob¥ p°ijetí zprávy.
Privacy Flag
- Kdyº je nastaven bit na 1 znamená to, ºe ²ifrování bylo pou-
ºito pro chrán¥ní soukromí zprávy. Tento bit nem·ºe být nastaven, jestliºe není nastaven Authentication bit.
Authentication Flag - Ur£uje, zda-li byla pouºita autenti kace k chrán¥ní pravosti zprávy.
• Message Security Model
- Hodnota ur£ující jaký bezpe£ností vzor byl pouºit. Vý-
chozí hodnota SNMPv3 je 3 (user-based).
• Message Security Parameters - Skupina poloºek obsahující parametry vyºadované k realizování jednotlivých bezpe£nostních vzor·. Obsah tohoto pole je popsán v kaºdém dokumentu popisující SNMPv3 security model. Nap°íklad parametry popisující userbased model jsou popsány v RFC 3414.
3.1. PROTOKOLY PRO SPRÁVU SÍT
• Scoped PDU
13
- Obsahuje p°ená²ené PDU spole£n¥ s parametry, které ur£ují SNMP
kontext. Struktura poloºky je následující:
Context Engine ID - Ur£uje ke které aplikaci bude PDU odesláno ke zpracování. Context Name - OID ur£ující p°esný kontext spojený s tímto PDU. PDU - Protocol Data Unit.[5] 3.1.1.4 Bezpe£nost protokolu SNMP Zabezpe£ení SNMPv1
Zabezpe£ení verze 1 je velmi omezené. Zavádí pouze jeden zp·sob
zabezpe£ení.
• Slabé objekty
- SNMP bylo vytvo°eno s my²lenkou, ºe v²echny MIB objekty vyu-
ºívané protokolem budou relativn¥ slabé. To znamená, ºe objekty jsou navrºeny tak, aby chyby vzniklé manipulací s t¥mito objekty m¥ly minimální dopad na systém. Zásada designér· SNMP byla taková, ºe MIB objekty, které je moºno normáln¥ £íst (tzv. read-only), neobsahují ºádné kritické informace. Objekty, do kterých se nechá zapisovat (tzv. read-write), neovládají ºádné kritické funkce. Proto, read-only MIB objekt, který obsahuje popis stroje, je v po°ádku, ale objekt, který obsahuje administrátorské heslo, v po°ádku není. Podobné to je u read-write objekt·. Ten, který ovládá, kdy se za°ízení p°í²t¥ restartuje, je p°ijatelný, ale ten, který °ídí formátování disku, v po°ádku není.
• Community string
- P°edstavme si velkou sí´, která obsahuje mnoho SNMP za°ízení
a alespo¬ dva NMS. Aby se SNMP pakety mezi sebou nemíchaly, m·ºeme sí´ rozd¥lit na dv¥ £ásti - takzvané komunity. Kaºdé za°ízení, které obdrºí zprávu nejd°íve zkontroluje, zda-li souhlasí jeho komunita s komunitou uvedenou v paketu. Pokud ano, je zpracován zbytek zprávy a výsledek odeslán. Kdyº spolu nesouhlasí, paket je zni£en. Lze ji tedy povaºovat za jakousi obdobu hesla. Komunita je obsaºena v hlavi£ce zprávy, v poli s názvem community string. SNMPv1 neobsahuje ºádné ²ifrování, proto p°i odchycení paketu snadno získáme community string.
Tyto bezpe£nostní vlastnosti jsou lep²í neº nic, ale ne o mnoho. Pouºití slabých objekt· je p°irovnatelné k pravidlu - nenechávejte va²e auto p°ed obchodem odem£ené a s klí£ky v zapalování. Pouºitím comunity stringu je stejné jako, kdyº va²e auto p°ed obchodem zamknete - to vás ochrání proti náhodným zlod¥j·m, ale trochu schopn¥j²í zlod¥j ho stejn¥ ukradne. To byl jeden z d·vod·, pro£ za£ala vznikat druhá verze protokolu SNMP.
14
KAPITOLA 3. ANALÝZA
Zabezpe£ení SNMPv2 a SNMPv3
Jak jsem jiº psal vý²e, protokol SNMPv2 nedopadl
podle p°edstav jeho tv·rc·. Neschopnost pracovní skupiny dohodnout se na moºnostech zabezpe£ení m¥la za následek vznik dvou podverzí protokolu SNMPv2. První verze pouºívá stejné zabezpe£ení, jako SNMPv1. Tato podverze je de nována v RFC 1901 - RFC 1908. O ciáln¥ jsou tyto dokumenty pouze ve fázi návrhu standardu, ale SNMPv2c je de facto povaºován za standard, který je implementován ve v¥t²in¥ za°ízení. SNMPv2u vyuºíval novou metodu zabezpe£ení nazývanou User-based Security Model (USM). ást tohoto návrhu byla implementována jako komer£ní verze SNMP v²eobecn¥ nazývanou jako SNMPv2*. Verze SNMPv3 vyuºívá autentizaci zaloºenou na USM a zárove¬ zavádí svojí vlastní metodu nazývanou View-based Access Control Model (VACM). V²echny metody zabezpe£ení nyní popí²i podrobn¥. Party-based Security Model - P·vodní návrh bezpe£nostního vzoru pro SNMPv2, nyní nazýván SNMPv2p. Logická jednotka nazývaná party ur£uje autenti ka£ní a ²ifrovací protokol, který se pouºije. Informace je pouºita k ov¥°ení, ºe poºadavek není zfal²ovaný, a k ov¥°ení, ºe odesílatel i p°íjemce se shodují na metod¥, jak za²ifrovat i roz²ifrovat data. User-based Security Model - Hlavní idea spo£ívá v odklon¥ní od svazování bezpe£nosti se za°ízením a místo toho vyuºít tradi£n¥j²í metodu zaloºenou na p°ístupových právech uºivatel·. Metoda je zaloºena na £asových známkách, synchronizaci £asu k zabrán¥ní n¥kterých typ· útok·. View-based Access Control Model - Pohled (view) ur£uje konkretní mnoºinu MIB objekt·, které jsou p°ístupné konkrétní skupinou v konkrétním kontextu. Kontrolováním t¥chto pohled· m·ºe administrátor snadno °ídit, kým je která informace p°ístupná. SNMPv3 poskytuje velmi dobré moºnosti zabezpe£ení p°enosu zpráv, ale bohuºel mezi nejroz²í°en¥j²í verze SNMP stále pat°í SNMPv1 a SNMPv2c. A práv¥ to je hlavní d·vod, pro£ jsem se i já rozhodl práv¥ pro verzi SNMPv1.
3.1.2
CMIP a CMOT ( CMIP over TCP/IP)
3.1.2.1 CMIP CMIP je protokol pro správu sítí, který poskytuje implementaci sluºeb de novaných v CMIS (Common Management Infomation Service). Stejn¥ jako v SNMP i v tomto protokolu jsou dva typy aplikací manager a agent a jejich význam je stejný jako u SNMP. CMIP nede nuje sm¥r p°enosu dat ani za°ízení, které otev°e nebo zav°e spojení. Proto jsou mechanismy komunikace mezi agentem a managerem zcela symetrické. V¥t²ina za°ízení obsahuje aplikace, které mohou mít pouze roli agenta. Av²ak existují i aplikace, které mohou mít ob¥ role. V tomto p°ípad¥ m·ºeme pouºít jednoho managera pro správu jiného managera. Tento p°ístup je velmi rozdílný od zp·sobu, který uºívá SNMP. V SNMP máme vºdy jasnou
3.1. PROTOKOLY PRO SPRÁVU SÍT
15
roli managera i agenta a komunikace za£íná, aº na výjimky, vºdy na stran¥ managera (jedinou výjimkou je SNMP trap).
P°ístup k informacím ve spravovaných objektech je realizován pomocí CMISE (Common Management Information Service Element). CMISE vyuºívá CMIP k vydání poºadavku pro spravovanou sluºbu. Sluºby poskytované CMIP/CMISE jsou organizovány do dvou skupin: CMIP je ve své podstat¥ soubor následujících aplika£ních protokol·, které realizují samotnou správu sít¥.
• ACSE
- Association Control Service Element
• ROSE
- Remote Operation Service Element
• CMIS
- Common Management Information Service Element
ACSE
ASCE je pouºíván k zaloºení a uvoln¥ní spojení mezi aplika£ními entitami. P°ed-
tím, neº je provedena jakákoliv operace, je nezbytné, aby aplikace mezi sebou vytvo°ily spojení. Nezáleºí na tom, jestli zaloºení spojení zahájí manager nebo agent. ACSE dovoluje managerovi a agentovi, aby si aplika£ní entity vym¥nily mezi sebou svoje názvy k usnadn¥ní identi kaci, dále umoº¬uje vým¥nu kontextových jmen pro nastavení kontextu aplikace. Aplika£ní kontext de nuje, které sluºby mohou být pouºity v rámci spojení. Poté, co je zaloºeno spojení, ACSE není pouºíváno, aº do doby, neº manager nebo agent spojení zru²í.
ROSE
ROSE je ISO ekvivalent pro RPC(poznámka pod £arou). Managerovi umoº¬uje
spou²t¥ní proces· na vzdálených systémech. ROSE obsahuje identi kátor pro korelaci ºádostí a odpov¥dí, £íslo procesu a pole pro argumenty, které m·ºe obsahovat parametry pro spou²t¥ný proces. CMIP pouºívá spojov¥ orientované spojení poskytované protokolem ROSE pro v²echny jeho poºadavky a odpov¥di. Zárove¬ m·ºe být protokol ROSE vyuºit pouze jednou vzhledem k navázanému spojení.
CMISE
Vyuºívá obou p°edchozích protokol·, ROSE i ACSE. Poskytuje potvrzovanou i
nepotvrzovanou sluºbu pro hlá²ení událostí, získávání a manipulování s daty. CMISE slouºí managerovi a agentovi k vým¥n¥ informací, a umoº¬uje mnohonásobnou odpov¥¤ na jediný poºadavek. Tabulka 3.1 ukazuje sluºby, které jsou v CMISE dostupné.
16
KAPITOLA 3. ANALÝZA
Sluºba
Typ
M-INITIALISE
potvrzovaná
M-TERMINATE
potvrzovaná
M-ABORT
nepotvrzovaná
M-EVENT-REPORT
potvrzovaná / nepotvrzovaná
M-GET
potvrzovaná
M-SET
potvrzovaná / nepotvrzovaná
M-ACTION
potvrzovaná / nepotvrzovaná
M-CREATE
potvrzovaná
M-DELETE
potvrzovaná
Tabulka 3.1: CMISE sluºby
3.1.2.2 CMOT Jak jsem psal vý²e CMIP není protokolem v pravém slova smyslu pouze de nuje strukturu pouºití jiných protokol· aplika£ní vrstvy k °ízení a spravování sí´ových za°ízení. Tento koncept umoº¬uje snadnou vým¥nu niº²ích protokol· za jiné. Toto vlastnost si uv¥domili U. Warrier z Unisys Corporation a L. Besaw z HP a sepsali RFC 1095 v n¥mº de nují vyuºití CMIP na sítích vyuºívající protokolovou rodinu TCP/IP[6].
LPP
P°i implementaci CMIP na sít¥ TCP/IP vznikne na úrovni prezenta£ní vrstvy mezera,
kterou bylo t°eba vyplnit. Auto°i m¥li dv¥ moºnosti. Bu¤ pouºijí £ást ISO protokol· zapouzd°ených do paket· TCP/IP. Hlavní nevýhodou tohoto °e²ení je nutnost plné implementace ISO prezenta£ní, rela£ní transportní vrstvy, coº je implementa£n¥ nákladné, a to jak £asov¥ tak pam¥´ov¥. Druhý postup je podrobn¥ popsán v RFC 1085. Protokoly pro správu sít¥ (ACSE, ROSE, CMISE) nepot°ebují plnou implementaci sluºeb ISO prezenta£ní vrstvy, proto se naskytuje moºnost de novat redukovanou prezenta£ní vrstvu, která poskytuje pouze poºadované sluºby. Odtud pochází název Lightweight Presentation Protocol (LPP). Tento postup eliminuje nutnost implementovat ISO prezenta£ní, rela£ní a transportní protokoly. Tento postup umoº¬uje snadné a kompaktní °e²ení problému. Výsledná CMOT rodina protokol· je na obrázku.
3.2 Návrch °e²ení Nyní bychom m¥li probrat teoretické moºnosti a navrhnout funk£ní °e²ení problému. Já jsem se ve své práci rozhodl jít cestou analýzy dat získaných z p°epína£e. Tato data nejsou nic
3.2. NÁVRCH EENÍ
jiného neº CAM
17
4 tabulky jednotlivých p°epína£·. Z t¥chto tabulek máme moºnost zjistit,
které fyzické adresy jsou p°ipojeny ke kterému portu p°epína£e. V p°edchozí kapitole jsem popsal dva nejroz²í°en¥j²í protokoly pro správu sí´ových za°ízení, které se dají vyuºít i pro získávání CAM tabulek z p°epína£·. Rozhodnutí ohledn¥ výb¥ru protokolu je d·leºité ud¥lat je²t¥ p°ed implementací, protoºe musíme zjistit, jaké moºnosti má daný protokol a jaká nám klade omezení ohledn¥ získávaných dat. Po zralé úvaze jsem se rozhodl pro protokol SNMP. Jeho nejv¥t²í výhodou je roz²í°enost a jednoduchost, a a£koliv CMOT v mnohých v¥cech protokol SNMP, jako jeho nástupce, p°ed£í, jeho nejv¥t²í nevýhodou z·stává, ºe dnes je implementován vet²inou v za°ízeních ur£ených pro sektor telekomunikací. Nyní se zam¥°me na to, jak pomocí SNMP získat pot°ebné údaje. Prvním a nejd·leºit¥j²ím krokem je CAM tabulka. Data z CAM jsou p°ístupná pod OID: 1.3.6.1.2.1.17.4.3.1. Tato poloºka obsahuje dal²í t°i poloºky. První je MAC. Druhou poloºkou je
dot1dTpFdbAddress, v níº je uloºen seznam
dot1dTpFdbPort, v níº
p°edchozí adresy, a poslední poloºkou je
se nachází seznam port·, na kterých jsou
dot1dTpFdbStatus
v níº je uloºen stav, ve kterém
se p°edchozí informace nachází. Stav m·ºe nabývat následujících hodnot:
• other
- ºádné z následujících
• invalid
- jiº nepouºívaná poloºka, tomuto stavu p°edcházel stav learned
• learned • self
- aktivní poloºka vyuºívána pro p°epínání
- ukazuje, ºe poloºka z
dot1dTpFdbAddress
reprezentuje samotnou adresu p°epí-
5 na£e
• mgmt
- v p°ípad¥, kdy poloºka z
dot1dTpFdbAddress
a zárove¬ je tato poloºka uvedena v sekci
reprezentuje adresu p°epína£e
dot1dStaticAddress6
Spojení je zaji²t¥no pomocí OID, kdy se k základnímu OID p°ipojí dekadický tvar uchovávané MAC adresy. V praxi to vypadá tak, ºe k OID poloºky
dot1dTpFdbAddress p°ipojíme
dekadický tvar MAC adresy, kterou tato poloºka uchovává. Pokud chceme zjistit port, na kterém je námi zvolená MAC, vezmeme OID tvar námi zvolené MAC adresy. S poloºkou
dot1dTpFdbPort a k n¥mu p°ipojíme dekadický
dot1dTpFdbStatus
postupuje stejn¥.
Jednotlivé poloºky tedy mohou mít následující tvar:
Content Addressable Memory je asociativní pole ve kterém si p°epína£ uchovává informace na kterém portu má která za°ízení. 5 V tomto p°ípad¥ je na p°epína£i smy£ka. 6 dot1dStaticAddress ur£uje adresy ze kterých je moºno p°epína£ spravovat. 4
18
KAPITOLA 3. ANALÝZA
• .1.3.6.1.2.1.17.4.3.1.1.0.15.226.7.242.224 - 00:0F:E2:07:F2:E0 • .1.3.6.1.2.1.17.4.3.1.2.0.15.226.7.242.224 - 23 • .1.3.6.1.2.1.17.4.3.1.3.0.15.226.7.242.224 - 3 Dal²í, co budeme pot°ebovat, je MAC adresa samotných p°epína£·. Podle ní totiº budeme moci rozli²it, zda-li je za°ízení nalezené v CAM tabulce p°epína£em nebo koncovým bodem. Tyto informace se nacházejí v poloºce
ifPhysAddress
s OID
1.3.6.1.2.1.2.2.1.6.
Nyní tedy víme, jaké adresy p°epína£ pouºívá a jaké ne, a zárove¬ m·ºeme rozli²it p°epína£e od koncových za°ízení. Na základ¥ t¥chto dat jsme jiº schopni za£ít rekonstruovat sí´ovou topologii. Je²t¥ neº se pustíme do rekonstrukce musíme si °íci, za jakých podmínek m·ºeme za°ízení do topologie za°adit. Já ve své analýze a pozd¥ji i v implementaci za°azuji do topologie pouze za°ízení, která jsou práv¥ na jednom portu daného p°epína£e. Pop°ípad¥ za°azuji za°ízení, která sice jsou na více portech, ale jedním z t¥chto za°ízení je p°epína£. V²echny ostatní p°ípady se mi jeví jako nejednozna£ná °e²ení, a proto je dále neuvaºuji. M¥jme tedy k dispozici následující CAM tabulky.
P°epína£ £. 1 port MAC adresa
P°epína£ £. 2 port MAC adresa
P°epína£ £. 3 port MAC adresa
1
PC-1
1
PC-3
1
PC-5
2
PC-2
2
PC-4
2
PC-6
3
PC-5
3
PC-5
3
P°epína£ £. 1
3
PC-6
3
PC-6
4
P°epína£ £. 2
3
PC-7
4
PC-7
Tabulka 3.2: P°íklad £. 1 - tabulky CAM
Z tabulek je vid¥t, ºe nejzajímav¥j²í informace má pro nás p°epína£ £íslo 3. Krom¥ po£íta£· PC-5 a PC-6 m·ºeme prohlásit za jeho sousedy i p°epína£e 1 a 2. U zbývajících dvou p°epína£· prohlásíme za sousedy pouze ty po£íta£e, které mohou být za°azeny jednozna£n¥ ke konkrétnímu portu p°epína£e. V²echna ostatní data jsou nejednozna£ná, a proto je budeme ignorovat. Na stejném principu fungovala i testovací verze v jazyce Perl, kterou jsem napsal v únoru 2009. Vzhledem k tomu, ºe v testovacím prost°edí dosahovala dobrých výsledk·, rozhodl jsem se tuto metodu pouºít i v ostré verzi, která v²ak m¥la být p°epsána do jazyka Python. P°i dokon£ovacích pracích na nální verzi jsem ale p°i²el na to, ºe jsem se dopustil závaºných chyb. Tyto chyby by mohly zp·sobit nefunk£nost na n¥kterých typech sítí, respektive p°i speci ckém nastavení p°epína£· v mapované síti. Proto jsem se rozhodl celý systém p°epracovat do dne²ní podoby.
3.2. NÁVRCH EENÍ
19
Chyba v p°edchozím postupu byla v tom, ºe pokud na p°epína£ích nebyl povolen n¥jaký
7
typ NDP , tak potom jsem nebyl schopen zjistit propojení t¥chto p°epína£·. V novém návrhu jsem tedy byl nucen uvaºovat práv¥ tuto moºnost. Pokud tedy budeme uvaºovat moºnost, ºe CAM tabulky jednotlivých p°epína£· obsahují pouze informace o koncových za°ízeních, situace se nám zkomplikuje. Následující postup tedy bude sloºit¥j²í.
1. Se°a¤ CAM tabulky v²ech p°epína£· podle £ísel port·. 2. Projdi CAM tabulku p°epína£e. MAC adresu, která je práv¥ na jednom portu za°a¤ mezi sousedy p°epína£e, a z CAM ji odeber. Zárove¬ si port, na kterém jsi MAC na²el, ozna£ jako obsazený. 3. Krok 2 opakuj pro v²echny p°epína£e. 4. Vezmi prvek z CAM tabulky p°epína£e a pokus se ho najít mezi sousedy ostatních p°epína£·. (a) Pokud jsi ho nenalezl, vra´ se ke kroku 4. (b) Pokud jsi ho nalezl, zapamatuj si, u jakého p°epína£e jsi ho na²el. (c) Vezmi dal²í prvek z CAM tabulky p°epína£e a najdi jej mezi sousedy p°epína£e z kroku b. i. Pokud jej nalezne², m·ºe² prohlásit p°epína£e za sousedy a ozna£it daný port za obsazený. ii. Pokud jej nenalezne², vra´ se ke kroku 4. 5. Krok 4 opakuj pro v²echny p°epína£e
Slovní popis vypadá na první pohled dosti sloºit¥, proto jej nyní rozeberu na p°íklad¥. Pro názornost pouºiji stejný p°íklad, jako v p°edchozím bod¥ s tím rozdílem, ºe nebudeme mít k dispozici data z NDP. M¥jme tedy k dispozici následující informace.
Tabulky jsou shodné s p°edchozím p°íkladem, aº na údaj o sousednosti p°epína£·. Nyní m·ºeme vyzkou²et, jestli nov¥ navrºená metoda bude fungovat. Kroky 1 - 3 jsou shodné s
8 Z tabulek jsme si odstranili v²echny jednozna£né údaje a k jednot-
p°edchozím p°íkladem.
livým p°epína£·m p°i°adili jejich sousedy. Po t¥chto krocích vypadají CAM tabulky následovn¥: 7 Neighbor Discovery Protocol - zde nemám na mysli NDP de nován v RFC 4861, ale pouºívám zkratku jako obecného zástupce mnoha proprietární protokol· nap°. (CDP, NDP, LLTD, ...) 8 Tam jsme ov²em postup nem¥li rozd¥len do jednotlivých krok·.
20
KAPITOLA 3. ANALÝZA
P°epína£ £. 1 port MAC adresa
P°epína£ £. 2 port MAC adresa
P°epína£ £. 3 port MAC adresa
1
PC-1
1
PC-3
1
PC-5
2
PC-2
2
PC-4
2
PC-6
3
PC-5
3
PC-5
3
PC-6
3
PC-6
Tabulka 3.3: P°íklad £. 2 - tabulky CAM
P°epína£ £. 1 port MAC adresa
P°epína£ £. 2 port MAC adresa
3
PC-5
3
PC-5
3
PC-6
3
PC-6
P°epína£ £. 3 port MAC adresa
Tabulka 3.4: P°íklad £. 2 - upravené tabulky CAM
Prozatímní nalezená topologie je vid¥t na obrázku 3.2.
Obrázek 3.2: Topologie sít¥ po provedení kroku 1-3
Nyní m·ºeme p°ejít ke kroku 4. Vezmeme první prvek z tabulky p°epína£e £. 1 a hledáme ho v tabulce soused· ostatních p°epína£·.
9 Nalezli jsme ho v tabulce p°epína£e £. 3, a tak
m·ºeme pokra£ovat dal²ím krokem. Vezmeme tedy dal²í poloºku z tabulky p°epína£e £. 1 a hledáme ji ve stejné struktu°e soused· jako p°edchozí prvek. Protoºe na²e hledání bylo úsp¥²né, m·ºeme oba p°epína£e prohlásit za sousedy. Takto pokra£ujeme pro v²echny zbylé údaje. Výslednou topologii m·ºeme vid¥t na obrázku 3.3. Tímto postupem jsme byli schopni zrekonstruovat celé propojení i bez znalosti p°ímého propojení p°epína£·. Coº je nejv¥t²í p°ínos tohoto postupu.
9
Tabulka soused· je reprezentována obrázkem 3.2
3.2. NÁVRCH EENÍ
21
Obrázek 3.3: Výsledná topologie
22
KAPITOLA 3. ANALÝZA
Kapitola 4
Implementace Kapitola ukazuje, na jakých nástrojích a v jakém jazyce byla provedena implementace. Dále popisuje neobvyklá °e²ení n¥kterých problém· a externí programy, které v sou£asnosti vyuºívám.
4.1 Výb¥r implementa£ního prost°edí První otázkou, kterou si kaºdý na za£átku poloºí, je, v jakém jazyce budeme daný problém implementovat. N¥kdy je odpov¥¤ jednoduchá, protoºe nás okolnosti tla£í k vyuºití práv¥ jednoho jazyka. Já jsem ºádnými okolnostmi tla£en nebyl, a tak jsem si pohrával s my²lenkou výb¥ru vhodného jazyka velmi dlouho. První testy, které jsem provád¥l nad p°epína£i byly psány BASHi. Tento nástroj jsem v²ak od za£átku nepovaºoval za vhodný, p°edev²ím proto, ºe slouºil hlavn¥ jako nástroj pro seznámení s prost°edím a daty, které nám p°epína£e pomocí SNMP poskytují. Druhým v po°adí byl jiº vý²e zmín¥ný PERL. Po napsání první testovací verze jsem jej v²ak ze svých úvah musel vylou£it (hlavním d·vodem byla vysoká nep°ehlednost kódu). Nakonec jsem se rozhodl pro jazyk Python konkrétn¥ pro verzi 2.5. Jazyk Python byl vytvo°en pro rychlý a snadný vývoj vysoko úrov¬ových aplikací (jedná se o jazyk interpretovaný), na rozdíl v²ak od jiných interpretovaných jazyk· se vyzna£uje zna£nou rychlostí. [1] Jeho dal²í velkou p°edností je úzká vazba na jazyk C. V pythonu proto není problém napsat program, provést analýzu jeho rychlosti a p°ípadné pomalé úseky implementovat pomocí jazyka C a vloºit tyto úseky zp¥t do pythonovského programu. Tímto postupem se celý program rapidn¥ zrychlí bez nutnosti p°epsání celého kódu. Tyto vlastnosti nakonec ud¥lali z jazyka Python mého favorita. Jako implementa£ní prost°edí jsem zvolil prost°edí Eclipse a dopln¥k pro jazyk Python Pydev. Cílový program je ur£en pro b¥h v prost°edí GNU/Linux (zejména distribuce Debian), a proto se v implementaci opírám o n¥které snadno dostupné externí programy, jakým
23
24
KAPITOLA 4. IMPLEMENTACE
je balík program· net-snmp (zaji²´uje komunikaci s p°epína£i) a graphviz (vykresluje zji²t¥nou topologii).
4.2 Neobvyklé £ásti implementace Protoºe pot°ebujeme pracovat se v²emi daty jednotlivých p°epína£· najednou, rozhodl jsem se pro dynamický zp·sob vytvá°ení jednotlivých instancí. Odkazy na jednotlivé instance uchovávám v poli objekt·. Celý tento proces v£etn¥ napln¥ní instance p°epína£e má na starosti následují £ást programu.
#connString obsahuje poloºky z konfigura£ního souboru # pro kaºdý switch z konfigurace for i in connString: tryConnection(i) # zkusím se p°ipojit switchname=getSwitchName(i) # získám jeho jméno lst.append(Switch(switchname,numOfPorts(i))) #vytvo°í instaci switche macport=knownMacPort(i) #do promn¥né macport uloºím CAM tabulku switche for j in macport[0]: # obsah promn¥né p°esypu do instace switche pom1=macport[1][macport[0].index(j)] lst[-1].insertInCAM(j,pom1) Pro snaz²í pochopení je²t¥ uvádím de nici t°ídy switch.
class Switch: def __init__(self,sw_name,x=0): #misto pro ulozeni CAM tabulek self.cam_address=[] self.cam_port=[] #nalezeni sousede self.neighbors=[] #obsazene porty self.ports=[] #switche name self.sw_name=sw_name for i in range(int(x)): self.ports.insert(i,0)
4.3. NET-SNMP
25
P°i vytvá°ení instance dojde k inicializaci pole obsahující seznam obsazených port· a nastavení v²ech jeho hodnot na nulu. Tím °íkáme, ºe na za£átku nemá ºádné sousedy. Tím, ºe si ozna£íme obsazené porty, m·ºeme snadn¥ji rozpoznávat nejednozna£ná °e²ení.
4.3 Net-snmp V sou£asnosti vyuºívám tento externí program pro získávání dat z p°epína£·. P·vodn¥ jsem m¥l toto °e²ení pouze pro testovací ú£ely a p°edpokládal jsem, ºe ve nální verzi bude spu²t¥ní externích program· nahrazeno n¥jakou vhodnou knihovnou, kterou budu moci svobodn¥ distribuovat spole£n¥ se zdrojovými kódy mého programu. Av²ak p°i hledání vhodného frameworku jsem byl záhy zastaven jejich nedostatkem. Po n¥kolika dnech hledání jsem nakonec získal následující seznam vhodných kandidát·:
• SNMPy
- Wrapper postavený kolem balíku net-snmp verze 4.x,v sou£asnosti mrtvý
projekt, poslední aktualizace je z 26. b°ezna 2001 licencován pomocí Python License (CNRI Python License).
• YAPSNMP
- Wrapper postavený kolem balíku net-snmp verze 5.x, v sou£asnosti
mrtvý projekt, poslední aktualizace je z 8. b°ezna 2004 ²í°ený pod licencí LGPL.
• Multi-core SNMP - Wrapper postavený kolem balíku net-snmp verze 5.4.2.1 a vy²²í ²í°ený pod MIT licencí. Jeho nevýhodou je ze je postavený na Pythonu verze 2.6.
• PySNMP - £ist¥ pythonovský framework pro práci se snmp sou£asnosti jsou dv¥ verze distibuované pod vlastní licencí.
1
verze 2.x - implementuje SNMPv1 a SNMPv2c - stabilní v¥tev verze 4.x - implementuje SNMPv1, SNMPv2c, SNMPv2u a SNMPv3 - sou£asná vývojová nestabilní verze (tento projekt byl dlouhou dobu zcela zastaven, av²ak nyní se zdá, ºe se op¥t za£íná trochu probouzet)
Z tohoto porovnání mi jako neslibn¥j²í knihovny p°ipadají poslední dv¥ zmín¥né. U Multicore SNMP je nevýhodou pouºití Pythonu verze 2.6, jelikoº jsem zam¥°il celý projekt tak,
2 byl jsem nucen poohlédnout se jinde.
aby p°edev²ím fungoval na distribuci Debian
U projektu PySNMP je nevýhoda, ºe verze 4.x je pouze ve stádiu vývoje. Sice bych mohl pouºít verzi 2.x, ale ta se natolik li²í od verze 4.x, ºe p°echod na vy²²í verzi by byl stejn¥ komplikovaný jako p°echod k jiné knihovn¥. 1 2
dostupná na http://pysnmp.sourceforge.net/license.html stav k 15.12. 2009 Sou£asná verze Debianu 5.0 pouºívá verzi 2.5
26
KAPITOLA 4. IMPLEMENTACE
Po t¥chto úvahách jsem tedy dosp¥l k rozhodnutí. Nadále z·stat u do£asné verze, tedy spou²t¥ní externích p°íkaz·, dokud se projekt PySNMP 4.x nedostane do stabilní verze, nebo distribuce Debian neza°adí do standardních balík· verzi Pythonu 2.6
3
P°íkaz snmpwalk z balíku program· net-snmp poºívám v n¥kolika metodách, které získávají d·leºité informace z p°epína£·. V²echny metody dostávají jako jeden parametr comunity string a IP adresu
4
• tryConnection(String) - funkce pokusí p°ipojit k p°epína£i v p°ípad¥ ºe usp¥je program pokra£uje dále, v p°ípad¥ chyby dojde k ukon£ení b¥hu programu a vypsání chyby.
• getSwitchName(String)
- funkce slouºí ke získání jména p°epína£e. Jméno pozd¥ji
pouºívám p°i vykreslování topologie.
• knownMacPort(String)
- funkce vrací dv¥ pole první pole obsahuje MAC adresy
známých za°ízení, druhé pole obsahuje port na kterém se daná MAC adresa vyskytuje. Provázanost obou polí je zaji²t¥no pomocí index· tzn. první poloºka z pole MAC adres odpovídá první poloºce z pole port· atd.
• myAddress(String)
5 jednotlivých port· p°epína£e
- funkce vrací MAC adresu(y)
ve v¥t²in¥ p°ípad· má p°epína£ pouze jednu MAC adresu pro v²echny své porty. Na základ¥ této informace se rozhoduji zda-li je nalezené za°ízení p°epína£ nebo koncový bod.
4.4 Graphviz Pro vyuºití tohoto externího programu v ostré verzi jsem nebyl donucen okolnostmi,jako u p°edchozího, ale toto rozhodnutí bylo £ist¥ pragmatické. Na za£átku vývoje nebylo nutné vyvíjet nástroj na vizualizaci topologie. Proto jsem se poohlédnul po n¥jakém vhodném nástroji. Graphviz je sada open-source nástroj·, jejichº vývoj za£al v AT&T Research Labs, a je ur£en pro generování graf·, které jsou popsány ve speciálním DOT jazyku. Je ²í°en pod licencí CPL v 1.0 dostupnou na http://www.graphviz.org/License.php Syntaxe jazyka DOT jeº graphviz pouºívá, je velmi jednoduchá. A pro lep²í p°edstavu p°ipojuji ukázku. 3 4
B.2. 5
Za°azení tohoto balíku je zatím plánováno do verze 6.0 s kódovým ozna£ením Squeeze. IP adresa i comunity string se získávají z kon gura£ního souboru jehoº podoba je uvedena v dodatku V pr·b¥hu implementace jsem narazil na n¥kolik p°epína£·, které m¥li pro kaºdý port jinou MAC adresu.
4.4. GRAPHVIZ
27
digraph G { ratio = "auto" ; #velikost grafu "auto" edge [dir=none]; #strany nemají orientaci #definice propojení bod· A -> B B -> C B -> D } Tento jednoduchý zdrojový text p°eloºí graphviz do následujícího obrázku.
A
B
C
D
Obrázek 4.1: P°íklad jazyka DOT
28
KAPITOLA 4. IMPLEMENTACE
Kapitola 5
Testování Program byl spou²t¥n z PC následující kon gurace:
• OS
- Debian 5.0 lenny
• Kernel • Python
- linux 2.6.18-6-xen-amd64 - verze 2.5
• NET-SNMP
- verze 5.4.1
Testovaná sí´ byla realizována 4 p°epína£i a nespeci kovaným mnoºstvím koncových za°ízení. Dva p°epína£e byly od rmy Cisco konkrétn¥ se jedná o typy Catalyst C2950 a zbylé dva od rmy Huawei konkrétn¥ se jedná o typy Quidway S5624P. Po celou dobu vývoje a testování jsem nem¥l sebemen²í fyzický p°ístup k jednotlivým za°ízením a také mi nebyla celá topologie prozrazena. Výsledky jsou tedy zcela objektivní. Výsledky b¥hu programu jsou názorné z následujících obrázk·. Na prvním bylo zakázáno vykreslování koncových za°ízení na druhém jiº byla tato volba povolena.
Obrázek 5.1: Test bez koncových za°ízení
29
30
KAPITOLA 5. TESTOVÁNÍ
Obrázek 5.2: Test s koncovými za°ízeními
Celé vykreslení trvalo asi 15-20 vte°in. Po hlub²í analýze programu jsem zjistil, ºe nejpo-
1
malej²í místo celého programu je získání CAM tabulek z p°epína£· . Proto by bylo v hodné 1
Rychlost zji²t¥ní topologie bude tedy zna£n¥ záviset na po£tu p°epína£· v dané síti.
31
p°ejít v budoucnu na SNMPv2c pop°ípad¥ SNMPv3. Obrázek na 5.1 se interpretuje velmi snadno. Jedná se o p°ímé propojení £ty° p°epína£·. Na obrázku 5.2 je situace mnohem zajímav¥j²í. V²echny p°epína£e jsou propojeny stejn¥ jako na p°edchozím obrázku, ale navíc je k nim p°ipojeno je²t¥ n¥kolik dal²ích stroj·. P°epína£e cat4 a cat0.trustica.cz nemají k sob¥ p°ipojen ºádný dal²í stroj. Po konzultaci s odborníkem, který danou topologii zná, bylo shledáno, ºe k t¥mto p°epína£·m jsou p°ipojeny stroje, na nichº b¥ºí n¥kolik virtualizovaných systém·. Z tohoto d·vodu se p°epína£i zdá, ºe má na jednom portu více MAC adres. Nejzajímav¥j²í je v²ak p°ipojení koncových stroj· s MAC adresami 00:13:C4:E8:5E:31 a 00:13:D3:55:F2:99. Jak je vid¥t, tyto stroje jsou p°ipojeny ke dv¥ma p°epína£·m hua1 a hua0. K p°epína£i hua0 je pak nadále p°ipojen jen jeden stroj. Teto zp·sob p°ipojení se £asto vyuºívá, pokud pot°ebujeme zajistit dostate£nou ²í°ku pásma mezi stroji 00:13:C4:E8:5E:31, 00:13:D3:55:F2:99 a 00:0D:60:17:11:E3. Po konzultaci mi byl m·j p°edpoklad potvrzen. Jediným závaºn¥j²ím problémem celého testování je nasazení programu pouze na jednu topologii sít¥. Proto doufám, ºe v budoucnu budu moci provést testy je²t¥ na jiných sítí abych p°ípadné nedostatky odstranil.
32
KAPITOLA 5. TESTOVÁNÍ
Kapitola 6
Záv¥r Prvním cílem této práce bylo prozkoumat protokoly t°etí a vy²²í vrstvy ISO/OSI modelu. Jako vhodné protokoly pro rekonstrukci fyzické topologie sít¥ se jevily protokoly SNMP a CMOT, které jsem se snaºil ve své práci porovnat. Druhý ze jmenovaných protokol· byl p·vodn¥ zamý²len jako nástupce SNMP, av²ak jeho p°íli²ná implementa£ní sloºitost nakonec nevedla k masovému roz²í°ení. Proto, z hlediska co nej²ir²í vyuºitelnosti mého programu, jsem byl nucen pouºít protokol SNMP. I tento protokol trpí °adou nedostatk·, av²ak jeho masové roz²í°ení z n¥j ud¥lalo mého favorita. Dal²ím cílem bylo na základ¥ vybraného protokolu navrhnout metodu, díky které bude moºno rekonstruovat fyzickou topologii. Mnou navrºená metoda je zaloºena na dvoufázové analýze CAM tabulek. V první fázi rekonstrukce pouºívá pouze údaje, kterým lze jednozna£n¥ p°i°adit jejich místo v rekonstruované topologii. V druhé fázi se snaºí, na základ¥ výsledk· první fáze, do°e²it propojení, která nejsou na první pohled z°ejmá. Nakonec jsem navrºenou metodu implementoval. V pr·b¥hu implementace do²lo k n¥kolika men²ím problém·m, které bylo nutno °e²it. Následné testování v²ak prokázalo, ºe implementace prob¥hla v po°ádku a ºe testovaný software podává o£ekávané výsledky. I p°es kvalitní dosaºené výsledky se ale objevily ur£ité nedostatky, které by bylo dobré dále °e²it.Testování implementace také ukázalo dal²í moºnosti roz²í°ení. Nejzávaºn¥j²ím nedostatkem, kterého jsem si v sou£asnosti v¥dom je, jakým zp·sobem p°istupovat k za°ízení, u kterých není jejich propojení s ostatními jednozna£n¥ ur£eno. V p°ípad¥, ºe se jedná o p°epína£, je do topologie normáln¥ zakreslen, ale není p°ipojen k ºádnému z dal²ích p°epína£·. Má k sob¥ p°ipojeny pouze v²echny koncová za°ízení, která se dala jednozna£n¥ ur£it. V p°ípad¥, ºe se jedná o koncový stroj, není do topologie z d·vodu p°ehlednosti zakreslen v·bec. V budoucnu by tento nedostatek ²el odstranit na základ¥ modulu, který by provád¥l mapování na t°etí vrstv¥ ISO/OSI modelu a zárove¬ by odstranil nejednozna£né propojení koncových stroj·.
33
34
KAPITOLA 6. ZÁV
R
Dal²í nedostatek v sou£asnosti spo£ívá v závislosti na externím programu net-snmp. Tato závislost p·jde odstranit vytvo°ením vlastní knihovny pro Python nebo vyuºitím n¥které z vý²e zmín¥ných knihoven, které v²ak v dob¥ vzniku této práce nebyly pouºitelné. Jsem p°esv¥d£en, ºe pokud dojde k odstran¥ní v²ech vý²e zmín¥ných nedostatk·, vznikne kvalitní nástroj pro mapování fyzické topologie, který bude schopen konkurovat i dosud dostupným program·m.
Literatura [1] Fractal Benchmark.
http://www.timestretch.com/FractalBenchmark.html. [2] R. Braden. Requirements for Internet Hosts communication layers, 1989.
http://tools.ietf.org/html/rfc1122/. [3] J. Case, M. Fedor, M. Schostall, and C. Davin. A Simple Network Management Protocol, 1989.
http://tools.ietf.org/html/rfc1098/. [4] ITU. Data networks and open system communications. Open Systems Interconnection -
model and notation, pages 3653, 1994. [5] Charles M. Kozierok. The TCP/IP Guide, 2005.
http://www.tcpipguide.com/free/. [6] U. Warrier, L. Besaw, L. LaBarre, and B. Handspicker. Information Services and Protocols for the Internet, 1990.
http://tools.ietf.org/html/rfc1189.
35
The Common Management
36
LITERATURA
Dodatek A
Seznam pouºitých zkratek ASN.1
Abstract Syntax Notation One
AT&T
American Telephone & Telegraph
BASH
Bourne Again Shell
CAM
Content Adresable Memory
DDP
Datagram Delivery Protocol
GNU
GNU's Not Unix
IANA
Internet Assigned Numbers Authority
ICMP
Internet Control Message Protocol
IEEE
Institute of Electrical and Electronics Engineers
IETF
Internet Engeneering Task Force
IGMP
Internet Group Message Protocol
ISO
International Standard Organization
IPX
Internetwork Packet Exchange
LAN
Local Arean Network
LGPL
Lesser General Public License
MIB
Management Information Base
MIT
Masachutes Institute of Technology
37
38
DODATEK A.
NDP OID OSI
SEZNAM POUITÝCH ZKRATEK
Neighbor Discovery Protocol Object Identi er
Open System Interconection
PDU
Program Data Unit
RFC
Request For Comments
RPC
Remote Procedure Call
SGMP SPX
Simple Gateway Monitoring Protocol
Sequenced Packet Exchange
TCP/IP
Transmition Control Protocol / Internet Protocol
UDP
User Datagram Protocol
XML
Extensible Markup Language
Dodatek B
Instala£ní a uºivatelská p°íru£ka B.1 Instalace programu Program se nachází na p°iloºeném CD v adresá°i /programy. Jeho instalaci provedeme tím, ºe oba soubory zkopírujeme do námi zvoleného adresá°e. Po zkopírování nastavíme souboru l2g.py práva ke spu²t¥ní. Pozor program je závyslí na balí£ku python 2.5, net-snmp a graphviz. Python 2.5 musí být zpustitelný pomocí p°íkazu
/usr/bin/env python. V prom¥nné
PATH pak musí být uvedeny cesty k program·m z balíku net.snmp a graphviz.
Parametry programu: Parametr Popis -i soubor
vstupní textový kon gura£ní soubor (povinný parametr)
-o soubor
soubor pro uloºení nalezené topologie ve formátu png (povinný parametr)
-v
vytiskne verzi programu
-h
vytiskne nápov¥du
Tabulka B.1: CMISE sluºby
B.2 Syntaxe kon gura£ního souboru V kon gura£ním souboru se uvádí community string a IP adresa od¥lená mezerou. IP adresa a community string musí být pro kaºdý p°epína£ na vlastním °ádku.
public 192.168.34.23 public 192.168.34.22
39
40
DODATEK B. INSTALANÍ A UIVATELSKÁ PÍRUKA
Dodatek C
Obsah p°iloºeného CD . |-| | |-| | \--
program |-- l2g.py - spustitelný soubor projektu \-- switch.py - definice t°ídy switch text |-- bach-l2g.pdf - text bakalá°ské práce ve formátu pdf \-- bach-l2g.tex - zdrojové texty bakalá°ské práce readme - popis obsahu CD
41
