Опис протоколу SNMP

ВСТУП

В сушильному цеху необхідно мати 138 трекових вагонеток.

Висновки

У даному курсовому проекті задано сушіння пиломатеріалів трьох порід (ялиця, липа, осика), призначених для виробництва зовнiшнiх дверей. Задані породи мають різну вологу та розміри.

Дана камера ПАП-32 є досить продуктивна, для даного призначення висушуваного матеріалу, має оптимальну аеродинаміку, не дивлячись на її розміри забезпечує рівномірне розподілення агенту сушіння по всій довжині та висоті камери.

Згідно розрахунків щодо заданих пиломатеріалів, для виробництва необхідно 4 сушильні камери в якій потрібно по 50 ребристих калориферів, 1 вагонетка що є досить нормальним показником.

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

Протокол SNMP був розроблений з метою перевірки функціонування мережевих маршрутизаторів і мостів. Згодом сфера дії протоколу охопила і інші мережеві пристрої, такі як хаби, шлюзи, термінальні сервера, LAN Manager сервера, машини під управлінням Windows NT і т.д. Крім того, протокол допускає можливість внесення змін у функціонування зазначених пристроїв.

Основними взаємодіючими особами протоколу є агенти і системи управління. Якщо розглядати ці два поняття на мові "клієнт- сервер", то роль сервера виконують агенти, тобто ті самі пристрої, для опитування стану яких і був розроблений розглянутий нами протокол. Відповідно, роль клієнтів відводиться системам управління - мережним додаткам, необхідним для збору інформації про функціонування агентів. Крім цих двох суб'єктів в моделі протоколу можна виділити також ще два: керуючу інформацію і сам протокол обміну даними.

Для чого взагалі потрібно виробляти опитування обладнання? Іноді в процесі функціонування мережі виникає необхідність визначити певні параметри деякого пристрою, такі як, наприклад, розмір MTU, кількість прийнятих пакетів, відкриті порти, встановлену на машині операційну систему і її версію, дізнатися чи включена опція форвардинга на машині і багато іншого. Для здійснення цього якнайкраще підходять SNMP клієнти.

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

Зупинимося на тому, яку ж все-таки інформацію може отримати система управління з надр SNMP. Вся інформація про об'єкти системи - агента потримається в так званій MIB (management information base) - базі керуючої інформації, іншими словами MIB являє собою сукупність об'єктів, доступних для операцій запису-читання для кожного конкретного клієнта, залежно від структури і призначення самого клієнта. Адже не має сенсу питати у термінального сервера кількість відкинутих пакетів, так як ці дані не мають жодного відношення до його роботи, так як і інформація про адміністратора для маршрутизатора. Тому керуюча система повинна точно уявляти собі, що і у кого запитувати.

На даний момент існує чотири бази MIB:

Internet MIB - база даних об'єктів для забезпечення діагностики помилок і конфігурацій. Включає в себе 171 об'єкт (у тому числі і об'єкти MIB I).

LAN manager MIB - база з 90 об'єктів - паролі, сесії, користувачі, загальні ресурси.

WINS MIB - база об'єктів, необхідних для функціонування WINS сервера (WINSMIB.DLL).

DHCP MIB - база об'єктів, необхідних для функціонування DHCP сервера (DHCPMIB.DLL), для динамічного виділення IP адрес в мережі.

За допомогою протоколу SNMP, програмне забезпечення для управління мережевими пристроями може отримувати доступ до інформації, яка зберігається на керованих пристроях (наприклад, на комутаторі). На керованих пристроях SNMP зберігає інформацію про пристрій, на якому він працює, в базі даних, яка називається MIB.

Всі імена MIB мають ієрархічну структуру. Існує десять кореневих аліасів: 1) System - дана група MIB II містить у собі сім об'єктів, кожен з яких служить для зберігання інформації про систему (версія ОС, час роботи і т.д.). 2) Interfaces - містить 23 об'єкта, необхідних для ведення статистики мережевих інтерфейсів агентів (кількість інтерфейсів, розмір MTU, швидкість передачі, фізичні адреси і т.д.). 3) AT (3 об'єкта) - відповідають за трансляцію адрес. Більш не використовується. Була включена в MIB I. Прикладом використання об'єктів AT може послужити проста ARP таблиця,відповідності фізичних (MAC) адрес мережевих карт IP адресами машин. У SNMP v2 ця інформація була перенесена в MIB для відповідних протоколів. 4) IP (42 об'єкта) - дані про проходять IP пакетах (кількість запитів, відповідей, відкинутих пакетів). 5) ICMP (26 об'єктів) - інформація про контрольні повідомленнях (вхідні / вихідні повідомлення, помилки і т.д.). 6) TCP (19) - все, що стосується однойменного транспортного протоколу (алгоритми, константи, з'єднання, відкриті порти тощо). 7) UDP (6) - аналогічно, тільки для UDP протоколу (вхідні / вихідні датаграми, порти, помилки). 8) EGP (20) - дані про трафік Exterior Gateway Protocol (використовується маршрутизаторами, об'єкти зберігають інформацію про прийнятих / відісланих / відкинутих кард). 9) Transmission - зарезервована для специфічних MIB. 10) SNMP (29) - статистика по SNMP - вхідні / вихідні пакети, обмеження пакетів за розміром, помилки, дані про оброблені запитах і багато іншого.

Кожен з них представимо у вигляді дерева, що росте вниз, (система до болю нагадує організацію DNS). Наприклад, до адреси адміністратора ми можемо звернутися за допомогою такого шляху: system.sysContact.0, до часу роботи системи system.sysUpTime.0, до опису системи (версія, ядро та інша інформація про ОС): system.sysDescr.0. З іншого боку ті ж дані можуть задаватися і в точковій нотації. Так system.sysUpTime.0 відповідає значення 1.3.0, так як system має індекс "1" в групах MIB II, а sysUpTime - 3 в ієрархії групи system. Нуль в кінці шляху говорить про скалярному типі збережених даних. Посилання на повний список (256 об'єктів MIB II). У процесі роботи символьні імена об'єктів не використовуються, тобто якщо менеджер запитує у агента вміст параметра system.sysDescr.0, то в рядку запиту посилання на об'єкт буде перетворена в " 1.1.0 ", а не буде передана " як є". Далі ми розглянемо BULK -запит і тоді стане ясно, чому це настільки важливо. На цьому ми завершимо огляд структури MIB II і перейдемо безпосередньо до опису взаємодії менеджерів (систем управління) та агентів.

Дата добавления: 2015-08-31