Сегодня я продолжу рассказ о неочевидных нюансах работы коммутатора ядра Cisco Catalyst 6509 в режиме VSS. Поскольку многие люди используют эту платформу в своей инфраструктуре, я считаю, что эта история может быть кому-то полезна.
Увлекательные истории с ВСС начались год назад и описаны в этом почта .
Итак, ровно через год, на январском ежеквартальном ТО этого года, как обычно, в план работ был включен пункт «пылесос стержневой».
Напомню, что ядро нашей сети — это VSS-пара коммутаторов Cisco Catalyst 6509. Вот краткая информация для статистики: 
Каждый коммутатор имеет на борту один SUP Engine 720 10GE.
Процесс удаления пыли было решено начать с помощью пылесоса с резервным шасси.
Выключил и пропылесосил.
Включил.
Картина маслом — шасси Standby ушло в циклическую перезагрузку из-за ошибки синхронизации конфига: 
Если вам интересно, как развивались события дальше,
На этот раз было решено не проявлять героизма и инициативы и просто отключить резервное шасси.
Так они и сделали.
Мы остались летать на главном крыле.
На производительность сети не повлияли циклические перезагрузки резервного шасси.
Утром вся необходимая информация была отправлена в техподдержку интегратора, а он, в свою очередь, открыл кейс в ТАС Cisco и стал ждать.
Ответ от CTAC пришел быстро.
Нам было предложено воспроизвести ситуацию с циклической перезагрузкой и удалить следующий отладочный код при включенном резервном шасси: «Массовая синхронизация конфигурации избыточности отладки» «отладка прогресса избыточности» Ночью отладку сняли и отправили в CTAC. Я не публиковал это здесь.
Текста много, а понимания мало.
CTAC сообщил, что такое поведение описано в DDTS: CSCtx12231 Синхронизация конфигурации: сбой массовой синхронизации из-за несоответствия PRC в ACL. Tools.cisco.com/bugsearch/bug/CSCtx12231/Эreffering_site=dumpcr
Поскольку для просмотра вам понадобится учетная запись на cisco.com, я опубликую скриншот здесь: 
Однако наш выпуск 12,2(33)SXJ6 указан там как Известные фиксированные выпуски .
Непонятно, что происходит. Нас попросили удалить повторяющиеся строки (ACE) из ACL, которые были представлены в выводе «show redundancy config-sync error prc»: 
и попробуйте загрузить резервное шасси.
У нас сразу возникли вопросы, ответы на которые от CTAC я приведу ниже на скриншоте: 1. Можно ли сразу проверить корректность удаления дубликатов ACE, используя вывод «show redundancy config-sync error prc» или другим способом, или мне придется запустить standby, чтобы это проверить? 2. Будет ли этот баг препятствовать переходу в режим ожидания, если активное шасси было перезагружено? 3. У нас были ситуации, когда IOS не позволял добавить дубликат ACE. Хотелось бы четко понимать сценарии, когда такая проверка выполняется, а когда нет (предположительно связано с группами объектов).
Вам нужно знать, где быть особенно осторожным и что следует проверить дважды.
В результате мы удалили дублирующиеся ACE из конфига активного шасси при выключении режима ожидания, но после этого вывод «show redundancy config-sync error prc» не изменился, что указывало на то, что данная проверка будет происходить при попытке загрузки резервное шасси.
Планировалось очередное техническое окно, в ходе которого было запущено резервное шасси.
В результате все заработало, из вывода «show redundancy config-sync отказы прк» исчезли сообщения о дублирующихся ACE. Сейчас всё работает, особое внимание уделяем редактированию ACL, чтобы ситуация не повторилась.
На вопросы о том, как так получилось, что наш релиз IOS числится как исправленный от этой ошибки и почему в свое время IOS все же позволяла вводить дублирующиеся ACE - ждем ответов от Cisco TAC. Если появится новая информация от CTAC, я обновлю пост или напишу в комментариях.
Удачи всем на боевом поприще! Теги: #cisco #cisco #Сетевые технологии #VSS #cisco vss #синхронизация конфигураций
-
Rbk.money —> Основа
19 Oct, 24 -
Стратегический План На Год
19 Oct, 24 -
Метка: Как Правильно Писать?
19 Oct, 24
