Who rated this post

I was a contributor to the CCME course material and wrote this section.  The CCME material simplifies the discussion somewhat by citing an example of "Static Hide NAT source port allocation" which was used prior to R77.30, which is close but is not precisely how Dynamic Port allocation works.  Everything in the next paragraph applies equally to "regular" gateways and Maestro gateways.  

GNAT was introduced on standard security gateways in R80.40 and Maestro gateways in R81.20.  GNAT is enabled by default on gateways with 8 more more total cores (whether SMT or not).  As stated with the older Dynamic Allocation, for each Hide NAT address a portion of the 50,000 available ports are allocated via an initial quota block to the various CoreXL instances as needed.  If the instance needs more it can request another block and also release blocks if no longer needed.  With GNAT, a global pool of ports for each Hide NAT address can be allocated one-by-one on demand by the CoreXL instances as they need them for each new Hide NAT operation, instead of pulling a larger block of source ports from the pool which may end up not being completely used.  This more efficient GNAT allocation reduces the chance of port exhaustion, especially as the number of instances increases which is why it is only enabled on gateways with 8+ cores, since GNAT does cause additional allocation/deallocation overhead.

Now let's talk Maestro.  First off the Orchestrator does a simple hash calculation based on the pre-NAT packet IP addresses (and port number if L4 distribution is enabled) when deciding which security group member to send the packet to.  If the packet is the first of a new connection, the Dynamic Dispatcher on the security group member who received the packet allocates it to a CoreXL instance for handling, based on which instance has the lowest CPU load.  In theory different connections that are Hide NATted behind the same IP address yet all going to the same destination IP address should usually end up on different CoreXL instances.  But even if they don't and they all somehow end up on the same instance, GNAT helps ensure that a situation will not occur where a certain instance cannot allocate any more source ports for that Hide NAT address (exhaustion), yet some other instance is holding onto some of the available, yet unused source ports for itself corresponding to the same Hide NAT address.

So you are correct GNAT does not increase the total number of Hide NAT source ports beyond 50k, but it helps ensure that the source ports for each Hide NAT address are allocated and released as efficiently as possible among the instances, without "wasting" unused source ports thus increasing the chance of exhaustion.