Кратко
- Классическая процедура могла признать соседа достижимым после полученного Hello, не зная, слышит ли сосед обратное направление. Состояния Down, Initializing и Up отделяют одностороннее наблюдение от подтверждённой взаимности.
- Neighbor System ID и Extended Local Circuit ID привязывают ответ к нужной системе и линии. Однако Three-Way Up доказывает обмен IIH, а не синхронизацию LSDB, установку FIB, передачу данных или доступность сервиса.
Восемнадцать часов начинаются после успешного Hello
Традиционный точка-точка IS-IS предполагает свойства нижележащей сети из ISO 10589. Каждая сторона слышит Hello, объявляет другую достижимой и отправляет CSNP для запуска синхронизации. В первой ситуации RFC 5303 линия возвращается или один из маршрутизаторов перезапускается. Если CSNP потерян, а линия является единственным разрезом сети, базы могут расходиться полный период обновления LSP — до восемнадцати часов.
Hello в этом случае был настоящим. Ошибка возникает, когда наличие соседства автоматически превращают в утверждение об общей базе. Недостающий чек находится после формирования соседства.
Во второй ситуации линия теряет только одно направление. Один маршрутизатор видит отказ, другой нет. При одной линии SPF обычно отбросит односторонне объявленную связь. При двух параллельных линиях путь между системами всё ещё вычисляется. Не заметившая отказ сторона способна отправлять трафик именно в неработающее направление. Совокупная связность маскирует дефект элемента.
В третьей ситуации физическая среда меняет соединение конечных точек без link-down. Система получает пакеты для другого устройства или другого своего порта и принимает их как продолжение старого соседства. Доставка пакета состоялась, но его принадлежность ожидаемому каналу не установлена.
RFC 5303 опубликован в 2008 году как Standards Track и представляет небольшую редакцию RFC 3373, продвигавшую механизм из Informational. Это не отчёт о современном инциденте и не доказательство дефекта продукта. Документ полезен как точная карта границ доказательства.
От Down к Up движется знание, а не весь сервис
Опция Point-to-Point Three-Way Adjacency несёт отдельное состояние. Down означает отсутствие IIH с опцией на этом канале. Initializing означает, что такой IIH получен, но локальная система ещё не знает, получает ли сосед её IIH. Up означает, что это известно.
Three-Way State не равен состоянию соседства ISO 10589 и не эквивалентен ему. У одного соседства могут быть оба состояния. ISH способен изменить ISO-состояние, тогда как Three-Way останется Down до нужного IIH. Единый зелёный индикатор уничтожил бы именно ту разницу, ради которой введена опция.
Таблица переходов сохраняет расхождение взглядов. Локальный Up вместе с удалённым Down возвращает инициализацию. Локальный Down при полученном Up может удалить соседство с причиной «Neighbor restarted». Такие комбинации — временная запись о том, что каждая сторона знает о другой.
Даже Up имеет узкий смысл: сосед получает локальные IIH. Оно ничего не говорит о доставке CSNP, равенстве всех LSP, установке маршрута в FIB, двусторонней передаче пакетов и ответе приложения.
Возвратный сигнал должен назвать правильный канал
Взаимность возможна и после ошибочной физической коммутации. Поэтому опция может включать Neighbor System ID и Neighbor Extended Local Circuit ID. Если поля присутствуют и не совпадают с локальной системой или расширенным ID канала, PDU отбрасывается.
Старое представление создавало неявную проблему 256 интерфейсов, хотя фактическое ограничение LAN точнее. Реализации повторно использовали ID точка-точка, потому что они появлялись главным образом в IIH и помогали обнаружить смену удалённого конца. Повторное использование ослабляло защиту: перемещённая линия на порту с тем же малым номером могла казаться непрерывной.
Extended Local Circuit ID занимает четыре октета, назначается при создании и должен быть уникален среди линий системы. Связь со старым ID не требуется. Он не просто расширяет числовой диапазон, а даёт квитанции устойчивое имя отношения.
Сила такой привязки различается. Поддерживающая система обязана включать состояние, но другие поля имеют статус SHOULD. При их отсутствии обработка может продолжиться. Поэтому «Three-Way Up» и «Up с совпавшими System ID и Circuit ID» следует считать разными классами доказательств.
Совместимость сохраняет связь, принимая меньше уверенности
Старая система игнорирует опцию и не отправляет её. Современная система, получив IIH без опции, предполагает двустороннюю работу и использует старые процедуры. Это позволяет поэтапное внедрение. Одновременно это явное согласие жить без более сильной квитанции.
Инвентаризация должна показывать не только локальную поддержку, но и отправку, ответ, значение состояния, наличие и совпадение идентификаторов, а также fallback. После обслуживания соседство может остаться Up, хотя исчезнувшая опция снизила качество доказательства.
Аутентификация — отдельная колонка. RFC 5304 и RFC 5310 подтверждают происхождение от принятого ключа и целостность сообщения. Они не гарантируют правильную физическую коммутацию, сходимость LSDB и передачу. BFD в RFC 5880 наблюдает быстрый двусторонний forwarding как другой объект. Эти механизмы дополняют, а не заменяют друг друга.
Где заканчивается вывод
Статья не утверждает, что современная реализация имеет описанные недостатки, что оператор не включил расширение или что реальная база расходилась восемнадцать часов. Для таких выводов нужны версии, конфигурации, захват IIH, поля идентичности, сравнение LSDB, FIB и тесты данных.
Включённая опция тоже не исключает все пробелы. Старый сосед вызывает fallback, рекомендуемые поля могут отсутствовать, ключи живут по своей политике, а синхронизация и forwarding идут позже. Ограниченность результата не обесценивает механизм: он добавляет необходимые чеки о взаимности и канале.
Практическая граница проста: приём не называть взаимностью, взаимность без имени не называть идентичностью канала, идентичность не называть сходимостью, а сходимость — доставленным сервисом.
Источники
- RFC 5303: трёхстороннее рукопожатие для точка-точка IS-IS
- RFC 5303 в текстовом виде
- Информация RFC Editor о RFC 5303
- Карточка RFC 5303 в IETF Datatracker
- История RFC 5303
- Ссылки из RFC 5303
- Документы, ссылающиеся на RFC 5303
- Исправления RFC 5303
- RFC 1195: OSI IS-IS в средах TCP/IP
- RFC 3373: предшествующий механизм
- RFC 3359: резервные коды TLV IS-IS
- RFC 5304: криптографическая аутентификация IS-IS
- RFC 5310: универсальная криптографическая аутентификация IS-IS
- RFC 5301: динамический обмен именами узлов
- RFC 5302: распределение префиксов по домену
- RFC 5305: расширения IS-IS для Traffic Engineering
- RFC 5880: Bidirectional Forwarding Detection
- Heng Lu: On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
- Heng Lu: Running Code Primary
- Heng Lu: On the Agency Problem at the Core of Internet Governance
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
