Анонс арендованных IP со своей ASN: LOA, объекты route в IRR, ROA и проверка распространения BGP
Арендовали у IMIDC блок IPv4 или IPv6 и хотите анонсировать его по BGP со своей ASN в собственном дата-центре или у другого провайдера? Для этого обычно нужны три вещи: LOA (письмо-авторизация) от держателя адресов, объекты route / route6 в IRR и ROA в RPKI. В статье разбираем весь процесс: что такое LOA, какие данные предоставить, как связаны IRR и ROA, как фильтруют аплинки и как проверить распространение через bgp.tools, bgp.he.net и RIPEstat. Материал для операторов, у которых уже есть ASN и BGP-сессия с аплинком.
Шаг 1: Зачем нужна LOA для анонса BGP
LOA (Letter of Authorization) — подписанное письмо держателя адресов о том, что ASxxx вправе анонсировать указанный префикс. Большинство транзитных операторов и IX перед приёмом клиентских префиксов проверяют, кому принадлежат адреса и есть ли у вас право их анонсировать. Одной LOA сегодня мало: аплинки также автоматически сверяются с IRR и RPKI, поэтому LOA, route-объект и ROA должны совпадать.
Шаг 2: Какие данные предоставить IMIDC для получения LOA
Запросите LOA через тикет и приложите следующие сведения. Чем они полнее, тем быстрее обработка:
Prefix(es): 203.0.113.0/24 2001:db8:1000::/48
Origin ASN: AS64500
Company / holder: Example Networks Ltd
Upstream(s): AS64510 (Transit Provider A), AS64520 (IX route server)
Announce from: 2026-10-10
IRR source: RIPE / RADB
Technical contact: [email protected]- Префикс: в глобальной таблице обычно принимаются IPv4 не длиннее /24 и IPv6 не длиннее /48; более специфичные, скорее всего, отфильтруют.
- Origin ASN: ASN, с которой вы будете анонсировать, и её юридический владелец.
- Аплинк: название и ASN транзитного провайдера; некоторые требуют указать их в LOA.
- Дата начала: когда планируете анонс, чтобы вовремя обновить IRR и ROA.
Шаг 3: Создание route-объектов в IRR (RIPE DB / RADB)
IRR (Internet Routing Registry) — базы маршрутной информации, по которым многие аплинки автоматически строят префикс-фильтры. Для адресов региона RIPE route-объект создаётся в базе RIPE и требует авторизации держателя адресов, поэтому обычно его создаёт или подтверждает IMIDC; для адресов вне RIPE часто используют RADB. Синтаксис — в статье «Создание route-объектов в IRR». Проверка через whois:
# install whois: Debian/Ubuntu
apt install -y whois
# CentOS/Rocky/AlmaLinux
dnf install -y whois
# route object in the RIPE database
whois -h whois.ripe.net -T route 203.0.113.0/24
whois -h whois.ripe.net -T route6 2001:db8:1000::/48
# route object mirrored / registered in RADB
whois -h whois.radb.net 203.0.113.0/24Убедитесь, что в поле origin указана ваша ASN.
Шаг 4: ROA, чтобы не получить RPKI Invalid
Всё больше сетей отбрасывают маршруты со статусом RPKI Invalid. Если для блока уже есть ROA на другую ASN, ваш анонс будет Invalid. Попросите в тикете выпустить ROA на вашу ASN с maxLength, покрывающим анонсируемую длину. Проверить статус можно через RIPEstat:
# RPKI status of origin AS64500 for the prefix (RIPEstat API)
curl -s "https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64500&prefix=203.0.113.0/24" | python3 -m json.tool | grep -E '"status"|"validating_roas"' -A2Нужен статус valid; unknown означает отсутствие ROA (большинство сетей такой маршрут примут); invalid нужно исправить до анонса.
Шаг 5: Обновление фильтров у аплинка и анонс префикса
Аплинки обычно строят префикс-листы из IRR по вашей ASN или as-set. Одни обновляют их ежедневно, другим нужно написать тикет с приложенной LOA. После подтверждения анонсируйте префикс со своего маршрутизатора. Пример для BIRD 2:
# BIRD 2 example (see the "BGP session" guide for the full config)
protocol static announce_v4 {
ipv4;
route 203.0.113.0/24 blackhole;
}
filter export_upstream {
if net = 203.0.113.0/24 then accept;
reject;
}
# reload and check
birdc configure
birdc show route export upstream_v4Шаг 6: Проверка распространения через bgp.tools, bgp.he.net и RIPEstat
После анонса префикс обычно появляется в глобальной таблице за несколько минут. Найдите его на bgp.tools или bgp.he.net — там видны origin ASN, пути через аплинки и статус RPKI; Routing Status в RIPEstat (stat.ripe.net) показывает, сколько коллекторов RIS видят маршрут. Из командной строки:
# who sees the prefix and with which origin (RIPEstat)
curl -s "https://stat.ripe.net/data/routing-status/data.json?resource=203.0.113.0/24" | python3 -m json.tool | head -40
# how many RIS peers see it
curl -s "https://stat.ripe.net/data/visibility/data.json?resource=203.0.113.0/24" | python3 -m json.tool | grep -E '"ris_peers_seeing"|"total_ris_peers"'
# from your router: is the session up and the route exported?
birdc show protocols
# test reachability of an address in the prefix from outside
mtr -rwc 20 203.0.113.1Типичные сроки: после предоставления полных данных подготовка LOA и IRR/ROA обычно занимает несколько рабочих дней (зависит от полноты данных и проверки); обновление фильтров у аплинка — от нескольких часов до нескольких дней в зависимости от автоматизации; само распространение маршрута — минуты; некоторые базы геолокации обновляются дольше (см. статью «Geofeed»).
Частые вопросы
Мой префикс не виден на bgp.tools
Проверьте, что сессия в состоянии Established, маршрутизатор действительно экспортирует префикс, аплинк обновил фильтры (посмотрите в его looking glass) и статус RPKI не invalid.
Можно ли анонсировать части меньше /24?
Префиксы IPv4 длиннее /24 повсеместно фильтруются, поэтому нет. Делите /24 на подсети внутри своей сети, а наружу анонсируйте целый /24.
Нужна ли новая LOA при смене аплинка или ASN?
При смене ASN нужны новая LOA и обновлённые route-объект и ROA. При смене только аплинка обычно достаточно, чтобы новый аплинк обновил фильтры, хотя некоторые просят свежую LOA.
Если проблема не решена, создайте тикет в круглосуточную техподдержку IMIDC: https://www.imidc.com/submitticket.php