ServerIron ADX Server Load Balancing Guide
Release 12.0.00
June 15, 2009

Table of Contents Previous Next Print


Server Load Balancing > SLB Configuration Examples

SLB Configuration Examples
For High Availability and DSR configuration examples, see “High Availability”.
Web Hosting with One Virtual Server Mapped to Multiple Real Servers
Suppose a company establishes a Web site with a URL of www.alterego.com. The company system administrator configures the networks so that the SLB switch forwards Web requests among four independent servers, as shown in Figure 2.27.
Figure 2.27
 
207.95.55.21 (Web1)
207.95.55.22 (Web2)
207.95.55.23 (Web3)
207.95.55.24 (Web4)
80
80
80
80
Web Hosting with Multiple Virtual Servers Mapped to One Real Server
Suppose an ISP administrator wants to use one real server to accommodate three premium users, all of which are Web sites. Each of these premium users is assigned its own Web site URL:
As shown in Figure 2.28, the SLB switch forwards requests received for each of the three Web sites to the real server(s) assigned to handle the traffic.
Figure 2.28
Many-To-One TCP/UDP Port Binding
Most SLB configurations for Web hosting map one virtual IP address to multiple real servers. However, suppose an ISP wants to host one or multiple domain names on the same real server, using the same TCP/UDP port and use a different VIP for each site. Using a separate VIP for each Web site eases administration and accounting by allowing the ISP to display statistics on the ServerIron ADX for each VIP address. In addition, you can create the appearance that you have many Web servers even if you have only a few.
When you bind a port on a real server with a port on a virtual server together, the ServerIron ADX makes an entry in its internal Layer 4 binding table. The port on the real server cannot be bound again to another virtual server if the Layer 4 binding table already has a binding for that port. Thus, to map multiple VIPs to the same real server, normally you need to map each VIP to a different TCP/UDP port on the real server.
If you want to bind multiple VIPs to the same TCP/UDP port on the same real server for accounting reasons, you can do so by creating an alias for the port. When you create an alias, you configure the VIP to bind to a different port number on the real server, then disable port translation for that binding. The ServerIron ADX thus collects and presents information for the alias port number, but traffic from all the VIPs goes to the same TCP/UDP port number on the real server.
To map multiple virtual IP addresses to the same real server, disable HTTP port translation for all but one of the virtual IP addresses, then bind the virtual IP addresses to an alias HTTP port. Disabling HTTP port translation enables the virtual IP addresses to use the same actual HTTP port number on the real server while the ServerIron ADX collects and displays separate statistics for the alias HTTP port number associated with each virtual IP address.
Figure 2.29 shows an example of this type of configuration.
Figure 2.29
 
S1: 10.0.1.5
S2: 10.0.2.200
S1: 10.0.1.5
S2: 10.0.2.200
Configuration Rules
Use the following rules when configuring the ServerIron ADX to bind more than one virtual server to the same real server using the same application port:
You must configure both the real port and the alias port on the real server(s). For example, if you need to create alias port 180 so that you can bind two virtual servers to the same real server and application port (80) on a real server, you must configure port 80 and port 180 on the real server. Otherwise, you will not be able to completely bind all the virtual servers to the real server. In the example below, the following real server configurations are incomplete because neither of the real servers has both the untranslated and alias ports configured:
ServerIron(config)# server real-name r1 10.0.1.5
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# exit
ServerIron(config)# server real-name r2 10.0.2.200
ServerIron(config-rs-r2)# port 180
ServerIron(config-rs-r2)# exit
ServerIron(config-vs-VIP1)# port http
ServerIron(config-vs-VIP1)# bind http r1 http r2 180
Here is a more detailed explanation:
When you configure SLB, one of the tasks you perform is to bind the TCP or UDP application ports on the virtual server to their counterparts on the real server. For example, if clients will be sending requests to port 80 (HTTP) on virtual server www.mysite.com, but your real servers expect the HTTP connections to arrive on port 8080 of real server R1, then you must bind port 80 on the virtual server to port 8080 on the real server.
One of the requirements is that a real server can be bound to only one virtual server using the same TCP or UDP application port. Thus, once you bind a real server port to a virtual server port, you cannot bind the same real server port to a different virtual server port.
Normally, the ServerIron ADX translates the IP address and application port of the virtual server requested by the client into the real server IP address and application port that you bind to the virtual server. However, when you disable port translation, the ServerIron ADX does not perform the translation for the application port. Instead, the ServerIron ADX translates the destination IP address in the client’s request to the IP address of a real server, but leaves the application port in the client’s request untranslated.
Configuration Example
To implement the configuration shown in Figure 2.29, enter commands such as the following:
ServerIron(config)# server real-name r1 10.0.1.5
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# port 180
ServerIron(config-rs-r1)# exit
ServerIron(config)# server real-name r2 10.0.2.200
ServerIron(config-rs-r2)# port http
ServerIron(config-rs-r2)# port 180
ServerIron(config-rs-r2)# exit
ServerIron(config)# server virtual-name-or-ip VIP1 209.157.22.88
ServerIron(config-vs-VIP1)# port http
ServerIron(config-vs-VIP1)# bind http r1 http r2 http
ServerIron(config-vs-VIP1)# exit
ServerIron(config)# server virtual-name-or-ip VIP2 209.157.22.99
ServerIron(config-vs-VIP2)# port http
ServerIron(config-vs-VIP2)# no port http translate
ServerIron(config-vs-VIP2)# bind http r1 180 r2 180
The well-known port (80) is used for VIP1, but an alias (180) is used for VIP2. The real servers actually use port 80 for traffic to both virtual IP addresses. However, the alias port enables the ISP to distinguish among the two IP addresses and their traffic when they display SLB information on the ServerIron ADX. The no port http translate command is required. This command enables the ServerIron ADX to send traffic from multiple VIPs to the same real TCP/UDP port on the real server (in this example, “http” (port 80)). If you leave this command out, the ServerIron ADX does not use port 180 as an alias but instead sends the VIP traffic to TCP/UDP port 180 on the real server rather than 80.
NOTE: Since the untranslated port is logically bound to the translated port and both ports are bound to the same port on the real server, state information for the untranslated port is based on the translated port’s state. In this example, state information for port 180 is based on the state for port 80. The state is shown in the Ms (Master port state) field of the display produced by the show server real command. See “Displaying Real Server Configuration Statistics”.
NOTE: You can configure the ServerIron ADX to perform health checks on each VIP independently. See “Health Check of Multiple Web Sites on the Same Real Server”.
To display statistics for the separate real IP addresses, enter the following command at any command prompt:
The lines highlighted in bold indicate the separate HTTP port numbers. The two HTTP lines for real server 1 (r1) indicate that an alias is in use. The first line lists the alias port number and the second line lists the actual port number used by the real server. Even though the same port number is used on the real server, the ServerIron ADX display distinguishes the traffic for the two virtual IP addresses.
NOTE: The state of the alias HTTP port is always the same as the state of the actual HTTP port used in the packets the ServerIron ADX sends to the real server. The state is shown in the Ms (Master port state) column in the show server real display. See“Displaying Real Server Configuration Statistics”.
Web Hosting with Unlimited Virtual IP Addresses
Many ISPs provide subscribers space on their Web servers for home pages. Some ISPs provide the user spaces by creating subdirectories off the main domain name of the ISP. For example, an ISP with the domain name "www.budget-Web.com" might create directories such as the following for individual subscribers:
Each subscriber’s account is on the same IP address. A Web user who accesses the server by entering the IP address gains access to the ISP’s main page, but then must navigate to the individual subscriber’s directory. For home subscribers, this method of Web hosting is perfectly satisfactory. However, business subscribers sometimes prefer to have unique domain names.
ISPs that provide separate IP addresses and domain names to their subscribers often do so by configuring multiple IP addresses on their real servers. The real servers have Network Interface Cards (NICs) that support multiple IP addresses. To provide load balancing and redundancy, ISPs sometimes configure multiple real servers with the same contents, but of course with different IP addresses. The ISP configures a unique virtual IP address (VIP) for each subscriber and uses the ServerIron ADX to map the VIP to real IP addresses on each real server for the subscriber’s Web site.
In this type of application, individually configuring a VIP for each subscriber can require a lot of typing. However, the ServerIron ADX makes configuring multiple VIPs easy by allowing you to configure a range of VIPs. When you configure a range, you create a VIP with the lowest address in the range, then specify how many consecutive addresses are in the range. When the ServerIron ADX translates a VIP address configured as part of a host range into its corresponding real IP address on a real server, the ServerIron ADX uses the VIP’s offset from the base address to determine the correct real address.
For example, suppose an ISP has two real servers with the following IP address ranges:
10.0.1.6 – 10.0.1.25
10.0.2.101 – 10.0.2.120
Instead of configuring 20 individual VIPs for these addresses, the ISP administrator can configure one VIP and a host range. In this example, the administrator configures the VIP 209.157.22.6 and adds a host range of 20 addresses to the VIP.
Figure 2.30
 
S1: 10.0.1.6
S2: 10.0.2.101
S1: 10.0.1.7
S2: 10.0.2.102
S1: 10.0.1.8
S2: 10.0.2.103
S1: 10.0.1.25
S2: 10.0.2.120
In the example in Figure 2.30, when the ServerIron ADX receives a request for VIP 209.157.22.6, the ServerIron ADX uses the predictor (balancing method) you configured to select one of the real servers, then selects the appropriate IP address on the server. In this case, since 209.157.22.6 is the first address in the VIP range, the ServerIron ADX sends the request to 10.0.1.6 on real server 1 or 10.0.2.101 on real server 2.
NOTE: To use this feature, make sure the real server has an unbroken range of consecutive IP addresses. Otherwise, you can define separate VIPs and host ranges for each range of unbroken addresses, or you can define a host-range map (see “Configuring Host-Range Maps”). Also, when you configure a real server, specify the first address in the host range on that server as that server’s IP address.
Suppose the ServerIron ADX receives a request for 209.157.22.8. The ServerIron ADX selects a real server, then applies the offset from the base VIP address to determine the corresponding real server address. In this example, 209.157.22.8 is two addresses higher than the base VIP address. Therefore, when the ServerIron ADX sends the request to a real server, the ServerIron ADX sends the request to a real IP address that is two addresses higher than the base address on the real server. The ServerIron ADX knows to apply the offset because the administrator specified a host range when configuring the virtual server and real servers. The IP address you specify when you configure the real server is the first address in the range.
NOTE: When health checks are enabled for the ports on the VIPs in a host range, the ServerIron ADX checks the health of the applications on the base IP address only. The ServerIron ADX assumes that the health of an application is the same for all the VIPs within the host range.
To configure the ServerIron ADX or switch for this application, enter the following commands:
ServerIron(config)# server real-name r1 10.0.0.1
ServerIron(config-rs-r1)# host-range 20
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# exit
These commands configure information for the first real server. The host-range command specifies the range of IP addresses the virtual server will represent for the real server. (You do not need to specify the beginning and ending points in the range, just the number of hosts in the range. The IP address you specify for the real server is automatically the first IP address in the range.)
NOTE: You can specify up to the number of hosts that are available in the sub-net starting with the offset address. For example, if you are configuring a host range on a Class C sub-net and the starting address is 1, then the host range can be up to 255. If the starting address is 100, you can specify up to 155.
The port http command enables the HTTP port.
To configure information for the second real server, enter the following commands:
ServerIron(config)# server real-name r2 10.0.2.101
ServerIron(config-rs-r2)# port http
ServerIron(config-rs-r2)# host-range 20
ServerIron(config-rs-r2)# exit
After you enter information for the real servers, you are ready to create the virtual server.
To create the virtual server, enter the following commands:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.6
ServerIron(config-vs-v1)# host-range 20
ServerIron(config-vs-v1)# port http
ServerIron(config-vs-v1)# bind http r1 http r2 http
ServerIron(config-vs-v1)# exit
The bind commands associate the http port on each real server with the http port on the virtual server.
NOTE: You also can enter the port number. If you enter the port name, the software uses the well-known number for the port (in this case 80).
SLB Intranet Configuration with HTTP, TELNET Hosting across Multiple Virtual Servers and Multiple Real Servers
A company establishes an Intranet that will handle three different URLs: www.support.com, www.marketing.com, and www.sales.com, as well as Telnet traffic. Telnet traffic is allocated among all four servers, and a server is dedicated to handle each URL with two servers allocated to handle www.support.com requests.
Figure 2.31
 
TCP/UDP Application Groups
Normally, when the ServerIron ADX selects a real server for a client’s request for a TCP/UDP port, there is no guarantee that the ServerIron ADX will select the same real server for subsequent requests from the same client. In many situations, this does not present a problem. Even when the client is requesting the same Web page or application, if the content or service is replicated on all the real servers, the client does not know or care which real server provides the content or service for each request.
However, some applications may require that the client continue to use the same real server. For example, an interactive Web site might require successive client requests to come to the same server. Other applications might require that additional TCP/UDP applications also be on the same real server. Some applications may even require the ability to open concurrent connections on the client with different TCP/UDP ports dynamically assigned by the real server.
In all of these cases, the predictor (load-balancing metric) does not ensure that the client returns to the same real server. To accommodate these types of applications, you can configure ports on a virtual server to have the following attributes:
Sticky connections – When you add a TCP/UDP port to a virtual server, if you specify that the port is “sticky”, a client request for that port always goes to the same real server unless the sticky age timer has expired. The sticky age timer ages out inactive sticky server connections. Possible values are from 2 – 60 minutes. The default is 5 minutes. See “Setting the Sticky Age” for information.
TCP/UDP application groups (using the track port function) – A “primary” TCP/UDP port is grouped with up to four additional TCP/UDP ports. After the ServerIron ADX sends a client request for the primary port to a real server, subsequent requests from the client for ports grouped with the primary port go to the same real server.
TCP/UDP application groups (using the track group function) – Up to eight TCP/UDP ports are grouped together. After the ServerIron ADX sends a client request for any of the grouped ports to a real server, subsequent requests from the client for ports in the group go to the same real server.
NOTE: You must configure all the ports in a TCP/UDP application group to be “sticky”.
Concurrent connections – The real server can open additional ("concurrent") TCP/UDP sessions with the client using arbitrary TCP/UDP port numbers.
NOTE: Although the concurrent connections attribute is similar to application groups, application groups apply to specific TCP/UDP ports that you configure on the virtual server. Concurrent connections enable the real server to arbitrarily determine the TCP/UDP ports and assign them to the client.
NOTE: For servers that use passive FTP, configure the FTP ports to be both sticky and concurrent.
Figure 2.32 shows an example of servers configured with sticky ports and an application group. In this example, the content on each real server is identical. However, some applications on the server require that clients use the same server for subsequent requests to application. The virtual server is configured to make the ports sticky and to group the TFTP and Telnet ports under the HTTP port.
Figure 2.32
To implement an application group for this example, enter the following commands:
ServerIron(config)# server real-name r1 10.0.1.5
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# port tftp
ServerIron(config-rs-r1)# port telnet
ServerIron(config-rs-r1)# exit
ServerIron(config)# server real-name r2 10.0.2.200
ServerIron(config-rs-r2)# port http
ServerIron(config-rs-r2)# port tftp
ServerIron(config-rs-r2)# port telnet
ServerIron(config-rs-r2)# exit
After you enter information for the real servers, you are ready to create the virtual server. To create the virtual server, enter the following commands:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 sticky
ServerIron(config-vs-v1)# port 69 sticky
ServerIron(config-vs-v1)# port 23 sticky
ServerIron(config-vs-v1)# track 80 69 23
ServerIron(config-vs-v1)# bind 80 r1 80 r2 80
ServerIron(config-vs-v1)# bind 23 r1 23 r2 23
ServerIron(config-vs-v1)# bind 69 r1 69 r2 69
ServerIron(config-vs-v1)# exit
The commands above illustrate the track port function. The sticky parameter makes the TCP/UDP ports sticky. The track command groups the Telnet port (23) and the TFTP port (69) under the HTTP port (80); the HTTP port is established as the “primary” port. After the ServerIron ADX sends a client to a real server for the HTTP port, subsequent requests from that client for the HTTP, TFTP, or Telnet port go to the same real server. Up to four ports can be grouped with the primary port.
NOTE: Since ports 23 and 69 track port 80, state information for the tracking ports (23 and 69 in this example) are based on the tracked port’s state (port 80 in this example). The state is shown in the Ms (Master port state) field of the display produced by the show server real command. See “Displaying Real Server Configuration Statistics”.
The track group function works similarly to the track port function. With the track port function, the client uses the same server for applications associated with the grouped ports, as long as the primary port is active. In contrast, with the track group function, the client uses the same server for applications associated with the grouped ports, as long as all the ports in the group are active. After the ServerIron ADX sends a client to a real server for any of the grouped ports, subsequent requests from that client for any of the grouped ports go to the same real server.
The following commands illustrate the track group function:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 sticky
ServerIron(config-vs-v1)# port 69 sticky
ServerIron(config-vs-v1)# port 23 sticky
ServerIron(config-vs-v1)# track-group 80 69 23
ServerIron(config-vs-v1)# bind 80 r1 80 r2 80
ServerIron(config-vs-v1)# bind 23 r1 23 r2 23
ServerIron(config-vs-v1)# bind 69 r1 69 r2 69
ServerIron(config-vs-v1)# exit
In this example, the track-group command groups the HTTP port (80), Telnet port (23), and TFTP port (69) together. Whenever a client attempts to connect to a port within the group, the ServerIron ADX ensures all ports in the group are active before granting the connection.
The sticky parameter makes the TCP/UDP ports sticky. The sticky parameter must be set for all ports in the group.
After the ServerIron ADX sends a client to a real server for any of these three ports, subsequent requests from that client for the HTTP, TFTP, or Telnet port go to the same real server. Up to eight ports can be grouped together using the track group function. A port can be part of only one group. The track-group and track commands for a port are mutually exclusive.
Web Hosting with ServerIron ADX and Real Servers in Different Subnets
The ServerIron ADX allows you to easily deploy its services in a multinetted environment, without the overhead of configuring routing protocols.
Normally, the ServerIron ADX requires only one IP address, which you use for management access to the device. However, when the ServerIron ADX and real servers are on different sub-nets, you need one of the following:
Figure 2.33 shows an example of a multinetted environment, in which the ServerIron ADX is on one sub-net but the real servers are on another sub-net. The ServerIron ADX is on sub-net 141.149.65.x and the real servers are on sub-net 10.10.10.x.
Figure 2.33
ServerIron ADX and real servers in multinetted environment – Router configured to route between sub-nets
In this example, the ServerIron ADX and the real servers are on different sub-nets, but can communicate because the router is configured with interfaces in both sub-nets. Traffic from the ServerIron ADX to the real servers goes to the router, which routes the traffic to the real servers’ sub-net. (The traffic passes back through the ServerIron ADX to reach the real servers, but still must be routed by the router.)
Traffic from the real servers to the ServerIron ADX passes through the ServerIron ADX to the router. The ServerIron ADX acts like a Layer 2 bridge in this case and thus passes the traffic to the router. The router then routes the traffic to the ServerIron ADX’s sub-net.
If you have network topology similar to the example in Figure 2.33, but you do not want to configure the router with multiple sub-nets, you can instead enable source NAT and configure a source IP address on the ServerIron ADX. The source IP address allows the ServerIron ADX to be in multiple sub-nets, in addition to the sub-net of the ServerIron ADX’s management IP address. Source NAT enables the ServerIron ADX to perform IP address translation on the source address in packets addressed to the real servers. When source NAT is enabled, the ServerIron ADX changes the source address in the IP packets addressed to the real server to the source IP address configured on the ServerIron ADX. Figure 2.34 shows an example of the topology shown in Figure 2.33, but in this case the ServerIron ADX is configured for multiple sub-nets instead of the router.
Figure 2.34
ServerIron ADX and real servers in multinetted environment – ServerIron ADX configured for source NAT
In this example, the ServerIron ADX is configured with source IP addresses in the real server’s sub-net and source NAT is enabled. The configuration requires five CLI commands. No reconfiguration of the router is required.
The ServerIron ADX supports a maximum of 64,000 simultaneous connections on each source IP address. This maximum value is based on the architectural limits of IP itself. As a result, if you add only one source IP address, the ServerIron ADX can support up to a maximum of 64,000 simultaneous connections to the real servers. You can configure up to eight source IP addresses, for even more simultaneous connections to the real servers.
To implement the configuration shown in Figure , enter commands such as the following:
ServerIron(config)# server source-ip 10.10.10.5 255.255.255.0 0.0.0.0
ServerIron(config)# server source-ip 10.10.10.6 255.255.255.0 0.0.0.0
ServerIron(config)# server source-ip 10.10.10.7 255.255.255.0 0.0.0.0
ServerIron(config)# server source-ip 10.10.10.8 255.255.255.0 0.0.0.0
ServerIron(config)# server source-nat
ServerIron(config)# server real-name R1 10.10.10.2
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# exit
ServerIron(config)# server real-name R2 10.10.10.3
ServerIron(config-rs-r2)# port http
ServerIron(config-rs-r2)# exit
ServerIron(config)# server virtual-name-or-ip VIP 209.157.22.88
ServerIron(config-vs-VIP1)# port http
ServerIron(config-vs-VIP1)# bind http R1 http R2 http
ServerIron(config-vs-VIP1)# exit
NOTE: If a real server is not reachable from the ServerIron ADX at Layer 2 (does not respond to ARP requests), and if the router connecting the ServerIron ADX to the real server is not running proxy ARP, use the following command instead:

server remote-name <name> <ip-addr>

This command adds the server as a remote server. See “Web Hosting with Geographically-Distributed Servers” for information.

Alternatively, enable proxy ARP on the router connecting the ServerIron ADX to the real server.
Web Hosting with Geographically-Distributed Servers
The ServerIron ADX allows you to configure a virtual server to fail over to remote real server IP addresses or VIPs if all local servers become unavailable. The remote servers can be real servers, virtual servers, or a combination of real servers and virtual servers. The remote servers can be locally connected to the ServerIron ADX, connected across a router or even across the Internet.
When you configure remote servers in addition to local servers, the ServerIron ADX does not include the remote servers in the predictor (load balancing method). Thus, the remote servers are not used unless all local servers are unavailable.
NOTE: If you want remote servers to be included in the predictor (load balancing method), configure all the real servers, including the local ones, as remote real servers.
Figure 2.35 shows an ISP that wants to use load sharing between two local real servers but use remote servers as failovers if both the local real servers are unavailable. The local servers are load balanced by the ServerIron ADX with IP management address 141.149.65.10. The remote servers are load balanced by the ServerIron ADX with IP management address 150.60.60.6. In this example, a VIP on the ServerIron ADX 2 (150.60.60.26) is configured on the ServerIron ADX 1 (141.149.65.10) as a remote server. The remote server can also be a real server’s IP address.
Figure 2.35
When you configure a ServerIron ADX to fail over to a remote server or to a VIP on another ServerIron ADX, the remote server or VIP typically is on a different sub-net. In this case, the ServerIron ADX must perform some additional address translation to ensure that the traffic from the remote server to the client passes back through the ServerIron ADX that originally serviced the request.
When the ServerIron ADX sends a client request to a local server, it does not change the source IP address of the client’s request. However, the ServerIron ADX does change the destination IP address from the VIP requested by the client to the IP address of a real server. When the real server replies to the request, the server’s reply is addressed to the client. The ServerIron ADX changes the source IP address of the server’s reply to the VIP, then forwards the reply to the client. When the client receives the reply, the reply appears to have come from the VIP.
For the configuration shown in Figure 2.35, you need to enable source NAT. When the ServerIron ADX sends a client request to a real server, the ServerIron ADX does not do source NAT by default. The ServerIron ADX simply performs a destination NAT, changing the VIP address to a real server address. When the real server replies, the ServerIron ADX reverses the destination NAT so that the client sees a reply from the VIP. Real server responses must flow through the ServerIron ADX that performed the original destination NAT so that the NAT can be reversed. Otherwise, the client sees a response from the wrong IP address and either resets the TCP connection or ignores the response.
If you use remote servers in a remote sub-net, you must enable source NAT to force traffic to return to the ServerIron ADX that performed the original destination NAT. The source IP addresses used for source NAT must be in the original ServerIron ADX’s broadcast domain. The remote real server replies are addressed to the original ServerIron ADX, not to the client’s address. The original ServerIron ADX can then properly reverse the destination NAT.
In Figure 2.35, client requests initially are addressed to VIP1 on ServerIron ADX 1, 141.149.65.2. If the local real servers are healthy, ServerIron ADX 1 distributes traffic to them using destination NAT in the normal way. However, if all the local real servers become unavailable, ServerIron ADX 1 sends traffic to VIP2 on ServerIron ADX 2. ServerIron ADX 1 sends the traffic by using destination NAT in the usual way, translating VIP1’s address into VIP2’s address. The client's packet is forwarded to the ServerIron ADX's default gateway. By default, if source NAT is not enabled, this is all that happens.
If source NAT is disabled, ServerIron ADX 2 performs a second destination NAT, replacing VIP2’s address with R3 or R4’s address, depending on which real server is next in the rotation. For this example, assume that ServerIron ADX 2 sends the client request to R3. When R3 replies, the destination address is the client’s address and R3’s address is replaced by VIP2’s address. R3’s default gateway forwards this packet directly to the client. ServerIron ADX 1 never sees the packet and never has a chance to reverse the original destination NAT. The client sees a response from 150.60.60.26, rather than 141.149.65.2. The client therefore either resets the TCP connection or simply ignores the response.
To avoid this problem, enable source NAT on ServerIron ADX 1 for VIP2, the remote server. In the example in Figure 2.35, ServerIron ADX 1 has four addresses to use with source NAT:
When ServerIron ADX 1 sends a packet to VIP2, ServerIron ADX 1 also performs a source NAT using one of these four addresses. The remote servers reply to an address on ServerIron ADX 1 rather than to the client’s address. Traffic returns to ServerIron ADX 1 where the original destination NAT is reversed. The client sees a response from VIP1, the same address to which the client sent its request.
All of this is transparent to the client, who simply sends a request to a published IP address and receives a response from that address.
NOTE: You can enable source NAT globally or an a real server basis (local or remote). If you enable source NAT globally, the ServerIron ADX translates the source address of all client requests. If you enable source NAT locally, on individual real servers, the ServerIron ADX translates the source IP address only for client requests directed to those servers. For example, if you enable source NAT only on the remote servers, the ServerIron ADX translates the source IP addresses only in client requests that the ServerIron ADX directs to the remote servers.
Here are the commands for implementing the configuration shown in Figure 2.35. This configuration and all the other configuration information shown here is from the perspective of ServerIron ADX 1. You of course also can configure the remote ServerIron ADX to use a VIP on the local ServerIron ADX as a remote failover.
ServerIron-1(config)# server real-name R1 10.10.10.2
ServerIron-1(config-rs-R1)# port http
ServerIron-1(config-rs-R1)# exit
ServerIron-1(config)# server real-name R2 10.10.10.3
ServerIron-1(config-rs-R2)# port http
ServerIron-1(config-rs-R2)# exit
The commands shown above configure the local servers. The following commands configure the remote server and enable source NAT for the server. In this example, the remote server is VIP2 configured on ServerIron ADX 2. It is also valid to configure real servers R3 and R4 as the remote servers instead. However, by configuring VIP2 as the remote server, you simplify configuration and also take advantage of the SLB services of ServerIron ADX 2. This example assumes that real servers R3 and R4 and VIP2 are configured on ServerIron ADX 2.
ServerIron-1(config)# server remote-name VIP2 150.60.60.26
ServerIron-1(config-rs-VIP2)# source-nat
ServerIron-1(config-rs-VIP2)# port http
ServerIron-1(config-rs-VIP2)# exit
The following commands configure VIP1 on ServerIron ADX 1:
ServerIron-1(config)# server virtual-name-or-ip VIP1 141.149.65.2
ServerIron-1(config-vs-VIP1)# port http
ServerIron-1(config-vs-VIP1)# bind http R1 http R2 http VIP2 http
ServerIron-1(config-vs-VIP1)# exit
The following source-ip commands configure source IP addresses to allow the ServerIron ADX to send a client request to a remote server, receive the response, and then send the response to the client. Notice that the source IP addresses added to the ServerIron ADX are not in the sub-net of the remote ServerIron ADX. They are in the sub-net that connects the ServerIron ADX’s local router to the Internet. The purpose of the source IP addresses in this configuration is to ensure that the responses from remote servers come back to the ServerIron ADX instead of going directly to the clients, so that the ServerIron ADX can properly change the source addresses of the responses back to the VIP requested by the clients.
ServerIron-1(config)# server source-ip 141.149.65.4 255.255.255.0 0.0.0.0
ServerIron-1(config)# server source-ip 141.149.65.5 255.255.255.0 0.0.0.0
ServerIron-1(config)# server source-ip 141.149.65.6 255.255.255.0 0.0.0.0
ServerIron-1(config)# server source-ip 141.149.65.7 255.255.255.0 0.0.0.0
You can implement this type of configuration using just one source IP address. However, an architectural limitation in IP allows a maximum of 64,000 simultaneous connections on an IP address. As a result, to maximize the number of simultaneous connections the ServerIron ADX can have to the remote VIP, add the maximum number of source IP addresses (eight).
Using HTTP Redirect with Geographically-Distributed Servers
The application example in the previous section illustrates how to configure the ServerIron ADX to fail over to a remote real server if all local real servers are unavailable. In the previous example, the source NAT feature is used to cause traffic from the remote real server to flow back through the ServerIron ADX to the client.
Depending on the speed of the network connections between the ServerIron ADX and the remote server, you might want the remote server to instead communicate directly with the client. To do so, you can configure a VIP to use HTTP redirect.
Normally, a client expects a response from the VIP and thus regards a TCP SYN ACK (acknowledgment) from the real server as a connection attempt from a different server. If the real server responds directly to the client, the client refuses the real server’s TCP SYN ACK. However, you can configure a VIP to use HTTP redirect. In this case, the ServerIron ADX performs address translation as normal when using local real servers. However, if all of the local real servers are unavailable and a remote server is available, the ServerIron ADX sends an HTTP redirect message to the client. The HTTP redirect message instructs the client to redirect its HTTP connection directly to the remote server, bypassing the ServerIron ADX. The client now is talking to the remote server’s IP address instead of the VIP.
The remote server can be a real server or another virtual server.
NOTE: If the user on the client bookmarks a page on the remote server following an HTTP redirect, then uses the bookmark later, the bookmark goes directly to the remote server instead of to the VIP.
Figure 2.36 shows an example of HTTP redirect in use.
Figure 2.36
To implement HTTP redirect for the VIP shown in Figure 2.36, enter commands such as the following:
ServerIron(config)# server real-name r1 10.0.1.5
ServerIron(config-rs-r1)# port http
ServerIron(config-rs-r1)# exit
ServerIron(config)# server real-name r2 10.0.2.200
ServerIron(config-rs-r2)# port http
ServerIron(config-rs-r2)# exit
ServerIron(config)# server remote-name r3 192.157.22.244
ServerIron(config-rs-r3)# source-nat
ServerIron(config-rs-r3)# port http
ServerIron(config-rs-r3)# exit
ServerIron(config)# server virtual-name-or-ip VIP 209.157.22.88
ServerIron(config-vs-VIP1)# port http
ServerIron(config-vs-VIP1)# bind http r1 80 r2 80 r3 80
ServerIron(config-vs-VIP1)# httpredirect
ServerIron(config-vs-VIP1)# exit
The command that enables HTTP redirect is shown in bold.
Using Reverse Proxy SLB
The Reverse Proxy SLB feature enables you to send client requests for a Web page first to a cache server, then to a load balanced real server if the cache server does not have the requested content. This feature is useful for enhancing performance within a load balanced Web site for frequently requested Web pages.
NOTE: You cannot use the Reverse Proxy SLB feature with the TCS cache server spoofing feature on the same ServerIron ADX.
To configure the ServerIron ADX for Reverse Proxy SLB, you configure the real servers and a VIP, then enable Reverse Proxy SLB on the VIP. When the ServerIron ADX receives a request for the VIP, the ServerIron ADX sends the request to a cache server.
If the cache server has the requested content, the ServerIron ADX sends the content to the client.
If the cache server does not have the requested content, the ServerIron ADX redirects the request to a real server. If there is more than one real server, the ServerIron ADX uses the load balancing metric and other SLB parameters you have configured to select the real server.
The ServerIron ADX uses the TCS hash mechanism when selecting a cache server and uses the SLB load balancing method (the predictor) when selecting a real server.
Basic Example
Figure 2.37 shows an example of a simple Reverse Proxy SLB configuration. Cache servers and real servers are located close to the Web content, as opposed to being close to the client (or the client’s ISP), which is usually the case. Because the cache servers are located close to the content, this type of configuration is sometimes called “reverse caching” or “reverse proxy”. The ServerIron ADX is a proxy acting on behalf of the client, but the proxy is located with the Web content, rather than with the client’s ISP.
Figure 2.37
In this example, the ServerIron ADX is configured to send client requests for VIP 209.157.22.26 to a cache server (C1 or C2). If the cache server does not have the requested content, the ServerIron ADX does not send the request to the Internet, as it does in a standard TCS configuration. Instead, the ServerIron ADX sends the request to a load balanced real server.
The commands for implementing the configuration are as follows.
The following commands globally enable TCS and configure the cache servers:
ServerIron(config)# ip policy 1 cache tcp 80 global
ServerIron(config)# server cache-name C1 10.0.1.2
ServerIron(config)# server cache-name C2 10.0.1.3
ServerIron(config)# server cache-group 1
ServerIron(config-tc-1)# cache-name C1
ServerIron(config-tc-1)# cache-name C2
ServerIron(config-tc-1)# exit
The following commands configure the real servers: Notice that port 80 (HTTP) is added to each server.
ServerIron(config)# server real-name R1 10.0.1.4
ServerIron(config-rs-R1)# port 80
ServerIron(config-rs-R1)# exit
ServerIron(config)#server real-name R2 10.0.1.5
ServerIron(config-rs-R2)# port 80
ServerIron(config-rs-R2)# exit
ServerIron(config)# server real-name R3 10.0.1.6
ServerIron(config-rs-R3)# port 80
ServerIron(config-rs-R3)#exit
The following commands configure the VIP and save the configuration to the ServerIron ADX’s startup-config file on the flash memory:
ServerIron(config)# server virtual-name-or-ip VIP1 209.157.22.26
ServerIron(config-vs-VIP1)# port 80
ServerIron(config-vs-VIP1)# bind 80 R1 80 R2 80 R3 80
ServerIron(config-vs-VIP1)# cache-enable
ServerIron(config)#write memory
The cache-enable command enables the Reverse Proxy SLB feature. You must use this command to use Reverse Proxy SLB. Otherwise, the ServerIron ADX will use the standard TCS behavior, and send client requests to the Internet if the cache server does not have the requested content. The cache-enable command configures the ServerIron ADX to send requests that the cache servers cannot fulfill to the real servers instead of to the Internet.
E-Commerce Example
You can use Reverse Proxy SLB in an E-Commerce environment to offer information that is located on a corporate intranet to the general public without compromising network security. Figure 2.38 shows an example of a Reverse Proxy SLB configuration. Notice that this configuration uses multiple ServerIron ADXs. One of the ServerIron ADXs is configured for TCS and Reverse Proxy SLB while the other two are configured for SLB.
Figure 2.38
In this example, the cache servers are located in the demilitarized zone (DMZ). The DMZ is the part of the company's network that is outside the company firewalls but still on the private side of the company's router connection to the Internet.
When a client request comes in from the Internet addressed to VIP 192.1.1.1 on a ServerIron ADX with Reverse Proxy SLB enabled, the ServerIron ADX redirects the request to a cache server. If the cache server has the requested content, the cache server responds directly to the client (through the ServerIron ADX). If the cache server does not have the requested content, the cache server redirects the request to the ServerIron ADX.
Normally, a ServerIron ADX configured for TCS redirects a cache request to the Internet. However, since Reverse Proxy SLB is enabled, the ServerIron ADX instead sends the request to a load balanced real server. In this example, the real servers are firewalls acting as proxy servers. The TCS ServerIron ADX is configured with two real servers. Each of them is actually a firewall. Each of the firewalls is configured to perform NAT to translate packets addressed to its interface with the ServerIron ADX into the VIP configured on the SLB ServerIron ADX connected to it. Thus, if the TCS ServerIron ADX sends a client request to firewall interface 192.1.1.5 (configured on the TCS ServerIron ADX as a real server), the firewall translates the packet’s destination address into VIP 10.10.2.20.
NOTE: This example assumes that the firewalls are properly configured to perform the address translations needed for this configuration.
The ServerIron ADX to which the firewall (proxy server) sends the client request sends the request to a real server, then sends the response back to the firewall, which again performs NAT and sends the response to the cache server. The cache server then sends the requested content to the client. From the client’s perspective, the response arrives from IP address 192.1.1.1. This is true whether the content was on the cache server when the client requested it or the cache server needed to obtain the content from a real server before providing it to the client.
Configuring TCS ServerIron ADX
The following commands configure the TCS ServerIron ADX:
ServerIron(config)# ip policy 1 cache tcp 80 global
ServerIron(config)# server cache-name C1 192.1.1.2
ServerIron(config)# server cache-name C2 192.1.1.3
ServerIron(config)# server cache-group 1
ServerIron(config-tc-1)# cache-name C1
ServerIron(config-tc-1)# cache-name C2
ServerIron(config-tc-1)# exit
ServerIron(config)# server real-name Proxy1 192.1.1.5
ServerIron(config-rs-Proxy1)# port 80
ServerIron(config-rs-Proxy1)# port 443
ServerIron(config-rs-Proxy1)# exit
ServerIron(config)# server real-name Proxy2 192.1.1.4
ServerIron(config-rs-Proxy2)# port 80
ServerIron(config-rs-Proxy2)# port 443
ServerIron(config-rs-Proxy2)# exit
ServerIron(config)# server virtual-name-or-ip VIP1 192.1.1.1
ServerIron(config-vs-VIP1)# port 80
ServerIron(config-vs-VIP1)# port 443
ServerIron(config-vs-VIP1)# bind 80 Proxy1 80 Proxy2 80
ServerIron(config-vs-VIP1)# bind 443 Proxy1 443 Proxy2 443
ServerIron(config-vs-VIP1)# cache-enable
ServerIron(config-vs-VIP1)# exit
ServerIron(config)#write memory
Notice that two real servers are added to the ServerIron ADX. These real servers are actually the firewalls. The real server IP addresses are the firewall interfaces with the TCS ServerIron ADX. Also notice that the ports on the VIP are bound to the real servers, as in a standard TCS configuration.
Configuring SLB ServerIron ADX A
The following commands configure the SLB ServerIron ADX A:
ServerIron(config)# server real-name R1 10.10.2.1
ServerIron(config-rs-R1)# port 80
ServerIron(config-rs-R1)# port 443
ServerIron(config-rs-R1)# exit
ServerIron(config)# server real-name R2 10.10.2.2
ServerIron(config-rs-R2)# port 80
ServerIron(config-rs-R2)# port 443
ServerIron(config-rs-R2)# exit
ServerIron(config)# server virtual-name-or-ip VIP2 10.10.2.20
ServerIron(config-vs-VIP2)# port 80
ServerIron(config-vs-VIP2)# port 443
ServerIron(config-vs-VIP2)# bind 80 R1 80 R2 80
ServerIron(config-vs-VIP2)# bind 443 R1 443 R2 443
ServerIron(config-vs-VIP2)# exit
ServerIron(config)# write memory
Configuring SLB ServerIron ADX B
The following commands configure the SLB ServerIron ADX:
ServerIron(config)# server real-name R3 10.10.3.1
ServerIron(config-rs-R3)# port 80
ServerIron(config-rs-R3)# port 443
ServerIron(config-rs-R3)# exit
ServerIron(config)# server real-name R4 10.10.3.2
ServerIron(config-rs-R4)# port 80
ServerIron(config-rs-R4)# port 443
ServerIron(config-rs-R4)# exit
ServerIron(config)# server virtual-name-or-ip VIP3 10.10.3.21
ServerIron(config-vs-VIP2)# port 80
ServerIron(config-vs-VIP2)# port 443
ServerIron(config-vs-VIP2)# bind 80 R3 80 R4 80
ServerIron(config-vs-VIP2)# bind 443 R3 443 R4 443
ServerIron(config-vs-VIP2)# exit
ServerIron(config)# write memory
Load Balancing Streaming Media Files
The ServerIron ADX can perform load balancing for the following kinds of streaming media files:
VDOLive – TCP port 7000
StreamWorks – UDP port 1558
Microsoft Media Service – TCP port 1755
Microsoft VxTreme – TCP port 12468
Apple’s QuickTime – TCP port 554
NOTE: Some streaming media types can use ports other than their well-known port. However, the ServerIron ADX generally supports only the well-known port. For example, QuickTime can use port 7070, in addition to the more common 554. The ServerIron ADX currently supports streaming media load balancing for QuickTime only on port 554.
Figure 2.39 shows a sample configuration where requests for three kinds of streaming media files are load balanced across three real servers.
Figure 2.39
 
rs1: 10.10.10.1
rs2: 10.10.10.2
rs3: 10.10.10.3
rs1: 10.10.10.1
rs2: 10.10.10.2
rs3: 10.10.10.3
rs1: 10.10.10.1
rs2: 10.10.10.2
rs3: 10.10.10.3
In this configuration, all the streaming media content is located on the three real servers. Requests for MS-media files on VIP 192.162.1.50 are load balanced across the real servers using the weighted predictor; requests for Real Audio files on VIP 192.162.1.51 are load balanced using the least connections predictor; and requests for QuickTime files on VIP 192.162.1.52 are load balanced using the round-robin predictor.
The following commands configure the real servers in Figure 2.39:
ServerIron(config)# server real-name rs1 10.10.10.1
ServerIron(config-rs-rs1)# port rtsp
ServerIron(config-rs-rs1)# port pnm
ServerIron(config-rs-rs1)# port mms
ServerIron(config-rs-rs1)# exit
ServerIron(config)# server real-name rs2 10.10.10.2
ServerIron(config-rs-rs2)# port rtsp
ServerIron(config-rs-rs2)# port pnm
ServerIron(config-rs-rs2)# port mms
ServerIron(config-rs-rs2)# exit
ServerIron(config)# server real-name rs3 10.10.10.3
ServerIron(config-rs-rs3)# port rtsp
ServerIron(config-rs-rs3)# port pnm
ServerIron(config-rs-rs3)# port mms
ServerIron(config-rs-rs3)# exit
The following commands bind the real servers to the virtual servers in Figure 2.39:
ServerIron(config)# server virtual-name-or-ip MSmedia1755 192.162.1.50
ServerIron(config-vs-MSmedia1755)# predictor weighted
ServerIron(config-vs-MSmedia1755)# port mms
ServerIron(config-vs-MSmedia1755)# bind mms rs1 mms rs2 mms rs3 mms
ServerIron(config-vs-MSmedia1755)# exit
ServerIron(config)# server virtual-name-or-ip real7070 192.162.1.51
ServerIron(config-vs-real7070)# predictor least-conn
ServerIron(config-vs-real7070)# port pnm
ServerIron(config-vs-real7070)# bind pnm rs1 pnm rs2 pnm rs3 pnm
ServerIron(config-vs-real7070)# exit
ServerIron(config)# server virtual-name-or-ip quicktime554 192.162.1.52
ServerIron(config-vs-quicktime554)# predictor round-robin
ServerIron(config-vs-quicktime554)# port rtsp
ServerIron(config-vs-quicktime554)# bind rtsp rs1 rtsp rs2 rtsp rs3 rtsp
ServerIron(config-vs-quicktime554)# exit
NOTE: The ServerIron ADX supports configurations that use port 80 for streaming media. However, a Layer 7 health check may fail because a status code of 404 can be returned in response to GET or HEAD requests. To work around this, you must configure the health check so that 404 is an acceptable status code. To do this, use the command port http status-code 200 404 in the real server configuration.
Layer 3 SLB
The following sections illustrate Layer 3 SLB support in these configurations:
Basic SLB with One VLAN and One Virtual Routing Interface
Figure 2.40 illustrates an SLB configuration with one VLAN and one virtual routing interface.
Figure 2.40
The following commands configure a virtual routing interface on VLAN 1 (the default VLAN), then configure IP addresses on the virtual routing interface.
ServerIron(config)# vlan 1 name DEFAULT-VLAN by port
ServerIron(config-vlan-1)# router-interface ve 1
ServerIron(config-vlan-1)# exit
ServerIron(config)# interface ve 1
ServerIron(config-ve-1)# ip address 68.1.1.254 255.255.255.0
ServerIron(config-ve-1)# ip address 164.128.1.254 255.255.255.0
ServerIron(config-ve-1)# ip address 206.65.1.254 255.255.255.0
ServerIron(config-ve-1)# ip ospf area 0
ServerIron(config-ve-1)# exit
ServerIron(config)# ip l4-policy 1 cache tcp 0 global
ServerIron(config)# ip l4-policy 2 cache udp 0 global
The following list of commands configures OSPF and enables redistribution of static and connected routes into OSPF:
ServerIron(config)# router ospf
ServerIron(config-ospf-router)# area 0
ServerIron(config-ospf-router)# redistribution connected
ServerIron(config-ospf-router)# redistribution static
ServerIron(config-ospf-router)# exit
The following commands configure the real servers in Figure 2.40:
ServerIron(config)# server real rs23 68.1.1.23
ServerIron(config-rs-rs23)# port dns
ServerIron(config-rs-rs23)# port mms
ServerIron(config-rs-rs23)# port ftp
ServerIron(config-rs-rs23)# port ssl
ServerIron(config-rs-rs23)# port http
ServerIron(config-rs-rs23)# port http url "HEAD /"
ServerIron(config-rs-rs23)# exit
ServerIron(config)# server real rs24 68.1.1.24
ServerIron(config-rs-rs24)# port dns
ServerIron(config-rs-rs24)# port mms
ServerIron(config-rs-rs24)# port ftp
ServerIron(config-rs-rs24)# port ssl
ServerIron(config-rs-rs24)# port http
ServerIron(config-rs-rs24)# port http url "HEAD /"
ServerIron(config-rs-rs24)# exit
ServerIron(config)# server real rs25 68.1.1.25
ServerIron(config-rs-rs25)# port dns
ServerIron(config-rs-rs25)# port mms
ServerIron(config-rs-rs25)# port ftp
ServerIron(config-rs-rs25)# port ssl
ServerIron(config-rs-rs25)# port http
ServerIron(config-rs-rs25)# port http url "HEAD /"
ServerIron(config-rs-rs25)# exit
The following commands configure the remote servers in Figure 2.40:
ServerIron(config)# server remote-name rs26 10.2.24.26
ServerIron(config-rs-rs26)# source-nat
ServerIron(config-rs-rs26)# port dns
ServerIron(config-rs-rs26)# port ftp
ServerIron(config-rs-rs26)# port ssl
ServerIron(config-rs-rs26)# port http
ServerIron(config-rs-rs26)# port http url "HEAD /"
ServerIron(config-rs-rs26)# exit
ServerIron(config)# server remote-name rs27 10.2.24.27
ServerIron(config-rs-rs27)# source-nat
ServerIron(config-rs-rs27)# port dns
ServerIron(config-rs-rs27)# port ftp
ServerIron(config-rs-rs27)# port ssl
ServerIron(config-rs-rs27)# port http
ServerIron(config-rs-rs27)# port http url "HEAD /"
ServerIron(config-rs-rs27)# exit
The following commands configure the virtual servers in Figure 2.40:
ServerIron(config)# server virtual-name-or-ip www 206.65.1.100
ServerIron(config-vs-www)# port ssl sticky
ServerIron(config-vs-www)# port http
ServerIron(config-vs-www)# bind ssl rs25 ssl rs24 ssl rs23 ssl
ServerIron(config-vs-www)# bind ssl rs27 ssl rs26 ssl
ServerIron(config-vs-www)# bind http rs25 http rs24 http rs23 http
ServerIron(config-vs-www) #bind http rs27 http rs26 http
ServerIron(config-vs-www)# exit
ServerIron(config)# server virtual-name-or-ip ftp 206.65.1.101
ServerIron(config-vs-ftp)# port ftp
ServerIron(config-vs-ftp)# bind ftp rs25 ftp rs24 ftp rs23 ftp
ServerIron(config-vs-ftp)# bind ftp rs27 ftp rs26 ftp
ServerIron(config-vs-ftp)# exit
ServerIron(config)# server virtual-name-or-ip mms 206.65.1.102
ServerIron(config-vs-mms)# port mms
ServerIron(config-vs-mms)# bind mms rs25 mms rs24 mms rs23 mms
ServerIron(config-vs-mms)# exit
ServerIron(config)# server virtual-name-or-ip dns 206.65.1.103
ServerIron(config-vs-dns)# port dns
ServerIron(config-vs-dns)# bind dns rs25 dns rs24 dns rs23 dns
Basic SLB with Multiple Subnets and Multiple Virtual Routing Interfaces
Figure 2.41 illustrates an SLB configuration with three VLANs and three virtual routing interfaces.
Figure 2.41
The following commands configure virtual routing interfaces on VLAN 1 (the default VLAN), VLAN 2, and VLAN 4 and configure IP addresses on the virtual routing interfaces.
ServerIron(config)# vlan 1 name DEFAULT-VLAN by port
ServerIron(config-vlan-1)# router-interface ve 1
ServerIron(config-vlan-1)# exit
ServerIron(config)# interface ve 1
ServerIron(config-ve-1)# ip address 206.65.1.254 255.255.255.0
ServerIron(config-ve-1)# ip ospf area 0
ServerIron(config-ve-1)# exit
ServerIron(config)# ip l4-policy 1 cache tcp 0 global
ServerIron(config)# ip l4-policy 2 cache udp 0 global
ServerIron(config)# vlan 2 by port
ServerIron(config-vlan-2)# untagged ethe 3/7 to 3/12 ethe 4/3 to 4/4
ServerIron(config-vlan-2)# router-interface ve 2
ServerIron(config-vlan-2)# exit
ServerIron(config)# interface ve 2
ServerIron(config-ve-2)# ip address 68.1.1.254 255.255.255.0
ServerIron(config-ve-2)# ip ospf area 0
ServerIron(config-ve-2)# exit
ServerIron(config)# vlan 4 by port
ServerIron(config-vlan-4)# untagged ethe 3/13 to 3/24 ethe 4/5 to 4/8
ServerIron(config-vlan-4)# ip-subnet 164.128.1.0 255.255.255.0 name PrivateNet
ServerIron(config-vlan-4)# static ethe 3/13 to 3/24 ethe 4/5 to 4/8
ServerIron(config-vlan-4)# router-interface ve 4
ServerIron(config-vlan-4)# exit
ServerIron(config)# interface ve 4
ServerIron(config-ve-4)# ip address 164.128.1.254 255.255.255.0
ServerIron(config-ve-4)# ip ospf area 0
ServerIron(config-ve-4)# exit
The following list of commands configures OSPF and enables redistribution of static as well as connected routes into OSPF:
ServerIron(config)# router ospf
ServerIron(config-ospf-router)# area 0
ServerIron(config-ospf-router)# redistribution connected
ServerIron(config-ospf-router)# redistribution static
ServerIron(config-ospf-router)# exit
The following commands configure the real servers in Figure 2.41:
ServerIron(config)# server real rs23 68.1.1.23
ServerIron(config-rs-rs23)# port dns
ServerIron(config-rs-rs23)# port mms
ServerIron(config-rs-rs23)# port ftp
ServerIron(config-rs-rs23)# port ssl
ServerIron(config-rs-rs23)# port http
ServerIron(config-rs-rs23)# port http url "HEAD /"
ServerIron(config-rs-rs23)# exit
ServerIron(config)# server real rs24 68.1.1.24
ServerIron(config-rs-rs24)# port dns
ServerIron(config-rs-rs24)# port mms
ServerIron(config-rs-rs24)# port ftp
ServerIron(config-rs-rs24)# port ssl
ServerIron(config-rs-rs24)# port http
ServerIron(config-rs-rs24)# port http url "HEAD /"
ServerIron(config-rs-rs24)# exit
ServerIron(config)# server real rs25 68.1.1.25
ServerIron(config-rs-rs25)# port dns
ServerIron(config-rs-rs25)# port mms
ServerIron(config-rs-rs25)# port ftp
ServerIron(config-rs-rs25)# port ssl
ServerIron(config-rs-rs25)# port http
ServerIron(config-rs-rs25)# port http url "HEAD /"
ServerIron(config-rs-rs25)# exit
The following commands configure the remote servers in Figure 2.41:
ServerIron(config)# server remote-name rs26 10.2.24.26
ServerIron(config-rs-rs26)# source-nat
ServerIron(config-rs-rs26)# port dns
ServerIron(config-rs-rs26)# port ftp
ServerIron(config-rs-rs26)# port ssl
ServerIron(config-rs-rs26)# port http
ServerIron(config-rs-rs26)# port http url "HEAD /"
ServerIron(config-rs-rs26)# exit
ServerIron(config)# server remote-name rs27 10.2.24.27
ServerIron(config-rs-rs27)# source-nat
ServerIron(config-rs-rs27)# port dns
ServerIron(config-rs-rs27)# port ftp
ServerIron(config-rs-rs27)# port ssl
ServerIron(config-rs-rs27)# port http
ServerIron(config-rs-rs27)# port http url "HEAD /"
ServerIron(config-rs-rs27)# exit
The following commands configure the virtual servers in Figure 2.41:
ServerIron(config)# server virtual-name-or-ip www 206.65.1.100
ServerIron(config-vs-www)# port ssl sticky
ServerIron(config-vs-www)# port http
ServerIron(config-vs-www)# bind ssl rs25 ssl rs24 ssl rs23 ssl
ServerIron(config-vs-www)# bind ssl rs27 ssl rs26 ssl
ServerIron(config-vs-www)# bind http rs25 http rs24 http rs23 http
ServerIron(config-vs-www)# bind http rs27 http rs26 http
ServerIron(config-vs-www)# exit
ServerIron(config)# server virtual-name-or-ip ftp 206.65.1.101
ServerIron(config-vs-ftp)# port ftp
ServerIron(config-vs-ftp)# bind ftp rs25 ftp rs24 ftp rs23 ftp
ServerIron(config-vs-ftp)# bind ftp rs27 ftp rs26 ftp
ServerIron(config-vs-ftp)# exit
ServerIron(config)# server virtual-name-or-ip mms 206.65.1.102
ServerIron(config-vs-mms)# port mms
ServerIron(config-vs-mms)# bind mms rs25 mms rs24 mms rs23 mms
ServerIron(config-vs-mms)# exit
ServerIron(config)# server virtual-name-or-ip dns 206.65.1.103
ServerIron(config-vs-dns)# port dns
ServerIron(config-vs-dns)# bind dns rs25 dns rs24 dns rs23 dns
IPsec and VPN Load Balancing
IPsec is a collection of protocols used for providing security for packet exchange at the network layer. It is used in the deployment of VPNs. In a VPN implementation that uses IPsec, packets are encrypted by an IPsec-compliant sender and are decrypted by an IPsec-compliant receiver.
IPsec requires that a key be exchanged between the sending and receiving devices in a VPN. The key negotiation and exchange is done using IKE (Internet Key Exchange). IKE uses UDP port 500 to set up the key exchange between the sending and receiving devices. After the key is exchanged, IPsec starts the secure exchange of packets between the end points by using the Authentication Header (AH) and Encapsulating Security Payload (ESP). Authentication is achieved by using the AH, and confidentiality and encryption are achieved using the ESP protocol. Note that AH and ESP are both higher layer protocols on top of IP, and they each have a protocol ID. AH packets contain the value 51 in the protocol field, and ESP packets are associated with protocol 50.
In a VPN implementation, typically the original IP packet (IP header and data payload) is encrypted, and a new IP header along with AH and ESP fields are added to the packet. The original IP address is known as the inner IP address, and the new IP address is known as the outer IP address. The outer IP address is used for communication with a VPN device or gateway, and is usually configured on the sending host (such as a remote VPN client). The outer IP address can be defined as a VIP on the ServerIron ADX. When the ServerIron ADX receives the IKE packet destined to this VPN VIP, it chooses a VPN device and load balances the IKE request to the proper VPN device belonging to this VIP.
The ServerIron ADX detects the IKE traffic and creates IKE sessions for each Source-Destination IP pair for UDP port 500. Once the VPN device completes IKE negotiation with the remote host, the ensuing IPsec encrypted packets are received by the ServerIron ADX, which in turn creates additional IPsec sessions for the traffic flow. The ServerIron ADX keeps track of each IPsec secured link by using Security Associations (SAs). Incoming packets are assigned to a particular SA by identifying three defining fields: Destination IP address, Security Parameter Index (SPI), and security protocol (50 or 51). The SPI value can be thought of as a cookie that is handed out by the receiving side, which when combined with the other two defining fields, guarantees a unique value to distinguish every single unidirectional flow of IPsec traffic.
NOTE: In some network configurations where many-to-one address translation is required, NAT transparency may be required. NAT transparency basically encapsulates IKE and ESP packets into another transport protocol such as UDP so that address-translating devices know how to correctly handle the address translation.
You can configure a single ServerIron ADX to load balance traffic for multiple VPN devices or use a pair of ServerIron ADXs in an Active-Standby or Active-Active configuration to provide redundancy and improved performance when load balancing multiple VPN devices. See “Sym-Active in an IPsec/IKE Load Balancing Configuration” for an example.
Figure 2.42 shows an example of a basic IPsec/IKE load balancing configuration. In this example, a single ServerIron ADX is configured to load balance VPN traffic across two VPN devices. A Layer 2 switch on the other side of the VPN devices connects the VPN devices to content servers. When a client sends a request to the VPN IP address, the ServerIron ADX forwards the request to one of the VPN devices. The VPN device authenticates the request and either denies the request or forwards the request to a content server. When the ServerIron ADX receives return traffic from a VPN device, the ServerIron ADX forwards the return traffic to the client.
Figure 2.42
Configuring IPsec and VPN Load Balancing
To configure IPsec and VPN load balancing on the ServerIron ADX, perform the following tasks:
Configure a virtual server with the VPN IP address that clients will access. Enable Layer 4 VPN tunneling on the virtual server, add port 500, and bind the real server definitions to the virtual server with port 500.
Configuration Considerations for IPsec and VPN Load Balancing
Adding a Real Server Definition for a VPN Device
To add a real server definition for a VPN device, enter commands such as the following for each VPN device:
ServerIron(config)# server real-name VPN1 192.168.1.10
ServerIron(config-rs-VPN1)# port 500
Syntax: [no] server real-name <string> <ip-addr>
Configuring a Virtual Server Definition for the VPN Address
To add a virtual server definition for the VPN address, enter commands such as the following:
ServerIron(config)# server virtual-name-or-ip VPNaddr 192.168.1.100
ServerIron(config-vs-VPNaddr)# sw-l4-vpn-tunnel
ServerIron(config-vs-VPNaddr)# port 500
ServerIron(config-vs-VPNaddr)# bind 500 vpn1 500 vpn2 500
Syntax: [no] server virtual-name-or-ip <string> <ip-addr>
Syntax: [no] sw-l4-vpn-tunnel
Syntax: bind 500 <real-server-name> 500 <real-server-name> [500 <real-server-name>...] 500
Configuration Example
Here are the CLI commands to implement the configuration shown in Figure 2.42.
The following commands change the CLI to global CONFIG level, add the management IP address, and identify the default gateway.
ServerIron> enable
ServerIron# configure terminal
ServerIron(config)# ip address 192.168.1.1 255.255.255.0
ServerIron(config)# ip default-gateway 192.168.1.254
The following commands add the real server definitions for the VPN devices:
ServerIron(config)# server real-name VPN1 192.168.1.10
ServerIron(config-rs-VPN1)# port 500
ServerIron(config-rs-VPN1)# exit
ServerIron(config)# server real-name VPN2 192.168.1.11
ServerIron(config-rs-VPN2)# port 500
ServerIron(config-rs-VPN2)# exit
The following commands configure the virtual server definition for the VPN address.
ServerIron(config)# server virtual-name-or-ip VPNaddr 192.168.1.100
ServerIron(config-vs-VPNaddr)# sw-l4-vpn-tunnel
ServerIron(config-vs-VPNaddr)# port 500
ServerIron(config-vs-VPNaddr)# bind 500 vpn1 500 vpn2 500
ServerIron(config-vs-VPNaddr)# exit
The following commands enable Layer 4 switching for TCP traffic and save the configuration changes to the startup-config file.
ServerIron(config)# ip l4-policy 1 cache tcp 0 global
ServerIron(config)# write memory
Active-Active Inside Source NAT with SLB and VRRP-E
The following commands add SLB information to the inside source NAT example in “Configuration Example: Active-Active Inside Source NAT with VRRP-E” .
Commands also are added to ServerIron ADX A to change its VRRP-E backup priority for the VRIDs, to ensure that the same ServerIron ADX has the higher SSLB priority for the VIP and the higher VRRP-E backup priority.
SI A Configuration
To add real server rs3, with four application ports, enter commands such as the following:
ServerIronA(config)# server real rs3 10.10.20.103
ServerIronA(config-rs-rs3)# port http
ServerIronA(config-rs-rs3)# port ftp
ServerIronA(config-rs-rs3)# port dns
ServerIronA(config-rs-rs3)# port rtsp
ServerIronA(config-rs-rs3)# exit
To enable session synchronization on the four application ports, enter commands such as the following:
ServerIronA(config)# server port 80
ServerIronA(config-port-http)# session-sync
ServerIronA(config-port-http)# exit
ServerIronA(config)# server port 21
ServerIronA(config-port-ftp)# session-sync
ServerIronA(config-port-ftp)# exit
ServerIronA(config)# server port 53
ServerIronA(config-port-dns)# session-sync
ServerIronA(config-port-dns)# exit
ServerIronA(config)# server port 554
ServerIronA(config-port-rtsp)# session-sync
ServerIronA(config-port-rtsp)# exit
To create virtual server vs1 and bind the application ports on rs3 to the virtual server, enter commands such as the following:
ServerIronA(config)# server virtual-name-or-ip vs1 10.10.20.100
ServerIronA(config-vs-vs1) #port http
ServerIronA(config-vs-vs1)# port ftp
ServerIronA(config-vs-vs1)# port dns
ServerIronA(config-vs-vs1)# port rtsp
ServerIronA(config-vs-vs1)# bind 80 rs3 80
ServerIronA(config-vs-vs1)# bind 21 rs3 21
ServerIronA(config-vs-vs1)# bind 53 rs3 53
ServerIronA(config-vs-vs1)# bind 554 rs3 554
To configure a Symmetric SLB (SSLB) priority and enable the active-active mode for SSLB, enter commands such as the following:
ServerIronA(config-vs-vs1)# sym-priority 254
ServerIronA(config-vs-vs1)# sym-active
To configure policies that enable SLB, enter commands such as the following:
ServerIronA(config)# ip l4-policy 1 cache tcp 0 global
ServerIronA(config)# ip l4-policy 2 cache udp 0 global
The following command, entered at the VRID configuration level for VRID 1 on virtual routing interface 1, sets the backup priority to 200, which is higher than the default priority (100). By setting this ServerIron ADX’s VRRP-E backup priority to a higher value than the other ServerIron ADX’s VRRP-E backup priority, you can ensure that the same ServerIron ADX will be the active ServerIron ADX for the VIP and the VRRP-E address.
Make sure the ServerIron ADX that has the higher SSLB priority also has the higher VRRP-E priority. Otherwise, after a VRRP-E failover, it is possible for a ServerIron ADX to become the VRRP-E master without the VIP also failing over to the ServerIron ADX. In this case, one ServerIron ADX is the master for the VRID while the other ServerIron ADX is the master for the VIP.
ServerIronA(config-ve-1-vrid1)# backup priority 200
Make sure the ServerIron ADX that has the higher SSLB priority also has the higher VRRP-E priority.
To set the backup priority for VRID 2 to 200, enter the following command at the VRID configuration level for VRID 2 on virtual routing interface 2:
ServerIronA(config-ve-2-vrid2)# backup priority 200
SI B Configuration
The following commands add the SLB information for ServerIron ADX B. Notice that the information is the same except for the SSLB priority, which is set to 100. The VRRP-E backup priority is not changed and remains set at the default (100).
ServerIronB(config)# server real rs3 10.10.20.103
ServerIronB(config-rs-rs3)# port http
ServerIronB(config-rs-rs3)# port ftp
ServerIronB(config-rs-rs3)# port dns
ServerIronB(config-rs-rs3)# port rtsp
ServerIronB(config-rs-rs3)# exit
ServerIronB(config)# server port 80
ServerIronB(config-port-http)# session-sync
ServerIronB(config-port-http)# exit
ServerIronB(config)# server port 21
ServerIronB(config-port-ftp)# session-sync
ServerIronB(config-port-ftp)# exit
ServerIronB(config)# server port 53
ServerIronB(config-port-dns)# session-sync
ServerIronB(config-port-dns)# exit
ServerIronB(config)# server port 554
ServerIronB(config-port-rtsp)# session-sync
ServerIronB(config-port-rtsp)# exit
ServerIronB(config)# server virtual-name-or-ip vs1 10.10.20.100
ServerIronB(config-vs-vs1) #port http
ServerIronB(config-vs-vs1)# port ftp
ServerIronB(config-vs-vs1)# port dns
ServerIronB(config-vs-vs1)# port rtsp
ServerIronB(config-vs-vs1)# bind 80 rs3 80
ServerIronB(config-vs-vs1)# bind 21 rs3 21
ServerIronB(config-vs-vs1)# bind 53 rs3 53
ServerIronB(config-vs-vs1)# bind 554 rs3 554
ServerIronB(config-vs-vs1)# sym-priority 100
ServerIronB(config-vs-vs1)# sym-active
ServerIronB(config)# ip l4-policy 1 cache tcp 0 global
ServerIronB(config)# ip l4-policy 2 cache udp 0 global
server opt-enable-route-recalculation
For optimized SLB, the ServerIron ADX does not calculate a reverse route for every packet in a flow. In this scenario, the ServerIron ADX uses the route that it learns in the first reverse packet, such as SYN-ACK packet. However, this calculation might not be desirable in a environment where a route can be dynamically changed, such as a case with upstream firewall fail-over, where the new firewall has the same IP address but a different MAC address. To cover these cases, the server opt-enable-route-recalculation command, forces the ServerIron ADX to dynamically calculate the reverse route.
NOTE: This command should only be used when there is a need to recalculate reverse route. Most cases don't require this.

Server Load Balancing > SLB Configuration Examples

Table of Contents Previous Next Print
Copyright © 2009 Brocade Communications Systems, Inc.