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 определяет, как оцениваются составляющие правила политики.

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

Тут конечно без примера никуда. Для начала -эта та самая важная политика которая настраивается на интерфейсе и полностью определяет все поведение
например
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_
!
class type control always event session-restart
 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_RESTART_
!
class type control always event service-stop
 1 service-policy type service unapply identifier service-name
 10 service-policy type service unapply identifier service-name
 20 log-session-state
!
class type control always event radius-timeout
 20 set-timer UNAUTH-TIMER 60
 30 service-policy type service name POLICY_MAP_SERVICE_ON_SESSION_RADIUS_TIMEOUT_
!
class type control always event access-reject
 20 set-timer UNAUTH-TIMER 60
 30 service-policy type service name ALLOW_172_31_100_2
 40 service-policy type service name ALLOW_172_31_100_3_SPEED_8k
 50 service-policy type service name NO_SERVICE
!

Пока без пояснений - это просто пример

События

Полный список такой, однако по описаниям далеко не все понятно

• access-reject Radius authentication failed - если Radius прислал Acсess-Reject
• account-logoff Upon an account logoff - насколько я могу судить, это возможно только с CoA, если пришел внешний пакет
• account-logon Upon an account logon - Radius прислал Acсess-Accept
• 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
• flow-timeout Upon flow timeout of a service
• quota-depleted Upon the depletion of allocated quota
• radius-timeout RADIUS server timed out during authentication - Radius не ответил за определнный тайм-аут
• 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 - Событие возникает когда на сессии был установлен таймер и он истек

timed-policy-expiry

Событие возникает когда на сессии был установлен таймер и он истек, например

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



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 radius-timeout
  20 set-timer UNAUTH-TIMER 60
  30 service-policy type service name POLICY_MAP_SERVICE_ON_SESSION_RADIUS_TIMEOUT_

В этом случае (если радиус не работает) произойдет событие radius-timeout, взведется таймер с именем UNAUTH-TIMER ( на 60 минут)
и по его истечении будет сгенерировано событие timed-policy-expiry
Это событие будет обработано строкой class type control ISG-IP-UNAUTH event timed-policy-expiry по-тому что:

• event timed-policy-expiry - совпадает со сгенерированным событием
• ISG-IP-UNAUTH - имя class-map type control который проверяется на соответстие
  • match-all - должны сработать все условия
  • match authen-status unauthenticated - сабскрайбер не аутентифицирован (так как радиус не ответил), условие совпадает
  • match timer UNAUTH-TIMER - имя таймера который истек, совпадает (20 set-timer UNAUTH-TIMER 60

В целом эта конструкция реализует логику "если радиус не ответил, назначить сервис POLICY_MAP_SERVICE_ON_SESSION_RADIUS_TIMEOUT_", и через 60 митут сбросить сессию,
Что при активности со стороны сабскрайбера тут же вызовет новую попытку авторизации, и соответвенно новый запрос в радиус. Если радиус заработал - то результат зависит от ответа со
стороны радиуса, если радиус не заработал (опять тайм-айт), то опять следующая попытка через 60 минут.

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

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

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

Ссылки

• https://forum.nag.ru/index.php?/topic/160850-cisco-asr1002-isg/page/2/
• https://www.gtllc.ru/docroot/filesup/u/Cisco/Cisco_ISG_segusaro.pdf
• https://forum.nag.ru/index.php?/topic/160850-cisco-asr1002-isg/page/2/#comments