53-1003441-01 November 2014 Brocade ServerIron ADX Advanced Server Load Balancing Guide Supporting Brocade ServerIron ADX version 12.5.
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.
Content Preface Document conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Text formatting conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii Command syntax conventions . . . . . . . . . . . . . . . . . . . . . . . . . . viii Notes, cautions, and warnings . . . . . . . . . . . . . . . . . . . . . . . . . . viii Brocade resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Contacting Brocade Technical Support .
Chapter 2 Transparent Cache Switching Transparent cache switching overview . . . . . . . . . . . . . . . . . . . . . . . 33 Operation of transparent cache switching . . . . . . . . . . . . . . . . . 34 Response to cache server failures . . . . . . . . . . . . . . . . . . . . . . . 35 Stateful caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Advanced statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Sample deployment topologies . . . .
Content-aware cache switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 How content-aware switching works. . . . . . . . . . . . . . . . . . . . . . 78 Basic example of content-aware cache switching . . . . . . . . . . . 79 Configuring policies for dynamic content . . . . . . . . . . . . . . . . . . 84 Bypassing embedded protocols . . . . . . . . . . . . . . . . . . . . . . . . . 87 HTTP 1.1 support for cache switching . . . . . . . . . . . . . . . . . . . .
vi Brocade ServerIron ADX Advanced Server Load Balancing Guide 53-1003441-01
Preface Document conventions The document conventions describe text formatting conventions, command syntax conventions, and important notice formats used in Brocade technical documentation. Text formatting conventions Text formatting conventions such as boldface, italic, or Courier may be used in the flow of the text to highlight specific words or phrases.
Command syntax conventions Bold and italic text identify command syntax components. Delimiters and operators define groupings of parameters and their logical relationships. Convention Description bold text Identifies command names, keywords, and command options. italic text Identifies a variable. [] Syntax components displayed within square brackets are optional. Default responses to system prompts are enclosed in square brackets.
Brocade resources Visit the Brocade website to locate related documentation for your product and additional Brocade resources. You can download additional publications supporting your product at www.brocade.com. Select the Brocade Products tab to locate your product, then click the Brocade product name or image to open the individual product page. The user manuals are available in the resources module at the bottom of the page under the Documentation category.
Document feedback Brocade OEM customers If you have purchased Brocade product support from a Brocade OEM/Solution Provider, contact your OEM/Solution Provider for all of your product support needs. • OEM/Solution Providers are trained and certified by Brocade to support Brocade® products. • Brocade provides backline support for issues that cannot be resolved by the OEM/Solution Provider.
Chapter SIP Server Load Balancing 1 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.
1 SIP overview SIP packet flow Figure 1 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 1 SIP packet flow The example in Figure 1 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 1 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.
1 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 1 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 a series of messages. It must be the same for all requests and responses sent by either the UAC or UAS in a dialog.
1 SIP SLB and call persistence SIP SLB and call persistence Figure 2 shows an overview of a ServerIron ADX SIP server load balancing implementation. FIGURE 2 ServerIron ADX SIP Server Load Balancing implementation There are three kinds of SIP servers: • Proxy server • Redirect server • Registrar server In Figure 2, the ServerIron 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 1 • 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 ServerIron ADX replaces the source IP (SIP server real IP) with Virtual IP (VIP).
1 SIP SLB and call persistence Sample deployment topologies ServerIron 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 3 shows an SIP server farm built around ServerIron ADX application switches.
SIP SLB and call persistence 1 The proxy server receives the INVITE request and sends a 100 (Trying) message to User1's SIP phone. Because the ServerIron 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 ServerIron ADX.
1 SIP SLB and call persistence SIP server load balancing with non-DSR mode Figure 5 shows a SIP server farm with proxy servers connected inline (non-DSR mode) with the ServerIron ADX switch.
SIP SLB over UDP 1 SIP server health monitoring There are two types of SIP servers of particular importance: SIP proxy servers and SIP registrar servers. The ServerIron ADX supports advanced UDP Layer-7 application health checks for both server types. ServerIron ADX switches can be enabled to send REGISTER or OPTION messages to SIP servers to track their health.
1 SIP SLB over UDP 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. ServerIronADX(config)#server real proxy-server-1 10.1.3.1 Syntax: [no] server real name ip address 2. Specify the SIP port.
SIP SLB over UDP 1 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. ServerIronADX(config)#server real registrar-1 10.1.5.1 Syntax: [no] server real name ip_address 2. Specify the SIP port. ServerIronADX(config-rs-registrar-1)#port sip Syntax: [no] port sip 3.
1 SIP SLB over UDP 3. Specify a registrar proxy server. ServerIronADX(config-rs-registrar-proxy-server-5)#port sip sip-both-registrar-proxy-server Syntax: port sip [sip-both-registrar-proxy-server] [options | health-check-method 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.
SIP SLB over UDP 1 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. ServerIronADX(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.
1 SIP SLB over UDP NOTE The ServerIron ADX UDP L7 SIP health checks are supported only at regular health checks, i.e. at the real server configuration. It is not supported at element health check. NOTE The ServerIron ADX TCP L7 SIP health checks are supported only at the element health checks and is not supported at regular health checks. 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 SLB over UDP 1 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.
1 SIP SLB over TCP 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. ServerIronADX#show sip session info Syntax: show sip session info ServerIronADX#show sip session info slot-9 cup-1 Avail.
SIP SLB over TCP 1 In most cases, TCP and UDP are used interchangeably, depending on the data length. Support for TCP in addition to UDP is provided for seamless deployment of advanced SIP services. This implementation is based on RFC 3261. Connection handling with SIP requests initiated by client When a SIP client initiates a call using TCP, it either uses a separate TCP connection for each call or groups multiple calls together over a single TCP connection.
1 SIP SLB over TCP Client side: Connection reuse with Mega Proxy client Figure 7 shows several SIP requests being initiated by a Mega Proxy client. The Mega Proxy uses a single TCP connection to send all these requests. Each of these requests is identified using a unique SIP Call-ID. The ServerIron ADX separates these requests and load balances them among different back-end proxy servers.
SIP SLB over TCP 1 Connection handling with SIP requests initiated by proxy server Topologies involving back-to-back user agent (B2BUA) are also supported. Figure 8 shows how the ServerIron ADX performs reverse source NAT on SIP server-initiated traffic.
1 SIP SLB over TCP Use the server sip tcp max-tcp-transaction-limit command to limit the maximum number of TCP transactions. ServerIronADX(config)#server sip tcp max-tcp-transaction-limit 200,000 Syntax: [no] server sip tcp max-tcp-transaction-limit #-of-transactions The #-of-transactions is the concurrent SIP transactions that a ServerIron ADX can manage. Enter 10 - 300,000 for #-of-transactions. The default value is 100,000.
SIP SLB over TCP 1 By default, real server traffic is deeply scanned by the ServerIron ADX SIP parser. In some cases, you may want to prevent traffic from being deeply scanned because the real server initiated traffic other than SIP traffic (such as HTTP, DNS, and others). For these cases, use the sip tcp-access-list command to configure an ACL for SIP. If the ACL action is "permit", packets should be forwarded without being deeply scanned by the SIP parser.
1 SIP SLB over TCP SIP SLB over TCP options The following section describes SIP SLB over TCP options. Configuring periodic keepalive Use the keepalive commands to periodically check the real server state after it is brought up. You can enable keepalive from the port profile configuration or from the real server port configuration. SIP port profile configuration Use the udp keepalive protocol sip command to configure keepalive from the SIP port profile configuration.
SIP SLB over TCP 1 Rehashing the SIP hash table This section describes the commands for hash table management. Manual rehash Use the server sip-hash-table-rehash command to manually rehash the hash table. ServerIronADX(config)#server sip-hash-table-rehash vip1 sip registrar-table Syntax: server sip-hash-table-rehash virtual server name virtual port registrar-table | proxy-table Automatic rehash Use the server sip-hash-table-idle command to set the hash table idle time for real server replacement.
1 SIP SLB over TCP Displaying SIP real server connection rate Use the show server sip-conn-rate command to display the connectivity rate for a real server.
SIP SLB for a SIP media session 1 Stateful SIP session handling in the event of a proxy server failure ServerIron ADX can seamlessly handle failure of proxy servers while running in stateful mode. The ServerIron ADX can be enabled to reroute subsequent SIP packets on an existing flow for a failed proxy server to an available healthy proxy server. However, note that the back-end SIP proxy server should have the capability of handling such SIP calls that were originally serviced by a different proxy server.
1 SIP SLB for a SIP media session The start_port_number variable is the start port number for the media range. The end_port_number variable is the end port number for the media range.
Debug commands 1 Debug commands The following commands and the counters they display are useful for internal debugging purposes.
1 Debug commands Debugging SIP TCP connections ServerIronADX#show sip debug tcp-connection SIP Connection Counters: TCP CONNECT ERR :130 TCP CONNECT HOST ERR TCP CONNECT ALLOC FAILED :0 TCP CONN BUSY TCP CONN RPORT FAILED :5 TCP DYNAMIC BACKEND LISTEN TCP DYNAMIC FRONTEND LISTEN :0 TCP CONN PKT CHAIN ERR TCP CONN DBL FREE :0 TCP MAX CONN REACHED TCP SESSION ERR :0 :0 :0 :0 :0 :0 Syntax: show sip debug tcp-connection Debugging UDP processes ServerIronADX#show sip debug udp-process SIP UDP Process Counte
SIP SLB command reference 1 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.
1 SIP SLB command reference port sip dsr port sip sip-switch bind sip rs1 sip rs2 sip 32 Brocade ServerIron ADX Advanced Server Load Balancing Guide 53-1003441-01
Chapter Transparent Cache Switching 2 Transparent cache switching overview Cache servers process web queries faster and more efficiently by temporarily storing details about repetitive web queries locally, thereby reducing the number of external inquiries required to process a web query.
2 Transparent cache switching overview Operation of transparent cache switching A sample Transparent Cache Switching network diagram utilizing Brocade ServerIron ADX is shown in Figure 9. FIGURE 9 Logical representation of transparent caching Four cache servers, server1, server2, server3, and server4, are installed within the network to handle the transparent caching of HTTP traffic. Server1 and server 2 are IPv4 cache servers and server3 and server4 are IPv6 cache servers.
Transparent cache switching overview 2 The cache server determines how the web query will be handled by pulling from its local information stores and facilitating that information with external web queries on the WAN, as needed, to complete the query. The ServerIron ADX provides the detection and switching of those HTTP packets forwarded from the cache server. This process is known as “transparent” cache switching because it is transparent to the end user.
2 Sample deployment topologies Advanced statistics Our TCS implementation provides the following advanced statistics: • • • • • Current connections on a per cache basis Peak connections on a per cache basis Total connections on a per cache basis Packet counts to and from cache on a per-cache basis Octet counts to and from cache on a per-cache basis Sample deployment topologies ServerIron ADX supports TCS in the following example topologies.
Sample deployment topologies TABLE 1 2 Required CAM programming for simple TCS configurations Level Match Hash 1 Destination port Source IP address 2 Source port Destination IP address TCS with spoofing In the following example configuration, the cache server is spoofing the client’s IP address instead of using its own IP address when accessing the real server. In Flow 2a, the cache server is using the client’s IP address as the source address instead of using its own IP address.
2 Sample deployment topologies In Flow 1b, the ServerIron ADX changes the destination address in Flow 1a to that of the cache server. CAM programming is the same as for basic TCS, as detailed in Table 1. NOTE FTP is not supported for TCS with destination NAT.
Sample deployment topologies TABLE 2 2 Required CAM programming for simple TCS with source NAT configuration Level Match Hash 1 Source NAT IP address Destination port 2 Destination port Source IP address Source port Destination IP address NOTE For real servers that are in multiple subnets and are configured with source NAT IP addresses, the netmask will be used by the ServerIron ADX to select the “best” source NAT IP address to use.
2 Configuring transparent cache switching TABLE 3 Required CAM programming for VIPs with reverse proxy SLB enabled Level Match Hash 1 Destination IP = cache enabled VIP Source IP address 2 Source IP = cache enabled VIP Destination IP address 3 Destination port = cache port Source IP address 4 Source port = cache port Destination IP address Configuring transparent cache switching Transparent cache switching (TCS) is disabled by default. To set up TCS, perform the following tasks: 1.
Configuring transparent cache switching 2 • A cache group is defined in terms of input ports to the ServerIron ADX. To give a client access to a group of cache servers, the input port connecting the client to the ServerIron ADX must be in the cache group that contains the cache servers. If you plan to have only one cache group, you do not need to add the input ports to the cache group because all ports are members of cache group 1 by default.
2 Configuring transparent cache switching Identify application ports for caching For each defined cache server you must specify the ports whose traffic you want to cache. The following example configures the previously named “server1” cache server to cache traffic from the port: “http”, “ssl” and port number “8080”.
Configuring transparent cache switching 2 To assign Cache Server 1 and Cache Server 2 to the same cache group (as in Figure 9 on page 34), create the server group and assign the servers to the group, as shown in the following.
2 Configuring transparent cache switching Enabling transparent cache switching When TCS is enabled, the feature detects web traffic addressed for output to the Internet and redirects the traffic to the CPU, which processes the traffic and forwards it to the cache servers instead. TCS can be defined on either a global or local basis as described: • globally – If TCS is enabled on a global basis, all ports redirect web traffic toward the cache servers.
Other transparent cache switching options 2 In the following example, the ip policy command is configured to direct traffic locally. That IP policy is then configured under the interface configuration for ethernet port 18.
2 Other transparent cache switching options Removing or re-assigning an interface By default, all ports (physical interfaces) on the ServerIron ADX belong to cache-group 1. An interface however, can assigned to more than one cache group. Removing an interface from a cache group You can remove an interface from a cache group to assign it to another cache group or to bias its traffic away from cache servers entirely.
Other transparent cache switching options 2 NOTE Traffic controlled by policy-based caching on an individual server level is load balanced, whereas traffic for the other cache servers is partitioned according to the hash feature. Refer to “Policy-based caching” on page 106. NOTE If you use content-aware cache switching (CSW in a TCS environment), URL string hashing is used to select a cache server within a server group.
2 Other transparent cache switching options The ServerIron ADX uses the following algorithm for distributing traffic among the cache servers: • "AND" the destination IPv6 address and destination IPv6 mask to get 16 1-byte values: d1, d2 ... d15, d16 • "AND" the source IP address and source IP mask to get 16 1-byte values: s1, s2 ... s15, s16 • Add each of the 1-byte values together sequentially: d1 + d2 + ...+ d15 + d16 + s1 + s2 + ... + s15 + s16.
Other transparent cache switching options TABLE 4 2 Example TCS hash masks (IPv4+IPv6) (Continued) Destination mask Source mask Destination IP address Source IP address Cache server 255.255.255.0 0.0.0.255 10.24.32.12 10.165.16.233 C1 10.24.32.12 10.12.122.233 C1 10.24.32.12 10.12.122.
2 Other transparent cache switching options NOTE If multiple services use the hash method to select a cache server, Brocade recommends that you group those services together using the hc-track-group command to maintain persistence of traffic across those services. For example, both HTTP and HTTPS use hashing by default. To ensure that traffic persists to the same cache servers, you should group these services together.
Other transparent cache switching options 2 Resilient hashing for L7 and L4 TCS for maximum cache persistence In order to the maximize ‘cache-hit ratio’ which is a critical metric for architectures utilizing cache servers, most vendors of application delivery controllers (ADC) utilize a mechanism that provides persistence for traffic flows.
2 Other transparent cache switching options To display the current hashing mechanism used for Layer 4 TCS and Layer 7 TCS, use the command: show cache-group as shown in the following truncated example. ServerIronADX#show cache-group The current TCS hash method is resilient hash. Cache-group 1 has 8 members Admin-status = Enabled Active = 0 Hash_info: Dest_mask = 255.255.255.255 Src_mask = 0.0.0.0 Cache Server Name ca1 ca2 ca3 Admin-status 6 6 6 Name: ca1 IP: 10.10.10.
Other transparent cache switching options 2 NOTE The resilient hashing mechanism supports High Availability (HA). NOTE The resilient hashing mechanism supports IPv6. Cache route optimization Typically the ServerIron ADX sits between a border access router (BAR) and a remote access server (RAS) where the BAR connects to the Internet/intranet. The RAS forwards the client HTTP traffic to the ServerIron ADX, which redirects the traffic to the cache servers.
2 Other transparent cache switching options In this example, return traffic from the cache servers passes through the ServerIron ADX to the border access router (BAR) because the BAR is the default gateway for the cache servers. However, the traffic is destined for the clients on the other side of the remote access server (RAS).
Other transparent cache switching options 2 Why ICMP redirects do not solve the problem The ServerIron ADX redirects HTTP traffic destined for the Internet to the cache server. When the cache server responds to the client, it does so by sending its packets to its default gateway because the users are not in the same subnet as the cache server. However, at Layer 3, the packet is addressed to a client that is actually accessible through the remote access server (RAS).
2 Other transparent cache switching options ServerIron ADX examines its Layer 4 header and checks to see whether it matches an entry in the state table. The ServerIron ADX also examines the source MAC address to verify that the cache sent the packet. If the MAC address field in the state table is null, and it will be for the first packet, the ServerIron ADX simply forwards the packet at Layer 2 to the cache’s default gateway, the BAR.
Other transparent cache switching options 2 Destination NAT for TCS If the cache server is remote (not directly connected to the ServerIron ADX), or is running in proxy mode (client connection is terminated completely from the back-end Internet connection), destination NAT can be configured for TCS. When destination NAT is enabled under a cache server, the destination IP of client TCS traffic (client-to-Internet) is translated to that of the cache server (client-to-cache).
2 Other transparent cache switching options Source MAC address tracking for TCS If content is not found locally, some cache servers will initiate a connection to the Internet using the same TCP parameters as the incoming client connection (source IP:source port destination IP:destination port), which can cause a conflict with the original client connection. For such situations, ServerIron ADX enables you to track the source MAC address of the incoming packet.
Other transparent cache switching options 2 You can ensure that cache server replies always pass back through the ServerIron ADX by configuring source NAT. FIGURE 11 Using source NAT with TCS In this example, the ServerIron ADX and cache server are connected by a router and are in different sub-nets. In a topology where the cache server’s response is guaranteed to pass back through the ServerIron ADX, you may not need to configure source NAT.
2 Other transparent cache switching options To configure source NAT: • Enable the source NAT feature. You can enable the feature at the cache group level for all cache servers or at the cache server level for individual servers. • Configure a source IP address. A source IP address allows the ServerIron ADX to be a member of more than one sub-net. If the cache server and ServerIron ADX are in different sub-nets, configure a source IP address that is in the cache server’s sub-net.
Other transparent cache switching options 2 Consider an example where there are 64 cache servers within one cache group (CS1 through CS64). Because there are 256 buckets, each server is assigned four buckets (256 / 64 = 4). If one cache server (CS1), goes down, the four buckets assigned to CS1 are re-assigned to cache servers “CS2-CS5”. Consequently, “CS2-CS5” have five buckets each while CS6 through CS64 still have four buckets.
2 Other transparent cache switching options Displaying the hash values per BP You can display the hash values for a specific source and destination IP pair. The output first displays the current hash table size, then the hash value which is the bucket number for the given destination and source IP addresses. If a cache server is selected for this bucket, the selected cache server name is displayed and if no cache server is selected for this bucket, "empty" is displayed, as shown in the following examples.
Other transparent cache switching options 2 When cache server spoofing support is enabled, the ServerIron ADX does the following with requests sent from a cache server to the Internet. 1. The ServerIron ADX looks at the MAC address to see if the packet is from a cache server. Note that the ServerIron ADX and the cache server cannot be separated by any router hops; they must be on the same physical segment. The ServerIron ADX uses an ARP request to get the MAC address of each configured cache server. 2.
2 Other transparent cache switching options Configuring the maximum connections for a cache server You can limit the maximum number of connections supported on a server-by-server basis. By setting a limit, you can avoid a condition where the capacity threshold of a cache server is exceeded. When a cache server reaches the maximum defined connection threshold, the ServerIron ADX sends an SNMP trap.
Other transparent cache switching options 2 Configuring the connection rate control Connection rate control enables you to limit the connection rate to a cache server. The ServerIron ADX limits the number of new port connections per second to the number you specify. The ServerIron ADX increments the connection counter for cache connections only after the ServerIron ADX selects one for the connection.
2 Other transparent cache switching options Enabling FastCache By default, the ServerIron ADX uses cache responses to client requests as a means to assess the health of the cache server. However, in an asymmetric topology where the cache server uses a path to the client that does not pass through the ServerIron ADX, the ServerIron ADX does not observe the return traffic. As a result, the ServerIron ADX concludes that the cache server has failed even though the server may still be healthy.
Other transparent cache switching options 2 Shutting down a cache server 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 cache server.
2 Other transparent cache switching options NOTE You may need to set the maximum connections parameter for the remaining cache servers, especially if the servers already run at a high percentage of their capacity when all cache servers are available. Refer to “Configuring the maximum connections for a cache server” on page 64. Forceful shutdown on cache servers SLB and TCS allow the graceful shutdown of servers and services.
Other transparent cache switching options 2 Figure 12 shows passive FTP packet flow. Using passive FTP, a PASV command is sent instead of a PORT command. Instead of specifying a port that the server can send to, the PASV command asks the server to specify a port it wishes to use for the Data Channel connection. The server replies on the Control Channel with the port number which the client then uses to initiate an exchange on the Data Channel.
2 Other transparent cache switching options Basic TCS Figure 13 shows the packet flow in a basic TCS configuration. In this example, Flows 1 and 2 are the Control Channel and Data Channel between the client and cache servers. Both flows are opened by the client. If the cache server does not have the information, it establishes Flows 3 and 4, which are the Control Channel and Data Channel between the cache server and the real server.
Other transparent cache switching options 2 High availability support Because sessions are synced between ServerIron ADX devices, passive FTP for TCS also supports the high availability (HA) topology. The most common HA setup is Symmetric Active-Active HA mode. Figure 15 shows an example of a Layer 2 Symmetric Active-Active HA setup.
2 Other transparent cache switching options If the R1 router or “ServerIron ADX 1” fails, the flow will switch as shown in Figure 18. FIGURE 18 Failover flow During the failover, any traffic of the control or data channels will not be corrupted. After a short break, all transport will continue. Enabling passive FTP caching There is no specific CLI command to enable passive FTP caching.
Other transparent cache switching options 2 Proxy servers with auto-last hop support TCS also supports certain proxy servers connected to a ServerIron ADX. In this setup, the ServerIron ADX is configured with Layer 4 TCS with spoof support so that the proxy-to-Internet server connection is treated as a spoofed connection. However, some proxy servers initiate spoofed connections using the same client IP address and the same source port.
2 Other transparent cache switching options Figure 20 shows an example setup with the ServerIron ADX configured with the server cache track-source-mac spoof-mac command. FIGURE 20 With “auto-last hop” and “server cache track-source-mac spoof-mac” setup In Figure 20, with the spoof-mac option, the following flow occurs: 1. Client sends SYN to the Internet server with Src MAC: A (client MAC), Dst MAC: B (Default Gateway MAC) 2.
Policy-based caching 2 Policy-based caching Policy-based caching allows configuration of a separate set of filters for each cache group. Users can use access lists to define a set of filters and apply these to different cache groups. Creating a set of filters using access lists You first must create a set of filters using the access-list command at the CLI. You can use regular or extended access lists. Applying access lists to cache group Apply the access list to the desired cache group as follows.
2 Policy-based caching Configuring an ACL to bypass caching You can configure a bypass filter to redirect traffic to the Internet instead of sending it to the cache servers. Configure an access list using the existing access-list CLI if you want to designate it as the bypass filter as follows. ServerIronADX(config)#server cache-bypass 3 Syntax: server cache-bypass acl-id [ipv6] The acl-id variable specifies the ID of the IPv4 or IPv6 ACL being used for bypass caching.
Content-aware cache switching 2 Debug commands You can configure the following command to enable debugging for enhanced policy-based caching. ServerIronADX(config)#server debug-policy-caching Syntax: server debug-policy-caching NOTE The server debug-policy-caching command impacts performance and should be used for debugging purposes only. Output for this command is sent to the BP.
2 Content-aware cache switching How content-aware switching works Content-aware switching (CSW) is the ServerIron ADX's ability to direct HTTP requests to a server, or group of servers, using information in the text of a URL string. The ServerIron ADX examines the contents of a URL string and makes a decision about where to send the packet based on selection criteria in user-defined policies.
Content-aware cache switching 2 Basic example of content-aware cache switching The diagram in Figure 21 illustrates a configuration that uses content-aware cache switching to cache GIF files on one set of cache servers and different kinds of files on another set. In this configuration, Cache Group 1 consists of three cache servers. CacheServer1 and CacheServer2 are allocated to Server Group ID = 1, and CacheServer3 is allocated to Server Group ID = 2.
2 Content-aware cache switching The first time a client requests a URL that ends with "gif" (for example, /home/main/banner.gif) the following events take place. 1. Because the URL ends with "gif", the CSW policy on the ServerIron ADX directs the request to one of the cache servers in Server Group ID=1. 2. When a server group consists of more than one cache server, the ServerIron ADX uses a hashing algorithm to select one of the cache servers, and directs the request to the selected cache server. 3.
Content-aware cache switching 2 Setting up the CSW policies The CSW policies define selection criteria for URL strings and specify what happens when a URL string matches the selection criteria. In content-aware cache switching, if an HTTP request contains a URL string that matches a policy’s selection criteria, the HTTP request can be sent to a load balanced cache server group or to another policy for additional matching.
2 Content-aware cache switching NOTE As the diagram in Figure 21 illustrates, there is only one cache server in Server Group ID = 2. Even so, the match command must refer to a server group rather than an actual cache server. Server groups can consist of one or more cache servers. NOTE By default, if no cache server is found in the server group then the request is bypassed to the Internet. To override this behavior, you need to enable 'group-failover' under the cache-group.
Content-aware cache switching 2 ServerIronADX(config-rs-CacheServer3)#port http group-id 2 2 ServerIronADX(config-rs-CacheServer3)#exit Assigning the cache servers to a cache group To activate content-aware cache switching (as in Figure 21), you create a cache group, assign the cache servers to that group, and specify a CSW policy to be active for the cache group, such as in the following example.
2 Content-aware cache switching ServerIron(config)#server cache-name Cache1 10.1.1.12 ServerIron(config-rs-Cache1)#port http url "HEAD /" ServerIron(config-rs-Cache1)#port http group-id 2 2 ServerIron(config)#server cache-name Cache1 10.1.1.
Content-aware cache switching 2 In the configuration in Figure 22 on page 85, the ServerIron ADX has CSW policies in place that cause HTTP requests to be directed to the cache servers as follows: • Requests that have URL strings with the text "asp" anywhere within go directly to the Internet. • Requests for all other content are directed to one of the cache servers in server group ID = 100. • HTTP 1.0 requests that have a pragma:no-cache header are sent to the Internet regardless of the URL string.
2 Content-aware cache switching ServerIronADX(config)#ip policy 1 cache tcp 80 global Setting up the CSW policies To implement the configuration in Figure 22, you would create a CSW policy that sends all requests containing URL strings ending with "asp" directly to the Internet, bypassing the cache servers. All other requests are sent to one of the cache servers in Server Group ID = 100. The following commands define a CSW policy called “policyA1”.
Content-aware cache switching 2 Bypassing embedded protocols In network environments where non-HTTP protocols such as FTP and RTSP are masquerading over port HTTP, ServerIron ADX enables network administrators to bypass such embedded traffic to the Internet rather than forwarding it to cache servers.
2 Content-aware cache switching Displaying HTTP keep-alive statistics You can use the show server proxy keep-alive command to display HTTP keep-alive statistics. The statistics relevant to HTTP keep-alive are shown (in bold) in the following abbreviated output and described in Table 5. NOTE With the ServerIron ADX release 12.4.00e, the show server proxy keep-alive command will display hash bucket counters for tracing the reason why a persist based on hash-to-bucket CSW policy failed during traffic flow.
Cache persistence using URL hashing 2 The fields described in Table 5 provide statistics about HTTP keep-alive. TABLE 5 HTTP keep-alive statistics Field Description Allocated from pool The number of instances when a server port was allocated from the Keep-Alive pool. Freed to pool The number of instances when a server port was freed to the Keep-Alive pool. Total TCBs in list (appears in two locations) The total number of Keep-Alive connections received by the ServerIron ADX.
2 Cache persistence using URL hashing The following example directs the ServerIron ADX to hash on the complete URL when the conditions in the “r1” CSW rule is met. NOTE Because hash-persist action is a secondary action, you must add a forward action as shown in the following example, before adding a hash-persist action.
Cache persistence using URL hashing 2 Parsing the entire URL Parsing the entire URL string allows you to select a portion of a URL to perform hashing on. The URL is searched to find a pattern string. This pattern string is combined with a configured offset value to identify a starting point. From this starting point in the URL, a string that will be used for hashing is derived by a method that is specified by the options you select for the hash-persist url search-url command.
2 Cache persistence using URL hashing Parsing using the “pattern string” with a delimiter The following example identifies a pattern string to perform hashing on with an offset of “0” and a delimiter with the value “&”. NOTE Because hash-persist action is a secondary action, you must add a forward action as shown in the following example, before adding a hash-persist action.
Cache persistence using URL hashing 2 Examples for parsing on the entire URL In the following example, the client tries to connect to youtube at the following URL. http://www.example4.com/watch?v=bUfp24dwzOA&playnext=1&videos=XA7MyzKoQXQ&feature =featured Table 7 displays the contents of the strings used for hashing if the pattern-string variable is set to “v=” and the offset value is set to “0” depending on the method used. The methods and commands required are described as follows.
2 Cache persistence using URL hashing Search host string by starting at a “pattern string” and continuing for a specified length – With this option, the ServerIron ADX begins at the starting point in the URL and includes the number of characters specified to form the string used for hashing. Parsing using the “pattern string” only The following example identifies a pattern string to perform hashing on with an offset of “0”.
Cache persistence using URL hashing 2 The contents and operation of the offset-value is the same as described in “Parsing using the “pattern string” only”. With this command, the third step is for the system to parse the URL string up-to a character defined by the value of the delimiter-string variable. The delimiter string is used to define the end pattern after finding the substring. If the rest of URL string has multiple delimiter strings, only the first one will be used.
2 Cache persistence using URL hashing Parsing using the “pattern string” with a specified string length ServerIronADX(config)#csw-policy p1 ServerIronADX(config-csw-p1)#match r1 forward 1 ServerIronADX(config-csw-p1)#match r1 hash-persist url search-host “www.” offset 0 length 5 TABLE 8 Results for parsing the host string of a URL by method Method String used for hashing pattern string only brocade.com pattern string with a delimiter of “.
Traffic distribution based on cache server capacity 2 NOTE This command generally disrupts the existing cache persistence. Traffic distribution based on cache server capacity In order to determine the health of a cache server, the Brocade ServerIron ADX performs basic health monitoring functions such as check IP connectivity and check reachability of application ports. Basic monitoring of these metrics however, may not provide an aggregated view of the health of cache servers.
2 Traffic distribution based on cache server capacity TABLE 9 Load balancing action as determined by cache server state (Continued) Cache server states ServerIron ADX load balancing action HALTING (7): Cache is in the process of shutting down. The ServerIron ADX will neither allow any new connections nor continue servicing existing connections on these cache servers. Any new connections will instead be forwarded to the under used and normal cache servers.
Traffic distribution based on cache server capacity 2 The seconds variable specifies the poll interval for the SNMP queries sent by the ServerIron ADX to the cache servers. The ServerIron ADX then sets the cache state based on the reply received from the cache server. The following configuration sets Server Cache Group 1 to use the SNMP predictor configured with the OID index 1 with the cs100 cache server. ServerIronADX(config)#server cache-group 1 ServerIronADX(config-tc-1)#hash-mask 255.255.255.255 0.0.
2 Displaying cache information TABLE 11 Transaction allocation and load balancing performed by ServerIron ADX doing Layer-7 TCS based on the load state of the cache server Cache Server state New transactions Existing transactions Underused Allows Allows Normal Allows Allows Burdened Allows Allows Stressed Allows (If no other cache in SNMP state 1 to 3 exists. Otherwise, all the transactions will go to caches whose state is in between 1 to 3.
Displaying cache information 2 Table 12 describes the output of the show cache-group command. TABLE 12 TCS information Field Description Global cache group information This section of the display lists global information for the cache group. Admin-status The administrative status of the cache group. The status can be one of the following: • Disabled • Enabled Hash_info The source and destination mask for the cache distribution hash value.
2 Sample configurations TABLE 12 TCS information (Continued) Field State Description The state of the service, which can be one of the following: 1 – Enabled 2 – Failed 3 – Testing 4 – Suspect 5 – Graceful shutdown 6 – Active • • • • • • CurConn The number of currently active connections between hosts and the cache server. TotConn The total number of connections between hosts and the cache server. Cache->Web-Server The total number of packets and octets from the cache server to web servers.
Sample configurations 2 Basic TCS configuration Figure 23 shows a configuration in which HTTP traffic flows into a Point-of-Presence (POP) from Remote Access Servers (RASs) and out of the POP to the Internet through a Border Access Router (BAR). The cache servers are labeled C1, C2, and C3. FIGURE 23 Basic TCS configuration example In the most basic setup, HTTP traffic flowing across the ServerIron ADX, in any direction, is redirected to the cache servers.
2 Sample configurations In this example, suppose you want all traffic to be cached and you want to use the ServerIron ADX’s default settings. To configure the ServerIron ADX for this example, you define the caches, assign them to cache groups, and apply an IP policy. Applying IP policies For the simple case in which you want to cache everything no matter where it comes from or where it is going to, use a global policy, such as the following.
Sample configurations 2 Once the caches have been defined, they must be associated (bound) with a particular cache group. The following CLI commands bind the cache servers shown in Figure 23 with a cache group. ServerIronADX(config)#server cache-group 1 ServerIronADX(config-tc-1)#cache-name C1 ServerIronADX(config-tc-1)#cache-name C2 ServerIronADX(config-tc-1)#cache-name C3 POP using caching to minimize WAN costs This example assumes a POP that belongs to an ISP.
2 Sample configurations Policy-based caching Policy-based caching enables you to selectively cache some web sites but not others, on specific cache servers. For example, an ISP can use a ServerIron ADX configured for policy-based caching to redirect HTTP traffic to a series of web cache servers made by different vendors with different caching criteria.
Sample configurations 2 In the same way, Access List “102” is tied under Cache Group 2. The filter-acl 102 command diverts all the traffic that was originally destined to Web Server 2 (IP address 10.1.1.2) to cache 3 (ch3) and cache 4 (ch4). The server cache-bypass 103 command divert all the traffic to Internet Web Server 3 (IP address 10.1.1.3). The fundamental use of the server cache-bypass command is to skip the caching mechanism and send web queries directly to the Internet.
2 Sample configurations Asymmetric TCS (FastCache) Traffic in typical TCS configurations passes through the ServerIron ADX both from the client to the cache and from the cache to the client. The ServerIron ADX uses the cache responses to the client to diagnose the health of the cache server. If the cache server responds to the client requests the ServerIron ADX redirects to the cache server, the ServerIron ADX knows that the cache server is healthy.
Sample configurations FIGURE 25 2 FastCache feature used for asymmetric topology Here are the commands for configuring the ServerIron ADX for the topology shown in Figure 25. The line that enables the FastCache feature is shown in bold. NOTE This example shows commands that are valid on the ServerIron ADX device only when it is running the Layer 3 router image. ServerIronADX(config)#server cache-name cacheserver3 10.157.22.
2 Sample configurations This example assumes that the cache contains the contents requested by the client. However, if the cache does not contain the requested page, the cache tries to get the page from the live web site. In this case, the source address for the request is the IP address of the cache server, instead of the IP address of the client. Moreover, this behavior can result in a loop from the cache server to the RAS to the ServerIron ADX and back to the cache server.
Sample configurations 2 Figure 26 shows an example of a configuration that requires CFO.
2 Sample configurations Here are the CLI commands for adding a virtual IP address to a cache group. Add the virtual IP address to which your router forwards the clients’ HTTP requests. ServerIronADX(config)#ip policy 1 cache tcp 80 global ServerIronADX(config)#server cache-group 1 ServerIronADX(config-tc-1)#virtual-ip 10.157.22.77 Syntax: [no] virtual-ip { ipv4_address | ipv6_address } The ipv4_address variable specifies an IPv4 address for the virtual IP address of the cache group.
Sample configurations FIGURE 27 2 Example Proxy Server Cache Load Balancing Configuration Perform the following steps to configure Proxy Server Cache Load Balancing. 1. Add the cache servers as customary, using the server cache-name string ip-addr command. 2. Add the HTTP ports and configure port-specific health check parameters at the Cache Server level, using the port http | num commands. 3. Create the proxy virtual IP address (VIP) and bind the HTTP ports of the cache servers to the VIP.
2 Sample configurations ServerIronADX(config)#server port 8080 ServerIronADX(config-port-8080)#tcp ServerIronADX(config-port-8080)#exit The previous commands add port profiles for the two HTTP ports in this example that are using port numbers other than the well-known port 80: 4199 and 8080. The tcp command at each port’s configuration level is required.
High availability designs with TCS 2 The previous commands configure a virtual IP address (VIP) to take the place of the Proxy IP address to which some of the client browsers are directing their web requests. The IP address specified with the server virtual-name-or-ip command is the IP address that is configured as the proxy on some clients’ web browsers. The port 4199 sticky and port 8080 sticky commands add the ports and also make them “sticky”.
2 High availability designs with TCS Layer 3 basic TCS configuration Figure 28 illustrates a basic Layer 3 TCS configuration. FIGURE 28 Basic TCS configuration The following commands configure the ServerIron ADX in Figure 28. NOTE This example shows commands that are valid on the ServerIron ADX device only when it is running the Layer 3 router image.
High availability designs with TCS 2 ServerIronADX(config-rs-cache3)#port rtsp ServerIronADX(config-rs-cache3)#port pnm ServerIronADX(config-rs-cache3)#port http ServerIronADX(config-rs-cache3)#port http url "HEAD /" ServerIronADX(config)#server cache-group 1 ServerIronADX(config-tc-1)#prefer-router-cnt 0 ServerIronADX(config-tc-1)#cache-name cache3 ServerIronADX(config-tc-1)#exit ServerIronADX(config)#ip l4-policy 1 cache tcp 0 global ServerIronADX(config)#ip l4-policy 2 cache udp 0 global ServerIronADX(
2 High availability designs with TCS ServerIronADX(config)#vlan 1 name DEFAULT-VLAN by port ServerIronADX(config-vlan-1)#exit ServerIronADX(config)#vlan 100 by port ServerIronADX(config-vlan-100)#untagged ethe 1/1 to 1/4 ServerIronADX(config-vlan-100)#router-interface ve 1 ServerIronADX(config-vlan-100)#exit ServerIronADX(config)#vlan 200 by port ServerIronADX(config-vlan-200)#untagged ethe 1/5 to 1/7 ServerIronADX(config-vlan-200)#router-interface ve 2 ServerIronADX(config-vlan-200)#exit ServerIronADX(co
High availability designs with TCS 2 ServerIronADX(config)#ip route 192.92.10.0 255.255.255.0 10.10.10.2 ServerIronADX(config)#router vrrp-extended ServerIronADX(config)#server active-active-port ethe 1/16 vlan-id 16 ServerIronADX(config)#server force-delete ServerIronADX(config)#no server l4-check Commands for ServerIron ADX B The following commands configure ServerIron ADX B in Figure 29.
2 High availability designs with TCS ServerIronADX(config-rs-cache3)#port http ServerIronADX(config-rs-cache3)#port http url "HEAD /" ServerIronADX(config)#server cache-group 1 ServerIronADX(config-tc-1)#prefer-router-cnt 0 ServerIronADX(config-tc-1)#cache-name cache3 ServerIronADX(config-tc-1)#no http-cache-control ServerIronADX(config-tc-1)#exit ServerIronADX(config)#ip l4-policy 1 cache tcp 0 global ServerIronADX(config)#ip l4-policy 2 cache udp 0 global ServerIronADX(config)#ip l4-policy 3 cache tcp m
High availability designs with TCS 2 Commands for ServerIron ADX A The following commands configure ServerIron ADX A in Figure 30. NOTE This example shows commands that are valid on the ServerIron ADX device only when it is running the Layer 3 router image.
2 High availability designs with TCS ServerIronADX(config-tc-1)#cache-name cache1 ServerIronADX(config-tc-1)#no http-cache-control ServerIronADX(config-tc-1)#exit ServerIronADX(config)#ip l4-policy 1 cache tcp 0 global ServerIronADX(config)#ip l4-policy 2 cache udp 0 global ServerIronADX(config)#ip l4-policy 3 cache tcp mms global ServerIronADX(config)#ip l4-policy 4 cache tcp rtsp global ServerIronADX(config)#ip l4-policy 5 cache tcp pnm global ServerIronADX(config)#ip l4-policy 6 cache tcp http global S
High availability designs with TCS 2 ServerIronADX(config-ve-3-vrid-3)#backup ServerIronADX(config-ve-3-vrid-3)#ip-address 10.3.3.10 ServerIronADX(config-ve-3-vrid-3)#track-port ve 1 ServerIronADX(config-ve-3-vrid-3)#track-port ve 2 ServerIronADX(config-ve-3-vrid-3)#enable ServerIronADX(config)#server cache-name cache1 172.32.1.
2 High availability designs with TCS Layer 3 Symmetric Active-Active HA with TCS Figure 31 illustrates a Symmetric Active-Active HA configuration with TCS, using VRRPE. NOTE To allow failover and session synchronization in a Symmetric Active-Active HA configuration to work properly, there must be a Layer 2 connection between the two ServerIron ADX devices.
High availability designs with TCS 2 NetIron(config)#vlan 2 by port NetIron(config-vlan-2)#untagged ethe 1 to 2 NetIron(config-vlan-2)#router-interface ve 2 NetIron(config-vlan-2)#exit NetIron(config)#vlan 23 by port NetIron(config-vlan-23)#untagged ethe 23 NetIron(config-vlan-23)#exit NetIron(config)#interface ve 1 NetIron(config-ve-1)#ip address 10.1.1.3 255.255.255.
2 High availability designs with TCS ServerIronADX(config)#vlan 999 by port ServerIronADX(config-vlan-999)#untagged ethe 3/24 ServerIronADX(config-vlan-999)#exit ServerIronADX(config)#interface ve 1 ServerIronADX(config-ve-1)#ip address 10.1.1.252 255.255.255.0 ServerIronADX(config-ve-1)#ip vrrp-extended vrid 5 ServerIronADX(config-ve-1-vrid-5)#backup ServerIronADX(config-ve-1-vrid-5)#ip-address 10.1.1.
High availability designs with TCS 2 ServerIronADX(config)#server router-ports ethernet 3/1 ServerIronADX(config)#server router-ports ethernet 3/3 ServerIronADX(config)#server real rs29 10.1.1.
2 High availability designs with TCS ServerIronADX(config-vs-ftp)#sym-priority 254 ServerIronADX(config-vs-ftp)#sym-active ServerIronADX(config-vs-ftp)#port ftp ServerIronADX(config-vs-ftp)#bind ftp rs31.1 ftp rs30.1 ftp rs29.1 ServerIronADX(config-vs-ftp)#bind ftp rs30 ftp rs31 ftp ServerIronADX(config-vs-ftp)#exit ServerIronADX(config)#server virtual-name-or-ip mms 10.2.24.
High availability designs with TCS 2 NetIron(config-vlan-2)#untagged ethe 1 to 2 NetIron(config-vlan-2)#router-interface ve 2 NetIron(config-vlan-2)#exit NetIron(config)#vlan 23 by port NetIron(config-vlan-23)#untagged ethe 23 NetIron(config-vlan-23)#exit NetIron(config)#interface ve 1 NetIron(config-ve-1)#ip address 10.172.1.4 255.255.255.0 NetIron(config-ve-1)#ip ospf area 0 NetIron(config-ve-1)#ip vrrp-extended vrid 3 NetIron(config-ve-1-vrid-3)#backup NetIron(config-ve-1-vrid-3)#ip-address 10.172.1.
2 High availability designs with TCS ServerIronADX(config)#vlan 999 by port ServerIronADX(config-vlan-999)#untagged ethe 3/24 ServerIronADX(config-vlan-999)#exit ServerIronADX(config)#interface ve 1 ServerIronADX(config-ve-1)#ip address 10.1.1.251 255.255.255.0 ServerIronADX(config-ve-1)#ip vrrp-extended vrid 5 ServerIronADX(config-ve-1-vrid-5)#backup ServerIronADX(config-ve-1-vrid-5)#ip-address 10.1.1.
High availability designs with TCS 2 ServerIronADX(config-port-443)#exit ServerIronADX(config)#server router-ports ethernet 3/1 ServerIronADX(config)#server router-ports ethernet 3/3 ServerIronADX(config)#server real rs29 10.1.1.
2 High availability designs with TCS ServerIronADX(config)#server virtual-name-or-ip ftp 10.2.24.102 ServerIronADX(config-vs-ftp)#sym-priority 254 ServerIronADX(config-vs-ftp)#sym-active ServerIronADX(config-vs-ftp)#port ftp ServerIronADX(config-vs-ftp)#bind ftp rs31.1 ftp rs30.1 ftp rs29.1 ServerIronADX(config-vs-ftp)#bind ftp rs30 ftp rs31 ftp ServerIronADX(config-vs-ftp)#exit ServerIronADX(config)#server virtual-name-or-ip mms 10.2.24.
High availability designs with TCS 2 Active-standby TCS TCS is supported in an active-standby configuration. Figure 29 illustrates a sample active-standby TCS configuration. In this configuration, one of the ServerIron ADXs serves as the active ServerIron ADX, while the other remains in standby mode. If the active ServerIron ADX fails, the standby ServerIron ADX assumes the duties of the failed ServerIron ADX and becomes the new active ServerIron ADX.
2 High availability designs with TCS ServerIronADX(config)#interface ve 1 ServerIronADX(config-ve-1)#ip address 192.92.10.1 255.255.255.0 ServerIronADX(config-ve-1)#exit ServerIronADX(config)#interface ve 2 ServerIronADX(config-ve-2)#ip address 192.92.20.1 255.255.255.0 ServerIronADX(config-ve-2)#exit ServerIronADX(config)#interface ve 3 ServerIronADX(config-ve-3)#ip address 172.32.1.1 255.255.255.
Interoperability issues with cache servers 2 ServerIronADX(config-vlan-13)#untagged ethe 1/13 ServerIronADX(config-vlan-13)#no spanning-tree ServerIronADX(config-vlan-13)#exit ServerIronADX(config)#ip address 192.92.10.6 255.255.255.0 ServerIronADX(config)#ip default-gateway 192.92.10.
2 Interoperability issues with cache servers NetCache C720 cache server This model of cache server sends HTTP error code 500 in response to an HTTP keep-alive health check sent by the ServerIron ADX. By default, the ServerIron ADX does not consider this to be a valid health check response. To work around this issue, configure status code 500 to be a valid response to the health check. To do so, enter the port http status_code 500 500 command at the configuration level for the cache server.
Chapter Pass-Through Flow Management 3 Pass-through flow management overview Stateful devices, such as firewalls and Deep Packet Inspection (DPI) devices, require visibility into both forward and reverse traffic flows to process them appropriately. These devices fail to function if the network handles traffic asymmetrically.
3 Configuring pass-through flow management NOTE Pass-through flow management does not function if the MAC addresses are defined statically. High Availability support Pass-through flow management is available in active-active HA mode only. For pass-through flow management to function properly with High Availability (HA), you must follow the symmetric numbering convention when you connect multiple devices to the two ServerIron ADX devices that are configured in HA.
Displaying related pass-through flow management information 3 flow-mgmt stick-to-sender ip address 192.168.3.20 255.255.255.0 interface ve 4 ip address 192.168.4.20 255.255.255.
3 Displaying related pass-through flow management information The internal MAC table size is 2048 entries. If it approaches full capacity only on the MP, use the clear flow-mgmt mac-table command followed by the clear mac command to restart the MAC learning. ServerIronADX# clear flow-mgmt mac-table ServerIronADX# clear mac Syntax: clear flow-mgmt mac-table Displaying session information Use the show session command at the BP console to display the session information.
