Различия

Показаны различия между двумя версиями страницы.

--- dpi:bras_bng:radius_integration:radius_accounting [2026/03/23 07:58] – elena.krasnobryzh
+++ dpi:bras_bng:radius_integration:radius_accounting [2026/03/26 08:02] (текущий) – elena.krasnobryzh
@@ Строка 3: / Строка 3: @@
 {{indexmenu_n>3}}
-FastPCRF поддерживает RADIUS accounting. FastDPI пропускает абонентский трафик и генерирует статистику по Netflow в сторону PCRF, который в свою очередь меняет формат и отправляет на RADIUS.
+FastPCRF поддерживает RADIUS accounting. FastDPI обрабатывает абонентский трафик и формирует Netflow-статистику, которая передается в fastPCRF. Далее fastPCRF агрегирует данные, преобразует их в формат RADIUS Accounting и отправляет на RADIUS-сервер.
-Для активации RADIUS accounting в **''/etc/dpi/fastdpi.conf''** необходимо добавить следующие параметры:
-  * Разрешение аккаунтинга: <code bash>enable_acct=1</code>
+Для активации RADIUS accounting в **''/etc/dpi/fastdpi.conf''** необходимо задать следующие параметры:
-  * Необходимо активировать [[dpi:dpi_options:opt_statistics:statistics_settings#общие_настройки_экспрота_статистики|Netflow-статистику]] для биллинга, например: <code bash>
+  * Включение аккаунтинга:<code bash>enable_acct=1</code>
-    # Статистика по биллингу абонента
+  * Включение Netflow-статистики для биллинга:<code bash>
+# Статистика по биллингу абонента
 netflow=4
-    # Тайм-аут отправки статистики
+# Тайм-аут отправки статистики
-netflow_timeout=60
+netflow_timeout=60</code>
-</code>
-<note important>В этом случае данные для биллинга по объему потребляемого трафика пользователя будут передаваться по протоколу RADIUS Accounting через fastPCRF, а не через Netflow.\\
-Учитывайте, что параметр ''netflow'' — это битовая маска: он допускает несколько разных значений. Например, чтобы включить accounting и сбор полной статистики (8), нужно указать ''netflow=12'' (12 = 8 + 4).</note>
-  * Необходимо активировать [[dpi:bras_bng:general_setup#настройка_bras_l3_в_fastdpi|авторизацию локальных пользователей]] (''enable_auth=1'' в файле конфигурации fastdpi.conf)
+<note important>Данные по объему потребляемого трафика передаются в биллинговую систему по протоколу RADIUS Accounting через fastPCRF, а не напрямую через Netflow.\\
+Параметр ''netflow'' является битовой маской и может принимать комбинированные значения. Например, для одновременного включения accounting и полной статистики (8) необходимо указать ''netflow=12''.</note>
-  * Пользователю должна быть подключена [[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"''
+  * Включение авторизации локальных пользователей:<code bash>enable_auth=1</code>
+  * Назначение абоненту услуги 9 (экспорт статистики для биллинга). В ответе на Access-Request должен присутствовать атрибут:<code>VasExperts-Enable-Service="9:on"</code>
-<note important>**Для авторизации по DHCP:** Accounting по IPv4 и IPv6-адресам абонента передается в разных сессиях. Если абоненту выдан IPv4-адрес и IPv6-подсеть, то accounting по IPv4 будет передаваться в одной сессии, а по IPv6 (включая PD-префикс) — в другой.\\ **Для PPPoE авторизации**, при условии, что выдача IPv4 и IPv6 была сделана через один RADIUS запрос accounting будет передаваться в одной сессии.</note>
+<note important>
+**Для DHCP-авторизации:** учет трафика по IPv4 и IPv6 ведется в отдельных сессиях. При наличии у абонента IPv4-адреса и IPv6-префикса создаются две независимые accounting-сессии.\\
+**Для PPPoE:** при выдаче IPv4 и IPv6 в рамках одного RADIUS-запроса учет ведется в одной сессии.
+</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''.
+При запуске fastPCRF отправляет на RADIUS-сервер запрос Accounting-Request с атрибутом ''Acct-Status-Type=Accounting-On'', а при завершении — ''Accounting-Off''. В этих запросах передаются NAS-атрибуты, идентифицирующие сервер, и ''Acct-Session-Id=0''. Аналогичный запрос Accounting-On отправляется при переключении на резервный RADIUS-сервер.
-**[СКАТ 9.5.3+]** Задержка в секундах при синхронизации acct и auth (ЛанБиллинг) При включенном режиме acct_auth_sync СКАТ, получив подтверждение от RADIUS (биллинга), что Acct-Stop принят, немедленно шлет Access-Request. В некоторых случаях между подтверждением Acct-Stop и отправкой Access-Request необходимо вставить небольшую задержку, чтобы все переходные процессы в биллинге прошли и Access-Request был успешно обработан и получен Access-Accept. Данный параметр определяет величину этой задержки в секундах. **По умолчанию = 0 (нет задержки).**
+Некоторые биллинговые системы требуют синхронизации процессов авторизации и аккаунтинга: перед отправкой Access-Request текущая accounting-сессия должна быть корректно завершена. Для включения такого режима используется параметр:
+<code bash>
+acct_auth_sync=1
+</code>
+При включенной синхронизации перед отправкой Access-Request выполняется проверка наличия активной accounting-сессии для IP-адреса абонента. Если сессия существует, отправляется Acct-Stop, ожидается подтверждение, после чего выполняется авторизация.
+Дополнительно может быть задана задержка между подтверждением Acct-Stop и отправкой Access-Request:
 <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>
+  * 0 — без изменений;
+  * 1 — инвертировать направления.
-<note important>Следует учитывать, что Accounting-поток от fastDPI может быть настолько интенсивным, что fastPCRF будет не в состоянии вычитать все поступающие данные. Для решения этой проблемы может потребоваться [[dpi:faq:fastdpi:net_points|тюнинг сетевого стека]].</note>
+===== Rating group (группы тарификации) =====
-{{anchor:acct-pending-queue}}
+Rating group (RG) используется для детализации учета трафика абонента в RADIUS Accounting. Использование RG возможно только при включенной услуге 9 (экспорт статистики для биллинга).
-Инициатором начала/завершения аккаунтинг-сессии в подавляющем числе случаев является fastDPI, но внутренняя БД аккаунтинга ведется в fastPCRF: fastDPI поставляет в эту БД сырые данные по потреблению трафика абонентом, тогда как fastPCRF ведет агрегацию этих данных и преобразует их в формат RADIUS Accounting'а. Взаимодействие между fastDPI и fastPCRF ведется посредством обмена внутренними сообщениями по сети (закрытый протокол). Потеря внутренних сообщений в случае аккаунтинга может приводить, например, к бесконечной аккаунтинг-сессии (потерян stop), или к тому, что аккаунтинг-сессии не будет, хотя абонент активно потребляет трафик (потерян start).
-Для предотвращения потери сообщений старта/завершения аккаунтинга, посылаемых от fastDPI к fastPCRF, в fastDPI предусмотрена очередь, призванная сгладить кратковременную потерю связи между fastDPI и fastPCRF.
-Данная очередь регулируется следующими параметрами в fastdpi.conf:
-**Параметры очереди запросов к PCRF (pcrf pending queue)**
+==== Настройка RG в fastDPI ====
-PCRF pending queue призвана сгладить кратковременную недоступность PCRF. Запросы к PCRF могут быть обязательными к доставке (например, Acct Start/Stop) или необязательными (например, все запросы авторизации, — если запрос авторизации пропадет, то абонент пошлет его снова). В pending queue попадают только обязательные к доставке запросы.
-**Max время нахождения запроса в pending queue**, секунд (по умолчанию 300 сек)
+Параметры хранилища и обработки RG:
-Запросы старше этого времени не будут отправляться на PCRF.
+  * Количество групп: <code bash>rating_group_count=0</code> Значение по умолчанию: 0 — RG отключены.
+  * Максимальное число абонентов с RG: <code bash>rating_group_max_subs=0</code> Значение по умолчанию: 0 — RG отключены.
+Инициализация хранилища RG выполняется только если включена биллинговая статистика.
+Объем памяти для хранения RG-статистики рассчитывается по формуле:
 <code bash>
-#pcrf_pending_queue_timeout=300
+memory_required = 32 * rating_group_count * rating_group_max_subs * num_thread
 </code>
+где:
+  * ''32'' — размер счетчиков на одну группу (в байтах);
+  * ''rating_group_count'' — количество групп;
+  * ''rating_group_max_subs'' — максимальное число абонентов;
+  * ''num_thread'' — количество потоков обработки.
-**Max размер pending queue**, по умолчанию 10000 запросов
+Пример расчета для 10 тыс. абонентов, 256 RG и 8 потоков обработки — требуется 625M памяти:
-При достижении этого размера первые запросы в очереди будут удалены.
 <code bash>
-#pcrf_pending_queue_size=10000
+rating_group_count = 256
+rating_group_max_subs = 10000
+num_thread = 8
+memory_required = 32 * 256 * 10000 * 8 = 625M
 </code>
+<note important>При высокой нагрузке поток accounting-данных от fastDPI может превышать возможности обработки fastPCRF. В этом случае требуется тюнинг сетевого стека.</note>
+{{anchor:acct-pending-queue}}
+==== Передача статистики RG в RADIUS Accounting ====
+Статистика по RG передается в отдельных пакетах Interim-Update. Передаются данные только по ненулевым RG.\\
+Из-за ограничения размера RADIUS-пакета (4096 байт) данные RG могут быть разбиты на несколько Interim-Update пакетов.
+Для идентификации типа пакета используется новый VSA ''VasExperts-Acct-Type'' (id=28, vendor=43823, integer) со значениями:
+  * ''0'' — стандартный Interim Update Accounting;
+  * ''1'' — данные по RG.
+Каждая RG и её счетчики передаются в **одном** VSA со следующими атрибутами:
+  * VasExperts-Acct-Rating-Group (short, 16-бит) — номер RG;
+  * VasExperts-Acct-Input-Octets-64;
+  * VasExperts-Acct-Output-Octets-64;
+  * VasExperts-Acct-Input-Packets-64;
+  * VasExperts-Acct-Output-Packets-64.
+Счетчики пакетов и байт по направлениям выводятся в соответствии с опцией <code>acct_swap_dir</code> (как в Accounting).
+Особенности передачи RG:
+  * RG являются опциональными; если у абонента нет RG, данные не передаются;
+  * если RADIUS не подтверждает прием RG-пакета, повторная отправка не выполняется — свежие данные уйдут в следующем Interim-Update;
+  * если у абонента есть RG-статистика, перед отправкой Acct-Stop сессии отправляются текущие данные RG.
+==== Задание RG при авторизации абонента ====
+RG задается на уровне абонента при авторизации через специальный профиль услуги 9 с именем 'RG':
+<code bash>
+VasExperts-Service-Profile :="9:RG"
+</code>
+Накопление статистики по RG возможно только при включенной услуге 9 (bill stat). Если услуга 9 отключается, RG также отключается.
+Примеры:
+  * Услуга 9 включена, RG отключены (стандартный RADIUS Accounting): <code bash>VasExperts-Enable-Service :="9:on"</code>
+  * Услуга 9 включена, RG включены (передача данных RG): <code bash>VasExperts-Service-Profile :="9:RG"</code>
+  * Услуга 9 отключена, RG отключены (RADIUS Accounting не отправляется): <code bash>VasExperts-Enable-Service :="9:off"</code>
 ===== Внутреннее устройство =====
 {{anchor:internals}}
-БД аккаунтинга находится в fastPCRF и является in-memory. БД двухуровневая:
-  * нижний raw-уровень отвечает за хранение данных, пришедших от fastDPI. Ключом здесь является IP-адрес;
-  * верхний уровень агрегации объединяет одну или несколько записей raw-уровня в аккаунтинг-сессию.
-Используя [[dpi:bras_bng:cli:acct|команды CLI]], можно вручную манипулировать данными аккаунтинга, стартовать и завершать сессии, смотреть внутреннюю статистику.
+База данных accounting размещена в fastPCRF и работает в памяти. Структура двухуровневая:
+  * raw-уровень — хранение исходных данных по IP-адресам;
+  * уровень агрегации — объединение данных в accounting-сессии.
-<note important>При рестарте или остановке fastPCRF все текущие аккаунтинг-сессии пропадают.</note>
+Через CLI возможно:
+  * управление сессиями (старт/стоп);
+  * просмотр состояния и статистики.
-<note important>При рестарте fastDPI также обнуляются все счетчики трафика. При старте fastDPI на RADIUS посылается сообщение Accounting-On с NAS-атрибутами, идентифицирующими этот fastDPI; при штатной остановке fastDPI на RADIUS посылается сообщение Accounting-Off с NAS-атрибутами fastDPI.</note>
+<note important>При перезапуске или остановке fastPCRF все текущие accounting-сессии удаляются.</note>
+<note important>При перезапуске fastDPI счетчики трафика обнуляются. При старте отправляется Accounting-On, при остановке — Accounting-Off с соответствующими NAS-атрибутами.</note>
 ===== Рестарт fastDPI =====
 {{anchor:fastdpi_restart}}
-При старте/стопе fastDPI отправляет на fastPCRF команды accounting-on/accounting-off. По этим командам fastPCRF закрывает текущие acct-сессии этого fastDPI.
+При запуске и остановке fastDPI отправляет в fastPCRF команды accounting-on/accounting-off, на основании которых закрываются текущие сессии.
-В **СКАТ 9.5.3+** возможны две стратегии обработки, регулируемые параметром fastpcrf.conf:
+Поведение при этом регулируется параметром:
-  * 0 — при стопе/старте fastDPI на RADIUS слать только Accounting-Off/Accounting-On с указанием NAS-атрибутов fastDPI-сервера, сессии для данного fastDPI-сервера останавливаются без отправки Acct-Stop;
-  * 1 — при стопе/старте fastDPI на RADIUS слать 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). Это регулируется параметрами:
+  * 1 — при старте/остановке fastDPI отправляется Acct-Stop для всех активных сессий;
+  * 0 — отправляются только Accounting-On/Accounting-Off без индивидуальных Acct-Stop.
-✔ для каждого fastDPI-сервера (опция [[dpi:bras_bng:radius_integration:radius_auth_fastpcrf_setup|fdpi_server]] в fastpcrf.conf) должны быть указаны уникальные ''attr_nas_ip'' и ''attr_nas_id'';
+Режим с отправкой Acct-Stop обеспечивает корректное завершение сессий, но создает повышенную нагрузку на RADIUS-сервер. Альтернативный режим снижает нагрузку, но требует корректной идентификации источника по NAS-атрибутам.
-✔ для идентификации fastPCRF (который при старте/стопе также шлет Acct-On/Acct-Off) следует использовать параметры ''radius_attr_nas_ip_address'' и ''radius_attr_nas_id'' конфигурационного файла fastpcrf.conf.
+Для корректной работы необходимо:
+  * задать уникальные ''attr_nas_ip'' и ''attr_nas_id'' для каждого fastDPI;
+  * настроить ''radius_attr_nas_ip_address'' и ''radius_attr_nas_id'' для fastPCRF.
-Действия RADIUS-сервера при приеме Acct-On/Acct-Off:
+Обработка на стороне RADIUS:
-  * если NAS-атрибуты (NAS-Identifier и/или NAS-IP-Address) относятся к fastDPI — следует закрыть все acct-сессии, инициированные данным fastDPI;
+  * если NAS-атрибуты соответствуют fastDPI — закрываются сессии этого узла;
-  * если NAS-атрибуты идентифицируют fastPCRF — надо закрыть все активные acct-сессии (все сессии от fastDPI, которые обслуживаются данным fastPCRF).
+  * если fastPCRF — закрываются все активные сессии.
-=====Список значений acct_stop_reason=====
+===== Список значений acct_stop_reason =====
-''acct_stop_reason_unspecified'' — причина явно не указана\\
-''acct_stop_reason_user_request'' — явный разрыв сессии по сигналу абонента или при создании новой сессии\\
+''acct_stop_reason_unspecified'' — причина не указана\\
-''acct_stop_reason_idle_timeout'' — разрыв сессии по тайм-ауту неактивности\\
+''acct_stop_reason_user_request'' — завершение по инициативе абонента или при создании новой сессии\\
-''acct_stop_reason_session_expired'' — разрыв сессии по завершению времени, отведенному для сессии\\
+''acct_stop_reason_idle_timeout'' — тайм-аут неактивности\\
-''acct_stop_reason_admin_reset'' — разрыв по запросу админа (CoA Disconnect-Request)\\
+''acct_stop_reason_session_expired'' — истечение времени сессии\\
-''acct_stop_reason_lost_service'' — закрытие со стороны DHCP-NAK или отключению услуги 9\\
+''acct_stop_reason_admin_reset'' — завершение по запросу администратора (CoA Disconnect-Request)\\
-''acct_stop_reason_NAS_error'' — в запросе обнаружены ошибки\\
+''acct_stop_reason_lost_service'' — отключение услуги или DHCP-NAK\\
-''acct_stop_reason_double_secondary_key'' — разрыв сессии с тем же уникальным вторичным ключом\\
+''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_callback'' — завершение из-за реавторизации\\
-''acct_stop_reason_no_auth_response'' — нет ответа на запрос авторизации\\
+''acct_stop_reason_no_auth_response'' — отсутствует ответ на авторизацию\\
-''acct_stop_reason_NAS_switch'' — переключение на другой СКАТ\\
+''acct_stop_reason_NAS_switch'' — переключение на другой узел\\
-''acct_stop_reason_CoA_Disconnect'' — закрытие по CoA disconnect\\
+''acct_stop_reason_CoA_Disconnect'' — CoA disconnect\\
 Из fastPCRF:\\
-''acct_stop_reason_source_reboot'' — обнаружен рестарт fastDPI по уменьшению значений счетчиков\\
+''acct_stop_reason_source_reboot'' — обнаружен рестарт fastDPI\\
 ''acct_stop_reason_change_session_id'' — изменение sessionId\\
-''acct_stop_reason_transfer_session_id'' — передача sessionId другому IP\\
+''acct_stop_reason_transfer_session_id'' — перенос sessionId\\
-''acct_stop_reason_fastdpi_acct_on'' — fastDPI прислал Acct-On/Acct-Off\\
+''acct_stop_reason_fastdpi_acct_on'' — получен Acct-On/Acct-Off\\
-''acct_stop_reason_suspended'' — сессия переведена в состояние suspended по отваливанию RADIUS\\
+''acct_stop_reason_suspended'' — сессия приостановлена из-за недоступности RADIUS\\
+''acct_stop_reason_ppp_changed_IPv6_prefix'' — изменен IPv6-префикс\\
-''acct_stop_reason_ppp_changed_IPv6_prefix'' — ppp Pool DHCPv6 Renew вернул другой префикс\\
+''acct_stop_reason_ppp_missing_IPv6_prefix'' — отсутствует IPv6-префикс
-''acct_stop_reason_ppp_missing_IPv6_prefix'' — ppp Pool DHCPv6 Renew вообще не вернул префикс\\

Аккаунт

Настройки

Различия

Различия

Что вы хотели найти?