Welcome to the final article of this redundancy series. In the previous articles of this series, we have considered two technologies that can be used to achieve redundancy on Cisco devices: HSRP and static route backup using IP SLA. In this concluding article, we will be looking at another technology, known as server load balancing, which we will configure on Cisco IOS. I will also give you my real-life experience of a challenge I faced and how I used another technology to achieve similar things. Sit back (or up) and enjoy.

Server Load Balancing

In a bid to achieve high availability, organizations usually have a cluster of servers performing similar functions. For example, an organization that is involved in e-commerce activities may have multiple web servers to handle customer requests. This is done because one server may not be able to handle all the requests (limited resources such as memory and space). However, as an organization, you don’t want your customers to have to keep track of different URLs (for example) just to be able to access your website. There should be a way by which all these servers will be seen as one “virtual” server and the backend load distribution among the real servers will be invisible to the end users. This is exactly what Cisco IOS SLB helps you achieve—load balancing of servers and this is done using a Cisco network device rather than on the server side.

Users make connections to the virtual server’s IP address (192.168.10.123 in our diagram) and the IOS SLB is able to forward the connection to one of the real servers. IOS SLB determines which real server in a “server farm” to forward a connection to, based on a load-balancing algorithm that could either be weighted round robin or weighted least connections. You can read about these algorithms here.

What happens when one of the real servers in a server farm fails? This is one of the cool features of IOS SLB- it is able to detect server failure and stop sending connections to that server, thus avoiding a black hole.

Let’s see the configuration in action. We will be using the network diagram shown below.

Since this is a test environment, we will use routers to simulate our servers and configure SLB for Telnet. This way, we’d be able to verify what ‘server’ we are connected to.

Configuring IOS SLB

The basic configuration of IOS SLB is fairly straightforward: Configure the server farm(s), add real servers to that server farm and put them in service, create the virtual server(s), associate the virtual server with a server farm, and then enable the virtual server.

There are three things I’d like to talk about in the above configuration. The first is the nat server command: IOS SLB can run in two modes: Directed mode or dispatched mode. In dispatched mode, the virtual IP address must be known to the real servers either by configuring it as a loopback address or as a secondary address. Although this mode has better performance, you can use the directed mode (NAT) to bypass this requirement. You can read more about these modes here.

Secondly, I have configured the failure detection thresholds. The default values are 8 for number of connections and 2 for number of clients but, for testing purposes, I don’t want to have to initiate 8 connections from 2 different clients before it shows up as failed, so this works for me.

Finally, I have set the maximum number of connections that can be made to Real Server 1. Although the round robin algorithm will be used by the IOS SLB, you cannot really determine what server will be selected for a connection. For example, if you have two servers and you open a connection to server_1, the next connection may not necessarily be made to server_2, as you’d expect. This is entirely up to the algorithm. This is the reason I have configured a maximum number of connections for testing purposes.

So let’s test. First some show commands:

Notice that the state shows up as “Operational.” The real servers are not yet turned on. It means IOS SLB does not run some sort of a continuous ping to determine the state of servers; it only probes the state of a server when a connection is supposed to be made to that server.

As can be seen from above, the default load balancing algorithm is the weighted round robin.

I’d start up all the routers now so that we can test. I have set up normal routing connectivity: The servers have the IOS SLB router configured as their default gateway. Since I am using NAT and the virtual IP address is on the outside subnet, the outside router does not need to know about the 192.168.10.0/24 network. Finally, I have configured a route for the 4.4.4.4/32 on the IOS SLB router pointing to the outside router.

I’d exit and open another connection. As I mentioned earlier, your next connection may not be to Real_Server_2, so you may have to use leave two connections open on Real_Server_1 (using the CTRL+SHIFT+6+X [by default] combination to go back to the originating router console).

To get this, I had to leave open the connections, as I mentioned; see below:

Before we move on from this topic, I’d shut down Real_Server_2’s LAN interface so that we can see the automatic detection of IOS_SLB:

Notice now that the state of Real_Server_1 has changed to “MAXCONNS” meaning I have maxed out the connections that this server can accept. No new connections will be sent to that server until some connections are closed. Also note that Real_Server_2 has a state of “FAILED” because its failure threshold has been reached. In this situation, any connection to the virtual IP address will fail as there are no other configured real servers.

Also keep in mind that when the server comes back online, nothing needs to be done; the same way IOS SLB can detect that the server failed is the same way it can automatically detect when it is restored.

My personal experience with server load balancing

I once worked on a project where the client required load balancing of its servers and the client wasn’t going to use server clustering; it had to be done on the network devices. They were not also looking to buy a dedicated load balancer.

During the design phase of this project, we tested the IOS SLB feature using GNS3 simulation. However when we got to the site to deploy our solution, we entered the ip slb command and we got an unknown command error. We initially thought it was an IOS image fault and so we upgraded. It turned out that the router platform doesn’t even support SLB! How do you tell a client that you have made a mistake and the routers they have bought are not useful? Well, you don’t—not until you have explored all options. Where there’s a will, there’s a way. Let’s look at that way.

First, I removed all the IOS SLB configurations.

The solution is a technology that you are familiar with – network address translation. On Cisco IOS devices, you can configure a server TCP load balancing feature using NAT. You specify a NAT pool of IP addresses for the real servers, create an ACL to match the virtual IP address and then use the pool and ACL in a NAT destination list. The configuration is as shown below:

Let’s test from our outside router.

show ip nat translations on our IOS_SLB router gives us the following:

Keep in mind that server TCP load balancing using NAT works purely in a rotary fashion (like round robin without any algorithm). This means that, if you have two servers, your first connection will be to server_1, your second connection to server_2, your third connection to server_1 and so on. Let’s confirm this.

So far, all is still good in server load balancing land because you may not necessarily be interested in all the load balancing algorithms of IOS SLB. However, let’s see what happens when one of the real servers goes offline.

All the NAT translations have expired right now so I have a blank translation table.

I will shut down Real_Server_2’s LAN interface and then open the telnet connections from our outside router again.

Remember that the last connection I opened above was to Real_Server_1; using the rotary connection method, it means the next connection will be made to Real_Server_2. However, since that server is down, the connection failed. The IOS_SLB Router still created a NAT translation for this connection as shown below:

What does this tell us? Server TCP load balancing using NAT cannot detect failed servers! It will keep on making connections in a round-robin approach, whether or not the server is online. Ouch. While this is not necessarily a good thing, it may not be so bad; if for example, you are load balancing web servers where the user can just refresh the page because the next connection will succeed, as shown below:

Also notice the name of this feature: server TCP load balancing. It only works with TCP; other traffic is passed untranslated (except you have other NAT rules). Good or bad, this feature saved the day for that project and the client was happy.

Summary

This concludes the series on achieving redundancy with Cisco devices. Although there are numerous technologies for achieving redundancy, we have covered only three (or four)—HSRP, static route backup with IP SLA, IOS SLB, and server TCP load balancing using NAT. As we have seen in this article, there is usually more than one way of achieving something; however, you have to be aware of the benefits (and features) or one solution over the other.

I hope you have found this article and the entire series informative. If you have any questions or comments, do not hesitate to use the comment section.

Reference and Further Reading