st_re Опубликовано 14 августа, 2009 (изменено) · Жалоба Подъехал к бензоколонке. Вставил шланг, нажал чтобы лилось до отсечки. Выдернул шланг из бака и кинул на землю. Пошел качать права к "Королеве бензоколонки" что бизин в машину не текет, а считается ...... ;) Правда в случае с бензином можно и срок получить, если оно полыхнуть успеет. Изменено 14 августа, 2009 пользователем st_re Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Yuka Опубликовано 14 августа, 2009 · Жалоба martin74 st_re Ну для таких ;) можно конец сесии обрабатывать если ты кабель вытачил состояние прота изменилось, и биллинг перестаёт считать, решит это такую проблему? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zoro Опубликовано 16 августа, 2009 · Жалоба :) сталкнулся с такими-же потребностями... нетап- отказался делать это и считает это странным... бг-биллинг может такое сделать только за деньги... с циской и ISG пока сильно не занимался, Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 16 августа, 2009 · Жалоба Может быть здесь есть необходимость в cisco dhcp accounting ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 16 августа, 2009 · Жалоба Для таких фишек циска придумала ISG. Кстати аналогичные примочки есть и у других вендоров - джунипера например. Как это работает на примере циски: 1. Свич доступа или агрегации вставляет опт82 в дхцп запрос, и релеит его на дхцп-сервер. 2. Дхцп-сервер (циска с ISG) выдаёт адрес из пула, и создаёт сессию, ПОСЛЕ чего ломится на радиус, используя в качестве логина юзера информацию из опт82. 3. Радиус (он же биллинг) отвечает акцесс-ацептом или отлупом, при акцесс-ацепте - выдаёт параметры сессии (политики, назначенные на юзера). 4. В процессе активности сессии - по ней на радиус отсылается аккоунтинг. 5. Когда сессия завершается ( дхцп релис или по таймауту, или по пинку с радиуса через PoD) - по ней на радиус отсылается аккоунтинг-стоп. На жунипере ЕRХ - все примерно так же, только можно ещё и адрес через радиус назначить вроде. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zoro Опубликовано 16 августа, 2009 · Жалоба Для таких фишек циска придумала ISG. Кстати аналогичные примочки есть и у других вендоров - джунипера например. Как это работает на примере циски: 1. Свич доступа или агрегации вставляет опт82 в дхцп запрос, и релеит его на дхцп-сервер. 2. Дхцп-сервер (циска с ISG) выдаёт адрес из пула, и создаёт сессию, ПОСЛЕ чего ломится на радиус, используя в качестве логина юзера информацию из опт82. 3. Радиус (он же биллинг) отвечает акцесс-ацептом или отлупом, при акцесс-ацепте - выдаёт параметры сессии (политики, назначенные на юзера). 4. В процессе активности сессии - по ней на радиус отсылается аккоунтинг. 5. Когда сессия завершается ( дхцп релис или по таймауту, или по пинку с радиуса через PoD) - по ней на радиус отсылается аккоунтинг-стоп. На жунипере ЕRХ - все примерно так же, только можно ещё и адрес через радиус назначить вроде. А циске принудительно адрес выдать нельзя?? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 16 августа, 2009 · Жалоба Неа. Низзя. Она сначала адрес выдаёт, а потом у радиуса спрашивает. Но это для Л3-коннектед субскрайберов, для Л2-коннектед вроде бы что-то можно сделать. Но тут я не копал глубоко, не было нужды. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 16 августа, 2009 · Жалоба Пруфлинк: 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Targetlink Опубликовано 18 августа, 2009 (изменено) · Жалоба :) сталкнулся с такими-же потребностями... нетап- отказался делать это и считает это странным... бг-биллинг может такое сделать только за деньги... с циской и ISG пока сильно не занимался, Мы тоже повозились с прикручиванием к UTM DHCP 82, но так как спецов толком нет, работало все довольно криво и лично у меня вообще руки опустились. Тут и на нетаповском форуме все так лихо обсуждают как они и то прикрутили и это дописали, чуть ли не дураком себя чувствую :), но решение кажись нашли в обход... Так как основной целью приследовалось управление абонентами на портах, взяли на Try&Buy софтину от framesoft.ru. Наши почти все вопросы решились, но есть ряд коммутаторов, которые они пока не держат (дописать коммутаторы самим при помощи api опять-же некому), так что просим доработок и тянем из них жилы... По результатам, если кому интересно - отпишусь. Изменено 18 августа, 2009 пользователем Targetlink Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Pyzzle Опубликовано 28 августа, 2009 · Жалоба вот пример использования Option 82 в связке DHCP - Биллинг - Управление свитчами. http://www.pyzzle.ru/doc/fuzzy_mac_ip/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jp1111 Опубликовано 28 августа, 2009 · Жалоба вот пример использования Option 82 в связке DHCP - Биллинг - Управление свитчами.Коллеги поясните пожалуйста вот что. Если в netpatch е для ISC DHCP нет эккаунтинга, то какое отношение данная Вами ссылка имеет к поднятой проблеме, а именно: И выдача динамического IP абоненту, пусть даже и через RADIUS И одновременная тарификация трафика по IP. Средствами чего в данном случае организована сессия от назначения адреса до DHCP lease ? Для статического выделения адреса по DHCP при опции 82, решение подходит, сами такое используем, в тандеме с привязкой абонента к порту через LBInventory. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Pyzzle Опубликовано 28 августа, 2009 · Жалоба вот пример использования Option 82 в связке DHCP - Биллинг - Управление свитчами.Коллеги поясните пожалуйста вот что. Если в netpatch е для ISC DHCP нет эккаунтинга, то какое отношение данная Вами ссылка имеет к поднятой проблеме, а именно: И выдача динамического IP абоненту, пусть даже и через RADIUS И одновременная тарификация трафика по IP. Средствами чего в данном случае организована сессия от назначения адреса до DHCP lease ? Новый IP выдается Radius-ом, и радиус при этом прописывает этот IP в биллинге как принадлежащий клиенту, потом при обработке трафика этого IP, этот трафик будет посчитан нужному абоненту.Чтобы сделать полностью динамческим все это дело, то нужно просто при отсутствии трафика в течении lease времени просто отвязывать IP от абонента и делать этот IP снова свободным. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jp1111 Опубликовано 28 августа, 2009 · Жалоба ключевое вот в чем "то нужно просто при отсутствии трафика в течении lease времени" 2 вопроса: Вы это уже реализовали или нет? как определять "lease время"? Правильно ли я понял что в данном случае accounting-updates фиктивно заменен "отслеживанием" т.е. один из модулей системы как бы сам шлет в RADIUS interim updates. Ну или как то аналогично, видя, например, что за последнее "lease время" проходили пакеты с таким-то IP по сетевому уровню ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Pyzzle Опубликовано 28 августа, 2009 · Жалоба ключевое вот в чем "то нужно просто при отсутствии трафика в течении 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 на коммутаторах это все будет работать и корректно тарифицироваться. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jp1111 Опубликовано 28 августа, 2009 · Жалоба ключевое вот в чем "то нужно просто при отсутствии трафика в течении 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 по своим алгоритмам. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Pyzzle Опубликовано 28 августа, 2009 · Жалоба По 1 согласен с Вами.По 2 - не проще принудительно вставить эккаунтинг в DHCP по событиям выдачи адреса и по событию его релиза по запросу, либо релиза по таймауту? Всю остальную логику пусть отрабатывает RADIUS по своим алгоритмам. Не проще, существующие DHCP сервера (во всяком случае я о таких не знаю) не поддерживают такое взаимодействие, ISC-DHCPd+netpatch.ru позволяет перенести всю логику работы, в том числе и учет времени жизни leases на сторону radius сервера, никаких событий о том что кончилась аренда адреса DHCP отправить не может. С точки зрения стройности к красивости всей системы в целом - вы правы, но для этого нужно написать свой DHCP сервер с нуля и либо, чтобы он работал с Radius как полноценный NAS (только для полного счастья он должен еще и знать и отдавать данные о трафике за сессию, уметь резать скорость и т. п. в результате получается аналог ISG) или делать сервер изначально заточенный на определенную систему биллинга и тогда можно огранизовать взаимодействия вообще как угодно. Развивая тему хотелось бы узнать у людей хотящих динамическую раздачу адресов что именно вы хотите, и зачем это вам? Если хочется давать реальные IP: чтобы и у всех абонентов были реальники, и у провайдера реальников было меньше чем абонентов, то для эффективной работы придется слишком большие VLAN делать, а значит броадкаст по всей сети гулять будет. В этом случае использование PPPoE более разумное решение. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 28 августа, 2009 (изменено) · Жалоба придется слишком большие VLAN делать, а значит броадкаст по всей сети гулять будет А вот этим должен занимаеться ip unnumbereb на кошке в центре. Изменено 28 августа, 2009 пользователем Дегтярев Илья Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jp1111 Опубликовано 29 августа, 2009 · Жалоба "чтобы и у всех абонентов были реальники, и у провайдера реальников было меньше чем абонентов" - именно для этого, во всяком случае заказчик именно этим мотивирует данную доработку. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jp1111 Опубликовано 4 сентября, 2009 · Жалоба В этом случае использование PPPoE более разумное решение.В целом, если резюмировать все сказанное выше, я полностью согласен, что основная ценность этого обсуждения заключается именно во фразе, оставленной в качестве квотинга.Что касается опции 82, сделали ровно так, как написано в статье: http://www.lanbilling.ru/dhcp_radius.html Что касается поднятой темы, то потенциальный заказчик закрыл тему с формулировкой "мы не лохи" :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Yuka Опубликовано 5 сентября, 2009 · Жалоба jp1111 Уважаемый, потенциальный заказчик закрыл тему с формулировкой "мы не лохи". после того как вы выкатили сумму за эту реализацию. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jp1111 Опубликовано 5 сентября, 2009 · Жалоба Уважаемый, потенциальный заказчик закрыл тему с формулировкой "мы не лохи". после того как вы выкатили сумму за эту реализацию. Общие принципы ценообразования по доработкам см. по ссылке http://forum.nag.ru/forum/index.php?showto...0&start=100 . Думаю, наша компания не одинока в подобном подходе. В данном случае запрос большинством данного форума, ровно как и нашими разработчиками, квалифицирован как "заказчик хочет странного". Несмотря на это, обозначенная в КП цена, для потенциального заказчика, Юрий :), полностью адекватна сложности реализации запрошенного. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zoro Опубликовано 7 сентября, 2009 · Жалоба И мне хочется странного :) то что и юрию... да и еще десяток людей также хотят это... я лично щас копаю ISG+ ISC+ Как "легализовать" свой самописный биллинг, бо стоймость нормального биллинга с доработкой под нас (хочется странного)=стоймости легализации... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dk_ Опубликовано 9 сентября, 2009 · Жалоба Есть платные программные решения, которые, насколько я понимаю, позволяют подружить DHCP с RADIUS'ом, а дальше уже с биллингом подружить — дело техники. Если такое решение окажется экономически выгоднее, почему бы не попробовать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jp1111 Опубликовано 9 сентября, 2009 · Жалоба Есть платные программные решения, которые, насколько я понимаю, позволяют подружить DHCP с RADIUS'ом, а дальше уже с биллингом подружить — дело техники. Если такое решение окажется экономически выгоднее, почему бы не попробовать.Да как Вы все не поймете !!! Можно подружить DHCP с RADIUS см. пример, http://www.lanbilling.ru/dhcp_radius.html, но если у DHCP понятие СЕССИЯ отсутствует, а в RADIUS оно (понятие) присутствует, то соединить, то, чего нет, с тем, что есть, это не только "дело техники", но и дело извращения с "эмуляцией" в DHCP этой самой сессии с помощью танцев с бубнами в коде и определенными допущениями. "И мне хочется странного :) то что и юрию" - ну так скиньтесь с Юрием и оплатите эту странность, дело то в чем? Если еще с десяток заинтересованных найдете, то ТЗ, хоть сюда выложу на согласование. У меня разработчики на з.п. сидят, а не на чувстве альтруизма. А те, которые с бубнами танцевать умеют получают далеко не средний уровень оной. "Легализовать" это = "Получить 2 сертификата и 2 лицензии", не так сложно, вот только больно дорого получается с 01.01.10 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dk_ Опубликовано 9 сентября, 2009 · Жалоба А, про dhcp2radius на netpatch.ru я сразу не увидел, спасибо. Конечно, если это доступно бесплатно и нормально работает, то нет смысла добывать это за деньги и за границей. Уважаемые «желающие странного» — можете писать мне в личку, или на почту, или связаться через контактную информацию на сайте (указан в профиле). Думаю, договоримся насчёт этого функционала. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...