Кратко

  • RFC 1220 запрещал обмен LAN-трафиком до открытия Bridge Network Control Protocol. Open подтверждал необходимое состояние управляющего протокола, но не передачу конкретного кадра и не его появление в удалённом сегменте.
  • Даже после переговоров требовались достаточный MRU, правильная последовательность на нескольких линиях, совместимый MAC-тип, согласованное направление tinygram-компрессии, политика LAN ID, состояние spanning tree и действие получателя.
  • CRC кадра PPP и необязательный LAN FCS относились к разным слоям. Успешная проверка последовательного участка не доказывала сохранение исходного кадра или результат приложения.

Управление открыло путь, но не завершило поездку

RFC 1220, Point-to-Point Protocol Extensions for Bridging, вышел в апреле 1991 года под редакцией F. Baker. Каталог RFC Editor и IETF Datatracker указывают Proposed Standard, IETF stream и замену документа на RFC 1638. Эти карточки доказывают происхождение и статус текста. Они ничего не сообщают о внедрении на конкретном устройстве.

Задачей был перенос LAN-кадров между удалёнными мостами через одну или несколько последовательных линий. RFC опирался на дисциплину PPP из RFC 1171. В модели предполагалось, что устройства уже согласились использовать PPP в некоторой форме, могли договориться о смешивании других протоколов и могли быть готовы к remote bridging. Предположение спецификации не равно журналу реального согласования.

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

Состояние Open точно отвечало на вопрос: разрешает ли теперь автомат протокола этот класс трафика? Оно не называло переданный кадр, выбранный выходной интерфейс, состояние удалённого порта, получателя или приложение. Начало допустимого обмена и достигнутый результат — разные записи.

Молчание было правилом протокола, а не голосом оператора

Для transparent bridging документ использовал узкое допущение: если сосед получил IEEE 802.1 BPDU и не ответил PPP Protocol-Reject, bridging на линии считался разрешённым. Отсутствие отказа имело определённую семантику внутри этой модели.

Однако из него нельзя было получить неограниченную административную санкцию. Молчание не идентифицировало человека, не подтверждало одинаковую конфигурацию сторон, не показывало root spanning tree и не доказывало состояние forwarding. Менеджер сети мог намеренно разделить линию на две spanning-tree-домены. Тогда оба конца следовало настроить на отсутствие обмена BPDU, а неожиданную BPDU мост должен был молча отбросить.

Снаружи протокольное принятие, намеренное разделение и односторонняя неисправность могли выглядеть одинаково. Обычный поток spanning tree был преимущественно однонаправленным — от корня к листьям. Поэтому RFC настоятельно рекомендовал Magic Number Loopback Detection и Link Quality Monitoring. Тихое обратное направление не подтверждало двустороннюю исправность.

Опции оставляли асимметрию на виду

BNCP согласовывал MAC-типы, tinygram-компрессию, LAN Identification и ring/bridge-идентификаторы. Объявление MAC-типа описывало, какие кадры получатель готов принять и обслужить. Если он перечислял набор, остальные типы следовало отбрасывать. Если список отсутствовал, отправитель мог предположить широкую поддержку, хотя получатель всё равно отбросил бы непонятный тип.

Отказ от объявления MAC-типа мог привести к ещё более странному состоянию: отправитель продолжал пересылать такой трафик, уже зная, что получатель намерен его удалять. Переговоры фиксировали несовместимость, но не всегда превращали её в автоматическую безопасную блокировку.

Tinygram-компрессия относилась к направлению. Одна сторона могла разрешить декомпрессию, другая — нет; без согласования компрессии не было. Показатель «compression enabled» без указания направления терял важную часть состояния.

LAN Identification был рекомендательным механизмом и по умолчанию выключался. Включённая опция говорила, что за соседом могут находиться маркированные LAN и он готов их обслуживать. Выключенная предупреждала, что маркированный трафик будет сброшен. LAN ID описывал область протокола, но не доказывал организационную принадлежность и не заменял контроль доступа.

Open не менял физический предел кадра

RFC 1220 требовал, чтобы согласованный MRU вмещал поддерживаемые MAC-типы. Для bridged frame не предусматривались фрагментация и сборка. Даже Ethernet мог превышать стандартный PPP MRU в 1 500 октетов. Управляющий протокол мог успешно открыться, а допустимый для локальной сети кадр — не поместиться в выбранное состояние линии.

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

Две контрольные суммы показывали другую границу. PPP CRC защищал кадр на участке point-to-point. Необязательный встроенный LAN FCS был значением, рассчитанным — или выглядевшим рассчитанным — исходной станцией. RFC прямо называл их раздельными и несвязанными. Если встроенного FCS не было, при выпуске в LAN мост мог инициировать расчёт нового. Целостность линии, сохранение исходного LAN-кадра и доставка подтверждались разными событиями.

Формат описывал посылку, а не работу сети

Флаги могли отмечать встроенный FCS, LAN ID, сжатие нулевого заполнения и хвостовой padding. Поле MAC Type определяло интерпретацию следующих октетов. Эти данные помогали разобрать то, что заявил отправитель. Они не показывали запись forwarding database, незаблокированный порт spanning tree, выход в нужную LAN или приём конечной системой.

В источниках нет операторской конфигурации, записи переговоров BNCP, таблицы пересылки, packet trace или журнала приложения. Раздел безопасности сообщает, что вопросы безопасности не обсуждаются. Значит, пакет не доказывает аутентификацию, полномочие, конфиденциальность, безопасный откат, распространённость внедрения или результат сервиса.

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

Источники