[SokolovS]

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

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

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

Нам хватает ;) Номера портов определяются нормально, причем даже для многоюнитовых коммутаторов. Обратите внимание мы указывам номера портов в виде юнит:порт. Проблема скорее в кольцах L2, L3, но у нас есть возможность и ручной привязки с запрещением внесения изменений автоматом. Работать вобщем то еще есть над чем, но аварийная служба с тех.поддержкой уже балдеют.

 

Обрити внимание на скрине: http://forum.nag.ru/forum/index.php?act=at...ost&id=5249

Стоит соответствие на 24 порту и запрещено его отключать т.к. это аплинк. Т.е. мне кажется как раз наоборот в большинстве случаев FDB более реальную картину дает. Потом еще хочу рекомендацию дать, для устройств хранить диапазон self MAC-адресов, т.к. у L3 коммутаторов их например много и наличие любого из них на порту носит определяющий характер :)

Изменено 9 ноября, 2010 пользователем SokolovS

[SokolovS]

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

Вот тут пожалуй соглашусь :) Скрины которые я приводил это на самом деле часть интерфейса билинга, а не отдельная система. И у нас именно так как ты пишешь, т.е. оператор ТП сразу видит куда подключен абонент, может посмотреть нет ли ошибок на порту, посмотреть клиентские маки и.т.д. и это удобно. Я не представляю если бы им пришлось лезть еще куда-то.

 

Когда я писал что билинг не должен работать с железом я имел ввиду что он не должен делать это напрямую, должен быть некий сервер реализующий функционал работы с железом и интерфейсом SOAP или XML-RPC. Вся первичная информация в том числе и по оборудованию должна храниться в билинге. Ну это мое мнение.

 

Плюс должна быть гибкая система прав. Например доступ к веб-консоли управления железом у нас имеет только группа "Специалисты по сетевому обеспечению" ну и "Суперюзеры" :) Права у нас делятся на чтение / запись / супер-привелегии / просмотр паролей.

Изменено 9 ноября, 2010 пользователем SokolovS

[dvolodin]

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

nocproject это целый самостоятельный project, который, очевидно, заточен под управление оборудованием датацентра или магистральных операторов и для учёта технологических объектов(rd,ip-адреса, домены и т.д.), хотя опять же очевидно, что все эти вещи должны быть привязаны к деньгам абонентам, а не храниться в отдельной базе. И пожалуй самое главное, база данных должна быть единой, крайне важно избегать любое дублирование данных, иначе получается бардак.

Мы идем немного в другую сторону - разделяемые ресурсы должны привязываться к сервису, а вот сервис может оказываться, в том числе, и абоненту. Давайте все-таки определимся с задачами. Маленький ШПД вполне проживет и на биллинге, так как его относительно просто на него натянуть. Если оператор покрупнее, то пихать все в биллинг - идиотизм. По большей части, в качестве центрального хранилища выступает таки inventory, из которого все дергают данные.

 

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

Опять же - зависит от размеров и задачи. Возьмем для примера тот же Juniper E-series, чем не BRAS. SRC-PE к ним совсем не зря делают, несмотря на его монструозность. И тут еще большой вопрос, откуда SRC-PE правильнее брать адрес.

 

NOC обычно используется как инструмент для проведения технической политики, элементами которой являются и адресный план, и политика маршрутизации и пиринговая политика. К вопросам биллинга, абонентам и деньгам эти вещи весьма ортогональны. Каким боком конфиг свича, например, относится к биллингу? А прилетевший SNMP Trap?

 

Собственно IPAM в NOC появился под вполне конкретную задачу - разработку адресного плана для сети МгМн.

 

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

 

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

 

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

Опять же - если центр управления сетью совмещен с девочками-менеджерами на телефоне, то да, биллинг. А если сетью управляет распределенная техническая служба, то в биллинг ее вообще пускать противопоказано. Все-таки каждый инструмент - для своей задачи.

 

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

Это вы о чем?

HP ProCurve. CLI у них чудной, для того же MSTP часть параметров можно выдернуть только через SNMP или walkMIB

[dvolodin]

Обрити внимание на скрине: http://forum.nag.ru/forum/index.php?act=at...ost&id=5249

Стоит соответствие на 24 порту и запрещено его отключать т.к. это аплинк. Т.е. мне кажется как раз наоборот в большинстве случаев FDB более реальную картину дает. Потом еще хочу рекомендацию дать, для устройств хранить диапазон self MAC-адресов, т.к. у L3 коммутаторов их например много и наличие любого из них на порту носит определяющий характер :)

В этом нет необходимости. MAC'и SVI интерфейсов автоматом выскребаются из ARP-кешей. Кроме того наш алгоритм нормально определяет абонентские порты.

FDB не видит заблокированные по STP порты и не видит физические порты, входящие в port-channel.

[Wingman]

Каким боком конфиг свича, например, относится к биллингу? А прилетевший SNMP Trap?

Навскидку:

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

- vpn vlan, например. Хотя у нас - достаточно нечастое явление, чтобы хранить отдельно.

- Прилетел трап о срабатывании того же storm-control и блокировке абонентского порта - желательно также в билинг запихнуть, чтобы операторы, открыв инфу юзера, сразу видели причину "неработы тырнета"

Можно продолжать долго =)

Изменено 9 ноября, 2010 пользователем Wingman

[s.lobanov]

>Опять же - зависит от размеров и задачи. Возьмем для примера тот же Juniper E-series, чем не BRAS. SRC-PE к ним совсем не зря делают, несмотря на его монструозность. И тут еще большой вопрос, откуда SRC-PE правильнее брать адрес.

 

И всё же вернёмся к дублированию данных. Абонент, подключённый по PPPoE захотел статический адрес, допустим внедрён nocproject в чистом виде, вносим в него, что абонент Вася Пупкин(что именно вносим - какой-то id абонента, id сервиса или "вася пупкин" ?) получил такой-то адрес.

Чтобы он выдавался Васе каждый раз при авторизации, его ведь ещё куда-то надо внести, откуда его будет брать брас? Ну чем тут не дублирование?

 

По всему остальному дам ответ позже, если за меня не ответят.

[dvolodin]

Каким боком конфиг свича, например, относится к биллингу? А прилетевший SNMP Trap?

Навскидку:

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

- vpn vlan, например. Хотя у нас - достаточно нечастое явление, чтобы хранить отдельно.

Ну так пусть хранится. Только зачем именно биллингу самому по свичам бегать? Пнул service activation и все.

 

По хранению данных, применительно к NOC, можно навесить триггеры на события: см. пример. И никакой двойной работы

не будет - забил данные в NOC, если надо, они автоматом уедут в биллинг. Со стороны биллинга, в принципе, аналогично должно делаться.

 

- Прилетел трап о срабатывании того же storm-control и блокировке абонентского порта - желательно также в билинг запихнуть, чтобы операторы, открыв инфу юзера, сразу видели причину "неработы тырнета"

Можно продолжать долго =)

Опять же - не дело биллинга парсить весь syslog/snmp. Пусть их собирает fault management, у него и производительность повыше, и мозгов побольше :)

Дополнительные данные он всегда сможет дернуть из inventory/биллинга или других систем. А уже по факту, словив событие, сообщающее о приостановке сервиса, красиво пнуть биллинг и сказать, что юзера отключили по такой-то причине. И оператор сразу увидит причину в общем dashboard'е.

[dvolodin]

>Опять же - зависит от размеров и задачи. Возьмем для примера тот же Juniper E-series, чем не BRAS. SRC-PE к ним совсем не зря делают, несмотря на его монструозность. И тут еще большой вопрос, откуда SRC-PE правильнее брать адрес.

 

И всё же вернёмся к дублированию данных. Абонент, подключённый по PPPoE захотел статический адрес, допустим внедрён nocproject в чистом виде, вносим в него, что абонент Вася Пупкин(что именно вносим - какой-то id абонента, id сервиса или "вася пупкин" ?) получил такой-то адрес.

Чтобы он выдавался Васе каждый раз при авторизации, его ведь ещё куда-то надо внести, откуда его будет брать брас? Ну чем тут не дублирование?

Давайте все-таки разделять дублирование данных и их повторный многократный ввод. Как вариант - NOC можно научить генерировать конфиг для DHCPd, или подсовывать нужные данные RADIUS'у, или провзаимодействовать с policy-server'ом, или тупо накормить BRAS данными о подписчике, если он софтовый. Со стороны биллинга все предельно просто должно быть - запросили и зарезервировали свободный адрес в заданном пуле, сказали NOC'у, что ему надо активировать сервис "статический IP на PPPoE", получили подтверждение, что сервис активирован.

 

А если завтра клиент вдруг обзаведется AS'кой и решит стать downlink'ом. А биллинг про BGP'шные вещи вообще не в курсе, что делать будем? А в случае с отдельным service activation ему достаточно только пнуть его на тему активации сервиса "BGP Downlink" и забыть о том, что сессии, вообще-то, надо настраивать, а фильтры - периодически обновлять. И, по отработанному механизму, NOC, увидев, что BGP-пир завалился, честно пнет биллинг, и оператор увидит это в списке событий. А если пойдем дальше и вспомним про MPLS-сервисы? А тут опаньки, а биллинг и слов-то таких страшных не знает. Плагины к нему писать будем?

 

Основной вопрос - в удобстве сопровождения. Если своих ресурсов немного и сетка небольшая, то биллинг может и сам заниматься такими вещами. Но, с определенного момента, лучше использовать более гибкое внешнее решение. Скрипты для активации сервиса могут быть весьма запутанными и лучше выносить из них все взаимодействие непосредственно с железом отдельно. В случае с NOC'ом - есть generic script'ы, которые не привязаны непосредственно к железу. Если, скажем, решили поменять часть DLink'ов на Zyxel'ы, то достаточно сделать небольшой набор примитивов (которые, с высокой вероятностью, уже кем-то сделаны), и сложный скрипт активации сервисов будет работать на новом железе. Как мы будем выкручиваться в случае, если этим занимается биллинг? Перепишем весь скрипт для другой железки? А при модификации сервиса потом будем вносить изменения в нескольких местах?

 

 

 

 

[terrible]

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

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

 

Если, скажем, решили поменять часть DLink'ов на Zyxel'ы, то достаточно сделать небольшой набор примитивов (которые, с высокой вероятностью, уже кем-то сделаны), и сложный скрипт активации сервисов будет работать на новом железе. Как мы будем выкручиваться в случае, если этим занимается биллинг? Перепишем весь скрипт для другой железки?

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

[marikoda]

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

Придумать свой язык для описания парсилки лога? Проще взять готовые perl,tcl,pyhon и т.п.

[terrible]

Придумать свой язык для описания парсилки лога?

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

Я думал заняться такой хнёю, но пока у нас только длинк и смысла делать нет.

[mlevel]

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

 

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

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

 

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

Извините за оффтоп, скажите пожалуйста чем рисуеться карта коммутаторов (рис. 1), очень ровно получилось, хотелось бы у себя такое реализовать.

[SokolovS]

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

 

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

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

 

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

Извините за оффтоп, скажите пожалуйста чем рисуеться карта коммутаторов (рис. 1), очень ровно получилось, хотелось бы у себя такое реализовать.

http://pear.php.net/package/Image_GraphViz

Это кстати не вся карта, это только кусочек, один из центров. Там ноды можно ссылками делать для переходов вглубь и возвратов обратно, т.е. для навигации по уровням карты.

Изменено 11 ноября, 2010 пользователем SokolovS

[mlevel]

Огромнейшее спасибо.

Оф. сайт:

http://www.graphviz.org/

[dvolodin]

Придумать свой язык для описания парсилки лога?

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

Я думал заняться такой хнёю, но пока у нас только длинк и смысла делать нет.

В NOC примерно так и сделано. Сообщения классифицируются и, в дальнейшем, вся работа идет с классами сообщений.

[jingvar]

Позвольте незамутненным взглядом высказаться.

 

Сейчас занимаюсь домашним написанием управлялки. Основная проблема - банально нет описания и понимания что нужно сделать. Т.е. понятно, что конфиги, прошивки лить, итд.

Но главный вопрос - нет реверс инженеринга бизнеспроцессов.

Вот вы говорите для операторов нужен дашборд, а что они должны там делать? Как они должны исполнять свои обязанности? Какие именно ресурсы им необходимы?

 

Вот когда работа админов, операторов, бухгалтерии, и маркетинга будет понятна от и до, возникнет некая CRM система. И в целом как будет крутится биллинг+управление, вообще все отдельно или еще как будет не принципиально.

 

На тему готовых систем - а я что-то не помню ни одной системы которая взяла и сразу в конторе заработал без допилки. Я к тому, что поверх любой базовой системы придется натягивать свое окружение и вариант подсесть на интегратора будет в любом случае. Для конкретики есть python - постой язык, сделать на нем framework стоит денег, есть Zope свободный крутой framework - на нем сделать CMS стоит денег, берем свободный Plone - CMS - запилить его под вас стоит денег, запилили под вас CMS - девелопер слишком много денег хочет, сколько будет стоить другой? Да одинаковую сумму относительно любого этапа.

 

Если будет существовать идеальная система управления, вы то для чего будете нужны :)

 

P.S. Может кто поделится инфой что должен делать оператор, как, к каким ресурсам должен быть доступ?

[terrible]

что должен делать оператор, как, к каким ресурсам должен быть доступ

Первое и самое главное - он должен делать деньги!

Второе - заработанные даньги он должен экономить!

Третье - он должен всегда стремиться к новым возможностям заработка денег и их экономии!

 

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

 

И не идите вперёд паравоза, для реальной работы первоначально требуется чётко описать бизнес-процесс, а уже под него допиливать СУ.

[jingvar]

И не идите вперёд паравоза, для реальной работы первоначально требуется чётко описать бизнес-процесс, а уже под него допиливать СУ.

Так о чем я и говорю, без этого обсуждать СУ и их связки нет смысла.

[dvolodin]

что должен делать оператор, как, к каким ресурсам должен быть доступ

Первое и самое главное - он должен делать деньги!

Второе - заработанные даньги он должен экономить!

Третье - он должен всегда стремиться к новым возможностям заработка денег и их экономии!

Вы путаете оператора и менеджера по продажам. Оператор должен работать с клиентом согласно своим инструкциям, в отдельных случаях проводить диагностику по диагностическим картам,

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

 

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

 

И не идите вперёд паравоза, для реальной работы первоначально требуется чётко описать бизнес-процесс, а уже под него допиливать СУ.

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

 

Разделение функционала по службам и системам позволяет, в определенной мере, устранить перекосы, возникающие при смене процессов. Обычно всякая лобуда, связанная с маркетингом, работой с клиентами, тарифными планами и прочим куда более динамична, чем работа службы эксплуатации, которая по определению весьма статична и не допускает излишней дерготни.

 

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

[s.lobanov]

dvolodin

Поделитесь Вашей точкой зрения на процесс общения первой линии с абонентом. Допустим звонит "блондинка" и говорит, что "интернет не работает", посмотреть статус линка, тем более выполнить ipconfig /all не в состоянии. (Допустим, что проблема в том, что абонент установил фаервол типа "iptables -I INPUT -j DROP")

 

Оператору удаётся узнать ФИО и домашний адрес. Что должен делать оператор дальше? В какие системы ползти?(особенно интересует как в этом учавствует nocproject). Вариант - составить заявку и отправить на вторую линию не предлагать или же описать алгоритм работы второй линии по типовым заявкам "не работает интернет"

Изменено 13 ноября, 2010 пользователем s.lobanov

[Ivan_83]

Убедится что проблема есть: проверить не ушёл ли в минуса или всякую блокировку биллингом типа юзер сам заблокировал или его отключили за вирусную активность и тп.

Уже потом искать в технических плоскостях проблему.

[dvolodin]

dvolodin

Поделитесь Вашей точкой зрения на процесс общения первой линии с абонентом. Допустим звонит "блондинка" и говорит, что "интернет не работает", посмотреть статус линка, тем более выполнить ipconfig /all не в состоянии. (Допустим, что проблема в том, что абонент установил фаервол типа "iptables -I INPUT -j DROP")

 

Оператору удаётся узнать ФИО и домашний адрес. Что должен делать оператор дальше? В какие системы ползти?(особенно интересует как в этом учавствует nocproject). Вариант - составить заявку и отправить на вторую линию не предлагать или же описать алгоритм работы второй линии по типовым заявкам "не работает интернет"

Да хотя бы так:

* При входящем вызове у оператора в CRM'е выскакивает dashboard с состоянием счета клиента и текущим статусом сервисов, если удается определить клиента по A-номеру. Если не удается - спрашиваем номер договора и ищем руками и получаем тот же dashboard.

* Дальше, в идеале, проходим по шагам по карте. Если надо, например, посмотреть маки на порту, то можно пнуть тот же сторонний service activation и получить их. Линк стоит - маков нет - идем дальше.

* Ходим по карте пока не исчерпываем все варианты, которые вы предусмотрели для девочек. Не помогло - отдаем на вторую линию.

* Опционально девочек спихиваем на аутсорс. Несогласных - в декрет.

 

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

 

Если бизнес-процессы просты, и девочку не обламывает схватить бухту кабеля и побежать перетягивать клиента, то пойдут и простые решения, где все в одном (биллинг, CRM, OSS'ы). А если задача посложней, то придется комбинировать более специализированные системы и, возможно, часть дорабатывать. В отдельных случаях NOC может быть хорошим кубиком и альтернативой написанию аналогичного функционала с нуля.