Кратко

  • RFC 8654 разрешает receiver объявить приём до 65 535 октетов, кроме OPEN и KEEPALIVE; sender использует размер только после получения capability от этого peer.
  • Обещание заканчивается на сессии. Для соседа с 4096 разрешено удалить лишь узкий класс RFC 7606 attribute discard; если сообщение не помещается, его не отправляют, а ранее объявленный NLRI отзывают.
  • Безопасное внедрение выравнивает iBGP до внешней зависимости, измеряет encoded size и ресурсы и сохраняет legacy-fit форму для rollback.

На ingress видна capability 6, большой UPDATE принят в RIB. Другой border не может экспортировать его: сосед не объявил поддержку, а attribute set превышает старый предел. Успех одного hop ошибочно приняли за свойство пути.

RFC 4271 использует двухоктетный Length, но ограничивает сообщения диапазоном 19–4096. RFC 8654 поднимает согласованный максимум до 65 535 и вводит capability code 6 длиной ноль. Она обещает приём и обработку на конкретной сессии, а не во всём AS.

Speaker отправляет Extended Message только после получения capability от peer. RFC 5492 делает использование двусторонним и оставляет оператору право потребовать функцию. Реализация, скрывшая способность конфигурацией, не вправе молча принять большое сообщение.

OPEN и KEEPALIVE исключены. RFC 9072 решает другую проблему — предел 255 октетов для Optional Parameters OPEN — через type 255 и двухоктетную длину. Расширенный OPEN не доказывает право на UPDATE размером 65 535.

Потолок не является целью

ADD-PATH добавляет четыре октета к каждому NLRI, Large Community — двенадцать к каждому значению, VPN и другие расширения увеличивают attributes. Это может быть policy-семантика, а не лишний padding.

При небольших attributes prefixes можно разнести по нескольким UPDATE. Если сам attribute block больше 4096, деление NLRI бесполезно. TCP дробит транспортный поток, но не семантическое сообщение BGP.

На legacy egress RFC 8654 допускает удаление только attributes из класса RFC 7606 attribute discard. Нельзя так убирать данные, влияющие на selection или installation; local policy может сделать решающим и обычно нейтральное поле. Если всё ещё велико, UPDATE не выходит, а прежняя route withdraw.

Одинаковая route может присутствовать на одном border и исчезнуть на другом; reflectors могут создать разные внешние картины; backup способен стать неотправляемым во время failover. Поэтому RFC 8654 требует согласованной capability у всех значимых iBGP speakers.

Растёт и поверхность ресурсов

Обещание 65 535 затрагивает buffers, queue, parser, validation, policy и logs. RFC 8654 предупреждает о resource exhaustion. Повторное изменение больших сообщений для legacy peers расходует CPU. Аутентифицированный сосед всё равно способен прислать корректные дорогие данные.

FRRouting перечисляет RFC 8654 среди реализованных RFC, BIRD 3.3.0 разделяет enable и require. Это проверяемые заявления, но не доказательство negotiation, headroom или прохождения по всем hops.

Доказательство привязывается к session epoch: local/received capabilities, peer, AFI/SAFI, running build, inbound и outbound length, attribute block и NLRI. Outcome различает repack, discard, suppress, withdrawal, Bad Message Length и policy reject.

Получение UPDATE не доказывает FIB и packets. Selection, recursive resolution, hardware programming и измеренный трафик завершают цепочку.