07-12-2026 09:50 PM
Hello everyone!
In our PrismaAccess environment, we set the number of IP address pools to twice the number of mobile user devices connecting to Prisma Access, as per the documentation below.
However, the following situation occurs, and the following message is frequently displayed.
"mu private ip pool allocation exceeds 85% for theater worldwide"
"mu private ip pool allocation is at 100% for theater worldwide"
I contacted TAC and received the following response:
1. Due to an increase in connected users, a new GPGW (MU-SPN) was added via autoscaling. Therefore, several IPPOOL blocks were allocated for this new GPGW (MU-SPN).
2. Subsequently, the number of connected users decreased, but the IPPOOL blocks allocated to this new GPGW (MU-SPN) remain allocated to it.
3. If access to this new GPGW (MU-SPN) becomes completely "0", this new GPGW (MU-SPN) is considered inactive and will be deleted. At this point, the IPPOOL block assigned to this new GPGW is released.
Regarding the operation described in "3." above, could you please answer the following questions?
Q1) You mentioned that the GPGW (MU-SPN) becomes inactive and is deleted. At which of the following timings is it determined that the GPGW is inactive (deleted)?
A: When no users access this GPGW (MU-SPN) anymore.
B: When the user's active session (idle timeout) ends.
Q2) Is there a way to make the GPGW (MU-SPN) inactive (deleted) sooner so that it can release the IPPOOL block as quickly as possible?
We look forward to your comments!
07-12-2026 10:58 PM - edited 07-12-2026 11:10 PM
Why don't you just give a really big ip address block?
Prisma Access VPN connections can't be rescheduled to other nodes as this are stateful this is why if you delete 1 MU-SPN a user will lose access and their VPN will be restarted.
A way you can do MU-SPN deletion by having external automation that uses the REST-API and checks Prisma Access Region number of connected users/cpu/memory and then to delete 1 SPN node by accepting the risks that some users will need to reconnect but this is outside of this forum or TAC for creating the automation.
See and the related links as a nice overview:
07-12-2026 11:42 PM
@nikoolayy1
Thank you for your comment!
>Why don't you just give a really big ip address block?
Adding an IPPOOL block would require adding and modifying the routing for peripheral devices, which would be a huge amount of work. Therefore, we want to avoid running out of IPPOOL blocks by using the current ones.
If there's a sudden surge in connected users, and IPPOOL blocks remain allocated to a GPGW that was temporarily added via autoscaling, we'll run out of IPPOOL blocks.
To release IPPOOL blocks allocated to a temporarily used GPGW, the GPGW needs to become inactive. Therefore, I'd like to understand this mechanism.
If you have any information regarding the following, could you please share it with me?
Q1) You mentioned that the GPGW (MU-SPN) becomes inactive and is deleted. At which of the following timings is it determined that the GPGW is inactive (deleted)?
A: When no users access this GPGW (MU-SPN) anymore.
B: When the user's active session (idle timeout) ends.
Q2) Is there a way to make the GPGW (MU-SPN) inactive (deleted) sooner so that it can release the IPPOOL block as quickly as possible?
Best Regards,
Mami Otsuka
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!
