Кратко

  • RFC 7067 и RFC 8171 описывают Push- и Pull-каталоги для сокращения unknown unicast, ARP и ND. Отсутствие записи в неполном наборе означает «источник не знает», а в доказанно полном наборе может означать «адреса в этой области нет».
  • RFC 8302 и RFC 8380 позволяют записи влиять на кэш, ответы и предварительную инкапсуляцию. Чем раньше каталог принимает участие в пересылке, тем выше ущерб от устаревшего или ложного соответствия.

Анализ

Старая запись не выглядит сломанной

Виртуальная машина перемещается с RB1 на RB2. Её IP- и MAC-адреса могут сохраниться, меняется только egress RBridge. Клиент, который получил прежнее соответствие через Pull, видит обычную корректную структуру. Ошибка заключена не в сообщении, а в расхождении между сохранённым местом и работающей сетью.

Flooding дорого обходится именно потому, что открыто признаёт незнание. Пограничный узел расширяет вопрос, если не знает назначения. Каталог меняет эту модель: Push заранее раздаёт адресные и маршрутные соответствия, Pull отвечает по запросу и разрешает кэширование. В крупном центре обработки данных это может уменьшить unknown unicast, ARP и IPv6 Neighbor Discovery, особенно при частом создании, удалении и перемещении виртуальных машин.

RFC 7067 сформулировал задачу и высокоуровневый дизайн в ноябре 2013 года. Linda Dunbar написала его вместе с Donald Eastlake, Radia Perlman и Igor Gashinsky. Это Informational RFC, а не спецификация Internet Standards Track. RFC 8171, созданный Donald Eastlake 3rd, Linda Dunbar, Radia Perlman и Yizhou Li, в июне 2017 года закрепил конкретные механизмы на Standards Track.

Linda Dunbar также входит в число пяти авторов RFC 8302 вместе с Yizhou Li, Donald Eastlake 3rd, Radia Perlman и Muhammad Umair, а RFC 8380 она подготовила с Donald Eastlake 3rd и Radia Perlman. Оба документа Standards Track опубликованы в 2018 году. Её профиль IETF Datatracker подтверждает участие в коллективной работе, но не единоличное изобретение, внедрение или результат в конкретной сети.

Заявление о полноте разрешает действие

Если неполный каталог не нашёл адрес, он доказал только предел собственного знания. Полный каталог для данного Data Label заявляет, что содержит все относящиеся к нему соответствия. RFC 8171 позволяет Push Directory server объявлять этот статус, и получатель меняет поведение на его основе.

Когда RBridge действительно получил полный набор, он может отбросить кадр к отсутствующему unicast-назначению вместо flooding. Если полнота заявлена ошибочно, та же оптимизация уничтожит трафик к существующему узлу.

Поэтому полнота — не декоративное свойство базы. Она превращает отрицательный ответ в разрешение прекратить поиск. «Нет данных у этого источника» сохраняет неопределённость. «Нет в доказанно полном множестве» допускает более сильный вывод. Единый статус not found стирает эту границу и даёт частичной базе полномочие отрицать сеть.

RFC 8171 отдельно ограничивает происхождение истины. Primary server должен получать данные надёжным способом, предназначенным для обеспечения свежести, однако этот способ находится вне рамок документа. Secondary server способен получать записи от primary. Протокол может безошибочно распространять устаревшее состояние, если система-источник пропустила последнюю миграцию.

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

Серверу приходится учитывать чужую память

Pull экономит запросы благодаря Lifetime. Положительная запись устаревает при перемещении или удалении узла. Отрицательная устаревает при последующем создании узла. Во втором случае пакеты не уходят не туда — клиент продолжает считать новое достижимое назначение несуществующим.

RFC 8171 требует от сервера с ненулевыми Lifetime посылать Update, чтобы сократить использование старых данных. Три метода различаются объёмом учёта. Самый грубый хранит сводные сроки по Data Label и при изменении может сбрасывать большие наборы. Самый точный отслеживает, какой клиент мог сохранить какую положительную или отрицательную запись и до какого времени. Он точнее исправляет, но требует больше центрального состояния.

Цена не исчезает. Меньше учёта на сервере означает больше широких сбросов и повторных запросов. Больше учёта означает, что каталог хранит предположение о кэше каждого клиента. Даже при правильной реализации остаётся короткий промежуток, когда сервер уже изменился, а удалённый кэш ещё не обновлён.

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

Confidence Level — это политика, а не измеритель истины

RFC 8302 использует соответствия IP/MAC/Data Label для оптимизации ARP/ND. Они могут поступать из управления, каталога или control plane, либо из наблюдения data plane. Источники ошибаются по-разному: ARP и ND без SEND легко подделать, защищённые административные данные можно неправильно настроить или обновить с задержкой.

Механизм Confidence Level позволяет реализации задать относительную надёжность. Полные и доверенные данные каталога способны ограничить вред поддельных ARP/ND. Неполные или сомнительные данные можно совместить с обучением по data plane и разрешать конфликт по уровню доверия.

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

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

Более раннее решение увеличивает радиус ошибки

RFC 8380 позволяет доверенным узлам, не являющимся RBridge, заранее инкапсулировать TRILL-трафик при помощи каталога. Зная egress RBridge, они сокращают обычное обнаружение и flooding. Одновременно часть полномочий перемещается ближе к источнику.

Раздел безопасности прямо описывает последствия. Недоверенный узел способен подделывать ingress и egress nicknames, внутренние и внешние MAC-адреса, а также узнавать существенную часть топологии. Атака на путь от каталога может доставить ложные соответствия, направить пакеты не тому получателю и нарушить политику доступа. RFC рекомендует аутентификацию и шифрование, своевременные обновления, корректную конфигурацию и минимальный доступ.

Защищённый путь не обновляет содержание. Идентичность источника, заявленный охват, относительное доверие, Lifetime, успешное исправление и наблюдаемая пересылка образуют разные поверхности доказательства. Чем раньше запись начинает действовать, тем меньше шансов у обычного пограничного устройства усомниться в ней.

Каталог должен оставаться опровержимым

Позднейшая идея Lu Heng о минимальной начальной спецификации, локализованном будущем решении и добровольном принятии служит Sofia Ren редакционной рамкой. Общими остаются только необходимые для совместимости формат, область, Push/Pull, полнота, истечение и исправление. Политика доверия, кэш, fallback и принятие риска остаются там, где несут последствия. Это более поздняя интерпретация, а не утверждение о замысле авторов RFC.

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

Четыре RFC не доказывают распространённость реализации, фактическое сокращение flooding, отсутствие потерь, время сходимости или предотвращение инцидентов. Они дают проверяемую структуру вопросов: кто создал данные, каков их охват, кто ещё хранит ответ, что может его отменить и когда работающая сеть приняла новое положение.

Надёжный каталог не только отвечает. Он сохраняет для сети право доказать, что ответ устарел.

Источники