В тарифных планах возможна установка наборов RADIUS-атрибутов, передаваемых в AUTH ACCEPT-пакете. Например, это может использоваться для заужения канала клиента в зависимости от потреблённого им трафика в течении месяца. Пример подобного тарифа приведён ниже. Наборы передаваемых RADIUS-атрибутов должны быть предаварительно настроены в конфигурации модуля.
При получении тарифного запроса узел передаёт в ответную часть набор атрибутов, который должен быть установлен. С использованием флага
(см. далее) узел может удалять из ответной части установленные ранее наборы атрибутов.Недостаток приведенного примера в том, что атрибуты передаются только при авторизации. При прохождении порога 100Мб по ходу соединения ничего не произойдет, до следующей авторизации клиент будет работать на большой скорости.
Для выполнения каких-либо действий при необходимости изменения свойств соединения используются зоны. Нижеприведенный пример разделяет весь потребленный объем на две зоны, при этом переход из одной зоны в другую вызывает разрыв соединения и, как следствие, повторную авторизацию. Разрыв необходимо настроить в обоих зонах, т.к. в начале месяца происходит переход в первую зону.
Помимо разрыва соединения при смене зон возможна отправка CoA запроса, в том случае, если в качестве инспектора соединений для NASа указан PoD инспектор, а NAS поддерживает PoD и CoA-запросы. В этом случае нужно выбрать действие .
При установке в поле
любой строки при переходе на данную зону генерируется событие , которое можно обработать скриптом поведения. При этом строка передаётся в событии.При прохождении тарифного запроса узел
проставляет свой идентификатор в ответную часть. RADIUS отслеживает смену зоны по ходу соединения и выполняет те действия, которые указаны в новой зоне. Также данный узел можно использовать для разрыва соединений при переходе между разными временами суток с различной скоростью канала. Сброс должен быть установлен в обеих зонах.Важно понимать, что смена зоны происходит только при очередном обсчёте, который, в свою очередь, при Update режиме тарификации происходит по Accounting Update пакету. В случае, если зоны изменяются по времени, они должны быть установлены в узле услуги типа "Время". В случае, если они меняются от объема потребленного трафика - в узле услуги типа "Трафик". Это связанно с алгоритмом тарификации, а именно с тем, что трафик всегда считается потреблённым единой "порцией" в момент предыдущего Update-пакета. Время же при переходе часа обсчитывается двумя "порциями": в момент предыдущего Update-пакета считается потреблённым время до границы часа, и на начало часа учитывается потребление остатка времени. Поэтому, если вы установите зоны, которые должны изменяться по времени в услугу по трафику, то реально действие произойдёт при втором Update-пакете после наступления нужного часа.
Обратите внимание на флаг
в узле . Необходимость данного флага можно рассмотреть на следующем примере тарифа. Пусть при смене зон отправляется CoA-пакет.Без установки этого флага набор атрибутов просто добавляется в тарифный запрос. В результате по приведённому выше тарифу, но без установки этого флага при очередном обсчёте трафика по Update-пакету в ответе тарифного запроса вернутся два набора атрибутов (часть трафика будет обсчитана по 0 руб. а остаток по 1 руб.), которые и будут отправлены в CoA-пакете. При установке же данного флага, последний набор атрибутов удалит информацию о предыдущем в результате будет отправлен только набор
. При изменении зоны по времени наличие данного флага не принципиально по описанным чуть ранее причинам, связанным с различными алгоритмами обсчёта времени и трафика.Вот ещё один пример тарифа, когда после смены зоны отправляются уже два набора атрибутов
и .При отправке CoA используются стандартно набор(ы) атрибутов, полученные из тарифа при очередном обсчёте. Однако в реальности зачастую необходима также повторая отправка атрибутов логина и релама. В этом случае в конфигурации NASа при настройке PoD-инспектора необходима установка опции
. При установке данного флага в CoA-пакете будут отправлены атрибуты, аналогичные отправляемым в Auth Accept-пакете: из свойств логина, реалма. Также будут добавлены все наборы атрибутов, полученные из тарифного плана при последнем обсчёте.Изменение зон может быть отслежено только в пределах тарификации одной услуги. Однако, зачастую могут быть ситуации, когда требуется изменять параметры доступа в зависимости от нескольких услуг. Например, в приведённом ниже примере скорость входящего и исходящего канала понижаются независимо. Обратите внимание на префикс с двоеточием перед названием зоны. Это группа зон. RADIUS отслеживает смену зон в каждой из групп и при этом выполняет действия, указанные в новой зоне. Если бы вместо "группа:зона" в данном тарифе использовались просто зоны, то при превышении наработки 200 Мб входящего и исходящем меньше 100 Мб возникало бы противоречие в зонах.
Всвязи с наличием возможности изменения в тарифном плане свойств соединения возникает необходимость обработки ситуации смены тарифного плана по ходу работы сессии. Штатно логика обработки события изменения тарифных планов договора во время активной сессии описана ниже.
При смене тарифа разрывается соединение только, если в результате смены:
изменился текущий действующий тариф, его нужно в общем случае переинициализировать, если есть узлы
;правился сам тарифный план в справочнике текущего действующего тарифа, при этом идёт загрузка тарифного дерева заново и, опять таки, нужно переинициализировать узлы
;не стало тарифа на текущую дату.
Также производится разрыв соединения, если в ходе обсчёта начал использоваться тариф, отличный от предыдущего (начались новые сутки). Однако этот сброс можно отключить опцией
в конфигурации экземпляра модуля, котроллируя разрыв/CoA, когда нужно зонами в тарифах, т.к. смена зон ослеживается и при переходе на другой тариф.