Кратко

  • RFC 5185 использует Area ID для выбора смежности, но пакет backbone может одновременно совпасть с virtual link и multi-area adjacency. Это ошибка конфигурации, которую надо устранить до работы.
  • Тот же принцип нужен инвентарю: пока не доказано, являются ли две логические грани разными физическими каналами, нельзя объявлять независимость, складывать ёмкость или обещать резервирование.

Пакет был синтаксически правильным и пришёл от ожидаемого соседа. Одна запись сопоставления относила его к virtual link, другая — к дополнительной смежности backbone. Обе интерпретации выглядели законными.

RFC 5185 не предлагает выбрать первую. Совпадение означает ошибку конфигурации, которую следует обнаружить при создании. Детерминированная очередь обработки не превращает неоднозначность в истину.

Зачем одному интерфейсу несколько областей

Стандарт 2008 года рассматривает быстрый backbone-канал между ABR и более медленные внутренние пути другой области. Поскольку OSPF предпочитает intra-area, трафик может обходить быстрый канал. Дополнительная смежность делает его intra-area-путём и не удаляет из backbone.

Virtual link потребовал бы иного членства, secondary addresses расходуют адреса, не подходят unnumbered и добавляют маршруты, а одна адресованная подсеть в нескольких областях противоречит модели. Поэтому расширение добавляет логический контекст, а не новый физический линк.

Area ID разделяет состояния

Для каждой multi-area adjacency создаётся отдельная OSPF interface structure типа point-to-point независимо от нижнего network type. Neighbor FSM остаётся стандартной, primary adjacency продолжает RFC 2328.

На непунктовом носителе адрес соседа задаётся или узнаётся внешним механизмом, затем пакеты идут unicast. Area ID входящего пакета выбирает контекст. Именно здесь конфликт с virtual link должен быть запрещён конфигурацией.

После FULL связь попадает в Router-LSA как type 1: Link ID равен remote Router ID, Link Data — neighbor IP или IfIndex для unnumbered. Type 3 для multi-area не объявляется.

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

Неизвестное нельзя считать разнообразием

Инвентарь часто получает грани раньше, чем физические связи. Если две смежности имеют разные Area ID, это ещё не доказывает разные circuit ID. Без связи с портом, картой, LAG member, провайдером и трассой вывод о diversity должен оставаться запрещённым.

RFC 3630 описывает TE metric, maximum bandwidth, reservable и unreserved bandwidth, administrative group. Повтор этих значений на трёх гранях одного 100-Гбит/с канала не даёт 300 Гбит/с.

В терминах слоёв реальности Heng Lu, граф — символическая исполнимая модель; оптика, счётчики и фактический путь пакета — работающий слой. Join между ними должен быть доказательством, а не догадкой по имени.

Изменение SPF меняет и blast radius

Новая intra-area-грань привлекает трафик на быстрый общий канал. Надо сохранить LSDB, SPF, RIB, FIB, нагрузку, потери, очереди и запас альтернатив до и после. Иначе команда увидит улучшение метрики, но не концентрацию риска.

Stub-router из RFC 6987 и reverse metric из RFC 9355 могут дренировать или перенаправлять трафик, не меняя кабель. Результат подтверждается наблюдаемым forwarding, не наличием настройки.

Асимметрия допустима, карта обязательна

Удалённая сторона должна лишь моделировать связь как point-to-point; одинаковая multi-area-конфигурация не обязательна. Симметрия рекомендована для представления и диагностики.

Это поддерживает добровольное внедрение, но требует хранить обе точки зрения: Router IDs, роли ABR, версии, интерфейсы, происхождение neighbor address, Area IDs и общий physical ID. Иначе совместимые устройства создают несовместимые оперативные рассказы.

OSPFv3 не требует выдуманного префикса

Router-LSA OSPFv3 отделена от адресной семантики. Префиксы multi-area adjacency не объявляются в intra-area-prefix-LSA, link-LSA объявлять не следует, а link-local адрес можно узнать из Hello.

Топологическая грань без нового префикса корректна. Модели топологии, адресов и ресурсов нужно соединять, а не заполнять пробел вымышленными объектами.

Проверяемая запись изменения

Она включает change ID и snapshot; Router IDs, роли и builds; интерфейс, neighbor и его источник; circuit, карту, провайдера и shared risk; primary и дополнительные adjacencies; Area IDs; network type; времена FSM; Link ID, Link Data, metric и отсутствие type 3; OSPFv3-поведение; LSDB, SPF, RIB, FIB и traffic; ёмкость один раз; асимметрию; проверку virtual link; drain, rollback и итог.

RFC 5185 оставляет локальным сетям право на будущие решения и даёт минимальный общий механизм. Это право сохраняется только тогда, когда неоднозначность блокирует действие, а не маскируется технически повторяемым выбором.

Источники

  1. RFC 5185 HTML
  2. RFC 5185 текст
  3. RFC Editor
  4. IETF Datatracker
  5. История
  6. Ссылки
  7. Errata RFC 5185
  8. RFC 2328 OSPFv2
  9. RFC 2328 информация
  10. RFC 5340 OSPFv3
  11. RFC 5340 информация
  12. RFC 3630 Traffic Engineering
  13. RFC 6987 Stub Router
  14. RFC 7770 Optional Capabilities
  15. RFC 8665 Segment Routing
  16. RFC 9355 Reverse Metric
  17. RFC 3137 Stub Router
  18. Heng Lu — слои реальности
  19. Heng Lu — минимальная спецификация
  20. Heng Lu — приоритет работающего кода