11 April 2013

F5 Diaries - Episode 3 ISP Load Balancing

Having redundancy or fail-over is one thing, having active load balancing is another.  F5 LTM allows you to
configure both.

In Episode 1 and 2 I covered building the lab and setting up a very basic ISP redundancy.  In this episode  I will place that configuration in a real world deployment, send some traffic trough it and monitor and tweak setting until we have load balancing.

Real world deployment.
Combining your ISP links is most effective if it is done as close to the perimeter as possible.  This means it normally sits outside the corporate firewall.  Clients would then access the load balanced gateway through a NAT or proxy.

Expected conversations
From the proxy perspective the traffic source will be the individual internal IP addresses of the client computers.

From an F5 perspective all the TCP/IP traffic will have the same source IP.  The one of the Firewall or Proxy.  The destination will be the Internet site.  The F5 will elect the external interface to use to send the traffic to that site.

From the internet site the source IP would be the public IP associated with the link that was used.  If the route was via ISP1 the source would be different if the route was via ISP2

Configuring persistence
Once a TCP conversation is started on one route you would like to maintain that route for the duration of that conversation.  This is persistence.  Normally persistence is based on the client address or session cookie.  However in this case the source IP will always be the same. This is great for persistence but would not allow for effective load balancing.  We can use the destination address since this will be very different from conversation to conversation.

  • Local Traffic
  • Virtual Servers
  • Default_gateway (your wildcard VS)
  • Resources
  • Set Default Persistence Profile to dest_addr

Deciding how to split the load
The ideal is to be able to connect many different ISPs with potentially different performance capabilities.  As an example the lab has 1 x 4MB ADSL and 1 x 512KB ADSL.  Because these links will have varying different performance and load on them you want to set the load balancing method to be a dynamic on that evaluates the connection count as well as the performance.

The Observed (node) method uses a combination of the logic evaluating fastest response time and least connections.

  • Local Traffic
  • Pools
  • default_gateway_pool
  • Members
  • Set the Load Balancing Method to Observed (node)

Test your deployment
This setup work nicely for the lab but your environment will probably different in some regard.  It is important to check and see that your load is being distributed as you would like it to be.

You will need:
A number of client computers attempting to access the Internet through your gateway or proxy.  The wider the scope of sites being requested the better.

One of the easiest places to check that load is going to the various ISPs is the monitor the pool

  • Statistics
  • Module Statistics
  • Local traffic
  • Statistics Type Pools
  • Enable Auto Refresh

After letting traffic run for a bit this is what I could see.  It is as expected with the Telkom line has theoretically 8 x bandwidth of the IS line

Monitor traffic using tcpdump
Seeing traffic being split across the  nodes is useful.  It gives you a high level overview to see that things are going as expected.  If however you want to get a closer look as to what is actually goimg where you will need to check out TCP flows with tcpdump in an SSH session

To see outbound traffic from both of the internet facing self ips you will need to specify the following

tcpdump  src host internetIP1 or internetIP2 -i any

T narrow down to HTTP and HTTPS traffic only

tcpdump src host internetIP1 or internetIP2 and dst port 80 or 443 -i any

To see traffic outbound and  inbound for HTTP and HTTPS

tcpdump host internetIP1 or internetIP2 and dst port 80 or 443 -i any

For a bit more info on tcpdump check


No comments:

Post a Comment