Главная > Железо > Как работает протокол snmp community. SNMP протокол (основы)

Как работает протокол snmp community. SNMP протокол (основы)

Сбор информации о сервере и инфраструктуре – очень важная часть работы системного администратора. Существует множество инструментов для сбора и обработки таких данных, и многие из них основаны на технологии SNMP.

SNMP (simple network management protocol, простой протокол сетевого управления) – это стандартный протокол для управления устройствами в IP-сетях. С его помощью серверы могут обмениваться информацией о своем текущем состоянии, а администратор может изменять предварительно определенные значения. Сам протокол очень простой, однако структура основанных на нём программ может оказаться сложной.

Данная статья ознакомит вас с основами протокола SNMP: базовыми понятиями, методами работы, случаями его применения, различными версиями протокола и т.д.

Базовые понятия

Протокол SNMP реализуется на прикладном уровне сетевого стека. Протокол был разработан для согласованного сбора информации из самых разных систем. SNMP использует стандартизированные методы запроса информации и пути.

Существует много различных версий протокола SNMP. Кроме того, протокол частично реализуется некоторыми сетевыми аппаратными устройствами. Наиболее распространённой является версия SNMPv1, но она имеет много уязвимостей; на самом деле, основными причинами её популярности являются её вездесущность и долгое время существования. Вместо неё рекомендуется использовать более безопасную версию SNMPv3.

Сеть на основе SNMP в основном состоит из SNMP-агентов. Агент – это программа, которая собирает информацию об аппаратном устройстве, систематизирует её в предварительно определенные записи, а также отвечает на запросы с помощью протокола SNMP.

Компонент, который запрашивает данные у агентов, называется менеджером SNMP. SNMP-менеджеры получают данные о всех управляемых устройствах и могут выдавать запросы для сбора информации и устанавливать некоторые свойства.

Менеджеры SNMP

Менеджер SNMP – это машина, которая запрашивает информацию, собранную агентами SNMP. Такая машина гораздо проще устроена, чем клиенты, поскольку она просто запрашивает данные.

Менеджером может быть любая машина, которая может отправлять запросы агентам SNMP, предоставляя валидные учётные данные (например, сервер мониторинга); иногда задачи менеджера выполняет сам администратор с помощью простых утилит для быстрого запроса данных.

Почти все команды SNMP предназначены для менеджера. Например:

GetRequest
GetNextRequest
GetBulkRequest
SetRequest
InformRequest
Response

Кроме того, менеджер может отвечать на Trap и Response.

Агенты SNMP

Агенты SNMP выполняют основную работу. Они отвечают за сбор данных о локальной системе, их хранение в удобном для запросов формате, обновление БД management information base (или просто MIB).

MIB – это иерархическая предварительно определенная структура, хранящая информацию, которую можно запросить или добавить. Она доступна для запросов SNMP, исходящих от хоста, предоставившего правильные учетные данные (т.е. менеджера SNMP).

Агент определяет, какие менеджеры могут получить доступ к данным. Также агент может выступать в качестве посредника и передавать информацию на устройства, не настроенные для SNMP-трафика.

Агенты SNMP отвечают на большинство команд протокола, среди которых:

GetRequest
GetNextRequest
GetBulkRequest
SetRequest
InformRequest

Также он может отправлять сообщения Trap.

Кратко о MIB

Management Information Base, или MIB – пожалуй, самый сложный компонент системы SNMP. Это иерархическая глобально стандартизированная база данных, которая следует стандартам агентов и менеджеров системы.

Проще всего структуру MIB можно представить в виде перевёрнутого дерева. Каждая ветвь получает порядковый номер (начиная с 1) и уникальную для этого уровня иерархии строку.

Чтобы сослаться на определённый узел, нужно отследить к нему путь в базе. Идентификаторы узла (номера и строки) можно использовать как адрес. Каждый узел в иерархии обозначается точкой. Таким образом, адрес содержит ряд идентификационных строк или чисел, разделенных точками. Такой адрес называется идентификатором объекта (или OID).

MIB предоставляет стандартные ветки, которые может использовать любое устройство. Однако при внедрении SNMP в свое устройство вы можете создавать пользовательские ветки.

Все стандартные ветки принадлежат одной родительской структуре. Эта ветка определяет информацию для спецификации MIB-2 (это пересмотренный стандарт для совместимых устройств).

Базовый путь к этой ветке:

iso.org.dod.internet.mgmt.mib-2

Часть 1.3.6.1 или iso.org.dod.internet – это OID, который определяет интернет-ресурсы.
2 или mgmt определяют подкатегории управления.
1 или mib-2 определяют спецификацию MIB-2.

Запрашивая информацию устройств, вы заметите, что большинство адресов начинается с 1.3.6.1.2.1.

Команды протокола SNMP

Отчасти протокол SNMP популярен благодаря простым командам. Он выполняет всего несколько операций, но они достаточно гибки.

Следующие блоки данных протокола описывают точные типы сообщений, которые поддерживает протокол:

Get: это сообщение менеджер отправляет агенту, чтобы запросить значение определённого OID. В ответ этот запрос получает сообщение Response, содержащее все необходимые данные.
GetNext: это сообщение позволяет менеджеру запрашивать следующий последовательный объект в MIB. Так можно пересечь структуру MIB, не используя в запросах OID.
Set: это сообщение менеджер отправляет агенту для того, чтобы изменить значение переменной. С помощью Set можно управлять информацией о конфигурации или иным образом изменять состояние удаленных хостов. Это единственная операция записи, которую поддерживает протокол.
GetBulk: этот запрос работает как несколько запросов GetNext. Менеджер получит ответ максимальный объём данных (учитывая ограничения запроса).
Response: агент отправляет это сообщение менеджеру, чтобы передать ему запрашиваемые данные. Если запрашиваемые данные нельзя передать, response будет содержать ошибку с дополнительной информацией. Сообщение response отправляется на любой из вышеперечисленных запросов, а также на сообщение Inform.
Trap: это сообщение обычно отправляется агентом менеджеру, чтобы предоставить информацию о событиях, которые происходят на управляемых устройствах.
Inform: такое сообщение менеджер отправляет агенту в ответ на trap. Если агент не получит такого сообщения, он будет повторно отправлять сообщения trap.

Версии протокола

С момента выхода протокол SNMP прошел через множество изменений. Первая реализация SNMP, сейчас известная как SNMPv1, появилась в 1988 году и состояла из RFC 1065, RFC 1066 и RFC 1067. Эта версия до сих пор широко поддерживается, однако она имеет множество проблем с безопасностью (например, аутентификация в виде обычного текста), поэтому её использование крайне нежелательно, особенно это касается незащищенных сетей.

Работа над версией 2 данного протокола началась в 1993 году. Эта версия предлагает ряд существенных улучшений представленных ранее стандартов. В этой версии была представлена модель безопасности на основе сторон, которая устраняет уязвимости, связанные с предварительным пересмотром. Тем не менее, новую модель безопасности оказалось достаточно сложно реализовать, потому популярной она не стала.

Поэтому появились дополнительные релизы версии 2, каждый из которых сохранил основную часть усовершенствований версии 2, но изменил модель безопасности. Версия SNMPv2c возобновила модель безопасности на основе сообществ (которая была использована в v1); это была самая популярная версия протокола v2. Другая реализация, SNMPv2u, основана на пользовательской модели безопасности, также не стала популярной.

В 1998 вышла третья версия SNMP (текущая). Она предлагает пользовательскую систему безопасности, которая позволяет устанавливать требования к аутентификации с помощью одной из этих моделей:

NoAuthNoPriv: пользователи, подключающиеся на этом уровне, не имеют учётных данных для аутентификации; отправленные и полученные ими сообщения находятся в общем доступе.
AuthNoPriv: на этом уровне для подключения нужно пройти аутентификацию, но сообщения не будут зашифрованы.
AuthPriv: обязательная аутентификация, сообщения шифруются.

Кроме новых моделей аутентификации был реализован механизм контроля доступа, который управляет доступом пользователей к веткам. Версия 3 также может использовать протоколы безопасности SSH или TLS.

Tags: , Дмитрий Ганьжа

Типичная сеть состоит из множества устройств различных производителей. Управлять такой сетью возможно только при наличии стандартного, не зависящего от производителя протокола управления. Самым популярным стандартным протоколом управления в современных сетях является простой протокол управления сетью (Simple Network Manage-ment Protocol, SNMP). Широкое распространение он получил в силу своей гибкости и расширяемости - SNMP позволяет описывать объекты для самых разных устройств. Ниже мы рассмотрим основные компоненты SNMP с указанием отличий первой версии протокола от второй.

МОДЕЛЬ SNMP

Модель SNMP состоит из четырех компонентов:

управляемых узлов;
станций управления (менеджеров);
управляющей информации;
протокола управления.

Управляемыми узлами могут быть компьютеры, маршрутизаторы, коммутаторы, принтеры или любые другие устройства, способные сообщать информацию о своем состоянии. Чтобы им можно было управлять с помощью SNMP, узел должен выполнять управляющий процесс SNMP, иными словами, иметь агента SNMP. Каждый агент ведет собственную локальную базу данных о состоянии устройства и истории событий.

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

Спрашивать, например, у маршрутизатора, сколько пакетов было потеряно, бессмысленно, если он не ведет их учет или не понимает запроса. Поэтому SNMP самым тщательным образом описывает, какую информацию агент должен собирать и в каком формате ее следует предоставлять. Таким образом, каждое устройство поддерживает несколько переменных с описанием своего состояния. Все возможные переменные объединены в такую структуру, как база управляющей информации.

Станции управления взаимодействуют с агентами с помощью протокола SNMP. Он позволяет станции запрашивать значения локальных переменных агента и при необходимости изменять их.

Однако иногда в сети могут происходить нежелательные события. Управляемые узлы могут сломаться, линии связи - выйти из строя и т. п. Как только агент замечает какое-либо значительное событие, он немедленно сообщает о нем всем станциям из своего конфигурационного списка. Это сообщение называется прерыванием SNMP. Агент лишь сообщает о событии, а все подробности станция управления должна выяснять самостоятельно. Из-за ненадежности коммуникаций между станцией и агентами (получение сообщений не подтверждается) каждая станция периодически проводит опрос управляемых узлов для выявления необычных событий. Такая модель опроса через длительные интервалы времени с немедленным опросом при получении прерывания называется инициируемым прерываниями опросом.

СТРУКТУРА УПРАВЛЯЮЩЕЙ ИНФОРМАЦИИ

Структура управляющей информации (Structure of Management Information, SMI) определяет допустимые в базе управляющей информации типы данных и способы их представления. Кроме того, она определяет иерархическую структуру имен, чтобы управляемые объекты имели уникальные однозначные имена. SMI представляет своего рода надподмножество ASN.1 - она использует часть типов данных этого стандарта и вводит несколько своих типов данных. (АSN - абстрактное описание синтаксиса - представляет собой стандартный язык описания объектов, принятый в OSI. Как и многие другие протоколы OSI, он сложен, громоздок и неэффективен.)

Для того чтобы агенты и менеджеры могли управлять объектами в сети со множеством устройств и протоколов разных поставщиков, объекты должны быть описаны, а также стандартным образом закодированы для передачи по сети. Термин "объекты" относится к переменным, описывающим состояние устройства. Он несколько сбивает с толку, так как это далеко не те же объекты, что и в объектно-ориентированных системах, в частности они имеют состояния, но не имеют методов (помимо чтения и записи значений объектов). Однако этот термин используется в официальных стандартах.

Объекты базы управляющей информации обычно имеют шесть атрибутов. Как правило, это имя, например ifInErrors или tcpAttemptFails; идентификатор объекта в точечно-десятичной нотации вида 1.3.6.1.2.1.2.2.1.1.4; поле синтаксиса для выбора одного из нескольких возможных типов данных - Integer, IPAddress или Counter; поле метода доступа - "недоступен", "только чтение", "чтение-запись" и "только запись"; поле статуса - "обязательный", "необязательный" или "вышедший из употребления", а также текстовое описание объекта.

SMI задает правила описания объектов. Все эти абстрактные правила и зарезервированные слова позволяют получить машиночитаемые спецификации, понятные человеку. Объекты MIB имеют статичную природу. Они компилируются из текстов файлов с описанием в двоичную форму, которую агенты и управляющие процессы и загружают. Используя SMI, производитель может написать собственное определение объекта управления (например, PacketsContainingWordSpam), пропустить текст через стандартный компилятор MIB и создать таким образом исполнимый код. Этот код можно затем установить на агенты с надлежащим аппаратным и программным обеспечением для подсчета количества содержащих слово spam пакетов.

БАЗА УПРАВЛЯЮЩЕЙ ИНФОРМАЦИИ

Множество объектов, которыми управляет SNMP, составляет базу управляющей информации (Management Information Base, MIB). Для удобства эти объекты объединены в десять групп, каждая из которых представляет собой дочерний для mib-2 узел в дереве имен объектов (см. Рисунок 1). Изначально база управляющей информации содержала восемь групп. Спецификация MIB-2 добавила еще две группы и исключила одну прежнюю. Производители могут определять собственные объекты. Информация по всем десяти группам сведена в Таблицу 1.

Группа System позволяет определить, как называется устройство, кем оно произведено, какое программное и аппаратное обеспечение оно содержит, где находится и какие функции выполняет. Кроме того, она предоставляет информацию о том, когда последний раз производилась загрузка и каковы имя и координаты ответственного лица. Зная эту информацию, администратор из центрального офиса может, например, без труда установить конфигурацию устройства в удаленном офисе.

Группа Interface служит для сбора статистики о работе сетевых адаптеров, в том числе о количестве переданных и полученных пакетов и байтов, о числе широковещательных пакетов и текущем размере выходной очереди.

Присутствовавшая в MIB-1 группа АТ предоставляла данные о соответствии адресов (например, MAC- и IP-адресов). В SNMPv2 эта информация была перемещена в базы управляющей информации для конкретных протоколов.

Группа IP описывает трафик через узел. Она изобилует счетчиками для подсчета числа отброшенных по каждой из причин кадров (например, кадр был отброшен, потому что его адресат неизвестен). Кроме того, она позволяет получить данные о фрагментации и сборке дейтаграмм. Как нетрудно понять, эта группа особенно полезна для получения статистики о работе маршрутизатора.

Группа ICMP собирает данные о сообщениях об ошибках в IP. Она имеет счетчики для подсчета количества зафиксированных сообщений каждого возможного типа.

Группа TCP служит для учета числа открытых соединений, количества переданных и полученных сегментов и различного рода ошибок.

Группа UDP позволяет фиксировать число переданных и полученных дейтаграмм, а также количество дейтаграмм, потерянных из-за того, что порт неизвестен, или по другим причинам.

Группа EGP используется маршрутизаторами, поддерживающими Exterior Gate-way Protocol. Она позволяет подсчитывать число полученных из внешней сети кадров, а также сколько из них было передано правильно, а сколько отброшено и т. п.

Группа Transmission служит родительским узлом для специфичных баз управляющей информации. Например, сюда может быть помещена группа для сбора статистики об Ethernet. Цель включения пустой группы в MIB-2 состоит исключительно в резервировании идентификатора для подобных целей.

Последняя группа - группа SNMP - предназначена для сбора статистики о функционировании самого протокола SNMP: сколько сообщений было послано, что это за сообщения и т.п.

ПРОТОКОЛ SNMP

Собственно SNMP представляет собой протокол по типу запрос-ответ, которыми сетевые станции управления и агенты обмениваются между собой. Первая версия протокола SNMP предусматривает всего пять различных сообщений. Три из них может посылать менеджер агенту, а два других - агент менеджеру.

Если в сети ничего необычного не происходит, то SNMP используется менеджером для отправки агенту запроса с просьбой передать запрошенную информацию или с приказом изменить свое состояние указанным образом. Агент посылает в ответ требуемую информацию или подтверждает изменение своего состояния. Однако агент может передать сообщение об ошибке, например "нет такой переменной". В чрезвычайных же обстоятельствах, в частности при превышении заданного порога, агент отправляет менеджеру прерывание. Данные передаются с использованием синтаксиса ASN.1.

Менеджер агенту может послать следующие три сообщения: GetRequest, GetNextRequest и SetRequest. Первые два служат для запроса у агента значений конкретных переменных. Первое из них содержит имя переменной в явном виде. Второе запрашивает значение следующей переменной в алфавитном порядке. Третье позволяет менеджеру изменять значения переменных, если определение объекта это позволяет.

Агент может отправлять два различных сообщения: одно из них - GetResponse - служит для ответа (и подтверждения) на запрос от менеджера, а второе - Trap - посылается при обнаружении агентом предопределенного чрезвычайного события.

Протоколом SNMPv2 вводится еще два типа сообщений. GetBulkRequest позволяет запросить целый массив переменных, например таблицу, а InformRequest - одному менеджеру сообщить другому, какими переменными он управляет.

Все типы сообщений сведены в Таблице 2.

НИЖЕЛЕЖАЩИЕ ТРАНСПОРТНЫЕ ПРОТОКОЛЫ

SNMP предназначался в первую очередь для управления сетями на базе протоколов Internet. Как протокол прикладного уровня он может, однако, использовать в качестве транспортного любой другой протокол, помимо UDP и IP. Например, он может выполняться поверх IPX, отображаться напрямую в кадры Ethernet, инкапсулироваться в ячейки ATM и т. п.

Протокол SNMP разрабатывался в расчете на то, что обмен сообщениями между агентами и менеджерами будет происходить без установления соединения. В результате SNMP не предоставляет гарантии, что сообщения будут доставлены по назначению. Однако на практике большинство сообщений достигает адресата, а те, что теряются по пути, могут быть переданы повторно. Исходя из этого - и, естественно, ориентации SNMP на протоколы Internet, основным транспортом для SNMP является UDP.

Благодаря своей простоте и транспорту без установления соединения SNMP оказывается весьма эффективным протоколом. И агенты, и менеджеры могут работать независимо друг от друга. Таким образом, менеджер будет продолжать работать, даже если удаленный агент окажется недоступен. После возобновления функционирования агент отправит менеджеру прерывание, дабы известить его о своей работоспособности.

Обмен сообщениями при использовании в качестве транспорта протокола UDP осуществляется следующим образом. Агент следит за поступлением дейтаграмм на порт 161. Ответы посылаются запрашивающей сетевой станции управления на динамически назначаемый порт, однако многие агенты используют тот же номер порта - 161. Асинхронные прерывания станция управления принимает на порт 162.

Максимальная допустимая длина сообщений SNMP ограничивается мак-симальным размером сообщения UDP, т. е. 65 507 байт. Однако спецификация SNMP предусматривает, что все агенты и менеджеры должны принимать пакеты лишь длиной до 484 байт, поэтому некоторые из них могут не уметь обрабатывать пакеты длиной свыше 484 байт.

UDP более подходит для транспорта SNMP, нежели TCP, в частности, когда сеть сталкивается с проблемами и пакеты передаются каждый раз по новым маршрутам, т. е. когда управление наиболее необходимо. Кроме того, он предъявляет меньшие требования к сетевым ресурсам, нежели TCP, т. е. накладные расходы на управление оказываются меньше. Однако в результате задача обнаружения потерянных и ошибочных пакетов возлагается непосредственно на менеджеров и агентов.

ЗАЩИТА В SNMP

Одно из самых слабых (и критикуемых) мест SNMP - реализация защиты. Так, станция управления может не только узнать практически все о находящихся в сфере ее контроля узлах, но и остановить их. Поэтому агенты должны быть уверены, что полученный ими запрос действительно исходит от станции управления.

В SNMPv1 простейшая идентификация отправителя осуществляется посредством включения в сообщения имени группы (community name), причем имя передается открытым текстом. После проверки имени группы агент или менеджер проверяет наличие у отправителя с данным адресом прав на выполнение запрошенной операции. Таким образом, проверка прав осуществляется на основании имени группы и адреса отправителя.

В SNMPv2 сделана попытка укрепить защиту SNMP за счет использования современных криптографических методов, в частности DES. Однако это еще более усложнило протокол. Кроме того, в такой реализации SNMPv2 оказался обратно несовместим с SNMPv1.

ЛОЖКА ДЕГТЯ?

Несмотря на свое название, SNMP оказался далеко не простым для реализации протоколом ввиду сложности правил кодирования информации. Кроме того, SNMP мог бы быть более эффективным, чем он есть. В частности, его сообщения содержат зачастую ненужную информацию, например номер версии SNMP. Из-за принятого в SNMP способа описания переменных сообщения содержат чрезмерно большие дескрипторы данных. Все это ведет к раздуванию объема сообщений. Изначально SNMP предназначался для относительно простых сетей, так что станции управления не могли обмениваться информацией друг с другом. Наконец, самым существенным недостатком SNMP была (и остается) слабая защита. Многие из этих недостатков - но не все - исправлены во второй версии SNMP (SNMPv2).

Однако SNMP продолжает совершенствоваться, и уже готовится третья версия этого протокола.

Дмитрий Ганьжа - ответственный редактор LAN. С ним можно связаться по адресу:

Цель работы: изучение способов мониторинга и управления сетью на основе протокола SNMP.

Применяемое оборудование:

2.Один коммутатор третьего уровня D-LinkDES-3810-28.

3. Два управляемых коммутатора второго уровня D-LinkDES-3200-10.

Теоретические сведения:

Протокол SNMP

Определение и функции протокола:

Протокол SNMP (Simple Network Management Protocol, простой протокол управления сетью) является протоколом Прикладного уровня, разработанный для выполнения двух задач:

Мониторинг сетевых устройств и сети в целом;

Управление сетевыми устройствами.

Протокол SNMP предоставляет возможность станциям управления считывать и изменять настройки шлюзов, маршрутизаторов, коммутаторов и прочих сетевых устройств.

Версии протокола SNMP

Опишем различия между версиями протокола SNMP и документы, определяющие эти версии. По состоянию на 2006 год единственной не устаревшей версией SNMP является SNMPv3, определённая в RFC 3411-3418.

Первые RFC, описывающие стандарты SNMP, появились в 1988 году. Версия 1 подвергласькритике за её посредственную модель безопасности на основе сообществ. В товремя безопасность в Интернете не входила в круг первоочередных задач рабочих группIETF.

Версия 2, известная так же, как Party-based SNMPv2, ипи SNMPv2p, не получила широкого распространения из-за серьёзных разногласий по поводу инфраструктуры безопасности в стандарте. SNMPv2 улучшал версию 1 в области быстродействия, безопасности, конфиденциальности и взаимодействий «менеджер-менеждер». Он представил новый тип PDU Get-Bulk-Request, альтернативу Get-Next-Request для получения больших объёмов

информации при помощи одного запроса. Тем не менее, новая система безопасности на основе сторон выглядела для многих как чересчур сложная и не была широко признана.

Community-based SNMPv2, или SNMPv2c, представил SNMPv2 без новой модели безопасности версии 2. Вместо неё предлагалось использовать старую модель безопасности версии 1 на основе сообществ. Соответствующее предложение RFC было принято только как черновик стандарта, однако стало де факто стандартом SNMPv2. Безопасность SNMP снова оказалась нерешённым вопросом.

User-based SNMPv2, или SNMPv2u, является компромиссом между незащищённостью SNMPvl и чрезмерной сложностью SNMPv2p. Предложенная модель безопасности на основе пользователей была положена в основу SNMPv3.

SNMPv3 наконец-то решил проблемы с безопасностью способом, который многие посчитали приемлемым. Версия 3 SNMP принята IETF как стандарт Интернета (IETF STD 62). Почти все предыдущие RFC признаны устаревшими. Документы, описывающие протокол SNMPv3, приведены ниже:

Общаяинформация.

RFC 3411. An Architecture for Describing SNMP Management Frameworks.

Обработка сообщений.

1)Привязки к транспорту.

RFC 3417. Transport Mappings for the SNMP.

2)Разбор и диспетчеризация сообщений.

RFC 3412. Message Processing and Dispatching for the SNMP.

3)Безопасность.

RFC 3414. User-based Security Model (USM) for SNMPv3.

Обработка PDU

1) Операции протокола.

RFC 3416. Version 2 of the Protocol Operations for SNMP.

2)ПриложенияSNMP.

RFC 3413. SNMP Applications.

3)Управлениедоступом.

RFC 3415. View-based Access Control Model (VACM) for the SNMP.

МодулиMIB.

RFC 3418. MIB for the SNMP.

Модель протокола SNMP

Общая модель

Модель приведена на рисунке 1. Основными взаимодействующими элементами протокола являются агенты (agent) и системы управления сетью (NMS, network management system). С точки зрения концепции «клиент-сервер» роль сервера выполняют агенты, то есть те самые устройства, для опроса состояния которых используется протокол SNMP.

Соответственно, роль клиентов отводится системам управления - сетевым приложениям, необходимым для сбора информации о функционировании агентов. Взаимодействие агентов и систем управления осуществляется на основе сообщений протокола SNMP.

Агентами в SNMP являются программные модули, которые работают в управляемых устройствах. Агенты собирают информацию об управляемых устройствах, в которых они работают.

В любой управляемой сети может иметься одна или более NMS. NMS выполняют прикладные программы сетевого управления, которые представляют информацию управления конечному пользователю.

Структура базы M I В

На данный момент существует четыре типа информационной базы MIВ:

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

2. LAN manager MIB - база из 90 объектов - пароли, сессии, пользователи, общие ресурсы.

3. WINS MIB - база объектов, необходимых для управления и диагностики WINS- сервера (в серверах Microsoft Windows физически находится в файле

4. DHCP MIB - база объектов, необходимых для управления и диагностики DHCP- сервера (в серверах Microsoft Windows физически находится в файле

Структуру MIB определяет документ, называемый SMI (Structure of Management Information, структура управляющей информации). Все 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 объектов со статистикой об ICMP-сообщениях.

6. TCP - содержит 19 объектов, хранящих статистику по протоколу TCP (соединения, открытые порты и т.д.).

7. UDP - содержит 6 объектов, хранящих статистику по протоколу UDP (входящие/исходящие датаграммы, порты, ошибки).

8. EGP - содержит 20 объектов - данные о трафике Exterior Gateway Protocol.

9. Transmission - зарезервирована для специфических задач.

10. SNMP - содержит 29 объектов, в которых хранится статистика по SNMP-протоколу (входящие/исходящие пакеты, ограничения пакетов по размеру, ошибки, данные об обработанных запросах и многое другое).

Рисунок 1

Каждая из ветвей в свою очередь также представима в виде дерева. Например, к адресу администратора мы можем обратиться посредством такого пути: system.sysContact.0, ко времени работы системы system.sysUpTime.O. С другой стороны те же данные могут задаваться и в точечной нотации. Так system.sysUpTime. O соответствует значение 1.3.0, так

как system имеет индекс «1» в группах MIB II, a sysUpTime - «3» в иерархии группы system. Ноль в конце пути говорит о скалярном типе хранимых данных. В процессе работы SNMP-протокол использует точечную нотацию, то есть если менеджер запрашивает у агента содержимое параметра system.sysDescr.O, то в строке запроса ссылка на объект будет преобразована в «1.1.0».

Рисунок 2

Дерево MIB расширяемо благодаря экспериментальным и частным ветвям. Например, поставщики могут определять свои собственные ветви для включения реализаций своих изделий. В настоящее время вся работа по стандартизации ведется на экспериментальной ветви.

SMI определяет следующие типы данных Ml В:

1. Network addresses (сетевые адреса) - символьные строки, представляющие адреса из конкретного стека протоколов. В настоящее время единственным примером сетевых адресов являются 32-битовые IP-адреса.

2. Counters (счетчики) - неотрицательные целые числа, которые монотонно увеличиваются до тех пор, пока не достигнут максимального значения, после чего они сбрасываются до нуля. Примером счетчика является общее число байтов, принятых интерфейсом.

3. Gauges (измерители) - неотрицательные целые числа, которые могут увеличиваться или уменьшаться, но фиксируются при достижении максимального значения. Примером типа «gauges» является длина очереди, состоящей из выходных пакетов.

4. Ticks (тики) - сотые доли секунды, прошедшие после какого-нибудь события. Примером типа «ticks» является время, прошедшее после вхождения интерфейса в свое текущее состояние.

5. Opaque (непрозрачный) - произвольное тип данных. Используется для передачи произвольных информационных последовательностей, находящихся вне пределов точного печатания данных, которое использует SMI.

Основные команды системы NMS

Если NMS хочет проконтролировать какое-либо из управляемых устройств, она делает это путем отправки ему сообщения с указанием об изменении значения одной из его переменных.

В целом управляемые устройства отвечают на четыре типа команд (или инициируют их):

Для контролирования управляемых устройств NMS считывают переменные, поддерживаемые этими устройствами.

Для контролирования управляемых устройств NMS записывают переменные, накопленные в управляемых устройствах

3. Traversal operations.

NMS используют операции прослеживания, чтобы определить, какие переменные поддерживает управляемое устройство, а затем собрать информацию в таблицы переменных.

Управляемые устройства используют «ловушки» для асинхронных сообщений в NMS о некоторых событиях.

Протокол SNMPv3

Начиная с января 1998 года, выпущен набор документов, посвященных SNMPv3. В этой версии существенно расширена функциональность, разработана новая система безопасности.

Протокол обмена данными

Ниже на рисунке 3 приведена временная диаграмма, на которой в общем виде представлен протокол обмена SNMP-сообщениями. Для своей работы протокол SNMP использует транспортный протокол UDP, в основном 161 порт. Но для trap-сообщений используется 162 порт. Возможные команды протокола SNMPv3 приведены в таблице 1.

Рисунок 3

таблица 1

Команда SNMP		Назначение
		Получить значение указанной переменной или информацию о состоянии сетевого элемента
		Получить значение переменной, не зная точного её имени (следующий логический идентификатор на дереве MIB).
		Присвоить переменной соответствующее значение. Используя для описания действия, которое должно быть выполнено.
		ОткликнаGET-request, GET-next-request и SET-request. Содержит также информацию о состоянии (коды ошибок и другие данные).
		Отклик сетевого объекта на событие или на изменение состояния.
		Запрос пересылки больших объемов данных, например, таблиц.
		Менеджер обращает внимание партнёра на определенную информацию в MIB.
		Отклик на событие (расширение по отношению
		Отчёт (функция пока не задана).

Формат SNMP-сообщения

Полное описание формата сообщения протокола SNMPv3 дано в документе RFC-3412 в разделе 6 «TheSNMPv3 MessageFormat*. Формат сообщения представлен на рисунке 4

Рисунок 4

SNMP-сообщение логически разделено на три части:

1. Часть, которая формируются отправителем в рамках модели обработки сообщений и обрабатываются получателем.

2. Часть, отвечающая за функции безопасности.

3. Собственно поле данных.

В данном разделе дано описание полей первой и третей частей. Описание полей безопасности дано в разделе. Для реализации модели обработки сообщений используются следующие поля:

MsgVersion. Версия протокола. Для протокола SNMPv3 значение в поле равно 3.

MsgID. Уникальный идентификатор, используемый SNMP-сущностями для установления соответствия между запросом и откликом. Значение msgID лежит в диапазоне 0 - (231-1).

MsgMaxSize. Максимальный размер сообщения в октетах, поддерживаемый отправителем. Его значение лежит в диапазоне 484 - (231-1) и равно максимальному размеру сегмента, который может воспринять отправитель.

MsgFlags. Однобайтовая строка, содержащая три флага в младших битах:

- reportableFlag. Если reportableFlag=1, то должно быть прислано сообщение с отчётом (команда Report). Флаг reportableFlag устанавливается отправителем во всех сообщениях запроса (команды Get, Set, Inform). Флаг устанавливается равным нулю в откликах и Trap-уведомлениях;

- privFlag;

- authFlag.

Флаги privFlag и authFlag устанавливаются отправителем для индикации уровня безопасности для данного сообщения. Для privFlag=1 используется шифрование, а для authFlag=0 - аутентификация. Допустимы любые комбинации значений флагов кроме privFlag=1 AND authFiag=0 (шифрование без аутентификации).

MsgSecurityModel Идентификатор со значением в диапазоне 0 - (231-1), который указывает на модель безопасности, используемую при формировании данного сообщения. Зарезервированы значения 1 - для SNMPvl, 2 и 3 - д л я SNMPv3.

Безопасность протокола SNMPv3

Модели безопасности протоколов SNMPv1-v3

Перечислим модели безопасности, применяющиеся в соответствующих версиях протокола

1. SNMPvl

SNMPvl - Community-based Security Model

2. SNMPv2

SNMPv2p - Party-based Security Model

SNMPv2c- Community-based Security Model

SNMPv2u - User-based Security Model

3. SNMPv3

SNMPv3 - USM User-based Security Model

Модель безопасности на основе сообществ

Модель безопасности на основе сообществ (Community-based Security Model) была первой, самой простой и самой небезопасной. Она подразумевает лишь аутентификацию на основе «строки сообщества», фактически, пароля, передаваемого по сети в теле сообщения SNMP в открытом тексте. Эта модель безопасности не в состоянии бороться ни с одной из угроз информационной безопасности. Тем не менее, она часто используется до сих пор в связи со своей простотой, а также благодаря наличию внешних, не связанных с SNMP систем безопасности, например, межсетевых экранов.

Модель безопасности на основе сторон

Модель безопасности на основе сторон (Party-based Security Model) подразумевает введение понятие стороны. Сторона — это виртуальное окружение исполнения, в котором набор допустимых операций ограничен административно. Сущность SNMP при обработке сообщения действует как сторона, поэтому ограничена операциями, определёнными для этой стороны.

Сторона определяется следующими параметрами:

1. Уникальный идентификатор стороны.

2. Логический сетевой адрес (адрес транспортного протокола).

3. Протокол аутентификации и параметры, требующиеся для аутентификации всех сообщений стороны.

4. Протокол шифрования и параметры, требующиеся для шифрования всех сообщений стороны. Могут использоваться различные алгоритмы для протоколов аутентификации и шифрования. Обычно в качестве алгоритма для протокола аутентификации используют хэш-функцию Message Digest 5 (MD5), а для протокола шифрования — алгоритм Data EncryptionStandard(DES) в режиме CipherBlockChaining(CBC). При использовании соответствующих протоколов аутентификации и шифрования модель успешно справляется с большинством угроз безопасности. Данная модель безопасности не была широко принята, поскольку показалась многим слишком сложной и запутанной.

Модель безопасности на основе пользователей

Модель безопасности на основе пользователей (User-based Security Model) вводит понятие пользователя, от имени которого действует сущность SNMP. Этот пользователь характеризуется именем пользователя, используемыми протоколами аутентификации и шифрования, а также закрытым ключом аутентификации и шифрования. Аутентификация и шифрование являются необязательными. Модель безопасности во многом похожа на

модель на основе сторон, но она упрощает идентификацию пользователей, распределение ключей и протокольные операции.

Модель безопасности USM . Модель безопасности USM (User-Based Security Model) использует концепцию авторизованного

сервера (authoritative Engene). При любой передаче сообщения одна или две

сущности, передатчик или приемник, рассматриваются в качестве авторизованного SNMP-сервера. Это делается согласно следующим правилам:

1. Когда SNMP-сообщение содержит поле данных, которое предполагает отклик (например, Get, GetNext, GetBulk, Set или Inform), получатель такого сообщения считается авторизованным.

2. Когда SNMP-сообщение содержит поле данных, которое не предполагает посылку отклика (например, SNMPv2-Trap, Response или Report), тогда отправитель такого сообщения считается авторизованным.

Таким образом, сообщения, посланные генератором команд, и сообщения Inform, посланные отправителем уведомлений, получатель является авторизованным. Для сообщений, посланных обработчиком команд или отправителем уведомлений Trap, отправитель является авторизованным. Такой подход имеет две цели:

1. Своевременность сообщения определяется с учетом показания часов авторизованного сервера. Когда авторизованный сервер посылает сообщение (Trap, Response, Report), оно содержит текущее показание часов, так что неавторизованный получатель может синхронизовать свои часы. Когда неавторизованный сервер посылает сообщение (Get, GetNext, GetBulk, Set, Inform), он помещает туда текущую оценку показания часов места назначения, позволяя получателю оценить своевременность прихода сообщения.

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

Когда входное сообщение передается обработчиком сообщений в USM, обрабатываются значения параметров безопасности, содержащихся в заголовке сообщения.

В параметрах безопасности содержатся следующие поля:

MsgAuthoritativeEngenelD. Идентификатор авторизованного сервера, участвующего в обмене. Это значение идентификатора отправителя для Trap,

Response илиReport илиадресатадляGet, GetNext, GetBulk, Set илиInform.

MsgAuthoritativeEngeneBoots. snmpEngeneBoots авторизованногосервера,

участвующеговобмене. Объект snmpEngeneBoots содержит целочисленные

значения в диапазоне 0 - (23 1-1). Это поле содержит число, показывающее сколько раз SNMP-сервер был перезагружен с момента конфигурирования.

MsgAuthoritativeEngeneTime. Время работы авторизованного сервера, участвующего в обмене. Значение этого поля лежит в диапазоне 0 - (231-1). Это поле характеризует число секунд, которое прошло с момента последней перезагрузки сервера. Каждый авторизованный сервер должен инкрементировать это поле один раз в секунду.

MsgUserName. Имя пользователя, который послал сообщение.

MsgAuthentication Parameters. Поле содержит ноль, если при обмене не используется аутентификация. В противном случае данное поле содержит аутентификационный параметр.

MsgPrivacyParameters. Поле содержит ноль, если не требуется соблюдения

конфиденциальности. В противном случае данное поле содержит параметр

безопасности. В действующей модели USM используется алгоритм шифрования DES.

Механизм аутентификации в SNMPv3 предполагает, что полученное сообщение действительно послано пользователем, имя которого содержится в заголовке сообщения, и это имя не было модифицировано во время доставки сообщения. Для реализации аутентификации каждый из пользователей, участвующих в обмене должен иметь секретный ключ аутентификации, общий для всех участников (определяется на фазе конфигурации системы).

В посылаемое сообщение отправитель должен включить код, который является функцией содержимого сообщения и секретного ключа. Одним из принципов USM является проверка своевременности сообщения, что делает маловероятной атаку с использованием копий сообщения.

Модель управления доступом

Система конфигурирования агентов позволяет обеспечить разные уровни доступа к базе MIB для различных SNMP-менеджеров. Это делается путем ограничения доступа некоторым агентам к определенным частям MIB, а также с помощью ограничения перечня допустимых

операций для заданной части Ml В. Такая схема управления доступом называется VACM(View-BasedAccessControlModel). В процессе управления доступом анализируется контекст (vacmContextTable), а также специализированные таблицы vacmSecurity ToGroupTable, vacmTreeFamilyTable и vacmAccessTable.

Порядок выполнения работы:

1.Соберите топологию сети, представленную на рисунке 5.

Рисунок 5 - топология сети

2. Настройте SNMP-протокол на коммутаторах.

3. ЗапуститеутилитуiReasoning MIB Browser.

4. Загрузите базу MIB RFC-1213.

5. На обоих коммутаторах (DES-3010 и DES-3828) выясните следующие параметры:

- название устройства, время работы устройства, службы, запущенные на

устройстве (ветвь system);

- количество интерфейсов на устройстве, содержимое таблицы интерфейсов,

назначение двух дополнительных виртуальных портов (ветвь interfaces);

- IP-адрес устройства, содержимое таблицы маршрутизации (ветвь ip);

TCP-соединения, установленные устройством (ветвь tap).

6. Загрузите базы MIB Time, DES-3010G-L2MGMT из каталога

root/ Desktop/SNMP/DES3000-MIB/ private/.

7. Определите текущее системное время коммутатора.

8. Определите состояния портов коммутатора (база DES-3010G-L2MGMT, ветвь swL2PortlnfoTable, таблица swL2PortMgmt).

Контрольные вопросы:

1. Что такое SNMP-протокол, функции и назначение?

2. Назовите вкладки раздела SingleIPManagementи их функции.

Введение

Так как количество сетей растет, сети разнообразным образом объединяются (маршрутизаторы различных поставщиков, хосты со встроенными функциями маршрутизации, терминальные серверы и так далее), задача управления этими системами становится очень важной. В этой главе рассматриваются стандарты, которые используются внутри семейства протоколов Internet, для управления сетью.

Управление сетью в объединенных сетях TCP/IP строится на взаимодействии между станцией управления сетью (менеджер) и элементами сети. Элементами сети могут быть любые объекты, которые используют семейство протоколов TCP/IP: хосты, маршрутизаторы, X терминалы, терминальные сервера, принтеры и так далее. На элементах сети должно быть запущено программное обеспечение, которое называется агентом. Станции управления это обычно рабочие станции с цветным монитором и графическим дисплеем, которые отображают то, что происходит с элементами (которые из них работают, а которые нет, объем траффика по различным каналам за единицу времени и так далее).

Обмен данными, как правило, двусторонний: менеджер просит агента сообщить ему определенное значение (например, "сколько было сгенерировано ICMP ошибок о недоступности порта?"), или агент сообщает менеджеру о каком-либо важном событии ("подключенный интерфейс не работает"). У менеджера должна быть возможность установить переменные в агенте ("измени значение TTL по умолчанию на 64"), помимо того, что менеджер должен иметь возможность считывать переменные от агента.

Управление сетями TCP/IP состоит из трех частей.

Информационная база управления (MIB - Management Information Base), которая указывает, какие переменные в элементах сети необходимо обслуживать (информация, которая может быть запрошена и установлена менеджером). RFC 1213 определяет вторую версию, которая называется MIB-II.
Установка общей структуры и схемы идентификации, используемой для обращения к переменным в MIB. Это называется структурой информации управления ( SMI - Structure of Management Information) и описывается в RFC 1155 . Например, SMI указывает, что счетчик (Counter) это неотрицательное целое число, которое изменяется от 0 до 4294967295 и затем снова возвращается в 0.
Протокол, который функционирует между менеджером и элементом, называется простым протоколом управления сетью ( SNMP - Simple Network Management Protocol). RFC 1157 [ Case et al. 1990] описывает этот протокол. Там же подробно описан формат пакетов, с помощью которых осуществляется обмен. Несмотря на то, что в качестве транспортных протоколов могут быть использованы разные протоколы, обычно с SNMP используется UDP.

Эти RFC определяют то, что в настоящее время называется SNMPv1, или просто SNMP, что мы и обсудим в этой главе. В течение 1993 года были опубликованы дополнительные RFC, которые описывают SNMP Version 2 (SNMPv2), который мы опишем в разделе этой главы.

В этой главе мы рассмотрим протокол, который используется для общения между менеджером и клиентом, во-первых, а затем посмотрим какие переменные использует агент. Мы опишем информационную базу данных, поддерживаемую агентом (MIB), рассмотрим группы, которые мы уже описали в тексте: IP, UDP, TCP и так далее. Рассмотрим примеры, соответствующие каждому описанию, а в процессе рассмотрения будем обращаться к концепции протоколов, описанных в предыдущих главах.

Протокол

SNMP определяет всего пять типов сообщений, которыми обмениваются менеджер и клиент.

Получить значение одной или нескольких переменных: оператор get-request. Получить следующую переменную после этой или несколько указанных переменных: оператор get-next-request. (Мы опишем то, что имеем в виду под словом "следующий" позже в этой главе.) Установить значение одной или нескольких переменных: оператор set-request. Выдать значение одной или нескольких переменных: оператор get-response. Это сообщение возвращается агентом менеджеру в ответ на операторы get-request, get-next-request и set-request. Уведомить менеджера, когда что-либо произошло с агентом: оператор trap.

Первые три сообщения отправляются от менеджера к агенту, а последние два от агента к менеджеру. (Мы будем называть первые три оператора как get, get-next и set.) На рисунке 25.1 приведены все пять операторов.

Так как четыре из пяти SNMP сообщений реализуются простой последовательностью запрос-отклик (менеджер отправляет запрос, а агент возвращает отклик), SNMP используют UDP. Это означает, что запрос от менеджера может не прибыть к агенту, а отклик от агента может не прибыть к менеджеру. В этом случае менеджер, возможно, отработает тайм-аут и осуществит повторную передачу.

Рисунок 25.1 Пять операторов SNMP.

Менеджер отправляет эти три запроса на UDP порт 161. Агент отправляет ловушки (trap) на UDP порт 162. Так как используются два разных порта, одна система может выступать в роли менеджера и агента одновременно. (См. в конце главы.)

На рисунке 25.2 показан формат пяти SNMP сообщений, инкапсулированных в UDP датаграмму.

Рисунок 25.2 Формат пяти SNMP сообщений.

На этом рисунке мы указали в байтах только размер IP и UDP заголовков. Это объясняется тем, что для SNMP сообщений используется кодирование - называемое ASN.1 и BER, которые мы опишем позже в этой главе - в зависимости от типа переменных и их значений.

Значение поля version равно 0. Это значение в действительности равно номеру версии минус единица. (Версия SNMP, которую мы описываем, называется SNMPv1.)

На рисунке 25.3 показано значение для типа блока данных протокола (PDU type). ( PDU - это блок данных протокола - Protocol Data Unit, обычно называемый "пакет".)


	get-request
	get-next-request
	set-request
	get-response
	trap

Рисунок 25.3 Типы PDU сообщений SNMP.

Сообщество (community) это строка символов, в которой содержится пароль в открытом виде. Пароль используется при общении между менеджером и агентом. Обычное значение - 6-символьная строка public.

В операторах get, get-next и set менеджер устанавливает идентификатор запроса (request ID), который возвращается агентом в сообщении get-response. Мы видели этот тип переменной в других UDP приложениях. (Вспомните поле идентификации (identification) DNS на и поле идентификатора транзакции (transaction ID) на .) Это позволяет клиенту (менеджеру в данном случае) сопоставить отклики от сервера (агент) с запросами, которые были отправлены клиентом. Это поле также позволяет менеджеру выдать несколько запросов одному или нескольким агентам, а затем отсортировать полученные отклики.

Статус ошибки (error status) это целое число, которое возвращается агентам и указывает на ошибку. На рисунке 25.4 показаны значения, имена и описания ошибок.

статус ошибки		Описание
	noError	все в порядке
	tooBig	клиент не может поместить отклик в одно SNMP сообщение
	noSuchName	оператор указывает на несуществующую переменную
	badValue	в операции установки использовано недопустимое значение или сделана ошибка в синтаксисе
	readOnly	менеджер попытался изменить переменную, которая помечена как "только для чтения"
	genErr	неопознанная ошибка

Рисунок 25.4 Значения статуса ошибки SNMP.

Если возникла ошибка, индекс ошибки (error index) это целое смещение, указывающее на то, в какой переменной произошла ошибка. Это значение устанавливается агентом только для ошибок noSuchName (нет такого имени), badValue (неверное значение) и readOnly (только для чтения).

Список имен переменных и значений следует в get, get-next и set запросах. Раздел значений игнорируется в операторах get и get-next.

Для оператора trap (PDU type равен 4) формат SNMP сообщения изменяется. Мы опишем поля заголовка ловушки, когда будем описывать этот оператор в разделе этой главы.

Структура управляющей информации

SNMP использует небольшое количество различных типов данных. В этой главе мы рассмотрим эти типы, однако не будем рассматривать то, как эти данные в действительности кодируются (для хранения данных используются битовые шаблоны).

INTEGER (целое число). Некоторые переменные объявляются как целые без ограничений (например, MTU для интерфейса), некоторые определены с конкретными значениями (например, флаг IP о перенаправлении установлен в 1, если перенаправление включено, или в 2, если перенаправление выключено), а другие определены с их минимальными и максимальными значениями (например, номера портов TCP и UDP находятся в диапазоне от 0 до 65535).
OCTET STRING (восьмеричная строка). Строка из 0 или нескольких 8-битных байт. Каждый байт имеет значение от 0 до 255. В кодировании BER, используемом для этих типов данных и для следующего, счетчик количества байт в строке находится перед самой строкой. Эти строки не заканчиваются нулевыми значениями.
DisplayString. Строка из 0 или нескольких 8-битных байт, причем каждый байт должен быть символом из набора ASCII NVT . Все переменные этого типа в MIB-II должны содержать не больше чем 255 символов. (Строка нулевой длины допустима.)
OBJECT IDENTIFIER (идентификатор объекта). Мы опишем их в следующем разделе.
NULL (ноль). Означает, что у соответствующей переменной нет значения. Используется, например, в качестве всех значений для переменных в запросах get или get-next, пока эти переменные запрашиваются, а не устанавливаются.
IpAddress (IP адрес). OCTET STRING (восьмеричная строка) длиной 4, с 1 байтом на каждый байт IP адреса.
PhysAddress (физический адрес). OCTET STRING (восьмеричная строка), содержит физический адрес (например, 6-байтный Ethernet адрес).
Counter (счетчик). Неотрицательное целое число, значение которого увеличивается монотонно от 0 до значения 232-1 (4.294.967.295) и затем вновь возвращается в 0.
Gauge (критерий). Неотрицательное целое число в диапазоне от 0 до 232-1, значение которого может увеличиваться или уменьшаться, однако изменения прекращаются по достижении максимального значения. Это означает, что если значение достигнет величины 232-1, критерий будет оставаться в этом значении до тех пор, пока не будет сброшен. Примером может служить переменная MIB tcpCurrEstab: это количество TCP соединений, находящихся в настоящий момент в состоянии ESTABLISHED (установлено) или CLOSE_WAIT (ожидание закрытия).
TimeTicks (тики времени). Счетчик, который считает время в сотых долях секунды с какой-либо исходной точки. Различные переменные могут указывать начало счета с различных исходных точек, исходная точка используемая для каждой переменной этого типа и указывается, когда переменная объявляется в MIB. Например, переменная sysUpTime это количество сотых долей секунды, в течение которых агент был включен.
SEQUENCE (последовательность). Напоминает структуру в языке программирования С. Например, мы рассмотрим, как в MIB определяется последовательность (SEQUENCE), которая называется UdpEntry и которая содержит информацию об активности конечных точек UDP агента. (Под словом "активность" мы подразумеваем порты, которые используются в настоящее время приложением.) В этой структуре есть две записи:

udpLocalAddress, типа IpAddress, содержащая локальный IP адрес.
udpLocalPort, типа INTEGER, в диапазоне от 0 до 65535, которая содержит локальный номер порта.

SEQUENCE OF (последовательность чего). Это определение вектора со всеми элементами, которые имеют тот же самый тип данных. Если каждый элемент имеет простой тип данных, такой как целое, мы имеем простой вектор (одномерный массив). Однако мы увидим, что SNMP использует эти типы данных с каждым элементом вектора, который является последовательностью (SEQUENCE) (структура). Поэтому мы можем считать их двумерными массивами или таблицей. Например, таблица слушающих процессов (listener) UDP называется udpTable, и является последовательностью (SEQUENCE OF) 2-элементной структуры (SEQUENCE) UdpEntry, которую мы только что описали. На рисунке 25.5 показан двумерный массив.

Рисунок 25.5 Таблица listener UDP (udpTable), которая представлена как двумерный массив SNMP.

Количество строк в этой таблице не определяется SNMP, однако мы увидим, что менеджер, используя оператор get-next (раздел этой главы), может определить, что получена последняя строка таблицы. Также, в разделе мы увидим, как менеджер указывает, какую строку таблицы он хочет получить или установить.

Идентификаторы объектов

Идентификатор объекта это тип данных, указывающий на полномочно названный объект. Под словом "полномочно" мы подразумеваем, что эти идентификаторы не назначаются случайным образом, а назначаются некоторыми организациями, которые несут ответственность за группу идентификаторов.

Идентификатор объекта это последовательность целых десятичных чисел, разделенных точками. Эти целые числа представляют собой древовидную структуру, напоминающую DNS () или файловую систему Unix. В вершине, откуда начинается дерево идентификаторов объектов, существует корень без названия.

На рисунке 25.6 показана структура дерева. Все переменные в MIB начинаются с идентификатора объекта 1.3.6.1.2.1.

У каждого узла в дереве также существует текстовое имя. Имя, соответствующее идентификатору объекта 1.3.6.1.2.1, это iso.org.dod.internet.mgmt.mib. Подобная форма записи имен используется для удобства чтения. Имена переменных MIB используемые при обмене пакетами между менеджером и агентом (рисунок 25.2), это цифровые идентификаторы объектов, начинающиеся с 1.3.6.1.2.1.

Рисунок 25.6 Идентификаторы объектов в информационной базе управления.

Помимо идентификаторов объектов mib, приведенных на рисунке 25.6, мы также привели еще один iso.org.dod.internet.private.enterprises (1.3.5.1.4.1). В этом месте находится MIB различных производителей. В Assigned Numbers RFC приведен список около 400 идентификаторов, зарегистрированных ниже этого узла.

Введение в Информационную Базу Управления (MIB)

Информационная база управления ( MIB - Management Information Base) это информационная база данных, которая обслуживается агентом, а менеджер может запросить информацию из этой базы или записать информацию в эту базу. Мы рассмотрим то, что называется MIB-II и описано в RFC 1213 .

Как показано на рисунке 25.6, MIB поделена на группы: system, interfaces, at (трансляция адресов), ip и так далее.

В этом разделе мы опишем только переменные, находящиеся в группе UDP. Это простая группа с небольшим количеством переменных и одной таблицей. В следующих разделах, на примере этой группы мы покажем, как осуществляется идентификация, построение лексикографического порядка и некоторые простые примеры этих характеристик. После чего, в разделе , мы вернемся к MIB и опишем некоторые другие группы в MIB.

На рисунке 25.6 мы показали группу под названием udp, находящуюся ниже mib. На рисунке 25.7 показана структура группы UDP.

Рисунок 25.7 Древовидная структура таблицы IP адресов.

Как мы говорили ранее, группа UDP содержит четыре переменные, и одну таблицу из двух переменных. На рисунке 25.8 приведены четыре переменные.

	Тип данных	Описание
udpInDatagrams	Counter	Количество UDP датаграмм, доставленных пользовательским процессам.
udpNoPorts	Counter	Количество доставленных UDP датаграмм, для которых не оказалось пользовательского процесса на порте назначения.
udpInErrors	Counter	Количество недоставленных UDP датаграмм не по причине того, что на порте назначения не оказалось приложения (например, ошибка контрольной суммы UDP).
udpOutDatagrams	Counter	Количество отправленных UDP датаграмм.

Рисунок 25.8 Переменные в группе udp.

Мы будем использовать этот формат при описании всех переменных MIB в этой главе. Колонка, помеченная как "R/W", пуста, если переменная предназначена только для чтения или содержит точку (face=Symbol>·), если переменную можно читать и записывать. Мы всегда будем включать эту колонку, даже если все переменные в группе только для чтения (как мы видели в группе udp), чтобы напомнить, что ни одна из переменных не может быть установлена менеджером. В случае если тип данных - INTEGER (целый) с ограничением, мы будем указывать верхний и нижний пределы, как сделано для номера порта UDP на следующем рисунке.

На рисунке 25.9 описываются две переменные в udpTable.

Рисунок 25.9 Переменные в udpTable.

Каждый раз, когда мы описываем переменные в SNMP таблице, первая строка рисунка содержит значение "index", используемое для обращения к каждой строке таблицы. Мы покажем некоторые примеры того, как это делается, в следующем разделе.

Диаграммы зависимостей

Здесь приводится взаимосвязь между первыми тремя счетчиками, описанными на рисунке 25.8. Диаграммы зависимостей иллюстрируют взаимосвязь между различными MIB переменными в заданной группе. На рисунке 25.10 показана диаграмма зависимостей для UDP группы.

Рисунок 25.10 Диаграмма зависимостей для группы UDP.

Эта диаграмма показывает, что количество UDP датаграмм, доставленных приложению (udpInDatagrams), можно получить как количество UDP датаграмм, доставленных от IP к UDP, минус udpInErrors, минус udpNoPorts. Количество UDP датаграмм, доставленных в IP (udpOutDatagrams), это количество, переданное в UDP от приложения. Можно сделать вывод, что udpInDatagrams не включает в себя udpInErrors или udpNoPorts.

Эти диаграммы были использованы в процессе разработки MIB, для проверки того, что все пути данных для пакета были учтены. [ Rose 1994] показывает диаграммы зависимостей для всех групп в MIB.

Примеры идентификации

Каждая переменная в MIB должна быть идентифицирована, когда SNMP обращается к ней, чтобы получить или установить ее значение. Во-первых, обращение осуществляется только к листовым узлам (листовой узел в древовидной структуре - любой самый удаленный элемент от корня). SNMP не работает с целыми рядами или колонками таблицы. Возвращаясь к рисунку 25.7, мы видим, что листовыми узлами дерева, являются те четыре, что мы описали на рисунке 25.8, и два на рисунке 25.9. Узлы mib, udp, udpTable и udpEntry не являются листовыми узлами.

Простые переменные

На то, что эта переменная простая, указывает ".0", добавленный к идентификатору объекта переменной. Например, к счетчику udpInDatagrams показанному на рисунке 25.8, c идентификатором объекта 1.3.6.1.2.1.7.1, можно обратиться как 1.3.6.1.2.1.7.1.0. Текстовое имя при подобном обращении будет iso.org.dod.internet.mgmt.mib.udp.udpInDatagrams.0.

Однако обращения к этой переменной обычно делаются в сокращенном виде, udpInDatagrams.0, мы повторим, что name (имя) переменной, которое появляется в сообщении SNMP (рисунок 25.2), это идентификатор объекта 1.3.6.1.2.1.7.1.0.

Рассмотрим идентификацию пунктов таблицы более подробно. Давайте вернемся к таблице слушающего процесса UDP (рисунок 25.7).

Для каждой таблицы в MIB указан один или несколько индексов. Для таблицы слушающего процесса UDP, MIB определяет индекс как комбинацию двух переменных udpLocalAddress (локальный IP адрес) и udpLocalPort (локальный UDP порт), индекс в данном случае - целое число. (Мы показали этот индекс в верхней строке на рисунке 25.9.)

Представьте себе, что в таблице слушающего процесса UDP есть три строки: первая для IP адреса 0.0.0.0 и порта 67, вторая для 0.0.0.0 и порта 161 и третья для 0.0.0.0 и порта 520. На рисунке 25.11 показана эта таблица.

Рисунок 25.11 Простая таблица слушающего процесса UDP.

Из таблицы видно, что система готова принимать UDP датаграммы с любого интерфейса для портов 67 (BOOTP сервер), 161 (SNMP) и 520 (RIP). К трем строкам в таблице можно обратиться, как показано на рисунке 25.12.

Лексикографический порядок

Порядок в MIB основан на расположении идентификаторов объектов. Все записи в MIB таблице расположены в лексикографическом порядке в соответствии с их идентификаторами объектов. Это означает, что шесть переменных, приведенных на рисунке 25.12, расставлены в MIB так, как это показано на рисунке 25.13. В результате можно декларировать два правила.

Строка (ряд)	Идентификатор объекта	Сокращенное имя	Значение
	1.3.6.1.2.1.7.5.1.2.0.0.0.0.67	udpLocalAddress.0.0.0.0.67 udpLocalPort.0.0.0.0.67
	1.3.6.1.2.1.7.5.1.2.0.0.0.0.161	udpLocalAddress.0.0.0.0.161 udpLocalPort.0.0.0.0.161
	1.3.6.1.2.1.7.5.1.1.0.0.0.0.520	udpLocalAddress.0.0.0.0.520 udpLocalPort.0.0.0.0.520

Рисунок 25.12 Пример идентификации строк в таблице слушающего процесса UDP.

Идентификатор объекта (в лексикографическом порядке)	Сокращенное имя	Значение
1.3.6.1.2.1.7.5.1.1.0.0.0.0.67 1.3.6.1.2.1.7.5.1.1.0.0.0.0.161 1.3.6.1.2.1.7.5.1.1.0.0.0.0.520	udpLocalAddress.0.0.0.0.67 udpLocalAddress.0.0.0.0.161 udpLocalAddress.0.0.0.0.520	0.0.0.0 0.0.0.0 0.0.0.0
1.3.6.1.2.1.7.5.1.2.0.0.0.0.67 1.3.6.1.2.1.7.5.1.2.0.0.0.0.161 1.3.6.1.2.1.7.5.1.2.0.0.0.0.520	udpLocalPort.0.0.0.0.67 udpLocalPort.0.0.0.0.161 udpLocalPort.0.0.0.0.520	67 161 520

Рисунок 25.13 Лексикографический порядок таблицы слушающего процесса UDP.

Так переменная udpLocalAddress всегда появляется перед появлением в этой же таблице следующей переменной (udpLocalPort), это означает, что доступ к таблице осуществляется в порядке колонка-строка. Это является результатом лексикографического упорядочивания идентификаторов объектов, а не имен, предназначенных для чтения человеком.
Порядок расположения строк в таблице зависит от значений индексов для таблицы. На рисунке 25.13, 67 лексикографически меньше чем 161, который, в свою очередь, лексикографически меньше чем 520.

На рисунке 25.14 показан порядок колонка-строка для нашего примера таблицы слушающего процесса UDP.

Рисунок 25.14 Таблица слушающего процесса UDP, показанная в порядке колонка-ряд.

Мы еще увидим этот порядок колонка-строка, когда будем использовать оператор get-next в следующем разделе.

Простые примеры

В этой главе мы покажем некоторые простые примеры того, как можно получить значения переменных от SNMP агента. Программное обеспечение, используемое для опроса агента, называется snmpi и взято из системы ISODE. Оба кратко описаны в [ Rose 1994].

Простые переменные

Мы запрашиваем маршрутизатор на предмет двух простых переменных из UDP группы:

sun % snmpi -a gateway -c secret

snmpi> get udpInDatagrams.0 udpNoPorts.0
udpInDatagrams.0=616168 udpInDatagrams.0=616168
udpNoPorts.0=33

snmpi> quit

Опция -a указывает на агента, с которым мы хотим пообщаться, а опция -c указывает SNMP сообщество. Это пароль, устанавливаемый клиентом (snmpi в данном случае), и если сервер (агент на системе gateway) распознает имя сообщества, он ответит на запрос менеджера. Агент может позволить клиентам, принадлежащим к одному сообществу, только чтение своих переменных, а клиентам из другого сообщества чтение и запись.

Программа выводит приглашение snmpi>, после чего мы можем, например, ввести команду get, которая будет преобразована в SNMP сообщение get-request. Затем мы вводим quit. (Во всех следующих примерах последняя команда quit удалена.) На рисунке 25.15 показаны две строки вывода tcpdump для этого примера.

1 0.0 sun.1024 > gateway.161: GetRequest (42)
1.3.6.1.2.1.7.1.0 1.3.6.1.2.1.7.2.0

2 0.348875 (0.3489) gateway.161 > sun.1024: GetResponse (46)
1.3.6.1.2.1.7.1.0=616168
1.3.6.1.2.1.7.2.0=33

Рисунок 25.15 Вывод tcpdump для простого запроса SNMP.

Запрос о двух переменных посылается в одной UDP датаграмме, отклик также прибывает в одной UDP датаграмме.

Мы показали переменные в виде соответствующих им идентификаторов объектов, потому что именно это было отправлено в SNMP сообщениях. Мы должны были указать эти две переменные как 0. Обратите внимание на то, что в отклике всегда возвращается имя переменной (идентификатора объекта). Ниже мы увидим, что это необходимо для работы оператора get-next.

Оператор get-next

Функционирование оператора get-next основано на лексикографическом порядке MIB. Мы начнем следующий пример с запроса следующего идентификатора объекта после udp (не указывая объект, так как это не листовой объект). При этом будет возвращен первый объект группы UDP. Затем мы запросим следующую запись, будет возвращена вторая запись. И наконец, мы повторим это еще раз, чтобы получить третью запись:

sun % snmpi -a gateway -c secret

Snmpi> next udp
udpInDatagrams.0=616318

snmpi> next udpInDatagrams.0
udpNoPorts.0=33

snmpi> next udpNoPorts.0
udpInErrors.0=0

Этот пример показывает, почему оператор get-next должен возвращать имя переменной: мы спрашиваем агента о следующей переменной, и агент возвращает ее имя и значение.

При использовании оператора get-next менеджер осуществляет циклический опрос всех переменных, поддерживаемых агентом (цикл стартует с начала MIB). Другое использование этого оператора - просмотр таблиц.

Доступ к таблице

Мы можем убедиться в том, что таблица имеет организацию колонка-строка, воспользовавшись программой, которая отправляет запросы, для того чтобы пройти через таблицу слушающего процесса UDP. Мы начнем с того, что спросим следующую переменную после udpTable. Так как это не листовой объект, мы не можем указать объект, однако оператор get-next все равно возвращает следующий объект в таблице. Затем мы продолжим движение по таблице, так как агент возвращает следующую переменную, в соответствии с порядком столбец-строка:

sun % snmpi -a gateway -c secret

snmpi> next udpTable
udpLocalAddress.0.0.0.0.67=0.0.0.0

snmpi> next udpLocalAddress.0.0.0.0.67
udpLocalAddress.0.0.0.0.161=0.0.0.0

snmpi> next udpLocalAddress.0.0.0.0.161
udpLocalAddress.0.0.0.0.520=0.0.0.0

snmpi> next udpLocalAddress.0.0.0.0.520
udpLocalPort.0.0.0.0.67=67

snmpi> next udpLocalPort.0.0.0.0.67
udpLocalPort.0.0.0.0.161=161

snmpi> next udpLocalPort.0.0.0.0.161
udpLocalPort.0.0.0.0.520=520

snmpi> next udpLocalPort.0.0.0.0.520
snmpInPkts.0=59 здесь мы закончили просмотр таблицы слушающего процесса UDP

Мы видим, что порядок, возвращенный в данном примере, соответствует порядку, приведенному на рисунке 25.14.

Как менеджер может определить, что он достиг конца таблицы? Так как ответ на оператор get-next содержит имя следующего пункта в MIB после таблицы, менеджер может сказать, когда имя изменилось. В нашем примере последний пункт в таблице слушающего процесса UDP следует за переменной snmpInPkts.

Информационная база управления (продолжение)

А сейчас мы вернемся к описанию MIB. Опишем следующие группы: system (идентификация системы), if (интерфейсы), at (трансляция адресов), ip, icmp и tcp. Также определены дополнительные группы.

Группа system

Группа system довольно проста; она состоит из семи простых переменных (таблиц в этой группе нет). На рисунке 25.16 приведены их имена, типы данных и описания.

	Тип данных	Описание
sysDescr	DisplayString	Текстовое описание пункта.
sysObjectID	ObjectID	Идентификатор поставщика в поддереве 1.3.6.1.4.1.
sysUpTime	TimeTicks	Время в сотых долях секунд с того момента, когда часть системы, отвечающая за управление сетевое, была перестартована.
sysContact	DisplayString	Имя человека, к которому необходимо обратиться, и как его можно найти.
sysName	DisplayString	Полное имя домена узла ( FQDN) .
sysLocation	DisplayString	Физическое расположение узла.
sysServices		Значение, указывающее на то, какие сервисы предоставляются узлом. Это сумма уровней OSI модели, поддерживаемых узлом. Следующие значения складываются вместе, в зависимости от того, какие сервисы поддерживаются: 0х01 (физический), 0х02 (канальный), 0х04 (сетевой), 0х08 (точка-точка), 0х40 (прикладной).

Рисунок 25.16 Простые переменные группы system.

Мы можем отправить запрос маршрутизатору netb, для того чтобы получить некоторые из этих переменных:

sun % snmpi -a netb -c secret

Snmpi> get sysDescr.0 sysObjectID.0 sysUpTime.0 sysServices.0
sysDescr.0="Epilogue Technology SNMP agent for Telebit NetBlazer"
sysObjectID.0=1.3.6.1.4.1.12.42.3.1
sysUpTime.0=22 days, 11 hours, 23 minutes, 2 seconds (194178200 timeticks)
sysServices.0=0xc

Идентификатор объекта системы находится в группе internet.private.enterprises (1.3.6.1.4.1), в соответствии с рисунком 25.6. Из Assigned Numbers RFC мы можем определить, что следующий идентификатор объекта (12) назначен производителю (Epilogue).

Также мы можем видеть, что переменная sysServices является суммой 4 и 8: этот элемент сети (netb) поддерживает IP уровень (маршрутизация) и транспортный уровень (точка-точка).

Группа interface

Только одна простая переменная определена для этой группы: количество интерфейсов в системе. Рисунок 25.17.

Рисунок 25.17 Простая переменная в группе if.

В этой группе также определена таблица, состоящая из 22 строк. Каждая строка в таблице определяет характеристики каждого интерфейса, как показано на рисунке 25.18.

Таблица интерфейсов, индекс = < IfIndex >
	Тип данных	Описание
ifIndex	INTEGER	Индекс интерфейса, находится в диапазоне между единицей и ifNumber.
ifDescr	DisplayString	Текстовое описание интерфейса.
ifType	INTEGER	Тип, например: 6 = Ethernet, 7 = 802.3 Ethernet, 9 = 802.5 Token ring, 23 = PPP, 28 = SLIP и многие другие переменные.
ifMtu	INTEGER	MTU интерфейса (максимальный блок передачи).
ifSpeed	Gauge	Скорость в битах в секунду.
ifPhysAddress	PhysAddress	Физический адрес или строка нулевой длины для интерфейсов без физического адреса (например, последовательные каналы).
ifAdminStatus		Желательное состояние интерфейса: 1 = активен, 2 = выключен, 3 = тестируется.
ifOperStatus		Текущее состояние интерфейса: 1 = активен, 2 = выключен, 3 = тестируется.
ifLastChange	TimeTicks	Значение sysUpTime на момент, когда интерфейс вошел в текущее состояние функционирования.
ifInOctets	Counter	Полное количество принятых байтов, включая символы построения фреймов.
ifInUcastPkts	Counter	Количество персональных пакетов, доставленных к верхним уровням.
ifInNUcastPkts	Counter	Количество неперсональных (широковещательных или групповых) пакетов, доставленных к верхним уровням.
ifInDiscards	Counter	Количество принятых и отброшенных пакетов, даже если в пакете не была обнаружена ошибка (переполнение буферов).
ifInErrors	Counter	Количество пакетов принятых и отброшенных по причине ошибок.
ifInUnknownProtos	Counter	Количество принятых и отброшенных пакетов по причине того, что они принадлежали неизвестному протоколу.
ifOutOctets	Counter	Количество переданных байт, включая символы построения фреймов.
ifOutUcastPkts	Counter	Количество персональных пакетов, принятых от верхних уровней.
ifOutNUcastPkts	Counter	Количество неперсональных (широковещательных или групповых) пакетов, принятых от верхних уровней.
ifOutDiscards	Counter	Количество исходящих пакетов, которые были отброшены, даже если в пакетах не была обнаружена ошибка (переполнение буферов).
ifOutErrors	Counter	Количество исходящих пакетов, отброшенных по причине ошибок.
ifOutQLen	Gauge	Количество пакетов, находящихся в выходной очереди.
ifSpecific	ObjectID	Ссылка на определение MIB конкретно для этого типа среды передачи.

Рисунок 25.18 Переменные в таблице интерфейсов: ifTable.

Мы можем запросить хост sun на предмет некоторых из этих переменных для всех его интерфейсов. Мы ожидаем увидеть три интерфейса (см. главу 3, раздел ), если активизирован SLIP интерфейс:

sun % snmpi -a sun

snmpi> next ifTable во-первых, мы видим, чему равен индекс первого интерфейса
ifIndex.1=1

snmpi> get ifDescr.1 ifType.1 ifMtu.1 ifSpeed.1 ifPhysAddress.1
ifDescr.1="le0"
ifType.1=ethernet-csmacd (6)
ifMtu.1=1500
ifSpeed.1=10000000
ifPhysAddress.1=0x08:00:20:03:f6:42

snmpi> next ifDescr.1 ifType.1 ifMtu.1 ifSpeed.1 ifPhysAddress.1
ifDescr.2="sl0"
ifType.2=propPointToPointSerial (22)
ifMtu.2=552
ifSpeed.2=0
ifPhysAddress.2=0x00:00:00:00:00:00

snmpi> next ifDescr.2 ifType.2 ifMtu.2 ifSpeed.2 ifPhysAddress.2
ifDescr.3="lo0"
ifType.3=softwareLoopback (24)
ifMtu.3=1536
ifSpeed.3=0
ifPhysAddress.3=0x00:00:00:00:00:00

Во-первых, мы получили пять переменных для первого интерфейса, используя оператор get, а затем получили те же пять переменных для второго интерфейса, используя оператор get-next. Последняя команда получает эти же пять переменных для третьего интерфейса и опять с использованием команды get-next.

Тип интерфейса для SLIP канала сообщается как последовательное соединение точка-точка, а не SLIP. Также, не сообщается скорость SLIP канала.

Очень важно понять взаимосвязь между оператором get-next и порядком расположения информации в таблице, а именно колонка-строка. Когда мы задаем next ifDescr.1, возвращается следующая строка таблицы для этой переменной, а не следующую переменную в этой же строке. Однако если бы таблицы хранились в порядке строка-колонка, мы могли подобным образом перейти к следующему появлению заданной переменной.

Группа at

Группа трансляции адресов поддерживается во всех системах, однако ее ценность значительно уменьшилась, после того как стала использоваться MIB-II. С использованием MIB-II, каждая группа сетевых протоколов (например, IP) содержит свою собственную таблицу трансляции адресов. Для IP это ipNetToMediaTable.

В группе at определена только одна таблица из трех строк, как показано на рисунке 25.19.

Мы можем использовать новую команду, существующую в программе snmpi, чтобы получить содержимое таблицы в целом. Мы запросим маршрутизатор с именем kinetics (который предоставляет маршруты между TCP/IP сетью и сетью AppleTalk), выдать полный ARP кэш. Этот вывод будет находиться в лексикографическом порядке в виде пунктов, находящихся в таблице:

Таблица трансляции адресов, индекс = .1.
	Тип данных	Описание
atIfIndex	INTEGER	Номер интерфейса: ifIndex.
atPhysAddress	PhysAddress	Физический адрес. Установка этого параметра в строку с нулевой длиной приводит к тому, что пункт считается некорректным.
atNetAddress	NetworkAddress	IP адрес

Рисунок 25.19 Таблица трансляции адресов: atTable.

sun % snmpi -a kinetics -c secret dump at

atIfIndex.1.1.140.252.1.4=1
atIfIndex.1.1.140.252.1.22=1
atIfIndex.1.1.140.252.1.183=1
atIfIndex.2.1.140.252.6.4=2
atIfIndex.2.1.140.252.6.6=2

atPhysAddress.1.1.140.252.1.4=0xaa:00:04:00:f4:14
atPhysAddress.1.1.140.252.1.22=0x08:00:20:0f:2d:38
atPhysAddress.1.1.140.252.1.183=0x00:80:ad:03:6a:80
atPhysAddress.2.1.140.252.6.4=0x00:02:16:48
atPhysAddress.2.1.140.252.6.6=0x00:02:3c:48

atNetAddress.1.1.140.252.1.4=140.252.1.4
atNetAddress.1.1.140.252.1.22=140.252.1.22
atNetAddress.1.1.140.252.1.183=140.252.1.183
atNetAddress.2.1.140.252.6.4=140.252.6.4
atNetAddress.2.1.140.252.6.6=140.252.6.6

С использованием tcpdump можно увидеть следующее. Для того чтобы получить полную таблицу, snmpi, во-первых, выдает get-next для имени таблицы (at в данном примере), чтобы получить первый пункт. Затем печатает первый пункт и выдает get-next. Это продолжается до тех пор, пока не будет получена вся таблица целиком.

На рисунке 25.20 показана подобная таблица.


	0xaa:00:04:00:f4:14	140.252.1.4
	0x08:00:20:0f:2d:38	140.252.1.22
	0x00:80:ad:03:6a:80	140.252.1.183
	0x00:02:16:48	140.252.6.4
	0x00:02:3c:48	140.252.6.6

Рисунок 25.20 Пример таблицы at (ARP кэш).

Физические адреса AppleTalk с номером интерфейса - 2 имеют 32-битные значения, а не 48-битные, как у привычных Ethernet адресов. Также обратите внимание на то, что существуют запись для нашего маршрутизатора (netb находится по адресу 140.252.1.183), так как kinetics и netb находятся на одном и том же Ethernet кабеле (140.252.1), и kinetics должен использовать ARP, чтобы послать нам SNMP отклик.

Группа ip

Группа ip определяет большое количество переменных и три таблицы. На рисунке 25.21 приведены простые переменные.

	Тип данных	Описание
ipForwarding		1 означает, что система перенаправляет IP датаграммы, а 2 означает, что не перенаправляет.
ipDefaultTTL	INTEGER	Значение TTL по умолчанию, когда его не предоставляет транспортный уровень.
ipInReceives	Counter	Полное количество IP датаграмм, полученных со всех интерфейсов.
ipInHdrErrors	Counter	Количество IP датаграмм, отброшенных из-за ошибок в заголовке (например, ошибка контрольной суммы, несовпадение номера версии, истечение TTL и так далее).
ipInAddrErrors	Counter	Количество IP датаграмм, отброшенных из-за неправильного адреса назначения.
IpForwDatagrams	Counter	Количество IP датаграмм, для которых была сделана попытка перенаправить.
ipInUnknownProtos	Counter	Количество локально адресованных IP датаграмм, у которых было неверное поле протокола.
ipInDiscards	Counter	Количество принятых IP датаграмм, отброшенных из-за недостаточного размера буфера.
ipInDelivers	Counter	Количество IP датаграмм, доставленных соответствующему модулю протокола.
ipOutRequests	Counter	Полное количество IP датаграмм, переданных в IP уровень для передачи. Сюда не включены те, которые были посчитаны в ipForwDatagrams.
ipOutDiscards	Counter	Количество исходящих IP датаграмм, которые были отброшены из-за отсутствия места в буфере.
ipOutNoRoutes	Counter	Количество IP датаграмм, которые были отброшены из-за того, что не был найден маршрут.
ipReasmTimeout	INTEGER	Максимальное количество секунд, в течение которого принятые фрагменты ждали повторной сборки.
ipReasmReqds	Counter	Количество принятых IP фрагментов, которые должны быть собраны.
ipReasmOKs	Counter	Количество успешно собранных IP датаграмм.
ipReasmFails	Counter	Количество сбоев в алгоритме повторной сборки IP.
ipFragOKs	Counter	Количество успешно фрагментированных IP датаграмм.
ipFragFails	Counter	Количество IP датаграмм, которые необходимо фрагментировать, однако это не было сделано, потому что был установлен флаг "не фрагментировать".
ipFragCreates	Counter	Количество IP фрагментов, которые были получены при фрагментации.
ipRoutingDiscards	Counter	Количество пунктов маршрутизации, выбранных для уничтожения, даже если они существовали и были верны.

Рисунок 25.21 Простые переменные группы ip.

Первая таблица в группе ip это таблица IP адресов. Она содержит по одной строке для каждого IP адреса в системе. Каждая строка содержит пять переменных, описанных на рисунке 25.22.

Таблица IP адресов, индекс =
	Тип данных	Описание
ipAdEntAddr	IpAddress	IP адрес для этой строки.
ipAdEntIfIndex	INTEGER	Соответствующий номер интерфейса: ifIndex.
ipAdEntNetMask	IpAddress	Маска подсети для этого IP адреса.
ipAdEntBcastAddr		Значение младших битов в широковещательном IP адресе. Обычно равно 1.
ipAdEntReasmMaxSize		Размер максимальной принятой IP датаграммы для этого интерфейса, которая может быть повторно собрана.

Рисунок 25.22 Таблица IP адресов: ipAddrTable.

Мы можем запросить хост sun, чтобы получить таблицу IP адресов:

sun % snmpi -a sun dump ipAddrTable

ipAdEntAddr.127.0.0.1=127.0.0.1
ipAdEntAddr.140.252.1.29=140.252.1.29
ipAdEntAddr.140.252.13.33=140.252.13.33

ipAdEntIfIndex.127.0.0.1=3 loopback интерфейс, lo0
ipAdEntIfIndex.140.252.1.29=2 SLIP интерфейс, sl0
ipAdEntIfIndex.140.252.13.33=1 Ethernet интерфейс, le0

ipAdEntNetMask.127.0.0.1=255.0.0.0
ipAdEntNetMask.140.252.1.29=255.255.255.0
ipAdEntNetMask.140.252.13.33=255.255.255.224

ipAdEntBcastAddr.127.0.0.1=1 все три используют единичный бит
ipAdEntBcastAddr.140.252.1.29=1 для широковещательного адреса
ipAdEntBcastAddr.140.252.13.33=1

ipAdEntReasmMaxSize.127.0.0.1=65535
ipAdEntReasmMaxSize.140.252.1.29=65535
ipAdEntReasmMaxSize.140.252.13.33=65535

Номера интерфейсов можно сравнить с выводом, полученным на рисунке 25.18, а IP адреса и маски подсетей можно сравнить со значениями, полученными в выводе команды ifconfig в разделе главы 3.

Следующая таблица, приведенная на рисунке 25.23, это таблица IP маршрутизации. (Обратитесь к описанию таблиц маршрутизации, приведенному в разделе главы 9.) В качестве индекса для получения доступа к каждой строке таблицы, используется IP адрес назначения.

На рисунке 25.24 приведена таблица маршрутизации для хоста sun, полученная с помощью команды dump ipRouteTable программы snmpi. Мы удалили все пять показателей маршрутизации, так как все они равны -1, а в заголовках колонок удалили префикс ipRoute для каждого имени переменной.

Таблица маршрутизации IP, индекс =
	Тип данных	Описание
ipRouteDest	IpAddress	IP адрес назначения. Значение 0.0.0.0 указывает на пункт по умолчанию.
ipRouteIfIndex	INTEGER	Номер интерфейса: ifIndex.
ipRouteMetric1	INTEGER	Первичный показатель маршрута. Значение показателя зависит от протокола маршрутизации (ipRouteProto). Значение -1 означает, что маршрут не используется.
ipRouteMetric2	INTEGER
ipRouteMetric3	INTEGER	Альтернативный показатель маршрута.
ipRouteMetric4	INTEGER	Альтернативный показатель маршрута.
ipRouteNextHop	IpAddress	IP адрес маршрутизатора следующей пересылки.
ipRouteType	INTEGER	Тип маршрута: 1=другой, 2=недействующий маршрут, 3=прямой, 4=непрямой.
ipRouteProto	INTEGER	Протокол маршрутизации: 1=другой, 4=ICMP перенаправление, 8=RIP, 13=OSPF, 14=BGP и другие.
ipRouteAge	INTEGER	Количество секунд, которое прошло с того момента, когда маршрут был последний раз обновлен или определен как корректный.
ipRouteMask	IpAddress	Маска, которая должна быть добавлена по логическому И к IP адресу назначения, перед тем как она будет сравнена с ipRouteDest.
ipRouteMetric5	INTEGER	Альтернативный показатель маршрута.
ipRouteInfo	ObjectID	Ссылка на конкретное определение MIB для этого протокола маршрутизации.

Рисунок 25.23 Таблица IP маршрутизации: ipRouteTable.


0.0.0.0	140.252.1.183	непрямой (4)	другой (1)	0.0.0.0
127.0.0.1	127.0.0.1	прямой (3)	другой (1)	255.255.255.255
140.252.1.183	140.252.1.29	прямой (3)	другой (1)	255.255.255.255
140.252.13.32	140.252.13.33	прямой (3)	другой (1)	255.255.0.0
140.252.13.65	140.252.13.35	непрямой (4)	другой (1)	255.255.255.255

Рисунок 25.24 Таблица IP маршрутизации маршрутизатора sun.

Для сравнения здесь приводится таблица маршрутизации IP в формате вывода команды netstat (см. главу 9, раздел ). На рисунке 25.24 таблица маршрутизации приводится в лексикографическом порядке:

sun % netstat -rn
Routing tables
Destination Gateway Flags Refcnt Use Interface
140.252.13.65 140.252.13.35 UGH 0 115 le0
127.0.0.1 127.0.0.1 UH 1 1107 lo0
140.252.1.183 140.252.1.29 UH 0 86 sl0
default 140.252.1.183 UG 2 1628 sl0
140.252.13.32 140.252.13.33 U 8 68359 le0

И последняя таблица для группы ip это таблица трансляции адресов, приведенная на рисунке 25.25. Как мы говорили раньше, группа at в настоящее время практически не используется (как устаревшая), и эта таблица заменяет ее.

Таблица трансляции IP адресов, индекс = .
Имя	Тип данных	Описание
ipNetToMediaIfIndex	INTEGER	Соответствующий интерфейс: ifIndex.
ipNetToMediaPhysAddress	PhysAddress	Физический адрес.
ipNetToMediaNetAddress	IpAddress	IP адрес.
ipNetToMediaType		Тип сопоставления: 1=другой, 2=неиспользуемый, 3=динамический, 4=статический.

Рисунок 25.25 Таблица трансляции IP адресов: ipNetToMediaTable.

Здесь мы приводим ARP кэш системы sun:

Face="Courier New" size=1>

sun % arp -a
svr4 (140.252.13.34) at 0:0:c0:c2:9b:26
bsdi (140.252.13.35) at 0:0:c0:6f:2d:40

и соответствующий SNMP вывод:

Face="Courier New" size=1>

sun % snmpi -a sun dump ipNetToMediaTable

IpNetToMediaIfIndex.1.140.252.13.34=1
ipNetToMediaIfIndex.1.140.252.13.35=1
ipNetToMediaPhysAddress.1.140.252.13.34=0x00:00:c0:c2:9b:26
ipNetToMediaPhysAddress.1.140.252.13.35=0x00:00:c0:6f:2d:40
ipNetToMediaNetAddress.1.140.252.13.34=140.252.13.34
ipNetToMediaNetAddress.1.140.252.13.35=140.252.13.35
ipNetToMediaType.1.140.252.13.34=dynamic(3)
ipNetToMediaType.1.140.252.13.35=dynamic(3)

Группа icmp

Группа icmp состоит из четырех общих счетчиков (общее количество входящих и исходящих ICMP сообщений и количество входящих и исходящих ICMP сообщений с ошибками) и 22-х счетчиков для различных типов ICMP сообщений: 11 счетчиков на входящие сообщения и 11 счетчиков на исходящие сообщения. Это показано на рисунке 25.26.

Для ICMP сообщений с дополнительными кодами (обратитесь к , на котором приведены 15 различных кодов для сообщения о недостижимости пункта назначения) отдельный счетчик для каждого SNMP кода не поддерживается.

Группа tcp

На рисунке 25.27 описаны простые переменные группы tcp. Многие из них соответствуют состояниям TCP, которые показаны на .

	Тип данных	Описание
icmpInMsgs	Counter	Полное количество принятых ICMP сообщений.
icmpInErrors	Counter	Количество принятых ICMP сообщений с ошибками (например, ошибочная контрольная сумма ICMP).
icmpInDestUnreachs	Counter	Количество принятых ICMP сообщений о недоступности источника.
icmpInTimeExcds	Counter	Количество принятых ICMP сообщений об истечении времени.
icmpInParmProbs	Counter	Количество принятых ICMP сообщений о проблемах с параметром.
icmpInSrcQuenchs	Counter	Количество принятых ICMP сообщений о подавлении источника.
icmpInRedirects	Counter	Количество принятых ICMP сообщений о перенаправлении.
icmpInEchos	Counter	Количество принятых ICMP сообщений с эхо запросом.
icmpInEchoReps	Counter	Количество принятых ICMP сообщений с эхо откликом.
icmpInTimestamps	Counter	Количество принятых ICMP сообщений с запросом временной марки.
icmpInTimestampReps	Counter	Количество принятых ICMP сообщений с откликом временной марки.
icmpInAddrMasks	Counter	Количество принятых ICMP сообщений с запросом маски адреса.
icmpInAddrMaskReps	Counter	Количество принятых ICMP сообщений с откликом маски адреса.
icmpOutMsgs	Counter	Полное количество исходящих ICMP сообщений.
icmpOutErrors	Counter	Количество ICMP сообщений, которые не были отправлены из-за проблем внутри ICMP (переполнение буферов).
icmpOutDestUnreachs	Counter	Количество посланных ICMP сообщений о недоступности пункта назначения.
icmpOutTimeExcds	Counter	Количество посланных ICMP сообщений об истечении времени.
icmpOutParmProbs	Counter	Количество посланных ICMP сообщений о проблемах с параметром.
icmpOutSrcQuenchs	Counter	Количество посланных ICMP сообщений о подавлении источника.
icmpOutRedirects	Counter	Количество посланных ICMP сообщений о перенаправлении.
icmpOutEchos	Counter	Количество посланных ICMP сообщений с эхо запросом.
icmpOutEchoReps	Counter	Количество посланных ICMP сообщений с эхо откликом.
icmpOutTimestamps	Counter	Количество посланных ICMP сообщений с запросом временной марки.
icmpOutTimestampReps	Counter	Количество посланных ICMP сообщений с откликом временной марки.
icmpOutAddrMasks	Counter	Количество посланных ICMP сообщений с запросом маски адреса.
icmpOutAddrMaskReps	Counter	Количество посланных ICMP сообщений с откликом маски адреса.

Рисунок 25.26 Простые переменные группы icmp.

Мы можем запросить некоторые из этих переменных для системы sun:

Face="Courier New" size=1>

sun % snmpi -a sun

Snmpi> get tcpRtoAlgorithm.0 tcpRtoMin.0 tcpRtoMax.0 tcpMaxConn.0
tcpRtoAlgorithm.0=vanj(4)
tcpRtoMin.0=200
tcpRtoMax.0=12800
tcpMaxConn.0=-1

Система SunOS 4.1.3 использует алгоритм тайм-аута и повторной передачи, разработанный Van Jacobson, при этом используемые тайм-ауты находятся в диапазоне от 200 миллисекунд до 12,8 секунд, и не существует фиксированного предела для количества TCP соединений. (Верхняя граница диапазона, составляющая 12,8 секунды, неверна, так как большинство реализаций используют верхний предел в 64 секунды, как мы видели в .)

Группа tcp имеет одну таблицу, таблицу TCP соединений, показанную на рисунке 25.28. Она содержит по одной строке для каждого соединения. Каждая строка содержит пять переменных: состояние соединения, локальный IP адрес, локальный номер порта, удаленный IP адрес и удаленный номер порта.

	Тип данных	Описание
tcpRtoAlgorithm	INTEGER	Алгоритм, используемый для расчета величин тайм-аутов и повторных передач: 1=нет, 2=постоянный RTO, 3=MIL-STD-1778 (), 4=алгоритм Van Jacobson.
tcpRtoMin	INTEGER	Минимальное значение тайм-аута повторной передачи, в миллисекундах.
tcpRtoMax	INTEGER	Максимальное значение тайм-аута повторной передачи, в миллисекундах.
tcpMaxConn	INTEGER	Максимальное количество TCP соединений. Значение -1 обозначает, что эта величина определяется динамически.
tcpActiveOpens	Counter	Количество переходов от состояния CLOSED к состоянию SYN_SENT.
tcpPassiveOpens	Counter	Количество переходов от состояния LISTEN к состоянию SYN_RCVD.
tcpAttemptFails	Counter	Количество переходов от состояния SYN_SENT или SYN_RCVD к состоянию CLOSED, плюс количество переходов от состояния SYN_RCVD к состоянию LISTEN.
tcpEstabResets	Counter	Количество переходов от состояния ESTABLISHED или CLOSE_WAIT к состоянию CLOSED.
tcpCurrEstab	Gauge	Количество соединений, находящихся в настоящее время в состоянии ESTABLISHED или CLOSE_WAIT.
tcpInSegs	Counter	Полное количество принятых сегментов.
tcpOutSegs	Counter	Полное количество отправленных сегментов, за исключением тех, которые содержали только повторно передаваемые байты.
tcpRetransSegs	Counter	Полное количество повторно переданных сегментов.
tcpInErrs	Counter	Полное количество сегментов, принятых с ошибками (например, неверная контрольная сумма).
tcpConnLocalAddress	IpAddress	Локальный IP адрес. 0.0.0.0 указывает на то, что слушающий процесс готов принять соединение с любого интерфейса.
tcpConnLocalPort		Локальный номер порта.
tcpConnRemAddress	IpAddress	Удаленный IP адрес.
tcpConnRemPort		Удаленный номер порта.

Рисунок 25.28 Таблица TCP соединений: tcpConnTable.

Давайте посмотрим эту таблицу на системе sun. Мы показали только часть таблицы, так как очень много серверов (в данном случае слушающие процессы) слушает запросы на соединения. Перед тем как получить таблицу, было установлено два TCP соединения:

Face="Courier New" size=1>

sun % rlogin gemini face=Arial size=2>IP адрес face="Courier New" size=2>gemini равен 140.252.1.11

Face="Courier New" size=1>

sun % telnet localhost IP адрес должен быть 127.0.0.1

Единственный слушающий сервер, как мы показали, это FTP сервер на порте 21:

Face="Courier New" size=1>

sun % snmpi -a sun dump tcpConnTable

TcpConnState.0.0.0.0.21.0.0.0.0.0=listen(2)
tcpConnState.127.0.0.1.23.127.0.0.1.1415=established(5)
tcpConnState.127.0.0.1.1415.127.0.0.1.23=established(5)
tcpConnState.140.252.1.29.1023.140.252.1.11.513=established(5)

tcpConnLocalAddress.0.0.0.0.21.0.0.0.0.0=0.0.0.0
tcpConnLocalAddress.127.0.0.1.23.127.0.0.1.1415=127.0.0.1
tcpConnLocalAddress.127.0.0.1.1415.127.0.0.1.23=127.0.0.1
tcpConnLocalAddress.140.252.1.29.1023.140.252.1.11.513=140.252.1.29

tcpConnLocalPort.0.0.0.0.21.0.0.0.0.0=21
tcpConnLocalPort.127.0.0.1.23.127.0.0.1.1415=23
tcpConnLocalPort.127.0.0.1.1415.127.0.0.1.23=1415
tcpConnLocalPort.140.252.1.29.1023.140.252.1.11.513=1023

tcpConnRemAddress.0.0.0.0.21.0.0.0.0.0=0.0.0.0
tcpConnRemAddress.127.0.0.1.23.127.0.0.1.1415=127.0.0.1
tcpConnRemAddress.127.0.0.1.1415.127.0.0.1.23=127.0.0.1
tcpConnRemAddress.140.252.1.29.1023.140.252.1.11.513=140.252.1.11

tcpConnRemPort.0.0.0.0.21.0.0.0.0.0=0
tcpConnRemPort.127.0.0.1.23.127.0.0.1.1415=1415
tcpConnRemPort.127.0.0.1.1415.127.0.0.1.23=23
tcpConnRemPort.140.252.1.29.1023.140.252.1.11.513=513

Для команды rlogin на хост gemini присутствует только один пункт, так как gemini это удаленный хост. Мы видим только клиентскую часть соединения (локальный порт 1023), однако показаны оба конца Telnet соединения (порт клиента 1415 и порт сервера 23), так как соединение проходит через loopback интерфейс. Также мы можем видеть, что слушающий FTP сервер имеет локальный IP адрес 0.0.0.0, что указывает на то, что он примет соединение с любого интерфейса.

Дополнительные примеры

Сейчас мы вернемся к некоторым проблемам, которые были рассмотрены раньше в этой книге, и попробуем использовать SNMP, для того чтобы понять, что все-таки произошло.

MTU интерфейса

Вернемся к нашему эксперименту, описанному в разделе главы 11, в котором мы пытались определить MTU SLIP канала от netb к sun. Сейчас мы можем использовать SNMP, чтобы получить этот MTU. Во-первых, мы получим номер интерфейса (ipRouteIfIndex) для SLIP канала (140.252.1.29) из таблицы IP маршрутизации. Для этого, мы попадаем в таблицу интерфейсов и получаем MTU (вместе с описанием и типом) канала SLIP:

Face="Courier New" size=1>

sun % snmpi -a netb -c secret

Snmpi> get ipRouteIfIndex.140.252.1.29
ipRouteIfIndex.140.252.1.29=12
snmpi> get ifDescr.12 ifType.12 ifMtu.12
ifDescr.12="Telebit NetBlazer dynamic dial virtual interface"
ifType.12=other(1)
ifMtu.12=1500

Мы видим, что даже для канала, который является SLIP, MTU установлено в Ethernet значение равное 1500, возможно для того, чтобы избежать фрагментации.

Таблицы маршрутизации

Давайте обратимся к нашему обсуждению сортировки адресов, которая осуществляется DNS, приведенному в разделе главы 14. Мы показали, как первый IP адрес, возвращенный DNS сервером, был одним из тех, что принадлежат к той же подсети, что и клиент. Также мы упомянули, что использование другого IP адреса, вполне возможно, будет работать, однако в этом случае все будет менее эффективно. Давайте посмотрим, что произойдет при использовании альтернативного IP адреса. Мы будем использовать SNMP, чтобы посмотреть пункты в таблице маршрутизации, и попробуем объединить вместе несколько концепций, о которых мы рассказывали в предыдущих главах и которые имели отношение к IP маршрутизации.

Хост gemini имеет несколько интерфейсов, два из которых Ethernet интерфейсы. Во-первых, убедимся, что можем получить соединение Telnet на оба адреса:

Face="Courier New" size=1>

sun % telnet 140.252.1.11 daytime
Trying 140.252.1.11 ...
Connected to 140.252.1.11.
Escape character is "^]".
Sat Mar 27 09:37:24 1993
Connection closed by foreign host.

sun % telnet 140.252.3.54 daytime
Trying 140.252.3.54 ...
Connected to 140.252.3.54.
Escape character is "^]".
Sat Mar 27 09:37:35 1993
Connection closed by foreign host.

Мы видим, что нет никакой разницы в соединениях между двумя адресами. Сейчас воспользуемся traceroute, чтобы посмотреть, используются ли различные маршруты к каждому адресу:

sun % traceroute 140.252.1.11
traceroute to 140.252.1.11 (140.252.1.11), 30 hops max, 40 byte packets
1 netb (140.252.1.183) 299 ms 234 ms 233 ms
2 gemini (140.252.1.11) 233 ms 228 ms 234 ms

sun % traceroute 140.252.3.54
traceroute to 140.252.3.54 (140.252.3.54), 30 hops max, 40 byte packets
1 netb (140.252.1.183) 245 ms 212 ms 234 ms
2 swnrt (140.252.1.6) 233 ms 229 ms 234 ms
3 gemini (140.252.3.54) 234 ms 233 ms 234 ms

Мы видим, что при использовании адреса подсети 140.252.3 появляется дополнительная пересылка (маршрутизатор swnrt - это R3 на ). Давайте посмотрим, почему осуществляется эта дополнительная пересылка.

На рисунке 25.29 показаны настройки систем. На основе вывода команды traceroute мы можем сказать, что хост gemini и маршрутизатор swnrt оба подсоединены к двум сетям: 140.252.1 и 140.252.3.

Рисунок 25.29 Топология систем, которые используются в примере.

sun % traceroute -g 140.252.3.54 sun
traceroute to sun (140.252.13.33), 30 hops max, 40 byte packets
1 netb (140.252.1.183) 244 ms 256 ms 234 ms
2 * * *
3 gemini (140.252.3.54) 285 ms 227 ms 234 ms
4 netb (140.252.1.183) 263 ms 259 ms 294 ms
5 sun (140.252.13.33) 534 ms 498 ms 504 ms

Когда используется свободная маршрутизация от источника, маршрутизатор swnrt никогда не отвечает. Если посмотреть на ранний вывод команды traceroute, без маршрутизации от источника, мы увидим, что swnrt является второй пересылкой. Причиной этого может являться то, что маршрутизатор не генерирует ICMP ошибки об истечении времени, когда в датаграмме установлена свободная маршрутизация от источника. Мы видим из этого вывода команды traceroute, что путь возврата от gemini (TTL 3, 4 и 5) проходит непосредственно к netb, а не проходит через маршрутизатор swnrt.

Вопрос, на который нам должен помочь ответить SNMP, заключается в том, что делает пункт таблицы маршрутизации в netb таким, что сеть назначения установлена в 140.252.3? Все дело в том, что netb отправляет пакеты к swnrt, а не непосредственно к gemini. Мы используем команду get, чтобы получить значение маршрутизатора следующей пересылки для этого пункта назначения:

Face="Courier New" size=1>

sun % snmpi -a netb -c secret get ipRouteNextHop.140.252.3.0

IpRouteNextHop.140.252.3.0=140.252.1.6

Пункт таблицы маршрутизации говорит netb послать пакеты на swnrt, что, как мы видим, и происходит.

Почему gemini отправляет пакеты назад непосредственно через netb? Потому что адрес назначения для пакетов, возвращающихся от gemini, установлен в 140.252.1.29, а сеть 140.252.1 подключена непосредственно.

То, что мы видим в этом примере, является результатом политических решений о маршрутизации. Маршрут по умолчанию к сети 140.252.3 проходит через маршрутизатор swnrt, потому что gemini является просто хостом с несколькими интерфейсами, но не выполняет функции маршрутизатора. Это как раз пример хоста с несколькими интерфейсами, который не хочет быть маршрутизатором.

Ловушки (Traps)

Все примеры, которые мы рассмотрели в этой главе, иллюстрируют передачу информации от менеджера к агенту. Однако у агента существует способ сообщить менеджеру о возникновении какого-либо события, о котором менеджер должен знать (см. рисунок 25.1). В этом случае агент посылает менеджеру ловушки (trap). Ловушки отправляются на UDP порт 162 менеджера.

На рисунке 25.2 мы показали формат ловушки PDU. Мы просмотрим все поля в этом сообщении, когда ниже будем рассматривать вывод команды tcpdump.

Определены шесть ловушек, седьмая используется производителем, чтобы установить собственную ловушку. На рисунке 25.30 описываются значения типа ловушки (trap type) в сообщении ловушки (рисунок 25.2).

тип ловушки		Описание
0	coldStart	Агент инициализировал себя сам.
1	warmStart	Агент повторно инициализировал себя сам.
2	linkDown	Состояние интерфейса изменилось с "активизировано" на "выключено" (рисунок 25.18). Первая переменная в сообщении указывает на интерфейс.
3	linkUp	Состояние интерфейса изменилось с состояния "выключено" на состояние "активизировано" (рисунок 25.18). Первая переменная в сообщении указывает на интерфейс.
4	authenticationFailure	Сообщение было получено от SNMP менеджера из неверного сообщества.
5	egpNeighborLoss	EGP узел изменил свое состояние на "выключено". Первая переменная в сообщении содержит IP адрес узла.
6	enterpriseSpecific	Обратитесь к полю специализированных кодов за информацией об этой ловушке.

Рисунок 25.30 Типы ловушек.

Мы можем увидеть некоторые ловушки с помощью tcpdump. Стартуем SNMP агента на системе sun и посмотрим, как он генерирует ловушку coldStart. (Агент знает о необходимости посылать ловушки на хост bsdi. Однако на bsdi не стартован менеджер для обработки ловушек, вместо него запущен tcpdump, что позволяет увидеть генерируемые пакеты. Обратитесь к рисунку 25.1, откуда видно, что ловушки посылаются от агента к менеджеру, однако менеджер не посылает подтверждений, поэтому нет необходимости, чтобы менеджер обрабатывал ловушки.) Затем, с использованием программы snmpi, мы посылаем запрос, в котором указано неверное имя сообщества. В ответ на это должна быть сгенерирована ловушка authenticationFailure. На рисунке 25.31 показан вывод.

1 0.0 sun.snmp > bsdi.snmp-trap: C=traps Trap(28)
E:unix.1.2.5 coldStart 20

2 18.86 (18.86) sun.snmp > bsdi.snmp-trap: C=traps Trap(29)
E:unix.1.2.5 authenticationFailure 1907

Рисунок 25.31 Вывод команды tcpdump, соответствующий генерации ловушек SNMP агентом.

Во-первых, необходимо обратить внимание на то, что обе UDP датаграммы, отправленные от SNMP агента (порт 161, печатается как имя snmp), имеют порт назначения 162 (печатается как имя snmp-trap).

Выражение C=traps это имя сообщества в сообщении ловушки. Это опция конфигурации, которая используется агентом в случае ISODE SNMP.

Следующее выражение, Trap(28) в строке 1 и Trap(29) в строке 2, это тип PDU (PDU type) и длина.

Следующее поле вывода для обеих строк - E:unix.1.2.5. Это enterprise: идентификатор системы объекта (sysObjectID). Он находится под узлом 1.3.6.1.4.1 в дереве, приведенном на рисунке 25.6 (iso.org.dod.internet.private.enterprises), таким образом, идентификатор объекта агента равен 1.3.6.1.4.1.4.1.2.5. Его сокращенное имя unix.agents.fourBSD-isode.5. Последняя цифра (5) это номер версии релиза агента ISODE. Это значение указывает на то, какое программное обеспечение агента сгенерировало ловушку.

Следующее поле вывода команды tcpdump это IP адрес агента (140.252.13.33).

Тип ловушки печатается как coldStart в строке 1 и как authenticationFailure в строке 2. Они соответствуют значениям типа ловушки равным 0 и 4 соответственно (рисунок 25.30). Так как эти ловушки не являются специализированными (enterprise), специфичный код (specific code) должен быть равен 0 и поэтому не печатается.

Далее следует поле временной марки (timestamp), которое печатается как 20 и 1907. Это значение TimeTicks, соответствующее количеству сотых долей секунд с момента инициализации агента. В случае ловушки холодного старта, она генерируется через 200 миллисекунд после того, как агент инициализирован. Вывод tcpdump указывает на то, что вторая ловушка появилась через 18,86 секунды после первой, чему соответствует напечатанное значение 1907 сотых долей секунд минус 200 миллисекунд.

Из рисунка 25.2 видно, что сообщение ловушки может содержать переменные, которые агенты хотят отправить менеджеру, однако в наших примерах они не присутствуют.

Формальная спецификация SNMP использует абстрактную форму записи ( ASN.1 - Abstract Syntax Notation 1), и кодирование бит в SNMP сообщениях (рисунок 25.2) на основе основных правил кодирования ( BER - Basic Encoding Rules). В отличие от большинства публикаций, описывающих SNMP, мы специально оставили обсуждение ASN.1 и BER на самый конец. Если рассказать о них в самом начале, читатель может неправильно понять реальное назначение SNMP - управление сетью. В этом разделе мы дадим только краткий обзор этих двух тем. Глава 8 [ Rose 1990] описывает ASN.1 и BER более подробно.

ASN.1 это формальный язык, который описывает данные и характеристики данных. Он не определяет то, как эти данные хранятся или кодируются. Все поля в MIB и SNMP сообщениях описываются с использованием ASN.1. Например, ASN.1 определение типа данных IpAddress из SMI выглядит следующим образом:

IpAddress::=
-- in network-byte order
IMPLICIT OCTET STRING (SIZE(4))

Точно так же, в MIB мы находим следующее определение простых переменных:

udpNoPorts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The total number of received UDP datagrams for which there
was no application at the destination port."
::= { udp 2 }

Определение таблиц, использующих SEQUENCE и SEQUENCE OF, более сложное.

С использованием подобных ASN.1 определений существует множество способов закодировать данные в поток битов при передаче. SNMP использует BER. Для представления маленьких целых чисел, таких как 64, с использованием BER требуется 3 байта. Один байт содержит значение целого, следующий байт говорит, сколько байтов используется, чтобы хранить целое (1), и последний байт содержит двоичное значение.

К счастью, подробности ASN.1 и BER важны только для разработчиков SNMP. Они не обязательны для понимания того, как осуществляется управление сетью.

SNMP версии 2 (SNMP Version 2)

В течение 1993 года было опубликовано 11 RFC, которые определяли новые стандарты SNMP. Первый из них, RFC 1441 [ Case et al. 1993], является введением в SNMP версии 2 (SNMPv2). Две книги также описывают SNMPv2 . В настоящее время существуют две доступные реализации (см. приложение В.3 публикации [ Rose 1994]), однако коммерческие реализации, возможно, не будут широко доступны до 1994 года.

В этом разделе мы опишем основные отличия SNMPv1 от SNMPv2.

Новый тип пакетов get-bulk-request позволяет менеджеру эффективно обрабатывать большие блоки данных. Еще один новый тип пакетов inform-request позволяет одному менеджеру посылать информацию другому менеджеру. Определены два новых MIB: MIB SNMPv2 и MIB SNMPv2-M2M (менеджер-менеджер). SNMPv2 предоставляет улучшенную секретность по сравнению с SNMPv1. В SNMPv1 имя сообщества передается от менеджера к агенту в виде открытого пароля. SNMPv2 предоставляет аутентификацию и расширенную секретность.

Все производители начинают реализовывать агентов, совместимых с SNMPv2, а также появляются управляющие станции, которые могут использовать оба стандарта. [ Routhier 1993] описывает расширения и улучшения SNMPv1, которые призваны обеспечить совместимость и поддержку SNMPv2.

Краткие выводы

SNMP это простой протокол, основанный на запросах и откликах, предназначенный для обмена между SNMP менеджером и SNMP агентом. Информационная база данных управления (MIB) определяет переменные, которые обслуживаются агентом, которые, в свою очередь, менеджер может либо запросить, либо установить. Для определения переменных используется ограниченное количество типов данных.

Все переменные идентифицируются идентификаторами объекта, используется иерархическая схема присвоения имен, которая состоит из длинных строк чисел, которые обычно сокращаются в простые имена, для простоты чтения. Конкретные переменные строятся с помощью добавления переменной к идентификатору объекта.

Большинство SNMP переменных содержится в таблицах, с фиксированными номерами колонок, однако с переменными номерами строк. Фундаментальным для SNMP является схема идентификации, используемая для того, чтобы идентифицировать каждую строку в таблице (в том случае, когда мы не знаем, сколько строк содержится в таблице), и лексикографический порядок (порядок колонка-строка). SNMP оператор get-next является основным для любого SNMP менеджера.

Мы описали следующие группы SNMP переменных: система, интерфейс, трансляция адресов, IP, ICMP, TCP и UDP. Затем показали два примера, один из которых позволил определить MTU интерфейса, а другой - просмотреть таблицу маршрутизации маршрутизатора.

Мы завершили главу рассмотрением SNMP ловушек. Это способ, предоставляющий агенту возможность уведомить менеджера о том, что произошло какое-либо событие, которое будет интересно менеджеру. Здесь же кратко описаны ASN.1 и BER. Две последние темы, скорее всего, являются наиболее сложными аспектами SNMP, однако они необходимы только для разработчиков.

Упражнения

Мы сказали, что использование двух различных портов (161 и 162) позволяет системе запускать как менеджера, так и агента. Что произойдет, если будет использоваться один и тот же порт?
Как Вы можете получить полный список таблицы маршрутизации с использованием get-next?

1. Введение

Деятельность современных организаций тесно связана с использованием информационных технологий, будь то компьютер на рабочем месте менеджера мелкой фирмы или корпоративная сеть крупной компании - системного интегратора. И чем больше организация и чем важнее ее функции, тем выше требования к компьютерным системам, обеспечивающим выполнение этих функций, и тем дороже цена каждого сбоя в работе. Эффективность деятельности компании становится все более и более зависимой от качества работы ее компьютерного и телекоммуникационного оборудования.

Особенно остро встает вопрос о надежности и максимальной эффективности функционирования вычислительных сетей. Огромные убытки от сетевых неполадок, приводящих к потере данных, резкому падению производительности, блокировке серверов и другим неприятностям, несут банки, финансовые, транспортные и телекоммуникационные компании. Следовательно, особую актуальность приобретает проблема управления сетью.

Управление сетью - это комплекс мер и мероприятий, направленный на повышение эффективности функционирования сети, обнаружение и устранение сбоев в ее работе, правильное ее развитие и модернизацию, и сокращение затрат в конечном итоге. Принято разделять функции управления сетью на две группы:

Управление элементами сети:

управление конфигурацией:
- регистрация устройств сети, их сетевых адресов и идентификаторов;
- определение параметров сетевой операционной системы и описание конфигурации элементов сети, а также протоколов сетевых взаимодействий;
- графическое отображение схемы сети.
управление безопасностью:
- контроль доступа и управление полномочиями пользователей;
- контроль и управление параметрами межсетевого взаимодействия;
- защита от несанкционированного доступа извне;
- управление целостностью данных (архивированием и энергопитанием).
управление ресурсами:
- регистрация лицензий и учет использования программных средств и сетевых ресурсов;
- управление приоритетами пользователей и прикладных задач.

Управление коммуникациями:

обработка сбоев:
- поиск, обнаружение, локализация и устранение неисправностей и ошибок;
- предупреждение и профилактика сбоев;
- наблюдение за кабельной системой;
- мониторинг удаленных сегментов и межсетевых связей.
управление производительностью:
- сбор и анализ статистических данных о функционировании сети, анализ трафика;
- планирование и оценка эффективности использования ресурсов сети;
- анализ и интерпретация протоколов;
- планирование развития сети, управление сегментацией.

В настоящее время для управления сетями используются приложения, работающие на базе платформ сетевого управления, таких как системы HP OpenView фирмы Hewlett-Packard, NetView for AIX (IBM), SunNet Manager (Sun), Spectrum (Cabletron Systems), NetWare Management Systems (Novell) и другие разнообразные кросс-платформные средства управления.

В основе этих средств лежит использование протокола SNMP (Simple Network Management Protocol). Протокол SNMP предназначен для сбора и передачи служебной информации (status information) между различными компьютерами.

2. Определение SNMP

SNMP - это протокол из семейства TCP/IP (Протокол SNMP описан в RFC 1157). Первоначально он был разработан Сообществом Интернета (Internet community) для наблюдения и устранения неполадок в маршрутизаторах и мостах (bridges). SNMP позволяет наблюдать и передавать информацию о состоянии:

компьютеров, работающих под управлением Windows NT;
серверов LAN Manager;
маршрутизаторов и шлюзов;
мини-компьютеров или мэйнфреймов;
терминальных серверов;
концентраторов.

SNMP использует распределенную архитектуру, состоящую из систем управления (management systems) и агентов (agents). С помощью сервиса Microsoft SNMP компьютер, работающий под управлением Windows NT, может выдавать отчет о своем состоянии системе управления SNMP в сети, использующей протокол TCP/IP.

2.1. Системы управления и агенты

SNMP позволяет наблюдать за различными компьютерами с помощью систем управления и агентов, как показано на рис. 1 .

Система управления SNMP

Основная функция системы управления - запрос информации от агентов. Система управления (management system) - это любой компьютер, на котором работает программное обеспечение управления SNMP. Система управления может выполнять операции get, get-next и set.

Операция get запрашивает какой-либо параметр, например количество доступного пространства на жестком диске.
Операция get-next запрашивает следующую величину, используется для просмотра таблицы объектов.
Операция set изменяет значение, используется редко, потому что большинство параметров доступны только для чтения и не могут быть изменены.

Агент SNMP

Основная функция агента SNMP заключается в выполнении операций set, инициированных системой управления. Агент - это любой компьютер, на котором работает соответствующее программное обеспечение SNMP, как правило, сервер или маршрутизатор. Сервис Microsoft SNMP - это программное обеспечение агента SNMP.

Единственная операция, которая может быть инициирована агентом, - trap. Эта операция сигнализирует системам управления о необычном событии, например о нарушении пароля.

2.2. Сервис Microsoft SNMP

Сервис Microsoft SNMP обеспечивает сервисы агента SNMP любому компьютеру, на котором работает программа управления SNMP (рис. 2 ). Сервис SNMP:

обрабатывает запросы служебной информации от различных компьютеров;
сообщает о важных событиях [ловушках (traps)] нескольким компьютерам, как только они происходят;
использует имена узлов и их IP-адреса для идентификации компьютеров, которым посылает информацию и с которых получает запросы;
может быть установлен и использован на любом компьютере, работающем под управлением Windows NT с протоколом TCP/IP;
позволяет применять счетчики для наблюдения за TCP/IP, используя Performance Monitor.

Архитектурная модель SNMP

Сервис Microsoft SNMP написан с использованием интерфейса Windows Sockets. Это позволяет обращаться к нему из сетевых систем управления, созданных средствами этого интерфейса. Сервис SNMP посылает и принимает сообщения по протоколу UDP (порт 161) и использует IP для поддержки маршрутизации SNMP-сообщений. SNMP позволяет применять дополнительные динамически подключаемые библиотеки агентов для поддержки других баз MIB. Сторонние производители могут разрабатывать собственные базы MIB для использования совместно с сервисом Microsoft SNMP. Microsoft SNMP включает модуль Microsoft Win32 (API SNMP администратора для упрощения разработки SNMP-приложений).

Таким образом, SNMP позволяет наблюдать за компьютерами, работающими под управлением Windows NT, и сигнализировать системам управления о происходящих событиях. Сервис Microsoft SNMP обеспечивает сервисы агентов, дополнительные библиотеки DLL и Win32 SNMP API администратора для упрощения разработки SNMP-приложений.

3. MIB

Информация, которую система управления запрашивает от агентов, хранится в специальной информационной базе данных MIB (Management Information Base).

MIB - это набор контролируемых объектов, предоставляющих информацию об устройствах сети, например о количестве активных сеансов или версиях сетевой операционной системы, работающей на компьютере. Главное то, что и агент SNMP, и база данных MIB одинаково интерпретируют контролируемые объекты. Таким образом, система управления с помощью базы данных MIB «знает», какую информацию можно запросить у агента и что характеризует тот или иной объект.

Сервис SNMP поддерживает Internet MIB II, LAN Manager MIB II, DHCP MIB и WINS MIB.

Internet MIB II

Internet MIB II - это расширение предыдущего стандарта Internet MIB I. Оно определяет 171 объект, необходимый для поиска неисправностей и анализа конфигурации (База данных Internet MIB II описана в RFC 1212).

LAN Manager MIB II

LAN Manager MIB II определяет приблизительно 90 объектов, которые включают такие элементы, как статистическая, сеансовая, пользовательская, регистрационная информация, и данные о совместно используемых ресурсах. К большинству объектов LAN Manager MIB II установлен доступ только для чтения, в связи с отсутствием обеспечения безопасности в SNMP.

DHCP MIB

Операционная система Windows NT 4.0 поставляется с DHCP MIB. Эта база определяет объекты наблюдения за активностью DHCP-сервера. Модуль Dhcpmib.dll автоматически устанавливается при установке сервиса DHCP Server. Он наблюдает около 14 параметров DHCP, например число полученных запросов DHCPDISCOVER, количество отказов или адресов, взятых в аренду клиентами.

WINS MIB

Windows NT 4.0 поставляется с WINS MIB. Эта база определяет объекты для наблюдения за активностью WINS-сервера. Модуль Winsmib.dll автоматически устанавливается при установке сервиса WINS Server. Он наблюдает приблизительно 70 параметров WINS, например число запросов, на которые удалось успешно ответить, количество неуспешных запросов или дату и время последнего сеанса тиражирования базы данных.

Дерево имен

Пространство имен MIB-объектов имеет иерархическую структуру. На рис. 3 видно, что оно организовано так, что каждому контролируемому объекту может соответствовать уникальное имя. Полномочия на управление частями пространства имен присваиваются отдельным организациям. Поэтому организации, в свою очередь, вправе назначать имена, не консультируясь с комитетом по Интернету. Например, 1.3.6.1.4.1.77 является пространством имен, присвоенным LAN Manager. Поскольку 1.3.6.1.4.1.77 присвоено LAN Manager, корпорации Microsoft присвоено 1.3.6.1.4.1.311, и все новые базы MIB будут созданы на этой ветви. Microsoft вправе назначать имена объектам где угодно в рамках этого пространства имен.

Идентификатор объекта в иерархии записывается как последовательность меток, начинающихся в корне и заканчивающихся самим объектом. Метки разделены точками. Например, идентификатор объекта для MIB II приведен ниже.

Пространство имен, используемое для идентификаторов объектов, - уникально и отделено от иерархического пространства имен, присвоенного именам UNIX-доменов.

4.1. Определение сообществ SNMP

Перед установкой SNMP вам необходимо определить сообщество (SNMP community) - группу, к которой принадлежат компьютеры с сервисом SNMP. Имя сообщества (community name) идентифицирует сообщество. Оно обеспечивает простейшую безопасность и контекстную проверку для агентов, получающих запросы и инициирующих прерывания (traps), и для систем управления, инициирующих запросы и обрабатывающих прерывания. Агент не примет запрос от системы управления, сконфигурированной за пределами его сообщества.

SNMP-агент может быть членом нескольких сообществ одновременно, что позволит ему связываться с администраторами SNMP различных сообществ. Например, на рис. 4 определены два сообщества - Public и Public2. Только агенты и администраторы - члены одного сообщества - могут связываться друг с другом.

Agent1 может получать и посылать сообщения Manager2, потому что оба они являются членами сообщества Public2.
Agent2, Agent3 и Agent4 могут получать и посылать сообщения Manager1, потому что все они являются членами сообщества Public, принятого по умолчанию.

4.2. Сбор информации

Приведенные ниже инструкция и рис. 5 показывают, как сервис SNMP реагирует на запросы системы управления.

Система управления SNMP посылает запрос агенту, используя имя узла агента (или его IP-адрес).

Запрос отправляется приложением на UDP-порт 161.

Имя узла преобразуется в IP-адрес любым из доступных методов разрешения, включая файл HOSTS, DNS, WINS, широковещание или файл LMHOSTS.

Формируется SNMP-пакет, содержащий следующую информацию:
- операцию get, get-next или set для одного или нескольких объектов;
- имя сообщества и другую проверочную информацию.

Пакет передается по сети агенту на UDP-порт 161.

SNMP-агент получает пакет в свой буфер.

Проверяется имя сообщества. Если оно неправильное или пакет некорректный, он отвергается.

Если имя сообщества правильное, агент проверяет имя узла или IP-адрес отправителя. Агент должен быть уполномочен принимать пакеты от системы управления. В противном случае пакет отвергается.

Запрос передается соответствующей DLL.

Если запрос для	Происходит следующее
объекта Internet MIB II	TCP DLL отыскивает информацию
объекта LAN Manager MIB II	LAN Manager DLL отыскивает информацию
объекта DHCP	DHCP MIB DLL отыскивает информацию
объекта WINS	WINS MIB DLL отыскивает информацию
расширенного агента MIB	DLL для этой MIB отыскивает информацию

Идентификатор объекта отображается в соответствующую функцию API, которая и вызывается далее. Библиотека DLL возвращает информацию агенту.

SNMP-пакет с требуемой информацией отправляется назад администратору SNMP.

4.3. Установка сервиса SNMP

В Control Panel Network (рис. 6 , рис. 7).
Выберите вкладку Services и нажмите Add (рис. 8).

Select Network Service.

Щелкните SNMP Service и нажмите ОК (рис. 9).
Введите на запрос путь к установочным файлам Windows NT (рис. 10) .
После того как нужные файлы скопируются на компьютер, появится диалоговое окно Microsoft SNMP Properties (рис. 11).
Во вкладке Traps выберите имя сообщества Public (рис. 12) .
Нажмите ОК. Появится диалоговое окно Network.
Нажмите Close. Появится окно Network Settings Change с предупреждением о необходимости перезагрузить компьютер (рис. 13) .
Нажмите Yes.
Войдите в систему под именем Administrator.

4.4. Настройка безопасности

Сервис SNMP обеспечивает элементарную безопасность и контекстную проверку агентов, получающих запросы и инициирующих ловушки, и систем управления, инициирующих запросы и получающих ловушки. Агент не примет запрос от системы управления, не принадлежащей ни к одному из указанных в списке допустимых сообществ. Windows NT посылает системное прерывание аутентификации, принятое по умолчанию.

Конфигурирование безопасности SNMP

В Control Panel дважды щелкните мышью пиктограмму Network (рис. 6 , рис. 7).
Выберите вкладку Services, нажмите SNMP Services и затем Properties. Появится диалоговое окно Microsoft SNMP Properties (рис. 11).
Выберите вкладку Security (рис. 14).
Сконфигурируйте параметры, показанные в таблице.

Параметр	Описание
Send Authentication Trap	Когда SNMP-сервис получает запрос на информацию, не содержащий корректного имени сообщества или не совпадающий с подходящим именем узла для сервиса, сервис SNMP может отправить в ответ системное прерывание, указывающее, что запрос не аутентифицирован. Отметьте этот флажок, чтобы задать системное прерывание аутентификации
Accepted Community Names	Компьютер должен принадлежать сообществу, указанному в этом списке, чтобы сервис SNMP смог принимать запросы от него. Как правило, все компьютеры принадлежат сообществу Public, являющемуся стандартным именем для сообщества всех компьютеров
Accept SNMP Packets from Any Host	Если указана эта опция, пакеты SNMP не отвергаются на основе идентификаторов узлов-отправителей и указанного под опцией списка допустимых узлов
Only Accept SNMP Packets from These Hosts	Если выбрана эта опция, пакеты SNMP принимаются только с указанных в списке компьютеров

4.5. Настройка сервисов SNMP-агента

Сервис SNMP позволяет компьютеру, работающему под управлением Windows NT, информировать систему управления о деятельности на различных уровнях семейства протоколов Интернета.

Конфигурирование сервисов SNMP-агента

В диалоговом окне Microsoft SNMP Properties выберите вкладку Agent (рис. 15).
В поле Contact введите контактное имя. Обычно это имя человека, использующего компьютер.
В поле Location введите описание места, где установлен компьютер.
В поле Service выберите сервисы, которые будут обеспечиваться агентом.

Каждый сервис информирует о транзакции на разном уровне. Сервисы, выбранные по умолчанию: Applications, End-to-End и Internet.

	Выберите эту опцию, если
	компьютер, работающий под Windows NT, управляет какими-либо физическими устройствами, например повторителями (repeaters)
Datalink/ Subnetwork	компьютер, работающий под Windows NT, управляет мостом
	компьютер, работающий под управлением Windows NT, действует как IP-шлюз (маршрутизатор)
	компьютер, работающий под управлением Windows NT, действует как IP-узел. Эта опция должна быть указана всегда
	компьютер, работающий под управлением Windows NT, использует любое TCP/IP-приложение. Эта опция должна быть указана всегда

Нажмите ОК.
Нажмите Close.

4.6. Обнаружение ошибок

Если сервис SNMP дал сбой по какой-либо причине, это будет отмечено в системном журнале в Event Viewer. Именно туда следует заглянуть в первую очередь при возникновении проблемы, связанной с сервисом SNMP.

Просмотр новых объектов в Performance Monitor

Щелкните кнопку Start, укажите на Programs, затем на - Administrative Tools и выберите Performance Monitor (рис. 19). Появится окно Performance Monitor (рис. 20).
В меню Edit выберите Add to Chart. Появится диалоговое окно Add to Chart (рис. 21).
3. В поле Object нажмите стрелку, чтобы вывести список объектов.

Наблюдение за датаграммами IP с помощью Performance Monitor

В поле Object выберите из списка ICMP. Появится список счетчиков ICMP.
В поле Counters выберите Message/sec.
В поле Scale установите 1.0 и нажмите Add.
В поле Object выберите IP.
В поле Counters выберите из списка Datagrams Sent/sec.
В поле Scale установите 7.0 и нажмите Add.
Нажмите Done. Ваш выбор появится в области отображения.
В меню Options
4.8. Применение утилиты SNMPUTIL

В составе Microsoft Windows NT Resource Kit поставляется утилита Snmputil, которая проверяет корректность установки сервиса SNMP для связи с управляющими станциями SNMP. Snmputil выполняет те же самые вызовы, что и управляющая станция SNMP.

Вот ее синтаксис:
Snmputil команда агент сообщество идентификатор_объекта_(OID)
Возможные команды:
- get - позволяет получить значение запрашиваемого идентификатора объекта;
- getnext - позволяет получить значение объекта, следующего за заданным идентификатором;
- walk - позволяет переходить по ветви MIВ, заданной идентификатором объекта.
Например, чтобы определить число предоставленных в аренду адресов сервером DHCP с именем DHCPserver в сообществе Public, вам понадобится ввести команду:

snmputil getnext DHCPserver Public.1.3.6.1.4.1.311.1.3.2.1.1.1

Эта команда выдаст идентификатор объекта (OID) и значение счетчика для указанного в запросе идентификатора объекта, в приведенном случае - число взятых в аренду IP-адресов.

Следовательно, просмотрев описания объектов MIB, можно получить доступ к объектам SNMP для просмотра данных, собранных агентом SNMP и программой управления.

Например, команда
snmputil getnext <IP-адрес > public.1.3.6.1.4.1.311.1.3.2.1.1.1
позволяет определить относящиеся к DHCP объекты SNMP (<IP-адрес > необходимо заменить нужным значением, например 192.168.40.91).

Аналогично, применяя утилиту Snmputil.ехе к объекту WINS 1.3.6.1.4.1.311.1.2.1.17 и объекту WINS 1.3.6.1.4.1.311.1.2.1.18, можно определить, сколько успешно разрешенных запросов было обработано WINS-сервером
snmputil getnext <IP-адрес > public.1.3.6.1.4.1.311.1.2.1.17
и сколько неуспешных запросов было выполнено сервером WINS
snmputil getnext <IP-адрес > public.1.3.6.1.4.1.311.1.2.1.18
А применение утилиты Snmputil.exe к объекту LAN Manager 1.3.6.1.4.1.77.1.1.1 и объекту LAN Manager 1.3.6.1.4.1.77.1.1.2
snmputil getnext 131.107.2.host_id public.1.3.6.1.4.1.77.1.1.1 snmputil getnext 131.107.2.host_id public.1.3.6.1.4.1.77.1.1.2
возвращает номер версии Windows NT Server, работающей на компьютере.

5. Заключение

Таким образом, протокол SNMP из семейства TCP/IP позволяет наблюдать и передавать информацию о состоянии компьютеров, работающих под управлением Windows NT, серверов LAN Manager, маршрутизаторов и шлюзов, мини-компьютеров или мэйнфреймов, терминальных серверов, концентраторов. SNMP использует распределенную архитектуру, состоящую из систем управления и агентов .

Перед установкой SNMP вам необходимо определить сообщество - группу, к которой принадлежит SNMP-компьютер. SNMP обеспечивает минимальный уровень безопасности и контекстную проверку для агентов. Вы можете использовать Event Viewer для обнаружения сбоев сервиса SNMP.

С помощью сервиса Microsoft SNMP-компьютер, работающий под управлением Windows NT, может выдавать отчет о своем состоянии системе управления SNMP в сети, использующей протокол TCP/IP.

Сервис SNMP посылает информацию о состоянии одному или нескольким компьютерам по запросу или в случае, когда происходит важное событие, например компьютеру не хватает места на жестком диске.

Этот протокол поддерживается как Microsoft Systems Management Server, так и продуктами OpenView (Hewlett-Packard), UniCenter TNG (Computer Associates), Tivoli (IBM). Windows NT Server и Windows NT Workstation включают агентов SNMP, что позволяет управлять ими с помощью всех названных продуктов.

КомпьютерПресс 5"2000

Статьи по теме:

Как скопировать веб-страницу если там установлена защита от копирования

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

Как правильно выполнить сброс настроек

Cодержание: Зачем нужна эта функцияПричин воспользоваться данной функцией может быть множество. Нередко пользователи сталкиваются с проблемой ограничения памяти.SD-карта всегда имеет свой предел, а встроенная в телефон память, как правило, может вместить

Подключение и запуск Telnet

Обсуждение подопций Некоторые опции требуют большего количества информации, нежели просто "включить" (enable) или "выключить" (disable). Например, установка типа терминала: для того чтобы клиент мог идентифицировать тип терминала, он должен отправить AS

Что такое Проектор LED или светодиодный проектор?

DLP- и LCD-проекторы отличаются технологией создания изображения. В свет лампы с помощью призмы разбивается на лучи основных цветов: зеленый, синий и красный, а потом попадает на одну из трех маленьких жидкокристаллических матриц. ЖК-матрицы пропускают св

2024-05-16 10:16:18	Как установить MiFlash и драйверы для смартфонов Xiaomi Сложные способы решения
2024-05-12 10:16:33	TrueCrypt шифрование важных файлов
2024-05-12 10:16:33	Какую форму имеет канал гранде
2024-05-11 10:40:41	Как заблокировать доступ к вконтакте
2024-05-11 10:40:41	Установка Kaspersky Internet Security Параметры и свойства установки программы
2024-05-10 11:12:07	Что такое фаервол (firewall)
2024-05-08 11:08:27	Восстановление системы Windows
2024-05-08 11:08:27	Обновление драйверов через диспетчер устройств
2024-05-07 10:44:30	Как перезагрузить компьютер с помощью клавиатуры?
2024-05-06 10:39:45	Как устранить неполадки Windows встроенными средствами

2024-05-05 10:57:32	Какую лучше выбрать в актуальном модельном ряду
2024-05-02 10:39:53	Аморальный intitle datalife engine панель управления
2024-05-01 10:36:37	Не работает Qiwi — что можно сделать?
2024-04-28 10:48:36	Нтв плюс - установка, подключение, настройка спутниковых антенн
2024-04-27 11:13:14	Планшеты самсунг таб s 10
2024-04-26 11:12:06	Прошивка Meizu M5 Note M621Q
2024-05-19 10:09:20	Как скопировать веб-страницу если там установлена защита от копирования
2024-05-19 10:09:20	Как правильно выполнить сброс настроек
2024-05-18 10:49:59	Подключение и запуск Telnet
2024-05-17 11:41:58	Что такое Проектор LED или светодиодный проектор?
2024-05-16 10:16:18	Как установить MiFlash и драйверы для смартфонов Xiaomi Сложные способы решения
2024-05-12 10:16:33	TrueCrypt шифрование важных файлов

Как работает протокол snmp community. SNMP протокол (основы)

Базовые понятия

Менеджеры SNMP

Агенты SNMP

Кратко о MIB

Команды протокола SNMP

Версии протокола

МОДЕЛЬ SNMP

СТРУКТУРА УПРАВЛЯЮЩЕЙ ИНФОРМАЦИИ

БАЗА УПРАВЛЯЮЩЕЙ ИНФОРМАЦИИ

ПРОТОКОЛ SNMP

НИЖЕЛЕЖАЩИЕ ТРАНСПОРТНЫЕ ПРОТОКОЛЫ

ЗАЩИТА В SNMP

ЛОЖКА ДЕГТЯ?

2. Определение SNMP

2.1. Системы управления и агенты

Система управления SNMP

Агент SNMP

2.2. Сервис Microsoft SNMP

Архитектурная модель SNMP

3. MIB

Internet MIB II

LAN Manager MIB II

DHCP MIB

WINS MIB

Дерево имен

4.1. Определение сообществ SNMP

4.2. Сбор информации

4.3. Установка сервиса SNMP

4.4. Настройка безопасности

Конфигурирование безопасности SNMP

4.5. Настройка сервисов SNMP-агента

Конфигурирование сервисов SNMP-агента

4.6. Обнаружение ошибок

Просмотр новых объектов в Performance Monitor

Наблюдение за датаграммами IP с помощью Performance Monitor

4.8. Применение утилиты SNMPUTIL

5. Заключение