>
    Strata Copilot
    Reset the ID Manager After Replacing a Firewall in an HA Cluster
    Focus
    Download PDF
    Focus
    1. Home
    2. Next-Generation Firewall
    3. High Availability
    4. Reset the ID Manager After Replacing a Firewall in an HA Cluster
    Download PDF
    Next-Generation Firewall

    Reset the ID Manager After Replacing a Firewall in an HA Cluster

    Table of Contents

    Reset the ID Manager After Replacing a Firewall in an HA Cluster

    After you replace a firewall in an HA cluster, reset the ID manager on the active peer to prevent stale factory entries from causing traffic drops.
    Where Can I Use This?What Do I Need?
    • NGFW (Managed by PAN-OS or Panorama)
    • No prerequisites needed
    When a replacement firewall joins an HA cluster as the passive peer, PAN-OS merges the replacement unit's factory ID manager database with the active peer's operational database. This merge can inject stale entries — application or policy IDs scoped to virtual systems that don't exist in the running configuration. If the replacement unit then becomes active while these stale entries are present, traffic can be misidentified and dropped.
    Resetting the ID manager on the active peer clears the merged database on both peers. A subsequent commit force repopulates both peers from the running configuration, removing any stale entries. Run the reset on the active peer — running it on the passive peer doesn't resolve the issue because the next HA sync cycle re-injects stale entries from the active peer's intact database.
    1. On the active firewall, verify which ID manager types are out of sync with the passive peer:
      username@hostname(active)> debug device-server dump idmgr high-availability state
      Any type listed as has difference indicates a sync inconsistency.
    2. On the active firewall, reset the ID manager for all types:
      username@hostname(active)> debug device-server reset id-manager type all
      Run this command only on the active firewall. Running it on the passive peer doesn't resolve the issue — the next HA sync cycle re-injects stale entries from the active peer.
    3. Perform a commit force on the active firewall:
      username@hostname(active)> commit force
      This resets the passive peer's ID manager first, then the active peer's, and repopulates both from the running configuration.
    4. Verify that the ID manager is in sync on both peers:
      username@hostname(active)> debug device-server dump idmgr high-availability state
      The expected output is:
      id manager compared with HA peer; id manager has no difference
      Run the same command on the passive peer to confirm.
    5. Verify that no stale application entries remain in unexpected virtual systems on either peer:
      username@hostname(active)> debug device-server dump idmgr type vsys-application all
      Confirm that no custom application entries appear in virtual systems where they are not configured.

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