Differences

This shows you the differences between two versions of the page.

--- en:dpi:bras_bng:radius_integration:radius_accounting [2024/11/29 10:25] – elena.krasnobryzh
+++ en:dpi:bras_bng:radius_integration:radius_accounting [2024/12/08 14:44] (current) – elena.krasnobryzh
@@ Line 1: / Line 1: @@
 {{tag>Services "Service 9" "RADIUS Accounting" "NetFlow Collection for Billing"}}
-====== Accounting – traffic accounting======
+====== Accounting – traffic accounting (service 9)======
 {{indexmenu_n>3}}
-FastPCRF supports the Radius accounting. FastDPI transmits subscribers' traffic and generates NetFlow statistics towards PCRF, which changes the format and sends it to Radius.
+FastPCRF supports the RADIUS accounting. FastDPI transmits subscribers' traffic and generates NetFlow statistics towards PCRF, which changes the format and sends it to RADIUS.
-Add the following parameters in **/etc/dpi/fastdpi.conf** to activate the Radius accounting:
+Add the following parameters in **/etc/dpi/fastdpi.conf** to activate the RADIUS accounting:
   * to enable accounting
 <code>enable_acct=1</code>
-<note important>In this case user traffic volume data will be transmitted via the Radius Accounting protocol using fastPCRF rather than NetFlow.</note>
+<note important>In this case user traffic volume data will be transmitted via the RADIUS Accounting protocol using fastPCRF rather than NetFlow.</note>
   * you need to activate the billing [[en:dpi:dpi_options:opt_statistics:statistics_settings|netflow-statistics]] collection option (in the fastdpi.conf), for example:
@@ Line 23: / Line 23: @@
   * [[en:dpi:dpi_components:platform:dpi_billing|service 9]] - the billing statistics export - has to be activated for the subscriber. It means that [[en:dpi:bras_bng:radius_integration:radius_auth_server_integration:radius_auth_response|Access-Request reply]] should contain the following VasExperts-Enable-Service="9:on" attribute
-<note important>**For DHCP authorization:** subscribers IPv4- and IPv6-addresses accounting is transmitted in separate sessions. If the subscriber is assigned an IPv4 address and an IPv6 subnet, then IPv4-accounting will be transmitted in one session, and IPv6 in another one including PD-prefix. \\ **For PPPoE authorization:** provided that IPv4 and IPv6 were given out with a single Radius request accounting will be transmitted in one session.</note>
+<note important>**For DHCP authorization:** subscribers IPv4- and IPv6-addresses accounting is transmitted in separate sessions. If the subscriber is assigned an IPv4 address and an IPv6 subnet, then IPv4-accounting will be transmitted in one session, and IPv6 in another one including PD-prefix. \\ **For PPPoE authorization:** provided that IPv4 and IPv6 were given out with a single RADIUS request accounting will be transmitted in one session.</note>
 ===== Additional Settings =====
-[Stingray Service Gateway 8.1+] When fastPCRF starts it sends the Accounting-Request request containing the ''Acct-Status-Type=Accounting-On'' attribute to the Radius server, when it terminates - the Accounting-Request containing the ''Acct-Status-Type=Accounting-Off'' attribute will be sent correspondingly. These requests also contain the ''Acct-Session-Id=0'' attribute and NAS attributes specifying the NAS server. ''Accounting-On'' is sent also in the event of switching to the backup Radius server.
+[Stingray Service Gateway 8.1+] When fastPCRF starts it sends the Accounting-Request request containing the ''Acct-Status-Type=Accounting-On'' attribute to the RADIUS server, when it terminates - the Accounting-Request containing the ''Acct-Status-Type=Accounting-Off'' attribute will be sent correspondingly. These requests also contain the ''Acct-Session-Id=0'' attribute and NAS attributes specifying the NAS server. ''Accounting-On'' is sent also in the event of switching to the backup RADIUS server.
 [Stingray Service Gateway 8.1+] Some billing systems require accounting and authorization requests to be syncronized: the accounting session has to be finished before sending an Access-Request. SSG does not syncronize accounting and authorization by default. To enable syncronization set the following parameter in //fastpcrf.conf//
@@ Line 36: / Line 36: @@
    # [SSG 9.5.3+] Delay in seconds when synchronizing acct and auth (LanBilling)
    # When the acct_auth_sync mode is enabled, the SSG, after receiving confirmation
-   # from Radius (billing) that Acct-Stop is accepted, immediately sends an Access-Request.
+   # from RADIUS (billing) that Acct-Stop is accepted, immediately sends an Access-Request.
    # In some cases, between the confirmation of Acct-Stop and the sending of Access-Request
    # it is need to insert a small delay so that all transients in billing
@@ Line 51: / Line 51: @@
 <code>
-	# To change traffic direction in accounting Radius-attributes
+	# To change traffic direction in accounting RADIUS-attributes
 	# 0 (default) - no changes
 	# 1 - swap the incoming/outgoing traffic counters
@@ Line 58: / Line 58: @@
 <note important> Note that Accounting-dataflow from the fastDPI can be so intense that fastpcrf  won't be able to handle all the incoming data flows. To meet the challenge a [[en:dpi:faq:fastdpi:net_points|network stack configuration]] may be required.</note>
-The start/end of the accounting session is usually initiated by fastDPI, but the internal accounting database is maintained in fastPCRF. FastDPI delivers traffic consumption raw data by subscriber to the database, while fastPCRF aggregates the data and converts it to the Radius Accounting format. The interaction between fastDPI and fastPCRF is handled through the exchange of internal messages over the network by closed protocol. In case of accounting lost internal messages might lead to an endless accounting session (lost "stop"), or to a situation without accounting session, although the subscriber actively consumes traffic (lost "start"). To prevent the loss of fastDPI internal start/finish accounting messages, fastDPI has a queue designed to smooth the short-term loss of communication between fastDPI and fastPCRF. This queue is regulated by the following parameters in fastdpi.conf:
+The start/end of the accounting session is usually initiated by fastDPI, but the internal accounting database is maintained in fastPCRF. FastDPI delivers traffic consumption raw data by subscriber to the database, while fastPCRF aggregates the data and converts it to the RADIUS Accounting format. The interaction between fastDPI and fastPCRF is handled through the exchange of internal messages over the network by closed protocol. In case of accounting lost internal messages might lead to an endless accounting session (lost "stop"), or to a situation without accounting session, although the subscriber actively consumes traffic (lost "start"). To prevent the loss of fastDPI internal start/finish accounting messages, fastDPI has a queue designed to smooth the short-term loss of communication between fastDPI and fastPCRF. This queue is regulated by the following parameters in fastdpi.conf:
 <code>########################################################
 # PCRF pending queue parameters
@@ Line 83: / Line 83: @@
 <note important>When you restart or stop fastPCRF, all running accounting sessions are interrupted</note>
-<note important>When restarting fastDPI, all traffic counters are also reset. When starting fastDPI the Accounting-On message with NAS attributes identifying this fastDPI is sent to the Radius; during a regular stop of fastDPI, a Accounting-Off message with NAS attributes of fastDPI is sent to the Radius.</note>
+<note important>When restarting fastDPI, all traffic counters are also reset. When starting fastDPI the Accounting-On message with NAS attributes identifying this fastDPI is sent to the RADIUS; during a regular stop of fastDPI, a Accounting-Off message with NAS attributes of fastDPI is sent to the RADIUS.</note>
 ===== FastDPI restart =====
@@ Line 93: / Line 93: @@
 <code>
 # How to handle a fastdpi-server restart:
-# 0 - when stopping/starting fastDPI, send to Radius only Accounting-Off/Accounting-On
+# 0 - when stopping/starting fastDPI, send to RADIUS only Accounting-Off/Accounting-On
 # specifying NAS-attributes of the fastDPI-server, sessions for this fastDPI-server
 # stop without sending Acct-Stop.
-# 1 - when stopping/starting fastDPI, send to Radius Acct-Stop for all sessions from this fastDPI
+# 1 - when stopping/starting fastDPI, send to RADIUS Acct-Stop for all sessions from this fastDPI
 # Accounting-Off/Accounting-On do not send fastdpi for this.
 # Default value: 1
@@ Line 102: / Line 102: @@
 </code>
-By default ''(acct_fastdpi_session_stop = 1)'', when starting/stopping fastDPI, Acct-Stop is sent for each active session. This leads to a heavy load on the Radius server. Therefore, the second strategy has been added ''(acct_fastdpi_session_stop = 0)'': send only Accounting-On when starting fastDPI and Accounting-Off when stopping fastDPI. The subtle point of this strategy is identifying the source of the Acct-On/Acct-Off message: The radius server must figure out which sessions should be closed by Acct-On/Acct-Off, and which ones  it should keep (it is relevant for configurations when there is one fastPCRF and several fastDPI). This is cкупгдфеув by the parameters:
+By default ''(acct_fastdpi_session_stop = 1)'', when starting/stopping fastDPI, Acct-Stop is sent for each active session. This leads to a heavy load on the RADIUS server. Therefore, the second strategy has been added ''(acct_fastdpi_session_stop = 0)'': send only Accounting-On when starting fastDPI and Accounting-Off when stopping fastDPI. The subtle point of this strategy is identifying the source of the Acct-On/Acct-Off message: The RADIUS server must figure out which sessions should be closed by Acct-On/Acct-Off, and which ones  it should keep (it is relevant for configurations when there is one fastPCRF and several fastDPI). This is cкупгдфеув by the parameters:
 ✔ for each fastdpi server (the option [[en:dpi:bras_bng:radius_integration:radius_auth_fastpcrf_setup|fdpi_server]] in fastpcrf.conf) must be specified its unique ''attr_nas_ip'' and ''attr_nas_id'';
@@ Line 108: / Line 108: @@
 ✔ to identify fastPCRF (which also sends Acct-On/Acct-Off at start/stop), use the parameters ''radius_attr_nas_ip_address'' and ''radius_attr_nas_id'' of the fastpcrf.conf configuration file.
-Actions of the Radius server when receiving Acct-On/Acct-Off:
+Actions of the RADIUS server when receiving Acct-On/Acct-Off:
   * if NAS-attributes (NAS-Identifier and/or NAS-IP-Address) refer to fastDPI, all acct-sessions initiated by this fastDPI should be closed;
@@ Line 133: / Line 133: @@
 ''acct_stop_reason_transfer_session_id'' — transferring sessionId to another IP\\
 ''acct_stop_reason_fastdpi_acct_on'' — fastDPI sent Acct-On/Acct-Off\\
-''acct_stop_reason_suspended'' — the session's been put on hold for Radius to fall off\\
+''acct_stop_reason_suspended'' — the session's been put on hold for RADIUS to fall off\\
 ''acct_stop_reason_ppp_changed_IPv6_prefix'' — ppp Pool DHCPv6 Renew returned a different prefix\\
 ''acct_stop_reason_ppp_missing_IPv6_prefix'' — ppp Pool DHCPv6 Renew did not return a prefix at all\\