BYOIP означает, что клиент использует собственный или законно предоставленный ему префикс в инфраструктуре оператора. Но за этой короткой формулировкой скрываются разные модели: анонс из ASN оператора, анонс из ASN клиента через eBGP или маршрутизация сети без отдельной клиентской сессии.
До оплаты определите модель и путь запуска. Иначе оборудование уже будет тарифицироваться, а фильтры, LOA или ROA ещё останутся в переписке между несколькими сторонами.
Выберите модель анонса
В первой модели оператор анонсирует префикс из своего ASN и маршрутизирует его клиенту. Во второй клиент поднимает BGP-сессию и становится origin. Возможны гибридные схемы, но origin ASN в глобальной таблице всё равно должен быть заранее известен.
От модели зависят документы, RPKI, фильтры, оборудование и зона ответственности. Запишите origin ASN и next hop прямо в техническом приложении.
ДальшеРазделите обязанности сторон→Разделите обязанности сторон
Держатель адресов обычно отвечает за законное право использования, LOA и ROA. Владелец ASN — за разрешённый origin и данные для фильтров. Оператор площадки — за порт, BGP-параметры, свои фильтры и передачу анонса upstream-провайдерам.
Если участвует посредник, всё равно нужен один ответственный за координацию. Клиент не должен самостоятельно выяснять, на чьей стороне неделями лежит заявка.
- кто создаёт и меняет ROA;
- кто создаёт route object и в какой IRR;
- кто проверяет LOA и право использования;
- кто настраивает сессию и upstream-фильтры;
- кто отвечает клиенту при недоступности маршрута.
Согласуйте параметры BGP до поставки
Нужны адреса соседей, ASN сторон, тип сессии, VLAN, пароль при его использовании, max-prefix и набор принимаемых/отдаваемых маршрутов. Отдельно уточните communities, blackhole, default route, BFD и допустимые длины префиксов.
Не все функции входят в базовую BGP-услугу. Их наличие и стоимость должны быть подтверждены до оплаты, особенно если проект зависит от удалённого blackhole или управления маршрутами через communities.
ДальшеПроверьте реальное резервирование→Проверьте реальное резервирование
Две BGP-сессии не гарантируют два независимых пути. Они могут сходиться в один коммутатор, маршрутизатор или upstream. Спросите, различаются ли порты, сетевые устройства, линии и внешние операторы.
Согласуйте поведение при отказе: кто переключает трафик, какие таймеры используются, нужен ли BFD и как проверяется возврат основного пути. Резервирование считается готовым только после контролируемого теста.
ДальшеВыясните, как работает DDoS для BYOIP→Выясните, как работает DDoS для BYOIP
Защита адресов оператора не всегда автоматически распространяется на клиентский префикс. Нужны поддерживаемый размер сети, способ детектирования, допустимая полоса атаки, методы очистки и правила blackhole.
Уточните, сохраняется ли origin во время очистки, меняется ли маршрут, требуется ли отдельный GRE-туннель и какие протоколы или порты ограничиваются. Без этого слово «DDoS-защита» слишком неопределённо.
ДальшеОпределите готовность и срок запуска→Определите готовность и срок запуска
BGP готов, когда сессия установлена, согласованные префиксы принимаются, анонс виден из внешних сетей, RPKI имеет ожидаемый статус и трафик проходит в обе стороны. Письмо «настройки применены» не заменяет эти проверки.
В предложении укажите срок первичного запуска и срок исправления фильтров или маршрута. Если BYOIP обязателен для проекта, начало биллинга сервера логично связывать с готовностью сети — но это условие должно быть согласовано отдельно.
- обе стороны видят состояние Established;
- префикс принимается без ошибок max-prefix и фильтров;
- анонс виден через независимые looking glass;
- ROA даёт ожидаемый результат origin validation;
- входящий, исходящий и резервный маршруты протестированы.