Usm checker

Описание

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

Для определения доступности используются различные методы проверок, которые дают более достоверный результат в зависимости о специфики конкретных сетей или узлов. Модуль является аналитическим и не может со 100% достоверностью определить активность узла в сети. Например, если на тестируемом узле заблокированы ICMP-запросы, то единственный способом определить доступность такого узла может быть проверка записи в ARP-таблице, но и в ARP-таблице данные могут быть не достоверны, так как запись в ней находится какое-то время вне зависимости от фактической доступности узла. Поэтому следует выбирать методы проверок, которые дают более точный результат.

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

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

Требования

Python 3.4 USERSIDE 3.12.41

Установка

Установите Python и менеджер пакетов pip

 sudo apt install -y python3 python3-pip

Скачайте архив, извлеките из него каталог с файлами модуля. Перейдите в этот каталог и установите зависимости, введя команду:

 sudo pip3 install --upgrade -r requirements.txt

Затем, если это первоначальная установка, скопируйте файл settings.yml-example с именем settings.yml

 cp settings.yml-example settings.yml

Отредактируйте этот файл (предварительно ознакомьтесь с форматом yaml, если это необходимо):

Укажите верные значения для секции api - URL вашего USERSIDE и API-ключ.

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

Стратегии проверок доступности

Всего существует три стратегии (метода) проверки доступности хостов: ping, cmd, snmp

Каждый метод содержит обязательные поля, такие как:

• method - наименование метода
• networks - список подсетей, для которых применять данный метод. Подсети не должны пересекаться с подсетями других методов.

И одно необязательное поле group, которое можно добавить к проверке, чтобы отнести ее к той или иной группе (об использовании групп будет сказано позже).

Эти поля относятся абсолютно ко всем проверкам.

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

Методы проверок

ping

Данный метод предназначен для выявления активных хостов путем проверки ответов на запрос ICMP-ECHO к этим хостам. Если хост ответил - он считается активным. В противном случае - не активным.

Данный метод может включать дополнительные необязательные параметры, такие как:

• in_iteration - значение которого - количество асинхронных ICMP-ECHO запросов в одной итерации. По умолчанию используется 1024 запроса, но если ваша сетевая инфраструктура препятствует прохождению такого большого ICMP-трафика, уменьшайте значение до такого, при котором ICMP-трафик не будет отфильтрован оборудованием сети.
• timeout - таймаут ожидания ответов в секундах (время на одну итерацию). Значение по умолчанию - 1 секунда. Не рекомендуется указывать время ожидания менее секунды. Если нужно увеличить время между итерациями - увеличте это значение.
• retry - количество попыток выполнения запросов.

cmd

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

Команда должна выводить на стандартный вывод список IP-адресов активных хостов по одному в строку.

Примером может послужить команда ip neigh show | awk '{print $1}'

Вы также можете выполнить команду на удаленном узле через ssh, например: ssh gateway.network.net -i ~/.ssh/id_rsa 'ip neigh show dev eth0' 2>/dev/null | awk '{print $1}'

Команда указывание в значении параметра command. Никаких других дополнительных параметров данный метод не поддерживает.

snmp

Данный метод предназначен для выявления активных хостов путем чтения ARP-таблицы, используя SNMP-запрос GET-BULK. По умолчанию выполняется чтение из таблицы .1.3.6.1.2.1.4.22.1.2

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

• community - наименование коммунити для чтения
• host - адрес узла SNMP-агента

Также можно указать альтернативный OID ARP-таблицы (если на вашем устройстве он не стандартный). Для этого используется необязательный параметр oid.

Подразумевается, что IP-адрес хоста содержится в суффиксе OID каждой строки таблицы. Модуль извлекает IP-адрес хоста из OID и считывает его только в том случае, если значение этого OID не пусто (содержит МАС-адрес).

Первый тестовый запуск

Выполните тестовый запуск модуля с правами суперпользователя:

 sudo python3 usm_checker.py

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

Автоматизированный запуск

Отредактируйте файл settings.yml, изменив в секции log значение to_console на no и значение level на 2.

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

Если у вас небольшая сеть (до 500 узлов), то достаточно запускать модуль раз в несколько минут, чтобы он определял активность как оборудования так и абонентов.

 */2 * * * *    root    python3 /path/to/usm_checher.py > /dev/null 2>&1

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

Но, если количество узлов большое, либо модуль работает достаточно долго (больше 30 секунд), следует использовать разделенный запуск по группам. Для этого, при помощи параметра group в файле настроек settings.yml, разнесите проверки по группам. Например, выделите группу для оборудования, назвав ее equipment и группу для абонентов, назвав ее customers.

Одна проверка может относиться только к одной группе. Одна и та же группа может повторяться на любом количестве проверок. Файл настроек может выглядеть следующим образом (здесь проверка методом ping отнесена к группе equipment, а проверка методом cmd, считывающая ARP-таблицу, к группе customers).

 checks:
   - method: ping
     group: equipment
     networks:
       - 192.186.0.0/24
       - 192.168.1.128/25
   - method: cmd
     group: customers
     command: "ip neigh show | awk '{print $1}'"
     networks:
       - 192.168.2.0/24

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

 */1  * * * *    root    python3 /path/to/usm_checher.py equipment > /dev/null 2>&1
 */15 * * * *    root    python3 /path/to/usm_checher.py customers > /dev/null 2>&1

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