====== Accounting — учет трафика ======
{{indexmenu_n>3}}

FastPCRF поддерживает Radius accounting. FastDPI пропускает абонентский трафик и генерирует статистику по Netflow в сторону PCRF, который в свою очередь меняет формат и отправляет на Radius.  
Для активации Radius accounting в **''/etc/dpi/fastdpi.conf''** необходимо добавить следующие параметры:
  * Разрешение аккаунтинга: <code bash>enable_acct=1</code>

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

  * Необходимо активировать [[dpi:dpi_options:opt_statistics:statistics_settings#общие_настройки_экспрота_статистики|Netflow-статистику]] для биллинга, например: <code bash>
    # Статистика по биллингу абонента
netflow=4
    # Тайм-аут отправки статистики
netflow_timeout=60
</code>

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

  * Необходимо активировать [[dpi:bras_bng:general_setup#настройка_bras_l3_в_fastdpi|авторизацию локальных пользователей]] (''enable_auth=1'' в файле конфигурации fastdpi.conf)

  * Пользователю должна быть подключена [[dpi:dpi_components:platform:dpi_billing|услуга 9]] — экспорт статистики для биллинга. Это значит, что [[dpi:bras_bng:radius_integration:radius_auth_server_integration:radius_auth_response|ответ на Access-Request]] должен содержать атрибут ''VasExperts-Enable-Service="9:on"''

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

===== Дополнительные настройки =====
**[СКАТ 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 (нет задержки).** 
<code bash>
acct_auth_sync_delay=0
</code>
При включенной синхронизации СКАТ перед отправкой Access-Request проверит, есть ли активная аккаунтинг-сессия у данного IP-адреса абонента. Если есть — СКАТ посылает запрос Stop accounting, дожидается ответа на него, и только затем посылает запрос авторизации Access-Request. 

**[СКАТ 8.3+]** Существует разная интерпретация, что такое "входящий" и "исходящий" трафик. Для СКАТ входящий трафик — это то, что приходит абоненту из inet, а исходящий — то, что от абонента уходит в inet. Некоторые системы считают иначе, —  для них можно инвертировать направления в аккаунтинге, для чего введен параметр ''acct_swap_dir'':
  * 0 (по умолчанию) — не изменять;
  * 1 — поменять местами счетчики входящего/исходящего трафика.
<code bash>
acct_swap_dir=0
</code>

<note important>Следует учитывать, что Accounting-поток от fastDPI может быть настолько интенсивным, что fastPCRF будет не в состоянии вычитать все поступающие данные. Для решения этой проблемы может потребоваться [[dpi:faq:fastdpi:net_points|тюнинг сетевого стека]].</note>

{{anchor:acct-pending-queue}}
Инициатором начала/завершения аккаунтинг-сессии в подавляющем числе случаев является 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.
<code bash>
#pcrf_pending_queue_timeout=300
</code>

**Max размер pending queue**, по умолчанию 10000 запросов
При достижении этого размера первые запросы в очереди будут удалены.
<code bash>
#pcrf_pending_queue_size=10000
</code>


===== Внутреннее устройство =====
{{anchor:internals}}
БД аккаунтинга находится в fastPCRF и является in-memory. БД двухуровневая: 
  * нижний raw-уровень отвечает за хранение данных, пришедших от fastDPI. Ключом здесь является IP-адрес;
  * верхний уровень агрегации объединяет одну или несколько записей raw-уровня в аккаунтинг-сессию.

Используя [[dpi:bras_bng:cli:acct|команды CLI]], можно вручную манипулировать данными аккаунтинга, стартовать и завершать сессии, смотреть внутреннюю статистику.

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

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

===== Рестарт fastDPI =====
{{anchor:fastdpi_restart}}

При старте/стопе 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.**
<code bash>
acct_fastdpi_session_stop=1
</code>

По умолчанию (''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-сервера (опция [[dpi:bras_bng:radius_integration:radius_auth_fastpcrf_setup|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 вообще не вернул префикс\\