СОДЕРЖАНИЕ
Введение 2
Описание протокола и его компонентов 3
Стандартные элементы протокола SNMP 4
Особенности версии 3 протокола SNMP 7
Заключение 15
Список литературы 16
ВВЕДЕНИЕ
Задача автоматизации управления различным сетевым оборудованием существует со времени появления первых сетевых устройств. На сегодняшний день практически в любой сети можно найти активное сетевое оборудование, управление которым можно, а как правило, нужно автоматизировать. Для решения подобных задач был разработан протокол SNMP (Simple Network Management Protocol). Существует масса готовых коммерческих решений по управлению различными устройствами с помощью SNMP, например HP Open View, однако не каждой организации по карману приобретение подобного ПО, к тому же эти программные продукты предназначены для управления большим количеством устройств, и их использование в небольших сетях будет нецелесообразным. ОПИСАНИЕ ПРОТОКОЛА И ЕГО КОМПОНЕНТОВ
SNMP использует UDP в качестве транспортного протокола порт 161 и предназначен для использования сетевыми управляющими станциями, как правило серверами, в качестве управляющих и активного сетевого оборудования в качестве управляемых систем. Протокол определяет формат данных, их обработка и интерпретация остаются на усмотрение управляющих станций.
SNMP-сообщения не имеют фиксированного формата и фиксированных полей. При работе протокол SNMP использует управляющую базу данных MIB – (Management Information Base), которая определяется стандартами RFC1213, 1212.
Общая архитектура взаимодействия по протоколу SNMP имеет следующий вид: на устройстве, которым необходимо управлять, запущен агент SNMP (см. рис. 1). Рисунок 1. Структура взаимодействия SNMP
Агенты имеют доступ к инфоpмации об упpавляемом устpойстве, на котоpом они запущены и делают ее доступной для систем сетевого упpавления NMS (Network Management Systems).
Упpавляемое устpойство может быть любого типа, лишь бы оно было подключено к сети, это могут быть как компьютеpы, так и сеpвеpа, пpинтеpы, маpшpутизатоpы, коммутаторы и даже DSL-модемы.
Для пpимеpа: устpойство может отслеживать следующие паpаметpы:
Количество и состояние своих виpтуальных соединений (Virtual circuits).
Количество пpинятых сообщений об ошибках опpеделенного pода (Number of certain kinds of error messages received).
Количество байт и пакетов, пpинятых и посланных этим устpойством.
Максимальное значение длины очеpеди (для маpшpутизатоpов и дpугих межсетевых устpойств).
Количество пpинятых и отправленных шиpоковещательных сообщений.
Состояние каждого из своих интеpфейсов.
СТАНДАРТНЫЕ ЭЛЕМЕНТЫ ПРОТОКОЛА SNMP
Стандартные элементы протокола SNMP включают в себя несколько команд:
GetHextRequest - запрос, используемый менеджером для получения значения следующего объекта (без указания имени) при последовательном просмотре таблицы объектов.
GetRequest - запрос, используемый менеджером для получения от агента значения какого-либо объекта по его имени.
GetRespons - ответ, используемый агентом для передачи сообщения на запросы (Get Request и Get Next Request).
Set-изменить, используется менеджером для какого-либо объекта.
Тгаре-особая ситуация, используется агентом для сообщения менеджеру.
Формат сообщений SNMP.
Сообщения в SNMP не имеют заголовка с фиксированными полями.
Сообщения SNMP состоят из произвольного количества полей, каждый из которых предворяется описанием и длиной.
Пакет SNMP состоит из трех основных полей Version - номер версии SNMP (1,2,3)
identification- используется для формирования устройств управления одним менеджером. Может служить для безопасности. SNMPPDU- блок данных определяет кол-во полей и кол-во тех. данных, которые войдут в формат протокола в дальнейшем. Типысообщений:
Get, Get Next, Set, Get Responce, Trape.
PDU- будет содержать имена переменных и их значения.
Фиксированный блок -зависит от переменных.
Variable (описание значения) • список переменных и их значения.
Формат значения Тгаре: Enterprise-идентифицирует тип объекта.
Agent addr-адрес агента.
GeneriseTrape - об шее описание проблемы (ошибка Alarm)
Specifix code Trape - код ошибки.
time -метка времени, указывает величину времени между последней инициализацией сети и генерацией данного сообщения Тгаре.
Variable- описание значения.
Обычные SNMP функционируют по принципу запрос-ответ, однако, иногда нужна активная роль управляемого устройства, тогда существует блок данных типа Тгаре.
События, которые требуют внимания:
Перезагрузка управляемого устройства.
Исчезновениесвязи.
Существует 7 кодов прерывания и под каждым кодом подразумевается определённая ошибка, например код 7 означает прерывание специфичного для определённого оператора.
Тип будет записан в поле Generise Тгаре.
при посылке сообщения типа Тгаре помимо кода посылается адрес агента, время посылки сообщения, код производителя аппаратуры, а также произвольное число пар переменных, состоящих из имени и их значения. Например, имя. канал - значение, какой канал; скорость-какая скорость.
произвольное число пар переменных, состоящих из имени и их значения. Например, имя. канал - значение, какой канал; скорость-какая скорость. Для Get, Get Next, Set, Get Response суш^етвует другой формат:
Request (идентификатор запроса)- служит для связи номера запроса с ответом. ErrorStatus- состояние ошибки, сигнализирует о типе ошибки и о типе сбоя. Enorhtdex-связывает код ошибки с переменной.
Variable - список переменных.
ОСОБЕННОСТИ ВЕРСИИ 3 ПРОТОКОЛА SNMP
Главное отличие протокола SNMPv3 от его предыдущих версий, это классические функции безопасности [1-3], а именно:
аутентификация (Authentication), определяющая, что запрос получен от доверенного источника;
шифрование (Encryption), для предотвращения раскрытия передаваемых данных при их перехвате третьими лицами;
целостность (Integrity), то есть гарантия того, что пакет не был подделан при передаче.
SNMPv3 подразумевает использование модели безопасности, при которой стратегия аутентификации устанавливается для заданного пользователя и группы, к которой он относится (в предыдущих версиях SNMP в запросе от сервера к объекту мониторинга сравнивалось только «community», текстовая строка с «паролем», передаваемая в открытом виде (plain text)).
SNMPv3 вводит понятие уровней безопасности — допустимых уровней безопасности, определяющих настройку оборудования и поведение SNMP-агента объекта мониторинга. Сочетание модели безопасности и уровня безопасности определяет, какой механизм безопасности используется при обработке пакета SNMP [4].
В таблице описаны комбинации моделей и уровней безопасности SNMPv3 (первые три столбца я решил оставить как в оригинале): Соответственно, мы будем использовать SNMPv3 в режиме аутентификации с применением шифрования.
Настройка SNMPv3
Мониторинг сетевого оборудования предполагает одинаковую настройку протокола SNMPv3 и на сервере мониторинга, и на наблюдаемом объекте.
Начнем с настройки сетевого устройства Cisco, его минимально необходимая конфигурация выглядит следующим образом (для конфигурирования используем CLI, имена и пароли я упростил во избежание путаницы):
snmp-server group snmpv3group v3 priv read snmpv3name snmp-server user snmpv3user snmpv3group v3 auth md5 md5v3v3v3 priv des des56v3v3v3
snmp-server view snmpv3name iso included
Первая строка snmp-server group – определяет группу SNMPv3-пользователей (snmpv3group), режим чтения (read), и право доступа группы snmpv3group на просмотр определенных веток MIB-дерева объекта мониторинга (snmpv3name далее в конфигурации задает, к каким веткам MIB-дерева группа snmpv3group сможет получить доступ).
Вторая строка snmp-server user – определяет пользователя snmpv3user, его принадлежность к группе snmpv3group, а так же применение аутентификации md5 (пароль для md5 — md5v3v3v3) и шифрования des (пароль для des — des56v3v3v3). Разумеется, вместо des лучше использовать aes, здесь я его привожу просто для примера. Так же при определении пользователя можно добавить список доступа (ACL), регламентирующий IP-адреса серверов мониторинга, имеющих право осуществлять мониторинг данного устройства – это так же best practice, но я не буду усложнять наш пример.
Третья строка snmp-server view определяет кодовое имя, которое задает ветки MIB-дерева snmpv3name, чтобы их могла запрашивать группа пользователей snmpv3group. ISO, вместо строгого определения какой-то одной ветки, позволяет группе пользователей snmpv3group получать доступ ко всем объектам MIB-дерева объекта мониторинга.
Аналогичная настройка оборудования Huawei (так же в CLI) выглядит следующим образом:
snmp-agent mib-view included snmpv3name iso
snmp-agent group v3 snmpv3group privacy read-view snmpv3name
snmp-agent usm-user v3 snmpv3user group snmpv3group
snmp-agent usm-user v3 snmpv3user authentication-mode md5 md5v3v3v3
snmp-agent usm-user v3 snmpv3user privacy-mode des56 des56v3v3v3
После настройки сетевых устройств, необходимо проверить наличие доступа с сервера мониторинга по протоколу SNMPv3, я воспользуюсь snmpwalk:
snmpwalk -v 3 -u snmpv3user -l authPriv -A md5v3v3v3 -a md5 -x des -X des56v3v3v3 10.10.10.252 Более наглядный инструмент для запроса конкретных OID-объектов, с использованием MIB-фалов – snmpget: Теперь перейдем к настройке типового элемента данных для SNMPv3, в рамках Zabbix-шаблона. Для простоты и независимости от MIB, я использую цифровые OID: Я использую в ключевых полях пользовательские макросы, поскольку они будут одинаковы для всех элементов данных в шаблоне. Задавать их можно в рамках шаблона, если в Вашей сети у всех сетевых устройств параметры SNMPv3 одинаковы, или в рамках узла сети, если параметры SNMPv3 для разных объектов мониторинга отличаются: Обратите внимание, система мониторинга располагает только именем пользователя, и паролями для аутентификации и шифрования. Группа пользователей и область MIB-объектов, к которым разрешен доступ, задается на объекте мониторинга.
Теперь перейдем к наполнению шаблона.
Шаблон опроса в Zabbix
Простое правило при создании любых шаблонов опроса – делать их максимально подробными: Я уделяю большое внимание инвентаризации, чтобы с большой сетью было удобнее работать. Об этом немного позднее, а пока – триггеры: Для удобства визуализации триггеров в их названия заложены системные макросы {HOST.CONN}, чтобы на дашборде в разделе алёртинга выводились не только имена устройств, но и IP-адреса, хотя это больше вопрос удобства, чем необходимости. Для определения недоступности устройства, помимо обычного echo-запроса, я использую проверку на недоступность узла по протоколу SNMP, когда объект доступен по ICMP, но не отвечает на SNMP-запросы – такая ситуация возможна, например, при дублировании IP-адресов на разных устройствах, из-за некорректно настроенных межсетевых экранов, или неверных настроек SNMP на объектах мониторинга. Если использовать проверку доступности узлов только по ICMP, в момент расследования инцидентов в сети, данных мониторинга может не оказаться, поэтому их поступление нужно контролировать.
Перейдем к обнаружению сетевых интерфейсов – для сетевого оборудования это самая важная функция мониторинга. Поскольку на сетевом устройстве могут быть сотни интерфейсов, необходимо фильтровать ненужные, чтобы не загромождать визуализацию и не захламлять базу данных.
Используя стандартную функцию обнаружения для SNMP, с большим количеством обнаруживаемых параметров, для более гибкой фильтрации:
discovery[{#IFDESCR},1.3.6.1.2.1.2.2.1.2,{#IFALIAS},1.3.6.1.2.1.31.1.1.1.18,{#IFADMINSTATUS},1.3.6.1.2.1.2.2.1.7] При таком обнаружении, можно фильтровать сетевые интерфейсы по их типам, пользовательским описаниям «description», и административным статусам портов. Фильтры и регулярные выражения для фильтрации в моем случае выглядят следующим образом: При обнаружении будут исключены следующие интерфейсы:
выключенные вручную (adminstatus<>1), благодаря IFADMINSTATUS;
не имеющие текстового описания, благодаря IFALIAS;
имеющие в текстовом описании символ *, благодаря IFALIAS;
являющиеся служебными или техническими, благодаря IFDESCR (в моем случае, в регулярных выражениях IFALIAS и IFDESCR проверяются одним регулярным выражением alias).
Шаблон для сбора данных по протоколу SNMPv3 почти готов. Не будем подробнее останавливаться на прототипах элементов данных для сетевых интерфейсов, перейдем к результатам.
Итоги мониторинга
Для начала – инвентаризация небольшой сети: Если подготовить шаблоны для каждой серии сетевых устройств – можно добиться удобной для анализа компоновки сводных данных по актуальному ПО, серийным номерам, и оповещении о приходе в серверную уборщицы (по причине малого Uptime). Выдержка моего списка шаблонов ниже: А теперь – главная панель мониторинга, с распределенными по уровням важности триггерами: Благодаря комплексному подходу к шаблонам для каждой модели устройств в сети, можно добиться того, что в рамках одной системы мониторинга будет организован инструмент для прогнозирования неисправностей и аварий (при наличии соответствующих датчиков и метрик). Zabbix хорошо подходит для мониторинга сетевых, серверных, сервисных инфраструктур, и задача обслуживания сетевого оборудования наглядно демонстрирует её возможности. ЗАКЛЮЧЕНИЕ
В завершении хотелось бы отметить ряд моментов. Прежде всего, следует обратить внимание на то, что у многих крупных производителей имеются свои базы MIB и для более эффективного использования возможностей SNMP лучше использовать MIB для оборудования конкретного производителя. Для поиска баз MIB воспользуйтесь сайтом MIBSearch.com. Что же касается активного сетевого оборудования Cisco, то на CPAN.org можно найти множество Perlсценариев для взаимодействия по протоколу SNMP, а также сценариев, осуществляющих разбор SNMP-сообщений для конкретных событий, например для событий, связанных с протоколами динамической маршрутизации, потерей пакетов, состоянием VLAN и так далее.
Также, возможно, у вас сложилось впечатление, что протокол SNMP на практике использует только активное сетевое оборудование, канального и сетевого уровней, c встроенным программным обеспечением, однако это не так. К примеру, некоторые виды программного обеспечения, такие как корпоративные антивирусные системы, активно используют уведомления Trap для оповещения о вирусных инцидентах и эпидемиях. Также SNMP используют системы резервного копирования и системы бесперебойного питания.
Так что данный протокол полезен не только для организации систем управления сетевым оборудованием, но и для решения повседневных задач системного администрирования. СПИСОК ЛИТЕРАТУРЫ
1. Основы организации сетей Cisco. Справочное руководство.
2. www.opennet.org – интернет-ресурс со множеством статей и примеров, посвященных реализации SNMP на различных устройствах.
3. www.ietf.org – ресурс содержит все стандарты RFC, в том числе и RFC 1212, 1213.
4. www.CPAN.org – ресурс, на котором можно найти большое количество исходных кодов Perl-сценариев для работы с SNMP.
5. http://www.switch.ch/misc/leinen/snmp/perl/dist – исходный код, а также библиотеки, использованные при написании сценария.
6. http://www.adventnet.com/products/simulator – дистрибутив симулятора SNMP.
7. SNMP Configuration Guide, Cisco IOS XE Release 3SE. Chapter: SNMP Version 3. www.cisco.com/c/en/us/td/docs/ios-xml/ios/snmp/configuration/xe-3se/3850/snmp-xe-3se-3850-book/nm-snmp-snmpv3.html
СОДЕРЖАНИЕ
Введение 2
Описание протокола и его компонентов 3
Стандартные элементы протокола SNMP 4
Особенности версии 3 протокола SNMP 7
Заключение 15
Список литературы 16
ВВЕДЕНИЕ
Задача автоматизации управления различным сетевым оборудованием существует со времени появления первых сетевых устройств. На сегодняшний день практически в любой сети можно найти активное сетевое оборудование, управление которым можно, а как правило, нужно автоматизировать. Для решения подобных задач был разработан протокол SNMP (Simple Network Management Protocol). Существует масса готовых коммерческих решений по управлению различными устройствами с помощью SNMP, например HP Open View, однако не каждой организации по карману приобретение подобного ПО, к тому же эти программные продукты предназначены для управления большим количеством устройств, и их использование в небольших сетях будет нецелесообразным. ОПИСАНИЕ ПРОТОКОЛА И ЕГО КОМПОНЕНТОВ
SNMP использует UDP в качестве транспортного протокола порт 161 и предназначен для использования сетевыми управляющими станциями, как правило серверами, в качестве управляющих и активного сетевого оборудования в качестве управляемых систем. Протокол определяет формат данных, их обработка и интерпретация остаются на усмотрение управляющих станций.
SNMP-сообщения не имеют фиксированного формата и фиксированных полей. При работе протокол SNMP использует управляющую базу данных MIB – (Management Information Base), которая определяется стандартами RFC1213, 1212.
Общая архитектура взаимодействия по протоколу SNMP имеет следующий вид: на устройстве, которым необходимо управлять, запущен агент SNMP (см. рис. 1). Рисунок 1. Структура взаимодействия SNMP
Агенты имеют доступ к инфоpмации об упpавляемом устpойстве, на котоpом они запущены и делают ее доступной для систем сетевого упpавления NMS (Network Management Systems).
Упpавляемое устpойство может быть любого типа, лишь бы оно было подключено к сети, это могут быть как компьютеpы, так и сеpвеpа, пpинтеpы, маpшpутизатоpы, коммутаторы и даже DSL-модемы.
Для пpимеpа: устpойство может отслеживать следующие паpаметpы:
Количество и состояние своих виpтуальных соединений (Virtual circuits).
Количество пpинятых сообщений об ошибках опpеделенного pода (Number of certain kinds of error messages received).
Количество байт и пакетов, пpинятых и посланных этим устpойством.
Максимальное значение длины очеpеди (для маpшpутизатоpов и дpугих межсетевых устpойств).
Количество пpинятых и отправленных шиpоковещательных сообщений.
Состояние каждого из своих интеpфейсов.
СТАНДАРТНЫЕ ЭЛЕМЕНТЫ ПРОТОКОЛА SNMP
Стандартные элементы протокола SNMP включают в себя несколько команд:
GetHextRequest - запрос, используемый менеджером для получения значения следующего объекта (без указания имени) при последовательном просмотре таблицы объектов.
GetRequest - запрос, используемый менеджером для получения от агента значения какого-либо объекта по его имени.
GetRespons - ответ, используемый агентом для передачи сообщения на запросы (Get Request и Get Next Request).
Set-изменить, используется менеджером для какого-либо объекта.
Тгаре-особая ситуация, используется агентом для сообщения менеджеру.
Формат сообщений SNMP.
Сообщения в SNMP не имеют заголовка с фиксированными полями.
Сообщения SNMP состоят из произвольного количества полей, каждый из которых предворяется описанием и длиной.
Пакет SNMP состоит из трех основных полей Version - номер версии SNMP (1,2,3)
identification- используется для формирования устройств управления одним менеджером. Может служить для безопасности. SNMPPDU- блок данных определяет кол-во полей и кол-во тех. данных, которые войдут в формат протокола в дальнейшем. Типысообщений:
Get, Get Next, Set, Get Responce, Trape.
PDU- будет содержать имена переменных и их значения.
Фиксированный блок -зависит от переменных.
Variable (описание значения) • список переменных и их значения.
Формат значения Тгаре: Enterprise-идентифицирует тип объекта.
Agent addr-адрес агента.
GeneriseTrape - об шее описание проблемы (ошибка Alarm)
Specifix code Trape - код ошибки.
time -метка времени, указывает величину времени между последней инициализацией сети и генерацией данного сообщения Тгаре.
Variable- описание значения.
Обычные SNMP функционируют по принципу запрос-ответ, однако, иногда нужна активная роль управляемого устройства, тогда существует блок данных типа Тгаре.
События, которые требуют внимания:
Перезагрузка управляемого устройства.
Исчезновениесвязи.
Существует 7 кодов прерывания и под каждым кодом подразумевается определённая ошибка, например код 7 означает прерывание специфичного для определённого оператора.
Тип будет записан в поле Generise Тгаре.
при посылке сообщения типа Тгаре помимо кода посылается адрес агента, время посылки сообщения, код производителя аппаратуры, а также произвольное число пар переменных, состоящих из имени и их значения. Например, имя. канал - значение, какой канал; скорость-какая скорость.
произвольное число пар переменных, состоящих из имени и их значения. Например, имя. канал - значение, какой канал; скорость-какая скорость. Для Get, Get Next, Set, Get Response суш^етвует другой формат:
Request (идентификатор запроса)- служит для связи номера запроса с ответом. ErrorStatus- состояние ошибки, сигнализирует о типе ошибки и о типе сбоя. Enorhtdex-связывает код ошибки с переменной.
Variable - список переменных.
ОСОБЕННОСТИ ВЕРСИИ 3 ПРОТОКОЛА SNMP
Главное отличие протокола SNMPv3 от его предыдущих версий, это классические функции безопасности [1-3], а именно:
аутентификация (Authentication), определяющая, что запрос получен от доверенного источника;
шифрование (Encryption), для предотвращения раскрытия передаваемых данных при их перехвате третьими лицами;
целостность (Integrity), то есть гарантия того, что пакет не был подделан при передаче.
SNMPv3 подразумевает использование модели безопасности, при которой стратегия аутентификации устанавливается для заданного пользователя и группы, к которой он относится (в предыдущих версиях SNMP в запросе от сервера к объекту мониторинга сравнивалось только «community», текстовая строка с «паролем», передаваемая в открытом виде (plain text)).
SNMPv3 вводит понятие уровней безопасности — допустимых уровней безопасности, определяющих настройку оборудования и поведение SNMP-агента объекта мониторинга. Сочетание модели безопасности и уровня безопасности определяет, какой механизм безопасности используется при обработке пакета SNMP [4].
В таблице описаны комбинации моделей и уровней безопасности SNMPv3 (первые три столбца я решил оставить как в оригинале): Соответственно, мы будем использовать SNMPv3 в режиме аутентификации с применением шифрования.
Настройка SNMPv3
Мониторинг сетевого оборудования предполагает одинаковую настройку протокола SNMPv3 и на сервере мониторинга, и на наблюдаемом объекте.
Начнем с настройки сетевого устройства Cisco, его минимально необходимая конфигурация выглядит следующим образом (для конфигурирования используем CLI, имена и пароли я упростил во избежание путаницы):
snmp-server group snmpv3group v3 priv read snmpv3name snmp-server user snmpv3user snmpv3group v3 auth md5 md5v3v3v3 priv des des56v3v3v3
snmp-server view snmpv3name iso included
Первая строка snmp-server group – определяет группу SNMPv3-пользователей (snmpv3group), режим чтения (read), и право доступа группы snmpv3group на просмотр определенных веток MIB-дерева объекта мониторинга (snmpv3name далее в конфигурации задает, к каким веткам MIB-дерева группа snmpv3group сможет получить доступ).
Вторая строка snmp-server user – определяет пользователя snmpv3user, его принадлежность к группе snmpv3group, а так же применение аутентификации md5 (пароль для md5 — md5v3v3v3) и шифрования des (пароль для des — des56v3v3v3). Разумеется, вместо des лучше использовать aes, здесь я его привожу просто для примера. Так же при определении пользователя можно добавить список доступа (ACL), регламентирующий IP-адреса серверов мониторинга, имеющих право осуществлять мониторинг данного устройства – это так же best practice, но я не буду усложнять наш пример.
Третья строка snmp-server view определяет кодовое имя, которое задает ветки MIB-дерева snmpv3name, чтобы их могла запрашивать группа пользователей snmpv3group. ISO, вместо строгого определения какой-то одной ветки, позволяет группе пользователей snmpv3group получать доступ ко всем объектам MIB-дерева объекта мониторинга.
Аналогичная настройка оборудования Huawei (так же в CLI) выглядит следующим образом:
snmp-agent mib-view included snmpv3name iso
snmp-agent group v3 snmpv3group privacy read-view snmpv3name
snmp-agent usm-user v3 snmpv3user group snmpv3group
snmp-agent usm-user v3 snmpv3user authentication-mode md5 md5v3v3v3
snmp-agent usm-user v3 snmpv3user privacy-mode des56 des56v3v3v3
После настройки сетевых устройств, необходимо проверить наличие доступа с сервера мониторинга по протоколу SNMPv3, я воспользуюсь snmpwalk:
snmpwalk -v 3 -u snmpv3user -l authPriv -A md5v3v3v3 -a md5 -x des -X des56v3v3v3 10.10.10.252 Более наглядный инструмент для запроса конкретных OID-объектов, с использованием MIB-фалов – snmpget: Теперь перейдем к настройке типового элемента данных для SNMPv3, в рамках Zabbix-шаблона. Для простоты и независимости от MIB, я использую цифровые OID: Я использую в ключевых полях пользовательские макросы, поскольку они будут одинаковы для всех элементов данных в шаблоне. Задавать их можно в рамках шаблона, если в Вашей сети у всех сетевых устройств параметры SNMPv3 одинаковы, или в рамках узла сети, если параметры SNMPv3 для разных объектов мониторинга отличаются: Обратите внимание, система мониторинга располагает только именем пользователя, и паролями для аутентификации и шифрования. Группа пользователей и область MIB-объектов, к которым разрешен доступ, задается на объекте мониторинга.
Теперь перейдем к наполнению шаблона.
Шаблон опроса в Zabbix
Простое правило при создании любых шаблонов опроса – делать их максимально подробными: Я уделяю большое внимание инвентаризации, чтобы с большой сетью было удобнее работать. Об этом немного позднее, а пока – триггеры: Для удобства визуализации триггеров в их названия заложены системные макросы {HOST.CONN}, чтобы на дашборде в разделе алёртинга выводились не только имена устройств, но и IP-адреса, хотя это больше вопрос удобства, чем необходимости. Для определения недоступности устройства, помимо обычного echo-запроса, я использую проверку на недоступность узла по протоколу SNMP, когда объект доступен по ICMP, но не отвечает на SNMP-запросы – такая ситуация возможна, например, при дублировании IP-адресов на разных устройствах, из-за некорректно настроенных межсетевых экранов, или неверных настроек SNMP на объектах мониторинга. Если использовать проверку доступности узлов только по ICMP, в момент расследования инцидентов в сети, данных мониторинга может не оказаться, поэтому их поступление нужно контролировать.
Перейдем к обнаружению сетевых интерфейсов – для сетевого оборудования это самая важная функция мониторинга. Поскольку на сетевом устройстве могут быть сотни интерфейсов, необходимо фильтровать ненужные, чтобы не загромождать визуализацию и не захламлять базу данных.
Используя стандартную функцию обнаружения для SNMP, с большим количеством обнаруживаемых параметров, для более гибкой фильтрации:
discovery[{#IFDESCR},1.3.6.1.2.1.2.2.1.2,{#IFALIAS},1.3.6.1.2.1.31.1.1.1.18,{#IFADMINSTATUS},1.3.6.1.2.1.2.2.1.7] При таком обнаружении, можно фильтровать сетевые интерфейсы по их типам, пользовательским описаниям «description», и административным статусам портов. Фильтры и регулярные выражения для фильтрации в моем случае выглядят следующим образом: При обнаружении будут исключены следующие интерфейсы:
выключенные вручную (adminstatus<>1), благодаря IFADMINSTATUS;
не имеющие текстового описания, благодаря IFALIAS;
имеющие в текстовом описании символ *, благодаря IFALIAS;
являющиеся служебными или техническими, благодаря IFDESCR (в моем случае, в регулярных выражениях IFALIAS и IFDESCR проверяются одним регулярным выражением alias).
Шаблон для сбора данных по протоколу SNMPv3 почти готов. Не будем подробнее останавливаться на прототипах элементов данных для сетевых интерфейсов, перейдем к результатам.
Итоги мониторинга
Для начала – инвентаризация небольшой сети: Если подготовить шаблоны для каждой серии сетевых устройств – можно добиться удобной для анализа компоновки сводных данных по актуальному ПО, серийным номерам, и оповещении о приходе в серверную уборщицы (по причине малого Uptime). Выдержка моего списка шаблонов ниже: А теперь – главная панель мониторинга, с распределенными по уровням важности триггерами: Благодаря комплексному подходу к шаблонам для каждой модели устройств в сети, можно добиться того, что в рамках одной системы мониторинга будет организован инструмент для прогнозирования неисправностей и аварий (при наличии соответствующих датчиков и метрик). Zabbix хорошо подходит для мониторинга сетевых, серверных, сервисных инфраструктур, и задача обслуживания сетевого оборудования наглядно демонстрирует её возможности. ЗАКЛЮЧЕНИЕ
В завершении хотелось бы отметить ряд моментов. Прежде всего, следует обратить внимание на то, что у многих крупных производителей имеются свои базы MIB и для более эффективного использования возможностей SNMP лучше использовать MIB для оборудования конкретного производителя. Для поиска баз MIB воспользуйтесь сайтом MIBSearch.com. Что же касается активного сетевого оборудования Cisco, то на CPAN.org можно найти множество Perlсценариев для взаимодействия по протоколу SNMP, а также сценариев, осуществляющих разбор SNMP-сообщений для конкретных событий, например для событий, связанных с протоколами динамической маршрутизации, потерей пакетов, состоянием VLAN и так далее.
Также, возможно, у вас сложилось впечатление, что протокол SNMP на практике использует только активное сетевое оборудование, канального и сетевого уровней, c встроенным программным обеспечением, однако это не так. К примеру, некоторые виды программного обеспечения, такие как корпоративные антивирусные системы, активно используют уведомления Trap для оповещения о вирусных инцидентах и эпидемиях. Также SNMP используют системы резервного копирования и системы бесперебойного питания.
Так что данный протокол полезен не только для организации систем управления сетевым оборудованием, но и для решения повседневных задач системного администрирования. СПИСОК ЛИТЕРАТУРЫ
1. Основы организации сетей Cisco. Справочное руководство.
2. www.opennet.org – интернет-ресурс со множеством статей и примеров, посвященных реализации SNMP на различных устройствах.
3. www.ietf.org – ресурс содержит все стандарты RFC, в том числе и RFC 1212, 1213.
4. www.CPAN.org – ресурс, на котором можно найти большое количество исходных кодов Perl-сценариев для работы с SNMP.
5. http://www.switch.ch/misc/leinen/snmp/perl/dist – исходный код, а также библиотеки, использованные при написании сценария.
6. http://www.adventnet.com/products/simulator – дистрибутив симулятора SNMP.
7. SNMP Configuration Guide, Cisco IOS XE Release 3SE. Chapter: SNMP Version 3. www.cisco.com/c/en/us/td/docs/ios-xml/ios/snmp/configuration/xe-3se/3850/snmp-xe-3se-3850-book/nm-snmp-snmpv3.html
СОДЕРЖАНИЕ
Введение 2
Описание протокола и его компонентов 3
Стандартные элементы протокола SNMP 4
Особенности версии 3 протокола SNMP 7
Заключение 15
Список литературы 16
ВВЕДЕНИЕ
Задача автоматизации управления различным сетевым оборудованием существует со времени появления первых сетевых устройств. На сегодняшний день практически в любой сети можно найти активное сетевое оборудование, управление которым можно, а как правило, нужно автоматизировать. Для решения подобных задач был разработан протокол SNMP (Simple Network Management Protocol). Существует масса готовых коммерческих решений по управлению различными устройствами с помощью SNMP, например HP Open View, однако не каждой организации по карману приобретение подобного ПО, к тому же эти программные продукты предназначены для управления большим количеством устройств, и их использование в небольших сетях будет нецелесообразным. ОПИСАНИЕ ПРОТОКОЛА И ЕГО КОМПОНЕНТОВ
SNMP использует UDP в качестве транспортного протокола порт 161 и предназначен для использования сетевыми управляющими станциями, как правило серверами, в качестве управляющих и активного сетевого оборудования в качестве управляемых систем. Протокол определяет формат данных, их обработка и интерпретация остаются на усмотрение управляющих станций.
SNMP-сообщения не имеют фиксированного формата и фиксированных полей. При работе протокол SNMP использует управляющую базу данных MIB – (Management Information Base), которая определяется стандартами RFC1213, 1212.
Общая архитектура взаимодействия по протоколу SNMP имеет следующий вид: на устройстве, которым необходимо управлять, запущен агент SNMP (см. рис. 1). Рисунок 1. Структура взаимодействия SNMP
Агенты имеют доступ к инфоpмации об упpавляемом устpойстве, на котоpом они запущены и делают ее доступной для систем сетевого упpавления NMS (Network Management Systems).
Упpавляемое устpойство может быть любого типа, лишь бы оно было подключено к сети, это могут быть как компьютеpы, так и сеpвеpа, пpинтеpы, маpшpутизатоpы, коммутаторы и даже DSL-модемы.
Для пpимеpа: устpойство может отслеживать следующие паpаметpы:
Количество и состояние своих виpтуальных соединений (Virtual circuits).
Количество пpинятых сообщений об ошибках опpеделенного pода (Number of certain kinds of error messages received).
Количество байт и пакетов, пpинятых и посланных этим устpойством.
Максимальное значение длины очеpеди (для маpшpутизатоpов и дpугих межсетевых устpойств).
Количество пpинятых и отправленных шиpоковещательных сообщений.
Состояние каждого из своих интеpфейсов.
СТАНДАРТНЫЕ ЭЛЕМЕНТЫ ПРОТОКОЛА SNMP
Стандартные элементы протокола SNMP включают в себя несколько команд:
GetHextRequest - запрос, используемый менеджером для получения значения следующего объекта (без указания имени) при последовательном просмотре таблицы объектов.
GetRequest - запрос, используемый менеджером для получения от агента значения какого-либо объекта по его имени.
GetRespons - ответ, используемый агентом для передачи сообщения на запросы (Get Request и Get Next Request).
Set-изменить, используется менеджером для какого-либо объекта.
Тгаре-особая ситуация, используется агентом для сообщения менеджеру.
Формат сообщений SNMP.
Сообщения в SNMP не имеют заголовка с фиксированными полями.
Сообщения SNMP состоят из произвольного количества полей, каждый из которых предворяется описанием и длиной.
Пакет SNMP состоит из трех основных полей Version - номер версии SNMP (1,2,3)
identification- используется для формирования устройств управления одним менеджером. Может служить для безопасности. SNMPPDU- блок данных определяет кол-во полей и кол-во тех. данных, которые войдут в формат протокола в дальнейшем. Типысообщений:
Get, Get Next, Set, Get Responce, Trape.
PDU- будет содержать имена переменных и их значения.
Фиксированный блок -зависит от переменных.
Variable (описание значения) • список переменных и их значения.
Формат значения Тгаре: Enterprise-идентифицирует тип объекта.
Agent addr-адрес агента.
GeneriseTrape - об шее описание проблемы (ошибка Alarm)
Specifix code Trape - код ошибки.
time -метка времени, указывает величину времени между последней инициализацией сети и генерацией данного сообщения Тгаре.
Variable- описание значения.
Обычные SNMP функционируют по принципу запрос-ответ, однако, иногда нужна активная роль управляемого устройства, тогда существует блок данных типа Тгаре.
События, которые требуют внимания:
Перезагрузка управляемого устройства.
Исчезновениесвязи.
Существует 7 кодов прерывания и под каждым кодом подразумевается определённая ошибка, например код 7 означает прерывание специфичного для определённого оператора.
Тип будет записан в поле Generise Тгаре.
при посылке сообщения типа Тгаре помимо кода посылается адрес агента, время посылки сообщения, код производителя аппаратуры, а также произвольное число пар переменных, состоящих из имени и их значения. Например, имя. канал - значение, какой канал; скорость-какая скорость.
произвольное число пар переменных, состоящих из имени и их значения. Например, имя. канал - значение, какой канал; скорость-какая скорость. Для Get, Get Next, Set, Get Response суш^етвует другой формат:
Request (идентификатор запроса)- служит для связи номера запроса с ответом. ErrorStatus- состояние ошибки, сигнализирует о типе ошибки и о типе сбоя. Enorhtdex-связывает код ошибки с переменной.
Variable - список переменных.
ОСОБЕННОСТИ ВЕРСИИ 3 ПРОТОКОЛА SNMP
Главное отличие протокола SNMPv3 от его предыдущих версий, это классические функции безопасности [1-3], а именно:
аутентификация (Authentication), определяющая, что запрос получен от доверенного источника;
шифрование (Encryption), для предотвращения раскрытия передаваемых данных при их перехвате третьими лицами;
целостность (Integrity), то есть гарантия того, что пакет не был подделан при передаче.
SNMPv3 подразумевает использование модели безопасности, при которой стратегия аутентификации устанавливается для заданного пользователя и группы, к которой он относится (в предыдущих версиях SNMP в запросе от сервера к объекту мониторинга сравнивалось только «community», текстовая строка с «паролем», передаваемая в открытом виде (plain text)).
SNMPv3 вводит понятие уровней безопасности — допустимых уровней безопасности, определяющих настройку оборудования и поведение SNMP-агента объекта мониторинга. Сочетание модели безопасности и уровня безопасности определяет, какой механизм безопасности используется при обработке пакета SNMP [4].
В таблице описаны комбинации моделей и уровней безопасности SNMPv3 (первые три столбца я решил оставить как в оригинале): Соответственно, мы будем использовать SNMPv3 в режиме аутентификации с применением шифрования.
Настройка SNMPv3
Мониторинг сетевого оборудования предполагает одинаковую настройку протокола SNMPv3 и на сервере мониторинга, и на наблюдаемом объекте.
Начнем с настройки сетевого устройства Cisco, его минимально необходимая конфигурация выглядит следующим образом (для конфигурирования используем CLI, имена и пароли я упростил во избежание путаницы):
snmp-server group snmpv3group v3 priv read snmpv3name snmp-server user snmpv3user snmpv3group v3 auth md5 md5v3v3v3 priv des des56v3v3v3
snmp-server view snmpv3name iso included
Первая строка snmp-server group – определяет группу SNMPv3-пользователей (snmpv3group), режим чтения (read), и право доступа группы snmpv3group на просмотр определенных веток MIB-дерева объекта мониторинга (snmpv3name далее в конфигурации задает, к каким веткам MIB-дерева группа snmpv3group сможет получить доступ).
Вторая строка snmp-server user – определяет пользователя snmpv3user, его принадлежность к группе snmpv3group, а так же применение аутентификации md5 (пароль для md5 — md5v3v3v3) и шифрования des (пароль для des — des56v3v3v3). Разумеется, вместо des лучше использовать aes, здесь я его привожу просто для примера. Так же при определении пользователя можно добавить список доступа (ACL), регламентирующий IP-адреса серверов мониторинга, имеющих право осуществлять мониторинг данного устройства – это так же best practice, но я не буду усложнять наш пример.
Третья строка snmp-server view определяет кодовое имя, которое задает ветки MIB-дерева snmpv3name, чтобы их могла запрашивать группа пользователей snmpv3group. ISO, вместо строгого определения какой-то одной ветки, позволяет группе пользователей snmpv3group получать доступ ко всем объектам MIB-дерева объекта мониторинга.
Аналогичная настройка оборудования Huawei (так же в CLI) выглядит следующим образом:
snmp-agent mib-view included snmpv3name iso
snmp-agent group v3 snmpv3group privacy read-view snmpv3name
snmp-agent usm-user v3 snmpv3user group snmpv3group
snmp-agent usm-user v3 snmpv3user authentication-mode md5 md5v3v3v3
snmp-agent usm-user v3 snmpv3user privacy-mode des56 des56v3v3v3
После настройки сетевых устройств, необходимо проверить наличие доступа с сервера мониторинга по протоколу SNMPv3, я воспользуюсь snmpwalk:
snmpwalk -v 3 -u snmpv3user -l authPriv -A md5v3v3v3 -a md5 -x des -X des56v3v3v3 10.10.10.252 Более наглядный инструмент для запроса конкретных OID-объектов, с использованием MIB-фалов – snmpget: Теперь перейдем к настройке типового элемента данных для SNMPv3, в рамках Zabbix-шаблона. Для простоты и независимости от MIB, я использую цифровые OID: Я использую в ключевых полях пользовательские макросы, поскольку они будут одинаковы для всех элементов данных в шаблоне. Задавать их можно в рамках шаблона, если в Вашей сети у всех сетевых устройств параметры SNMPv3 одинаковы, или в рамках узла сети, если параметры SNMPv3 для разных объектов мониторинга отличаются: Обратите внимание, система мониторинга располагает только именем пользователя, и паролями для аутентификации и шифрования. Группа пользователей и область MIB-объектов, к которым разрешен доступ, задается на объекте мониторинга.
Теперь перейдем к наполнению шаблона.
Шаблон опроса в Zabbix
Простое правило при создании любых шаблонов опроса – делать их максимально подробными: Я уделяю большое внимание инвентаризации, чтобы с большой сетью было удобнее работать. Об этом немного позднее, а пока – триггеры: Для удобства визуализации триггеров в их названия заложены системные макросы {HOST.CONN}, чтобы на дашборде в разделе алёртинга выводились не только имена устройств, но и IP-адреса, хотя это больше вопрос удобства, чем необходимости. Для определения недоступности устройства, помимо обычного echo-запроса, я использую проверку на недоступность узла по протоколу SNMP, когда объект доступен по ICMP, но не отвечает на SNMP-запросы – такая ситуация возможна, например, при дублировании IP-адресов на разных устройствах, из-за некорректно настроенных межсетевых экранов, или неверных настроек SNMP на объектах мониторинга. Если использовать проверку доступности узлов только по ICMP, в момент расследования инцидентов в сети, данных мониторинга может не оказаться, поэтому их поступление нужно контролировать.
Перейдем к обнаружению сетевых интерфейсов – для сетевого оборудования это самая важная функция мониторинга. Поскольку на сетевом устройстве могут быть сотни интерфейсов, необходимо фильтровать ненужные, чтобы не загромождать визуализацию и не захламлять базу данных.
Используя стандартную функцию обнаружения для SNMP, с большим количеством обнаруживаемых параметров, для более гибкой фильтрации:
discovery[{#IFDESCR},1.3.6.1.2.1.2.2.1.2,{#IFALIAS},1.3.6.1.2.1.31.1.1.1.18,{#IFADMINSTATUS},1.3.6.1.2.1.2.2.1.7] При таком обнаружении, можно фильтровать сетевые интерфейсы по их типам, пользовательским описаниям «description», и административным статусам портов. Фильтры и регулярные выражения для фильтрации в моем случае выглядят следующим образом: При обнаружении будут исключены следующие интерфейсы:
выключенные вручную (adminstatus<>1), благодаря IFADMINSTATUS;
не имеющие текстового описания, благодаря IFALIAS;
имеющие в текстовом описании символ *, благодаря IFALIAS;
являющиеся служебными или техническими, благодаря IFDESCR (в моем случае, в регулярных выражениях IFALIAS и IFDESCR проверяются одним регулярным выражением alias).
Шаблон для сбора данных по протоколу SNMPv3 почти готов. Не будем подробнее останавливаться на прототипах элементов данных для сетевых интерфейсов, перейдем к результатам.
Итоги мониторинга
Для начала – инвентаризация небольшой сети: Если подготовить шаблоны для каждой серии сетевых устройств – можно добиться удобной для анализа компоновки сводных данных по актуальному ПО, серийным номерам, и оповещении о приходе в серверную уборщицы (по причине малого Uptime). Выдержка моего списка шаблонов ниже: А теперь – главная панель мониторинга, с распределенными по уровням важности триггерами: Благодаря комплексному подходу к шаблонам для каждой модели устройств в сети, можно добиться того, что в рамках одной системы мониторинга будет организован инструмент для прогнозирования неисправностей и аварий (при наличии соответствующих датчиков и метрик). Zabbix хорошо подходит для мониторинга сетевых, серверных, сервисных инфраструктур, и задача обслуживания сетевого оборудования наглядно демонстрирует её возможности. ЗАКЛЮЧЕНИЕ
В завершении хотелось бы отметить ряд моментов. Прежде всего, следует обратить внимание на то, что у многих крупных производителей имеются свои базы MIB и для более эффективного использования возможностей SNMP лучше использовать MIB для оборудования конкретного производителя. Для поиска баз MIB воспользуйтесь сайтом MIBSearch.com. Что же касается активного сетевого оборудования Cisco, то на CPAN.org можно найти множество Perlсценариев для взаимодействия по протоколу SNMP, а также сценариев, осуществляющих разбор SNMP-сообщений для конкретных событий, например для событий, связанных с протоколами динамической маршрутизации, потерей пакетов, состоянием VLAN и так далее.
Также, возможно, у вас сложилось впечатление, что протокол SNMP на практике использует только активное сетевое оборудование, канального и сетевого уровней, c встроенным программным обеспечением, однако это не так. К примеру, некоторые виды программного обеспечения, такие как корпоративные антивирусные системы, активно используют уведомления Trap для оповещения о вирусных инцидентах и эпидемиях. Также SNMP используют системы резервного копирования и системы бесперебойного питания.
Так что данный протокол полезен не только для организации систем управления сетевым оборудованием, но и для решения повседневных задач системного администрирования. СПИСОК ЛИТЕРАТУРЫ
1. Основы организации сетей Cisco. Справочное руководство.
2. www.opennet.org – интернет-ресурс со множеством статей и примеров, посвященных реализации SNMP на различных устройствах.
3. www.ietf.org – ресурс содержит все стандарты RFC, в том числе и RFC 1212, 1213.
4. www.CPAN.org – ресурс, на котором можно найти большое количество исходных кодов Perl-сценариев для работы с SNMP.
5. http://www.switch.ch/misc/leinen/snmp/perl/dist – исходный код, а также библиотеки, использованные при написании сценария.
6. http://www.adventnet.com/products/simulator – дистрибутив симулятора SNMP.
7. SNMP Configuration Guide, Cisco IOS XE Release 3SE. Chapter: SNMP Version 3. www.cisco.com/c/en/us/td/docs/ios-xml/ios/snmp/configuration/xe-3se/3850/snmp-xe-3se-3850-book/nm-snmp-snmpv3.html