Кратко

  • В отчёте от 13 октября LACNIC рекомендует получать полную таблицу BGP по оптоволокну, а через LEO принимать только маршрут по умолчанию, чтобы спутник подхватил трафик при отказе оптического пути.
  • Само правило не обнаруживает обрыв кабеля. LACNIC сообщает об учениях, но не называет внедрение у оператора, время снятия маршрута, проверку ёмкости или результат восстановления.

Рекомендация после встречи

CaribNOG 32 прошла в Виллемстаде, Кюрасао, с 7 по 9 октября. В публикации от 13 октября LACNIC сообщает, что Alejandro Acosta и Nicolás Antoniello провели техническую сессию после вступления Mark Kosters, технического директора ARIN. Рекомендации связаны с уязвимостью подводных кабелей и другими рисками региона. Это рассказ самой LACNIC о встрече, а не независимое исследование сетей островов.

Предложение конкретно: подключаться хотя бы к одному подводному оптическому маршруту, лучше к нескольким; принимать полную таблицу BGP по оптоволокну; а через спутник на низкой орбите — только маршрут по умолчанию. Спутник должен передавать трафик при отказе оптического пути. LACNIC предупреждает, что одного канала LEO может не хватить многим провайдерам, но не публикует ёмкость, профиль нагрузки или испытание.

Не описано условие снятия маршрутов

Маршрут по умолчанию используется для адресов без более конкретной записи. Он не обнаруживает отказ. Для направлений с точными оптическими маршрутами трафик обычно продолжает идти по ним; переход на спутник возможен, когда эти записи сняты или изменена политика. Если устаревший маршрут остаётся после отказа, резерв может не включиться, а пакеты продолжат идти в неработающий путь.

Поэтому важны сигнал и правило снятия маршрута. Достаточно ли обрыва интерфейса? Оператор ждёт разрыва BGP-сессии, использует BFD или активную проверку сервиса? Как избежать повторных переключений при нестабильной линии? Публикация описывает желаемую схему, но не даёт параметров и не сообщает об испытании в действующей сети.

У средств защиты разные границы

В публикации упоминаются проверка происхождения маршрута через RPKI, защита от утечек BGP и BFD. RFC 6811 проверяет, уполномочена ли исходная AS объявлять префикс; она не подтверждает весь путь AS_PATH. RFC 9234 опирается на согласованные роли соседей eBGP, маркировку маршрутов и политику оператора. Стандарты сами по себе не доказывают доступность или внедрение настройки.

По словам LACNIC, BFD может сократить обнаружение отказа примерно с 90 секунд до миллисекунд. RFC 5880 связывает время с согласованными интервалами передачи и множителем обнаружения; таймеры в отчёте не указаны. Для IPv6 Path MTU Discovery должны проходить сообщения ICMPv6, как объясняет RFC 8201. Упомянутые упражнения по DNSSEC и RPKI подтверждают обучение, а не производственное внедрение.

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

Источники: отчёт LACNIC после встречи; программа CaribNOG 32; RFC 6811; RFC 9234; RFC 5880; RFC 8201.