Accounting — traffic accounting (Service 9) [Документация VAS Experts]

This is an old revision of the document!


Accounting — traffic accounting (Service 9)

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.

To enable RADIUS accounting in /etc/dpi/fastdpi.conf, set the following parameters:

  • Enable accounting:
    enable_acct=1
  • Enable Netflow statistics for billing:
    # Subscriber billing statistics
    netflow=4
    # Statistics transmission timeout
    netflow_timeout=60
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.
  • Enable local user authentication:
    enable_auth=1
  • Assign service 9 (statistics export for billing) to the subscriber. The Access-Request response must include the following attribute:
    VasExperts-Enable-Service=“9:on”
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.

Additional Settings

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.

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:

acct_auth_sync=1

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.

Additionally, you can specify a delay between the Acct-Stop confirmation and the sending of the Access-Request:

acct_auth_sync_delay=0

The value is specified in seconds. This is used to account for processing delays in the billing system.

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.

To change the direction, use the following setting:

acct_swap_dir=0
  • 0 — no change;
  • 1 — reverse the direction.

Rating Group Settings

Rating groups can be used to track traffic in detail.

The following settings are available:

  • Number of groups:
    rating_group_count=0

    Default value: 0

  • Maximum number of subscribers per rating group:
    rating_group_max_subs=0

    Default value: 0 (RG disabled)

A value of “0” means that the feature is disabled.

The rating group storage is initialized only when billing statistics are enabled.

The amount of memory required to store rating group statistics is calculated using the following formula:

32 * rating_group_count * rating_group_max_subs * num_thread

where:

  • 32 bytes — the size of counters per group;
  • rating_group_count — the number of groups;
  • rating_group_max_subs — the maximum number of subscribers;
  • num_thread — the number of processing threads.

Calculation example:

rating_group_count = 256
rating_group_max_subs = 10000
num_thread = 8

memory_required = 32 * 256 * 10000 * 8 = 625M
Under heavy load, the accounting data stream from fastDPI may exceed the processing capacity of fastPCRF. In this case, network stack tuning is required.

The primary source of events for the start and end of accounting sessions is fastDPI, while the accounting database is maintained in fastPCRF. fastDPI transmits raw traffic data, and fastPCRF aggregates it and generates RADIUS messages.

Communication between fastDPI and fastPCRF takes place via an internal network protocol. Message loss can result in incorrect session states (for example, the absence of an Acct-Stop or Acct-Start).

To improve reliability, a pending queue is used, which mitigates short-term unavailability of fastPCRF.

PCRF Request Queue Settings:

  • Maximum request timeout (seconds):
    pcrf_pending_queue_timeout=300
  • Maximum queue size:
    pcrf_pending_queue_size=10000

Only critical messages (such as Acct Start/Stop) are placed in the queue. If the retention time or queue size is exceeded, older entries are deleted.

Internal Structure

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.

The CLI allows you to:

  • manage sessions (start/stop);
  • view status and statistics.
When fastPCRF is restarted or stopped, all current accounting sessions are deleted.
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.

Restarting fastDPI

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:

acct_fastdpi_session_stop=1

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

Was this information helpful?