Disabling or Re-enabling an Application Port
You can globally disable a Layer 4 port on the ServerIron ADX. The port can be disabled for all real servers, all virtual servers or all real and virtual servers. After you disable a port globally, you can enable the port on individual real or virtual servers as necessary. By default, all real and virtual ports are enabled.
When the ServerIron ADX is booted, if the command to globally disable a real or virtual port exists in the startup-config file, the specified port is disabled at startup. When a real or virtual port is created, and the port has been disabled globally, the real or virtual port is disabled as well. You must enable the port explicitly.
By default, the ServerIron ADX sends a client’s request to the next available real server based on the load balancing method. This is true regardless of whether the client has already sent a request for the same application. If you want the ServerIron ADX to send all of a client’s requests for a given application to the same real server during a client’s session with the server, configure the application port to be sticky.
To configure a TCP/UDP application group, enter the following commands. These commands configure HTTP (port 80), Telnet (port 23), and TFTP (port 69) to be sticky. In addition, the Telnet and TFTP ports are configured to track the HTTP port.
The sticky function causes the ServerIron ADX to send all of a client’s requests for a given application to the same real server during the client’s session with the server. By default, the stickiness is based on the client's IP address. You can configure the ServerIron ADX to base the stickiness on the client’s subnet, rather than IP address. All requests originating from a specific subnet for a given application are sent to the same real server.
ServerIron(config)# server virtual-name-or-ip vs1 10.10.10.10
ServerIron(config-vs-vs1)# port http
ServerIron(config-vs-vs1)# port http client-subnet-sticky prefix-length 24
In this example, client requests from sub-net 192.168.9.x would go to the same real server. Sub-net sticky connections are aged out according to the sticky age setting, in the same way regular sticky connections are aged out.
The features port sticky and
port client-subnet-sticky cannot be configured together on the same port on the same virtual server.
The SSL port is configured as sticky by default, and the CLI will not allow you to configure port client-subnet-sticky on an SSL port of a virtual server. As a work around, you must first disable the sticky function before configuring
port ssl client-subnet-sticky on a virtual serverl
ServerIron(config)# server virtual-name-or-ip vs1 10.10.10.10
ServerIron(config-vs-vs1)# port ssl client-subnet-sticky prefix-length 24
Several applications require sticky age to be longer than the 60 minute global maximum that is configured using the server sticky-age command as described in
“Setting the Sticky Age”. This may occur where a client connects in the morning and requires connectivity throughput the day.
There are also situations where you may want to configure a different value per Virtual Server. The following command allows you to apply a multiplier value to the global sticky-age value for a specific Virtual Server:
ServerIron(config)# server virtual-name-or-ip vs1 10.10.10.10
ServerIron(config-vs-vs1)# sticky-age-multiplier 5
The <multiplier-value> variable is a numerical value in the following range: 2 to 120. This value is used to produce a sticky-age value for the Virtual Server it is configured under that is a multiple of the value configured globally for the ServerIron as described in
“Setting the Sticky Age”. For example, if the sticky age is configured to be 20 minutes, and the sticky-age-multiplier to be 40, then the actual sticky age of the sticky sessions for the server will be 20x40= 800 minutes.
Please note that even though the sticky-ages are multiplied, the
show session command will still only show ordinary age of the sticky sessions. The difference is that the age is incremented in a slower pace when multiplier is applied. For example if the sticky-age-multiplier is configured to be 40, the age counter in the session table is incremented once in 40 minutes instead of 1 minute.
The concurrent feature allows a client to have sessions on different application ports on the same real server at the same time. When you enable an application port to be concurrent, the real server can open additional (“concurrent”) TCP/UDP sessions with the client using arbitrary TCP/UDP port numbers.
Configuring the Smooth Factor
The ServerIron ADX calculates the server response time value for a real server by regularly collecting response time samples, then using a calculation to smooth the values of the samples and derive a single response time value for the real server. The ServerIron ADX collects the samples around once every 100 milliseconds (about 10 times a second). The sampling rate can vary slightly depending on the processing the ServerIron ADX is performing.
To smooth the samples out, the ServerIron ADX uses the following calculation:
S = Smooth factor, which is configurable and can be from 1 – 99. The default is 90. A large value gives the previous response time more weight than the new response time. A small value gives the new response time more weight than the previous response time.
For example, if a given real server’s previous response time value was 2 milliseconds, and a new measurement also results in 2 milliseconds, the calculated server response time using the default smooth factor is as follows:
If the real server’s response time slows due to processing for additional connections, the slower response time affects the Server Response Time calculation for the server. For example, if the next server response time sample is 5 milliseconds instead of 2, the Server Response Time calculation is as follows:
You can affect the degree of difference in subsequent response time weights by changing the smooth factor (S). For example, if you change the smooth factor from 90 (the default) to 50, the calculations shown above have the following results:
Notice that the differences between the first and second samples are much greater when the smooth factor is 50 than when the smooth factor is 90. A large value gives the previous response time more weight than the new response time. A small value gives the new response time more weight than the previous response time.
By default, the ServerIron ADX creates session table entries for sessions between clients and applications on real servers. The ServerIron ADX uses the session table entries to maintain state information for the sessions. The ServerIron ADX uses the state information for features such as health checking and session failover in hot-standby configurations.
You can configure individual application ports to be stateless. The ServerIron ADX does not maintain state information for a stateless port. Making a port stateless is useful when you want to conserve session table resources or when you have configured the VIP to be transparent.
In a typical configuration, a client’s IP address remains the same throughout the client’s session with a virtual server. However, in some configurations where a proxy is used for the clients before the client traffic reaches the ServerIron ADX, the client’s IP address can be different for each request. To configure session persistence in a proxy environment, configure a standard IP ACL containing the addresses, then use the
Virtual Source feature.
When you configure the Virtual Source feature, the ServerIron ADX sends all client traffic from a specified range of IP addresses to the same real server for the application ports you specify. To specify the IP addresses, configure a standard IP ACL. Use this command in configurations where a proxy device allocates IP addresses to client traffic before sending the traffic to the VIP. In some configurations, the proxy device assigns different IP addresses to traffic from the same client. Unless you configure the addresses to go to the same real server, the ServerIron ADX might load balance the client traffic to different servers. This makes applications that require continued access to the same real server unusable.
By default, the ServerIron ADX translates the application port number requested by the client into the application port number you specify on the virtual server when you bind it to the real server. For example, if you bind port 80 on a virtual server to port 8080 on a real server, the ServerIron ADX translates the application port in the client’s request from port 80 into 8080 before forwarding the request to a real server.
A few ServerIron ADX configurations require that you disable translation for an application port. For example, if you want to bind multiple virtual IP addresses to the same real server, you must disable port translation for all but one of the virtual IP addresses, then bind the virtual IP addresses to an alias port for the application. Disabling port translation enables the virtual IP addresses to use the same actual port number on the real server while the ServerIron ADX collects and displays separate statistics for the alias port number associated with each virtual IP address.
In a configuration with two VIPs bound to the same server port, where the VIPs are hosting multiple Web sites on the same server (different VIPs point to different sites), an alias port is required. In this scenario, if the master port goes down, the ServerIron ADX stops forwarding traffic to the other sites as well, even though these sites are up. This occurs because the ServerIron ADX uses the master port’s state for traffic forwarding decisions. To resolve this issue, you must enable the ServerIron ADX to use the alias port’s state for traffic forwarding decisions. Thus, if the alias port’s state is up, the ServerIron ADX continues to forwarding traffic. Likewise, if the alias port’s state is down, the ServerIron ADX stops forwarding traffic to the server.
To enable the ServerIron ADX to use the alias port’s state for traffic forwarding decisions, enter the following command:
Syntax: port <tcp/udp port> use-alias-port-state
In the next example, if site test1 goes down, the ServerIron ADX would stop forwarding traffic to VIP2 as well. In this scenario, you would enable the
port http-use-alias-port-state command so that traffic to VIP2 does not stop when site test1 goes down.
You can designate real servers as primary servers or backup servers. A primary server is used by the ServerIron ADX when load balancing client requests for an application. A backup server is used by the ServerIron ADX only if all the primary servers are unavailable for the requested application.
In a configuration where one real server is configured as a primary server and another is configured as a backup, the virtual server may have the
sticky option enabled, which ensures that new connections are sent to the primary server, and a sticky session to a given port is created that points to that primary server.
If the primary server goes down, new connections are sent to the backup server, and a sticky session to the port is created that points to the backup server. The sticky session to the (inoperative) primary server is deleted. When the primary server becomes operative again, since the sticky session to the backup server is still valid (that is, it has not aged out), new connections to the port are still sent to the backup server. This is the default behavior.
You can optionally configure the ServerIron ADX to send new connections for the port to the primary server when it comes back up, even though there is a sticky session to the backup server.
ServerIron(config)# server virtual-name-or-ip v1 192.168.9.210
ServerIron(config-vs-v1)# port dns lb-pri-servers
ServerIron(config-vs-v1)# port dns sticky
ServerIron(config-vs-v1)# port dns active-primary-overide-sticky
When the active-primary-overide-sticky command is configured, if the primary server goes down and then comes back up, any new connection to the DNS port is sent to the primary server. The old sticky session to the backup server is deleted, and a new sticky session to the primary server is created.
ServerIron(config)# server virtual-name-or-ip v1 10.10.1.151
ServerIron(config-vs-v1)# port 8080
ServerIron(config-vs-v1)# no port 8080 translate
ServerIron(config-vs-v1)# port 8080 use-alias-port-state
Assume a configuration having two VIPs on the same real server with different healthchecks for each VIP using no port translate. If the real server healthcheck fails for the first VIP (bound to master port), traffic is not sent to the second VIP (bound to alias port). The client will receive a RST. When
port use-alias-port-state is enabled, traffic to a VIP on the alias port will be forwarded if the health of the alias port passes. This feature is useful in scenarios where master port health and alias port health are using different URLs for healthcheck.
Copyright © 2009 Brocade Communications Systems, Inc.
