Как импортировать данные SNMP MIB в MIB Manager.
В окне Предпочтения укажите положения MIB, которые регулярно используются для MIB поставщиков. Убедитесь, что ваши MIB расположены в заданных для поставщиков каталогах, а все номера связанного оборудования содержатся в подкаталогах. Убедитесь также, что в этих каталогах нет других, отличных от MIB, текстовых файлов. Большинство MIB устанавливаются в каталог ДОМАШНИЙ_КАТАЛОГ_NC/omnibus/var/mibmanager/mibs/base, а все RFC MIB - в каталог ДОМАШНИЙ_КАТАЛОГ_NC/omnibus/var/mibmanager/mibs/rfc.
Импортированные вами MIB могут зависеть от других MIB. Чтобы обеспечить для MIB Manager возможность искать зависимые MIB при выполнении импорта, задайте путь поиска к положениям зависимых файлов MIB.
Чтобы импортировать данные MIB:
Представление Модули MIB автоматически обновляется, чтобы показать имена новых импортированных модулей MIB. Представление Дерево OID автоматически обновляется, чтобы показать все импортированный объекты MIB. Для перепостроения дерева MIB Manager рекурсивно ищет родительские узлы дерева (iso, ccitt и joint-iso-ccitt) для дочерних узлов, пока не будет найден дочерний узел, у которого нет связанных дочерних элементов. Если не обнаруживаются ошибки, целиком заполненное дерево MIB выводится в представлении Дерево OID , содержащем проанализированные объекты.
Если щелкнуть по объекту в представлении Дерево OID, объект будет автоматически показан в представлении Модули MIB. В представлении Подробности выводится подробная информация о выбранном объекте.
Импортированные модули MIB хранятся в файле XML, представляющем структуру данного модуля MIB. Эти файлы XML расположены в каталоге ДОМАШНИЙ_КАТАЛОГ_NC/omnibus/var/mibmanager/data.
Если обнаруживаются неразрешенные операторы импорта, обратитесь к поставщику, ответственному за отсутствующие MIB, добавьте отсутствующий файл или файлы в путь поиска и повторите операцию импорта.
Иногда поставщики указывают дублированные имена объектов или имя объекта, совпадающее с именем объекта, заданным в RFC.
Например, объект с именем system может быть определен в модуле SNMPv2-MI' с OID 1.3.6.1.2.1.1, а другой объект с именем system - в модуле WINDOWS-NT-PERFORMANCE с OID 1.3.6.1.4.1.311.1.1.3.1.1.23. Также объект с именем sysDescr может быть определен как system.1 в модуле SNMPv2-MIB, а другой объект с именем sysFileReadOperationsPerSec - как system.1 в модуле WINDOWS-NT-PERFORMANCE. В этом случае неясно, с каким родительским объектом связаны дочерние объекты.
Когда обнаружен объект с дублированным родительским именем, MIB Manager пытается найти родительский объект, определенный в том же модуле MIB. В предыдущем примере это модуль WINDOWS-NT-PERFORMANCE. Если в том же модуле MIB не определен ни один из родительских объектов, MIB Manager ищет, не определен ли родительский объект в другом модуле MIB, от которого этот объект зависим. MIB Manager определяет также другие модули MIB, которые ссылаются на родительский объект, и выбирает родительское имя, на которое существует более всего ссылок. Однако этот способ выбора может привести к неправильному заполнению дерева MIB и к неправильному вычислению OID. Поэтому каждый раз, когда MIB Manager находит дублированное имя объекта, этот компонент производит запись в журнал отладки предупреждения, а также действий, предпринятых для исправления дублирования.