Пост 3.4, патч 4, остановка репликации с PAN и CLI не удалось подключиться

[anilraj_003]

Пост 3.4, патч 4, остановка репликации между PAN и PSN, ошибка, сбой репликации Jediss, проблема с доступом к CLI — ошибка, не удалось подключиться к серверу. В журнале отладки выброшена ошибка: Ошибка, не удалось подключиться к серверу, не удалось подключиться к test-ise-01.net.lab/198.XX.XX.01:12001 Ошибка репликации: из отладки psn: -FullSync:- Первичный адрес нулевой

[anilraj_003]

RCA инженерной командой. Сочетание пути обновления -3.4.0-608->pathc-3-patch-4 и этой конфигурации SNMP привело к сбою CLI. Этот патч не принимает местоположение, в котором в поле snmp locaiton присутствует специальный символ «[]», и вызывает сбой всего кластера. Восстановление: загрузитесь с образа восстановления, смонтируйте sysimage, удалите поле locaiton из initial_configuration.xml. в opt.confd/confd-cdb. Затем отмените регистрацию узла и зарегистрируйте его обратно в кластере.

[Marcelo Morais]

@anilraj_003 Пожалуйста проверьте
порты
12001
на обоих
узлах
: ise/admin#
show ports | include 12001
...
198.xx.xx.01:12001
,
... проверьте
службы
на наличие
инициализации
или
неработающего
состояния
: ise/admin#
show application status ise
ISE PROCESS NAME STATE PROCESS ID

Database Listener
running
8436
Database Server running 203 PROCESSES
Application Server running 27824
... Проверьте, нет ли чего-либо
, что блокирует связь
между
узлами
. Справочник портов
Cisco ISE
: Руководство по установке Cisco ISE — версия 3.4 — Справочник портов Надеюсь, это поможет!

[anilraj_003]

Спасибо за информацию. В нашем случае доступ к CLI невозможен ни на одном узле (SSH / CIMC / последовательный порт сразу же отключаются после запроса на вход), поэтому мы не можем запустить команду «show application status ise» или проверить порты локально. У нас есть в общей сложности 15 физических узлов SNS36XX, которые, по сути, можно считать технически неработоспособными. Проблема: это не проблема репликации — это сбой ОС / оболочки / сервисного уровня на всех 15 узлах после установки патча 3.4 Patch 4, при котором сеансы CLI не могут запускаться, службы репликации PAN не отвечают, и кластер фактически находится в состоянии «смерти мозга». Журналы PSN подтверждают повторные попытки подключения к PAN на порту 12001, но служба репликации PAN не отвечает, и адрес Primary становится нулевым. Это исследуется TAC как проблема на уровне ОС, требующая восстановления. Вот и все.
Никаких дополнительных действий не требуется.

[Marcelo Morais]

@anilraj_003
, интересно... Мне немного любопытно, нет доступа
к CLI
через
SSH
или
консоль
, верно? Можете ли вы удалить
2 узла
из вашего
кластера из 15 узлов
,
SPAN
и
PSN
, чтобы создать
небольшую развертку
и протестировать репликацию этого нового
кластера
? Примечание 1: если ответ «да», то
SPAN
будет
PPAN
нового
кластера
. Примечание 2: я подумываю протестировать, была ли проблема специфична для
PPAN
или также для
SPAN
. Если
SPAN
в порядке, то вы можете перестроить весь
кластер
с использованием
SPAN
. Пожалуйста, держите нас в курсе расследования
TAC
! С уважением

[anilraj_003]

Спасибо за предложение. К сожалению, в нашем случае доступ к CLI недоступен (утрачен) на любом узле (P-PAN, S-PAN, PSNs, pxGrid, MNT). SSH, консоль и CIMC KVM демонстрируют одинаковое поведение: аутентификация проходит успешно, но сеанс оболочки немедленно закрывается. Я не могу поделиться скриншотом на этой платформе, но в выводе cli после ввода учетных данных для входа отображается сообщение «не удалось подключиться к серверу». Мы уже пытались переключить роль PAN на S-PAN после введения нового P-PAN, но это не помогло. Это указывает на то, что проблема не связана конкретно с ролью P-PAN, а носит системный характер для всего кластера. В журнале репликации, собранном из отладки, было обнаружено следующее: «org.jgroups.protocols.TUNNEL -:::::- Не удалось подключиться к GossipRouter по адресу pan-test.com/192.168.1.1:12001». В настоящее время мы сотрудничаем с Cisco TAC/BU/Engineering, которые исследуют эту проблему как сценарий на уровне ОС/восстановления. Мы поделимся обновлениями, как только TAC завершит анализ.

[Marcelo Morais]

@anilraj_003
, спасибо за ваш отзыв. Пожалуйста, держите нас в курсе! Примечание: в прошлом у меня были проблемы, которые возникали только при
распределенном развертывании
. Когда я удалил
SPAN
из
кластера,
и он стал
автономным
, проблема была устранена, и с этого момента я мог воссоздать
кластер
через этот
SPAN
.