Jump to content
Калькуляторы

Как и чем управляете по SNMP кучей коммутаторов?

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

Понятно, что спасает SNMP, но ведь должен быть и софт, который будет интуитивно-удобно-понятно через этот SNMP управлять целой кучей коммутаторов/маршрутизаторов.

 

Вопрос: каким софтом для централизованного управления сетью пользуетесь? и пользуетесь ли вообще?

Share this post


Link to post
Share on other sites
Когда количество умных коммутаторов в сети исчисляется сотнями, или даже тысячами, очень сложно становится тыкаться по веб-интерфейсам железяк, особенно в поисках проблемы "чтота гдета поломалось".

Понятно, что спасает SNMP, но ведь должен быть и софт, который будет интуитивно-удобно-понятно через этот SNMP управлять целой кучей коммутаторов/маршрутизаторов.

 

Вопрос: каким софтом для централизованного управления сетью пользуетесь? и пользуетесь ли вообще?

 

Мы, убогие, до сих пор телнет юзаем для массового конфига и прошивки =)

Логи - на сислог сервер, там парсятся. Мониторинг - скрипты + самописный веб с как снмп, так и телнет плюшками

 

Share this post


Link to post
Share on other sites

У большинства вендоров есть свои системы управления по SNMP, но как правило они сильно ограничены по функционалу и поддерживают только свои железки или ещё несколько вендоров. Я как раз занимаюсь разработкой такой системы, но она никогда не будет в паблике. Основная проблема с которой сталкиваюсь - не всё можно сделать по snmp(например, править/навешивать ACL на cisco)+бывает, что в мибах не очень подробное описание каких-то оидов.

 

Если нужно чисто для диагностики(на уровне порт up/down), то такую систему можно написать меньше чем за неделю на стандратных мибах.

Share this post


Link to post
Share on other sites
Когда количество умных коммутаторов в сети исчисляется сотнями, или даже тысячами, очень сложно становится тыкаться по веб-интерфейсам железяк, особенно в поисках проблемы "чтота гдета поломалось".

Понятно, что спасает SNMP, но ведь должен быть и софт, который будет интуитивно-удобно-понятно через этот SNMP управлять целой кучей коммутаторов/маршрутизаторов.

 

Вопрос: каким софтом для централизованного управления сетью пользуетесь? и пользуетесь ли вообще?

NOC умеет управлять коммутаторами по SNMP, через CLI и WEB, а также принимать и обрабатывать SYSLOG/SNMP Traps. В качестве бонуса - будет собирать со свичей конфиги и отслеживать изменения.

 

Share this post


Link to post
Share on other sites
У большинства вендоров есть свои системы управления по SNMP, но как правило они сильно ограничены по функционалу и поддерживают только свои железки или ещё несколько вендоров. Я как раз занимаюсь разработкой такой системы, но она никогда не будет в паблике. Основная проблема с которой сталкиваюсь - не всё можно сделать по snmp(например, править/навешивать ACL на cisco)+бывает, что в мибах не очень подробное описание каких-то оидов.

 

Если нужно чисто для диагностики(на уровне порт up/down), то такую систему можно написать меньше чем за неделю на стандратных мибах.

А в том же длинке далеко не всё, что есть в cli, есть в snmp

Share this post


Link to post
Share on other sites

У большинства вендоров есть свои системы управления по SNMP, но как правило они сильно ограничены по функционалу и поддерживают только свои железки или ещё несколько вендоров. Я как раз занимаюсь разработкой такой системы, но она никогда не будет в паблике. Основная проблема с которой сталкиваюсь - не всё можно сделать по snmp(например, править/навешивать ACL на cisco)+бывает, что в мибах не очень подробное описание каких-то оидов.

Что еще хуже - в MIB'ах часто бывают ошибки и, бывает, что не вся информация доступна через MIB'ы. И наоборот - не вся информация доступна через CLI, часть только по SNMP (HP этим грешит).

Share this post


Link to post
Share on other sites
dvolodin

А через web-то зачем?(или речь идёт о коммутаторах без cli?)

Есть железки с кастрированным SNMP, без CLI, но с WEB'ом. Медиашлюзы разные и CPE'шки.

Share this post


Link to post
Share on other sites
Что еще хуже - в MIB'ах часто бывают ошибки и, бывает, что не вся информация доступна через MIB'ы.
Честно говоря, не сталкивался, только пару раз видел, когда название oid'а не совпадает с тем, что он делает(но по описанию вроде понятно)

 

И наоборот - не вся информация доступна через CLI, часть только по SNMP (HP этим грешит).

это значительно реже бывает

 

 

Share this post


Link to post
Share on other sites
dvolodin

А через web-то зачем?(или речь идёт о коммутаторах без cli?)

Есть железки с кастрированным SNMP, без CLI, но с WEB'ом. Медиашлюзы разные и CPE'шки.

Согласен, это действительно нужно, но только если эти железки в зоне отвественности оператора, но как правило cpe-шками рулят сами абоненты

Share this post


Link to post
Share on other sites
Что еще хуже - в MIB'ах часто бывают ошибки и, бывает, что не вся информация доступна через MIB'ы.
Честно говоря, не сталкивался, только пару раз видел, когда название oid'а не совпадает с тем, что он делает(но по описанию вроде понятно)

В телефонных железках достаточно часто бывает. Вплоть до того, что MIB'ы просто не компилируются.

 

И наоборот - не вся информация доступна через CLI, часть только по SNMP (HP этим грешит).

это значительно реже бывает

Если на сети есть прокурвы, то бывает каждый день :)

Share this post


Link to post
Share on other sites
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, что такому-то абоненту с такими-то параметрами надо настроить сервис, получил ответ, что сервис активирован, и успокоился.

 

Share this post


Link to post
Share on other sites

>В телефонных железках достаточно часто бывает. Вплоть до того, что MIB'ы просто не компилируются.

 

Ага, бывает, что один миб-браузер не съедает, а второй на раз-два. В этом плане ireasoning меньше всего подводит.

 

>Равно как и не дело биллинга теребить железо. Плюнул по SOAP запрос в сторону service activation, что такому-то абоненту с такими-то параметрами надо настроить сервис, получил ответ, что сервис активирован, и успокоился.

 

Ну в самом деле это не совсем так, нужна ещё очередь заданий, если для активации требуется настройка оборудования доступа и если биллинг разделён с активатором, то надо делать, чтобы из биллинга можно было узнать статус(активировано на оборудовании или ещё нет).

 

>В этом отношении NOC - крайне полезная вещь, так как позволяет прятать особенности поведения разных моделей железок на низком уровне и представляет для сервисов интерфейсы более высокого уровня.

 

Кстати, забыл написать про библиотеку SNMP::Info (perl), только в ней слабая поддержка китайского говножелеза (http://netdisco.org/DeviceMatrix.html ), которую в принципе можно заюзать как интерфейс управлением железом. Если perl не пугает...

 

dvolodin

Ради интереса спрошу, у вас есть коммерческая поддержка?(если вдруг кому-то лень будет что-то править или допиливать под свою сеть)

 

Share this post


Link to post
Share on other sites
>Равно как и не дело биллинга теребить железо. Плюнул по SOAP запрос в сторону service activation, что такому-то абоненту с такими-то параметрами надо настроить сервис, получил ответ, что сервис активирован, и успокоился.

 

Ну в самом деле это не совсем так, нужна ещё очередь заданий, если для активации требуется настройка оборудования доступа и если биллинг разделён с активатором, то надо делать, чтобы из биллинга можно было узнать статус(активировано на оборудовании или ещё нет).

В NOC так и делается через Map/Reduce Tasks. Запускается задача и периодически опрашивается ее статус. В принципе, можно и callback сделать, когда по завершению

задачи NOC сам пнет биллинг и доложит о выполнении или об ошибке

 

>В этом отношении NOC - крайне полезная вещь, так как позволяет прятать особенности поведения разных моделей железок на низком уровне и представляет для сервисов интерфейсы более высокого уровня.

 

Кстати, забыл написать про библиотеку SNMP::Info (perl), только в ней слабая поддержка китайского говножелеза (http://netdisco.org/DeviceMatrix.html ), которую в принципе можно заюзать как интерфейс управлением железом. Если perl не пугает...

Если есть желание сделать все самому, то относительно неплохой выбор.

 

dvolodin

Ради интереса спрошу, у вас есть коммерческая поддержка?(если вдруг кому-то лень будет что-то править или допиливать под свою сеть)

Есть. Все обсуждаемо.

Share this post


Link to post
Share on other sites

Ну у нас вот как-то так. Это фронтенд в билинге. Тоже считаю что не дело билинга с железками общаться. У нас выполнено все в виде XML-RPC сервера через Frontier::Daemon:Fork, работает как с SNMP, так и с telnet.

 

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

Софт закрытый, хотя есть идея выложить как открытый как раз сам сервер. Там структура классов на perl для snmp и telnet, т.е. можно дописывать под другие коммутаторы. Сейчас рабтает с D-Link (почти все модели включая L3), Planet WSW, SGSW, Cisco L2/L3, Telesyn L3.

 

Кару сети можно строить как в автоматическом режиме на основе FDB, так и в ручном (через привязки).

post-44829-1289308389_thumb.png

post-44829-1289308394_thumb.png

post-44829-1289308397_thumb.png

post-44829-1289308402_thumb.png

post-44829-1289308407_thumb.png

post-44829-1289308411_thumb.png

post-44829-1289308415_thumb.png

post-44829-1289308419_thumb.png

post-44829-1289308425_thumb.png

post-44829-1289308429_thumb.png

post-44829-1289308433_thumb.png

Edited by SokolovS

Share this post


Link to post
Share on other sites

Кару сети можно строить как в автоматическом режиме на основе FDB, так и в ручном (через привязки).

Topology discovery в NOC уже вполне достойный. Работает комплексно по MAC'ам, ARP-кешу, *STP, LLDP и CDP и корректно обрабатывает port-channel'ы.

Share this post


Link to post
Share on other sites

2dvolodin: я периодически смотрю что вы делаете, интересный проект. Полностью свои проекты я открыть не могу к сожалению :(

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

Share this post


Link to post
Share on other sites
Равно как и не дело биллинга теребить железо.
Не соглашусь. В биллинге ведётся учёт абонентов (у всех так), там-же записаны разные политики для разных абонентов (например тарифы), там-же должны быть учтены особенности той или иной абонентской группы (например слабые линки), и от туда-же должен вестись онлайн мониторинг. Всё в одном ОЧЕНЬ сильно сокращает время для поиска, диагностики и устранения неисправностей на линках (или у клиентов). О том-же падении линков в первую очередь должны быть оповещены диспетчера, которые и работают с биллингом и абонентами, и у них первоначально должна быть самая оперативная информация.

 

Если это дело начинать дробить на куски (там вот Дуда, там нок, там кактус, тут веб-морда свича, здесь консоль, вон там телнет, а вот тут SSH и т.д. и т.п.) это КРАЙНЕ негативно скажется во первых на времени и качестве поиска неисправностей, во вторых на зарплатном бюджете.

 

Если я не прав - извиняюсь.

Share this post


Link to post
Share on other sites
2dvolodin: я периодически смотрю что вы делаете, интересный проект. Полностью свои проекты я открыть не могу к сожалению :(

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

Мы столкнулись с тем, что FDB хватает далеко не всегда, это скорее fallback вариант. Наши алгоритмы определяют не только связь между железками, но и физические порты или port-channel'ы, в зависимости от алгоритма. То есть информации о том, что железка A подцеплена к железке B для нас недостаточно, нужны конкретные порты, которых на наших железках бывает по несколько сотен.

Share this post


Link to post
Share on other sites
Равно как и не дело биллинга теребить железо.
Не соглашусь. В биллинге ведётся учёт абонентов (у всех так), там-же записаны разные политики для разных абонентов (например тарифы), там-же должны быть учтены особенности той или иной абонентской группы (например слабые линки), и от туда-же должен вестись онлайн мониторинг. Всё в одном ОЧЕНЬ сильно сокращает время для поиска, диагностики и устранения неисправностей на линках (или у клиентов). О том-же падении линков в первую очередь должны быть оповещены диспетчера, которые и работают с биллингом и абонентами, и у них первоначально должна быть самая оперативная информация.

А вот и не соглашусь: мешать в кучу биллинг, CRM, мониторинг, NMS, FMS, provisioning, inventory, middleware и policy server - крайне порочная практика, как в техническом, так и в политическом смысле.

Да, для оператора call-центра нужен dashboard, на котором он увидит всю необходимую информацию по клиенту сразу. Но это, скорее, CRM а не биллинг, и его задача просто сходить и дернуть нужные данные из других систем, иначе грош ему цена. Невозможно сделать продукт, который будет одинаково хорош во всем, а если вам такой продукт продали, значит на шею сели насмерть и уже не слезут. Во-вторых, либо этот продукт будет создан под ваш бизнес, либо ваш бизнес будет натянут на этот продукт. В третьих - продукт будет весьма сложным и малотиражным, тут уже просто бабло насосом сосать будут за поддержку и каждый чих.

 

Если это дело начинать дробить на куски (там вот Дуда, там нок, там кактус, тут веб-морда свича, здесь консоль, вон там телнет, а вот тут SSH и т.д. и т.п.) это КРАЙНЕ негативно скажется во первых на времени и качестве поиска неисправностей, во вторых на зарплатном бюджете.

 

Если я не прав - извиняюсь.

Достаточно просто научить биллинг/CRM выдирать данные из нужных систем по требованию и все.

 

В NOC'е мы придерживались именно такого подхода - что сделано, должно работать хорошо, но в нем не будет биллинга, middleware и прочих вещей, не имеющих отношения к управлению сетями. Но он будет с ними интегрироваться :)

Share this post


Link to post
Share on other sites

>В NOC'е мы придерживались именно такого подхода - что сделано, должно работать хорошо, но в нем не будет биллинга, middleware и прочих вещей, не имеющих отношения к управлению сетями. Но он будет с ними интегрироваться :)

 

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

nocproject это целый самостоятельный project, который, очевидно, заточен под управление оборудованием датацентра или магистральных операторов и для учёта технологических объектов(rd,ip-адреса, домены и т.д.), хотя опять же очевидно, что все эти вещи должны быть привязаны к деньгам абонентам, а не храниться в отдельной базе. И пожалуй самое главное, база данных должна быть единой, крайне важно избегать любое дублирование данных, иначе получается бардак. Допустим мы хотим дать возможность получения статического белого IPv4-адреса. Следуя Вашей идеалогии, пометка о том, кому принадлежит этот адрес должна быть в базе nocproject, но в самом деле ассоциация IP и логина на pppoe/pptp или id порта(option82) должна быть в базе биллинга, чтобы при авторизации bras получил радиус-атрибут, содержащий статический IP адрес абонента. Поэтому первая строчка из overview к nocproject нужна далеко не всем. Аналогично про последнюю, reporting должен быть в контексте денег, а не оборудования.

 

Большинству операторов он конечно интересен, но не как отдельная система, а как некий libnocproject, чтобы дёргать его напрямую из биллинга/техучёта, а не использовать его как чёрный ящик в стиле бросил SOAP-запрос и получил ответ.

 

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

 

У провайдеров последней мили все бизнес-процессы должны быть решены в виде модулей биллинга, покупается биллинг с нормальным API, к нему прикручиваются модули, тогда никакого высасывания бабла не будет

Share this post


Link to post
Share on other sites
>В NOC'е мы придерживались именно такого подхода - что сделано, должно работать хорошо, но в нем не будет биллинга, middleware и прочих вещей, не имеющих отношения к управлению сетями. Но он будет с ними интегрироваться :)

 

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

nocproject это целый самостоятельный project, который, очевидно, заточен под управление оборудованием датацентра или магистральных операторов и для учёта технологических объектов(rd,ip-адреса, домены и т.д.), хотя опять же очевидно, что все эти вещи должны быть привязаны к деньгам абонентам, а не храниться в отдельной базе. И пожалуй самое главное, база данных должна быть единой, крайне важно избегать любое дублирование данных, иначе получается бардак. Допустим мы хотим дать возможность получения статического белого IPv4-адреса. Следуя Вашей идеалогии, пометка о том, кому принадлежит этот адрес должна быть в базе nocproject, но в самом деле ассоциация IP и логина на pppoe/pptp или id порта(option82) должна быть в базе биллинга, чтобы при авторизации bras получил радиус-атрибут, содержащий статический IP адрес абонента. Поэтому первая строчка из overview к nocproject нужна далеко не всем. Аналогично про последнюю, reporting должен быть в контексте денег, а не оборудования.

 

Большинству операторов он конечно интересен, но не как отдельная система, а как некий libnocproject, чтобы дёргать его напрямую из биллинга/техучёта, а не использовать его как чёрный ящик в стиле бросил SOAP-запрос и получил ответ.

 

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

 

У провайдеров последней мили все бизнес-процессы должны быть решены в виде модулей биллинга, покупается биллинг с нормальным API, к нему прикручиваются модули, тогда никакого высасывания бабла не будет

>> Понимаете, провайдеру нужно чтобы всё было под рукой и быстро, чтобы всё было в одном интерфейсе, а не так, чтобы сначала по номеру договора смотреть есть ли деньги в

>> биллинге, потом лезть в тех.учёт и смотреть куда он подключен, потом ползти в некий интерефейс управления железом, смотреть что там с портом, приходит ли мак и т.д.

+100500, подписываюсь под каждой буквой. Именно поэтому в конечном итоге с ростом сети все провайдеры приходят к самописному либо заказному софту.

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

Share this post


Link to post
Share on other sites
Что еще хуже - в MIB'ах часто бывают ошибки и, бывает, что не вся информация доступна через MIB'ы.
Честно говоря, не сталкивался, только пару раз видел, когда название oid'а не совпадает с тем, что он делает(но по описанию вроде понятно)

В телефонных железках достаточно часто бывает. Вплоть до того, что MIB'ы просто не компилируются.

 

И наоборот - не вся информация доступна через CLI, часть только по SNMP (HP этим грешит).

это значительно реже бывает

Если на сети есть прокурвы, то бывает каждый день :)

Это вы о чем?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this