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

Всім удачі на бойовому ниві!

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.