
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:
CSCtx12231
Config 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 зроблю апдейт поста або відпишуся в коментарях.
Всім удачі на бойовому терені!