Ve znamení SNMP a RMON

S nárůstem velikosti sítí, které je třeba spravovat, se jejich správci stále častěji poohlížejí po dodatečných ...


S nárůstem velikosti sítí, které je třeba spravovat, se jejich správci stále
častěji poohlížejí po dodatečných prostředcích, které by jim umožnily udržet
svěřené sítě v chodu. Na jejich požadavky pak samozřejmě reagují výrobci, kteří
dodávají stále dokonalejší nástroje pro monitorování sítí a nastavování jejich
parametrů. Protože se však zřídkakdy vyskytne síť, ve které by všechny její
prvky byly dílem jediného výrobce, je nezbytným předpokladem pro její efektivní
řízení kompatibilita těchto zařízení s programy pro jejich správu.
A co víc základním požadavkem bývá možnost správy celé sítě prostřednictvím
jediné konzole a proto je nutno zajistit kompatibilitu všech síťových prvků,
které je třeba spravovat, s jediným správcovským nástrojem. To by samozřejmě
nebylo možné bez dodržení určitých standardů. Mezi ty, které jsou nejčastěji
citovány (a které jsou také v této oblasti nejdůležitělší), patří SNMP a RMON.
Co se pod těmito pojmy skrývá?
SNMP
Název SNMP znamená Simple Network Management Protocol a je to tedy protokol
určený pro správu sítě, resp. pro správu jednotlivých síťových prvků. Takovými
prvky mohou být třeba přepínače, routery nebo prostě jen SNMP sondy
monitorující určitý segment sítě.
Tím, kdo zjišťuje stav nějakého prvku v síti a je schopen o něm podat zprávu,
je tzv. SNMP agent, který je dnes již většinou součástí spravovaného zařízení.
Pomocí protokolu SNMP pak komunikuje se správcovským softwarem (NMS Network
Management Software), chcete-li s Manažerem, který má na starosti zpracování
přijatých dat a jejich předložení osobám zodpovědným za chod sítě v nějaké
přijatelné podobě, která je zpravidla uživatelsky nastavitelná.
Komunikace prostřednictvím SNMP tedy probíhá mezi dvěma účastníky mezi Agenty,
kteří data sbírají a Manažerem, který je od nich dostává. Přesnější by ovšem
bylo říci který si jim o ně říká.
MIB
Aby Manažer věděl, které informace si má od Agentů vyžádat, má k dispozici
hierarchickou databázi síťových objektů MIB (Management Information Base).
Objekty jsou v ní popsány prostřednictvím jazyka ASN.1 (Abstract Syntax
Notation One).
Nejsnáze je možno si tuto databázi představit jako adresářovou strukturu, kde
na nejvyšší úrovni je, stejně jako u disku, kořen
(root) a pod ním se pak nacházejí další síťové objekty. Objektem může být
nějaké fyzické zařízení, jeho vlastnost, ale také např. složka ISO, kterou
spravuje stejnojmenná organizace.
Pokud jste někdy editovali registry ve Windows 95, potom budete velice blízko
skutečnosti, když si strukturu MIB představíte jako strukturu registrů. I v
řídicí databázi Windows 95 se na určité úrovni setkáte se složkami, které patří
konkrétním aplikacím, které si s nimi de facto mohou dělat, co se jim zlíbí. A
zrovna tak v MIB mají na jedné úrovni své podsložky jednotliví výrobci síťových
zařízení, kam mohou zapisovat vlastnosti svých produktů.
Každý objekt (složka) v MIB je popsán několika parametry mj. textovým jménem,
které slouží ke snadnější orientaci v této databázi, identifikačním (celým)
číslem, syntaxí, což je definice typu hodnoty, kterou může obsahovat, textovou
definicí jeho významu, aby nedošlo k dezinterpretaci jím obsahované hodnoty,
atributem přístupu k objektu [jen pro čtení (read-only), pro čtení a zápis
(read-write), pouze pro zápis (write-only), a nepřístupný (not-accessible)] a
statusem nutný, volitelný, zastaralý.
Řada objektů je již standardně definována. Za všechny jmenujme např. objekt
označený textovým názvem sysUpTime ze skupiny system s číslem 3, typ objektu je
TimeTicks (typ proměnné, která v sobě uchovává časovou hodnotu), textová
definice zní: čas (v setinách sekundy), který uplynul od poslední inicializace
této části systému, přístup: jen pro čtení (read-only), status: nutný.
Libovolný objekt je, podobně jako v případě adresářové struktury, definován
cestou, kterou se k němu dostaneme. Nepoužívá se ovšem textový popis
jednotlivých prvků v cestě, ale číselný. Takže cesta může být např. 1.3.6.1.4.
1.44.22.
Vrátíme-li se k úvaze o složkách přidělených jednotlivým výrobcům, potom když
má nějaký výrobce k dispozici např. složku 1.3.6.1.4.1.58, může si do ní dávat
libovolné podsložky, takže např. 1.3.6.1.4.1.58.1.23 může být složka jeho hubu
Super22. Pro standardní vlastnosti jeho hubů je však obvyklé použít jejich
předdefinovanou složku potom každý Manažer ví, kam se obrátit pro informace.
Popis nestandardních parametrů mu musí být nějakým způsobem předán (typicky z
instalační diskety).
Definice MIB byla později rozšířena a dnes je většina novějších účastníků SNMP
komunikace kompatibilní s verzí MIB II.
Komunikace SNMP
MIB je tedy popisem struktury dat, která může Manažer získat od Agentů
(samozřejmě podle typu jednotlivých zařízení). Informace se od Agentů k
Manažerům dostávají prostřednictvím SNMP příkazů (hlášení), přičemž každý z
nich je vždy reprezentován jedním datagramem v sítích TCP/IP se přenos děje
prostřednictvím protokolu UDP (kvůli jednoduchosti agenta).
Každé hlášení v sobě nese kromě identifikace příkazu také číslo verze, jméno
komunity, ke které patří daný adresát a odesílatel a tzv. PDU (Protocol Data
Unit), což je specifikace datové položky, o kterou se jedná. V protokolu SNMP
je definováno 5 typů hlášení:
lGetRequest vysílá Manažer k Agentovi jako žádost o zaslání stavu (hodnoty)
objektu. V rámci jednoho příkazu je možno žádat informace o více objektech.
lGetNextRequest je vysílán Manažerem k Agentovi jako žádost o zaslání informací
z nižší vrstvy MIB struktury.
lSetRequest zasílá Manažer Agentovi za účelem nastavení nějaké proměnné objektu.
lGetResponse je odpovědí Agenta na příkaz GetRequest nebo GetNextRequest.
lTrap vysílá agent v případě nějaké události, o které je třeba bezprostředně
informovat manažera typicky resetu, překročení nějaké hraniční hodnoty, nebo
selhání určité části zařízení (napájecího zdroje apod.). Toto hlášení Agenta
jako jediné nečeká na výzvu Manažera.
Omezení SNMP
Protože má tento protokol kořeny kdesi v 80. letech, jeho specifikace dnes již
plně nevyhovuje současným požadavkům. Mezi nedostatky, které mu jsou nejčastěji
vytýkány, patří malá bezpečnost, žádná přímá podpora komunikace mezi
jednotlivými Manažery (je-li jich třeba v rozsáhlé síti více) a zbytečné
zatěžování sítě v případě, že je třeba získat v krátkých časových intervalech
řadu stavů jednotlivých síťových prvků pro další vyhodnocení.
Reakcí na tyto skutečnosti byl návrh normy SNMP 2, která se i přes určité
spory, vyplývající z různých názorů zúčastněných stran, snad v blízké
budoucnosti konečně výrazněji prosadí.
RMON
Na jednu z výtek, které jsou zmíněny výše, totiž na zbytečné zatížení sítě v
případě, že je třeba statisticky vyhodnocovat stav jednotlivých zařízení v
určitých intervalech, reaguje návrh standardu RMON (Remote Monitoring). Jedná
se o rozšíření MIB o další položky, které jsou zaměřeny na statistické
zpracování postupně nasbíraných dat toto zpracování provádí Agent a nikoli
Manažer.
Výhodou tohoto řešení je snížení zátěže sítě, protože po ní nemusí putovat řada
postupně naměřených hodnot určená k pozdějšímu zpracování, ale přenáší se pouze
výsledek tohoto zpracování. V neposlední řadě se také ulehčí Manažerovi.
Standard RMON (v RFC1757) definuje 9 nových skupin MIB (ve firemních údajích je
však možno se setkat i s jiným dělením):
1.Statistika informuje o statistikách týkajících se přenesených paketů a jejich
velikosti, kolizí (Ethernet), všesměrového vysílání apod. z hlediska segmentu,
portu nebo uživatele.
2.Historie dává přehled o historickém vývoji stejných údajů jako v bodu 1
(vzorkovací periodu může určit uživatel, délka testování a perioda je
pochopitelně omezena kapacitou paměti Agenta). Někdy bývá rozdělena do 2 skupin
nastavení parametrů a vlastní historická data.
3.Alarmy umožňuje uživateli nastavit maximální a minimální hodnoty sledovaných
údajů, jejichž překročení je zaznamenáno a je na něj upozorněno (je-li
podporována 9. skupina).
4.Hostitelé informuje o statistických údajích z hlediska jednotlivých síťových
uzlů.
5.Top N hostitelů stejné informace jako v bodě 4 seřazené podle dosažených
hodnot (např. 5 stanic s největším provozem).
6.Matrice provozu data o vzájemné komunikaci dvojic uzlů.
7.Filtry umožňují nastavit omezení sledovaných paketů jen na ty, které
uživatele zajímají. 8.Lovení paketů umožňuje zachytávat určité pakety a
zapamatovat si je pro pozdější předání Manažeru.
9.Události umožňuje zasílat zprávy (reakce na různé události) na uživatelskou
konzoli.
Také v případě RMON se záhy ukázalo, že by neškodila další rozšíření, takže
byly brzy přidány i další skupiny. V současnosti je nejnovější verzí RMON 2,
která umožňuje monitorovat sítě až do aplikační úrovně.
8 0396 / pen









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.