Способы контроля за сетевыми ресурсами

9 способов контроля доступа устройств к ресурсам сети

Cетевой обмен по протоколу SMB / SAMBA

Одним из способов доступа с STB к файлам, расположенным на сетевых компьютерах, является протокол общего доступа SMB, который является стандартным протоколом Microsoft Windows и обеспечивает функции «Сети Microsoft Windows» и «Совместного использования файлов и принтеров» . Samba — свободная реализация протокола SMB для UNIX-подобных и других операционных систем.

Видео

Низкоуровневые средства общего доступа. Протокол DAFS

Архитектура виртуального интерфейса

Архитектура виртуального интерфейса (VIA) — это совместная разработка Microsoft, Intel и Compaq, которая определяет абстрактную модель низкоуровневой технологии ввода/вывода. VIA используется для организации высокоскоростного обмена данными между двумя процессами, которые работают на разных серверах или системах хранения в центрах обработки данных (ЦОД).

Virtual Interface (VI) — это протокол связи в архитектуре Virtual Interface Architecture

DAFS (Direct Access File System) — это стандартный протокол файлового доступа, который базируется на NFS v4. Он позволяет прикладным задачам передавать данные в обход операционной системы и ее буферного пространства напрямую к транспортным ресурсам, сохраняя семантику, свойственную файловым системам. DAFS использует преимущества новейших технологий передачи данных по схеме память-память. Его использование обеспечивает высокие скорости файлового ввода-вывода, минимальную загрузку CPU и всей системы, благодаря значительному уменьшению количества операций и прерываний, которые обычно необходимы при обработке сетевых протоколов. Особенно эффективным является использование аппаратных средств поддержки VI (Virtual Interface).

Кратко описать алгоритм работы DAFS можно следующим образом: пусть имеются два приложения, осуществляющие доступ к сети при помощи сетевого интерфейса пользовательского уровня (VI, рис. 3), тогда:

1. Драйвер устройств операционной системы управляет аппаратными средствами интерфейса традиционным способом, осуществляя контроль за доступом приложений к оборудованию.
2. Приложения выделяют буферы сообщений в собственном адресном пространстве и обращаются к драйверу устройств для получения доступа к сетевому интерфейсу. После соответствующей настройки они автоматически инициируют процесс передачи и приема, а интерфейс пересылает информацию в буферы приложений и в обратном направлении, используя обычный механизм прямого доступа к памяти (direct memory access, DMA)

Рис. 3. Общий принцип работы DAFS

Приложения имеют доступ к сети с использованием виртуального интерфейса. Драйвер NIC ОС управляет сетевым контроллером и обеспечивает прямой доступ приложений к интерфейсу. Приложения выделяют буферы в собственном адресном пространстве, куда принимают и откуда отправляют сообщения, используя DMA.

Архитектура сетевого интерфейса пользовательского уровня варьируется в зависимости от особенностей конкретных приложений и сетей — от способа определения приложениями местоположения пересылаемых сообщений, от местонахождения выделяемых для приема информации буферов, от порядка уведомления приложений о поступивших сообщениях. В некоторых сетевых интерфейсах (например, в интерфейсах Active Message или Fast Message) операции передачи и приема реализованы в виде функций, помещенных в пользовательскую библиотеку, которая загружается при инициализации каждого процесса. В других (например, в U-NET и VIA) для каждого процесса создаются очереди, которыми манипулируют сами приложения. Эти очереди обслуживаются аппаратными средствами интерфейса.

DAFS спроектирован для сетей хранения данных (NAS) и используется в кластерном и серверном окружении баз данных и разнообразных Интернет-приложений, ориентированных на непрерывную работу. Он обеспечивает наименьшие задержки доступа к общим файловым ресурсам и данным, а также поддерживает интеллектуальные механизмы восстановления работоспособности системы и данных.

Открываем доступ к папке через командную строку

Наверное, самый быстрый метод создания сетевого раздела – через командную строку Windows 7 и 10.

Для этого делаем следующее:

1. Открываем «Пуск/Все программы/Стандартные/Командная строка» либо пишем команду «cmd» в поисковой строке.
2. В консоли вводим команду: «net share files=буква диска:\название папки». В нашем случае это «net share files=d:\Деловая документация» (без кавычек).

Становимся владельцем сетевой папки

В некоторых ситуациях вы можете столкнуться с проблемами в работе с расшаренным разделом. Если новый компьютер в сети не наделен правами пользования ресурсом, то вы получите сообщение о том, что у вас нет доступа к сетевой папке. Выходом из ситуации станет изменение политики безопасности путем смены владельца. Сделать это можно лишь имея права администратора.

Чтобы сменить владельца папки делаем следующее:

1. Выделяем интересующую нас папку, жмем правую кнопку мыши и выбираем «Свойства/Безопасность». После переходим в меню «Дополнительно».
2. В этом разделе пользователю доступны точные настройки доступа к папке и возможных действий над ней. Идем во вкладку «Владелец» и кликаем по «Изменить» в нижней части окна.
3. Теперь мы должны выбрать свою учетную запись. Чтобы доступ распространялся на все вложения, обязательно ставим галочку «Заменить владельца подконтейнеров и объектов».

По окончании настройки нажимаем «ОК» или «Применить». Если владелец был успешно изменен — система оповестит вас об этом в окне уведомления.

1. В десятой Windows есть небольшие отличия в структуре меню. Нажимаем синюю ссылку «Изменить», где выбираем свой профиль из списка. Отмечаем галочкой о замену владельца вложенных файлов и папок.

Завершаем настройку кнопкой «ОК».

Проблемы получения доступа к сетевым ресурсам

1. Выполните следующие действия:

1. • Пропинговать STB со стороны ПК (убедиться, что оба устройства могут взаимодействовать по сети). При необходимости восстановить сетевое взаимодействие;
   • Убедиться, что на сервере (ПК, с которого настраивается доступ) включена поддержка протокола SMB версии 1.
   • На компьютере проверить Настройку параметров общего доступа для различных профилей Windows.
   • На компьютере проверить Открытие доступа к папке.

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

Перезагрузить STB и ПК и повторить попытку соединения.

Источник

Сетевой мониторинг: как мы следим за тем, чтобы у крупных компаний работали все узлы

По виду этой оптики, идущей по лесу к коллектору, можно заключить, что монтажник немного не соблюдал технологию. Крепление на фото также подсказывает, что он, наверное, моряк – узел-то морской.

Я из команды обеспечения физической работоспособности сети, проще говоря – техподдержки, отвечающей за то, чтобы лампочки на роутерах мигали, как надо. У нас «под крылом» разные крупные компании с инфраструктурой по всей стране. Внутрь их бизнеса не лезем, наша задача – чтобы работала сеть на физическом уровне и трафик проходил как надо.

Общий смысл работы – постоянный опрос узлов, снятие телеметрии, прогоны тестов (например, проверка настроек для поиска уязвимостей), обеспечение работоспособности, мониторинг приложений, трафика. Иногда инвентаризации и прочие извращения.

Расскажу про то, как это организовано и пару историй с выездов.

Как это обычно бывает

Наша команда сидит в офисе в Москве и снимает телеметрию сети. Собственно, это постоянные пинги узлов, а также получение данных мониторинга, если железки умные. Самая частая ситуация – пинг не проходит несколько раз подряд. В 80% случаев для розничной сети, например, это оказывается отключением электропитания, поэтому мы, видя такую картину, делаем следующее:

1. Сначала звоним провайдеру по поводу аварий
2. Потом – на электростанцию по поводу отключения
3. Затем пытаемся установить связь с кем-нибудь на объекте (это не всегда удаётся, например, в 2 ночи)
4. И, наконец, если за 5-10 минут вышеописанное не помогло, выезжаем сами или отправляем «аватара» — инженера-контрактника, сидящего где-нибудь в Ижевске или Владивостоке, если проблема там.
5. С «аватаром» держим постоянную связь и «ведём» его по инфраструктуре — у нас датчики и сервис-мануалы, у него— плоскогубцы.
6. Потом инженер присылает нам отчёт с фото по поводу того, что же это было.

Диалоги иногда такие:
— Так, связь пропадает между зданиями №4 и 5. Проверь роутер в пятом.
— Порядок, включён. Коннекта нет.
— Ок, иди по кабелю до четвёртого корпуса, там ещё узел.
—… Оппа!
— Что случилось?
— Тут 4-й дом снесли.
— Что??
— Прикладываю фото в отчёт. Дом в SLA восстановить не смогу.

Но чаще всё же получается найти обрыв и восстановить канал.

Примерно 60% выездов – «в молоко», потому что либо перебито питание (лопатой, прорабом, злоумышленниками), либо провайдер не знает про свой сбой, либо же кратковременная проблема устраняется до прибытия монтажника. Однако бывают ситуации, когда мы узнаём о проблеме раньше пользователей и раньше ИТ-служб заказчика, и сообщаем о решении до того, как они вообще поймут, что что-то случилось. Чаще всего такие ситуации случаются ночью, когда активность в компаниях заказчиков низкая.

Кому это надо и зачем

Как правило, у любой крупной компании есть свой IT-отдел, который чётко понимает специфику и задачи. В среднем и большом бизнесе работу «эникеев» и инженеров-сетевиков часто аутсорсят. Это просто выгодно и удобно. Например, один ритейлер имеет своих очень крутых айтишников, но занимаются они далеко не заменой роутеров и выслеживанием кабеля.

Что мы делаем

1. Работаем по обращениям — тикеты и панические звонки.
2. Делаем профилактику.
3. Следим за рекомендациями вендоров железа, например, по срокам ТО.
4. Подключаемся к мониторингу заказчика и снимаем с него данные, чтобы выезжать по инцидентам.

С мониторингом история часто заключается в том, что его нет. Или он был поднят 5 лет назад и не очень актуален. В самом простом случае, если мониторинга реально нет, предлагаем заказчику простой опенсорсный русский Zabbix бесплатно – и ему хорошо, и нам проще.

Первый способ — simple cheсks — это просто машина, которая пингует все узлы сети и следит за тем, чтобы они правильно отвечали. Такая реализация не требует вообще никаких изменений или минимальных косметических изменений в сети заказчика. Как правило, в очень простом случае мы ставим Заббикс прямо к себе в один из дата-центров (благо у нас их целых два в офисе КРОК на Волочаевской). В более сложном, например, если используется своя защищённая сеть – на одну из машин в ЦОДе заказчика:

Заббикс можно применять и сложнее, например, у него есть агенты, которые ставятся на *nix и win-узлы и показывают системный мониторинг, а также режим external check (с поддержкой протокола SNMP). Тем не менее, если бизнесу нужно что-то подобное, то либо у них уже есть свой мониторинг, либо выбирается более функционально-богатый вариант решения. Конечно, это уже не открытое ПО, и это стоит денег, но даже банальная точная инвентаризация уже примерно на треть отбивает затраты.

Это мы тоже делаем, но это история коллег. Вот они прислали пару скринов Инфосима:

Я же оператор «аватара», поэтому расскажу дальше о своей работе.

Как выглядит типовой инцидент

Перед нами экраны с вот таким общим статусом:

На этом объекте Zabbix собирает для нас довольно много информации: партийный номер, серийный номер, загрузка ЦПУ, описание устройства, доступность интерфейсов и т.п. Вся необходимая информация доступна из этого интерфейса.

Рядовой инцидент обычно начинается с того, что отваливается один из каналов, ведущих к, например, магазину заказчика (которых у него штук 200-300 по стране). Розница сейчас прошаренная, не то что лет семь назад, поэтому касса продолжит работу — каналов два.

Мы берёмся за телефоны и делаем минимум три звонка: провайдеру, электростанции и людям на месте («Да, мы тут арматуру грузили, чей-то кабель задели… А, ваш? Ну, хорошо, что нашли»).

Как правило, без мониторинга до эскалации прошли бы часы или дни — те же резервные каналы проверяют далеко не всегда. Мы знаем сразу и выезжаем сразу же. Если есть дополнительная информация кроме пингов (например, модель глючащей железки) – сразу комплектуем выездного инженера необходимыми частями. Дальше уже по месту.

Второй по частоте штатный вызов – выход из строя одного из терминалов у пользователей, например, DECT-телефона или Wi-Fi-роутера, раздававшего сеть на офис. Здесь мы узнаём о проблеме из мониторинга и почти сразу получаем звонок с деталями. Иногда звонок ничего нового не добавляет («Трубку беру, не звонит чего-то»), иногда очень полезен («Мы его со стола уронили»). Понятно, что во втором случае это явно не обрыв магистрали.

Оборудование в Москве берётся с наших складов горячего резерва, у нас их несколько типа таких:

У заказчиков обычно есть свои запасы часто выходящих из строя комплектующих – трубок для офиса, блоков питания, вентиляторов и так далее. Если же нужно доставить что-то, чего нет на месте, не в Москву, обычно мы едем сами (потому что монтаж). Например, у меня был ночной выезд в Нижний Тагил.

Если у заказчика есть свой мониторинг, они могут выгружать данные нам. Иногда мы разворачиваем Заббикс в режиме опроса, просто чтобы обеспечить прозрачность и контроль SLA (это тоже бесплатно для заказчика). Дополнительные датчики мы не ставим (это делают коллеги, которые обеспечивают непрерывность производственных процессов), но можем подключиться и к ним, если протоколы не экзотические.

В целом – инфраструктуру заказчика не трогаем, просто поддерживаем в том виде, как она есть.

По опыту скажу, что последние десять заказчиков перешли на внешнюю поддержку из-за того, что мы очень предсказуемые в плане затрат. Чёткое бюджетирование, хорошее управление кейсами, отчёт по каждой заявке, SLA, отчёты по оборудованию, профилактика. В идеале, конечно, мы для CIO заказчика типа уборщиц — приходим и делаем, всё чисто, не отвлекаем.

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

И ещё один важный момент: наш отдел не занимается критичной инфраструктурой. Всё внутри ЦОДов и всё банковско-страховое-операторское, плюс системы ядра розницы — это икс-команда. Вот эти ребята.

Ещё практика

Многие современные устройства умеют отдавать много сервисной информации. Например, у сетевых принтеров очень легко мониторится уровень тонера в картридже. Можно заранее рассчитывать на срок замены, плюс иметь уведомление на 5-10% (если офис вдруг начал бешено печатать не в стандартном графике) — и сразу отправлять эникея до того, как у бухгалтерии начнётся паника.

Очень часто у нас забирают годовую статистику, которую делает та же система мониторинга плюс мы. В случае с Заббиксом это простое планирование затрат и понимание, что куда делось, а в случае с Инфосимом – ещё и материал для расчёта масштабирования на год, загрузки админов и всякие другие штуки. В статистике есть энергопотребление – в последний год почти все стали его спрашивать, видимо, чтобы раскидывать внутренние затраты между отделами.

Иногда получаются настоящие героические спасения. Такие ситуации – большая редкость, но из того, что помню за этот год – увидели около 3 ночи повышение температуры до 55 градусов на цискокоммутаторе. В далёкой серверной стояли «глупые» кондиционеры без мониторинга, и они вышли из строя. Мы сразу вызвали инженера по охлаждению (не нашего) и позвонили дежурному админу заказчика. Он потушил часть некритичных сервисов и удержал серверную от thermal shotdown до приезда парня с мобильным кондиционером, а потом и починки штатных.

У Поликомов и другого дорогого оборудования видеоконференцсвязи очень хорошо мониторится степень зарядки батарейки перед конференциями, тоже важно.

Мониторинг и диагностика нужны всем. Как правило, самим без опыта внедрять долго и сложно: системы бывают либо предельно простые и преднастроенные, либо с авианосец размером и с кучей типовых отчётов. Заточка напильником под компанию, придумывание реализации своих задач внутреннего ИТ-подразделения и вывод информации, которая им нужна больше всего, плюс поддержка всей истории в актуальном состоянии – путь грабель, если нет опыта внедрений. Работая с системами мониторинга, мы выбираем золотую середину между бесплатными и топовыми решениями – как правило, не самых популярных и «толстых» вендоров, но чётко решающих задачу.

Один раз было достаточно нетипичное обращение. Заказчику нужно было отдать роутер какому-то своему обособленному подразделению, причём точно по описи. В роутере был модуль с указанным серийником. Когда роутер начали готовить в дорогу, выяснилось, что этого модуля что-то нет. И найти его никто не может. Проблему слегка усугубляет тот факт, что инженер, который в прошлом году работал с этим филиалом, уже на пенсии, и уехал ко внукам в другой город. Связались с нами, попросили поискать. К счастью, железо давало отчёты по серийникам, а Инфосим делал инвентаризацию, поэтому мы за пару минут нашли этот модуль в инфраструктуре, описали топологию. Беглеца выследили по кабелю – он был в другой серверной в шкафу. История перемещения показала, что попал он туда после выхода из строя аналогичного модуля.

Кадр из художественного фильма про Хоттабыча, точно описывающий отношение населения к камерам

Много инцидентов с камерами. Однажды вышло из строя сразу 3 камеры. Обрыв кабеля на одном из участков. Монтажник задул новый в гофру, две камеры из трёх после ряда шаманств поднялись. А третья – нет. Более того, непонятно, где она вообще. Поднимаю видеопоток – последние кадры прямо перед падением – 4 утра, подходит трое мужиков в шарфах на лицах, что-то яркое внизу, камера сильно трясётся, падает.

Один раз настраивали камеру, которая должна фокусироваться на «зайцах», лазящих через забор. Пока ехали, думали, как будем обозначать точку, где должен появляться нарушитель. Не пригодилось – за те 15 минут, что мы там были, на объект проникло человек 30 только в нужной нам точке. Прямо настроечная таблица.

Как я уже приводил пример выше, история про снесённое здание – не анекдот. Один раз пропал линк до оборудования. На месте – нет павильона, где проходила медь. Павильон снесли, кабель пропал. Мы увидели, что маршрутизатор сдох. Монтажник приехал, начинает смотреть – а расстояние там между узлами пара километров. У него в наборе випнетовский тестер, стандарт — прозвонил от одного коннектора, прозвонил от другого – пошёл искать. Обычно проблему сразу видно.

Выслеживание кабеля: это оптика в гофре, продолжение истории с самого верха поста про морской узел. Здесь в итоге кроме совершенно удивительного монтажа обнаружилась проблема в том, что кабель отошёл от креплений. Тут лазят все, кому не лень, и расшатывают металлоконструкции. Примерно пятитысячный представитель пролетариата порвал оптику.

На одном объекте примерно раз в неделю отключались все узлы. Причём в одно и то же время. Мы довольно долго искали закономерность. Монтажник обнаружил следующее:

• Проблема происходит всегда в смену одного и того же человека.
• Отличается он от других тем, что носит очень тяжёлое пальто.
• За вешалкой для одежды смонтирован автомат.
• Крышку автомата кто-то унёс уже очень давно, ещё в доисторические времена.
• Когда этот товарищ приходит на объект, он вешает одежду, и она отключает автоматы.
• Он тут же включает их обратно.

На одном объекте в одно и то же время ночью выключалось оборудование. Выяснилось, что местные умельцы подключились к нашему питанию, вывели удлинитель и втыкают туда чайник и электроплитку. Когда эти устройства работают одновременно – выбивает весь павильон.

В одном из магазинов нашей необъятной родины постоянно с закрытием смены падала вся сеть. Монтажник увидел, что всё питание выведено на линию освещения. Как только в магазине отключают верхнее освещение зала (потребляющее очень много энергии), отключается и всё сетевое оборудование.

Был случай, что дворник лопатой перебил кабель.

Часто видим просто медь, лежащую с сорванной гофрой. Один раз между двумя цехами местные умельцы просто пробросили витую пару без всякой защиты.

Подальше от цивилизации сотрудники часто жалуются что их облучает «наше» оборудование. Коммутаторы на каких-нибудь далёких объектах могут быть в той же комнате, что и дежурный. Соответственно, нам пару раз попадались вредные бабки, которые всеми правдами и неправдами отключали их в начале смены.

Ещё в одном далёком городе на оптику вешали швабру. Отколупали гофру от стены, стали использовать её как крепёж для оборудования.

В данном случае с питанием явно есть проблемы.

Что умеет «большой» мониторинг

Ещё коротко расскажу о возможностях более серьёзных систем, на примере инсталляций Infosim, Там 4 решения, объединённых в одну платформу:

• Управление отказами – контроль сбоев и корреляция событий.
• Управление производительностью.
• Инвентаризация и автоматическое обнаружение топологии.
• Управление конфигурациями.

Что важно, Инфосим поддерживает сразу кучу оборудования «из коробки», то есть легко разбирает весь их внутренний обмен и получает доступ до всех их технических данных. Вот список вендоров:Cisco Systems, Huawei, HP, AVAYA, Redback Networks, F5 Networks, Extreme Networks, Juniper, Alcatel-Lucent, Fujitsu Technology Solutions, ZyXEL, 3Com, Ericsson, ZTE, ADVA Optical Networking, Nortel Networks, Nokia Siemens Networks, Allied Telesis, RADCOM, Allot Communications, Enterasys Networks, Telco Systems и др.

Отдельно про инвентаризацию. Модуль не просто показывает список, но ещё и сам строит топологию (по крайней мере, в 95% случаев пытается и попадает правильно). Он же позволяет иметь под рукой актуальную базу используемого и простаивающего ИТ оборудования (сетевое, серверное оборудование и т.д.), проводить вовремя замены устаревшего оборудования (EOS/EOL). В общем, удобно для большого бизнеса, но в малом многое из этого делается руками.

Примеры отчетов:

• Отчеты в разрезе по типам ОС, прошивок, моделей и производителей оборудования;
• Отчет по количеству свободных портов на каждом коммутаторе в сети/по выбранному производителю/по модели/по подсети и т.д.;
• Отчет по вновь добавленным устройствам за заданным период;
• Извещение о низком уровне тонера в принтерах;
• Оценка пригодности канала связи для трафика чувствительного к задержкам и потерям, активный и пассивный методы;
• Слежение за качеством и доступностью каналов связи (SLA) – генерация отчетов по качеству каналов связи с разбивкой по операторам связи;
• Контроль сбоев и корреляция событиями функционал реализован за счет механизма Root-Cause Analysis (без необходимости написания правил администратором) и механизма Alarm States Machine. Root-Cause Analysis – это анализ первопричины аварии, основанный на следующих процедурах: 1. автоматическое обнаружение и локализация места сбоя; 2. сокращение количества аварийных событий до одного ключевого; 3. выявление последствий сбоя – на кого и на что повлиял сбой.

Ещё можно ставить на сеть вот такие штуки, которые сразу интегрируются в мониторинг:

Stablenet – Embedded Agent (SNEA) — компьютер размером чуть больше пачки сигарет.

Установка выполняется в банкоматы, или выделенные сегменты сети, где требуется проверка доступности. С их же помощью выполняются нагрузочные тестирования.

Облачный мониторинг

Ещё одна модель установки – SaaS в облаке. Делали для одного глобального заказчика (компания непрерывного цикла производства с географией распределения от Европы по Сибири).

Десятки объектов, в том числе – заводы и склады готовой продукции. Если у них падали каналы, а поддержка их осуществлялась из зарубежных офисов, то начинались задержки отгрузки, что по волне вело к убыткам дальше. Все работы делались по запросу и на расследование инцидента тратилось очень много времени.

Мы настроили мониторинг конкретно под них, потом допилили на ряде участков по особенностям именно их маршрутизации и железа. Это всё делалось в облаке КРОК. Сделали и сдали проект очень быстро.

Результат такой:

• За счет частичной передачи управления сетевой инфраструктурой удалось оптимизировать как минимум на 50%. Недоступность оборудования, загрузка канала, превышение рекомендованных производителем параметров: всё это фиксируется в течение 5-10 минут, диагностируется и устраняется в течение часа.
• При получении услуги из облака заказчик переводит капитальные расходы на развертывание своей системы сетевого мониторинга в операционные затраты на абонентскую плату за наш сервис, от которого в любой момент можно отказаться.

Преимущество облака в том, что в своем решении мы стоим как бы над их сетью и можем смотреть на все происходящее более объективно. В то время, если бы мы находились внури сети, мы видели бы картину только до узла отказа, и что за ним происходит, нам уже не было бы известно.

Пара картинок напоследок

Это — «утренний паззл»:

А это мы нашли клад:

В сундуке было вот что:

Ну и напоследок про самый весёлый выезд. Я как-то раз выезжал на объект розницы.

Там случилось следующее: сначала начало капать с крыши на фальшпотолок. Потом в фальшпотолке образовалось озеро, которое размыло и продавило одну из плиток. В результате всё это хлынуло на электрику. Дальше точно не знаю, что именно случилось, но где-то в соседнем помещении коротнуло, и начался пожар. Сначала сработали порошковые огнетушители, а потом приехали пожарные и залили всё пеной. Я приехал уже после них к разборку. Надо сказать, что циска 2960 врубилась после всего этого – я смог забрать конфиг и отправить устройство в ремонт.

Ещё один раз при сработке порошковой системы цисковский 3745 в одном банке был заполнен порошком почти полностью. Все интерфейсы были забиты – 2 по 48 портов. Надо было включать на месте. Вспомнили прошлый случай, решили попробовать снять конфиги «на горячую», вытрясли, почистили, как умели. Врубили – сначала устройство сказало «пфф» и чихнуло в нас большой струёй порошка. А потом заурчало и поднялось.

Источник