Кратко

  • Стандартный предел провайдеров ASPA в FORT — 4 000. В изученном слиянии он сравнивает сумму длин двух текущих списков до удаления повторов.
  • При превышении на этом этапе возвращаются нулевой указатель и счетчик с нулевым значением; контракт типа связывает их с отзывом. Пострадавший клиент, отзыв, доставленный маршрутизатору, или отмена регистрации ресурсов не наблюдались.

Число разных провайдеров и емкость для объединения двух списков могут отличаться. Закрепленный код FORT проверяет бюджет между этими операциями: сначала складывает длины, затем строит объединение без повторов.

Предположим, что для одного клиентского AS поступают два отсортированных списка по 2 500 ASID с одинаковым составом. Математическое объединение содержит 2 500 AS, но предварительная сумма равна 5 000 и превышает стандартные 4 000. Это условный вывод из функции, а не найденная в рабочей среде пара публикаций ASPA. Предполагается, что списки прошли остальные проверки и попали в одно слияние.

Объяснение ASPA, опубликованное LACNIC 9 сентября 2026 года, называет FORT среди существующих реализаций. ASPA дает отношения провайдеров, разрешенные клиентским AS, а не только проверку источника маршрута. Здесь рассматривается подсчет совпадающей информации при ее приеме, не уровень внедрения или версия протокола с маршрутизатором.

Разбор фиксирован на 1.7.0.experimental, опубликованном 16 июля, и коммите c67d14bcdbc8cbcf100e97c481a8c4ef6eb0ca7e. Сентябрьская статья не объявляет сентябрьский выпуск и не инвентаризирует все действующие установки. FORT не запускался, рабочий сервис не опрашивался, синтетический ASPA не публиковался.

Одна настройка, два места проверки

Руководство определяет aspa.max-providers как целое, задаваемое аргументом или JSON: по умолчанию 4 000, диапазон от нуля до 16 380. Оно описывает декларации клиента по всем деревьям RPKI за цикл и говорит о признании превысивших число клиентов недействительными. Конфигурационный код подтверждает значения. Статья не превращает их в протокольный потолок и не представляет ноль как отсутствие ограничения.

Первая проверка относится к отдельному объекту. parse_providers отклоняет слишком длинный список до выделения массива и передачи объекта дальше. ASID должны идти по возрастанию, без внутренних повторов и без самого клиента в роли провайдера. Совпадения между двумя допущенными списками поэтому отличаются от повтора внутри объекта. Форма списков также не доказывает все условия действительности подписей и сертификатов.

Вторая проверка возникает при объединении записей базы по клиентскому ключу. Когда запись этого клиента уже существует, add_aspa вызывает merge_providers. Сначала та помещает сумму old->count и new->count в m. Если прежний указатель провайдеров нулевой либо сумма выше предела, результат содержит нулевой указатель и нулевое число.

Только после этого барьера выделяется емкость для суммы и объединяются отсортированные списки с удалением повторов между ними. Меньшее число членов появляется после первой бюджетной проверки. add_aspa присваивает результат новой записи клиента и освобождает замененное хранилище. Заголовок типа указывает, что нулевой указатель и ноль используются для отзыва.

Так две одинаковые последовательности по 2 500 проверяются как 5 000 прежде, чем могли бы дать 2 500 разных членов. Арифметика не доказывает реального отзыва или изменения сетевого трафика.

Не обязательно сумма всех исходных записей за цикл

Прежнее число может уже быть результатом объединения с удаленными повторами. Оно не обязано сохранять длины каждого первоначального объекта.

В условной последовательности к одной исправной целевой записи три одинаковых списка по 1 500 дают сначала сумму 3 000, затем множество 1 500, а с третьим списком снова сумму 3 000. Первоначальные списки содержат 4 500 записей, но эта конкретная последовательность не обязательно превышает 4 000.

Это не гарантия группировки реальных деревьев. Пример разделяет исходное число записей, емкость двух текущих входов и количество разных членов. За словами «число провайдеров» могут скрываться разные единицы.

Числовое условие — больше предела, не равно ему. Равенство не включает этот числовой путь, хотя остальные проверки сохраняются. Нулевой результат также не доказывает превышение: прежний нулевой указатель — другая причина. Все порядки слияния не проверены, и универсальная необратимость недействительных маркеров не заявляется.

Сначала назвать защищаемый бюджет

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

Оператору при этом может быть виднее число разных AS в результате. Полезное уточнение назовет защищаемую величину: промежуточную емкость двух входов или окончательных уникальных членов. Изменение объяснения и изменение порядка — разные решения. Ни одно не объявляется принятым, и простое повышение предела не рекомендуется.

Последующая реакция требует отдельных свидетельств. Нулевой результат и соглашение об отзыве не показывают, что получила сессия маршрутизатора, какую политику он применил или изменился ли трафик. Решение кеша об информации провайдеров не отменяет ASN или регистрацию ресурсов клиента. Найдено правило приема в программный результат, а не наблюдавшийся инцидент.

Источники

  1. Введение LACNIC в ASPA
  2. Выпуск FORT 1.7.0.experimental
  3. Руководство параметров в закрепленном коммите
  4. Разбор провайдеров объекта ASPA
  5. Слияние по клиенту и порядок подсчета
  6. Значения и границы конфигурации
  7. Тип провайдеров и соглашение об отзыве