Traffic Distribution with Server Load Balancing

As you recall from Chapter 11, you can use NAT to load-balance traffic among multiple internal servers. However, I also mentioned that this feature, configured with ip nat commands, has the following limitations:

• It cannot detect whether an internal server in the group fails. This means that the Cisco IOS always will forward traffic to servers in the group, regardless of their operational status.

• It cannot determine loads of the internal servers, so it cannot perform load balancing efficiently.

To deal with these deficiencies, Cisco introduced the Server Load Balancing (SLB) feature in Cisco IOS 12.0(7)XE. As with IP NAT traffic distribution, SLB provides server load balancing, but it does so in a more intelligent manner. With SLB, you define a virtual server on your router, with the virtual server representing a group of real servers, commonly called a server farm. The Cisco IOS takes care of redirecting packets that are directed to the virtual server to the various servers in the server farm. Depending on the platform, such as the Catalyst 6500 switch, this process can be done in hardware.

SLB Process

SLB can operate in one of two redirection modes:

• Directed mode

• Dispatched mode

In directed mode, you assign the virtual server any address that you want. The real servers in the SLB group do not know this address. Instead, the Cisco IOS translates the virtual destination address to an address of one of the real servers by performing NAT. Figure 12-9 illustrates how directed mode works. In this example, a virtual IP address of 192.1.1.1 is used. When Internet users want to access the internal virtual web server, they put 192.1.1.1 in the destination IP address field of the IP header. When the router receives this packet, directed mode causes the Cisco IOS to change 192.1.1.1 to one of the addresses that the internal servers use, recalculate the CRC, and then forward the packet to the internal server. This process is very similar to traffic distribution, discussed in the previous chapter.

Figure 12-9. SLB: Directed Mode

In dispatched mode, which is the default mode for SLB, the real servers know the virtual server address. Actually, the real servers have two IP addresses configured on them: their own personal IP address and the virtual IP address. The virtual IP address is configured as either a loopback address or a secondary IP address. Figure 12-10 illustrates this mode. In the figure, the two file servers have two addresses configured on them: their real address (10.0.0.x) and their virtual address (192.1.1.1).

Figure 12-10. SLB: Dispatched Mode

One advantage that dispatched mode has over directed mode is that your router's Cisco IOS does not have to perform address translation on the dispatched packets: It only redirects them, thus maximizing your throughput. With directed mode, the Cisco IOS must change the destination IP address as well recalculate the CRC, which is not necessary in dispatched mode. The limitation of dispatched mode, however, is that the real servers must be connected, through Layer 2, to your router. Of course, if your Layer 3 (perimeter router) device has Layer 2 functionality, as a Catalyst 4000 or 6500 switch with routing functions does, this is less of an issue; if this is not the case, you must connect your router and real servers in the server farm to the same Layer 2 switch. Otherwise, intervening internal routers between your perimeter router and the real servers might not be capable of routing the traffic to the appropriate server. Remember that all of them have the same virtual IP address configured on them. This is the same address in the packet header, so the intermediate routers do not know how to load balance this information. At least if the router is connected directly to the subnet with the server farm, it knows about the real addresses of the server farm and can use the appropriate MAC address found in its ARP table to forward the packet with the virtual address to the correct server.

Load-Balancing Algorithms

This section takes a closer look at the load-balancing process that SLB uses. This process is actually much more sophisticated than what I briefly described in the previous section. The Cisco IOS can use two load-balancing algorithms with SLB:

• Weighted round robin (WRR)

• Weighted least connections (WLC)

Weighted Round Robin

With WRR, the assignment of real servers to handle connections is done on a round-robin fashion: Each real server services a portion of the connections. Because each server might have different performance characteristics, SLB's WRR enables you to assign a weight to a server, basically identifying how many connections that it can handle compared to other servers. For example, assume that the weight on all servers is 1, but for one more powerful server, the weight is 2. In this instance, all of the weighted-1 servers would have one connection assigned to them as the Cisco IOS performs its load balancing. However, when the Cisco IOS reached the weighted-2 server, the Cisco IOS would assign two connections to it. After the Cisco IOS went through the list of real servers, it would start over at the top of the list.

Weighted Least Connections

With WLC, the Cisco IOS examines the number of connections that a real server currently has been assigned. Based on this number, when the Cisco IOS needs to assign a new connection to a real server, it chooses the real server with the fewest number of assigned connections. As with WRR, you can assign a weight to a real server, indicating the likelihood that it can handle more or fewer connections than other servers. The capacity of a real server is the assigned weight of the server divided by the sum of assigned weights of other servers. For example, if a server farm had two servers, with one server (A) having a weight of 1 and the other (B) having a weight of 2, server A would be assigned one third of the connections (1 / [1 + 2] = 1/3), whereas server B would be assigned two thirds of the connections (2 / [1 + 2] = 2/3).

Other SLB Load-Balancing Features

SLB offers other load-balancing features, including the following:

• Slow start? When SLB uses WLC for load balancing, a condition can exist where a real server with no connections can be assigned so many new connections that it is overloaded. This feature prevents this process by controlling the number of new connections redirected to the real server that was just enabled or that became available.

• Maximum connections? You can limit the number of active connections that a real server handles in a server group.

• Port-bound servers? Based on the TCP or UDP port number of the connection, a specific server group can handle the connection. This enables you to have one server group handle one application, such as www, and another handle a second application, such as FTP.

• Client-assigned load balancing? You can limit the access that a client has to a virtual server. For example, you might have two server groups: one for internal clients and one for external clients.

• Sticky connections? If a client has an existing connection to a real server, subsequent connection requests from this client can be assigned to the same server. A configurable timer is used so that, even if no current connections exist from the client to the real server, the real server that the client previously used can be assigned again to the client. This feature is useful if you have two server groups, such as one for HTTP and one for HTTPS. In this example, instead of the two real servers from the different groups handling the connection requests for the client, sticky connections allow one real server in just one of the groups to handle the client's connection requests.

• Automatic server failure detection? SLB increments a failure counter for a real server when a TCP connection attempt fails for different (not the same) clients. If the number of failed connection requests reaches a predefined threshold, the Cisco IOS dynamically removes the real server from the list of active servers. A server in this state is considered out of service.

• Automatic server unfail detection? When a server is removed from the active server list because of a failure detection, no new connections are assigned to it for the length of the predefined retry timer. When this timer expires, SLB puts the real server back on the active server list. If the first new connection to the real server fails, the server again is removed from the active server list.

• TCP session reassignment? SLB keeps tabs on every TCP SYN that a client sends when opening up a connection to a real server. If the real server doesn't respond or responds with an RST, the Cisco IOS keeps tabs on the number of times that this occurs. When a predefined threshold is reached, the Cisco IOS assigns the connection request to another server in the server group.

• SYNGuard? SLB limits the number of TCP SYNs sent to a virtual server, preventing a DoS SYN flood attack. With this feature, SLB monitors the number of SYNs sent to the virtual server IP address over a defined interval, preventing the number of new connections to a predefined threshold. Any connections above this threshold are dropped.

• Delay removal of TCP connections? Because some packets from a TCP session might arrive out of order, when a connection is terminated, SLB maintains the connection information for a short time, ensuring that all packets for the connection have a chance to reach the client or the real server. You can manipulate this delay timer.

• Dynamic Feedback Protocol (DFP)? DFP is an SLB protocol that allows the real servers to share status information with the device that is handling the load balancing (the SLB router). DFP is beyond the scope of this book.

• Stateless backup? SLB, working with HSRP, allows for a stateless (not stateful) redundancy solution.

SLB Advantages and Limitations

One of the nice features of SLB is that it provides a scalable solution that is easy to maintain. For example, you can add or remove real servers from the group without affecting the function of the virtual server. Plus, when a new real server is added to the server group, the slow start feature ensures that the new server is not overloaded quickly by a flood of new connection requests. Because clients know only about the virtual servers, maintenance is easy: Changes in your configuration are centralized. Plus, clients know only about the virtual address, not the real address of the server, providing extra protection for your server groups. With the SYNGuard feature, SLB can provide a basic level of DoS protection as well.

SLB does have some limitations, however, including the following:

• FTP is supported only in dispatched mode.

• Load balancing is supported only between subnets, not between devices on the same subnet.

• For routers using dispatched mode, the real servers must be connected through Layer 2 to the SLB router.

• For routers, with both directed and dispatched modes, packet switching is not hardware accelerated. The Catalyst 6500 supports hardware acceleration for dispatched mode.

• SLB is supported only on the 2690 series of routers and higher, limiting its usefulness in smaller environments.

SLB Configuration

SLB has a handful of required commands that you must configure to enable it, along with many other optional commands that you can configure. This section breaks down the required and optional configuration tasks.

Required SLB Commands

The first thing that you need to do is specify which real servers will be placed in which server group:

Router(config)# ip slb serverfarm server_farm_name

Router(config-slb-sfarm)# real IP_address

Router(config-slb-real)# inservice

The ip slb serverfarm command creates a grouping of your real servers. The name of the server farm can be up to 15 characters in length. The real command specifies the IP address of a real server in the server group. This takes you into a subconfiguration mode, in which the inservice command enables the server in the group: Preface the command with the no parameter to take it out of service. For more servers, repeat this process with the real and inservice commands.

After you have created your real server group(s), you need to associate the server farm with a virtual server:

Router(config)# ip slb vserver virtual_server_name

Router(config-slb-vserver)# serverfarm server_farm_name

Router(config-slb-vserver)# virtual IP_address {tcp | udp} port_# 

  [service service_name]

Router(config-slb-vserver)# inservice

The ip slb vserver command is used to create the information necessary for your virtual server. You must create a name for the virtual server, which can be up to 15 characters in length. The serverfarm command specifies which server farm group is to be used to service traffic sent to the virtual IP address. The virtual IP address for the virtual server is configured with the virtual command. You also must specify the protocol used (TCP or UDP), as well as the port number or name of the application that the virtual server handles. Table 12-3 lists valid port names and numbers. The optional service parameter specifies that all related connections for a client should be handled by the same real server. Currently, the only choice that you can specify is ftp. When you have everything configured, use the inservice command to activate the virtual server.

Table 12-3. Virtual Server Ports

Virtual Port Name	Virtual Port Number	Description
dns	53	Domain Name System
ftp	21	File Transfer Protocol
https	443	HTTP over SSL
matip-a	350	Mapping of Airline Traffic over IP
nntp	119	Network News Transport Protocol
pop2	109	Post Office Protocol v2
pop3	110	Post Office Protocol v3
smtp	25	Simple Mail Transport Protocol
telnet	23	Telnet
www	80	World Wide Web
	0	All ports

Optional SLB Commands

You can use many optional commands to tune SLB. The section covers many of these commands.

Load-Balancing Algorithm

The default load-balancing algorithm for SLB is WRR. This can be changed with the following configuration:

Router(config)# ip slb serverfarm server_farm_name

Router(config-slb-sfarm)# predictor {roundrobin | leastconns}

The roundrobin command specifies WRR, and the leastconns parameter specifies WLC. This command affects all real servers in this server farm group.

Real Server Attributes

These commands affect how SLB interacts with a specified real server in the server farm group:

Router(config)# ip slb serverfarm server_farm_name

Router(config-slb-sfarm)# real IP_address

Router(config-slb-real)# faildetect numconns #_of_connections

  [numclients #_of_clients]

Router(config-slb-real)# maxconns maximum_#_of_connections

Router(config-slb-real)# reassign #_of_SYN_requests

Router(config-slb-real)# retry #_of_seconds

Router(config-slb-real)# weight weighting_value

These commands affect only the specified real server in the server farm group.

The faildetect numconns command specifies the number of consecutive failed connection attempts by a client that cause SLB to take a real server out of service. The default number is 8, but this can range from 1 to 255. Optionally, you can specify the number of unique clients that must have connection failures, along with the total number of failures. The default number of clients is 2, but this can range from 1 to 8.

The maxconns command restricts the maximum number of active connections allowed to the real server. This can range from 1 to 4,294,967,295, with 4,294,967,295 as the default.

The reassign command specifies the number of consecutive ignored SYNs from a client to a real server that causes SLB to reassign the client's connection to a different real server. SLB waits for 30 seconds for the connection to be established; after this period, SLB removes the connection from its table. The threshold that can be assigned ranges from 1 to 4 SYN requests, with 3 being the default.

The retry command specifies the number of seconds that the Cisco IOS should wait after detecting a failed server before a new connection attempt is allowed. This value can range from 0 to 3600 seconds, with 60 seconds as the default. If you specify 0, no new connection attempt is made when a server is considered out of service.

The weight command assigns a weight to the real server, which the load-balancing algorithm then uses. This can range from 1 to 155, with 8 as the default weight.

Virtual Server Attributes

These commands affect how SLB interacts with a specified virtual server that is serviced by a server farm group:

Router(config)# ip slb vserver virtual_server_name

Router(config-slb-vserver)# client IP_address subnet_mask

Router(config-slb-vserver)# delay #_of_seconds

Router(config-slb-vserver)# idle #_of_seconds

Router(config-slb-vserver)# sticky #_of_seconds [group group_ID]

Router(config-slb-vserver)# synguard #_of_SYNs #_of_milliseconds

Router(config-slb-vserver)# no advertise

The client command restricts the clients that use the virtual server. By default, all clients (0.0.0.0 0.0.0.0) are allowed to use the virtual server.

The delay command specifies the number of seconds that SLB maintains the client's TCP connection in its table after the connection has terminated. This defaults to 10 seconds but can range from 1 to 600.

The idle command specifies the number of seconds that SLB keeps an idle connection in its table. The default is 3600 seconds, but this can range from 10 to 65,535.

The sticky command specifies the length of time, in seconds, that all the connections from the same client are forwarded to the same real server. By default, this option is disabled. Valid time ranges are 0 to 65,535. The optional group parameter associates a virtual server with a group number, which is used to group these connections. The group number ranges from 0 to 255. If more than one virtual server is placed in the same group, services from the same client IP address are handled by the same real server.

The synguard command controls the number of TCP SYNs for new connections, to prevent a TCP SYN flood DoS attack. The number of half-open connections can range from 0 to 4,294,967,295. The default is 0, which disables this feature. When it is enabled, the default interval of 100 milliseconds is used to monitor SYN flooding. This can range from 50 to 5000 milliseconds.

The advertise command is used to advertise a route to the virtual server address. By default, the Cisco IOS creates a static route for the virtual server address, pointing to interface null0. This ensures that the Cisco IOS will handle the specified virtual server traffic instead of dropping it. To disable this function, use the no advertise command.

NAT Configuration

By default, the Cisco IOS uses dispatched mode for servicing the virtual server address. To use directed mode, use the following configuration for the server farm grouping:

Router(config)# ip slb serverfarm server_farm_name

Router(config-slb-sfarm)# nat server

The nat server command enables directed mode for the processing of packets, which causes the Cisco IOS to translate the virtual IP address to the real IP address in the redirection.

SLB Verification

You can use many show and debug commands to verify and troubleshoot SLB. Table 12-4 lists the show commands for SLB.

Table 12-4. SLB show Commands

Command	Description
show ip slb conns [vservers virtserver_name] [client ip_address] [detail]	Displays all the connections handled by SLB. You can qualify the output with the addition of these parameters.
show ip slb dfp [agent IP_address port_#] [detail] [weights]	Displays information about DFP and the real servers using DFP.
show ip slb reals [vservers virtserver_name] [detail]	Displays information about the real servers defined in SLB.
show ip slb serverfarms [name serverfarm_name] [detail]	Displays information about the server farms defined in SLB.
show ip slb stats	Displays statistics about SLB.
show ip slb sticky [client IP_address]	Displays information about clients' sticky connections.
show ip slb vservers [name virtserver_name] [detail]	Displays information about SLB's virtual servers.

For more detailed troubleshooting, you can use the following debug command:

Router# debug ip slb {conns | dfp | icmp | reals | all} 

Table 12-5 displays the options for this command.

Table 12-5. SLB debug Commands

Parameter	Description
conns	Displays messages for connections handled by SLB
dfp	Displays messages about DFP messages
icmp	Displays all ICMP messages used by SLB
reals	Displays all messages for real servers used by SLB
all	Displays all debug messages for SLB

SLB Example

Take a look at a simple example using SLB, using the network shown in Figure 12-11. In this network, two web servers are located off the DMZ interface (ethernet2). The second web server can handle twice as many connections as the first server, so the load-balancing algorithm needs to be adjusted. Assume that the web servers have both their real and virtual addresses configured on them (they're operating in dispatched mode).

Figure 12-11. SLB Example

Example 12-14 shows the configuration for this example.

Example 12-14. Configuring SLB in Dispatched Mode

Router(config)# ip slb serverfarm dmz-web-servers

Router(config-slb-sfarm)# real 10.0.0.2

Router(config-slb-real)# weight 8

Router(config-slb-real)# inservice

Router(config-slb-real)# exit 

Router(config-slb-sfarm)# real 10.0.0.3

Router(config-slb-real)# weight 16

Router(config-slb-real)# inservice

Router(config-slb-real)# exit 

Router(config)# ip slb vserver internet-web-server

Router(config-slb-vserver)# serverfarm dmz-web-servers

Router(config-slb-vserver)# virtual 192.1.1.1 tcp 80

Router(config-slb-vserver)# inservice

As you can see, this example is straightforward. The ip slb serverfarm command specifies the real web servers being used: 10.0.0.2 and 10.0.0.3. If you were using directed mode instead of dispatched mode, you would include the nat service command here. Notice that, in this example, 10.0.0.3 has twice the weight of 10.0.0.2, indicating that it can handle twice the number of connections. The ip slb vserver command creates the virtual server (192.1.1.1) for web traffic.

Copyright eTutorials.org 2008-2023. All rights reserved.