topic Re: resources-unavailable for DNS-base traffic in General Topics

resources-unavailable for DNS-base traffic

adminglu — Mon, 20 Jan 2025 12:59:31 GMT

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?

Re: resources-unavailable for DNS-base traffic

OtakarKlier — Wed, 22 Jan 2025 21:56:55 GMT

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,

Re: resources-unavailable for DNS-base traffic

adminglu — Thu, 23 Jan 2025 09:54:36 GMT

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.

Re: resources-unavailable for DNS-base traffic

MattSloan — Wed, 19 Feb 2025 03:47:56 GMT

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.

Re: resources-unavailable for DNS-base traffic

mshekh — Wed, 19 Feb 2025 03:50:58 GMT

Hi @adminglu ,

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

Re: resources-unavailable for DNS-base traffic

adminglu — Wed, 19 Feb 2025 07:37:58 GMT

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.

Re: resources-unavailable for DNS-base traffic

cskhor — Wed, 07 May 2025 00:56:42 GMT

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 .

Re: resources-unavailable for DNS-base traffic

adminglu — Wed, 07 May 2025 06:45:11 GMT

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?

Re: resources-unavailable for DNS-base traffic

pomologist — Fri, 31 Oct 2025 01:09:14 GMT

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!

Re: resources-unavailable for DNS-base traffic

F.Pinar — Wed, 07 Jan 2026 15:31:21 GMT

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 .

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

Re: resources-unavailable for DNS-base traffic

kiwi — Thu, 08 Jan 2026 15:13:29 GMT

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,