Перемикач Connectrix серії B: Дефекти FOS-849642 і FOS-847091 - Директори та комутатори 7-го покоління можуть зіткнутися з проблемою збою, яка спричиняє помилки CRC, несправності портів або спричиняє перезавантаження

Продукти, на
які поширюється діяBrocade X7-8, X7-4, 7730 і 7720 під керуванням FOS v9.1.x або FOS v9.2.0
Виправлено у випусках
Brocade FOS v9.1.1c, v9.2.0a та новіших версій

У зоні ризику лише продукти Gen 7.
Директори 7-го покоління (X7-8 і X7-4) із встановленими лопатями портів FC64-48 та/або FC32-X7-48 ризикують зіткнутися як з помилками переповнення, так і з помилками «перевірки». Лопаті портів FC32-64 і FC32-48, встановлені в директорах 7-го покоління, не ризикують зіткнутися з будь-якою з цих поломок.
Комутатори 7-го покоління (G730 і G720) ризикують зіткнутися лише з несправністю переповнення буфера. Ці перемикачі не піддаються і не ризикують зіткнутися з помилкою
«перевірити».Щоб надалі піддаватися ризику, тканина повинна зазнавати сильних перевантажень, що призводить до управління надмірною підпискою за допомогою Traffic
Optimizer. Наступне повідомлення RASlog буде спостерігатися, якщо коли-небудь зустрічався такий рівень відповіді: Дія з керування перевищенням підписки за допомогою Оптимізатора трафіку існує лише в мікропрограмі FOS версії 9.1.x. Продукти
7-го покоління, що працюють на FOS v9.0.x, не піддаються ризику будь-якої з умов несправності.

Умови
ризику переповнення буфераДля того, щоб виник стан переповнення буфера, крім того, що він вимагає періоду сильного перевантаження, F-порти на директорі або комутаторі Gen 7
також повинні бути налаштовані від значення за замовчуванням до більшої кількості буферів. За замовчуванням FOS призначає
не більше 28 буферів.
Будь-який директор або комутатор 7-го покоління, у якого максимальна кількість буферів F-Port була збільшена вище значень за замовчуванням, що використовуються FOS
, потенційно піддаються ризику, і будь-який директор X7-8 або X7-4, який раніше працював під керуванням FOS v9.0.x, може бути схильний до ризику зіткнутися
з помилками «перевірки». В обох випадках оптимізатор трафіку також повинен намагатися керувати маршрутизацією кадрів у відповідь на
подію перевищення, спричинену періодом сильного перевантаження.

Щоб визначити директорів і комутатори, які можуть бути в зоні ризику, використовуйте команду "portbuffershow" для перегляду використання буфера Якщо загальна сума всього використання

буфера для портів на тому ж ASIC/чіпі, які також зоновані разом, становить значення, що перевищує 256 буферів, то комутатор Gen 7 вважається ризикованим зіткнутися з переповненням буфера, якщо серйозна подія перевантаження вимагатиме керування перепідпискою від Traffic Optimizer. Збій не буде виникати під час кожної події керування перепідпискою, оскільки кількість буферів, якими керують на момент події, має перевищувати 256, поки Traffic Optimizer керує перепідпискою, але налаштування на потенційну обробку понад 256 буферів поставить перемикач під загрозу.
У наведеному вище прикладі виведення, якщо всі 8 F-портів знаходяться в одній зоні разом, комутатор ризикує зіткнутися з переповненням буфера кадрів, поки оптимізатор трафіку керує умовою перепідписки, оскільки загальна кількість використання буфера
в цьому прикладі становить 360.
Однак, у наступному прикладі, де F-порти не всі зоновані разом, цей перемикач не буде під загрозою, оскільки дві зони (показані зеленим кольором) сумарно складають 232 буфери та 128 буферів відповідно.

Максимальна кількість портів, що використовуються для керування перепідпискою, становить 8 портів. Якщо більше 8 портів зоновано разом від одного ASIC/чіпа, то для визначення ризику об'єднайте 8 портів із найвищими значеннями використання буфера.

ПРИМІТКА: Директори та комутатори 7-го покоління, у яких за замовчуванням ніколи не змінювалася кількість буферів F-Port, не ризикують зіткнутися з цією проблемою переповнення буфера кадрів. Максимальне значення, яке використовується як налаштування за замовчуванням для максимальних/зарезервованих буферів, становить 28 для продуктів 7-го покоління, однак залежно від типу перемикача та оптичної швидкості може бути виділено менше буферів. Клієнти
, які ніколи не збільшували кількість максимальних/зарезервованих буферів за замовчуванням, не зіткнуться з проблемою переповнення
буфера. Навіть якщо 8 портів зоновано разом, використовуючи максимальне типове виділення 28 буферів на порт, загальне значення
максимального використання буфера становить лише 224 кадри.

«Перевірити» умови
ризику збоївНа додаток до проблеми переповнення буфера, директори X7-8 і X7-4 також потенційно можуть бути схильні до ризику «перевірки» повідомлень про помилки, якщо виконуються наступні умови в такому порядку:

• Директор X7-8 або X7-4, який раніше працював на FOS v9.0.x
• Потім director оновлюється до FOX v9.1.x
• Потім у директора є F-порти, які виходять із системи та входять до системи, перебуваючи у версії v9.1.x
• Потім директор стикається з подією перепідписки, яка вимагає керування з боку Оптимізатора трафіку
• Потім директор виконує відмову HA (оновлення прошивки спричиняє відмову)
• Директор стикається з іншою подією перепідписки, яка вимагає керування з боку Оптимізатора трафіку 

Директори X7-8 або X7-4, які відповідають усім цим умовам, у зазначеній послідовності, можуть бути схильні до ризику зіткнутися з помилками «перевірити» під час керування перепідпискою від Traffic Optimizer.

• Директори X7-8 або X7-4, які коли-небудь працювали тільки на прошивці FOS v9.1.x, не ризикують зіткнутися з помилкою «verify», оскільки для всіх портів використовується тільки модель програмування v9.1. Директори 7-го покоління, мабуть, раніше працювали з FOS v9.0.x, щоб бути сприйнятливими до цієї проблеми.
• Директори X7-8 або X7-4, які були холодно завантажені / включені під час роботи на прошивці FOS v9.1.x, також не ризикують зіткнутися з помилкою "verify", оскільки всі порти будуть використовувати програмування v9.1 після перезавантаження

Симптоми
Директори та комутатори 7-го покоління, які зіткнулися з подією керування перепідпискою, спостерігатимуть за наступним
RASlog оптимізатора трафіку: Додатковими симптомами, які можуть з'явитися через ці виявлені проблеми, можуть бути:

• Може спостерігатися велика кількість помилок CRC на каналі зв'язку, які не виправляються при заміні оптики/кабелю
• Кадри можуть бути відкинуті, посилання на посилання може бути втрачено
• Порти можуть бути несправні, ASIC може зупинитися та бути несправним
• Режисер може спостерігати несподіваний провал ХА або навіть холодний перезапуск директора
• Перемикачі можуть спостерігати холодний перезапуск

Керування перевищенням підписки за допомогою функції Traffic Optimizer за певних умов може спричинити сценарії збоїв, що впливають на передачу кадрів або портів,
якими керують. У сценаріях серйозного перевантаження ці збої також
можуть вплинути на продуктивність інших демонів Fabric OS (FOS), активних на комутаторі, що призведе до тайм-аутів наглядового тайм-аута
програмного забезпечення, що призведе до відмови HA або паніки перемикача.

Директори та комутатори 7-го покоління (X7-8, X7-4, 7730 та 7720), які стикаються з переповненням буферів кадрів під час спроб керувати та перенаправляти потоки з перевищенням підписки у відповідь на серйозну подію перевантаження, можуть спричинити
несподівані помилки. Якщо
кількість кадрів переповнює буфер, який використовується для керування обробкою перепідписки, то ці надлишкові кадри можуть
бути пропущені під час обробки Оптимізатора трафіку. Ці надлишкові кадри потенційно можуть бути перезаписані іншими кадрами, що призведе
до помилок CRC кадрів або навіть до помилок порту, якщо інформація заголовка буде перезаписана. У сценаріях сильного перевантаження керування цими переповненнями/надлишком кадрів може призвести до блокування інших фонових демонів FOS, що може призвести до
тайм-аутів вочдога. Критичні демони, які час очікування спричиняють відмову HA або перезавантаження перемикача.

На додаток до потенційної обробки переповнення кадрів, директори X7-8 і X7-4, які раніше працювали на FOS v9.0.x, а потім були оновлені до FOS v9.1.x, могли зіткнутися з помилками перевірки після відмов HA (включаючи ті, що викликані оновленням мікропрограми до більш високих версій v9.1.x). Кілька повідомлень про помилку «перевірити» будуть спостерігатися під час керування перепідпискою за допомогою Traffic Optimizer через виявлений конфлікт у програмуванні портів, створений, коли деякі порти, але не всі порти скидаються під час версії 9.1.x. Конфлікт між програмуванням керування перевантаженнями на портах, які ніколи не були скинуті в версії 9.0.x, а потім зіткнувся з керуванням перевантаженнями під час версії 9.1.x на портах, які були скинуті, може з'явитися після події відмови HA.

Обхідний шлях
" Під загрозою» директори та комутатори можуть відключити дію «Оптимізатор трафіку» з управління перепідпискою.
Виконайте наступну команду CLI з облікового запису обслуговування, щоб вимкнути поведінку керування перепідпискою
в Оптимізаторі трафіку ПРИМІТКА: Команду технічного обслуговування потрібно виконувати на всіх логічних перемикачах у шасі.
ПРИМІТКА: Налаштування буде стійким під час перемикання на відмову та циклів

живленняКоригувальні дії
Програмне рішення, що надається в FOS версії 9.1.1c і вище, запобігає цим збоям. Такі ж рішення також передбачені
в FOS v9.2.0a і більш високих версіях FOS v9.2.x. Оновлення до цих версій FOS запобіжить переповненню кадрів
через керування перепідпискою, а також запобігатиме помилкам "перевірки" у директорах X7.

Для будь-якого директора або комутатора 7-го покоління (X7-8, X7-4, 7730 і 7720), який все ще працює на версії FOS v9.0.x і може бути «під загрозою»,
щоб зіткнутися з описаними проблемами, рекомендується дочекатися випуску FOS v9.1.1c перед оновленням.

Директори та комутатори 7-го покоління, які зараз працюють у випусках v9.1.x або v9.2.0 і визначені як такі, що перебувають у зоні ризику,
повинні впровадити обхідний шлях. Деактивація дії з управління перепідпискою на Оптимізатор трафіку запобіжить
виникненню помилок переповнення буфера та «перевірки». Після оновлення до версії 9.1.1c або версії 9.2.0a дію керування перепідпискою можна повторно ввімкнути за допомогою такої команди:
Запустіть наступну команду CLI з облікового запису обслуговування, щоб знову ввімкнути дію керування перепідпискою
в оптимізаторі трафіку ПРИМІТКА: Команду технічного обслуговування потрібно виконувати на всіх логічних перемикачах у шасі.

Будь-який директор або перемикач 7-го покоління, який вже зіткнувся зі збоєм «переповнення буфера», повинен буде виконати холодний перезапуск
, щоб повністю відновитися після стану несправності: Варіант 1: Виконайте дію перезавантаження, показану вище, а потім виконайте обхідний шлях, щоб вимкнути дію керування перепідпискою в оптимізаторі
трафіку Варіант 2: Оновіть систему до версії FOS за допомогою цього рішення, а потім виконайте дію перезавантаження, показану вище.

Оновлення до версії FOS за допомогою наданого рішення запобіжить збою «переповнення буфера», але
як тільки виникне умова відмови, лише холодний перезапуск ASIC вирішить умову збою.
Оновлення до версії FOS за допомогою наданого рішення запобігає та автоматично відновлюється з умови помилки
«verify» без будь-яких подальших дій.

Після оновлення до версії FOS, яка містить рішення, буде виконано перевірку внутрішньої пам'яті, щоб визначити, чи не стикався директор або комутатор раніше зі збоєм і чи потребує перезавантаження для відновлення після умови помилки.
Наступний RASlog буде відображено, якщо після оновлення FOS до версії з рішенням буде виявлено умову помилки: Якщо вищевказаний RASlog спостерігається після оновлення FOS, то директор або перемикач раніше стикалися з помилкою «переповнення буфера
» перед оновленням і повинні будуть виконати холодний перезапуск для повного відновлення після відмови: