Мониторинг сетевого оборудования по SNMPv3 в Zabbix

    Эта статья посвящена особенностям мониторинга сетевого оборудования с помощью протокола SNMPv3. Мы поговорим об SNMPv3, я поделюсь своими наработками по созданию полноценных шаблонов в Zabbix, и покажу, чего можно добиться при организации распределенного алертинга в большой сети. Протокол SNMP является основным при мониторинге сетевого оборудования, а Zabbix отлично подходит для мониторинга большого количества объектов и обобщения значительных объемов поступающих метрик.

    Несколько слов об SNMPv3


    Начнем с назначения протокола SNMPv3, и особенностей его использования. Задачи 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 хорошо подходит для мониторинга сетевых, серверных, сервисных инфраструктур, и задача обслуживания сетевого оборудования наглядно демонстрирует её возможности.

    Список использованных источников:
    1. Hucaby D. CCNP Routing and Switching SWITCH 300-115 Official Cert Guide. Cisco Press, 2014. pp. 325-329.
    2. RFC 3410. tools.ietf.org/html/rfc3410
    3. RFC 3415. tools.ietf.org/html/rfc3415
    4. 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
    Zabbix
    Компания

    Похожие публикации

    Комментарии 0

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое