Не машина, а железяка. Большая и типа умная, но на практике такая же тупая как то, на базе чего она построена, например, если в консоли указать download_firmware tftp://zzz/xxx.bin,
то она выдаст ошибку, правильно указывать - download_firmware tftp:///zzz/xxx.bin, и tftp:///zzz//xxx.bin тоже вернет ошибку.На ней нет ни fdb таблиц, ни tcpdump, хотя разрабы показали некий хак, чтобы запустить tcpdump на порту управления, но этоже смешно.
По snmp она умеет отдавать чуть больше, чем ничего. То есть на сервере управления мне нужно разворачить персонально под нее какой-то крайне не распространенный протокол, который скорее всего еще и реализовать нужно будет самому.
В ответ на это разрабы посоветовали использовать макросы, вывод которых можно перенаправить на тот же tftp сервер, однако практика показала, что результат заливается на сервак не весь - из 144кб реального текста доходит 9к.
Вероятнее, виноваты ленивые индусы, но осадок от использования "УмногоЯйца", которое не имеет элементарных общепринятых опций, доступных в железках на 2 и 3 порядка ниже в сетевой иерархии остается. Лично мне проще поставить стеренький комп, который хоть по rs232 будет мониторить состояния объектов, чем бодаться с ТП - дожидаться пока случится, снимать дампы и что-то объяснять, тем более первыми их словами будут - А вы пробовали выключить и снова включить, а это уже авария, это премия, это нельзя))
Что касается выбора, - в корпоративном секторе никто никого ниачем не спрашивает, о всех закупках договариваются коммерсанты, которые "нишарят", а технари потом сидят по ночам общаясь с ТП, что в принципе оплачивается, но по факту того не стоит. И чтобы завершить картину, стоит упомянуть о том, что биллинговая система стоит на CentOS 5.9, а сервер мониторинга на RHEL, при этом биллинг 1-2 раза в сутки тупо отваливается, а сервер мониторинга в стойке просто валяется, потому что та ява-хрень на которой он написан тупо неработоспособна, и попытки его реанимировать продолжаются уже около 5 лет.
