[megahertz0]

А можно ли сделать так, чтобы в случае, если радиус отдает access-reject, PPPoE сессия поднималась все равно, но на нее навешивался сервис редиректа? Как бы с IPoE проблем нет т.к. сессии как таковой нет, у конечного пользователся тоннель не поднимается, но что делать с PPPoE чтобы завернуть пользователя на кабинет при блокировке?

[triam]

Конечно можно =)

На айте циски есть хорошие примеры.

А в общих словах, то вам надо отвечать Accept'ом с с сервисом редирект =)

http://www.cisco.com/en/US/docs/ios-xml/ios/isg/configuration/15-1s/isg-acess-ppp-sess.html

http://old.ciscoexpo.ru/moscow/2008/download/pdf/Cisco_ISG_segusaro.pdf

[megahertz0]

Я эти доки читал. Но дело вот в чем. У меня биллинг не умеет отвечать access-acceptом при блокировке пользователся. Т.е сервисы ИСГ он отдавать умеет, но вот такой фичи нет. Если пользователь отключен, то только access-reject. Пока у разрабов фича висит в реквесте.

Я настроил на стенде схему с ИПоЕ и автоизацией по source ip. Сервисы, редиректы и все такое работает без проблем, ISG вообще оказалась довольно простой и логичной системой. Но дело в том, что у В случае с ИПоЕ я просто повесил на событине access-reject control type policy map, которая навешивает локально описаный сервис с редиректом на портал + оставляет открытыми всякие киви-кошельки и т.д. Но в ИПоЕ сессии как таковой нет и на стороне клиента тоннель никакой не поднимаетсяю Соотвтественно и ничего придумывать там не надо. Нет авторизации - навешиваем редирект. Есть авторизация - вызываем деавторизацию сессии редиректа через CoA и авторизавываем с новым набором сервисов.

 

Но мне очень хочется перевести на ISG часть клиентов, сидящих на PPPOE еще с давних времен. Дело в том, что навесить на автоизованную сессию ПППоЕ сервисы проблем нет, а вот на сессию, которую биллинг авторизовывать не хочет не получается т.к. сессия просто рвется на этапе установки соединения. М.б. есть какая-нибудь опция у ISG, которая позволяет авторизовать сессию безусловно вне зависимости от ответа радиуса?

[triam]

Вообще если отвечаете reject на установку PPPOE то нужно PPPoE сессию поднимать без аутентификации. А автртзацию делать средствами isg.

Ну и когдо пишите полиси на session-start то помните если aaa из политики прислал ответ с сервисами, то политика дальше не отрабатывается .

А если пришел reject , то обрабатывается следующий шаг. Там может быть редирект типа "нет бабла" и таймер на сессию в 10 минут :)

На слайде 31 как раз нарисована политика о которой я говорю.

[megahertz0]

А можно пример? Что-то я не догоню никак. Допустим неавторизоанного пользователся я аутентифицирую вот так:

aaa authentication ppp ALWAYS-AUTHEN none
aaa authorization network LOCAL-AUTHOR local

class-map type control match-all ISG-IP-UNAUTH
match timer UNAUTH-TIMER
match authen-status unauthenticated

policy-map type control ISG-CUSTOMERS-POLICY
class type control ISG-IP-UNAUTH event session-start
 1 authenticate aaa list ALWAYS-AUTHEN

 

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

[triam]

Да.

[megahertz0]

Да.

Чего да? :)

[triam]

 

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

Да.

У меня нет примеров, где бы RADIUS выдавал Reject, но клиента всё равно надо было терминировать для PPPoE.

Но я б сделал так:

interface Virtual-Template100            
ip unnumbered Loopback100
no ip redirects
no ip unreachables
no ip proxy-arp
ip tcp adjust-mss 1360
no logging event link-status
load-interval 60
peer ip address forced
peer default ip address pool LOCAL-POOL
keepalive 60
service-policy type control ISG-CUSTOMER-POLICY
!

....

policy-map type control ISG-CUSTOMERS-POLICY
class type control ISG-IP-UNAUTH event session-start
 1 authenticate aaa list ALWAYS-AUTHEN
 2 service-policy  type service SERVICE-FOR-REDIRECT
 3 set-timer UNAUTH 5

.....

Привёл часть полиси. Вся хитрость в том, что если пришёл ответ на RADIUS-запрос из пункта 1 (aaa authenticate aaa list ....) то дальше политика не обрабатывается, а вот если пришёл Reject то в игру вступают пункты 2 и 3.

 

Сложность у вас в том, чтобы выдавать в такой схеме через PPPoE реальники =(

[megahertz0]

Я примерно так и предполагал. Т.е. если я укажу в виртуал-темплейте

peer ip address forced
peer default ip address pool LOCAL-POOL

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

Если же сделать

peer default ip address pool LOCAL-POOL

то при наличии Framed-IP-Address в access-accept будет выдаваться адрес, назначеный биллингом, а в случае access-reject, т.е. при отсутствии Framed-IP-Address будет выдаватсья адрес из локального пула? А потом PBR завернуть левые серые адреса на лупбэк с натом и навесить сервис с редиректом...

[triam]

Не совсем так. Если делать аутентификацию на PPPoE сессию, то всем кому придет reject не поднимут PPPoE. Потому что reject. Peer ip address forced тоже отработает нормально, если из радиуса прилетел framed-ip-address.

Про forced

Надо делать так, чтобы PPPoE всегда поднимался. Если радиус это не умеет, то делать на циске, а уже весь интелект переносить на политики ISG.

А-ля IPoE если вам так понятнее.