[st_re]

Подъехал к бензоколонке. Вставил шланг, нажал чтобы лилось до отсечки. Выдернул шланг из бака и кинул на землю. Пошел качать права к "Королеве бензоколонки" что бизин в машину не текет, а считается ...... ;)

 

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

Изменено 14 августа, 2009 пользователем st_re

[Yuka]

martin74

st_re

 

 

Ну для таких ;) можно конец сесии обрабатывать если ты кабель вытачил состояние прота изменилось, и биллинг перестаёт считать, решит это такую проблему?

 

[zoro]

:) сталкнулся с такими-же потребностями... нетап- отказался делать это и считает это странным...

бг-биллинг может такое сделать только за деньги...

с циской и ISG пока сильно не занимался,

[pchol]

Может быть здесь есть необходимость в cisco dhcp accounting ?

[Stak]

Для таких фишек циска придумала ISG. Кстати аналогичные примочки есть и у других вендоров - джунипера например.

 

Как это работает на примере циски:

1. Свич доступа или агрегации вставляет опт82 в дхцп запрос, и релеит его на дхцп-сервер.

2. Дхцп-сервер (циска с ISG) выдаёт адрес из пула, и создаёт сессию, ПОСЛЕ чего ломится на радиус, используя в качестве логина юзера информацию из опт82.

3. Радиус (он же биллинг) отвечает акцесс-ацептом или отлупом, при акцесс-ацепте - выдаёт параметры сессии (политики, назначенные на юзера).

4. В процессе активности сессии - по ней на радиус отсылается аккоунтинг.

5. Когда сессия завершается ( дхцп релис или по таймауту, или по пинку с радиуса через PoD) - по ней на радиус отсылается аккоунтинг-стоп.

 

На жунипере ЕRХ - все примерно так же, только можно ещё и адрес через радиус назначить вроде.

[zoro]

Для таких фишек циска придумала ISG. Кстати аналогичные примочки есть и у других вендоров - джунипера например.

 

Как это работает на примере циски:

1. Свич доступа или агрегации вставляет опт82 в дхцп запрос, и релеит его на дхцп-сервер.

2. Дхцп-сервер (циска с ISG) выдаёт адрес из пула, и создаёт сессию, ПОСЛЕ чего ломится на радиус, используя в качестве логина юзера информацию из опт82.

3. Радиус (он же биллинг) отвечает акцесс-ацептом или отлупом, при акцесс-ацепте - выдаёт параметры сессии (политики, назначенные на юзера).

4. В процессе активности сессии - по ней на радиус отсылается аккоунтинг.

5. Когда сессия завершается ( дхцп релис или по таймауту, или по пинку с радиуса через PoD) - по ней на радиус отсылается аккоунтинг-стоп.

 

На жунипере ЕRХ - все примерно так же, только можно ещё и адрес через радиус назначить вроде.

А циске принудительно адрес выдать нельзя??

[Stak]

Неа. Низзя. Она сначала адрес выдаёт, а потом у радиуса спрашивает.

Но это для Л3-коннектед субскрайберов, для Л2-коннектед вроде бы что-то можно сделать. Но тут я не копал глубоко, не было нужды.

[Stak]

Пруфлинк:

http://www.cisco.com/en/US/docs/ios/12_2sb....html#wp1114248

IP Sessions

 

For IP sessions, ISG supports the following methods of IP address assignment:

 

•Static IP addresses

 

If a subscriber's static IP address is configured correctly for the service domain, ISG does not have to be involved in the assignment of an IP address for the subscriber.

 

•DHCP

 

If DHCP is being used to assign IP addresses, and the IP address that is assigned by DHCP is correct for the service domain, ISG does not have to be involved in the assignment of an IP address for the subscriber.

 

If the IP address that is assigned by DHCP is not correct for the service domain, or if the domain changes because of a VRF transfer, ISG can be configured to influence the DHCP IP address assignment.

 

The following conditions must be met in order for ISG to influence DHCP IP address assignment:

 

–The subscriber must be Layer 2 connected.

 

–The ISG device must be in the path of DHCP requests by serving as a DHCP server or relay.

 

–Subscribers must not have statically configured IP addresses.

 

For deployments that support it, DHCP is the recommended method of IP address assignment.

[Targetlink]

:) сталкнулся с такими-же потребностями... нетап- отказался делать это и считает это странным...

бг-биллинг может такое сделать только за деньги...

с циской и ISG пока сильно не занимался,

Мы тоже повозились с прикручиванием к UTM DHCP 82, но так как спецов толком нет, работало все довольно криво

и лично у меня вообще руки опустились. Тут и на нетаповском форуме все так лихо обсуждают как они и то прикрутили

и это дописали, чуть ли не дураком себя чувствую :), но решение кажись нашли в обход...

Так как основной целью приследовалось управление абонентами на портах, взяли на Try&Buy софтину от framesoft.ru.

Наши почти все вопросы решились, но есть ряд коммутаторов, которые они пока не держат (дописать коммутаторы самим

при помощи api опять-же некому), так что просим доработок и тянем из них жилы... По результатам, если кому интересно - отпишусь.

Изменено 18 августа, 2009 пользователем Targetlink

[Pyzzle]

вот пример использования Option 82 в связке DHCP - Биллинг - Управление свитчами.

 

http://www.pyzzle.ru/doc/fuzzy_mac_ip/

 

[jp1111]

вот пример использования Option 82 в связке DHCP - Биллинг - Управление свитчами.

Коллеги поясните пожалуйста вот что. Если в netpatch е для ISC DHCP нет эккаунтинга, то какое отношение данная Вами ссылка имеет к поднятой проблеме, а именно: И выдача динамического IP абоненту, пусть даже и через RADIUS И одновременная тарификация трафика по IP. Средствами чего в данном случае организована сессия от назначения адреса до DHCP lease ?

 

Для статического выделения адреса по DHCP при опции 82, решение подходит, сами такое используем, в тандеме с привязкой абонента к порту через LBInventory.

[Pyzzle]

вот пример использования Option 82 в связке DHCP - Биллинг - Управление свитчами.

Коллеги поясните пожалуйста вот что. Если в netpatch е для ISC DHCP нет эккаунтинга, то какое отношение данная Вами ссылка имеет к поднятой проблеме, а именно: И выдача динамического IP абоненту, пусть даже и через RADIUS И одновременная тарификация трафика по IP. Средствами чего в данном случае организована сессия от назначения адреса до DHCP lease ?

Новый IP выдается Radius-ом, и радиус при этом прописывает этот IP в биллинге как принадлежащий клиенту, потом при обработке трафика этого IP, этот трафик будет посчитан нужному абоненту.

Чтобы сделать полностью динамческим все это дело, то нужно просто при отсутствии трафика в течении lease времени просто отвязывать IP от абонента и делать этот IP снова свободным.

[jp1111]

ключевое вот в чем "то нужно просто при отсутствии трафика в течении lease времени"

2 вопроса:

Вы это уже реализовали или нет?

как определять "lease время"?

 

Правильно ли я понял что в данном случае accounting-updates фиктивно заменен "отслеживанием" т.е. один из модулей системы как бы сам шлет в RADIUS interim updates. Ну или как то аналогично, видя, например, что за последнее "lease время" проходили пакеты с таким-то IP по сетевому уровню ?

[Pyzzle]

ключевое вот в чем "то нужно просто при отсутствии трафика в течении lease времени"

2 вопроса:

Вы это уже реализовали или нет?

как определять "lease время"?

 

Правильно ли я понял что в данном случае accounting-updates фиктивно заменен "отслеживанием" т.е. один из модулей системы как бы сам шлет в RADIUS interim updates. Ну или как то аналогично, видя, например, что за последнее "lease время" проходили пакеты с таким-то IP по сетевому уровню ?

1. Удаление не реализовано, т.к. такая задача действительно из разряда "хочется странного".

 

2. Если встанет задача реализовать именно то, что хочет топик-стартер: "нужно клиентам выдавать динамические адреса, реальные", то это можно сделать. Естественно никакого Radius-accounting по сессиям не будет, т.к. при DHCP четко понять сессию не возможно, DHCP выдал адрес на определенное время и забыл про клиента. Если пугает ресурсоемкость вопроса определения "отустствия трафика за последнее время" и необходимость запуска дополнительных операций по cron для чистки старых IP, то можно реализовать следующим образом:

Когда приходит запрос на получение IP, по Option 82 определяем клиента, по MAC определяем давали ли ему уже адрес, если давали, то отдаем ему тот-же адрес и отмечаем в базе время последней выдачи адреса. Если про этот MAC записей нету, то выбираем свободный из пула. Если в пуле свободных нет, то выбираем из пула адрес, у которого самое раннее время последнего получения адреса и если оно раньше чем max-lease-time+интервал получения данных по IP трафику, то выдаем его, и заменяем привязку этого адреса на нового абонента. Если адресов свободных нет, то ничего не выдаем абоненту, и пишем гневную запись в error-log, что кончились адреса. При включенном dhcp-snooping на коммутаторах это все будет работать и корректно тарифицироваться.

 

[jp1111]

ключевое вот в чем "то нужно просто при отсутствии трафика в течении lease времени"

2 вопроса:

Вы это уже реализовали или нет?

как определять "lease время"?

 

Правильно ли я понял что в данном случае accounting-updates фиктивно заменен "отслеживанием" т.е. один из модулей системы как бы сам шлет в RADIUS interim updates. Ну или как то аналогично, видя, например, что за последнее "lease время" проходили пакеты с таким-то IP по сетевому уровню ?

1. Удаление не реализовано, т.к. такая задача действительно из разряда "хочется странного".

 

2. Если встанет задача реализовать именно то, что хочет топик-стартер: "нужно клиентам выдавать динамические адреса, реальные", то это можно сделать. Естественно никакого Radius-accounting по сессиям не будет, т.к. при DHCP четко понять сессию не возможно, DHCP выдал адрес на определенное время и забыл про клиента. Если пугает ресурсоемкость вопроса определения "отустствия трафика за последнее время" и необходимость запуска дополнительных операций по cron для чистки старых IP, то можно реализовать следующим образом:

Когда приходит запрос на получение IP, по Option 82 определяем клиента, по MAC определяем давали ли ему уже адрес, если давали, то отдаем ему тот-же адрес и отмечаем в базе время последней выдачи адреса. Если про этот MAC записей нету, то выбираем свободный из пула. Если в пуле свободных нет, то выбираем из пула адрес, у которого самое раннее время последнего получения адреса и если оно раньше чем max-lease-time+интервал получения данных по IP трафику, то выдаем его, и заменяем привязку этого адреса на нового абонента. Если адресов свободных нет, то ничего не выдаем абоненту, и пишем гневную запись в error-log, что кончились адреса. При включенном dhcp-snooping на коммутаторах это все будет работать и корректно тарифицироваться.

По 1 согласен с Вами.

По 2 - не проще принудительно вставить эккаунтинг в DHCP по событиям выдачи адреса и по событию его релиза по запросу, либо релиза по таймауту? Всю остальную логику пусть отрабатывает RADIUS по своим алгоритмам.

[Pyzzle]

По 1 согласен с Вами.

По 2 - не проще принудительно вставить эккаунтинг в DHCP по событиям выдачи адреса и по событию его релиза по запросу, либо релиза по таймауту? Всю остальную логику пусть отрабатывает RADIUS по своим алгоритмам.

Не проще, существующие DHCP сервера (во всяком случае я о таких не знаю) не поддерживают такое взаимодействие, ISC-DHCPd+netpatch.ru позволяет перенести всю логику работы, в том числе и учет времени жизни leases на сторону radius сервера, никаких событий о том что кончилась аренда адреса DHCP отправить не может.

С точки зрения стройности к красивости всей системы в целом - вы правы, но для этого нужно написать свой DHCP сервер с нуля и либо, чтобы он работал с Radius как полноценный NAS (только для полного счастья он должен еще и знать и отдавать данные о трафике за сессию, уметь резать скорость и т. п. в результате получается аналог ISG) или делать сервер изначально заточенный на определенную систему биллинга и тогда можно огранизовать взаимодействия вообще как угодно.

 

Развивая тему хотелось бы узнать у людей хотящих динамическую раздачу адресов что именно вы хотите, и зачем это вам?

 

Если хочется давать реальные IP: чтобы и у всех абонентов были реальники, и у провайдера реальников было меньше чем абонентов, то для эффективной работы придется слишком большие VLAN делать, а значит броадкаст по всей сети гулять будет. В этом случае использование PPPoE более разумное решение.

 

 

[Дегтярев Илья]

придется слишком большие VLAN делать, а значит броадкаст по всей сети гулять будет

А вот этим должен занимаеться ip unnumbereb на кошке в центре.

Изменено 28 августа, 2009 пользователем Дегтярев Илья

[jp1111]

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

[jp1111]

В этом случае использование PPPoE более разумное решение.

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

Что касается опции 82, сделали ровно так, как написано в статье: http://www.lanbilling.ru/dhcp_radius.html

Что касается поднятой темы, то потенциальный заказчик закрыл тему с формулировкой "мы не лохи" :)

[Yuka]

jp1111

 

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

[jp1111]

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

Общие принципы ценообразования по доработкам см. по ссылке http://forum.nag.ru/forum/index.php?showto...0&start=100 . Думаю, наша компания не одинока в подобном подходе. В данном случае запрос большинством данного форума, ровно как и нашими разработчиками, квалифицирован как "заказчик хочет странного". Несмотря на это, обозначенная в КП цена, для потенциального заказчика, Юрий :), полностью адекватна сложности реализации запрошенного.

[zoro]

И мне хочется странного :) то что и юрию... да и еще десяток людей также хотят это...

я лично щас копаю ISG+ ISC+ Как "легализовать" свой самописный биллинг, бо стоймость нормального биллинга с доработкой под нас (хочется странного)=стоймости легализации...

[dk_]

Есть платные программные решения, которые, насколько я понимаю, позволяют подружить DHCP с RADIUS'ом, а дальше уже с биллингом подружить — дело техники. Если такое решение окажется экономически выгоднее, почему бы не попробовать.

[jp1111]

Есть платные программные решения, которые, насколько я понимаю, позволяют подружить DHCP с RADIUS'ом, а дальше уже с биллингом подружить — дело техники. Если такое решение окажется экономически выгоднее, почему бы не попробовать.

Да как Вы все не поймете !!! Можно подружить DHCP с RADIUS см. пример, http://www.lanbilling.ru/dhcp_radius.html, но если у DHCP понятие СЕССИЯ отсутствует, а в RADIUS оно (понятие) присутствует, то соединить, то, чего нет, с тем, что есть, это не только "дело техники", но и дело извращения с "эмуляцией" в DHCP этой самой сессии с помощью танцев с бубнами в коде и определенными допущениями.

 

"И мне хочется странного :) то что и юрию" - ну так скиньтесь с Юрием и оплатите эту странность, дело то в чем? Если еще с десяток заинтересованных найдете, то ТЗ, хоть сюда выложу на согласование. У меня разработчики на з.п. сидят, а не на чувстве альтруизма. А те, которые с бубнами танцевать умеют получают далеко не средний уровень оной.

 

"Легализовать" это = "Получить 2 сертификата и 2 лицензии", не так сложно, вот только больно дорого получается с 01.01.10

[dk_]

А, про dhcp2radius на netpatch.ru я сразу не увидел, спасибо. Конечно, если это доступно бесплатно и нормально работает, то нет смысла добывать это за деньги и за границей.

 

Уважаемые «желающие странного» — можете писать мне в личку, или на почту, или связаться через контактную информацию на сайте (указан в профиле). Думаю, договоримся насчёт этого функционала.