Web Hosting with One Virtual Server Mapped to Multiple Real Servers
Web Hosting with Multiple Virtual Servers Mapped to One Real Server
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
To configure the ServerIron ADX or switch for this application, enter the following commands:
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.)
The port http command enables the HTTP port.
The bind commands associate the http port on each real server with the http port on the virtual server.
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.
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.
|
|
•
|
Concurrent connections – The real server can open additional ("concurrent") TCP/UDP sessions with the client using arbitrary TCP/UDP port numbers.
|
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.
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
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1ServerIron(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.
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.
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1ServerIron(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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Figure 2.36 shows an example of HTTP redirect in use.
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.
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.
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.
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.
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.
ServerIron(config)# ip policy 1 cache tcp 80 globalServerIron(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 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.
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.
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.
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.
ServerIron(config)# server virtual-name-or-ip VIP1 192.1.1.1ServerIron(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.
The ServerIron ADX can perform load balancing for the following kinds of streaming media files:
Figure 2.39 shows a sample configuration where requests for three kinds of streaming media files are load balanced across three real servers.
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.
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.
Figure 2.40 illustrates an SLB configuration with one VLAN and one 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
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
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
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
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
Figure 2.41 illustrates an SLB configuration with three VLANs and three 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
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
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
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
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.
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.
ServerIron(config)# server real-name VPN1 192.168.1.10
ServerIron(config-rs-VPN1)# port 500
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> 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
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
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
ServerIron(config)# ip l4-policy 1 cache tcp 0 global
ServerIron(config)# write memory
Active-Active Inside Source NAT with SLB and 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.
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
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
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
ServerIronA(config-vs-vs1)# sym-priority 254
ServerIronA(config-vs-vs1)# sym-active
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.
ServerIronA(config-ve-2-vrid2)# backup priority 200
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).
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.
Copyright © 2009 Brocade Communications Systems, Inc.
