53-1003247-01 July 2014 Brocade Virtual ADX Server Load Balancing Guide Supporting Brocade Virtual ADX version 03.1.
Copyright © 2014 Brocade Communications Systems, Inc. All Rights Reserved. ADX, AnyIO, Brocade, Brocade Assurance, the B-wing symbol, DCX, Fabric OS, ICX, MLX, MyBrocade, OpenScript, VCS, VDX, and Vyatta are registered trademarks, and HyperEdge, The Effortless Network, and The On-Demand Data Center are trademarks of Brocade Communications Systems, Inc., in the United States and/or in other countries. Other brands, products, or service names mentioned may be trademarks of their respective owners.
Contents Preface Document conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Text formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Command syntax conventions . . . . . . . . . . . . . . . . . . . . . . . . . . xiv Notes, cautions, and warnings . . . . . . . . . . . . . . . . . . . . . . . . . . xiv Brocade resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing the Load-Balancing Predictor Method . . . . . . . . . . . . . . . 21 Configuring a weighted predictor . . . . . . . . . . . . . . . . . . . . . . . . 22 Configuring dynamic weighted predictor . . . . . . . . . . . . . . . . . . 24 Configuring the smooth factor . . . . . . . . . . . . . . . . . . . . . . . . . . 25 Real server ports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Disabling or re-enabling application ports . . . . . . . . . . . . . . . . .
Multiple port binding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Direct binding of multiple ports . . . . . . . . . . . . . . . . . . . . . . . . . 70 Port aliases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Real server groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Defining a real server group . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Miscellaneous options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106 Changing a real server’s IP address . . . . . . . . . . . . . . . . . . . . .106 Adding a description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Configuring a local or remote real server . . . . . . . . . . . . . . . . . 107 Configuring a TCP MSS value at the global level . . . . . . . . . . . 107 Configuring a TCP MSS value for a virtual server . . . . . . . . . .
Show and debug commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151 Displaying the BP distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . .151 Chapter 3 Stateless Server Load Balancing Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153 Stateless TCP and UDP ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .153 How the Brocade Virtual ADX selects a real server for a stateless port. . . . . . . . . . . .
Port profiles and attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .187 Configuring a port profile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188 Configuring port profile attributes . . . . . . . . . . . . . . . . . . . . . .189 Port policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193 Port policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193 Configuring a port policy . . . . . . . . .
Chapter 5 Layer 7 Content Switching Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243 Layer 7 content switching. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243 Enabling CSW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244 Specifying scan depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244 Enabling CSW load balance . . . . . . . . . . . . . . . . . . . . . . . . . . .244 CSW rules .
Chapter 6 Hot Standby High Availability Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .305 Hot Standby HA protocol operations. . . . . . . . . . . . . . . . . . . . .306 Hot Standby HA configuration modes . . . . . . . . . . . . . . . . . . . . . . .307 Non-Promiscuous mode with default non-shared MAC option307 Promiscuous mode with shared MAC option . . . . . . . . . . . . . .308 Hot Standby HA Configuration Considerations . . . . . . . . . . . . . . .
Defining IPv6 real servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .346 Defining IPv6 virtual servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .346 Defining port characteristics using port profile . . . . . . . . . . . . . . .346 Defining IP routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .346 VLAN and tagging definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347 Miscellaneous . . . . . . . . . . . . . . . . . . .
Displaying configuration information . . . . . . . . . . . . . . . . . . . . . . . .386 Showing aggregate health of tracked ports . . . . . . . . . . . . . . .386 Auto repeat of show command output . . . . . . . . . . . . . . . . . . .387 Clearing all session table entries . . . . . . . . . . . . . . . . . . . . . . .387 Clearing the connections counter. . . . . . . . . . . . . . . . . . . . . . .388 Appendix C Acknowledgements OpenSSL license . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Preface Document conventions This section describes text formatting conventions and important notice formats that may be used in this document. Text formatting The following text formatting conventions may be used in the flow of the text to highlight specific words or phrases.
Command syntax conventions Convention Description bold text Identifies command names, keywords, and command options. italic text Identifies variables. [] Syntax components displayed within square brackets are optional. { x | y |z } A choice of required parameters is enclosed in curly braces separated byvertical bars. You must select one. x|y A vertical bar separates mutually exclusive elements. <> Nonprinting characters, for example, passwords, are enclosed in angle brackets. ...
Brocade resources To get up-to-the-minute information, go to http://my.brocade.com to register at no cost for a user ID and password. Release notes are available at http://my.brocade.com. White papers, online demonstrations, and data sheets are available through the Brocade website at: http://www.brocade.com/products-solutions/products/index.page Select Application Delivery Switches on this page to navigate to the relevant product information.
Document feedback • Brocade Supplemental Support augments your existing OEM support contract, providing direct access to Brocade expertise. For more information, contact Brocade or your OEM. • For questions regarding service levels and response times, contact your OEM/Solution Provider. Document feedback Quality is our first concern at Brocade and we have made every effort to ensure the accuracy and completeness of this document.
Chapter 1 Features Brocade Virtual ADX Supported Features The Brocade Virtual ADX supports all of the essential features for ensuring the optimized delivery of application traffic. Load Balancing The Brocade Virtual ADX enables the efficient distribution of traffic among application and infrastructure servers.
1 Brocade Virtual ADX Supported Features Advanced networking with support for static and dynamic routing The system supports both static and dynamic routing (for OSPF, BGP and RIP protocols) as well as route health injection (RHI). This combination of features allows administrators to configure the system so that an upstream router can pick the optimal route for reaching a virtual server.
Feature summary 1 Feature summary The following tables lists the supported features and related documentation for the Brocade Virtual ADX releases. TABLE 1 Supported features for Brocade Virtual ADX version 03.1.
1 Feature summary TABLE 2 Supported features for Brocade Virtual ADX version 03.0.
Feature summary TABLE 3 1 Supported features for Brocade Virtual ADX version 02.0.00 (Continued) Category Feature Document High Availability Additional variations, IPv4 to IPv6 gateway high availability support Brocade Virtual ADX Server Load Balancing Guide System Management All system management including SOAP/XML API for supported features, CLI, GUI, syslog, Telnet, SCP, SNTP, SNMP, AAA, packet filter etc.
1 6 Feature summary Brocade Virtual ADX Server Load Balancing Guide 53-1003247-01
Chapter Server Load Balancing 2 Overview The Brocade Virtual ADX Application Delivery Switch (Brocade Virtual ADX) helps ease the administration of TCP-based or UDP-based applications. They provide server load balancing (SLB) for the application servers, help offload CPU-intensive tasks from the application servers, and provide added security to the server farm. In Figure 1, the system administrator has greater flexibility in managing application server resources.
2 Overview In Figure 1, an application administrator has established a web site www.example7.com. This web site is mapped to the virtual server (VIP 10.95.55.1) that is hosted on the Brocade Virtual ADX. All queries made to this web site arrive at the virtual server. The Brocade Virtual ADX then distributes these queries among the four back-end application servers. The actual addresses of these four real web servers remain unknown and unseen to the end users.
Overview 2 Weighted Round Robin predictor Like the Round Robin predictor, the Weighted Round Robin predictor treats all servers equally regardless of the number of connections or response time. It does however use a configured weight value that determines the number of times within a sequence that the each server is selected in relationship to the weighted values of other servers.
2 Overview For BP2 1. The first request is sent to Server1. 2. The second request is sent to Server2. 3. The third request is sent to Server3. 4. The fourth request is sent to Server1. 5. The fifth request is sent to Server2. 6. The sixth request is sent to Server1. Notice that this sequence for each pair of servers is exactly the same as described in the example for the Weighted Round Robin predictor.
2 Overview If you set the weight so that your fastest server gets 50 percent of the connections, it will get 50 percent of the connections at a given time. Because the server is faster than others, it can complete more than 50 percent of the total connections overall, because it services the connections at a higher rate. Therefore, the weight is not a fixed ratio but adjusts to server capacity over time.
2 Overview Connection assignments with enhanced weighted predictor for enhanced weighted load-balancing In enhanced weighted load-balancing, the traffic is distributed in the same proportions as in weighted load-balancing, but the order of distribution is different.
Overview 2 Dynamic weighted predictor The Brocade Virtual ADX provides a dynamic weighted predictor that enables it to make load balancing decisions using real time server resource usage information, such as CPU utilization and memory consumption. The Brocade Virtual ADX retrieves this information (through the SNMP protocol) from MIBs available on the application servers. To achieve this capability, a software process in the Brocade Virtual ADX, named SNMP manager (also called SNMP client) is used.
2 Overview If the SNMP-weight indicates that your fastest server gets 50 percent of the connections, the server will get 50 percent of the connections at a given time. However, because the server is faster than others, it can complete more than 50 percent of the total connections overall by servicing the connections at a higher rate. As a result, the weight is not a fixed ratio but instead adjusts to server capacity over time.
Overview 2 Application port groups Application groups enhance the sticky connections method by allowing you to group up to four TCP or UDP ports with another, “primary” TCP or UDP port. When the Brocade Virtual ADX sends a client request for the primary port to a real server, requests from the same client for a port that is grouped with the primary port also go to the same real server. The application group method, like the sticky method, is governed by the sticky age.
2 Overview The Brocade Virtual ADX switches all subsequent connections to S2 to ensure that the application session completes successfully. By default, the concurrent property of a virtual TCP or UDP service port is enabled except for FTP, Telnet, TFTP, HTTP, and SSL ports. Remote Servers The application servers that are a Layer 3 hop away (in other words, in a different subnet that is separated by router) are identified as remote servers in the Brocade Virtual ADX.
Overview 2 Figure 3 shows an example of a Brocade Virtual ADX deployed in an L2 DSR configuration. FIGURE 3 Brocade Virtual ADX in an L2 DSR configuration The example above shows the flow of packets in which the Brocade Virtual ADX and the real servers are Layer 2 connected. 1. The client sends a packet to an VIP on the Brocade Virtual ADX. 2. The Brocade Virtual ADX forwards the packets to the loopback address on the real server. 3. The real server then sends the packet directly to the client.
2 Configuring basic SLB In the example, the Brocade Virtual ADX inspects and modifies packets sent to a VIP. The real server uses the L3 DSR VIP as the source address in response packets if the DSCP bit value of the received packet matches the configured value. 1. The client sends a packet to an L3 DSR VIP on the Brocade Virtual ADX. 2. The Brocade Virtual ADX modifies the DSCP field in the packet to a configured value and sends the packet to a real server. 3.
Configuring basic SLB TABLE 6 2 Real and virtual server assignments Domain name Virtual IP Port Real IP Port www.example7.com 10.95.55.1 80 10.95.55.21 (Web1) 80 10.95.55.22 (Web2) 80 10.95.55.23 (Web3) 80 10.95.55.24 (Web4) 80 Configuration guidelines The following configuration guidelines should be observed when configuring SLB on a switch: • • • • • Each virtual server name and IP address must be unique. Each virtual server can have multiple TCP or UDP ports assigned.
2 Configuring basic SLB Virtual ADX(config-rs-Web2)#exit Virtual Virtual Virtual Virtual ADX(config)#server real Web3 10.95.55.23 ADX(config-rs-Web3)#port http ADX(config-rs-Web3)#port dns ADX(config-rs-Web3)#exit Virtual Virtual Virtual Virtual ADX(config)#server real Web4 10.95.55.
Changing the Load-Balancing Predictor Method 2 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. Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual ADX(config)#server virtual-name-or-ip www.altergo.com 10.95.55.1 ADX(config-vs-www.altergo.com)#port http ADX(config-vs-www.altergo.com)#exit ADX(config)#server virtual-name-or-ip 10.95.55.
2 Changing the Load-Balancing Predictor Method Selecting the round-robin parameter configures the Round Robin load-balancing method. This method is described in “Round Robin predictor” on page 8. Selecting the weighted-round-robin parameter configures the Weighted Round Robin load-balancing method. This method is described in “Weighted Round Robin predictor” on page 9. Selecting the weighted-round-robin-static parameter configures the Static Weighted Round Robin load-balancing method.
Changing the Load-Balancing Predictor Method 2 Assigning weights to the real servers When configuring Weights on a real server, consider the following: • Real Server Weight assignments apply to all ports configured under the real server. • For the Weighted Round Robin predictor, server weights are assigned at the server level and not at the server port level. The load balancing, however, is based on per-server port. • The Weighted Round Robin predictor has VIP port-level granularity.
2 Changing the Load-Balancing Predictor Method If you enter a value for response-time-weight, the Brocade Virtual ADX adds the two weight values together when selecting a real server. If you specify equal values for each parameter, the Brocade Virtual ADX treats the weights equally. The number of connections on the server is just as relevant as the server’s response time.
Changing the Load-Balancing Predictor Method 2 Dynamic-weighted direct To configure a dynamic-weighted reverse predictor, use the following command. Virtual ADX(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.
2 Changing the Load-Balancing Predictor Method To smooth the samples out, the Brocade Virtual ADX uses the following calculation: R = ((S * previous_R) + ((100 - S) * new_R)) / 100 where: R = Response time S = smooth factor, which is configurable and can be from 1to 99. The default is 60. 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.
Real server ports 2 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. You can change the smooth factor on an individual virtual server’s application port basis.
2 Real server ports To disable all the application ports on a real server, enter the following command at the configuration level for the server. Virtual ADX(config-rs-R1)#port disable-all To re-enable all the application ports, enter the following command. Virtual ADX(config-rs-R1)#no port disable-all Syntax: [no] port disable-all Globally disabling application ports You can globally disable a Layer 4 port on the Brocade Virtual ADX.
Real server ports 2 When you enable this feature, the Brocade Virtual ADX resets the connection for an unavailable TCP or UDP application on a real server in addition to redirecting future requests away from this real server. To enable the feature, enter commands such as the following: Virtual Virtual Virtual Virtual ADX(config)#server virtual vip-test 10.50.1.
2 Real server ports Configuring a real port as TCP-only or UDP-only This feature allows you to configure a Brocade Virtual ADX to allow traffic to a virtual port being load-balanced to a different set of real ports based on its protocol (TCP or UDP). No configuration change is required for the virtual server. A virtual port can be bound to tcp-only, udp-only and a regular real port at the same time. By default, a real port accepts both TCP and UDP traffic.
Source NAT 2 The tcp/udp-portnum variable specifies the application port you want to make stateless. NOTE The Brocade Virtual ADX supports port translation for stateless SLB. Port translation is useful when clients connect to real servers directly. Without port translation, if a client connects to a real server directly, the Brocade Virtual ADX automatically replaces the source IP address to a VIP.
2 Source NAT 4. The Client sees the response coming from an unknown IP address (other than the one that it sent the request to) and drops the packet. FIGURE 6 Scenario without source NAT configured In Figure 7 the traffic flow of the configuration is changed by enabling Source NAT as described in the following: 1. A request from the Client arrives at the Brocade Virtual ADX through a Layer 2 switch. 2.
Source NAT 2 Enabling source NAT globally Source NAT allows the Brocade Virtual 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 Brocade Virtual ADX performs source NAT only for those real servers.
2 Source NAT 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) HA 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 Brocade Virtual ADX devices. The address is active only on one Brocade Virtual ADX (the Brocade Virtual ADX that is currently active) at a time.
Source NAT 2 The source-ip variable is the source NAT IP address of the subnet with which you want to associate the client subnet. The source NAT IP address you enter must be configured on the Brocade Virtual ADX. Enabling port allocation per real server for source NAT IP For the Brocade Virtual ADX products, the port pools are not shared globally but are allocated to each real server and each real server is able to use the entire pool by itself.
2 Remote server Remote server If the server is attached through one or more router hops, configure the server as remote. When you add a remote real server, the Brocade Virtual ADX does not include the server in the predictor (load-balancing method). Instead, the Brocade Virtual ADX sends traffic to the remote server only if all local real servers are unavailable. The server name is used to bind the server IP address, so that the real server name can be used to represent the server.
Sticky and concurrent connections 2 Configuring stickiness based on client’s subnet The sticky function causes the Brocade Virtual 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 Brocade Virtual ADX to base the stickiness on the client’s subnet, rather than IP address.
2 Sticky and concurrent connections Allowing sticky ports You can configure the Brocade Virtual ADX to continue using a sticky port (a persistent connection) even if you have entered a command to unbind the port or the port is disabled. When you unbind an application port from a server, the Brocade Virtual ADX temporarily places the port in the aw_unbnd (awaiting unbind) state. If you delete an application port, the Brocade Virtual ADX temporarily places the port in the aw_del (awaiting delete) state.
Sticky and concurrent connections 2 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 Brocade Virtual ADX as described in “Setting the sticky age” on page 37.
2 Sticky and concurrent connections Enabling group sticky The group sticky feature enables sticky connections to be load balanced among servers in the same group. Without this feature, normal sticky behavior always sends a specific client IP to a specific server. Group Sticky is useful when the server farm is grouped into clusters, and each cluster has servers with replicated (mirrored) content. To enable Group Sticky, use the port type group-sticky command.
Sticky and concurrent connections 2 port http port http url "HEAD /" port http group-id 2 2 server real Web2 10.20.1.43 port http port http url "HEAD /" port http group-id 2 2 server real Web3 10.20.1.44 port http port http url "HEAD /" port http group-id 2 2 2. On the VIP, ensure the minimum required commands for Group Sticky are present: port type group-sticky and port type sticky. If stickiness is not configured, load balancing among the group will not work.
2 Sticky and concurrent connections 3. Identify what server the sticky session is pointed to. In the example below, the sticky session was originated from the client 10.30.1.1 to the VIP 10.40.1.10 using real server rs1. All the traffic to/from the client is being load balanced across the group (group-id 1 1) to which the real server rs1 belongs. Enter the show session all 0 command (at the BP console) such as the following. .
Application port grouping 2 Enabling a concurrent port 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 or UDP sessions with the client using arbitrary TCP or UDP port numbers.
2 Application port grouping Tracking primary ports You can configure the Brocade Virtual ADX to send all client requests for a specific set of TCP or UDP ports to the same real server as a “primary” TCP or UDP port grouped with the other ports. The primary TCP or UDP port can be grouped with up to four additional TCP or UDP ports.
Application port grouping 2 NOTE Every port in a track port group must be configured to be “sticky” and be bound to the real servers involved. NOTE If no track port group configured, the sticky session age is not refreshed if any data session exists. Only the data session's age will be refreshed if the connection is still alive. NOTE If a track port group is configured into the VIP (i.e. for two ports), the sticky session refreshes and will not expire as long as one of the ports has an alive session.
2 Application port grouping Virtual ADX(config-real-server-r1) port 8082 Virtual ADX(config-rsr1) hc-track-group 80 8081 8082 In this example, the Brocade Virtual ADX now tracks health status for ports 80, 8081, and 8082. If any of these ports is down. the combined health would be marked as failed and the Brocade Virtual ADX will not use these ports for load balancing traffic. Sample configuration server real rs1 10.1.1.
Application port grouping 2 TCP/UDP application groups configuration example Normally, when the Brocade Virtual ADX selects a real server for a client’s request for a TCP/UDP port, there is no guarantee that the Brocade Virtual ADX will select the same real server for subsequent requests from the same client. In many situations, this does not present a problem.
2 Application port grouping Figure 9 shows an example of servers configured with sticky ports and an application group. In this example, the content on each real server is identical. However, some applications on the server require that clients use the same server for subsequent requests to the application. The virtual server is configured to make the ports sticky and to group the TFTP and Telnet ports under the HTTP port.
Primary and backup servers 2 NOTE Because ports 23 and 69 track port 80, state information for the tracking ports (23 and 69 in this example) are based on the tracked port’s state (port 80 in this example). The state is shown in the Ms (Master port state) field of the display produced by the show server real command. Refer to “Displaying real server information and statistics” on page 371. The track group function works similarly to the track port function.
2 Primary and backup servers In addition, this feature implements the primary and backup configuration on an individual VIP basis. You designate each backup server by changing the real server configurations. You do not need to designate the primary servers. You enable the feature in individual VIPs for individual application ports. NOTE The Brocade Virtual ADX does not differentiate between real and remote servers when the primary-backup feature is enabled.
Primary and backup servers 2 remotely-attached servers (configured using the server remote-name command) as their backup servers. Optionally, configure the individual applications on the VIPs to continue using the backup servers following a failover, instead of returning to the primary servers. Designating a real server as a backup By default, the virtual server uses the locally attached real servers as the primary load-balancing servers and uses the remotely attached servers as backups.
2 Primary and backup servers Configuration example The example configures load-balancing shown in Figure 10 on page 50. To configure the real servers, enter commands such as the following. Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual ADX(config)#server real R1 10.10.10.10 ADX(config-rs-R1)#port http ADX(config-rs-R1)#exit ADX(config)#server real R2 10.10.10.
Primary and backup servers 2 Designating a real server port as a backup Backup functionality can be configured at the application port level, meaning that for a given real server, you can specify one port to be a backup and another port as a primary. Figure 11 illustrates this feature. FIGURE 11 Real server application ports configured as primaries and backups In this example, real servers RS1 and RS2 are bound to a VIP. Each real server has three ports defined: HTTP, FTP, and DNS.
2 Primary and backup servers Syntax: [no] port port-name backup Per server based real server backup The current implementation of the backup server requires that all non-backup servers fail before SLB directs requests to backup servers. This method might not allow for maintaining the same level of performance in the server farm. The ability to maintain the same performance level for a given service is critical for many customers.
Primary and backup servers 2 Slow start of the backup and the primary servers If the server selection predictor is least connection, the backup server can be overwhelmed by the flood of the new connections when its primary server goes down. The same is true when the primary server goes back up and starts to take over the connections from the backup server. The slow start mechanism will be used whenever the switching of the backup or primary server happens, to give the server the chance to ramp up.
2 Primary and backup servers Example To configure the real server R2 as the backup of the real server R1. Virtual Virtual Virtual Virtual Virtual Virtual Virtual ADX(config)#server real-name R1 10.10.10.10 ADX(config-rs-R1)#port http ADX(config-rs-R1)#exit ADX(config)#server real-name R2 10.10.10.
Configuring Direct Server Return 2 Display the backup bindings This command is used to display the binding relationship between the servers and the ports. Syntax: show server backup-server-port-binding Example Virtual ADX(config)#server real-name R1 10.10.10.10 Virtual ADX(config-rs-R1)#port http Virtual ADX(config-rs-R1)#exit Virtual ADX(config)#server real-name R2 10.10.10.
2 Configuring Direct Server Return FIGURE 12 Two Brocade Virtual ADX devices in an DSR configuration Brocade Virtual ADX supports both Layer 2 Direct Server Return (L2 DSR) and Layer 3 Direct Server Return (L3 DSR). The steps required to configure support L2 DSR and L3 DSR differ significantly. • In an L2 DSR configuration, the Brocade Virtual ADX and the real servers must be on the same subnet. • In an L3 DSR configuration, the Brocade Virtual ADX and the real servers can be connected by a router.
Configuring Direct Server Return 2 Enabling L2 DSR on TCP/UDP ports To configure the Brocade Virtual ADX for L2 DSR, you must 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 L2 DSR for that port. Virtual ADX(config)#server virtual-name-or-ip v1 10.157.22.
2 Configuring Direct Server Return Placing a session in delete queue DSR fast delete places a session in a delete queue upon seeing the first FIN in Direct Server Return (as opposed to the standard two FINs). The session is deleted in eight seconds instead of the standard two minute FIN session age. The DSR fast-delete option is enabled by default.
Configuring Direct Server Return 2 To implement the configuration shown in Figure 13, configure Brocade Virtual ADX devices A and B. Because multiple VIPs are mapped to the same ports on the same real servers, TCP/UDP port binding is used. Thus, port 180 on VIP2 on Brocade Virtual ADX A and on VIP1 on Brocade Virtual ADX B is a logical port that is bound to port 80 on the real servers. For more information, refer to “Multiple port binding” on page 69.
2 Configuring Direct Server Return Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual ADXA(config-rs-Real_Server_2)#exit ADXA(config)#server real-name Real_Server_3 10.0.1.1 ADXA(config-rs-Real_Server_3)#port http ADXA(config-rs-Real_Server_3)#port 180 ADXA(config-rs-Real_Server_3)#exit ADXA(config)#server real-name Real_Server_4 10.0.1.
Configuring Direct Server Return 2 Configuring L3 Direct Server Return In an L3 DSR configuration, the Brocade Virtual ADX marks all packets sent to servers bound to a specified VIP (the L3 DSR VIP) by setting the DSCP field to a configured value. The real server must be programmed to check the DSCP field of incoming packets and change the source IP address of appropriate reply packets from its own IP address (real IP address) to the virtual IP address (VIP).
2 Configuring Direct Server Return Special handling by real servers L3 DSR requires special intelligence on the real server. Real servers must be programmed to check for DSCP field values in incoming packets and, if the received DSCP value matched a preconfigured value, change the source IP address of reply packets from its own IP address (real-ip) to a virtual IP address (virtual-ip).
Displaying server information 2 NOTE To make the above configuration work, the real server must have a special intelligence. When the server receives a packet with DSCP value 20, it should use "10.1.1.151" as a source IP address in response packets. NOTE When DSR is configured, the server directly responds to the client, therefore, if the user binds different real server ports and virtual server ports, e.g. port 8080 of real server to port 80 of virtual server, the DSR traffic will not work.
2 Port ranges Defining a port range Port ranges are identified by their names. A port range can be created as follows. 1. Define the port range Virtual ADX(config)#port-range pr1 Syntax: [no] port-range port-range-name 2. Identify the ports in the range. Virtual ADX(config-pr-pr1)#port 8051 to 8100 Syntax: [no] port port-number to port-number Enter the port’s numerical value for port-number. When defining a port range: • • • • • • Ports in a port range must be consecutive.
Port ranges 2 Using a port range under a real server definition You can define port ranges under a real server definition. Virtual ADX(config)#server real real1 10.0.0.1 Virtual ADX(config-rs-real1)#port-range pr1 Syntax: [no] port-range port-range-name Enter the ID of the port range for port-range-name. Refer to the rules in “Defining a port range” on page 66 for additional rules. You can add more than one port range to a real server; however, the ports in the port ranges cannot overlap.
2 Port ranges Defining port profile for port range You can define a profile for a port range. Policies and other features defined for a port profile are applied to all the ports included in the port range.
Multiple port binding 2 Using a start-index variable begins display at the record specified where the first record has a value of 0. In the following example, the start-index value of 2 is used on the same port-range displayed in the previous example. Virtual ADX(config)#show port-range 2 Name Start End pr98 9800 9803 range4 7001 7050 Pending Start Pending End RefCnt 4 To display a list of port ranges with a name that starts with a specified prefix, issue the following command.
2 Multiple port binding To simplify an existing configuration that uses port aliases, you can manually convert that configuration to the direct binding method to reduce the size of SLB configurations. If you choose to use the direct method, you must first remove all alias port bindings and reload your configuration. Direct binding of multiple ports Direct binding of multiple ports enables you to associate a real server TCP or UDP port with multiple virtual TCP or UDP ports.
Multiple port binding 2 NOTE The default port (a port the Brocade Virtual ADX automatically configures on all real and virtual servers) and the source IP application port do not support multiple port binding. Specifying the number of multiple port bindings available Direct binding of multiple ports is enabled by default with the default value for the number of bindings allowed as determined by the license that is active on your system.
2 Multiple port binding Port aliases When you associate a virtual port (VIP) with a real server, you make the association for a particular TCP or UDP port. The association of a TCP or UDP port on a VIP with a TCP or UDP port on a real server is called a "port binding". In most configurations, only one VIP-to-real-server binding is made for a TCP or UDP port. For example, if you bind VIP 10.29.2.2 to real server 10.0.0.
Multiple port binding 7. 2 Bind the alias ports to the real servers on the virtual servers. Virtual ADX(config-vs-vs2)#bind http rs1 8081 real-port 81 rs2 8082 real-port 82 Syntax: bind virtual-port real-server-name alias-port [real-port real-port-num] NOTE Alias ports should be treated like regular ports and should have the same server ID and group ID.
2 Multiple port binding Configuration rules Use the following rules when configuring the Brocade Virtual ADX to bind more than one virtual server to the same real server using the same application port: • You must configure both the real port and the alias port on the real servers. For example, if you need to create alias port 180 so that you can bind two virtual servers to the same real server and application port (80) on a real server, you must configure port 80 and port 180 on the real server.
Multiple port binding 2 Configuration example To implement the configuration described above, enter commands such as the following. Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual Virtual ADX(config)#server real-name r1 10.0.1.5 ADX(config-rs-r1)#port http ADX(config-rs-r1)#port 180 ADX(config-rs-r1)#exit ADX(config)#server real-name r2 10.0.2.
2 Multiple port binding To display statistics for the separate real IP addresses, enter the following command at any command prompt. Virtual ADX(config)#show server real Real Servers Info ======================== State(St) - ACT:active, ENB:enabled, FAL:failed, TST:test, DIS:disabled, UNK:unknown, UNB:unbind, AWU:await-unbind, AWD:await-delete HLD:held-down Name: r1 State: Active Cost: 0 IP:10.95.7.1:1 Mac: 0000.855d.
Real server groups 2 Assume a configuration having two VIPs on the same real server with different health checks for each VIP using no port translate. If the real server health check 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.
2 Real server groups Real server group configuration is a three-step process: • First, you must define the real server group. • Once defined, you can associate one or more real servers with that real server group. Up to four real servers can be associated with a real server group in a single command. • You can then bind the real server group to a virtual server.
Disabling or deleting VIPs and real ports 2 Binding a real server group to a virtual server Use the bind group-real command to bind a real server group to a virtual server. Virtual ADX(config)#server virtual name-or-ip v1 Virtual ADX(config-vs-v1)#bind http group-real sg1 http A real server group can be bound to multiple virtual servers.
2 Disabling or deleting VIPs and real ports Disabling a real server Under the real server config level, you can disable a real server. Disabling a real server also disables all the existing real server ports. The real server state will become “disabled”, and no new connections will be assigned to a disabled real server. However, all the existing connections will remain. No health check will be done for a disabled real server. To disable a real server, enter commands such as the following.
Disabling or deleting VIPs and real ports 2 Deleting a VIP It is critical that you follow the steps below before 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. Syntax: [no] server real real-server-name Syntax: [no] port port disable 2. Keep checking the current connection count against the real server until the connection count falls to zero. Syntax: show server real real-server-name 3.
2 Disabling or deleting VIPs and real ports Enabling force-delete SLB allows the graceful shutdown of servers and services. By default, when a service is disabled or deleted, the Brocade Virtual ADX does not send new connections to the real servers for that service. However, the Brocade Virtual ADX does allow existing connections to complete normally, however long that takes. You can force the existing SLB connections to be terminated within two minutes, by using the server force-delete command.
Disabling or deleting VIPs and real ports 2 Real server shutdown The force shutdown feature (sometimes called the force delete feature) allows you to force termination of existing SLB connections. This feature assumes that you already have shut down a TCP/UDP service on the real server, or you have shut down the real server itself. There are several methods for shutting down a service or server. Each method has consequences, so choose the method that works best in your situation.
2 Disabling or deleting VIPs and real ports Table 9 describes the behavior of the Brocade Virtual ADX for a specified action when it is configured with the server force-delete command, with a port hold-down timer configured and in a normal scenario without either configured. TABLE 9 Behavior with server force-delete command Action Normal Scenario With Force-Delete With Port Hold-down Delete Real Server Sessions deleted within 2 minutes. Sessions deleted within 2 minutes.
2 Disabling or deleting VIPs and real ports Enabling the port hold down timer for an individual real server port You can configure the port hold down timer to enable port holddown for an individual port within a real server configuration. Virtual ADX(config)#server real rs1 Virtual ADX(config-real-rs1)#port http holddown Syntax: [no] port port-type holddown The port-type variable specifies the port that you want to apply the holddown timer to.
2 Hash-based SLB with server persistence The time remaining for the holddown state is displayed by the show server real detail command as shown in the following. Virtual ADX(config)#show server real rs1 det http HLD 0 0 0 0 0 0 0 0 max_conn = 10 fail time = 0, Vir IP 192.168.1.
Hash-based SLB with server persistence 2 If the client makes another request to the VIP, for example after two days, then the Brocade Virtual ADX will again calculate the hash based on the client IP and retrieve the persistent hash table entry. Because a real server has already been allocated to the persistent hash table entry, the Brocade Virtual ADX will use this real server to service the client request. As an effect, the client will always be directed to the same real server.
2 Hash-based SLB with server persistence Figure 14 shows the persistent hash table for a virtual server port before the rs3 comes up. FIGURE 14 Hash table before rs3 comes up Persistent Hash table virtual server vs1 port http Hash 0 none Hash 1 rs2 Hash 2 rs2 Hash 3 rs1 Hash 4 rs1 Hash 5 rs2 Hash 6 .............. rs1 Hash 255 none Assume the administrator now binds port HTTP of a new real server rs3 to port HTTP of virtual server vs1.
Hash-based SLB with server persistence 2 Configuring the reassign threshold and duration There are two configurable global parameters related to the reassign mechanism: • Reassign threshold — When the number of empty hash entries (buckets) in the persistent hash table falls to or below this threshold (less than or equal to), the Brocade Virtual ADX reassigns some of the persistent hash entries on introduction of a new real server.
2 Hash-based SLB with server persistence The Brocade Virtual ADX will stop reassigning persistent hash entries to the new real server when either of the following occurs: • The system has finished reassigning X persistent hash entries to the new real server (occurs in the amount of time specified by the persist-hash-reassign-duration).
2 Hash-based SLB with server persistence The Brocade Virtual ADX now attempts to reassign 3 persistent hash entries to the new real server over 2 minutes. The system will stop after it has reassigned 2 entries of real server rs1 to new real server rs3. The reason is that when rs3 is assigned 2 persistent hash entries, the value is equal to the number of entries assigned to existing real server rs2. Figure 17 shows the persistent hash table after the reassignment.
2 Hash-based SLB with server persistence Real server failure If a real server fails, the Brocade Virtual ADX will remove all assignments of the real server from all persistent hash table entries in the persistent hash table. For example, consider a virtual server vs1 whose port HTTP is bound to port HTTP of real server rs1 and rs2. Figure 18 shows the persistent hash table for vs1 for port HTTP before server failure.
2 Hash-based SLB with server persistence In the previous example, assume a client now makes an HTTP request for virtual server vs1. Assume also the client’s IP address hashes to a value of 2. The Brocade Virtual ADX checks the hash table entry corresponding to hash value 2 in the above persistent hash table. Because no real server is associated with the hash entry, the Brocade Virtual ADX selects a new real server, such as rs2, using the SLB predictor and then assigns the server to the hash table entry.
2 Hash-based SLB with server persistence Clearing the hit count for the persistent hash table To clear the hit count for the persistent hash table for a virtual server port, enter commands such as the following.
2 SLB spoofing configuration and support Displaying hash bucket changes You can display information about hash bucket changes on the Brocade Virtual ADX, through use of the show server proxy keep-alive command. A truncated display is shown with the hash bucket information. Virtual ADX#show server proxy keep-alive Keep-alive connection statistics: ... Hash Bucket Change: Current serv is down = Lower BP wins = ...
2 Policy-based SLB Policy-based SLB Policy-based server load balancing (PBSLB) is the Brocade Virtual ADX ability to direct requests to a server group based on the source IP address of the request. When policy-based SLB is enabled for a port on a virtual server, the Brocade Virtual ADX examines the source IP address of each new connection sent to the VIP on the port. The Brocade Virtual ADX looks up the source IP address of the request in an internal policy list.
Policy-based SLB 2 • When a request from a different address is received, because it does not have an entry in the policy list, it is forwarded to one of the load-balanced real servers in the default server group, which is specified as group 3. NOTES: • Policy-based SLB is enabled for individual ports on virtual servers. • Because policy-based SLB is enabled on a per-VIP basis, some VIPs configured on the Brocade Virtual ADX can have policy-based SLB enabled, while others do not.
2 Policy-based SLB For the example shown in “Policy-based SLB configuration” on page 96, the policies would be defined as shown in the following. 10.10.10.10 1 20.20.0.0/16 2 The policy list file created in the format defined above can be transferred to the Brocade Virtual ADX from a TFTP server. A single download file should contain all IPv4 entries. These entries can be in any order. NOTE Downloading a new file overwrites the existing policy list file on a Brocade Virtual ADX.
Policy-based SLB 2 Creating a PBSLB default group To create a PBSLB default group, enter a command such as the following. Virtual ADX(config)#server pbslb default-group-id ipv4 4 Syntax: [no] server pbslb default-group-id ipv4 group-id Assigning real server ports to default group A default group can contain one or more real servers. If there is more than one real server in a default group, requests are load balanced across all the servers in the group.
2 Policy-based SLB The ipv4-addr variable specifies the IPv4 entry that you want to delete from the policy list. You must specify either a prefix or a netmask. The server-group-id variable is alphanumeric and refers to one of the real server groups configured on the Brocade Virtual ADX. Deleting an entire PBSLB list To delete the entire PBSLB list, enter a command such as the following. NOTE This command will delete all the entries in the PBSLB list.
Policy-based SLB 2 For example, to configure real server rs1 in Figure 21 on page 96, enter commands such as the following. Virtual ADX(config)#server real rs1 10.95.7.1 Virtual ADX(config-rs-rs1)#port http group-id 1 1 Virtual ADX(config-rs-rs1)#exit Syntax: [no] server real real-server-name ip-addr Syntax: [no] port port group-id server-group-id-pairs In this example, the server real command defines a real server called rs1 with an IP address of 10.95.7.1.
2 Policy-based SLB Deleting existing PBSLB sessions By default, when a PBSLB server group configuration changes, the client sessions with that group remain open. For example, if a client has sessions associated with Group A, but Group A’s configuration changes and moves the client sessions to Group B, the sessions with Group A are still open. You can change this behavior by enabling the scan-session-table-after-config-change feature.
Policy-based SLB 2 Command line interface There are three steps to enable this feature. 1. Create a PBSLB failsafe group ID. 2. Assign real server ports to a failsafe group. 3. Enable PBSLB on a VIP port. Creating a PBSLB failsafe group To create a PBSLB failsafe group, enter a command such as the following.
2 Policy-based SLB NOTE The server pbslb tftp command must be configured before the server pbslb time-of-day or server pbslb download-interval command, so the Brocade Virtual ADX knows which server and file name to use in the download. NOTE The PBSLB time-of-day granularity is in minutes, so seconds are ignored in the configuration. For example, if you enter time as 16:35:30, it is taken as 16:35:00.
Policy-based SLB 2 To display multiple entries in the policy list, enter a command such as the following. Virtual ADX#show pbslb all ipv4 10 Max Count: 1000000 Total Count: 2 IP address Mask Server Group ID 10.10.1.101 128 11 Syntax: show pbslb all ipv4 index The show pbslb all command displays 20 entries in the policy list, starting from the point specified with the index variable. In the example, 20 entries in the policy list are displayed, starting from the 100th entry.
2 Miscellaneous options TABLE 12 Error messages (Continued) Message Description Full err The number of times the Brocade Virtual ADX could not add a new PBSLB entry to the table because the PBSLB is already full. This value should indicate the number by which the downloaded pbslb table size exceeds the value that the Brocade Virtual ADX supports. When the PBSLB list is downloaded, it is first populated into a flat table that does not have any hierarchy.
Miscellaneous options 2 Adding a description You can add a description to a real server or virtual server. The description appears in the output of show commands and in the running-config and startup-config files. To add a description, enter commands such as the following. Virtual ADX(config)#server real RS20 10.2.3.
2 Miscellaneous options Configuring a TCP MSS value at the virtual server port level The default TCP MSS value configured on a Brocade Virtual ADX is 1460 Bytes. This value can be changed per virtual server port as shown in the following. Virtual ADX(config)#server virtual-name-or-ip v1 Virtual ADX(config-vs-v1)#port http tcp-mss 4000 Syntax: [no] port virtual-server-port tcp-mss mss-value The virtual-server-port variable specifies the TCP port that the MSS value will be applied to.
Miscellaneous options 2 Configuring TCP window scale option To configure the TCP window scale option in the TCP header and change the receive and transmit buffer sizes, enter the following commands at the tcp profile name configuration level as shown in the example: Virtual Virtual Virtual Virtual ADX(config)# tcp profile sample ADX(config-tcp-sample)# tcp-wnd-scale 1 ADX(config-tcp-sample)# rxbuf-size 3145278 ADX(config-tcp-sample)# txbuf-size 3145278 Syntax: [no] tcp-wnd-scale window_scale_factor The
2 Miscellaneous options 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 maximum number of TCP SYN requests to 3500, enter the following command. Virtual ADX(config)#server syn-limit 3500 Syntax: [no] server syn-limit max_requests The max_requests variable is maximum number of TCP SYN requests per second per server.
Miscellaneous options 2 The first command limits new TCP connections to the real server to 1000 per second. The second command limits the rate of new UDP connections to the real server to 800 per second. Syntax: max-tcp-conn-rate num Syntax: max-udp-conn-rate num The num variable specifies the maximum number of connections per second. There is no default. The maximum connection rate that can be configured is 4294967295.
2 Miscellaneous options Disabling port translation By default, the Brocade Virtual 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 Brocade Virtual ADX translates the application port in the client’s request from port 80 into 8080 before forwarding the request to a real server.
Miscellaneous options 2 Including the server client port in hash calculations When there are a small number of client IP addresses that connect to a Brocade Virtual ADX, the traffic distribution of IP addresses to the BPs might not be optimal. Where this is the case, it can be useful to include the client source port in the hash calculations. This configuration is achieved by running the following command.
2 Miscellaneous options Sending a TCP RST to a client that requests unavailable applications If a client requests an unavailable application, the Brocade Virtual ADX does one of the following: • Quietly drops the request. • Sends an ICMP Destination Unreachable message (for UDP or TCP). • Sends a TCP RST (for TCP only) – the default action.
Miscellaneous options 2 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 Brocade Virtual 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 session with the server. You can globally disable the TCP RST message from being sent under these circumstances.
2 Miscellaneous options Optimized fast-path SLB processing You can enable the Brocade Virtual ADX to use fast-path processing for stateful 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. When you enable fast-path processing, the Brocade Virtual ADX does not process every TCP or UDP packet in a given session in detail.
Miscellaneous options 2 To disable TCP fast aging and use the 1- to 2- minute aging time from previous releases, enter the following command. Virtual ADX(config)#server no-tcp-fast-age-on-server-reset Syntax: [no] server no-tcp-fast-age-on-server-reset Server opt-enable-route recalculation For optimized SLB, the Brocade Virtual ADX does not calculate a reverse route for every packet in a flow.
2 Miscellaneous options Enabling SYN ACK threshold The SYN ACK threshold specifies the number of contiguous unacknowledged TCP SYN ACKs the Brocade Virtual ADX allows to accumulate for a real server, before determining that the server is down and marking it FAILED. For examples and configuration information, refer to “Reassign threshold” on page 220. Syntax: server reassign-threshold number The number variable specifies the number of contiguous unacknowledged TCP SYN ACKs for the threshold.
Miscellaneous options 2 Configuring a host range If you want to use the Unlimited VIP feature to load balance a large set of contiguous IP addresses on the real server, configure a host range to create a range of contiguous virtual IP addresses (VIPs) based on the VIP address of the virtual server. The Brocade Virtual ADX creates the range by creating the number of VIPs that you specify with this command. You do not specify a range; you specify the number of hosts in the range.
2 Miscellaneous options • Allow "TCP only" or "UDP only" port definitions under virtual server • Allow similar definitions under real server also On a Brocade Virtual ADX, when a port is defined under VIP, both UDP and TCP traffic with the port number are enabled and passed through to the real server. This scenario is not desirable in some cases. As an enhancement, the user is allowed to define a TCP-only or UDP-only port so that only TCP or UDP traffic with the specified port number can pass through.
Miscellaneous options 2 Enabling normal UDP aging for DNS and RADIUS By default, the Brocade Virtual ADX immediately deletes a UDP DNS or RADIUS session table entry when the Brocade Virtual ADX receives a reply for the application from a real server. You can configure the Brocade Virtual ADX to instead age out DNS or RADIUS sessions normally using the UDP age timer. To age DNS or RADIUS sessions using the UDP age timer, enter the following command at the global CONFIG level of the CLI.
2 Miscellaneous options Virtual ADX(config)#server virtual-name-or-ip v1 Virtual ADX(config-vs-v1)#port snmp udp-age 26 Syntax: [no] port port udp-age minutes You can set the TCP or UDP age from 2 through 60 minutes. The default TCP age is 30 minutes. The default UDP age is five minutes.
Miscellaneous options 2 NOTE CPU utilization is not collected for every packet but every second. Consequently, the throttling decision might not always be accurate. Because of this, CPU utilization might go higher than the set threshold in some situations.
2 Miscellaneous options VIP route health injection VIP route health injection (RHI) allows the Brocade Virtual ADX to advertise the availability of an IPv4 or IPv6 VIP address (instead of a real host) throughout the network. Multiple Brocade Virtual ADX devices with identical VIP addresses and services can exist throughout the network. This feature allows the Brocade Virtual ADX VIP to be used in lieu of the same VIP on other Brocade Virtual ADX devices if the VIP is no longer healthy on those devices.
Miscellaneous options 2 percentage threshold is not configured), then the VIP port will be declared unhealthy. If you have configured the option where a VIP should be considered healthy if at least one VIP port is healthy, then the Brocade Virtual ADX will check if there are any other healthy VIP ports. If there are none, it will delete the VIP route.
2 Miscellaneous options For IPv6, enter commands similar to the following. Virtual ADX(config)#interface loopback 1 Virtual ADX(config-lbif-1)#ipv6 address 2001:db8::1/64 Virtual ADX(config-lbif-1)#ipv6 dont-advertise 2001:db8::1/64 Syntax: ipv6 dont-advertise ipv6-prefix/prefix length The following example of the display from the show ipv6 route command shows how dont-advertise routes are represented for IPv6 routes. As shown, the route type for these routes is “C (N)”.
Miscellaneous options 2 NOTE Where VIP hosts are classified as healthy, the Brocade Virtual ADX injects static host/subnet routes. If a VIP is found to be unhealthy, RHI withdraws the static host/subnet route but the feature remains enabled. Using the no server global-advertise-vip-route command (IPv4 and IPv6) disables RHI and causes all routes that were injected by RHI because of the global-advertise command to be withdrawn.
2 Miscellaneous options Defining the health of a VIP port globally To globally define the percentage of bound real server ports that must be healthy to consider a VIP port healthy, enter commands such as the following.
Miscellaneous options 2 NOTE If a VIP port is not bound to any real server ports, it will not be used for deciding the health of the VIP. If a VIP port is bound but you do not want to use it to determine the health of the VIP as described above, then configure the following for the VIP port.
2 Miscellaneous options If you configure a vip-route-mask-length as “96” then when this VIP becomes healthy, an IPv6 subnet route with a mask length of “96” is advertised as shown. S 2001:DB8::/96 2001:DB8::10 loopback 1 1/1 Where a user configures the vip-route-subnet-mask-length to the same values as the interface mask length, RHI injects two subnet static routes instead of one. In this situation the user will see two routes instead of one.
Miscellaneous options 2 The following examples display how the output from the show ip route command will differ for the same destination address for non-dangling and dangling VIPs. Notice that for dangling VIPs the “gateway” is specified as a non-valid route (IPv4 and IPv6). Also, the “interface” is specified as “drop” for IPv4 and “null” for IPv6. Display of these values is normal for dangling VIPs. Example of non-dangling VIPs Virtual ADX#show Total number Start index: default Destination 1 10.1.1.
2 Miscellaneous options VIP RHI and high availability topologies • Hot Standby topology - VIP RHI is only supported on the Brocade Virtual ADX Router (R) platform. A Hot Standby topology is not supported for the R code base. Therefore, VIP RHI is not applicable to Hot Standby topologies. • Symmetric and sym-active topologies - In both symmetric and sym-active topologies, only the owner of the VIP (the VIP in the active state) will inject the route.
Miscellaneous options 2 The following snap shot of the show ipv6 route command was taken from a Brocade Virtual ADX with VIP RHI enabled.
2 Miscellaneous options 4. Set the VIP, bind VIP ports to real server ports, and enable VIP RHI. Virtual Virtual Virtual Virtual Virtual ADXA(config)#server virtual-name-or-ip vip-vadx-A 10.1.1.10 ADXA(config-vs-vip-vadx-A)#port http ADXA(config-vs-vip-vadx-A)#bind http rs1 http rs2 http ADXA(config-vs-vip-vadx-A)#advertise-vip-route ADXA(config-vs-vip-vadx-A)#exit The configuration is similar for Brocade Virtual ADX B and C (with relevant interface IP addresses).
Miscellaneous options 2 server port 21 tcp server port 80 tcp server port 53 udp server port 161 udp server port 25 tcp server port 443 tcp server port 8601 tcp ! ! server real rs1 10.20.1.40 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "example9.com" port snmp port mms port rtsp ! server real rs2 10.20.1.41 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "example9.com" port snmp port mms port rtsp ! server real Web1 10.60.1.
2 Miscellaneous options server real Web8 10.60.1.47 port 8601 ! server real Web9 10.60.1.48 port 8601 ! server real Web10 10.60.1.49 port 8601 ! server remote-name rem1 10.80.1.40 port 8601 port ftp port smtp port ssl port dns port dns zone "example9.com" port snmp port mms port rtsp ! server remote-name rem2 10.80.1.41 port 8601 port ftp port smtp port ssl port dns port dns zone "example9.com" port snmp port mms port rtsp ! ! server virtual-name-or-ip vip60 10.60.1.
Miscellaneous options 2 ! vlan 1 name DEFAULT-VLAN by port ! vlan 10 by port untagged ethe 1 router-interface ve 1 ! vlan 20 by port untagged 2 router-interface ve 2 ! vlan 30 by port untagged ethe 3 router-interface ve 3 ! hostname Site1-VADX router ospf area 0 metric-type type1 redistribution connected redistribution static ! interface loopback 1 ip address 10.100.100.100 255.255.255.255 ip ospf area 0 ! interface ve 1 ip address 10.40.1.120 255.255.255.0 ip address 10.40.1.121 255.255.255.
2 Miscellaneous options tcp server udp server udp server tcp server tcp server tcp ! ! port 53 port 161 port 25 port 443 port 8601 server real rs1 10.120.1.40 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "example9.com" port snmp port mms port rtsp ! server real rs2 10.120.1.41 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "example9.
Miscellaneous options 2 ! server real Web9 10.60.1.48 port 8601 ! server real Web10 10.60.1.49 port 8601 ! ! server remote-name rem1 10.180.1.40 port 8601 port ftp port smtp port ssl port dns port dns zone "example9.com" port snmp port mms port rtsp ! server remote-name rem2 10.180.1.41 port 8601 port ftp port smtp port ssl port dns port dns zone "example9.com" port snmp port mms port rtsp ! ! server virtual-name-or-ip vip60 10.60.1.
2 Miscellaneous options vlan 1 name DEFAULT-VLAN by port ! vlan 10 by port untagged ethe 1 router-interface ve 1 ! vlan 20 by port untagged ethe 2 router-interface ve 2 ! vlan 30 by port untagged ethe 3 router-interface ve 3 ! hostname Site2-VADX ! router ospf area 0 metric-type type1 redistribution connected redistribution static ! interface loopback 1 ip address 10.100.100.101 255.255.255.255 ip ospf area 0 ! interface ve 1 ip address 10.140.1.120 255.255.255.0 ip address 10.140.1.121 255.255.255.
Miscellaneous options 2 Site 1 Brocade Virtual ADX in primary mode and Site 2 Brocade Virtual ADX in backup mode FIGURE 23 Primary mode and backup mode Site 1 configuration ! global-protocol-vlan ! ! server predictor round-robin server global-advertise-vip-route v4-only server rhi-active-bindings-threshold 80 server tcp server tcp server udp server udp port 21 port 80 port 53 port 161 Brocade Virtual ADX Server Load Balancing Guide 53-1003247-01 141
2 Miscellaneous options server port 25 tcp server port 443 tcp server port 8601 tcp ! ! server real rs1 10.20.1.40 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "example9.com" port snmp port mms port rtsp ! server real rs2 10.20.1.41 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "example9.com" port snmp port mms port rtsp ! server real Web1 10.60.1.40 port 8601 ! server real Web2 10.60.1.41 port 8601 ! server real Web3 10.60.1.
Miscellaneous options 2 server remote-name rem1 10.80.1.40 port 8601 port ftp port smtp port ssl port dns port dns zone "example9.com" port snmp port mms port rtsp ! server remote-name rem2 10.80.1.41 port 8601 port ftp port smtp port ssl port dns port dns zone "example9.com" port snmp port mms port rtsp ! ! ! server virtual-name-or-ip vip60 10.60.1.
2 Miscellaneous options untagged ethe 2 router-interface ve 2 ! vlan 30 by port untagged ethe 3 router-interface ve 3 ! hostname Site1-VADX router ospf area 0 metric-type type1 redistribution connected redistribution static ! interface loopback 1 ip address 10.100.100.100 255.255.255.255 ip ospf area 0 ! interface ve 1 ip address 10.40.1.120 255.255.255.0 ip address 10.40.1.121 255.255.255.0 secondary ip ospf area 0 ! interface ve 2 ip address 10.20.1.120 255.255.255.0 ip address 10.20.1.121 255.255.255.
Miscellaneous options 2 port 8601 protocol http protocol http url "HEAD /" interval 20 retries 4 l7-check healthck Web3-8601-chk tcp dest-ip 10.60.1.42 port 8601 protocol http protocol http url "HEAD /" interval 20 retries 4 l7-check healthck Web4-8601-chk tcp dest-ip 10.60.1.43 port 8601 protocol http protocol http url "HEAD /" interval 20 retries 4 l7-check healthck Web5-8601-chk tcp dest-ip 10.60.1.
2 Miscellaneous options healthck Web9-8601-chk tcp dest-ip 10.60.1.48 port 8601 protocol http protocol http url "HEAD /" interval 20 retries 4 l7-check healthck Web10-8601-chk tcp dest-ip 10.60.1.
Miscellaneous options 2 udp server port 25 tcp server port 443 tcp server port 8601 tcp ! ! ! server real rs1 10.120.1.40 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "example9.com" port snmp port mms port rtsp ! server real rs2 10.120.1.41 port http port http url "HEAD /" port ftp port smtp port dns port dns zone "example9.com" port snmp port mms port rtsp ! server real Web1 10.60.1.40 port 8601 port 8601 healthck Web1-chk ! server real Web2 10.60.1.
2 Miscellaneous options port 8601 healthck Web7-chk ! server real Web8 10.60.1.47 port 8601 port 8601 healthck Web8-chk ! server real Web9 10.60.1.48 port 8601 port 8601 healthck Web9-chk ! server real Web10 10.60.1.49 port 8601 port 8601 healthck Web10-chk ! ! server remote-name rem1 10.180.1.40 port 8601 port ftp port smtp port ssl port dns port dns zone "example9.com" port snmp port mms port rtsp ! server remote-name rem2 10.180.1.
Miscellaneous options 2 port snmp port ftp bind http rs1 http rs2 http bind dns rs1 dns rs2 dns bind snmp rs1 snmp rs2 snmp bind ftp rs1 ftp rs2 ftp ! ! vlan 1 name DEFAULT-VLAN by port ! vlan 10 by port untagged ethe 1 router-interface ve 1 ! vlan 20 by port untagged ethe 2 router-interface ve 2 ! vlan 30 by port untagged ethe 3 router-interface ve 3 ! hostname Site2-VADX router ospf area 0 metric-type type1 redistribution connected redistribution static ! interface loopback 1 ip address 10.100.100.
2 Application-specific SLB considerations Application-specific SLB considerations RTSP server load balancing The Brocade Virtual ADX natively understands protocol RTSP and provides load balancing for it. The Brocade Virtual ADX can also provide Layer 7 health checks for RTSP. Refer to “RTSP” on page 174 for details on Layer 7 health checks for RTSP. If RTSP is bound to an unknown port, use the following command to provide RTSP server load balancing.
Show and debug commands 2 Show and debug commands Refer to Appendix B, “SLB Show and Debug Commands” for a full list of show and debug commands.
2 152 Displaying the BP distribution Brocade Virtual ADX Server Load Balancing Guide 53-1003247-01
Chapter Stateless Server Load Balancing 3 Overview This chapter describes server load balancing configuration options that are “stateless.” Stateless SLB does not use session table entries for the TCP or UDP sessions between the Brocade Virtual ADX and clients or real servers.
3 Stateless TCP and UDP ports NOTE The Direct Server Return feature also allows server responses to take paths that do not pass back through the Brocade Virtual ADX. However, Direct Server Return still uses session table resources because the Brocade Virtual ADX creates a session table entry for the connection from the client to the real server. NOTE The Brocade Virtual ADX supports port translation for stateless SLB. Port translation is useful when clients connect to real servers directly.
Stateless TCP and UDP ports 3 If client 10.161.1.88’s Web browser sent the request from TCP port 8080, and the Brocade Virtual ADX’s hash calculation resulted in selecting real server 10.10.10.2, the packet would have the following address values: • • • • Source IP: 10.161.1.88 Source application port: 8080 Destination IP: Real server’s IP 10.10.10.
3 Stateless TCP and UDP ports Syntax: [no] port tcp/udp-portnum stateless The tcp/udp-portnum variable specifies the application port you want to make stateless. Disabling the stateless SLB hashing algorithm for UDP ports By default, stateless SLB uses a hashing algorithm to select a real server. The Brocade Virtual ADX calculates a hash value for a given client request based on the request’s source IP address and source TCP/UDP port. The request is sent to a real server corresponding to this hash value.
Stateless TCP and UDP ports 3 The tcp/udp-port variable specifies the application port you want to make stateless. The stateless parameter configures the port to be stateless. The tcp | udp parameter restricts stateless operation to the specified protocol (TCP or UDP). The no-hash parameter disables the SLB hashing mechanism for the port (and protocol, if specified). When hashing is disabled, the Brocade Virtual ADX uses the round-robin load balancing method to select a real server for each request.
3 Stateless TCP and UDP ports • Connections originating from real server ports other than the ports configured on the Brocade Virtual ADX as real server ports are not supported when fragmented. Example VIP: 10.11.1.1:80 rs1 10.1.1.1:80 and rs2 10.1.1.2:80 In this configuration, packets from rs1 and rs2 with a source port other than port 80 will exhibit unpredictable behavior when they are fragmented. In these cases, configure the virtual server as a statefull virtual server.
Chapter Health Checks 4 Health checks overview The Brocade Virtual ADX uses Layer 3, Layer 4, and Layer 7 health checks to verify the availability of real servers and of applications on the real servers. When you configure a real server, the Brocade Virtual ADX first sends an ARP request for the real server and then sends an IP ping to the server, to verify that the Brocade Virtual ADX can reach the server through the network.
4 Layer 3 health checks Table 13 summarizes the Layer 3 health checks. TABLE 13 Summary of Layer 3 health checks Type Description When performed ARP request A standard IP ARP request for the server’s MAC address, which the Brocade Virtual ADX adds to its ARP table. • When you configure a real server IP ping A standard ICMP-based IP ping.
Layer 4 health checks 4 Modifying the ping interval and ping retries The Brocade Virtual ADX automatically uses a Layer 3 health check, consisting of ICMP echo requests (pings), to check the health of a real server. Ping is enabled by default. However, you can modify the ping interval and the number of retries. To modify the ping interval, enter the following command.
4 Layer 4 health checks • UDP health check – The Brocade Virtual ADX sends a UDP packet with garbage (meaningless) data to the UDP port: - If the server responds with an ICMP “Port Unreachable” message, the Brocade Virtual ADX concludes that the port is not alive. - If the server does not respond at all, the Brocade Virtual ADX assumes that the port is alive and received the garbage data.
Layer 4 health checks 4 Table 14 describes the Layer 4 health check types performance and its description.
4 Layer 4 health checks Server response threshold health check The Brocade Virtual ADX distributes traffic among real servers based on a dynamic weight value derived from the caculated response time of health check packets. Using the same calculated response times, the Brocade Virtual ADX can perform Layer 4 and Layer 7 health checks. The Brocade Virtual ADX calculate Layer 4 and Layer 7 response times and compares those with the configured response threshold.
Layer 4 health checks 4 To display configuration information and statistics for the real server configured on the Brocade Virtual ADX, enter the following command: Virtual ADX(config)#show server real http HTTP keepalive statistics: HTTP statistics: URL replace cs: test = 3, fail = 0, malloc fail = 0 checksum: tested = 1, fail = 0, malloc fail = 0 No free ka port = 0, content match alloc fail = 0 Content match malloc = 0, free = 0 Bring port down = 0, retries = 0 TCP bring up statistics: send buf alloc fa
4 Layer 7 health checks • The Current Appl RTT field displays in microseconds the current application round trip time. If this value exceeds the configured l7 response threshold, the port is brought down. • The TCP RTT field is a smoothed l4 round trip time that is used by the response time predictor. • The Appl RTT field is a smoothed l7 round trip time that is used by response time predictor.
Layer 7 health checks • • • • • • 4 “RADIUS” on page 174 “RTSP” on page 174 “SMTP” on page 175 “SSL (complete)” on page 175 “SSL (simple)” on page 176 “Telnet” on page 176 Application ports The Brocade Virtual ADX selects a Layer 4 or Layer 7 health check based on whether the application port is known to the Brocade Virtual ADX. A Layer 4 health check is a TCP or UDP request and is not related to a specific application.
4 Layer 7 health checks DNS The Brocade Virtual ADX performs one or both of the following types of DNS health checks: • Address-based – The Brocade Virtual ADX sends an address request for a specific domain name. If the server successfully responds with the IP address for the domain name, the server passes the health check. • Zone-based – The Brocade Virtual ADX sends a Start-of-Authority (SOA) request for a specific zone name.
Layer 7 health checks 4 bind dns linux dns rs1 dns ! end NOTE If the addr_query or zone has a “.” at the end, the Brocade Virtual ADX will return “invalid packet” for Layer 7 DNS health check. FTP The Brocade Virtual ADX waits for a message from the server: • If the server sends a greeting message with status code 220, the Brocade Virtual ADX resets the connection and marks the port ACTIVE.
4 Layer 7 health checks HTTP (content verification) The Brocade Virtual ADX sends HTTP GET or HEAD requests to HTTP servers when using SLB. The GET or HEAD request specifies a page (identified by the URL) on the server. The Brocade Virtual ADX examines the page and compares the contents of the page to a list of user-defined selection criteria.
Layer 7 health checks 4 IMAP4 The Brocade Virtual ADX waits for a message from the IMAP4 server: • If the server sends a greeting message that starts with “* OK”, The Brocade Virtual ADX sends a Logout command to the IMAP4 port on the real server, resets the connection, and marks the port ACTIVE. • If the server does not send a greeting message that starts with “* OK”, the Brocade Virtual ADX retries the health check up to the number of times configured (the default is two retries).
4 Layer 7 health checks Authenticated bonding If a username and password are configured, the Brocade Virtual ADX sends an authenticated bind request to the LDAP server that includes three configurable parameters: the version number, the name of the directory object that the client wants to bind to, and information used to authenticate the Distinguished Name (DN). Brocade Virtual ADX then queries the LDAP directory using a user-configured search.
Layer 7 health checks 4 NNTP The Brocade Virtual ADX waits for a message from the NNTP server: • If the server sends a greeting message with status code 200 or 201, the Brocade Virtual ADX sends a Quit command to the NNTP port on the real server, then resets the connection by sending a quit and a RESET, one immediately after the other, and marks the port ACTIVE.
4 Layer 7 health checks RADIUS The Brocade Virtual ADX sends an authentication request with a user name, password, and key to the RADIUS server. The account information does not need to be valid for the server to pass the health check. In fact, to prevent someone from learning account information by observing the Brocade Virtual ADX RADIUS health check, Brocade recommends you use invalid information.
Layer 7 health checks 4 SMTP The Brocade Virtual ADX waits for a message from the SMTP server: • If the server sends a greeting message with status code 220, the Brocade Virtual ADX sends a Quit command to the SMTP port on the real server, then resets the connection by sending a quit and a RESET, one immediately after the other, and marks the port ACTIVE.
4 Layer 7 health checks SSL (simple) The Brocade Virtual ADX sends an SSL client hello with the SSL SID set to 0: • If the server responds, then the Brocade Virtual ADX resets the connection and marks the port ACTIVE. • If the server does not respond, the Brocade Virtual ADX retries the health check up to the number of times configured (the default is two retries).
Layer 7 health checks 4 NOTE The Brocade Virtual ADX uses its own management IP address or a source IP address configured on the Brocade Virtual ADX as the source IP address in the health check packets (as opposed to a virtual IP address). If the real servers are in the same subnet as the Brocade Virtual ADX, then the health checks can use the Brocade Virtual ADX’s management IP address. Otherwise, the health checks use a source IP address.
4 Layer 7 health checks HTTP Changing HTTP keepalive method, value, and status codes The Brocade Virtual ADX supports two kinds of HTTP health checks: • HTTP status code health checks look at the status code returned in HTTP responses to keepalive requests. • HTTP content verification health checks look at the actual HTML contained in HTTP responses to keepalive requests. The default URL page for HTTP keepalive requests used in HTTP health checks is “HEAD /1.0”.
Layer 7 health checks 4 DNS Enabling recursive DNS health checks By default, a Layer 7 health check for a DNS port sends the query only to the real server (DNS server). If the DNS server does not reply with the IP address or zone name requested by the health check, the port fails the health check. You can enable the real server to perform a recursive lookup for the IP address or zone requested by the health check.
4 Layer 7 health checks RADIUS Configuring RADIUS health check values You can define the RADIUS parameters that the Brocade Virtual ADX sends to a RADIUS application port during the Layer 7 health check. The RADIUS health check requires a specific user name, password, and authentication key from the RADIUS server. To specify these values, use one of the following methods. To configure the parameters for a RADIUS health check, enter commands such as the following at the real server level of the CLI.
Layer 7 health checks 4 Syntax: [no] port {ldap | ldaps | port-num} password string The string variable specifies the password for the Directory object that the Brocade Virtual ADX binds as; it is a character string that cannot exceed 64 characters. Configuring Base Distinguished Names for Authenticated LDAP Bonding To configure the base Distinguished Name (DN) used to query the LDAP directory, enter commands such as the following at the real port level of the CLI. Virtual ADX(config)#server real r1 192.
4 Layer 7 health checks Configuring Boolean LDAP health checks To configure a Boolean LDAPS health check, enter commands such as the following. Virtual Virtual Virtual Virtual Virtual ADX(config)#healthck check1 tcp ADX(config-hc-check1)#dest-ip 10.10.1.101 ADX(config-hc-check1)#port ldaps ADX(config-hc-check1)#protocol ldaps ADX(config-hc-check1)#l7-check A Layer 7 health check must be configured in order for the Brocade Virtual ADX to establish a secure connection on the LDAPS port.
Layer 7 health checks 4 SSL interface: ssl_read_data return error !!! ssl_receive_data but tcb->ssl is null SSL cleanup: can't find key ??? SSL interface: ssl_read_data return error !!! The Brocade Virtual ADX normally stops processing the rest of the data and releases the SSL control block data structure. However when the Brocade Virtual ADX does not do that, the Brocade Virtual ADX finds the SSL data structure is null and prints these messages.
4 Server and application port states Syntax: [no] tcp keepalive protocol TCP-port The protocol TCP-port parameters specify the type of Layer 7 health you want to use for the port. You can specify one of the following: • • • • • • ftp or 21 imap4 or 143 ldap or 389 pop3 or 110 smtp or 25 telnet or 23 Configuring an unknown UDP port to use a Layer 7 health check The Brocade Virtual ADX can perform Layer 7 health checks on the DNS port (UDP port 53).
Server and application port states TABLE 15 4 Server states State Description ENB:enabled There is no link to the real server. The real server is configured on the Brocade Virtual ADX but is not physically connected to the Brocade Virtual ADX. FAL:failed The real server has failed to respond to repeated Layer 3 health checks (IP pings). Typically, a real server changes to the FAILED state from the SUSPECT state.
4 Server and application port states TABLE 16 Application port states (Continued) State Description SUSPECT The Brocade Virtual ADX associates a time stamp with each packet sent to and received from the real servers. If the time gap between the last packet received from the server and the last packet sent to the server grows to 3 or 4 seconds, the Brocade Virtual ADX sends a Layer 4 health check to the service.
4 Port profiles and attributes Displaying virtual server state information To display virtual server information, enter the following command at any level of the CLI.
4 Port profiles and attributes Configuring a port profile For an application port not known to the Brocade Virtual ADX, the Brocade Virtual ADX assumes that it is a UDP port. In addition, the Brocade Virtual ADX does not perform keepalive health checks for it. You can configure a port profile for the port and specify whether the port is TCP or UDP, in addition to setting keepalive health check parameters for the port.
Port profiles and attributes 4 Adding a port and specifying its type By adding a port, you also automatically enable periodic Layer 4 (and Layer 7, if applicable) keepalive health checks for the port. If you do not specify the port type (TCP or UDP), the Brocade Virtual ADX assumes the port type is UDP. To add a port and specify that it is a TCP port, enter commands such as the following.
4 Port profiles and attributes TABLE 18 Port profile attributes (Continued) Attribute Description Keepalive port By default, the Brocade Virtual ADX bases the health of an application port on the port itself. You can specify a different application port for the health check. In this case, the Brocade Virtual ADX bases the health of an application port on the health of the other port you specify. Refer to “Basing a port’s health on the health of another port” on page 220.
4 Port profiles and attributes You also can change port attributes locally, on the real server and virtual server configuration levels. Port profiles simplify configuration by letting you characterize a port globally. For example, if many of your real servers use TCP port 80 (the well-known number for HTTP) and you want to change the keepalive interval for the port, you can do so globally. You do not need to change the value multiple times on each real server.
4 Port profiles and attributes Overriding the global TCP or UDP age The TCP and UDP ages specify how many minutes a TCP or UDP session can remain inactive before the Brocade Virtual ADX closes the session and clears it from its session table. You can set the TCP or UDP age from 2 through 60 minutes. The default TCP age is 30 minutes, and the default UDP age is 5 minutes.
Port policy 4 To change the smooth factor for an application port, enter a command such as the following. Virtual ADX(config-port-80)#smooth-factor 50 Syntax: smooth-factor num Port policy Port policies Server port policies help reduce the configuration required for health checks and provide more flexibility while configuring health checks.
4 Port policy 4. Configure a keepalive interval under a port policy. Virtual ADX(config-port-policy-p1)#keepalive-interval 5 Syntax: [no] keepalive-interval seconds Refer to “Configuring a keepalive interval under a port policy” on page 196 for more details. 5. (Optional) Enter the number of times the policy will be tried before the Brocade Virtual ADX marks the port as "UP" or "DOWN". Virtual ADX(config-port-policy-p1)#retries 5 Syntax: retries num The default is 3 tries. 6.
Port policy 4 Binding the policy After the policy is configured, return to the configuration level and bind the policy to a real server port. Virtual ADX(config)#server real r1 10.10.1.101 Virtual ADX(config-rs-name)#port 1234 use-port-policy p1 Syntax: server real real-server-name real-server-ip-address Syntax: [no] port port-num use-port-policy policy-name For the policy-name variable, enter the name of the policy you created.
4 Port policy Port Policy pp2 is bound to real server rs3 port 8080 and real server rs4 port 9090. These two ports have a keepalive interval of 30 seconds.
Port policy 4 After configuring the policy, bind it to a real server port. (Refer to “Binding the policy” on page 195 for details.
4 Element health checks Element health checks Introduction The Brocade Virtual ADX allows the creation of a health check that is customized for a given application server. Such definition is also known as element health check. You can specify the health check frequency, the number of retrials, and the number of other parameters for server health check.
Element health checks 4 These commands change the CLI to the configuration level for an element-action expression, then specify the IPv4 or IPv6 address of the real server and the application port on the server. Because the specified application is well-known to the Brocade Virtual ADX, the Brocade Virtual ADX automatically associates the default health check parameters for the port with the element-action expression.
4 Element health checks This command begins configuration of the element-action expression. The string variable specifies the name for the expression and can be up to 20 characters long. The tcp | udp parameter specifies whether you are configuring an expression for a TCP application port or a UDP application port. There is no default. Syntax: [no] dest-ip { ipv4-addr | ipv6-addr } The ipv4-addr variable specifies the IPv4 address of the real server.
Element health checks 4 This command specifies a port whose health-check mechanism you want to use for the port specified by the port command. You need to use this command only if the port specified by the port command is not one of the ports listed above but the port is the same type as one of the ports listed above. For example, use this command if you want to use the DNS health-check mechanism for a port other than 53.
4 Element health checks verification is contained in a matching list that is attached to one or more real servers. The following is an example of the commands used to set up a matching list. For information on how to configure the match lists, refer to “Configuring HTTP content matching lists” on page 208. Syntax: [no] protocol dns | 53 [addr_query "name" | zone zone-name] This command changes one of the following DNS health-check parameters.
Element health checks Virtual Virtual Virtual Virtual 4 ADX(config-hc-check4)#protocol ssl content-match m1 ADX(config-hc-check4)#l7-check ADX(config-hc-check4)#enable ADX(config-hc-check4)#exit Syntax: [no] protocol ssl use-complete Changing the health-check interval and retries By default, the Brocade Virtual ADX performs a health check every 5 seconds.
4 Element health checks Changing the health-check type For TCP application ports, you can change the health-check type between Layer 4 and Layer 7. By default, the Brocade Virtual ADX performs a Layer 7 health check in the following cases: • The port is one of the following ports well-known to the Brocade Virtual ADX: - FTP – port 21. (Ports 20 and 21 both are FTP ports but on the Brocade Virtual ADX, the name “FTP” corresponds to port 21.
Element health checks 4 The l4-check command configures the Brocade Virtual ADX to use the Layer 4 health check for the application port in the element-action expression. Because the application port in this element-action expression is HTTP, the Brocade Virtual ADX will use the Layer 4 health check for TCP.
4 Element health checks Displaying health-check policies and their status To display a list of the configured health-check policies and their current status, enter the following command. Virtual ADX(config-hc-check1)#show healthck Total nodes: 6; Max nodes: 128 Name Value Enable Type Dest-IP Port Proto Layer -------------------------------------------------------------------------------check1 TRUE YES tcp 10.10.10.50 http http l4-chk check2 TRUE YES tcp 10.10.10.40 http http l7-chk check3 TRUE NO udp 10.
Element health checks TABLE 19 4 Health-check policy status (Continued) Field Description Proto For element-action expressions, the health-check method to be used for the port. NOTE: If the value is " - ", the protocol has not been specified and the port is not well-known to the Brocade Virtual ADX. Layer The type of health check, which can be one of the following: l4-chk – Layer 4 TCP or UDP health check. l7-chk – Layer 7 application-specific health check.
4 Health check with content match Health check with content match Content match for HTTP Configuring HTTP content matching lists The Brocade Virtual ADX currently supports compound and simple content-matching statements under the match-list configuration. This enhancement adds support for "start" and "end" statements in the match-list configuration.
Health check with content match 4 NOTE The HTTP page file size returned by the server should be less than 100kb. When an HTML file meets more than one set of selection criteria in a matching list, the Brocade Virtual ADX takes one of the following actions: • If the strings that meet the selection criteria are different, the Brocade Virtual ADX takes action based on the string that comes first in the file.
4 Health check with content match The default command specifies what happens if none of the HTML text in the HTTP response message meets the selection criteria. You can specify either up or down; the default is up. If the real server responds to the health check with a RST, the port is marked ACTIVE or FAILED depending on what was specified in the default statement in the matching list. The log parameter causes the following warning message to be logged when the selection criteria is met.
Health check with content match 4 In this example, the port http content-match m4 command binds matching list m4 to real server rs1. HTTP response messages coming from real server rs1 are examined using the selection criteria in matching list m4. The port http url command sets the method used for HTTP keepalive requests and the URL of the page to be retrieved.
4 Health check with content match The following commands configure a port profile for port 12345 and specify that the port is a TCP port. The no-fast-bringup command is necessary because it prevents the Brocade Virtual ADX from marking a port ACTIVE until it passes both Layer 4 and Layer 7 health checks.
Health check with content match 4 Using a scripted health check in a health-check policy A scripted health check can be used in a health-check policy. A health-check policy is a group of one or more health checks attached to a real server port. When the scripted health check checks the health of a destination port specified in the policy, the health-check policy can be evaluated to true or false depending on the response from the server.
4 Health check with content match Scripted health check enhancement on real servers When the port port-name command is configured with the content-check send option to send a string to the server, the Brocade Virtual ADX establishes a TCP connection, and on receiving a SYN-ACK, sends the configured string to the server. The device then waits for the server to send ASCII text and then brings the server port up or down, based on the configured match-list policy.
Health check with content match 4 The match-list-name variable defines the name of the matching list used in the binary scripted health check. Syntax: [no] port port-name content-check-carray send Carray-data The port-name variable defines the port where the binary scripted health check is performed. The Carray-data variable defines the binary data in C array format used in the binary scripted health check. The maximum number of characters supported is 2000.
4 Boolean health checks Boolean health checks Boolean health-check policies You can configure a group of Layer 4 and Layer 7 health checks as a health-check policy and associate the group with a specific application port on a real server.1 Health-check policies enable you to assess the health of any application port using the health-check mechanisms for ports well-known to the Brocade Virtual ADX.
Boolean health checks 4 Follow the steps given below to use a health-check policy. 1. Configure the element-action expressions. 2. Configure the health-check policy using element-action expressions and logical expressions joined by the operators AND or OR or NOT. 3. Attach logical expressions to application ports on specific real servers. A health check policy does not take effect until you attach it to an application port on a server.
4 Boolean health checks The address 00e0.5208.dd8e is the MAC address of Link3's access router interface. The vlan-id 40 is the Brocade Virtual ADX’s interface, that is used to connect Link3's access router is in VLAN 40 Syntax: next-hop-mac-address mac-address vlan-id vlan# Using a nested health-check policy If you want to use a single health-check policy to test more than two IP addresses, configure health-check policies for all the IP addresses, and use them in another health-check policy.
Miscellaneous health check settings 4 Miscellaneous health check settings Basing an alias port’s health on the health of its master port By default, the Brocade Virtual ADX performs health checks for alias ports independently of the master ports on which they are based. For example, if you configure alias port 8080 and base the port on port 80 (its master port), the Brocade Virtual ADX checks the health of 80 and 8080 independently.
4 Miscellaneous health check settings Basing a port’s health on the health of another port You can configure the Brocade Virtual ADX to base the health of a port that is not well-known to the Brocade Virtual ADX on the health of one of the following ports that are well-known to the Brocade Virtual ADX: • DNS (port 53) • FTP (port 21). Ports 20 and 21 both are FTP ports but on the Brocade Virtual ADX, the name “FTP” corresponds to port 21.
Miscellaneous health check settings 4 NOTE It is possible to take a service down without triggering the reassign threshold. For example, if no new TCP SYN packets are being sent to a real server that has its application disabled, the real server will not fail to respond to enough consecutive TCP SYNs to meet the reassign threshold. As a result, the Brocade Virtual ADX indicates the real server and the service are ACTIVE when in fact they might have been disabled.
4 Miscellaneous health check settings Globally disabling all health-check policies You can easily disable all the health-check policies configured on the Brocade Virtual ADX. To do so, enter the following command at the global CONFIG level of the CLI. Virtual ADX(config)#no server l4-check NOTE This command also disables the TCP and UDP Layer 4 health checks for all applications that are not associated with a health-check policy.
Miscellaneous health check settings FIGURE 24 4 Health check of remote server – learned MAC address is not used In this example, the Brocade Virtual ADX sends the health check through its default gateway. The default gateway sends the health check back to the Brocade Virtual ADX, because Router R1’s route to the remote server lists the Brocade Virtual ADX as the next hop. Despite the unnecessary trip through the default gateway, the health check still reaches the remote server.
4 Miscellaneous health check settings Syntax: [no] server identify-server-by-ip Health check of multiple websites on the same real server If you host multiple websites on the same real server, with each website using a different VIP, you can perform an independent health check for each VIP. One method for binding two VIPs to the HTTP port on the same real server, you create an alias for the HTTP port on one of the VIPs.
Miscellaneous health check settings 4 Minimum healthy real servers under VIP port The minimum healthy servers feature allows a VIP port to handle traffic only if the a configured number of real server ports bound to the VIP port are healthy and UP. This would allow virtual servers to stay down unless they have enough server capacity to handle the load. Command line interface The command to turn on minimum healthy servers feature is under virtual server configuration.
4 Miscellaneous health check settings Overview The Brocade Virtual ADX uses the server slow-start mechanism to adjust the maximum number of connections that can be established for a real server that has just gone online. The Brocade Virtual ADX begins with a connection limit that is lower than the maximum configured value (which is one million by default) and gradually increases this connection limit until the maximum configured value is reached.
Miscellaneous health check settings 4 • At 21 seconds,the Brocade Virtual ADX allows a max-connection rate of 20 times the elapsed time. The Brocade Virtual ADX increases the connections to 420 and from 22 seconds to 29 seconds, the Brocade Virtual ADX allows up to 20 new connections every second. • At 30 seconds, the maximum number of connections is reached. The graph on the right shows how the maximum number of connections allowed for the real server increases over the 30-second slow-start period.
4 Miscellaneous health check settings When a port on a real server becomes active, the Brocade Virtual ADX applies the default slow-start mechanism to regulate how quickly connections for the port are established. In addition, you can set up a user-configured slow-start mechanism that regulates how quickly connections are established for specific ports on specific real servers.
Miscellaneous health check settings 4 • From 30 seconds to 40 seconds, the Brocade Virtual ADX allows up to 40 new connections every second. • From 40 seconds to 50 seconds, the Brocade Virtual ADX allows up to 50 new connections every second. • From 50 seconds to 60 seconds, the Brocade Virtual ADX allows up to 100 new connections every second.
4 Miscellaneous health check settings Syntax: slow-start list-id rate1 interval1 rate2 interval2 max-connections In the slow-start command, the list-id variable specifies the slow-start list. This variable can be a number from 1 through 1000000. When you apply the slow-start list to a port on a real server, you refer to the slow-start list by the variable specified here. You can create multiple slow-start lists for a given port and assign them each an ID number.
Miscellaneous health check settings 4 Using the slow-start list defined above, the two graphs in Figure 28 illustrate how a user-configured slow-start mechanism ramps up the connections for a port on a real server. The graph on the left shows the rate at which the number of HTTP connections increases over the slow-start period. The graph on the right shows how the maximum number of HTTP connections the Brocade Virtual ADX allows for real server rs1 increases over the slow-start period.
4 Miscellaneous health check settings The graph on the right shows how the maximum number of possible HTTP connections for real server rs1 increases over the slow-start period: • Ten seconds after going online, the maximum number of HTTP connections real server rs1 can have is 300: a maximum of 10 (rate 1) new HTTP connections per second for 30 (interval 1) seconds equals 300 total HTTP connections for real server rs1.
Miscellaneous health check settings 4 To globally re-enable slow-start, enter a command such as the following. Virtual ADX(config)#no server no-slow-start Syntax: [no] server no-slow-start FIN close for server health check FIN close replaces the RESET close for a TCP health check. To enable FIN close, use the following command.
4 Miscellaneous health check settings Enhanced server bringup Enhanced Server Bringup increases the speed of the bringup process by sending more (up to a maximum of 50) health-checks at one time. In previous releases, the Brocade Virtual ADX sent a health check for each real server port in a configuration, in the process of bringing up all of the ports.
Sample show commands 4 The Brocade Virtual ADX now tracks the health status of port 80. If the health-check state of port 80 is DOWN, then all the other ports in the track-port list will have their health-check state as also DOWN. In this case, FTP and DNS have their master state as DOWN and traffic is not load balanced on these ports. Syntax: [no] hc-track-port port ...port The port variable specifies the secondary ports that will be tracked based on the health of the primary port.
4 Sample show commands NOTE The log messages do not distinguish between Layer 4 and Layer 7 health checks. When the status changes based on either type of health check, the Brocade Virtual ADX logs the event as shown in this example. Session table parameters The Brocade Virtual ADX maintains state information for TCP and UDP connections in the session table. The session table contains an entry for each TCP and UDP session between the Brocade Virtual ADX and a client or real server.
Sample show commands 4 For this change to take effect, you must save the change to the startup-config file, then reload the software using the following commands. Virtual ADX(config)#write memory Virtual ADX(config)#end Virtual ADX#reload Configuring fast session aging The Brocade Virtual ADX supports fast session aging.
4 Sample show commands When the number of available sessions drops below the value specified for the random-threshold variable, sessions are aged out randomly, without regard to session age, until the number of free sessions exceeds the threshold. The value specified for the random-threshold variable is expressed as a percentage of the maximum number of sessions available on the Brocade Virtual ADX. The value specified for the random-threshold variable can be from 1 through 30 percent.
Sample show commands 4 Clearing statistics counters for sessions that aged out randomly If the random threshold is configured, you can clear the statistics counters for sessions aged out randomly, by entering the following command. Virtual ADX(config)#clear server random-age-counters Syntax: clear server random-age-counters This command resets the "Random-aged : total" counter and corresponding "last 60 sec" counter as displayed by the show server sessions command.
4 Sample show commands For DNS and RADIUS UDP load balancing, the age value does not follow the normal configuration and default value unless the udp-normal-age option is configured on the port, under the virtual server port definition, the port dns udp-normal-age command. (Refer to “Enabling normal UDP aging for DNS and RADIUS” on page 121.) The default UDP age will always be 2 minutes unless the udp-normal-age option is configured.
Sample show commands 4 The time value in this example is in the format for devices on which the system time add date have not been set. NOTE The feature description and command syntax use the terms “session” and “connection”. A connection consists of multiple sessions, for the send and receive directions. NOTE Because the log messages are generated when the software creates a session table entry, features that do not use session table entries do not result in log messages.
4 242 Sample show commands Brocade Virtual ADX Server Load Balancing Guide 53-1003247-01
Chapter Layer 7 Content Switching 5 Overview CSW enables Layer 7 application content based traffic direction for non-HTTP protocols such as Financial Information Exchange (FIX) protocol. This chapter describes the Layer 7 Switching features in the Brocade Virtual ADX. • “Layer 7 content switching” on page 243 • “Layer 7 content switching on HTTP response” on page 271 NOTE Fast session synch is not supported in Layer 7 or TCP-offload configurations.
5 Layer 7 content switching • Support for persisting requests to servers, along with simple forwarding actions • Support for content-rewrite functions, including cookie and HTTP header insertion and deletion To configure Layer 7 content switching, you define content switching rules and policies.
Layer 7 content switching 5 Brocade Virtual ADX will not run the server load balance predictor algorithm to choose a new server. It will just use the same real server for the current request. If the next request goes to a different server group, the Brocade Virtual ADX will follow the current code behavior to perform server section. The following command enables use of a load balancing predictor.
5 Layer 7 content switching This example creates a rule called r1 that matches if an incoming packet contains the PUT method. Syntax: [no] csw-rule rule-name method eq method-string The rule-name variable is the name of the rule and can be up to 80 characters in length. The method-string variable can be GET, HEAD, POST, OPTIONS, PUT, DELETE, TRACE, PROPFIND, MOVE, CONNECT, BDELETE, PROPPATCH, COPY, LOCK, UNLOCK, MKCOL, BCOPY, BMOVE, POLL, SUBSCRIBE, SEARCH, BPROPPATCH, RPC_OUT_DATA, or RPC_IN_DATA.
Layer 7 content switching TABLE 23 5 URL rules for Layer 7 content switching (Continued) URL rule name Description Syntax Example URL Equals Matches if the URL string is equal to the specified value. [no] csw-rule rule-name url equals value csw-rule r1 url equals "/home.html" URL Search [no] csw-rule rule-name url Matches if the search value URL string contains any one of up to five specified values. This type of rule can be used with the persist action.
5 Layer 7 content switching TABLE 24 HTTP header rules for Layer 7 content switching (Continued) HTTP header rule name Description Syntax Example Header Equals Matches if the contents of the specified HTTP header field are equal to the specified value. [no] csw-rule rule-name header header-name equals value csw-rule r1 header "host" equals "www.example4.com" Header Search Matches if the specified HTTP header field contains any one of up to five specified values.
Layer 7 content switching TABLE 25 5 XML tag rules for Layer 7 content switching (Continued) XML tag rule name Description Syntax Example XML Tag Equals Matches if the contents of the specified XML tag are equal to the specified value. [no] csw-rule rule-name xml-tag tag-name equals value csw-rule r1 xml-tag "name" equals "george" XML Tag Search Matches if the specified XML tag contains any one of up to five specified values. This type of rule can be used with the persist action.
5 Layer 7 content switching CSW policies A policy specifies the action to take when a rule is matched. You can specify the following actions in a policy: • Forward action – Causes the Brocade Virtual ADX to forward packets matching a specified rule to a specified real server or server group. Refer to “Configuring the forward action” on page 250. • Reply-error action – Causes the Brocade Virtual ADX to send a 403 error code page back to the client when the specified rule is matched.
Layer 7 content switching 5 NOTE The real server ID range is limited to 1024-1+the maximum number of real servers that can be configured on the Brocade Virtual ADX. For example, if the maximum server limit is 16384, then the valid real server ID range is from 1024 to 1024-1+16384=17407. If you specify a server group ID, you can optionally specify a cookie name.
5 Layer 7 content switching The hash-to--bucket persist method is illustrated in the following figure. FIGURE 29 Hash-to-bucket persist method For a given rule, you can configure a primary persist action and a secondary persist action. If the primary persist action does not return a valid persist string, or if the server indicated by the primary persist string is not available, the Brocade Virtual ADX uses the secondary persist action to direct packets to a server.
Layer 7 content switching 5 The persist-method variable specifies which of the following persist methods you want to use. • hash-to-bucket – Hashes the persist string to a hashing bucket, as illustrated in Figure 29. This is the default. • hash-to-group-id – Hashes the persist string to a server group ID, instead of to a hashing bucket. • group-or-server-id – Translates the persist string to the ID of a real server or server group.
5 Layer 7 content switching By default, the format of the Syslog message is as follows.
Layer 7 content switching 5 Damaging a cookie Cookie damage consists of altering the cookie header so that it does not contain any cookie that matches the name of the cookie inserted by the Brocade Virtual ADX. For example, the following command causes the Brocade Virtual ADX to damage the cookie indicated by the rewrite insert-cookie command in the HTTP response when rule r1 is matched.
5 Layer 7 content switching Configuring Rewrite request-delete HTTP URL Rewrite allows the Brocade Virtual ADX to delete a string or portion of a string from inside the incoming client request, as described in the following sections: • • • • “Deleting a matched-string” on page 256 “Deleting content at positive offset” on page 257 “Deleting content at negative offset” on page 258 “Deleting a string” on page 259 Deleting a matched-string To configure a request to delete a matched string in a CSW rule, fo
Layer 7 content switching 5 In this case, "-sample" is the deleted string that CSW rule r11 matches. The request is forwarded to the server with server ID 1025, which is defined by primary CSW action match r11 forward 1025. The URLs in the following two HTTP request messages show the difference between the original request and the rewritten request.
5 Layer 7 content switching The URL prefix "/abc" is matched, offset 0 is at the second "/", which is right after the matched prefix "/abc" in the URL, which is defined in CSW "r12a"; so offset 4 is number "1" which is 4 bytes away after the letter "c". The result is that the 2 bytes containing "12" are deleted in the URL. Example Original HTTP request: GET /abc/xyz12/index.html HTTP/1.1\r\n Host: www.foo.com\r\n User-Agent: Mozilla/5.0 Netscape/7.
Layer 7 content switching 5 Example Original HTTP request: GET /abc/xyz/default_index.html HTTP/1.1\r\n Host: www.example5.com\r\n User-Agent: Mozilla/5.0 Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=brocadenet; userid=12345\r\n \r\n Example Rewritten HTTP request: GET /abc/xyz/default.html HTTP/1.1\r\n Host: www.example5.com\r\n User-Agent: Mozilla/5.0 Netscape/7.
5 Layer 7 content switching \r\n Example Rewritten HTTP request: GET /abc/xyz/index.html HTTP/1.1\r\n Host: www.example5.com\r\n User-Agent: Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=brocadenet; userid=12345\r\n \r\n Configuring Rewrite request-insert Content insertion allows the Brocade Virtual ADX to insert any string either right after the matched string found by the CSW rule, or at any specified offset in the content located by the matched CSW rule.
Layer 7 content switching 5 The highlighted URLs in the following two HTTP request messages show the difference between the original request and the one after being rewritten. Example Original HTTP request: GET /abc/xyz/index.html HTTP/1.1\r\n Host: www.example5.com\r\n User-Agent: Mozilla/5.0 Netscape/7.02\r\n Accept-Charset: ISO-8859-1\r\n Cookie: name=brocadenet; userid=12345\r\n \r\n Example Rewritten HTTP request: GET /abc/hello-world/xyz/index.html HTTP/1.1\r\n Host: www.example5.
5 Layer 7 content switching The highlighted URLs in the following two HTTP request messages show the difference between the original request and the rewritten request. Offset 0 is at the first "x," which is right after the matched prefix "/ abc/," as defined in CSW "r22". Therefore, negative offset 5 is at the first "/," which is 5 bytes away from and before the "x." The result is that string "/hello-world" is inserted at the first "/", which is the beginning of URL "/abc/xyz/index.html".
Layer 7 content switching 5 Syntax: match rule-name rewrite request-replace matched-string new-string The rule-name variable defines the name of CSW rule. The matched-string keyword defines the matched string (defined by CSW rule), which is to be replaced. The new-string variable defines the new string that replaces the previous string. NOTE The following information assumes you have already completed the previous configuration.
5 Layer 7 content switching The old-string variable defines the string to be replaced, if it can be found in the URL defined by the CSW rule. If the old-string variable is not found, the replacement will not happen. The new-string variable defines the string with which the old string is to be replaced. NOTE The following information assumes you have already completed the previous configuration. Because the URL contains the pattern "abc," rule r32 will be hit.
Layer 7 content switching 5 HTTP redirect status code The Brocade Virtual ADX can be configured to use a temporary or permanent move to suit different application requirements: • 301 - To redirect the HTTP request to a new, assigned permanent URI. • 302 (the default) -To redirect HTTP requests to a temporary URI. To redirect an HTTP request with redirect code 301, enter the following command. Virtual ADX(config)#csw-policy p1 Virtual ADX(config-csw-p1)#match r1 redirect "brocade.
5 Sample configurations Offset 0 points to "\r", which is the next byte after "www.example5.com" in the value of "Host" header, "www.foo.com". Sample configurations The HTTP URL Rewrite feature allows the Brocade Virtual ADX to dynamically rewrite URL content in an HTTP request. Also, the HTTP URL Rewrite options allow you to insert, delete, and replace URL content at any offset in an HTTP request.
Sample configurations 5 CSW topology Figure 30 shows a simple CSW network topology. FIGURE 30 CSW network topology For the CSW configuration shown in Figure 30, the following rules apply: • The Brocade Virtual ADX receives incoming traffic on HTTP port, VIP 10.1.1.100. • The Brocade Virtual ADX is configured with content switching (CSW) rules and policies. Policy 1 is defined to rewrite URL content and forward the request to the Web server 1.
5 Sample configurations Creating a policy with HTTP URL Rewrite To define a CSW rule and create a CSW policy with HTTP URL Rewrite options, follow these steps. 1. Define a CSW rule to match a URL pattern in an HTTP header. Virtual ADX(config)#csw-rule r11 url pattern /xyz Syntax: csw-rule rule-name url pattern url-content 2. Define a CSW rule to match a prefix string in an HTTP header. NOTE Only one rule is required for configuring HTTP URL Rewrite.
Sample configurations 5 NOTE For more information about offsets, refer to “Explanation of offsets” on page 265. 9. Specify default action for client requests that do not match any other rules. Send such requests to the Web server with ID 1026. Virtual ADX(config-csw-mypolicy)#default forward 1026 Syntax: default forward server-id Configuring real and virtual servers To configure the real and virtual servers, follow these steps. 1. Define a real server (1) with an IP address.
5 Sample configurations Enabling content switching To enable content switching, follow these steps. 1. Bind the policy to virtual HTTP port on virtual server. Virtual ADX(config-vs-csw-vip)#port http csw-policy mypolicy Syntax: port http csw-policy policy-name 2. Enable CSW on the virtual port. Virtual ADX(config-vs-csw-vip)#port http csw Syntax: port http csw HTTP URL Rewrite configuration summary The following example shows a summary of the configuration steps.
Layer 7 content switching on HTTP response 5 Layer 7 content switching on HTTP response The Brocade Virtual ADX can perform content rewrite on the server responses. In other words, the Brocade Virtual ADX can not only modify requests in the forward direction, but also the responses in reverse direction. The HTTP response is divided into the "header" part and the "body" part. The Brocade Virtual ADX can selectively rewrite the header, body, or both.
5 Layer 7 content switching on HTTP response Creating a CSW rule specifying the header response codes In this step, the header response codes are specified, and a response is inspected only if those codes are found. For example, to specify the redirect response code, the following configuration is required.
Using multiple cookies under virtual server port 5 In this configuration, the Brocade Virtual ADX rewrites the HTTP response. Whenever response code 301 or 302 appears in the header, together with a redirect URL http://www.example6.com (signified by the Location header), the Brocade Virtual ADX replaces the URL with https://www.example6.com. In other words, "Location: http://www.example6.com" becomes "Location: https://www.example6.com.
5 Using multiple cookies under virtual server port NOTE Spoofing can be configured with the port port number spoofing command under the virtual server configuration. This can also be achieved by configuring l3-default-gateway. Configuring cookie insertion in default mode (when no CSW rule is hit) To configure cookie insertion in default mode (when no CSW rule is hit), use the following command.
Server passive cookie persistence 5 Example The Brocade Virtual ADX does cookie switching based on the cookie value of "ServerID" or "biz" defined in either rule1 or rule2. If both rule1 and rule2 are not hit but rule3 is hit, it will forward the request to server group 10 and insert a cookie with name "biz", with path being "business". If no rule is hit, the Brocade Virtual ADX will take the default action.
5 Server passive cookie persistence together with the real server that is responsible for the cookie. Client requests are then monitored for the cookie value associated with the server and a hash value is generated. Where this hash value is equal to the value stored in the sticky session with the real server, client requests are sent to that real server. For example in Figure 32, a client sends an initial request to the HTTP port at VIP address: “10.10.10.1”. The real server at IP address “172.16.0.
Server passive cookie persistence 5 • “Creating a CSW rule to match the client request” • “Specifying a CSW action to create persistence information” • “Specifying a CSW action to perform persistence lookup and retrieve real server information” Creating a CSW rule to match the server response To create a CSW rule to match the server response, use the following command.
5 Server passive cookie persistence Once the offset point is set by the persistence-string-offset, the system will parse the search-string variable matched in the specified CSW rule up-to the number of characters defined by the value of the persistence-string-length variable. The value of the persistence-string-length variable must be greater than 0 (zero).
Server and server port persistence with CSW nested rules 5 3. The Client clicks on the link: www.test.com/test/nextpage.html?PSrvrID=1234567 If cookies are enabled, the Client sends: “Cookie: PSrvrID=1234567” If cookies are disabled, NO cookie is sent back. 4. The load balancer analyzes the incoming request as described: If “cookie” is found in the header (Cookie:), the cookie value is looked up in the session table for the session bound to the same server. If no cookie is found, the URL can be analyzed.
5 Server and server port persistence with CSW nested rules Also, the current CSW supports the persistence on the group or server ID. Support of persistence on the real server port gives you more granular control. This feature is to be used with persistence on the group or server ID and is useful when the customer has multiple ports configured on the same group or server, and also wants to direct the request to a particular port instead of load balancing among all the ports.
Server and server port persistence with CSW nested rules 5 Usage example The customer needs the following request: • • • • Two real servers, 192.168.1.100 and 192.168.1.101. Each server has a different application listening on different ports: 10500 and 10520. Each server is configured to a different group, 30 and 31. The request with “pweb” and “jsession=groupid”embedded in the URL is directed to the specified group. The configuration is as follows.
5 Displaying CSW information Displaying CSW information Displaying header information To display information about the HTTP headers encountered in a Layer 7 content switching configuration, enter the following command.
Displaying CSW information TABLE 26 5 Output from the show csw-hdr-info command (Continued) Field... Description Known header list Name The name of each known header field encountered. Hdr Tab Ind The offset in the header table. Known header count: The number of unknown headers encountered. XML tag list Name The name of each XML tag encountered. Hdr Tab Ind The offset in the XML tag table. Ref Co The reference count of the number of XML rules using this header.
5 Displaying CSW information To display detailed information for a specified rule, enter a command such as the following.
Displaying CSW information 5 Displaying CSW policy information To display information about a Layer 7 content switching policy, enter the following command on the BP.
5 Displaying CSW information To display detailed information about a policy, enter a command such as the following.
Displaying CSW information TABLE 30 5 Output from the show csw-policy detail command (Continued) Field Description Database Count The number of search databases. XML Tag Count The number of XML tags used in the policy. Parse Mask Mask to indicate the parsing information. Parse Tags The header or XML tags to be parsed. Vip Bindings The list of VIPs and port numbers using this policy.
5 Displaying CSW information TABLE 31 Layer 7 Rewrite information (Continued) Field Description Cookie Deleted The total number of cookies deleted in HTTP requests. Cookie Deletion Err The number of errors that occurred when deleting cookies in HTTP requests. Cookie Destroyed The number of cookies destroyed during HTTP requests. Cookie Destroy Err The number of errors that occurred while destroying cookies in HTTP requests.
Usage guidelines TABLE 32 5 Layer 7 Switching statistics (Continued) Field Description Slot freed Number of proxies finished Slot alloc fail Number of proxy allocation failures Pkt freed Number of packets stored by proxy Max slot alloc Maximum number of concurrent proxies Pkt freed Number of packets freed by proxy Fwd Stored pkt Number of stored packets sent to server Session T/O Number of session timeouts Sess T/O pkt free Number of stored packets freed due to session timeout Session
5 Miscellaneous Layer 7 switching configurations The offset variable defines the distance of bytes from the offset 0. By default, offset 0 is right after the interested string defined by matched CSW rule. The Keyword offset or neg-offset indicates that the insertion offset starting after or before the offset 0. Support for large GET requests The Brocade Virtual ADX can perform Layer 7 Content Switching on large GET requests (up to 20,000 bytes). Earlier releases supported up to 8,000-byte GET requests.
Miscellaneous Layer 7 switching configurations 5 The default TCP window size is 8000 bytes. Setting the TCP window size to 1460 bytes causes a client to send only one packet before waiting for the Brocade Virtual ADX to send an ACK, assuming a Maximum Segment Size (MSS) of 1460 bytes. This setting applies only to SYN ACK and ACK packets sent from the Brocade Virtual ADX to the client.
5 Miscellaneous Layer 7 switching configurations clients that originally created the connections. When a client makes a request for content that is served by a different server, the Brocade Virtual ADX closes the connection to the original server on the server side before setting up a connection with the new server; however, the connection on the client side can still be reused if keepalive mode is enabled on the client connections.
Miscellaneous Layer 7 switching configurations 5 This feature works only when Content Switching is enabled on a virtual server port. if pipelined HTTP requests are sent in one connection, the Virtual ADX makes the switching decision based on the first request and forwards only the first request to the real server. When the real server sends a complete response to the first request, the Virtual ADX will forward the response to the client.
5 Miscellaneous Layer 7 switching configurations Displaying transactions and connections To display information about the transactions and connections for Layer 7 switching over keepalive connections, enter the following command. Virtual ADX4/1#show server session keep-alive Avail.
Miscellaneous Layer 7 switching configurations 5 Layer 7 CSW pseudo stack client-side retransmission handling The Brocade Virtual ADX Content Switching (CSW) pseudo stack needs to store HTTP request packets from the client before it is able to perform server selection. If the stored packets are not acknowledged by the CSW pseudo stack and these packets get dropped before reaching the server, they can be retransmitted by the client.
5 Miscellaneous Layer 7 switching configurations Displaying the Layer 7 CSW client-side retransmission handling information In order to display information about Layer 7 CSW client-side retransmission handled by the Brocade Virtual ADX, use the show server proxy keep-alive command. A truncated display is shown: Virtual ADX#show server proxy keep-alive Keep-alive connection statistics: ... Client-side statistics: In seq. packets = 412 Out of seq.
5 Miscellaneous Layer 7 switching configurations Layer 7 CSW pseudo stack server-side TCP packet out-of-sequence handling With the current Layer 7 Content Switching (CSW) pseudo stack, the Brocade Virtual ADX expects all TCP packets from the server-side to arrive in-sequence. If the server-side TCP packets are received out-of-sequence, the Brocade Virtual ADX will silently drop the out-of-sequence TCP packets and then wait for either the TCP stack timeout to expire, or for the server to retransmit.
5 Setting up SSL session ID switching The fields described in Table 34 provide statistics about out-of-sequence (oos) TCP packets. TABLE 34 Out-of-sequence TCP packets statistics Field Description Total stored oos pkt The total number of out-of-sequence packets buffered by the Brocade Virtual ADX. Total freed oos pkt The total number of out-of-sequence packets transmitted by the Brocade Virtual ADX. The number variable specifies the number of database entries.
Setting up SSL session ID switching 5 SSL session ID workflow Figure 33 illustrates how the initial SSLHP messages exchanged between a client and server, client_hello and server_hello, establish an SSL Session ID. FIGURE 33 How the SSL Handshake Protocol Establishes a Session ID If the value in the session_id field that the client sends to the server is non-zero, the Brocade Virtual ADX can connect the client to the server that originally sent the Session ID value.
5 Setting up SSL session ID switching FIGURE 34 How the Brocade Virtual ADX uses an SSL Session ID to Select a Real Server Client sends initial client_hello message with empty session_id 1 Client Internet Remote Access Router 4 When client wants to resume session, it sends a client_hello message containing the session_id it received from the server 5 3 Brocade Virtual ADX stores session_id value in an internal database that maps session_id values to real servers 2 Real server rs10 responds wi
Setting up SSL session ID switching 5 Configuration Example Configuring the real servers for SSL To configure the real servers for SSL shown in Figure 34, enter commands such as the following. Virtual Virtual Virtual Virtual Virtual Virtual ADX(config)#server real-name rs10 10.157.22.10 ADX(config-rs-rs10)#port ssl ADX(config-rs-rs10)#exit ADX(config)#server real-name rs20 10.157.22.
5 Command reference Adjusting the maximum number of session_id-to-real-server associations By default, the Brocade Virtual ADX can store in its database 8,192 entries associating a session_id with a real server. You can change the maximum number of database entries to any larger value up to 256,000 by entering a command such as the following. Virtual ADX(config)#server max-ssl-session-id 256000 Syntax: server max-ssl-session-id number The number variable specifies the number of database entries.
Command reference 5 rewrite request-insert Use the rewrite request-insert option in the CSW policy configuration mode to insert content, as shown in the following. Virtual ADX(config-csw-mypolicy)#match r11 rewrite request-insert abc offset 4 Syntax: match rule-name rewrite request-insert {[ASCII-string [neg-offset decimal | offset decimal]] | client-ip | header} The ASCII-string variable specifies the value of the string for the offset options, listed below, in the insert request.
5 304 Command reference Brocade Virtual ADX Server Load Balancing Guide 53-1003247-01
Chapters the Hot Standby High Availability 6 Overview This chapter describes the Hot Standby high availability (HA) feature for the Brocade Virtual ADX. In Hot Standby HA, two Brocade Virtual ADX devices must be in a network that you configure to serve as a redundant pair (primary and secondary). One Brocade Virtual ADX is always active while the other Brocade Virtual ADX is always standby (idle).
6 Overview Hot Standby HA protocol operations Figure 35 illustrates a typical Hot Standby HA configuration. FIGURE 35 Typical Hot Standby HA When Brocade Virtual ADX-A initializes in a Hot Standby HA configuration, it is in the standby state. When it sends Hello messages and no other Brocade Virtual ADX responds to these messages, Brocade Virtual ADX-A sets itself to the active state. When Brocade Virtual ADX-B initializes, it also goes through Hello-message processing.
Hot Standby HA configuration modes 6 When the entire synchronization process is completed, Brocade Virtual ADX-B calculates Brocade Virtual ADX-A router-port plus server-port count. • If the Brocade Virtual ADX-A count is greater than or equal to Brocade Virtual ADX-B, Brocade Virtual ADX-A remains in the active state and Brocade Virtual ADX-B remains in the standby state.
6 Hot Standby HA Configuration Considerations Promiscuous mode with shared MAC option When a server does not honor gratuitous ARP, the virtual switch in the ESX hypervisor needs to be set to promiscuous mode. This mode is known to the Brocade Virtual ADX based on an optional keyword configured in the server backup ethernet port vlan-id vlan MAC [shared-mac] command, where MAC is normally one of the HA sync port MAC out of the two Brocade Virtual ADXs.
Configuring standard Hot Standby HA 6 NOTE You must use a dedicated port for the HA sync link. 2. Configure the server backup port, shared MAC address between the Brocade Virtual ADX devices, and any connected router ports: Virtual ADX-A(config)#server backup ethe 3 000c.290d.
6 Configuring standard Hot Standby HA Virtual ADX-B#write memory .Write startup-config in progress. .Write startup-config done. Virtual ADX-B#reload 5. Use show server backup and show log to obtain the Brocade Virtual ADX status in the Hot Standby HA configuration. The following screen shots display the different stages of reload and show how a Brocade Virtual ADX comes up in a Hot Standby HA configuration.
Configuring standard Hot Standby HA 6 Now Brocade Virtual ADX B comes up with Brocade Virtual ADX A already up and running. Virtual ADX-B#show server backup Server Backup port = 3 Backup group id = 0 Switch state = Standby SLB state = 0<------------------------- Goes from 0>1>2>3>4>0 Share MAC = Off Peer sync state = 0 SLB Partner MAC valid= 0 SLB Partner MAC = 000c.290d.e85f <----- Peer MAC appears when SLB state returns to 0 SLB Partner HA sync port MAC = 000c.290d.
6 Additional configuration variations TABLE 35 Field descriptions for show server backup command (Continued) Field Description Share MAC Indicates whether the shared-mac option through the server backup command is set. The state is one of the following: • Off indicates that the virtual switch is set to non-promiscuous mode. • On indicates that the virtual switch is set to promiscuous mode.
Additional configuration variations 6 Figure 37 shows a configuration with the VIP and servers in different subnets.
6 Configuring additional HA parameters Source-NAT in Hot Standby Figure 38 shows a configuration for seamless failover in Hot Standby when Source-NAT is enabled.
Configuring additional HA parameters 6 Configuring a backup group ID Hot Standby HA redundancy enables a Brocade Virtual ADX to serve as an automatic backup for another Brocade Virtual ADX. Each Hot Standby HA pair consists of two Brocade Virtual ADX devices. You can configure up to 127 Hot Standby HA pairs within a single L2 broadcast domain. To enable this support, configure a backup group ID on each of the Brocade Virtual ADX devices. Both Brocade Virtual ADX devices in a given pair have the same ID.
6 Configuring additional HA parameters NOTE The backup timer must have the same value on both Brocade Virtual ADX devices in the HA pair. To set the backup timer on a Brocade Virtual ADX in an HA pair, enter the following command. Virtual ADX(config)#server backup-timer 50 This command sets the backup timer to 5 seconds (50 * 100 milliseconds).
Configuring additional HA parameters 6 To enable this feature, enter the following command. Virtual ADX(config)#server backup-vip-cnt Syntax: [no] server backup-vip-count Configuring failover based on the number of active virtual ports You can configure the HA peer to fail over based on router ports and active virtual ports, instead of just the router ports (default) or the combination of router ports and virtual servers as described in “Configuring failover based on active VIP count”.
6 Configuring additional HA parameters Delayed failover With this feature configured, when a Brocade Virtual ADX device detects a failover condition because of a VIP/VPORT count change, the failover will be delayed. At the end of the period of delay, the Brocade Virtual ADX device examines the conditions that led to the failover condition and performs a failover if the conditions still apply. If they no longer apply, the failover will be cancelled. To enable this feature, enter the following command.
Configuring the forwarding of synchronizing messages 6 Configuring the forwarding of synchronizing messages In a Hot Standby HA configuration, the active Brocade Virtual ADX and the backup Brocade Virtual ADX continuously communicate through synchronizing messages. These messages contain Layer 4 –Layer 7 session status information and are only used by the Brocade Virtual ADX devices. Some of the messages can travel over a non-dedicated private link between the two Brocade Virtual ADX devices.
6 Hot-standby HA with routing protocols NOTE Manual alteration of the cost or the metric of the routing protocols can affect the traffic forwarding by the HA pair. For internal BGP (IBGP), you need to enable the compare-med-empty-aspath flag on the upstream and downstream router for cost and MED to be considered for route selection. The BGP RFC defines all vendor support.
Hot-standby HA with routing protocols 6 Tie state of virtual link and HA physical link using health checks The Brocade Virtual ADX virtual interface is unaware of the state of the physical interface and this result is an inconsistent port state. In HA scenarios, failover cannot be triggered even if the associated physical interface is down. Hence, the virtual interface state is tied with that of the physical interface.
6 322 Hot-standby HA with routing protocols Brocade Virtual ADX Server Load Balancing Guide 53-1003247-01
Chapter SIP Server Load Balancing 7 SIP overview The Session Initiation Protocol (SIP) is a signaling protocol used by numerous IP communication products to create session-oriented connections between two or more endpoints in an IP network. SIP is emerging as the preferred technology for Voice over IP (VoIP) implementations. Application-aware network switches play a vital role in increasing the uptime and availability of IP-based services such as VoIP.
7 SIP overview SIP packet flow Figure 40 demonstrates the basic operation of SIP; location of an endpoint, signal of a desire to communicate, negotiation of session parameters to establish the session, and tear-down of the session after completion. FIGURE 40 SIP packet flow The example in Figure 40 shows packet exchange between two SIP clients, also known as User Agent Clients (UACs). In the figure each message is labeled with the letter "F" and a number for reference.
SIP overview 7 SIP is based on an HTTP-like request-and-response transaction model. Each transaction consists of a request that invokes a particular method, or function, on the server, and at least one response. In this example, the transaction begins with User1's SIP phone sending an INVITE request addressed to User2's SIP URI. The INVITE request contains a number of header fields.
7 SIP overview The 200 OK message is routed back through the SIP proxy server to the User1's SIP phone, which then stops the ringback tone and indicates that the call has been answered. Finally, User1's SIP phone sends an acknowledgement (ACK) message to User2's SIP phone to confirm the reception of the final response (200 OK). This ACK is sent directly from User1's SIP phone to User2's SIP phone, bypassing the SIP proxy server.
SIP overview 7 SIP message headers This section describes SIP message headers that you might find useful when making decisions about SIP server load balancing. Call-ID The Call-ID is a header field that appears in all SIP requests and responses. This header field acts as a unique identifier to group together all messages belonging to the same call. It must be the same for all requests and responses sent by either the UAC or UAS in a dialog.
7 SIP SLB and call persistence SIP SLB and call persistence Figure 41 shows an overview of a Virtual ADX SIP server load balancing implementation. FIGURE 41 Virtual ADX SIP Server Load Balancing implementation There are three kinds of SIP servers: • Proxy server • Redirect server • Registrar server In Figure 41, the Virtual ADX SIP SLB uses the Domain-1 VIP to load balance SIP requests from Client A (user1) or Client B (user2) among Domain 1 proxy servers and registrar servers.
SIP SLB and call persistence 7 • CANCEL • BYE • OPTIONS Additionally, the following methods are supported: • SUBSCRIBE • NOTIFY • Other proprietary methods SIP and call persistence specifications The SIP server load balancing has the following specifications: • By default, server selection is persistent on Call-ID. • Pass-through SIP traffic from real SIP servers to SIP clients gets translated. The Virtual ADX replaces the source IP (SIP server real IP) with Virtual IP (VIP).
7 SIP SLB and call persistence Sample deployment topologies Virtual ADX switches offer application-aware advanced intelligence for SIP server load balancing. The following sections describe some SIP server load balancing scenarios. SIP server load balancing with DSR mode Figure 42 shows an SIP server farm built around Virtual ADX application switches.
SIP SLB and call persistence 7 The proxy server receives the INVITE request and sends a 100 (Trying) message to User1's SIP phone. Because the Virtual ADX switch is configured in DSR mode, the response message that is sourced from the virtual IP address flows directly to User1's SIP phone, bypassing the Virtual ADX.
7 SIP SLB and call persistence SIP server load balancing with non-DSR mode Figure 44 shows a SIP server farm with proxy servers connected inline (non-DSR mode) with the Virtual ADX switch.
Configuring SIP SLB 7 SIP server health monitoring There are two types of SIP servers of particular importance: SIP proxy servers and SIP registrar servers. The Virtual ADX supports advanced UDP Layer-7 application health checks for both server types. Virtual ADX switches can be enabled to send REGISTER or OPTION messages to SIP servers to track their health.
7 Configuring SIP SLB Configuring a SIP proxy server and enabling health check Complete the following steps to configure a real SIP proxy server and its health check. 1. Configure a real server and IP address for a proxy server and enter the real server configuration mode. Virtual ADX(config)#server real proxy-server-1 10.1.3.1 Syntax: [no] server real name ip address 2. Specify the SIP port.
Configuring SIP SLB 7 Configuring a SIP registrar server and enabling health check Complete the following steps to configure a real SIP registrar server and its health check. 1. Configure a real server and IP address for a registrar server and enter the real server configuration mode. Virtual ADX(config)#server real registrar-1 10.1.5.1 Syntax: [no] server real name ip_address 2. Specify the SIP port. Virtual ADX(config-rs-registrar-1)#port sip Syntax: [no] port sip 3.
7 Configuring SIP SLB 3. Specify a registrar proxy server. Virtual ADX(config-rs-registrar-proxy-server-5)#port sip sip-both-registrar-proxy-server Syntax: port sip [sip-both-registrar-proxy-server] [health-check-method [ options | register ] ] [health-check-no-dsr] • sip-both-registrar-proxy-server—Identifies the server as a SIP registrar server or a proxy server. • • • • health-check-method—Specifies the SIP health check method. options—Enables health check through OPTION messages.
Configuring SIP SLB 7 Configuring a SIP virtual server Complete the following steps to configure SIP SLB virtual redirect-proxy servers and virtual proxy domains, and bind real servers to virtual servers. 1. Configure a virtual proxy domain name and IP address for Domain 1 and enter the virtual server configuration mode. Virtual ADX(config)#server virtual-name-or-ip proxy-domain-1 10.1.6.9 Syntax: [no] server virtual-name-or-ip name ip address 2. Specify the SIP port and SIP switch.
7 Configuring SIP SLB SIP SLB over UDP (stateful SLB mode) SIP SLB over UDP makes SIP stateful and adds the intelligence needed to handle different Caller-ID situations. SIP stateful basic configuration 1. Configure a real server. Virtual ADX(config)#server real rs 10.2.2.2 Virtual ADX(config)#port sip sip-proxy-server Virtual ADX(config)#port sip sip-both-registrar-proxy-server health-check-method register 2. Configure a virtual server. Virtual ADX(config)#server virtual-name-or-ip sip_vip 10.1.1.
Configuring SIP SLB 7 Additional SIP session-specific commands The following global configuration commands are related to SIP SLB. They will affect all virtual servers with stateful SIP SLB. The commands will not have any effect on the old stateless SIP SLB. Stateless SIP SLB will still follow the hash table and ages accordingly. Configuring the maximum number of SIP sessions Use the server sip session max-sip-sessions command to configure the maximum entries of SIP sessions.
7 Configuring SIP SLB Show commands for displaying SIP sessions NOTE The show sip session command does not count SIP sessions. Use the show sip server command to display SIP-related real server information. • “Showing sip session info” • “show sip server” Showing sip session info Use the show sip session info command to display information on SIP session usage. Virtual ADX#show sip session info Syntax: show sip session info Virtual ADX#show sip session info slot-9 cup-1 Avail.
Configuring SIP SLB 7 Syntax: show sip debug [parser | session| sip-transaction | udp-process] Debugging SIP sessions Virtual ADX#show sip debug session SIP Session Debug Counters SIP SESSION GET :4381 SIP SESS FREE LIST CORUPT :0 SIP SESS FINAL FREE :84 SIP SESS AGED :60 SIP SESS CORRUPT :0 SIP HA AGE SYNC RECV :0 SIP HA OUT OF IPC BUF :0 SIP HA SESS CREAT RECV :0 SIP HA DEL MSG RECV :0 SIP HA DEL ATTEMPT SENT :0 SIP HA CREATE EXIST :0 SIP SIP SIP SIP SIP SIP SIP SIP SIP SIP SIP SESSION GET FAILURE SE
7 Configuring SIP SLB Debugging SIP packet traces The show sip debug packet-trace command shows the packets with the IP address of either src-or-dest-IP-1 or src-or-dest-IP-2. The output displays packet processing starting from parsing to forwarding. The command is very useful in debugging; however, it only displays in the BP console not on rconsole. Syntax: show sip debug packet-trace src-or-dest-IP-1 src-or-dest-IP-2 The following example is a display of session packet processing shown on a BP console.
SIP SLB command reference 7 SIP SLB command reference This section describes the syntax and usage for each SIP Server Load Balancing command in the real server configuration mode and the virtual server configuration mode. Real server configuration mode Use the port sip command in the real server or virtual server configuration mode to configure a proxy, redirect, registrar, or registrar-proxy server. These commands are issued from the real server configuration.
7 SIP SLB command reference port sip dsr port sip sip-switch bind sip rs1 sip rs2 sip 344 Brocade Virtual ADX Server Load Balancing Guide 53-1003247-01
Chapter IPv6 Support for Server Load Balancing 8 Overview NOTE The Brocade Virtual ADX software release 3.0.00 IPv6 support for SLB applies to IPv6 clients and IPv6 server communications only. The commands to configure server load balancing, including configuration of virtual servers, real servers, VIP groups, health check parameters, and others are the same for IPv6 as they are for IPv4. The existing commands have been enhanced to accept IPv6 addresses.
8 Defining IPv6 real servers Defining IPv6 real servers Virtual Virtual Virtual Virtual Virtual Virtual ADX(config)#server real ADX(config-rs-rs3)#port ADX(config-rs-rs3)#port ADX(config-rs-rs3)#port ADX(config-rs-rs3)#port ADX(config-rs-rs3)#exit rs3 2001:db8::a http http http url "HEAD /" dns Virtual Virtual Virtual Virtual Virtual Virtual ADX(config)#server real ADX(config-rs-rs4)#port ADX(config-rs-rs4)#port ADX(config-rs-rs4)#port ADX(config-rs-rs4)#port ADX(config-rs-rs4)#exit rs4 2001:db8::5 h
VLAN and tagging definitions 8 VLAN and tagging definitions Virtual ADX(config)#vlan 1 name DEFAULT-VLAN by port Virtual ADX(config-vlan-1)#exit Virtual Virtual Virtual Virtual Virtual ADX(config)#vlan 110 by port ADX(config-vlan-10)#tagged ethe 1 to 2 ADX(config-vlan-10)#untagged ethe 3 ADX(config-vlan-10)#router-interface ve 10 ADX(config-vlan-10)#exit Miscellaneous Virtual Virtual Virtual Virtual Virtual Virtual ADX(config)#aaa authentication web-server default local ADX(config)#no enable aaa consol
8 IPv6 configuration example Example SLB session output Virtual ADX# show session all 0 Session Info: Flags - 0:UDP, 1:TCP, 2:IP, 3:INT, 4:INVD, H:sessInHash, N:sessInNextEntry Index ===== 0 0 348 Src-IP ============= 2001:db8:2::4 2001:db8:2::3 Dst-IP ============= 2001db8:2::20 2001db8:1::10 S-port ====== 80 53366 D-port ====== 10241 80 Age === 32 32 Server ====== rs1 rs1 Flag ========== oSLB 1 H 6 oSLB 1 H 6 Brocade Virtual ADX Server Load Balancing Guide 53-1003247-01
Appendix Server-specific Loopback Configurations A Overview You can configure loopback addresses on some common types of real servers. NOTE The information in this appendix 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.
A Windows NT Windows NT To configure a loopback interface on Windows NT, you need to configure a new network adapter. Use the following procedure. This procedure applies to the following products: • • • • Microsoft Windows 2000 Professional Microsoft Windows 2000 Server Microsoft Windows 2000 Advanced Server Microsoft Windows 2000 Datacenter Server NOTE When you add a loopback interface to Windows NT, it sometimes creates a route that has the same address as the loopback interface.
A Windows NT [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.
A Windows NT 2. Delete the route that has the same address as the loopback interface. C:\>route delete 192.168.200.0 mask 255.255.255.0 192.168.200.106 3. Display the route table again to verify that the unwanted route is gone . C:\>route print Active Routes: Network Address 0.0.0.0 10.0.0.0 192.168.200.0 192.168.200.106 192.168.200.251 192.168.200.255 224.0.0.0 224.0.0.0 10.255.255.255 Netmask 0.0.0.0 255.0.0.0 255.255.255.0 255.255.255.255 255.255.255.255 255.255.255.255 224.0.0.0 224.0.0.0 255.255.
Windows NT A 3. Display the route table again to verify the results. In this example, Windows 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 finished with this procedure. C:\users\default>route print Active Routes: Network Address 0.0.0.0 10.0.0.0 192.168.200.0 192.168.200.106 192.168.200.250 192.168.200.255 224.0.0.0 224.0.0.0 255.255.255.255 Netmask 0.0.0.
A Windows NT 7. Display the route table again to verify that the table contains the gateway route but does not contain a route with the loopback address. C:\users\default>route print Active Routes: Network Address 0.0.0.0 10.0.0.0 192.168.200.0 192.168.200.106 192.168.200.250 192.168.200.255 224.0.0.0 224.0.0.0 10.255.255.255 354 Netmask 0.0.0.0 255.0.0.0 255.255.255.0 255.255.255.255 255.255.255.255 255.255.255.255 224.0.0.0 224.0.0.0 255.255.255.255 Gateway Address 192.168.200.254 10.0.0.1 192.168.
Appendix SLB Show and Debug Commands B Using show source-ipsource ip [real-server ip | all] The show source-ip source-ip command displays the IP information, free ports, owner, start, and end for port pools for a specific source IP. The show source-ip source ip real-server-ip command displays the free ports, owner, start, and end for port pools for the specified source IP addresses and real server.
B Using the show session all command Using the show session all command Use the show session command (available at the BP console only) to determine if the sessions have been created correctly. Virtual ADX#rconsole 1 1 Virtual ADX1/1#show session all 0 Session Info: Flags0:UDP, 1:TCP, >:fwdSess, +:userCntFlgSet, D:sessInDelQ, F:fin_setFlg, A:acked * before age indicates that the static bit is set Index Src-IP ===== ====== 0 10.0.0.5 1 10.0.0.5 2 10.1.1.15 3 10.1.1.15 4 10.1.1.42 5 10.1.1.42 6 10.1.1.
Using the source-ip-debug command B Using the source-ip-debug command NOTE This command should only be used for debugging purposes, because enabling it could impact performance. You can configure the following command to enable debugging for source IP. Virtual ADX(config)#source-ip-debug Syntax: [no] source-ip-debug Using the debug filter command The Brocade Virtual ADX debug filter is a packet capture utility that captures packets at the Brocade Virtual ADX itself based on user-defined filters.
B Using the debug filter command Configuring Capture Buffer You have to specify the size of the capture buffer in kilobytes.
Using the debug filter command B Table 36 displays the Ethernet Filter settings. TABLE 36 Ethernet Filter Settings CLI Command Filter Type mac bcast Ethernet broadcast packets mac dest mac-address Packets with the specified destination MAC address mac mcast Ethernet multicast packets mac src mac-address Packets with the specified source MAC address mac type type-in-hex Packets of the specified Layer 3 type Table 37 displays the IP Filter settings.
B Using the debug filter command TABLE 39 UDP Filter Settings CLI Command Filter Type tcp ack TCP packets with the ACK flag on tcp push TCP packets with the PSN flag on tcp urgent TCP packets with the URG flag on Pattern matching filter settings You can set up a filter to capture packets that contain a pattern of a specified length, starting from a given offset from the beginning of the packet.
Using the debug filter command B Syntax: show Use reset at the filter ID configuration level to restore the filter IDs default settings (match ALL): Virtual ADX(debug-filter-spec-1)#reset Syntax: reset Use exit to leave the filter ID configuration level. Virtual ADX(debug-filter-spec-1)#exit Virtual ADX(debug-filter)# Syntax: exit It is also possible to display the setting for a filter ID at the "debug filter" level.
B Using the debug filter command You can apply multiple filter IDs and specify an and/or relationship between them. For example, to apply filter IDs 1 and 2, enter the following command. Packets that match the filters in both filter IDs are stored in the capture buffer. Virtual ADX(debug-filter)# apply "1 and 2" This is useful to create more complex filtering rules.
Using the debug filter command B Stop Capturing Process You can stop the packet capture utility with the following command: Virtual ADX(debug-filter)# stop Number of packets captured: 126 Syntax: stop View Captured Packets First of all you have to select one of the places where packets are captured.
B Using the debug filter command ! server virtual vs222 192.168.8.222 port http bind http rs101 http Task: Get a packet capture of an HTTP request coming from the client IP 192.168.8.100 to the virtual server 192.168.8.222 including the packets going to the real server 192.168.9.101. The source IP of the client request is 192.168.8.100 and the destination TCP port is 80. The backend traffic is as well using the client IP 192.168.8.100 because we do not have source-nat configured.
Using the debug filter command B Check ALL BPs to find the BP responsible for the test client: telnet@Virtual telnet@Virtual telnet@Virtual telnet@Virtual telnet@Virtual telnet@Virtual ADX(debug-filter)#view bp 1 1 ADX(debug-filter-1-1)#sum ADX(debug-filter-1-1)#view bp 1 2 ADX(debug-filter-1-2)#sum ADX(debug-filter-1-2)#view bp 1 3 ADX(debug-filter-1-3)#sum NOTHING SO FAR - CHECK THE NEXT AND LAST PROCESSOR TALKING ABOUT THE ADX1016-4: telnet@Virtual ADX(debug-filter-1-3)#view bp 1 4 telnet@Virtual ADX
B Using the debug filter command 0... .... = Reserved .1.. .... = Do not fragment ..0. .... = Last fragment Fragment offset(LSB 13 bits): 0 (0x00) Time to live: 128 seconds/hops IP protocol type: TCP (0x06) Checksum: 0x4be2 IP address: 192.168.8.100 ---> 192.168.8.222 No option Transmission Control Protocol Port 3881 ---> 80 Sequence Number: 4047880147 Acknowledgement Number: 2434401980 Header Length(MSB 4 bits): 5 (32-bit word) Reserved(LSB 4 bits): 0 Code: 0x18 RES: 0... .... CON: .0.. .... URG: ..0. ..
Using the debug filter command B Fragment offset(LSB 13 bits): 0 (0x00) Time to live: 128 seconds/hops IP protocol type: TCP (0x06) Checksum: 0x4be2 IP address: 192.168.8.100 ---> 192.168.9.101 No option Transmission Control Protocol Port 3881 ---> 80 Sequence Number: 4047880147 Acknowledgement Number: 2434401980 Header Length(MSB 4 bits): 5 (32-bit word) Reserved(LSB 4 bits): 0 Code: 0x18 RES: 0... .... CON: .0.. .... URG: ..0. .... ACK: ...1 .... PSH: .... 1... RST: .... .0.. SYN: .... ..0. FIN: .... .
B Displaying global Layer 4 Brocade Virtual ADX configuration Now you can copy the file to a TFTP server. Use one of the following methods: • From a Linux console: [root@Virtual ADX pcap]# tftp -p -l a1.cap -r z1.cap 10.24.132.85 a1.cap is the local file and z1.cap is the remote file name. • From the CLI or Management console: Virtual ADX#copy file tftp 10.24.132.85 b1.cap /opt/ADX/pcap/a1.cap b1.cap is the remote file name and a1.cap is the local file name.
Displaying global Layer 4 Brocade Virtual ADX configuration B Table 40 lists the displayed information. TABLE 40 Global layer 4 configuration information Field Description SLB Parameters Predictor The load balancing metric in effect on the Brocade Virtual ADX.
B Displaying global Layer 4 Brocade Virtual ADX configuration TABLE 40 Global layer 4 configuration information (Continued) Field Description Global TCP/UDP Parameters TCP-age The number of minutes the Brocade Virtual ADX allows a TCP connection to remain unused before closing the connection. The default is 30. To change this parameter, refer to “Configuring TCP age” on page 239. The value shown here is the global value.
B Displaying real server information and statistics Displaying real server information and statistics Using the show server real command Use the show server real command to view real IP addresses as well as configuration information and basic statistics for all the real servers configured on the Brocade Virtual ADX.
B Displaying real server information and statistics TABLE 41 Real server information (Continued) Field Description State 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: • ACT: Active • ENB: Enabled • FAL: Failed • TST: Test • DIS: Disabled • UNK: Unknown • UNB: Unbind • AWU: Await-unbind • AWD: Await-delete NOTE: HLD: Held-down.
Displaying real server information and statistics B Using the show server real detail command Use the show server real detail command to view information not only about a specified real server, but also information about the various ports configured on that server.
B Displaying real server information and statistics TABLE 42 Real server detail information Field Description Port The TCP/UDP port name or number. This field can have one of the following values: • default • 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 Brocade Virtual ADX, the name “ftp” corresponds to port 21.
Displaying real server information and statistics TABLE 42 B Real server detail information (Continued) Field Description Ms 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 Brocade Virtual ADX sends a client’s request for the tracking port to the same real server as the master port.
B Displaying real server information and statistics TABLE 42 Real server detail information (Continued) Field Description Rx throughput Rate at which packets are received expressed in Kbps. Tx throughput Rate at which packets are transmitted expressed in Kbps.
Displaying virtual server information and statistics B Displaying virtual server information and statistics Use the show server virtual command to view information about the virtual servers configured on the Brocade Virtual ADX.
B Displaying virtual server information and statistics TABLE 43 378 Virtual server information (Continued) Field Description ACL ID Displays the ID of the Access Control List (ACL) policy bound to the virtual server Predictor The load balancing predictor the Brocade Virtual ADX uses to balance traffic among the real servers bound to this virtual server.
Displaying virtual server information and statistics TABLE 43 B Virtual server information (Continued) Field Description TCP/UDP Port Information and Statistics Port State The TCP/UDP port name or number. This field can have one of the following values: default 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 Brocade Virtual ADX, the name “ftp” corresponds to port 21.
B Displaying a list of failed servers TABLE 43 Virtual server information (Continued) Field Description DSR Displays the state of the Direct Server Return (DSR) in the virtual server port. The state can be one of the following: • No • Yes TotConn The number of client connections on the server since the Brocade Virtual ADX was booted. A connection consists of two sessions, the client-to-server session and the server-to-client session.
Displaying port-binding information B Name: MyServer03 IP:192.168.160.93 State: Enabled Port 8083: Failed Port http: Failed Syntax: show server port failed Displaying port-binding information Using the “show server bind” command To display port-binding information, enter the following command.
B Displaying port-binding information Virtual ADX#rconsole 1 1 Virtual ADX1/1#show server session Avail.
Displaying port-binding information TABLE 44 B Field descriptions for the show server session command (Continued) Field Description Random-aged: total 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, in addition to the number of sessions that were aged out randomly in the last 60 seconds.
B Displaying packet traffic statistics 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 currently implemented on the MP. The MP correctly shows most of the commonly used counters. For some counters, including show server traffic and show server debug, you should use the rconsole command in the BPs and issue show commands from there.
Displaying packet traffic statistics TABLE 45 B Field descriptions for the show server traffic command (Continued) Field Description Drops Number of packets dropped by the Brocade Virtual ADX.
B Displaying configuration information TABLE 45 Field descriptions for the show server traffic command (Continued) Field Description Unsuccessful Number of packets that were dropped for one of the following reasons: A deny filter configured on the Brocade Virtual ADX matched the packet, causing the Brocade Virtual ADX to drop the packet. • A client requested a TCP/UDP port that is not bound on the VIP. • last conn rate Rate of TCP traffic per second.
Displaying configuration information B Auto repeat of show command output The repeat-show “cmd-to-show” interval command is a regular show command that is repeated at periodic intervals. You can issue this command from any mode (user, privileged, or configuration) from a Telnet session, SSH session, or a console. To repeat the show command display at specific intervals, use the following command (on MP only).
B Displaying configuration information 3. Under VIP, unbind the real server. 4. Delete the real server. To complete deletion of the server in this case, enter the clear server session name command after entering the no server real name command. Example Virtual ADX(config)#no server real rs1 Virtual ADX(config)#show server real rs1 Real Servers Info Name : rs1 IP:10.2.3.
Appendix Acknowledgements C This appendix presents the acknowledgements for portions of code from various vendors that are included in the Brocade devices covered in this manual. OpenSSL license Copyright (c) 1998-2001 The OpenSSL Project. All rights reserved. 1. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 2.
C Cryptographic software Cryptographic software This product includes cryptographic software written by Eric Young (eay@cryptsoft.com). This product includes software written by Tim Hudson (tjh@cryptsoft.com). Original SSLeay License Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com)/. All rights reserved. This package is an SSL implementation written by Eric Young (eay@cryptsoft.com). The implementation was written so as to conform with Netscape’s SSL.
Original SSLeay License C The license and distribution terms for any publicly available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution license [including the GNU Public License.
C 392 Original SSLeay License Brocade Virtual ADX Server Load Balancing Guide 53-1003247-01
