Software Release 09.1.00R supports Policy-Based Routing (PBR) for reverse SLB traffic on the ServerIron. Policy-Based Routing routes traffic based on policies you define. A PBR policy specifies the next hop for traffic that matches the policy.
To configure PBR, you define the policies using IP ACLs and route maps, then enable PBR globally or on individual interfaces. The device routes traffic that matches the ACLs according to the instructions in the route maps.
In a network where clients belonging to different sub-nets and VLANs are sending traffic to VIPs belonging to their respective sub-nets, you can configure PBR to send return traffic back to each client the way it came, rather than
Table 3.11: Real Server Bandwidth Octet List
This Field... Displays...
Server IP address IP address of the real server
Number of intervals Number of 100 ms byte counts (bandwidth usage counts) maintained for the real server.
Bind count Number of virtual servers to which the ports of a real server are bound Interval size The size of an interval, which is always 100 ms
Start of list ... end of list Each entry represents a count. A count represents the bandwidth usage in bytes for a duration shown in the Interval size field and is an aggregate of the bytes reported by all the ServerIron for that interval .
For example, in the example above, there are ten bandwidth usage counts for Real Server dns-ns. Each count reflects the bandwidth usage of the real server during a 100 ms interval. The text "write next here" means that this is the most recent interval; that is, the most recent bandwidth usage count will be written in this space.
having all of the traffic use the default route. To do this, you can configure ACLs and route maps and apply them either globally or to individual interfaces.
In the following example, clients belonging to two different sub-nets 33.33.33.0/24 and 10.10.1.0/24 are accessing VIPs 33.33.33.111 and 10.10.1.111, respectively. The next-hop routers for these clients are 33.33.33.1 and 10.10.1.1. To load balance the return traffic to the clients, you can configure the following ACLs and route map:
ServerIron(config)# access-list 101 permit ip 33.33.33.0 0.0.0.255 any ServerIron(config)# access-list 102 permit ip 10.10.1.0 0.0.0.255 any ServerIron(config)# route-map test-route permit 101
ServerIron(config-route-map test-route)# match ip address 101 ServerIron(config-route-map test-route)# set ip next-hop 33.33.33.2 ServerIron(config-route-map test-route)# exit
ServerIron(config)# route-map test-route permit 102
ServerIron(config-route-map test-route)# match ip address 102 ServerIron(config-route-map test-route)# set ip next-hop 10.10.1.2 ServerIron(config-route-map test-route)# exit
ServerIron(config)# ip policy route-map test-route
See "Policy-Based Routing (PBR)" in the Foundry Enterprise Configuration and Management Guide for more information on configuring PBR.
DSR
Direct Server Return (DSR) enables the return traffic to not be processed by the ServerIron. Instead, the real server directly sends the return traffic to the client. In this case, the ServerIron changes the way it sends health checks to the application so that the health checks do not rely on the return traffic.
There are many DSR applications. You can use DSR on a single ServerIron or apply it to a High Availability (HA) scenario (Hot Standby SLB, Symmetric SLB, and Sym-Active SLB).
SwitchBack configurations enhance server response time and increase capacity on the ServerIron, by allowing server responses to bypass the ServerIron on the way to clients and at the same time increasing the number of simultaneous connections the ServerIron can support.
Figure 3.28
DSR configurations can enhance server response time and increase capacity on the ServerIron, by allowing server responses to bypass the ServerIron on the way to clients and at the same time increasing the number of simultaneous connections the ServerIron can support.
Some ServerIron implementations are in topologies where both directions of load-balancing traffic, the client-to- server and server-to-client traffic, flow through the ServerIron. In this type of configuration, the ServerIron uses two sessions for each connection. One session is for the client-server traffic and the other session is for the server-client traffic.
Typically, the client-server traffic uses less bandwidth than the server-client traffic. The client-server traffic usually consists of the initial GET requests to the VIP and TCP ACKs when the client receives a response from the server. The remaining traffic consists of the requested Web pages sent to the client by the server.
The SwitchBack feature places the real server directly in contact with the client, so that server-client traffic does not pass through the ServerIron but instead goes directly from the server to the client. By placing the client directly in contact with the real server, SwitchBack enhances overall performance and throughput, and thus enhances the service experienced by the client.
A ServerIron configured for Server Load Balancing acts as a dispatcher, sending client requests for a VIP directly to the real server, which responds directly to the client. The ServerIron does not translate the destination IP address in the client’s request from the VIP into the real server’s IP address as in other SLB configurations. Instead, the ServerIron leaves the destination IP address unchanged.
NOTE: You cannot have a router hop between the ServerIrons. They must have Layer 2 connectivity. The SwitchBack feature applies to individual TCP/UDP ports. To configure the ServerIron for SwitchBack, you enable the feature for individual TCP/UDP ports when configuring the virtual server. For example, when you enable TCP port 80 (HTTP) on a virtual server, you can add the dsr parameter to enable SwitchBack for that port. Traffic for other ports still returns through the ServerIron. The ServerIron does not translate the destination IP address in client requests for the port with SwitchBack enabled. However, the ServerIron does still translate the destination IP address in the client’s request to the real server’s IP address for other ports.
To configure the real servers for SwitchBack, configure a loopback interface on each real server and assign the VIP addresses to the loopback interface. The loopback interface enables the real server to respond to client requests directed at the VIPs, while at the same time keeping the real server “hidden”. The loopback interface responds to unicast traffic directed to it, but does not respond to ARP requests. The ServerIron responds to pings and ARPs for the VIPs. Thus, an attempt to obtain the real server’s MAC address by ARPing a VIP does not succeed. See “Configuring the Loopback Address on a Real Server” on page 3-143.
SI-A
SI-B
Client
Client requests
Server
Server sends return traffic directly to the client