Cisco VSS: баг, который не был исправлен
Сегодня я продолжу рассказ о не очевидных нюансах работы коммутатора уровня ядра Cisco Catalyst 6509 в режиме VSS. Поскольку многие используют данную платформу в своей инфраструктуре, полагаю, что этот рассказ кому-то может быть полезен.Начало увлекательных историй c VSS было положено год назад и описано в этом посте.
Итак, ровно год спустя на январской квартальной профилактике этого года по обыкновению в план работ был включен пункт «пылесос ядра». Напомню, что ядро нашей сети составляет VSS-пара коммутаторов Cisco Catalyst 6509. Вот краткая информация для статистики:
Каждый коммутатор имеет на борту по одному SUP Engine 720 10GE.Было решено начать процесс удаления пыли методом пылесоса с standby-шасси. Выключили, пропылесосили. Включили. Картина маслом — Standby-шасси ушло в циклическую перезагрузку из-за ошибки синхронизации конфига:
Если Вам интересно как развивались события дальше,
В этот раз было решено не проявлять героизма и самодеятельности и просто выключить standby-шасси. Так и сделали. Остались лететь на основном крыле. Работоспособность сети во время циклических перезагрузок standby-шасси затронута не была. На утро вся необходимая информация была отправлена в техническую поддержку интегратора, а тот в свою очередь открыл кейс в Cisco TAC и стали ждать. Ответ от CTAC последовал быстро. Нам было предложено воспроизвести ситуацию с циклической перезагрузкой и снять следующий дебаг при включенном standby-шасси:
«debug redundancy config-sync bulk«debug redundancy progression»
Ночью дебаг сняли и отправили в CTAC. Здесь публиковать не стал. Там много текста и мало понятного.CTAC сообщил, что данное поведение описано в DDTS: CSCtx12231Config Sync: Bulk-sync failure due to PRC mismatch in ACL
tools.cisco.com/bugsearch/bug/CSCtx12231/? reffering_site=dumpcr
Поскольку для просмотра нужна учетка на cisco.com, то выложу сюда скрин:
Однако, наш релиз 12.2(33) SXJ6 там числится как «Known Fixed Releases». В чем дело непонятно. Нам было предложено убрать дублированные строки (ACE) из ACL, которые были представлены в выводе «show redundancy config-sync failures prc»:
и попробовать загрузить standby-шасси. У нас сразу же возникли вопросы, ответы на которые от CTAC я приведу ниже на скриншоте:
1. Можно ли по выводу «show redundancy config-sync failures prc» или иным способом сразу проконтролировать корректность удаления дублированных ACE, или придётся запускать standby для того, чтобы это проверить?
2. Помешал ли бы этот баг переключению на standby, если бы было перезагружено активное шасси?
3. У нас были ситуации, когда IOS не позволял добавить дублирующий ACE. Хотелось бы чётко понять сценарии, когда такая проверка выполняется, а когда нет (предположительно, связано с object-группами). Нужно знать, где быть особенно осторожным и что перепроверять.
В итоге мы удалили дублированные ACE из конфига активного шасси при выключенном standby, но после этого вывод «show redundancy config-sync failures prc» не изменился, что свидетельствовало о том, что данная проверка произойдет при попытке загрузки standby-шасси. Было запланировано очередное техническое окно, во время которого произвели запуск standby-шасси. Итог — все завелось, сообщения о дублированных ACE пропали из вывода «show redundancy config-sync failures prc».
Сейчас все работает, особое внимание уделяем редактированию ACL, дабы не допустить повторения ситуации. На вопросы как так получилось, что наш релиз IOS числится как исправленный от этого бага и почему в свое время IOS все же позволил внести дублированные ACE — ждем ответы от Cisco TAC.
При появлении новой информации от CTAC сделаю апдейт поста или отпишусь в комментариях.
Всем удачи на боевом поприще!
