Panorama Device Groups and Templates Explained

Panorama manages firewalls through two parallel configuration layers, and confusing them is the root of most "I pushed the change but the firewall did not get it" incidents. Policies and objects live in device groups; network settings and device-level configuration live in templates. Understanding the hierarchy, and the order in which Panorama evaluates it, makes multi-firewall management predictable.

Device groups: policy and objects

A device group holds security policies, NAT, application filters, address and service objects, and the profiles that policies reference. Firewalls are assigned to exactly one device group. The hierarchy is evaluated top-down:

• Shared - objects and policies that apply to every firewall. Put address objects and service definitions here unless there is a reason not to.
• Parent device groups - common policy for a region, environment or business unit.
• Child device groups - site-specific policy. Rules in a child group are evaluated after the parent's, so a parent rule that matches forwards or blocks before the child's rules are considered.

Objects resolve upward: a child group can use objects defined in its parent or in shared, but not the reverse. That single rule explains most "object not found" commit failures - the object exists, just not at a scope the referencing rule can see.

Templates: device and network configuration

Templates hold what device groups deliberately do not: interfaces and zones, virtual routers, static routes, DNS and NTP, HA settings, and logging targets. Templates are combined into template stacks, and a firewall is assigned to one stack. Template stacks exist so several firewalls can share a base configuration (management settings, syslog, HA parameters) while differing in interface layout.

Template variables let one template serve many sites: define the variable once in the stack and give each firewall its own value. An unresolved variable is the classic reason a commit to a device fails validation - the error points at the template, not at the firewall you thought you changed.

Commit workflow

Panorama changes are committed twice: first a commit to Panorama itself, which validates and saves the configuration, then a push to the affected device groups and template stacks. Panorama determines the default target set from what changed - device group policy changes push to the firewalls in those groups (and their parents' targets), template changes push to the firewalls in the affected stacks. You can widen or narrow the target selection manually, and the "include devices in scope" behaviour is sticky, so check the target list rather than assuming.

# from the Panorama CLI, verify scope and connectivity
> show devicegroups
> show devices all
> show config pushed-shared-policy | match "device group"
# from the managed firewall
> show panorama-status

When a push does not arrive

• Device not registered or disconnected: check show devices all for connection state and certificate expiry. A firewall whose management certificate expired still forwards traffic normally but stops accepting configuration.
• Commit succeeded, configuration missing: confirm the change was made at a scope the firewall actually belongs to. A rule added to the wrong child device group validates happily and reaches nobody.
• Unresolved template variables: give every firewall in the stack a value before pushing.
• Out-of-sync after a successful push: the firewall may have local configuration that conflicts, or an earlier failed commit left it in a partial state. Compare the Panorama-pushed configuration against the local candidate configuration before re-pushing.
• Pushed but not enforced: policy evaluation order. A parent rule above the child rule decides the outcome, whatever the child rule says.

Design habits that scale

• Keep shared objects genuinely shared; duplicating an object per device group is how "one firewall has a different idea of what the DMZ is" happens.
• Use parent groups for mandatory policy (non-negotiable egress, logging, threat profiles) and child groups for local exceptions.
• Version-control the exported Panorama configuration and diff it before every change window - Panorama is a configuration source of truth, not a backup strategy.
• Prefer fewer, broader rules with tags over hundreds of site-specific rules; each rule is a future scope mistake.

Related: PAN-OS commit failure troubleshooting, FortiGate debug flow and packet trace, and strongSwan IKEv2 site-to-site VPN.

原文链接：https://docs.paloaltonetworks.com/ngfw/help/10-1/panorama-web-interface/panorama-commit-operations