forum.bitel.ru
http://forum.bitel.ru/

Единый модуль трафика
http://forum.bitel.ru/viewtopic.php?f=1&t=4352		 Страница 2 из 4
Автор:  Cromeshnic [ 05 авг 2010, 15:33 ]
Заголовок сообщения:  Re: Единый модуль трафика
А можно поподробнее про dial-up часть? В модуле dialup сейчас есть логины и наборы атрибутов. Как это будет представлено там на договоре? Есть мысли касаемо isg, в ближайшее время постараемся оформить..
Автор:  Администратор [ 06 авг 2010, 18:04 ]
Заголовок сообщения:  Re: Единый модуль трафика
Посмотрите на второй странице ТЗ, блок: "При RADIUS авторизации".

Логины будут в отдельном каком-то блоке, называемом "Учётные данные". Ну, например, "Блок логинов 1".
RADIUS сервер заводится в дереве шлюзов, в конфигурации указываются порты, с какого блока учётных данных брать логины.

NAS - дочерний для RADIUS шлюза шлюз в дереве. Там указываются его идентификатор, секрет и т.п.
И каждый NAS соотнесён своему источнику логов.

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

Т.е. например в тарифах будет переключатся в зависимости от зон "Тип правила". А уже шлюз будет смотреть, что ему при такой комбинации типов правил делать.
Слать ли CoA с какими-то атрибутами, или добавлять какую-то ACL.

Я бы предложил форумчанам описать реально существующие структуры сети, а также потребности по их управлению со стороны биллинга. А я попробую расписать, как это можно будет реализовать в новом модуле.
Автор:  Cromeshnic [ 11 авг 2010, 15:32 ]
Заголовок сообщения:  Re: Единый модуль трафика
Администратор писал(а):
Я бы предложил форумчанам описать реально существующие структуры сети, а также потребности по их управлению со стороны биллинга. А я попробую расписать, как это можно будет реализовать в новом модуле.


Ок. Наша реализация ISG и хотелки:

ISG для нас - возможность гибко сконфигурировать сервисы клиента.
Схема выглядит следующим образом:
1. pppoe-клиент авторизуется в биллинге обычным образом, ему выдаются специальные radius-атрибуты (cisco-SSG-Account-Info), определяющие, какие ISG-сервисы нужно подключить для этой сессии
2. Циска авторизует эти сервисы как обычные логины (с точки зрения биллинга) на втором radius-сервере биллинга, работающем с отдельным экземпляром модуля dialup (далее - "модуль ISG")
3. Каждому сервису ISG соответствует логин в модуле ISG на специальном служебном договоре. Для каждого логина прописан большой список radius-атрибутов, которые вешаются циской на родительскую сессию (логин основного модуля)

Собственно, пока это всё.
Картинка:
Вложение:
isg.JPG


Хотелки пока две:
- Удобное управление сервисами из тарифного плана
- Считать аккаунтинг сервисов наработкой отдельных услуг родительской сессии

Если со вторым мы справимся, подменив в скрипте предобработки session-id на parent-session-id, записав Acct-Output-Packets и Acct-Input-Packets в новй атрибут и воспользовавшись RAD(<vcode>,<atrcode>,<prefix>) по доке, то с первым сложнее..

Вообще, ISG очень многогранная штука, мы используем только маленькую часть возможностей.
Автор:  skyb [ 11 авг 2010, 17:18 ]
Заголовок сообщения:  Re: Единый модуль трафика
А как у тебя организовано разлогивание сессий ??
Автор:  vdd [ 11 авг 2010, 18:26 ]
Заголовок сообщения:  Re: Единый модуль трафика
snark писал(а):
vdd писал(а):
фильтр на входе в нетфлоу-коллектор (ну или на выходе в сброс на диск) позволил бы нам не хранить на винтах кучу мусорного флоу.

собирать netflow только с/на нужные сети не выход?


А кто-то делает по другому? ;)
Автор:  Cromeshnic [ 11 авг 2010, 21:21 ]
Заголовок сообщения:  Re: Единый модуль трафика
skyb писал(а):
А как у тебя организовано разлогивание сессий ??

С этим проблема:
viewtopic.php?f=5&t=3811
Автор:  skyb [ 12 авг 2010, 05:43 ]
Заголовок сообщения:  Re: Единый модуль трафика
Нет, у нас то ее как раз и нет, у нас логаут работает....мне интересно как у тебя это реализовано...или это невопрос был, а описание проблемы? :?:
Автор:  Cromeshnic [ 12 авг 2010, 06:32 ]
Заголовок сообщения:  Re: Единый модуль трафика
Ну основная сессия рвется обычным образом, а сервисы тогда сами отваливаются.
Автор:  skyb [ 12 авг 2010, 07:09 ]
Заголовок сообщения:  Re: Единый модуль трафика
Обычным это как?? CoA ? snmp PoD или как (если под то какой именно) :)
Автор:  Cromeshnic [ 12 авг 2010, 07:25 ]
Заголовок сообщения:  Re: Единый модуль трафика
snmp
Код:
nas.inspector.class=bitel.billing.server.processor.SNMPNASConnectionInspectorType3
nas.inspector.snmp.kill.oid=1.3.6.1.4.1.9.9.150.1.1.3.1.5


А как у вас реализована работа с CoA? Как вы отключаете сервисы/сессии?
Автор:  skyb [ 12 авг 2010, 07:37 ]
Заголовок сообщения:  Re: Единый модуль трафика
Мож переместимся сюда?? у нас идет logout посылкой CoA запроса. Используем инспектор ISG (про который ты спрашивал)
Автор:  Cromeshnic [ 12 авг 2010, 07:38 ]
Заголовок сообщения:  Re: Единый модуль трафика
ок
Автор:  Администратор [ 12 авг 2010, 13:04 ]
Заголовок сообщения:  Re: Единый модуль трафика
To Cromeshnic:
Вы не могли бы с примерами сделать описание? Я по абстрактным "сервисам" не очень понимаю, что там может быть..
У нужно ли клиенту видеть трафик и деньги в разрезе по "сессиям"?
Может параллельно показывать сессии и параллельно отчёт по трафику?
А наработку, например, отображать по дням/часам. Эта завязка наработки на сессии всё сильно усложняет..
Автор:  Cromeshnic [ 12 авг 2010, 14:08 ]
Заголовок сообщения:  Re: Единый модуль трафика
Примеры серисов:

LOCAL1 - локальный трафик в 1МБит
LOCAL2 - 2 Мбита и т.п.

Аналогично
INET1
...

Другое:
REDIRECT
конфиг:
Цитата:
cisco-avpair=ip:traffic-class=out default drop
cisco-SSG-Service-Info=IREDIRECT
cisco-SSG-Service-Info=QU;56000;D;56000
cisco-avpair=ip:l4redirect=redirect to ip <ip расположения страницы reject-to-accept>
cisco-avpair=ip:traffic-class=in access-group name redirect-in priority 10
cisco-avpair=ip:traffic-class=in default drop
cisco-avpair=ip:traffic-class=out access-group name redirect-out priority 10

Сервис подключается при входе по правилу reject-to-accept

Есть ещё сервис REDIRECT-DNS, который редиректит любые днс запросы на наш днс, чтобы человек с прописанными левыми ns-серверами смог ресолвить адрес страницы для reject-to-accept.

В ТП каждому сервису сопоставлен набор атрибутов, его подключающий:
Цитата:
attrset.1.title=LOCAL1
attrset.1.attributes=cisco-SSG-Account-Info=ALOCAL1


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

Было бы здорово, если б у нас был один шаблон для сервиса: LOCAL, а конкретную скорость можно было задавать в соответствующем узле тарифного плана (а лучше любой набор атрибутов в виде параметр=значение).
Автор:  Amir [ 12 авг 2010, 14:18 ]
Заголовок сообщения:  Re: Единый модуль трафика
Радиус атрибутов в тарифе точно не будет. Будут абстракции, вроде ipn-овского правила, или тех же сервисов. При изменении набора этих правил/сервисов будет выполняться какое-то действие.
Автор:  Cromeshnic [ 12 авг 2010, 14:29 ]
Заголовок сообщения:  Re: Единый модуль трафика
Воот!

Чего-то такого и хочется. С произвольным текстовым конфигом узла тарифа вида "параметр=значение".
Автор:  Cromeshnic [ 12 авг 2010, 14:37 ]
Заголовок сообщения:  Re: Единый модуль трафика
На тему задания в тп нескольких сервисов одновременно у нас в хелпдеске висит обращение #1716 - тоже нужно будет что-то более универсальное делать для нового модуля.
Автор:  Cromeshnic [ 13 авг 2010, 09:05 ]
Заголовок сообщения:  Re: Единый модуль трафика
Тут у меня спрашивают, планируется ли в новом модуле "dynamic ip для DHCP с option82"?
Автор:  Amir [ 13 авг 2010, 12:31 ]
Заголовок сообщения:  Re: Единый модуль трафика
Смотря что именно это значит... Планы есть.
Но сложноватая система получается - надо по dhcp запросу нужно поднимать сессию, выдавать ip, потом отправлять шлюзу команду, чтобы с этого порта мог работать только выданный ip и следить, жива ли сессия по трафику и наличию последующих dhcp запросов, при закрытии сессии по неактивности - закрывать доступ на шлюзе - так?
Кстати, а разве ISG чего-то подобного не умеет? Т.е. прямой доступ с dhcp представлять radius аккаунтингом?
Автор:  skyb [ 13 авг 2010, 12:36 ]
Заголовок сообщения:  Re: Единый модуль трафика
Вообще можно, только надо продумывать как будет происходить аккаунтинг(я говорю про тот который будет без авторизации на портале)
Автор:  Администратор [ 17 авг 2010, 12:18 ]
Заголовок сообщения:  Re: Единый модуль трафика
To Cromeshnic про примеры сервисов:
А одновременно можно активировать например локал 1Мбит и локал 2Мбит?
То же про инет.
Эти сервисы они на текущую сессию только распространяются или как?
Портал позволяет там зависимости их между собой настраивать?
Автор:  Cromeshnic [ 17 авг 2010, 13:21 ]
Заголовок сообщения:  Re: Единый модуль трафика
Local1 и Local2 - взаимно исключающие сервисы
Экземпляр сервиса распространяется на текующую сессию, несколько сервисов может быть на одной сессии
Порталом хочется видет BG с конструктором тарифов и сервисов + Web, где клиент активирует опции
Автор:  borisk [ 17 авг 2010, 19:50 ]
Заголовок сообщения:  Re: Единый модуль трафика
Отличная задумка! Разработчики просто молодцы. Хотелось бы добавить в функционал DHCP.82 аналог RADIUS Reject-to-Accept. Я у себя пробовал реализовать два варианта:
1. В случае недостатка средств через блокировку шлюза высаживал пользователя в гостевой VLAN
2. Поделил пользовательский диапазон /24 пополам, выдавая рабочие адреса из нижнего диапазона и гостевые из верхнего.
Вот и хочется видеть подобное для DHCP.82, в каком либо варианте. Но, IMHO, второй вариант гораздо проще в реализации и именно на нем я в конечном итоге остановился в своей сети.
Автор:  skyb [ 17 авг 2010, 20:14 ]
Заголовок сообщения:  Re: Единый модуль трафика
можно просто в другой влан переводить...или я не так понял?
Автор:  borisk [ 17 авг 2010, 21:17 ]
Заголовок сообщения:  Re: Единый модуль трафика
Skyb, можно, я и писал что пробовал оба способа. Просто с точки зрения реализации, назначение другого адреса гораздо проще, чем перевод пользователя в другой VLAN. Поэтому я и остановился именно на выделении другого адреса. Опять таки есть реализации сети, где за одним управляемым портом стоит 4-8 портовый неуправляемый свитч, в этом случае перевод порта в другой VLAN не подходит, а вот смена адреса очень даже подходит.
Автор:  skyb [ 18 авг 2010, 05:08 ]
Заголовок сообщения:  Re: Единый модуль трафика
Мы полностью используем VLAN "забвения" :)
Автор:  Amir [ 18 авг 2010, 12:40 ]
Заголовок сообщения:  Re: Единый модуль трафика
Цитата:
4-8 портовый неуправляемый свитч, в этом случае перевод порта в другой VLAN не подходит, а вот смена адреса очень даже подходит.

А чем в этом случае поможет смена адреса? И к тому же DHCP не позволяет просто сменить адрес, можно только не продлять аренду.
Автор:  borisk [ 18 авг 2010, 16:15 ]
Заголовок сообщения:  Re: Единый модуль трафика
Поможет тем, что на ближайшем роутинг интерфейсе висит ACL, разрешающий одному диапазону лазать везде, а другому только до биллинга. Да, де факто адрес сменить нельзя, но как сделано у меня - пока шлюз открыт, то для пользователя в конфиге dhcp присутствует жесткая связка mac<->ip, соответственно выдается всегда постоянный адрес. Как только шлюз закрыт, то связка убирается и dhcp выдает адрес из гостевого диапазона.

P.S. Естественно для всяких любителей халявы dhcp snooping + arp anti-hack
Автор:  cvb [ 10 сен 2010, 16:26 ]
Заголовок сообщения:  Re: Единый модуль трафика
Строим новую сеть с нуля, по описанию очень заинтересовались BGBilling, но судя по всему поддержки IPv6 сейчас в нём нет никакой? Очень бы хотелось выдавать абонентам адреса по DHCPv6 на основании Option82, по нему же и шейпить анлимы. Netflow даже не планируем - нет смысла связываться. Возможен ли данный функционал в новой версии?

Обратил внимание на то, что в базе в CP1251 - хотелось бы всё-таки UTF-8.
Автор:  snark [ 10 сен 2010, 16:54 ]
Заголовок сообщения:  Re: Единый модуль трафика
кроме высказываний в духе "это модно/круто!" или "это задел на будующее, т.к IPv4 адреса скоро закончатся!" хотелось бы услышать _реальную_ необходимость внедрения IPv6 в провайдерской сети ... честно! я сколько ни пытался у наших (китайцев не в счет) строителей сетей жаждущих IPv6 узнать зачем оно им надо так внятного ответа и не получил ... может Вы сможете объяснить?
Страница 2 из 4 Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/