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

Table of Contents Previous Next Print


Server Load Balancing > DSR

DSR
Direct Server Return (DSR) enables the return traffic to not be processed by the ServerIron ADX. Instead, the real server directly sends the return traffic to the client. In this case, the ServerIron ADX 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 ADX 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 ADX, by allowing server responses to bypass the ServerIron ADX on the way to clients and at the same time increasing the number of simultaneous connections the ServerIron ADX can support.
When DSR is used in the configuration, the return traffic gets directed over a more efficient path.
Figure 2.25
DSR configurations can enhance server response time and increase capacity on the ServerIron ADX, by allowing server responses to bypass the ServerIron ADX on the way to clients and at the same time increasing the number of simultaneous connections the ServerIron ADX can support.
Some ServerIron ADX implementations are in topologies where both directions of load-balancing traffic, the client-to-server and server-to-client traffic, flow through the ServerIron ADX. In this type of configuration, the ServerIron ADX 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 ADX 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 ADX 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 ADX 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 ADX leaves the destination IP address unchanged.
NOTE: You cannot have a router hop between the ServerIron ADXs. They must have Layer 2 connectivity.
The SwitchBack feature applies to individual TCP/UDP ports. To configure the ServerIron ADX 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 ADX. The ServerIron ADX does not translate the destination IP address in client requests for the port with SwitchBack enabled. However, the ServerIron ADX 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 ADX 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”.
Setting DSR Normal Age Reverse Session
Use the server dsr-normal-age-reverse-session command in the global configuration mode to ensure that a DSR reverse session ages normally during long-lived sessions. With this command, you can avoid session accumulation when connections are long lived.
Syntax: [no] server dsr-normal-age-reverse-session
Remote Failover Servers for SwitchBack
You can use real servers on other sub-nets as remote servers in SwitchBack configurations. In this configuration, the ServerIron ADX uses the local servers as in previous releases. This means all the local servers must have Layer 2 connectivity to the ServerIron ADX. However, if all the local servers become unavailable, the ServerIron ADX then fails over to the remote servers, thus continuing to provide service to the clients.
NOTE: All the local servers in the SwitchBack configuration still must have Layer 2 connectivity to the ServerIron ADX.
Health Checks with SwitchBack
Normally, the ServerIron ADX can perform health checks on an application port only when server replies from that port pass back through the ServerIron ADX. If the ServerIron ADX does not see the real server’s responses to client requests, the ServerIron ADX concludes that the application or the entire server is down and stops sending client requests to that server.
When you enable an application port for DSR, the ServerIron ADX can still perform heath checks on the application by sending the health checks to the loopback address you configure on the real server:
ServerIron(config)# server virtual-name-or-ip v1 209.157.22.1
ServerIron(config-vs-v1)# port 80 dsr
Syntax: [no] port <tcp/udp-port> dsr
You can use Layer 4 and Layer 7 health checks in your SwitchBack configuration:
The ServerIron ADX addresses Layer 3 (IP ping) health checks to the real server IP address, and addresses Layer 4 health checks to the real server IP address and the TCP or UDP protocol on the server.
The ServerIron ADX addresses Layer 7 health checks to the real server MAC address and to the loopback address that matches the VIP address.
The configuration procedures for the health checks are the same as for other types of SLB. See “Health Checks”.
SYN-Defense with SwitchBack
SYN-Defense is a security feature that configures the ServerIron ADX to complete the TCP three-way handshake on behalf of a connecting client. ServerIron ADX releases that do not support Layer 3 do not support the SYN-Defense feature in SwitchBack configurations. This is because the ServerIron ADX does not see the server’s SYN ACK, and as a result cannot complete the connection. The incomplete connection resides on the server as a pending connection, a condition the SYN-Defense feature is meant to eliminate.
TrafficWorks router software enables you to use the SYN-Defense feature in a SwitchBack configuration. To do so, configure the server to use the ServerIron ADX as its default gateway.
Placing a Session in Timeout Queue
This feature places a session in an accelerated session timeout queue upon seeing the first FIN in DSR (as opposed to the standard two FINs). The session is timed out in 8 seconds instead of the standard session age.
To place a session in an accelerated session timeout queue, enter commans such as the following:
ServerIron(config)#server virtual-name-or-ip vs
ServerIron(config-vs-vs)#port <port> dsr fast-delete
Upon receiving first FIN from a client, the ServerIron ADX puts sessions in a deletion queue, thus speeding up the deletion process.
Syntax: [no] port <port> dsr fast-delete
NOTE: If there is pending data delayed beyond the accelerated timeout, the session may become prematurely aged out. Exercise caution when enabling this command.
SwitchBack Configuration Example
The following table and Figure 2.26 show an example of a SwitchBack configuration for a High Availability scenario.
Because multiple VIPs are mapping to the same ports on the same real servers, TCP/UDP port binding is used. Thus, port 180 on VIP2 on ServerIron ADX A and on VIP1 on ServerIron ADX B is a logical port that is bound to port 80 on the real servers. For more information, see “Many-To-One TCP/UDP Port Binding”.
VIP’s TCP Port
Real IP Address
Real Server’s TCP Port
VIP1:
209.157.22.100
Real Server 1: 10.0.0.1

Real Server 2: 10.0.0.2
80


80
VIP2:
209.157.22.101
Real Server 1: 10.0.1.1

Real Server 2: 10.0.1.2
180


180
VIP1:
209.157.22.100
Real Server 3: 10.0.0.1

Real Server 4: 10.0.0.2
180


180
VIP2:
209.157.22.101
Real Server 3: 10.0.1.1

Real Server 4: 10.0.1.2
80


80
Figure 2.26
ServerIron ADXs deployed in SwitchBack configuration
To implement the configuration shown in Figure 2.26, configure ServerIron ADXs A and B.
Note the dsr parameter on the port commands that add the HTTP port (TCP port 80) to the VIPs. To enable SwitchBack for additional TCP/UDP ports, you use the dsr parameter for each port when you add the port to a VIP.
NOTE: Be sure you configure all the real servers on both ServerIron ADXs, and bind the VIPs on each ServerIron ADX to all the real servers.
NOTE: Brocade recommends that you specify 2 (instead of 1) as a low priority or 254 (instead of 255) as a high priority. This way, you can easily force failover of the high priority ServerIron ADX to the low priority ServerIron ADX by changing the priority on just one of the ServerIron ADXs. For example, you can force a failover by changing the priority on the high priority ServerIron ADX from 254 to 1. Since the priority on the low priority ServerIron ADX is 2, the low priority ServerIron ADX takes over for the VIP. Likewise, you can force the low priority ServerIron ADX to take over by changing its priority to 255, since the priority on the high priority ServerIron ADX is only 254.
Configuring ServerIron ADX A
Notice that all four real servers must be configured, and bound to the VIPs, on both ServerIron ADXs. Notice also that two HTTP ports are added to each real server. This type of configuration requires that you use the TCP/UDP port binding feature to bind the ports on the two real servers to the same port on the virtual server. For information, see “Many-To-One TCP/UDP Port Binding”.
To configure the real servers, enter the following commands:
ServerIronA(config)# server real-name Real_Server_1 10.0.0.1
ServerIronA(config-rs-Real_Server_1)# port http
ServerIronA(config-rs-Real_Server_1)# port 180
ServerIronA(config-rs-Real_Server_1)# exit
ServerIronA(config)# server real-name Real_Server_2 10.0.0.2
ServerIronA(config-rs-Real_Server_2)# port http
ServerIronA(config-rs-Real_Server_2)# port 180
ServerIronA(config-rs-Real_Server_2)# exit
ServerIronA(config)# server real-name Real_Server_3 10.0.1.1
ServerIronA(config-rs-Real_Server_3)# port http
ServerIronA(config-rs-Real_Server_3)# port 180
ServerIronA(config-rs-Real_Server_3)# exit
ServerIronA(config)# server real-name Real_Server_4 10.0.1.2
ServerIronA(config-rs-Real_Server_4)# port http
ServerIronA(config-rs-Real_Server_4)# port 180
ServerIronA(config-rs-Real_Server_4)# exit
 
To configure the VIPs, enter the following commands:
ServerIronA(config)# server virtual-name-or-ip VIP1 209.157.22.100
ServerIronA(config-vs-VIP1)# port http dsr
ServerIronA(config-vs-VIP1)# bind http Real_Server_1 http Real_Server_2 http Real_Server_3 http Real_Server_4 http
ServerIronA(config-vs-VIP1)# sym-priority 254
ServerIronA(config-vs-VIP1)# exit
ServerIronA(config)# server virtual-name-or-ip VIP2 209.157.22.101
ServerIronA(config-vs-VIP2)# port http dsr
ServerIronA(config-vs-VIP2)# bind http Real_Server_1 180 Real_Server_2 180 Real_Server_3 180 Real_Server_4 180
ServerIronA(config-vs-VIP2)# no http port translate
ServerIronA(config-vs-VIP2)# sym-priority 2
ServerIronA(config-vs-VIP2)# exit
ServerIronA(config)# write memory
Configuring ServerIron ADX B
To configure the real servers, enter the following commands:
ServerIronB(config)# server real-name Real_Server_1 10.0.0.1
ServerIronB(config-rs-Real_Server_1)# port http
ServerIronB(config-rs-Real_Server_1)# port 180
ServerIronB(config-rs-Real_Server_1)# exit
ServerIronB(config)# server real-name Real_Server_2 10.0.0.2
ServerIronB(config-rs-Real_Server_2)# port http
ServerIronB(config-rs-Real_Server_2)# port 180
ServerIronB(config-rs-Real_Server_2)# exit
ServerIronB(config)# server real-name Real_Server_3 10.0.1.1
ServerIronB(config-rs-Real_Server_3)# port http
ServerIronB(config-rs-Real_Server_3)# port 180
ServerIronB(config-rs-Real_Server_3)# exit
ServerIronB(config)# server real-name Real_Server_4 10.0.1.2
ServerIronB(config-rs-Real_Server_4)# port http
ServerIronB(config-rs-Real_Server_4)# port 180
ServerIronB(config-rs-Real_Server_4)# exit
 
To configure the VIPs, enter the following commands:
ServerIronB(config)# server virtual-name-or-ip VIP1 209.157.22.100
ServerIronB(config-vs-VIP1)# port http dsr
ServerIronB(config-vs-VIP1)# bind http Real_Server_1 180 Real_Server_2 180 Real_Server_3 180 Real_Server_4 180
ServerIronB(config-vs-VIP1)# no http port translate
ServerIronB(config-vs-VIP1)# sym-priority 2
ServerIronB(config-vs-VIP1)# exit
ServerIronB(config)# server virtual-name-or-ip VIP2 209.157.22.101
ServerIronB(config-vs-VIP2)# port http dsr
ServerIronB(config-vs-VIP2)# bind http Real_Server_1 http Real_Server_2 http Real_Server_3 http Real_Server_4 http
ServerIronB(config-vs-VIP2)# sym-priority 254
ServerIronB(config-vs-VIP2)# exit
ServerIronB(config)# write memory
Configuring the Loopback Address on a Real Server
You can configure loopback addresses on some common types of real servers.
NOTE: The information in this section is based on information from the vendors of these servers. For more information, please consult your real server vendor.
Solaris
To configure a loopback address on Solaris, enter the following command:
ifconfig lo0:1 <vip-addr> netmask <net-mask> up
You might need to “plumb” the interface first. In this case, enter the following commands:
ifconfig lo0:1 plumb
ifconfig lo0:1 <vip-addr> netmask <net-mask> up
NOTE: This command applies to the current running configuration only. To make the address permanent so that it is reconfigured following a reboot or power cycle, create the file /etc/hostname.lo0:1.
NOTE: For Hewlett-Packard (HP) version 11.x, use the May 2000 or later patch.
Linux
To configure a loopback interface on Linux, enter a command such as the following:
ifconfig lo:0 <vip-addr> netmask <net-mask> up
NOTE: This command applies to the current running configuration only. To make the address permanent so that it is reconfigured following a reboot or power cycle, go to /etc/sysconfig/network-scripts and make a file called ifcfg-lo:0 using ifcfg-lo as a template.
NT
To configure a loopback interface on NT, you need to configure a new network adapter. Use the following procedure. This procedure applies to the following products:
NOTE: When you add a loopback interface to NT, NT sometimes creates a route that has the same address as the loopback interface. You need to delete this route. In come cases, the procedure for deleting the route can include deleting the correct route to the server’s default gateway. When this is the case, you need to add this route back to NT.
Manual Installation
1.
2.
3.
4.
5.
6.
7.
8.
After the adapter is installed successfully, you can configure its options manually, as with any other adapter.
NOTE: If the TCP/IP properties are configured to use DHCP (the default), the adapter will eventually use an autonet address (169.254.x.x/16) because it is not actually connected to any physical media.
Unattended Installation
Modify the Unattend.txt file using the following example as a guide to install the Microsoft Loopback adapter:
[NetAdapters]
Adapter01=Params.Adapter01
[Params.Adapter01]
InfID="*msloop" ; Microsoft Loopback Adapter
ConnectionName = "MS Loopback Adapter"
[NetProtocols]
MS_TCPIP=Params.MS_TCPIP
; TCP/IP parameters
; Use parameter values specific to your network
[Params.MS_TCPIP]
AdapterSections=params.TCPIP.Adapter01
DNS=yes
DNSSuffixSearchOrder=mycorp.com
EnableLMHosts=No
; Adapter Specific TCP/IP parameters
; Use parameter values specific to your network
[params.TCPIP.Adapter01]
SpecificTo=Adapter01
DNSDomain=mycorp.com
DNSServerSearchOrder=192.168.5.251
WINS=no
DHCP=no
IPAddress=192.168.5.10
SubnetMask=255.255.255.0
DefaultGateway=192.168.5.254
Deleting the Unwanted Routes
In some cases, NT creates a route that has the same address as the loopback interface. You need to delete this route.
Two methods are shown in this section. If you receive an error message while trying to use the simple method, you need to use the long method instead.
NOTE: Regardless of the method you use, you must repeat the procedure every time the NT server is booted. However, you can create a small batch file to enter these commands and add the batch file to the AT subsystem so that the file runs automatically each time the server is booted.
Simple Method
The simple method requires you to delete the route that NT creates when you add the loopback interface. The route you need to delete is the one that has the same IP address as the loopback interface.
1.
Enter the route print command to display the server’s route table. In this example, the loopback interface has address 192.168.200.106.
2.
C:\>route delete 192.168.200.0 mask 255.255.255.0 192.168.200.106
 
3.
Long Method
The long method, like the short method, requires you to delete the route that NT creates when you add the loopback interface. However, what makes this method is long is that in some cases, when the route table has more than one route in the network that contains the loopback interface, the route delete command deletes the wrong route. In this case, you need to enter the command again to delete the route that has the loopback address, then re-add the other route.
1.
Enter the route print command to display the server’s route table. In this example, the loopback interface has address 192.168.200.106. Notice that the route table also contains another route (192.168.200.250) in the same network. The 192.168.200.250 route is the gateway route and needs to stay in the route table.
2.
Enter the route delete command to delete the unwanted 192.168.200.106 route.
C:\users\default>route delete 192.168.200.0 mask 255.255.255.0 192.168.200.106
3.
Display the route table again to verify the results. In this example, NT deletes the first 192.168.200.x route in the table instead of deleting the route you want to delete. If this occurs when you are performing this procedure, go to Step 4. Otherwise, you are through with this procedure.
4.
Enter the route delete command again to delete the unwanted route.

C:\users\default>route delete 192.168.200.0 mask 255.255.255.0 192.168.200.106
5.
6.
Enter the route add command to re-add the gateway route.
C:\users\default>route add 192.168.200.0 mask 255.255.255.0 192.168.200.250
7.
Displaying Server Information
The show server command, as a standalone command, gives the output of the following commands together:
The show server global command gives the output of the show server backup or the show server symmetric command, depending on which high availability method is in use, plus some additional configuration information that would have to be shared between a pair of ServerIron ADXs in a high availability environment.
The following is a sample for a ServerIron using Sym-active SLB:
 
 
Displaying Global Layer 4 ServerIron ADX Configuration
To display global Layer 4 ServerIron ADX configuration information, enter the following command:
Syntax: show server global
This display shows the following information.
 
The ServerIron ADX port number on which the ServerIron ADX perceives other ServerIron ADXs running Symmetric SLB.
The number of ports on which the ServerIron ADX perceives a partner ServerIron ADX running Symmetric SLB.
The load balancing metric in effect on the ServerIron ADX. The predictor can be one of the following:
round-robin
The state of the force shutdown option. This option immediately shuts down a server or service instead of waiting for existing connections to end before shutting the server or service down. The state can be one of the following:
0 – Disabled
1 – Enabled
The number of contiguous inbound TCP-SYN packets sent to the server that the server has not responded to.
The TCP SYN-ACK counter increments only when acknowledgments are not received. Each time an expected TCP SYN-ACK is received, the counter is cleared.
The default reassign threshold is 21 unacknowledged TCP SYN-ACKs. The value can be from 6 – 254. To change the reassign threshold, see “Reassign Threshold”
Note: You can modify this parameter to help minimize vulnerability to TCP SYN attacks.
The number of missed TCP SYN packets the ServerIron ADX will accept before moving an inbound connection attempt to another server.
How often the ServerIron ADX sends a Layer 3 IP ping to test the basic health and reachability of the real servers. When enabled, this parameter specifies the interval for the pings. To change the interval, see “Modifying the Ping Interval and Ping Retries”.
How many times the ServerIron ADX resends a ping to a real server that is not responding. The default is 4 and can be from 2 – 10. To change this parameter, see “Modifying the Ping Interval and Ping Retries”.
If the server still does not respond after the last retry, the ServerIron ADX marks the server FAILED and removes it from the load balancing rotation.
The number of minutes the ServerIron ADX allows a TCP connection to remain unused before closing the connection. The default is 30 minutes. To change this parameter, see “Configuring TCP Age”.
The number of minutes the ServerIron ADX allows a UDP connection to remain unused before closing the connection. The default is 5 minutes. To change this parameter, see “Configuring UDP Age”.
The maximum number of TCP SYN connections per second the ServerIron ADX is allowed to send to the real server. The default is 65535 connections.
The total number of TCP connections the ServerIron ADX is currently managing.
The number of client requests for a TCP port that the ServerIron ADX could not fulfill because the server was busy or down, or the port was not configured on the server.
Disabled – The ServerIron ADX does not send ICMP “Destination Unreachable” messages to a client that requests an HTTP port that is on a busy or down server or that is not configured on the server. This is the default.
Enabled – The ServerIron ADX does send ICMP “Destination Unreachable” messages to clients when the requested HTTP port is not available or not configured.
Displaying Real Server Configuration Statistics
To display configuration information and statistics for the real servers configured on the ServerIron ADX, enter the following command:
 
information for remaining real servers omitted for brevity...
Syntax: show server real
This display shows the following information.
 
Table 2.15: Real Server Information  
The name of the real server. This is the name you assigned to the server when you configured it on the ServerIron ADX.
If you configured a host range of VIPs on the server, the number following the IP address (after the colon) is the number of hosts on the server. In the example shown above, the VIP address is 209.157.23.60 and the address has been configured with a host range of four hosts. For more information, see “Web Hosting with Unlimited Virtual IP Addresses”.
The state of the real server, based on Layer 3 health checks. The state can be one of the following states, also listed next to "Server State" at the top of the show server real display:
1 – Enabled
2 – Failed
3 – Test
4 – Suspect
5 – Graceful shutdown
6 – Active
Note: The value in this field is based on the results of Layer 3 health checks, if enabled. The real server state can also be seen in the State column in the show server session display. To display the server state based on Layer 3 health checks, see the State field in the show server session display.
The maximum number of client connections that the ServerIron ADX will manage for the server. A connection consists of two sessions, the client-to-server session and the server-to-client session.
By default, the ServerIron ADX allows up to 500,000 connections (one million sessions) on a server.
The configured and operational states of the source NAT feature. The two states are separated by a colon ( : ). The configured state is shown first, followed by the operational state. Each state can have one of the following values:
0 – Disabled
1 – Enabled
The configured and operational states of the destination NAT feature. The two states are separated by a colon ( : ). The configured state is shown first, followed by the operational state. Each state can have one of the following values:
0 – Disabled
1 – Enabled
Indicates whether the server is configured on the ServerIron ADX as a remote server or a local server. The ServerIron ADX uses remote servers as failovers if all the local servers are down. This field can have one of the following values:
No – The server is not a remote server.
Yes – The server is a remote server.
Note: For DNS, HTTP, and RADIUS ports, the server-specific health check information for the port is listed under the port’s statistics. For information about the health check parameters, see “Changing HTTP Keepalive Method, Value, and Status Codes”.
dns – the well-known name for port 53
ftp – the well-known name for port 21. (ports 20 and 21 both are FTP ports but on the ServerIron ADX, the name “ftp” corresponds to port 21.)
http – the well-known name for port 80
imap4 – the well-known name for port 143
ldap – the well-known name for port 389
nntp – the well-known name for port 119
ntp – the well-known name for port 123
pop2 – the well-known name for port 109
pop3 – the well-known name for port 110
radius – the well-known name for udp port 1812
smtp – the well-known name for port 25
snmp – the well-known name for port 161
ssl – the well-known name for port 443
telnet – the well-known name for port 23
tftp – the well-known name for port 69
<number> – the port number, if the port is not one of those listed above
Note: If the state is unbnd, you have not bound the port to a virtual server port.
The master port state. This field applies only to track ports and to ports to which you have bound other TCP/UDP ports in many-to-one configurations.
For track ports, the state of the master port. When a port is configured to track a master port, the ServerIron ADX sends a client’s request for the tracking port to the same real server as the master port. See “Configuring a Track Port Group” and “TCP/UDP Application Groups”. In the example show real server output shown above, assume that port 500 is tracked by port 600. If port 500’s state changes, port 600’s state also changes to match.
For many-to-one TCP/UDP port binding, the state of the port that is translated in the port binding between the real server and the virtual server. The ports that are not translated follow the state of the port that is translated. See “Many-To-One TCP/UDP Port Binding”. In the example show real server output shown above, assume that port 70 is untranslated and follows the state of port http. If port http’s state changes, port 70’s state also changes to match.
1 – Enabled
2 – Failed
3 – Test
4 – Suspect
5 – Graceful shutdown
6 – Active
The number of client connections currently on the server. A connection consists of two sessions, the client-to-server session and the server-to-client session.
The number of client connections on the server since the ServerIron ADX was last booted. A connection consists of two sessions, the client-to-server session and the server-to-client session.
The number of packets the ServerIron ADX has received from the server.
The number of packets the ServerIron ADX has sent to the server.
The number of octets (bytes) the ServerIron ADX has received from the server.
The number of octets (bytes) the ServerIron ADX has sent to the server.
The number of times the ServerIron ADX has reassigned the connection to another server in the rotation because the server that is in use has not responded to two contiguous TCP SYNs from the client. When this occurs, the ServerIron ADX directs the client to another server upon receiving the third SYN from the client.
Note: Windows 98 sends two TCP SYNs for each connection attempt.
Note: This statistic does not apply to SwitchBack (Direct Server Return).
Displaying Virtual Servers Configuration Statistics
To display configuration information and statistics for the virtual servers configured on the ServerIron ADX, enter the following command:
Syntax: show server virtual-name-or-ip
This display shows the following information.
 
The name of the virtual server. This is the name you assigned to the server when you configured it on the ServerIron ADX.
If you configured a host range of VIPs on the server, the number following the IP address (after the colon) is the number of hosts on the server. In the example above, the VIP has a host range of 4 addresses.
The load balancing predictor the ServerIron ADX uses to balance traffic among the real servers bound to this virtual server. The predictor can be one of the following:
round-robin
You can assign these metrics on a global basis and an individual virtual server basis.
To change the predictor (globally or locally), see “Changing the Load-Balancing Predictor Method”.
The number of client connections on the server since the ServerIron ADX was last booted or restarted. A connection consists of two sessions, the client-to-server session and the server-to-client session.
The state of the HTTP redirect feature. This feature enables the ServerIron ADX to send an HTTP redirect message to the client if all the real servers are down and the ServerIron ADX is therefore sending client requests to a remote server.
The HTTP redirect message instructs the client to redirect its HTTP connection directly to the remote server, bypassing the ServerIron ADX.
group – The Symmetric SLB group number.
state – State 3 means the VIP is inactive. State 5 means the VIP is active.
priority – The Symmetric SLB priority configured on the ServerIron ADX.
keep – The number of times an SSLB backup has failed to communicate with the active ServerIron ADX. By default, the counter is incremented by 1 every 400 milliseconds the backup ServerIron ADX is late responding to the active ServerIron ADX’s keepalive message. The counter is reset to 0 each time the backup ServerIron ADX replies to a keepalive message. If the counter goes higher than the maximum number allowed (20 by default, thus 8 seconds), the standby ServerIron ADX takes over as the new active ServerIron ADX. Normally, this field almost always contains 0.

Note: This field is applicable only on the active ServerIron ADX.
dyn priority/factor – The current dynamically set priority and the decrement value. In this example, an application has failed a health check, so the dynamic priority is 20 instead of 30. The decrement value is 10. If the priority and dyn priority values match, then all the VIP’s applications that are configured for SSLB are responding to their health checks.
Activates – The number of times this ServerIron ADX has become the active ServerIron ADX.
Inactive – The number of times this ServerIron ADX has changed from being the active ServerIron ADX.
Best-standby-mac – The MAC address of the backup ServerIron ADX with the second-highest priority. This ServerIron ADX will become the active ServerIron ADX if a failover occurs.
dns – the well-known name for port 53
ftp – the well-known name for port 21. (ports 20 and 21 both are FTP ports but on the ServerIron ADX, the name “ftp” corresponds to port 21.)
http – the well-known name for port 80
imap4 – the well-known name for port 143
ldap – the well-known name for port 389
nntp – the well-known name for port 119
ntp – the well-known name for port 123
pop2 – the well-known name for port 109
pop3 – the well-known name for port 110
radius – the well-known name for udp port 1812
radiuso – UDP port 1645, which is used in some older RADIUS implementations instead of port 1812
smtp – the well-known name for port 25
snmp – the well-known name for port 161
ssl – the well-known name for port 443
telnet – the well-known name for port 23
tftp – the well-known name for port 69
<number> – the port number, if the port is not one of those listed above
Note: If the status is unbnd, you have not bound the port to a real server port.
Whether the port is “sticky”. When a port is sticky, the ServerIron ADX uses the same real server for multiple requests from the same client for the port. For non-sticky ports, the ServerIron ADX load balances the requests and thus does not necessarily send them all to the same real server.
Whether the port is configured for concurrent connections. A port configured to allow concurrent connections can have more than connection open to the same client at the same time.
The number of client connections currently on the server. A connection consists of two sessions, the client-to-server session and the server-to-client session.
The number of client connections on the server since the ServerIron ADX was booted. A connection consists of two sessions, the client-to-server session and the server-to-client session.
Displaying Information about Virtual Server’s Bound Ports
The show server virtual-name-or-ip command has an option that displays detailed information for the server’s bound application ports.
The additional information is shown in bold type.
Syntax: show server virtual-name-or-ip [<virtual-server-name> [<tcp/udp-port>]]
This display shows the following information for bound ports.
For information about these states, see the "Application Port States" section in the "Configuring Port and Health Check Parameters" chapter of the ServerIron ADX.
Note: This information is the same as the application information displayed by the show server real command.
The master port state. This field applies only to track ports and to ports to which you have bound other TCP/UDP ports in many-to-one configurations.
For many-to-one TCP/UDP port binding, the state of the port that is translated in the port binding between the real server and the virtual server.
1 – Enabled
2 – Failed
3 – Test
4 – Suspect
5 – Graceful shutdown
6 – Active
The number of client connections currently on the server. A connection consists of two sessions, the client-to-server session and the server-to-client session.
The number of client connections on the server since the ServerIron ADX was last booted. A connection consists of two sessions, the client-to-server session and the server-to-client session.
The number of packets the ServerIron ADX has received from the server.
The number of packets the ServerIron ADX has sent to the server.
The number of octets (bytes) the ServerIron ADX has received from the server.
The number of octets (bytes) the ServerIron ADX has sent to the server.
The number of times the ServerIron ADX has reassigned the connection to another server in the rotation because the server that is in use has not responded to two contiguous TCP SYNs from the client. When this occurs, the ServerIron ADX directs the client to another server upon receiving the third SYN from the client.
Note: Windows 98 sends two TCP SYNs for each connection attempt.
Note: This statistic does not apply to SwitchBack (Direct Server Return).
Displaying a List of Failed Servers
Use show server failed to display all servers that are not in Active or Disabled state. Only servers in the failed state are included in the display.
Example:
SLB-ServerIron# show server failed
Real servers in Failed state:
Total failed servers: 3
Name: MyServer01 IP:192.168.160.91 State: Enabled
Name: MyServer02 IP:192.168.160.92 State: Enabled
Name: MyServer03 IP:192.168.160.93 State: Enabled
Syntax: show server failed
Displaying a List of Failed Ports
Use show server port failed to display all server ports that are not in Active or Disabled state. It also shows the servers to which the ports belong.
Example:
SLB-ServerIron# show server port failed
Real ports in Failed state:
Total failed servers:3 Total failed ports:7
Name: MyServer01 IP:192.168.160.91 State: Enabled
Port http: Failed
Port 8081: Failed
Port ftp: Failed
Name: MyServer02 IP:192.168.160.92 State: Enabled
Port 8082: Failed
Port http: Failed
Name: MyServer03 IP:192.168.160.93 State: Enabled
Port 8083: Failed
Port http: Failed
Syntax: show server port failed
Displaying Port-Binding Information
To display port-binding information, enter the following command:
http -------> s43: 209.157.23.43, http
s60: 209.157.23.60, 8080
ftp -------> s43: 209.157.23.43, ftp
s60: 209.157.23.60, ftp
70 -------> s43: 209.157.23.43, 70
s60: 209.157.23.60, 70
Virtual Server Name: v105, IP: 209.157.23.105
telnet -------> s60: 209.157.23.60, 300
ftp -------> s60: 209.157.23.60, 200
http -------> s60: 209.157.23.60, 100
dns -------> s60: 209.157.23.60, 400
tftp -------> s60: 209.157.23.60, 500
Syntax: show server bind
The display lists the port bindings for each virtual server configured on the ServerIron ADX. The first row of information for each virtual server lists the virtual server name and VIP. The following rows list the TCP/UDP ports configured on the virtual server and the real servers and port names or numbers to which each port is bound.
In the example shown above, two virtual servers are configured on the ServerIron ADX, v100 and v105. The first set of rows in the example output shown above is for virtual server v100, with VIP 209.157.23.100.
The rows below the first row list the real servers and ports to which the virtual server’s ports are bound. The rows are grouped by port type. The first two rows after the first row in the example above list the port bindings for the virtual server’s HTTP port. In this case, the virtual server is bound to an HTTP port on two real servers, s43 and s60. The port name or number on the real server is listed following the real server’s IP address. In this example, the HTTP port to which v100 is bound on s43 is "http", the well-known name for the port. The virtual server’s HTTP port is bound to port 8080 on real server s60.
You can also display port-binding information by entering the show server session command:
Syntax: show server session
The number of sessions that are still available for use. By default, the ServerIron ADX is configured to allow the maximum number of sessions it can support. However, if you need to decrease the number of sessions supported, see “Configuring the Maximum Number of Active Sessions”.
The number of connections initiated by servers. Generally, this value is 0 unless the client is using FTP or another application that causes the server to initiate connections.
The number of unacknowledged TCP SYN-ACKs on all the real servers combined. When a server reaches the maximum number of unacknowledged TCP SYN-ACKs allowed by the ServerIron ADX (the reassign threshold), the ServerIron ADX marks that server FAILED and removes it from the load balancing rotation.
The TCP SYN-ACK counter increments only when acknowledgments are not received. Each time an expected TCP SYN-ACK is received from a real server, the counter is cleared for that server, thus reducing the total count.
Note: This statistic does not apply to SwitchBack (Direct Server Return).
If the fast-age threshold is configured, the total number of sessions that were aged out because the number of free sessions dropped below the fast-age threshold, as well as the number of these sessions that were aged out in the last 60 seconds.
If the random threshold is configured, the total number of sessions that were aged out at random because the number of free sessions dropped below the random threshold, as well as the number of sessions that were aged out randomly in the last 60 seconds.
See “Configuring Fast Session Aging” for more information on the fast-age and random thresholds.
Note: The value in this field is based on the results of Layer 3 health checks. To display the server state based on Layer 4 or Layer 7 health checks, see the State field in the show server real display. (See “Displaying Real Server Configuration Statistics”.)
The number of client connections currently on the server. A connection consists of two sessions, the client-to-server session and the server-to-client session.
The number of client connections on the server since the ServerIron ADX was last booted or restarted. A connection consists of two sessions, the client-to-server session and the server-to-client session.
The highest number of simultaneous connections the ServerIron ADX has managed since it was last booted or restarted.
Displaying Packet Traffic Statistics
In theory, each BP sends its counters to the MP. The MP then aggregates all the counters from each BP and synthesizes them into tables. However in reality, not all the BP counters are implemented yet on the MP.
The MP correctly shows most of the commonly used counters. For some counters of show server traffic and show server debug, you should rconsole into BPs and issue show commands from there.
Use clear server traffic to clear traffic statistics for real and virtual servers.
Syntax: show server traffic
 
Number of packets dropped by the ServerIron ADX. This statistic includes the following:
TCP Resets – Resets sent by the ServerIron ADX
Forward Resets – Resets from the client
Unsuccessful requests – Requests sent to a TCP or UDP port that is not bound to the request’s destination VIP
Number of TCP and UDP sessions that the ServerIron ADX closed because the aged out. A session ages out when the age timer configured on the ServerIron ADX expires. For more information, see “Configuring TCP Age” and “Configuring UDP Age”.
Number of client-to-server packets the ServerIron ADX has dropped. If this statistic is high, there might not be a session entry. This can occur under the following circumstances:
Number of server-to-client packets the ServerIron ADX has dropped. If this statistic is high, there might not be a session entry. This can occur for the same reasons as listed for the Fw_drops field.
Number of FINs or RSTs passing through (forward and reverse) a non-optimized path (no FPGA processing) inside the ServerIron ADX. All traffic is optimized (FPGA processed) by default except FTP control, streaming protocol control, and DNS traffic.
When the ServerIron ADX receives a SYN packet for a session that is already listed in the session table (show server sessions), the ServerIron ADX has received a Duplicate SYN. The counter is then incremented by 1.
Total (ttl) number of resets received in both the forward and reverse direction. This counter applies to both optimized (FPGA assisted) and non optimized traffic paths.
Number of packets the ServerIron ADX dropped because they were sent by a client to a VIP port that is bound to a real server port that is currently disabled.
Number of packets dropped by the ServerIron ADX because the TCP SYN limit on the real servers had been reached. The TCP SYN limit is a configurable parameter that allows you to protect servers against TCP SYN attacks by limiting the number of TCP SYN requests the ServerIron ADX can send to the server each second.
Number of TCP SYN packets the ServerIron ADX dropped because they matched a stale session entry.
A deny filter configured on the ServerIron ADX matched the packet, causing the ServerIron ADX to drop the packet.
Rate of TCP traffic per second. This counter includes all TCP traffic, including TCP SYN DoS attacks. This field displays in releases 09.0.00S and later.
Rate of TCP Dos attacks per second. This rate is delayed by 1 to 2 minutes. This field displays in releases 09.0.00S and later.
Peak rate of TCP DoS attacks (per second) encountered on this device. This rate is delayed by 1 to 2 minutes. This field displays in releases 09.0.00S and later.

Server Load Balancing > DSR

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