Graph Category List¶
There are a several different categories of graph data that the firewall can plot. Each category is covered here, but not all categories will be visible on every firewall. Some graphs must be enabled separately or will only be present if a specific feature or piece of hardware is enabled.
The graphs under the System category show a general overview of the system utilization, including CPU usage, memory usage, and firewall states.
The Mbuf Clusters graph plots the network memory buffer cluster usage of the firewall. Firewalls with many interfaces, or many CPU cores and NICs that use one interface queue per core, can consume a large number of network memory buffers. In most cases, this usage will be fairly flat, but depending on various circumstances, such as unusually high load, the values may increase. If the usage approaches the configured maximum, increase the number of buffers.
Refer to Hardware Tuning and Troubleshooting for information on how to increase the amount of mbufs available to the OS.
The Mbuf Clusters graph contains the following data sources:
The current number of consumed mbuf clusters
The number of cached mbuf clusters
The total of Current and Cache
The maximum allowed number of mbuf clusters
The Memory graph shows the system RAM usage broken down into multiple areas. These areas are described in detail at Memory Management.
Active (in use) memory pages referenced by userland (non-kernel).
Memory pages which were in use but have not been referenced recently.
Memory available for immediate use.
Memory used by the operating system for caching. On systems using ZFS, this is the ZFS ARC cache (23.05+). On UFS systems, it is the UFS directory hash.
Memory allocated by the kernel, including the kernel itself, which cannot be paged/swapped and cannot be freed until explicitly released.
In the OS, the ZFS ARC cache and UFS buffers sizes are included in wired memory. In the graphs on pfSense Plus software version 23.05 and later, however, these values are removed from the Wired total and graphed separately. ZFS ARC usage is graphed under Cache and UFS buffers are graphed under Buffers.
Similar to Wired, but memory wired by user processes, not the kernel.
Memory pages which are considered “dirty” and are due to be “cleaned”.
Memory used for UFS buffers.
The processor graph shows CPU usage for the firewall using the following data sources:
- User Utilization
The amount of processor time consumed by user processes.
- Nice Utilization
The amount of processor time consumed by processes with a high priority.
- System Utilization
The amount of processor time consumed by the operating system and kernel.
The amount of processor time consumed by interrupt handling, which is processing hardware input and output, including network interfaces.
The number of running processes.
The states graph shows the number of system states but also breaks down the value in several ways.
- State Changes
The number of state changes per second, or “churn”. A high value from this source would indicate a rapid number of new or expiring connections.
- Filter States
The total number of state entries in the states table.
- NAT States
The total number of state entries involving NAT (e.g. outbound NAT, port forwards, 1:1 NAT, etc).
- Source Addresses
The number of active unique source IP addresses.
- Destination Addresses
The number of active unique destination IP addresses.
Traffic graphs shows the amount of bandwidth used on each available interface in bits per second notation. The Graph list contains entries for each assigned interface, as well as IPsec and individual OpenVPN clients and servers.
The traffic graph is broken down into several data sources. Aside from the
total, each has an IPv4 and IPv6 equivalent. The IPv6 data sources have
appended to the name.
The rate of traffic entering this interface that was passed into the firewall.
The rate of traffic leaving from this interface that was passed out of the firewall.
The rate of traffic attempting to reach this interface that was blocked from entering the firewall.
The rate of traffic attempting to leave this interface that was blocked from leaving the fiewall.
- inpass total
The total rate of traffic (IPv4 and IPv6) that was passed inbound.
- outpass total
The total rate of traffic (IPv4 and IPv6) that was passed outbound.
The terms “inbound” and “outbound” on these graphs are from the perspective of the firewall itself. On an external interface such as a WAN, “inbound” traffic is traffic arriving at the firewall from the Internet and “outbound” traffic is traffic leaving the firewall going to a destination on the Internet. For an internal interface, such as LAN, “inbound” traffic is traffic arriving at the firewall from a host on the LAN, likely destined for a location on the Internet and “outbound” traffic is traffic leaving the firewall going to a host on the LAN.
The packet graphs work much like the traffic graphs and have the same names for the data sources, except instead of reporting based on bandwidth used, it reports the number of packets per second (pps) passed. The Graph list contains entries for each assigned interface, as well as IPsec and individual OpenVPN clients and servers.
Packets Per Second (pps) is a better metric for judging hardware performance than Traffic throguhput as it more accurately reflects how well the hardware handles packets of any size. A circuit may be sold on a certain level of bandwidth, but hardware is more likely to be bottlenecked by an inability to handle a large volume of small packets. In situations where the hardware is the limiting factor, the Packets graph may show a high plateau or spikes while the traffic graph shows usage under the rated speed of the line.
The Quality category contains Graph entries that track the quality of WAN or WAN-like interfaces such as interfaces with a gateway specified or those using DHCP or PPPoE. The firewall contains one Graph entry per gateway, including gateways that were configured previously, but no longer exist. Graph data files for old gateways are not automatically removed so that historical data is available for future reference.
The following data sources are used to track gateway reliability:
- Packet Loss
The percentage of attempted pings to the monitor IP address that were lost. Loss on the graph indicates connectivity issues or times of excessive bandwidth use where pings were dropped.
- Delay Average
The average delay (Round-trip time, RTT) on pings sent to the monitor IP address. A high RTT means that traffic is taking a long time to make the round trip from the firewall to the monitor IP address and back. A high RTT could be from a problem on the circuit or from high utilization.
- Delay Standard Deviation
The standard deviation on the RTT values. The standard deviation gives an impression of the variability of the RTT during a given calculation period. A low standard deviation indicates that the connection is relatively stable. A high standard deviation means that the RTT is fluctuating up and down over a large range of values, which could mean that the connection is unstable or very busy.
The Captive Portal category contains Graph entries for each Captive Portal zone, past and present. Graph data files for old zones are not automatically removed.
The Concurrent graph choice shows how many users are logged in at a given point in time. As users log out or their sessions expire, this count will go down. A large number of concurrent users will not necessarily cause a strain on the portal, but it can be useful for judging overall capacity and bandwidth needs.
- Logged In
The Logged In graph shows the number of login events that occur during each polling interval. This is useful for judging how busy the captive portal daemon is at a given point in time. A large number of users logging in around the same time will put more stress on the portal daemon compared to logins that are spread out over the course of a day.
The NTP graph displays statistics about the NTP service and clock quality. This graph is disabled by default because it is not relevant for most use cases. The graph can be enabled at Services > NTP. On that page, check Enable RRD Graphs of NTP statistics.
Combined clock difference between from server relative to this host.
- System Jitter (sjit)
Combined system jitter, which is an estimate of the error in determining the offset.
- Clock Jitter (cjit)
Jitter computed by the clock discipline module.
- Clock Wander (wander)
Clock frequency stability expressed in parts per million (PPM)
- Frequency Offset (freq)
Offset relative to hardware clock (In PPM)
- Root Dispersion (disp)
Total difference between the local clock and the primary reference clock across the network.
The queue graphs are a composite of each traffic shaper queue. Each individual queue is shown, represented by a unique color.
The Queues category shows individual queue usage in bytes.
The QueueDrops category shows a count of packet drops from each queue.
The DHCP category contains a graph for each interface with a DHCP server enabled. The data sources shown for DHCP are:
The number of leases in use out of the configured DHCP range for the interface.
- Static Leases
The number of static mapping leases configured for the interface.
- DHCP Range
The total size of the DHCP pool available for use on the interface.
If the Leases count approaches the Range value, then a larger pool may be required for the interface. Static mappings exist outside the range, so they do not factor into the amount of leases consumed in the pool.
On select 3G/4G devices, the firewall is able to collect signal strength data for the Cellular graph. The signal strength is the only value plotted on the graph.
The Wireless category is present on systems containing an 802.11 wireless network device that is enabled and in-use as a client (Infrastructure, BSS mode). The following data sources are collected and displayed when acting as a wireless client:
The signal-to-noise ratio for the AP the client is connected to.
The wireless channel number used to reach the AP.
The wireless data rate to the AP.
The VPN Users category shows the number of OpenVPN users logged in concurrently for each individual OpenVPN server.