MIB Viewer

Palo Alto

Last updated September 10, 2026

Unlike Cisco, Juniper, and Fortinet, Palo Alto's SNMP setup is primarily a GUI-driven workflow rather than a well-documented sequence of CLI commands - this guide reflects that rather than inventing CLI syntax Palo Alto itself doesn't document for this purpose.

Enabling SNMP (SNMPv2c or SNMPv3)

  1. Navigate to Device > Setup > Operations, then click SNMP Setup in the lower right.
  2. Enter the physical location and a contact (these populate the standard sysLocation/sysContact objects).
  3. Choose the SNMP version: V2c or V3.
    • For V2c, enter the community string directly on this page.
    • For V3, the page changes to show view and user configuration instead - you need at least one view and one user assigned to it.
  4. Click OK, then commit the configuration.

SNMP also needs to be explicitly enabled on whichever interface will answer queries - typically Device > Setup > Management, then check the SNMP box under Management Interface Settings.

Sending traps: a separate configuration path

This is the biggest structural difference from other vendors on this list: Palo Alto separates being polled (the SNMP Setup page above) from sending traps, which is configured as a Server Profile tied to log forwarding, not inside the SNMP Setup page itself.

  1. Go to Device > Server Profiles > SNMP Trap and add a new profile - name it, specify the SNMP version, the manager's IP address, and (for v2c) the community string to use when sending traps.
  2. Under Device > Log Settings, pick which log types/severities should actually generate a trap, and select the SNMP server profile you just created as the destination.

In other words: a firewall can be pollable over SNMP without sending a single trap, and can send traps without allowing any inbound SNMP queries at all - the two are independently configured and neither implies the other.

Verifying from the CLI

While configuration is GUI-first, the resulting settings can be inspected from the CLI:

show deviceconfig system snmp-setting

Model/platform differences

This workflow applies the same way across PA-Series firewalls. Panorama (Palo Alto's centralized management platform) has its own separate SNMP configuration, under its own Device tab in the Panorama web interface - configuring SNMP on Panorama does not configure it on the firewalls it manages, or vice versa; each is set up independently.

Common OIDs and MIBs

Palo Alto's own MIB, PAN-COMMON-MIB, lives under enterprises.25461 (1.3.6.1.4.1.25461) - but notably, CPU and memory specifically come from a standard, cross-vendor MIB instead, not a proprietary one. See the gotcha below for why that distinction matters in practice.

  • CPU - standard HOST-RESOURCES-MIB, not PAN-COMMON-MIB. hrProcessorLoad (1.3.6.1.2.1.25.3.3.1.2) reports processor load averaged over the last 60 seconds, same as it would on any generic HOST-RESOURCES-MIB-compliant device - the Palo Alto-specific part is that there are multiple instances of it, one per logical processor, and which instance means what is platform-specific. See the gotcha below.
  • Memory - also standard, hrStorageTable (1.3.6.1.2.1.25.2.3) - covers both management plane memory and data plane packet buffer, again via the generic HOST-RESOURCES-MIB rather than anything Palo Alto-specific.
  • Session utilization - PAN-COMMON-MIB's panSession subtree (1.3.6.1.4.1.25461.2.1.2.3). panSessionUtilization and panSessionMax give device-wide session load as a percentage and a ceiling - but on a multi-vsys deployment, see the gotcha below before assuming this is the whole picture.
  • Per-VSYS session data - panVsysTable (1.3.6.1.4.1.25461.2.1.2.3.9). Breaks session utilization and active session count down per virtual system, rather than device-wide.
  • High availability and GlobalProtect - panSysHAState/panSysHAPeerState report this unit's and its peer's HA status; panGPGWUtilizationPct and related objects under panGlobalProtect report GlobalProtect gateway tunnel utilization, for firewalls acting as a VPN gateway.

Gotchas and platform-specific nuances

CPU utilization comes from a standard MIB, and the instance number is what actually distinguishes management plane from data plane. Rather than a Palo Alto-specific CPU object, hrProcessorLoad from the generic HOST-RESOURCES-MIB is what's populated - and on most platforms, hrProcessorLoad.1 is the management plane (matching the CPU percentage shown on the GUI dashboard) while hrProcessorLoad.2 is the data plane. Some larger platforms expose a third instance splitting data-plane load further into system versus packet-processing cores specifically. Nothing in the object's own name tells you which instance is which - that mapping is platform-dependent and worth confirming with a walk (checking each instance's corresponding hrDeviceDescr entry, which does label it) rather than assuming .1 and .2 always mean the same thing across every model.

Device-wide session utilization doesn't reflect per-VSYS load on a multi-tenant firewall. panSessionUtilization reports the whole device's session usage against its overall session limit - on a firewall carved into multiple virtual systems, that single number doesn't tell you whether one specific VSYS is approaching its own configured session limit while others sit nearly idle. panVsysTable breaks this down per VSYS instead, and is the more meaningful target for anything beyond a single-vsys deployment.

Panorama's SNMP configuration is entirely separate from the firewalls it manages - already noted above, but worth repeating as a gotcha specifically: pushing a device group's configuration from Panorama does not push its own SNMP settings onto managed firewalls, and there's no inheritance to rely on here. Each firewall's SNMP setup, and Panorama's own, has to be configured as its own, independent step.