Accounting Profiles: An Alternative to SNMP Statistics

SNMP enables users to monitor network devices from a central location. Juniper Networks provides many different platforms that support SNMP on the Junos operating system (Junos OS). Junos OS includes an onboard SNMP agent that provides remote management applications with access to detailed information about the devices in the network. The SNMP agent exchanges network management information with the SNMP network management system (NMS). The agent responds to requests for information and actions from the manager. The SNMP manager collects information about network connectivity, activity, and events by polling managed devices.

When network problems occur, SNMP requests might not reach the device, or the SNMP replies might not reach the server. After the problem is resolved, the SNMP monitoring application gets the sum of the minutes and can only average it over the missing time spans. This means that the time you most need to know what is going on in your network is the time you are unable to get the statistics.

Delays and time-outs (where the response does not arrive before the SNMP monitor application times out) provide an equally poor view of the network. If the request is delayed, the time period between requests is not consistent, leading to poor data. If a time-out results in discarded packets, the device is likely wasting resources generating statistics that are being discarded.

Juniper Networks devices can collect various types of data about the traffic passing through the device using a feature called accounting profiles. You can set up accounting profiles to avoid the limitations of using SNMP polling. You can set up one or more accounting profiles that specify some common characteristics of the required data. Setting up accounting profiles provides you with persistent data even during network outages. This data can be transferred when the network is restored and can be used for troubleshooting and monitoring.

Understanding Accounting Profiles

Accounting profiles are implemented in the Packet Forwarding Engine process (pfed). The pfed process routinely requests interface statistics from the Packet Forwarding Engine to ensure that accurate values are cached in the Routing Engine kernel. Accounting profiles enable you to store these statistics in a file on the hard disk.

You can configure multiple accounting profiles, as described in Table 1.

Table 1: Types of Accounting Profiles

Type of Profile


Interface profile

Collects the specified error and statistic information

Filter profile

Collects the byte and packet counts for the counter names specified in the filter profile

MIB profile

Collects selected MIB statistics

Routing Engine profile

Collects selected Routing Engine statistics

Class usage profile

Collects class usage statistics

Each of these profile types have specific fields that can be recorded as shown in Table 2.

Table 2: Profile Types and Corresponding Fields

Profile Type



input-bytes–Input bytes

input-errors–Generic input error packets

input-multicast–Input packets arriving by multicast

input-packets–Input packets

input-unicast–Input unicast packets

output-bytes–Output bytes

output-errors–Generic output error packets

output-multicast–Output packets sent by multicast

output-packets–Output packets

output-unicast–Output unicast packets

rpf-check-bytes–Bytes failing the IPv4 reverse-path-forwarding check

rpf-check-packets–Packets failing the IPv4 reverse-path-forwarding check

rpf-check6-bytes–Bytes failing the IPv6 reverse-path-forwarding check

rpf-check6-packets–Packets failing the IPv6 reverse-path-forwarding check

unsupported-protocol–Packets for an unsupported protocol


counter–Counter name configured at the [edit firewall filter filter-name term rule-name then count counter-name] hierarchy level


object-names–Set of SNMP object identifiers (OIDs)


cpu-load-1–Average system load (number of processes in the run queue) over the last 1 minute

cpu-load-15–Average system load (number of processes in the run queue) over the last 15 minutes

cpu-load-5–Average system load (number of processes in the run queue) over the last 5 minutes

date–Date in YYYYMMDD format

host-name–Router hostname

memory-usage–Instantaneous active memory usage

time-of-day–Time of day in HHMMSS format

total-cpu-usage–Total CPU usage percentage

uptime–Time (in seconds) since last reboot


source-class–A set of named source classes

By saving these statistics locally, data values are recorded regardless of network conditions. Because the requests are generated locally, they are sent regardless of network conditions. By driving both sides locally, data is consistent and of higher quality. Handling data locally avoids encoding and decoding issues, providing better performance.

Related Documentation