Reply to IS-IS, команда no adjacency-check on Fri, 13 Feb 2026 19:57:37 GMT

M02@rt37 — Fri, 13 Feb 2026 19:57:37 GMT

Привет, Дэвид Рад видеть, что ты продвигаешься в своем обучении!!! Короче говоря: только маршрутизатор, который объявляет дополнительную семью адресов, выполняет проверку смежности... в вашем случае, R1. С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените.ı|ı.ı|ı.

Reply to IS-IS, команда no adjacency-check on Fri, 13 Feb 2026 19:57:36 GMT

Cristian Matei — Fri, 13 Feb 2026 19:57:36 GMT

Привет, @Mitrixsen
Прежде всего, то, что будет сказано далее, относится исключительно к Cisco, ваш опыт работы с другими поставщиками может в определенной степени отличаться. Следующее относится к IOS-XE, IOS-XR и NX-OS. Во-вторых, мы говорим о работе с одной топологией ISIS, поскольку обсуждение нескольких топологий будет совершенно иным.
Проверка смежности
используется для двух целей. Когда ISIS объявляет в TLV 129 только AFI/NLPID IP/IPv4 через пакеты HELLO для формирования соседства, помимо прочих требований, Cisco выполняет проверку, чтобы обе стороны соседства имели общую подсеть IPv4 (проверяется TLV 132, здесь утекает IPv4-адрес, настроенный на канале). Это своего рода лучшее усилие, далеко не идеальное, поскольку в TLV 132 утекает только IPv4-адрес канала, маска подсети не утекает ни в TLV 132, ни в каком-либо другом TLV. Если удаленно представленный IPv4-адрес канала не включен в локально настроенную подсеть IPv4 на канале, соседство не формируется (чтобы избежать ненужного потребления ресурсов ЦП для соседства ISIS, обновлений, дерева SPF, вычисления лучших путей для префиксов и, в конечном итоге, невозможности заполнения префиксов в RIB из-за недоступности NH). Опять же, вы можете легко обмануть алгоритм, поскольку маска подчинения не объявляется, имея одну сторону с 10.10.10.1/24, а другую сторону с 10.10.10.2/8, и соседство все равно будет сформировано, однако, если одна сторона имеет 10.10.10.1/24, а другая сторона имеет 20.20.20.2/24, соседство не будет сформировано; в этом сценарии, чтобы обойти эту проверку и позволить сформировать соседство, вы настраиваете для NLPID IPv4
no adjacency-check
(в IOS-XE непосредственно под конфигурацией маршрутизатора isis, в NX-OS под IPv4 AFI) или
adjacency-check disable
(в IOS-XR под IPv4 AFI). Это относится только к IPv4, так как в IPv6 все IGP работают на адресах LLU IPv6 (FE80::/10), поэтому эта проверка будет бесполезна. В стандарте IS-IS нет строгих требований к тому, чтобы два маршрутизатора строго согласовывали поддерживаемые/объявленные NLPID для формирования соседства (ITU-T для SONET/SDH требует, чтобы обе стороны объявляли по крайней мере один общий NLPID, но не идеальное совпадение всех объявленных NLPID). В результате каждый поставщик использовал немного разные подходы. В случае Cisco, когда IPv6 NLPID рекламируется вместе с IPv4 NLPID только на одной стороне (другая сторона рекламирует только IPv4 NLPID), два маршрутизатора не могут установить соседство из-за включенной
проверки соседства
. После отключения этой проверки (под AFI IPv6) соседство будет успешно установлено, так как теперь это требование больше не применяется. Почему это работает, если отключить его только на стороне, где рекламируется IPv6 AFI / NLPID, потому что на этой стороне AFI / NLPID включен / активен, и поэтому именно эта сторона может выполнять проверку; сторона, на которой IPv6 AFI / NLPID не включен, ведет себя так, как будто не распознает дополнительную рекламу, что по стандартам ISIS означает игнорировать ее и продолжать работу без принятия каких-либо мер. На практике это используется, когда вы хотите активировать IPv6 NLPID, и чтобы не потерять соседство в процессе, вы сначала отключаете проверку на всех маршрутизаторах, активируете IPv6 NLPID, а затем можете безопасно включить проверку снова. Спасибо, Кристиан.