cancel
Showing results for 
Search instead for 
Did you mean: 

Pulse Secure vADC

Sort by:
What is Policy Based Routing?   Policy Based Routing (PBR) is simply the ability to choose a different routing policy based on various criteria, such as the last hop used, or the local IP address of the connection. As you may have guessed, PBR is only necessary where your Traffic Manager is multi-homed (ie multiple default routes) and asynchronous routing is either not possible or not desired.   There are only really two types of multi homing which we commonly deal with in vADC deployments. I am going to refer to them as "Multiple ISP", and "Multiple Link".   Multiple ISP   This is the simpler scenario, and it is seen when vADC is deployed in an infrastructure with two or more independent ISPs. The ISPs all provide different network ranges, and Traffic IP Groups are the end points for the addresses in those ranges. Pulse vADC must chose the default gateway based on the local Traffic IP Address of the connection.   Multiple Link   This is slightly more complicated because traffic destined for the vADC Traffic IP can come in via a number of different gateways. Pulse vADC must ensure that return traffic is sent out of the same gateway as it arrived through. This is also known as "Auto-Last-Hop", and is achieved by keeping track of the Layer 2 mac address associated with the connection.     Setting up Policy Based Routing on Pulse vADC   This guide will show you how to set up a process within Traffic Manager vTM such that a PBR policy is applied during software start up. The advantage of configuring vTM this way is that there are no changes to the underlying OS configuration, and as such it is fully compatible with the Virtual Appliance as well as the software (Linux) version. The steps to set up the PBR are as follows...   Configure gateways.conf for your environment Upload the gateways.conf to Catalogs -> Extra -> Misc Create a new action called "DynamicPBR" in System -> Alerting -> Actions This should be a program action, and execute the dynamic-pbr.sh script Create a new Event called "Dynamic PBR" in System -> Alerting -> Events You want to hook the software started event here   Step 1: Upload the dynamic-pbr.sh script   Navigate to Catalogs -> Extra Files -> Actions Programs and upload the dynamic-pbr.sh script found attached to this article.     Step 2: Configure the gateways.conf for your environment   When the dynamic-pbr.sh script is executed it will attempt to load and process a file called gateways.conf from miscellaneous files. You will need to create that configuration file.   The configuration is a simple text file with a number of fields separated by white space. The first column should be either MAC (to indicate a “Multiple Link” config) or SRC (to indicate “Multiple ISP”).   If you are using the MAC method, then you only need to supply the IP address of each of your gateways and their Layer 2 MAC address. Each MAC line should read “MAC <Gateway IP> <Gateway MAC>”.   If you are using the SRC method, then you should include: local source IP (this can be an individual Traffic IP, or a subnet), the Gateway IP. You should also include information on the local network if you need to be able to access local machines other than the gateway. Do this using two additional/optional columns: Local subnet and device.   Each SRC line should read: “SRC <Local IP> <Gateway IP> <Local subnet> <local device>”     Step 3: upload the gateways.conf   Once you have configured the gateways.conf for your environment, you should upload it to Catalogs -> Extra Files -> Miscellaneous   Step 4: Create Dynamic PBR Action   Now we have the script and configuration file uploaded to vTM, the next steps are to configure the alerting system to execute them at software start up. First we must create a new program action under System -> Alerting -> Manage Actions.   Create a new action called “Dynamic PBR” of type Program. In the edit action screen, you should then be able to select dynamic-pbr.sh from the drop down list.     Step 5: Create Dynamic PBR Event   Now that we have an action, we need to create an event which hooks the “software is running” event. Navigate to System -> Alerting -> Manage Event Types and create a new Event Type called “Dynamic PBR”.   In the event list select the software running event under General, Information Messages.     Step 6: Link the event to the action   Navigate back to the System -> Alerting page and link our new “Dynamic PBR” event type to the “Dynamic PBR” action.     Finished   Now every time the software is started, the configuration from the gateways.conf will be applied.   How do I check the policy?   If you want to check what policy has been applied to the OS, you can do so on the command line. Either open the console or SSH into the vTM machine. The policy is applied by setting up a rule and matching routing table for each of the lines in the gateways.conf configuration file.You can check the routing policy by using the iproute2 utility.   To check the routing rules, run: “ip rule list”.   There are three default rules/tables in Linux: rule 0 looks up the “local” table, rule 32766 looks up “main”, and 32767 looks up “default”. The rules are executed in order. The local rule (0) is maintained by the kernel, so you shouldn’t touch it. The main table (look up rule 32766) and default table (look up rule 32767) tables go last. The main table holds the main routing table of your machine and is the one returned by “netstat –rn”. The default table is usually empty. All other rules in the list are custom, and you should see a rule entry for each of the lines in your gateway configuration file.   So where are the routes? Well the rules are passed in order and the lookup points to a table. You can have upto 255 tables in linux. The “main” table is actually table 255. To see the routes in the table you would use the “ip route list” command. Executing “ip route list table main” and “ip route list table 254” should return the same routing information.   You will note that the rules added by vTM are referenced by their number only. So to look at one of your tables you would use its number. For example “ip route list table 10”. Enjoy!   Updates 20150317: Modified script to parse configuration files which use windows format line endings.
View full article
The Pulse Secure Virtual Traffic Manager includes a useful benchmarking tool named 'zeusbench' that we use for internal performance testing and as a load generation tool for training courses. The first incarnation of ZeusBench was donated to the Apache project a long time ago, and is now well known as ApacheBench. The new incarnation starts from a completely fresh codebase; it has a new 'rate' mode of operation, is less resource intensive and is often more accurate in its reporting.   You’ll find ZeusBench in the admin/bin directory of your Traffic Manager installation ( $ZEUSHOME ). Run zeusbench with the -–help option to display the comprehensive help documentation:   $ $ZEUSHOME/admin/bin/zeusbench --help   Using zeusbench   zeusbench generates HTTP load by sending requests to the desired server. It can run in two different modes:   Concurrency   When run with the –c N option, zeusbench simulates N concurrent HTTP clients. Each client makes a request, reads the response and then repeats, as quickly as possible.   Concurrency mode is very stable and will quickly push a web server to its maximum capacity if sufficient concurrent connections are used. It's very difficult to overpower a web server unless you select far too many concurrent connections, so it's a good way to get stable, repeatable transactions-per-second results. This makes it suitable for experimenting with different performance tunings, or looking at the effect of adding TrafficScript rules.   Rate   When run with the –r N option, zeusbench sends new HTTP requests at the specified rate (requests per second) and reads responses when they are returned.   Rate mode is suitable to test whether a web server can cope with a desired transaction rate, but it is very easy to overwhelm a server with requests. It's great for testing how a service copes with a flash-crowd - try running one zeusbench instance for background traffic, then fire off a second instance to simulate a short flash crowd effect. Rate-based tests are very variable; it's difficult to get repeatable results when the server is overloaded, and it’s difficult to determine the maximum capacity of the server (use a concurrency test for this).   Comparing concurrency and rate   The charts below illustrate two zeusbench tests against the same service; one where the concurrency is varied, and one where the rate is varied:   Measuring transactions-per-second (left hand axis, blue) and response times (right hand axis, red) in concurrency and rate-based tests   The concurrency-based tests apply load in a stable manner, so are effective at measuring the maximum achievable transactions-per-second. However, they can create a backlog of requests at high concurrencies, so the response time will grow accordingly.   The rate-based tests are less prone to creating a backlog of requests so long as the request rate is lower then the maximum transactions-per-second. For lower request rates, they give a good estimate of the best achievable response time, but they quickly overload the service when the request rate nears or exceeds the maximum sustainable transaction rate.   Controlling the tests   The –n N option instructs zeusbench to run until it has sent N requests, then stop and report the results. The –t N option instructs zeusbench to run for N seconds, then stop and report the results. The –f option instructs zeusbench to run forever (or until you hit Ctrl-C, at which point zeusbench stops and reports the results). The –v option instructs zeusbench to report each second on the progress of the tests, including the number of connections started and completed, and the number of timeouts or unexpected error responses.   Keepalives   Keepalives can make a very large difference to the nature of a test. By default, zeusbench will open a TCP connection and use it for one request and response before closing it. If zeusbench is instructed to use keepalives (with the –k flag), it will reuse TCP connections indefinitely; the –k N option can specify the number of times a connection is reused before it is closed.   Other zeusbench options   We’ve just scratched the surface of the options that zeusbench offers. zeusbench gives you great control over timeouts, the HTTP requests that it issues, the ability to ramp up concurrency or rate values over time, the SSL parameters and more.   Run   $ $ZEUSHOME/admin/bin/zeusbench --help   for the detailed help documentation   Running benchmarks   When running a benchmark, it is always wise to sanity-check the results you obtain by comparing several different measurements. For example, you can compare the results reported by zeusbench with the connection counts charted in the Traffic Manager Activity Monitor. Some discrepancies are inevitable, due to differences in per-second counting, or differences in data transfers and network traffic counts.   Benchmarking requires a careful, scientific approach, and you need to understand what load you are generating and what you are measuring before drawing any detailed conclusions. Furthermore, the performance you measure over a low-latency local network may be very different to the performance you can achieve when you put a service online at the edge of a high-latency, lossy WAN.   For more information, check out the document:Tuning Virtual Traffic Manager   The article Dynamic Rate Shaping of Slow Applications gives a worked example of the use of zeusbench to determine how to rate-shape traffic to a slow application.   Also note that many Traffic Manager licenses impose a maximum bandwidth limit (development licenses are typically limited to 1Mbits); this will obviously impede any benchmarking attempts. You can commence a managed evaluation and obtain a license key that gives unrestricted performance if required.
View full article
A selection of SteelApp security articles, for SteelApp Traffic Manager and SteelApp Web App Firewall. Listed from the most recent to the oldest, let me know if you have other articles to add to this list.   Poodle 2.0:   SteelApp not vulnerable to POODLE 2.0 (CVE 2014-8730) CVE-2014-8730   Poodle:   Disabling SSL v3.0 for SteelApp Re: Assuming TLS, what ciphers does SteelApp 9.8 support? CVE-2014-3566   ShellShock/Bash:   TrafficScript rule to protect against "Shellshock" bash vulnerability (CVE-2014-6271) CVE-2014-6271   Heartbleed:   Heartbleed: Using TrafficScript to detect TLS heartbeat records Would Stingray automatically protect servers from Heartbleed? CVE-2014-0160   Whitepapers:   Global-scale Web Application Security for DOD Why Web Application Firewalls Matter   Miscellaneous Articles:   The "Contact Us" attack against mail servers Protecting against Java and PHP floating point bugs Managing DDoS attacks with Stingray Traffic Manager Enhanced anti-DDoS using TrafficScript, Event Handlers and iptables How to stop 'login abuse', using TrafficScript Bind9 Exploit in the Wild... Protecting against the range header denial-of-service in Apache HTTPD Checking IP addresses against a DNS blacklist with Stingray Traffic Manager SteelApp TrafficManager SAML 2.0 Protocol Validation with TrafficScript
View full article
Stingray Traffic Manager version 9.5 includes some important enhancements to the RESTful API.  These enhancements include the following:   A new API version The API version has moved to 2.0.  Versions 1.0 and 1.1 are still available but have been deprecated.   Statistics and Version Information A new resource, "status", is available that contains the child resources "information" and "statistics", under the host name.  Data can only be retrieved for these resources; no updates are allowed.  The URL for "information" is: http(s)://<host>:<port>/api/tm/2.0/status/<host>/information   and the URI for "statistics" is:   http(s)://<host>:<port>/api/tm/2.0/status/<host>/statistics   <host> can also be "local_tm", which is an alias for the Traffic Manager processing the REST request.  For this release, only statistics for the local Traffic Manager are available.   The "information" resource contains the version of the Stingray Traffic Manager, so for example the request:   http(s)://<host>:<port>/api/tm/2.0/status/local_tm/information   for version 9.5 would return:   tm_version9.5   The "statistics" resource contains the Stingray statistics that are also available with SNMP or the SOAP API.  The following child resources are available under "statistics":   actions, bandwidth, cache, cloud_api_credentials, connection_rate_limit, events, glb_services, globals, listen_ips, locations, network_interface, nodes, per_location_service, per_node_slm, pools, rule_authenticators, rules, service_level_monitors, service_protection, ssl_ocsp_stapling, traffic_ips, virtual_servers   The statistics that are available vary by resource.   Example:   To get the statistics for the pool "demo" on the Stingray Traffic Manager "stingray.example.com": https://stingray.example.com:9070/api/tm/2.0/status/local_tm/statistics/pools/demo { "statistics": { "algorithm": "roundrobin", "bytes_in": 20476976, "bytes_out": 53323, "conns_queued": 0, "disabled": 0, "draining": 0, "max_queue_time": 0, "mean_queue_time": 0, "min_queue_time": 0, "nodes": 1, "persistence": "none", "queue_timeouts": 0, "session_migrated": 0, "state": "active", "total_conn": 772 } } Resource Name Changes Some resources have been renamed to be more clear:   actionprogs-> action_programs auth-> user_authenticators authenticators-> rule_authenticators cloudcredentials-> cloud_api_credentials events-> event_types extra-> extra_files flipper-> traffic_ip_groups groups-> user_groups scripts-> monitor_scripts services-> glb_services settings.cfg-> global_settings slm-> service_level_monitors vservers-> virtual_servers zxtms-> traffic_managers   New Resource   One new resource, "custom" has been added to support the new Custom Configuration Sets feature.  This allows arbitrary name:value configuration pairs to be stored in the Traffic Manager configuration system. As part of the Traffic Manager configuration, this data is replicated across a cluster and is accessible using the REST API, SOAP API and ZCLI.  All data structures supported by the Stinray REST API are also supported for Custom Configuration Sets.  Please see the REST API Guide for more information.
View full article
Stingray Traffic Manager operates as a full network proxy.  Incoming TCP and UDP traffic is terminated on the traffic manager, and new TCP or UDP sessions are initiated from the traffic manager to the selected target server.   This approach has the benefit that Stingray can apply a range of TCP optimizations (such as independent window scaling) and higher-level optimizations (HTTP connection reuse), and it's an architectural necessity for any complex content inspection and rewriting (including compression, SSL decryption and all manner of TrafficScript-based solutions).   However, the approach has the side effect that the target servers observe the connection as originating from the Stingray device, not from the remote client.  There are several situations where this may be a problem:   Security and access control measures that need to observe the source IP address of a connection will not work Access logs will identify the Stingray IP address as the source of the connection, and compliance requirements may mandate that the true origin is recorded   There are a number of steps you can take to address problems that arise from this situation.   Offload the task that requires the IP address on to the Stingray device   In many cases, it's possible to move the task that requires access to the IP address from the back-end servers and deploy it on the traffic manager instead:   Access Logging: Stingray provides full webserver-style access logging.  Another advantage of logging transactions on Stingray rather than the webserver cluster is that you don't need to worry about merging log files from multiple servers Security: You can implement a range of IP-based security measures on Stingray, such as Checking IP addresses against a DNS blacklist with Stingray Traffic Manager   Modify the behavior of the Server Application   When Stingray manages an HTTP connection, it adds an X-Cluster-Client-Ip header to the request that identifies the true source address. A web based application that wishes to know the source address of the connection could inspect the value of this header instead.   For example, if you are logging transactions using the common log format in a server such as Apache:   LogFormat "%h %l %u %t \"%r\" %>s %b"   ... you can replace the %h macro with a macro that records the value of the custom header that Stingray inserts:   LogFormat "%{X-Cluster-Client-Ip} %l %u %t \"%r\" %>s %b"   If you are using Apache, you should consider using the mod_remoteip - Apache HTTP Server module (thanks to Julian Midgley for the following).  Enable it as follows:   LoadModule remoteip_module modules/mod_remoteip.so RemoteIPHeader X-Cluster-Client-Ip RemoteIPTrustedProxy 1.2.3.4   ... where 1.2.3.4 is the trusted source of the traffic (i.e. the IP address of the Stingray device).  If you want to trust the header even if it points to a private IP (e.g. 192.168.0.1), then use RemoteIPInternalProxy instead of RemoteIPTrustedProxy.   Note that Apache will continue to log the Stingray IP address when using %h in the log file; replace this with %a to get the client IP address.   If you're using iPlanet, SunONE or a related webserver, you can look at this alternative: Preserving the Client IP address to iPlanet/SunONE/Sun Java System Web Server servers and apps.   Use Stingray's IP Transparency Feature   Stingray's IP Transparency Feature is used to rewrite the source IP address in the server-side connection so that the TCP and UDP traffic appears to originate from the remote client.   It is a very effective solution, but it requires careful network configuration and it incurs an additional workload on the Stingray host because it needs to maintain a large NAT table for the rewritten connections.   On the Stingray Virtual Appliance, the ztrans kernel module that provides IP Transparency is pre-installed; if you are using the Stingray software on a Linux host, you will need to install the Stingray Kernel Modules for Linux Software.  The feature is not available for Solaris.   Once installed, you enable IP Transparency on a per-pool basis:     Please refer to the Stingray Product Documentation for more information.   Read more   HowTo: Spoof Source IP Addresses with IP Transparency Transparent Load Balancing with Stingray Traffic Manager Preserving the Client IP address to iPlanet/SunONE/Sun Java System Web Server servers and apps
View full article
This article describes how TrafficScript manages the memory needed when a rule executes, and how it references connection and global data that is stored outside of a rule's execution environment.  It will help you understand the differences between local variables in TrafficScript, connection-local variables ( connection.data.get/set ), resource data ( resource.get ) and global data ( data.get/set ). Overview TrafficScript is a very lightweight compiled language.  TrafficScript rules are compiled into a Stingray-internal bytecode with about a dozen simple stack-based instructions and are executed on an internal 'virtual machine' (code-named ' ichor ').  All of the 'heavy lifting' (i.e. all of the trafficscript functions) are implemented by internal Stingray procedures (not by the TrafficScript language) so the performance of TrafficScript is driven by native Stingray performance rather than the performance of the virtual machine bytecode. The biggest single determinant of performance in an optimized, lightweight virtual machine like ichor is the use of memory.  Ichor goes to great pains to minimize memory copies by use of references and region-based memory management where possible to reduce the overhead as far as possible. In this article, we'll consider how TrafficScript addresses memory via the String datatype.  Internally, Strings are implemented as references (pointer-and-length) to memory that is often managed outside of the Ichor runtime.  From Ichor's perspective, this memory is read-only; multiple strings can refer to the same memory area and memory is only copied when a new string with new contents is created.  This allows ichor to make assumptions that significantly improve execution speed and memory footprint. A model of memory The diagram below outlines five types of memory that TrafficScript can address. Constants TrafficScript constants (string, integer and double values) are stored with the compiled TrafficScript rule Stored with the compiled TrafficScript rule: String, integer and double values that are declared in a TrafficScript rule are stored with the rule bytecode and referenced directly.  They are deduped, simply to reduce the memory footprint of the compiled TrafficScript rule. Local variables and Temporary values Variables and other temporary values are stored in a temporary memory region that is discarded once the rule has finished executing. Stored for the scope of the rule execution: Local variables and temporary values that are created during the execution of a TrafficScript rule are stored on the execution stack and in the growable heap used by the TrafficScript virtual machine. Because string data uses references rather than private copies, code like the following is very efficient: $body = http.getResponseBody(); if( string.regexMatch( $body, "(.*?)(<body.*?>)(.*)" ) ) {   $head = $1;   $bodytag = $2;   $remainder = $3; } No memory copies are made during the regex search and the assignment of the results to $head , $bodytag and $remainder .  These variables simply contain references to substrings within Stingray's internal copy of the response body. TrafficScript variables and temporaries are only valid for the duration of the rule's execution; persistent data is copied out of the heap as a side-effect of the relevant TrafficScript operations and the heap is safely and quickly discarded in a single operation when the rule execution completes. Per-connection data Data can be stored with a connection using connection.data.set() , and retrieved by a later rule using connection.data.get() .  This is used when sharing state between the rules that process a connection. Stored for the duration of the connection: A connection that is processed by Stingray uses a variety of memory data structures for various data types. HTTP headers and other connection data is stored with the connection.  If a TrafficScript rule requests the value of the path or a header (for example), it is given a reference to the connection-local memory containing the path, so there are no memory copies.  If a TrafficScript rule updates the value of the path (for example, using http.setPath() ), then the connection-local copy is updated so that the value persists when the TrafficScript rule completes. In the example above where the TrafficScript rule used http.getResponseBody() , all of the strings refer to the connection-local copy of the body, and this single copy is used by all TrafficScript rules that need to access it in a read-only fashion. Note: Stingray's HTTP virtual server type abstracts an HTTP transaction from the underlying TCP connection.  Connection-local data is associated with the HTTP transaction and discarded when the transaction completes. connection.data.set(): You can explicitly store data with a connection-scope using the connection.data.set() trafficscript function.  This places a copy of the data in the connection's growable memory pool and this data can be retrieved by a later TrafficScript rule ( connection.data.get() ) or a transaction log macro.  The connection's memory pool is discarded in a single operation once the connection has completed. Per-process data Resource files are stored per-process and can be referenced efficiently using resource.get() and related functions. The most common per-process data that TrafficScript will address is the contents of resource files.  Resource files sit in the extra section of the Stingray configuration.  They are loaded into memory and stored persistently at startup, and whenever they change on disk. resource.get() returns a reference to the body of the already-loaded resource file.  In a similar fashion, resource.getMTime() and resource.getMD5() return the pre-calculated values so there is no disk or compute overhead from invoking these functions. Global data Data can be shared between all rules using the global key-value store.  Access the data using data.get(), data.set() and related functions. On a multi-core machine, Stingray will typically run one zeus.zxtm traffic manager process per core.  These processes share a fixed-size shared memory segment that is allocated at startup. This shared memory segment is used for a number of purposes - sharing session persistence data, bandwidth and rate data, the web content cache, etc.  It includes a key-value store called the Global Data Table that you address using TrafficScript functions such as data.set() and data.get() . The Global Data Table is the key memory resource to use if you want to share data between different connections (the alternative is an external solution accessed using a Java Extension or other external callout, or a client-side cookie).  Keys and values are stored as strings (other types are serialized and deserialized on demand), and the size of the table is fixed (trafficscript!data_size) so you must track and discard entries yourself.  Without locking, iterators or memory management, using the global data table effectively can be a challenge. data.set( $key, $value ) : put a copy of the key/value pair in the global data table, serializing non-string datastructures where necessary data.get( $key ) : return the corresponding value, de-serializing where necessary, or the empty string if $key is not recognised data.remove( $key ) : removes the key/value pair from the table, freeing the memory used by both data.reset( [$prefix] ) : removes every entry, or just entries where the key begins with $prefix, from the table, freeing memory data.getMemoryUsage() and data.getMemoryFree(): indicate memory usage and can be used to detect impending memory exhaustion Read more HowTo: TrafficScript Arrays and Hashes Investigating the performance of TrafficScript - storing tables of data (illustrates efficient use of the global data table)
View full article
This document details the performance figures obtained by the Riverbed® StingrayTM Traffic Manager Virtual Appliance (VA) on VMware vSphere 4.0 and outlines the methods used to achieve these performance figures. A comparison of the performance of various virtual appliance configurations relative to that of the native install of Linux on the same hardware is also provided.
View full article
These results illustrate the performance potential of Stingray Traffic Manager software, based on in-the-lab tests on a range of hardware appliances. (Updated 5th March 2014 by Paul Wallace, to include 2048-bit SSL performance)
View full article
Recently, Cisco announced that they are deprioritizing Cisco ACE — often a prelude to eliminating development on a product line. As a result, many customers want to know what the next step is for their application delivery controller (ADC) strategy. For ACE customers who are shifting to virtual data centers, private clouds, public clouds, and even hybrid clouds, they know an ADC that can easily map to these deployment models is needed. Riverbed® StingrayTM is a family of software and virtual ADCs that provide this capability. While not a one-to- one feature match for Cisco ACE, Stingray provides the right features, and often times more features compared to ACE. This document provides a high-level feature comparison of Riverbed® StingrayTM Traffic Manager software vs. Cisco ACE. You will get enough information to determine if Stingray is right for your environment.
View full article
Stingray Redefines Application Performance for ADCs Focus on website content optimization (WCO) to drive e-commerce revenue, user engagement, and employee productivity The only complete full-featured virtual ADC with integrated WCO, supported on the widest range of virtual and cloud platforms. Stingray Aptimizer is also now available as a stand-alone web content optimization tool to accelerate existing ADC environments FREE Stingray Developer License now makes it even easier for application and security professionals to access capabilities
View full article
This Document provides step by step instructions on how to set up Brocade Virtual Traffic Manager for Microsoft Outlook Web Access.   This document has been updated from the original deployment guides written for Riverbed Stingray and SteelApp software.
View full article
By using Stingray Traffic Manager to load-balance and manage traffic across two or more clustered SharePoint servers, you can achieve dramatic improvements in capacity and reliability. Adding more SharePoint servers to your cluster will scale capacity linearly, and Stingray Traffic Manager’s application acceleration technology – offloading, caching, HTTP optimization – increases the capacity improvements further. When you load-balance traffic across two or more SharePoint servers, you make the entire service resilient to routine downtime (upgrades and reboots) and unexpected errors (such as hardware failures).
View full article
Oracle's PeopleSoft Enterprise applications are designed to address the most complex business requirements. The PeopleSoft Enterprise suite is a comprehensive set of enterprise applications covering a range of business needs. Riverbed® StingrayTM Traffic Manager is able to accelerate web-based PeopleSoft applications, making them faster, more reliable, more secure and easier to manage.
View full article
This Document provides step by step instructions on how to set up Brocade Virtual Traffic Manager for Oracle Application Server 10G.   This document has been updated from the original deployment guides written for Riverbed Stingray and SteelApp software.
View full article
This Document provides step by step instructions on how to set up Brocade Virtual Traffic Manager for Microsoft IIS.   This document has been updated from the original deployment guides written for Riverbed Stingray and SteelApp software.
View full article
This Document provides step by step instructions on how to set up Brocade Virtual Traffic Manager for Microsoft Intelligent Application Gateway.   This document has been updated from the original deployment guides written for Riverbed Stingray and SteelApp software.
View full article
This Document provides step by step instructions on how to set up Brocade Virtual Traffic Manager for Oracle GlassFish Server.   This document has been updated from the original deployment guides written for Riverbed Stingray and SteelApp software.
View full article
Blackboard is a mission-critical application for a Universities e-learning program, and needs to be reliable, secure and provide a high level of performance. As part of the solution, Stingray Traffic Manager can: Improve the reliability of the Blackboard suite Make it easier to manage clusters of application servers Secure the application environment Improve the performance
View full article
This Document provides step by step instructions on how to set up Brocade Virtual Traffic Manager for Microsoft SharePoint 2010.  
View full article
Stingray MSM is an integrated management solution that gives a coordinated view of your application delivery fabric, which may span multiple, geographically distributed, data centers and cloud-based environments. As an advanced feature, MSM makes it easier to manage clusters of StingrayTM Traffic Manager deployments, greatly reducing the complexity of multi-site installations. In addition, the integrated global load balancing (GLB) feature allows you to control where traffic is directed throughout the world, based on factors such as geographic location and data center load.
View full article