I’m picking up here from my previous article on a couple of F5 BIG-IP boxes I’m lucky enough to have the opportunity to play with. In this article I’m going to spend some time going over some basic configuration information. Now this is where the real fun starts 
.
At the heart of the BIG-IP configuration are what F5 calls virtual servers. Each virtual server is assigned an IP address referred to as a virtual ip or a VIP (rhymes with nip when we say it around here). Anyone familiar with HSRP or VRRP is familiar with the concept of a virtual IP. It’s simply an IP address the F5 is configured to listen for and respond to, but is not actually configured on any interface. Along with the virtual IP, a virtual server will need to be configured with a port number and application type (allowing for the use of nonstandard ports for common network apps). You also have many additional options you could configure your virtual server with in regards to additional security, performance enhancements, and SSL settings (of which I’ll touch on later).
Most of the time you’ll also be assigning a pool list to your virtual servers. A pool list is a predefined group of real server(s) that host a particular application. A pool list will contain a listing of all of the (actual) IP addresses of the servers along with the way in which the F5 will load-balance between them. Different servers in the list can be assigned different priorities – the F5 will always send traffic to a higher priority server over a lower-priority one.
You also configure your load-balancing settings at the pool-list level, allowing you to differentiate how you load balance different applications. There are a multitude of different options for load-balancing your servers, including round-robin, fastest, least connections, predictive, and many more. When configuring your load-balancing for a pool-list, you are also able to set up monitors for that list, which allows the F5 to monitor the health of the systems it’s load balancing and avoid sending traffic to an unavailable server.
As I touched on in the previous article, BIG-IP functions in proxy mode. Incoming TCP connections to the virtual IP are handled on the appliance, and a new connection is initiated by the F5 for the destination server to complete the conversation. The client and server never directly communicate with each other, making the F5 a true “man-in-the-middle”.
This F5 proxy communication architecture means that the BIG-IP appliance can now terminate SSL connections for your servers. The offloading of SSL can be a big performance boost on your systems, but it may mean some significant changes for your organization. SSL certificates will now reside on the F5 device (they’re tied to a virtual server) instead of on the server(s) themselves. Most of the time it seems like moving the location of SSL certificates doesn’t cause major issues, but there are applications out there that will require quite a bit of modifications in order to work well (*cough* Citrix *cough*).
As you can imagine, I really just broke the ice with your configuration options here. I didn’t even get into setting up iRules (which we use for server redirects), authentication, routing issues, SNAT, or the fail-over setup. I’m sure I’ll be back to revisit these topics in a later post .
Please drop me a line if any of you F5 gurus out there see I’ve butchered a point or would like to clarify something I said. Also, if you’re looking for a good technical read, check out how F5 built the Traffic Management Operating System (TMOS), which is the underlying operating system of the BIG-IP. Fascinating stuff.
As always, thanks for reading.
Jason