Flat-File Accounting Overview

Accounting statistics can be collected from the Packet Forwarding Engine and reported in an XML flat file, which both contains and describes the data. Starting in Junos OS Release 16.1R4, you can use a flat-file profile that acts as a template to define attributes for accounting flat files.

Subscriber service accounting statistics are typically collected based on RADIUS Acct-Start and Acct-Stop messages that are sent to a RADIUS server individually or in bulk.

Starting in Junos OS Release 17.1R1, you can alternatively configure service-filter-based accounting statistics to be recorded per subscriber in a local flat file that is not automatically forwarded to a RADIUS server. This configuration collects the running total service statistics per interface family. Service accounting is initiated when the service profile is attached to the interface, whether by a static configuration or a RADIUS Change of Authorization (CoA) message.

When the accounting file is created, a file header is also created if the file format is IP Detail Record (IPDR). The header is not created if the format is comma-separated variable (CSV). The file header includes the following information:

• XML namespace—Static link to the World Wide Web Consortium (W3C) organization’s XML Schema Instance (XSI) definition.

• Schema version—Configurable name of the schema that defines the information conveyed in the accounting file. The schema version is associated with a specific XML format and output based on the flat-file profile configuration that is used for the business purpose. This structure enables the XML-formatted contents of the file to be correctly interpreted by the service provider’s external file processor.

• NAS ID—Name of the BNG host (network access server) where the accounting statistics are collected.

• File creation timestamp—UTC time zone date and time when the accounting file was created.

• File ID—Number identifying the file. The ID is incremented when a new accounting file is created and can range from 1 through 2,147,483,647.

For example, consider the following sample header for an accounting file for Extensible Subscriber Services Manager (ESSM) business subscribers:

Table 1 lists the elements and their values in the sample header.

You can configure the following options for flat-file accounting at the [edit accounting-options file filename] hierarchy level:

• Maximum size of the accounting file.

• Number of files that are saved before overwriting.

• One or more sites where the files are sent for archiving.

• Frequency at which the files are transferred to an archive site.

• Start time for file transfer.

• Compression for the transferred files.

• Local backup on the router for files when transfer fails.

• Whether accounting files are saved when a change in primary role occurs for both the new primary Routing Engine and the new backup Routing Engine or for only the new primary Routing Engine.

• How long files are kept before being deleted from the local backup directory.

You can also create one or more flat-file profiles at the [edit accounting-options flat-file-profile profile-name] hierarchy level that act as templates to specify the following attributes for new accounting files when they are created:

• Statistics fields that you want to collect, such as egress statistics or ingress statistics fields.

• Name and format of the accounting file.

• Frequency at which the Packet Forwarding Engine is polled for the statistics.

• Schema version.

Archive sites provide security and storage for the accounting files, which are transferred at regular intervals. When more than one archive site is configured, the router attempts to transfer the files to the first site on the list. If that fails, the router tries each of the other sites in turn until the transfer either succeeds for one site or fails for all sites. If you configure the last site in the list to be a local directory on the router rather than another remote site, then the files are backed up locally if all remote sites fail. The failed files are simply stored in the designated site. They are not automatically resubmitted to the archival sites. You must use an event script or some other means to have these files resubmitted. Any files remaining in the local directory are deleted when the cleanup-interval expires.

Alternatively, you can use the backup-on-failure statement at the [edit accounting-options file filename] hierarchy level to back up the files locally if all the remote attempts fail. If that occurs, the router compresses the accounting files and backs them up to the /var/log/pfedBackup/ directory. Whenever any of the archive sites is reachable, the router attempts to transfer the data from /var/log/pfedBackup/ to that site in compressed format. If the transfer of the backed-up files to the reachable site fails, the system tries to transfer the files to any other site that becomes reachable during the transfer interval. Any files that fail to transfer are compressed and kept in /var/log/pfedBackup/ until an archival site is reachable and the files are successfully transferred. Any files that remain in that directory are deleted when the cleanup-interval expires.

If the backup Routing Engine does not have access to the archive site—for example, when the site is not connected by means of an out-of-band interface or when the path to the site is routed through a line card—you can ensure that the backup Routing Engine’s accounting files are backed up by using the push-backup-to-master statement at the [edit accounting-options file filename] hierarchy level. When a change in primary role occurs, the new backup Routing Engine saves its files to the /var/log/pfedBackup/ directory. The primary Routing Engine subsequently includes these files when it sends its own accounting files to the archive site at every transfer interval.

To conserve resources during transfer of accounting files and at the archive site, use the compress statement at the [edit accounting-options file filename] hierarchy level to compress the files when they are transferred. This option is disabled by default.

A system logging message is generated when a transfer succeeds (transfer-file: Transferred filename) or fails (transfer-file failed to transfer). In the event of a failure, an error message is logged to indicate the nature of the failure.