Accounting — учет трафика

FastPCRF поддерживает Radius accounting. FastDPI пропускает абонентский трафик и генерирует статистику по Netflow в сторону PCRF, который в свою очередь меняет формат и отправляет на Radius. Для активации Radius accounting в /etc/dpi/fastdpi.conf необходимо добавить следующие параметры:

Разрешение аккаунтинга:
```
enable_acct=1
```

В этом случае данные для биллинга по объему потребляемого трафика пользователя будут передаваться по протоколу Radius Accounting через fastPCRF, а не через Netflow.

Необходимо активировать Netflow-статистику для биллинга, например:

    # Статистика по биллингу абонента
netflow=4
    # Тайм-аут отправки статистики
netflow_timeout=60

Учитывайте, что параметр netflow — это битовая маска: он допускает несколько разных значений. Например, чтобы включить accounting и сбор полной статистики (8), нужно указать netflow=12 (12 = 8 + 4).

Необходимо активировать авторизацию локальных пользователей (enable_auth=1 в файле конфигурации fastdpi.conf)

Пользователю должна быть подключена услуга 9 — экспорт статистики для биллинга. Это значит, что ответ на Access-Request должен содержать атрибут VasExperts-Enable-Service="9:on"

Для авторизации по DHCP: Accounting по IPv4 и IPv6-адресам абонента передается в разных сессиях. Если абоненту выдан IPv4-адрес и IPv6-подсеть, то accounting по IPv4 будет передаваться в одной сессии, а по IPv6 (включая PD-префикс) — в другой.
Для PPPoE авторизации, при условии, что выдача IPv4 и IPv6 была сделана через один Radius запрос accounting будет передаваться в одной сессии.

Дополнительные настройки

[СКАТ 8.1+] При старте fastPCRF шлет Radius-серверу запрос Accounting-Request с атрибутом Acct-Status-Type=Accounting-On, при завершении — Accounting-Request с атрибутом Acct-Status-Type=Accounting-Off. В этих запросах также передаются NAS-атрибуты, идентифицирующие NAS-сервер, и атрибут Acct-Session-Id=0. Accounting-On передается также в случае переключения на резервный Radius-сервер.

[CKAT 8.1+] Некоторые биллинговые системы (например, ЛанБиллинг) требуют, чтобы запросы авторизации и аккаунтинг были синхронизированы: прежде чем послать Access-Request нужно, чтобы текущая сессия аккаунтинга была закрыта. СКАТ по умолчанию не синхронизирует аккаунтинг и авторизацию. Чтобы включить синхронизацию, установите в fastpcrf.conf параметр acct_auth_sync=1.

[СКАТ 9.5.3+] Задержка в секундах при синхронизации acct и auth (ЛанБиллинг) При включенном режиме acct_auth_sync СКАТ, получив подтверждение от Радиуса (биллинга), что Acct-Stop принят, немедленно шлет Access-Request. В некоторых случаях между подтверждением Acct-Stop и отправкой Access-Request необходимо вставить небольшую задержку, чтобы все переходные процессы в биллинге прошли и Access-Request был успешно обработан и получен Access-Accept. Данный параметр определяет величину этой задержки в секундах. По умолчанию = 0 (нет задержки).

acct_auth_sync_delay=0

При включенной синхронизации СКАТ перед отправкой Access-Request проверит, есть ли активная аккаунтинг-сессия у данного IP-адреса абонента. Если есть — СКАТ посылает запрос Stop accounting, дожидается ответа на него, и только затем посылает запрос авторизации Access-Request.

[СКАТ 8.3+] Существует разная интерпретация, что такое "входящий" и "исходящий" трафик. Для СКАТ входящий трафик — это то, что приходит абоненту из inet, а исходящий — то, что от абонента уходит в inet. Некоторые системы считают иначе, — для них можно инвертировать направления в аккаунтинге, для чего введен параметр acct_swap_dir:

0 (по умолчанию) — не изменять;
1 — поменять местами счетчики входящего/исходящего трафика.

acct_swap_dir=0

Следует учитывать, что Accounting-поток от fastDPI может быть настолько интенсивным, что fastPCRF будет не в состоянии вычитать все поступающие данные. Для решения этой проблемы может потребоваться тюнинг сетевого стека.

Инициатором начала/завершения аккаунтинг-сессии в подавляющем числе случаев является fastDPI, но внутренняя БД аккаунтинга ведется в fastPCRF: fastDPI поставляет в эту БД сырые данные по потреблению трафика абонентом, тогда как fastPCRF ведет агрегацию этих данных и преобразует их в формат Radius Accounting'а. Взаимодействие между fastDPI и fastPCRF ведется посредством обмена внутренними сообщениями по сети (закрытый протокол). Потеря внутренних сообщений в случае аккаунтинга может приводить, например, к бесконечной аккаунтинг-сессии (потерян stop), или к тому, что аккаунтинг-сессии не будет, хотя абонент активно потребляет трафик (потерян start). Для предотвращения потери сообщений старта/завершения аккаунтинга, посылаемых от fastDPI к fastPCRF, в fastDPI предусмотрена очередь, призванная сгладить кратковременную потерю связи между fastDPI и fastPCRF. Данная очередь регулируется следующими параметрами в fastdpi.conf:

Параметры очереди запросов к PCRF (pcrf pending queue) PCRF pending queue призвана сгладить кратковременную недоступность PCRF. Запросы к PCRF могут быть обязательными к доставке (например, Acct Start/Stop) или необязательными (например, все запросы авторизации, — если запрос авторизации пропадет, то абонент пошлет его снова). В pending queue попадают только обязательные к доставке запросы.

Max время нахождения запроса в pending queue, секунд (по умолчанию 300 сек) Запросы старше этого времени не будут отправляться на PCRF.

#pcrf_pending_queue_timeout=300

Max размер pending queue, по умолчанию 10000 запросов При достижении этого размера первые запросы в очереди будут удалены.

#pcrf_pending_queue_size=10000

Внутреннее устройство

БД аккаунтинга находится в fastPCRF и является in-memory. БД двухуровневая:

нижний raw-уровень отвечает за хранение данных, пришедших от fastDPI. Ключом здесь является IP-адрес;
верхний уровень агрегации объединяет одну или несколько записей raw-уровня в аккаунтинг-сессию.

Используя команды CLI, можно вручную манипулировать данными аккаунтинга, стартовать и завершать сессии, смотреть внутреннюю статистику.

При рестарте или остановке fastPCRF все текущие аккаунтинг-сессии пропадают.

При рестарте fastDPI также обнуляются все счетчики трафика. При старте fastDPI на Радиус посылается сообщение Accounting-On с NAS-атрибутами, идентифицирующими этот fastDPI; при штатной остановке fastDPI на Радиус посылается сообщение Accounting-Off с NAS-атрибутами fastDPI.

Рестарт fastDPI

При старте/стопе fastDPI отправляет на fastPCRF команды accounting-on/accounting-off. По этим командам fastPCRF закрывает текущие acct-сессии этого fastDPI.

В СКАТ 9.5.3+ возможны две стратегии обработки, регулируемые параметром fastpcrf.conf:

0 — при стопе/старте fastDPI на Радиус слать только Accounting-Off/Accounting-On с указанием NAS-атрибутов fastDPI-сервера, сессии для данного fastDPI-сервера останавливаются без отправки Acct-Stop;
1 — при стопе/старте fastDPI на Радиус слать Acct-Stop для всех сессий от этого fastDPI. Accounting-Off/Accounting-On для этого fastDPI не слать.
Значение по умолчанию: 1.

acct_fastdpi_session_stop=1

По умолчанию (acct_fastdpi_session_stop=1), при старте/стопе fastDPI для каждой активной сессии отправляется Acct-Stop. Это приводит к большой нагрузке на Radius-сервер. Поэтому добавлена вторая стратегия (acct_fastdpi_session_stop=0): посылать только Accounting-On при старте fastDPI и Accounting-Off при стопе fastDPI. Тонким местом данной стратегии является идентификация источника сообщения Acct-On/Acct-Off: Radius-сервер должен понять, какие сессии следует закрывать по Acct-On/Acct-Off, а какие оставить (актуально для конфигураций, когда есть один fastPCRF и несколько fastDPI). Это регулируется параметрами:

✔ для каждого fastDPI-сервера (опция fdpi_server в fastpcrf.conf) должны быть указаны уникальные attr_nas_ip и attr_nas_id;

✔ для идентификации fastPCRF (который при старте/стопе также шлет Acct-On/Acct-Off) следует использовать параметры radius_attr_nas_ip_address и radius_attr_nas_id конфигурационного файла fastpcrf.conf.

Действия Radius-сервера при приеме Acct-On/Acct-Off:

если NAS-атрибуты (NAS-Identifier и/или NAS-IP-Address) относятся к fastDPI — следует закрыть все acct-сессии, инициированные данным fastDPI;
если NAS-атрибуты идентифицируют fastPCRF — надо закрыть все активные acct-сессии (все сессии от fastDPI, которые обслуживаются данным fastPCRF).

Список значений acct_stop_reason

acct_stop_reason_unspecified — причина явно не указана
acct_stop_reason_user_request — явный разрыв сессии по сигналу абонента или при создании новой сессии
acct_stop_reason_idle_timeout — разрыв сессии по тайм-ауту неактивности
acct_stop_reason_session_expired — разрыв сессии по завершению времени, отведенному для сессии
acct_stop_reason_admin_reset — разрыв по запросу админа (CoA Disconnect-Request)
acct_stop_reason_lost_service — закрытие со стороны DHCP-NAK или отключению услуги 9
acct_stop_reason_NAS_error — в запросе обнаружены ошибки
acct_stop_reason_double_secondary_key — разрыв сессии с тем же уникальным вторичным ключом
acct_stop_reason_coa_reauth — CoA reauth
acct_stop_reason_callback — stop текущей сессии из-за реавторизации
acct_stop_reason_no_auth_response — нет ответа на запрос авторизации
acct_stop_reason_NAS_switch — переключение на другой СКАТ
acct_stop_reason_CoA_Disconnect — закрытие по CoA disconnect

Из fastPCRF:
acct_stop_reason_source_reboot — обнаружен рестарт fastDPI по уменьшению значений счетчиков
acct_stop_reason_change_session_id — изменение sessionId
acct_stop_reason_transfer_session_id — передача sessionId другому IP
acct_stop_reason_fastdpi_acct_on — fastDPI прислал Acct-On/Acct-Off
acct_stop_reason_suspended — сессия переведена в состояние suspended по отваливанию Радиуса

acct_stop_reason_ppp_changed_IPv6_prefix — ppp Pool DHCPv6 Renew вернул другой префикс
acct_stop_reason_ppp_missing_IPv6_prefix — ppp Pool DHCPv6 Renew вообще не вернул префикс