Bog Bos SNMP, MIB, RMON

Предишен ◈ Следващото
Като пример, използвайки SNMP са описани:
  • Мониторинг на мрежата чрез rrdtool
  • Мониторинг на мрежата чрез MRTG
  • Пакет нетна-SNMP (бивш UCD-SNMP)
  • графична обвивка - tkmib
В спецификацията SNMP архитектура определя следните роли контролни субекти (единица):
  • управление на мрежата станция (ЗНС, Станция за управление на мрежата) - подканва да изтегли или променя данните и обработва отговори
  • агент - обект за управление, интегриран в устройството или програмата; реагира контролна станция чрез извличане на данни от устройството, или извършва контрол действие на устройството; стандарт не определя механизъм на агента, например, са агенти, които, при обработката на искане изпращането на заявки подчинени агенти
  • Proxy Agent - изпраща искания SNMP за обработка на други агенти не разбират съдържанието на искането

Това е наистина ролята, защото същата програма може да действа като агент за получаване на искания от майстор пункт за управление и контрол на гарата, за да бъдат подчинени агенти. При изграждането на системите за йерархични управление, необходими за контролиране на контролната станция. В такъв интегрираното управление на станция агент и той се нарича тема "двойно предназначение" (двойна роля лице).







Главен агент (майстор-агент) и подизпълнител на комуникационния протокол (AgentX, DPI, SMUX, излъчва).

Протокол взаимодействие между станцията за управление и агент на базата на съобщения PDU (Единица Protocol), включен в Документ за транспорт протоколни пакети. Всяко съобщение съдържа команди за управление станция, за да прочетете променливи стойности в команда за събиране на информация или промяна на променлива стойност в устройството за управление.

Обектите могат да имат скаларен тип, е таблица на редове или таблици (таблици не могат да бъдат вложени). Всяка таблица има точно един подчинен обект от тип низ. Един обект от тип низ маса се състои от един или повече скаларни обекти. Променливите могат да бъдат само случаи на скаларни обекти. Променлива идентификатор се състои от две части: идентификатор на обект, пример за което е и наставка. За скаларна обект, който не е в съответствие наставка променлива е числото 0, т.е. скаларен тип обект има точно един пример. За обекти, които са част от една линия на масата, променлива идентификатор наставка е индекс низ маса на едно или повече прости идентификатори, разделени с точки. Т.е. обект на маса тип низ може да има множество случаи, се идентифицира по уникален индекс. Индекс е посочено в таблицата описание низ като списък от идентификатори на обекти скаларни стойности, които копия (т.е., променливи) еднозначно идентифициране на ред маса, и по този начин всяка клетка на таблицата. Пример скаларна обект:
  • ЕВРОВОК Обект: system.sysDescr
  • Променлива ЕВРОВОК: system.sysDescr.0
  • стойност на променливата: "APC Embedded PowerNet SNMP Agent"
Пример маса (ARP таблица):
  • ЕВРОВОК маса: at.atTable
  • ЕВРОВОК маса ред: at.atTable.atEntry
  • индекс ред: atIfIndex, atNetAddress
  • дръжки обекти, които изграждат низ:
    • at.atTable.atEntry.atIfIndex
    • at.atTable.atEntry.atPhysAddress
    • at.atTable.atEntry.atNetAddress
  • пример на променлива: at.atTable.atEntry.atPhysAddress.192.168.0.1
  • Примерни стойности на тази променлива: 00: C0: 34: 00: 00: А0

Средство за третиране списък на обекти и техните видове се поставя в него от страна на строителя, и контролната станция получава тази информация, с помощта на MIB (за управление на информацията в базата). MIB - текстов файл с описание на наличните обекти и техните видове на език, определен от стандартната SMI (Структура и Идентификация на управление на информацията). Агентът не използва този файл по време на работа. MIB е разделена на модули, някои модули са направени под формата на стандарти, някои от модулите са разработчиците на оборудването.

Developer успя оборудване (разработчик агент) трябва да представи списък на поддържаните модули агент. В описанието на модула се уточни кои обекти са длъжни да прилагат, и какво - не. При описанието на агента може да посочи какви модули го поддържа, колко и какви модификации.

SNMP административен модел определя удостоверяване и алгоритми за криптиране, ключове, използвани, метод за удостоверяване станция за управление и агент (или по-точно неговото настоящата бизнес контекст), метод за определяне правото на достъп до информация. PDU се обработва изцяло в рамките на една връзка. Context позволява на агента да се разграничат един контролен го от друго устройство. Името на общността SNMPv1 и SNMPv2c (име общност) определя всички параметри на административен модел (контекст, автентичността и алгоритми за криптиране, и т.н.). В повечето приложения, тя се използва (стандартна употреба на наименованието не е на общността), както е паролата (изпратен в ясни и лесно прихванати и подправени), както и за определяне на контекста (името на общността определя кои от наличните обекти - MIB View), не се използва шифроване. Обикновено, когато конфигурирате агент определя от индивидуалния Името на общността за четене на обекти, звукозаписни обекти и изпращане капан. Начин да се посочва името на общността, не е стандартизирана.

Realnoispolzuemym първия набор от стандарти, SNMP са RFC-1155, RFC 1156 и RFC-1157, за определяне на SMI. SNMP протокол и Интернет MIB. RFC-1212 въвежда за изясняване SMI стандарт (въведени изрично описание низ индекс алгоритми описано вмъкване и изтриване на таблица редове). RFC-1213 прави промени в Интернет MIB (MIB-II), базирани на новата SMI. RFC-1215 добавя способността да се опише капана. RFC-1441, за да RFC-1552 дефинира нова версия на SMI, SNMP протокол и Интернет MIB. Освен това е установено, сигурност административен модел Партийно-. За съжаление, това се оказа твърде трудна за изпълнение, към една и съща разногласия сред разработчиците. В резултат на това той е бил приет RFC-1901 и RFC-1908 съчетаят новата версия на SMI, протокола SNMP и административния модел Интернет MIB SNMPv1 (общността). Освен това, тъй когато агентът не се използва MIB и SMI, то е възможно да се използват различни комбинации от стара и нова MIB, SMIv1 и SMIv2, SNMPv1 и SNMPv2 протокол. Например, може да се вземат старата MIB, го пренапише да SMIv2 за контролна станция общуването с агенти, използващи SNMPv2 протокол (освен капан). По същия начин, типичен пример е използването във връзка с протокола SNMPv1 MIB, написани за SNMPv2 (обаче, това е невъзможно да се използват редица 64-битова).







Основните разлики от SNMPv2c SNMPv1:
  • Не можете да използвате тирета в имената (и как MIB-2?!)
  • текстови споразумение вместо просто производния клас
  • Добавена е възможност да се уточни на звената за описване на обекти
  • 64-битови цели числа и Counter преименуване Counter32 т.н.
  • формално описание на изискванията за прилагане на агенти
  • формално описание на изпълнението на конкретното средство
  • ДОСТЪП заменен от MAX-ДОСТЪП, не можете да използвате за запис само-, имаше разрешения за четене създават
  • задължителен статут, се заменя със ток, отстранява състоянието на избор
  • копия на индексиране могат да бъдат описани чрез увеличава
  • Премахнато Вид NetworkAddress
  • внимателно определя възможността за създаване и изтриване на редове от таблицата
  • капан заменя на уведомяване (нотификация), Trap PDU в SNMPv2-Trap PDU
  • променен номерът на версията в съобщението, носещ PDU

MIB описание е разделена на модули, като всеки модул обикновено се поставя в отделен текстов файл съдържа следната структура:

станция за контрол могат да съставят MIB модел на един или повече модули. Макроси, обекти и видове (без съединение), както са определени в един модул MIB, могат да бъдат внесени в друг модул MIB. Списък на изнесени обекти могат да бъдат определени от износ операторът. Имена (дескриптори) на модулите трябва да са уникални. Прости описания в рамките на една и съща единица трябва да бъдат уникални. Различни версии на един и същ модул трябва да имат едно и също име.

Всеки модул съдържа MIB
  • Модул Описание (задължително и точно един): МОДУЛ-ИДЕНТИЧНОСТ
  • споразумение текстова (синоними на предварително дефинирани типове данни): текстова-КОНВЕНЦИЯ
  • обекти описания: Обект ТИП, ПРЕДМЕТ Идентичността
  • описва капан (нотификация): УВЕДОМЯВАНЕ ТИП (SNMPv2), TRAP-ТИП (SNMPv1)
  • формално описание на изискванията за изпълнителите: обектно-група, известяване и група, МОДУЛ СПАЗВАНЕ
  • формално описание на изпълнението на конкретен агент:-ВЪЗМОЖНОСТИ
Модулът е текстов файл, написан на и адаптирана подмножество OSI ASN.1 (Нотиране на абстрактен синтаксис, ISO 8824: 1987, ITU-X.208). "Адаптация", така че познаването на оригиналния ASN.1 SNMP пречи само разбиране (разбира се, ако не е необходимо да се програмира кодиране / декодиране на PDU, което изисква познаване на основните правила за кодиране - РГО). "Адаптиран подгрупа" се определя стандарт SMI (Структура и Идентификация на управление на информацията, Структура на управление на информацията), която определя списъка на стандартните видове и набор от ASN.1 макроси могат да използват при създаването на модула. Чрез използване на всеки макро (с изключение на капан), определен идентификатор обект (капан определя цяло число). Разрешено директно определяне на идентификатори и описания на обекти и използването на износ Внос и оператори (износ SNMPv2 оператор отменени и изнесени всички описания). Не се разрешава използването на други средства за ASN.1 и писане на собствени макроси. Версия на SMI:
  • SMIv1 (RFC-1155); SMIv1 разширение на MIB-II (RFC-1212); описание капан за SMIv1 (RFC-1215); Модули: RFC1155-SMI, RFC-1212, RFC-1215
  • версия SNMPv2 (RFC-1442), по-късно наречен SMIv2
  • SMIv2 версия за SNMPv2c (RFC-1902, RFC-1903 и RFC-1904); Модули: SNMPv2 МСИ, SNMPv2-TC, SNMPv2-Conf
  • SMIv2 версия за SNMPv3 (RFC-2578, RFC-2579 и RFC-2580)
Стандартни типове (RFC1155-SMI модул за SNMPv1, SNMPv2-SMI модул за SNMPv2):
  • INTEGER (-2147483648..2147483647) или Integer32 (само SMIv2), също представлява ENUM
  • Counter или Counter32 (в SMIv2): монотонно увеличаване число от 0 до 2 ^ 32-1 до загуба преливник малко, първоначалната стойност не е посочена, устройството може да се нулира в инициализация и други ясно описани моменти
  • Gauge или Gauge32 (в SMIv2): неотрицателно цяло число от 0 до 2 ^ 32-1, "заседнал" в прехода през максимум
  • БАЙТОВЕ STRING (РАЗМЕР (0..65535), се препоръчва да се ограничи 255 символа)
  • ПРЕДМЕТ идентификатор (не повече от 128 прости имена)
  • NULL (заменен от zeroDotZero в SMIv2)
  • TimeTicks (неотрицателно цяло число брои времето в centiseconds от някои референтна точка по модул 2 ^ 32)
  • Непрозрачно (произволен тип ASN.1 кодиран като БАЙТОВЕ STRING, за съвместимост с по-големия MIB, срещнах веднъж)
  • NetworkAddress (препратка към IPADDRESS, изчезна в SNMPv2)
  • IPADDRESS (БАЙТОВЕ STRING на дължина 4, мрежа за байт)
  • Counter64 (в SMIv2)
  • Unsigned32 (в SMIv2)
  • ПОСЛЕДОВАТЕЛНОСТ НА (маса)
  • ПОСЛЕДОВАТЕЛНОСТ <> (Списък, низ маса)
  • DisplayString (ASCII, 255 символа, се добавят към MIB-II, се превърна в една конвенция текстова в SNMPv2)
  • PhysAddress (НИЗ ОТ БАЙТОВЕ, добави в MIB-II, се трансформира в текстова съгласие SNMPv2)

Всички имена на MIB обекти, включени в iso.org.dod.internet.mgmt.mib клон (1.3.6.1.2.1). Клон iso.org.dod.internet.mgmt.mib-2 има същия идентификатор - (!) 1.3.6.1.2.1. Частни обекти са включени в iso.org.dod.internet.private.enterprises клон (1.3.6.1.4.1). Така например, преминаването Allied Telesyn: iso.org.dod.internet.private.enterprises.alliedTelesyn.mibObject.fstswitchMib (1.3.6.1.4.1.207.8.32).

Не всички групи (podvetki), определен в стандарт MIB SNMPv1, трябва да бъдат изпълнени в определен агент, но ако изпълняват podvetka, трябва да се прилага изцяло. В SNMPv2 формални изисквания, определени макро МОДУЛ спазване, но специфичните възможности за изпълнение - макро агент възможности.

Стандартът не препоръчва за изпращане на съобщения по-дълги от 484 байта (раздробяването на UDP дейтаграми е нежелателна, особено ако е възможно загуба на пакети при фрезоване; това ограничение гарантира до минимум на MTU, в случай на използване само на етернет, размер PDU може да се увеличи до 1200 байта). Официално максималната - 64 KB, но прилагането на ограниченията, обикновено са по-малко. PDU използван за кодиране на основни правила за кодиране (РГО от ASN.1).

Клон iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTrap контролира SNMPv2-Trap:
  1. snmpTrapOID (ПРЕДМЕТ IDENTIFIER, достъпен и за уведомяване, изпратено до псевдонима като втората променлива в SNMPv2-Trap PDU)
  2. snmpTrapEnterprise (ПРЕДМЕТ IDENTIFIER, достъпен и за уведомяване, които се използват при конвертиране RFC1157 Trap-PDU в SNMPv2-Trap-PDU)
Браншови iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpTraps (5) описва "стандартен" капана:
  1. coldStart
  2. warmStart
  3. linkDown (определена в IF-MIB модул)
  4. LinkUp (определена в IF-MIB модул)
  5. authenticationFailure
  6. egpNeighborLoss (определена в модул.)
iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBObjects.snmpSet (6) позволява многократно управление клон станции координират промени променливи от брокера:
  1. snmpSetSerialNo (TestAndIncr, четене и запис)
Промушете iso.org.dod.internet.snmpV2.snmpModules.snmpMIB.snmpMIBConformance (2) определя формалните изисквания за SNMPv2-MIB минимална реализация агенти:
  1. snmpMIBCompliances
    1. snmpBasicCompliance (DB непременно изпълнени snmpGroup група, snmpSetGroup, SystemGroup, snmpBasicNotificationsGroup; snmpCommunityGroup група DB се осъществява чрез използване на административен модел, основан на имената на общността)
  2. snmpMIBGroups (обект група за използване в snmpMIBCompliances)
    1. snmpSetGroup (snmpSetSerialNo)
    2. SystemGroup (система линия)
    3. snmpBasicNotificationsGroup (coldStart, authenticationFailure)
    4. snmpGroup (snmpInPkts, snmpInBadVersions, snmpInASNParseErrs, snmpSilentDrops, snmpProxyDrops, snmpEnableAuthenTraps)
    5. snmpCommunityGroup (snmpInBadCommunityNames, snmpInBadCommunityUses)
Определя се следното enterpriseSpecific капан (както се използва sysObjectID dot1dBridge, т.е. 1.3.6.1.2.1.17):
  1. newRoot (мост се превърна в нов корен на дървото, обхващаща)
  2. topologyChange (всяка друга промяна в топологията на обхващаща дървото)

ПОД-SNMP не включва текст Bridge-MIB.

Определя се следното enterpriseSpecific капан (както се използва sysObjectID snmpDot3RptrMgt, т.е. 1.3.6.1.2.1.22):
  1. rptrHealth (предава rptrOperStatus променлива може да бъде rptrHealthText), при всяка промяна rptrOperStatus, но не по-често от веднъж на всеки 5 секунди
  2. rptrGroupChange (предава променлива rptrGroupIndex), при всяка промяна на порт групови структури, но не по-често от веднъж на всеки 5 секунди за всяка група
  3. rptrResetEvent (предава променлива rptrOperStatus, може да бъде rptrHealthText) След обработка на командата за управление, не повече от веднъж на всеки 5 секунди
  • Ретранслатор MIB (RFC-2108 за SNMPv2)
  • Bridge MIB (RFC-2674 за SNMPv2)
  • MIB Ethernet интерфейс (RFC-1643, RFC-2665, RFC-2666, RFC-2668)
  • RMON MIB (RFC-1757, RFC-2021, RFC-2074, RFC-2613, RFC-2819), обекти за управление на мрежата като цяло (сблъсък домейн за Ethernet)

Нетната-SNMP (нето-SNMP пакети и нетна-SNMP-UTILS, бивш UCD-SNMP до версия 4.9.2, 5.0 променен синтаксис) ви позволява да изпращате заявки за SNMP и отговори процес, задаване на агент SNMP на компютъра, за да изпращате и получавате SNMP съобщения (капан). Тя включва библиотека API за разработване на собствени програми. Налице е подкрепа за криптиране SNMPv2 и SNMPv3.







Предишен ◈ Следващото