Кратко

  • Слайды LACNIC 46 сопоставляют 14-секундный обрыв канала с примерно 90 минутами до нахождения причины: 23 минуты до первой жалобы и ещё 67 минут ручной диагностики.
  • Авторы предлагают собирать syslog, данные RouterOS v7, сессии RADIUS и топологию внутри ISP, а затем искать по ним через локальную модель с доступом к SQL только для чтения.

Канал уже восстановился, а инженер ещё даже не открыл нужный журнал. Так устроен временной разрыв, который показали Joaquín Tadeo Riedmaier и Santiago Agustín Zualet на LACNIC 46 · LACNOG 2026 в Мендосе. В их сценарии связь пропадает на 14 секунд, первая жалоба поступает через 23 минуты, а ручной поиск причины занимает ещё 67. Всего — около 90 минут.

Авторы из инженерного факультета Национального университета Мисьонес называют эту последовательность типичной оценкой для критического события и отмечают, что время на схеме иллюстративное. Доклад прозвучал на заседании Internet Measurement Working Group (IMWG). Его замысел — связать данные до того, как специалист начнёт обходить оборудование по очереди.

Предусмотрены два канала сбора. UDP syslog отправляет смену состояния линка, ошибки, нестабильность интерфейсов и отключения PPPoE/RADIUS. REST API RouterOS v7 выдаёт трафик, ошибки и отбрасывания по интерфейсам и VLAN, загрузку CPU и памяти, ARP и connection tracking. RADIUS добавляет состояние сессий по NAS. Связав их с топологией, можно сопоставить сбой интерфейса с подключениями, которые могли оборваться вместе с ним.

Вся схема размещается на Docker-узле внутри сети ISP. Django принимает syslog и обращается к API; Python убирает шум, приводит события к общей форме, удаляет дубликаты и проверяет пороговые значения; PostgreSQL хранит подготовленные для поиска представления. Затем локальная языковая модель формирует SQL-запрос. Плоские представления должны уменьшить число соединений таблиц, а учётная запись модели разрешает только SELECT. Слайды упоминают проверку модели на устройстве с 32 ГБ оперативной памяти, но не называют модель, нагрузку или время ответа.

Один пример предлагает спросить, какие маршрутизаторы фиксировали обрывы за последние четыре часа. Ответ говорит о семи событиях на ether2 устройства NAS 6 и 23 затронутых сессиях PPPoE. Авторы помечают его как иллюстрацию. Другая схема сводит ошибки L2/L3, connection tracking, RADIUS и PPPoE в одну минуту — 12:04 — и предполагает физическую неисправность. Там прямо сказано, что данные смоделированы, а корреляция не является измеренным результатом.

В предложении разделены предупреждение и расследование. Пороговый сигнал должен прийти раньше жалобы; панель и запрос на обычном языке помогают разобраться после события. Модель даёт доступ к уже собранным данным, но не заменяет их. Если syslog не сохранил момент обрыва, интервал опроса API перескочил через 14 секунд или часы устройств расходятся, связный ответ не восстановит потерянную последовательность.

В презентации 90 минут названы оценкой, а 18 минут — ожидаемым эффектом, но не приведены набор реальных инцидентов ISP, частота опроса API, замеры до и после, доля ложных тревог или методика для цели ≥95%; журнал пилота с этими показателями по каждому событию изменил бы оценку.

Сильная сторона доклада — не обещание чат-интерфейса, а точное место потери времени: оператор вручную связывает события маршрутизатора с сессиями и топологией, когда жалоба уже пришла. Следующий шаг должен оставить воспроизводимый след от события до подтверждённой причины. Тогда станет ясно, заметила ли система короткий обрыв заранее и вернула ли инженеру время, или просто переложила поиск в новое окно.

Источники: официальная программа LACNIC 46; исходная презентация IMWG.