Приветствую! Тема: Микротик 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) и что делать в такой ситуации. Спасибо!
@fAntom - Спасибо за участие! Но в указанной теме форума обсуждают сам список oid-ов. Эта вся информация у меня есть, а проблема состоит в том, что при каждом прерывании vpn или, правильнее сказать, при каждой попытке договориться о "proposal" (физика есть, но vpn не поднят, по сути phase-1) происходит увеличение индекса "mtxrIkeSAIndex" на единицу, а так как он (индекс) входит в "адрес" oid-а (последний разряд) становится невозможным прямое считывание значений oid-в во всей ветке IPsec - mtxrIPSec,1.3.6.1.4.1.14988.1.1.20.2.1.yy.хx . То есть необходима предварительная обработка по подстановке текущего индекса в последний разряд (хх) нужного oid-a. И вот тут засада - сам индекс "mtxrIkeSAIndex" нигде не указан в виде определенного oid. Можно конечно считать всю таблицу mtxrIPSec (20) - 23 строки, "отпарсить" ее на известное значение, выделить последний разряд, далее сформировать правильные oid-ы для IPsec Rx и Tx и будет тогда счастье.... Но это очень уж "костыльно" :-(( и не люблю я делать, когда не понимаю самого принципа - "Почему ОНО так работает?", это всегда чревато ошибками и сюрпризами... Так что пока ищу ответ - почему оно так работает? Списался с Support Mikrotik, отправил им все, что просили....может помогут и расскажут как достигнуть цели - надежно и без "костылей" автоматизировано мониторить скорость данных в IPsec.
UpDate: 10/05/2025 И так, что касается возможности мониторинга IPsec по SNMP и изменяющегося (динамического) индекса mtxrIkeSAIndex таблицы mtxrIkeSATable, где собственно и содержатся все показатели (oid) IPsec: 1. Динамический индекс - это решение разработчиков. Почему именно так и что это дает - вопросы на которые я не получил ответа. Хотя по мне само решение весьма сомнительное... Но это решение разработчиков и у них, наверно, были причины делать так. 2. Так что если есть желание/необходимость мониторить IPsec по SNMP остается стандартная технология считывать через walk "ключевой" набор oid-ов или всю таблицу, затем парсить результат считывания на нужный параметр и его значение или находить текущий индекс mtxrIkeSAIndex и делать "синтетические" oid-ы на те параметры, которые нужны. (и для достоверности повторять это каждый раз перед считыванием нужного/ых параметра/ов.) :-( 3. Данные по IPsec active peer и пр. конечно можно получить через CLI или API, но это уже другая тема. .
