ASPA может затронуть владельца сети, даже если он не менял BGP-конфигурацию: ошибка в опубликованной записи способна повлиять на оценку маршрутов, проходящих через его ASN. Проблему обычно замечают не по недоступности сайта как таковой, а по предупреждениям при проверке BGP-путей или по риску, что система валидации сочтёт маршрут недействительным. Это важно для операторов, которые публикуют ASPA или собираются учитывать такие записи при фильтрации маршрутов.
ASPA — подписанный объект RPKI, в котором владелец ASN указывает разрешённые AS-провайдеры. Эти сведения помогают проверять последовательность AS в BGP-пути и выявлять утечки маршрутов или поддельные пути. Но запись должна соответствовать реальной передаче трафика: пограничные случаи возникают при резервном или частичном транзите, сложном пиринге и подключении через IXP. Ошибка здесь не сводится к формальности — неверный список способен привести к отклонению легитимных маршрутов.
Почему вопрос стал практическим
Поддержка управления ASPA в APNIC появилась в июне 2026 года, и число опубликованных объектов растёт. Чем больше сетей создают записи и включают валидацию BGP-путей, тем важнее согласовать данные RPKI с фактическими отношениями между AS. APNIC посвятил этим вопросам отдельный разбор после вебинара для участников и интернет-сообщества: материал APNIC об ASPA.
В статье разберём, как определить провайдера для ASPA, почему схема IXP меняет состав списка и чем опасна ошибочная запись. Это поможет понять, какие сведения о маршрутизации нужно проверить до публикации ASPA и на что обратить внимание перед включением валидации.
Что ASPA проверяет в BGP-пути
Разрешённые переходы между автономными системами
ASPA — подписанный объект RPKI, который связывает ASN владельца с ASN его разрешённых провайдеров. Проверка сопоставляет эти сведения с AS_PATH в BGP-маршруте: она оценивает, согласуются ли соседние AS в пути с заявленными отношениями провайдер—клиент. Это не проверка доступности сайта и не подтверждение того, что маршрут оптимален. ASPA даёт валидатору основание выявить путь, в котором переход между сетями не подтверждается опубликованными разрешениями.
Как обнаруживаются утечки и поддельные пути
При утечке маршрута сеть может распространить дальше маршрут, полученный от клиента, хотя не должна выступать для него транзитным провайдером. Поддельный путь, в свою очередь, может содержать ASN, отношения с которым не подтверждаются ASPA. Если проверка обнаруживает несоответствие, маршрут можно классифицировать как недействительный; это сигнал о возможной ошибке или нарушении, а не доказательство злого умысла.
Результат зависит от полноты и точности опубликованных объектов. Если владелец не указал реального провайдера, корректный маршрут тоже может не пройти проверку. Поэтому ASPA описывает разрешённые отношения, а не автоматически устанавливает, кто виноват в аномалии. В список включают AS, которая действительно передаёт маршруты между сетями; конкретный состав зависит от схемы транзита.
ASPA помогает проверять правдоподобие пути, но не заменяет другие механизмы безопасности маршрутизации. Она не подтверждает происхождение префикса сама по себе: для этого применяются ROA. Проверка AS-пути отвечает на другой вопрос — допустимы ли заявленные переходы между автономными системами.
Кого включать в список провайдеров
Критерий — передача маршрутов
В ASPA указывают не всех операторов, с которыми сеть обменивается трафиком, а AS, передающие её маршруты дальше. Провайдером здесь считается сеть, которая обеспечивает транзит между другими сетями. Важна функция в распространении маршрутов, а не название договора или тип соединения.
Транзит может быть частичным: провайдер передаёт маршруты только к некоторым сетям. Он может использоваться как резервный канал или быть доступен лишь в отдельных точках присутствия. Во всех этих случаях AS всё равно может выступать провайдером для вашей сети — если через неё ваши маршруты распространяются дальше.
Пиринг не всегда означает отсутствие транзита
Само слово «пиринг» не отвечает на вопрос, нужно ли включать AS в список. При прямом обмене маршрутами сети могут передавать трафик только друг другу, не предоставляя транзит третьим сторонам. Но отношения бывают сложнее: для одних префиксов сеть может предоставлять транзит, а для других сама пользоваться транзитом партнёра. RFC 9234 описывает такую схему как «complex» peering relationship; её разбор требует учитывать направление передачи маршрутов, а не только название отношений.
Практический вопрос для каждой AS — передаёт ли она ваши маршруты дальше и в каких условиях. Если ответ зависит от префикса, точки подключения или резервного сценария, это не основание автоматически исключать AS: нужно проверить, где именно она выполняет транзитную роль. Двусторонний случай, когда обе сети могут быть провайдером друг для друга, рассматривается отдельно.
Почему сложный пиринг может быть двусторонним
Роль AS зависит от префикса
В BGP отношения между сетями не всегда укладываются в схему, где одна AS только предоставляет транзит, а другая только его получает. RFC 9234 называет такую конфигурацию «complex» peering: две AS могут быть клиентом и провайдером друг для друга, но для разных префиксов.
Например, сеть A может передавать трафик сети B к одним направлениям, а сеть B — обеспечивать транзит для сети A к другим. Это не противоречие: роль определяется тем, кто передаёт маршрут и трафик для конкретного префикса, а не постоянным статусом всей AS. Поэтому нельзя свести отношения пары к одной метке «пиринг» и считать, что транзита между ними нет.
Как это отражается в ASPA
ASPA описывает разрешённых провайдеров для ASN владельца объекта. При двустороннем транзите каждой стороне нужно авторизовать другую: AS A включает AS B в список провайдеров, а AS B — AS A. Иначе проверка пути может не учесть одно из реальных направлений передачи маршрутов.
Практически важно сверять список не только с договорной формулировкой или общей схемой пиринга, но и с тем, как распространяются маршруты для разных префиксов. Если транзит предоставляется лишь для части направлений, это всё равно может создавать провайдерское отношение, которое следует отразить в ASPA. Сам факт прямого соединения между AS не отвечает на вопрос, кто кому передаёт маршруты: решает фактическая роль в распространении конкретных префиксов.
Прозрачный route server IXP не становится провайдером
ASN route server не попадает в AS path
В прозрачной схеме IXP route server работает на Layer 2: он помогает участникам обмениваться маршрутами, но не становится промежуточной автономной системой в пути. Когда участник получает маршрут от другого участника, в AS path остаются ASN этих сетей, а ASN route server не добавляется.
Для ASPA важен именно этот путь. Если ASN IXP в нём нет, участникам не нужно указывать IXP как провайдера: объект ASPA должен описывать реальные отношения между автономными системами, а не инфраструктуру, через которую переданы маршруты.
Пиринг участников сохраняет свою роль
Прозрачность route server не отменяет отношений между самими участниками. Если одна AS передаёт маршруты другой, их связь провайдер—клиент остаётся значимой для ASPA, даже когда обмен организован через IXP. Участники указывают соответствующие ASN друг друга согласно фактическому направлению передачи маршрутов. Сам route server в этот список не добавляют.
Здесь важно не смешивать посредничество в обмене маршрутами с транзитом на уровне AS path. IXP предоставляет площадку и механизм обмена, но в прозрачной схеме не появляется в пути как автономная система. Поэтому наличие подключения к route server само по себе не делает IXP провайдером участника.
Layer 2 ограничен одной коммутационной средой
Прозрачная схема подходит для обмена в пределах одной коммутационной фабрики. Если требуется связность через широкую территорию, Layer 2-дизайн может привести к широковещательным штормам, петлям Spanning Tree Protocol (STP) и проблемам масштабирования MAC-таблиц. Для таких задач применяют Layer 3 route server, обычно с IP или Multiprotocol Label Switching (MPLS); в этой схеме ASN сервера уже влияет на AS path.
Когда ASN IXP нужно добавить в ASPA
Layer 3 меняет путь
В прозрачной схеме Layer 2 route server не добавляет свой ASN в AS path. Вариант Layer 3 устроен иначе: route server добавляет собственный ASN в путь, поэтому для участников он выступает провайдером. Если такой ASN не указан в ASPA участника, проверка пути может не найти ожидаемую связь между AS.
Это не просто иной способ организации пиринга. Layer 3 route servers часто обеспечивают связность через широкие сети за пределами одной коммутационной фабрики, обычно с использованием IP или Multiprotocol Label Switching (MPLS). Попытка получить ту же связность только на Layer 2 может привести к broadcast storms, петлям Spanning Tree Protocol (STP) и проблемам масштабирования MAC-таблиц.
Особая запись в ASPA route server
Для Layer 3 route server источник указывает отдельную схему: его ASPA содержит список провайдеров с единственной записью AS0. Это не означает, что участникам нужно указывать AS0 вместо ASN route server. Участник добавляет в свой список провайдеров именно ASN, который появляется в AS path; собственный объект ASPA route server оформляется по правилу с AS0.
Такой подход повторяет логику Route Origin Authorization (ROA): AS0 означает, что для соответствующего префикса нет допустимых origin ASN. Здесь важно не смешивать две стороны настройки: участник авторизует реального провайдера, а объект route server содержит единственную запись AS0.
Чем опасна ошибочная ASPA и как её проверить
Ошибочная ASPA может повлиять не только на оценку маршрутов с поддельным путём. Если в списке провайдеров пропущена AS, которая действительно передаёт маршруты, валидатор может признать недействительными легитимные пути через неё. Особенно легко ошибиться в сложной топологии: транзит может быть резервным или доступным лишь для части префиксов. Поэтому проверять нужно не только список в объекте, но и реальные BGP-пути.
Сверьте ASPA с наблюдаемыми путями
APNIC рекомендует перед публикацией сопоставить предполагаемые отношения провайдер—клиент с наблюдениями BGP. Если в путях встречается ASN, который передаёт маршруты вашей сети, но не указан как провайдер, это повод проверить договорённости и схему распространения маршрутов. Само присутствие ASN в пути ещё не доказывает транзит: важно установить, какую роль эта сеть играет для конкретных маршрутов.
До отправки изменений стоит проверить их на предмет последствий для известных путей. Такая проверка помогает заметить пропущенного провайдера или неверно описанное отношение, но не гарантирует, что учтены все маршруты: видимость BGP зависит от доступных наблюдений. Рекомендации APNIC описывают практику проверки, а не универсальный механизм, одинаковый для всех валидаторов и сетей.
Не путайте ошибку в объекте с ошибкой в маршруте
ASPA задаёт разрешённые отношения между AS, а не подтверждает, что каждый наблюдаемый путь корректен сам по себе. Если объект неполон, валидатор может отметить путь как недействительный из-за отсутствующего разрешения, хотя маршрут распространяется штатно. Если же добавить лишнюю AS без соответствующего транзита, объект будет неточно описывать политику сети и ослабит смысл проверки.
Перед изменением полезно отдельно разобрать пути, где возникает сомнение: кто передаёт маршрут, для каких префиксов и действует ли это отношение постоянно или только как резерв. Взаимный пиринг и роль route server требуют отдельной трактовки; их нельзя автоматически сводить к обычному списку вышестоящих сетей.
Почему валидацию советуют включать до роста числа ASPA
Малое число объектов упрощает поиск ошибок
Проверка ASPA сопоставляет заявленные отношения провайдер—клиент с AS path в BGP. Если объект описывает отношения неверно, путь может получить статус недействительного, хотя маршрут нужен для связности. Чем больше опубликовано ASPA, тем больше объектов и путей приходится учитывать при поиске причины: ошибка может быть в собственной записи или в записи другой AS на пути.
APNIC рекомендует включать валидацию, пока объектов немного. На раннем этапе проще наблюдать, какие маршруты меняют статус, сопоставлять результат с реальными отношениями и исправлять ошибочные данные до того, как проверка станет частью обычной обработки маршрутов. Это снижает сложность диагностики, но не гарантирует отсутствия сбоев: результат зависит от корректности ASPA и от того, как конкретная сеть применяет валидацию.
Проверять нужно реальные пути, а не только запись
Перед включением проверки полезно изучить BGP-наблюдения и убедиться, что видимые пути согласуются с заявленными провайдерами. Важно учитывать резервные и частичные отношения: маршрут может проходить через AS, которая передаёт трафик лишь для части префиксов или в отдельных точках. Если такая связь не отражена в ASPA, проверка способна затронуть легитимный путь.
APNIC также советует проверять изменения до их отправки. Такая предварительная проверка помогает обнаружить ошибку в данных, но не заменяет наблюдение за маршрутами и не является универсальной гарантией для всех систем валидации. По данным APNIC, под его RPKI trust anchor опубликовано 538 объектов ASPA; по мере роста их числа ранняя проверка помогает находить несоответствия до того, как их станет сложнее отделить от ошибок в других объектах.
Создание ASPA в MyAPNIC: от заявки до публикации
В MyAPNIC ASPA создаётся через раздел управления маршрутами. Перед отправкой проверьте, что выбраны нужная автономная система и список её провайдеров: объект авторизует именно указанные отношения, а ошибка в данных может повлиять на проверку BGP-путей.
Создание объекта
- Откройте
Route Management. - Выберите
Autonomous System Provider Authorization (ASPA), затемCreate ASPA. - Заполните данные объекта, включая ASN и список провайдеров.
- Проверьте созданную запись в статусе
Pending. - Если данные верны, выполните
Commit, чтобы отправить объект на публикацию.
Проверка перед публикацией
Статус Pending — точка для проверки, а не подтверждение, что объект уже опубликован. Сверьте ASN и провайдеров с фактической схемой маршрутизации; не добавляйте ASN только потому, что он встречается в инфраструктуре или участвует в пиринге. В частности, роль route server зависит от того, добавляет ли он собственный ASN в AS path.
После проверки используйте Commit. Если обнаружили ошибку до отправки, исправьте данные в ожидающем объекте, а не рассчитывайте, что её компенсирует последующая валидация маршрутов.
