resources-unavailable for DNS-base traffic

[adminglu]

Model: Palo Alto PA-3420
Software version: 11.2.4-h1

Most of our dns-base traffic has the "session end reason" resources-unavailable suddenly. We're also having trouble loading webpages. The resources-unavailable reason is only on DNS-base traffic and it is for DNS traffic to our 2 internal DNS servers, but also from our DNS-server to the forwarders or directly to external DNS server (for example 8.8.4.4, 8.8.8.8).

I checked the commands "show counter global name aho_alloc_lookup_failed":

Name:           aho_alloc_lookup_failed
Value:          0
Severity:       Warning
Category:       aho
Aspect:         resource
Description:    failed to alloc regex lookup

 And "debug dataplane pool statistics | match "Regex Results"":

[18] Regex Results (  16352): 2048/2048  52/2048  1/1      0xd301603b00-0xd3035f3b00  52

But that seems ok. Any suggestions what can be wrong, or where I can look?

[OtakarKlier]

Hello,

Check the unified logs to see where/if the traffic is getting blocked. Its UDP so might have to check the session browser, if the session is still open it wont show in the logs (reason 'log at session end' on the security policy).

Regards,

Regards,

[adminglu]

The traffic is allowed:

It seems like some sort of memory leak affecting only the DNS traffic. We had to restart the firewall because normal internet was impossible with all the failed DNS requests. After the reboot we haven't seen any "session end reason: resource-unavailable" anymore. The uptime before the reboot was 61 days, so not that long.

[MattSloan]

Any info on the cause? We've had this occur twice now, 14 days apart. A reboot was the only solution. I haven't opened a case yet, but that's my next step.

[mshekh]

Hi @adminglu ,

Recommendation is to open a support case and work with tac team to identify the issue.

[adminglu]

After 21 days uptime the issue came back. This friday I have to install an update on the firewall so the problem will be gone for a while. If it comes back again I'm going to create a support ticket with Palo Alto.

[cskhor]

Just want to share for my case is PA440 , opened with support and they request to enable the Jumbo frame support in PA to avoid this issue . 

[adminglu]

Thanks for reporting back, we just had the issue again yesterday after 72 days uptime.

You mean under Device->Setup->Session->Session Settings->Enable Jumbo Frame?

[pomologist]

I've been having this exact problem. Causing me horrific chaos on my PA-440!!  Only restarting the firewall fixes the issue, and it happens every 2-3 months. I just saw this thread, so have turned on Jumbo Frame enablement per the recommendation above, we'll see if that helps.  Did that fix it for you guys?
If anyone has any other suggestions, please let me know!

[F.Pinar]

Hi 

I would like to ask if this behavior is also related to PA-1410 version 11.2.5. I found out the following bug , however, I need to confirm it .

1. PAN-296752
   This issue is now resolved. See PAN-OS 11.2.10 Addressed Issues
   The PA-1410 firewalls experience a spike in the management plane CPU utilization when the monitor-dp process attempts to retrieve the power cycle count from the NVMe drive’s SMART data. This condition leads to repeated reboots of the device, requiring a hard reset for recovery.

2025/12/29 17:35:41  Crash                  /var/log/pan/md_apps.log             2025-12-29 17:35:41.443 -0600 Process monitor exited with signal of 15; core dumped: no
         2025/12/29 17:35:41  Crash                  /var/log/pan/md_apps.log             2025-12-29 17:35:41.444 -0600 Process plugin_api_server exited with signal of 15; core dumped: no
         2025/12/29 17:35:41  Crash                  /var/log/pan/md_apps.log             2025-12-29 17:35:41.446 -0600 Process csad exited with signal of 9; core dumped: no
         2025/12/29 17:35:41  Crash                  /var/log/pan/md_apps.log             2025-12-29 17:35:41.446 -0600 Process devsrvr exited with signal of 9; core dumped: no
         2025/12/29 17:35:41  Crash                  /var/log/pan/md_apps.log             2025-12-29 17:35:41.446 -0600 Process distributord exited with signal of 9; core dumped: no
         2025/12/29 17:35:41  Crash                  /var/log/pan/md_apps.log             2025-12-29 17:35:41.446 -0600 Process iotd exited with signal of 9; core dumped: no
         2025/12/29 17:35:41  Crash                  /var/log/pan/md_apps.log             2025-12-29 17:35:41.447 -0600 Process mgmtsrvr exited with signal of 9; core dumped: no

[kiwi]

Hi @F.Pinar ,

PAN-296752 is indeed flagged for PAN-OS version 11.2.5, so the timing and the hardware match up. However, even with the logs you provided, I can't confirm this is the exact bug from here.

Processes exiting with signal 9 or 15 are essentially the system's way of panic-closing apps because the Management Plane is overwhelmed.

While PAN-296752 is a likely candidate, these same crashes can be triggered by other underlying issues.

To be sure before you start changing code I'd generate a TSF and submit it to TAC for review. Point them directly to your logs and PAN-296752. 

TAC has the tools to look to see if monitor-dp was specifically the process that choked the CPU. They can confirm if moving to 11.2.10 is your fix or if there’s something else going on with your specific config.

It’s better to have TAC verify the root cause now than to perform an upgrade and have the same crash happen again hours later.

Kind regards,