Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 83
Как страшно жить.
Тут рядом стоят Juniper, DLink… курят, переминаются, обсуждают… обстановка нервная, но не агрессивная.
> На наш вопрос о том, каким образом мы ранее могли узнать о неисправности супервизоров и, соответственно, зная об этом, не перезагружать их — нам не ответили.
Может быть попробуете додавить их по этому вопросу. А то странно все это.
Пробовали гуглить подобную проблему, есть что-ть по теме?
Может быть попробуете додавить их по этому вопросу. А то странно все это.
Пробовали гуглить подобную проблему, есть что-ть по теме?
Ни чего странного. Переходные процессы. Ведает о нем первый же курс Электротехники. После перезагрузки устройста, до установленя нормального режима работы, на компоненты действуют силы большие чем номинальные. Что часто приводит к выходу их из строя.
В данном случае человеку экслючивно не повезло. Такое бывает.
Но вот что реально странно. Зачем потребовалось перезагружать второе шасси до восстановления работы первого? Лично я считаю что нормальный план по проверки непрерывности оказываемого сервиса обязан включать в себя регулярные перезагрузки оборудования. Они эмулируют сбой и наглядно показывают недочеты или наоборот, что все хорошо. На таких проверках и можно выявить такого рода неисправности.
В данном случае человеку экслючивно не повезло. Такое бывает.
Но вот что реально странно. Зачем потребовалось перезагружать второе шасси до восстановления работы первого? Лично я считаю что нормальный план по проверки непрерывности оказываемого сервиса обязан включать в себя регулярные перезагрузки оборудования. Они эмулируют сбой и наглядно показывают недочеты или наоборот, что все хорошо. На таких проверках и можно выявить такого рода неисправности.
вот так и появляются нездоровые сенсации — сейчас большая часть людей толком не понявших в чем дело будут думать что VSS — гавно и цыска — SOHO. мне бы не пришла в голову идея перезапустить активный резерв при неработающем основном свитче имея меньше часов шести времени в запасе…
Честно, мне не могло придти в голову, что два супа могут выйти из строя одновременно и я рассчитывал, что второе шасси уж точно заведется повторно. Был не прав.
Посыл автора в том, что не надо уповать на бренд и платную техподдержку. И именно этим пост полезен для всех. Аппартная проблема сразу на обоих нодах отказаустойчивого кластера плюс человеческий фактор, автору реально неповезло. Кстати, так как оба устройства из одной партии есть ненулевой шанс того, что они выйдут из строя одновременно с одинаковой проблемой. К примеру многие сталкивались с такой бедой когда из зеркального рейда сначала вылетает один диск, а еще через несколько дней второй и системный администратор начинает рвать на голове последние волосы, а директор ему говорит «Ты ж специалист, хули ж ты? Даже мне очевидно, что надо сразу же было подцепить резервный диск, а не сиськи мять»
Да и подстава с перезагрузками та еще, нужен какой-то регламент с регулярным проведением таких испытаний, полностью выключить питание и включить.
У нас была проблема в HP DL160G6, из 8 серверов со временем у 4 вылетели БП, сервак работает нормально все хорошо, выключаешь питание — больше не включается.
Аналогично и длинковский коммутатор поступал, но тут уже бренд обязывает :-D
У нас была проблема в HP DL160G6, из 8 серверов со временем у 4 вылетели БП, сервак работает нормально все хорошо, выключаешь питание — больше не включается.
Аналогично и длинковский коммутатор поступал, но тут уже бренд обязывает :-D
Дайте номер кейса, почитать. Может там и написано как инженер определил что супервизоры дохлые. =)
все нормально, кроме выключения 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 вланов через один из свичей со второго тупо не проходит, хотя порт доверенный. Отключаю инспекцию этого влана — всё полетело.
Почти целый день убил на обход этих приколов.
Обновил недавно на 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 вланов через один из свичей со второго тупо не проходит, хотя порт доверенный. Отключаю инспекцию этого влана — всё полетело.
Почти целый день убил на обход этих приколов.
Только в последнее время? ;)
Да, раньше как-то стабильнее было, а тут скачешь с версии на версию и ищешь где багов поменьше. Хотя, казалось бы, уж свичи могли бы допилить, там иосы в 5-6 раз меньше, чем в роутерах, технологий меньше, глючить почти нечему :)
Если вы про коммутаторы, то я соглашусь. Раньше они работали очень хорошо вне зависимости от релиза. На 12.2.5x каком-то была неприятная бага года так 4-ре назад. А так все было хорошо.
А вот если привнести сюда роутеры, то с ними ситуация была такая.
Нужен конкретный набор фич, и сидишь перебираешь ios-ы выясняя, в каком ios-е все эти фичи заработают в полном обьеме. Потом нужно еще новую фичу добавить, пробуешь в текущем — не получается. Опять сидишь и ищешь ту версию где всё, что тебе нужно заработает.
Потом с этим попроще стало, базовые вещи в ios таки вылизали.
Кроме роутеров, есть другие технологии, а уж там глюков… Могу книги писать на тему Cisco И Баги.
А вот если привнести сюда роутеры, то с ними ситуация была такая.
Нужен конкретный набор фич, и сидишь перебираешь ios-ы выясняя, в каком ios-е все эти фичи заработают в полном обьеме. Потом нужно еще новую фичу добавить, пробуешь в текущем — не получается. Опять сидишь и ищешь ту версию где всё, что тебе нужно заработает.
Потом с этим попроще стало, базовые вещи в ios таки вылизали.
Кроме роутеров, есть другие технологии, а уж там глюков… Могу книги писать на тему Cisco И Баги.
Да, на роутерах вообще весело: есть IPSEC, казалось бы — стандартизованная технология! И не только внутре цыски, а вообще — мультивендорно.
Дано — небольшой DMVPN, пара 2901 хабами, кучка 880ых споками. Так вот у первых иос был вроде 15.2, а у вторых — 15.3.
Так вот, IPSEC между ними не поднимался, то есть вообще. Всё настроено было стандартно через tunnel protection и ikev2
Обновляешь хабы до 15.3 и всё сверкает свежими красками! Откатываешь споки до 15.2 — аналогично. В конфигах ничего не менялось.
То есть получается, что айписек у цыски совместим только в пределах одного мажорного режима IOS? Смех и грусть.
Дано — небольшой DMVPN, пара 2901 хабами, кучка 880ых споками. Так вот у первых иос был вроде 15.2, а у вторых — 15.3.
Так вот, IPSEC между ними не поднимался, то есть вообще. Всё настроено было стандартно через tunnel protection и ikev2
Обновляешь хабы до 15.3 и всё сверкает свежими красками! Откатываешь споки до 15.2 — аналогично. В конфигах ничего не менялось.
То есть получается, что айписек у цыски совместим только в пределах одного мажорного режима IOS? Смех и грусть.
Тут может быть проблема в том, что разные параметры по умолчанию в разных релизах. Эти параметры не показываются в sh run, но замечательно работают. Поэтому, чтобы оно заработало, нужно читать Release Notes, Configuration Guides, Troubleshooting guides. Вообще для ipsec debug-и очень понятные, по сравнению с некоторыми другими технологиями.
Дебаги, конечно, смотрел, но сейчас уже не вспомню в чем дело было, какой-то затык на первой фазе IPSEC, кажется.
На мысли как лечить не навело. Доки, конечно, тоже читал, но по-диагонали.
Для меня это странно, что какие-то важные дефолтные параметры, влияющие на сам факт работы протокола, меняются от версии к версии. Даже после апгрейда свичей с 12 до 15 иоса ничего не ломалось, про роутеры не помню.
На мысли как лечить не навело. Доки, конечно, тоже читал, но по-диагонали.
Для меня это странно, что какие-то важные дефолтные параметры, влияющие на сам факт работы протокола, меняются от версии к версии. Даже после апгрейда свичей с 12 до 15 иоса ничего не ломалось, про роутеры не помню.
Ну в свичах переход от версии 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 — полностью. Там много бывает важных вещей.
А что касается дефолтных параметров — нужно читать Release notes, хотя бы по диагонали все, а New and Changed option — полностью. Там много бывает важных вещей.
Посмотрите когда был релиз 12.2.(55)SE8 и 12.2(58)SE. Многое станет ясно. 12.2(57)SE не было. 12.2(58)SE была выпущена для очень узких потребностей. Показали, и больше её не развивали/не фиксили.
Заказчики разные есть. Согласен с вами. У Cisco есть отличная служба — Advanced Services. Они могут авторитетно заявить, что лучше конкретно для вас.
Заказчики разные есть. Согласен с вами. У Cisco есть отличная служба — Advanced Services. Они могут авторитетно заявить, что лучше конкретно для вас.
Ок. Я согласен 12.2.57 не было — привел для примера. Про 12.2.58 — это просто отлично. Кто-бы знал, что это по сути 12.2.55XYZ (боковое ответвление софта)
А как получить эти Advanced Services? Какая строчка в GPL?
А как получить эти Advanced Services? Какая строчка в GPL?
На сколько я знаю, это очень дорого и индивидуально. Сильно зависит от инсталяционной базы. Обратитесь к своему аккаунт менеджеру.
Понятно. Это только для очень больших компаний.
А посылать к account manager-у это уже все равно что посылать на три буквы. Нет, он конечно приедет, может даже не один, сиящий, с галстукои и IPad-ом. Запишет твои проблемы и уедет. И опять ничего не изменится :) Account manager это такая психологическая поддержка от Cisco, иногда на дому.
А посылать к account manager-у это уже все равно что посылать на три буквы. Нет, он конечно приедет, может даже не один, сиящий, с галстукои и IPad-ом. Запишет твои проблемы и уедет. И опять ничего не изменится :) Account manager это такая психологическая поддержка от Cisco, иногда на дому.
С чего Вы взяли, что это «вроде как релиз чисто багфиксный». Рекомендую прочитать что значит ED, и не путать с MD.
Для большинства access коммутаторов рекомендуется 12.2(55)SE8.
Для большинства access коммутаторов рекомендуется 12.2(55)SE8.
Хм. 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 «потому что там баги пофикшены»?
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 «потому что там баги пофикшены»?
Я, звиняюсь, а вы где видели MD у свичей 2960 или 3750? Там все релизы ED, что 15.х, что 12.х, сгоняйте на сайт цыски да убедитесь. У роутеров — пожалуйста, а тут неет. Что ж мне бедному юзать, если оно там всё для продакшена не готово?
Под «багфиксный» я подразумеваю по отношению к тому, что уже стояло (15.0(2)SE4 и ниже)
Кем? У меня оно стоит на старых 3560 с 16мб флеша, туда 15.х тупо не влазит. Работает, да, всё ок.
Но и с 15.х до последних горе-релизов проблем особых не было — всё работало. Но вот чёрт дёрнул обновиться планово…
Под «багфиксный» я подразумеваю по отношению к тому, что уже стояло (15.0(2)SE4 и ниже)
Для большинства access коммутаторов рекомендуется 12.2(55)SE8
Кем? У меня оно стоит на старых 3560 с 16мб флеша, туда 15.х тупо не влазит. Работает, да, всё ок.
Но и с 15.х до последних горе-релизов проблем особых не было — всё работало. Но вот чёрт дёрнул обновиться планово…
А к чему вопрос видел я или нет? Нет MD на ССO. Это очевидно. Рекомендация от разработчиков.
Вопрос к тому, что мне считать стабильной версией? Вы говорите — MD, а его нет. Есть 15.2.1, но он явно не стабилен.
Есть 15.0.2, который уже 5 SE поимел. Я, по логике разработки софта, выбираю его как золотую середину.
Товарищи из циско, судя по всему, не заморачиваются над нормальным циклом разработки: разработали версию, заморозили фичи, правим баги, параллельно разрабатываем ветку с новыми фичами и всё еще правим баги в старой.
По крайней мере по отношению к коммутаторам это, похоже, так.
Есть 15.0.2, который уже 5 SE поимел. Я, по логике разработки софта, выбираю его как золотую середину.
Товарищи из циско, судя по всему, не заморачиваются над нормальным циклом разработки: разработали версию, заморозили фичи, правим баги, параллельно разрабатываем ветку с новыми фичами и всё еще правим баги в старой.
По крайней мере по отношению к коммутаторам это, похоже, так.
Боюсь Вы меня не правильно поняли. Я всего лишь сказал, что ED ни когда не считалась версией только с фиксами багов и попросил не вводить в заблужение других.
По поводу остального, это всего лишь ваши домыслы. Думаю наберетесь опыта и будет все лучше. Судя по всему желание есть.
По поводу остального, это всего лишь ваши домыслы. Думаю наберетесь опыта и будет все лучше. Судя по всему желание есть.
А все таки, как простым инженерам (не инженерам TAC) выбирать «самый стабильный» ios для Cisco Catalyst?
12.2(55)SE8 — хорошо, но почему? Где посмотреть, когда он изменится?
Пока прослеживается только один алгоритм — самая большая цифра после SE.
12.2(55)SE8 — хорошо, но почему? Где посмотреть, когда он изменится?
Пока прослеживается только один алгоритм — самая большая цифра после SE.
Параметров много. Разработчики делаю регулярный анализ дефектов. Присваивают им веса. По результатам дают рекомендации. TAC не имеет права рекомендовать конретную версию IOS в кейсе. Можно сказать лишь, когда испраление дефекта было включено в релиз. Ну или посмотреть, что советуют разработчики в общем случае, для конкретной платформы.
Установка последней версии часто является требованием разработчиков.
Установка последней версии часто является требованием разработчиков.
Да, и еще. Алгоритм выбора OS очень простой.
Если IOS не end of support. Нет дефекта или уязвимости, которые могут доставить вам неприятности. Нет новой нужной фичи, которую вы давно ждали. => Не обновляйтесь.
Если IOS не end of support. Нет дефекта или уязвимости, которые могут доставить вам неприятности. Нет новой нужной фичи, которую вы давно ждали. => Не обновляйтесь.
Раз считаете что домыслы, то аргументируйте. Я, как пользователь железа, хочу понимать — какой софт юзать безопасно, а какой — нет. В случае другого софта это, обычно, ясно (особенно в опенсурсе). Есть стабильные ветки, есть экспериментальные.
Как мне, зайдя на сайт Cisco и почитав Release Notes выбрать прошивку?
Как мне, зайдя на сайт Cisco и почитав Release Notes выбрать прошивку?
Я, как пользователь железа, хочу понимать — какой софт юзать безопасно, а какой — нет
Не бывает безопасного софта. Есть более глючный и есть менее глючный. «Stable» ветка в опенсорсе не гарантирует нормальную работу.
В принципе, рядом с некоторыми версиями софта выставляют значок «safe harbor». В случае 6500 он есть, например, на SXI12. Понятия не имею, что это на самом деле значит, но, возможно, количество выявленных багов ниже определенного порога.
Safe Harbor — программа тестирования. Включает очень большое количество сценариев типичного использования коммутаторов и взаимодействия фич между собой. + конечно же учитываются дефекты.
Не бывает безопасного софта. Есть более глючный и есть менее глючный. «Stable» ветка в опенсорсе не гарантирует нормальную работу.
Это и так всем очевидно, что никто ничего не гарантирует. Баги бывают везде. Но вот основной функционал должен работать, а не так что обновился до очередного SE и сломался DHCP Snooping совсем. Это одна из основных технологий акцес свича, уж ее то могли протестировать.
Вообще такие истории всегда — мрак неприятные.
С одной стороны архитекторы должны гореть в аду, за такой дизайн сети. 6708 у вас одна, это фатальная ошибка. Отказ CrossBar не такая и редкость, бывали случаи когда не работает слот, но шасси работает нормально. Линейные карты на такой enviroment должны быть всегда дублированы, да это дорого, но это вопрос к коэффициенту «А».
Второй фатал, это решение вывести второй коммутатор на maintense, вопрос напрашивается сам собой — зачем?
Вопрос номер три, почем вы полезли на maintense в одиночку, я имею не вас конкретно, а тех людей которые не запросили тех под на возможность подмоги. Почему вы не оповести их о окне, и не запросили статус ЗИП? Вам крупно повезло что у них вообще SUP оказался, это просто свыше решили не устраивать хардкор.
Вопрос номер четыре, почему дизайн сети не предусматривает преодоление Disaster? Все очень просто, дизайн сети должен быть рассчитан на возможность получения двойного отказа (а именно он у вас и произошел). У меня зреет вопрос, как допустили отсутствие резервных линков между узлами агрегации? Ведь можно сделать легкий setup 10GE -> 1GE, преодолеть двойной отказ с понижением в скорости и дальше продолжить работать над решением сложившейся ситуации?
Можно Вас попросить назвать именаархитекторов/дизайнеров героев. Ну так, на всякий случай, не пускать их близко.
С одной стороны архитекторы должны гореть в аду, за такой дизайн сети. 6708 у вас одна, это фатальная ошибка. Отказ CrossBar не такая и редкость, бывали случаи когда не работает слот, но шасси работает нормально. Линейные карты на такой enviroment должны быть всегда дублированы, да это дорого, но это вопрос к коэффициенту «А».
Второй фатал, это решение вывести второй коммутатор на maintense, вопрос напрашивается сам собой — зачем?
Вопрос номер три, почем вы полезли на maintense в одиночку, я имею не вас конкретно, а тех людей которые не запросили тех под на возможность подмоги. Почему вы не оповести их о окне, и не запросили статус ЗИП? Вам крупно повезло что у них вообще SUP оказался, это просто свыше решили не устраивать хардкор.
Вопрос номер четыре, почему дизайн сети не предусматривает преодоление Disaster? Все очень просто, дизайн сети должен быть рассчитан на возможность получения двойного отказа (а именно он у вас и произошел). У меня зреет вопрос, как допустили отсутствие резервных линков между узлами агрегации? Ведь можно сделать легкий setup 10GE -> 1GE, преодолеть двойной отказ с понижением в скорости и дальше продолжить работать над решением сложившейся ситуации?
Можно Вас попросить назвать имена
Я извиняюсь за опечатку — линейная карта, вышедшая из строя была WS-X6724-SFP, а не WS-X6708-10GE как я написал. Исправлю. Поясните — в чем фатальная ошибка иметь одну 6708 в шасси? В том, что только на ней есть DFC? Ну ведь и без DFC коммутация трафика будет происходить, но медленнее.
Про второй фатал — ответил выше в комментах.
К ответу на 3й вопрос — наверное, избыточная самоуверенность. Я уже пообщался с коллегами из старшего подразделения — они на абсолютно все профилактические работы вызывают на площадку сервисного инженера для подстраховки. Возьму на вооружение.
Вопрос четыре. Дизайн сети нам достался по наследству. Архитекторов не знаю. Бюджет организации не предполагает закупок дубля итак задублированного оборудования. А тем более, объяснить руководству необходимость закупки дубля уже задублированного оборудования, которое, как показала практика, даже задублированное может выйти из строя одновременно — не представляется возможным. Спросят — зачем вообще такое железо нужно? И у нас гос. контора, не забывайте. А так, конечно, при наличии финансирования можно построить «надутую энтерпрайзную» схему (понравилась формулировка из коммента ниже).
Про второй фатал — ответил выше в комментах.
К ответу на 3й вопрос — наверное, избыточная самоуверенность. Я уже пообщался с коллегами из старшего подразделения — они на абсолютно все профилактические работы вызывают на площадку сервисного инженера для подстраховки. Возьму на вооружение.
Вопрос четыре. Дизайн сети нам достался по наследству. Архитекторов не знаю. Бюджет организации не предполагает закупок дубля итак задублированного оборудования. А тем более, объяснить руководству необходимость закупки дубля уже задублированного оборудования, которое, как показала практика, даже задублированное может выйти из строя одновременно — не представляется возможным. Спросят — зачем вообще такое железо нужно? И у нас гос. контора, не забывайте. А так, конечно, при наличии финансирования можно построить «надутую энтерпрайзную» схему (понравилась формулировка из коммента ниже).
В вашем случае две линейные карты через которые вяжется VSS link нужны для простой отказоустойчивости. Ведь нет гарантии того что не откажет карта или слот? Таким образом вы увеличиваете коэффициент «А», устраняя точки отказа. Представьте ситуацию, отказывает карта на которой у вас повязан VSS? Как будет развиваться ситуация не известно никому, может пройдет split brain, а может ПО преодолеет эту ситуацию путем отключения одной коробки. Вариант перевязывать VSS через SUP тоже смертельный трюк, т.к. если на CP случиться авария, лазеры потухнут автоматически. Так что проще две карты, больше шансов на выживание.
Надувать не надо, надо трезво оценивать бюджет, выводить «А», и говорить руководству бумагой. Вот бумага, «А», такой-то, надо еще вот это и мы закроем вот это, на такой-то период.
Надувать не надо, надо трезво оценивать бюджет, выводить «А», и говорить руководству бумагой. Вот бумага, «А», такой-то, надо еще вот это и мы закроем вот это, на такой-то период.
Да ну нафиг. Может быть просто надо было держать резервную прошивку? И попробовать грузануть ее? А может еще и резервный конфиг, с минимальными BGP-функциями и отключенным VSS-ом после перезагрузки?
> Но я, подумав на конфликт нод, решил погасить 2й коммутатор, подключить ноут к консоли первого и попробовать его включить в одиночку
вот тут все и началось. надо у вас уже был аварийный режим работы, как пришло в голову валить вторую кошку — ума не приложу
вот тут все и началось. надо у вас уже был аварийный режим работы, как пришло в голову валить вторую кошку — ума не приложу
Хех…
У нас тоже песня была с VSS.
Сначала весь VSS тупо встал колом — т.е. трафик гоняет, но не зайти. В локальную консоль, через кабель, ЧСХ, пускал. Благо, все равно собирались менять на ASR1001. Заменили, проверили — сдох SUP. До этого сдохла линейная карта после банального апгрейда IOS. На той же паре шасси после ребута сдох еще и второй суп. Хорошо что кошки уже не в эксплуатации были, так что играться можно было вволю. Ну и smartnet, да.
P.S. А так все гуд, кроме шатдауна циски в отсутствие резерва
У нас тоже песня была с VSS.
Сначала весь VSS тупо встал колом — т.е. трафик гоняет, но не зайти. В локальную консоль, через кабель, ЧСХ, пускал. Благо, все равно собирались менять на ASR1001. Заменили, проверили — сдох SUP. До этого сдохла линейная карта после банального апгрейда IOS. На той же паре шасси после ребута сдох еще и второй суп. Хорошо что кошки уже не в эксплуатации были, так что играться можно было вволю. Ну и smartnet, да.
P.S. А так все гуд, кроме шатдауна циски в отсутствие резерва
Если хотите надутый энтерпрайз-ответ — у вас должна быть лаборатория с оборудованием, эквивалентным продакшену, которая заодно выступает в качестве холодного резерва.
Там отлаживаются все изменения, оно же служит в качестве второго резерва.
Да, такое отвоёвывать тяжко — но такова работа админа.
Там отлаживаются все изменения, оно же служит в качестве второго резерва.
Да, такое отвоёвывать тяжко — но такова работа админа.
Сочувствую автору. Реально подстава.
Энтерпрайз ответ к сожалению будет скорее: «всё работало, циска не может не работать, это ваши инженера пылесосом все сломали».
Энтерпрайз ответ к сожалению будет скорее: «всё работало, циска не может не работать, это ваши инженера пылесосом все сломали».
Выключение второго коммутатора при неработающем первом – это был очень оптимистичный поступок.
А почему, кстати, в 6509E всего по одному супервизору? Второй не был запланирован к закупке?
И ещё: насколько оправдано ежеквартальное выключение шеститонника для чистки пылесосом? В серверной настолько пыльно? Я встречался с одним 6509, который три года проработал без выключения, и только через три года добрая душа прошлась по БП… так, снаружи немного :)
Не повезло вам, сочувствую. Кстати, как таковая «хронология» до 6 утра отсутствует, а дальше – хромает.
А почему, кстати, в 6509E всего по одному супервизору? Второй не был запланирован к закупке?
И ещё: насколько оправдано ежеквартальное выключение шеститонника для чистки пылесосом? В серверной настолько пыльно? Я встречался с одним 6509, который три года проработал без выключения, и только через три года добрая душа прошлась по БП… так, снаружи немного :)
Не повезло вам, сочувствую. Кстати, как таковая «хронология» до 6 утра отсутствует, а дальше – хромает.
Добавлю ложку дёгтя в VSS на шеститонниках. При апгрейде отказали по 2 лайн-карты на каждом холодильнике. Железно отказали. Хорошо на access-свитчах портов хватило и контракт был 24х7х4. Но от VSS после этого отказались и больше я его никому не советую.
И да, ребутить второй коммутатор, не взглянув консолью на не поднимающийся первый — немного опрометчиво.
И да, ребутить второй коммутатор, не взглянув консолью на не поднимающийся первый — немного опрометчиво.
Далее, по плану была плановая чистка коммутаторов catalyst 6509E от пыли методом пылесоса. Эту операцию мы делаем регулярно (раз в квартал) и ничего неестественного мы не ждали.
А зачем их пылесосить так часто? У нас стойка с цисками стоит 8 лет и за это время ни разу не было желания что то отключать и пылесосить и все работает без проблем.
Как говориться — работает и не трожь!
>>Как говориться — работает и не трожь!
Так оно всё работает. До определённого момента. А потом приходит он. Alopex lagopus.
Обслуживание и профилактика нужны.
После того, как до этого доходят сами админы есть ещё начальство, которое нужно в этом убедить.
Хорошо, если согласятся (как первый вариант). А могут кивать полгода/год, говоря «ну вот, не сейчас». Пока не придёт озвученный зверь (вариант второй).
Мне, к сожалению, пришлось работать через 2й вариант. После этого, конечно, уже не просто кивают, но и дают добро на действия.
Так оно всё работает. До определённого момента. А потом приходит он. Alopex lagopus.
Обслуживание и профилактика нужны.
После того, как до этого доходят сами админы есть ещё начальство, которое нужно в этом убедить.
Хорошо, если согласятся (как первый вариант). А могут кивать полгода/год, говоря «ну вот, не сейчас». Пока не придёт озвученный зверь (вариант второй).
Мне, к сожалению, пришлось работать через 2й вариант. После этого, конечно, уже не просто кивают, но и дают добро на действия.
Про серверную ответил выше. Про ребут второго шасси тоже. Был оптимистом. Виноват. Исправлюсь. Спасибо.
Боюсь, что вы не очень понимаете специфику. Есть технологическое окно с 2 ночи до 8 утра, что скорее всего обусловлено наименьшей нагрузкой; другого времени – нет. Хорошо, когда всё идёт по плану работ, но если вдруг появляются незапланированные действия – откладывать их до рабочего дня не лучшая идея.
Я бы вспомнил другое хорошее телеком-правило: никаких работ в пятницу после обеда. Лучше, вообще никаких работ в пятницу: всем хочется уйти вовремя и не убивать выходные.
Я бы вспомнил другое хорошее телеком-правило: никаких работ в пятницу после обеда. Лучше, вообще никаких работ в пятницу: всем хочется уйти вовремя и не убивать выходные.
где JDima? :)
В отпуске он…
Было дело, плавали. Вкратце: конфрег, отображаемый в show ver и show boorvar, не всегда равен реально проставленному конфрегу.
Соответственно:
Зря. Одна команда из четырех букв, вполне вероятно, запустила бы шасси. Я ведь ничего не упустил, и TAC объявил суп 1-го коммутатора поломатым только на основании «не начинает грузить софт», никаких других ошибок он не демонстрировал?
Ну про «дергать второй свитч, когда первый не загрузился» уже все сказали, не буду добавлять свое закономерное «фу-фу-фу» :) В целом, никаких особых претензий к самому по себе VSS я в статье не видел. Это могли быть и два обособленных свитча, катастрофу это не уменьшило бы.
В консоли я увидел следующее – коммутатор (1) вывалился в rommon. Без единой ошибки. Просто rommon.
Было дело, плавали. Вкратце: конфрег, отображаемый в show ver и show boorvar, не всегда равен реально проставленному конфрегу.
Соответственно:
Я решил, что экспериментировать и пробовать загрузить IOS из rommon’а не стоит.
Зря. Одна команда из четырех букв, вполне вероятно, запустила бы шасси. Я ведь ничего не упустил, и TAC объявил суп 1-го коммутатора поломатым только на основании «не начинает грузить софт», никаких других ошибок он не демонстрировал?
Ну про «дергать второй свитч, когда первый не загрузился» уже все сказали, не буду добавлять свое закономерное «фу-фу-фу» :) В целом, никаких особых претензий к самому по себе VSS я в статье не видел. Это могли быть и два обособленных свитча, катастрофу это не уменьшило бы.
Заключение TAC по поводу 1-го коммутатора: «По результатам диагностики выявлена аппаратная проблема с памятью adjacency table».
По супу 2-го коммутатора: «Нарушена коммуникация между RP и SP процессорами».
По линейной карте: «В таблицах тестов обнаружилась строка „TestL3VlanMet------------>F“, которая указывает на аппаратную неисправность оборудования.
По линейной карте: «В таблицах тестов обнаружилась строка „TestL3VlanMet------------>F“, которая указывает на аппаратную неисправность оборудования.
Ну а по поводу «Наша сетевая инфраструктура является полностью production и должна быть доступна практически 24*7*365»
Затея «VSS на два шасси, по одному супу в каждом» куда меньше способствует 100% аптайму, чем «два независимых шасси, по два супа в каждом»… При малейшем чихе одно из шасси в лучшем случае перезагрузится (соответственно — суровые требования к дизайну). И учитывая печальный опыт, имеет смысл вставить еще по супу в каждое из шасси и поднять quad-sup SSO. При фейловере шасси с активным супом все равно перезагрузится, но будет теплый резерв. Sup2T приятнее — у него все 4 супа могут быть полностью прогружены, и шасси уже не обязано падать.
Кстати, htol, как знаток cat6500 скажи (если имеешь право) — решение не добавлять такую приятную фичу в sup720 было вызвано техническими или маркетиновыми причинами?
Затея «VSS на два шасси, по одному супу в каждом» куда меньше способствует 100% аптайму, чем «два независимых шасси, по два супа в каждом»… При малейшем чихе одно из шасси в лучшем случае перезагрузится (соответственно — суровые требования к дизайну). И учитывая печальный опыт, имеет смысл вставить еще по супу в каждое из шасси и поднять quad-sup SSO. При фейловере шасси с активным супом все равно перезагрузится, но будет теплый резерв. Sup2T приятнее — у него все 4 супа могут быть полностью прогружены, и шасси уже не обязано падать.
Кстати, htol, как знаток cat6500 скажи (если имеешь право) — решение не добавлять такую приятную фичу в sup720 было вызвано техническими или маркетиновыми причинами?
Эм, а сетевики и впрямь регулярно работают по ночам? Или это исключение чем правило? Как это описано в трудовом договоре, есть ли доплаты за «ночные смены»?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Cisco VSS: страх и ненависть на работе