Конфигурирование протокола snmp

Для того, чтобы станции NMS могли обмениваться данными с сетевыми устрой­ствами, на этих устройствах должен быть установлен протокол SNMP и сконфигу­рированы строки сообщества. Ниже приведен обзор команд и их синтаксис для конфигурирования этих устройств.

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

Router(config) #snmp-server community string ro

где:

• параметр string является строкой сообщества, которая выполняет функции па­роля и представляет доступ к протоколу SNMP.

• параметр го (необязательный) указывает на статус доступа "только для чте­ния". Получить доступ к объектам баз MIB должны только авторизованные станции управления сетью.

Возможна поддержка нескольких строк со статусом "только для чтения". Все объекты протокола SNMP доступны для записи в них данных.

По умолчанию в большинстве систем строка сообщества является приватной. Ис­пользовать это значение в сети предприятия не рекомендуется. Для установки атрибута "для чтения/записи" для строки сообщества используется следующая команда:

Router(config)#snmp-server community string rw

Где:

• rw (необязательный параметр) указывает на возможность доступа для чте­ния/записи. Авторизованные станции управления могут извлекать значения объектов баз данных MIB и изменять их. Для задания расположения управ­ляемого устройства и главного системного контакта для него могут использо­ваться несколько строк.

Router (config) #snmp-server location text

Router (config) #snmp-server contact text

где:

параметр text представляет собой строку, содержащую информацию о системном расположении. Эти значения хранятся в объектах MIB sysLocation и sysContact.

Удаленный мониторинг (rmon)

Удаленный мониторинг RMON является крупным шагом вперед в развитии управления сетями. Он определяет базу данных удаленного мониторинга RMON MIB, которая дополняет базу MIB-II и предоставляет сетевому менеджеру жизненно важную информацию о сети. Примечательной функцией RMON является то, что хо­тя это лишь спецификация базы MIB, не вносящая изменений в лежащий в основе протокол SNMP, она представляет собой значительное расширение функций прото­кола SNMP. С помощью базы MIB-II сетевой менеджер может получить информа­цию, которая является чисто локальной и относится только к индивидуальным уст­ройств. Рассмотри локальную сеть LAN, в которой имеется несколько устройств и на каждом из них действует агент протокола SNMP.

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

Стандарт удаленного мониторинга RMON первоначально имел название IETF RFC 1271 (в настоящее время RFC 1757) и был предназначен для активного монито­ринга и диагностики в распределенных сетях на основе LAN-сетей. Устройства мо­ниторинга, называемые агентами или тестерами, позволяют создавать в критических сетевых сегментах определяемые пользователем аварийные сигнализаторы и соби­рать обширные и весьма важные статистические данные путем анализа каждого фрейма в сегменте.

Для поддержки топологий Ethernet стандарт RMON подразделяет функции монито­ринга на девять групп и добавляет десятую группу в RFC 1513 для уникальных парамет­ров сетей Token Ring. Стандарт RMON был предназначен для распределенной вычисли­тельной архитектуры, в которой агенты осуществляют обмен данными с центральной станцией управления (клиентом) при посредстве протокола SNMP. Эти агенты опреде­лили структуры баз MIB протокола SNMP для всех 9-10 групп (Ethernet или Token Ring) RMON, что позволило взаимодействовать производителям диагностических средств на основе RMON. Ниже описаны группы удаленного мониторинга RMON.

• Группа статистики — эта группа поддерживает статистику использования и оши­бок для подсети/сегмента, в которой осуществляется мониторинг (в качестве при­меров можно привести использование полосы пропускания, широковещание, многоадресатную рассылку и т.д.).

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

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

• Группа хостов (узлов) — задает измерение различных типов данных, посту­пающих на узлы, подключенные к сети, или отправляемых с них (в качестве примеров можно привести количество полученных/отправленных пакетов, полученных/отправленных байтов, количество ошибок, а также широковеща­тельных или многоадресатных пакетов).

• Группа из первых N узлов — эта группа предоставляет отчет по первым N узлам, составленный на основе статистики группы узлов.

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

• Группа фильтров — эта группа генерирует поток пакетов от фреймов, которые соответствуют заданному пользователем шаблону.

• Группа захвата пакетов — эта группа определяет способ помещения во внут­ренний буфер пакетов, соответствующих критерию фильтрации.

• Группа событий — задает запись в журнал для менеджера событий (соответст­вующих команде trap) вместе со временем и датой (Примером может служить генерирование отчетов на основе заданного типа аварийной ситуации).