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 | Description |
---|---|
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 | Fields |
---|---|
interface-profile | 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 | |
filter-profile | counter–Counter name configured at the [edit firewall filter filter-name term rule-name then count counter-name] hierarchy level |
mib-profile | object-names–Set of SNMP object identifiers (OIDs) |
routing-engine-profile | 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 | |
class-usage-profile | 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.