Перейти к содержимому
Калькуляторы

Массовый падёж MES1124

Коллеги, никто последнее время не сталкивался с массовыми вылетами сабжа?

У нас почти 100 единиц такого оборудования. Партии разные, покупали на протяжении последних 6 лет.

Никогда с ними особых проблем не было, а сегодня почти все из них пошли в отказ, но с разными симптомами.

 

Несколько штук формально работали, но перестали пускать по SSH. Причём без ошибок. Пустая сессия зависала навечно.

Несколько штук потеряли аплинк, хардварную консоль, перестали передавать трафик пользователей, но не перезагрузились.

Несколько десятков ребутнулись, оставив перед этим в логах "SYSLOG-F-OSFATAL FATAL ERROR: STSB: ABORT DATA exception ***** FATAL ERROR ***** SW Version : 1.1.48.14 Version Date: 24-Dec-2021 Version Time: 13:59:09 Instruction 0x37CAEC Exception vector 0x10 Program state register 0x"

 

Все отказы произошли за день, но не одновременно. И не по очереди (по сетевой адресации, по возрасту, по именам). Рандомно.

Софт последжний, рекомендованный для них.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Звучит как таймбомб, если они время берут с NTP сервера то переведите там часы на пару лет назад.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

12 часов назад, M-a-x-Z сказал:

У нас почти 100 единиц такого оборудования. Партии разные, покупали на протяжении последних 6 лет.

Никогда с ними особых проблем не было, а сегодня почти все из них пошли в отказ, но с разными симптомами.

Почти все из почти 100?

Элтекс что-то ответил?

Смахивает на 0-day уязвимость и наличие на сети "недоброжелателя".

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Почти все за исключением пары штук.
Заявку в Eltex сделали, но пока молчат.
По IP-протоколу управление у них закрыто ото всех, кроме администратора цисковским deny ip any any

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Точно нет.

Поддержка ответила, что страдает демон SSH. У нас конечно есть кастомный скрипт сбора конфигов. Но падения не совпадают по времени со сбором таких конфигов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А в системе мониторинга нет "полок" по CPU, траффику на портах и т.п.?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нет, всё чисто L2. CPU отдыхает.

Кажется нашли причину. Был виноват демон SSH, в нём текла память. Триггер у утечки был весьма своеобразный. Но я пока не буду расписывать причину, так как мы в процессе диагностики. Потом отпишусь

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ой. И даже статус "ЕРРРП (ТОРП)" не помог. Как же так. Как же так.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 30.05.2023 в 15:11, M-a-x-Z сказал:

Поддержка ответила, что страдает демон SSH.

И что в итоге поддержка предложила в качестве решения сабжа?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В общем дело было так. Уже много лет у нас был скрипт, который тащил конфиги со всех элтексов (примерно 250 штук серий 11, 21, 23, 33). Делал он это по SSH вручную вводя команды и листая страницы (да, я знаю, что можно вывести конфиг без разбиения на страницы, но скрипт старый, ему шесть лет и раньше так не получалось). И вот, недавно, у нас появились стеки с большим конфигом. Для сбора конфигураций с них пришлось уменьшить интервал, который использовался при отправке команд в SSH. Скрипт протестили, все линейки он успешно опрашивал и его отправили в прод.

 

Позже выяснилось: слишком быстрый ввод команд и перелистывание страниц в SSH привели к утечкам памяти, даже возвращая правильный результат. Проявлялись утечки не сразу, а через 2-12 часов с различными симптомами. Причём, как потом выяснилось, 4 коммутатора зараза вообще не брала (прошивки у всех одинаковые, последние). Коммутаторы продолжали падать даже после того, как автоматизированный сбор конфигов и всё другое обслуживание остановили: к этому моменту память уже была протекшей и преподносила отложенные сюрпризы. Из-за такого хитрого поведения не сразу установили причинно-следственную связь с ускорением сбора конфигов.

 

Поддержка нам только точно диагностировала, что проблема в демое SSH. Ну а мы более тонко подкрутили таймеры. Так и решили проблему.
Но серия в целом проблемная в демоне SSH. Лет 5 назад была проблема, что если к устройству подключалось более одного юзера, то он глючил. Тогда оперативно пофиксили и прислали апдейт. Сейчас не знаю, пофиксят ли. Серия старая.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

10 часов назад, M-a-x-Z сказал:

В общем дело было так. Уже много лет у нас был скрипт, который тащил конфиги со всех элтексов (примерно 250 штук серий 11, 21, 23, 33). Делал он это по SSH вручную вводя команды и листая страницы (да, я знаю, что можно вывести конфиг без разбиения на страницы, но скрипт старый, ему шесть лет и раньше так не получалось).

Какая нескучная реализация. А вариант захода по ssh сливать конфиги по tftp не рассматривали? Правда там не нужно будет крутить тайминги и городить постраничный листинг.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 2124 серии есть команды для hardware watchdog и software watchdog. А также есть загрузчик, который этот watchdog включает с самого старта.

Думаю, в 1124 тоже должно быть что-то подобное.

Хотя бы тогда перезагружаться будут.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нормальная универсальная реализация.

Во-первых, по tftp не контролируется целостность. Даже сливая таким образом конфиги с Cisco сталкивались с потерей пакетов (причём не со стороны сети, так как в ней пакеты не терялись остальные), например в середине конфигурации. При опросе нескольких тысяч устройств постоянно такие вещи происходили не сверх. часто, но периодически. В итоге для Cisco по tftp конифг пришлось брать несколько раз и сравнивать и если не сходится - брать третий раз.

Во-вторых, на момент разработки автомтаизации Eltex был более сырым и tftp там не было реализовано полноценно. Да, были времена, что он стоил как D-link и не входил в ТОРП.

В-третьих, я не уверен, что алгоритмически проще код с отслеживанием tftp и ssh одновременно, нежели один ssh. Как я говорил, проще листинг конфига отключить.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Согласен, CRC32 или md5 сумму могли бы и положить в конфиг при экспорте по tftp. Встречался с недокачным конфигом в eltex.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Элтекс с года так 2010 знаком. tftp там уже в наличии имелся. Если не нравится tftp, есть scp.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.