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

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

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

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

 

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

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


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

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

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

 

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

 

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

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

 

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


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

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

 

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

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


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

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

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

 

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

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

 

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


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

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

 

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

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

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


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

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

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

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


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

dvolodin

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

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


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

dvolodin

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

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

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


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

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

 

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

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

 

 

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


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

dvolodin

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

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

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

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


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

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

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

 

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

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

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

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


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

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

 

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


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

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

 

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

 

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

 

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

 

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

 

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

 

dvolodin

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

 

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


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

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

 

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

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

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

 

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

 

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

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

 

dvolodin

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

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

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


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

Ну у нас вот как-то так. Это фронтенд в билинге. Тоже считаю что не дело билинга с железками общаться. У нас выполнено все в виде 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

Изменено пользователем SokolovS

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


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

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

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

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


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

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

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

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


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

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

 

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

 

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

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


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

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

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

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

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


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

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

http://forum.nag.ru/forum/index.php?showtopic=54023

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


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

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

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

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

 

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

 

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

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

 

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

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


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

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

 

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

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

 

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

 

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

 

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

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


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

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

 

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

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

 

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

 

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

 

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

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

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

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

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

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


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

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

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

 

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

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

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

Это вы о чем?

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


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

Join the conversation

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

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

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

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

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

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

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