трехстороннее согласование IS-IS

Reply to трехстороннее согласование IS-IS on Fri, 13 Feb 2026 19:58:15 GMT

Cristian Matei — Fri, 13 Feb 2026 19:58:15 GMT

Привет, @Mitrixsen
С самого начала, как объяснялось ранее, в локальных сетях существовал способ обеспечить двустороннюю подтвержденную/функциональную доступность перед переходом соседства в состояние UP, но в сетях PTP эта концепция не учитывалась. Почему? Ну, я не нашел этого в письменном виде где-либо в виде четкого заявления. OSPF имеет эту проверку независимо от типа сети, поэтому OSPF имеет лучший дизайн в этом отношении, и теперь, задним числом, мы можем считать это недостатком дизайна IS-IS, но судить об этом всегда легко. Мое мнение относительно этой первоначально отсутствующей функции в IS-IS таково (опять же, это могло быть принято во внимание, это было, скажем, архитектурное решение, принятое в тот момент): 1. С технической точки зрения, на PTP-связях ДОЛЖНЫ быть только два объекта; однако реальная жизнь, особенно с развитием и добавлением PTP-протоколов, показала нам, что это не всегда так. 2. На PTP-связях SNPA идентифицирует либо сам протокол (PPP, HDLC, поскольку здесь нет идентификатора конечной точки/маршрутизатора в соответствии с технологией), либо идентификатор VC (ATM, Frame-Relay, где VC идентифицирует цепь, а не конечную точку/маршрутизатор). Увидев на практике, что это убеждение может привести к хаосу в определенных условиях (некоторые из них описаны в RFC5303 в разделе «Введение»), необходимость обеспечить двустороннюю связь перед переходом соседства IS-IS в состояние UP для PTP-связей стала чем-то, что необходимо было решить. Почему SNPA не был использован и в этом случае, см. мои вышеуказанные заявления, так как в случае PTP SNPA, используемый IS-IS, не идентифицирует конечную точку. Почему System ID был выбран как наиболее подходящий? Ну, опять же, можно было бы создать новый TLV с новым IS-IS, давайте упрощенно назовем его идентификатором, однако зачем усложнять, если в общем заголовке уже есть то, что уникально идентифицирует каждый IS / маршрутизатор, а именно System ID; поэтому я считаю, что System-ID был выбран для выполнения этой задачи в рамках вновь добавленного TLV 240. Помимо прочего, этот TLV объявлял состояние смежности, и вот как он работает (реализация RFC5303, а не проприетарная реализация Cisco, которая немного отличается в плане объявления только состояния смежности): 1. И левая, и правая стороны отправляют свои PDU ISIS HELLO с состоянием соседства в TLV 240, помеченным как DOWN. 2. Предполагая, что вышеуказанный PDU ISIS HELLO получен каждой стороной, каждая сторона добавит соседство IS-IS в базу данных соседства в состоянии INIT, и когда она теперь отправит следующий PDU ISIS HELLO, она укажет состояние соседства в состоянии INIT вместе с добавлением удаленного System ID, чтобы сигнализировать, что она получила HELLO с состоянием соседства в состоянии DOWN. 3. Предполагая, что вышеуказанный PDU ISIS HELLO получен каждой стороной, каждая сторона переведет соседство IS-IS в базе данных соседства в состояние UP, и когда она теперь отправит следующий PDU ISIS HELLO, она укажет состояние соседства как UP, сохранив при этом узнанный системный ID удаленной стороны, чтобы сигнализировать, что она получила HELLO с состоянием соседства INIT. На этом этапе начинается обмен LSP, поскольку обе стороны, благодаря переходам состояния соседства, указанным в TLV 240, поняли, что удаленная сторона получила HELLO как в состоянии DOWN, так и в состоянии INIT; поэтому, как только эти два пакета HELLO принимаются каждой стороной, этого считается достаточным для функциональной двусторонней связи и перехода состояния смежности в состояние UP, что приводит к началу обмена LSP. Таким образом, в случае PTP каждая сторона отправляет и получает как минимум три HELLO, каждый из которых выделяет другое состояние смежности (DOWN, INIT, UP), по этой причине это называется
THREE-WAY-HANDSHAKE
, чтобы «подтвердить/проверить» функциональную
двустороннюю
связь. Чтобы немного запутать или, надеюсь, прояснить ситуацию, в данном случае трехстороннее рукопожатие является однонаправленным (по 3 пакета в каждом направлении, прежде чем каждая сторона считает соседство UP, то есть 6 пакетов в общей сложности), в отличие от TCP, в котором трехстороннее рукопожатие является двунаправленным (3 пакета в общей сложности). Напротив, реализация LAN немного отличается, в том числе и тем, что, помимо всего прочего, что было объяснено в моем предыдущем посте, самое главное, что состояние соседства каждой стороны не сигнализируется в пакетах HELLO. По этой причине каждая сторона отправляет как минимум два пакета HELLO, прежде чем соседство будет считаться установленным локально на каждой стороне, однако каждой стороне может потребоваться отправить как минимум три пакета HELLO, прежде чем соседство будет считаться установленным локально на каждой стороне.
Вам предстоит ответить, в каком случае применяется тот или иной вариант
. Однако, независимо от этого, как только эти условия выполняются,
двусторонняя
функциональная связь «подтверждается/валидируется»; в документах RFC или ISO для LAN нет конкретного упоминания о том, что этот процесс называется двусторонним или трехсторонним рукопожатием, поэтому можете понимать это как хотите; в большинстве литературы это все же называется трехсторонним рукопожатием. Интересный факт: исходя из того, как был написан RFC5303, чтобы сохранить обратную совместимость с системами, в которых эта функция еще не активирована, и как Cisco реализовала свою проприетарную версию (был использован тот же код TLV), реализация RFC обратно совместима с реализацией Cisco, что означает, что одна сторона может использовать реализацию Cisco, а другая — реализацию RFC, и агентство будет работать. Очевидно, что такие сценарии являются лишь предметом для лабораторных исследований, в производстве вы всегда будете использовать один и тот же метод на обеих сторонах. IOS-XR работает только с версией IETF. Старые коды IOS-XE работают с версией Cisco по умолчанию, новые коды IOS-XE работают с версией IETF по умолчанию, обе версии поддерживают переключение между режимами. Да, прочтите мой пост несколько раз, попрактикуйтесь в лаборатории, выполните захват пакетов, и все будет ясно. Спасибо, Кристиан.

Reply to трехстороннее согласование IS-IS on Fri, 13 Feb 2026 19:58:14 GMT

paul driver — Fri, 13 Feb 2026 19:58:14 GMT

Hello
FYI
«для повышения надежности P2P hello TLV 240 был введен — он содержит список sysids всех соседей, известных инициатору rtr, и индикатор, показывающий состояние этого соседства». RFC 3373
3-стороннее состояние
UP=0
Инициализация =1
Down = 2
Cisco Routing tcp/ip том 2
Работа интегрированного isis -
3
-стороннее
рукопожатие
страница 555 Пожалуйста, оцените и отметьте как принятое решение, если вы нашли какую-либо из предоставленной информации полезной.
Это поможет другим участникам форума найти ценный ответ и расширит глобальную сеть сообщества.
С уважением,
Пол

Reply to трехстороннее согласование IS-IS on Fri, 13 Feb 2026 19:58:13 GMT

Mitrixsen — Fri, 13 Feb 2026 19:58:13 GMT

Здравствуйте, Кристиан, Очень хорошо объяснено, спасибо всем
@Giuseppe Larosa
@paul driver
. Еще одно уточнение. Если IS-IS уже реализовал двустороннюю проверку доступности на сегментах LAN (через SNPA), знаем ли мы, почему они решили сделать отдельную для P2P? Мне просто непонятно, почему они реализовали эту функцию, но в сегментах P2P используется совершенно новая (трехстороннее рукопожатие), которая включает системный ID соседнего маршрутизатора. И еще одно. Обе эти проверки связи считаются двусторонними или трехсторонними? Учитывая, что вы,
@Cristian Matei,
описали LAN как двустороннюю проверку. Я понимаю и то, и другое следующим образом: ![Mitrixsen_0-1767982657376.png] Что технически является трехэтапным процессом. Еще раз спасибо!

Reply to трехстороннее согласование IS-IS on Fri, 13 Feb 2026 19:58:12 GMT

Cristian Matei — Fri, 13 Feb 2026 19:58:12 GMT

Привет, @Mitrixsen
Причина, по которой не было и нет необходимости добавлять функцию трехстороннего рукопожатия для LAN / широковещательных каналов связи после первоначальной разработки IS-IS, заключается в том, что с самого начала IS-IS через LAN имел встроенное двустороннее ФУНКЦИОНАЛЬНОЕ рукопожатие на основе адреса SNPA (очень похожее на двустороннее рукопожатие OSPF, однако в OSPF двусторонняя связь определялась на основе значения ROUTER-ID, в отличие от IS-IS, который основан на адресе SNPA). Представьте, что у вас есть новое соединение LAN и два маршрутизатора IS-IS подключаются к сети (я сейчас обойду / не буду учитывать процесс выбора DIS, чтобы упростить объяснение двустороннего рукопожатия) и для простоты предположим, что оба работают как L2 по цепи (для L1 это был бы тот же процесс, только с другим соседством) и все необходимые требования IS-IS к соседству в остальном выполняются с точки зрения конфигурации: 1. R1 отправляет сообщение ISIS L2 HELLO PDU по каналу. 2. R2 получает сообщение ISIS L2 HELLO PDU от R1 по каналу связи, берет адрес SMAC из заголовка кадра Ethernet, добавляет новое соседство ISIS в свою базу данных соседства с этим новым маршрутизатором IS, от которого он получил HELLO, однако в состоянии INIT, поскольку этот маршрутизатор еще не знает, работает ли двусторонняя связь (таким образом, обмен LSP еще не произошел) и использует адрес SMAC в качестве SNPA. 3. R2 отправляет сообщение ISIS L2 HELLO PDU по каналу связи, однако, поскольку он получил сообщение IS-IS L2 HELLO PDU по каналу связи от R1, в отличие от TLV в HELLO, полученном от R1, в своем сообщении HELLO R2 вставит TLV 6 (список соседей IS) и в этот TLV вставит MAC-адрес Ethernet R1. 4. R1 получает сообщение ISIS L2 HELLO PDU от R2 по каналу связи, и поскольку он видит в TLV 6 свой собственный MAC-адрес на канале связи, что означает наличие двунаправленной связи между ними, он берет SMAC-адрес из заголовка Ethernet-кадра, добавляет новую соседскую связь ISIS в свою базу данных соседских связей с этим новым маршрутизатором IS, от которого он получил HELLO, однако в состоянии UP (обмен LSP теперь может начаться) и используя адрес SMAC в качестве SNPA. 5. R1 отправляет сообщение ISIS L2 HELLO PDU по каналу связи, однако, поскольку он получил сообщение IS-IS L2 HELLO PDU по каналу связи от R2, R1 вставит TLV 6 (список соседей IS) и в этот TLV вставит MAC-адрес Ethernet R2. 6. R2 получает сообщение ISIS L2 HELLO PDU от R2 по каналу связи, и поскольку он видит в TLV 6 свой собственный MAC-адрес на канале связи, что означает наличие двунаправленной связи между ними, переводит существующее соседство ISIS из состояния INIT в состояние UP (теперь можно начинать обмен LSP). Спасибо, Кристиан.

Reply to трехстороннее согласование IS-IS on Fri, 13 Feb 2026 19:58:11 GMT

paul driver — Fri, 13 Feb 2026 19:58:11 GMT

Привет
P2P отличается от приветствий в локальной сети. Приветствия
в локальной сети требуют трехстороннего рукопожатия, поскольку маршрутизаторы в локальной сети должны знать всех своих соседей, которые активны в этой локальной сети.
В P2P-соседстве это не требуется, поэтому двухстороннее рукопожатие считается необходимым. Отредактировано — только что посмотрел. В приветствии LAN есть IS neighbour TLV, отвечающий за это — он выполняет ту же функцию, что и приветствия списка соседей ospf — isis rtr, который видит свой собственный sysid в IS neighbour TLV полученных приветствий LAN, знает, что двунаправленная связь подтверждена. Cisco Routing TCP/IP, том 2,
работа интегрированного ISIS,
стр. 555.
Также
Cisco ISIS TLVS
— TVL 240 P2P 3-стороннее соседство. Пожалуйста, оцените и отметьте как принятое решение, если вы нашли полезной какую-либо из предоставленной информации.
Это поможет другим участникам форума найти ценный ответ и расширит глобальную сеть сообщества.
С уважением,
Пол

Reply to трехстороннее согласование IS-IS on Fri, 13 Feb 2026 19:58:10 GMT

Giuseppe Larosa — Fri, 13 Feb 2026 19:58:10 GMT

Здравствуйте
[, @Mitrixsen]
, в сегменте LAN есть DIS, и каждый маршрутизатор с поддержкой IS-IS устанавливает соседство с DIS. Только устройства, которые установили соседство с DIS, перечислены в псевдоузле DIS LISP. Поэтому двустороннее рукопожатие необходимо только на точечных соединениях. Если я правильно помню, существует два вида рукопожатия: один — IETF, а другой — проприетарный Cisco. В проприетарной версии Cisco добавляется идентификатор локальной цепи для идентификации канала. Надеюсь, это поможет Джузеппе