Кратко

  • Один владелец может подключить не более двух программных зондов с одного IP-адреса и четырёх из одного видимого в BGP префикса; для всех владельцев вместе предел равен 32 зондам в IPv4-префиксе и 64 в IPv6-префиксе.
  • Политика прямо говорит о расходах, малой добавочной ценности плотного размещения, исключениях и возможности менять пределы. Не хватает воспроизводимой связи между состоянием BGP в определённый момент и группой, посчитанной для конкретного решения.
  • Закрытая квитанция для оператора и владельца должна связывать время, границы наблюдения маршрутов, вычисленный префикс, счётчики, сработавший порог, условие освобождения и проверку исключения; публике достаточно безопасной агрегации.

Четыре числа означают четыре разных проверки

RIPE Atlas получает ценность не от количества процессов как такового, а от разнообразия точек наблюдения. Каждый подключённый зонд расходует центральные ресурсы. Множество программных зондов в одной сети и одном месте может давать сходные результаты с небольшой дополнительной информацией. При этом владельцы активных зондов получают кредиты для собственных измерений. Система должна поощрять участие, не превращая плотность установок в отдельную цель.

В сообщении от 29 апреля 2026 года RIPE NCC назвал четыре ограничения. Один владелец может подключить два программных зонда с одного IP-адреса. Тот же владелец может подключить четыре из одного IP-префикса «как он виден в BGP». Независимо от владельца, в одном IPv4-префиксе допускается не более 32 зондов, а в IPv6-префиксе — 64. Зонд сверх предела не подключается, пока другой не выйдет из группы.

Это не четыре степени одной проверки. Число 2 соединяет учётную запись и адрес. Число 4 — учётную запись и префикс маршрутизации. Числа 32 и 64 считают все записи внутри префикса и различают семейства адресов. Поэтому сообщение о нарушении без указания слоя не объясняет, какая совокупность была построена и какой предел она пересекла.

RIPE NCC не представил эти значения как неизменные константы. Максимумы могут корректироваться. Если зонды одного пользователя выглядят принадлежащими одной сети, но на деле широко разнесены географически, владелец может описать ситуацию по электронной почте и попросить послабление. На момент объявления речь шла примерно о 71 зонде у 13 владельцев. Это оценка запуска на 29 апреля, а не нынешний итог и не доказательство, что все 71 зонд действительно были остановлены.

Ключевая формулировка — «как виден в BGP». Система не принимает регистрационное выделение, весь ASN или введённое пользователем местоположение за готовую операционную границу. Она смотрит на наблюдаемую маршрутизацию. Но BGP-префикс не прикреплён к устройству: может появиться более специфичный анонс, произойти агрегация или отзыв, смениться источник, разойтись картины в точках наблюдения. Зонд остаётся на месте, а его группа может измениться.

Это техническая возможность, а не установленный сбой RIPE Atlas. Изученные источники не показывают зонд, который был задержан или освобождён только из-за изменения BGP. Они также не называют источник маршрутов, набор коллекторов, порог видимости, момент наблюдения и правило выбора префикса. Неизвестное нельзя выдавать за ошибку; его следует превратить в поля доказательства.

Большие сети проверяют предположение об одинаковости

В публичном обсуждении Robert Scheck спросил о возможном влиянии на AS3209 и AS3320. Он напомнил об исследовании, где зонды внутри одного BGP-префикса вели себя по-разному и помогли найти проблему.

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

Ответ RIPE NCC, сохранённый в официальной выдаче ответов, был осторожным. Пределы выбрали так, чтобы не затронуть обычное количество программных зондов в этих крупных сетях. Ситуацию будут отслеживать, а большим префиксам в будущем, возможно, дадут больше свободы. Это признание настраиваемого параметра, не обещание особой квоты каждому крупному ASN.

В том же разговоре спросили, увидит ли владелец понятную причину или только статус «Disconnected». RIPE NCC обещал специальную метку и предварительное письмо тем 13 владельцам, которые входили в оценку. Изменения сайта от 15 июля теперь сообщают: обзор зонда показывает владельцу, что устройство находится в ожидании из-за farming violation.

Название причины полезно. Оно отделяет намеренное ограничение подключения от проблем межсетевого экрана, линии или контроллера. Однако метка не является квитанцией решения. Из неё не видно, сработали 2, 4, 32 или 64, какой префикс вычислила система, сколько зондов было посчитано и когда случится новая оценка.

Поле префикса не заменяет происхождение решения

Текущая инструкция по управлению зондом повторяет четыре предела, ссылку на BGP и путь для географически распределённого исключения. FAQ для зондов и владельцев описывает стимул: активность приносит кредиты, тогда как RIPE Atlas стремится к топологическому разнообразию и хочет остановить выращивание кредитов.

Публичная документация API зондов содержит поля prefix_v4 и prefix_v6. Они полезны как описательное состояние, но рассмотренные материалы не определяют публичный объект, который связывает префикс, время маршрута, счётчик, порог и проверку одного ожидания. Да и раскрывать всю механику защиты было бы неразумно. Точные исходные адреса, связи учётных записей и сведения, помогающие обходу, должны оставаться закрытыми.

Нужны два слоя. RIPE NCC и затронутому владельцу требуется закрытая воспроизводимая запись. Исследователям и обществу нужны агрегированные показатели работы правила без раскрытия конкретных установок. Подотчётность не требует одинакового набора полей для этих аудиторий.

Документация BGP State от RIPEstat даёт здесь словарь, а не описание реализации Atlas. Воспроизводимое состояние маршрутов может назвать ресурс, момент времени, выбранные коллекторы, идентификаторы источников и время запроса. Нет оснований утверждать, что механизм ограничений использует RIPEstat, RIS, все коллекторы RIS или тот же расчёт. Пример лишь показывает, насколько точнее может быть выражение «виден в BGP».

Квитанция, которая не помогает обходить защиту

Закрытая запись начинается со времени решения, семейства адресов и защищённого представления исходного IP. Она сохраняет вычисленный префикс, время состояния BGP и границу используемых данных. Если наблюдались конкурирующие или перекрывающиеся маршруты, записывается правило выбора.

Затем указывается ступень. Это третий зонд владельца за одним адресом, пятый зонд владельца в префиксе, 33-й в IPv4-группе или 65-й в IPv6-группе? Число непосредственно до решения и действующий максимум должны храниться рядом. Почти одновременные подключения требуют устойчивого порядка обработки.

Последняя часть — выход из ожидания. Формула «пока не выпадут другие зонды» понятна как политика, но не отвечает, когда группа пересчитывается, запускает ли изменение BGP проверку, существует ли очередь и какое событие вернуло доступ. Для исключения можно сохранить время запроса, категорию причины, решение, проверяющего и срок, не публикуя чувствительный текст владельца.

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

Это редакционная рекомендация Theo March. Она не предполагает отсутствия внутренних журналов RIPE NCC и не называет нарушителем каждого владельца, попавшего под предел. Название состояния описывает путь контроля, а не намерение человека.

Источники