| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| en:dpi:bras_bng:radius_integration:radius_accounting [2024/11/29 10:25] – elena.krasnobryzh | en:dpi:bras_bng:radius_integration:radius_accounting [2026/03/26 08:10] (current) – elena.krasnobryzh |
|---|
| {{tag>Services "Service 9" "RADIUS Accounting" "NetFlow Collection for Billing"}} | {{tag>Services "Service 9" "RADIUS accounting" "Netflow collection for billing"}} |
| ====== Accounting – traffic accounting====== | ====== Accounting — traffic accounting (Service 9)====== |
| {{indexmenu_n>3}} | {{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 RADIUS accounting. FastDPI processes subscriber traffic and generates NetFlow statistics, which are forwarded to FastPCRF. FastPCRF then aggregates the data, converts it into the RADIUS Accounting format, and sends it to the RADIUS server. |
| 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|netflow-statistics]] collection option (in the fastdpi.conf), for example: | To enable RADIUS accounting in **''/etc/dpi/fastdpi.conf''**, set the following parameters: |
| <code> | * Enable accounting:<code bash>enable_acct=1</code> |
| # statistics on the subscriber's billing | * Enable Netflow statistics for billing:<code bash> |
| | # Subscriber billing statistics |
| netflow=4 | netflow=4 |
| # timeout for statistics to be sent | # Statistics transmission timeout |
| netflow_timeout=60 | netflow_timeout=60</code> |
| 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#fastdpi_l3_bras_setup|local users authentication]] (''enable_auth=1'' in the fastdpi.conf configuration file) | <note important>Data on traffic volume is transmitted to the billing system via the RADIUS Accounting protocol through fastPCRF, rather than directly via Netflow.\\ |
| | The ''netflow'' parameter is a bit mask and can take combined values. For example, to enable both accounting and full statistics (8) simultaneously, you must specify ''netflow=12''.</note> |
| |
| * [[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 | * Enable local user authentication:<code bash>enable_auth=1</code> |
| | * Assign service 9 (statistics export for billing) to the subscriber. The Access-Request response must include the following attribute: <code>VasExperts-Enable-Service="9:on"</code> |
| |
| <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 authentication:** IPv4 and IPv6 traffic are accounted for in separate sessions. If a subscriber has both an IPv4 address and an IPv6 prefix, two independent accounting sessions are created.\\ |
| | **For PPPoE:** when IPv4 and IPv6 addresses are assigned within a single RADIUS request, accounting is performed in a single 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. | ===== Additional Settings ===== |
| |
| [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// | When fastPCRF starts up, it sends an Accounting-Request to the RADIUS server with the attribute ''Acct-Status-Type=Accounting-On'', and when it shuts down, it sends ''Accounting-Off''. These requests include NAS attributes that identify the server and ''Acct-Session-Id=0''. A similar Accounting-On request is sent when switching to a backup RADIUS server. |
| |
| <code> | Some billing systems require synchronization of the authorization and accounting processes: the current accounting session must be properly terminated before sending an Access Request. To enable this mode, use the following parameter: |
| | <code bash> |
| acct_auth_sync=1 | acct_auth_sync=1 |
| | </code> |
| |
| # [SSG 9.5.3+] Delay in seconds when synchronizing acct and auth (LanBilling) | When synchronization is enabled, a check is performed to verify whether an active accounting session exists for the subscriber's IP address before sending the Access-Request. If a session exists, an Acct-Stop is sent, confirmation is awaited, and then authorization is performed. |
| # 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 | |
| |
| | Additionally, you can specify a delay between the Acct-Stop confirmation and the sending of the Access-Request: |
| | <code bash> |
| | acct_auth_sync_delay=0 |
| </code> | </code> |
| | The value is specified in seconds. This is used to account for processing delays in the billing system. |
| |
| 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. | You can configure how traffic directions are interpreted. By default: |
| | * Incoming traffic — from the network to the subscriber; |
| | * Outgoing traffic — from the subscriber to the network. |
| |
| [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: | To change the direction, use the following setting: |
| | <code bash> |
| | acct_swap_dir=0 |
| | </code> |
| | * 0 — no change; |
| | * 1 — reverse the direction. |
| |
| <code> | ===== Rating Group ===== |
| # 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:fastdpi:net_points|network stack configuration]] may be required.</note> | A Rating Group (RG) is used to break down subscriber traffic accounting in RADIUS Accounting. RGs can only be used if Service 9 (statistics export for billing) is enabled. |
| |
| 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: | ==== Configuring RG in fastDPI ==== |
| <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) | RG storage and processing settings: |
| # 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 ===== | * Number of groups: <code bash>rating_group_count=0</code> Default value: 0 — RG disabled. |
| The accounting database is placed in fastPCRF and is in-memory. DB is two-level: | * Maximum number of subscribers with RG: <code bash>rating_group_max_subs=0</code> Default value: 0 — RG disabled. |
| * 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. | The RG storage is initialized only if billing statistics are enabled. |
| |
| <note important>When you restart or stop fastPCRF, all running accounting sessions are interrupted</note> | The amount of memory required to store RG statistics is calculated using the following formula: |
| | <code bash> |
| | memory_required = 32 * rating_group_count * rating_group_max_subs * num_thread |
| | </code> |
| | where: |
| | * ''32'' — the size of counters per group (in bytes); |
| | * ''rating_group_count'' — the number of groups; |
| | * ''rating_group_max_subs'' — the maximum number of subscribers; |
| | * ''num_thread'' — the number of processing threads. |
| |
| <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> | Sample calculation for 10,000 subscribers, 256 rating groups, and 8 processing threads—625 MB of memory is required: |
| | <code bash> |
| | rating_group_count = 256 |
| | rating_group_max_subs = 10000 |
| | num_thread = 8 |
| | memory_required = 32 * 256 * 10000 * 8 = 625M |
| | </code> |
| |
| ===== FastDPI restart ===== | <note important>Under heavy load, the flow of accounting data from fastDPI may exceed the processing capacity of fastPCRF. In this case, the network stack must be tuned.</note> |
| {{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. | {{anchor:acct-pending-queue}} |
| |
| In SSG 9.5.3+, two possible processing strategies are regulated by the fastpcrf.conf parameter: | ==== Transmission of RG Statistics to RADIUS Accounting ==== |
| <code> | |
| # How to handle a fastdpi-server restart: | RG statistics are transmitted in separate Interim-Update packets. Only data for non-zero RGs is transmitted.\\ |
| # 0 - when stopping/starting fastDPI, send to Radius only Accounting-Off/Accounting-On | Due to the RADIUS packet size limit (4096 bytes), RG data may be split across multiple Interim-Update packets. |
| # specifying NAS-attributes of the fastDPI-server, sessions for this fastDPI-server | |
| # stop without sending Acct-Stop. | A new VSA, ''VasExperts-Acct-Type'' (id=28, vendor=43823, integer), is used to identify the packet type, with the following values: |
| # 1 - when stopping/starting fastDPI, send to Radius Acct-Stop for all sessions from this fastDPI | * ''0'' — standard Interim Update Accounting; |
| # Accounting-Off/Accounting-On do not send fastdpi for this. | * ''1'' — RG data. |
| # Default value: 1 | |
| acct_fastdpi_session_stop = 1 | Each RG and its counters are transmitted in a **single** VSA with the following attributes: |
| | * VasExperts-Acct-Rating-Group (short, 16-bit) — RG number; |
| | * VasExperts-Acct-Input-Octets-64; |
| | * VasExperts-Acct-Output-Octets-64; |
| | * VasExperts-Acct-Input-Packets-64; |
| | * VasExperts-Acct-Output-Packets-64. |
| | |
| | Packet and byte counters for each direction are output according to the <code>acct_swap_dir</code> option (as in Accounting). |
| | |
| | Features of RG transmission: |
| | * RGs are optional; if the subscriber does not have an RG, the data is not transmitted; |
| | * if RADIUS does not acknowledge receipt of the RG packet, it is not resent—the latest data will be sent in the next Interim-Update; |
| | * if the subscriber has RG statistics, the current RG data is sent before sending the Acct-Stop session. |
| | |
| | ==== Setting the RG During Subscriber Authentication ==== |
| | |
| | The RG is set at the subscriber level during authentication via a special service profile 9 named 'RG': |
| | <code bash> |
| | VasExperts-Service-Profile :="9:RG" |
| </code> | </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: | RG statistics can only be collected if Service 9 (bill stat) is enabled. If Service 9 is disabled, RG is also disabled. |
| |
| ✔ 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''; | Examples: |
| | * Service 9 enabled, RG disabled (standard RADIUS Accounting): <code bash>VasExperts-Enable-Service :="9:on"</code> |
| | * Service 9 enabled, RG enabled (RG data transmission): <code bash>VasExperts-Service-Profile :="9:RG"</code> |
| | * Service 9 disabled, RG disabled (RADIUS Accounting not sent): <code bash>VasExperts-Enable-Service :="9:off"</code> |
| |
| ✔ 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. | ===== Internal Structure ===== |
| | {{anchor:internals}} |
| |
| Actions of the Radius server when receiving Acct-On/Acct-Off: | The accounting database is stored in fastPCRF and runs in memory. It has a two-level structure: |
| | * raw level — storage of raw data by IP address; |
| | * aggregation level — grouping of data into accounting sessions. |
| |
| * if NAS-attributes (NAS-Identifier and/or NAS-IP-Address) refer to fastDPI, all acct-sessions initiated by this fastDPI should be closed; | The CLI allows you to: |
| * if NAS-attributes identify fastPCRF, all active acct sessions should be closed (all sessions from fastDPI that are served by this fastPCRF) | * manage sessions (start/stop); |
| | * view status and statistics. |
| |
| =====List of acct_stop_reason values===== | <note important>When fastPCRF is restarted or stopped, all current accounting sessions are deleted.</note> |
| ''acct_stop_reason_unspecified'' — the reason is not explicitly stated\\ | |
| ''acct_stop_reason_user_request'' — explicit session termination by subscriber's signal or when creating a new session\\ | |
| ''acct_stop_reason_idle_timeout'' — session termination on inactivity timeout\\ | |
| ''acct_stop_reason_session_expired'' — session termination at the end of the time allotted for the session\\ | |
| ''acct_stop_reason_admin_reset'' — breakup at admin's request (CoA Disconnect-Request)\\ | |
| ''acct_stop_reason_lost_service'' — closure by DHCP-NAK or service disconnection 9\\ | |
| ''acct_stop_reason_NAS_error'' — errors have been detected in the request\\ | |
| ''acct_stop_reason_double_secondary_key'' — session break with the same unique secondary key\\ | |
| ''acct_stop_reason_coa_reauth'' — CoA reauth\\ | |
| ''acct_stop_reason_callback'' — stop current session due to reauthorization\\ | |
| ''acct_stop_reason_no_auth_response'' — no response to authorization request\\ | |
| ''acct_stop_reason_NAS_switch'' — switching to another SCAT\\ | |
| ''acct_stop_reason_CoA_Disconnect'' — CoA disconnect closure\\ | |
| |
| From fastPCRF:\\ | <note important>When fastDPI is restarted, the traffic counters are reset. Upon startup, an Accounting-On command is sent; upon shutdown, an Accounting-Off command is sent, along with the corresponding NAS attributes.</note> |
| ''acct_stop_reason_source_reboot'' — fastDPI restart by decreasing counter values was detected\\ | |
| ''acct_stop_reason_change_session_id'' — sessionId change\\ | |
| ''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_ppp_changed_IPv6_prefix'' — ppp Pool DHCPv6 Renew returned a different prefix\\ | ===== Restarting fastDPI ===== |
| ''acct_stop_reason_ppp_missing_IPv6_prefix'' — ppp Pool DHCPv6 Renew did not return a prefix at all\\ | {{anchor:fastdpi_restart}} |
| |
| | When fastDPI starts and stops, it sends accounting-on/accounting-off commands to fastPCRF, which are used to close the current sessions. |
| | |
| | This behavior is controlled by the following parameter: |
| | <code bash> |
| | acct_fastdpi_session_stop=1</code> |
| | |
| | Two modes are available: |
| | * 1 — When fastDPI starts or stops, an Acct-Stop is sent to all active sessions; |
| | * 0 — Only Accounting-On/Accounting-Off messages are sent, without individual Acct-Stop messages. |
| | |
| | The mode that sends an Acct-Stop message ensures that sessions are terminated correctly, but places an increased load on the RADIUS server. The alternative mode reduces the load, but requires the source to be correctly identified based on NAS attributes. |
| | |
| | For proper operation, you must: |
| | * Set unique ''attr_nas_ip'' and ''attr_nas_id'' values for each fastDPI; |
| | * Configure ''radius_attr_nas_ip_address'' and ''radius_attr_nas_id'' for fastPCRF. |
| | |
| | RADIUS-side processing: |
| | * if the NAS attributes match fastDPI, sessions for that node are closed; |
| | * if fastPCRF, all active sessions are closed. |
| | |
| | ===== List of acct_stop_reason values ===== |
| | ''acct_stop_reason_unspecified'' — reason not specified\\ |
| | ''acct_stop_reason_user_request'' — termination initiated by the subscriber or upon creation of a new session\\ |
| | ''acct_stop_reason_idle_timeout'' — inactivity timeout\\ |
| | ''acct_stop_reason_session_expired'' — session timeout\\ |
| | ''acct_stop_reason_admin_reset'' — termination at the administrator's request (CoA Disconnect-Request)\\ |
| | ''acct_stop_reason_lost_service'' — service disconnection or DHCP-NAK\\ |
| | ''acct_stop_reason_NAS_error'' — request error\\ |
| | ''acct_stop_reason_double_secondary_key'' — secondary key conflict\\ |
| | ''acct_stop_reason_coa_reauth'' — CoA reauth\\ |
| | ''acct_stop_reason_callback'' — termination due to re-authorization\\ |
| | ''acct_stop_reason_no_auth_response'' — no authorization response\\ |
| | ''acct_stop_reason_NAS_switch'' — switch to another node\\ |
| | ''acct_stop_reason_CoA_Disconnect'' — CoA disconnect\\ |
| | |
| | From fastPCRF:\\ |
| | ''acct_stop_reason_source_reboot'' — fastDPI reboot detected\\ |
| | ''acct_stop_reason_change_session_id'' — sessionId changed\\ |
| | ''acct_stop_reason_transfer_session_id'' — session ID transferred\\ |
| | ''acct_stop_reason_fastdpi_acct_on'' — Acct-On/Acct-Off received\\ |
| | ''acct_stop_reason_suspended'' — session suspended due to RADIUS unavailability\\ |
| | ''acct_stop_reason_ppp_changed_IPv6_prefix'' — IPv6 prefix changed\\ |
| | ''acct_stop_reason_ppp_missing_IPv6_prefix'' — IPv6 prefix missing |
