Кратко

  • В журнале изменений от 18 августа 2026 года AFRINIC описал четыре состояния BGP: анонс исходного префикса, только более специфичные маршруты, отсутствие маршрутизации и отсутствие данных.
  • Применение опубликованного алгоритма к полному файлу ЮАР, полученному 3 сентября, дает 239 точных анонсов и 42 случая с более специфичными маршрутами. Вместе это 281 из 522 блоков, или 54% после округления.
  • Файл указывает дату формирования 20 августа, но не дату снимка BGP. Здесь воспроизведен расчет по открытым данным, а не проведено новое наблюдение за маршрутами или доступностью сервисов.

Удобный показатель должен сокращать время на разбор ситуации, а не подменять ее более простой. Если исходный префикс сети перестал быть виден, но остались маршруты к меньшим диапазонам внутри него, это не та же ситуация, что полное отсутствие наблюдаемых анонсов. Для оператора различие важнее, чем цвет общего индикатора.

AFRINIC сделал это различие явным в Africa IPv6 & DNSSEC Deployment Monitor. Запись об обновлении от 18 августа описывает переход от двух состояний BGP к четырем. Помимо точного анонса и более специфичных маршрутов, отдельно показаны отсутствие маршрутизации и отсутствие данных. Последнее особенно полезно: неизвестный результат больше не обязан выглядеть как отрицательный.

Однако более подробная классификация не означает, что общий процент теперь учитывает только исходные префиксы. На данных по ЮАР можно проверить, что именно складывается.

Две составляющие одной суммы

В открытом файле ЮАР, полностью полученном 3 сентября, содержатся 522 записи с разными префиксами. У 451 записи указан статус allocated, у 71 — assigned. Поэтому речь идет о перечисленных блоках, а не о 522 одинаковых операциях распределения.

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

Состояние по правилу монитора Блоков
Исходный префикс анонсируется 239
Только более специфичные маршруты 42
Отнесены к состоянию без маршрутизации 241
Отнесены к состоянию без данных 0

Главный расчет объединяет первые две строки: 239 плюс 42 равно 281. Деление 281 на 522 с округлением до целого дает 54%. Поясняющая фраза, которую формирует тот же код, отдельно называет обе составляющие. Таким образом, инструмент уже предоставляет читателю возможность понять сумму, а не только повторить ее.

Если оставить в числителе лишь 239 точных анонсов, получится около 46%. Это не исправленный коэффициент доступности, а другой показатель. Каждая запись имеет одинаковый вес независимо от размера блока. Ни один из этих расчетов не показывает долю адресов, организаций, клиентов или успешных соединений.

Более специфичный маршрут не получает низшую оценку автоматически

Слово «только» может создавать впечатление незавершенного внедрения. Но техническое значение уже. В RFC 4271 более специфичный маршрут описывается как более длинный префикс, охватывающий меньшее множество адресов назначения. Это отношение между множествами, а не заключение о качестве работы сети.

Простой арифметический пример: две правильно выровненные половины /33 могут вместе описывать весь диапазон /32 без анонса самого /32. В этой проверке не установлено, что хотя бы один из 42 случаев использует такую схему. Пример показывает лишь, почему отсутствие агрегата само по себе не доказывает пробел в охвате адресов более мелкими маршрутами.

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

Поэтому 42 случая нельзя на основании этих входных данных объявлять неисправными, неиспользуемыми или небезопасными. Для 241 отрицательной классификации также действуют границы набора данных монитора: это не доказательство отсутствия маршрута во всех возможных представлениях BGP. Ноль неизвестных записей относится к полученному файлу ЮАР, а не к полноте наблюдения за всей Африкой.

Когда сформирован файл и когда наблюдались маршруты

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

В проверенном файле указана дата формирования 20 августа 2026 года, а поле даты снимка BGP пусто. Код сохраняет эту разницу: при наличии даты снимка сообщает ее, иначе указывает время формирования данных. Дата получения файла, 3 сентября, не заполняет отсутствующий момент наблюдения и не делает расчет свежим замером маршрутов за этот день.

На странице ЮАР также разделены вкладки доменных сервисов, использования IPv6 конечными пользователями, адресного пространства и BGP. Такое разделение стоит сохранять и в выводах. Наличие анонса не означает, что за читателя проверили сайт, почту или соединение абонента.

Польза обновления состоит в более точных вопросах к известной сумме. Общий процент может кратко описывать наличие одного из двух видов анонсов. Разбивка показывает, какой именно вид наблюдается. Для этого ей не нужно становиться рейтингом правильных и неправильных архитектур.