Firewall Load Balancing

Firewall load balancing distributes traffic across multiple firewalls, providing fault
tolerance and increased throughput. Firewall load balancing protects your network by:

 Dividing the load between the firewalls, which eliminates a single point of failure
and allows the network to scale.
 Increasing high availability.

Firewall Load Balancing Methods

The following load balancing methods are supported for firewall load balancing.

 Least Connections
 Round Robin
 Least Packets
 Least Bandwidth
 Source IP Hash
 Destination IP Hash
 Source IP Destination IP Hash
 Source IP Source Port hash
 Least Response Time Method (LRTM)
 Custom Load

F5 LTM Load Balancing Methods

Load Textbook Austin’s Insight
Balancing Description
Method

Round Round Robin Round Robin is a static lb method you pick in early application testing when you have
Robin method passes each little or no information about the application and backend servers. In other words, there
new connection are typically better options – but if you needed to get something distributing traffic quick
request to the next with little background info round robin will work.
server in the pool,
eventually It can also be a good baseline to identify if the application is stateful – ie if it would
distributing require a persistence profile, if you did round robin would break your app.
connections evenly
across the array of
machines being
load balanced. This
 is the default load
balancing method.

Ratio The BIG-IP system Ratio load balancing is a static load balancing method basing traffic distribution on the
(member) distributes ratio you set, ie 3 to 1, 2 to 1, 5 to 2.
connections among
Ratio pool members or Sometimes folks will use ratios according to server size, ie double the server size send
(node) nodes in a static twice as much traffic to it. I’m not a huge fan of static ratio load balancing as things don’t
rotation according always work out like that in the real world. I do however think they are useful for load
to ratio weights that balancing things you can’t easily measure and are more static – like circuits in a gateway
you define. In this pool. For example, if you have a gateway pool with two circuits, one is 1gb and the other
case, the number of is 100mb, a static ratio might make sense – but it always depends.
connections that
each system
receives over time
is proportionate to
the ratio weight you
defined for each
pool member or
node. You set a
ratio weight when
you create each
pool member or
node.

Dynamic The Dynamic Ratio Dynamic ratio load balancing is great for application traffic that can vary greatly from
Ratio methods select a user to user. For example, a user for a payroll application might generate reports for 100
(member) server based on employees made up of big bulky PDFs, vs a user who is just logging in to make a change
various aspects of to her account. If you based your traffic distribution decisions on a static load balancing
Dynamic real-time server method, or even one of the simpler dynamic methods like least connections, you wouldn’t
Ratio performance have a good way of knowing one server is working 500% harder than the other pool
(node) analysis. These members and is subsequently slower – unless you have a way to measure server
methods are similar performance – let me introduce you to dynamic ratio load balancing… 😉
to the Ratio
methods, except In order to use this load balancing method you will need to apply a performance monitor
that with Dynamic at the node level to the members in the pool and ensure the server supports that data
Ratio methods, the collection. Other than the SNMP performance monitor, performance monitors require
ratio weights are their specific plug-in file to be installed on the actual server.
system-generated,
and the values of
the ratio weights
are not static. These
Server type Monitor plug-in Monitor Type
methods are based
on continuous
monitoring of the
servers, and the
RealServer Win F5RealMon.dll Real Server
ratio weights are
therefore
continually
changing.
RealServer UNIX f5realmon.so Real Server
Note: To
implement
Dynamic Ratio load
balancing, you must Windows Server f5isapi.dll or F5Isapi64.dll or WMI / SNMP DCA & SNMP
first install and
configure the
 necessary server
software for these WMI F5.IsHandler.dll DCA Base
systems, and then
install the
appropriate
performance Windows 2000 SNMP agent SNMP DCA & SNMP DCA
monitor. Server Base

UNIX Server UC Davis SNMP agent SNMP DCA & SNMP DCA
Base

Read more about installing performance monitor plugins

here https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/big-ip-local-
traffic-management-basics-14-0-0/07.html.

Fastest The Fastest The key to understanding the fastest load balancing method is to grasp that an
(node) methods select a “outstanding request” is one that has not received a response. The BIG-IP has a counter
Fastest server based on the on each pool member that increments when it receives a L7 request, and decrements those
(applicatio least number of counters as soon as the response is received.
n) current outstanding
sessions. These This method comes in handy when your pool members are located in different networks /
methods require data centers where latency might become a factor.
that you assign both
a Layer 7 and a Again, you’ll need a TCP profile and a layer 7 profile – for example an HTTP profile.
TCP type of profile
to the virtual server. Note: You’ll see the disclaimer txt from F5 to the left “If the OneConnect feature is
enabled, the Least Connections methods.. etc etc..” When they say “least connection
Note: If the methods” they are talking about the load balancing methods that in one way or another
OneConnect™ featu distribute traffic to pool members based on least connections. Those methods are: Least
re is enabled, the Connections, Weighted Least Connections, Fastest, Observed, and Predictive.
Least Connections
methods do not
include idle
connections in the
calculations when
selecting a pool
member or node.
The Least
Connections
methods use only
active connections
in their
calculations.

Least The Least The Least Connections method is a good choice when the servers you’re load balancing
Connection Connections have similar performance capabilities, AND the application traffic on the servers DON’T
s (member) methods are vary greatly from user to user. Recall earlier in the article where when we discussed the
relatively simple in payroll app – just because the server has less connections, it doesn’t necessarily mean it’s
Least that the BIG-IP going to be faster. In those situations, you should take a look if dynamic ratio load
Connection system passes a balancing and investigate if it meets your needs.
s (node) new connection to
the pool member or Since there are some dependencies and complexities to dynamic ratio load balancing,
node that has the weighted least connections method may be a good choice when you have servers with
least number of
 active connections. varying capacity that you can quantify.

Note: If the
OneConnect feature
is enabled, the
Least Connections
methods do not
include idle
connections in the
calculations when
selecting a pool
member or node.
The Least
Connections
methods use only
active connections
in their
calculations.

Weighted Similar to the Least Weighted least connections requires you to have a good handle on server capacity, which
Least Connections can be hard to quantify. Additionally, if your application have dynamic traffic varying
Connection methods, these load from user to user it can skew the limits you set. Moral of the story? If your pool is made
s (member) balancing methods up of servers with different capacities and the app is relatively static, weighted least
select pool connections can work for your situation – but not the best for adaptive traffic distribution.
Weighted members or nodes
Least based on the
Connection number of active
s (node) connections.
However, the
Weighted Least
Connections
methods also base
their selections on
server capacity.

The Weighted
Least Connections
(member) method
specifies that the
system uses the
value you specify in
Connection Limit
to establish a
proportional
algorithm for each
pool member. The
system bases the
load balancing
decision on that
proportion and the
number of current
connections to that
pool member. For
example,
member_a has 20
connections and its
connection limit is
100, so it is at 20%
of capacity.
Similarly,
member_b has 20
connections and its
connection limit is
200, so it is at 10%
of capacity. In this
case, the system
select selects
member_b. This
algorithm requires
all pool members to
have a non-zero
connection limit
specified.

The Weighted
Least Connections
(node) method
specifies that the
system uses the
value you specify in
the node’s
Connection Limit
setting and the
number of current
connections to a
node to establish a
proportional
algorithm. This
algorithm requires
all nodes used by
pool members to
have a non-zero
connection limit
specified. If all
servers have equal
capacity, these load
balancing methods
behave in the same
way as the Least
Connections
methods.

Note: If the
OneConnect feature
is enabled, the
Weighted Least
Connections
methods do not
include idle
connections in the
calculations when
selecting a pool
member or node.
The Weighted
Least Connections
methods use only
active connections
in their
 calculations.

Observed The Observed Observed load balancing is ratio load balancing where the ratios are dynamically assigned
(member) mode dynamic load by the F5 every second based on connection counts. Observed can work well for small
balancing algorithm pools with varying server speeds, but does not perform well in large pools and should be
Observed calculates a avoided in those situations.
(node) dynamic ratio value
which is used to
distribute
connections among
available pool
members. The ratio
is based on the
number of Layer 4
(L4) connections
last observed for
each pool member.
Every second, the
BIG-IP system
observes the
number of L4
connections to each
pool member and
assigns a ratio value
to each pool
member. When a
new connection is
requested,
Observed mode
load balances the
connections based
on the ratio values
assigned to each
pool member,
preferring the pool
member with the
greatest ratio value.

Predictive The Predictive Predictive is similar to observed except the ratio is derived from a trend over time. Ahhh
(member) methods use the so what is the length of time the predictive load balancing method bases its decision on,
ranking methods you ask? That time has never been confirmed or denied by F5. It’s rumored to be based
Predictive used by the on the monitoring interval, but some brief testing proved inconclusive.
(node) Observed methods,
where servers are
rated according to
the number of
current
connections.
However, with the
Predictive methods,
the BIG-IP system
analyzes the trend
of the ranking over
time, determining
whether a node’s
performance is
currently improving
 or declining. The
servers with
performance
rankings that are
currently
improving, rather
than declining,
receive a higher
proportion of the
connections.

Least The Least Sessions This is an interesting option for a load balancing method, as it bases the metric off of
Sessions method selects the persistence table entries. There are only a couple persistence types that the F5 maintains
server that currently tables for – they are Source Address, or Universal persistence.
has the least
number of entries in Universal persistence allows you to persist traffic based on header or content data (in the
the persistence client request and server response) that you specify in an iRule. Whether it’s source
table. Use of this address, or universal – the traffic distribution works the same way – the pool members
load balancing with less persistence table entries get more traffic.
method requires
that the virtual
server references a
type of profile that
tracks persistence
connections, such
as the Source
Address Affinity or
Universal profile
type.

Note: The Least

Sessions methods
are incompatible
with cookie
persistence.

Ratio Least The Ratio Least You don’t see this ratio least connections used very often in the wild, and for good reason
Connection Connections – there are usually better options.
s methods cause the
system to select the
pool member
according to the
ratio of the number
of connections that
each pool member
has active.

Note – If a ratio
weight is not
specified, it will be
treated as a default
value of 1.