53-1002435-01 January, 2012 ServerIron ADX Advanced Server Load Balancing Guide Supporting Brocade ServerIron ADX version 12.4.
© 2012 Brocade Communications Systems, Inc. All Rights Reserved. Brocade, Brocade Assurance, the B-wing symbol, DCX, Fabric OS, MLX, SAN Health, VCS, and VDX are registered trademarks, and AnyIO, Brocade One, CloudPlex, Effortless Networking, ICX, NET Health, OpenScript, and The Effortless Network 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.
ServerIron ADX Advanced Server Load Balancing Guideiii 53-1002435-01
ivServerIron ADX Advanced Server Load Balancing Guide 53-1002435-01
Contents About This Document Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Supported hardware and software . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Document conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Text formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Command syntax conventions . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sample Deployment Topologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 Basic TCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 TCS with spoofing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 TCS with destination NAT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 TCS with Source NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 VIPs with reverse proxy . . . . . . . . . . . . .
Sample configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Basic TCS configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 POP belonging to an ISP using caching to minimize WAN costs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Policy-based caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Asymmetric TCS (FastCache) . . . . . . . . . . . . . . . . . . . . . . . . . . .
viii ServerIron ADX Advanced Server Load Balancing Guide 53-1002435-01
About This Document Audience This document is designed for system administrators with a working knowledge of Layer 2 and Layer 3 switching and routing. If you are using a Brocade Layer 3 Switch, you should be familiar with the following protocols if applicable to your network – IP, RIP, OSPF, BGP, ISIS, IGMP, PIM, DVMRP, and VRRP. Supported hardware and software Although many different software and hardware configurations are tested and supported by Brocade Communications Systems, Inc. for 12.
bold text Identifies command names Identifies the names of user-manipulated GUI elements Identifies keywords Identifies text to enter at the GUI or CLI italic text Provides emphasis Identifies variables Identifies document titles code text Identifies CLI output For readability, command names in the narrative portions of this guide are presented in bold: for example, show version.
Notice to the reader This document may contain references to the trademarks of the following corporations. These trademarks are the properties of their respective companies and corporations. These references are made for informational purposes only. Corporation Referenced Trademarks and Products Sun Microsystems Solaris Microsoft Corporation Windows NT, Windows 2000 The Open Group Linux Related publications The following © 2009 Brocade Communications Systems Inc.
Web access The Knowledge Portal (KP) contains the latest version of this guide and other user guides for the product. You can also report errors on the KP. Log in to my.Brocade.com, click the Product Documentation tab, then click on the link to the Knowledge Portal (KP). Then click on Cases > Create a New Ticket to report an error. Make sure you specify the document title in the ticket description. E-mail and telephone access Go to http://www.brocade.com/services-support/index.
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 Proxy Server user1 IP Phone user2 IP Phone INVITE F1 INVITE F2 TRYING F3 RINGING F4 RINGING F5 200 OK F6 200 OK F7 ACK F8 MEDIA FLOW BYE F9 OK F10 This example shows packet exchange between two SIP clients, also known as user agent clients (UAC). Each message is labeled with the letter "F" and a number for reference by the text. The session established between the two end clients is facilitated by the SIP proxy server.
SIP Overview 1 Content-Length: 142 Since User1's SIP phone does not know the location of User2's SIP phone, it sends the INVITE message to the SIP proxy server that is serving the brocade.com domain. The address of the brocade.com proxy server is known to the SIP phone through static configuration or through DHCP. The proxy server receives the INVITE request and sends a 100 (Trying) response back to User1's SIP phone.
1 SIP Overview SIP client registration Registration is another common SIP operation. Registration is the means through which the SIP domain's registrar server learns the current location of SIP clients (UAC). Upon initialization, and at periodic intervals, the SIP clients send REGISTER messages to domain's SIP registrar server. The REGISTER messages associate an individual SIP URI (sip:user@brocade.com) with the machine (IP address) into which the user is currently logged.
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 UAC or UAS in a dialog.
1 SIP SLB and Call Persistence using ServerIron ADX Max-Forwards The Max-Forwards header field must be used with any SIP method to limit the number of proxies or gateways that can forward the request to the next downstream server. The Max-Forwards value is an integer in the range 1-255 indicating the remaining number of times that a request message is allowed to be forwarded. The recommended initial value is 70.
SIP SLB and Call Persistence using ServerIron ADX 1 • Proxy • Redirect • Registrar The ServerIron supports the following methods in accordance with RFC 3261: • • • • • • INVITE REGISTER ACK CANCEL BYE OPTIONS Additionally, the following methods are supported: • SUBSCRIBE • NOTIFY • Other proprietary methods SIP and Call Persistence specifications The SIP Server Load Balancing feature has the following specifications: • By default, server selection is persistent on Call-ID.
1 SIP SLB and Call Persistence using ServerIron ADX FIGURE 3 SIP server farm with DSR mode SIP Proxy Server G YIN TR F3 ING G RIN OK F5 F7 IN VI TE user1 F1 ServerIron F2 F4 L2/3 Infrastructure F1 SI OK F6 G TE VI IN IN NG RI OK F10 BYE F9 MEDIA RTP ACK F8 INVITE user2 From/To SIP Phone To/From VIP From/To SIP Phone To/From Real IP Figure 3 demonstrates a typical use case - the ServerIron application switch provides call-id based server persistence for UDP SIP traffic.
SIP SLB and Call Persistence using ServerIron ADX 1 NOTE The proxy server's IP address must be reachable from all SIP clients. User2's SIP phone receives the INVITE and alerts User2 of an incoming call. User2 replies with a Ringing message to the proxy server. if User2 answers the call, a 200 OK message is sent to the proxy server. The proxy server forwards this message to User1's SIP phone.
1 SIP SLB and Call Persistence using ServerIron ADX FIGURE 5 SIP Server Load Balancing with ServerIron non-DSR mode OK F7 TRYING F3 INVITE F1 INVITE F2 RINGING F4 OK F6 RINGING F5 SIP Proxy Server SI TE I NV F3 G ServerIron F5 F7 F2 F6 F4 K O O G IN G K IN NG RI R IN TE G VI N YI TR IN I F1 ACK F8 MEDIA RTP user1 user2 BYE F9 OK F10 From/To SIP Phone To/From VIP To maintain session persistence and transaction integrity, this implementation has the following requi
Configuring SIP SLB 1 SIP server health monitoring There are two types of SIP servers of particular importance — SIP proxy servers and SIP registrar servers. The ServerIron supports advanced UDP layer-7 application health checks for both server types. ServerIron switches can be enabled to send REGISTER or OPTION messages to SIP servers to track their health.
1 Configuring SIP SLB • sip-proxy-server— Identifies the server as SIP proxy server. • health-check-method— specifies the SIP health check method. • options— enables health check through OPTION messages. • register— enables health check through REGISTER messages (default method). • health-check-no-dsr— specifies for health check to be sent to a real server rather than a virtual server.
Configuring SIP SLB 1 NOTE You can specify SIP port number 5060 or the keyword SIP. 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] [health-check-method register|options] [health-check-no-dsr] • sip-both-registrar-proxy-server— Identifies the server as an SIP registrar or a proxy server. • health-check-method— specifies the SIP health check method.
1 Configuring SIP SLB Configure a SIP virtual server Follow the steps given below to configure SIP Server Load Balancing virtual redirect-proxy servers and virtual proxy domains, and bind real severs 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 1.1.6.9 Syntax: [no] server virtual-name-or-ip 2. Specify the SIP port and SIP switch.
Configuring SIP SLB 1 SIP stateless sample configuration Load Balancing SIP over UDP (Stateful SLB mode) This feature enhances the SIP feature by making it stateful and by adding necessary intelligence for handling varying caller-id situations. This feature has the following elements: • SIP stateful support— Server selection is based on round robin persistent on user configured key-header, such as Call-ID, and corresponding SIP sessions are created for this purpose.
1 Configuring SIP SLB Configure max number of SIP sessions ServerIronADX(config)# server sip session max-sip-sessions 1000000 Syntax: [no] server sip session max-sip-sessions • Where is between 10 and 2 Million. NOTE This command requires a reload. Removing this configuration using no command will reset the session to 500000.
Configuring SIP SLB 1 Example ServerIronADX# show sip sess all 0 Session Info: Indx ==== 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Src-IP ====== 4.4.4.131 4.4.4.131 4.4.4.131 4.4.4.131 4.4.4.131 4.4.4.131 4.4.4.131 4.4.4.131 4.4.4.131 4.4.4.131 4.4.4.131 4.4.4.131 4.4.4.131 4.4.4.131 4.4.4.131 4.4.4.131 4.4.4.131 4.4.4.131 4.4.4.131 4.4.4.131 VIP ====== 4.4.4.171 4.4.4.171 4.4.4.171 4.4.4.171 4.4.4.171 4.4.4.171 4.4.4.171 4.4.4.171 4.4.4.171 4.4.4.171 4.4.4.171 4.4.4.171 4.4.4.171 4.4.4.171 4.4.
1 Configuring SIP SLB ServerIronADX# show sip sess all source-ip 4.4.4.131 0 4.4.4.131 4.4.4.171 SnPtwbMhlhNhAWLKNPJoQfmg 1 4.4.4.131 4.4.4.171 PgUprlMdooIlFMLOKIOkLpmc 2 4.4.4.131 4.4.4.171 OoHhjcPlpgVtNVIGJQBcDgpk 3 4.4.4.131 4.4.4.171 MpVgjiPlrfHuNPIGHRPbDmpk 4 4.4.4.131 4.4.4.171 MtUplcPrrbIlLVIAHVOkFgpq 5 4.4.4.131 4.4.4.171 SqUhwjUjleItAODINSOcQnui 6 4.4.4.131 4.4.4.171 OiTsmkRhpmJiKNGKJKNnGorg 7 4.4.4.131 4.4.4.171 LlIlkpHpsjUpMIQCGNCgEtho 8 4.4.4.131 4.4.4.171 ThNfrgUfknPvFRDMOJHaLkue 9 4.4.4.
Configuring SIP SLB 1 SIP Stateful sample configuration Load Balancing SIP over TCP Like HTTP, SIP protocol follows a request and response model. However, SIP transactions are independent of the underlying transport layer protocol. For example, some transactions run over UDP connections, some get transported over TCP connections, and some use a combination of TCP and UDP interchangeably, depending on the size of the data. Generally most SIP deployments are observed over UDP transport.
1 Configuring SIP SLB FIGURE 6 Single TCP connection for each SIP request SIP Proxy Server TCP Connection Cal l-ID ... -ID1 1... Call ServerIron SIP phone Cal .. D2. all-I C l-ID 2... TCP Connection SIP phone SIP Proxy Server 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.
Configuring SIP SLB FIGURE 7 1 Reuse of TCP connection ... -ID1 Call Mega-proxy SIP Proxy Server Call-ID1...Call-ID2...Call-ID3 ServerIron Call-ID2 Several SIP messages using one TCP Connection Ca ll-ID 3... SIP Proxy Server SIP Proxy Server Server side connection: With source NAT If source NAT is enabled, then the ServerIron uses source NAT IP addresses and ports for establishing connections with proxy servers.
1 Configuring SIP SLB Connection handling with SIP requests initiated by proxy server The topologies involving B2BUA are supported. ServerIron performs reverse source NAT on SIP server initiated traffic. FIGURE 8 SIP proxy server initiated SIP requests SIP Proxy Server Cal l-ID ServerIron SIP phone 1... l-ID 1... Cal Cal l-ID ... D2 all-I C 2...
Configuring SIP SLB 1 Use the following command to configure the maximum number of TCP-based server connections. ServerIronADX(config)# server sip max-server-tcp-connections 25 Syntax: [no] server sip max-server-tcp-connections <#of connections> Enter 1 - 64 for <#-of-connections>, which specifies the maximum number of concurrent TCP connections that ServerIron can actively open to a specific server. Use the following command to limit the maximum number of TCP transactions.
1 Configuring SIP SLB Enter the following command. ServerIronADX(config-rs-sip)# sip alternative-server-ip 10.120.5.34 Syntax: [no] sip alternative-server-ip Enter an IP address for . By default, real server traffic is deeply scanned by the ServerIron SIP parser. In some cases, you may want to prevent traffic from being deeply scanned because the real server initiated other traffic beside SIP (such as HTTP, DNS, and others). For these cases, configure an ACL for SIP.
Configuring SIP SLB 1 ServerIronADX(config)#server virtual vs-sip 172.28.8.
1 Configuring SIP SLB Rehashing the SIP hash table This section describes the commands for hash table management. It contains the following sections: • “Manual rehash” on page 26 • “Automatic rehash” on page 26 Manual rehash Use the following command to manually rehash the hash table.
Configuring SIP SLB 1 Example ServerIronADX# show server sip-conn proxy-server-1 Real Server: proxy-server-1 : Real Port: sip(BOTH REGISTRAR AND PROXY SERVER): Type: Cur Local Rate:Last Conn Rate:Max Local Rate:TTL Conns INVITE* 0 0/0 1 1/1 ACK 0 0/0 0 0/0 OPTIONS 0 0/0 0 0/0 BYE* 0 0/0 0 0/0 CANCEL* 0 0/0 0 0/0 REGISTER* 0 0/0 1 1/1 RQST UNKNOWN 0 0/0 0 0/0 RESP INFO 0 0/0 0 0/0 RSP SUCCESS 0 0/0 0 0/0 RSP REDIRECT 0 0/0 0 0/0 RESP C ERR 0 0/0 0 0/0 RSP S ERR 0 0/0 0 0/0 RESP FAIL 0 0/0 0 0/0 Displaying
1 Configuring SIP SLB NOTE This command is not required when ServerIron is configured in SIP stateless mode. With stateless mode, ServerIron automatically assigns a new proxy server when packets arrive on an existing flow to failed server. Debug commands The following commands and the counters they display are useful for internal debugging purpose.
Configuring SIP SLB 1 Debug SIP TCP connection 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 SERVERIRON 1/1# :0 :0 :0 :0 :0 Syntax: show sip debug tcp-connection Debug UDP process ServerIronADX# show sip debug udp-process SIP UDP Pro
1 SIP SLB command reference ServerIronADX4/2 # show sip 4/2 # ->Start processing Incoming [1460]... Start SIP Parsing for chain SIP header parsing for flow debug packet-trace 172.28.8.67 172.28.8.100 Flow [172.28.8.67:3798->172.28.8.100:5060] Data len len [1460]... COMPLETED with sip header - orig chain len [1460] SIP packet header dump: Packet type: INVITE URI: sip:service@172.28.8.100:5060 parse completed: 1 version: SIP/2.0 num pkts processed: 1 response code: 0 method: INVITE VIA header: SIP/2.
SIP SLB command reference 1 • sip-both-registrar-proxy-server— Identifies the server as an SIP registrar or a proxy server. • health-check-method— specifies the SIP health check method. • options— enables health check through OPTION messages. • register— enables health check through REGISTER messages (default method). • health-check-no-dsr— specifies for health check to be sent to a real server rather than a virtual server. Usage guidelines These commands are issued from the real server configuration.
1 32 SIP SLB command reference ServerIron ADX Advanced Server Load Balancing Guide 53-1002435-01
Chapter Transparent Cache Switching 2 TCS Overview Transparent Cache Switching (TCS) allows a ServerIron ADX to detect and switch web traffic to a local cache server within the network. A single ServerIron ADX (or hot standby pair) can provide transparent cache switching for up to 256 web cache servers per cache group.
2 TCS Overview FIGURE 9 Logical representation of transparent caching Internet Web Servers www.rumors.com www.stockquotes.com www.news.com Border Access Router (BAR) Web Queries 208.95.8.3 Remote Access Router e18 (output port) SI e17 e4 e5 e16 e15 208.95.7.3 208.95.6.3 2001:db8::1 Cache Server 1 207.95.5.11 Cache Server 2 207.95.5.
TCS 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 2 The following table lists the entries that need to be programmed in the CAM for hardware forwarding of pass-through traffic. TABLE 1 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.
2 Sample Deployment Topologies Client CIP ServerIron VIP 1a(CIP-RIP) Real Server RIP 2b(TIP-RIP) 3a(RIP-TIP) 4b(RIP-CIP) 3b(RIP-TIP) 2a(TIP-RIP) 4a(TIP-CIP) 1bDestNAT(CIP-TIP) CIP-Client IP Address RIP-Real Server IP Address VIP-Virtual IP Address TIP-Cache Server IP Address Transparent Cache Server TIP In flow 1b, the ServerIron 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.
Sample Deployment Topologies 2 In flow 1b, the ServerIron ADX changes the source address to a configured IP address. The ServerIron ADX applies source NAT to the requests going from the ServerIron ADX to the cache server. Table 2 illustrates the CAM programming for this example.
2 Configuring TCS The following table lists the entries that need to be programmed in the CAM for hardware forwarding of pass- through traffic. 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 TCS TCS is disabled by default.
Configuring TCS 2 • You must apply an IP policy to redirect Internet traffic to the cache servers. You can apply a global or local policy. A global policy takes effect on all ports as soon as you configure the policy. A local policy does not take effect until it is assigned to an interface. If you assign a local policy, assign it to the output port connected to the Internet. The policy sends all HTTP traffic addressed as output traffic to the port to the CPU instead for processing and forwarding.
2 Configuring TCS NOTE Where a non-well-known port is configured for the variable, a policy with port “0” needs to be configured as described in “Enabling TCS” on page 44.
Configuring TCS 2 Assigning web cache servers to cache groups TCS requires all cache servers to belong to a cache group. To assign cache servers to a different cache group, use the server cache-group command. The ServerIron ADX uses one of two possible methods to distribute requests among the servers in a cache group. These are the least-connection method or a hashing algorithm based on source and destination IP addresses.
2 Configuring TCS Enabling TCS 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 TCS 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. ServerIronADX(config)# ip policy 2 cache tcp 80 local ServerIronADX(config)# int e 18 ServerIronADX(config-if-18)# ip-policy 2 Syntax: ip-policy The variable specifies index of the ip policy that defines the web traffic that you want to direct towards the cache servers.
2 Other TCS options 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. ServerIronADX(config)# interface ethernet 3 ServerIronADX(config-if-3)# no cache-group 1 Syntax: [no] cache-group Assigning an interface to a cache group To assign an interface to cache group, enter the following command.
Other TCS options 2 Syntax: [no] server cache-router-offload NOTE FTP is not supported when cache-router-offload is enabled. Cache Route Optimization example The Cache Route Optimization (CRO) feature solves a typical network topology dilemma, in which a cache server’s default gateway is not the most direct route to the client. Figure 10 shows an example of a network with this topology.
2 Other TCS options You can reduce the burden on the BAR by enabling CRO. This feature configures the ServerIron ADX to use the information in its Layer 4 session table to recognize that the return traffic actually should go to the RAS instead of the BAR, and send the return traffic directly to the RAS. Thus, the return traffic does not needlessly add overhead to the BAR. FIGURE 10 Cache route optimization Internet Web servers www.oldnews.com 1.0.0.1 www.livenews.com 1.0.0.3 www.stockquotes.com 1.0.
Other TCS options 2 • The BAR does not send an ICMP redirect in this case, as you might expect. A router sends ICMP redirects only if the following conditions are met: • The interface on which the packet comes into the router is the same as the interface on which the packet gets routed out. • The route being used for the outgoing packet must not have been created or modified by an ICMP redirect, and must not be the router's default route.
2 Other TCS options When the cache server transmits the next packet, the ServerIron ADX compares its Layer 4 header to the state table and gets a match and now the entry has a MAC address in the MAC address field. The ServerIron ADX replaces the destination address with the stored MAC address and transmits the packet at Layer 2 using the new “optimum” MAC address. Thus all packets except the first packet are sent directly to the optimum router.
Other TCS options 2 However, if the time since the last packet the ServerIron ADX sent to the cache server and the cache server’s response increases significantly, or the cache server’s reply never reaches the ServerIron ADX but instead takes an alternate path to the client, the ServerIron assumes that the cache server has stopped responding. When this occurs, the ServerIron ADX marks the cache server FAILED and stops redirecting client queries to the cache server.
2 Other TCS options ServerIronADX(config)# server cache-group 1 ServerIronADX(config-tc-1)# source-nat ServerIronADX(config-tc-1)# dest-nat These commands configure a source IP address at the global CONFIG level of the CLI, then change the CLI to the cache group configuration level and enable source NAT and Destination NAT. Source NAT configures the ServerIron ADX to change the source IP address in a client query from the client’s IP address to configured source IP address.
Other TCS options 2 ServerIronADX(config-rs-server1)# port http url “HEAD/” ServerIronADX(config-rs-server1)# port ssl ServerIronADX(config-rs-server1)# exit ServerIronADX(config)# server cache-name cs2 3.3.3.
2 Other TCS options NOTE If you configure the ServerIron ADX for Server Load Balancing (SLB) in addition to TCS, and the SLB configuration provides load balancing for your cache servers, then content will be duplicated on the cache servers as a result of the SLB predictor (load balancing metric). The SLB predictor works differently from the TCS hash mechanism and assumes that content is duplicated across the load-balanced server.
Other TCS options 2 • "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 sequentually: d1 + d2 + ...+ d15 + d16 + s1 + s2 + ... + s15 + s16. This yields a 1-byte value that is used as the hash value. • This 1-byte hash value is used to map to an entry in the hash table. Each entry maps to an active cache server.
2 Other TCS options TABLE 4 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 125.24.32.12 149.165.16.233 C1 125.24.32.12 189.12.122.233 C1 125.24.32.12 189.12.122.
Other TCS options 2 Configuring an increased hash bucket count You can set the size of the TCS hash bucket count to a value from 256 to 16384 using the following system-max command. ServerIronADX(config)# system-max tcs-hash-table-size 2048 Syntax: [no] system-max tcs-hash-table-size The hash-table-size variable specifies the size that you want to configure the hash table. Acceptable values are: 256, 512, 1024, 2048, 4096, 8192 and 16384.
2 Other TCS options NOTE You cannot use the cache server spoofing feature with the Reverse Proxy SLB feature on the same ServerIron ADX. When a cache server makes a request for content from the origin server, it can do one of the following: • The cache server replaces the requesting client's IP address with its own before sending the request to the Internet. The origin server then sends the content to the cache server.
Other TCS options 2 ServerIronADX# show cache-group Cache-group 1 has 1 members Admin-status = Enabled Active = 0 Hash_info: Dest_mask = 255.255.255.0 Src_mask = 0.0.0.0 Cache Server Name cs1 Admin-status L4-Hash-Buckets L7-Hash-Buckets 6 0 0 Name: cs1 IP: 192.168.1.
2 Other TCS options Optionally, you can direct the ServerIron ADX to send client requests to another available cache server in the same cache-group that has not reached its maximum connection threshold without changing the current hash distribution. Use the reselect-server-if-overloaded command under the cache-group configuration as shown in the following.
Other TCS options 2 Setting the cache server weight You can assign a performance weight to each server. Servers assigned a larger or higher weight receive a larger percentage of connections. To set the weight for cache server1 to 5 from the default value of 1, enter the following commands. ServerIronADX(config)# server cache-name server1 ServerIronADX(config-rs-server1)# weight 5 Syntax: weight Both the variable may have any value between 1 to 65000.
2 Other TCS options This example assumes that a source IP address is configured and Source NAT and Destination NAT also are enabled, if applicable. 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.
Other TCS options 2 This option is simple because it does not require any configuration changes on the ServerIron ADX. However, this option immediately disconnects all users from the cache server, whereas the above options allow the server or service to gracefully shut down (unless you use the force shutdown option).
2 Other TCS options Traffic flow of passive FTP Using normal or passive FTP, a client begins a session by sending a request to communicate through TCP port 21, the port that is conventionally assigned for this use at the FTP server. This communication is known as the Control Channel connection. Using passive FTP, a PASV command is sent instead of a PORT command.
Other TCS options Client CIP ServerIron ADX 1a Ctrl (CIP:x - RIP:21) 3b Ctrl (TIP:i - RIP:21) 2a Data (CIP:z - RIP:y) 4b Data (TIP:j - RIP:k) 2 Real Server RIP 3a Ctrl (TIP:i - RIP:21) 4a Data (TIP:j - RIP:k) 1b Ctrl (CIP:x - RIP:21) 2b Data (CIP:z - RIP:y ) CIP-Client IP Address RIP-Real Server IP Address TIP-Cache Server IP Address Transparent Cache Server TIP TCS with spoofing In Figure 14, the cache server is spoofing the client's IP address instead of using its own IP address when accessi
2 Other TCS options Real Server RIP R3 R4 Transparent Cache Server TIP ServerIron ADX 1 ServerIron ADX 2 Session Sync Link R1 R2 Client CIP Asymmetric flow The control and data traffic between a client and cache server or between a cache server and a real server can be asymmetric as described in Figure 16.
Policy based caching 2 Enabling passive FTP caching There is no specific CLI command to enable passive FTP caching. To enable passive CLI caching, configure “port ftp” within a cache-server configuration, as shown in the following. ServerIronADX(config)# server cache-name CacheServer6 ServerIronADX(config-rs-CacheServer6)# port ftp Whether the data channel is in active mode or passive mode depends on the operation of the FTP Client and Server.
2 Policy based caching Creating a set of filters using access-list First create a set of filters using the access-list command at the CLI. You can use regular or extended access lists. Applying access-list to cache group Apply the access-list to the desired cache group as follows. ServerIronADX(config)# server cache-group 1 ServerIronADX(config-tc-1)# filter-acl 1 ServerIronADX(config-tc-1)# exit In the above example, the filters defined in access-list 1 are used for cache-group 1.
Policy based caching 2 The variable specifies the ID of the IPv4 or IPv6 ACL being used for bypass caching. You must use ipv6 parameter if the ACL being used for bypass caching is an IPv6 ACL. The above bypass caching ACL will be evaluated first. If traffic matches this ACL, this traffic will be sent directly to the Internet. NOTE This bypass caching ACL is global in scope i.e. it will apply to all cache-groups. It should be configured as a permit ACL.
2 Content aware cache switching Content aware cache switching Content aware cache switching (CSW in a TCS environment) uses information in the header of an HTTP request to determine how or if content should be retrieved from a cache server. Using the text in a URL string, the ServerIron ADX sends a request from a client to a cache server or to the Internet according to user-defined policies.
Content aware cache switching 2 Basic example of content aware cache switching The diagram in Figure 19 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 1. Since 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 Syntax: csw-rule r1 url prefix | suffix | pattern"" Syntax: csw-policy Syntax: match r1 forward Syntax: default forward The csw-rule r1 url suffix gif command consists of two parts. The first part specifies what kind of matching the policy does on the selection criteria. Three kinds of matching methods are supported: • The prefix keyword compares the selection criteria to the beginning of the URL string.
2 Content aware cache switching A server group can contain one or more cache servers. 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. When configuring content aware cache switching, you establish the IP address of each cache server and specify the server group to which it belongs.
Content aware cache switching 2 Configuring policies for dynamic content For dynamic Web pages, such as Active Server Pages, it may be preferable not to cache the content. You can configure CSW policies on the ServerIron ADX that cause requests for these kinds of pages to bypass the cache servers and go directly to the Internet. In addition, the ServerIron ADX examines directives in the HTTP 1.0 or 1.1 header to determine whether a request should be sent to the cache servers or to the Internet.
2 Content aware cache switching FIGURE 20 Sending requests for Active Server Pages to the Internet Internet Client requests for URLs that contain asp anywhere within are directed to the Internet BAR Web Queries RAS SI CacheServer1 192.168.1.101 CacheServer2 192.168.1.102 CacheServer3 192.168.1.
Content aware cache switching 2 ServerIronADX(config)# csw-rule r1 url pattern “asp” ServerIronADX(config)# csw-policy policyA1 ServerIronADX(config-csw-policyA1)# match forward 0 ServerIronADX(config-csw-policyA1)# default forward 100 ServerIronADX(config-csw-policyA1)# exit The pattern method in the command causes the policy to look for the selection criteria anywhere within the URL string. The match forward 0 command looks for URL strings that contain the text "asp"; for example, /active/q.
2 Content aware cache switching state machine to track HTTP request/response transactions. Every HTTP request will be analyzed and forwarded according to the CSW configuration. When CSW makes a decision to switch from one server to another server, it will send a TCP reset to the previously chosen server and establish a TCP connection to the newly selected server Disabling HTTP Keep Alive mode HTTP keep-alive mode is the default mode for TCS CSW.
2 Content aware cache switching ServerIronADX 1000#sh server proxy keep-alive Keep-alive connection statistics: ... TCB status: Total in mem Allocated from mem Allocated from pool Allocated from FS po Free to FS mem Clean reusables None-reusable to mem = = = = = = = 100000 2 36 0 0 0 0 Connection unreusable reasons: Small window = Not reusable = Image = Delayed ACK list status: Total TCBs in list = Generated ack num = ...
2 Traffic Distribution based on Cache Server Capacity Traffic Distribution based on Cache Server Capacity This feature allows you to use SNMP to monitor the load on cache servers and load-balance the cache servers using that information. For this feature to operate, the cache server must run an SNMP agent and support MIBs that can be queried by the SNMP manager software on the ServerIron ADX.
Traffic Distribution based on Cache Server Capacity TABLE 6 2 Load balancing action as determined by cache server state Cache Server States ServerIron ADX load balancing action OFFLINE (8): Cache is out-of-service and unable to handle any traffic. 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.
2 Traffic Distribution based on Cache Server Capacity ServerIronADX(config-tc-1)# hash-mask 255.255.255.255 0.0.0.0 ServerIronADX(config-tc-1)# cache-name cs100 ServerIronADX(config-tc-1)# predictor snmp-weighted oid 1 Syntax: [no] predictor snmp-weighted oid The variable specifies the index number for the SNMP object identifier that you want to use for operating SNMP weighted load sharing for this cache group.
Displaying cache information 2 Displaying cache information To display cache information, enter the following command at any level of the CLI. ServerIronADX# show cache-group Cache-group 1 has 1 members Admin-status = Enabled Hash_info: Dest_mask = 255.255.255.0 Src_mask = 0.0.0.0 Cache Server Name cs1 cs2 cs3 Admin-status 6 6 6 Hash-distribution L7-hash-distribution 4 21 3 22 4 21 HTTP Traffic From <-> to Web-Caches ===================================== Name: cf Client Web-Server Total IP: 209.157.
2 Displaying cache information TABLE 8 TCS information (Continued) This field... Displays... Hash_info The source and destination mask for the cache distribution hash value. The ServerIron ADX compares the web site’s IP address to the hash mask to determine which cache server to send a a request for a given web site to. As long as the cache server is available, the ServerIron ADX always sends requests for a given IP address to the same cache.
Displaying cache information TABLE 8 2 TCS information (Continued) This field... Displays... TotConn The total number of connections between hosts and the cache server. Cache->Web-Server The total number of packets and octets from cache server to web servers. Web-Server->Cache The total number of packets and octets from web servers to cache server. Client->Cache The total number of packets and octets from clients to cache server.
2 Sample configurations Sample configurations Basic TCS configuration Figure 21 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 Area Router (BAR). The cache servers are labeled C1, C2, and C3. FIGURE 21 Basic TCS configuration example Internet Remote Access Server (RAS) The CAR connects the clients (through the ServerIron) to the cache servers.
Sample configurations 2 In a transparent caching scheme, the ServerIron ADX acts as the traffic redirector and the cache servers accept requests for any destination IP address. A cache server that accepts requests for any IP address are running in promiscuous mode. The client does not have to configure anything on their web browser. Thus, the caching is “transparent” to the client. It is this transparent characteristic that sets proxy-based caching and transparent caching apart.
2 Sample configurations Defining the cache groups A cache group is a collection of ServerIron ADX input ports and cache servers. You can define up to four cache groups on a ServerIron ADX. Each cache group can have a cache server farm with up to 256 caches. If a cache group has more than one cache server, the ServerIron ADX distributes traffic among the servers using a hashing algorithm. (Refer to “Controlling traffic distribution among cache servers” on page 53.
Sample configurations 2 Traffic entering from a BAR destined for a RAS is not cached because rule 2 (output redirection enabled) is not true for the RAS ports. Traffic from RAS-to-RAS is not cached because rule 2 is false in this case as well. Traffic from RAS-to-BAR is cached because both rules are true. Both rules are true for BAR-to-BAR traffic as well. This type of traffic rarely, if ever, occurs.
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 Policy based caching configuration The following configuration implements the topology described in Figure 22.
2 Sample configurations NOTE Even when use the FastCache feature, the ServerIron ADX still performs a Layer 3 health check by regularly pinging the cache server. In addition, you can continue to use HTTP health checking. FIGURE 23 FastCache feature used for asymmetric topology Internet Web Servers www.livenews.com 1.0.0.3 www.oldnews.com 1.0.0.1 www.stockquotes.com 1.0.0.2 Border Access Router (BAR) Web Queries 208.95.8.3 Remote Access Server (RAS) e18 (output port) e17 SI 208.95.7.3 208.95.
Sample configurations 2 To prevent this situation from occurring: • Define the other interface on the cache server as a cache, but do not place the cache in a cache group. Policy-based cache failover In some TCS configurations, the ServerIron ADX is connected to the clients and also to the Internet through the same router.
2 Sample configurations FIGURE 24 Configuration using policy-based Cache Failover (CFO) Internet Web servers www.oldnews.com 1.0.0.1 www.livenews.com 1.0.0.3 www.stockquotes.com 1.0.0.2 The router has a policy that forwards HTTP requests to a virtual IP address. To enable the ServerIron to properly forward the requests, add the virtual IP address to the cache group. Border Access Router (BAR) Web Queries 208.95.8.3 Remote Access Server (RAS) e18 (output port) e17 SI 208.95.7.
Sample configurations 2 TCS with reverse proxy TCS with reverse proxy relieves clients who have configured their web browsers to point to a proxy server from the need to reconfigure their browsers.
2 Sample configurations As shown in Figure 25, some clients’ web browsers are configured to use proxy IP address 209.157.22.2, while other client’s web browsers are not configured to use a proxy server. You can configure the ServerIron ADX to satisfy both sets of clients. Follow the steps given below to configure Proxy Server Cache Load Balancing. 1. Add the cache servers as customary, using the server cache-name command. 2.
High availability designs with TCS 2 ServerIronADX(config)# server virtual-name-or-ip Proxy 209.157.22.
2 High availability designs with TCS Layer 3 basic TCS configuration Figure 26 illustrates a basic Layer 3 TCS configuration. FIGURE 26 Basic TCS configuration e 1/ 22 17 2. 32 .1 .1 Cache Server 172.32.1.22 10.10.20.1 VLAN 100 tag e 1/1-1/4 ve 1 10.10.10.1 SI VLAN 200 untag e 1/5-1/7 ve 2 ve1 (tag e1) Port e1 Port e1 10.10.20.2 Router 10.10.10.2 Router Port e7 Port e7 195.92.10.1 195.92.20.1 Clients Multimedia Server DNS Server 195.92.20.102 195.92.20.
2 High availability designs with TCS 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 ServerIronADX(config)# interface ethernet 1/22 ServerIronADX(config-if-1/22)# ip address 172.32.1.1 255.255.255.
2 High availability designs with TCS ServerIronADX(config)# vlan 16 by port ServerIronADX(config-vlan-16)# untagged ethe 1/16 ServerIronADX(config-vlan-16)# static-mac-address 00e0.52c2.8b00 ethernet 1/16 ServerIronADX(config-vlan-16)# exit ServerIronADX(config)# interface ve 1 ServerIronADX(config-ve-1)# ip address 10.10.20.1 255.255.255.0 ServerIronADX(config-ve-1)# ip vrrp-extended vrid 1 ServerIronADX(config-ve-1-vrid-1)# backup ServerIronADX(config-ve-1-vrid-1)# ip-address 10.10.20.
High availability designs with TCS 2 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(config)# vlan 500 by port ServerIronADX(config-vlan-500)# untagged ethe 1/8 to 1/12
2 High availability designs with TCS ServerIronADX(config)# ServerIronADX(config)# ServerIronADX(config)# ServerIronADX(config)# router vrrp-extended server active-active-port ethe 1/16 vlan-id 16 server force-delete no server l4-check Layer 3 active-active TCS configuration with a remote cache server Figure 28 illustrates an active-active TCS configuration with a remote cache server. FIGURE 28 Active-active TCS configuration with remote cache server untag e 1/1-1/4 ve 1 SI 10.10.20.
High availability designs with TCS 2 ServerIronADX(config-ve-1-vrid-1)# ip-address 10.10.20.10 ServerIronADX(config-ve-1-vrid-1)# track-port ve 2 ServerIronADX(config-ve-1-vrid-1)# track-port ve 3 ServerIronADX(config-ve-1-vrid-1)# enable ServerIronADX(config)# interface ve 2 ServerIronADX(config-ve-2)# ip address 10.10.10.1 255.255.255.0 ServerIronADX(config-ve-2)# ip vrrp-extended vrid 2 ServerIronADX(config-ve-2-vrid-2)# backup ServerIronADX(config-ve-2-vrid-2)# ip-address 10.10.10.
2 High availability designs with TCS ServerIronADX(config)# vlan 500 by port ServerIronADX(config-vlan-500)# untagged ethe 1/8 to 1/12 ServerIronADX(config-vlan-500)# router-interface ve 3 ServerIronADX(config-vlan-500)# exit ServerIronADX(config)# vlan 16 by port ServerIronADX(config-vlan-16)# untagged ethe 1/16 ServerIronADX(config-vlan-16)# static-mac-address 00e0.52ee.d600 ethernet 1/16 ServerIronADX(config-vlan-16)# exit ServerIronADX(config)# interface ve 1 ServerIronADX(config-ve-1)# ip address 10.
High availability designs with TCS 2 Layer 3 Sym-Active SLB with TCS Figure 29 illustrates a Sym-Active configuration with TCS, using VRRPE. NOTE To allow failover and session synchronization in an Sym-Active configuration to work properly, there must be a Layer 2 connection between the two ServerIron ADXs. This connection is required so that Layer 2 broadcasts, including ARP to the VIP from the ServerIron ADX with lower symmetric priority, can be exchanged between the two ServerIron ADXs.
2 High availability designs with TCS 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 172.1.1.3 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 172.1.1.
High availability designs with TCS 2 ServerIronADX(config-ve-1-vrid-5)# track-port e 3/2 ServerIronADX(config-ve-1-vrid-5)# track-port e 3/3 ServerIronADX(config-ve-1-vrid-5)# enable ServerIronADX(config-ve-1)# ip vrrp-extended vrid 6 ServerIronADX(config-ve-1-vrid-6)# backup ServerIronADX(config-ve-1-vrid-6)# ip-address 100.1.1.
2 High availability designs with TCS ServerIronADX(config-rs-rs29)# port http url "HEAD /" ServerIronADX(config-rs-rs29)# port ftp ServerIronADX(config-rs-rs29)# port dns ServerIronADX(config-rs-rs29)# exit ServerIronADX(config)# server real rs30 100.1.1.
High availability designs with TCS 2 ServerIronADX(config)# server virtual-name-or-ip mms 10.2.24.103 ServerIronADX(config-vs-mms)# sym-priority 254 ServerIronADX(config-vs-mms)# sym-active ServerIronADX(config-vs-mms)# port mms ServerIronADX(config-vs-mms)# bind mms rs31.1 mms rs30.1 mms rs29.1 mms rs29 mms ServerIronADX(config-vs-mms)# bind mms rs30 mms rs31 mms ServerIronADX(config-vs-mms)# exit ServerIronADX(config)# server virtual-name-or-ip dns 10.2.24.
2 High availability designs with TCS NetIron(config-ve-1-vrid-3)# ip-address 172.1.1.1 NetIron(config-ve-1-vrid-3)# track-port e 1 NetIron(config-ve-1-vrid-3)# track-port e 2 NetIron(config-ve-1-vrid-3)# track-port e 8 NetIron(config-ve-1-vrid-3)# enable NetIron(config-ve-1)# ip vrrp-extended vrid 4 NetIron(config-ve-1-vrid-4)# backup NetIron(config-ve-1-vrid-4)# ip-address 172.1.1.
High availability designs with TCS 2 ServerIronADX(config-ve-1-vrid-6)# track-port e 3/2 ServerIronADX(config-ve-1-vrid-6)# track-port e 3/3 ServerIronADX(config-ve-1-vrid-6)# enable ServerIronADX(config-ve-1-vrid-6)# exit ServerIronADX(config)# interface ve 2 ServerIronADX(config-ve-2)# ip address 10.2.24.251 255.255.255.
2 High availability designs with TCS ServerIronADX(config-rs-rs30)# port http url "HEAD /" ServerIronADX(config-rs-rs30)# port ftp ServerIronADX(config-rs-rs30)# port dns ServerIronADX(config-rs-rs30)# exit ServerIronADX(config)# server real rs31 100.1.1.
High availability designs with TCS 2 ServerIronADX(config)# server virtual-name-or-ip dns 10.2.24.105 ServerIronADX(config-vs-dns)# sym-priority 254 ServerIronADX(config-vs-dns)# sym-active ServerIronADX(config-vs-dns)# port dns ServerIronADX(config-vs-dns)# bind dns rs31.1 dns rs30.1 dns rs29.1 dns rs29 dns ServerIronADX(config-vs-dns)# bind dns rs30 dns rs31 dns ServerIronADX(config-vs-dns)# exit ServerIronADX(config)# server virtual-name-or-ip ssl 10.2.24.
2 High availability designs with TCS Layer 2 Switch 195.92.10.5 Port e1/1 Port e1/10 SI-A Port e1/13 Port e1/5 Cache1 195.92.10.22 Port e1 195.92.10.1 Port e3 Server Router Port e1/13 Port e1/1 SI-B Client Port e1/10 Port e1/5 195.92.10.6 Layer 2 Switch Client Configuring Router R1 The following commands configure router R1 in Figure 27.
High availability designs with TCS 2 ServerIronADX(config)# vlan 13 by port ServerIronADX(config-vlan-13)# untagged ethe 1/13 ServerIronADX(config-vlan-13)# no spanning-tree ServerIronADX(config-vlan-13)# exit ServerIronADX(config)# ip address 195.92.10.5 255.255.255.0 ServerIronADX(config)# ip default-gateway 195.92.10.
2 Interoperability issues with cache servers Interoperability issues with cache servers The defaults for many of the ServerIron ADX’s parameters are applicable to most TCS environments. However, depending on the brand of cache server you use, you might need to make minor modifications either to the cache server or to the ServerIron ADX for interoperability. CacheFlow server version 2.x.x and 3.x.
Cache Persistence using URL Hashing 2 On this page, disable IP Fast Output. When this feature is disabled, the cache server performs a route lookup and sends the packet to the correct destination address. Cache Persistence using URL Hashing The ServerIron ADX enables traffic distribution among cache servers in a TCS setup after inspecting and hashing based on the request URL. This enables cache persistence based on the requested URL and minimizes duplication of content among multiple cache servers.
2 Cache Persistence using URL Hashing 1. Get http://login.yahoo.com/config/mail?.src=ym HTTP 1.1 2. Get /config/mail?.src=ym Host: login.brocade.com The following table demonstrates which part of the string would be used for hashing either of the prior examples depending the method selected with the csw-hash url command. TABLE 9 Hashing methods Method String used for hashing Complete login.brocade.com/confg/mail?.src=ym path-only config/mail path-and-parameters confg/mail?.
Cache Persistence using URL Hashing 2 NOTE Since 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.
2 Cache Persistence using URL Hashing 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 . 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.
Cache Persistence using URL Hashing 2 ServerIronADX(config-csw-p1)# match r1 forward 1 ServerIronADX(config-csw-p1)# match r1 hash-persist url search-url “v=” offset 0 length 16 TABLE 10 Results for parsing the entire URL by method Method String used for hashing pattern string only bUfp24dwzOA&playnext=1&videos=XA7MyzKoQXQ&feature=featured pattern string with a delimiter of “&” cbUfp24dwzOA pattern string with a length value of “16” bUfp24dwzOA&play Parsing the host string Parsing the host stri
2 Cache Persistence using URL Hashing system will start the second step. The second step in the process is to adjust the starting place on the URL string by moving it by the number of characters defined by a value specified in the . If the pattern string is empty, the system will not search the pattern part, and use the beginning of URL string as the start point of the third step.
Cache Persistence using URL Hashing 2 ServerIronADX(config-csw-p1)# match r1 hash-persist url search-host “www.” offset 0 length 5 Syntax: [no] hash-persist url search-url offset length The contents of the variable is the same as described in “Parsing using the “pattern string” only”. The contents and operation of the is the same as described in “Parsing using the “pattern string” only”.
2 Cache Persistence using URL Hashing ServerIron ADX supports multiple pattern search for the same rule. Support is provided for up to 4 different pattern strings as shown in the following example.
