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

Единый модуль трафика
http://forum.bitel.ru/viewtopic.php?f=1&t=4352
Страница 3 из 4

Автор:  cvb [ 10 сен 2010, 17:08 ]
Заголовок сообщения:  Re: Единый модуль трафика

snark писал(а):
может Вы сможете объяснить?


Легко: адреса IPv4 получить проблематично в желаемом объёме, IPv6 - минимум /32. Никаких заделов на будущее. IPv4 через IPv6 УЖЕ будет бегать.

Автор:  snark [ 10 сен 2010, 17:44 ]
Заголовок сообщения:  Re: Единый модуль трафика

RFC 1918 уже отменили?

Автор:  cvb [ 10 сен 2010, 19:02 ]
Заголовок сообщения:  Re: Единый модуль трафика

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

Автор:  zzeka [ 22 сен 2010, 11:12 ]
Заголовок сообщения:  Re: Единый модуль трафика

Amir писал(а):
Смотря что именно это значит... Планы есть.
Но сложноватая система получается - надо по dhcp запросу нужно поднимать сессию, выдавать ip, потом отправлять шлюзу команду, чтобы с этого порта мог работать только выданный ip и следить, жива ли сессия по трафику и наличию последующих dhcp запросов, при закрытии сессии по неактивности - закрывать доступ на шлюзе - так?
Кстати, а разве ISG чего-то подобного не умеет? Т.е. прямой доступ с dhcp представлять radius аккаунтингом?


У нас появился проект в котором планируется авторизировать клиентов через DHСP+option82, при этом идентификатором клиента должен быть порт на определенном свиче.

В связи с чем нужен функционал для выдачи клиентам динамических адресов из пула при помощи DHCP.

Цитата:
потом отправлять шлюзу команду, чтобы с этого порта мог работать только выданный ip

Для этого на свичах есть функционал DHCP snooping, он как раз запоминает, какой IP какому MAC с какого порта был выдан, и соответственно не разрешает ходить пкетам не подходящим под все условия.


Цитата:
следить, жива ли сессия по трафику и наличию последующих dhcp запросов

Для этого можно использовать lease time.
Цитата:
при закрытии сессии по неактивности - закрывать доступ на шлюзе - так?

Опять же при неактивности клиента dhcp snooping не даст ему работать как только истек lease time.

Агрегацию клиентов планируется делать посредством L3 свичей, поэтому ISG тут неприменимо.
Ограничение скоростей хотелось бы реализовать посредством установки rate-limit на порту свича через SNMP.
Есть еще хотелка чтобы DHCP поддерживал DHCP LEASEQUERY protocol (RFC4388) для интеграции со сторонними сервисами.

Так же на будущее хотелось бы иметь поддержку ipv6..


PS: Есть похожая тема.

Автор:  Cromeshnic [ 28 сен 2010, 11:06 ]
Заголовок сообщения:  Re: Единый модуль трафика

Интересно, на каком этапе процесс?
Вообще, какой roadmap сейчас в развитии биллинга?

Автор:  Администратор [ 28 сен 2010, 15:28 ]
Заголовок сообщения:  Re: Единый модуль трафика

Цитата:
Про IPv6 предлагаю общаться ..

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

Автор:  Администратор [ 28 сен 2010, 15:44 ]
Заголовок сообщения:  Re: Единый модуль трафика

Цитата:
Вообще, какой roadmap сейчас в развитии биллинга?

Исключая мелкие текущие модификации примерно так.
1) Единый модуль трафика. IPv6, ISG (и Juniper ERX), DHCP.82 + динамика и т.п. Резервирование шлюзов авторизации (RADIUS).
2) Единый модуль голоса. Возможность переобработки логов как RADIUS так и CDR.
3) Перевод основных таблиц на транзакционный режим. InnoDB как дефолтовый движок для таблиц, MyIsam как исключение для различных логов.
Ещё изучается вопрос миграции на Postgre, но пока тесты не особо впечатлили. В 9.0 хоть появилась быстрая штатная реплика, посмотрим дальше, сейчас вон оракл MySQL что-то улучшил :)
Транзакционный режим работы акшенов сервера, для целостности БД в случае сбоя по середине акшена.
Для этого нужно переделать всё API на выброс исключений наружу.
4) Движок кэша. Есть задумка кэшировать все договора, их параметры и учётные данные (логины/пароли) в памяти для более быстрого получения при необходимости.
Возможно потребуется делать распределённый кэш. К общему кэшу смогут обратиться все приложения биллинга по JMS.
И ещё возможно специализированные кэши с учётными данными на серверах авторизации, можно было бы быстро делать проверку логинов-паролей а потом
запрашивать центральный кэш для предоставления договора, его тарифов и т.п.
5) Распределение БД. Собственно учётные данные будут лежать в единой транзакционной БД + кэш обеспечивающий быстрый доступ к ним.
Различные логи, балансы, сессии - разнесены по разным БД. Но тут нужно подумать. Возможно, проще сделать различные таблицы либо партиции таблиц в единой БД,
разделив по договорам. Возможно проще вообще сделать несколько экземпляров модулей и реализовать текущими средствами.
При разделении БД возникают проблемы с отчётами, с джойнами.

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

P.S. Если есть ещё вопросы по роадмапу - поднимите отдельную тему, чтобы путанницы не было. А оттуда делать ссылки на темы с конкретными обсуждениями что ли.. А ту главную можно прилепить.

Автор:  snark [ 28 сен 2010, 17:52 ]
Заголовок сообщения:  Re: Единый модуль трафика

Администратор писал(а):
Если есть ещё вопросы по роадмапу - поднимите отдельную тему, чтобы путанницы не было.
сделано!

Автор:  Amir [ 19 окт 2010, 19:33 ]
Заголовок сообщения:  Re: Единый модуль трафика

Набросок скрипта для типа устройства (шлюза), который будет отвечать за синхронизацию. В данном случае тип устройства - Radius.
Код:
import java.util.*;
import java.net.*;

import ru.bitel.bgbilling.kernel.network.radius.*;
import ru.bitel.bgbilling.modules.inet.api.common.bean.*;
import ru.bitel.bgbilling.modules.inet.radius.*;

deviceParams = device.getConfigParameterMap();

nasHost = deviceParams.get( "nas.radius.host", device.getHost() );
nasHost = InetAddress.getByName( nasHost );
nasHostBytes = nasHost.getAddress();
nasPort = deviceParams.getInt( "nas.radius.port", 0 );

nasIdentifier = deviceParams.get( "nas.identifier", null );
nasSecret = deviceParams.get( "nas.secret", device.getSecret() ).getBytes();

nasCoaFixedAttributeSet = deviceParams.get( "nas.radius.coa.attributes", null );
if( Utils.notBlankString( nasCoaFixedAttributeSet ) )
{
   nasCoaFixedAttributeSet = RadiusAttributeSet.newRadiusAttributeSet( nasCoaFixedAttributeSet );
}
else
{
   nasCoaFixedAttributeSet = null;
}

nasPodFixedAttributeSet = deviceParams.get( "nas.radius.pod.attributes", null );
if( Utils.notBlankString( nasPodFixedAttributeSet ) )
{
   nasPodFixedAttributeSet = RadiusAttributeSet.newRadiusAttributeSet( nasPodFixedAttributeSet );
}
else
{
   nasPodFixedAttributeSet = null;
}

pod = new PodSupport( nasHost, nasPort, nasSecret );

public void finalize()
{
   if( pod != null )
   {
      pod.destroy();
   }
}

public void init() {}
public void destroy() {}

public Object serviceCreate( service )
{
}

public Object serviceModify( service )
{
   session = service.getSession();
   if( session == null )
   {
      return true;
   }

   oldContractServ = service.getOldContractServ();
   newContractServ = service.getNewContractServ();

   if( service.newState == InetContractServ.STATE_DISABLE )
   {
      return sessionKill( session );
   }

   optionsToAdd = event.getOptionsToAdd();
   optionsToRemove = event.getOptionsToRemove();

   if( optionsToAdd.size() > 0 || optionsToRemove.size() > 0 )
   {
      return sessionModify( session, service.serviceSessions, optionsToRemove, optionsToAdd );
   }

   return true;
}

public Object serviceCancel( service )
{
   session = service.getSession();
   if( session == null )
   {
      return true;
   }

   return sessionKill( session );
}

void preparePacket( packet, session )
{
   packet.setIntAttribute( -1, RadiusDictionary.NAS_Port, session.getDevicePort() );
   packet.setStringAttribute( -1, RadiusDictionary.Acct_Session_Id, session.getAcctSessionId() );
   packet.setStringAttribute( -1, RadiusDictionary.User_Name, session.getUsername() );
   packet.setAttribute( new RadiusAttribute.RadiusAttributeIpAddr( -1, RadiusDictionary.Framed_IP_Address, Utils.convertBytesToInt( session.getInetAddressBytes() ) ) );
   packet.setAttribute( new RadiusAttribute.RadiusAttributeIpAddr( -1, RadiusDictionary.NAS_IP_Address, Utils.convertBytesToInt( nasHostBytes ) ) );
   packet.setStringAttribute( -1, RadiusDictionary.NAS_Identifier, nasIdentifier );
}

Object sessionKill( session )
{
   packet = pod.createDisconnectRequest();
   preparePacket( packet, session )

   if( nasPodFixedAttributeSet != null )
   {
      packet.addAttributes( nasPodFixedAttributeSet );
   }

   return pod.send( packet );
}

Object sessionModify( session, serviceSessions, optionsToRemove, optionsToAdd )
{
   packet = pod.createModifyRequest();
   preparePacket( packet, session )

   for( Integer option : optionsToRemove )
   {
      // TODO:
   }

   for( Integer option : optionsToAdd )
   {
      // TODO:       
   }

   if( nasCoaFixedAttributeSet != null )
   {
      packet.addAttributes( nasCoaFixedAttributeSet );
   }

   return pod.send( packet );
}

Автор:  Cromeshnic [ 20 окт 2010, 06:24 ]
Заголовок сообщения:  Re: Единый модуль трафика

Мм, интересно :)
А что такое service здесь? options? Каковы их отношения друг с другом, с сессией, с тарифными опциями?

finalize, init, destroy - это методы какого класса/интерфейса?

Автор:  skyb [ 20 окт 2010, 12:17 ]
Заголовок сообщения:  Re: Единый модуль трафика

http://inetcore.com/project/ipv4ec/index_ru.html
мы все умрем О_О :facepalm:

Автор:  Amir [ 20 окт 2010, 12:40 ]
Заголовок сообщения:  Re: Единый модуль трафика

Цитата:
Мм, интересно
А что такое service здесь? options? Каковы их отношения друг с другом, с сессией, с тарифными опциями?

finalize, init, destroy - это методы какого класса/интерфейса?

service - просто обертка, которая будет содержать oldContractServ/newContractServ - старое и новое значение логина/диапазона адресов, а также вспомогательные значения.
options - опции модуля inet. В тарифе в зависимости от времени, наработки, тарифных опций будут прописываться опции модуля. При изменении набора опций модуля будет вызываться serviceModify().
При первичной инициализации скрипт интерпретируется и может храниться в таком виде до изменения скрипта. При изменении скрипта перед использованием нового в старом вызывается finalize() для того чтобы можно было освободить постоянные локальные ресурсы.
При появлении заданий на создание (логин добавили), изменение, отмену (логин удалили) сначала вызывается init() - здесь, например, может быть инициализация ssh соединения, затем могут вызваться какое-то количество раз serviceCreate/Modify/Cancel(), по окончании синхронизации - destroy().
Т.е. интерпретация и вызов finalize() происходит один раз для скрипта, init() и destroy() один раз за синхронизацию, serviceCreate/Modify/Cancel() - может вызваться много раз между init() и destroy().

Автор:  Amir [ 20 окт 2010, 12:41 ]
Заголовок сообщения:  Re: Единый модуль трафика

Цитата:
мы все умрем О_О

Может еще успеем... :)

Автор:  skyb [ 20 окт 2010, 12:53 ]
Заголовок сообщения:  Re: Единый модуль трафика

Amir писал(а):
Цитата:
мы все умрем О_О

Может еще успеем... :)

биллинг допилить?
я надеюсь что успеете

Автор:  Cromeshnic [ 20 окт 2010, 13:44 ]
Заголовок сообщения:  Re: Единый модуль трафика

Круто.
1) Т.е. service - это название обобщенной сущности нового модуля (как login для dialup или user_range для ipn)?
2) Т.е. опции - некий набор подключенных в данный момент абстрактных фич у клиента. Логика действия опций описывается только в таких скриптах для устройств? В смысле, не будет никаких hardcoded обработчиков для стандартных случаев? Здорово, если так. Уже чешутся руки завести некоторые костыли в виде опций :) Опции - это просто флаги для service или имеют date1 и date2? На первый взгляд не должны бы..
3) Опции модуля и тарифные опции - разные вещи, что есть хорошо.
4) Как будет выглядеть конфигурирование тарифных опций в тарифном плане в ветке нового модуля? Как разрулили проблему с невозможностью задать произвольный набор тарифных опций? (сейчас приходится прописывать все возможные сочетания)

Автор:  Cromeshnic [ 12 ноя 2010, 12:26 ]
Заголовок сообщения:  Re: Единый модуль трафика

Как прогресс? :D

Автор:  Администратор [ 12 ноя 2010, 12:48 ]
Заголовок сообщения:  Re: Единый модуль трафика

Идёт. Коллектор вроде почти доделали, поддержку нетфлоу9 сочиняем..

Автор:  vdd [ 24 ноя 2010, 12:17 ]
Заголовок сообщения:  Re: Единый модуль трафика

Еще применения для пре/пост-процессинга флоу: отсев нежелательного трафика из наработки (и из отчета и детализации). Тема в форуме:http://forum.bgbilling.ru/viewtopic.php?f=7&t=4661

Автор:  borisk [ 21 дек 2010, 13:55 ]
Заголовок сообщения:  Re: Единый модуль трафика

1. Хочется узнать прогресс
2. В текущей версии IPN есть особенность, что тарифные опции применяются только на границе часа, что не очень удобно. Будет ли эта проблема решена в новом модуле?

Автор:  snark [ 21 дек 2010, 18:41 ]
Заголовок сообщения:  Re: Единый модуль трафика

borisk писал(а):
Хочется узнать прогресс

да, да, да!

Автор:  skyb [ 21 дек 2010, 19:04 ]
Заголовок сообщения:  Re: Единый модуль трафика

snark писал(а):
borisk писал(а):
Хочется узнать прогресс

да, да, да!

))))))))
согласен, но он будет на 5.2 :)

Автор:  borisk [ 29 дек 2010, 20:52 ]
Заголовок сообщения:  Re: Единый модуль трафика

В DHCPD надо бы добавить возможность идентификации шлюза по MAC адресу, а не только по IP. Схема - несколько коммутаторов находятся в общем VLAN и сводятся на один L3, который выступает как dhcp relay и прозрачно пропускает Option 82. Коммутаторы access уровня несколько туповаты, и в AgentID передают свой MAC, и изменить это ни как нельзя.

Автор:  skyb [ 29 дек 2010, 22:21 ]
Заголовок сообщения:  Re: Единый модуль трафика

borisk писал(а):
В DHCPD надо бы добавить возможность идентификации шлюза по MAC адресу, а не только по IP. Схема - несколько коммутаторов находятся в общем VLAN и сводятся на один L3, который выступает как dhcp relay и прозрачно пропускает Option 82. Коммутаторы access уровня несколько туповаты, и в AgentID передают свой MAC, и изменить это ни как нельзя.

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

Автор:  borisk [ 30 дек 2010, 10:27 ]
Заголовок сообщения:  Re: Единый модуль трафика

MAC чего, коммутатора? Я думаю хранить его в конфигурации самого шлюза, что-то вроде switch.mac=.....
Задвоения - да, такое может быть, но не боюсь, так как это всплывет уже на моменте монтажа оборудования (начнет глючить управление). Но даже если и не всплывет - то проблема решаемая и единичная :)

Если вы про маки пользователей, то как раз от них я и хочу отказаться и авторизовать по коммутатору и порту. У нас правило - один пользователь/один порт.

Автор:  mazay-d [ 12 янв 2011, 15:03 ]
Заголовок сообщения:  Re: Единый модуль трафика

Ну вот, праздники закончились :facepalm: , как дела с модулем, когда тестить мона будет? :)

Автор:  Администратор [ 24 янв 2011, 14:11 ]
Заголовок сообщения:  Re: Единый модуль трафика

Модуль начали тестировать не стенде разработчика. Пока режим DHCP.82 с динамической выдачей адресов. Ещё дали стенд с Cisco ISG, но пока не добрались.
Как только появятся какие-то рабочие связки - обязательно выложим.
Просто очень всё изменилось от 5.1, со сборкой даже много времени потратили.

Автор:  borisk [ 24 янв 2011, 15:30 ]
Заголовок сообщения:  Re: Единый модуль трафика

Скажите, а там учтена ситуация когда в AgentID передается не IP, а MAC коммутатора? И вообще ситуация, когда AgentID может быть любым?

Автор:  Администратор [ 25 фев 2011, 12:14 ]
Заголовок сообщения:  Re: Единый модуль трафика

Да, учтена.

Автор:  msh [ 26 фев 2011, 03:44 ]
Заголовок сообщения:  Re: Единый модуль трафика

skn писал(а):
пока не решено, но скорее всего просто будет обмен лицензий по формуле: diaup + ipn = inet (новый модуль)

а с лицензиями от 4.0 чего будет?
или надо пока можно 5.0 покупать, что бы не остаться с необмениваемыми дицензиями ipn от 4.0?

Автор:  dimOn [ 28 фев 2011, 13:00 ]
Заголовок сообщения:  Re: Единый модуль трафика

ну модуля inet в любом случае не будет на 4.x

Страница 3 из 4 Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/