Step 1: Review the incident details and identify the affected site, ION, incident time, software version, assigned TACACS+ profile, source interface, and any recent AAA, DNS, interface, routing, firewall, or TACACS+ server changes.

If remote authentication is unavailable, use an approved local administrator account to access the ION while troubleshooting.

Step 2: Go to Configuration > Prisma SD-WAN > Profiles and Templates > AAA and open the assigned TACACS+ profile. Verify the protocol, server IP addresses or FQDNs, configured ports, and server-response time. A profile can contain up to four servers, which the ION attempts sequentially.

Step 3: Go to Insights > Prisma SASE > ION Devices, select the affected ION, and open its AAA configuration. Verify that the correct TACACS+ profile and source interface are assigned. If customized profile values are enabled, verify that the customized server and protocol values are correct.

Make any required configuration changes through SCM. Do not change the configuration through the local CLI.

Step 4: Run the following read-only command:

dump interface status all

Confirm that the TACACS+ source interface is operational and has the expected IP address.

Test connectivity to each configured TACACS+ server:

tcpping <source_interface> <tacacs_server_ip_or_fqdn>:<tacacs_port>

Obtain the source interface from the device’s AAA configuration. Obtain each server address and port from the assigned TACACS+ profile.

If the profile uses an FQDN, verify DNS resolution:

dig <source_interface> <dns_server_address> <tacacs_server_fqdn>

Use the DNS resolver configured for the source interface as <dns_server_address>.

Step 5: Verify that routing, NAT, and firewall policies permit TCP communication from the ION source address to each TACACS+ server on its configured port. Confirm that each server is operational, listening on the configured port, and receiving connection attempts from the ION.

Step 6: After correcting the profile, DNS, network, firewall, or server issue, repeat the connectivity test. Confirm that at least one configured server is reachable, remote authentication is operational, and the incident clears.

Step 7: If the servers remain unreachable, the incident repeatedly returns, or remote authentication remains unavailable after connectivity is restored, 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 tacacs_servers_down_branch-ion1_20260818T1430.

Step 1: Review the incident details and record the affected site, ION, interface, incident time, software version, and any available information about the failing client (such as MAC address, VLAN, or authentication error).

Step 2: In SCM, review the 802.1X configuration for the affected interface, including the configured RADIUS server, authentication method, and supplicant settings.

Step 3: Verify that the client's 802.1X credentials (certificate, username, or password) are valid and have not expired.

Step 4: Confirm that the configured RADIUS server is reachable from the ION. Check for related DOT1X_RADIUS_SERVER_UNREACHABLE incidents at the same site.

Step 5: If the client credentials are valid and the RADIUS server is reachable, review the RADIUS server logs for additional authentication failure details.

Step 6: Correct any misconfigured 802.1X settings, invalid credentials, or RADIUS policy issues.

Step 7: If authentication failures persist, run dump-support all file=<descriptive_filename> (Release 6.4.1 and later) or dump-support outputs file=<descriptive_filename> (earlier releases), where <descriptive_filename> is a user-selected name such as event_name_ion-name_YYYYMMDDTHHMM.

Step 1: Review the incident details and record the affected user, tenant service group, incident time, workflow type, and reported validation failures. Do not record or expose the token value.

Step 2: Verify the user identity and intended tenant service group through the organization's approved identity and access process.

Step 3: Revoke or leave the disabled token invalid and issue a new token and unique ID through the supported access-management workflow.

Step 4: Deliver the replacement information through an approved secure channel and ask the user to retry the sign-up or password-reset workflow once.

Step 5: Confirm that the workflow completes successfully and that no additional failed-validation events occur.

Step 6: If a newly issued token also fails, open a Palo Alto Networks Support case with the incident metadata and workflow error. Do not include token values.

Step 1: Review the incident details and record the affected tenant and site, incident time, reported selection error, and any candidate data center or ION identifiers.

Step 2: In SCM, verify that the Device ID configuration and required subscriptions are enabled for the intended tenant and site.

Step 3: Confirm that the intended data center site and candidate IONs are operational and review related SITE_CONNECTIVITY_DOWN, NETWORK_ANYNETLINK_DOWN, controller-service, or configuration incidents.

Step 4: Correct any site association, configuration, or connectivity issue identified in SCM and monitor the controller selection result.

Step 5: If selection continues to fail, open a Palo Alto Networks Support case with the controller incident details and candidate data center or ION 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.

Step 1: Review the incident details and record the affected ION, incident time, affected interface, recurrence history, and any reported DHCP client impact.

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

dump dhcp-relay config

dump dhcprelay stat

Review the configured DHCP server IP addresses, source interface, Option 82 settings, and the Request, Request Relayed, Response, Response Relayed, Drop, ACK, NACK, and Decline counters.

Step 3: Confirm that the ION is assigned to an active site. Verify that the DHCP-relay interface and source interface are Admin Up and operational:

dump interface config <interface>

dump interface status <interface>

Step 4: In Strata Cloud Manager, navigate to Configuration > Prisma SD-WAN > ION Devices > Claimed, select the affected ION, and review its interface configuration. Confirm that the DHCP server IP addresses and source interface are correct and that the source interface has reachability to the DHCP servers.

Step 5: Correct any interface, DHCP server address, source-interface, Option 82, routing, or DHCP-server reachability issue. Confirm that clients can obtain or renew leases and that DHCP relay requests and responses are being forwarded without increasing drop or error counters.

Step 6: If this was a single restart with no client impact and the relay remains stable, continue monitoring.

Step 7: If the restart recurs or DHCP service is affected, 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-relay-restart

For earlier supported releases:

dump-support outputs file=dhcp-relay-restart

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

Step 1: Review the incident details and record the affected ION, incident time, recurrence history, and any DHCP client impact.

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

dump dhcp-server config

dump dhcp-server status

dump dhcpstat

inspect dhcplease all

Confirm that the DHCP server is currently running on the expected interfaces. Review the DHCP request, response, ACK, NACK, Decline, and lease counters.

Step 3: Verify the configuration and state of the interfaces on which the DHCP server is expected to operate:

dump interface config <interface>

dump interface status <interface>

Confirm that the intended physical interface is Admin Up, operational, and configured with the correct static primary IP address.

Step 4: In Strata Cloud Manager, navigate to Configuration > Prisma SD-WAN > Branch Sites, select the affected site, and review Configuration > DHCP Scopes. Confirm that the scope is enabled and that its subnet, address ranges, gateway, lease settings, and network context are valid.

Step 5: Review audit records around the restart time for changes to the DHCP scope, interface configuration, or an administrator-initiated DHCP server restart.

Step 6: Confirm that clients can obtain and renew leases and that the DHCP server remains stable. If this was a single restart with no client impact, continue monitoring.

Step 7: If the restart recurs or affects DHCP service, 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-restart

For earlier supported releases:

dump-support outputs file=dhcp-server-restart

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, software version, and any recent SLS subscription, security-policy, DNS, routing, firewall, or NAT changes.

Step 2: Go to Configuration > Prisma SD-WAN > Devices > Claimed Devices and hover over the affected ION’s status. Review Device State, Config and Events, Cloud Security Services, and Logging Service. If Device State or Config and Events is Offline, first follow the remediation for DEVICESW_DISCONNECTED_FROM_CONTROLLER.

Step 3: Confirm that the site has an applicable SASE Site license or that the standalone ION has a valid SLS license. Verify that the subscription is active and allocated to the correct tenant.

Step 4: Run the following read-only commands:

dump log-agent config

dump log-agent status

dump log-agent eal conn detail

dump log-agent eal stats

In dump log-agent config, confirm that the log-agent is enabled and record the Cloud URL. In dump log-agent status, confirm that the service reports Running.

In dump log-agent eal conn detail, review the cloud server FQDN and port, connection state, configured source IP, device-certificate status and validity, last successful connection, and connection failures.

In dump log-agent eal stats, review connection errors, queued logs, failed requests, unauthenticated errors, and dropped logs.

Step 5: Identify the source interface by matching the configured source IP from dump log-agent eal conn detail with the interface addresses shown by:

dump interface status all

Test connectivity to the SLS server:

tcpping <source_interface> <sls_fqdn>:<sls_port>

Obtain <sls_fqdn> and <sls_port> from the cloud server displayed by dump log-agent eal conn detail. Verify that DNS, routing, NAT, firewall, and access-control policies permit the connection from the ION source address to the displayed SLS FQDN and port.

Step 6: After correcting any licensing or network-connectivity issue, run dump log-agent eal conn detail again and confirm that the cloud connection reports connected. Run dump log-agent eal stats and confirm that log-send and acknowledgment counters increase when new logs are generated. Verify that new logs appear in Log Viewer.

Step 7: If the connection remains down, the log-agent reports Not Running, the device certificate is missing or invalid, unauthenticated errors continue, 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 slsconnection_down_branch-ion1_20260818T1430.

Step 1: Review the incident details and record the affected site, ION, incident time, software version, reported reason, and any recent SNMP configuration changes.

Step 2: Go to Configuration > Prisma SD-WAN > ION Devices > Claimed, select the affected ION, and open Configure the device > SNMP Config > Agent.

Confirm that SNMPv2, SNMPv3, or both are enabled. For SNMPv2, verify the Community configuration. For SNMPv3, verify the Username, Engine ID, Security Level, authentication protocol, and privacy protocol.

Step 3: Run the following read-only commands:

dump snmpagent config

dump snmpagent status

Confirm that the SNMP configuration received by the ION matches the configuration in SCM. Review the enabled SNMP versions, SNMPv3 username, security level, authentication protocol, and privacy protocol. Do not include community strings or SNMPv3 passwords in incident notes.

Step 4: If the incident reports an invalid configuration, correct the identified SNMP settings through SCM and save the configuration. If the incident reports a decryption failure, re-enter the required SNMPv3 authentication and privacy passwords through SCM and save the configuration.

Step 5: After the configuration is applied, run dump snmpagent status and confirm that it reports SNMP agent is running. Verify that the SNMP manager can poll the ION successfully and that the incident clears.

Step 6: If the agent still cannot start, the decryption failure continues after the credentials are re-entered, 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 snmp_agent_failed_branch-ion1_20260818T1430.

Step 1: Review the alert details and record the affected site, ION, alert time, software version, and whether the restart was isolated or occurred repeatedly. Check for recent SNMP configuration changes, software upgrades, or device reboots.

Step 2: Run the following read-only commands:

dump snmpagent status

dump snmpagent config

Confirm that the SNMP agent reports running and that the configuration received by the ION matches the configuration in SCM.

Step 3: Verify that the SNMP manager can poll the ION successfully. Check for gaps in SNMP monitoring around the alert time and confirm that polling has resumed.

Step 4: If this was an isolated restart, the SNMP agent is running, and polling is successful, continue monitoring for recurrence.

Step 5: If the agent does not remain running, SNMP polling remains unavailable, or multiple restart alerts occur, review Device Activity for CPU or memory pressure and check for related process restart, process stop, software upgrade, or system boot incidents.

Step 6: If the alert repeatedly returns or the SNMP agent remains unavailable, 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 snmp_agent_restart_branch-ion1_20260818T1430.