Accounting – traffic accounting

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
enable_acct=1
In this case user traffic volume data will be transmitted via the Radius Accounting protocol using fastPCRF rather than NetFlow.
  • you need to activate the billing netflow-statistics collection option (in the fastdpi.conf), for example:
    # statistics on the subscriber's billing
netflow=4
    # timeout for statistics to be sent
netflow_timeout=60
netflow_as_direction=1
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).
  • service 9 - the billing statistics export - has to be activated for the subscriber. It means that Access-Request reply should contain the following VasExperts-Enable-Service="9:on" attribute
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.

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

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

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:

	# To change traffic direction in accounting Radius-attributes
	# 0 (default) - no changes
	# 1 - swap the incoming/outgoing traffic counters
acct_swap_dir=0
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 network stack configuration may be required.

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:

########################################################
# 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

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.

When you restart or stop fastPCRF, all running accounting sessions are interrupted
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.

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:

# 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

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 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)

List of acct_stop_reason values

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:
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
acct_stop_reason_ppp_missing_IPv6_prefix — ppp Pool DHCPv6 Renew did not return a prefix at all