How To Avoid F5 LTM SNAT Pool Exhaustion

In the recent Indeni 6.0 release, we are excited to announce additional knowledge support for F5 Networks. One of the most common pain points customers of F5 users is around managing SNAT pools.

Why use SNATpool availability?
Source Network Address Translation (SNAT) is used by an F5 load balancer to allocate a dedicated IP and port for a connection facing a pool member. This allows the pool member to return the traffic to the correct session. SNAT uses ports to do the translation, and there is a limit to the number of ports one can use concurrently for a given IP address. Indeni will alert when the SNAT pool is nearing its capacity.

Watch this video to see how Indeni helps IT operations avoid F5 SNAT pool exhaustion or check out the alert & remediation steps.

View Full Transcript of the Video Here
Charles Kim: Hey guys. Welcome to the very first Indeni weekly connect video. My name is Charles Kim. I’m an SE here, and today I’ll be focusing on the F5 LTM. The reason why we’re focusing on it is that we just released the support for it this month, and I’m really excited to provide some of the checks that we do for F5 LTM.

Let’s go ahead and generate a quick little architecture of an F5 load balancer with a pool that’s called WebServer.com and it has associated to it three different pool members, or three different physical servers connected to it. And, I’ll be identifying them as 1, 2, and 3.

Now, Indeni will be connecting to the F5 LTM via the management IP. It will be leveraging the API that’s provided in the description below. Please feel free to try to leverage it using a curl command or through a basic request through your HP browser. What you’ll notice is the output is very hierarchical thanks to the RESTful API of the F5 architecture.

Now, let’s say, for example, at any given time there’s a client trying to access my pool or WebServer.com. I’ll try to communicate. We’re using the virtual IP interface we provide to the F5, and the F5 load balancer will go ahead and intercept that traffic. Based on what it determines of which pool members are up, it’ll rout the traffic or establish a TCP connection to the available pool members. But, let’s say, for example, pool member 3 goes down. Well, that’s pretty standard, because at any given time, someone can be doing an update. But, let’s say pool number 1 is down, as well. Well, that’s not a big deal either. At least we still have pool number two. But, what happens if pool number two goes down as well? Well, it will only determine which pool members are available to receive connection and traffic through it. At any given time, if all three pool members are down, it’ll go ahead and try to… It’ll drop all further client connections.

Before we get to that point: The Indeni platform is capable of checking using the API query to determine if there’s at least one pool member up, and by doing so, will alert you if the pool itself is running at a very low capacity. If that happens, we can go ahead and proactively let you know when you should be checking your pool members to determine if you should take a look at pool number 1, or pool number 3; and, maybe you can alleviate or fix the issues that are happening at those pool members and then bring it back up to full capacity. So, there you guys have it. That’s the Indeni check for F5 load balancers and their pool capacity and determining at any given time if the pool capacity is running very low. If you guys have any questions, please feel free to pose on the forums or in the community, or feel free to reach out to Indeni. Thank you.

 

Like getting network best practices? Subscribe to our newsletter which gives you access to Indeni Crowd. You can also join the F5 Networks discussion on Indeni Crowd or Download Indeni today.