Кратко

  • FRRouting включил исправление #22681 в версии 10.7.1, 10.6.2 и 10.5.5, выпущенные 25 августа 2026 года. Оно касается больших значений в расширенном сообществе BGP Link Bandwidth.
  • Формат IEEE и старое представление беззнаковым целым по-прежнему требуют разных суммарных значений. Тесты также различаются по глубине проверки и не устанавливают фактические доли трафика.

Для двух входных значений, 30 и 100 Гбит/с, ожидаемый ответ после обновления FRRouting нельзя записать просто как «130». Сначала нужно назвать единицу, способ кодирования и точку наблюдения. В формате IEEE результат близок к полной сумме; в старом целочисленном формате он должен упереться примерно в 34,36 Гбит/с. Последний результат сам по себе не означает, что исправление не сработало.

Официальные примечания к 10.7.1, 10.6.2 и 10.5.5 перечисляют одну и ту же коррекцию #22681. Все три выпуска датированы 25 августа. Речь идёт о числовом представлении атрибута BGP, а не об измерении физической пропускной способности. Источники не показывают, что порт на 100 Гбит/с прежде мог передавать лишь 34 Гбит/с.

Порог возник при сужении числа

В запросе на включение изменения #22681, принятом 28 июля, описано несоответствие внутренних типов. BGP уже хранил полосу пропускания как беззнаковое 64-битное целое, но вспомогательные операции кодирования, декодирования или отображения сужали значение до 32 бит. Кроме того, при замене суммарной полосы безусловно применялся максимум беззнакового 32-битного целого.

Поле выражено в байтах в секунду. Поэтому максимум 4 294 967 295 соответствует приблизительно 34,36 Гбит/с. Формат IEEE на линии тоже занимает 32 бита, однако это число с плавающей точкой, у которого иной диапазон. RFC 10005 определяет четырёхоктетное представление и эту единицу измерения.

Исправление расширяет соответствующие внутренние операции и оставляет ограничение суммы только для классического сырого целочисленного формата. Оно не вводит 64-битное поле в протокол и не отменяет округление плавающей точки. Формулировка «снят предел полосы пропускания» теряет важное условие: для одного режима ограничение было ошибочным, для другого оно остаётся необходимым.

Что именно сравнивают тесты

Изменённые регрессионные тесты получают от двух внутренних соседей BGP значения 30 000 и 100 000 Мбит/с. Точная сумма равна 16 250 000 000 байт/с. После преобразований входов и суммы в формат одинарной точности получается 16 249 999 360. Небольшая разница — обычное округление, а не повтор прежнего сужения до целого.

В целочисленной ветви ожидается 4 294 967 295 байт/с. Обновлённый тест требует именно этого предела вместо меньшего усечённого результата. Если требовать эквивалент 130 Гбит/с в обоих режимах, можно ошибочно отклонить корректную реализацию.

Арифметика для этой статьи пересчитана независимо. Саму тестовую топологию FRRouting мы не запускали. Чтение исходного текста теста позволяет установить его утверждения, но не заменяет собственный эксперимент на маршрутизаторах или измерение в сети заказчика.

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

Почему нужно смотреть на выход сумматора

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

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

FRRouting сохраняет настройку кодирования для отдельного соседа, позволяющую работать со старыми целочисленными реализациями. Исправление не даёт оснований советовать убрать её сразу повсюду. Сначала нужно подтвердить, что получатель понимает другой формат. Некоторые соседние описания допустимых диапазонов команд в текущей документации уже, чем входы зафиксированной версии тестов. Из них нельзя составить универсальную инструкцию для всех ветвей сопровождения; нужны конкретная сборка и её поддерживаемые команды.

Источники, проверенные по состоянию на 8 сентября, 12:40 UTC, не устанавливают число затронутых клиентов, производственный инцидент, измеренное ускорение или полный перечень затронутых версий. Три примечания подтверждают включение исправления в указанные выпуски, а не состояние всех остальных.

Такое разделение механизма и обещанного эффекта соответствует редакционному принципу Lu Heng из эссе о реальности, а не продвижении позиции. Здесь принцип применяет автор; это не оценка FRRouting со стороны Lu Heng. Практический вывод состоит в более точной приёмке: вместе с версией следует указывать режим, ожидаемую цифру и наблюдение у получателя.