Design Strategies in F5 LTM–Part 1

A key to an effective, resilient and robust network is a good design. Big IP design is a key for faster and more effective failover leading to greater availability and lesser convergence time. This blog is written with the deployment considerations that are done.
A Big IP works like a switch, having VLAN’s and Spanning Tree Protocol. This enables the Big IP to fit right into your LAN design. You are offered with choices of Active/Standby (Failover) pair or Active/Active or as I like to call it, the “load balance your load balancer” pair, which doubles up on covering for each other. All this is feasible with the concept of “Floating IP”, “Gratuitous ARP” or “Mac Masquerading”.
When the initial configuration of Big IP is done, these are things you need to consider,
  1. What business purpose will this need to serve?
  2. How many businesses are going to be using it?
  3. Where is the load balancer going to be located physically?
  4. Where are the Servers that need to be load balanced going to be located?
Well I have assumed that the Big IP is rightly sized based on the Capacity Planning and licensed as per needs. The above questions will lead us to the answers for one of the most critical things in design, (i.e.) The number of VLAN’s that will be on the Big IP.
We have the following options when designing the Big IP deployments
  1. One Arm Mode
  2. Two Arm Mode
  3. Multi Arm Mode
The number of Arm’s are nothing more but the number of VLAN’s that are created and active on the Big IP. We in this blog will only detail the One Arm Mode:
One Arm Mode is the most common kind of deployment seen nowadays. This is very easy to achieve, this means, creating just one VLAN on the Load Balancer, both the physical servers to be load balanced and the Clients that are try to reach the servers use the same VLAN. So if the Load balancer can reach the clients and servers using that VLAN, we are all set.
This causes the minimum impact on the existing LAN / WAN Design. But it is to be noted that for this to work, we need to enable SNAT (Source NAT) settings on our load balancer.
The below diagram shows the functioning of the One Arm Mode and traffic flow with and without SNAT.
 
image
One ARM Mode – Physical Connection
Traffic Flow (Without SNAT)
image
As you can see without SNAT the traffic flow will be asymmetric and the F5 will block the next packet and so the above will not work. (There is a way to make this setup work as well, that is called n-path in F5 terminology and DR mode (Direct Routing Mode) load balancing in general terms. More on that later.
With SNAT:
image
As you can see with SNAT the traffic flow Normalizes and the connection starts working again.
Thus this is one of the most commonly deployed scenarios in the Load Balancer world, I will be detailing the other modes in my future blog posts, so till then, take care …

Comments

  1. siddOctober 25, 2011 at 11:14 PM

    very informative, when can we expect part-2

    ReplyDelete
  2. Thunder EmperorOctober 29, 2011 at 5:57 PM

    sure sidd ... if you are interested in some thing, I can detail on that first ...

    ReplyDelete
  3. WinterFebruary 19, 2014 at 4:49 PM

    Hi - where can I find this icons you have used in your diagram ? Cheers

    ReplyDelete
    Replies
    1. Thunder EmperorFebruary 22, 2014 at 12:52 AM

      Visio 2010 and F5 stencils that you can download of devcentral

      Delete
  4. RobsecMay 17, 2014 at 10:25 PM

    Hi
    Is this design still hold for LTM in 2014 ? Thanks !

    ReplyDelete
    Replies
    1. Thunder EmperorMay 23, 2014 at 7:47 AM

      May be ... It really depends in what you want to do. The designs could be made a little better due to Viprions and what not, but the basic construct is pretty much the same

      Delete
  5. LucasSeptember 29, 2016 at 8:50 PM

    This comment has been removed by a blog administrator.

    ReplyDelete

Post a Comment

Popular posts from this blog

Juniper Aggregate Interfaces (LACP/No LACP)

Image
Last week, I was implementing link aggregation on Juniper EX Series switches (EX4200). I was moving them off HP switches and putting them into Juniper. We were moving VMWare ESX boxes, NetApp and some physical boxes, though the configuration is very simple, I would like to mention how to do those with these boxes. Points to remember: You will explicitly need to create “Aggregated Ethernet” interfaces on juniper You cannot have more than 64 AE interfaces on a single Virtual Chassis You cannot change the algorithm for load balancing between the multiple links. (If you are interested in the Junipers LAG algorithm read this ) Now having said this, lets look at the common steps, you need to create the Aggregated Ethernet interfaces on the Juniper. root@EX4200#set chassis aggregated-devices ethernet device-count  4 The above command will create 4 “ae” interfaces, after you commit, you should see ae0 – ae 3 created. You can have any value between 1 and 64 in...
Read more

Exporting Contacts out of Blackberry with Windows Contacts

Image
So, you are trying to get your contacts out of your blackberry and sync it to your Android / iPhone / Windows Phone, or just want to sync it to your Google account for backup purposes. Here are a few tips that will get you started – I have just enumerated some methods. Option 1: Use Blackberry Desktop 6 (Manual) (Not the most updated software) – It can directly export out your contacts out in the CSV Format. Please read the official How-To here Option 2: Using Blackberry Desktop 7 (Manual) If you have a Blackberry Desktop 7 – Which most likely you may end up having, here is how you can do it – For people who don’t want to use the sync (Option 3) Step 1: Backup BB Contacts to Windows Contacts Connect your Phone to your Windows (Assuming you have Windows 7/8/8.1) Click On Organizer Select Configure Select “One-Way to Your Computer and Windows Contacts (You may Sync it to your outlook, but that’s not covered in this blog) Click on Sync Organizer (Sync All) on ...
Read more

Configuring Multicasting with Juniper EX switches (Part 1)

Image
Configuring multicast routing using Protocol Independent Multicast in a all Juniper environment is as simple as the Cisco environment, but when I searched, I dint find good articles or KB’s explaining this, so I decided to write one. I am fairly certain that if you have searched and arrived at this post, you know the basics of multicasting and IGMP, but yet, for the benefit of all readers, I will in brief describe the need for multicast. Please note, that this is just the IPv4 version of the story presented in a understandable manner and not all aspects of multicast are covered, but only the ones needed for this post. What is Multicast ? In IPv4 we have 3 kinds of packets, Unicast – One Source, One Destination Broadcast – One source and all destinations Multicast – One source and many destinations Now, all of us are familiar with the first one, we use it almost every minute we are on a network connected equipment. To, explain all this, lets choose different ...
Read more