Перейти к содержимому
Калькуляторы
Точная информация о портах подключений абонентов  

39 пользователей проголосовало

  1. 1. Знаете ли вы на все 100% о реальных точках подключения абонентов (логинов) к вашей сети с точностью до абонентского порта?

    • Нет не знаю, при обслуживании абонента эта информация абсолютно не востребована
      3
    • Знаю по результатам записей в журнале подключений и мне этого вполне достаточно
      7
    • Знаю, т.к. у нас используется жёсткая связка MAC+port
      8
    • Знаю по результатам сбора SNMP-trap пакетов
      3
    • Знаю по результатам периодического сбора информации о MAC-адресах абонентов
      8
    • Знаю, т.к. у нас для этого используется своё ПО
      18
    • Не знаю, но был бы не прочь иметь такую возможность
      6
    • Не знаю, но очень нужно знать в реальном времени об этом.
      2
    • Готов учавствовать в разработке и тестировании подобного ПО
      8


Open-TMN Открытая реализация концепции Telecommunication Management Network

День добрый коллеги.

 

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

И практически всегда мы мониторим оборудование именно в смысле работоспособности.

 

Работаю я в провайдинге с 2003 года и за все эти годы понял что очень важно не просто видеть как работает оборудование (это безусловно важно), а знать де-факто откуда подключается в сеть абонент. Так я начал использовать в своей работе концепцию "точка доступа", хотя впервые эту концепцию придумал не я.

Но я пошёл дальше и постепенно вокруг этой концепции родилась целая модульная система, которая как выяснилось во многом напоминает концепцию Telecommunication Management Network http://ru.wikipedia.org/wiki/TMN

 

С некоторых пор я понял что будет лучше сделать проект общедоступным, т.к. мне всегда была интересна практическая сторона вопроса, т.е. конкретные задачи. Именно практические задачи дают рост программному продукту. Проект расположен по адресу http://open-tmn.googlecode.com, лицензия - GPLv2

Т.к. я не программист по образованию, прошу пинать не злостно ;) Некоторая часть кода написана очень давно, когда мои навыки были несколько иными.

 

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

Описание продукта пока ещё только общее, но я буду заниматься и этим по мере наличия свободного времени.

WEB-интерфейс написал мой коллега, за что ему большое человеческое спасибо.

 

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

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

 

Чуть позже постараюсь описать подробно как всё устроено.

Изменено пользователем tux-tm

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


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

Т.к. я не программист по образованию, прошу пинать не злостно ;) Некоторая часть кода написана очень давно, когда мои навыки были несколько иными.
+1, иногда такое у себя встречаю - волосы дыбом встают :) а иногда и такие вещи, гениальность реализации которых меня поражает до сих пор (не пойму, как это я вообще это смог написать)

 

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

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


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

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

 

Главное что нужно сделать сразу - это по сути несколько базовых вещей

- чёткое определение понятий

- концепция взаимодействия между частями системы

- и соответственно структура данных БД.

 

Цели рождаются от практически стоящих перед нами задач. И поскольку система задумана модульно, то и реализовывать желательно каждую отдельную задачу модулями, а затем "причёсывать" в общую систему.

 

Опишу сначала в общем принципы взаимодействия внутри системы.

Сеть строится по древовидной архитектуре. Ведь почти любая сеть - это логически дерево или звезда. Даже кольцевые сети под эту логику коммутации подходят. Кроме того, обычно в практике даже с основных колец уходят ветвления в виде дерева. Так что каждый коммутатор имеет у себя PARENT коммутатор, т.е. вышестоящий (кроме последнего - головного для всей сети). В частности такой же принцип используется в Nagios.

 

В простом варианте системы считается что вся сеть входит в единую зону и внутри неё одно пространство VLAN, т.е. максимум что можно использовать - около 4000 VLAN-ID внутри одной зоны.

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

Зональное разделение я тестировал только на стенде. И хотя в общем всё очень логично работало, возможны ошибки в коде с учётом зон.

 

Из типов подключений абонентов используются следующие:

1) PPPoE подключение, а так же в качестве дополнительного - IPoE с получением адреса по DHCP. Используется влан-на-свич

2) L2LINK - коммутация территориально распределённых точек абонента между собой по заданным скоростям на портах каждой точки подключения. Используется влан-на-порт

3) L3NET Прямое подключение со статическими параметрами IP-сети. Используется влан-на-порт. С удовольствием заменил бы его на IPoE с получением адреса по DHCP. Но т.к. эти подключения исторически сложились до моего прихода в компанию, мне их к сожалению вмиг не изменить.

 

Базовым подключением в системе является PPPoE. На каждом оконечном коммутаторе заводится общий для базового подключения абонентов этого свича VLAN и он прокидывается "вверх" через все вышестоящие коммутаторы до головного для зоны коммутатора и заводится на PPPoE-BRAS и так же на IPoE-BRAS. Соответственно при вводе в эксплуатацию для каждого свича в БД указывается его зона и его базовый абонентский VLAN. На свичах без возможности сегментации трафика используется принцип "влан на порт". У меня доля таких свичей постоянно уменьшается к счастью, и вам того же желаю ибо с таким подходом слишком всё усложняется.

При подключении абонента к BRAS прямо на стадии авторизации выясняется "точка выхода" логина с точностью до порта коммутатора. Так же в БД импортируются из билинговой системы параметры подключения для каждого логина. Если в БД были иные параметры - формируется задание в очередь по перенастройке портов. Каждый тип заданий имеет своего обработчика. Простые задачи настройки портов выполняются автоматическим обработчиком. Обработку сложных заданий выполняет человек с отслеживанием логов процесса настройки. Пример простого задания - сменить скорости на порту, сложное - прокинуть влан от оконечного порта к головному свичу зоны через все вышестоящие коммутаторы.

 

Кроме этого у меня дополнительно к PPPoE очень эффективно работает прямое подключение абонентов по IPoE. Это подключение базируется на информации о входах с использованием базового подключения. Т.е. по IPoE возможность подключения отсутствует до тех пор пока абонент ни разу не подключался по PPPoE и если вообще такое подключение предусмотрено тарифом абонента.

 

IPoE-терминатор является общим для зоны. Я использовал для этой задачи узловой коммутатор CISCO, запросы DHCP с него пересылаются на FreeRADIUS. Далее вступают в дело функции rlm_perl, которые обеспечивают обработку запросов с проверкой возможности выхода абонентов по данным с БД. Там же реализован алгоритм использования пулов адресов и учёта сессий.

 

Для мониторинга сети по SNMP данные из БД автоматически переливаются в конфиг Nagios'а и через него мониторим всю сеть до портов включительно.

 

Для просмотра данных по коммутаторам и абонентам на них, а так же для редактирования и добавления информации в БД написан свой WEB-интерфейс.

Скриншоты есть на сайте проекта.

Изменено пользователем tux-tm

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


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

Несколько скриншотов по коммутаторам

http://picasaweb.google.com/Bannix/OpenTMN#

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


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

tux-tm, вы видите систему как техническое средство реализации какой-то одной, четко поставленной задачи. В этом случае вы 100% решите поставленную задачу. А как же другие задачи, которые тоже требуют незамедлительного решения?

 

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

 

1) обеспечение сервиса клиента - удалённая диагностика, постоянный мониторинг оборудования, быстрая сигнализация о сбоях (в течении 3-х минут максимум) и своевременная реация в случае проблем

2) обеспечение менеджмента кадров - жесткое разграничение полномочий, максимально-точная статистика выполненных работ

3) централизация управления оборудованием и его мониторинга

4) максимально-возможное сокращение трудозатрат сотрудников при работе с системой - всё должно быть максимально-удобно и понятно

 

Вы описали систему, я описал подход.

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

Ответьте на вопрос: какие организационные задачи решит именно ваша система, в отличии от конкурирующих продуктов? Почему именно она должна стать самой лучшей?

Ответ на эти вопросы, их тчательнейшая проработка и даст начало (это только начало) работы над структурой системы.

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


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

Задача у меня достаточно определённая, но не одна. И я не "вижу подобную систему как средство для решения главной задачи в любом бизнесе". Для бизнеса продают достаточно ПО, только вот бизнесмены не спешат на него тратить денег, вместо этого возлагая неэффективную рутину на сотрудников. Моя цель - облегчить работу людям-сотрудникам ISP с одной стороны и дать сервис другим людям-абонентам с другой. При этом ни одна важная часть текущей системы не заменяется, а просто происходит взаимодействие с ними и между ними, особенно с той частью что обязательно должна иметь сертификат - билинг, мониторинг, сбор информации о сервисах и т.п. у каждого по-своему.

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

 

Я никогда не был сторонником методов "всё в одном флаконе", а именно это ИМХО вы пытаетесь вложить в концепцию. Эдакий монолит, в котором каждый чих каждого сотрудника надо описать портянкой ACL - это не наш метод. Модульно и ещё раз модульно, UNIX-like подход.

 

1) У каждого провайдера наверняка есть свой билинг и он же должен иметь сертификат. Так накой мне велосипед придумывать то?

2) Мониторинговых систем так же немало, и всё что нужно - слить в них информацию из БД и наслаждаться созерцанием картины сети или получать СМС и т.п.

3) Делать разграничение прав в чём-то нужно, но обычно это либо права админа, либо техника, и они соответственно - RW или RO. Да и касается это разграничение только web-интерфейса. Всё остальное настраивает один специалист и далее оно должно работать автоматически.

 

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

 

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

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

Система по возможности использует давно проверенные программные продукты, при этом данные об абонентских сервисах берёт из билинга, ведь там по сути они должны быть самыми достоверными.

 

По вашим пунктам:

1) Нисколько не пытаюсь придумать конкурирующую скажем мониторинговую систему, я просто использую уже имеющуюся - Nagios.

И все вопросы касательно вашего 1-го пункта касаются именно его функционала.

2) Полномочия по сути нужны только для технического персонала, который занимается настройкой оборудования или просмотром данных - это не настолько сложно реализовать, например средствами Apache. К тому же таких специалистов в компании обычно не более двух, так что не вижу смысла огород городить.

3) Здесь ИМХО мухи с котлетами - управление оборудованием и так централизовано, а о мониторинге сказали ещё в первом.

4) В системе как раз таки подход такой чтобы максимально автоматизировать управление оборудованием на основании данных из билинга.

 

Я описал именно базовые принципы построения сети, а не установил жёсткие рамки. Эти базовые принципы и есть точка отсчёта.

 

Если Вам хочется построить именное так как Вы это видите - я только за!

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

 

 

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


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

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

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


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

Честно говоря, тоже не очень понятно что это такое. Примерно тоже самое что и nocproject, который пиарят в одной из соседних веток? Хотелось бы понять какие функции выполняет эта софтина(чётко и по пунктам - тех.учёт, мониторинг, управление, бэкапы или что ещё? Или же это вообще некий костыль, который связывает кучу другого софта?).

 

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

настораживает... т.е. это изначально расчитано на небольших операторов? Даже без деления на техподдержку(кол-центр) и администраторов?

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


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

Честно говоря, тоже не очень понятно что это такое. Примерно тоже самое что и nocproject, который пиарят в одной из соседних веток? Хотелось бы понять какие функции выполняет эта софтина(чётко и по пунктам - тех.учёт, мониторинг, управление, бэкапы или что ещё? Или же это вообще некий костыль, который связывает кучу другого софта?).

 

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

настораживает... т.е. это изначально расчитано на небольших операторов? Даже без деления на техподдержку(кол-центр) и администраторов?

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

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

 

Деление на админов и техподдержку есть, но не в развёрнутом виде.

Изменено пользователем tux-tm

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


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

Действительно задачи очень сходные с NOC-project, Но не всё похоже, насколько я могу судить из описания на их сайте. В целом NOC-проект мне нравится и подход во многом совпадает, но у меня больше направлено на управление оконечным оборудованием, а там насколько я успел понять большая направленность на узловое оборудование.
В первом приближении у мня сложилось понимание, что вы жестко привязываетесь к конечному юзеру (скорее физику) и его сервису и к типовым топологиям (дерево/звезда/кольцо) и,

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

И тот и другой подход имеют право на существование.

 

Насколько я понял, вы сделали заточенное под себя простое inventory?

 

Но его я не пробовал юзать т.к. своё детище имело нужный мне функционал гораздо раньше и в большем объёме. Кроме того на питоне не пишу, а так бы может даже и поучаствовал.
Ну так поучаствуйте :) Для этого не обязательно что-либо писать, и тем более на питоне. Проект набирает обороты и имеет достаточно серьезную поддержку. Сейчас начали делать inventory, может быть и ваши наработки на нее лягут.

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


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

Действительно задачи очень сходные с NOC-project, Но не всё похоже, насколько я могу судить из описания на их сайте. В целом NOC-проект мне нравится и подход во многом совпадает, но у меня больше направлено на управление оконечным оборудованием, а там насколько я успел понять большая направленность на узловое оборудование.
В первом приближении у мня сложилось понимание, что вы жестко привязываетесь к конечному юзеру (скорее физику) и его сервису и к типовым топологиям (дерево/звезда/кольцо) и,

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

И тот и другой подход имеют право на существование.

 

Насколько я понял, вы сделали заточенное под себя простое inventory?

 

Но его я не пробовал юзать т.к. своё детище имело нужный мне функционал гораздо раньше и в большем объёме. Кроме того на питоне не пишу, а так бы может даже и поучаствовал.
Ну так поучаствуйте :) Для этого не обязательно что-либо писать, и тем более на питоне. Проект набирает обороты и имеет достаточно серьезную поддержку. Сейчас начали делать inventory, может быть и ваши наработки на нее лягут.

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

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

 

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

 

У себя в системе я не делаю backup реальных конфигов типичных коммутаторов. Делаю их только для узловых и головных, у которых конфиги нетипичные.

Порты же типичных коммутаторов, легко можно настроить даже с нуля средствами абстрактных команд, например "SETPARM" (настроить параметры порта по данным из БД).

 

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

 

Задумок возникает достаточно много и конечно же проект ещё очень сырой. В немалой степени ещё и потому что я не ахти какой программист.

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

Предстоит смена работы, очень надеюсь что это к лучшему.

А пока что правлю баги и добавляю по мелочи. Например надо сделать тестовое наполнение в БД, чтобы можно было хотя-бы поднять систему на предмет "пощупать", сейчас же доступна только лишь структура БД.

 

p.s.

Постараюсь выкроить время и пощупать NOC-project, заодно и подумаю о Вашем предложении поучаствовать ;)

И ещё мне интересно по каким соображениям Вы выбрали лицензию BSD?

Изменено пользователем tux-tm

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


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

У меня даже есть анализатор соответствия транковых портов, но он работает только по корректировке состыкованных портов соседних коммутаторов. В планах было доработать алгоритм, чтобы он смог полностью строить дерево коммутаторов. А ещё в планах было сделать механизм сбора абстрактной конфигурационной информации из реального оборудования в БД. Это очень облегчит первоначальный запуск системы на уже рабочей сети.
Topology discovery в первом приближении мы сделали. Работает комплексно по анализу данных из таблиц мак адресов, ARP-кеша, *STP, LLDP и CDP. Сейчас работаем над хранением топологии в базе. Тестовая реализация уже есть, необходимые скрипты для Force10 уже написаны, доделываем морду для просмотра топологии. Дальше пойдем в сторону физики и набивки железок.

 

Задумок возникает достаточно много и конечно же проект ещё очень сырой. В немалой степени ещё и потому что я не ахти какой программист.

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

Предстоит смена работы, очень надеюсь что это к лучшему.

А пока что правлю баги и добавляю по мелочи. Например надо сделать тестовое наполнение в БД, чтобы можно было хотя-бы поднять систему на предмет "пощупать", сейчас же доступна только лишь структура БД.

Проще сделать VMware image.

 

И ещё мне интересно по каким соображениям Вы выбрали лицензию BSD?
зачем кому-то что-то навязывать? :) От того, что кто-то сделает из NOC'а EMS или свою OSS или интегрирует его в свое решение - у нас не убудет. FreeBSD немного потеряла от того, что используется в Junos, а NetBSD - от того, что используется в Force10 FTOS. ;)

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


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

Join the conversation

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

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

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

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

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

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

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