Differences

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

--- en:dpi:bras_bng:radius_integration:radius_accounting:start [2023/10/26 14:20] – [Accounting – traffic accounting] elena.krasnobryzh
+++ en:dpi:bras_bng:radius_integration:radius_accounting:start [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1
@@ Line 1: / Line 1: @@
-====== Accounting – traffic accounting======
-{{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.
-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>
-  * you need to activate the billing [[en:dpi:dpi_options:opt_statistics:statistics_settings:start|netflow-statistics]] collection option (in the fastdpi.conf), for example:
-<code>
-    # statistics on the subscriber's billing
-netflow=4
-    # timeout for statistics to be sent
-netflow_timeout=60
-netflow_as_direction=1
-</code>
-<note important>Keep in mind that the ''netflow'' parameter is a bitmask: it allows several different values. For example, to enable accounting and full statisrics collection (8), you need to specify ''netflow=12'' (12 = 8 + 4).</note>
-  * you need to activate the [[en:dpi:bras_bng:general_setup:start#fastdpi_l3_bras_setup|local users authentication]] (''enable_auth=1'' in the fastdpi.conf configuration file)
-  * [[en:dpi:dpi_components:platform:dpi_billing:start|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:start|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>
-===== 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+] 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//
-<code>
-acct_auth_sync=1
-   # [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.
-   # 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
-   # passed and the Access-Request was successfully processed and an Access-Accept was received.
-   # This parameter defines the extent of this delay in seconds.
-   # Default = 0 (no delay).
-# acct_auth_sync_delay = 0
-</code>
-When synchronization is enabled, SSG checks whether the given IP address has an active accounting session before sending the Access-Request. If there is such session, DPI sends a Stop accounting request, waits for a response and only then sends an Access-Request authorization request.
-[Stingray Service Gateway 8.3+] There are different concepts of what is “incoming” and “outgoing” traffic. In case of SSG incoming traffic is the one that comes to the subscriber from inet, while outgoing is what goes to inet from the subscriber. Some systems are desined differently - you can invert directions in accounting for such cases. Use the parameter acct_swap_dir:
-<code>
-	# To change traffic direction in accounting Radius-attributes
-	# 0 (default) - no changes
-	# 1 - swap the incoming/outgoing traffic counters
-acct_swap_dir=0</code>
-<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:dpi_functionality:admin_faq:admin_faq_fdpi_ctrl_reqs|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:
-<code>########################################################
-# PCRF pending queue parameters
-	# PCRF pending queue is designed to smooth short-term PCRF inaccessibility
-	# Requests to PCRF may be binding (e.g. Acct Start/Stop)
-	# or optional for delivery (e.g. all authorization requests, - if such request
-	# disappeares, the subscriber will repeat it).
-	# Only the binding for delivery requests get into pending queue.
-	# Maximum time for a request being in the pending queue, sec (default=300 sec)
-	# Requests older than this time will not be sent to PCRF
-#pcrf_pending_queue_timeout=300
-	# Max size pending queue, default=10000 requests
-	# When this size is reached, the first requests in the queue will be deleted.
-#pcrf_pending_queue_size=10000</code>
-===== Internal design =====
-The accounting database is placed in fastPCRF and is in-memory. DB is two-level:
-  * The lower raw layer is responsible for storing data from fastDPI. The key here is the IP address.
-  * The upper level aggregation combines one or more raw-level records into an accounting session.
-Using CLI commands you can manipulate accounting data, start and end sessions and watch internal statistics.
-<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>
-===== FastDPI restart =====
-{{anchor:fastdpi_restart}}
-When starting/stopping, fastDPI sends accounting-on/accounting-off commands to fastPCRF. With these commands, fastPCRF closes the current acct-sessions of this fastDPI.
-In SSG 9.5.3+, two possible processing strategies are regulated by the fastpcrf.conf parameter:
-<code>
-# How to handle a fastdpi-server restart:
-# 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
-# Accounting-Off/Accounting-On do not send fastdpi for this.
-# Default value: 1
-acct_fastdpi_session_stop = 1
-</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:
-✔ for each fastdpi server (the option [[en:dpi:bras_bng:radius_integration:radius_auth_fastpcrf_setup:start|fdpi_server]] in fastpcrf.conf) must be specified its unique ''attr_nas_ip'' and ''attr_nas_id'';
-✔ 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:
-  * if NAS-attributes (NAS-Identifier and/or NAS-IP-Address) refer to fastDPI, all acct-sessions initiated by this fastDPI should be closed;
-  * if NAS-attributes identify fastPCRF, all active acct sessions should be closed (all sessions from fastDPI that are served by this fastPCRF)