Находчивость и смекалка. Как мы теперь чиним железки Cisco
В нашу лабораторию небольшим, но стабильным потоком потекли железки, которые раньше обслуживались в сервис-центрах производителей. Вместе с ними появились и новые загадочные случаи с почти необъяснимыми багами. Скажу честно, что мы не были к этому готовы, но стараемся изо всех сил.
Сегодня расскажу о том, как искали причины и устраняли одну такую странную поломку в ASA, а заодно объясню, как наш отдел справляется со сложившейся ситуацией.
Меня зовут, Андрей Тарасов, я руководитель группы поддержки сетевой инфраструктуры в КРОК. Мой отдел занимается поддержкой корпоративных проводных и беспроводных сетей, фабрик коммутации, систем обеспечения безопасности, телефонии и видеоконференцсвязи.
Железа мы раньше почти не касались, все оно по гарантии уезжало производителям, а мы просто ставили оборудование на подмену. Однако теперь с проблемами часто приходится разбираться самим, и за помощью обратиться некуда. Так что мы организовали новую, пока еще во многом импровизированную лабораторию и примерили на себя роль хардкорной железной техподдержки.
Большинство неисправностей, с которыми мы столкнулись за последние месяцы, связано с сетевыми коммутаторами. Где-то горят блоки питания, где-то нужно перезалить образ, где-то просто сбросить настройки к заводским. Однако попадается и техника посложнее. Так, уже пришлось изучить несколько неисправных межсетевых экранов.
У одного возникла проблема с жестким диском — типичная неисправность, которую несложно устранить. В другом сгорел микроконтроллер, который отвечает за шифрование.
Тот самый криптопроцессор
Из любопытства я нашел этот чип на eBay в составе сетевой карты, которая продается за 30 долларов. Копеечная деталь, но межсетевой экран пришлось отправить на склад, дожидаться, пока восстановятся логистические цепочки. А вот третий ASA заставил нас попотеть и почесать в затылке.
Загадочная циска
Это был Cisco ASA5525 с простым анамнезом: включается, но не загружается. Как водится, экран нормально работал, но внезапно и без видимых причин сломался.
Начали разбираться: подсоединились удаленно и увидели, что BIOS стартует, находит устройства на материнской плате, но затем выдает ошибку: «No images in / Error 15: File not found». ОС не загружается, будто ее и нет. Пришлось ехать на место, в надежде разобраться лично.
Наверняка давно разработаны методички для таких случаев, но то у вендора, мы же полагались на логику и здравый смысл. Первым делом решили проверить загрузку с USB-носителя, но контроллер не нашел USB-устройств.
Так как сетевые интерфейсы загружались, залили ISO на TFTP-сервер и указали загрузчику путь до него. Это сработало, ASA загрузился до конца, но USB-порты так и не заработали.
При попытке прогнать тесты для внутренней флэш-памяти, на которой находится загрузочный образ, ASA выдал ошибку: There are one or more sw-modules running on the system. Please shut down the sw-modules before attempting to run fsck on flash. При записи в память: Error copying system:/running-config (Not enough space on device). Error executing command [FAILED]. Форматированию она также не поддавалась.
Симптоматика наводила на мысль о неисправности встроенного флэш-накопителя, но замена проблему не решила. Эксплуатировать экран в таком виде, конечно, нельзя, так что пришлось установить запасной и вести злополучную железку на вскрытие в лабораторию.
Поиск решения: 3 тупика и верный путь
Далее начался этап занудного гугления и поиска технической документации, но в нем нет ничего интересного, в отличие от конструкции и программной архитектуры ASA.
Для начала немного о софте. В телеком-системах Cisco используется трехуровневая загрузка. Первый уровень — BIOS, который, как и положено, стартует сразу после включения. Потом управление передается ROMMON — это подпрограмма начальной загрузки, которая инициализирует оборудование и загружает третью часть ПО — Cisco IOS. Таким образом, чтобы исправить проблему, нужно понять, на каком этапе загрузки происходит сбой.
Cisco ASA имеет схемотехнику обычного сервера, и для начала коллеги решили подключить к нему стандартную серверную диагностическую карту и посмотреть по кодам ошибок BIOS, почему устройство не загружается до конца.
Карта действительно выводила коды, но какие то-то странные. Они совершенно не сходились с инструкцией и не поддавались расшифровке. Все, что мы поняли: загрузка доходит до какого-то места и очень долго висит на одном коде, хотя должна идти дальше. Интересно, но, с практической точки зрения, это тупик.
В то же время мы изучили разводку материнской платы. Оказалось, что внутренний флеш накопитель с Cisco IOS висит на USB-контроллере. Контроллер же, напомню, не находит никаких устройств. Возможно, из строя вышло плечо.
Первое время работали с железом почти на коленке
На материнской плате было 8 USB-портов. Причем схематически они распределены на 2 независимых контроллера, висящих на разных прерываниях, по 4 порта на каждом. Попробовали перепаять flash-память на порт второго контроллера. К сожалению, это не помогло.
Еще мог сгореть южный мост на материнской плате, но эту гипотезу не проверить без его замены. Мало того что это трудоемкое дело, так еще запчасть взять негде. Еще один тупик. Однако все возможные варианты неисправностей еще не исчерпаны, тем более в наличии был подходящий программатор.
Для начала один из наших инженеров снял дамп с микросхемы с настройками пользователя. Объем памяти там всего 4 КБ. Внутри хранятся IP-адреса, название образа, откуда следует загружаться системе, и путь к нему.
Ниже центра кадра расположен SMT-чип, а в левом верхнему углу— EEPROM
Предположили, что какие-то пользовательские настройки могут влиять на то, что система не видит USB-контроллер. Перепрошили схему и вернули на место, но и это не решило проблему.
На следующем этапе исследований мы извлекли чип, в котором хранятся BIOS и ROMMON. Слили дамп и стали изучать код. По нему было ясно видно, сколько места занимает BIOS, что после него идет ROMMON, а потом — дамп с памятью, однако, на полноценный реверс-инжиниринг прошивки просто не было времени. Поэтому мы пошли прямым путем — сняли дамп с заведомо рабочего чипа из аналогичного ASA, перепрошили микросхему и впаяли назад — вуаля! — межсетевой экран загрузился до конца. Система увидела USB-контроллер и, соответственно, смогла считать Cisco IOS.
Внутренний флеш-накопитель с BIOS и ROMMON
Судя по всему, причиной проблем было повреждение матрицы ПЗУ где-то в том секторе, который отвечает за инициализацию USB-контроллера.
Бывает так, что из-за брака памяти по определенным адресам пропадает содержимое, но в таком случае этот участок либо не поддается стиранию и перезаписи, либо перезаписывается с частыми ошибками. Для контроля мы несколько раз стерли и перепрошили проблемную микросхему разными дампами с инверсией битовых комбинаций, чтобы исключить все возможные проблемы с залипанием битов. Процессы прошли хорошо, значит, физически матрица исправна, микросхема живая.
К сожалению, нельзя точно сказать, почему возник сбой. Есть только смутные предположения: либо виноват скачок по питанию, либо некое внешнее воздействие.
Сложно представить, как кто-то в большой компании целенаправленно ковыряется в межсетевом экране, но кто знает. А может быть, зловред попытался перепрошить микросхему. Как бы там ни было, надежность оборудования после ремонта не снизилась. В этом случае замена компонентов не потребовалась, а паяем мы на совесть. Межсетевой экран был восстановлен до заводского уровня.
Наша команда уже подготовила методику, базовый регламент проверки работоспособности телеком-оборудования. Кроме того, мы закупили необходимые ROM-микросхемы, чтобы сразу ставить новый компонент, а не тратить время на тестирование старой микросхемы на работоспособность.
После восстановления ставим устройства на прогонку, эмулируем боевые режимы. Стараемся давать максимальную нагрузку и дополнительно собираем специальные стенды для нагрузочного тестирования. Ни один агрегат не выходит из лаборатории, пока не убедимся в его работоспособности.
Впрочем, если проблема вызвана сбоем питания, то не исключено ее повторение — не обязательно у этого клиента, может, у другого. Тогда придется обновить рекомендации по установке и эксплуатации этой модели экранов.
Очевидно, что к нам будет попадать все больше оборудования вендоров, прекративших поддержку, поэтому мы стараемся сделать все, чтобы наладить и оптимизировать эксплуатацию и ремонт. Прежде всего — создаем базу знаний. Снимаем дампы со всех проходящих через наши руки микросхем, чтобы в случае необходимости они были под рукой. Ищем в сети документацию, описания распространенных проблем и пути их решения.
Постепенно, по мере необходимости закупаем оборудование. Полгода назад мы взялись за починку первого коммутатора с одним столом, кусачками и паяльником. С тех пор мы обзавелись и паяльной станцией, и программаторами, и нормальным освещением. Вот-вот привезут инфракрасный стол. Но главное, наша команда набирается опыта, справляется с трудностями и выручает оставшихся без поддержки клиентов.
--
Из-за массового ухода вендоров с российского рынка мы стали получать практически в два раза больше заявок на сервисную поддержку. Справляться с потоком помогает центр сервисных компетенций CROC Service Partner, в котором собраны экспертиза и практика комплексной мультивендорной поддержки всех типов ИТ-инфраструктуры: вычислительной, сетевой, облачной, программной, инженерной, мультимедийной и телефонии в формате «единого окна».
10 ноября мы приглашаем тех, кто интересуется ситуацией с техподдержкой, в офис КРОК на CROC Service Partner Day. Мы расскажем, как сохранить работоспособность инфраструктуры, на каких условиях можно обеспечить сервисную поддержку в критической ситуации и в долгосрочной перспективе, и как сегодня выбрать надежного сервисного партнера. Проведем экскурсию по ключевым локациям нашего офиса, покажем лаборатории и склады ЗИП. Вы познакомитесь с нашей командой и увидите, как работает сервис КРОК.
Кстати, интересное и актуальное публикуем в нашем ТГ-канале @crocit. Приходите почитать.
