Кратко

  • Lighthouse у InterLAN IX задуман как портал для запросов участников: изменение может затронуть несколько маршрутизаторов, но для каждого предусмотрены предварительная конфигурация, таймер отката и отдельное подтверждение. При недоказанной безопасности восстановления управление возвращается человеку.
  • База данных хранит утверждённое намерение, ручные правки устройств видны как отклонения, а ИИ-помощник умеет читать и составлять отчёты, но не менять конфигурацию. Удобная кнопка не передаёт участнику власть над общей сетью.

Один запрос не равен одному устройству

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

Аннотация выступления InterLAN IX на RIPE 93 описывает Lighthouse как попытку управлять именно таким промежутком. Андрею Дину предстоит рассказать о платформе на маршрутизаторах Nokia SR OS и коммутаторах Arista EOS. Для каждого затронутого маршрутизатора предусмотрены предварительный просмотр конфигурации, свой таймер отката и отдельное подтверждение. Если безопасное восстановление нельзя доказать, дело принимает человек. На странице встречи пока нет стенограммы, слайдов или записи; нет и статистики внедрения, сбоев и успешных откатов. Публичный материал позволяет разобрать схему полномочий, а не объявить её проверенным результатом.

Сайт InterLAN перечисляет публичный пиринг через два route server, частные VLAN и резервные порты. Это общая инфраструктура для многих участников. Список конкретных изменений, доступных через Lighthouse, не опубликован. Зато ясна точка конфликта: участник заказывает действие ради своей связи, оператор отвечает за состояние ткани обмена в целом. Быстрый заказ не превращает частично обновлённую сеть в согласованную.

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

Главный документ лежит не в маршрутизаторе

Самая важная строка аннотации касается базы данных: она определяет желаемое состояние. Изменение, внесённое инженером прямо в устройство, показывается как расхождение и не присваивается незаметно в качестве нового правила. Это спасает от превращения ночного временного обхода в постоянную политику. Фактическое состояние и санкционированная цель должны оставаться разными записями, иначе выяснить причину отклонения уже не получится.

В Note 73 Лу Хэн спрашивает, когда участие начинают выдавать за мандат. В сетевой эксплуатации вопрос звучит проще: кто получает власть вместе с кнопкой? Участник подаёт запрос. Оператор утверждает состояние общих устройств. Инженер вправе вмешаться в чрезвычайной ситуации. База данных должна сохранять, какое решение стало длительным обязательством сети. Портал без такого разграничения похож на приёмную, в которой посетителям незаметно выдали ключи от серверной.

По аннотации, цифровой двойник из снимков производственной сети позволяет репетировать изменения. Его полезность определяется временем снимка, полнотой модели и тем, как результат репетиции влияет на разрешение. Публичного примера всей цепочки нет. Для оценки хватило бы одного дела: запрос, различия конфигурации по устройствам, снимок, репетиция, согласование, подтверждения и журнал отката. Красивую анимацию можно приложить в конце.

У ИИ, напротив, скромная роль. Страница доклада обещает инструменты только для чтения: отчёты и планы миграции без записи конфигурации. Убедительно написанный план не получает исполнительных прав. FAQ InterLAN проводит ещё одну границу: сеансы BGP с серверами маршрутов добровольны, каждый участник определяет свою политику пиринга. Оператор управляет общим оборудованием, а участники — собственными отношениями обмена. В документации RIPE RIS коллектор RRC22 указан в InterLAN-IX, Бухарест. Внешнее наблюдение маршрутов поможет заметить последствия; имя того, кто санкционировал конфигурацию, ищут во внутреннем журнале Lighthouse.