Кратко

  • План RIPEstat на третий квартал 2026 года обещает вскоре добавить описания BGP-community. Действующий API уже возвращает community_info, а RIPEstat называет NLNOG Looking Glass источником части сведений об известных community.
  • Единственный сохранённый запрос для 193.0.20.0/23 вернул 349 записей peers в 23 группах RRC; в 71 записи сведения о community были непустыми. Это характеристика одного ответа, а не общая доля покрытия.
  • В одной записи наблюдалось 12859:4000, описание было «customer routes», а original содержал 12859:4xxx. Фраза возникла из масочного правила, а не из точного словарного определения значения.
  • Нужна краткая квитанция описания: тип community, наблюдаемое значение, совпавшее выражение, класс совпадения, источник, версия, время загрузки определения, заявленная семантика и время маршрута. Наличие community действия не доказывает выполнение действия.

Число пришло с маршрутом, фраза — по другой цепочке

Квартальный план RIPEstat относит описания BGP-community к следующим улучшениям Looking Glass. Это полезно: без знания соглашений конкретной сети число 12859:4000 почти ничего не говорит читателю.

Документация API Looking Glass указывает, что маршруты основаны на BGP-данных коллекторов RIPE RIS, а поле community_info добавляет сведения об обычных и Large Communities. Страница источников RIPEstat сообщает, что часть информации об известных community предоставляет проект NLNOG Looking Glass.

Это две линии происхождения. RIS наблюдает атрибут в маршруте, полученном от peer. Слой описаний ищет правило в другом наборе данных и присоединяет читаемый текст. Соседство в интерфейсе удобно, но не превращает текст в атрибут, который был передан в BGP Update.

Сообщение о запуске в мае 2025 года называло новый Looking Glass полной переработкой на основе RIS, с разбором Large и Extended Communities, доступом через API и статусом раннего выпуска. Именно сейчас разумно сохранить шов, пока пояснения не разошлись по скриншотам, заявкам и автоматизации без контекста.

Конкретное сопоставление

Пакет доказательств сохранил ответ для 193.0.20.0/23. Он имел статус ok, версию 2.1, latest_time 2026-09-14T20:20:43, 23 группы RRC и 349 записей peers. В 71 из них community_info не был пуст.

Эти числа нельзя превращать в метрику всего сервиса. Одна сеть в один момент не показывает, какая доля community в Интернете описана, насколько свежи определения и сколько из них пришло непосредственно от операторов. Запрос показывает форму соединения данных.

В одной строке среди наблюдаемых community находилось 12859:4000. Объект community_info.regular вернул описание «customer routes», сохранив original: 12859:4xxx. В другой строке 2914:410 имело точное исходное выражение 2914:410 и текст «NTT and customer routes».

В короткой таблице оба результата выглядят одинаково убедительно, но разрешение доказательства различно. Точное совпадение означает, что источник перечислил конкретное значение. Маска означает, что значение попало в описанное семейство. Проверяемая формулировка звучит так: «12859:4000 совпало с 12859:4xxx, правилом, описанным как customer routes».

Маска сама по себе не недостаток. Оператор может намеренно определить одной строкой целую серию значений. Но точное значение, диапазон и открытый шаблон дают разную точность. Если правило скрыть, последующее уточнение или конфликт окажутся необъяснимыми.

Синтаксис сопоставления входит в происхождение

Репозиторий NLNOG Looking Glass описывает два пути. Структурированные YANG-подобные файлы загружаются с объявленных URL. Старый формат хранит по текстовому файлу на ASN: выражение community, запятая и описание в каждой допустимой строке.

Старый matcher принимает точные значения, диапазоны, однозначные маски и шаблоны произвольных чисел. Захваченные части можно подставлять в текст. Это экономно описывает большое пространство, однако применённое правило становится частью результата.

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

Зафиксированный community_urls.yml перечислял структурированные источники для AS25152 и AS197000. Это не полный реестр всех пояснений из ответа RIPEstat. Отсутствие AS12859 не доказывает ошибку; оно лишь означает, что сам проверенный JSON не принёс URL, ревизию, время загрузки или автора проверки правила 12859:4xxx.

Время маршрута не датирует описание

latest_time относится к данным маршрутизации. Оно не говорит, когда проверили слова «customer routes». Определение могло раньше прийти со страницы оператора, из pull request или формального feed. Затем текст способен измениться при неизменной маршрутизации, а маршрут — при неизменном тексте.

RFC 1997 определяет обычные Communities как необязательный транзитивный атрибут BGP и разрешает автономной системе задавать локальную семантику вне зарезервированных значений. RFC 8092 делит Large Community на глобального администратора и два локальных поля, которые могут описывать свойства или действия политики.

Числовая структура указывает административное пространство, но не удостоверяет внешний текст. Получающие сети не обязаны применять одинаковую политику: community можно добавлять, удалять, менять, игнорировать или использовать. Наблюдение RIS показывает, что дошло до одной точки, а не каждое решение вдоль пути.

Запрос действия не является результатом

RFC 8195 различает информационные community и community действия. Первые помечают свойства, вторые просят другую AS выполнить заранее определённую операцию. Операторам рекомендуется публиковать и поддерживать документацию обоих типов.

Наблюдаемая community действия доказывает присутствие запроса. Она не доказывает, что получатель его принял, политика сработала, эффект распространился или сохранился. Интерфейс должен писать «запрашивает», а не «выполняет». Независимо наблюдаемый эффект нуждается в отдельном поле, методе и времени.

«Customer routes» в данном случае — классификация, а не команда. Но и она не доказывает договор, собственность, юридическую идентичность или текущие коммерческие отношения для каждого помеченного префикса.

Компактная квитанция

Основная строка может оставаться простой. В раскрываемой части следует хранить:

  • обычный, Large или Extended тип;
  • фактически наблюдаемое значение;
  • совпавшее выражение и класс — точный, диапазон или шаблон;
  • источник, URL и класс авторитетности;
  • ревизию, commit или хеш содержания;
  • время загрузки и заявленный период действия;
  • информационный смысл или запрос действия;
  • время маршрута, RRC и peer;
  • конфликт, исправление и замещение.

Квитанция не сертифицирует текст. Она делает соединение воспроизводимым. Пустые состояния тоже различны: описание не найдено, источник недоступен, правила конфликтуют, определение устарело, тип не поддерживается.

Узкий вывод

Сохранённый ответ доказывает, что RIPEstat способен одновременно показать наблюдаемую community, человеческое описание и более широкое выражение, давшее совпадение. Он не доказывает ошибку описания, опасность маршрута, договорные отношения или выполнение политики; не оценивает весь каталог NLNOG и не обвиняет RIPE NCC, NLNOG или сети пути.

Следующий шаг — не убрать объяснения, а заставить их переносить своё происхождение. Чем понятнее RIPEstat делает community, тем важнее оставлять маску видимой.

Источники