Cisco SLB (Server Load Balancing) is meant to distribute load between several servers as well as to ensure fault-tolerance of the provided service since it supports its operation even upon failure of certain servers. SLB is not the only technology that is used for load distribution and quite often the network administrator use NLB or balance the load using DNS too. Using several load balancing techniques at the same time and applying various hardware balancers can also be done.
Cisco Server Load Balancing functions in two modes: L2 and L3. The easiest mode to understand and implement is L3; during this mode the router doesn't only distribute TCP or UDP sessions between the servers, but also change the receiver's IP-addresses (NAT), occasionally together with TCP/UDP port of the receiver (PAT). The real server address is chosen as the receiver's address. The advantage of this load balancing method is a possibility to locate the balancing router and servers in various L3 subnets. Among its drawbacks is a higher CPU utilization which is due to NAT/PAT operation.
NAT/PAT translations do not function in L2 mode, or in other words the receiver's address and port remain the same. So-called selection of the server is performed only on the grounds of the change of receiver's MAC-address. This way all servers will be applied an additional requirement: the OS interface to which the service IP-address has been assigned must be always active. Assigning this kind of IP-address directly to the Ethernet-interface (or a secondary address) is not the best idea since its activation will lead to sending a broadcast ARP query about this address, resulting in an error message about IP-address duplication (which all other similar servers will reply to). In effect, special loopback interfaces are used for that.
The example of a network in which SLB functions is presented below. It's worth noticing that loopback interfaces on the servers in this scheme will only be used upon operation of SLB L2 mode. Client and router external interfaces masks are not shown since in the real network these addresses will obviously come from various sub-networks and may be random.
Configuration of devices featured in this lab is divided into three parts: at first the L3 mode scheme is built, then the reconfiguration is done in order to switch to L2, and then (strictly in the emulation mode) building of a fail-proof load balancing scheme is carried out. It's worth pointing out separately that this lab should be done only when one knows how to do all previous and simpler labs. There's no exact sequence of actions for each setup item, which lets the student be creative and get him/herself familiar with all supportive features. The third part is done strictly in the emulator mode.
When doing this lab using real equipment, please use Cisco 3640 as the router with SLB and choose Cisco 7200 router upon operation in the emulator mode. Also, in the emulator mode one can use routers as the clients and servers.
- Perform all necessary connections and manage all settings for the initial setup (assigning IP-addresses, managing routing, configuring virtual networks on the switch). Make sure that the scheme that you built is operable. One should understand that in the real network there won't be access to the servers externally due to two reasons: firstly, private IP-addresses are not routed globally and secondly, all excessive accesses can be blocked with the access lists.
- Switch from the global configuration mode to the virtual server farm test management mode on SLB router using ip slb serverfarm test command.
- Type nat server command in order to switch the server farm to L3 mode.
- Decide what service needs to be launched in order to test the scheme being built. Upon operation in the emulator mode one can use telnet with the routers-servers as a service. Switch to 10.0.0.2 server management mode in the farm using real 10.0.0.2 port command where port is the port number with the active service under test. Activate the server in the farm using inservice command. Repeat this procedure with the second server. Generally, the port number of a certain server may be different from the port numbers of other servers and the service external port.
- Examine the following supportive features: faildetect, maxconns, predictor, retry, and weight.
- Use sho ip slb serverfarms, sho ip slb serverfarms detail, and sho ip slb reals privileged mode commands to review statuses of the server farms and servers that are assigned to them.
- Use ip slb vserver test command to switch to the test virtual server management mode.
- Use serverfarm test command to assign test server farm that you previously created to this virtual server.
- One can specify the address (it's 22.214.171.124 in this lab), protocol, and port of the external server using virtual 126.96.36.199 protocol port command.
- Switch the virtual server to the service mode using inservice command. Additionally examine capabilities of the following features: advertise, client, sticky, and synguard.
- Examine capabilities of sho ip slb conns, sho ip slb reals, sho ip slb stats, sho ip slb sticky, sho ip slb vservers, and sho ip slb wildcard review commands.
- Launch test service on the test servers and connect to them via the client. Use netcps, iperf, and similar utilities to measure the performance of the router with SLB in L3 mode on the real equipment.
- Make sure that disabling of any server doesn't lead to the failure of the service.
- Create loopback interface with 188.8.131.52 address assigned to it on the test servers or routers in the emulator mode.
- Create a new server farm, but do not use nat server command.
- Add servers to the new server farm. One doesn't need to specify the port upon adding the server to L2 farm.
- Shut down test virtual server.
- Change the server farm on test virtual server with a new one.
- Activate test virtual server.
- Make sure that the new operation mode of SLB functions well.
- Test the service availability upon disabling any of the servers.
- Build a new scheme in such a way so that apart from SLB router there is also another router of the same model and with the same IOS version.
- Set up HSRP with a named group on both of the routers.
- Shut down test virtual server.
- Copy the settings from the first SLB router to the second.
- Activate test virtual server on both of the routers using inservice standby name command where name is the name of the preconfigured HSRP group.
- Make sure that the virtual server status depends on the node status in the configured HSRP group.
- Test fault-tolerance of the scheme by separately disabling both SLB routers.