Данный пост я написал в порыве негодования и недоумения от того, как сетевое оборудование от мирового лидера в данном сегменте может сильно и неожиданно портить жизнь production-процессам и нам – сетевым админам.
Я работаю в государственной организации. Ядром нашей сетевой инфраструктуры является VSS-пара, собранная из двух коммутаторов Cisco Catalyst 6509E под управлением супервизоров VS-S720-10G-3C с версией IOS 12.2-33.SXI6 (s72033-adventerprisek9_wan-mz.122-33.SXI6.bin) на борту. Наша сетевая инфраструктура является полностью production и должна быть доступна практически 24*7*365. Какие-либо профилактические работы, предполагающие малейший останов предоставляемых сервисов, мы должны заранее согласовывать и выполнять в ночное время. Чаще всего это ночные квартальные профилактики. Об одной из таких профилактик я хочу рассказать. И я искренне не хочу, чтобы с вами повторилась моя история.
Сразу обозначу начинку одного из коммутаторов VSS пары (начинка второго коммутатора идентична):
На эту профилактику были запланированы, казалось бы, совершенно рутинные операции. Нам было выделено окно с 2 часов ночи до 8 утра. Это значит, что в 8 утра все должнобыть агонь! работать. Я приведу хронологию событий той романтической ночи:
1. Включение поддержки jumbo frames на VSS-паре Cisco catalyst 6509E. Все команды взяты из официального руководства Cisco:
# conf t
# system jumbomtu
# wr mem
На сайте CISCO сказано, что некоторые линейные карты не поддерживают jumbo frames вовсе, либо поддерживают ограниченный размер пакетов:
Мои линейные карты в этот список не попали. Отлично.
2. Также была включена поддержка jumbo frames еще на нескольких, стеках (catalyst 3750E, 3750X), смотрящих в VSS. Но это, на мой взгляд, мало имеет отношения к ниже описанной ситуации.
На данном этапе все было штатно. Полет нормальный. Едем дальше.
3. Далее, по плану была плановая чистка коммутаторов catalyst 6509E от пыли методом пылесоса. Эту операцию мы делаем регулярно (раз в квартал) и ничего неестественного мы не ждали. Решили начать с коммутатора, имеющего на тот момент active virtual switch member role, чтобы заодно проверить корректное выполнение switchover. Назову его коммутатор (1). Итак, коммутатор (1) выключили. Switchover произошел корректно – второй коммутатор (2) отрапортовал, что теперь он стал active. По пингу потерялся лишь один пакет. Далее, вынули и пропылесосили Fan Tray и оба блока питания. Вставили обратно. На данном этапе мониторинг рапортовал, что сеть работает исправно – все железки доступны. Отлично, подумал я, включил коммутатор (1) и отправился за комп ждать т.к. загрузка 6509 занимает порядка 7-8 минут. Проходит 10-15-20 минут, а все лампочки на супервизоре рыжие, линейные карты погашены и второй активный коммутатор (2) по-прежнему не видит первого (#sho swi vir red). Выключил коммутатор (1). Включил снова. Опять проходит порядка 20 минут – ситуация повторяется. В это время у меня рядом не было ноута с консольным кабелем, чтобы посмотреть что происходит. Сеть по-прежнему «летит на одном крыле» — коммутаторе (2).
Здесь правильным решением стало бы взять ноут, подключиться к консоли коммутатора (1) и посмотреть — что же там происходит? Но я, подумав на конфликт нод, решил погасить 2й коммутатор, подключить ноут к консоли первого и попробовать его включить в одиночку. В консоли я увидел следующее – коммутатор (1) вывалился в rommon. Без единой ошибки. Просто rommon. Еще раз выключил — включил – сразу rommon и все. А на часах 7й час утра и меньше чем через 2 часа начинается рабочий день. Обстановка накаляется. Я решил, что экспериментировать и пробовать загрузить IOS из rommon’а не стоит. Выключил коммутатор (1). И отправился включать второй коммутатор, думая себе – ну ладно, день полетим на одном крыле, а следующей ночью разберусь с проблемой. Воткнулся в консоль, включил и…что-то пошло не так в консоли я вижу как после полной, казалось, корректной загрузки коммутатор судорожно начинает гасить по очереди все порты и уходить в перезагрузку. Так повторялось 3 раза. И только с третьего раза он с горем пополам загрузился и предложил ввести учетные данные. Залогинился. Сеть вроде работает. Выдохнул. Но не тут-то было — враги наступали в мониторинге несколько access-коммутаторов то становились доступными, то уходили в «даун». Часть серверов также «моргала». Разные ресурсы из разных VLAN частично были не доступны. Перестал корректно работать DNS в соседние сети. Я не понимал в чем дело. Закономерность не прослеживалась. Время на часах близится к 8 часам. Уселся читать логи, а там красота то какая, ляпотааа шквал повторяющихся ошибок вида:
%DIAG-SW2_SP-3-MAJOR: Switch 2 Module 5: Online Diagnostics detected a Major Error. Please use 'show diagnostic result ' to see test results.
%DIAG-SW2_SP-3-MINOR: Switch 2 Module 2: Online Diagnostics detected a Minor Error. Please use 'show diagnostic result ' to see test results.
Здесь Module 5 – это супервизор SUP-720-10G-3C, а Module 2 – это линейная карта WS-X6724-SFP.
Немедленно в компанию, с которой у нас заключен сервисный договор на обслуживание, мы отправили все логи, а также show tech-support и show diagnostic. Те, в свою очередь открыли кейс в Cisco TAC. И уже через 3 часа пришел ответ от Cisco TAC, что ОБА (!!!) супервизора и линейная карта _аппартно_неисправны_ и подлежат замене.Бинго! Проанализировав логи, инженеры Cisco TAC сообщили, что супервизоры были уже неисправны до перезагрузки. А во время перезагрузки из-за неисправностей не смогли пройти Self tests и возобновить корректную работу. На наш вопрос о том, каким образом мы ранее могли узнать о неисправности супервизоров и, соответственно, зная об этом, не перезагружать их — нам не ответили.
Вот вам и отказоустойчивость когда 2 железки стоимостью в $42000 каждая (цена из осеннего Cisco GPL) дохнут одновременно при рестарте шасси. И это, не считая умершей линейной карты.
К нам выехал инженер с одним (потому что на этот момент больше у них в наличии не было) подменным супом и линейной картой.
Тем временем, проанализировав ситуацию, мы поняли, что клиенты, которые испытывают проблемы с сетью, воткнуты именно в эту линейную карту. Клиентов перевесили на другие порты. До конца рабочего дня худо-бедно долетели. После окончания рабочего дня на новый подменный SUP-720-10G-3СXL с помощью флешки был залит конфиг, vlan.dat и новая версия IOS 12.2 (33) SXJ6. И было решено начать с шасси (1) – того, которое было на данный момент выключено. Заменили суп, вытащили все трансиверы (на всякий случай), завели шасси – ошибок нет. После этого погасили работающее шасси (2) и вставили трансиверы в шасси (1) – сеть ожила на одном починенном крыле с временно предоставленным SUP-720-10G-3CXL.
Обращаю внимание, что VSS не заводится между двумя разными супами: SUP-720-10G-3CXL и SUP-720-10G-3C ругаясь на:
02:16:21 MSK: %PFREDUN-SW1_SP-4-PFC_MISMATCH: Active PFC is PFC3CXL and Other PFC PFC3C
Поэтому это было временное решение-костыль до того момента как нам привезут два одинаковых SUP-720-10G-3C.
Поскольку оставлять production-сеть на долго на «одном крыле» не вариант совсем, то в ближайшее время было согласовано еще одно ночное окно для замены супа и линейной карты в шасси(2). К этому моменту на площадку привезли 2 новых SUP-720-10G-3C и линейную карту WS-X6708-10GE. По старому сценарию на новые супы были залиты прошивка, vlan.dat и свежий конфиг с уже работающего шасси (1). От шасси (2) были отсоединены все трансиверы от греха подальше. Убедились, что шасси (2) на новом железе грузится без ошибок, выключили. Скоммутировали VSL-линки, включили. Полет нормальный. VSS собрался. Воткнули трансиверы и сеть зажила на обоих крыльях. Радости не было предела. УРА! Наконец-то закончился этот кошмар.
Но радость продолжалась не долго. Через несколько дней после этих работ в разгар рабочего дня внезапно гаснет VSL-линк между супами. Что за чертовщина? На новом оборудовании? Благо второй VSL-линк (на каждом шасси собран Port-channel LACP из двух портов для суммарного VSL-линка между шасси) между линейными картами жил и Dual Active Detection обошел нас стороной. Методом замены трансиверов 10Gbase-LRM и перестановки в соседние слоты было выявлено, что умер слот в шасси супервизора (1) – АХТУНГ!
В логах:
Далее, процедура открытия кейса в Cisco TAC и последующий ответ CISCO-инженера:
Для тех, у кого сложности с английским коротко опишу его ответ. Инженер Cisco TAC предлагает включить diagnostic bootup level complete, «передернуть» супервизор в шасси и наблюдать за развитием событий. Если это связано с Faulty Fabric Channel on Supervisor Module or the Line cards (с неисправным каналом фабрики коммутации на супервизоре или линейной карте), то проблема проявится вскоре через довольно короткое время. Если проблема не проявится по истечению 48 часов, то ее можно считать “…termed to be a one time” т.е. одноразовой.
Сейчас мы согласовываем очередное окно для выполнения данных работ. Напишу здесь обновление по результатам.
Надеюсь, что эта статья поможет кому-нибудь в трудной ситуации или предостережет от нее. На все вопросы с удовольствием отвечу в комментариях.
Всем крепкихсупервизоровнервов в нашей, порой захватывающей дух, профессии :)
UPD: Сегодня ночью на горячую из активного шасси вытащили суп (по вышеизложенной рекомендации инженера Cisco TAC), потерялся один пинг, второе шасси стало активным. Вставили суп обратно. Проверили якобы неисправный слот под 10Gbase-LRM — работает. Летим дальше.
Я работаю в государственной организации. Ядром нашей сетевой инфраструктуры является VSS-пара, собранная из двух коммутаторов Cisco Catalyst 6509E под управлением супервизоров VS-S720-10G-3C с версией IOS 12.2-33.SXI6 (s72033-adventerprisek9_wan-mz.122-33.SXI6.bin) на борту. Наша сетевая инфраструктура является полностью production и должна быть доступна практически 24*7*365. Какие-либо профилактические работы, предполагающие малейший останов предоставляемых сервисов, мы должны заранее согласовывать и выполнять в ночное время. Чаще всего это ночные квартальные профилактики. Об одной из таких профилактик я хочу рассказать. И я искренне не хочу, чтобы с вами повторилась моя история.
Сразу обозначу начинку одного из коммутаторов VSS пары (начинка второго коммутатора идентична):
На эту профилактику были запланированы, казалось бы, совершенно рутинные операции. Нам было выделено окно с 2 часов ночи до 8 утра. Это значит, что в 8 утра все должно
1. Включение поддержки jumbo frames на VSS-паре Cisco catalyst 6509E. Все команды взяты из официального руководства Cisco:
# conf t
# system jumbomtu
# wr mem
На сайте CISCO сказано, что некоторые линейные карты не поддерживают jumbo frames вовсе, либо поддерживают ограниченный размер пакетов:
Мои линейные карты в этот список не попали. Отлично.
2. Также была включена поддержка jumbo frames еще на нескольких, стеках (catalyst 3750E, 3750X), смотрящих в VSS. Но это, на мой взгляд, мало имеет отношения к ниже описанной ситуации.
На данном этапе все было штатно. Полет нормальный. Едем дальше.
3. Далее, по плану была плановая чистка коммутаторов catalyst 6509E от пыли методом пылесоса. Эту операцию мы делаем регулярно (раз в квартал) и ничего неестественного мы не ждали. Решили начать с коммутатора, имеющего на тот момент active virtual switch member role, чтобы заодно проверить корректное выполнение switchover. Назову его коммутатор (1). Итак, коммутатор (1) выключили. Switchover произошел корректно – второй коммутатор (2) отрапортовал, что теперь он стал active. По пингу потерялся лишь один пакет. Далее, вынули и пропылесосили Fan Tray и оба блока питания. Вставили обратно. На данном этапе мониторинг рапортовал, что сеть работает исправно – все железки доступны. Отлично, подумал я, включил коммутатор (1) и отправился за комп ждать т.к. загрузка 6509 занимает порядка 7-8 минут. Проходит 10-15-20 минут, а все лампочки на супервизоре рыжие, линейные карты погашены и второй активный коммутатор (2) по-прежнему не видит первого (#sho swi vir red). Выключил коммутатор (1). Включил снова. Опять проходит порядка 20 минут – ситуация повторяется. В это время у меня рядом не было ноута с консольным кабелем, чтобы посмотреть что происходит. Сеть по-прежнему «летит на одном крыле» — коммутаторе (2).
Здесь правильным решением стало бы взять ноут, подключиться к консоли коммутатора (1) и посмотреть — что же там происходит? Но я, подумав на конфликт нод, решил погасить 2й коммутатор, подключить ноут к консоли первого и попробовать его включить в одиночку. В консоли я увидел следующее – коммутатор (1) вывалился в rommon. Без единой ошибки. Просто rommon. Еще раз выключил — включил – сразу rommon и все. А на часах 7й час утра и меньше чем через 2 часа начинается рабочий день. Обстановка накаляется. Я решил, что экспериментировать и пробовать загрузить IOS из rommon’а не стоит. Выключил коммутатор (1). И отправился включать второй коммутатор, думая себе – ну ладно, день полетим на одном крыле, а следующей ночью разберусь с проблемой. Воткнулся в консоль, включил и…
%DIAG-SW2_SP-3-MAJOR: Switch 2 Module 5: Online Diagnostics detected a Major Error. Please use 'show diagnostic result ' to see test results.
%DIAG-SW2_SP-3-MINOR: Switch 2 Module 2: Online Diagnostics detected a Minor Error. Please use 'show diagnostic result ' to see test results.
Здесь Module 5 – это супервизор SUP-720-10G-3C, а Module 2 – это линейная карта WS-X6724-SFP.
Немедленно в компанию, с которой у нас заключен сервисный договор на обслуживание, мы отправили все логи, а также show tech-support и show diagnostic. Те, в свою очередь открыли кейс в Cisco TAC. И уже через 3 часа пришел ответ от Cisco TAC, что ОБА (!!!) супервизора и линейная карта _аппартно_неисправны_ и подлежат замене.
Вот вам и отказоустойчивость когда 2 железки стоимостью в $42000 каждая (цена из осеннего Cisco GPL) дохнут одновременно при рестарте шасси. И это, не считая умершей линейной карты.
К нам выехал инженер с одним (потому что на этот момент больше у них в наличии не было) подменным супом и линейной картой.
Тем временем, проанализировав ситуацию, мы поняли, что клиенты, которые испытывают проблемы с сетью, воткнуты именно в эту линейную карту. Клиентов перевесили на другие порты. До конца рабочего дня худо-бедно долетели. После окончания рабочего дня на новый подменный SUP-720-10G-3СXL с помощью флешки был залит конфиг, vlan.dat и новая версия IOS 12.2 (33) SXJ6. И было решено начать с шасси (1) – того, которое было на данный момент выключено. Заменили суп, вытащили все трансиверы (на всякий случай), завели шасси – ошибок нет. После этого погасили работающее шасси (2) и вставили трансиверы в шасси (1) – сеть ожила на одном починенном крыле с временно предоставленным SUP-720-10G-3CXL.
Обращаю внимание, что VSS не заводится между двумя разными супами: SUP-720-10G-3CXL и SUP-720-10G-3C ругаясь на:
02:16:21 MSK: %PFREDUN-SW1_SP-4-PFC_MISMATCH: Active PFC is PFC3CXL and Other PFC PFC3C
Поэтому это было временное решение-костыль до того момента как нам привезут два одинаковых SUP-720-10G-3C.
Поскольку оставлять production-сеть на долго на «одном крыле» не вариант совсем, то в ближайшее время было согласовано еще одно ночное окно для замены супа и линейной карты в шасси(2). К этому моменту на площадку привезли 2 новых SUP-720-10G-3C и линейную карту WS-X6708-10GE. По старому сценарию на новые супы были залиты прошивка, vlan.dat и свежий конфиг с уже работающего шасси (1). От шасси (2) были отсоединены все трансиверы от греха подальше. Убедились, что шасси (2) на новом железе грузится без ошибок, выключили. Скоммутировали VSL-линки, включили. Полет нормальный. VSS собрался. Воткнули трансиверы и сеть зажила на обоих крыльях. Радости не было предела. УРА! Наконец-то закончился этот кошмар.
Но радость продолжалась не долго. Через несколько дней после этих работ в разгар рабочего дня внезапно гаснет VSL-линк между супами. Что за чертовщина? На новом оборудовании? Благо второй VSL-линк (на каждом шасси собран Port-channel LACP из двух портов для суммарного VSL-линка между шасси) между линейными картами жил и Dual Active Detection обошел нас стороной. Методом замены трансиверов 10Gbase-LRM и перестановки в соседние слоты было выявлено, что умер слот в шасси супервизора (1) – АХТУНГ!
В логах:
Далее, процедура открытия кейса в Cisco TAC и последующий ответ CISCO-инженера:
Для тех, у кого сложности с английским коротко опишу его ответ. Инженер Cisco TAC предлагает включить diagnostic bootup level complete, «передернуть» супервизор в шасси и наблюдать за развитием событий. Если это связано с Faulty Fabric Channel on Supervisor Module or the Line cards (с неисправным каналом фабрики коммутации на супервизоре или линейной карте), то проблема проявится вскоре через довольно короткое время. Если проблема не проявится по истечению 48 часов, то ее можно считать “…termed to be a one time” т.е. одноразовой.
Сейчас мы согласовываем очередное окно для выполнения данных работ. Напишу здесь обновление по результатам.
Надеюсь, что эта статья поможет кому-нибудь в трудной ситуации или предостережет от нее. На все вопросы с удовольствием отвечу в комментариях.
Всем крепких
UPD: Сегодня ночью на горячую из активного шасси вытащили суп (по вышеизложенной рекомендации инженера Cisco TAC), потерялся один пинг, второе шасси стало активным. Вставили суп обратно. Проверили якобы неисправный слот под 10Gbase-LRM — работает. Летим дальше.
