Формати і імена об'єктів SNMP MIB

Для іменування змінних бази MIB і однозначного визначення їх форматів використовується додаткова специфікація, звана SMI - Structure of Management Information. Наприклад, специфікація SMI включає в якості стандартного ім'я IpAddress і визначає його формат як рядок з 4 байт. Інший приклад - ім'я Counter, для якого визначений формат у вигляді цілого числа в діапазоні від 0 до 232-1.

При описі змінних MIB і форматів протоколу SNMP специфікація SMI спирається на формальну мову ASN.1, прийнятий ISO як нотації для опису термінів комунікаційних протоколів (правда, багато комунікаційні протоколи, наприклад IP, PPP або Ethernet, обходяться без цієї нотації). Нотація ASN.1 служить для встановлення однозначної відповідності між термінами, узятими із стандартів, призначених для людського використання, і тими даними, які передаються в комунікаційних протоколах апаратурою. Досягається однозначність дуже важлива для гетерогенного середовища, характерною для корпоративних мереж. Так, замість того щоб вказати, що деяка змінна протоколу являє собою ціле число, розробник протоколу, що використовує нотацію ASN.1, повинен точно визначити формат і допустимий діапазон змінної. В результаті документація на MIB, написана за допомогою нотації ASN.1, може точно і механічно транслюватися у форму кодів, характерних для повідомлень протоколів.

Нотація ASN.1 схожа на інші метамови, наприклад нормальну Бекусову форму, використовувану при описі мов програмування, зокрема Алгол. Нотація ASN.1 підтримує базовий набір різних типів даних, таких як ціле число, рядок і т. п., а також дозволяє конструювати з цих базових типів складові дані - масиви, перерахування, структури.

Існують правила трансляції структур даних, описаних на ASN.1, в структури даних мов програмування, наприклад C + +. Відповідно, є транслятори, що виконують цю роботу. Приклади описів даних за допомогою ASN.1 приведені нижче при описі протокольних блоків даних SNMP. Нотація ASN.1 широко використовується при описі багатьох стандартів OSI, зокрема моделей керованих об'єктів і структури повідомлень протоколу CMIP.

Імена змінних MIB можуть бути записані як в символьному, так і в числовому форматах. Символьний формат використовується для представлення змінних в текстових документах і на екрані дисплея, а числові імена - в повідомленнях протоколу SNMP. Наприклад, символьному імені SysDescr відповідає числове ім'я 1, а більш точно 1.3.6.1.2.1.1.1.

Складене числове ім'я об'єкту SNMP MIB відповідає повному імені цього об'єкта в дереві реєстрації об'єктів стандартизації ISO. Розробники протоколу SNMP не стали використовувати традиційний для стандартів Internet спосіб фіксації чисельних параметрів протоколу в спеціальному RFC, званому «Assigned Numbers» (там описуються, наприклад, чисельні значення, які може приймати поле Protocol пакету IP, і т. п.). Замість цього вони зареєстрували об'єкти баз MIB SNMP у всесвітньому дереві реєстрації стандартів ISO, показаному на рис. 10.

Рис. 10. Простір імен об'єктів ISO

Як і в будь-яких складних системах, простір імен об'єктів ISO має деревоподібну ієрархічну структуру, причому на рис. 6 показано тільки його верхня частина. Від кореня цього дерева відходять три гілки відповідають стандартам, контрольованим ISO, ITU і спільно ISO-ITU. У свою чергу, організація ISO створила гілку для стандартів, створюваних національними та міжнародними організаціями (гілка org). Стандарти Internet створювалися під егідою Міністерства оборони США (Departament of Defence, DoD), тому стандарти MIB потрапили в піддерево dod-internet, а далі, природно, в групу стандартів управління мережею - гілка mgmt. Об'єкти яких стандартів, створюваних під егідою ISO, однозначно ідентифікуються складовими символьними іменами, що починаються від кореня цього дерева. У повідомленнях протоколів символьні імена не використовуються, а застосовуються однозначно відповідні їм складові числові імена. Кожна гілка дерева імен об'єктів нумерується в дереві цілими числами зліва направо, починаючи з одиниці, і ці числа і замінюють символьні імена. Тому повне символьне ім'я об'єкта MIB має вигляд: iso.org.dod.internet.mgmt.mib, a повне числове ім'я: 1.3.6.1.2.1.

Група об'єктів private (4) зарезервована за стандартами, створюваними приватними компаніями, наприклад Cisco, Hewlett-Packard і т. п. Це ж дерево реєстрації використовується для іменування класів об'єктів CMIP і TMN.

Відповідно, кожна група об'єктів MIB-I і MIB-II також має крім коротких символьних імен, наведених вище, повні символьні імена і відповідні їм числові імена. Наприклад, короткий символьне ім'я групи System має повну форму iso.org.dod.internet.mgmt.mib.system, а її відповідне числове ім'я - 1.3.6.1.2.1. Частина дерева імен ISO, що включає групи об'єктів MIB, показана на рис. 11.

Рис. 11. Частина дерева імен ISO, що включає групи об'єктів MIB-I

Формат повідомлень SNMP

Протокол SNMP обслуговує передачу даних між агентами і станцією, що управляє мережею. SNMP використовує дейтаграмним транспортний протокол UDP, не забезпечує надійної доставки повідомлень. Протокол, організуючий надійну передачу дейтаграм на основі з'єднань TCP, вельми завантажує керовані пристрої, які на момент розробки протоколу SNMP були не дуже потужні, тому від послуг протоколу TCP вирішили відмовитися.

SNMP часто розглядають тільки як рішення для управління мережами TCP / IP. Хоча SNMP найчастіше і працює над UDP (він може також працювати і над TCP), він може працювати і над транспортними мережевими протоколами стека OSI - ТРО, ТР4, CNLS, а також над протоколами МАС-рівня. Зростає підтримка протоколу SNMP і в інших транспортних середовищах. Наприклад, фірма Novell почала підтримувати протокол SNMP з версії NetWare 3.11, а деякі виробники обладнання (наприклад, Bay Networks) реалізують у своїх пристроях передачу повідомлень SNMP за допомогою як IP, так і IPX.

Повідомлення SNMP, на відміну від повідомлень багатьох інших комунікаційних протоколів, не мають заголовків з фіксованими полями. Відповідно до нотацією ASN.1 повідомлення SNMP складається з довільної кількості полів, і кожне поле випереджається описувачем його типу і розміру.

Будь-яке повідомлення SNMP складається з трьох основних частин:

· версії протоколу (version)

· ідентифікатора спільності (community), використовуваного для групування пристроїв, керованих певним менеджером

· області даних, в якій власне і утримуються описані вище команди протоколу, імена об'єктів і їх значення. Область даних ділиться на блоки даних протоколу (Protocol Data Unit, PDU).

Загальний формат повідомлення SNMP в нотації ASN.1 виглядає наступним чином:

SNMP-Message:: =

SEQUENCE {

version INTEGER {

version-1 (0)

},

community

OCTET STRING,

SNMP-PDUs

ANY

}

Область даних може містити п'ять різних типів PDU, відповідних п'яти командам протоколу SNMP:

SNMP-PDUs:: =

CHOICE {

get-request

GetRequest-PDU,

get-next-request

GetNextRequest-PDU,

get-response

GetResponse-PDU,

set-request

SetRequest-PDU,

trap

Trap-PDU,

}

І нарешті, для кожного типу PDU мається визначення його формату. Наприклад, формат блоку GetRequest-PDU описаний таким чином:

GetRequest-PDU:: =

IMPLICIT SEQUENCE {

request-id

Request ID,

error-status

ErrorStatus,

error-index

ErrorIndex,

variable-bindings

VarBindList

}

Далі стандарт SNMP визначає відповідно формат змінних блоку GetRequest-PDU.

Змінна Request ID - це 4-байтове ціле число (використовується для встановлення відповідності відповідей запитам), ErrorStatus і ErrorIndex - це однобайтові цілі, які в запиті повинні бути встановлені в 0. VarBindList - це список числових імен об'єктів, значеннями яких цікавиться менеджер. У нотації ASN.1 цей список складається з пар «ім'я - значення». При запиті значення змінної повинно бути встановлено в null.

Ось приклад повідомлення протоколу SNMP, яке являє собою запит про значення об'єкта SysDescr (числове ім'я 1.3.6.1.2.1.1.1).

Рис. 12.

Як видно з опису, повідомлення починається з коду 30 (всі коди шіснадцяткові), який відповідає ключовому слову SEQUENCE (послідовність). Довжина послідовності вказується в наступному байті (41 байт). Далі слід ціле число довжиною 1 байт - це версія протоколу SNMP (в даному випадку О, тобто SNMP vl, a 1 означала б SNMP v.2). Поле community має тип string (рядок символів) довжиною в 6 байт із значенням public. Іншу частину повідомлення становить блок даних GetRequest-PDU. Те, що це операція Get-request, говорить код АТ (це значення визначене в протоколі SNMP, а не в нотації ASN.1), а загальна довжина блоку даних - 28 байт. У відповідності зі структурою блоку Getrequest-PDU, далі йде ідентифікатор запиту (він визначений як ціле 4-байтове число). Потім в блоці випливають два однобайтових цілих числа статусу та індексу помилки, які в запиті встановлені в 0. І нарешті, завершує повідомлення список об'єктів, що складається з однієї пари - імені 1.3.6.1.2.1.1.1.0 і значення null.