Step 1: Review the incident details and record the affected ION, incident time, reported failure reason, affected DHCP scope or interface, and any client impact.

Step 2: Navigate to Configuration > Prisma SD-WAN > Branch Sites, select the affected site, and open Configuration > DHCP Scopes > Configure DHCP Scopes. Confirm that the DHCP scope is enabled and that the subnet, gateway, IP ranges, lease times, static mappings, and network context are valid.

Step 3: Run the following commands from the Remote CLI Toolkit:

dump dhcp-server config

dump dhcp-server status

dump dhcpstat

inspect dhcplease all

Review the configured scopes, interfaces on which the server is running, request and response counters, ACK and NACK counters, and used and available leases.

Step 4: Verify that at least one intended physical interface is Admin Up, operational, and configured with a static primary IP address:

dump interface config <interface>

dump interface status <interface>

Confirm that the interface address and DHCP scope are configured for the intended network. DHCP server operation is not supported on an interface's secondary IP address.

Step 5: Correct any invalid or disabled DHCP scope, address-pool, network-context, or interface configuration. After correcting the configuration, use the supported Restart DHCP Servers action on the DHCP Scopes page if a DHCP service restart is required.

Step 6: Run the validation commands again. Confirm that the DHCP server is running on the expected interface and network context, clients can obtain leases, and the incident clears.

Step 7: If the configuration and interfaces are valid but the server still fails to start, or the reported reason indicates an internal ION error, collect the incident details, command outputs, and a support bundle, and contact Palo Alto Networks Support.

For Release 6.4.1 or later:

dump-support all file=dhcp-server-errors

For earlier supported releases:

dump-support outputs file=dhcp-server-errors

Do not manually restart an internal DHCP process or reboot the ION unless instructed by Palo Alto Networks Support.

Step 1: Review the incident details and record the affected site, ION, incident time, duration, software version, active IPFIX profile, and any related interface or controller incidents.

Step 2: Go to Configuration > Prisma SD-WAN > Devices > Claimed Devices and hover over the affected device’s status. Review Device State, Config and Events, Analytics, Flows, Last Disconnected Time, and Last Reboot Reason. If Device State or Config and Events is Offline, first follow the remediation for DEVICESW_DISCONNECTED_FROM_CONTROLLER. If both are Online, continue with the IPFIX-specific checks.

Step 3: Verify the IPFIX configuration applied to the ION. Go to Configuration > Prisma SD-WAN > ION Devices > Claimed > select the affected ION > Configure the device > IPFIX. Confirm that the correct IPFIX profile is attached and review any device-specific overrides. Then go to Configuration > Prisma SD-WAN > Profiles and Templates > IPFIX and open the profile. On the Collectors tab, verify each collector’s Host, Protocol, Host Port, and IPFIX Collector Context. The host and port must match the address and listening port configured on the external collector.

Step 4: If the collector uses an IPFIX Collector Context, go to Configuration > Prisma SD-WAN > Profiles and Templates > IPFIX > Contexts. Open the context’s ellipsis menu, select View Interface Bindings, and confirm that it is bound to the intended interface on the affected ION. The interface must support collector-context use, be administratively up, and have a valid IP address.

Step 5: If no collector context is configured, the ION uses its controller port as the source by default. On platforms without a controller port, configure a collector context and bind it to a suitable interface. For an HA pair, confirm that the same IPFIX profile and collector-context bindings are configured on both IONs. Make all configuration corrections through SCM, not through the local CLI.

Step 6: Use the following read-only commands to compare the configuration received by the ION with the SCM configuration and review the collector state:

dump ipfix config derived-exporters

dump ipfix config collector-contexts all

inspect ipfix collector-stats

inspect ipfix exporter-stats

Confirm the effective collector host, port, protocol, and source interface. In inspect ipfix collector-stats, review the status of every collector, connection failures, disconnects, buffer errors, and session drops. In inspect ipfix exporter-stats, review generated records, record sends, and No Connected Collector Drops.

Step 7: Check the source interface and collector reachability:

dump interface status <source_interface>

ping <source_interface> <collector_ip_or_fqdn> args="-c 5"

Obtain <source_interface> from the interface bound to the IPFIX Collector Context, as shown by dump ipfix config collector-contexts all. If no context is configured, use the controller interface that the ION uses as the default source. Obtain <collector_ip_or_fqdn> from the collector Host in the IPFIX profile or from dump ipfix config derived-exporters.

Step 8: For a TCP collector, test its configured listening port:

tcpping <source_interface> <collector_ip_or_fqdn>:<collector_port>

Obtain <collector_port> from Host Port in the IPFIX profile or from the dump ipfix config derived-exporters output. A failed ICMP ping does not prove that the collector is unavailable if ICMP is blocked. For UDP collectors, tcpping does not apply. Verify the route, DNS resolution when an FQDN is used, NAT and firewall rules, the collector’s UDP listener, and the collector logs.

Step 9: If the configuration is correct but every collector remains down, verify that the collector service is running and listening on the configured protocol and port. Check for routing, DNS, NAT, firewall, access-control, or recent collector-side changes that could block traffic from the ION source address.

Step 10: After correcting the issue, run inspect ipfix collector-stats again and confirm that at least one collector reports Up. Run inspect ipfix exporter-stats and confirm that the record-send counters are increasing. Also verify that the external collector is receiving new IPFIX records.

Step 11: If all collectors remain unavailable or the incident repeatedly returns, collect a support bundle and open a Palo Alto Networks Support case:

dump-support all file=<descriptive_filename>

For earlier releases that do not support the all option:

dump-support outputs file=<descriptive_filename>

Use a filename that includes the ION name and collection time, such as ipfix_collectors_down_branch-ion1_20260818T1430.

Step 1: Review the incident details and record the affected site, ION, incident time, software version, and any recent NTP, DNS, interface, routing, or firewall changes.

Step 2: Go to Configuration > Prisma SD-WAN > ION Devices > Claimed, select the affected ION, and select Configure the device from the ellipsis menu. Open the NTP configuration and verify the configured NTP servers and source interfaces.

If the configuration uses a template, go to Configuration > Prisma SD-WAN > Profiles and Templates > NTP and verify the server Host, Version, Min Poll, and Max Poll values. Confirm that any configured source interface is up and has a valid IP address. Make configuration corrections through SCM.

Step 3: Run the following read-only commands:

dump time config

dump time status

dump time log

Confirm that the expected NTP servers appear in dump time config. In dump time status, review the current device time, last poll and selection times, resolved server address, stratum, time difference, and reported errors. Review dump time log for DNS, timeout, or synchronization errors.

Step 4: Based on the reported error, verify that the NTP server is available and that DNS, routing, NAT, firewall, and access-control policies permit communication between the ION source address and the NTP server. NTP uses UDP port 123.

Step 5: After correcting the configuration or network issue, use the refresh button on the NTP Client screen to force an immediate poll. Run dump time status again and confirm that the server was recently polled and selected, no current error is reported, and the incident clears.

Step 6: If synchronization continues to fail or the incident repeatedly returns, collect a support bundle and open a Palo Alto Networks Support case:

dump-support all file=<descriptive_filename>

For releases earlier than 6.4.1 that do not support the all option:

dump-support outputs file=<descriptive_filename>

Use a filename containing the ION name and collection time, such as ntp_no_sync_branch-ion1_20260818T1430.

Step 1: Review the incident details and record the tenant, region, SASE service endpoint ID, incident time, allocated bandwidth, and total configured CIR.

Step 2: Review the sites assigned to the SASE service endpoint and confirm that their CIR values and service-endpoint mappings are correct.

Step 3: Determine whether the incident followed a site addition or removal, CIR change, service-binding change, or another configuration update that caused the controller to recalculate capacity.

Step 4: Compare the combined configured CIR with the allocated regional bandwidth. Treat CIR as a capacity-planning value, not as live traffic utilization.

Step 5: Correct any unintended site mapping or incorrect CIR through the supported configuration workflow. Do not reduce a valid CIR solely to clear the incident.

Step 6: If the mappings and CIR values are correct but the combined CIR exceeds the regional allocation, open a Palo Alto Networks Support case to review the allocation and required capacity.

Step 7: Confirm that the incident clears after the total configured CIR is within the regional allocation or sufficient capacity is provided. This is a controller-generated capacity-planning alarm; an ION support bundle is not required unless Support requests it.

Step 1: Review the incident details and record the tenant, region, SASE service endpoint ID, incident time, allocated bandwidth, and total estimated bandwidth.

Step 2: Review the sites assigned to the SASE service endpoint and the estimated-bandwidth values used by the controller.

Step 3: Determine whether the incident followed a site addition or removal, CIR change, service-binding change, or another configuration update that caused the controller to recalculate capacity.

Step 4: Confirm that the site mappings and bandwidth configuration are correct. Treat the estimated bandwidth as a capacity-planning value, not as live traffic utilization, and do not reduce application traffic solely to clear the incident.

Step 5: Correct any unintended site mapping or bandwidth configuration through the supported workflow. If the configuration is correct but the estimate remains above the regional allocation, open a Palo Alto Networks Support case to review the estimate, available headroom, allocation, and required capacity.

Step 6: Confirm that the incident clears after the total estimated bandwidth is within the regional allocation or sufficient capacity is provided. This is a controller-generated capacity-planning warning; an ION support bundle is not required unless Support requests it.

Step 1: Review the incident details and record the tenant, region, SPN or element ID, associated security service endpoint and vION identifiers, incident time, SPN rated capacity, and total configured CIR.

Step 2: Determine whether the incident followed a site addition or removal, CIR change, service-binding or site-to-SPN mapping change, or another capacity-planning recalculation.

Step 3: Review the sites mapped through the SPN and confirm that their configured CIR values and mappings are correct. Treat CIR as a capacity-planning value, not as live traffic utilization.

Step 4: Compare the combined configured CIR with the SPN's rated capacity. Correct any unintended mapping or incorrect CIR through the supported workflow. Do not reduce a valid CIR solely to clear the incident.

Step 5: If the mappings and CIR values are correct but the combined CIR still exceeds the rated capacity, open a Palo Alto Networks Support case to review site-to-SPN allocation, rebalancing, or additional SPN capacity.

Step 6: Confirm that the incident clears after the total configured CIR is within the rated capacity or after capacity and rebalancing changes resolve the condition. This is a controller-generated capacity-planning alarm; an ION support bundle is not required unless Support requests it.

Step 1: Review the incident details and record the tenant, region, SPN or element ID, associated security service endpoint and vION identifiers, incident time, SPN rated capacity, total configured CIR, controller-estimated bandwidth, and combined planned load.

Step 2: Determine whether the incident followed a site addition or removal, CIR change, service-binding or site-to-SPN mapping change, or another capacity-planning recalculation.

Step 3: Review the sites mapped through the SPN and confirm that their CIR values, estimated-bandwidth values, and mappings are correct. Treat these as capacity-planning values, not as live traffic utilization.

Step 4: Verify the site mappings and bandwidth configuration. Do not reduce application traffic or a valid CIR solely to clear the incident.

Step 5: Correct any unintended mapping or bandwidth configuration through the supported workflow. If the configuration is correct but the combined planned load remains above the rated capacity, open a Palo Alto Networks Support case to review the estimate, available headroom, rebalancing, or additional SPN capacity.

Step 6: Confirm that the incident clears after the combined planned load is within the rated capacity or after capacity and rebalancing changes resolve the condition. This is a controller-generated capacity-planning warning; an ION support bundle is not required unless Support requests it.

Step 1: Review the incident details and record the affected tenant, region, VION ID, VION cluster ID, incident time, VION model, rated capacity, and reported CIR consumption.

Step 2: Determine whether the incident occurred after a site was added or removed, a site’s CIR was changed, or a related configuration was pushed. These events cause the controller to recalculate site placement and VION cluster capacity.

Step 3: Review the CIR values assigned to the sites associated with the affected VION cluster and confirm that they match the intended bandwidth allocations. CIR is a site capacity-planning value and does not represent current WAN traffic utilization. Do not reduce a valid CIR solely to clear the incident.

Step 4: Monitor the incident while the controller recalculates the cluster plan and attempts site rebalancing, VION expansion, vertical scaling, or horizontal scaling.

Step 5: Confirm that the incident clears after the total assigned CIR falls below the VION’s rated capacity or the controller provides sufficient additional capacity.

Step 6: If the incident remains active, a site cannot be placed, a CIR update cannot be accommodated, or a related configuration push fails, open a Palo Alto Networks Support case. Include the tenant, region, VION ID, VION cluster ID, rated capacity, total assigned CIR, affected sites, recent CIR or site changes, and any reported placement or scaling errors.

This is a controller-generated capacity-planning incident. ION CLI commands and an ION support bundle are not required unless requested by Palo Alto Networks Support.

Step 1: Review the incident details and record the affected tenant, region, VION ID, VION cluster ID, incident time, VION model, rated capacity, and reported CIR and estimated-bandwidth values.

Step 2: Determine whether the incident occurred after a site was added or removed, a site’s CIR was changed, or a related configuration was pushed. These events cause the controller to recalculate site placement and cluster capacity.

Step 3: Review the CIR values assigned to the sites associated with the affected VION cluster and confirm that they match the intended bandwidth allocations. The controller also includes estimated bandwidth when calculating this soft-limit condition. Do not treat this incident as evidence of excessive live traffic or a branch WAN-circuit problem.

Step 4: Monitor the incident while the controller recomputes the cluster plan and attempts to optimize site placement through rebalancing, VION expansion, vertical scaling, or horizontal scaling.

Step 5: Confirm that the incident clears after the combined CIR and estimated bandwidth returns within the applicable capacity-planning limit or sufficient VION capacity becomes available.

Step 6: If the incident remains active, open a Palo Alto Networks Support case. Request validation of the estimated-bandwidth values, site-to-cluster mappings, cluster packing, available headroom, and any pending rebalancing or scaling operations. Include the tenant, region, VION ID, VION cluster ID, rated capacity, total CIR, estimated bandwidth, affected sites, and recent CIR or site changes.

This is a controller-generated capacity-planning incident. ION CLI commands and an ION support bundle are not required unless requested by Palo Alto Networks Support.

Step 1: Confirm that the remote Syslog server is operational and listening on the configured protocol and port. Review any recent Syslog, DNS, routing, firewall, certificate, or collector changes.

Step 2: Go to Configuration > Prisma SD-WAN > ION Devices > Claimed, select the affected ION, and select Configure the device. Open Syslog Export and verify that the server is enabled and that the source interface and assigned Syslog profile or custom configuration are correct.

If the device uses a profile, go to Configuration > Prisma SD-WAN > Profiles and Templates > Syslog. Verify the server IP address or FQDN, protocol, port, severity level, and flow-logging setting. The default port is 514 for TCP or UDP and 6514 for TLS. Make configuration corrections through SCM.

For TLS, verify that the certificate is valid and not self-signed, the configured FQDN matches the certificate Subject Alternative Name (SAN), and the server supports TLS 1.2.

Step 3: Run the following read-only commands:

dump syslog config

dump syslog status

dump syslog-rtr stats

Confirm that the configuration matches SCM and that dump syslog status reports the service as running. In dump syslog-rtr stats, review the affected server’s Enabled, Protocol, Src Interface, Connected, Connect Fail Count, Send Fail Count, Send Retry Count, Send Success Count, Server Disconnect Count, and Cipher Info values.

Step 4: Verify that DNS, routing, NAT, and firewall policies permit traffic from the configured source interface to the Syslog server.

For TCP or TLS, test the configured destination and port:

tcpping <source_interface> <syslog_server_ip_or_fqdn>:<syslog_port>

Obtain the source interface from Src Interface in dump syslog-rtr stats. Obtain the destination and port from dump syslog config or the SCM configuration.

For UDP, do not use tcpping. Verify that UDP traffic is permitted and confirm on the remote collector that messages from the ION are being received.

Step 5: After correcting the configuration, network, certificate, or collector issue, run dump syslog-rtr stats again. For TCP or TLS, confirm that Connected is true and connection failures are no longer increasing. For all protocols, confirm that Send Success Count increases and that the remote server receives new Syslog messages.

Step 6: If the Syslog service is not running, connectivity cannot be restored, or the incident repeatedly returns, collect a support bundle and open a Palo Alto Networks Support case:

dump-support all file=<descriptive_filename>

For releases earlier than 6.4.1 that do not support the all option:

dump-support outputs file=<descriptive_filename>

Use a filename containing the ION name and collection time, such as syslogservers_down_branch-ion1_20260818T1430.

Step 1: Review the incident details and record the affected tenant, incident time, and reported failure reason.

Step 2: In Strata Cloud Manager, navigate to Configuration > Prisma SD-WAN > System > Cloud Identity Engine.

Step 3: Confirm that User Context Cloud Service is Enabled.

Step 4: Select the User Context tab and review the Status and Last Updated fields.

Step 5: If the status is Operational and the Last Updated timestamp is current, monitor the incident and confirm that it clears.

Step 6: If the status is not Operational, the Last Updated timestamp is not updating, or the incident continues to occur, capture the incident details and a screenshot of the User Context status, and contact Palo Alto Networks Support.

Step 7: Palo Alto Networks Support must investigate any certificate-related communication issue, Cloud User ID synchronization service failure, or controller-side failure.

Step 1: Review the incident details and record the affected data center site, ION, User-ID agent name or ID, incident time, software version, and any recent User-ID, interface, DNS, routing, firewall, or certificate changes.

Step 2: Determine which User-ID mapping method the tenant is intended to use:

User-ID Agent on a PAN-OS firewall

Cloud User-ID through Cloud Identity Engine User Context

These methods cannot be enabled at the same time.

If Cloud User-ID is the intended method, go to Configuration > Prisma SD-WAN > System > Cloud Identity Engine and confirm that Enable User Context Cloud Service is enabled and the User Context status is Operational. Also confirm that an unused User-ID Agent configuration is not enabled.

If User-ID Agent is the intended method, continue to Step 3.

Step 3: Go to Configuration > Prisma SD-WAN > Data Centers and select the affected data center site. In the Configuration tab, select Configure User Agent.

Confirm that:

The expected User-ID agent is configured.

Disabled is not selected.

The host IP address or FQDN is correct.

The configured port is correct.

The collector name is correct if the PAN-OS firewall uses a virtual system.

Do not record or expose the collector pre-shared key.

Step 4: Run the following read-only commands on the affected data center ION:

dump user-id status

dump user-id agent config all

dump user-id agent status all

dump user-id agent statistics all

Confirm that the User-ID service is running and its functionality is active. Review the configured agent address and port, connection state, source interface, last-heard or heartbeat time, last disconnect reason, TLS and certificate information, and connection-failure statistics.

Step 5: Verify that the source interface reported by dump user-id agent status all is operational. If the agent uses an FQDN, verify DNS resolution. Confirm that routing and firewall policies permit communication between the data center ION and the configured PAN-OS firewall address and port.

On the PAN-OS firewall, confirm that the User-ID agent is running and reachable. If the ION reports a TLS or certificate error, verify the certificate used by the User-ID agent.

Step 6: After correcting the configuration or connectivity issue, run the commands again. Confirm that the agent state is Completed, the last-heard or heartbeat time is recent, no current disconnect reason is reported, and the incident clears.

Step 7: If the connection remains down or the incident repeatedly returns, collect a support bundle and open a Palo Alto Networks Support case:

dump-support all file=<descriptive_filename>

For releases earlier than 6.4.1 that do not support the all option:

dump-support outputs file=<descriptive_filename>

Use a filename containing the event, ION name, and collection time, such as useridagents_down_dc-ion1_20260819T1430. Sanitize all command output and do not include the collector pre-shared key.

Step 1: Review the incident details and record the affected tenant, incident time, synchronization type (Full Sync or Delta Sync), object type (groups, users, or membership), reported error, and last successful synchronization time.

Step 2: In SCM, go to Configuration > Prisma SD-WAN > System > Cloud Identity Engine and verify that the intended Cloud Identity Engine configuration is associated with Prisma SD-WAN.

Step 3: Review the applicable identity-source or directory synchronization status in Cloud Identity Engine and confirm whether the same Full Sync or Delta Sync failure is reported there.

Step 4: If the identity source also reports a failure, verify the applicable connector or agent state, authorization and permissions, time synchronization, DNS and network reachability, and TLS certificate validity. Apply only the checks relevant to the configured identity source.

Step 5: If Cloud Identity Engine reports a current successful synchronization but the controller incident remains active, verify the Prisma SD-WAN association and review related Cloud Identity Engine or controller-service incidents. Do not change directory configuration unless the identity source also reports a synchronization problem.

Step 6: After correcting the identified issue, initiate or allow the next Full Sync or Delta Sync and confirm that groups, users, and membership synchronize successfully and the incident clears.

Step 7: If synchronization continues to fail, open a Palo Alto Networks Support case with the controller incident details, identity-source status, synchronization timestamps and error, relevant connector or agent logs, and recent changes. Do not collect an ION support bundle solely for this controller-originated incident unless Support requests it or a related ION incident is present.

Step 1: Review the incident details and record the affected tenant and site, incident time, reported hub-selection error, and candidate hub identifiers if provided.

Step 2: Verify the intended User-ID architecture and configuration in SCM. For User-ID Agent deployments, confirm the data center User Agent configuration under Configuration > Prisma SD-WAN > Data Centers. For Cloud User ID, confirm the configuration under Configuration > Prisma SD-WAN > System > Cloud Identity Engine.

Step 3: Confirm that candidate data center sites and IONs are operational and review related SITE_CONNECTIVITY_DOWN, NETWORK_ANYNETLINK_DOWN, User-ID Agent, or controller-service incidents.

Step 4: Correct any User-ID configuration, site association, software-compatibility, or connectivity issue identified in SCM and monitor hub selection.

Step 5: If selection continues to fail, open a Palo Alto Networks Support case with the controller incident details and candidate hub information. Do not collect an ION support bundle solely for this controller-originated incident unless Support requests it or a related ION incident is present.