Step 1: Navigate to Site > Site Summary and review Application Health to identify the affected application and path.

Step 2: Check for Init Failures or Transaction Failures, increased RTT or SRT, and path-health degradation.

Step 3: If multiple applications are affected on the same path, investigate and restore the underlying WAN connectivity.

Step 4: If only one application is affected, verify the destination route, security policy, NAT configuration, and application availability through the affected path.

Step 5: After remediation, confirm that application transactions are successful and the incident is cleared.

Step 6: If the issue persists while the path is healthy, collect the site name, application name, affected path, and incident time, and contact Palo Alto Networks Support.

Contact support if this incident recurs frequently or remains unresolved.

Contact support if this incident recurs frequently or remains unresolved.

Contact support if this incident recurs frequently or remains unresolved.

Multiple applications refer to the same IP address. Applications with an IP address collision are likely not uniquely defined, or there may be a network condition. If one or both are custom applications that you defined, correct any erroneous definitions.

Step 1: Review the incident details and note the affected application, site, path, WAN interface, Performance Policy Rule, and Performance Policy Set.

Step 2: Navigate to Site > Site Summary, select the affected application, and review its Application Health metrics.

Step 3: Review the Application Health Score and Bandwidth Utilization to identify when the degradation occurred and confirm the affected path.

Step 4: Review App Response Time, Transaction Stats, and Path Performance Details. Check for increased RTT, transaction or initialization failures, and a reduced health score on the affected link.

Step 5: Under Site Summary, review the Link Quality Metrics for the affected path and WAN interface. Check whether latency or packet loss exceeded the SLA thresholds defined in the performance policy.

Step 6: If the link-quality metrics show degradation, investigate the affected WAN link and resolve any underlay or overlay connectivity issue. If the link is healthy, verify the application or destination availability and confirm that the configured performance-policy thresholds are appropriate.

Step 7: After remediation, confirm that the application health score has recovered and the incident is cleared.

Step 8: If the issue persists, collect the incident details, application health metrics, affected path, WAN interface, and incident time, and contact Palo Alto Networks Support.

Check the unknown flows. Go to the Activity screen and select Flow Browser to inspect one or more unknown flows. Click the flow (the IP address is clickable) to view its details. Check the reason the flow is categorized as unknown.

Step 1: Review the alert details and record the affected site, ION, alert time, duration, software version, hardware model, and any recent software upgrade, reboot, or content update.

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, Last Disconnected Time, and Last Reboot Reason. If Device State or Config and Events is Offline, follow the remediation for DEVICESW_DISCONNECTED_FROM_CONTROLLER.

Step 3: Review Device Activity and System Health for CPU or memory pressure around the alert time. Check for related ML7/MCTD, process restart, system boot, software upgrade, or DEVICESW_APPDEF_SIGFILE_MISMATCH alerts. If the Appdef and signature-file mismatch incident is also active, follow the remediation for DEVICESW_APPDEF_SIGFILE_MISMATCH.

Step 4: On IONs running Release 6.4.1 or later, run:

dump ml7-mctd version

dump ml7-mctd counters

inspect process status

Record the MCTD engine and content versions and compare them with a healthy ION running the same software version and similar configuration, when available. Review ML7/MCTD process state, uptime, CPU, and memory. If traffic is present, run dump ml7-mctd counters again and determine whether application-identification and CTD processing counters are increasing.

Step 5: If the alert clears, the ML7/MCTD process is running, content versions are displayed, and processing counters are increasing, continue monitoring for recurrence. Do not manually reload content or restart the ML7/MCTD process.

Step 6: If the alert remains active, repeatedly returns, content versions cannot be displayed, or processing counters do not increase while relevant traffic is present, 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 containing the ION name and collection time, such as mctd_content_load_failure_branch-ion1_20260818T1430.

Step 1: Review the alert details and record the affected site, ION, alert time, duration, software version, hardware model, and whether the alert occurred during or immediately after a software upgrade, reboot, or configuration change.

Step 2: Go to Incidents & Alerts > Prisma SD-WAN > Incidents, select the time range around the alert, and filter for the affected ION. Check for repeated DEVICESW_MCTD_LOG_BUFFER_FULL alerts, MCTD content-load or initialization failures, and general or critical process restart or stop events. Then go to Insights > ION Devices > Device Activity, select the same ION and time range, and review CPU utilization, free memory, and interface bandwidth for changes that occurred at the same time as the alert.

Step 3: On IONs running Release 6.4.1 or later, run:

dump ml7-mctd version

dump ml7-mctd counters

dump flow count-summary

inspect process status

Run dump ml7-mctd counters and dump flow count-summary multiple times while the condition is active. Review ML7/MCTD processing rates, FPS in previous second, and ML7/MCTD process CPU, memory, and uptime. Use these results to identify conditions that occurred at the same time as the alert; increased traffic or resource use alone does not confirm the cause of the full buffer.

Step 4: On IONs running Release 6.4.1 or later, run:

dump ml7-mctd version

dump ml7-mctd counters

inspect process status

Confirm that the ML7/MCTD process is present and review its uptime, CPU, and memory. Record the engine and content versions. If traffic is present, run dump ml7-mctd counters again and determine whether the application-identification and CTD processing counters are increasing.

Step 5: If DEVICESW_MCTD_CONTENT_LOAD_FAILURE is also active, follow the content-validation steps in DEVICESW_MCTD_CONTENT_LOAD_FAILURE.

Step 6: If the alert clears, the ML7/MCTD process remains running, and processing counters are increasing, continue monitoring for recurrence. Do not manually start or restart the process.

Step 7: If initialization continues to fail, the ML7/MCTD process is not running, or the alert 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 containing the ION name and collection time, such as mctd_initialization_failure_branch-ion1_20260818T1430.

Step 1: Review the alert details and record the affected site, ION, alert time, duration, software version, hardware model, and whether the alert is isolated or repeatedly occurring.

Step 2: Review Device Activity and System Health around the alert time. Check CPU, memory, throughput, New TCP Flows, New UDP Flows, and related MCTD, process, or logging alerts. A sudden increase in traffic or ML7/MCTD activity may help explain why the buffer filled.

Step 3: On IONs running Release 6.4.1 or later, run:

dump ml7-mctd version

dump ml7-mctd counters

inspect process status

Review the ML7/MCTD process state, uptime, CPU, and memory. Run dump ml7-mctd counters more than once while the condition is active to identify rapidly increasing counters or resource-related entries.

Step 4: If the alert clears and does not return, continue monitoring. Do not clear the buffer, delete logs, or restart the ML7/MCTD process.

Step 5: If the buffer remains full, the alert repeatedly returns, or related MCTD functions become unavailable, 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 containing the ION name and collection time, such as mctd_log_buffer_full_branch-ion1_20260818T1430.