Управление устройствами NetPing из командной строки в Linux и Windows

Введение

В статье «Пример управления устройствами NetPing из командной строки по SNMP при помощи библиотеки NET-SNMP»⁠ были рассмотрены базовые операции чтения и записи отдельных OID с помощью snmpget.exe и snmpset.exe в Windows. В новом материале мы подробнее рассмотрим возможности работы с командной строкой: использование в Linux и Windows, обход дерева OID, прием SNMP Trap, а также реализацию сценариев автоматического реагирования на примере скрипта, который пингует узел и при его недоступности отправляет команды на устройство NetPing IO v5.

В устройствах NetPing чтение по протоколу SNMP выполняется запросами GET и GETNEXT, а запись — SET. Конкретный набор OID и доступных для записи параметров зависит от модели и версии встроенного ПО, поэтому перед составлением команд необходимо использовать таблицу OID или MIB-файл соответствующей прошивки.

В примерах используется IP-адрес устройства по умолчанию 192.168.0.100. Community чтения и записи по умолчанию — SWITCH.

В рабочей инфраструктуре стандартное значение community рекомендуется изменить. SNMP v1 не шифрует community и передаваемые данные, поэтому доступ к UDP/161 следует ограничить доверенным сегментом управления, ACL, межсетевым экраном или VPN.

Поддержка протокола и доступные операции для рассматриваемого в статье устройства NetPing IO v5 описаны в разделе 8 «Поддержка SNMP протокола» описания встроенного ПО NetPing IO v5⁠.

Используемые OID NetPing IO v5

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

  • .1.3.6.1.2.1.1.3.0

Объект sysUpTime имеет тип TimeTicks, доступ READ и показывает время работы с момента последнего включения или перезагрузки.

Текущее состояние Output-линии читается по OID:

  • .1.3.6.1.4.1.25728.8920.1.1.3.n

Здесь n — номер Output-линии от 1 до 2. Возвращаемые значения 0 и 1 соответствуют логическому нулю и логической единице.

Для управления Output-линией используется тот же OID, что и для чтения:

  • .1.3.6.1.4.1.25728.8920.1.1.3.n

Объект имеет тип Integer и доступ READ/WRITE. Запись 0 устанавливает логический ноль, запись 1 — логическую единицу.

Под переключением выхода далее понимается установка заданного логического уровня. Output-линия не является силовым выходом. Фактическое управление нагрузкой зависит от схемы подключения, внешнего реле или другого исполнительного устройства.

Полный перечень OID, их типы, права доступа и допустимые значения приведены в разделе 8.1 «Список OID» описания встроенного ПО NetPing IO v5⁠.

Какие SNMP TRAP отправляет NetPing IO v5

NetPing IO v5 поддерживает настраиваемые SNMP-уведомления с пользовательскими условиями отправки при изменении уровня дискретного входа, уровня дискретного выхода и статуса термодатчика (раздел 7 «Настройка уведомлений» описания встроенного ПО NetPing IO v5⁠).

TRAP-сообщения передаются в формате SNMP v1/v2c, а их описание в MIB-файле приведено в формате SNMP v2c. Поле памятки для дискретных входов и выходов передается в кодировке win1251, поэтому при обработке сообщений в системах с UTF-8 может потребоваться преобразование кодировки. Формат и состав сообщений приведены в разделе 8.2 «SNMP TRAP» описания встроенного ПО NetPing IO v5.

Работа с Net-SNMP в Linux

Установка

В Debian и Ubuntu клиентские утилиты и приемник SNMP TRAP устанавливаются командами:


sudo apt update
sudo apt install snmp snmptrapd

Отправка GET-запроса

Получить время работы NetPing IO v5:


snmpget -v1 -c SWITCH 192.168.0.100 .1.3.6.1.2.1.1.3.0

Получить только значение без имени OID и типа данных:


snmpget -v1 -c SWITCH -Oqv 192.168.0.100 .1.3.6.1.2.1.1.3.0

Параметр -Oqv изменяет формат вывода: q включает сокращенное представление, а v оставляет только значение OID без его имени и типа данных. Такой формат удобен для последующей обработки результата в скриптах.

Прочитать текущее состояние OUT1:


snmpget -v1 -c SWITCH -Oqv 192.168.0.100 .1.3.6.1.4.1.25728.8920.1.1.3.1

Отправка SET-запроса

Установить логическую единицу на OUT1:


snmpset -v1 -c SWITCH 192.168.0.100 .1.3.6.1.4.1.25728.8920.1.1.3.1 i 1

Установить логический ноль:


snmpset -v1 -c SWITCH 192.168.0.100 .1.3.6.1.4.1.25728.8920.1.1.3.1 i 0

Обозначение i указывает, что записываемое значение имеет тип Integer.

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

Отправка WALK-запроса

Обойти корпоративную ветвь OID NetPing:


snmpwalk -v1 -c SWITCH 192.168.0.100 .1.3.6.1.4.1.25728

Получить ветвь параметров Output-линий NetPing IO v5:


snmpwalk -v1 -c SWITCH 192.168.0.100 .1.3.6.1.4.1.25728.8920

snmpwalk последовательно выполняет GETNEXT-запросы и выводит объекты внутри указанной ветви. Полный обход удобен при первичном изучении устройства. Для регулярного мониторинга лучше обращаться к конкретным OID.

Прием SNMP TRAP в Linux

Для приема уведомлений используется snmptrapd, который обычно прослушивает UDP/162.
В файле /etc/snmp/snmptrapd.conf необходимо разрешить обработку сообщений с используемой для отправки TRAP community. Для работы с устройством NetPing IO v5 с прошивкой DKSF 58.1.14 добавьте строку:


authCommunity log public

Если используется другая модель устройства или версия встроенного ПО, необходимо уточнить community-строку для SNMP Trap и заменить public на актуальное значение.
Запуск в интерактивном режиме:


sudo snmptrapd -f -Lo -c /etc/snmp/snmptrapd.conf udp:162

Параметр -f оставляет процесс в foreground, -Lo направляет сообщения в стандартный вывод, а -c задает конфигурационный файл.

Если UDP/162 уже занят, snmptrapd не сможет открыть порт. Проверить использование порта можно командой:


sudo ss -lnup | grep :162

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

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

Внешний сетевой сторож в Linux

NetPing IO v5 не имеет встроенного пингера. Внешний Bash-скрипт может проверять доступность заданного адреса и отправлять SNMP SET для изменения состояния OUT1.

В примере отказ фиксируется после трех последовательных неуспешных проверок. После двух успешных проверок отправляется команда возврата выхода.


#!/usr/bin/env bash

TARGET_HOST="192.168.0.1"
NETPING_HOST="192.168.0.100"
COMMUNITY="SWITCH"
OUTPUT_OID=".1.3.6.1.4.1.25728.8920.1.1.3.1"

FAIL_STATE=1
RECOVERY_STATE=0
POLL_INTERVAL=10
FAIL_THRESHOLD=3
RECOVERY_THRESHOLD=2

fail_count=0
recovery_count=0
failure_active=0

set_output() {
    snmpset -v1 -c "$COMMUNITY" -t 2 -r 1 "$NETPING_HOST" "$OUTPUT_OID" i "$1" >/dev/null
}

while true; do
    if ping -c 1 -W 1 "$TARGET_HOST" >/dev/null 2>&1; then
        fail_count=0
        ((recovery_count += 1))

        if (( failure_active == 1 && recovery_count >= RECOVERY_THRESHOLD )); then
            if set_output "$RECOVERY_STATE"; then
                failure_active=0
                printf '%s Связь восстановлена, отправлен SET OUT1=%s\n' "$(date '+%F %T')" "$RECOVERY_STATE"
            fi
            recovery_count="$RECOVERY_THRESHOLD"
        fi
    else
        recovery_count=0
        ((fail_count += 1))

        if (( failure_active == 0 && fail_count >= FAIL_THRESHOLD )); then
            if set_output "$FAIL_STATE"; then
                failure_active=1
                printf '%s Узел недоступен, отправлен SET OUT1=%s\n' "$(date '+%F %T')" "$FAIL_STATE"
            fi
            fail_count="$FAIL_THRESHOLD"
        fi
    fi

    sleep "$POLL_INTERVAL"
done

Скрипт использует стандартную ICMP-проверку. Для контроля прикладного сервиса ping можно заменить на HTTP-запрос, TCP-подключение или другой подходящий тест.

Работа с Net-SNMP в Windows

Подготовка утилит

Скачать утилиты можно со страницы проекта на SourceForge: https://sourceforge.net/projects/net-snmp/files/net-snmp%20binaries/5.7-binaries.

Примеры предполагают, что snmpget.exe, snmpset.exe, snmpwalk.exe и snmptrapd.exe доступны через переменную PATH или запускаются непосредственно из каталога Net-SNMP.

Доступность готовой сборки и ее совместимость с конкретной версией Windows необходимо проверить отдельно.

Отправка GET-запроса

Получить время работы NetPing IO v5:


snmpget.exe -v1 -c SWITCH 192.168.0.100 .1.3.6.1.2.1.1.3.0

Получить только значение:


snmpget.exe -v1 -c SWITCH -Oqv 192.168.0.100 .1.3.6.1.2.1.1.3.0

Прочитать состояние OUT1:


snmpget.exe -v1 -c SWITCH -Oqv 192.168.0.100 .1.3.6.1.4.1.25728.8920.1.1.3.1

Отправка SET-запроса

Установить логическую единицу на OUT1:


snmpset.exe -v1 -c SWITCH 192.168.0.100 .1.3.6.1.4.1.25728.8920.1.1.3.1 i 1

Установить логический ноль:


snmpset.exe -v1 -c SWITCH 192.168.0.100 .1.3.6.1.4.1.25728.8920.1.1.3.1 i 0

Отправка WALK-запроса

Обойти корпоративную ветвь OID NetPing:


snmpwalk.exe -v1 -c SWITCH 192.168.0.100 .1.3.6.1.4.1.25728

Получить ветвь параметров Output-линий NetPing IO v5:


snmpwalk.exe -v1 -c SWITCH 192.168.0.100 .1.3.6.1.4.1.25728.8920

Прием SNMP TRAP в Windows

Создайте конфигурационный файл, например:


C:/Net-SNMP/etc/snmp/snmptrapd.conf

Если для отправки TRAP используется community public, добавьте строку:


authCommunity log public

Запустите PowerShell или командную строку с правами администратора:


snmptrapd.exe -f -Lo -c "C:/Net-SNMP/etc/snmp/snmptrapd.conf" udp:162

После настройки устройства на отправку TRAP на адрес Windows-компьютера можно инициировать изменение состояния входа, выхода или термодатчика и проконтролировать появление сообщения в окне snmptrapd.exe.

Если UDP/162 уже занят службой Microsoft SNMP Trap или другой программой, snmptrapd.exe не сможет открыть порт.

Проверить использование порта:


Get-NetUDPEndpoint -LocalPort 162

Если выбранная сборка Net-SNMP поддерживает регистрацию службы:


snmptrapd.exe -register -c "C:/Net-SNMP/etc/snmp/snmptrapd.conf" udp:162

Поддержку параметра -register и работу службы необходимо проверять в конкретной сборке Net-SNMP и версии Windows.

Внешний сетевой сторож в Windows

PowerShell-скрипт реализует ту же логику, что и Bash-вариант: проверяет доступность адреса, после нескольких ошибок отправляет аварийную команду, а после восстановления — команду возврата.


$TargetHost = "192.168.0.1"
$NetPingHost = "192.168.0.100"
$Community = "SWITCH"
$OutputOid = ".1.3.6.1.4.1.25728.8920.1.1.3.1"

$FailState = 1
$RecoveryState = 0
$PollInterval = 10
$FailThreshold = 3
$RecoveryThreshold = 2

$FailCount = 0
$RecoveryCount = 0
$FailureActive = $false

function Set-NetPingOutput {
    param([ValidateSet(0, 1)][int]$State)
    & snmpset.exe -v1 -c $Community -t 2 -r 1 $NetPingHost $OutputOid i $State | Out-Null
    return ($LASTEXITCODE -eq 0)
}

while ($true) {
    $IsAvailable = Test-Connection -ComputerName $TargetHost -Count 1 -Quiet -ErrorAction SilentlyContinue

    if ($IsAvailable) {
        $FailCount = 0
        $RecoveryCount++

        if ($FailureActive -and $RecoveryCount -ge $RecoveryThreshold) {
            if (Set-NetPingOutput -State $RecoveryState) {
                $FailureActive = $false
                Write-Host "$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') Связь восстановлена, отправлен SET OUT1=$RecoveryState"
            }
            $RecoveryCount = $RecoveryThreshold
        }
    }
    else {
        $RecoveryCount = 0
        $FailCount++

        if (-not $FailureActive -and $FailCount -ge $FailThreshold) {
            if (Set-NetPingOutput -State $FailState) {
                $FailureActive = $true
                Write-Host "$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') Узел недоступен, отправлен SET OUT1=$FailState"
            }
            $FailCount = $FailThreshold
        }
    }

    Start-Sleep -Seconds $PollInterval
}

snmpset.exe должен быть доступен через PATH. При необходимости в функции следует указать полный путь к исполняемому файлу.

Для контроля прикладного сервиса Test-Connection можно заменить на Test-NetConnection, Invoke-WebRequest или другой подходящий тест.

Ограничения автоматического управления

Оба скрипта являются демонстрационными примерами. Они отправляют SNMP SET, но не проверяют фактическое состояние Output-линии отдельным GET-запросом.

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

Если snmpset или snmpset.exe завершается с ошибкой, внутреннее состояние не изменяется и попытка отправить команду повторяется в следующем цикле проверки.

Перед использованием необходимо проверить номер выхода, значения FAIL_STATE и RECOVERY_STATE, доступность UDP/161 и реакцию подключенного исполнительного устройства.

Компьютер со скриптом должен сохранять доступ к NetPing IO v5 при отказе контролируемого узла. Если один сетевой сбой делает недоступными и целевой адрес, и контроллер, команда SET не будет доставлена.

Community хранится в скриптах в открытом виде. Файлы следует защитить правами доступа и не размещать в публичных репозиториях.

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

Скрипты необходимо проверить на стенде до применения в рабочей инфраструктуре.

Диагностика типовых ошибок

Если запрос завершается по тайм-ауту, необходимо проверить IP-адрес устройства, маршрутизацию, доступность UDP/161, community и выбранную версию SNMP.

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

Для управления Output-линией используется тип i, поскольку объект имеет тип Integer.

При проблемах с приемом TRAP следует проверить UDP/162, community и отсутствие другого процесса, уже использующего порт.

Заключение

Net-SNMP позволяет управлять устройствами NetPing и получать их параметры из командной строки в Linux и Windows. С помощью snmpget, snmpset и snmpwalk можно читать отдельные параметры, изменять доступные для записи значения и просматривать ветви OID.

snmptrapd позволяет принимать настраиваемые уведомления устройства без постоянного опроса OID.

Внешние Bash- и PowerShell-скрипты позволяют выйти за рамки встроенной логики устройства, интегрируя его со сторонними сервисами для реализации сложных сценариев автоматизации, сбора телеметрии и централизованного управления парком оборудования.