Универзитет „Св.

Кирил и Методиј“ – Скопје

Факултет за Електротехника и Информациски

Технологии

Семинарска работа по предметот

Управување со компјутерско комуникациски мрежи

Тема:

Simple Network Management Protocol (SNMP)

Ментoр: Кандидат:

Проф. Д-р. Аристорел Тентов Мејхан Коџаџиклиоски, индекс: 212/2009

Скoпје, 2011

1
 АПСТРАКТ
Денешниве комплексни мрежи кои се изградени од голем број на рутери,
свичеви, и сервери, може да претставуваат тешка задача во однос на управувањето и
менаџирањето со сите тие уреди на мрежата и воедно да се обезбеди сигурност за
нивно оптимално функционирање. За вакви потреби може да помогне Network
Management Protocol (SNMP), протокол за управување со мрежите. SNMP беше
воведена во 1988 година за да мозе да одговори на зголемената потреба за стандард
за управување со интернет протоколот (IP) на самите уреди. SNMP овозможува на
своите корисници далечински пристап на работа со овие уреди со едноставно
множество на операции за работа.

2
Содржина:

Вовед 4

1. Oпшт концепт за управување со мрежата 5

1.1 Управување со дефекти 5

1.2 Управување со конфигурација 5

1.3 Управување со пристапот 6

1.4 Управување со перформансите 6

1.5 Управување со безбедноста 6

2. Што е SNMP? 7
2.1SNMP верзии 8

2.2 Менаџери и агенти 8

2.3 Структура на управување со информации и MIBs 10

2.4 Хост (домаќин) менаџмент 11

2.5 Краток вовед за далечинско мониторирање (RMON) 11

2.6 Транспортно ниво 12

2.7 SNMP заедници 14

2.8 Структура на управување со информации 15

3. Објектно стебло (објекти потребни за управување со мрежата) 16

3.1 Именување OIDs 16

3.2 Проширувања на SMI во верзија SMIv2 22

3.3 Преглед на MIB-II 24

4. SNMP Операции 26

4.1 get операција 26

4.2 getnext операцијата 27
4.3 getbulk операција 29
4.4 set операција 31
4.5. get, getnext, getbulk, и set Error одговори 33

3
 4.6 SNMP Traps 34

5.Софтвер за управување со мрежата 34

5.1. Станици за управување со мрежата 35

5.2 Елемент – менаџер 37

5.3. Анализа 37

5.4 Софтвер за поддршка 38

Заклучок

Референци

Вовед

Simple Network Management Protocol (SNMP) e интернет-стандардизиран протокол

за управување со уреди во една IP мрежа. Многу типови на мрежни уреди поддржуваа
SNMP, вклучувајќи ги рутерите, серверите, работни станици, принтери, модеми исл.
Начинот на кој што може да се користи SNMP е многу различен и може да служи за
наједноставни работи до најсложени. Најчесто се користи за следење на работата на
рутерите во мрежата, серверите, и друготе делови од хардверот кој што ја сочинува
мрежата, но исто така може да се користи и за контрола на мрежните уреди или да се
превземе автоматски акции доколку се случи некој непредвидлив проблем во самата
мрежа. Информациите кои се прибираат од мрежата може да бидат едноставни и
стандардизирани работи, како што се големина на сообраќај кој што оди преку одреден
интерфејс, до многу сложени хардверски работи како што е мерење на температурата во
самиот рутер.

Со оваа семинарска се обидуваме да се даде основно разбирање на она што е

SNMP и како функционира, а надвор од тоа, ќе покажеме како да се стави сето тоа во
пракса, со користење на голем број на достапни алатки. Во ова поглавје главно ќе се
задржиме на SNMP, како концепт за управување со мрежата, и за управување и
справување со промени на самата мрежа. Очигледно, SNMP е во фокусот ќе ни биде во

4
фокусот на оваа семинарска, но ќе дадеме и дефинираме општи концепти за управување
со мрежата со цел подобро да се сфати и самиот концепт на работа и на SNMP.

1. Oпшт концепт за управување со мрежата

Управување со мрежата е дисциплина сама по себе, но пред да почнеме со SNMP

во детали, потребно е да направиме мал преглед на управувањето на мрежата сама по
себе.

Што е управување со мрежата? Управување со мрежата е општ поим кој вклучува

употреба на различни алатки, техники и системи за помош на луѓето во управувањето со
различни уреди, системи, или мрежи. Разгледуваме модел за управување со мрежата
наречена FCAPS, Fault Management, Configuration Management, Accounting Management,
Performance Management, и Security Management.Овие концептуални области беа
создадени од страна на Меѓународната организација за стандардизација (ISO) за да
помогне во разбирањето на главните функции од системите за управување сo мрежите.

1.1 Управување со дефекти

Целта на управувањето со дефектите е да се детектираат, логираат, и да се

известат корисниците на системите или мрежите од проблеми. Во многу средини, прекини
во работата од било кој вид не е прифатливо.
управувањето со дефекти диктира неколку чекори за решавање на дефектите и тоа:

1. Изолирање на проблемот со користење на алатки за да се утврдат симптомите

на настанатиот проблем.
2. Решавање на проблемот.
3. Меморирање на процесот што се користеше за откривање и решавање на
проблемот.

Иако чекор 3 е важен дел, тоа често не се користи. Занемарувањето на чекор 3

има несакани ефекти што предизвикува новите инженери потешко да ги следат чекорите
1 и 2. Доколку се меморираат решенијата лесно би можеле да се консултираат со таа
база на податоци за совети за дијагностицирање на проблемите.

1.2 Управување со конфигурација

Целта на управување со конфигурацијата е да ги следи и мрежа и информациите

за системската конфигурација, така што ефектите на мрежното функционирање на
различни верзии на хардверски и софтверски елементи може да се следи и управува.

5
 Секој систем може да има голем број на интересни и релевантни конфигурациски
параметри, за кој инженерите можат да бидат заинтересирани при работата, вклучувајќи:

• верзија на оперативниот систем, firmware, итн

• Број на мрежни интерфејси и брзина, итн
• Број на хард дисковите
• Број на процесори
• Големина на RAM меморија

Оваа информација, генерално е запишана во на некој начин во некоја база . Како

што конфигурациските параметри се менуваат така базата на податоци се ажурира. Овие
информации убаво е да се имаат бидејќи може да помогнат во решавањето на
проблемите.
.

1.3 Управување со пристапот

Целта на ова управување е да се има правилен пристап до пресметкувачките и

мрежните ресурски од страна на сите групи или поединци кои што имаа пристап до
нив. Преку оваа форма на регулирање, мрежните проблеми може да се минимизираат со
оглед на тоа дека ресурсите ќе бидат поделени според нивните капацитети.

1.4 Управување со перформансите

Целта на управувањето со перформанците е да се измери и да се известуваат за

различните аспекти на мрежата или перформансите на системот.

Ајде да ги погледнеме чекорите кои се вклучени во управувањето со

перформансите на мрежата:

1. Најпрво се собираат податоците за перформансите.

2. Се утврдуваат основните нивоа врз основа на анализата на собраните
податоците.
3. Се поставуваат границите (праговите) на перформансите. Кога овие прагови се
надминати, тоа е показател на проблем кој што бара внимание.

Еден пример за управување со перформансите е мониторинг на сервиси. На

пример, интернет сервис провајдерот (ISP) може да биде заинтересиран за следење на
неговото e-mail сервисно време за реакција. Ова вклучува испраќање пораки преку SMTP
и добивање пораки преку POP3.

1.5 Управување со безбедноста

6
 Целта на управување со безбедноста е двојна. Прво, ние сакаме да го
контролираме пристапот до некои ресурси, како во мрежата така и во нејзините
домаќини.Второ, сакаме да помогне во откривање и спречување на напади кои можат да
и наштетат на мрежата и нејзините домаќини. Нападите на самата мрежа и нејзините
домаќини може да доведе до одбивање на услуга која е побарана од мрежата и уште
полошо да им овозможи на хакерите да добијат пристап до витални информации за
системот кои што може да содржат сметководствени податоци, плати и изворниот код на
податоците.

Денес, за управување со мрежна безбедност се остварува преку употреба на

разни алатки и системи дизајнирани специјално за оваа намена. Тие вклучуваат:

• Firewalls
• рана детекција на пожар системи (IDSs)
• превенција на натрапници системи (IPSs)
• антивирус системи
• Политика за управување и спроведување на системите

Повеќето, ако не и сите од денешните безбедносни мрежни системи можат да се

интегрираат со систем за управување со мрежа преку SNMP.

2. Што е SNMP?
Јадрото на SNMP е едноставен збир на операции (и информациите од овие
операции се собираат) што им дава на администраторите можност за промена на
состојбата на некои SNMP базирани уреди. На пример, можете да го користите
SNMP за да се исклучи интерфејс на вашиот рутер или да се направи проверка на
брзина работи Ethernet. SNMP дури може да ја следи и температурата на вашиот
прекинувач и да даде предупредување, кога таа е премногу висока.

SNMP обично е поврзана со управување на рутери, но важно е да се разбере

дека може да се користи за управување повеќе различни типови на уреди. Додека
претходникот на SNMP, Simple Gateway Management Protocol (SGMP), бење развиен за
да се управува само со интернет рутери, SNMP може да се користи за управување и
со Unix системи, Windows системите, печатачите, модеми, уреди за напојување со
електрична енергија, и многу повеќе. Секој уред може да се управува од страна на
SNMP, доколку го користи софтверот кој што овозможува пронаоѓање на SNMP
информации. Ова вклучува не само физички (хардверски) уреди, туку и софтвер,
како што се web сервери и бази на податоци.
Друг аспект на управување со мрежата е мониторинг (надгледување) на самата
мрежа, а тоа е, следење на целата мрежа, за разлика од индивидуалното надгледување
на рутери, хостови, и други уреди. Remote Network Monitoring ( (RMON) е развиен за да
ни помогне да разбереме како самата мрежа функционира, како и начинот на кој што
индивидуалните уреди на мрежата имаат влијание на мрежата во целина. Може да се
користи за следење не само на LAN сообраќајот, туку дури и на WAN.

7
2.1 SNMP верзии

Следнава листа ги вклучува сите сегашни верзии на SNMP:

• SNMP Верзија 1 (SNMPv1) е првичната верзија на SNMP протоколот. SNMPv1 за

безбедноста се заснова врз “заедници”, кои не се ништо повеќе од лозинки: како
обични текстуални низи, кои дозволуваат било која SNMP-базирана апликација
која ја знае лозинката да добие пристап до информациите за управување со
уредот. Треба да се напомене дека додека SNMPv1 иако е постар стандард, се
уште е примарен за SNMP имплементација кај многу производители.

• SNMP верзија 2 (SNMPv2) е често нарекуван како заедница-стринг. Оваа верзија

на SNMP технички е наречена SNMPv2c, но овде ке го нарекуваме едноставно,
како SNMPv2. Тоа е што е дефинирано во RFC 3416, RFC 3417, и RFC 3418.

• SNMP верзија 3 (SNMPv3) е најновата верзија на SNMP. Нејзиниот главен

придонес е за управување со мрежата е во областа на безбедноста на
мрежата. Таа додава поддршка за силна автентикација и приватна комуникација
помеѓу објектите кои се управуваат. Во 2002 година, конечно го направи преминот
од нацрт-стандард во целосен стандард. Следниве RFCs ти дефинира
стандардите: RFC 3410, RFC 3411, RFC 3412, RFC 3413, RFC 3414, RFC 3415, RFC
3416, RFC 3417, RFC 3418, и RFC 2576. Глава 3 обезбедува темелна обработка на
SNMPv3 и Глава 6 оди преку SNMPv3 агент конфигурација за мрежно-SNMP и
Cisco. И покрај тоа што SNMPv3 е потполн стандард, продавачите бавно ги
усвојуваваат новите верзии на протоколот. Некои големи инфраструктурни
продавачи како Cisco ја поддржаа SNMPv3 за подолго време, а несомнено дека и
останатите ќе го прифатат како посигурна варијанта за управување со мрежата.

2.2 Менаџери и агенти

Во претходните делови, не беа наведени способностите и функциите на SNMP-

базираните уреди и станиците за управување со мрежата. Во овој дел ќе објасниме што
всушност птретставуваат. Во светот на SNMP, постојат два вида на ентитети: менаџери и
агенти. Менаџерот е серверот на кој се извршува некаков вид на софтвер кој што може да
се справи со управување со задачите за мрежа. Менаџерите често се нарекуваат станици
за управување со мражата (NMS). Овие станици се одговорни за “анкетирање” и

8
прибирање на информации од страна на агентите во мрежата. Анкетирањето, во контекст
на управување со мрежата, е чин на доведување во прашање на самиот агент (рутер,
Switch, Unix сервер, итн) за прибирање на некои информации. Овие информации може да
се користат подоцна за да се утврди дали може да настанаат некои видови на
катастрофални настани. Одговорите се испраќаат асинхроно, а не како одговор на
прашањата од страна на станиците. Станиците се одговорни за понатамошно вршење на
дејствие [] врз основа на информациите што ги добиваат од страна на самите агенти. На
пример, кога Т1 колото на интернет “паѓа”, тогаш SNMP-базираниот рутер може да
испрати одговор до станицата. За возврат, станицата може да преземе некоја акција, на
пример да даде известување дека се случило некој проблем во мрежата.

Вториот ентитет, агентот, е дел од софтвер кој работи на мрежните уреди со кои
се управува во мрежата. Тоа може да биде посебна програма (демон, во Unix јазик), или
може да биде вклучена во оперативниот систем (на пример, на Cisco IOS на рутерот, или
на пониско ниво на оперативниот систем, кој ги контролира UPS-от). Денес, повеќето IP
уреди доаѓаат со некој вид на SNMP агент вграден во нив. Фактот дека самите
производители се подготвени за вградување на агентите во многу од своите производи
им ја олеснува работата на систем администраторите за менаџирање на
мрежата. Агентот обезбедува информации за управување до станицата со следење на
различни оперативни аспекти на мрежниот уред. На пример, агентот на рутер е во
состојба да ги прати сите состојби на секој негов интерфејс до станицата и во моментот
кога забележува дека нешто се случува веднаш испраќа таква информација, а станицата
е одговорна да ги зачува во некој “ред на чекање” и соодветно да реагира на тие
настанати проблеми. Во случај кога имаме совршена состојба се испраќа “all clear” за да
се извести станицата дека се работи беспрекорно. Ова е корисно и во моментот кога
треба да добие одговор за состојбата после решавањето на некој проблем.Некои уреди
кои ќе испрати соодветните "сите јасно" стапица кога постои преминување. На слика 1 е
прикажана релацијата и пораките помеѓу агентот и станицата.

Слика 1. Релација помеѓу станицата за управување со мрежата и агентот

9
 Важно е да се има предвид дека пораките може да се одвиваат во исто време, и не
постојат никакви ограничувања за тоа кога станицата ќе прими барање или агентот да
испрати такво барање.

2.3 Структура на управување со информации и MIBs

Структура на управување со информации (SMI) обезбедува начин за да се

дефинираат објектите за управување и нивното однесување. Агент има во своја
сопственост листа на објекти кои што ги надгледува. Еден таков објект е оперативна
состојба на рутер интерфејс (на пример, дали е “паднат“, во исправна состојба, или
состојба на тестирање). Оваа листа колективно ги дефинира информациите за да
станиците полесно ги користат и да се утврди општата состојба на уредот на кој агентот
“престојува”.

Ќе дефинираме база на информации за управување (MIB), која ќе биде база на

податоци од управувани објекти кои агентот успеал да ги зачува. Било кој вид на статус
или статистички информации на кои може да се пристапи од страна на станиците се
дефинираат во таа база на информации за управување. SMI обезбедува начин да се
дефинираат објектите додека пак, MIB е самата дефиниција на објектите (со помош на
синтаксaта од SMI). Како речник, кој покажува како се спелува некој збор и потоа го дава
неговото значење и дефиниција, MIB дефинира текстуално име за објектот кој се
управува и дава негово објаснување.

Агентот може да се имплементира повеќе MIBs, но сите агенти имплементираат

MIB наречен MIB-II (RFC 1213). Овој стандард ги дефинира променливи за нешта како
што интерфејс статистика (интерфејс, брзина, MTU, испратени октети, примени октети,
итн) како и разни други работи кои се однесуваат на самиот систем (систем за локација,
конта систем, итн). Главната цел на MIB-II е да обезбеди генерален TCP / IP протокол за
управување со информации.

Кои други видови на информации може да бидат корисни за да се соберат? Прво,

многу нацрти и предложени стандарди се развиени за да се помогне за управување на
работи како што Frame Relay, АТМ, FDDI, и услугите (пошта, Domain Name System (DNS),
итн.)

• ATM MIB (RFC 2515)

• Frame Relay DTE Interface Type MIB (RFC 2115)
• BGP Version 4 MIB (RFC 1657)
• RDBMS MIB (RFC 1697)

10
 • RADIUS Authentication Server MIB (RFC 2619)
• Mail Monitoring MIB (RFC 2789)
• DNS Server MIB (RFC 1611)

2.4 Хост (домаќин) менаџмент

Управување со ресурсите на домаќинот (простор на дискот, употребата на

меморијата, итн) е важен дел на управувањето со мрежата. Разликата помеѓу
традиционалната систем администрација и управувањето со мрежата исчезнува со текот
на последната деценија и сега речиси и да не постои.

Како што Sun Microsystems вели:- "Мрежата е компјутерот". Ако вашиот веб
сервер или серверот за пошта е “паднат”, не е важно дали вашите рутери работат
исправно, вие сепак ќе бидете во можност да примате повици. Ресурсите на хостот MIB
(RFC 2790) дефинира множество од објекти за да помогне во управувањето со некои
критични аспекти на Unix и Windows системите.
Било кој оперативен систем на кој работи SNMP агент може да ги имплементира хост
ресурсите, не е ограничено само на Unix и Windows системите. Некои од објектите
поддржани од страна на Host Resources MIB се капацитет на дискот, бројот на
корисниците на системот, бројот на активни процеси, и софтвер во моментот кога се
инсталира. Денес, се повеќе и повеќе луѓе се потпираат на сервисно-ориентирани веб-
сајтови. Изработка на сигурна околина за серверите и нивна правилно функционирање е
толку важно како и следење на вашите рутери и други средства за комуникација во
самата мрежа. За жал, некои имплементации на агенти за овие платформи не го
имплементираат тоа MIB, бидејќи не е облигаторно.

2.5 Краток вовед за далечинско мониторирање (RMON)

Remote Monitoring Version 1 (RMONv1, или RMON) е дефиниран во RFC 2819,

подобрената верзија на стандардот, наречена RMON Верзија 2 (RMONv2), е дефиниран
во RFC 2021 година. RMONv1 им обезбедува на станиците статистика на пакетно ниво за
целата локална или WAN мрежа. RMONv2 се надградува над RMONv1 преку
обезбедување на мрежата со статистика на мрежно и апликациско ниво. Овие
статистички податоци може да се соберат на неколку начини. Еден начин е да се постави
RMON истрагата на секој мрежен сегмент сакате да го следите. Некои Cisco рутери имаат
ограничени RMON можности, па поради тоа може да се користат нивните
функционалности за извршување на помали RMON должности. Исто така, некои 3Com
прекинувачи имаат имплементирано целосна RMON спецификација и може да се
користат за нашите потреби во RMON истрагата за сегментите на мрежата.

11
 RMON MIB беше дизајниран за да овозможи вистинска RMON истрага дури и во
оффлине режим на работа кој што овозможува собирање на статистичките информации
за мрежата без притоа да има потреба од станиците да мора постојано да пребаруваат за
нови информации. По некое одредено време, станиците може да пребаруваат за
статистичките информации кои биле собрани преку RMON.

Друга карактеристика што се имплементира е способност да се постават граници

за разни услови на грешки, а кога прагот е преминат, да се алармираат станиците сп
SNMП trap.

2.6 Транспортно ниво

SNMP го користи UDP како транспортен протокол за пренесување на податоци

помеѓу менаџерите и агентите. UDP е одбран како транспортен протокол поради тоа што
е без-конекциски (connectionless), т.е нема крај-со-крај конекција помеѓу агентот и
станицата во моментот кога се праќаат или примаат датаграмите (пакетите). Ова го прави
UDP ненадежен бидејќи нема повратна потврда на загубените датаграми на протоклони
ниво. Затоа потребно е SNMP апликацијата да одлучи дали пораката е изгубена и треба
да се препрати. Тоа вообичаено се постигнува со воведување на timeout време за чекање
за да стигне пораката. Станицата испраќа UDP барање до агентот и оди во состојба на
чекање за одговор. Доколку пораката не стигне за тоа претходно поставено време на
чекање тогаш се смета дека пакетот е изгубен и се врши препраќање на пакетот.

Ваквата природа на UDP и не е толку голем проблем. Најлошото што може да

случи е станицата за управување да испрати барање и никогаш да не добие одговор. Кога
се работи за trap-ови ситуацијата е различна. Доколку агентот испрати trap и тој никогаш
не стигне, тогаш станицата нема шанси да дознае дека тој воопшто бил и испратен. Од
друга страна, агентот нема начин како да дознае дека станицата не го примила, бидејќи
не е потребно станицата да испраќа одговор во случај кога прима нешто.

12
 Слика 2. TCP/IP комуникациски модел и SNMP

SNMP користи 161 UDP порта за праќање и примање на барања и порта 162 за
примање на trap-ови од управуваните уреди. Секој уред кој што го има имплементирано
SNMP мора да ги користи овие порти по default, но некои производители овозможуваат и
менување на овие порти во конфигурацијата на агентот, т.е мрежниот уред. Доколку се
направи промена на портите мора да се извести и станицата за да може да пребарува по
точните порти. На следнава слика е прикажан TCP/IP протоколниот стек, кој што е основа
на секоја TCP/IP комуникација.

Во моментот кога се извршуваат SNMP функции како што се барања или trap, во
протоколниот стек се случуваат следниве настани:

На апликациско ниво – најпрво SNMP апликацијата (станицата или агентот)

одлучуваат што ќе се случи следно. На пример, може да се прати SNMP барање до
агентот, да се испрати одговор после SNMP барање (од страна на агентот), или да се
испрати trap до станицата. Апликацискиот слој обезбедува сервиси до крајниот корисник,
како на пример кога операторот бара информации за статусот за порта на пример, на
Ethernet свич.

На траспортниот слој (UDP) – тука се дозволува 2 хоста да комуницираат еден со

друг. UDP заглавието покрај многуте работи ја содржи и дестинациската порта од уредот
до каде што се испраќа или прима пораката.

IP слојот – обезбедува испорака на SNMP пакетите до дестинацијата

специфицирано со полето за IP адреса.

Media Access Control (MAC) – на крај за да SNMP пакетот стигне до дестинацијата

мора да помине преку некој физички медиум. Овој слој е составен од хардверот и
уредите кои што ги поставуваат податоците до физичкиот медиум кој што може да биде
жичан, како што е Ethernet картичка. Овој слој исто така е одговорен за примање на
пораката од физичката мрежа и повторно негово испраќање до протоколниот стек со цел
тие да бидат процесирани од стана на апликацискиот слој (во нашиов случај, од SNMP).

13
2.7 SNMP заедници

SNMPv1 и SNMPv2 користи нотација на заедници за да воспостави доверба помеѓу

менаџерите и агентите. Агентот е конфигуриран во три “заедници”: read-only, read-write и
trap. Имината на заедниците во суштина се лозинки, нема вистинска разлика меѓу една
заедница стринг и лозинката се користи за пристап до вашата сметка на
компјутерот. Трите заедница вршат контрола на различни видови на активности. Како што
самото име имплицира, во read-only заедница ни овозможува да се читаат вредностите
на податоците, но не ни дозволуваат да се менуваат податоците. На пример, овозможено
е да го прочитаме бројот на пакети што се пренесуваат преку портите на рутерот, но не е
дозволено да се ресетираат бројачите. За читање-пишување заедницата е дозволено
читање и пишување на податочните вредности со читање-пишување заедница низата,
може да се читаат бројачите, да се ресетираат нивните вредности, па дури и да се
ресетираат интерфејсите или да се направи нешто што би ја сменило конфигурацијата на
рутерот. На крај стапица заедницата дозволува да се примаат стапици (асинхрони
известувања) од страна на агентот.

Затоа што заедницата-низа се во суштина лозинки, треба да ги користите истите

правила за избор на нив, како кога се користат за Unix или Windows лозинките на
корисниците: нема зборови од речник, имиња итн. Алфанумерички стринг со мешани
големи и мали букви е добра идеја . Како што споменавме порано, проблемот со SNMP
автентикацијата е тоа што лозинките претставуваат обичен текст, што прави полесно да
се пресретнат лозинките и да се искористат против нас. SNMPv3 меѓу другото,
овозможува сигурна автентикација и комуникација помеѓу SNMP уредите.

Постојат неколку начини за да се намали ризикот од напад. IP firewalls или филтри

го минимизираат ризикот дека некој може да наштети на било кој уред на мрежата со
напаѓање преку SNMP. Можете да го конфигурирате вашиот заштитен ѕид за да се
овозможи UDP сообраќај од само една листа на познати домаќини. На пример, може да
се овозможи на UDP сообраќајот на порта 161 (SNMP барања) во вашата мрежа само ако
доаѓа од една од станиците во мрежата. Истото важи и за стапици; може да се
конфигурира рутерот со тоа што ќе овозможува UDP сообраќај на порта 162 до вашите
станици. Firewalls не е 100% ефективен, но едноставни мерки на претпазливост, како што
се овие можат многу да го намалат ризикот.

14
2.8 Структура на управување со информации

Досега го користевме терминот информации за управување кои се однесуваа за

операциските параметри на SMNP-базираните уреди. Сепак, многу малку спомнавме за
тоа што всушност содржат информациите за управување и како се претставуваат. Првиот
чекор кон разбирање на каков вид на информации мрежниот уред може да ги обезбеди е
да се разбере како тие податоци се претставуваат во контекст на SNMP. Structure of
Management Information Version 1 (SMIv1 , RFC 1155) го прави токму тоа: прецизно ја
дефинира како управуваните објекти се именуваат и специфицираат нивните податочни
типови. Structure of Management Information Version 2 (SMIv2 , RFC 2578) обезбедува
подобрувања за SNMPv2.

Дефиницијата на управуваните објекти може да се разложат на три атрибути:

Име

Името или идентификаторот на објектот (OID) уникатно го дефинира објектот. Имињата

вообичаено се јавуваат во две форми: нумерички или “лесно читливо за човекот”. Во секој
случај, имињата се долги и незгодни.

Тип и синтакса

Податочниот тип на управуваните објекти е дефиниран користејќи го подмножеството

Abstract Syntax Notation One (ASN.1 ). ASN.1 е начин на спецификација на тоа како
податоците ќе бидат претставени и испраќани помеѓу менаџерите и агентите во контекст
на SNMP. Добро во ASN.1 е тоа што оваа нотација е машински независна. Тоа значи дека
ако компјутерот работи на Windows 2000 може да комуницира со Sun SPARC машина и
нема потреба од грижа за распоред на октетите.

Кодирање

Еден пример на управуван објект е кодирање на серија на октети со користење на

Основни Правила за Кодирање. Овие правила го дефинираат како објектите се кодираат
и декодираат така што тие може да се пренесуваат преку транспортен медиум како што е
Ethernet.

15
3. Објектно стебло (објекти потребни за управување со
мрежата)

3.1 Именување OIDs

Објектите кои се управуваат се организирани во хиерархија treelike. Оваа

структура е основа за SNMP шемата на именување. Објектниот
идентификатор е составен од серија на броеви врз основа на јазли од дрвото,
одделени со точки (.). Сликата подоле ги покажува првите неколку нивоа на ова
дрво (намерно има изоставено некои гранки од дрвото , што не е голема грешка
во случајов).

Слика 3. SMI објектно стебло

Во дрвото од објекти јазлите на врвот од дрвото се нарекуваат корен, сите со

“деца” jaзли припаќаат во подстебло, а оние без “деца” јазли се нарекуваат лист јазел. На
пример, во сликата погоре корен јазел е Root-Node. Неговото подстебло го сочинуваат
ccitt(0), iso(1), и joint(2). Од овие трите, само iso(1) содржи подстебло, останатите два

16
јазли претставуваат листови. ccitt(0) и joint(2) не се однесуваат на SNMP па затоа нема да
дискутираме за нив.

Во остатокот од оваа семинарска, ќе се фокусираме на

iso(1).org(3).dod(6).internet(1) подстеблото, која претставена во форма на OID ќе биде
1.3.6.1 или како iso.org.dod.internet. Секој објект има свој нумерички OID и придружено
текстуално име. Ваквата точка-децимална нотација е како објектите се претставуваат
внатрешно во рамките на агент, текстуалното име слично како домен име, го спасува
човекот од тоа да мора за памти долги низи од броеви.

Овде е дефиницијата на internet подстеблото, како и сите четири негови подстебла:

internet OBJECT IDENTIFIER ::= { iso org(3) dod(6) 1 }

directory OBJECT IDENTIFIER ::= { internet 1 }
mgmt OBJECT IDENTIFIER ::= { internet 2 }
experimental OBJECT IDENTIFIER ::= { internet 3 }
private OBJECT IDENTIFIER ::= { internet 4 }

Првата линија го декларира internet со OID 1.3.6.1 (::= e oператор за дефинирање),

кој што е дефиниран како подстебло од iso.org.dod или 1.3.6. Останатите четири
декларации се слични, но тие ги дефинираат останатите делови кои што припаќаат на
internet. Нотацијата { internet } ни кажува дека е дел од internet подстеблото и дека
неговиот OID e 1.3.6.1.1. OID за mgmt е 1.3.6.1.2, итн.

Има уште еден дел под приватно подстебло кој се користи за да им овозможи на
хардверските и софтверските производители способност да дефинираат сопствен
приватен објект за кој било тип на хардвер или софтвер сакаат да управуваат со SNMP.
Неговата SMI дефиниција е:

enterprises OBJECT IDENTIFIER ::= { private 1 }

Важно е да се знае како да се читаат и разберат MIB документите. Следниов

пример е една верзија на MIB-II.

RFC1213-MIB DEFINITIONS ::= BEGIN

IMPORTS
mgmt, NetworkAddress, IpAddress, Counter, Gauge,
TimeTicks
FROM RFC1155-SMI
OBJECT-TYPE
FROM RFC 1212;

mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }

--група во MIB-II

system OBJECT IDENTIFIER ::= { mib-2 1 }

interfaces OBJECT IDENTIFIER ::= { mib-2 2 }
at OBJECT IDENTIFIER ::= { mib-2 3 }
ip OBJECT IDENTIFIER ::= { mib-2 4 }
icmp OBJECT IDENTIFIER ::= { mib-2 5 }

17
tcp OBJECT IDENTIFIER ::= { mib-2 6 }
udp OBJECT IDENTIFIER ::= { mib-2 7 }
egp OBJECT IDENTIFIER ::= { mib-2 8 }
transmission OBJECT IDENTIFIER ::= { mib-2 10 }
snmp OBJECT IDENTIFIER ::= { mib-2 11 }

-- Интерфејс табела

-- интерфејс табелата содржи информации за интерфејсите на

-- ентитетите.Секој интерфејс се претпоставува дека е
-- прикачен на “подстебло”. Ова подстебло не е исто со
-- “подмрежа” која што се користи за
-- адресирање според Интернет протоколот.

ifTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Листа на интерфејси на ентитети. Бројот на ентитети е даден
со вредноста на ifNumber."
::= { interfaces 2 }

ifEntry OBJECT-TYPE
SYNTAX IfEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Влезниот интерфејс содржи објекти во подмрежниот слој и подолу
за потребните интерфејси."
INDEX { ifIndex }
::= { ifTable 1 }

IfEntry ::=
SEQUENCE {
ifIndex
INTEGER,
ifDescr
DisplayString,
ifType
INTEGER,
ifMtu
INTEGER,
ifSpeed
Gauge,
ifPhysAddress
PhysAddress,
ifAdminStatus
INTEGER,
ifOperStatus
INTEGER,
ifLastChange
TimeTicks,
ifInOctets
Counter,
ifInUcastPkts

18
 Counter,
ifInNUcastPkts
Counter,
ifInDiscards
Counter,
ifInErrors
Counter,
ifInUnknownProtos
Counter,
ifOutOctets
Counter,
ifOutUcastPkts
Counter,
ifOutNUcastPkts
Counter,
ifOutDiscards
Counter,
ifOutErrors
Counter,
ifOutQLen
Gauge,
ifSpecific
OBJECT IDENTIFIER
}

ifIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Единствена вредност за секој интерфејс.
Нивната вредност е во опсег од 1 до вредноста
од ifNumber. Вредноста за секој интерфејс мора да
содржи константа од една преиницијализација до
следна."

::= { ifEntry 1 }

ifDescr OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Текстуална низа која содржи информации за
интерфејсот. Оваа низа мора да го содржи името
на производителот, името на продуктот, и
верзијата на хардверскиот интерфејс."
::= { ifEntry 2 }

END

Првата линија од овој документ го дефинира името на MIB, во случајов RFC1213-

MIB (RFC1213 е RFC кое го дефинира MBI-II). Форматот на оваа дефиниција секогаш е
ист. Делот IMPORTS овозможува да се импортираат податоќни типови и OIDs од другит
MBI документи. Во нашиов случај се импортира од RFC1155-SMI (RFC1155 ја дефинира
SMIv1 која што ја дискутиравме предходно).

19
 Истотака се импортира и OBJECT_TYPE од RFC 1212, кој што го дефинира како е
напишан MBI документот. Секоја група импортирана со IMPORTS клаузулата користи и
FROM клаузула за да дефинира од каде се превземени објектите.

Првиот објект за управување во нашата подгрупа во MIB-II е ifTable, што

претставува табела од мрежните интерфејси на управуваниот уред (се забележува дека
објектните имиња се дефинирани со измешани букви, со почетна мала буква)
Тука е нејзината дефиниција користејќи ASN.1 нотација:

ifTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Листа на интерфејси на ентитети. Бројот на ентитети е даден
со вредноста на ifNumber."
::= { interfaces 2 }

Синтаксата на ifTable е секвенца од IfEntry. Ова значи дека ifTable е табела која
што содржи колони дефинирани во IfEntry. Објектот не е достапен, што значи дека не
постои начин да агентот да пребарува за вредноста на овој објект. Неговиот статус е
задолжителен, што значи агентот мора да го спроведе овој објект, со цел да се во
согласност со спецификацијата на MIB-II. DESCRIPTION објаснува што точно претставува
овој објект. Неговиот единствен OID е 1.3.6.1.2.1.2.2 или iso.org.dod.internet.mgmt.mib-
2.interfaces.2.

Ајде сега да погледнеме во дефиниција на SEQUENCE од датотеката MIB, кој се

користи со SEQUENCE OF типот во ifTable дефиницијата:

IfEntry ::=
SEQUENCE {
ifIndex
INTEGER,
ifDescr
DisplayString,
ifType
INTEGER,
ifMtu
INTEGER,
.
.
.
ifSpecific
OBJECT IDENTIFIER
}

Секвенца е едноставна листа на објекти и нивните SMI податочни типови, кои што
ја дефинираат концептуалната табела. Во овој случај, ние очекуваме да се
најдат променливи дефинирани од страна на ifIndex,
ifDescr, ifType, итн. Оваа табела може да содржи колку било редови, тоа е до агентот за

20
управување со редовите, кои што се во табелата. Можно е за станиците да се
додадат редови во самата табела.

Дефиниција на IfEntry за тоа што се наоѓа во неговите редови:

ifEntry OBJECT-TYPE
SYNTAX IfEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Влезниот интерфејс содржи објекти во подмрежниот слој и подолу
за потребните интерфејси."
INDEX { ifIndex }
::= { ifTable 1 }

ifEntry дефинира одреден ред во ifTable. Нејзината дефиниција е речиси идентична

со онаа на ifTable, освен што се воведува нова клаузула, Индекс. Индексот е
уникатен клуч кое се користи да се дефинира ред во ifTable. Агентот е одговорен да
провери дали индексот е единствен во табелата. Ако некој
рутер има шест интерфејси, ifTable ќе има шест реда. OID ifEntry е 1.3.6.1.2.1.2.2.1, или
iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry. Индексот за ifEntry е ifIndex, кој е
дефиниран како:

ifIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Единствена вредност за секој интерфејс.
Нивната вредност е во опсег од 1 до вредноста
од ifNumber. Вредноста за секој интерфејс мора да
содржи константа од една преиницијализација до
следна."
::= { ifEntry 1 }

ifIndex објектот е само за читање, што значи дека може да се види неговата
вредност, но не можеме да се промени. Конечната цел на нашите MIB дефиниции
е ifDescr, што е текстуален опис за интерфејсите застапуван од некој одреден ред во
ifTable. Во нашиот MIB пример завршува со клаузула за крај, со кој се одбележува
крајот на MIB датотеката. Во конкретните MIB-II датотеки, секој објект излистан
во IfEntry секвенцатаима своја објект дефиниција. Во оваа верзија на MIB ние прикажавме
само две од нив, во интерест на просторот.

21
3.2 Проширувања на SMI во верзија SMIv2

SMIv2 е дополнување на SMI објектното стебло со додавање

на snmpV2 филијала на интернет подстеблото, додавајќи неколку нови типови на
податоци и измена на голем број други работи. Слика 2-3 покажува
како snmpV2 објектите се вклопуваат во една поголемата
слика. OID за оваа нова гранка е 1.3.6.1.6.3.1.1, или
iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects. SMIv2 исто така
дефинира некои нови типови на податоци, кои се сумирани во Табела 1.
.

Слика 3. SMIv2 регистрациско стебло за SNMPv2

22
Табела 1. Нови податочни типови во SMIv2

Податочен тип Објаснување

Integer32 Исто како и INTEGER.

Counter32 Исто како и Counter.

Gauge32 Исто како и Gauge.

Unsigned32 Претставува децимална вредност во опсег од

0 до 232 - 1
Counter64 Слично како и Counter32, но неговата
максимална вредност е
18,446,744,073,709,551,615. Counter64 е
идеален за ситуации каде Counter32 може да
се постави на 0 во краток временски период.
BITS Енумерација на ненегативни битови

Дефиницијата на објектите во SMIv2 е малку променета од SMIv1. Има неколку

нови полина за опции кои што ни даваат поголема контрола за пристап до објектите,
дозволувајќи да се додаваат повеќе колони во табелата и додавање на подобро
објаснување за нив. Ова е синтаксата за дефиниција на објект во SMIv2. Оние делови
што се променети од SMIv1 е со задебелени букви.

<name> OBJECT-TYPE
SYNTAX <datatype>
UnitsParts <Optional, see below>
MAX-ACCESS <See below>
STATUS <See below>
DESCRIPTION
"Текстуалната објаснување го опишува објектот за управување."
AUGMENTS { <name of table> }
::= { <Unique OID that defines this object> }

23
3.3 Преглед на MIB-II

MIB-II е важна група за управување бидејќи секој уред кој што поддржува SNMP
мора да поддржува и MBI-II. Поради тоа, ке ги користиме објектите од MBI-II во текот на
оваа семинарска. Поради просторот нема да се оди во детали за секој објект во MIB, туку
само ќе го дефинираме подстеблото од објекти. Делот од RFC1213-MIB кој што ги
дефинира основните OIDs за mib-2 подстеблото изгледа вака:

mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }

system OBJECT IDENTIFIER ::= { mib-2 1 }
interfaces OBJECT IDENTIFIER ::= { mib-2 2 }
at OBJECT IDENTIFIER ::= { mib-2 3 }
ip OBJECT IDENTIFIER ::= { mib-2 4 }
icmp OBJECT IDENTIFIER ::= { mib-2 5 }
tcp OBJECT IDENTIFIER ::= { mib-2 6 }
udp OBJECT IDENTIFIER ::= { mib-2 7 }
egp OBJECT IDENTIFIER ::= { mib-2 8 }
transmission OBJECT IDENTIFIER ::= { mib-2 10 }
snmp OBJECT IDENTIFIER ::= { mib-2 11 }

mib-2 e дефинирана како iso.org.dod.internet.mgmt.1, или во нумеричка нотација

1.3.6.1.2.1. од овде може да се забележи дека системска група е mib-2 1, или
1.3.6.1.2.1.1, итн. Слика 4 го покажува MBI-II подстеблото на mgmt гранката од стеблото.

24
 Слика 4. MBI-II подстебло

Табела 2. Во кратки црти ја опишува секоја група за управување, дефинирана во

MIB-II.

Гранка од
стеблото OID Објаснување
system 1.3.6.1.2.1.1 Дефинира листа на објекти за системски операции, како што
е системското време, контакт со системот и системско име.

interfaces 1.3.6.1.2.1.2 Го чува статусот на секој интерфеј од ентитет кој се

управува. Групата од интерфејси следи кој интерјеси
работат а кој не, испраќање, примање, грешки, ненавремено
пристигнување итн.

ip 1.3.6.1.2.1.4 Чува информации од повеќе аспекти за IP вклучувајќи и IP

рутирање.

icmp 1.3.6.1.2.1.5 Чува работи како што се ICMP грешки и сл.

tcp 1.3.6.1.2.1.6 Покрај другите работи ја чува состојбата на TCP конекциата

(пр. Затворена, ”слуша”, synSent итн.).

udp 1.3.6.1.2.1.7 Чува статистички информации за UDP, примени датаграми,

испратени датаграми и сл.

egp 1.3.6.1.2.1.8 Чува различни статистики за Exterior Gateway Protocol (EGP)

и ја чува EGP табелата на соседи.

transmission 1.3.6.1.2.1.10 Во оваа група не се дефинираат објекти, но служи за други

надворешни MIBs и се дефинираат преку оваа гранка.

snmp 1.3.6.1.2.1.11 Ги мери перформансите на SNMP имплементацијата на

управуваните ентитети и чува работи како што е бројот на
SNMP пакети кои се испратени и примени.

25
4. SNMP Операции

Досега дискутиравме како SNMP ги организира информации, не досега немавме

спомнато како се собираат тие информации кои подоцна ни се потребни за управување
со мрежата. Во овој дел ќе обврнеме внимание баш на тој дел од SNMP и како го прави
сето тоа.

Protocol Data Unit (PDU) е формат на порака кој менаџерите и агентите го користат за
испраќање и примање на информациите. Секоја од овие SNMP операции има стандарден
PDU формат.

• get
• getnext
• getbulk (SNMPv2 и SNMPv3)
• set
• getresponse
• trap
• notification (SNMPv2 и SNMPv3)
• inform (SNMPv2 и SNMPv3)
• report (SNMPv2 и SNMPv3)

4.1 get операција

Get барањето се иницира од страна на станицата, која сто испраќа барање до

агентот. Агентот го прима барањето и го обработува. Некои од уредите може и да не
бидат во состојба да одговорат на барањето. Ако агентот успешно ги собере бараните
информации, тогаш испраќа getresponse до станицата. Овој процес е прикажан на
сликата подолу.

Слика 5. Секвенца на get барање

26
 Како агентот знае што станцата бара од него? Во делот за get барањето се
вклучува променлива за биндање. variable binding, или varbind, е листа од MIB објекти кои
што овозможуваат да се види што точно бара испраќачот на барањето. Еве еден пример
како би изгледало:

$ snmpget cisco.ora.com public .1.3.6.1.2.1.1.6.0

system.sysLocation.0 = ""

За дадениов случај се работи на UNIX хост. Командата е snmpget, значи се работи

за get операција. Главна нејзина задача е да ги собере податоците за управување
користејќи get барање. Се задава со три аргументи на командна линија: името на уредот
кој што сакаме да го пребаруваме (cisco.ora.com), read-only текстуална низа како
заедница (public), и OID на тоа што сакаме да “собереме” (.1.3.6.1.2.1.1.6.0). Aко се
потсетиме на предходната табела ќе видиме дека 1.3.6.1.2.1.1 е системска група, но има
уште двa integer броеви на крајот од OID .6 и .1. .6 е MBI променлива која што сакаме да
ја пребаруваме, нејзиното име е sysLocation. Во овој случај сакаме да провериме каде е
системската локација во cisco рутерот. Како што се гледа од одговорот
(system.sysLocation.0 = ""), системската локација на овој рутер моментално не е
поставена на ништо. Истотака одговорот од snmpget е во исти формат како и барањето,
OID=вредност.

4.2 getnext операцијата

getnext операцијата овозможува да се издадат низа од команди за да се добијат

група на вредности од MIB. Со други зборови, за секој MIB објект сакаме да добиеме
информации , за затоа се креираат посебни getnext барање и getresponse. Getnext
командата го изминува стеблото по лексикографски ред. Бидејќи OID е низа од цели
броеви, тоа е лесно за агентот да започне со коренот од неговото SMI објектно стебло
и оди надоле по стеблото се додека не го најде OID што го бара. Оваа форма
на пребарување е наречен depth-first или пребарување најпрво по
длабочина. Кога станиците ќе добијат одговор од агентот за getnext командата дека се
издала, тогаш се издава друга getnext команда. Настаните се одвиваат по овој ред додека
агентот не врати грешка или пак дека е достигнат крајот на MIB и
дека нема повеќе објекти за изминување.

Ако го погледнеме следниов пример, ќе може да се види ова однесување во

акција. Овој пат ќе се користи командата наречена snmpwalk. Оваа команда само ја
олеснува getnext постапката за нас. Тоа се повикува исто како snmpget командата, а за
примеров ќе специфицираме од која гранка да започне (во овој случај, од системската
група):

27
$ snmpwalk cisco.ora.com public system
system.sysDescr.0 = "Cisco IOS Software, C2600 Software (C2600-IPBASE-M),
Version 12.3(8)T3, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2004 by Cisco Systems, Inc.
Compiled Tue 20-Jul-04 17:03 by eaarmas"
system.sysObjectID.0 = OID: enterprises.9.1.19
system.sysUpTime.0 = Timeticks: (27210723) 3 days, 3:35:07.23
system.sysContact.0 = ""
system.sysName.0 = "cisco.ora.com"
system.sysLocation.0 = ""
system.sysServices.0 = 6

getnext секвенцата враќа седум MIB променливи. Секој објект е дел од

системската група како што е дефинирано во RFC 1213. Getnext се базира на концептот
од лексикографско подредување на MIB објектното подредување. Ова подредување е
многу поедноставно поради тоа што секој јазел од стеблото си има свој број. За да се
разбере ова ќе почнеме од коренот на стеблото и ќе продолжиме надолу до ситемскиот
јазел.

За да стигнеме до систем групата (OID 1.3.6.1.2.1.1), ќе започнеме од коренот на

објектното стебло и ќе одиме надолу до самиот самиот јазел. Слика 6 ја покажува
логичката прогресија на патот од коренот до јазелот кој претставува систем групата на
објекти. На секој јазел во стеблото, ја посетуваме гранката со најмал број. Поради тоа, на
почеток кога сме кај коренот продолжуваме кај ccitt. Овој јазел нема свои “деца” јазли, па
затоа се одикај iso јазелот. Бидејќи iso свои “деца” јазли одиме кај org. овој процес
продолжува додека не стигнеме до system јазелот. Бидејќи секоја гранка си има свој број
(ccitt(0) iso(1) join(2), на пример), агентот нема проблем да “патува” по оваа структура се
додека не стигне до system јазелот. Ако беше потребно да се оди понатаму ќе
продолжевме со system.1 (system.sysLocation), system.2, итн со другите објекти во систем
групата на објекти.

Со следнава команда :

$ snmpwalk -v 1 -c public 127.0.0.1 system

Се добива овој резултат доколку гледаме како се изминува стеблото.

28
 Слика 6. Изминување на MIB стеблото

4.3 getbulk операција

SNMPv2 дефинира и getbulk операција, која што овозможува управување со

апликациите со цел да добие голем број на информации оддеднаш. Стандардната get
операција може да прифати повеќе од еден MIB објект, меѓутоа големината на пораките е
ограничена од страна на сособноста на агентот. Доколку агентот не може да ги врати сите
одговори, тогаш враќа грешка без никакви податоци. getbulk операцијата, од друга страна,
му кажува на агентот да испрати онолку одговори колку што можеда пренесе самиот тој.
Ова значи дека се возможни и некомплетни одговори. Две полина мора да бидат
подесени кога се користи getbulk командата за да се прифатат првите N објекти со
едноставната getnext операција. max-repetitions ни кажува дека getbulk командата ќе
направи M getnext операции за прифаќање на останатите објекти. Слика 7 ја прикажува
секвенцата на getbulk командата помеѓу станицата и агентот.

29
 Слика 5. Секвенца на getbulk барање

На сликата се гледа дека се испраќа getbulk барање со три различни променливи:

sysDescr, ifInOctets и ifOutOctets. Вкупниот број на променливи е даде со формулата

N + (M * R)

Каде што N е бројот на неповторувања (во случајов 1, бидејќи sysDescr е

еднинствен скаларен објект), M е max-repetitions, т.е максимален број на повторувања (ќе
го поставиме на 3) и R е број на нескаларни објекти кои се бараат ( во примеров 2,
бидејќи ifInOctets и ifOutOctets се двете нескаларни). За овој пример со вакви подесувања
се добива 1 + (3 * 2) = 7, што значи вкупниот број на биндувани променливи кои што може
да се вратат со getbulk барање.

Net-SNMP пакетот доаѓа со команди за извршување на getbulk барања. Ако ја

извршиме оваа команда користејќи ги сите параметри кои што ги дискутиравме
претходно, би изгледало вака:

$ snmpbulkget -v2c -c public -Cn1 -Cr3 linux.ora.com sysDescr ifInOctets ifOutOctets

system.sysDescr.0 = " Linux snort 2.4.7-10 #1 Thu Fev 24 17:27:27 EDT 2011
i686 unknown "
interfaces.ifTable.ifEntry.ifInOctets.1 = 70840
interfaces.ifTable.ifEntry.ifOutOctets.1 = 70840
interfaces.ifTable.ifEntry.ifInOctets.2 = 143548020
interfaces.ifTable.ifEntry.ifOutOctets.2 = 111725152
interfaces.ifTable.ifEntry.ifInOctets.3 = 0
interfaces.ifTable.ifEntry.ifOutOctets.3 = 0

Бидејќи getbulk е SNMPv2 команда, потребно е да се напомене на snmpbulkget да

користи SNMPv2 PDUсо -v2c опции. Параметрите N и M се поставуваат со -Cn1 и -Cr3
опциите. Се забележува дека командата враќа седум одговори, еден за sysDescr и по три
за ifInOctets и ifOutOctets.

30
За да погледнеме во резултатот треба да се изврши командата:

$ ./snmpbulkget -v2c -Cn1 -Cr2 127.0.0.1 -c public sysDescr sysContact

4.4 set операција

Set командата се користи за промена на вредностите на управуваните објекти или

за креирање на нов ред во табелата на објекти. Објектите кои се дефинираат во MIB како
read-write или read-only може да се креираат со оваа команда за станиците е овозможено
да се постават повеќе од еден објект во исто време.

Слика 8 ја покажува секвенцата на извршување на set операцијата. Слично е како

и на претходните команди кои што ги погледнавме, но се менува нешто во самата
конфигурација на уредот. Во следниов дел ќе погледнеме како изгледа set командата во
акција. Следниов пример ја бара променливата sysLocation и ја поставува нејзината
вредност.

$ snmpget cisco.ora.com public system.sysLocation.0

system.sysLocation.0 = ""
$ snmpset
cisco.ora.com private system.sysLocation.0 s "Atlanta, GA"
system.sysLocation.0 = "Atlanta, GA"
$ snmpget cisco.ora.com public system.sysLocation.0
system.sysLocation.0 = "Atlanta, GA"

Слика 8. Секвенца на извршување на set командата

31
 Првата команда е во тесна врска со get командата, која што ја прикажува
моменталната вредност на sysLocation променливата. Во еден од претходните примери,
видовме дека таа не е поставена, исто како што е слуќајот и сега. Втората команда е
snmpset. За оваа команда е потребен хостот read-write текстуалната низа (private), и
променливата која што сакаме да ја поставиме (system.sysLocation.0), заедно со нејзината
нова вредност (s "Atlanta, GA"). s му кажува на snmpset дека вредноста ќе биде стринг и
"Atlanta, GA" е новата вредност за тоа. Како знаеме дека за sysLocation е потребна
текстуална вредност? Бидејќи дефиницата од sysLocation во RFC 1213 изгледа вака:

sysLocation OBJECT-TYPE
SYNTAX DisplayString (SIZE (0..255))
ACCESS read-write
STATUS mandatory
DESCRIPTION
"Физичката локација на овој јазел (пр., 'telephone closet,
3rd floor')."
::= { system 6 }

SYNTAX за sysLocation е DisplayString (SIZE (0..255)), што значи дека е стринг со

255 максимален број на карактери. snmpset командата откако ќе успее ја враќа новата
вредност за sysLocation. Но за да се потврди, се извршува и последната snmpget
команда. Можно е да се постават повеќе од еден објект истовремено, меѓутоа ако еден од
тие не успее тогаш нема да успееат ниту едно од поставувањата.

За да се види резултат на конзола се пишува командата:

$ snmpset -v 1 -c private 127.0.0.1 sysContact.0s \ snmp@vagrant.org

32
4.5. get, getnext, getbulk, и set Error одговори

Одговорите кои пренесуваа грешки ни помагаат да се одлучиме дали нашето get

или set барање било исправно пренесено до агентот. get, getnext, getbulk, и set
операциите може да вратат пораки за грешка како што е прикажано на табелата 3,
подолу.

Табела 3. SNMPv1 error пораки

SNMPv1 пораки за
грешки Објаснување
noError(0) Значи дека нема проблеми со барањето.

tooBig(1) Одговорот на вашето барање било премногу долго за да се

одговори со еден одговор.
noSuchName(2) Агентот е прашан за get или set на OID кој што не може да го
најде или тоа OID не ни постои.
badValue(3) read-write или write-only објект бил поставен со несоодветна
вредност.
readOnly(4) Оваа грешка генерално и не се користи, еквивалентна на оваа е
noSuchName грешката.
genErr(5) Ова е генерална грешка, која се јавува ако не се појави никоја од
предходните а сепак има некој проблем.

33
4.6 SNMP Traps

trap е начин на кој агентот и кажува на станицата дека се случило нешто лошо.

Слика 9. Trap секвенца

Софтвер за управување со мрежата

Има повеќе SNMP софтверски пакети кои се достапни,почнувајќи од програмски

библиотеки кои што овозможуваат самостојно да се ги изградиме нашите услуги
(користејќи Perl, C/C++, или Java), па се до скапи и комплетни платформи за управување
со мрежата. Во овој дел ќе зборување за начесто користените пакети. Така софтверот
може да го поделиме на пет категории:

• SNMP агенти
• станици
• менаџери
• Trend analysis software
• Supporting software

За жал, одлуката за она што ни е потребно за работа не е така едноставна како што е
земање програма за секоја категорија. Ако имаме мала мрежа и сакаме да градиме свои
алатки, тогаш веројатно не ни се потребни комплексни станици. Дали ни е
потребно тренд-софтвер за анализа зависи очигледно од тоа дали сте заинтересирани
за анализа на трендови во вашата мрежа. Достапните производи зависат
од платформите за кои сме заинтересирани. Минимумот можеме да го постигнеме
со SNMP агентот кој е на уредот и некој софтвер кој што може да пристапи до
вредностите од тој уред (со користење на SNMP get операцијата). Иако ова е минимална
конфигурација, тоа е доволно за да се почне со работа, а истотака може да се добие и
слободен софтвер.

34
 Како што објаснивме претходно, агентот е софтвер кој што ги контролира сите SNMP
комуникации кои што се одвиваат со SNMP-базираните уреди. Во некои уреди, како што
се Cisco рутерите, софтверот на агентот е изграден во самиот уред и не бара посебна
инсталација. На други платформи, можно е да треба да се инсталира агент како
дополнителен софтверски пакет.

Пред да се види каков тип на агент ни е потребен , мора да се истражи какви типови
на уреди се користат во мрежата и какви типови на информации сакаме да добиваме од
уредите. Некои агенти се многу едноставни и враќаат само ограничен број на
информации, а други пак може да вратат цело “богатство” од информации. За почеток,
треба да се одлучи какви информации треба да се добиваат од серверите (Unix, Windows,
итн.) или од мрежните уреди (рутери, свичеви итн.). Генерално, мрежните уреди
обезбедуваат повеќе информации отколку серверите. Од друга страна, мрежните уреди
не може да се надградуваат така лесно, бидејќи мрежниот хардвер нема диск-базирана
работна околина. Ова го обврзува корисникот од тоа да прави модификации на агентот
или пак да го надградува. Во следнава табела имаме листа на неколку SNMP агенти .

Табела 4. SNMP агенти

AdventNet SNMP Agent(s) http://www.adventnet.com

Concord eHealth SystemEDGE http://www.concord.com
HP Extensible SNMP Agent http://www.openview.hp.com
MG-SOFT Master Agent http://www.mg-soft.com
Microsoft http://www.microsoft.com
Net-SNMP (formerly the UCD-SNMP project) http://net-snmp.sourceforge.net
Sun Microsystems http://www.sun.com
SNMP Research International http://www.int.snmp.com

5.1. Станици за управување со мрежата

Овој термин се користи за софтверски пакет кој што содржи повеќе апликации во еден
соодветен производ. Во овој дел ќе зборуваме за софтверот за овие станици за
управување со мрежата, кој што претставува еден од најважните делови во самото
управување на мрежата. Без нив софтверскиот агент не би имал никаква корист. Овие
станици дозволуваат да имаме комплетен преглед врз мрежата, вклучувајќи ги серверите,
рутерите, свичевите, и десктоп машините. Во повеќето случаеви, овој приказ може да
биде графички. Овие пакети се високо конфигурабилни и работат речеси во било која
мрежна околина. Оваа слобода, често доаѓа со голема цена и збунувачки процес на
инсталација. Дел од продуктите повеќе се фокусираат на управувањето од мрежната

35
страна (пр. на уредите како што се рутерите, хуб-овите и свичевите). Други пак, одат еден
чекор понапреди дозволуваат да се уредуваат серверите и работните станици за
полесно да се интегрираат со станиците. Исто така треба да се знае дека поголемите
софтверски пакети се за поголеми, покомплицирани мрежи и дека може да се набават и
триал верзии пред да се одлучиме за конечната верзија што ќе се користи. Во следнава
табела имаме комерцијални и слободен софтвер за станиците.

Табела 5. Станици за управување

со мрежата

HP OpenView http://www.openview.hp.com
SolarWinds http://www.solarwinds.net
IBM Tivoli http://www.ibm.com/software/tivoli
Castle Rock SNMPc http://www.castlerock.com
BMC Software http://www.bmc.com
Computer Associates Unicenter http://www.ca.com
Veritas NerveCenter http://www.veritas.com
Micromuse Netcool http://www.micromuse.com
GxSNMP http://www.gxsnmp.org
Tkined http://wwwhome.cs.utwente.nl/~schoenw/scotty
OpenNMS http://www.opennms.org
SNMPSTAT monitoring system http://snmpstat.sourceforge.net
Big Brother http://www.bb4.org
Mercury SiteScope http://www.mercury.com
Ipswitch WhatsUp http://www.ipswitch.com/products/whatsup/index.html
Just For Fun (JFF) NMS http://www.jffnms.org
Nagios http://www.nagios.org
NagMIN http://nagmin.sourceforge.net

5.2 Елемент - менаџер

Овие софтверски пакети се насочени кон одреден тип на произведители или

функција, на пример, менаџер може да биде производ кој што се фокусира на управување

36
со модемот. Пред купување на таков пакет, треба добро да се проучи моменталната
средина, како е начинот на раст на истата и она што производителите моментално
користат или каква е веројатноста да се користи во иднина. Бидејќи голем број од овие
производи ги специфицираат самите производители, лесно може да се случи да се купи
нешто за кое што сме имале поголемо очекување т.е да не ги оправда нашите очекувања.
На пример, CiscoView (дел од CiscoWorks) е одличен софтвер, кој може да направи многу
добри работи како што прикажување на информации за рутерот. Како и да е, ако
вклучиме поголем број на Nortel уреди пред инсталирањето на овој уред, тогаш тој нема
да биде во позиција да ги даде унифициран поглед на мрежата. Некои пакети
дозволуваат да се управува со нивната конкурентска опрема, на пример, елементот
менаџер кој што ги следи свичовите може да ги чува и свичовите од конкурентските
производители. Пред да се купи од овие производи, треба добро да се истражи каде е
главата на мрежата. Во следнава табела имаме листа од достапни манаџери.

Табела 6. менаџери

Sun Management Center http://www.sun.com/sunmanagementcenter

CiscoWorks 2000 http://www.cisco.com
3Com Total Control http://www.3com.com
Aprisma (now owned by Concord) http://www.aprisma.com
Nortel http://www.nortelnetworks.com/solutions/net_mang

5.3. Анализа

Кога ќе треба да се соочиме со повеќето мрежни проблеми, добро би било да

имаме некоја историја за настаните предходно со цел да ни даде идеја кога работите
тргнале на лошо. Ова ни овозможува да се вратиме наназад и да направиме преглед за
тоа што се случувало пред да настане проблемот и можеби да се спречи појава на таков
проблем во иднина. Ако сакаме да откриеме и дијагностицираме проблемот пред да се
појави, потребно е да знаеме што значи нормално да работи нашата мрежа преку разни
графици, статистики и сл. Иако голем број од поголемите пакети вршат анализа тие може
да бидат значително тешки за употреба, дури и може да не ги даваат оние информации
што ни се потребни. Следнава табела дава приказ на неколку пакети за анализа.

37
Табела 7. Анализа

Concord eHealth http://www.concord.com

Trinagy (formerly DeskTalk Systems, Inc.) TREND http://www.desktalk.com
MRTG http://www.mrtg.org
Cricket http://cricket.sourceforge.net
InfoVista http://www.infovista.com
RTG http://rtg.sourceforge.net
SNARLSNMP http://snarl-snmp.sourceforge.net

5.4 Софтвер за поддршка

Софтверот за поддршка ги вклучува сите видови на нешта кои се користат во

комбинација со софтверските пакети кои ги наведовме предходно. Дел од тие пакети
може да се користат за пишување на самостојни SNMP апликации. Следнава табела
содржи листа на неколку софтверски пакети за поддршка. Повеќето од нив се слободни и
може да се користат и од корисници кои немаат големо искуство.

Табела 8. Софтвер за поддршка

Perl http://www.perl.com

http://www.perl.org
SNMP framework for Python http://pysnmp.sourceforge.net
SNMP Support for Perl http://www.switch.ch/misc/leinen/snmp/perl

http://www.cpan.org
pwSNMP Visual Basic http://sourceforge.net/projects/websignoff

38
Табела 8. Софтвер за поддршка

WILMA ftp://ftp.ldv.e-technik.tu-
muenchen.de/dist/WILMA/INDEX.html
Net-SNMP C Library http://net-snmp.sourceforge.net
Net-SNMP Perl Module http://www.cpan.org/authors/id/GSM
A3Com http://www.kernel.org/software/A3Com
SNMP++ http://www.agentpp.com
Netcool http://www.micromuse.com
Network Computing Technologies http://www.ncomtech.com
Trap Receiver

Заклучок

39
 Во овој дел ќе погледнеме што имавме пред да користиме SNMP и откако ќе го
ставиме во пракса. На пример имаме, 100 машини кои работат на различни оперативни
системи. Неколку се податочни сервери, неколку ќе бидат принт сервери, а на други
работи софтвер кои што ги верифицира трансакциите на кредитните картички, а
останатите се персонални работни станици. Како додаток нормално се користат различни
свичеви и рутери за формирање на мрежата. А Т1 колото ја поврзува компанијата со
Интернет, а приватна конекција работи за системот за верификација на кредитните
картички.

Што ќе се случи кога имаме проблем со серверите кои ги чуваат податоците? Ако
тоа се случува во средината работна недела, луѓето кои што ја користат мрежата ќе
приметат и ќе го известат администраторот да го поправи проблемот. Но што доколку се
случи проблем кога веќе никој нема во самата компанија? Што ќе се случи доколку
системот за верификација на кредитните картички “падне” во 22 часот во петок навечер и
не може да се среди до понеделник наутро? Ваквите проблеми би ја чинело компанијата
илјадници, па и милиони денари.

Во вакви случаи може да помогне SNMP. Наместо да се чека некој да примети

дека има проблем во мрежата и да се извести администраторот на мрежата да ја поправи
грешката, SNMP овозможува следење на постојаноста на мрежата дури и кога нема никој
во компанијата. На пример, може да се открие дека бројот на “лоши” пакети кои што
доаѓаат од некој интерфејс на одреден рутер се зголемуваат, што навестува дека имаме
проблем во рутерот. Со SNMP би добиле предходно изестување за тоа и би ја одбегнале
оваа непријатна ситуација.

Референци

[1] RFC index at Ohio State University (http://www.cse.ohio-

state.edu/cs/Services/rfc/index.html).

[2] essential-snmp-second-edition, Douglas Mauro, Kevin Schmidt 2005

[3] network-management-mibs-and-mpls-principles-design-and-implementation
Stephen B. Morris, 2004

40