[StSphinx]

Может кто знает. Возможно ли на ISG сделать некий аналог Policy routing ? Когда пользователям одного класса разрешается выход через gw1, а пользователяем другого - через gw2. Управление этим делом желательно из радиуса.

 

Выдавать атрибут с разными vrf-id ?

[Sonne]

Может кто знает. Возможно ли на ISG сделать некий аналог Policy routing ? Когда пользователям одного класса разрешается выход через gw1, а пользователяем другого - через gw2. Управление этим делом желательно из радиуса.

 

Выдавать атрибут с разными vrf-id ?

 

Входной трафик с одного интерфейса. Если бы было с разных, то и вопроса не возникало бы.

[StSphinx]

Может кто знает. Возможно ли на ISG сделать некий аналог Policy routing ? Когда пользователям одного класса разрешается выход через gw1, а пользователяем другого - через gw2. Управление этим делом желательно из радиуса.

 

Выдавать атрибут с разными vrf-id ?

 

Входной трафик с одного интерфейса. Если бы было с разных, то и вопроса не возникало бы.

 

А тип трафика какой? И принадлежит ли интерфейс какому-либо vrf?

[ingress]

Входной трафик с одного интерфейса. Если бы было с разных, то и вопроса не возникало бы.

 

поместить в два разных vrf, в них дефолт сделать через leak route в два разных gw в таблице с общим интерфейсом.

/32 клиентов из разных vrf будут так же route leak будут литься в таблицу с общим интерфейсом.

[denis_vid]

Еще видел:

ip subscriber routed
 initiator unclassified ip-address

Это на интерфейс подписки. Тот что смотрит на юзеров в локальную сеть. Тип интерфейса значения не имеет

[Sonne]

Входной трафик с одного интерфейса. Если бы было с разных, то и вопроса не возникало бы.

 

поместить в два разных vrf, в них дефолт сделать через leak route в два разных gw в таблице с общим интерфейсом.

/32 клиентов из разных vrf будут так же route leak будут литься в таблицу с общим интерфейсом.

 

Это работает или в теории?

 

И не понимаю что значит /32 клиентов из разных vrf.

Все клиенты приходят в дефолтную таблицу содного интерфейса с помощью

initiator unclassified ip-address

[StSphinx]

Входной трафик с одного интерфейса. Если бы было с разных, то и вопроса не возникало бы.

 

поместить в два разных vrf, в них дефолт сделать через leak route в два разных gw в таблице с общим интерфейсом.

/32 клиентов из разных vrf будут так же route leak будут литься в таблицу с общим интерфейсом.

 

Это работает или в теории?

 

И не понимаю что значит /32 клиентов из разных vrf.

Все клиенты приходят в дефолтную таблицу содного интерфейса с помощью

initiator unclassified ip-address

 

Бегло просмотрел вот это:

http://www.cisco.com/en/US/docs/ios/isg/configuration/guide/isg_acess_sub_sessns.html#wp1054757

Вроде как можно, имея интерфейс в дефолтной таблице, сунуть сабскайбера в нужный вам vpn.

[Sonne]

Бегло просмотрел вот это:

http://www.cisco.com/en/US/docs/ios/isg/configuration/guide/isg_acess_sub_sessns.html#wp1054757

Вроде как можно, имея интерфейс в дефолтной таблице, сунуть сабскайбера в нужный вам vpn.

Интересная ссылка, посмотрим, спасибо!

[alks]

Входной трафик с одного интерфейса. Если бы было с разных, то и вопроса не возникало бы.

 

поместить в два разных vrf, в них дефолт сделать через leak route в два разных gw в таблице с общим интерфейсом.

/32 клиентов из разных vrf будут так же route leak будут литься в таблицу с общим интерфейсом.

 

Это работает или в теории?

 

официально такой схемы у циски нет, но у меня года 4 как работает

есть только один ньюанс - интерфейс для portbundle & radius должен быть в grt, иначе не взлетит

 

да и если мне память не изменяет то сначала было SSG а потом из нее выросло isg, т.е. грубо говоря isg это ssg v2

где-то на сайте циски была даже табличка по совместимости применения атрибутов isg/ssg

[Bushi]

Подскажите, на NPE-300 можно ли протестировать и поднять полноценный ISG (несколько тысяч pps меня устроит, покупать NPE-G1/G2 или ASR пока нет резона)? Пытаюсь это сделать на dynamips, но тот уже при 500pps ласты склеивает.

[survivor]

Прошло уже порядочно времени с момента когда я заводил эту тему, проблему я тогда так и не решил - забросил на лучшие времена... Все советы сообщества свелись к одному - читай доки салага :)

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

Cisco IOS Intelligent Services Gateway Configuration Guide

Читал еще раз Леонова, Алекса и всех-всех-всех...

 

Итак:

 

Чтобы контролировать юзера прежде всего нужна сессия, что-то что уникально определяет его на брасе и что можно закрыть/открыть/ограничить. В случае с PPPoE/PPtP и т.д. это туннель до браса, наш конец которого выглядит как interface Virtual-Access N.Y.

В случае с IPoE это либо source IP транзитного траффика (если на L3 юзер затерминирован где-то в другом месте), либо source MAC (если брас находится в одном влане с абонентом) либо это весь интерфейс браса (если у нас модель vlan-per-user).

Чтобы определить нашу модель вводим на брасе:

interface gig0/0/2.100500
 ip subscriber interface

 

дальше нужно сессией управлять - пускать не пускать. Для этого привяжем к интерфейсу policy-map типа control.

interface gig0/0/2.100500
 service-policy type control IPoE

 

теперь нужно его создать:

policy-map type control IPoE
class type control ...
class type control ...
class type control ...

 

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

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

А среди действий которые можно осуществить: авторизовать через aaa на радиусе (указываем что будет логином, а что паролем), есть возможность привязать к клиенту один или более сервисов. Что такой сервис? Да блин это просто очередной policy-map только уже типа service, который для своих классов тоже позволяет выполнить те или иные (но уже другие) действия: ну зашейпить или редиректнуть или вообще все дропнуть.

 

Итак:

policy-map type control IPoE
class type control always event session-start
  authorize aaa list IPoE-AAA password 12345 identifier remote-id plus circuit-id
  service-policy type service name L4REDIRECT
  service-policy type service name OPENGARDEN

 

Теперь надо создать эти самые OPENGARDED (что можно юзеру до авторизации):

policy-map type service OPENGARDEN
class type traffic ALLOWED-HOSTS
  police ...

class-map type traffic match-any ALLOWED-HOSTS
match acl ...

 

и L4REDIRECT:

policy-map type service L4REDIRECT
class type traffic WWW-TRAFFIC
  redirect to group HOME-CABINET

class-map type traffic match-any WWW-TRAFFIC
match acl ...

redirect server-group HOME-CABINET
server ... port ...

 

Итак конфигурация готова. Что она делает? В случае обнаружения новой сессии - первый пакет на данном интерфейсе (так как ip subscriber interface) брас аутентифицирует клиента на радиусе с логином равным его opt-82 и паролем 12345. При этом сессии навешивается два сервиса - свободный доступ к определенным ресурсам (OPENGARDEN) с лимитированной скоростью и редирект любого http траффика на домашний кабинет.

 

Что скажет сообщество? Верно ли мое понимание сессий и сервисов?

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

[Alex/AT]

В целом понимание верное. Если несколько упростить, то практически для любых сервисных гейтвеев верно следующее:

 

1. Есть клиентская сессия. Либо она поднимается по туннелю PPPoE/PPTP/etc., либо поднимается по появлению трафика с энного IP/MAC/DHCP-запроса, не суть. Клиентская сессия - это собственно сам клиент с точки зрения BRAS.

2. Сессия уникально идентифицируется IP клиента (одним или подсетью, ну и мб VRF еще, если оный есть). Ну, помимо там есть еще virtual-interface id, session id и проч, но опять же - не суть.

3. На каждую клиентскую сессию при старте может быть подвешен набор глобальных параметров. Это ACL, полисеры-шейперы, L4R и прочее.

4. Далее - на каждую клиентскую сессию вешаются сервисы. Сервисы - это динамическая составляющая, их можно поднимать и опускать динамически.

5. Каждый сервис - это совокупность приоритета, классификатора трафика (ACL) и набора параметров (ACL, полисеры-шейперы, L4R и прочее).

6. Идущий трафик сначала проходит глобальные параметры сессии, а потом (если не сброшен на первом этапе) в порядке приоритета проходит все классификаторы трафика сервисов.

7. Проход выполняется по "in"-классификатору, если трафик идёт от клиента, и по "out"-классификатору, если к клиенту. Причём приоритеты классификаторов на "in" и "out" могут быть разными.

8. Если трафик соответствует классификатору трафика сервиса, он "запихивается" в этот сервис, и к нему применяется весь набор параметров сервиса (раздельно на "in" и "out" соответственно).

9. При попадании трафика в сервис проход классификаторов прекращается. Т.е. трафик не может одновременно быть в двух сервисах на "in" либо "out" сразу. Но вполне может быть в одном на "in", и другом на "out" - согласно приоритетам.

10. Если трафик не попал ни в один классификатор трафика для сервисов, он запихивается в "стандартный" сервис. Обычно это "permit".

 

Собственно, и всё.

Изменено 13 мая, 2012 пользователем Alex/AT

[survivor]

Alex/AT спасибо за ваш ответ, рад что я на верном пути :)

кое-что мне все еще непонятно, надеюсь на вашу помощь - та конфигурация, которую я привел, навешивает на клиента сервисы в момент инициации сессии. А что будет когда юзер успешно пройдет авторизацию на радиусе? Эти сервисы сами снимутся или нужно прописать в мой polic-map type control IPoE еще один class type control с каким-то другим event'ом и там привязать уже новые сервисы? но тогда снимутся ли старые (OPENGARDEN и L4REDIRECT)? И что это за событие?

ASR(config-control-policymap)#class type control always event ?
 access-reject            Radius authentication failed
 account-logoff           Upon an account logoff
 account-logon            Upon an account logon
 acct-notification        Upon an Accounting Notification event
 credit-exhausted         Upon the billing server returning qt=0 qv=0 it>0
 dummy-event              Dummy event to test suspendable actions
 quota-depleted           Upon the depletion of allocated quota
 radius-timeout           RADIUS server timed out during authentication
 service-failed           Upon failure of a service
 service-start            Upon a request to start a service
 service-stop             Upon a request to stop a service
 session-default-service  Upon providing default service
 session-restart          Upon a session being restarted
 session-service-found    Upon network plumbing service determined
 session-start            Upon a session being created
 timed-policy-expiry      Upon a timed policy expiry 

 

наверное session-start?

 

Или же нужно назначить новые сервисы из радиуса? Честно говоря хочется минимизировать участие радиуса во всем этом, так как он является частью биллинга и не очень гибок...

[Alex/AT]

Не снимутся. Тут либо вешать сервисы с радиуса, либо "по умолчанию". Можно снять через CoA. Вообще правильно использовать либо "локальные" сервисы, либо выдавать все сервисы с RADIUS, но не обе вещи сразу. Технических препятствий нет, зато путаницы - хоть отбавляй.

[survivor]

Минутку... но я ведь и хочу только локальные сервисы использовать, через радиус ничего не загружать. А тут получается пользователь успешно авторизируется, ему через событие session-start назначатся локальные сервисы "доступ к интернет" и доступ к "локальным ресурсам", каждый со своей скоростью, а редирект все равно останется! Как же этим пользоваться?

[survivor]

хм, че-то я запутался - session start это событие не после авторизации, а до нее. Именно на него у меня и идет обращение к радиусу.

События "авторизация прошла успешно" похоже нет вовсе.

 

Но во всех примерах везде назначается в session start сервис L4REDIRECT, как же его отключают после авторизации? Я ничего относительно этого в примерах не обнаружил.

[azhur]

Но во всех примерах везде назначается в session start сервис L4REDIRECT, как же его отключают после авторизации? Я ничего относительно этого в примерах не обнаружил.

А может и не отключают?

Назначить сервису L4REDIRECT самый низкий приоритет, и при наличии других сервисов с более высоким приоритетом (после успешной авторизации) на него просто ничего не попадёт.

[Alex/AT]

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

Если хотите L4R'ить "неизвестных" пользователей - заставьте RADIUS отвечать на все неизвестные логины-пароли не Reject'ом, а стандартным набором сервисов для таких пользователей.

Изменено 14 мая, 2012 пользователем Alex/AT

[survivor]

Alex/AT, изучая коммуникацию isg браса с радиусом не понял одну штуку - почему на радиусе для сервисов заводят отдельных пользователей? Разве сервисы навешиваются не через av пары?

 

вот ваша цитата из http://alex-at.ru/cisco/3-ssg-cisco-7206-pppoe

 

Еще раз напоминаю, что каждая сервисная группа SSG является отдельным пользователем RADIUS.

 

А как брас этим пользуется? Он же авторизует абонента с логином = opt-82, причем здесь логин=сервис?

 

в то же время в этой теме StSphinx советовал использовать AV пару ssg-account-info... как то это все не стыкуется

[StSphinx]

Не то чтобы я советовал... :)

Можно передавать, как это делается у нас - через AvPair, либо через Cisco Vendor specific non-AVPair attributes.

Идеологически верным , как я понимаю, является второй способ. Но у нас вот так и это работает.

И еще, по моему представлению, первый способ, это SSG way, второй - ISG. Думаю кто-то более опытный это либо подтвердит, либо опровергнет.

 

...почему на радиусе для сервисов заводят отдельных пользователей?

 

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

[survivor]

:-) спасибо что вы тоже здесь! Ну я именно это и имел ввиду - не важно av пара или cisco vendor аттрибут - информация о сервисе, который нужно навесить на сессию передается радиусом в ответе на авторизацию юзера, юзером может быть mac или opt-82 - это мне понятно. Не понятно зачем в радиусе заводить пользователей для сервисов.

 

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

брас что после успешной авторизации шлет на радиус еще какой-то запрос - дай мне сервис для создавшейся сессии? Удобно-то может и да, не понятно как брас этим пользуется

[StSphinx]

:-) спасибо что вы тоже здесь! Ну я именно это и имел ввиду - не важно av пара или cisco vendor аттрибут - информация о сервисе, который нужно навесить на сессию передается радиусом в ответе на авторизацию юзера, юзером может быть mac или opt-82 - это мне понятно. Не понятно зачем в радиусе заводить пользователей для сервисов.

 

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

брас что после успешной авторизации шлет на радиус еще какой-то запрос - дай мне сервис для создавшейся сессии? Удобно-то может и да, не понятно как брас этим пользуется

 

Брас, увидев в профиле пользователя, атрибуты с именами сервисов, ищет их согласно настройкам(локально, локально+радиус, радиус), затем получив тем или иным способом описание сервиса и применив его к сессии сабскрайбера, активирует сервис либо нет, в зависимости от настроек оного.

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

 

И да, при необходимости получить описание сервиса от радиус сервера, брас шлет запрос на авторизацию пользователя aka сервиса с именем пользователя=имя сервиса и заданным в конфиге паролем.

[survivor]

И да, при необходимости получить описание сервиса от радиус сервера, брас шлет запрос на авторизацию пользователя aka сервиса с именем пользователя=имя сервиса и заданным в конфиге паролем.

О боже, наконец-то мне стало ясно! невероятное спасибо, эту схему я предполагал, но не видя нигде подтверждений считал неправильной...

[survivor]

и заданным в конфиге паролем

это оно?:

 subscriber service password 

 

 

Брас, увидев в профиле пользователя, атрибуты с именами сервисов

а это собственно говоря и есть

ssg-account-info

 

а:

ищет их согласно настройкам(локально, локально+радиус, радиус),

это и есть:

aaa authorization subscriber-service default local group ...

 

Вроде все стало на свои места!

[StSphinx]

и заданным в конфиге паролем

это оно?:

 subscriber service password 

 

 

Брас, увидев в профиле пользователя, атрибуты с именами сервисов

а это собственно говоря и есть

ssg-account-info

 

а:

ищет их согласно настройкам(локально, локально+радиус, радиус),

это и есть:

aaa authorization subscriber-service default local group ...

 

Вроде все стало на свои места!

 

Все верно. :) На КРОСе ставите пиво ;)