username Опубликовано 9 ноября, 2010 · Жалоба Когда количество умных коммутаторов в сети исчисляется сотнями, или даже тысячами, очень сложно становится тыкаться по веб-интерфейсам железяк, особенно в поисках проблемы "чтота гдета поломалось". Понятно, что спасает SNMP, но ведь должен быть и софт, который будет интуитивно-удобно-понятно через этот SNMP управлять целой кучей коммутаторов/маршрутизаторов. Вопрос: каким софтом для централизованного управления сетью пользуетесь? и пользуетесь ли вообще? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 9 ноября, 2010 · Жалоба Когда количество умных коммутаторов в сети исчисляется сотнями, или даже тысячами, очень сложно становится тыкаться по веб-интерфейсам железяк, особенно в поисках проблемы "чтота гдета поломалось".Понятно, что спасает SNMP, но ведь должен быть и софт, который будет интуитивно-удобно-понятно через этот SNMP управлять целой кучей коммутаторов/маршрутизаторов. Вопрос: каким софтом для централизованного управления сетью пользуетесь? и пользуетесь ли вообще? Мы, убогие, до сих пор телнет юзаем для массового конфига и прошивки =) Логи - на сислог сервер, там парсятся. Мониторинг - скрипты + самописный веб с как снмп, так и телнет плюшками Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 9 ноября, 2010 · Жалоба У большинства вендоров есть свои системы управления по SNMP, но как правило они сильно ограничены по функционалу и поддерживают только свои железки или ещё несколько вендоров. Я как раз занимаюсь разработкой такой системы, но она никогда не будет в паблике. Основная проблема с которой сталкиваюсь - не всё можно сделать по snmp(например, править/навешивать ACL на cisco)+бывает, что в мибах не очень подробное описание каких-то оидов. Если нужно чисто для диагностики(на уровне порт up/down), то такую систему можно написать меньше чем за неделю на стандратных мибах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 9 ноября, 2010 · Жалоба Когда количество умных коммутаторов в сети исчисляется сотнями, или даже тысячами, очень сложно становится тыкаться по веб-интерфейсам железяк, особенно в поисках проблемы "чтота гдета поломалось".Понятно, что спасает SNMP, но ведь должен быть и софт, который будет интуитивно-удобно-понятно через этот SNMP управлять целой кучей коммутаторов/маршрутизаторов. Вопрос: каким софтом для централизованного управления сетью пользуетесь? и пользуетесь ли вообще? NOC умеет управлять коммутаторами по SNMP, через CLI и WEB, а также принимать и обрабатывать SYSLOG/SNMP Traps. В качестве бонуса - будет собирать со свичей конфиги и отслеживать изменения. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 9 ноября, 2010 · Жалоба У большинства вендоров есть свои системы управления по SNMP, но как правило они сильно ограничены по функционалу и поддерживают только свои железки или ещё несколько вендоров. Я как раз занимаюсь разработкой такой системы, но она никогда не будет в паблике. Основная проблема с которой сталкиваюсь - не всё можно сделать по snmp(например, править/навешивать ACL на cisco)+бывает, что в мибах не очень подробное описание каких-то оидов. Если нужно чисто для диагностики(на уровне порт up/down), то такую систему можно написать меньше чем за неделю на стандратных мибах. А в том же длинке далеко не всё, что есть в cli, есть в snmp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 9 ноября, 2010 · Жалоба У большинства вендоров есть свои системы управления по SNMP, но как правило они сильно ограничены по функционалу и поддерживают только свои железки или ещё несколько вендоров. Я как раз занимаюсь разработкой такой системы, но она никогда не будет в паблике. Основная проблема с которой сталкиваюсь - не всё можно сделать по snmp(например, править/навешивать ACL на cisco)+бывает, что в мибах не очень подробное описание каких-то оидов. Что еще хуже - в MIB'ах часто бывают ошибки и, бывает, что не вся информация доступна через MIB'ы. И наоборот - не вся информация доступна через CLI, часть только по SNMP (HP этим грешит). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 9 ноября, 2010 · Жалоба dvolodin А через web-то зачем?(или речь идёт о коммутаторах без cli?) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 9 ноября, 2010 · Жалоба dvolodin А через web-то зачем?(или речь идёт о коммутаторах без cli?) Есть железки с кастрированным SNMP, без CLI, но с WEB'ом. Медиашлюзы разные и CPE'шки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 9 ноября, 2010 · Жалоба Что еще хуже - в MIB'ах часто бывают ошибки и, бывает, что не вся информация доступна через MIB'ы.Честно говоря, не сталкивался, только пару раз видел, когда название oid'а не совпадает с тем, что он делает(но по описанию вроде понятно) И наоборот - не вся информация доступна через CLI, часть только по SNMP (HP этим грешит). это значительно реже бывает Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 9 ноября, 2010 · Жалоба Биллинг наше всё :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 9 ноября, 2010 · Жалоба dvolodin А через web-то зачем?(или речь идёт о коммутаторах без cli?) Есть железки с кастрированным SNMP, без CLI, но с WEB'ом. Медиашлюзы разные и CPE'шки. Согласен, это действительно нужно, но только если эти железки в зоне отвественности оператора, но как правило cpe-шками рулят сами абоненты Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 9 ноября, 2010 · Жалоба Что еще хуже - в MIB'ах часто бывают ошибки и, бывает, что не вся информация доступна через MIB'ы.Честно говоря, не сталкивался, только пару раз видел, когда название oid'а не совпадает с тем, что он делает(но по описанию вроде понятно) В телефонных железках достаточно часто бывает. Вплоть до того, что MIB'ы просто не компилируются. И наоборот - не вся информация доступна через CLI, часть только по SNMP (HP этим грешит). это значительно реже бывает Если на сети есть прокурвы, то бывает каждый день :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 9 ноября, 2010 · Жалоба dvolodin А через web-то зачем?(или речь идёт о коммутаторах без cli?) Есть железки с кастрированным SNMP, без CLI, но с WEB'ом. Медиашлюзы разные и CPE'шки. Согласен, это действительно нужно, но только если эти железки в зоне отвественности оператора, но как правило cpe-шками рулят сами абоненты Те же самые 24-портовые FXS в подвалах. На самом деле, неблагодарное это дело, рассуждать, что нужно, а что нет. Хорошая система service activation должна работать с разным железом и по разным интерфейсам, причем, одновременно. Как показывает практика, завязываться строго на SNMP или на CLI не стоит, потом достаточно тяжело расширять функционал будет. В конце концов вдруг завтра понадобится рулить софтсвичом по TL1 и при этом настраивать порты на свичах, улить STB'шкой по CLI и настраивать порты на медиашлюзах по HTTP. Конвергенция - вещь гадская. В этом отношении NOC - крайне полезная вещь, так как позволяет прятать особенности поведения разных моделей железок на низком уровне и представляет для сервисов интерфейсы более высокого уровня. Сказали добавить vlan на этом свиче - надо добавить vlan на этом свиче. А что там - HP, Cisco, Force10, Huawei или DLink, никого волновать не должно. Равно как и не дело биллинга теребить железо. Плюнул по SOAP запрос в сторону service activation, что такому-то абоненту с такими-то параметрами надо настроить сервис, получил ответ, что сервис активирован, и успокоился. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 9 ноября, 2010 · Жалоба >В телефонных железках достаточно часто бывает. Вплоть до того, что MIB'ы просто не компилируются. Ага, бывает, что один миб-браузер не съедает, а второй на раз-два. В этом плане ireasoning меньше всего подводит. >Равно как и не дело биллинга теребить железо. Плюнул по SOAP запрос в сторону service activation, что такому-то абоненту с такими-то параметрами надо настроить сервис, получил ответ, что сервис активирован, и успокоился. Ну в самом деле это не совсем так, нужна ещё очередь заданий, если для активации требуется настройка оборудования доступа и если биллинг разделён с активатором, то надо делать, чтобы из биллинга можно было узнать статус(активировано на оборудовании или ещё нет). >В этом отношении NOC - крайне полезная вещь, так как позволяет прятать особенности поведения разных моделей железок на низком уровне и представляет для сервисов интерфейсы более высокого уровня. Кстати, забыл написать про библиотеку SNMP::Info (perl), только в ней слабая поддержка китайского говножелеза (http://netdisco.org/DeviceMatrix.html ), которую в принципе можно заюзать как интерфейс управлением железом. Если perl не пугает... dvolodin Ради интереса спрошу, у вас есть коммерческая поддержка?(если вдруг кому-то лень будет что-то править или допиливать под свою сеть) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 9 ноября, 2010 · Жалоба >Равно как и не дело биллинга теребить железо. Плюнул по SOAP запрос в сторону service activation, что такому-то абоненту с такими-то параметрами надо настроить сервис, получил ответ, что сервис активирован, и успокоился. Ну в самом деле это не совсем так, нужна ещё очередь заданий, если для активации требуется настройка оборудования доступа и если биллинг разделён с активатором, то надо делать, чтобы из биллинга можно было узнать статус(активировано на оборудовании или ещё нет). В NOC так и делается через Map/Reduce Tasks. Запускается задача и периодически опрашивается ее статус. В принципе, можно и callback сделать, когда по завершениюзадачи NOC сам пнет биллинг и доложит о выполнении или об ошибке >В этом отношении NOC - крайне полезная вещь, так как позволяет прятать особенности поведения разных моделей железок на низком уровне и представляет для сервисов интерфейсы более высокого уровня. Кстати, забыл написать про библиотеку SNMP::Info (perl), только в ней слабая поддержка китайского говножелеза (http://netdisco.org/DeviceMatrix.html ), которую в принципе можно заюзать как интерфейс управлением железом. Если perl не пугает... Если есть желание сделать все самому, то относительно неплохой выбор. dvolodin Ради интереса спрошу, у вас есть коммерческая поддержка?(если вдруг кому-то лень будет что-то править или допиливать под свою сеть) Есть. Все обсуждаемо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 9 ноября, 2010 (изменено) · Жалоба Ну у нас вот как-то так. Это фронтенд в билинге. Тоже считаю что не дело билинга с железками общаться. У нас выполнено все в виде XML-RPC сервера через Frontier::Daemon:Fork, работает как с SNMP, так и с telnet. Пингалка многопоточная отдельно написана, но все в рамках того же проекта. Как работать с железкой решает сам сервер. Софт закрытый, хотя есть идея выложить как открытый как раз сам сервер. Там структура классов на perl для snmp и telnet, т.е. можно дописывать под другие коммутаторы. Сейчас рабтает с D-Link (почти все модели включая L3), Planet WSW, SGSW, Cisco L2/L3, Telesyn L3. Кару сети можно строить как в автоматическом режиме на основе FDB, так и в ручном (через привязки). Изменено 9 ноября, 2010 пользователем SokolovS Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 9 ноября, 2010 · Жалоба Кару сети можно строить как в автоматическом режиме на основе FDB, так и в ручном (через привязки). Topology discovery в NOC уже вполне достойный. Работает комплексно по MAC'ам, ARP-кешу, *STP, LLDP и CDP и корректно обрабатывает port-channel'ы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 9 ноября, 2010 · Жалоба 2dvolodin: я периодически смотрю что вы делаете, интересный проект. Полностью свои проекты я открыть не могу к сожалению :( Вот идея с источниками топологической информации мне понравилась, применю ) У нас сейчас только FDB снимается, но карта как видите строится нормально, она кстати интерактивная, т.е. увязана с мониторингом и есть возможность переходить дальше вглубь. Если нод зеленый, то дальше что-то есть, если синий то это последний узел в цепи. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 9 ноября, 2010 · Жалоба Равно как и не дело биллинга теребить железо.Не соглашусь. В биллинге ведётся учёт абонентов (у всех так), там-же записаны разные политики для разных абонентов (например тарифы), там-же должны быть учтены особенности той или иной абонентской группы (например слабые линки), и от туда-же должен вестись онлайн мониторинг. Всё в одном ОЧЕНЬ сильно сокращает время для поиска, диагностики и устранения неисправностей на линках (или у клиентов). О том-же падении линков в первую очередь должны быть оповещены диспетчера, которые и работают с биллингом и абонентами, и у них первоначально должна быть самая оперативная информация. Если это дело начинать дробить на куски (там вот Дуда, там нок, там кактус, тут веб-морда свича, здесь консоль, вон там телнет, а вот тут SSH и т.д. и т.п.) это КРАЙНЕ негативно скажется во первых на времени и качестве поиска неисправностей, во вторых на зарплатном бюджете. Если я не прав - извиняюсь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 9 ноября, 2010 · Жалоба 2dvolodin: я периодически смотрю что вы делаете, интересный проект. Полностью свои проекты я открыть не могу к сожалению :(Вот идея с источниками топологической информации мне понравилась, применю ) У нас сейчас только FDB снимается, но карта как видите строится нормально, она кстати интерактивная, т.е. увязана с мониторингом и есть возможность переходить дальше вглубь. Если нод зеленый, то дальше что-то есть, если синий то это последний узел в цепи. Мы столкнулись с тем, что FDB хватает далеко не всегда, это скорее fallback вариант. Наши алгоритмы определяют не только связь между железками, но и физические порты или port-channel'ы, в зависимости от алгоритма. То есть информации о том, что железка A подцеплена к железке B для нас недостаточно, нужны конкретные порты, которых на наших железках бывает по несколько сотен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 9 ноября, 2010 · Жалоба Вопрос: каким софтом для централизованного управления сетью пользуетесь? и пользуетесь ли вообще? http://forum.nag.ru/forum/index.php?showtopic=54023 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dvolodin Опубликовано 9 ноября, 2010 · Жалоба Равно как и не дело биллинга теребить железо.Не соглашусь. В биллинге ведётся учёт абонентов (у всех так), там-же записаны разные политики для разных абонентов (например тарифы), там-же должны быть учтены особенности той или иной абонентской группы (например слабые линки), и от туда-же должен вестись онлайн мониторинг. Всё в одном ОЧЕНЬ сильно сокращает время для поиска, диагностики и устранения неисправностей на линках (или у клиентов). О том-же падении линков в первую очередь должны быть оповещены диспетчера, которые и работают с биллингом и абонентами, и у них первоначально должна быть самая оперативная информация. А вот и не соглашусь: мешать в кучу биллинг, CRM, мониторинг, NMS, FMS, provisioning, inventory, middleware и policy server - крайне порочная практика, как в техническом, так и в политическом смысле.Да, для оператора call-центра нужен dashboard, на котором он увидит всю необходимую информацию по клиенту сразу. Но это, скорее, CRM а не биллинг, и его задача просто сходить и дернуть нужные данные из других систем, иначе грош ему цена. Невозможно сделать продукт, который будет одинаково хорош во всем, а если вам такой продукт продали, значит на шею сели насмерть и уже не слезут. Во-вторых, либо этот продукт будет создан под ваш бизнес, либо ваш бизнес будет натянут на этот продукт. В третьих - продукт будет весьма сложным и малотиражным, тут уже просто бабло насосом сосать будут за поддержку и каждый чих. Если это дело начинать дробить на куски (там вот Дуда, там нок, там кактус, тут веб-морда свича, здесь консоль, вон там телнет, а вот тут SSH и т.д. и т.п.) это КРАЙНЕ негативно скажется во первых на времени и качестве поиска неисправностей, во вторых на зарплатном бюджете. Если я не прав - извиняюсь. Достаточно просто научить биллинг/CRM выдирать данные из нужных систем по требованию и все. В NOC'е мы придерживались именно такого подхода - что сделано, должно работать хорошо, но в нем не будет биллинга, middleware и прочих вещей, не имеющих отношения к управлению сетями. Но он будет с ними интегрироваться :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 9 ноября, 2010 · Жалоба >В NOC'е мы придерживались именно такого подхода - что сделано, должно работать хорошо, но в нем не будет биллинга, middleware и прочих вещей, не имеющих отношения к управлению сетями. Но он будет с ними интегрироваться :) Понимаете, провайдеру нужно чтобы всё было под рукой и быстро, чтобы всё было в одном интерфейсе, а не так, чтобы сначала по номеру договора смотреть есть ли деньги в биллинге, потом лезть в тех.учёт и смотреть куда он подключен, потом ползти в некий интерефейс управления железом, смотреть что там с портом, приходит ли мак и т.д. nocproject это целый самостоятельный project, который, очевидно, заточен под управление оборудованием датацентра или магистральных операторов и для учёта технологических объектов(rd,ip-адреса, домены и т.д.), хотя опять же очевидно, что все эти вещи должны быть привязаны к деньгам абонентам, а не храниться в отдельной базе. И пожалуй самое главное, база данных должна быть единой, крайне важно избегать любое дублирование данных, иначе получается бардак. Допустим мы хотим дать возможность получения статического белого IPv4-адреса. Следуя Вашей идеалогии, пометка о том, кому принадлежит этот адрес должна быть в базе nocproject, но в самом деле ассоциация IP и логина на pppoe/pptp или id порта(option82) должна быть в базе биллинга, чтобы при авторизации bras получил радиус-атрибут, содержащий статический IP адрес абонента. Поэтому первая строчка из overview к nocproject нужна далеко не всем. Аналогично про последнюю, reporting должен быть в контексте денег, а не оборудования. Большинству операторов он конечно интересен, но не как отдельная система, а как некий libnocproject, чтобы дёргать его напрямую из биллинга/техучёта, а не использовать его как чёрный ящик в стиле бросил SOAP-запрос и получил ответ. >Во-вторых, либо этот продукт будет создан под ваш бизнес, либо ваш бизнес будет натянут на этот продукт. В третьих - продукт будет весьма сложным и малотиражным, тут уже просто бабло насосом сосать будут за поддержку и каждый чих. У провайдеров последней мили все бизнес-процессы должны быть решены в виде модулей биллинга, покупается биллинг с нормальным API, к нему прикручиваются модули, тогда никакого высасывания бабла не будет Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Wingman Опубликовано 9 ноября, 2010 · Жалоба >В NOC'е мы придерживались именно такого подхода - что сделано, должно работать хорошо, но в нем не будет биллинга, middleware и прочих вещей, не имеющих отношения к управлению сетями. Но он будет с ними интегрироваться :) Понимаете, провайдеру нужно чтобы всё было под рукой и быстро, чтобы всё было в одном интерфейсе, а не так, чтобы сначала по номеру договора смотреть есть ли деньги в биллинге, потом лезть в тех.учёт и смотреть куда он подключен, потом ползти в некий интерефейс управления железом, смотреть что там с портом, приходит ли мак и т.д. nocproject это целый самостоятельный project, который, очевидно, заточен под управление оборудованием датацентра или магистральных операторов и для учёта технологических объектов(rd,ip-адреса, домены и т.д.), хотя опять же очевидно, что все эти вещи должны быть привязаны к деньгам абонентам, а не храниться в отдельной базе. И пожалуй самое главное, база данных должна быть единой, крайне важно избегать любое дублирование данных, иначе получается бардак. Допустим мы хотим дать возможность получения статического белого IPv4-адреса. Следуя Вашей идеалогии, пометка о том, кому принадлежит этот адрес должна быть в базе nocproject, но в самом деле ассоциация IP и логина на pppoe/pptp или id порта(option82) должна быть в базе биллинга, чтобы при авторизации bras получил радиус-атрибут, содержащий статический IP адрес абонента. Поэтому первая строчка из overview к nocproject нужна далеко не всем. Аналогично про последнюю, reporting должен быть в контексте денег, а не оборудования. Большинству операторов он конечно интересен, но не как отдельная система, а как некий libnocproject, чтобы дёргать его напрямую из биллинга/техучёта, а не использовать его как чёрный ящик в стиле бросил SOAP-запрос и получил ответ. >Во-вторых, либо этот продукт будет создан под ваш бизнес, либо ваш бизнес будет натянут на этот продукт. В третьих - продукт будет весьма сложным и малотиражным, тут уже просто бабло насосом сосать будут за поддержку и каждый чих. У провайдеров последней мили все бизнес-процессы должны быть решены в виде модулей биллинга, покупается биллинг с нормальным API, к нему прикручиваются модули, тогда никакого высасывания бабла не будет >> Понимаете, провайдеру нужно чтобы всё было под рукой и быстро, чтобы всё было в одном интерфейсе, а не так, чтобы сначала по номеру договора смотреть есть ли деньги в >> биллинге, потом лезть в тех.учёт и смотреть куда он подключен, потом ползти в некий интерефейс управления железом, смотреть что там с портом, приходит ли мак и т.д. +100500, подписываюсь под каждой буквой. Именно поэтому в конечном итоге с ростом сети все провайдеры приходят к самописному либо заказному софту. Как бы криво оно ни было написано - оно будет отвечать конкретным потребностям. Унификации нет, к сожалению. Из чужого - применяют в основном идеи/куски кода/отдельные скрипты Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
No_name Опубликовано 9 ноября, 2010 · Жалоба Что еще хуже - в MIB'ах часто бывают ошибки и, бывает, что не вся информация доступна через MIB'ы.Честно говоря, не сталкивался, только пару раз видел, когда название oid'а не совпадает с тем, что он делает(но по описанию вроде понятно) В телефонных железках достаточно часто бывает. Вплоть до того, что MIB'ы просто не компилируются. И наоборот - не вся информация доступна через CLI, часть только по SNMP (HP этим грешит). это значительно реже бывает Если на сети есть прокурвы, то бывает каждый день :) Это вы о чем? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...