IPsec и SNMP проблема мониторинга

[alexdek]

Приветствую!
Ищу совета/помощи на просторах микротик-интернета.
Тема:
Микротик heX refresh.
С белым адресом наружу.
Работает как доступ в Интернет и IPsec VPN Site-to-Site.
Осуществляется мониторинг Микротика по SNMP и среди прочих параметров (температура, процессор ...) считываются и параметры vpn-а - время поднятия, "скорость" передачи и "скорость" приема - по сути эти параметры можно увидеть как Rx Bytes и Tx Bytes в Active Peers.
Количество принятых/переданный байт я впоследствии пересчитываю в скорость Rx MBps и Тx MBps.
Референсно используется mib скачанный с сайта Микротика.
В качестве проверочного "прибора" - OiDVieW.
Соответственно :
Время поднятия vpn: mtxrIkeSAUptime oid: 1.3.6.1.4.1.14988.1.1.20.2.1.8.1
Передано Байт: mtxrIkeSATxBytes oid: 1.3.6.1.4.1.14988.1.1.20.2.1.20.1
Принято Байт: mtxrIkeSARxBytes oid: 1.3.6.1.4.1.14988.1.1.20.2.1.21.1

Все работало отлично до момента когда vpn не решил поменять SA и после появления в логе сообщений:
killing ike2 SA: xxxxx-peer XXX.XXX.XXX.XXX[4500]-XXX.XXX.XXX.XXX[4500] dfjkghdfkj...
new ike2 SA (I): xxxxx-peer .....
peer authorized: xxxxx-peer ....
Контроль именно параметров vpn перестал работать.
Все остальные параметры считываются без проблем.
"Расследование" показало, что изменился "адрес" oid-ов - вместо "1" в конце стоит теперь "2".
(Практически для всей ветви mtxrIkeSATable.)
А этот адрес - это параметр mtxrIkeSAIndex.
И вот тут для меня "серая" область
Может ли кто помочь/объяснить или рассказать, что за процесс происходит (почему смена индекса oid) и что делать (что делают более опытные) в такой ситуации.
Спасибо!

[Chupaka]

Уже, видимо, неактуально, но всё же оставлю тут: https://www.zabbix.com/documentation/5. ... namicindex

Индекс - это просто какой-то счётчик. Этих SA у Ike может быть несколько одновременно, каждая со своим индексом; при разрыве SA поднимается новая SA - у неё тоже новый индекс, чтобы не мешать всё в кучу. Поэтому надо, например, по mtxrIkeSAPeerAddress определить индекс нужной сессии - и потом у этого индекса читать уже все нужные параметры.

[alexdek]

@Chupaka, спасибо за участие!
К сожалению сам(и) индекс(ы)-счетчик(и) не являются отдельным oid-ом и их нельзя просто считать и далее использовать для формирования правильных oid для нужных параметров контроля. Ну если быть совсем корректным индекс "mtxrIkeSAIndex" есть как oid... но со статусом "NOT-ACCESSIBLE", что впрочем не отличается, в данном случае, от его отсутствия
Так что здесь пока только один выход - повторить методику считывания всей таблицы и далее в ней уже по известному признаку, скажем mtxrIkeSAPeerAddress, "парсить" последнее число - т.е. "нужный индекс".
По сути это то, о чем пишет Zabbix по указанной Вами ссылке.
Совершенно непонятно "ЗАЧЕМ???" так сделано... наверное исторический рудимент от самого Zabbix-a.
Желание учесть все SA и текущие-работающие и уже мертвые - смысла не имеет, тем более, если уж так надо, это можно сделать более красиво и прогнозируемо.
Остался вопрос - А как быть если несколько VPN... , будет несколько таблиц mtxrIkeSATable или всё в одной таблице с разными индексами или вообще что-то другое.
Так что пока непонятно как "ЭТО" работает - будем копать дальше.
Без понимания процесса получится скорее "костыль", а не техническое решение.
Списался по теме с Support Mikrotik, жду ответа.

[Chupaka]

Остался вопрос - А как быть если несколько VPN... , будет несколько таблиц mtxrIkeSATable или всё в одной таблице с разными индексами или вообще что-то другое.

Как я и упоминал, будет несколько индексов. Это не какая-то особенность Zabbix, это такая архитектура SNMP.

Т.е., например,

# mtxrIkeSAUptime
1.3.6.1.4.1.14988.1.1.20.2.1.8.1 = 18 часов
1.3.6.1.4.1.14988.1.1.20.2.1.8.2 = 2 часа
...
# mtxrIkeSATxBytes
1.3.6.1.4.1.14988.1.1.20.2.1.20.1 = 12345
1.3.6.1.4.1.14988.1.1.20.2.1.20.2 = 45678

Именно поэтому сначала делают walk по, например, mtxrIkeSAPeerAddress, где будет:
mtxrIkeSAPeerAddress.1 = 192.168.1.2
mtxrIkeSAPeerAddress.2 = 100.86.3.4

И отсюда уже извлекают нужный индекс

[alexdek]

Это все совершенно прозрачно и понятно.
Естественно такой подход усложняет/удорожает получение достоверных данных, но ... это опять к разработчику .

К сожалению нет документации по реализованному принципу работы Mikrotik-SNMP индексирования mtxrIkeSAIndex и следовательно каждое/любое считывание параметров из mtxrIkeSATable должно сопровождаться walk, парсингом и созданием синтетического oid-a.
Это конечно рабочее решение, но оно имеет существенные ограничения при росте масштабов использования.

При этом причина смены индекса (при каждой попытке создания SA и даже неудачной) совершенно не очевидна и никто не может этого объяснить. Может разработчики могут... но они молчат.
(после экспериментов и прочее я сейчас имею единственную vpn с mtxrIkeSAIndex = 52. ... и что это значит или что мне это дает ???)

В итоге имеем то, что имеем и будем с этим работать.

[Chupaka]

Если вас интересует конкретная цифра, я подозреваю, что если выполнить ":put [/ip/ipsec/active-peers/find]" в Терминале - вы этот id и увидите.

[alexdek]

Это конечно можно делать.
Как впрочем и через " :put [/ip/ipsec/active-peers get ([find]->0) rx-bytes] " получить количество принятых rx-bytes или переданных tx-bytes...
и даже не искать индекс пока peer один
В общем, думаю в сторону API (Python) сейчас...

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