Кратко

  • RFC 3518 добавил в PPP BCP согласуемую опцию Bridge-Control-Packet-Indicator. После её включения отправитель должен был помечать распознанные BPDU и PDU семейства GARP и не допускать их потери или существенной задержки.
  • Бит C подтверждал локальную классификацию и способность соседнего узла понять её. Он не удостоверял BPDU, не фиксировал его принятие управляющим процессом и не доказывал сходимость либо отсутствие петель.

Кадр данных следует уже принятому решению о пересылке. BPDU участвует в изменении этого решения: выборе корневого моста, ролей портов и блокировке избыточных путей. Поэтому задержка небольшого управляющего кадра за большим потоком способна дольше удерживать устаревшую картину сети.

Передача мостового трафика через PPP существовала задолго до 2003 года. RFC 1638 описал раннюю схему, а RFC 2878 пересмотрел Bridging Control Protocol. Два конца линии могли согласовать параметры и включить модули моста. RFC 3518 заменил RFC 2878, но не стал новым протоколом остовного дерева.

Раздел изменений назвал лишь два пункта: добавить конфигурационную опцию Bridge Control Packet Indicator и придать новый смысл одному резервному биту поля флагов. Узкое дополнение делало класс управления видимым именно там, где планировщик мог изменить обслуживание.

Тип опции BCP 10 обозначал поддержку индикатора. По умолчанию её не было. После согласования система должна была ставить C в единицу тогда и только тогда, когда исходящий кадр являлся управляющим для моста. Без согласования бит всегда оставался нулём; такой узел не мог ни отправлять, ни принимать единицу. Это сохраняло совместимость с RFC 2878.

Распознавание опиралось на назначенные IEEE адреса назначения MAC. RFC 3518 перечислял BPDU Spanning Tree, адрес управления мостами, GMRP и GVRP. Локальный классификатор видел адрес и заносил своё решение в заголовок мостового кадра PPP.

Целью было особое обслуживание. Реализация не должна была отбрасывать или значительно задерживать управляющие пакеты. Документ сравнивал их с обновлениями маршрутизации высокой важности и ссылался на модель дифференцированных услуг RFC 2474. На занятой линии метка могла выбрать лучшую очередь.

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

Каждому доказательству соответствует отдельный вопрос. Запись IANA подтверждает назначение номера 10. Configure-Request и Configure-Ack подтверждают возможность в конкретной сессии. Захват кадра показывает C. Далее нужны журналы управляющего процесса, изменения корня и ролей портов, а также наблюдение плоскости данных, чтобы говорить о реально заблокированных лишних путях.

Состояние Opened тоже локально. RFC 1661 задаёт автомат PPP, обмен которого использует BCP. При некоторых серьёзных несовпадениях, включая неразрешимый выбор протокола остовного дерева, RFC 3518 запрещает переход в Opened. Успешный переход означает приемлемое пересечение конфигураций двух соседей, а не проверку каждого устройства за ними.

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

Для линий, где возможен чужой или скомпрометированный аппарат, RFC рекомендует аутентификацию PPP при запуске LCP. CHAP из RFC 1994 проверяет соседа вызовом и ответом. Он укрепляет ответ на вопрос «кто на другом конце?», но не доказывает правильность конфигурации этого моста, свежесть BPDU и сходимость домена.

Многоканальные механизмы действуют на другом слое. RFC 1990 фрагментирует и упорядочивает данные по нескольким компонентам. RFC 2686 добавляет классы с разными требованиями к задержке. Они могут ускорить управляющий кадр, но скорость не означает принятие сообщения алгоритмом и безопасность результата.

Для старых мостов BCP RFC 3518 сохранил прежний формат BPDU, хотя обычный случай использовал общий формат мостового трафика. Исключение решало совместимость с соседом. Оно не описывало всю сеть за ним.

RFC 7042 позднее зафиксировал административную границу параметров IETF и IEEE 802, а реестр PPP продолжает хранить тип 10. Реестр доказывает власть над номером. Он не видит живую сессию и не может подтвердить подлинность, своевременность или эффект кадра.

Историческое значение RFC 3518 состоит в точном размещении полномочия. Интерфейс получил достаточно информации, чтобы лучше обслужить критический класс, но не был объявлен источником истины о распределённой системе. Классификация и приоритет оставались локальными; сходимость и отсутствие петель требовали собственных наблюдений.

BPDU может быть правильно распознан и быстро доставлен, но оказаться старым, исходить от скомпрометированного соседа, попасть не в тот домен или встретить ещё расходящиеся мосты. Бит C говорит, как обращаться с кадром. Он не говорит, что описываемый кадром мир безопасен.

Источники