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.
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.
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:
Defining a Virtual Server (VIP)
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.
ServerIronADX(config-rs-Web4)# server virtual-name-or-ip www.altergo.com 207.95.55.1
Syntax: [no] server virtual-name-or-ip [<name>] <ip-address>
Syntax: [no] port <tcp/udp-port>
ServerIronADX(config)# server virtual-name-or-ip www.altergo.com 207.95.55.1
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
Syntax: [no] bind <tcp/udp-port-number> <real-server-name> <tcp/udp-port-number>
|
1.
|
Disable the real server ports that are associated with this virtual server port.
|
If there are existing connections or the port is still in AWU or
AWM state, then clear the server sessions using following command.
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: Stateful and stateless SLB traffic is optimized by default.
|
•
|
The show server stateless command does not display hits.
|
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.
Syntax: [no] server fast-stateless
Changing the Load-Balancing Predictor Method
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:
|
2.
|
Configure the weighted predictor either globally or for a virtual server.
|
Assigning Weights to the Real Servers
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
|
•
|
<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
|
|
•
|
<port>— snmp-request host UDP port (Default: port 161)
|
|
•
|
<num>—Decimal value in seconds (Default: 3 sec)
|
ServerIronADX(config-vs-vs1)# predictor dynamic-weighted reverse oid 1 max 50
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).
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:
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.
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.
Syntax: [no] server syn-limit <1 – 65535>
|
•
|
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.
|
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”.
To globally configure the warning and shutdown thresholds for all real servers, enter a command such as the following:
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:
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.
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:
Syntax: [no] server icmp-message
To configure the ServerIron ADX to send a TCP RST to a client, enter the following command:
Syntax: [no] server reset-message
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:
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.
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.
To globally disable the TCP RST message from being sent, enter the following command:
Syntax: [no] server no-reset-for-established-session
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.
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.
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.
|
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.
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.
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.
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.
You can also use the
server source-ip command under a real server to designate the source IP address for Source NAT.
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.
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.
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: 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.
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.
ServerIron(config)# server vip-group 1
ServerIron(config-vip-group-[1])# source-nat-ip 20.10.10.3
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.
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
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.
ServerIron(config)# server source-nat 192.168.2.10 10.10.6.1
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.
ServerIron(config)# server source-nat-ip 10.10.10.5/24 0.0.0.0 port-range 2
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.
Copyright © 2009 Brocade Communications Systems, Inc.
