Пользователь
0,0
рейтинг
6 февраля 2014 в 18:45

Администрирование → Cisco VSS: страх и ненависть на работе

Данный пост я написал в порыве негодования и недоумения от того, как сетевое оборудование от мирового лидера в данном сегменте может сильно и неожиданно портить жизнь 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 — работает. Летим дальше.

glmonarch @glmonarch
карма
16,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (81)

  • +5
    Как страшно жить.
  • +6
    Тут рядом стоят Juniper, DLink… курят, переминаются, обсуждают… обстановка нервная, но не агрессивная.
  • +1
    > На наш вопрос о том, каким образом мы ранее могли узнать о неисправности супервизоров и, соответственно, зная об этом, не перезагружать их — нам не ответили.

    Может быть попробуете додавить их по этому вопросу. А то странно все это.

    Пробовали гуглить подобную проблему, есть что-ть по теме?
    • +5
      Ни чего странного. Переходные процессы. Ведает о нем первый же курс Электротехники. После перезагрузки устройста, до установленя нормального режима работы, на компоненты действуют силы большие чем номинальные. Что часто приводит к выходу их из строя.

      В данном случае человеку экслючивно не повезло. Такое бывает.

      Но вот что реально странно. Зачем потребовалось перезагружать второе шасси до восстановления работы первого? Лично я считаю что нормальный план по проверки непрерывности оказываемого сервиса обязан включать в себя регулярные перезагрузки оборудования. Они эмулируют сбой и наглядно показывают недочеты или наоборот, что все хорошо. На таких проверках и можно выявить такого рода неисправности.
  • +11
    вот так и появляются нездоровые сенсации — сейчас большая часть людей толком не понявших в чем дело будут думать что VSS — гавно и цыска — SOHO. мне бы не пришла в голову идея перезапустить активный резерв при неработающем основном свитче имея меньше часов шести времени в запасе…
    • +1
      Честно, мне не могло придти в голову, что два супа могут выйти из строя одновременно и я рассчитывал, что второе шасси уж точно заведется повторно. Был не прав.
    • 0
      Посыл автора в том, что не надо уповать на бренд и платную техподдержку. И именно этим пост полезен для всех. Аппартная проблема сразу на обоих нодах отказаустойчивого кластера плюс человеческий фактор, автору реально неповезло. Кстати, так как оба устройства из одной партии есть ненулевой шанс того, что они выйдут из строя одновременно с одинаковой проблемой. К примеру многие сталкивались с такой бедой когда из зеркального рейда сначала вылетает один диск, а еще через несколько дней второй и системный администратор начинает рвать на голове последние волосы, а директор ему говорит «Ты ж специалист, хули ж ты? Даже мне очевидно, что надо сразу же было подцепить резервный диск, а не сиськи мять»
      • 0
        Да и подстава с перезагрузками та еще, нужен какой-то регламент с регулярным проведением таких испытаний, полностью выключить питание и включить.
        У нас была проблема в HP DL160G6, из 8 серверов со временем у 4 вылетели БП, сервак работает нормально все хорошо, выключаешь питание — больше не включается.
        Аналогично и длинковский коммутатор поступал, но тут уже бренд обязывает :-D
  • 0
    Дайте номер кейса, почитать. Может там и написано как инженер определил что супервизоры дохлые. =)
    • 0
      Будешь смеятся, первым был мой кейс. Можешь стукнуться, расскажу как.
  • +4
    все нормально, кроме выключения 2-го шасси пока первый не включился.
    • 0
      Ответил выше. Согласен.
      • 0
        А без консольного подключения делать такие вещи, не следя за процессом загрузки? Имхо не совсем, учитывая критичность функций оборудования.
  • +2
    А у меня в последнее время претензии не к железу цысок, а к их софту.
    Обновил недавно на access-свичах IOS до 15.0(2)SE5 — вроде как релиз чисто багфиксный, беды ничего не предвещало.

    Но после этого у половины клиентов пропала связь, оказалось что в этом релизе тупо перестал работать DHCP Snooping и все технологии, на него завязаные — APR Inspection, Source Verify и т.п.

    Почитал форумы цыски — у всех такое, народ откатывается на 15.0(2)SE4

    И при этом что странное — у меня было два идентичные коммутатора 2960 и на одном из них Snooping работал(!) в этом релизе, а на втором — нет. Конфиги на 99% идентичны. Где закономерность я так и не понял…

    А с железом ихним тьфу тьфу у меня за последние лет 5 проблем никаких не было.

    Дальше — есть два свича, соеденины транками, которые помечены как доверенные (ip arp inspection trust, ip dhcp snooping trust) — траффик в одном из контроллируемых через ARP Inspection вланов через один из свичей со второго тупо не проходит, хотя порт доверенный. Отключаю инспекцию этого влана — всё полетело.

    Почти целый день убил на обход этих приколов.
    • +1
      Только в последнее время? ;)
      • 0
        Да, раньше как-то стабильнее было, а тут скачешь с версии на версию и ищешь где багов поменьше. Хотя, казалось бы, уж свичи могли бы допилить, там иосы в 5-6 раз меньше, чем в роутерах, технологий меньше, глючить почти нечему :)
        • +2
          Если вы про коммутаторы, то я соглашусь. Раньше они работали очень хорошо вне зависимости от релиза. На 12.2.5x каком-то была неприятная бага года так 4-ре назад. А так все было хорошо.

          А вот если привнести сюда роутеры, то с ними ситуация была такая.
          Нужен конкретный набор фич, и сидишь перебираешь ios-ы выясняя, в каком ios-е все эти фичи заработают в полном обьеме. Потом нужно еще новую фичу добавить, пробуешь в текущем — не получается. Опять сидишь и ищешь ту версию где всё, что тебе нужно заработает.
          Потом с этим попроще стало, базовые вещи в ios таки вылизали.

          Кроме роутеров, есть другие технологии, а уж там глюков… Могу книги писать на тему Cisco И Баги.
          • 0
            Да, на роутерах вообще весело: есть IPSEC, казалось бы — стандартизованная технология! И не только внутре цыски, а вообще — мультивендорно.

            Дано — небольшой DMVPN, пара 2901 хабами, кучка 880ых споками. Так вот у первых иос был вроде 15.2, а у вторых — 15.3.
            Так вот, IPSEC между ними не поднимался, то есть вообще. Всё настроено было стандартно через tunnel protection и ikev2

            Обновляешь хабы до 15.3 и всё сверкает свежими красками! Откатываешь споки до 15.2 — аналогично. В конфигах ничего не менялось.

            То есть получается, что айписек у цыски совместим только в пределах одного мажорного режима IOS? Смех и грусть.
            • 0
              Тут может быть проблема в том, что разные параметры по умолчанию в разных релизах. Эти параметры не показываются в sh run, но замечательно работают. Поэтому, чтобы оно заработало, нужно читать Release Notes, Configuration Guides, Troubleshooting guides. Вообще для ipsec debug-и очень понятные, по сравнению с некоторыми другими технологиями.
              • 0
                Дебаги, конечно, смотрел, но сейчас уже не вспомню в чем дело было, какой-то затык на первой фазе IPSEC, кажется.
                На мысли как лечить не навело. Доки, конечно, тоже читал, но по-диагонали.

                Для меня это странно, что какие-то важные дефолтные параметры, влияющие на сам факт работы протокола, меняются от версии к версии. Даже после апгрейда свичей с 12 до 15 иоса ничего не ломалось, про роутеры не помню.
                • 0
                  Ну в свичах переход от версии 12.2.58 на 15.0.1 аналогичен по фичам переходу от 12.2.57 на 12.2.58 (если был такой). Они фактически переименовали 12.2.x линейку в 15.x чтобы догнать по нумерации ios (а то, видимо, много менеджеров у заказчиков интересовались: «чего вы мне такой старый ios с каталистом продаете? Хочу 15-й!»)

                  А что касается дефолтных параметров — нужно читать Release notes, хотя бы по диагонали все, а New and Changed option — полностью. Там много бывает важных вещей.
                  • 0
                    Посмотрите когда был релиз 12.2.(55)SE8 и 12.2(58)SE. Многое станет ясно. 12.2(57)SE не было. 12.2(58)SE была выпущена для очень узких потребностей. Показали, и больше её не развивали/не фиксили.

                    Заказчики разные есть. Согласен с вами. У Cisco есть отличная служба — Advanced Services. Они могут авторитетно заявить, что лучше конкретно для вас.
                    • 0
                      Ок. Я согласен 12.2.57 не было — привел для примера. Про 12.2.58 — это просто отлично. Кто-бы знал, что это по сути 12.2.55XYZ (боковое ответвление софта)

                      А как получить эти Advanced Services? Какая строчка в GPL?
                      • 0
                        На сколько я знаю, это очень дорого и индивидуально. Сильно зависит от инсталяционной базы. Обратитесь к своему аккаунт менеджеру.
                        • +1
                          Понятно. Это только для очень больших компаний.

                          А посылать к account manager-у это уже все равно что посылать на три буквы. Нет, он конечно приедет, может даже не один, сиящий, с галстукои и IPad-ом. Запишет твои проблемы и уедет. И опять ничего не изменится :) Account manager это такая психологическая поддержка от Cisco, иногда на дому.
                          • 0
                            Ни чего такого не имел ввиду. :) Он же может предложить и сервисы попроще. Я боюсь со всеми не знаком. Уверен, что-то вроде NOS может тоже помочь.
    • 0
      С чего Вы взяли, что это «вроде как релиз чисто багфиксный». Рекомендую прочитать что значит ED, и не путать с MD.

      Для большинства access коммутаторов рекомендуется 12.2(55)SE8.
      • +1
        Хм. ED — Early Deployment, MD — Maintenance Deployment. И вообще то ортогональные штуки от SE5 и от SE4.

        15.0(2)SE5 должен отличаться от SE4 только фиксом багов + незначительные фичи. Смотрим в Release Notes www.cisco.com/en/US/docs/switches/lan/catalyst3750x_3560x/software/release/15.0_2_se/release/notes/OL25302.html#wp1065409
        И точно из нового там только
        Catalyst 3750-X and 3560-X switches now support Universal Power over Ethernet (UPoE).

        А вот честно, у вас в production только GD или MD? А когда case открываете TAC не советует вам сразу поставить последний ED «потому что там баги пофикшены»?
        • +1
          Только MD являются 100% баг фиксами по отношению к предыдущей версии. Ну или engineering special как исключение, которого нет на CCO. Приведенного вами Release Notes хватает, что бы релиз стал ED.

          С уважением, ваш TAC инженер.
          • 0
            Нужная информация, спасибо!

            > Приведенного вами Release Notes хватает, что бы релиз стал ED.

            А поясните подробнее, пожалуйста?
            • +1
              Любая новая мелочь => ED.
              New in Cisco IOS Release 15.0(2)SE5
              — Catalyst 3750-X and 3560-X switches now support Universal Power over Ethernet (UPoE).
      • 0
        Я, звиняюсь, а вы где видели MD у свичей 2960 или 3750? Там все релизы ED, что 15.х, что 12.х, сгоняйте на сайт цыски да убедитесь. У роутеров — пожалуйста, а тут неет. Что ж мне бедному юзать, если оно там всё для продакшена не готово?

        Под «багфиксный» я подразумеваю по отношению к тому, что уже стояло (15.0(2)SE4 и ниже)

        Для большинства access коммутаторов рекомендуется 12.2(55)SE8

        Кем? У меня оно стоит на старых 3560 с 16мб флеша, туда 15.х тупо не влазит. Работает, да, всё ок.
        Но и с 15.х до последних горе-релизов проблем особых не было — всё работало. Но вот чёрт дёрнул обновиться планово…
        • 0
          А к чему вопрос видел я или нет? Нет MD на ССO. Это очевидно. Рекомендация от разработчиков.
          • 0
            Вопрос к тому, что мне считать стабильной версией? Вы говорите — MD, а его нет. Есть 15.2.1, но он явно не стабилен.
            Есть 15.0.2, который уже 5 SE поимел. Я, по логике разработки софта, выбираю его как золотую середину.

            Товарищи из циско, судя по всему, не заморачиваются над нормальным циклом разработки: разработали версию, заморозили фичи, правим баги, параллельно разрабатываем ветку с новыми фичами и всё еще правим баги в старой.

            По крайней мере по отношению к коммутаторам это, похоже, так.
            • +1
              Боюсь Вы меня не правильно поняли. Я всего лишь сказал, что ED ни когда не считалась версией только с фиксами багов и попросил не вводить в заблужение других.

              По поводу остального, это всего лишь ваши домыслы. Думаю наберетесь опыта и будет все лучше. Судя по всему желание есть.
              • 0
                А все таки, как простым инженерам (не инженерам TAC) выбирать «самый стабильный» ios для Cisco Catalyst?
                12.2(55)SE8 — хорошо, но почему? Где посмотреть, когда он изменится?
                Пока прослеживается только один алгоритм — самая большая цифра после SE.
                • +1
                  Параметров много. Разработчики делаю регулярный анализ дефектов. Присваивают им веса. По результатам дают рекомендации. TAC не имеет права рекомендовать конретную версию IOS в кейсе. Можно сказать лишь, когда испраление дефекта было включено в релиз. Ну или посмотреть, что советуют разработчики в общем случае, для конкретной платформы.
                  Установка последней версии часто является требованием разработчиков.
                  • 0
                    Параметров много. Разработчики делаю регулярный анализ дефектов. Присваивают им веса. По результатам дают рекомендации.

                    Где эти рекомендации можно почитать? Или это только для избранных?
                    • +1
                      Внутренняя иформация. Открывайте кейс. :)
                • +1
                  Да, и еще. Алгоритм выбора OS очень простой.
                  Если IOS не end of support. Нет дефекта или уязвимости, которые могут доставить вам неприятности. Нет новой нужной фичи, которую вы давно ждали. => Не обновляйтесь.
                  • 0
                    Да. Это работает до тех пор, пока не выходит какой нибудь Security Update, который рекомендует обновиться на какой-то ios, который оказывается забагованным. Сам с таким сталкивался.
              • 0
                Раз считаете что домыслы, то аргументируйте. Я, как пользователь железа, хочу понимать — какой софт юзать безопасно, а какой — нет. В случае другого софта это, обычно, ясно (особенно в опенсурсе). Есть стабильные ветки, есть экспериментальные.

                Как мне, зайдя на сайт Cisco и почитав Release Notes выбрать прошивку?
                • +1
                  Я, как пользователь железа, хочу понимать — какой софт юзать безопасно, а какой — нет

                  Не бывает безопасного софта. Есть более глючный и есть менее глючный. «Stable» ветка в опенсорсе не гарантирует нормальную работу.

                  В принципе, рядом с некоторыми версиями софта выставляют значок «safe harbor». В случае 6500 он есть, например, на SXI12. Понятия не имею, что это на самом деле значит, но, возможно, количество выявленных багов ниже определенного порога.
                  • 0
                    Safe Harbor — программа тестирования. Включает очень большое количество сценариев типичного использования коммутаторов и взаимодействия фич между собой. + конечно же учитываются дефекты.
                  • 0
                    Не бывает безопасного софта. Есть более глючный и есть менее глючный. «Stable» ветка в опенсорсе не гарантирует нормальную работу.

                    Это и так всем очевидно, что никто ничего не гарантирует. Баги бывают везде. Но вот основной функционал должен работать, а не так что обновился до очередного SE и сломался DHCP Snooping совсем. Это одна из основных технологий акцес свича, уж ее то могли протестировать.
                    • 0
                      Но вот основной функционал должен работать

                      Я тоже временами недоумеваю, каким местом они тестируют софт…
                      Ну можете считать, что MD = «stable», ED = «unstable».
                      • 0
                        Окей, значит весь софт для акцес свичей unstable :) Это феерично)
                        • 0
                          Как-то так, да.

                          Хотя еще фееричнее обновлять софт без предварительного тестирования и сразу везде ;)
  • +8
    Вообще такие истории всегда — мрак неприятные.
    С одной стороны архитекторы должны гореть в аду, за такой дизайн сети. 6708 у вас одна, это фатальная ошибка. Отказ CrossBar не такая и редкость, бывали случаи когда не работает слот, но шасси работает нормально. Линейные карты на такой enviroment должны быть всегда дублированы, да это дорого, но это вопрос к коэффициенту «А».

    Второй фатал, это решение вывести второй коммутатор на maintense, вопрос напрашивается сам собой — зачем?
    Вопрос номер три, почем вы полезли на maintense в одиночку, я имею не вас конкретно, а тех людей которые не запросили тех под на возможность подмоги. Почему вы не оповести их о окне, и не запросили статус ЗИП? Вам крупно повезло что у них вообще SUP оказался, это просто свыше решили не устраивать хардкор.
    Вопрос номер четыре, почему дизайн сети не предусматривает преодоление Disaster? Все очень просто, дизайн сети должен быть рассчитан на возможность получения двойного отказа (а именно он у вас и произошел). У меня зреет вопрос, как допустили отсутствие резервных линков между узлами агрегации? Ведь можно сделать легкий setup 10GE -> 1GE, преодолеть двойной отказ с понижением в скорости и дальше продолжить работать над решением сложившейся ситуации?

    Можно Вас попросить назвать имена архитекторов/дизайнеров героев. Ну так, на всякий случай, не пускать их близко.
    • 0
      Я извиняюсь за опечатку — линейная карта, вышедшая из строя была WS-X6724-SFP, а не WS-X6708-10GE как я написал. Исправлю. Поясните — в чем фатальная ошибка иметь одну 6708 в шасси? В том, что только на ней есть DFC? Ну ведь и без DFC коммутация трафика будет происходить, но медленнее.
      Про второй фатал — ответил выше в комментах.
      К ответу на 3й вопрос — наверное, избыточная самоуверенность. Я уже пообщался с коллегами из старшего подразделения — они на абсолютно все профилактические работы вызывают на площадку сервисного инженера для подстраховки. Возьму на вооружение.
      Вопрос четыре. Дизайн сети нам достался по наследству. Архитекторов не знаю. Бюджет организации не предполагает закупок дубля итак задублированного оборудования. А тем более, объяснить руководству необходимость закупки дубля уже задублированного оборудования, которое, как показала практика, даже задублированное может выйти из строя одновременно — не представляется возможным. Спросят — зачем вообще такое железо нужно? И у нас гос. контора, не забывайте. А так, конечно, при наличии финансирования можно построить «надутую энтерпрайзную» схему (понравилась формулировка из коммента ниже).

      • 0
        В вашем случае две линейные карты через которые вяжется VSS link нужны для простой отказоустойчивости. Ведь нет гарантии того что не откажет карта или слот? Таким образом вы увеличиваете коэффициент «А», устраняя точки отказа. Представьте ситуацию, отказывает карта на которой у вас повязан VSS? Как будет развиваться ситуация не известно никому, может пройдет split brain, а может ПО преодолеет эту ситуацию путем отключения одной коробки. Вариант перевязывать VSS через SUP тоже смертельный трюк, т.к. если на CP случиться авария, лазеры потухнут автоматически. Так что проще две карты, больше шансов на выживание.

        Надувать не надо, надо трезво оценивать бюджет, выводить «А», и говорить руководству бумагой. Вот бумага, «А», такой-то, надо еще вот это и мы закроем вот это, на такой-то период.
        • 0
          У меня сейчас VSL-линк — это Port-channel, в котором с каждой стороны есть 1 порт в супе и 1 порт в 6708.
          Под CP Вы подразумеваете Control Plane? В этом случае связь останется по линку между 6708.
  • 0
    Да ну нафиг. Может быть просто надо было держать резервную прошивку? И попробовать грузануть ее? А может еще и резервный конфиг, с минимальными BGP-функциями и отключенным VSS-ом после перезагрузки?
  • +3
    > Но я, подумав на конфликт нод, решил погасить 2й коммутатор, подключить ноут к консоли первого и попробовать его включить в одиночку

    вот тут все и началось. надо у вас уже был аварийный режим работы, как пришло в голову валить вторую кошку — ума не приложу
    • 0
      На тот момент мне не могло придти в голову, что две кошки могут умереть одновременно после рестарта. Теперь знаю, что могут.
  • 0
    Хех…
    У нас тоже песня была с VSS.
    Сначала весь VSS тупо встал колом — т.е. трафик гоняет, но не зайти. В локальную консоль, через кабель, ЧСХ, пускал. Благо, все равно собирались менять на ASR1001. Заменили, проверили — сдох SUP. До этого сдохла линейная карта после банального апгрейда IOS. На той же паре шасси после ребута сдох еще и второй суп. Хорошо что кошки уже не в эксплуатации были, так что играться можно было вволю. Ну и smartnet, да.

    P.S. А так все гуд, кроме шатдауна циски в отсутствие резерва
  • 0
    Если хотите надутый энтерпрайз-ответ — у вас должна быть лаборатория с оборудованием, эквивалентным продакшену, которая заодно выступает в качестве холодного резерва.

    Там отлаживаются все изменения, оно же служит в качестве второго резерва.

    Да, такое отвоёвывать тяжко — но такова работа админа.
    • 0
      В госконторах свои реалии
  • –2
    Сочувствую автору. Реально подстава.
    Энтерпрайз ответ к сожалению будет скорее: «всё работало, циска не может не работать, это ваши инженера пылесосом все сломали».
  • 0
    Выключение второго коммутатора при неработающем первом – это был очень оптимистичный поступок.
    А почему, кстати, в 6509E всего по одному супервизору? Второй не был запланирован к закупке?

    И ещё: насколько оправдано ежеквартальное выключение шеститонника для чистки пылесосом? В серверной настолько пыльно? Я встречался с одним 6509, который три года проработал без выключения, и только через три года добрая душа прошлась по БП… так, снаружи немного :)

    Не повезло вам, сочувствую. Кстати, как таковая «хронология» до 6 утра отсутствует, а дальше – хромает.
    • +1
      Конфигурация с одним супом в шасси досталась по наследству. А серверная с шасси (1) не до конца серверная и с высокой проходимостью людей для таких помещений + там температурный режим не лучший и увеличенная вероятность перегрева. Поэтому пылесосим так часто.
      • 0
        Возникает вопрос: не будет ли дешевле организовать нормальную серверную?
        • 0
          Этот вопрос уже открыт минимум как полгода. Но Вы же, наверное, представляете скорость принятия решений и выделения бюджета под конкретные задачи в гос. конторах?
  • 0
    Добавлю ложку дёгтя в VSS на шеститонниках. При апгрейде отказали по 2 лайн-карты на каждом холодильнике. Железно отказали. Хорошо на access-свитчах портов хватило и контракт был 24х7х4. Но от VSS после этого отказались и больше я его никому не советую.

    И да, ребутить второй коммутатор, не взглянув консолью на не поднимающийся первый — немного опрометчиво.
    • 0
      Вот-вот :)
  • 0
    Далее, по плану была плановая чистка коммутаторов catalyst 6509E от пыли методом пылесоса. Эту операцию мы делаем регулярно (раз в квартал) и ничего неестественного мы не ждали.


    А зачем их пылесосить так часто? У нас стойка с цисками стоит 8 лет и за это время ни разу не было желания что то отключать и пылесосить и все работает без проблем.

    Как говориться — работает и не трожь!
    • 0
      del
    • 0
      >>Как говориться — работает и не трожь!
      Так оно всё работает. До определённого момента. А потом приходит он. Alopex lagopus.
      Обслуживание и профилактика нужны.
      После того, как до этого доходят сами админы есть ещё начальство, которое нужно в этом убедить.
      Хорошо, если согласятся (как первый вариант). А могут кивать полгода/год, говоря «ну вот, не сейчас». Пока не придёт озвученный зверь (вариант второй).
      Мне, к сожалению, пришлось работать через 2й вариант. После этого, конечно, уже не просто кивают, но и дают добро на действия.
  • 0
    Я так понимаю, что серверная у вас — не серверная, а просто выделенная комната с окном? Потому что иначе просто неясно, откуда столько пыли, что раз в квартал пылесосить надо. Операция потенциально опасная, надо проблему решать. Может быть, уплотнителями окна-двери проклеить или еще что…

    И я присоединюсь к хору товарищей выше: вы очень оптимистично отправили в ребут второй свитч. В вашей работе нельзя быть таким оптимистом. Я в свое время вывел для себя правило: никогда не предпринимать каких-либо незапланированных действий после 2 ночи. Потому что в это время мозг перестаёт адекватно продумывать и анализировать ситуацию.

    Удачи вам и побольше пессимизма.
    • 0
      Про серверную ответил выше. Про ребут второго шасси тоже. Был оптимистом. Виноват. Исправлюсь. Спасибо.
      • 0
        Понял.
        Тут вопрос не вины, а подхода.
        При внесении любых изменений надо быть мегапессимистом.
        Хотя, конечно, предположить невероятное нереально, это только с опытом приходит.
    • +1
      Боюсь, что вы не очень понимаете специфику. Есть технологическое окно с 2 ночи до 8 утра, что скорее всего обусловлено наименьшей нагрузкой; другого времени – нет. Хорошо, когда всё идёт по плану работ, но если вдруг появляются незапланированные действия – откладывать их до рабочего дня не лучшая идея.

      Я бы вспомнил другое хорошее телеком-правило: никаких работ в пятницу после обеда. Лучше, вообще никаких работ в пятницу: всем хочется уйти вовремя и не убивать выходные.
  • +2
    где JDima? :)
    • +1
      В отпуске он…

      В консоли я увидел следующее – коммутатор (1) вывалился в rommon. Без единой ошибки. Просто rommon.

      Было дело, плавали. Вкратце: конфрег, отображаемый в show ver и show boorvar, не всегда равен реально проставленному конфрегу.
      Соответственно:
      Я решил, что экспериментировать и пробовать загрузить IOS из rommon’а не стоит.

      Зря. Одна команда из четырех букв, вполне вероятно, запустила бы шасси. Я ведь ничего не упустил, и TAC объявил суп 1-го коммутатора поломатым только на основании «не начинает грузить софт», никаких других ошибок он не демонстрировал?

      Ну про «дергать второй свитч, когда первый не загрузился» уже все сказали, не буду добавлять свое закономерное «фу-фу-фу» :) В целом, никаких особых претензий к самому по себе VSS я в статье не видел. Это могли быть и два обособленных свитча, катастрофу это не уменьшило бы.
      • 0
        Заключение TAC по поводу 1-го коммутатора: «По результатам диагностики выявлена аппаратная проблема с памятью adjacency table».
      • 0
        По супу 2-го коммутатора: «Нарушена коммуникация между RP и SP процессорами».
        По линейной карте: «В таблицах тестов обнаружилась строка „TestL3VlanMet------------>F“, которая указывает на аппаратную неисправность оборудования.
        • 0
          Черт побери.

          В общем, это был не ваш день. Определенно.
          • +1
            Количество седых волос в ту ночь прибавилось определенно.
            • +1
              Мы обсудили ваши проблемы и пришли к выводу что вам определенно стоит попробовать сыграть в лотерею. С тем стечением обостоятельств что вы словили есть все шансы выиграть джек-пот в лотерею. Дважды.

              PS. Просто очень неудачное стечение обстоятельств и выход из строя кучи оборудования одновременно.
  • 0
    Ну а по поводу «Наша сетевая инфраструктура является полностью production и должна быть доступна практически 24*7*365»
    Затея «VSS на два шасси, по одному супу в каждом» куда меньше способствует 100% аптайму, чем «два независимых шасси, по два супа в каждом»… При малейшем чихе одно из шасси в лучшем случае перезагрузится (соответственно — суровые требования к дизайну). И учитывая печальный опыт, имеет смысл вставить еще по супу в каждое из шасси и поднять quad-sup SSO. При фейловере шасси с активным супом все равно перезагрузится, но будет теплый резерв. Sup2T приятнее — у него все 4 супа могут быть полностью прогружены, и шасси уже не обязано падать.

    Кстати, htol, как знаток cat6500 скажи (если имеешь право) — решение не добавлять такую приятную фичу в sup720 было вызвано техническими или маркетиновыми причинами?
    • 0
      Планов делать Quad sup SSO для vs-s720 пока нет. Это действительно намного сложнее чем для s2t. Если появится бизнес кейс, возможно начнут реализацию, но мне с трудом верится, что кто-то захочет в это вкладываться. 720-е потихоньку уходят в eos/eol

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.