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

Table of Contents Previous Next Print


Server Load Balancing > Traffic Distribution Among BPs

Traffic Distribution Among BPs
The ServerIron ADX uses a hash algorithm to distribute traffic among Barrel Processors (BP). There is the default algorithm and 3 optional algorithms that operate on the Source/Destination IP addresses to balance traffic among BPs.
The default hash algorithm is “hash-crc32l”. In most situations, this setting will provide the most effective distribution of traffic across BPs. If you find however that traffic is not being efficiently distributed across the BPs on your ServerIron switch, you can try one of the other options.
To change the server hash algorithm from the default “hash-crc32l” to “hash-crc32u” use the following command:
ServerIronADX(config)# server hash-crc32u
Syntax: server [ hash-crc32l | hash-crc32u | hash-xori | hash-xoru ]
hash-crc32l: This algorithm performs CRC on the 32-bits of Source IP in the forward direction and the 32-bits of Destination IP in the reverse direction. The lower 5 bits of the computed result are used to distribute traffic among BPs. This is the default setting.
hash-crc32u: This algorithm performs CRC on the 32-bits of Source IP in the forward direction and the 32-bits of Destination IP in the reverse direction. The upper 5 bits of the computed result are used to distribute traffic among BPs.
hash-xorl: This algorithm performs XOR on the 32-bits of Source IP in the forward direction and the 32-bits of Destination IP in the reverse direction. The lower 5 bits of the computed result are used to distribute traffic among BPs.
hash-xoru: This algorithm performs XOR on the 32-bits of Source IP in the forward direction and the 32-bits of Destination IP in the reverse direction. The upper 5 bits of the computed result are used to distribute traffic among BPs.
Including the Server Client Port In Hash Calculations
When there are a small number of client IP addresses that connect to a ServerIron ADX switch, the traffic distribution of IP addresses to the BPs may not be optimal. Where this is the case, it can be useful to include the client source port in the hash calculations. This is achieved by configuring the following command:
ServerIronADX(config)# server source-port-hash
Syntax: [no] server source-port-hash
NOTE: This command can be configured with any of the hash algorithms configured using the server hash-xxx command described previously. This command cannot be used for protocols that involve dynamic ports such as ftp and rtsp and with sticky features.
Defining a Virtual Server (VIP)
After you define the actual Web server’s physical addresses (real server), you then need to configure the external Web server address on the switch. The external Web server is the virtual server.
It is the IP address or server name to which client browsers send requests. Add the TCP or UDP application ports the ServerIron ADX will load balance. These should be the same application ports you specified for the real servers.
To define the virtual name and address that is the access point for the company's Web site and the supported service, enter commands such as the following:
ServerIronADX(config-rs-Web4)# server virtual-name-or-ip www.altergo.com 207.95.55.1
ServerIronADX(config-vs-www.alterego.com)# port http
 
Syntax: [no] server virtual-name-or-ip [<name>] <ip-address>
Syntax: [no] port <tcp/udp-port>
After you have defined the virtual server, you can add configuration statements or delete the server by referring to the server’s IP address or name, by entering commands such as the following:
ServerIronADX(config)# server virtual-name-or-ip www.altergo.com 207.95.55.1
ServerIronADX(config-vs-www.alterego.com)# port http
ServerIronADX(config-vs-www.alterego.com)# exit
ServerIronADX(config)# server virtual-name-or-ip 207.95.55.1
ServerIronADX(config-vs-www.alterego.com)# exit
ServerIronADX(config)# server virtual-name-or-ip www.altergo.com
ServerIronADX(config-vs-www.alterego.com)# exit
ServerIronADX(config)# no server virtual-name-or-ip 207.95.55.1
Binding Virtual and Real Servers
After you define the real servers, virtual servers, and TCP/UDP ports, you need to bind the real and virtual servers together. The bindings are based on the TCP and UDP application ports you are load balancing.
To bind the four Web servers shown in Figure 2.9 to the virtual server address, enter the following commands:
ServerIronADX(config-rs-Web4)# server virtual-name-or-ip www.altergo.com
ServerIronADX(config-vs-www.alterego.com)# bind http Web1 http
ServerIronADX(config-vs-www.alterego.com)# bind http Web2 http
ServerIronADX(config-vs-www.alterego.com)# bind http Web3 http
ServerIronADX(config-vs-www.alterego.com)# bind http Web4 http
 
Syntax: [no] bind <tcp/udp-port-number> <real-server-name> <tcp/udp-port-number>
NOTE: For clarity, the bindings in the example are shown as four separate entries. You can enter all the binding information as one command: bind http Web1 http Web2 http Web3 http Web4 http
Deleting a VIP
It is critical that you follow the steps below prior to deleting a VIP that is in production or is handling live traffic:
1.
Disable the real server ports that are associated with this virtual server port.
ServerIronADXServerIronADXServerIronADX
Syntax: [no] server real <real-server-name>
Syntax: [no] port <port> disable
2.
Syntax: ServerIronADXshow server real <real-server-name>
3.
ServerIronADXServerIronADXServerIronADX
Syntax: no bind <virtual-port> <real-server-name> <real-server-port>
4.
Syntax: show server bind
If the real server is not unbound properly, then check the connection count under the BP console and try clearing the server sessions.
ServerIronADX# rconsole 1 1
ServerIronADX1/1# show server real rs1
ServerIronADX1/1#rconsole-exit
ServerIronADX# rconsole 1 2
ServerIronADX1/2# show server real rs1
ServerIronADX1/1#rconsole-exit
ServerIronADX# rconsole 1 3
ServerIronADX1/3# show server real rs1
ServerIronADX1/1# rconsole-exit
Syntax: rconsole <slot#> <BP#>
Syntax: show server real <real-server-name>
Syntax: rconsole-exit
If there are existing connections or the port is still in AWU or AWM state, then clear the server sessions using following command.
Syntax: clear server all-session <real-server-name> <real-port>
5.
ServerIronADX
Syntax: no server virtual <virtual-server-name>
6.
ServerIronADX
Syntax: no server real <real-server-name>
If you any current connection or current session cannot be disabled and the port is in "AWU" or "AWM", then issue a clear server all-session <real server name> <port> command.
Global Settings for SLB
Many global parameters have default settings. In most cases, you do not need to modify these parameters. The following sections describe the parameters, their possible values, and how to configure them.
NOTE: To change the maximum number of sessions, TCP age, UDP age, or reassign threshold, see “Health Checks”.
Fast-Path SLB Processing
You can enable the ServerIron ADX to use fast-path processing for stateful or stateless SLB:
Stateful SLB is the standard form of SLB that uses session table entries to track session information. All traffic for stateful SLB takes an optimized processing path.
Stateless SLB is a form of SLB that does not use session table entries. All packets that go through stateless ports take an optimized processing path.
When you enable fast-path processing, the ServerIron ADX does not process every TCP or UDP packet in a given session in detail. Instead, the ServerIron ADX uses information gathered during setup of the session to forward packets in the session.
NOTE: SLB optimization is useful if simple SLB (stateful or stateless) is the primary or sole application on the device. If you use the ServerIron ADX for other features such as GSLB or FWLB, SLB optimization is not useful.
NOTE: Stateful and stateless SLB traffic is optimized by default.
Configuration Considerations
Source NAT (source-nat command) is not supported.
Host ranges (host-range command) are not supported.
The show server stateless command does not display hits.
Many-to-one TCP/UDP port binding (no port <tcp/udp-port> translate command) is not supported.
NOTE: Traffic for an SLB configuration that does not meet these criteria is still forwarded using normal processing, but fast-path processing is not used.
Enabling Fast-Path Processing for Stateless SLB
When you enable fast-path processing, the ServerIron ADX does not process every TCP or UDP packet in a given session in detail. Instead, the ServerIron ADX uses information gathered during setup of the session to forward packets in the session. All packets that go through stateless ports take an optimized processing path.
SLB optimization is useful if simple SLB is the primary or sole application on the device. If you use the ServerIron ADX for other features such as GSLB or FWLB, SLB optimization is not useful. Fast-path processing applies only to some configurations.
To enable fast-path processing for stateless SLB, enter the following command:
ServerIronADX(config)# server fast-stateless
Syntax: [no] server fast-stateless
Changing the Load-Balancing Predictor Method
The Load-Balancing Predictor Method can be configured either globally or per-Virtual Server as described in the following.
To globally change the load-balancing method used by the ServerIron ADX, enter the following command:
ServerIron(config)# server predictor round-robin
 
To change the load-balancing method used by the ServerIron ADX for Virtual Server “v1”, enter the following commands:
ServerIron(config)# server virtual-name-or-ip v1
ServerIron(config-vs-v1)# server enhanced-weighted
 
Syntax: [no] server predictor least-conn | round-robin | weighted-round-robin | weighted | enhanced-weighted | dynamic-weighted
Selecting the least-conn parameter configures the Least Connections load-balancing method. This method is described in “Least Connections”.
Selecting the round-robin parameter configures the Round Robin load-balancing method. This method is described in “Round Robin”.
Selecting the weighted-round-robin parameter configures the Weighted Round Robin load-balancing method. This method is described in “Weighted Round Robin”.
Selecting the weighted parameter configures the Weighted load-balancing method. This method is described in “Weighted and Enhanced Weighted”.
Selecting the enhanced-weighted parameter configures the Weighted load-balancing method. This method is described in “Weighted and Enhanced Weighted”.
Selecting the dynamic-weighted parameter configures the Dynamic Weighted load-balancing method. This method can be configured as either direct or reverse as described in “Dynamic Weighted Predictor”. Details about configuring the Dynamic Weighted load-balancing method as direct or reverse are described in “Configuring Dynamic Weighted Predictor”.
If you enable any of the weighted methods, you must configure both the virtual and real servers involved. Each real server is assigned a weight from 0 – 65000. This configuration is described in “Configuring a Weighted Predictor”.
When multiple ports of a given real server are bound to the same VIP port then the default least-connection predictor may not produce even connection distribution among these ports. Use of round-robin predictor in these cases.
For overview information, see “Load-Balancing Predictor”.
Configuring a Weighted Predictor
Several of the Load-Balancing Predictor Methods used on the ServerIron ADX require that weights be assigned to the real servers. The ServerIron ADX uses a formula based on each real server’s assigned weight to calculate the server load for the real servers, then selects the real server as determined by the predictor that is configured on the ServerIron ADX.
To configure a Load-Balancing Predictor Method, perform the following tasks:
1.
2.
Configure the weighted predictor either globally or for a virtual server.
NOTE: if a real server port is binded under a VIP but a weight is not configured under the real server, the ServerIron ADX will assume the the weight for that real server is 1.
Assigning Weights to the Real Servers
When configuring Weights on a Real Server, consider the following:
The Weighted Round Robin predictor has VIP port-level granularity. This is reflected in the output from the show server session and show server conn commands since they display output for the Weighted Round Robin predictor at a per vip-port level.
To configure weights for three real servers, enter commands such as the following:
ServerIronADX(config)# server real rsA
ServerIronADX(config-rs-rsA)# weight 1
ServerIronADX(config-rs-rsA)# exit
ServerIronADX(config)# server real rsB
ServerIronADX(config-rs-rsB)# weight 2
ServerIronADX(config-rs-rsB)# exit
ServerIronADX(config)# server real rsC
ServerIronADX(config-rs-rsC)# weight 3
ServerIronADX(config-rs-rsC)# exit
 
Syntax: [no] weight <weight-value>
The weight command assigns a performance weight to each server or firewall. Servers or firewalls with a larger or higher weight assigned receive a larger percentage of connections.
The <weight-value > parameter specifies the real server’s weight relative to other real servers in terms of the number of connections on the server. More precisely, this weight is based on the number of session table entries the ServerIron ADX has for TCP or UDP sessions with the real server. You can specify a value from 0 – 65000. The default is 1.
Configuring Dynamic Weighted Predictor
This section contains the following sections:
Configure Real Server with SNMP Query Requirements
A list of the SNMP Object ID (OID) can be configured under a real server. An OID represents the weight of the real server, for example server CPU utilization or its memory usage.
To configure SNMP query requirements use the following command:
ServerIronADX(config-rs-rs1)# snmp-request 1 1.3.6.1.2.1.25.3.3.1.2.1
Syntax: snmp-request oid <ID> <string>
<ID>—snmp-request entry identification, decimal value 1 - 256
<string>—ASCII string ASN.1 format - 1.3.6.1.2.1.25.3.3.1.2.1
SNMP versions 1 and 2 use community strings to restrict SNMP access. The administrator must configure an SNMP community string to match with those configured in all the real servers.
ServerIronADX(config-rs-rs1)#snmp-request community public
Syntax: snmp-request community public <port>
<port>— snmp-request host UDP port (Default: port 161)
You can configure the frequency of the periodic SNMP queries using the following command:
ServerIronADX(config)# server snmp-poll 5
Syntax: server snmp-poll <num>
<num>—Decimal value in seconds (Default: 3 sec)
Configuration Example
ServerIron(config)#server snmp-poll 5
ServerIron(config)#server real rs1 10.1.1.1
snmp-request community public port 161
snmp-request oid 1 1.3.6.1.2.1.25.3.3.1.2.1
snmp-request oid 2 1.3.6.1.2.1.1.3.0
port http
port http keepalive
port http url "HEAD /"
Configure a Virtual Server with Dynamic Weighted Predictor
Select a dynamic-weighted direct or reverse predictor and an SNMP OID.
Dynamic-Weighted Direct
To configure a dynamic-weighted reverse predictor, use the following comand:
ServerIronADX(config-vs-vs1)# predictor dynamic-weighted direct oid 1
Syntax: predictor dynamic-weighted {direct oid <ID> }
Configuration Example
server virtual-name-or-ip vs1 10.1.1.151
predictor dynamic-weighted direct oid 1
port http
bind http rs1 http rs2 http rs3 http
Dynamic-Weighted Reverse
To configure a dynamic-weighted reverse predictor, use the following comand:
ServerIronADX(config-vs-vs1)# predictor dynamic-weighted reverse oid 1 max 50
Syntax: predictor dynamic-weighted reverse oid <ID> [max <value>]
DECIMAL Max value - reverse weight = direct weight
RTSP Server Load Balancing
The ServerIron ADX natively understands protocol RTSP and provides load balancing for it. A ServerIron ADX can also provide Layer 7 health checks for RTSP. Please refer to health check chapter for details on Layer 7 health checks for RTSP. (You may provide a reference link here if possible).
If RTSP is bound to an unknown port, then the following command would be required:
ServerIronADX(config)#server rtsp-for-unknown-port
Syntax: [no] server rstp-for-unknown-port
NOTE: The ServerIron ADX supports RTSP client port value of up to 9999. If client is using port number above 9999 then configure the client to use the lower port value.
Deletion of UDP Data Session along with TCP Control Session for RTSP
The ServerIron ADX tracks both control and data sessions for RSTP regardless of the underlying transport layer (TCP or UDP) used by these sessions. Hence, when the system deletes an RSTP control session (TCP based), it also deletes the respective data session (which may be UDP based). Use the command below to enable this functionality:
ServerIronADX(config)# server rtsp-delete-udp-with-tcp-sess
Syntax: [no] server rstp-delete-udp-with-tcp-sess
Identifying the Ports Attached to a Router
If the ServerIron ADX is attached to multiple routers or to a single router configured for VRRP, FSRP, or HSRP, you need to identify the ports on the ServerIron ADX that are attached to the router. Explicitly identifying the ports enables the ServerIron ADX or switch to handle Layer 4 traffic correctly.
To identify port 8 as a router port, enter the following command:
ServerIron(config)# server router-port 8
Syntax: [no] server router-ports <portnum>
To define multiple router ports on a switch, enter the port numbers, separated by blanks. You can enter up to eight router ports in a single command line. To enter more than 8 ports, enter the server router-port... command again with the additional ports.
Limiting the Maximum Number of TCP SYN Requests
You can limit the maximum number of TCP SYN requests per second per server. A TCP SYN request is a packet a client sends requesting a TCP connection to the server.
To limit the connections to a maximum of 3500 for all Web servers on the network shown in Figure 2.9, enter the following command:
ServerIron(config)# server syn-limit 3500
Syntax: [no] server syn-limit <1 – 65535>
The default value is 65535.
Configuring the Warning and Shutdown Thresholds
Response-time thresholds for real servers enable you to display warning messages when a server’s response is too slow and even to stop using the server. You can specify a warning threshold and a shutdown threshold:
Warning – If an application’s average response time is longer than the number of milliseconds of the warning threshold, the software generates a Syslog message and an SNMP trap.
Shutdown – If an application’s average response time is longer than the number of milliseconds of the shutdown threshold, the software generates a Syslog message and an SNMP trap and also shuts down the application port on the real server. Other application ports on the real server are not affected.
By default, a real server does not have a warning threshold or a shutdown threshold. For each threshold, you can specify a threshold value from 0 (disabled) – 65535 milliseconds (65 seconds).
You can configure one or both thresholds globally or on an individual real server basis. The thresholds configured on an individual real server override the globally configured thresholds. After bringing down the application port, the ServerIron ADX periodically attempts to reach the port and brings the port back up once the port responds. For information, see “Application Port States”.
NOTE: This feature requires the Layer 4 and Layer 7 health checks to enabled. If the health checks are not enabled, the ServerIron ADX does not apply the response thresholds you configure.
NOTE: This feature applies only to TCP ports.
Configuring Warning and Shutdown Thresholds for All Real Servers
To globally configure the warning and shutdown thresholds for all real servers, enter a command such as the following:
ServerIron(config)# server response-time 200 300
The command in this example configures the ServerIron ADX to generate a warning message for an application port if its average response time is longer than 200 milliseconds. The command also configures the ServerIron ADX to shut down a port if its average response time is longer than 300 milliseconds.
If you want the ServerIron ADX to generate a warning message but you do not want the ServerIron ADX to shut down an application port, configure the warning threshold but not the shutdown threshold, such as the following:
ServerIron(config)# server response-time 100
To set the shutdown threshold without also setting a warning threshold, enter 0 for the warning threshold, such as the following:
ServerIron(config)# server response-time 0 300
Syntax: [no] server response-time <warning-threshold> [<shutdown-threshold>]
The <warning-threshold> parameter specifies the average number of milliseconds, 0 – 65535 (65 seconds), within which an application port must respond to avoid a warning message. There is no default. If you specify 0, the warning threshold is disabled.
The <shutdown-threshold> parameter specifies the average number of milliseconds within which an application port must respond to avoid being shut down. You can specify from 0 – 65535 milliseconds (65 seconds). There is no default. If you specify 0, the shutdown threshold is disabled.
Configuring Warning and Shutdown Thresholds for an Individual Real Server
See “Setting Warning and Shutdown Thresholds for a Server”.
Viewing Threshold Messages in the Syslog
When an application port’s average response time exceeds the warning or shutdown threshold, the ServerIron ADX generates a Syslog message and an SNMP trap.
To display Syslog entries, enter the following command at any level of the CLI:
ServerIronADX# show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 5 overruns)
Buffer logging: level ACDMEINW, 50 messages logged
level code: A=alert C=critical D=debugging M=emergency E=error
I=informational N=notification W=warning
Log servers: IP 10.10.10.20, Port 514
 
Dynamic Log Buffer (50 entries):
00d00h13m06s:I:running-config was changed from console
00d00h08m35s:N:L4 server 10.10.10.20 r20 port 80 is up
00d00h08m34s:N:L4 server 10.10.10.20 r20 port 80 is down
00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded lower threshold
00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded
upper threshold; Bringing down the port...
 
ServerIron# show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 5 overruns)
Buffer logging: level ACDMEINW, 50 messages logged
level code: A=alert C=critical D=debugging M=emergency E=error
I=informational N=notification W=warning
Log servers: IP 10.10.10.20, Port 514
 
Dynamic Log Buffer (50 entries):
00d00h13m06s:I:running-config was changed from console
00d00h08m35s:N:L4 server 10.10.10.20 r20 port 80 is up
00d00h08m34s:N:L4 server 10.10.10.20 r20 port 80 is down
00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded lower threshold
00d00h08m34s:W:Port 80 on server r20: 10.10.10.20: Avg response time 27 exceeded
upper threshold; Bringing down the port...
 
The first message shown in bold type is a warning message. The last message shown in bold type is a shutdown message.
Syntax: show logging
Sending ICMP Port Unreachable or Destination Unreachable Messages
NOTE: ICMP messages are disabled by default.
By default, if the ServerIron ADX receives a client request for a specific VIP and UDP port, but the requested port is not bound to the requested VIP, the ServerIron ADX quietly drops the packet. For example, if a client sends a request to VIP 10.10.5.1 and UDP port 99, but configuration for VIP 10.10.5.1 on the ServerIron ADX does not include a binding for port 99, the ServerIron ADX drops the request without sending a message to the client.
You can configure the ServerIron ADX to send an ICMP Port Unreachable message instead of quietly dropping the packet.
Also by default, if a client requests an unavailable TCP/UDP port, the ServerIron ADX does not send an ICMP Destination Unreachable message to the client.
For HTTP traffic, you can configure the ServerIron ADX to send such a message to the client, if the requested port either is not configured on any of the real servers or is unavailable because all the servers configured with the requested port are busy or down.
To configure the ServerIron ADX to send ICMP Destination Unreachable messages to clients, or to send an ICMP Port Unreachable message when the device receives a request for a UDP port that is not bound to the requested VIP, enter the following command:
ServerIron(config)# server icmp-message
Syntax: [no] server icmp-message
Sending a TCP RST to a Client That Requests Unavailable Applications
If a client requests an unavailable application, the ServerIron ADX does one of the following:
Send a TCP RST (for TCP only) – the default action.
Generally, an application is unavailable if all the real servers that have the application are unavailable or the application is not configured on the VIP requested by the client.
To configure the ServerIron ADX to send a TCP RST to a client, enter the following command:
ServerIron(config)# server reset-message
Syntax: [no] server reset-message
NOTE: The server reset message overrides the ICMP Destination Unreachable message. If the configuration contains both, the ServerIron ADX sends a TCP RST instead of an ICMP message for TCP requests. For UDP requests, the device still sends ICMP messages. TCP RST does not apply to UDP.
For information on how to globally configure the ServerIron ADX to send an ICMP Destination Unreachable message to a client, see “Sending ICMP Port Unreachable or Destination Unreachable Messages”.
NOTE: The server no-reset-on-max-conn command overrides the server reset-message command. For more information, see “Disabling TCP RST Message on Maximum Connections”.
Sending a TCP RST When TCP Session Entry Ages Out
By default, the ServerIron ADX does not send a TCP RST to a client or server when its TCP session in the session table ages out.
You can enable the ServerIron ADX to send a TCP RST to a client or server when a TCP session entry in use by the client or server ages out. To do this, enter the following command:
ServerIron(config)# server tcp-age reset
Syntax: [no] server tcp-age reset [both | client | server]
This command only works if you are running L7 SLB.
The both option (Default) enables the device to send messages to clients and servers.
The client option enables the device to send messages only to clients.
The server option enables the device to send messages only to servers.
Disabling TCP RST Message When a Real Server Goes Down During an Open Session
By default, if a real server goes down during an open TCP session with a client, the ServerIron ADX sends a TCP RST message to the client to terminate the session normally. When the real server comes back up, clients can establish a new sessions with the server.
You can globally disable the TCP RST message from being sent under these circumstances. When you disable the TCP RST message, the client can resume the interrupted session when the real server comes back up.
NOTE: Disabling the TCP RST messages affects only the message sent to a client when a real server goes down during a client’s session with the server. TCP RST messages sent under other circumstances are not affected.
To globally disable the TCP RST message from being sent, enter the following command:
ServerIronADX(config)# server no-reset-for-established-session
Syntax: [no] server no-reset-for-established-session
By default, sending TCP RST messages is enabled.
Disabling TCP RST Message on Maximum Connections
When a client sends a TCP SYN to a VIP, the ServerIron ADX selects one of the real servers bound to the VIP for the client's connection. If the ServerIron ADX cannot select a real server (for example, if the server port is down, or the server port has reached its maximum connection limit), then by default the ServerIron ADX sends a TCP RST to the client.
You can configure the ServerIron ADX not to send a TCP reset when the maximum connections limit is reached. The client may then subsequently attempt to establish a connection, by which time a real server may have fewer connections that its maximum connections limit, and the ServerIron ADX would be able to select it.
To disable the TCP RST message sent when the maximum connections limit on the real servers is reached, enter the following command:
ServerIron(config)# server no-reset-on-max-conn
Syntax: [no] server no-reset-on-max-conn
NOTE: This command overrides the server reset-message command, which enables the ServerIron ADX to send TCP RST to clients that request unavailable applications. If the configuration contains both commands, the ServerIron ADX will not send a TCP RST to a connecting client if the maximum connections limit on the real servers has been reached.
Adding a Source IP Address
You can define source IP addresses on a ServerIron ADX system running switch code to place it in multi-netted environment. These source IP addresses could potentially be used as default gateways for real servers. You can also define source NAT IP addresses while using source NAT.
The additional IP addresses allow you to deploy the ServerIron ADX in multinetted environments, including the following examples:
The ServerIron ADX and real servers are on different sub-nets.
The remote access server (RAS) and ServerIron ADX are on different sub-nets.
The border access router (BAR) and ServerIron ADX are on different sub-nets.
See “Web Hosting with ServerIron ADX and Real Servers in Different Subnets” for an example of the type of configuration in which you need to use this feature.
NOTE: Depending on the configuration, you might also need to enable source NAT. See “Web Hosting with ServerIron ADX and Real Servers in Different Subnets”. See “Multinetting Using NAT” for general information about the NAT operations performed by the ServerIron ADX.
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 64,000 simultaneous connections to the real servers. If you configure 64 source IP addresses, the ServerIron ADX can support more simultaneous connections.
ServerIron(config)#server source-ip 192.168.1.5 255.255.255.0 192.168.1.1
 
Syntax: [no] server source-ip <ip-addr> <network-mask> <default-gateway>
The <default-gateway> parameter is required. By specifying "0.0.0.0" as a gateway, the system is going to use the ip default-gateway setting for the default gateway. The gateway function will not actually be disabled for the interface.
You can configure source IP addresses to enable the ServerIron ADX to communicate with routers and real servers in different subnets. For example, Figure 2.10 shows an example of a ServerIron ADX that uses both public and private source NAT addresses.
NOTE: You can define a total of 64 source-ip and source-nat-ip addresses on a ServerIron ADX running switch code. The source-ip command is not required on ServerIrons running router code.
Figure 2.10
ServerIron ADX configured with public and private source NAT addresses
The ServerIron ADX in this example is configured with three source IP addresses. Two of the addresses are in the subnets of the real servers and the third address is in the same subnet as the ServerIron ADX management address.
The software considers any address that is not within the following address ranges to be a public address. These address ranges are defined as private address ranges in RFC 1918.
10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255
You can also use the server source-ip command under a real server to designate the source IP address for Source NAT.
For example, to specify that traffic from remote real server R1 use 193.77.7.7 as its source IP address, enter the following commands:
ServerIron(config)# server remote R1 193.77.7.2
ServerIron(config-rs-R1)# source-ip 193.77.7.7
If the <ip-addr> parameter is not already configured as a source IP address on the ServerIron ADX (with the server source-ip command), an error message is displayed.
Enabling Source NAT Globally
Source NAT allows the ServerIron ADX to use a specific source IP address as the source for sending packets to real servers, which is useful for operating in a multinetted environment. You can enable source NAT globally or locally on individual real servers. If you enable source NAT globally, the feature applies to all real servers. If you enable the feature locally, the ServerIron ADX performs source NAT only for those real servers. Other locally-attached real servers, on which source NAT is not enabled, must be in the same subnet as the ServerIron ADX.
To enable source NAT globally, enter the following command:
ServerIron(config)# server source-nat
Syntax: [no] server source-nat-ip
On a ServerIron ADX running switch code, you must also configure a source IP address. These ServerIron ADXs use source NAT to translate the management IP address in the source field of the IP packet into the source IP address you configure. See “Multinetting Using NAT” and “Adding a Source IP Address”. See “Web Hosting with ServerIron ADX and Real Servers in Different Subnets” for an example of the type of configuration in which you need to use Source NAT. You can define a total of 64 source-ip and source-nat-ip addresses on ServerIrons running switch code.
The source-ip command is not required on ServerIrons running router code.
NOTE: in a system with a large number of BPs, the usable Source Nat ports are limited. The larger the number of BPs that a system has, the lesser number of Source ports avaliable for the BP. We suggest that you use the “Enabling Port Allocation feature when all 64 Source IPs are used up. See “Enabling Port Allocation Per Real Server for Source IP” and “Enabling Port Allocation Per Real Server for Source NAT IP” for details.
NOTE: When Source Nat is enabled for ftp traffic, the ServerIron ADX only supports one mode for an established connection. This means that a user cannot toggle between active and passive mode for an existing ftp connection that is Source NATed.
NOTE: For Router (R) code, the ServerIron ADX uses the Interface/VE address to do source NAT by default. No user action is needed. Optionally, you can define source NAT IP addresses if they are required. You can define total of 64 Interface/VE and source NAT IP addresses. Interface/VE addresses do not exist on Switch (S) code.
If you are configuring a pair of ServerIron ADXs for hot-standby (active-standby) and you want to use the same source IP address on each ServerIron ADX, use the server source-nat-ip command instead.
Configuring Shared Source NAT IP Addresses within a VIP Group
Use the source-nat-ip command to configure shared source NAT IP addresses within a VIP group for SSLB. In an SSLB configuration, the shared source NAT IP addresses track the VRRP state to determine the active ServerIron ADX for a given source NAT IP address.
To configure a shared source NAT IP address within a VIP group, enter commands such as the following:
ServerIron(config)# server vip-group 1
ServerIron(config-vip-group-[1])# source-nat-ip 20.10.10.3
Syntax: source-nat-ip <ip-addr>
The <ip-addr> parameter is the shared source NAT IP address.
Source NAT to Packets from Specified Source IP Addresses
By default, if you configure the ServerIron ADX to apply source NAT for a real server, it is applied to all traffic for the real server. You can configure the ServerIron ADX to apply source NAT for a real server to traffic from specified source IP addresses.
To do this, you create an ACL, then specify the ACL in the source NAT configuration of the real server. When a flow is sent to the VIP, if the ACL specifies a permit action for the flow’s source IP address, then source NAT is performed on traffic in the flow.
For example, the following commands create an ACL that permits traffic from network 192.168.0.0/16 and denies all other traffic:
ServerIron(config)# access-list 1 permit 192.168.0.0 255.255.0.0
ServerIron(config)# access-list 1 deny any
In comparison, the source-nat access-list <acl-id> command configures source NAT on a real server to be performed on traffic whose source IP address is permitted by ACL 1:
ServerIron(config)# server real r1 10.10.10.10
ServerIron(config-rs-r1)# source-nat access-list 1
Client Subnet Based Source NAT
The selection of source NAT IP addresses is based on configured client subnets. You can associate a client subnet with a particular source NAT, which is defined on the ServerIron ADX. You can also associate multiple client subnets with the same source NAT IP address, and the same client subnet to multiple source NAT IP addresses. (These association type allow the clients to be load-balanced to real servers belonging to different subnets, and the source NAT IP address selected should belong to the same subnet as the real server).
When a client belonging to a configured subnet makes a new connection request, the source NAT IP address list corresponding to that client’s subnet is retrieved. Out of this list, a source NAT IP address is selected that is in the same subnet as the selected real server. If the selected source NAT IP address runs out of source ports, the ServerIron tries to use the next available source NAT IP address for that client’s subnet. If it does not find one, it will use any source NAT IP address that belongs to the same subnet as the real server.
To configure this feature, enter the following command:
ServerIron(config)# server source-nat 192.168.2.10 10.10.6.1
Syntax: server source-nat <client-subnet> <source-ip>
Enter the IP address to which the client belongs for <client-subnet>
Enter the source NAT IP address of the subnet with which you want to associate the client’s subnet. The source NAT IP address you enter must be configured on the ServerIron.
Configuring a Shared Source IP Address for NAT
Use the server source-nat-ip command to divide the ports used for source NAT for a source IP address.
In a hot-standby (active-standby) SLB configuration, this command configures a shared source IP address for NAT. Enter the same command with the same source IP address on each of the ServerIron ADXs. The address is active only on one ServerIron ADX (the ServerIron ADX that is currently active) at a time.
NOTE: This command applies only to hot-standby (active-standby) configurations. If you are configuring a shared source IP address for use by the real servers as their default gateway, use the server source-standby-ip address instead. The gateway parameter is required.
To configure a shared source IP address, enter the command such as the following:
ServerIron(config)# server source-nat-ip 10.10.10.5/24 0.0.0.0 port-range 2
Syntax: [no] server source-nat-ip <ip-addr> <ip-mask> <default-gateway> port-range 1 | 2
The <default-gateway> parameter is required. If you do not want to specify a gateway, enter "0.0.0.0".
The port-range parameter specifies which port range this peer uses for source NAT for this source IP address.Specify 1 for the lower port range or 2 for the upper port range. The peer using the upper port range is the owner of the source IP address. After you enter this command, ownership of the source IP address is negotiated between the peers. There must be a Layer 2 connection between the two ServerIron ADXs.
Displaying Information about the Shared Source IP Address
To display information about the source IP address, enter the command such as the following:
Syntax: show server source-nat-ip <ip-addr>

Server Load Balancing > Traffic Distribution Among BPs

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