forum.bitel.ru :: Просмотр темы - Выдача динамического реального ИП адреса в VLAN

кто должен выдавать? кому? какой тип подключения?

Выдавать должен DHCP биллинга.

Если DHCP будет работать в связке со шлюзами DLink , то необходимо добавить такие настройки для сервера DHCP.

Код:

processor.class=bitel.billing.server.ext.dhcp.DHCPRelayProcessor

#Номер субопции в Option 82, в которой  хранится vlan клиента(нумерация с 1)
dhcp.82.key.option.code=1
#Позиция(номер байта) внутри субопции, в которой  хранится порт клиента(нумерация с 0).
dhcp.82.key.position=5

После синхронизации клиента на шлюзе DLINK будет вызвана синхронизация клиента на BGDhcpIPN, а именно порт коммутатора: IP адрес.

При подключении клиента, он отправит запрос на получение IP адреса, коммутатор, при включённом и настроенном DHCP Relay, добавив данные RelayAgent Options, перенаправит запрос на DHCP сервер BGDhcpIPN, который по ip шлюза и порту клиента, указанному в RelayAgent Options, выдаст IP адрес.

То есть абонент включает компьютер, получает динамический реальный ИП адрес и начинает работу. Тарифы - с подсчетом трафика. Биллинг должен считать трафик, включать-выключать абонента.

Вот это самое НО и встает боком - нужны именно динамические реальные ИПы...

Наслышаны о последствиях выдачи абонентам статики - якобы после отключения абонентом компа трафик продолжает сыпаться на его реальный ИП адрес, и потом абонент предъявляет претензии по несоответствию статистики... Это правда? Если да, то вот чем обусловлено наша необходимость выдавать абонентам динамические адреса. Если б можно было выдавать серые адреса, то нас бы устроил вариант статического ИП адреса, там такой проблемы с несоответствием нет...

Или мы заморачиваемся?

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

Или мы заморачиваемся?

nur16 писал(а):

Вот это самое НО и встает боком - нужны именно динамические реальные ИПы...

snark писал(а):

тут уже как-то было обсуждение на предмет динамических адресов, но пока в этом направлении тихо

Так, понятно.. Примерно сколько будет стоить добавление этой функции?

nur16 писал(а):

snark писал(а):

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

думаю если сделать:

Код:

инет --- головной роутер --- шлюз1 --- место сбора netflow --- сеть --- шлюз2 --- клиент

шлюз2 служит ограничителем доступа в сеть/нет, при выдаче адреса открывать доступ адресу на "шлюз1" чтобы в netflow появились записи для этого хоста, ну а при истечении времени Т = проделению лиза * Х (вычислется эмпирически в зависимости от времени аренды) - закрывать доступ адресу и тогда записей о нем не будет, но это тааакой ахтунг ... проще чтоб юзеры смирились с паразитным траффиком

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

nur16 писал(а):

snark писал(а):

т.е. вариант статического NAT не рассматривается в принципе?

Вы имеете в виду серые адреса или реальные адреса?
Заранее извиняюсь, если вопрос неправилен. Я не слышал, что
можно NAT-ить реальные адреса.

nur16 писал(а):

Или мы заморачиваемся?

snark писал(а):

угу

Примерно сколько будет стоить добавление этой функции?

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

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

Вы имеете в виду серые адреса или реальные адреса?

Я не слышал, что можно NAT-ить реальные адреса.

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

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

думаю если сделать:

Код:

инет --- головной роутер --- шлюз1 --- место сбора netflow --- сеть --- шлюз2 --- клиент

Автор:	nur16 [ 27 авг 2009, 13:55 ]
Заголовок сообщения:	Выдача динамического реального ИП адреса в VLAN
Нигде не нашел такого. БГбиллинг такое умеет? Спасибо.

Автор:	snark [ 27 авг 2009, 16:14 ]
Заголовок сообщения:
кто должен выдавать? кому? какой тип подключения?

Автор:	nur16 [ 28 авг 2009, 14:25 ]
Заголовок сообщения:
snark писал(а): кто должен выдавать? кому? какой тип подключения? 1. Выдавать должен DHCP биллинга. 2. Абоненту, подключенному к Ethernet порту управляемого коммутатора, этот порт находится в одном из VLAN-ов. 3. Авторизации (то есть применения протоколов PPPoE, VPN) нет. То есть абонент включает компьютер, получает динамический реальный ИП адрес и начинает работу. Тарифы - с подсчетом трафика. Биллинг должен считать трафик, включать-выключать абонента. Заранее спасибо.

Автор:	Heggi [ 28 авг 2009, 16:33 ]
Заголовок сообщения:
Помоему тема не к тому модулю.. Модуль IPN такое умеет

Автор:	snark [ 28 авг 2009, 16:40 ]
Заголовок сообщения:
nur16 писал(а): Выдавать должен DHCP биллинга. модуль ipn имеет dhcp сервер (тыц!) тут описано как это работает со свичами D-Link: мануал писал(а): Если DHCP будет работать в связке со шлюзами DLink , то необходимо добавить такие настройки для сервера DHCP. Код: processor.class=bitel.billing.server.ext.dhcp.DHCPRelayProcessor #Номер субопции в Option 82, в которой хранится vlan клиента(нумерация с 1) dhcp.82.key.option.code=1 #Позиция(номер байта) внутри субопции, в которой хранится порт клиента(нумерация с 0). dhcp.82.key.position=5 После синхронизации клиента на шлюзе DLINK будет вызвана синхронизация клиента на BGDhcpIPN, а именно порт коммутатора: IP адрес. При подключении клиента, он отправит запрос на получение IP адреса, коммутатор, при включённом и настроенном DHCP Relay, добавив данные RelayAgent Options, перенаправит запрос на DHCP сервер BGDhcpIPN, который по ip шлюза и порту клиента, указанному в RelayAgent Options, выдаст IP адрес. обратите внимание на выделенный текст nur16 писал(а): То есть абонент включает компьютер, получает динамический реальный ИП адрес и начинает работу. Тарифы - с подсчетом трафика. Биллинг должен считать трафик, включать-выключать абонента. сосбно этим модуль ipn и занимается, с одним единственным НО - ЕМНИП там нет поддержки _динамических_ IP, только статика, а в остальном модуль полностью подходит под задачу ... BTW, Вы не в том разделе вопрос задали

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

Выдача динамического реального ИП адреса в VLAN http://forum.bitel.ru/viewtopic.php?f=7&t=2797	Страница 1 из 1

Автор:	nur16 [ 28 авг 2009, 19:13 ]
Заголовок сообщения:
Так, сорри за то, что написал первоначальный текст не в том разделе, не сообразил Вот это самое НО и встает боком - нужны именно динамические реальные ИПы... Про возможности модуля выдавать статику мы в курсе... Наслышаны о последствиях выдачи абонентам статики - якобы после отключения абонентом компа трафик продолжает сыпаться на его реальный ИП адрес, и потом абонент предъявляет претензии по несоответствию статистики... Это правда? Если да, то вот чем обусловлено наша необходимость выдавать абонентам динамические адреса. Если б можно было выдавать серые адреса, то нас бы устроил вариант статического ИП адреса, там такой проблемы с несоответствием нет... Или мы заморачиваемся?

Автор:	snark [ 28 авг 2009, 19:43 ]
Заголовок сообщения:
nur16 писал(а): Вот это самое НО и встает боком - нужны именно динамические реальные ИПы... тут уже как-то было обсуждение на предмет динамических адресов, но пока в этом направлении тихо nur16 писал(а): Наслышаны о последствиях выдачи абонентам статики - якобы после отключения абонентом компа трафик продолжает сыпаться на его реальный ИП адрес, и потом абонент предъявляет претензии по несоответствию статистики... Это правда? Если да, то вот чем обусловлено наша необходимость выдавать абонентам динамические адреса. Если б можно было выдавать серые адреса, то нас бы устроил вариант статического ИП адреса, там такой проблемы с несоответствием нет... Или мы заморачиваемся? да, то что на отключенный комп трафик всеравно сыпется - это правда, при этом не важно какой метод доступа используется - это особенность роутинга (апстрим шлет вам все пакеты направленные в вашу сеть), но в теории это можно побороть думаю если сделать: Код: инет --- головной роутер --- шлюз1 --- место сбора netflow --- сеть --- шлюз2 --- клиент шлюз2 служит ограничителем доступа в сеть/инет, при выдаче адреса открывать доступ адресу на "шлюз1" чтобы в netflow появились записи для этого хоста, ну а при истечении времени Т = проделению лиза * Х (вычислется эмпирически в зависимости от времени аренды) - закрывать доступ адресу и тогда записей о нем не будет, но это тааакой ахтунг ... проще чтоб юзеры смирились с паразитным траффиком nur16 писал(а): Если б можно было выдавать серые адреса, то нас бы устроил вариант статического ИП адреса, там такой проблемы с несоответствием нет... т.е. вариант статического NAT не рассматривается в принципе? nur16 писал(а): Или мы заморачиваемся? угу

Автор:	nur16 [ 29 авг 2009, 21:54 ]
Заголовок сообщения:
snark писал(а): nur16 писал(а): Вот это самое НО и встает боком - нужны именно динамические реальные ИПы... snark писал(а): тут уже как-то было обсуждение на предмет динамических адресов, но пока в этом направлении тихо Так, понятно.. Примерно сколько будет стоить добавление этой функции? nur16 писал(а): Наслышаны о последствиях выдачи абонентам статики - якобы после отключения абонентом компа трафик продолжает сыпаться на его реальный ИП адрес, и потом абонент предъявляет претензии по несоответствию статистики... Это правда? Если да, то вот чем обусловлено наша необходимость выдавать абонентам динамические адреса. Если б можно было выдавать серые адреса, то нас бы устроил вариант статического ИП адреса, там такой проблемы с несоответствием нет... snark писал(а): да, то что на отключенный комп трафик всеравно сыпется - это правда, при этом не важно какой метод доступа используется - это особенность роутинга (апстрим шлет вам все пакеты направленные в вашу сеть), но в теории это можно побороть думаю если сделать: Код: инет --- головной роутер --- шлюз1 --- место сбора netflow --- сеть --- шлюз2 --- клиент шлюз2 служит ограничителем доступа в сеть/нет, при выдаче адреса открывать доступ адресу на "шлюз1" чтобы в netflow появились записи для этого хоста, ну а при истечении времени Т = проделению лиза * Х (вычислется эмпирически в зависимости от времени аренды) - закрывать доступ адресу и тогда записей о нем не будет, но это тааакой ахтунг ... проще чтоб юзеры смирились с паразитным траффиком Сразу вопросы - есть ли примерные цифры, сколько такого паразитного трафа сыплется в процентном соотношении от полезного? В вашей схеме шлюз1 и место сбора netflow - это два разных маршрутизатора или может быть один? Принципиально схема не выглядит фантастически сложной или неразумной... nur16 писал(а): Если б можно было выдавать серые адреса, то нас бы устроил вариант статического ИП адреса, там такой проблемы с несоответствием нет... snark писал(а): т.е. вариант статического NAT не рассматривается в принципе? Вы имеете в виду серые адреса или реальные адреса? Заранее извиняюсь, если вопрос неправилен. Я не слышал, что можно NAT-ить реальные адреса. nur16 писал(а): Или мы заморачиваемся? snark писал(а): угу Весь понт с этими торрентами... Для эффективной работы на нем нужны реальные адреса, если пускать через NAT, заканчиваются какие-то буфера на трекерах и абоненты направляют жалобы в техподдержку.

Автор:	snark [ 31 авг 2009, 13:05 ]
Заголовок сообщения:
nur16 писал(а): Примерно сколько будет стоить добавление этой функции? это к разработчикам ... я всего лишь пользователь nur16 писал(а): В вашей схеме шлюз1 и место сбора netflow - это два разных маршрутизатора или может быть один? Принципиально схема не выглядит фантастически сложной или неразумной... если устр-во считает netflow _после_ ACL, то тогда одно, а если _до_ - то тогда лучше 2 разных устройства, поэтому я и нарисовал 2 устройства ("шлюз1" и "место сбора netflow"), т.к. все сильно зависит от применяемого железа ... nur16 писал(а): Принципиально схема не выглядит фантастически сложной или неразумной... Вы знаете, в случае с БГБ любая схема упирается ровно в то что надо придумать как все будет работать, найти нужные события в БГБ и написать скрипты ... правда пока никому не удалось заставить бегать БГБ за пивом, но я думаю что разработчики просто не афишируют как это сделать nur16 писал(а): Вы имеете в виду серые адреса или реальные адреса? и серые и реальные ... я имел ввиду NAT при котором некий уникальный внутренний адрес мапится на некий внешний и наоборот, т.е. достигается связка: Код: внешний адрес == внутренний адрес говоря языком циски: Код: ip nat inside source static 192.168.0.254 1.1.1.254 где 192.168.0.254 - внутренний адрес, а 1.1.1.254 - некий белый IP адрес nur16 писал(а): Я не слышал, что можно NAT-ить реальные адреса. можно nur16 писал(а): Весь понт с этими торрентами... Для эффективной работы на нем нужны реальные адреса торренты прекрасно работают через NAT nur16 писал(а): если пускать через NAT, заканчиваются какие-то буфера на трекерах и абоненты направляют жалобы в техподдержку. буфера заканчиваются не на трекерах, а на NAT железке именно для того чтобы торренты не "убивали" NAT-ер и используют ограничение на кол-во соединений ...

Автор:	Yellowfox [ 31 авг 2009, 16:18 ]
Заголовок сообщения:
Еще dhcp по виланам может ICS dhcp сервер раздавать. Это в случае если дхсп сервер и терминирование вланов на одной машине - если на разных не пробовал. А в биллинге заводите клиентов по ip.

Автор:	nur16 [ 05 сен 2009, 01:34 ]
Заголовок сообщения:
snark писал(а): да, то что на отключенный комп трафик всеравно сыпется - это правда, при этом не важно какой метод доступа используется - это особенность роутинга (апстрим шлет вам все пакеты направленные в вашу сеть), но в теории это можно побороть думаю если сделать: Код: инет --- головной роутер --- шлюз1 --- место сбора netflow --- сеть --- шлюз2 --- клиент шлюз2 служит ограничителем доступа в сеть/нет, при выдаче адреса открывать доступ адресу на "шлюз1" чтобы в netflow появились записи для этого хоста, ну а при истечении времени Т = проделению лиза * Х (вычислется эмпирически в зависимости от времени аренды) - закрывать доступ адресу и тогда записей о нем не будет, но это тааакой ахтунг ... проще чтоб юзеры смирились с паразитным траффиком Подумав, решили повторять эту схему, с небольшими изменениями, но в целом идея остается именно такой... Оказалось, что у нас сеть уже содержит все эти компоненты, только нужно настроить допфункции. Спасибо всем за ответы, а особенно snark-у.

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