ISGv2 Intro

Введение в ISG

• Intelligent Services Gateway (ISG) — это набор функций программного обеспечения Cisco и есть только у Cisco, аналогичный функционал у других вендоров называется иначе.

Шлюз интеллектуальных служб (ISG) представляет собой решение для терминирования абонентов/подписчиков для гибкой настройки услуг (не очень понятное определение с сайта)

ISG занимается следующими ключевыми аспектами управления подписчиками:

• Идентификация абонента
• Определение службы и политики
• Применение политики сеанса
• Управление жизненным циклом сеанса
• Учет доступа и использования услуг
• Мониторинг состояния сеанса
• CoA (Radius) для изменения состояния "не лету"

По картинке немного яснее

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

Ключевые термины которые нужно разобрать

• Subscriber Sessions
• Subscriber Access
• Subscriber Identification
• Subscriber Services
• Policies
• Dynamic Policy Updates

Subscriber Sessions

Сессия (иногда переводят как сеанс) ISG — это общий системный контекст, который создается для каждого подписчика, взаимодействующего с пограничным устройством.
По сути - это какой-то объект в памяти устройства который имеет собственный идентификатор и создается при первом взаимодействии абонента с шлюзом - по сути по первому пакету.
И этот программный объект содержит информацию по авторизации, службам (ограничение скорости или файрволл и прочее)

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

Subscriber Access

Пока что совершенно непонятный термин

Under ISG, the provisioning and handling of specific access media and protocols is decoupled as far as possible from the functionality that is applicable to all session types. This model has the following benefits:

* A common set of subscriber services may be used on an ISG at which heterogeneous subscriber networks are aggregated.
* A common set of subscriber services may be used for multiple ISGs, even when the access technology differs.
* For a given subscriber, the access method may be altered (through provisioning or roaming) without any need to change the service provisioning.

As new access protocols become available, they can be leveraged by existing edge deployments without requiring changes to the service content; new access protocols plug into the ISG framework.

Subscriber Identification

По событиям (первый пакет как самый частый пример) - сходить с запросом с тем что есть на RADIUS
А есть обычно IP адрес и МАК опционально

Пишут что стартом сессии может быть и DHCP

Для IP-сеанса, когда начало сеанса сигнализируется событием протокола DHCP, может быть активирована политика перенаправления TCP. Эта политика облегчит сбор имени пользователя и учетных данных на внешнем веб-портале.

Subscriber Services

Сервис (или услуга) - это набор политик которые применяются к абонентской сессии
Сервис сожет быть активирован в 3 случаях

• As a result of control policy execution - самый интересный и важный, подводит к понятию control policy
• By receipt of a CoA service-logon command - понятно что по CoA пакету можно что-то триггернуть
• By reference in a user profile, where the service is flagged for automatic activation - что написано понятно, как это написать в конфиге - пока нет

Policies

ISG introduces support for two basic policy types:

• Traffic policies
• Control policies

Traffic policies

Traffic policy определяют обработку пакетов данных и состоят из

• traffic class который определяет критерии на основе пакетов для которых применима политика, и
• одного или нескольких traffic actions, которые являются функциональными экземплярами, которые выполняют определенные операции с потоком данных и часто называют функциями.

Действия над трафиком, настроенные в политике трафика, вызываются для пакетов данных, которые соответствуют критериям, определенным классом трафика.
Тут пример не помешает (TODO)

Network-forwarding policies — это особый тип traffic policy, для которого действие представляет собой действие пересылки по сети,
например маршрутизация пакетов с использованием определенного VRF или пересылка пакетов через L2.

Network-forwarding policies являются «бесклассовыми» в том смысле, что невозможно уточнить критерии, для которых применимо действие переадресации.

Control policies

Control policies определяют обработку системных событий (handling) и состоят из одного или нескольких

• control policy rules (правил политики управления)
• decision strategy ( и стратегии принятия решений)

decision strategy определяет, как оцениваются составляющие правила политики.

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

События

session-start

policy-map type control IPOE_CUSTOMERS
 class type control COND_LAST event timed-policy-expiry
  10 service disconnect
 !
 class type control always event session-start
  10 authorize aaa list ISG_AUTH_LIST password radiuspassword identifier source-ip-address 
  20 set-timer 2MIN 2
...

Или

policy-map type control ISG-CUSTOMERS-POLICY
 class type control ISG-IP-UNAUTH event timed-policy-expiry
  1 service disconnect
 !
 class type control always event session-start
  10 authorize aaa list AAA-LIST-ISG-AUTH password secret identifier source-ip-address
  20 set-timer UNAUTH-TIMER 5
  30 service-policy type service name POLICY_MAP_SERVICE_ON_SESSION_START_

Политика IPOE_CUSTOMERS управляет всем циклом жизни сесcии. 
И является ключевым элементом, который описывает что, когда и как делать с абонентской сессией. 
В приведенном ниже примере она достаточна проста. 
По событию session-start на биллинг( метод ISG_AUTH_LIST) пошлется access-request ,
где в качестве username будет указан ip адрес клиента.Если авторизация не удастся, тогда на сессию повесится 2х-минутный таймер и она завершится по его истечению(event timed-policy-expiry).

Обращаю внимание ,что во всех мануалах рекомендуется на данном этапе (event session-start) третьим и четвертым действием разрешить клиенту 
временный доступ к ресурсам в OPENGARDEN и заблокировать/заредиректить все остальное. 

А при событии account-logon(по приходу access-accept от биллинга) снять эти сервисы. В виду того,что фантазия системного администратора безгранична, 
предлагается самостоятельно под себя настроить сценарий того что надо делать с клиентом в эти две минуты. 
Как правило до этого шага могут дойти абоненты если лег радиус и от него нет ответов. В приведенном примере если абонента не 
удается авторизовать он все равно будет иметь доступ в интернет(пока Вы чините radius).
И в большинстве случаев это будут вполне легитимные клиенты , если на доступе настроен dhcp snooping/ip source guard и прочие фичи.

account-logon

ccount-logon(по приходу access-accept от биллинга)