| |
| dpi:bras_bng:radius_integration:radius_accounting:start [2024/07/29 11:21] – ↷ Операцией перемещения обновлены ссылки elena.krasnobryzh | dpi:bras_bng:radius_integration:radius_accounting:start [Дата неизвестна] (текущий) – удалено - внешнее изменение (Дата неизвестна) 127.0.0.1 |
|---|
| ====== 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:start#общие_настройки_экспрота_статистики|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:start#настройка_bras_l3_в_fastdpi|авторизацию локальных пользователей]] (''enable_auth=1'' в файле конфигурации fastdpi.conf) | |
| |
| * Пользователю должна быть подключена [[dpi:dpi_components:platform:dpi_billing:start|услуга 9]] — экспорт статистики для биллинга. Это значит, что [[dpi:bras_bng:radius_integration:radius_auth_server_integration:radius_auth_response:start|ответ на 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:start|тюнинг сетевого стека]].</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:start|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 вообще не вернул префикс\\ | |
| |
