Jump to content

Recommended Posts

Posted

Коллеги, вот пришел момент перехода на ISG у меня. Начитался кучи манов, все прекрасно и здорово. Но... у меня биллинг не поддерживает несколько сервисных аккаунтинг сессий и модель предоставления услуг - PPPoE.

 

Собственно, вопрос: возможно ли оставить PPPoE и прикрутить сервисы и CoA из ISG, ну и L4-Redirect. Можете поделиться конфигом рутера с подобным решением?

Posted

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

Posted

Коллеги... не жадничайте. Подсобите пожалуйста...

 

Так никто ж не жадничает. По форуму примеров полно...

Posted

Сорри... но у всех dhcp... а у меня задача скрестить plain pppoe с возможностями isg по части назначения сервисов...

Posted

Сорри... но у всех dhcp... а у меня задача скрестить plain pppoe с возможностями isg по части назначения сервисов...

 

По части назначения сервисов, с точки зрения ISG , что pppoe , что dhcp - фиолетово.

Posted

Сорри... но у всех dhcp... а у меня задача скрестить plain pppoe с возможностями isg по части назначения сервисов...

 

По части назначения сервисов, с точки зрения ISG , что pppoe , что dhcp - фиолетово.

 

Ну в принципе, я так и думал. Т.е. получается что можно авторизовывать как обычно, через bba и соответствующий темплейт, а вот далее через coa - назначать сервисы. Или как-то иначе? Просто не очень понимаю тогда по поводу локальных сервисов, т.е. тех которые не приходят по radius`у... Можно пример какой-нить, пожалуйста...

Posted

Сорри... но у всех dhcp... а у меня задача скрестить plain pppoe с возможностями isg по части назначения сервисов...

 

По части назначения сервисов, с точки зрения ISG , что pppoe , что dhcp - фиолетово.

 

Ну в принципе, я так и думал. Т.е. получается что можно авторизовывать как обычно, через bba и соответствующий темплейт, а вот далее через coa - назначать сервисы. Или как-то иначе? Просто не очень понимаю тогда по поводу локальных сервисов, т.е. тех которые не приходят по radius`у... Можно пример какой-нить, пожалуйста...

 

Вот пример локально описанного сервиса:

 

policy-map type service 6Mb
class type traffic ALLTRAFF
 police input 6704000 1356448 2712896
 police output 6704000 1356448 2712896
!
class-map type traffic match-any ALLTRAFF
match access-group input 100
match access-group output 101

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

 

aaa authorization subscriber-service default local group тут_имя_радиус_группы

Posted

Спасибо. Т.е. получается, что проверяем логин\пароль пользователя по-обычному, т.е. без всяких хитрых мачилок session-start. А названия сервисов присылаем по access-accept и\или coa. Верно? Или можно как-то по-умолчанию назначить локальные сервисы при старте pppoe-сесии? Можете подсказать?

Posted

Спасибо. Т.е. получается, что проверяем логин\пароль пользователя по-обычному, т.е. без всяких хитрых мачилок session-start. А названия сервисов присылаем по access-accept и\или coa. Верно? Или можно как-то по-умолчанию назначить локальные сервисы при старте pppoe-сесии? Можете подсказать?

 

В принципе можно назначить сервисы при старте pppoe-сессии. Но как минимум одно событие надо будет обрабатывать - session-start.

Вешаете service-policy на Virtual-Template и назначаете сервис при наступлении события session-start.

Posted

Спасибо. Т.е. получается, что проверяем логин\пароль пользователя по-обычному, т.е. без всяких хитрых мачилок session-start. А названия сервисов присылаем по access-accept и\или coa. Верно? Или можно как-то по-умолчанию назначить локальные сервисы при старте pppoe-сесии? Можете подсказать?

 

В принципе можно назначить сервисы при старте pppoe-сессии. Но как минимум одно событие надо будет обрабатывать - session-start.

Вешаете service-policy на Virtual-Template и назначаете сервис при наступлении события session-start.

 

Хммм... а зачем, если можно проавторизовать пользователя стандартным образом, без обработки события session-start? Просто проверял, обычный способ работает как на c7201 так и asr1008. Но еще не сообразил и не проверил, будет ли работать назначение сервиса\ов в первом access-accept.

 

Можете пример простого сервиса, который вы предлагаете повесить на session-start? Я никак не могу раскурить эту идеологию в разрезе pppoe. Для dhcp - более-менее понятно.

Posted

Спасибо. Т.е. получается, что проверяем логин\пароль пользователя по-обычному, т.е. без всяких хитрых мачилок session-start. А названия сервисов присылаем по access-accept и\или coa. Верно? Или можно как-то по-умолчанию назначить локальные сервисы при старте pppoe-сесии? Можете подсказать?

 

В принципе можно назначить сервисы при старте pppoe-сессии. Но как минимум одно событие надо будет обрабатывать - session-start.

Вешаете service-policy на Virtual-Template и назначаете сервис при наступлении события session-start.

 

Хммм... а зачем, если можно проавторизовать пользователя стандартным образом, без обработки события session-start? Просто проверял, обычный способ работает как на c7201 так и asr1008. Но еще не сообразил и не проверил, будет ли работать назначение сервиса\ов в первом access-accept.

 

Можете пример простого сервиса, который вы предлагаете повесить на session-start? Я никак не могу раскурить эту идеологию в разрезе pppoe. Для dhcp - более-менее понятно.

 

 

Авторизовать можно как обычно, но если вы хотите навесить сервис, сразу в момент подключения абонента, не через Радиус, необходимо все таки описать политику, а так как политики работают на основе событий, то соотв. обработать одно событие - session-start.

Вот посмотрите топик:

http://forum.nag.ru/forum/index.php?showtopic=50333

Posted

Спасибо за информацию. Будем пробовать. Позвольте уточнить, в указанной теме обрабатывается session-start и цепляются два сервиса. Это ясно. Единственное уточнение, в этом случае пойдет вторая авторизация сервиса на radius-сервер, или нет? Просто у нас биллинг, который не умеет авторизовывать сервисы. для него существует только одна сессия с авторизацией, но аккаунтинг-сессий может быть несколько.

Posted

Спасибо за информацию. Будем пробовать. Позвольте уточнить, в указанной теме обрабатывается session-start и цепляются два сервиса. Это ясно. Единственное уточнение, в этом случае пойдет вторая авторизация сервиса на radius-сервер, или нет? Просто у нас биллинг, который не умеет авторизовывать сервисы. для него существует только одна сессия с авторизацией, но аккаунтинг-сессий может быть несколько.

 

 

Вот это решает вопрос с локальными сервисами и их авторизацией:

aaa authorization subscriber-service default local

То есть, позволяет иметь локальный сервис и не авторизовать его на Радиус-сервере.

И кстати, биллингу не обязательно уметь авторизовать сервис как сервис, можно иметь сервис в биллинге, как обычного пользователя.

У нас так и сделано.

Posted

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

Posted

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

 

Это дает возможность держать описание сервисов в биллинге. Когда БРАСов много, это знаете ли очень удобно. Ну и "биллингаторы" реже сетевых инженеров трясут. :)

Posted

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

 

И еще один вопрос, что матчит session-start? Старт какой сессии, ip-сессии? Или ppp? Или что? Что-то не могу найти на cisco.com удобоваримого описания событий... И езе уточнение: для dhcp используется еще ряд событий, они нужны для pppoe?

Posted

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

 

И еще один вопрос, что матчит session-start? Старт какой сессии, ip-сессии? Или ppp? Или что? Что-то не могу найти на cisco.com удобоваримого описания событий... И езе уточнение: для dhcp используется еще ряд событий, они нужны для pppoe?

 

Для авторизации сервисов никто не запрещает использовать отдельный Radius сервер.

session-start матчит начало сессии, неважно какой, IP или PPPoE.

О каких событиях для dhcp идет речь?

 

Вообще, в качестве лирического отступления - ISG оперирует такими понятиями как сессия, сабскрайбер, сервис.

Но никак не pppoe, ip, dhcp. Собственно - pppoe, ip, dhcp всего лишь техническая реализация доступа.

ISG это более высокий уровень асбтракции. Как только вы с этим свыкнитесь, станет легче :)

Posted

Уффф... Спасибо. Но пока не могу разобраться до конца. В приведенном примере, как я понял, на событие session-start - навешивается control-policy из двух сервисов. Сразу вопрос: а почему так? А если мы не знаем какие сервисы надо навесить тому или иному пользователю, т.е. хотим в radius-accept прислать те или иные сервисы? Как быть?

Posted

Уффф... Спасибо. Но пока не могу разобраться до конца. В приведенном примере, как я понял, на событие session-start - навешивается control-policy из двух сервисов. Сразу вопрос: а почему так? А если мы не знаем какие сервисы надо навесить тому или иному пользователю, т.е. хотим в radius-accept прислать те или иные сервисы? Как быть?

 

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

Posted

Т.е. получается что если все передаем по радиусу - не нужно использовать

 

interface Virtual-Template1
...
service-policy type control ACCT_POLICY

 

Или как-то не так?

Posted

Т.е. получается что если все передаем по радиусу - не нужно использовать

 

interface Virtual-Template1
...
service-policy type control ACCT_POLICY

 

Или как-то не так?

 

 

Все верно.

Posted

Прошу прощения, может коряво задал вопрос... Если мы передаем сервисы по Radius, тогда получается что не нужно использовать конструкцию вида:

 

interface Virtual-Template1
...
service-policy type control ACCT_POLICY

 

Или нужно? Зачем тогда вообще контрольная полиси? Если все в radius-accept`е можно передать?

Posted

Прошу прощения, может коряво задал вопрос... Если мы передаем сервисы по Radius, тогда получается что не нужно использовать конструкцию вида:

 

interface Virtual-Template1
...
service-policy type control ACCT_POLICY

 

Или нужно? Зачем тогда вообще контрольная полиси? Если все в radius-accept`е можно передать?

 

Я ответил на ваш вопрос выше.

Политики нужны в принципе, так как в природе существует не только pppoe.

В вашем случае, если вы не понимаете зачем вам они, политики не требуются.

Посмотрите презентацию, что я приаттачил и особенно внимательно примеры реального внедрения.

Service_Control_vleonov-RUS.pdf

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.