>
    Strata Copilot
    Troubleshoot Panorama Push Failures Caused by Firewall Capacity Limits
    Focus
    Download PDF
    Focus
    1. Home
    2. Panorama
    3. Troubleshooting
    4. Troubleshoot Commit Failures
    5. Troubleshoot Panorama Push Failures Caused by Firewall Capacity Limits
    Download PDF
    Panorama

    Troubleshoot Panorama Push Failures Caused by Firewall Capacity Limits

    Table of Contents

    Troubleshoot Panorama Push Failures Caused by Firewall Capacity Limits

    Panorama does not validate whether the target firewall can support the total volume of configuration objects being pushed.
    The Panorama® push log may show the job as completed or partially failed, while the failure is only visible in the firewall's commit log or system log.
    This issue most commonly affects low-end platforms (PA-220, PA-410, PA-415, PA-440, PA-450, and VM-50) that are members of Device Groups with large numbers of inherited configuration objects. When Panorama pushes a Device Group hierarchy, the firewall receives objects from the entire ancestor chain:
    [Shared Scope] > [Parent Device Group] > [Child Device Group] > [Firewall]
    An administrator managing only a Child Device Group may be unaware of the total number of objects the firewall receives from Shared scope and parent Device Groups combined. If that total exceeds the firewall's local object limit, the push succeeds on Panorama but the local commit fails on the firewall.
    The following failure modes indicate a capacity-related push failure.
    Failure ModeDescription
    Commit failure with object count error
    The firewall's local validation engine rejects the pushed configuration immediately. Review the Panorama push log and the firewall commit log for entries similar to the following:
    • Panorama push log: Error: address object count exceeds platform limit (2500 max, 5012 received)
    • Firewall commit log: Error: object count limit exceeded: address (5012 > 2500)
    Push timeout with no response from firewall
    On platforms with 4 GB of RAM (PA-220, PA-410), parsing a large XML configuration file can exhaust management plane memory, causing the operating system to terminate the configuration daemon (configd). The push appears to hang and then times out.
    • Symptom: The push job status shows Commit in progress for more than 15 minutes, then fails with device did not respond.
    • Firewall system log: configd: killed by signal 9 (OOM killer)
    Candidate configuration lock after failed push
    If a push fails or times out mid-process, the firewall's candidate configuration may remain locked. Subsequent pushes to the same firewall fail with another commit is in progress or Configuration is locked by admin.
    Silent DAG registration overflow
    When dynamic IP-to-tag registrations exceed the firewall's hardware table limit, new registrations are silently dropped. Security policies stop matching new endpoints with no error appearing in Panorama.
    • Firewall system log: registered-ip table full, dropping registration
    For per-platform DAG registration limits, see the Palo Alto Networks Product Selection tool.
    1. Identify the affected firewall platform and its capacity limits.
      1. Log in to the Panorama Web Interface and select PanoramaManaged DevicesSummary.
      2. Locate the affected firewall and note its platform model.
      3. Look up the configuration object limits for that platform using the Palo Alto Networks Product Selection tool.
        Pay particular attention to the limits for address objects, address groups, security policy rules, External Dynamic Lists (EDL), and Dynamic Address Group (DAG) registered IPs.
    2. Determine the total number of configuration objects that were pushed to the firewall.
      The firewall receives objects from all ancestor scopes in the Device Group hierarchy. Count address objects across Shared scope and each ancestor Device Group to determine the combined total that was delivered to the firewall.
      1. In Panorama, review the object counts in ObjectsAddresses for the Shared scope and each Device Group in the hierarchy above the affected firewall.
      2. Confirm the total exceeds the platform limit identified in the previous step.
    3. If the firewall's candidate configuration is locked, clear the lock before proceeding.
      1. Log in to the firewall CLI.
      2. Remove the commit lock.
        request commit-lock remove admin admin-name
      3. Revert the candidate configuration to the last running configuration.
        revert config
      4. Commit the reverted configuration locally on the firewall to restore a known-good state before re-attempting the push from Panorama.
        commit
    4. Reduce the total number of configuration objects that the affected firewall receives.
      Choose one or more of the following strategies based on your deployment.
      1. Move the affected firewall to a Device Group with fewer inherited objects.
        Assign low-end firewall platforms to a dedicated Device Group branch that inherits only the objects required for those firewalls to function. Avoid placing low-end platforms in Device Groups that inherit large Shared-scope object sets. See Manage Device Groups.
      2. Reduce the number of objects in the Shared scope.
        Move objects that are not required by all managed firewalls out of the Shared scope and into the specific Device Groups that need them. Use Manage Unused Shared Objects to identify and remove objects that are no longer referenced.
      3. Replace large sets of individual address objects with an EDL.
        An EDL hosted on an internal web server counts as a single configuration object against the firewall's limit, regardless of how many entries it contains. This is especially effective for large cloud IP ranges or threat feed address sets.
    5. Exclude the affected firewall from the push scope and push only after the object count has been reduced below the platform limit.
      1. In Panorama, select CommitPush to Devices and Edit Selections.
      2. Under Device Groups, deselect the affected firewall from the push scope.
      3. After reducing the object count, re-push to the affected firewall and verify the commit succeeds.
    6. If push jobs to low-end firewalls fail due to timeout rather than object count errors, increase the Panorama commit timeout.
      Low-end firewalls processing large configurations can take 10 to 20 minutes to complete a local commit. The default Panorama commit timeout of 10 minutes may cause false timeout failures before the firewall finishes committing.
      1. In Panorama, select PanoramaSetupManagement and edit the General Settings.
      2. Increase the Commit Timeout value to 30 or 60 minutes and click OK.
      3. Select CommitCommit to Panorama to save the change.

    © 2026 Palo Alto Networks, Inc. All rights reserved.