Кратко

  • RFC 1474 задавал отдельную строку состояния для каждого PPP-канала и типа MAC. Локальное accept описывало собственную обработку, а удалённое — лишь мнение локального узла о соседе.
  • По RFC 1220 отсутствие объявления позволяло предположить поддержку всех типов, хотя получатель мог отбрасывать непонятные. Даже отказ от опции не всегда прекращал отправку трафика к узлу, заявившему о сбросе.

Опубликованный в июне 1993 года RFC 1474 определил MIB для Bridge Network Control Protocol в PPP. Он сделал видимыми конфигурацию, состояние протокола и поддержку типов среды, не выдавая эти показатели за полную трассу кадра.

Особенно точно документ разделил два источника знания. Одинаковое слово accept могло означать неравные утверждения.

Локальная и удалённая колонки знали разное

Индекс pppBridgeMediaTable включал ifIndex и pppBridgeMediaMacType. Строка относилась к одному типу кадра на одном PPP-интерфейсе. Она ничего автоматически не говорила о другом типе, канале или соседе.

pppBridgeMediaLocalStatus=accept означал, что локальная сущность примет и корректно обработает такие пакеты. При dont-accept полученные пакеты не будут обработаны правильно. Система описывала собственное поведение.

pppBridgeMediaRemoteStatus сообщал другое: считает ли локальная сущность, что удалённая примет тот же тип. Объектом суждения был сосед, но автором оставалась локальная сторона.

Если панель красит обе ячейки одинаково, происхождение исчезает. Собственную возможность можно связать с локальной конфигурацией и кодом. Модель соседа строится из опций, интерпретации молчания и сохранённого состояния согласования.

Молчание давало правило отправителю, а не способность получателю

RFC 1220 ввёл MAC Type Selection. Узел мог объявить типы трафика, которые готов принимать и обслуживать. Для нескольких типов в Configure-Request помещались несколько опций.

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

Явный список предупреждал, что неуказанные типы будут отброшены. Но Configure-Reject тоже не означал безопасного прекращения потока: RFC 1220 описывал пересылку соответствующего трафика по каналу, хотя принимающая система уже сказала, что его отбросит.

Поэтому удалённый статус без основания неполон. Нужно знать тип, интерфейс, поколение согласования, объявление, умолчание и ответ.

Поздняя редакция прямо назвала опцию рекомендательной

В RFC 1638 1994 года согласование MAC-Support настоятельно рекомендовалось. Объявление позволяло не слать несовместимые типы и экономить полосу. При этом опция была названа advisory only.

Для типов MAC с номером выше 4 появилось более жёсткое условие: нельзя передавать их без полученной от соседа опции о готовности принять. Так расширение пространства типов получило защиту. Однако объявленная готовность всё равно не стала наблюдаемым приёмом кадра.

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

Поддержка формата не выбирала путь к адресу

Мост может понимать тип кадра и не знать порт для конкретного назначения. RFC 1493 вынес такую информацию в другую базу: unicast MAC-адреса, изученные или настроенные порты, правила пересылки и фильтрации.

Таблица RFC 1474 отвечала на вопрос о виде трафика на PPP-канале. FDB отвечала о распространении кадра для определённого адреса. Ни одна не являлась квитанцией конечной системы.

Проверяемая цепочка должна сохранить локальную политику, поколение перезапуска, обмен BNCP, основание мнения о соседе, отправленный кадр, обработку удалённой стороной, решение моста и результат у назначения.

RFC 1661 добавил порог: PPP переносил пакеты соответствующего протокола только после перехода его NCP в Opened; более ранние пакеты отбрасывались. Состояние разрешало трафик, но не свидетельствовало о конкретной передаче.

У мнения должен оставаться свидетель

RFC 1474 отделял изменяемую конфигурацию и предупреждал о риске управления PPP. Защищённые MIB views могли ограничить чтение и запись. Они не расширяли смысл поля.

Современное поле «удалённая поддержка» должно нести ifIndex, тип MAC, поколение, перезапуск, состояние NCP, опцию или правило умолчания, ответ и время вычисления. Иначе «моя модель соседа говорит да» превращается в «сосед получил».

Распределённой системе необходимы выводы. Ошибка возникает, когда автор вывода удалён, а видимость прямого факта сохранена.

RFC 1474 автора не удалял.

Источники