There are many ways to remove trailing slashes, you could use a regular expression match similar to your rewrite rule, but I would probably avoid that and do something like this instead: # Read in the path $path = http.getPath(); # if it's the root dir exit the script if( $path =="/" ) break; # if we end with a slash, then redirect; this does a 302 redirect if( string.endswith( $path,"/" )) http.redirect( string.drop( $path,1 )); This script uses http.redirect() which issues a 302 redirect, if you want it to be a 301, then you could switch the last block with the one below. The version below uses the more long winded http.sendResponse() , but this function allows you to send back any HTTP resopnse you wish, not only redirects. # Issue a 301 permanent redirect if( string.endswith( $path,"/" )){    $location = string.drop( $path,1 )    http.sendResponse( "301 Moved","text/plain","Object moved to: ". $location,"Location: ". $location ); } ... View more

The value you are monitoring is an SNMP Counter - it's an increasing count of the data transferred. To get a bandwidth rate, you need to sample the counter periodically (for example, every 10 seconds), the difference between the two samples will be the data transferred in that interval. There are a few code examples that illustrate this technique - see Gathering statistics from a cluster of Traffic Managers for starters.  And many SNMP monitoring agents will perform this rate calculation for you (ever-increasing counters are a common pattern in SNMP).  Some of our customers have recommended Monitoring Stingray using MRTG or using PRTG Network Monitor. Alternatively, you could create an action that was triggered when the bwlimited event was raised (this is one of the license key events).  Actions can raise SNMP traps (amongst other possibilities) - see Feature Brief: Event Handling in Stingray Traffic Manager ... View more

Try the following request rule $ip = request.getRemoteIP(); # Don't intercept requests from my IP address if( $ip =="123.45.67.89" ) break; http.sendResponse( "503 Too Busy", "text/plain",   "Sorry. No one can serve you right now", "" ); There are lots of other things you could do rather than directly sending the response: http.redirect( "http://en.wikipedia.org/wiki/Special:Random" ); Also, take a look at Using Stingray Traffic Manager as a Webserver. Finally, you could continue to use your .htaccess solution if you passed the source IP address through to Apache, using mod_remoteip as described in IP Transparency: Preserving the Client IP address in Stingray Traffic Manager ... View more

The Stingray virtual appliance is designed to be a complete, closed device. Although it's possible to get shell access on the appliance, 99% of the configuration is performed though the web user interface and the only time shell access is normally used is for major upgrades. You can upload custom monitors and other scripts that can be used by the Stingray software using the UI. However, there are three good reasons why you should not use shell access to modify configuration or install additional services: Configuration changes that are made directly may be overwritten by the Stingray software; the Stingray software monitors certain configuration files and updates them if they do not match the configuration comitted via the UI. For example, the Stingray software manages the configuration for the network interfaces, so any changes you make will be lost when the UI recommits the configuration; Additional software packages and modifications to unmonitored configuration files will not be preserved across major upgrades, and may be lost during minor upgrades; The virtual appliance is thoroughly tested; any changes you make fall outside what we can support you on. The virtual appliance is provided as a convenience - a single Stingray product with a single maintenance agreement to cover support and updates. All this said, it's a fairly standard Linux distribution, and if you're confident and appreciate the implications of doing so, there's nothing to stop you making custom modifications.  You can even stop Stingray managing the OS configuration files, to prevent it overwriting any changes you want to make - check out the configuration keys starting "appliance!manage" in the Configuration System Guide ( Stingray Product Documentation) to disable the management of certain components.  All of this falls outside your Riverbed Support, and please advise our support team if you raise a ticket that may be related to custom OS modifications. If you would like to flexibility that comes with being able to configure the OS to a greater degree or add additional software packages, you can install the Stingray software inside a Linux VM of your own making. Riverbed will provide full support and updates for the Stingray software, and you retain full control of (and responsibility for) the operating system. ... View more

Yes, IP Transparency does work with SSL Passthrough. Another option could be to decrypt SSL on the Traffic Manager, let it add the X-Cluster-Client-IP header, then re-encrypt in the pool's SSL settings, if you can't get IP Transparency working. ... View more

You can't do this with the built-in Health Monitors (Feature Brief: Health Monitoring in Stingray Traffic Manager), but you can create a custom health monitor to do this. There's a good selection of perl, python, ruby and other implementations of NTLM-aware client libraries you can use, but here's a health monitor that just uses wget, so you can run in on the Stingray Virtual Appliance. #!/bin/bash # Process the health monitor arguments args=( [email protected] ); for (( i=0; $i < $# ; i++ )) do   [[ "${args[$i]}" =~ --ipaddr= ]] && ipaddr=${args[$i]#*=} && continue   [[ "${args[$i]}" =~ --port= ]]  && port=${args[$i]#*=} && continue   [[ "${args[$i]}" =~ --node= ]]  && node=${args[$i]#*=} && continue   [[ "${args[$i]}" =~ --host= ]]  && host=${args[$i]#*=} && continue   [[ "${args[$i]}" =~ --path= ]]  && path=${args[$i]#*=} && continue   [[ "${args[$i]}" =~ --user= ]]  && user=${args[$i]#*=} && continue   [[ "${args[$i]}" =~ --pass= ]]  && pass=${args[$i]#*=} && continue   [[ "${args[$i]}" =~ --verbose ]] && verbose="--verbose" && continue   [[ "${args[$i]}" =~ --failures_left= ]] && failures_left=${args[$i]#*=} && continue done # Path and Host header are optional. If we don't have them, set defaults. [ -z "$path" ] && path="/" [ -z "$host" ] && host="$node:$port" # Disable verbose output if not requested. [ -z "$verbose" ] && verbose="" # All server headers and body are stored in the output variable. output=$( wget "--header=Host: $host" --http-user="$user" --http-passwd="$pass" \   $verbose -O - -S http://$ipaddr:$port$path 2>&1 ) [ $verbose ] && echo $output # The output will have a few 401, and at least 1 200 response code if we authenticated. echo $output | grep "HTTP/1.1 200 OK" > /dev/null result=$? [ $result -ne 0 ] && echo $output >&2 exit $result It's a while since I've tested this, so please first give it a go from the command line and verify that it works: $ ./ntlmtest.sh --ipaddr=1.1.1.1 --port=80 --node=www.foo.com \     --host=www.foo.com --path=/wibble --user=owen --pass=mememe \     --verbose --failures_left=2 $ echo $? If the monitor was successful, then echo $? should print ' 0 '. When you install this as a custom health monitor, you'll need to add the following parameters: host (optional): the host header to use in the request; otherwise, we'll guess it from the node's name and port path (optional): defaults to '/' user : the NTLM username pass : the NTLM password ... View more

You're spot on there. Stingray will attempt to find the java binary in your path; if you system doesn't have one, then you can simply download an appropriate one from Sun/Oracle (or even OpenJDK if you prefer). Of course, you only need Java if you plan on building some Feature Brief: Java Extensions in Stingray Traffic Manager. The Traffic Manager will run just fine without it: Enable or disable Java from the Global Settings page ... View more

Very good question... it does depend on what you mean by a 'persistent session' though! Concurrent Connections There's no built-in limit to the number of concurrent connections that Stingray can handle.  A fully-established L7 connection requires two file descriptors (one for the client-side connection and one for the server-side connection), although an idle HTTP connection just requires one (because Stingray recycles the server-side connections as efficiently as possible). The limiting factors are the memory available in the system, and the number of TCP ports. Each connection consumes a minimum of 5Kb memory; an HTTP connection typically consumes 10Kb, and additional features such as TrafficScript rules, SSL processing and the like will increase this to 20Kb or more.  Each server-side connection requires a unique 4-tuple (source IP address and port, destination IP address and port), so Stingray is typically limited  to about 60,000 concurrent TCP connections to each back-end node.  HTTP keepalive processing reuses connections to minimize the effect of this limitation, and you can use the Connection Limiting capability to limit the number of concurrent transactions against each node, queuing pending transactions in the traffic manager. Notwithstanding these caveats, we've run Stingray with about 1 million fully-established L7 connections in the lab, and there's no theoretical upper limit. Persistence Records Persistence records are used by Stingray's Session Persistence feature (Feature Brief: Session Persistence in Stingray Traffic Manager).  Stingray has a fixed-size session persistence cache that is created at start-up - you will need to restart the Stingray software if you want to change the size of this cache: Configure the cache sizes in the Global Settings configuration page in the Stingray Admin Interface The Feature Brief: Session Persistence in Stingray Traffic Manager document describes the behavior of the session persistence cache in detail, and considers what happens when it fills up and the least-recently-used entries are discarded.  You can instrument the number of entries in the cache and the age of the oldest one using the SNMP or Activity Monitor counters: In the first 4 minutes, traffic is steady at 300 new sessions per minute and the session cache fills.  Initially, the max age grows steadily but when the cache fills (after 2 minutes) the max age remains fairly stable as older entries are dropped.  In the last minute, no new entries were added, so the cache remains full and the max-age increases steadily. ... View more

Stingray does indeed use a 'greedy'-like algorithm to process connections.  When you have a simple configuration and most of your connection processing is simple layer 7 management with few trafficscript rules, then the behavior of this algorithm will skew the CPU usage on your system.  For lower traffic levels, Stingray may appear to be more heavily loaded than it really is, but as traffic levels increase, Stingray operates in a more efficient (less greedy) fashion to accommodate the higher load. An analogy - pizza! Consider the Lightning Fast Pizza Company (LFPC) - always striving to get your pizza delivered as quickly as is humanly possible. LFPC operate a fleet of 8 delivery trucks (just like your Stingray server has 8 cores).  Pizzas roll out of the conveyor oven as fast as they are ordered by customers, and when a delivery truck pulls into the bakery, it scoops up all the waiting pizzas and heads out to deliver them.  Pizza deliveries take a matter of seconds - the trucks really are that fast! When orders are slow, trucks will often wait in a line at the bakery, waiting for a pizza to pop out of the oven.  As soon as one is cooked, it's collected and the truck departs.  In this situation, the trucks are used quite inefficiently - they spend time waiting, and each truck only carries one pizza at a time - but the pizzas are delivered piping hot! When orders speed up, several pizzas may pop out at the same time.  There may not be a queue - a truck might arrive and half a dozen pizzas are there, waiting to be taken to customers.  In this situation, we still deliver pizzas as fast as possible with the resources (trucks) we have, but these resources are used more efficiently. So, just because all of the trucks are busy (delivering single pizzas at a time), that does not mean we are anywhere near the peak capacity of our pizza delivery business. What's this got to do with Stingray? The trucks are like Stingray processes (Stingray runs one process per CPU core).  The pizzas are like network events - they arrive unpredictably and must be handled by a stingray process. Like the delivery trucks, each Stingray process runs in a loop - polling to see if there is work to do, taking the work off the queue and then processing it. When there are only a few network events to process, the loop is very short and Stingray can execute it quickly because there's little work to do during each iteration. This uses a lot of CPU time (relatively) due to the frequency with which the loop executes, but it ensures that each connection is serviced as quickly as possible. Stingray becomes more CPU efficient as throughput increases. Each loop iteration can do more work: there are more active connections at each iteration, and there is more data pending for each connection (due to increased loop dwell time). This means Stingray can spend more time servicing requests in bigger chunks, rather then executing the loop itself. Stingray greedily uses as much CPU as it can to process the current connections as quickly as possible. At low connection rates, the CPU utilization is disproportionately high, and even when Stingray gets near to 100% utilization, there is still plenty of spare capacity to process additional connections. Is this really true? Sort of.... this is broadly true for simple workloads, where Stingray does not need to run complex rules, Aptimizer optimizations or Application Firewall policies against traffic.  In simple situations, you'll see the Stingray system spending disproportionately large amounts of time in 'system' CPU time, and less in 'user' CPU time (use vmstat to monitor this), and it's mostly the 'system' time that is elastic. When you have a complex configuration that performs a lot of layer 7 processing, the CPU profile is more linear as the load increases.  Adding more CPU cores is a cost-efficient way to increase layer 7 and other compute intensive capabilities (SSL, compression, TrafficScript etc). Of course, there are other bottlenecks in your Stingray system.  Just as if the driveway to your bakery is too narrow and the delivery trucks can't get through, your network card and the I/O capabilities of your host can become a bottleneck that limits the peak capacity of your system.  Other services (the UI, Rest API, SNMP and management daemons) also require CPU resources, although these will rarely dominate on a production system. ... View more

zinstall is the interactive script used to install the software version of Stingray Traffic Manager. It lays out the files in the filesystem, and then optionally calls the ' configure ' script to perform initial configuration and customization - admin password, license key, etc. Automating zinstall zinstall can record its installation options to a replay file, and then replay the options when installing on a different machine. To create a replay file, use the --record-to option to zinstall: # ./zinstall --record-to=install.txt NOTE: When asked to perform initial configuration, you must answer 'No', otherwise no replay file will be created. The install and configure steps have to be recorded and replayed separately. To replay this installation, use the --replay-from option: # ./zinstall --replay-from=install.txt This runs the zinstall script using the answers provided in the replay file. If a question is encountered that isn't answered, the normal prompt will appear, waiting for the answer. You can specify the --noninteractive option on the command line to cause zinstall to abort instead. Automating configure zinstall and configure are separate steps; typically, you would create a gold image of the Stingray software's filesystem using zinstall, and then 'personalize' it on each instance using configure. To record a configure script , use the --record-to option to configure: # ./configure --record-to=configure.txt To replay these configuration steps, use the --replay-from option: # ./configure --replay-from=configure.txt Note that passwords will appear in plaintext inside the replay file, but they will not printed in the output of the configure program. You might like to record the configuration, and then delete the line in the replay file that contains the password.  You will then be prompted for the password when you run configure , unless the --noninteractive option was passed. ... View more

This problem has caught out a number of users who have been using the Feature Brief: Stingray's SOAP Control API for a long time. The SOAP::Lite library has deprecated the use of 'uri' to specify the namespace for a SOAP request - see SOAP::Lite for Perl: uri and use_prefix deprecated in next release for more information.  This change is slowly rolling out as users update their SOAP::Lite library instances. In most cases, you can simply replace the call to 'uri' with a call to 'ns', as follows: my $conn = SOAP::Lite     -> ns(' http://soap.zeus.com/zxtm/1.0/VirtualServer/ ')     -> proxy("$admin_server/soap");   ... View more

This is expected behavior; it's a consequence of the connectivity ( Feature Brief: Clustering and Fault Tolerance in Stingray Traffic Manager) performed by each traffic manager to verify that it is operating correctly: Stingray will attempt to ping its front-end gateway to verify it has external connectivity, and it will attempt to ping some of the back-end nodes; as long as it can ping both the gateway and at least one active node, it will manage traffic normally. If one of the two tests fails, Stingray will conclude that it has lost network connectivity and it will voluntarily drop any traffic IP addresses or traffic shares.  It will also broadcast a 'failed' status in the internal health status messages so that its peers in the cluster know that it has dropped its traffic ip addresses and shares. You can change or disable the front-end 'gateway' test by configuring an alternative IP address to ping (see the global setting 'flipper!frontend_check_addrs'). You cannot disable the back-end node test, but if none of your nodes are able to respond to ping requests, then you can create a dummy pool that contains a node on localhost (127.0.0.1) - this local IP address should always respond to pings. Note that if you do disable or work around these connectivity tests, then the Stingray device will be unable to detect front-end or back-end network failures and initiate a failover to a working machine. ... View more

No, you don't need a license key, although you can if the packaged Stingray configurations don't meet your requirements, or if you don't want to use the subscription pricing we offer on Amazon. There are a number of pre-configured AMIs to chose from, published on Amazon's AWS Marketplace.  Other than the developer edition, each Stingray AMI contains a built-in license key, so it works 'out of the box'. You do not have to provide your own license key. New in the 9.2 release, you can also BYOL (bring your own license).  To use your own license key, select the Stingray Development Edition (this AMI has no license key, and there are no vendor charges associated with it).  You can then upload your own license key (check with the support portal if you need to modify the IP address your license key is associated with). How does licensing work on EC2? When you launch an instance of a Stingray AMI, Amazon checks that you have signed up to use the AMI. If you have, EC2 launches the instance; if you have not, EC2 refuses to launch the instance. Once the instance is running, it contacts EC2 periodically to check that it is still authorized to run. If the authorization check fails, the traffic manager will log a warning message but will continue to run normally for a grace period, the length of which is given in the log message. This prevents transient faults in EC2 from disrupting your services. If the authorization check continues to fail, the traffic manager will stop handling traffic when the grace period expires. ... View more

When Stingray rises a Traffic IP Address, it broadcasts a number of ARP replies to inform the attached Layer 2 network that it should update its ARP cache. This is to ensure that Ethernet frames directed to the Traffic IP Address in question are sent to the correct hardware interface (on the Stingray) via the correct LAN circuit. By default, Stingray will send 10 of these ARP broadcasts. In some scenarios, we find that Cisco hardware will ignore ARP broadcasts for a short period of time. The result is that, after Stingray fails over, frames will be sent to the wrong LAN segment, ultimately causing connection timeouts to your Traffic IP Addresses. So far, we know that this affects the PIX 506E Firewall, but it may apply to other products as well. To identify the problem, you can log into the Cisco device and use the ' show arp ' command to view the ARP table. If you discover that a Traffic IP Address is associated with the wrong MAC address, you can use the ' clear arp ' command to flush the table, which should correct the problem. To prevent future occurrences, we have found that increasing the number of ARP broadcasts sent by Stingray from 10 to 100 works reliably. To make this change, please log into the admin interface and navigate to: System -> Global -> Traffic Manager Fault Tolerance ...and change the " flipper!arp_count " value from 10 to 100. ... View more

When you try to start the CLI (ZEUSHOME/zxtm/bin/zcli) , you may see the following error message: ERROR: Failed to start due to SELinux restrictions (unable to load XML parser) This can occur when using SELinux, for example on Redhat Server 5. There are three possible workarounds: Disable SELinux: edit /etc/sysconfig/selinux and then reboot the system Temporarily turn off SELinux: As the root user, run the command: setenforce 0 If SELinux is in 'targetted' mode, then train it to not block this library from loading: chcon -t texrel_shlib_t $ZEUSHOME/zxtmadmin/lib/perl-soap/auto/XML/Parser/Expat/Expat.so These will then allow you to run the CLI program. ... View more

When attempting to extract any of the Virtual Appliance zip files, Windows may present an error similar to:   There is not enough space on Local Disk. You need an additional 734 PB to copy these files.   This is a known problem with the built-in zip functionality in Windows mis-computing the space required. This may also occur in WinZip. To work around this, use a different tool to extract the files, such as 7-Zip or the unzip command in most Linux distributions. ... View more

Assuming you are referring to activity state (ie. active, draining or disabled) then you will need the pool information because a node can be in a different state in different pools. If you are referring to the health status of the node then this can be retrieved without the pool name via snmp. ... View more