cancel
Showing results for 
Search instead for 
Did you mean: 

Pulse Secure vADC

Sort by:
Customers may occasionally need to install additional software on a Virtual Appliance, and this document shows how you can install the software in a way which will be supported. Examples of where this might be useful include:   Installing monitoring agents that customers use to monitor the rest of their infrastructure (e.g. Nagios) Installing other data collection tools (e.g. for Splunk or ELK) Note that for earlier versions of the Traffic Manager Virtual Appliance (before 9.7) we support customers installing software only via our standard APIs/interfaces (using extra files, custom action scripts). This "open access virtual appliance" support policy was introduced at version 9.7, to allow installation of additional software. However, we still do not support customers modifying the tested software shipped with the appliance.   Operating system   Traffic Manager virtual appliances use a customized build of Ubuntu, with an optimized kernel from which some unused features have been removed - check the latest release notes for details of the build included in your version.   What you may change   You may install additional software not shipped with the appliance, but note that some Ubuntu packages may rely on kernel features not available on the appliance.   You may modify configuration not managed by the appliance.   What you may not change   You may not install a different kernel.   You may not install different versions of any debian packages that were installed on the appliance as shipped, nor remove any of these packages (see the licence acknowledgements doc for a list).   You may not directly modify configuration that is managed from the traffic manager (e.g. sysctl values, network configuration).   You may not change configuration explicitly set by the appliance (usually marked with a comment containing ZOLD or  BEGIN_STINGRAY_BLOCK).   What happens when you need support   You should mention any additional software you have installed when requesting support, the Technical Support Report will also contain information about it. If the issue is found to be caused by interaction with the additional software we will ask you to remove it, or to seek advice or a remedy from its supplier.   What happens on reset or upgrade   z-reset-to-factory-defaults will not remove additional software but may rewrite some system configuration files.   An upgrade will install a fresh appliance image on a separate disk partition, and will not copy additional software or configuration changes across. The /logs partition will be preserved.   Note that future appliance versions may change the set of installed packages, or even the underlying operating system.
View full article
TrafficScript is a simple, command-based language. A command is called a 'statement', and each statement is terminated with a ';'. Comments begin with a '#' symbol, and finish at the end of the line:   # Store the value '2' in the variable named $a $a = 2; # call the 'connection.close' function connection.close();   Variables are indicated by the '$' symbol. There is no typing in TrafficScript, and you do not need to pre-declare a variable before you use it. Variables are not persistent - they go out of scope when a rule completes.   You can use variables in expressions to calculate new values (numbers and strings). Common mathematical, comparison and boolean operators are available, and '.' is used to concatenate strings.   # Set the value of $a to 1.75 $a = 1 + 1/2 + 0.25; # create a new string with the '.' operator $fullname = $firstname . " " . $lastname;   Functions are called using the normal bracket-and-argument-list syntax, and many functions can take different numbers of arguments. Function names often contain two or three parts, separated by '.'; this conveniently groups functions into different families.   $path = http.getPath(); $cookie = http.getCookie( "ASPSESSIONID" ); $browser = http.getHeader( "User-Agent" );   TrafficScript also provides data structures in the form of arrays and hashes. Arrays and hashes allow you to store multiple values in one TrafficScript structure. For more information, see the HowTo: TrafficScript Arrays and Hashes article.   Read more   Collected Tech Tips: TrafficScript examples
View full article
Array types in TrafficScript   Arrays store a collection of values indexed by an integer value - essentially they are a numbered list of TrafficScript variables:   $chickens = [ "nugget", "emily", "henrietta", "chelsea" ];   Array indexes start at 0, representing the first item in the list, and extend up to the size of the array - so the last index will be the number of items in the array, less one. Arrays can store any value in any index, including other arrays.   Arrays can be created by specifying a list of values separated by commas and surrounded by [ ] characters. Alternatively you can create an array of a specific size that is filled with a default value by using the array.create() function:   $array = [ 1, 2, 3 ]; # An array of size 3, containing the numbers 1, 2 and 3 $array = array.create( 10, "foo" ); # An array of size 10, each element is the string "foo"   To look up a value in an array, specify the array variable that contains the value you want to look up, followed by the index of the value enclosed in [ ] characters:   $array = [ 1, 2, 3 ]; $value = $array[0]; # $value will be set to 1 (indexes start at 0)   Similarly, to insert a value into an existing array, specify the array and the index into which you want to insert the value, followed by an '=' and the value you want to insert:   $array = [ 1, 2, 3 ]; $array[1] = "hello"; # the number 2 will be replaced by the string "hello"   You cannot insert into an index that does not exist - if you do, a warning will be printed in the Event Log and the array will remain unchanged:   $array = [ 1, 2, 3 ]; $array[3] = "Goodbye"; # This will print a warning and the array will be unchanged   Arrays can be expanded by adding new values to the end using the array.push() function, and they can also be shrunk by removing values from the end with the array.pop() function:   $array = [ 1, 2, 3 ]; array.push( $array, "Goodbye" ); $value = $array[3]; # $value will be set to "Goodbye" $value2 = array.pop( $array ); # $value2 will also be set to "Goodbye" $array[3] = "Au revoir"; # This will print a warning because 'pop' # shrunk the array back to 3 values   Hashes in TrafficScript   Hashes are very similar to arrays, however they are indexed by a string value rather than an integer value. Unlike arrays, you do not have to ensure that a particular index already exists before looking it up or before inserting a value into it.   Hashes are created by listing pairs of 'keys' (the string index of a value) and their values, separated by =>:   # Create a new hash $hash = [ "name" => "Andy", "occupation" => "Engineer", "height" => 5.11 ];   To look up a value in a hash, you specify the key that indexes the value you want after the hash variable, enclosed in [ ] characters:   $height = $hash["height"]; # $height will now be 5.11   You can add any key/value pair to the hash at any time, it does not need to exist in the hash before you add it:   # You can add a new key/value pair at any time $hash["drink"] = "Tea";   Arrays and hashes can contain any TrafficScript data type, including other arrays and hashes. You can index into multiple levels of arrays and hashes by adding additional indexes to the lookup:   # You can add the hash to another hash! $employees["andy"] = $hash; # You can then perform multiple lookups to get the values you want $occupation_andy = $employees["andy"]["occupation"];   To remove a value from the hash you can use the hash.delete() function:   hash.delete( $hash, "height" ); # the height/5.11 pair will now # be removed from the hash   Enumeration   The foreach loop is the easiest way to iterate over an array or hash and perform some actions with each value it contains:   foreach( $var in $array ) { ... # $var will be set to each element of $array in turn }   For example, the http.listHeaderNames() function returns an array containing the name of each header supplied by an HTTP request. If you want to log all the headers in a request then the foreach loop comes in very handy:   # Log all of the header names and values $headers = http.listHeaderNames(); foreach( $header in $headers ) { log.info($header . "=" . http.getHeader($header)); }   If you want to show the headers in alphabetical order, you can apply the array.sort() function to the array in the foreach loop:   foreach( $header in array.sort( $headers ) ) { ... }   Iterating over the values of a hash can be done in a similar way when using the hash.keys() function. This function returns an array containing all the keys in the hash with which there are associated values. You can then use the foreach loop to iterate over these keys and look them up in the hash.   You can therefore use the new http.getHeaders() function as an alternative way to print out all the headers in an HTTP request. The function returns a hash mapping all the header names in the request to their values. To print them all you could write:   $headers = http.getHeaders(); foreach( $header in hash.keys( $headers ) ) { log.info( $header . "=" . $headers[$header] ); }   The output will be the same as that from the previous http.listHeaderNames() example, except that the order in which the headers are printed might differ. The order of the keys returned by hash.keys() is not guaranteed.   Read more   Collected Tech Tips: TrafficScript examples
View full article
The AWS Marketplace provides a "launch with 1-click" button to simplify deployment of the Pulse Secure Virtual Traffic Manager in EC2.   If you accept the Marketplace defaults a new security group is created for you automatically. The security group is fine for single instances of vTM, but attempts to cluster traffic managers associated with this security group will fail.   Prior to clustering traffic managers, modify your security group to open ports 9080 and 9090 for UDP traffic. For more information read the Before You Begin section in the Cloud Services Installation and Getting Started Guide - see vADC Product Documentation
View full article
When managing the Traffic Manager Virtual Appliance you might need to free some space to perform certain tasks. This is usually most visible when performing upgrades where you might be presented with the following message: Analyzing system: failed  ERROR: Not enough space available, need 300000KB, however only xxxxxxKB is available   You can perform the following steps:   If you've previously uploaded a zeus upgrade package (.zpkg file) for a major upgrade, this can now be safely removed. Remove unnecessary files left over from a previous upgrade: (remove /opt/zeus/.upgrade and /opt/zeus.extract.* ) Remove any cached charts from the activity graphs: /opt/zeus/zxtmadmin/docroot/cache/ * If you've uploaded anything to /root that isn't needed any more, delete those files. Remove old versions of the traffic manager software as described below. Back up some old log files and remove them from /logs. Remove any temporary files from the /logs partition: /logs/.tmp/* Extend the logs partition as described in the Product Documentation - Virtual Appliance Getting Started Guide   Generally, the /logs partition has more free space than the /root partition.  You should move the upgrade package (.zpkg) and other temporary files to that partition rather than root.   If all else fails, you can generate a disk space report that lists the largest folders and files on each partition as follows:   # du -ax / | sort -rn | head -50 # du -ax /logs | sort -rn | head -50   Provide this information to Riverbed Technical Support.   Removing Previous Software Versions   When you upgrade the Virtual Appliance, the previous version of the software is retained so that you can revert back to it at any point in time. If you upgrade through a series of minor revisions you might have several older versions of the software still installed. In practice, it is unlikely that you need to retain all of these; having a single version that is known to be good should suffice.   Use the following command to list the software versions that are installed in the currently running partition:   # /opt/zeus/zxtm/bin/rollback --delete   You can safely delete old software versions using this interactive command if you are certain that you will not need to roll-back to them at some point in the future.   Web Application Firewall   In a manner similar to the Traffic Manager itself, the previous versions of the Web Application Firewall are retained following an upgrade. As with the Traffic Manager you can remove these old software versions to free disk space if you are certain that you will no longer need to roll-back to them.   Version 4.5 or later of the Web Application Firewall provides an interface to manage installed versions, the interface can be accessed via the Traffic Manager administration interface.   Application Firewall > Administration > Cluster Management > Updater > Open Update Center   After logging into the Update Center, use the "Undeploy" action to remove any inactive versions you no longer require.
View full article
In many cases, it is desirable to upgrade a virtual appliance by deploying a virtual appliance at the newer version and importing the old configuration.  For example, the size of the Traffic Manager disk image was increased in version 9.7, and deploying a new virtual appliance lets a customer take advantage of this larger disk.  This article documents the procedure for deploying a new virtual appliance with the old configuration in common scenarios.   These instructions describe how to upgrade and reinstall Traffic Manager appliance instances (either in a cluster or standalone appliances). For instructions on upgrading on other platforms, please refer to Upgrading Traffic Manager.   Upgrading a standalone Virtual Appliance   This process will replace a standalone virtual appliance with another virtual appliance with the same configuration (including migrating network configuration). Note that the Traffic Manager Cloud Getting Started Guide contains instructions for upgrading a standalone EC2 instance from version 9.7 onwards; if upgrading from a version prior to 9.7 and using the Web Application Firewall these instructions must be followed to correctly back up and restore any firewall configuration.   Make a backup of the traffic manager configuration (See section "System > Backups" in the Traffic Manager User Manual), and export it. If you are upgrading from a  version prior to 9.7 and are using the Web Application Firewall, back up the Web Application Firewall configuration - Log on to a command line - Run /opt/zeus/stop-zeus - Copy /opt/zeus/zeusafm/current/var/lib/config.db off the appliance. Shut down the original appliance. Deploy a new appliance with the same network interfaces as the original. If you backed up the application firewall configuration earlier, restore it here onto the new appliance, before you restore the traffic manager configuration: - Copy the config.db file to /opt/zeus/stingrayafm/current/var/lib/config.db    (overwriting the original) - Check that the owner on the config.db file is root, and the mode is 0644. Import and restore the traffic manager configuration via the UI. If you have application firewall errors Use the Diagnose page to automatically fix any configuration errors Reset the Traffic Manager software.   Upgrading a cluster of Virtual Appliances (except Amazon EC2)   This process will replace the appliances in the cluster, one at a time, maintaining the same IP addresses. As the cluster will be reduced by one at points in the upgrade process, you should ensure that this is carried out at a time when the cluster is otherwise healthy, and of the n appliances in the cluster, the load can be handled by (n-1) appliances.   Before beginning the process, ensure that any cluster errors have been resolved. Nominate the appliance which will be the last to be upgraded (call it the final appliance).  When any of the other machines needs to be removed from the cluster, it should be done using the UI on this appliance, and when a hostname and port are required to join the cluster, this appliance's hostname should be used. If you are using the Web Application Firewall first ensure that vWAF on the final appliance in the cluster is upgraded to the most recent version, using the vWAF updater. Choose an appliance to be upgraded, and remove the machine from the cluster: - If it is not the final appliance (nominated in step 2),    this should be done via the UI on the final appliance - If it is the final appliance, the UI on any other machine may be used. Make a backup of the traffic manager configuration (System > Backups) on the appliance being upgraded, and export the backup.  This backup only contains the machine specific info for that appliance (networking config etc). Shut down the appliance, and deploy a new appliance at the new version.  When deploying, it needs to be given the identical hostname to the machine it's replacing. Log on to the admin UI of the new appliance, and import and restore the backup from step 5. If you are using the Web Application Firewall, accessing the Application Firewall tab in the UI will fail and there will be an error on the Diagnose page and an 'Update Configuration' button. Click the Update Configuration button once, then wait for the error to clear.  The configuration is now correct, but the admin server still needs to be restarted to pick up the configuration: # $ZEUSHOME/admin/rc restart Now, upgrade the application firewall on the new appliance to the latest version. Join into the cluster: For all appliances except the final appliance, you must not select any of the auto-detected existing clusters.  Instead manually specify the hostname and port of the final appliance. If you are using Web Application Firewall, there may be an issue where the config on the new machine hasn't synced the vWAF config from the old machine, and clicking the 'Update Application Firewall Cluster Status' button on the Diagnose page doesn't fix the problem. If this happens, firstly get the clusterPwd from the final appliance: # grep clusterPwd /opt/zeus/zxtm/conf/zeusafm.conf clusterPwd = <your cluster pwd> On the new appliance, edit /opt/zeus/zxtm/conf/zeusafm.conf (with e.g. nano or vi), and replace the clusterPwd with the final appliance's clusterPwd. The moment that file is saved, vWAF should get restarted, and the config should get synced to the new machine correctly. When you are upgrading the final appliance, you should select the auto-detected existing cluster entry, which should now list all the other cluster peers. Once a cluster contains multiple versions, configuration changes must not be made until the upgrade has been completed, and 'Cluster conflict' errors are expected until the end of the process. Repeat steps 4-9 until all appliances have been upgraded.   Upgrading a cluster of STM EC2 appliances   Because EC2 licenses are not tied to the IP address, it is recommended that new EC2 instances are deployed into a cluster before removing old instances.  This ensures that the capacity of the cluster is not reduced during the upgrade process.  This process is documented in the "Creating a Traffic Manager Instances on Amazon EC2" chapter in the Traffic Manager Cloud Getting Started Guide.  The clusterPwd may also need to be fixed as above.
View full article
These instructions describe how to upgrade Traffic Manager AMIs on Amazon EC2. For instructions on upgrading on other platforms, please refer to Upgrading Traffic Manager.   Upgrade strategy   Unlike physical machines or regular virtual appliances which tend to be very long-lived, EC2 instances are intended to be transient. If an EC2 instance develops a fault, it is easier to terminate it and replace it with a new one than to try to repair it.   Upgrades can be handled in a similar way: instead of upgrading a running instance when a new version of the software is released, it is easier to start an instance of the newer software, migrate the configuration over from the old one, and then terminate the old instance. Using clustering and fault tolerant Traffic IP addresses it is possible to upgrade a cluster in place, replacing each traffic manager with one running a newer version of the software, while continuing to serve application traffic.   Upgrade howto Important: When the cluster is in a mixed state (i.e. the Traffic Managers are using different software versions) do not make any configuration changes. This should remain the case until all traffic manager instances in the cluster are running the upgraded version.   For each Traffic Manager in your cluster, perform the following steps:   Start an instance of the new AMI. Using the Admin Server, or the user-data pre-configuration parameters, join the new instance to your cluster. If using user-data pre-configuration, you can set the new instance to join the Traffic IP Groups by setting  join_tips=y but do not use this option if there are multiple Traffic IP groups configured in the cluster. Also for Amazon VPC instances, it will be ignored if the instance doesn't have a secondary IP address assigned whilst launching. Note that per-node hostname mappings (configured the in System > Networking page) will not be migrated automatically - you must set these manually on each new instance.   3. Terminate one of the old instances in your cluster.   Repeat these steps until all the traffic managers in your cluster have been replaced. Replace instances one by one - do not terminate an old instance until its replacement has successfully joined the cluster.   Upgrading to new product functionality   The instructions described in the previous section can also be used to change the product version you are running. For example, you can use this method to upgrade from one Traffic Manager to another that offers a higher bandwidth capacity or more functionality.  You can also use this method to upgrade from one Amazon instance size to another.   Note that you cannot use this method to downgrade the product you are currently running to one with fewer features, because your current configuration will not be applicable to a lower-featured instance. In this case, you must create a new cluster of simpler Traffic Manager instances and migrate the relevant configuration from the old cluster manually.
View full article
These instructions describe how to upgrade Traffic Manager Virtual Appliance instances. For instructions on upgrading on other platforms, please refer to Upgrading Traffic Manager.   Before you start   There are a few things that have to be checked before an upgrade is attempted to make sure it goes smoothly:   Memory requirements: Make sure the machine has enough memory. Traffic Manager requires at the very least 1GB of RAM; 2GB or more are recommended. If the traffic manager to be upgraded has less memory, please assign more memory to the virtual machine. Disk Space requirements: Ensure there is enough free disk space. For the upgrade to succeed, at least 500Mb must be free on the root partition, and at least 300MB on the /logs partition. The unix command df shows how much space is available, for example:   root@stingray-1/ # df -k Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda5 1426384 839732 514764 62% / varrun    517680      44 517636 1% /var/run varlock   517680       0 517680 0% /var/lock udev      517680      48 517632 1% /dev devshm    517680       0 517680 0% /dev/shm /dev/sda1 139985    8633 124125 7% /boot /dev/sda8 621536   17516 604020 3% /logs   If the disks are too full, you have to free up some space. Please follow the suggestions in the topic Freeing disk space on the Virtual Appliance.   Upgrading the Virtual Appliance   Traffic Manager software is stored on one of two primary partitions, and log files are stored on a separate disk partition.   Full Upgrades are required when you upgrade to a new major or minor version number, such as from 18.2 to 19.1, or 19.1 to 19.2.  Full upgrades include a new operating system installation. A full upgrade is installed in the unused primary partition, configuration (including the /root directory) is migrated across and the bootloader updated to point to the new partition. You can edit the bootloader configuration to fall back to the other primary partition if you need to roll back to the previous instance. Incremental Upgrades are required when you install a release with a new revision number, such as from 9.1 to 9.1r1.  The new software is added to the currently active primary partition. You can use the 'rollback' script to make a previous revision active.   Important note   If you wish to upgrade from one major.minor version to a later major.minor version with a later revision, you will need to upgrade in two steps: the full upgrade, and the subsequent incremental upgrade.   For example, suppose that you are running version 17.3r2 and you wish to upgrade to version 18.2r1.  You must perform the following two steps:   Perform a full upgrade from your current version to the closest major.minor version, i.e a full upgrade to 18.2 Perform a subsequent incremental upgrade from 18.2 to 18.2r1.   Performing a Full Upgrade   Upgrades between major and minor versions (e.g. 18.2 to 19.1 or 19.1 to 19.2) can either be performed via Administration Server (when upgrading from version 9.0 or later) or using a command-line script ( z-upgrade-appliance ) to install the new version into a spare section of the hard disk. This process involves one reboot and the downtime associated with that reboot.   Any configuration changes made in the existing version after the upgrade has been run won't be preserved when the new version is started; you should reboot the appliance as soon as possible (using the System -> Reboot button in the UI or using the 'reboot' command).   Before upgrading it is prudent to have a backup of your configuration.   Command line method Download the installation zpkg package from. This will be a file called something like ZeusTM_91_Appliance-x86_64.zpkg . Copy the file onto the appliance to the /logs partition using an scp or sftp client (e.g. psftp ). Log in to the appliance using an 'ssh' client (putty is a good choice) or the console; you can log in using any username that is in the admin group. Check the disk space requirements explained above are still fulfilled after you've uploaded the package. Once connected to the console of the appliance run: z-upgrade-appliance <filename> Confirm that you want to upgrade the appliance.   Administration Server (upgrading from 9.0 or later) Download the tgz upgrade package from the download site, go to the System -> Upgrade page, upload the upgrade tgz package, and follow the instructions.   Once complete, the current configuration will be migrated to the newly installed version, and this version will be automatically selected on the next reboot.   Performing an Incremental Upgrade   Upgrading revisions in the same product version (e.g. 18.2 to 18.2r2) are performed using the Administration Server. Download the tgz upgrade package from the download site, go to the System -> Upgrade page, upload the upgrade tgz package, and follow the instructions.   You will need to complete this process for each Appliance in your cluster.   Expected downtime for an upgrade will be a couple of seconds while the Traffic Manager software is restarted. On very rare occasions, it will be necessary to reboot the Appliance to complete the upgrade. The user interface will inform you if this is necessary when the upgrade is complete. You should ensure that the Appliance is rebooted at the most appropriate time.
View full article
These instructions describe how to upgrade Traffic Manager Software instances. For instructions on upgrading on other platforms, please refer to Upgrading Traffic Manager.   You can upgrade a running copy of the Traffic Manager software with very little downtime. There are two ways to perform the upgrade: using the Administration Interface, or using the command line.   The upgrade procedure:   Installs the new software into a different, version-controlled directory; Copies the configuration from the running version of the software; Stops the running software, swaps some symlinks and then starts the new software.   The downtime is rarely more than one or two seconds. If necessary, you can then install a new license key file using the Traffic Manager Admin Server, for example, to enable new product features.   Upgrading via the Administration Interface   Obtain the new installation package ( ZeusTM_ProductVersion_OS.tgz ); Navigate to the System > Traffic Managers page on the Admin Interface of the Traffic Manager you intend to upgrade; Click the Upgrade button and upload the new installation package; Follow the instructions to apply the software upgrade.   Upgrading via the command line   Unpack your new software distribution file ( ZeusTM_ProductVersion_OS.tgz ) on the server. Become root (assuming your existing installation is as root), and move into the directory that has just been created by extracting the distribution file. Run the ./zinstall command   The upgrade program automatically stops your existing version of Traffic Manager, upgrades it, and restarts it, keeping all your existing configuration. Upgrading a Cluster   If you have a cluster of Traffic Managers, you can upgrade each one in turn. Do not make any configuration changes until you have upgraded the entire cluster to the same software version.   To roll back to a previous software version   You can use the ' rollback ' script to revert back to a previously installed version of Traffic Manager software, or to roll forward to a later version that you installed previously:   Become 'root' and run the ZEUSHOME/zxtm/bin/rollback .   You will then be shown a list of the different software versions that you have installed, and asked to chose which one you would like to roll back or forwards to.  When you roll back (or forwards) to a different version, the software will use the configuration that was last active with that version. For example, If you upgraded from version X.1 to version X.2 two weeks ago, then roll back to version X.1, it will use the configuration that version X.1 last used two weeks ago.
View full article
This article explains how to use Traffic Manager's REST Control API using the excellent requests Python library.   There are many ways to install the requests library.  On my test client (MacOSX), the following was sufficient:   $ sudo easy_install pip $ sudo pip install requests   Resources   The REST API gives you access to the Traffic Manager Configuration, presented in the form of resources.  The format of the data exchanged using the RESTful API will depend on the type of resource being accessed:   Data for Configuration Resources, such as Virtual Servers and Pools are exchanged in JSON format using the MIME type of “application/json”, so when getting data on a resource with a GET request the data will be returned in JSON format and must be deserialized or decoded into a Python data structure.  When adding or changing a resource with a PUT request the data must be serialized or encoded from a Phython data structure into JSON format. Files, such as rules and those in the extra directory are exchanged in raw format using the MIME type of “application/octet-stream”.   Working with JSON and Python   The json module provides functions for JSON serializing and deserializing.  To take a Python data structure and serialize it into JSON format use json.dumps() and to deserialize a JSON formatted string into a Python data structure use json.loads() .   Working with a RESTful API and Python   To make the programming easier, the program examples that follow utilize the requests library as the REST client. To use the requests library you first setup a requests session as follows, replacing <userid> and <password> with the appropriate values:   client = requests.Session() client.auth = ('<userid>', '<password>') client.verify = False   The last line prevents it from verifying that the certificate used by Traffic Manager is from a certificate authority so that the self-signed certificate used by Traffic Manager will be allowed.  Once the session is setup, you can make GET, PUT and DELETE calls as follows:   response = client.get() response = client.put(, data = , headers = ) response = client.delete()   The URL for the RESTful API will be of the form:   https:// <STM hostname or IP>:9070/api/tm/1.0/config/active/   followed by a resource type or a resource type and resource, so for example to get a list of all the pools from the Traffic Manager instance, stingray.example.com, it would be:   https://stingray.example.com:9070/api/tm/1.0/config/active/pools   And to get the configuration information for the pool, “testpool” the URL would be:   https://stingray.example.com:9070/api/tm/1.0/config/active/pools/testpool   For most Python environments, it will probably be necessary to install the requests library.  For some Python environments it may also be necessary to install the httplib2 module.   Data Structures   JSON responses from a GET or PUT are deserialized into a Python dictionary that always contains one element.   The key to this element will be:   'children' for lists of resources.  The value will be a Python list with each element in the list being a dictionary with the key, 'name', set to the name of the resource and the key, 'href', set to the URI of the resource. 'properties' for configuration resources.  The value will be a dictionary with each key value pair being a section of properties with the key being set to the name of the section and the value being a dictionary containing the configuration values as key/value pairs.  Configuration values can be scalars, lists or dictionaries.   Please see Feature Brief: Traffic Manager's RESTful Control API for examples of these data structures and something like the Chrome REST Console can be used to see what the actual data looks like.   Read More   The REST API Guide in the Product Documentation Feature Brief: Traffic Manager's RESTful Control API Collected Tech Tips: Using the RESTful Control API
View full article
Looking for Installation and User Guides for Pulse vADC? User documentation is no longer included in the software download package with Pulse vTM, so the documentation can now be found on the Pulse Techpubs pages  
View full article
Traffic Manager logs activity (hits per minute and data transferred) for Virtual Servers, Pools and Nodes. You can view the logged data on the Activity -> Historical Activity page in the Admin interface. However, sometimes it is usefule to extract these graphs and archive them. The Admin server doesn't provide a facility to this, so this article presents a simple perl script that generates these graphs.   Using the Script Download the script attached to this article and copy it on to one of your Traffic Managers (it must be run from a Traffic Manager host or virtual appliance).  Ensure that the script is executable.   Running it with no arguments will produce the help output:   Usage: ./getHistoricalActivity.pl --output=image.png [OPTIONS] Generates a graph of historical activity. If given no arguments, will default to graphing all virtual servers for 24 hours Required arguments: --output=FILE File to output image to ('-' for stdout) Optional arguments: --time=HOURS Number of hours to graph (default 24) --width=WIDTH Width of output graph (default 640) --height=HEIGHT Height of output graph (default 480) --allvs Graph all Virtual Servers (default) --allpools Graph all pools --allnodes Graph all nodes --vs=VS1,VS2 Graph a subset of virtual servers --pool=POOL1,POOL2 Graph a subset of pools --node=NODE1,NODE2 Graph a subset of nodes --linear Graph using a linear axis (default) --logarithmic Graph using a logarithmic axis --hits Graph hits per minute (default) --bytes Graph bytes per second --help Show this help message   Running it just the --output argument will generate an image like the following: The line colours and the virtual server names are output to STDOUT: # ./foo.pl --output=foo.png Line colours: 00cfff: apache ffe626: Zeus AFM Integration 9a41d8: Web Site 00d840: SSL Passthrough ff4ca8: soundex
View full article
Top examples of Pulse vADC in action   Examples of how SteelApp can be deployed to address a range of application delivery challenges.   Modifying Content   Simple web page changes - updating a copyright date Adding meta-tags to a website with Traffic Manager Tracking user activity with Google Analytics and Google Analytics revisited Embedding RSS data into web content using Traffic Manager Add a Countdown Timer Using TrafficScript to add a Twitter feed to your web site Embedded Twitter Timeline Embedded Google Maps Watermarking PDF documents with Traffic Manager and Java Extensions Watermarking Images with Traffic Manager and Java Extensions Watermarking web content with Pulse vADC and TrafficScript   Prioritizing Traffic   Evaluating and Prioritizing Traffic with Traffic Manager HowTo: Control Bandwidth Management Detecting and Managing Abusive Referers Using Pulse vADC to Catch Spiders Dynamic rate shaping slow applications Stop hot-linking and bandwidth theft! Slowing down busy users - driving the REST API from TrafficScript   Performance Optimization   Cache your website - just for one second? HowTo: Monitor the response time of slow services HowTo: Use low-bandwidth content during periods of high load   Fixing Application Problems   No more 404 Not Found...? Hiding Application Errors Sending custom error pages   Compliance Problems   Satisfying EU cookie regulations using The cookiesDirective.js and TrafficScript   Security problems   The "Contact Us" attack against mail servers Protecting against Java and PHP floating point bugs Managing DDoS attacks with 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 Traffic Manager Heartbleed: Using TrafficScript to detect TLS heartbeat records TrafficScript rule to protect against "Shellshock" bash vulnerability (CVE-2014-6271) SAML 2.0 Protocol Validation with TrafficScript Disabling SSL v3.0 for SteelApp   Infrastructure   Transparent Load Balancing with Traffic Manager HowTo: Launch a website at 5am Using Stingray Traffic Manager as a Forward Proxy Tunnelling multiple protocols through the same port AutoScaling Docker applications with Traffic Manager Elastic Application Delivery - Demo How to deploy Traffic Manager Cluster in AWS VPC   Other solutions   Building a load-balancing MySQL proxy with TrafficScript Serving Web Content from Traffic Manager using Python and Serving Web Content from Traffic Manager using Java Virtual Hosting FTP services Managing WebSockets traffic with Traffic Manager TrafficScript can Tweet Too Instrument web content with Traffic Manager Antivirus Protection for Web Applications Generating Mandelbrot sets using TrafficScript Content Optimization across Equatorial Boundaries
View full article
With the evolution of social media as a tool for marketing and current events, we commonly see the Twitter feed updated long before the website. It’s not surprising for people to rely on these outlets for information.   Fortunately Twitter provides a suite of widgets and scripting tools to integrate Twitter information for your application. The tools available can be implemented with little code changes and support many applications. Unfortunately the same reason a website is not as fresh as social media is because of the code changes required. The code could be owned by different people in the organization or you may have limited access to the code due to security or CMS environment. Traffic Manager provides the ability to insert the required code into your site with no changes to the application.      Twitter Overview "Embeddable timelines make it easy to syndicate any public Twitter timeline to your website with one line of code. Create an embedded timeline from your widgets settings page on twitter.com, or choose “Embed this…” from the options menu on profile, search and collection pages.   Just like timelines on twitter.com, embeddable timelines are interactive and enable your visitors to reply, Retweet, and favorite Tweets directly from your pages. Users can expand Tweets to see Cards inline, as well as Retweet and favorite counts. An integrated Tweet box encourages users to respond or start new conversations, and the option to auto-expand media brings photos front and center.   These new timeline tools are built specifically for the web, mobile web, and touch devices. They load fast, scale with your traffic, and update in real-time." -twitter.com   Thank you Faisal Memon for the original article Using TrafficScript to add a Twitter feed to your web site   As happens more often than than not, platform access changes. This time twitter is our prime example. When loading Twitter js, http://widgets.twimg.com/j/2/widget.js you can see the following notice:   The Twitter API v1.0 is deprecated, and this widget has ceased functioning.","You can replace it with a new, upgraded widget from <https://twitter.com/settings/widgets/new/"+H+">","For more information on alternative Twitter tools, see <https://dev.twitter.com/docs/twitter-for-websites>   To save you some time, Twitter really means deprecated and the information link is broken. For more information on alternative Twitter tools the Twitter for Websites | Home. For information related to the information in this article, please see Embedded Timelines | Home   One of the biggest changes in the current twitter platform is the requirement for a "data-widget-id". The data-widget-id is unique, and is used by the twitter platform to provide information to generate the data. Before getting started with the Traffic Manager and Web application you will have to create a new widget using your twitter account https://twitter.com/settings/widgets/new/. Once you create your widget, will see the "Copy and paste the code into the HTML of your site." section on the twitter website. Along with other information, this code contains your "data-widget-id". See Create widget image.   Create widget (click to zoom)   This example uses a Traffic Script response rule to rewrite the HTTP body from the application. Specifically I know the body for my application includes a html comment   <!--SIDEBAR-->.    This rule will insert the required client side code into the HTTP body and send the updated body in to complete the request.  The $inserttag variable can be just about anything in the body itself  i.e. the "MORE LIKE THIS" text on the side of this page. Simply change the code below to:     $inserttag = "MORE LIKE THIS";   Some of the values used in the example (i.e. width, data-theme, data-link-color, data-tweet-limit) are not required. They have been included to demonstrate customization. When you create/save the widget on the twitter website, the configuration options (See the Create widget image above) are associated with the "data-widget-id". For example "data-theme", if you saved the widget with light and you want the light theme, it can be excluded. Alternatively if you saved the widget with light, you can use "data-theme=dark" and over ride the value saved with the widget.  In the example time line picture the data-link-color value is used to over ride the value provided with the saved "data-widget-id".   Example Response Rule, *line spaced for splash readability and use of variables for easy customization. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 # Only modify text/html pages    if ( !string.startsWith( http.getResponseHeader( "Content-Type" ), "text/html" )) break;         $inserttag = "<!--SIDEBAR-->" ;       # create a widget ID @ https://twitter.com/settings/widgets/new  #This is the id used by riverbed.com   $ttimelinedataid = "261517019072040960" ;  $ttimelinewidth = "520" ; # max could be limited by ID config.  $ttimelineheight = "420" ;  $ttimelinelinkcolor = "#0080ff" ; #0 for default or ID config, #0080ff & #0099cc are nice  $ttimelinetheme = "dark" ; #"light" or "dark"  $ttimelinelimit = "0" ; #0 = unlimited with scroll. >=1 will ignore height.  #See https://dev.twitter.com/web/embedded-timelines#customization for other options.       $ttimelinehtml = "<a class=\"twitter-timeline\" " .                   "width=\"" . $ttimelinewidth . "" .                     "\" height=\"" . $ttimelineheight . "" .                     "\" data-theme=\"" . $ttimelinetheme . "" .                   "\" data-link-color=\"" . $ttimelinelinkcolor . "" .                   "\" data-tweet-limit=\"" . $ttimelinelimit . "" .                   "\" data-widget-id=\"" . $ttimelinedataid . "" .                    "\"></a><script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)" .                     "[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id))" .                     "{js=d.createElement(s);js.id=id;js.src=p+" .                   "\"://platform.twitter.com/widgets.js\";fjs.parentNode.insertBefore(js," .                   "fjs);}}(document,\"script\",\"twitter-wjs\");" .                     "</script><br>" . $inserttag . "" ;         $body = http.getResponseBody();    $body = string.replace( $body , $inserttag , $ttimelinehtml );  http.setResponseBody( $body );    A short version of the rule above, still with line breaks for readability.   1 2 3 4 5 6 7 8 9 if ( !string.startsWith( http.getResponseHeader( "Content-Type" ), "text/html" )) break;         http.setResponseBody(string.replace( http.getResponseBody(), "<!--SIDEBAR-->" ,   "<a class=\"twitter-timeline\" width=\"520\" height=\"420\" data-theme=\"dark\" " .  "data-link-color=\"#0080ff\" data-tweet-limit=\"0\" data-widget-id=\"261517019072040960\">" .  "</a><script>!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test" .  "(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;" .  "js.src=p+\"://platform.twitter.com/widgets.js\";fjs.parentNode.insertBefore(js,fjs);}}" .  "(document,\"script\",\"twitter-wjs\");</script><br><!--SIDEBAR-->" ));    Result from either rule:  
View full article
In October 2014, Google published details of a vulnerability in the SSL 3.0 protocol - named "POODLE" - which makes it possible for an attacker to decrypt messages between client and server in some circumstances. Because this is a problem with the protocol itself, rather than with a specific implementation of the protocol, this means that any client-server transaction which supports SSL 3.0 is at risk. Even if the client-server supports higher levels of security (such as TLS 1.2), it is possible for an attacker to force a downgrade to SSL 3.0 using a man-in-the-middle attack - which means that systems should disable SSL 3.0 to protect against this kind of attack, and use more recent security handshake protocols such as TLS.   How to Disable SSL 3.0 Completely   With Traffic Manager, it is easy to disable SSL v3.0 completely from the system console. Navigate to System->Global settings->SSL Configuration, and you can control how Traffic Manager manages SSL transactions:     How to Trap SSL Requests:   So we can disable SSL 3.0 completely, but some browsers will show an unhelpful error message: ideally, we would provide some extra feedback to the user to show what the problem is, and how to resolve it. Attach this TrafficScript rule to your virtual server: if you leave SSL 3.0 enabled, this rule permits any transaction using TLS, but traps SSL requests and returns a custom error message to the user:   $cipher = ssl.clientCipher(); if (string.len($cipher) > 0) { if (string.contains($cipher, "version=TLS")) { # this is the good case, incrementing the user SNMP counter counter64.increment(1,1); break; } else { # logic for the SSL (insecure) cases counter64.increment(2,1); # increment a counter for bad cases event.emit ("ssl request", "IP: ".request.getRemoteIP()." User-agent: ".http.getHeader("User-Agent")); http.sendResponse( "400 Bad request", "text/plain", "This service requires TLS security, and is using SSL security. \ Please verify your SSL/TLS settings and try again", "" ); } }   This TrafficScript rule will write an event message to the Traffic Manager log file, identifying the client IP and User Agent, and we also increment a user-defined counter to help track how often attempts are made to open an SSL transaction. These counters can be graphed on the Traffic Manager Activity Monitor, or retrieved remotely as user-defined SNMP variables, (use index 1 for good TLS requests, and index 2 for SSL requests that were rejected). The rule also raises a custom event named "ssl request" which can be used to trigger external actions if needed.   To test the script using Firefox, go to the "about:config" page, and change the value "security.tls.version.max" from the default of "3" to "0" This will force SSL 3.0 to be used instead of TLS. In newer versions of Firefox, you may also need to set "security.tls.version.min" to "0" - but don't forget to set these values back to a secure setting after testing.   Poodle icon designed by http://www.thenounproject.com/edward from the http://www.thenounproject.com.
View full article
This guide will walk you through the setup to deploy Global Server Load Balancing on Traffic Manager using the Global Load Balancing feature. In this guide, we will be using the "company.com" domain.     DNS Primer and Concept of operations: This document is designed to be used in conjuction with the Traffic Manager User Guide.   Specifically, this guide assumes that the reader: is familiar with load balancing concepts; has configured local load balancing for the the resources requiring Global Load Balancing on their existing Traffic Managers; and has read the section "Global Load Balancing" of the Traffic Manager User Guide in particular the "DNS Primer" and "About Global Server Load Balancing" sections.   Pre-requisite:   You have a DNS sub-domain to use for GLB.  In this example we will be using "glb.company.com" - a sub domain of "company.com";   You have access to create A records in the glb.company.com (or equivalent) domain; and   You have access to create CNAME records in the company.com (or equivalent) domain.   Design: Our goal in this exercise will be to configure GLB to send users to their geographically closes DC as pictured in the following diagram:   Design Goal We will be using an STM setup that looks like this to achieve this goal: Detailed STM Design     Traffic Manager will present a DNS virtual server in each data center.  This DNS virtual server will take DNS requests for resources in the "glb.company.com" domain from external DNS servers, will forward the requests to an internal DNS server, an will intelligently filter the records based on the GLB load balancing logic.     In this design, we will use the zone "glb.company.com".  The zone "glb.company.com" will have NS records set to the two Traffic IP addresses presented by vTM for DNS load balancing in each data centre (172.16.10.101 and 172.16.20.101).  This set up is done in the "company.com" domain zone setup.  You will need to set this up yourself, or get your DNS Administrator to do it.       DNS Zone File Overview   On the DNS server that hosts the "glb.company.com" zone file, we will create two Address (A) records - one for each Web virtual server that the vTM's are hosting in their respective data centre.     Step 0: DNS Zone file set up Before we can set up GLB on Traffic Manager, we need to set up our DNS Zone files so that we can intelligently filter the results.   Create the GLB zone: In our example, we will be using the zone "glb.company.com".  We will configure the "glb.company.com" zone to have two NameServer (NS) records.  Each NS record will be pointed at the Traffic IP address of the DNS Virtual Server as it is configured on vTM.  See the Design section above for details of the IP addresses used in this sample setup.   You will need an A record for each data centre resource you want Traffic Manager to GLB.  In this example, we will have two A records for the dns host "www.glb.company.com".  On ISC Bind name servers, the zone file will look something like this: Sample Zone FIle     ; ; BIND data file for glb.company.com ; $TTL 604800 @ IN SOA stm1.glb.company.com. info.glb.company.com. ( 201303211322 ; Serial 7200 ; Refresh 120 ; Retry 2419200 ; Expire 604800 ; Default TTL ) @ IN NS stm1.glb.company.com. @ IN NS stm2.glb.company.com. ; stm1 IN A 172.16.10.101 stm2 IN A 172.16.20.101 ; www IN A 172.16.10.100 www IN A 172.16.20.100   Pre-Deployment testing:   - Using DNS tools such as DiG or nslookup (do not use ping as a DNS testing tool) make sure that you can query your "glb.company.com" zone and get both the A records returned.  This means the DNS zone file is ready to apply your GLB logic.  In the following example, we are using the DiG tool on a linux client to *directly* query the name servers that the vTM is load balancing  to check that we are being served back two A records for "www.glb.company.com".  We have added comments to the below section marked with <--(i)--| : Test Output from DiG user@localhost$ dig @172.16.10.40 www.glb.company.com A ; <<>> DiG 9.8.1-P1 <<>> @172.16.10.40 www.glb.company.com A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19013 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.glb.company.com. IN A ;; ANSWER SECTION: www.glb.company.com. 604800 IN A 172.16.20.100 <--(i)--| HERE ARE THE A RECORDS WE ARE TESTING www.glb.company.com. 604800 IN A 172.16.10.100 <--(i)--| ;; AUTHORITY SECTION: glb.company.com. 604800 IN NS stm1.glb.company.com. glb.company.com. 604800 IN NS stm2.glb.company.com. ;; ADDITIONAL SECTION: stm1.glb.company.com. 604800 IN A 172.16.10.101 stm2.glb.company.com. 604800 IN A 172.16.20.101 ;; Query time: 0 msec ;; SERVER: 172.16.10.40#53(172.16.10.40) ;; WHEN: Wed Mar 20 16:39:52 2013 ;; MSG SIZE rcvd: 139       Step 1: GLB Locations GLB uses locations to help STM understand where things are located.  First we need to create a GLB location for every Datacentre you need to provide GLB between.  In our example, we will be using two locations, Data Centre 1 and Data Centre 2, named DataCentre-1 and DataCentre-2 respectively: Creating GLB  Locations   Navigate to "Catalogs > Locations > GLB Locations > Create new Location"   Create a GLB location called DataCentre-1   Select the appropriate Geographic Location from the options provided   Click Update Location   Repeat this process for "DataCentre-2" and any other locations you need to set up.     Step 2: Set up GLB service First we create a GLB service so that vTM knows how to distribute traffic using the GLB system: Create GLB Service Navigate to "Catalogs > GLB Services > Create a new GLB service" Create your GLB Service.  In this example we will be creating a GLB service with the following settings, you should use settings to match your environment:   Service Name: GLB_glb.company.com   Domains: *.glb.company.com   Add Locations: Select "DataCentre-1" and "DataCentre-2"   Then we enable the GLB serivce:   Enable the GLB Service Navigate to "Catalogs > GLB Services > GLB_glb.company.com > Basic Settings" Set "Enabled" to "Yes"   Next we tell the GLB service which resources are in which location:   Locations and Monitoring Navigate to "Catalogs > GLB Services > GLB_glb.company.com > Locations and Monitoring" Add the IP addresses of the resources you will be doing GSLB between into the relevant location.  In my example I have allocated them as follows: DataCentre-1: 172.16.10.100 DataCentre-2: 172.16.20.100 Don't worry about the "Monitors" section just yet, we will come back to it.     Next we will configure the GLB load balancing mechanism: Load Balancing Method Navigate to "GLB Services > GLB_glb.company.com > Load Balancing"   By default the load balancing "algorithm" will be set to "Adaptive" with a "Geo Effect" of 50%.  For this set up we will set the "algorithm" to "Round Robin" while we are testing.   Set GLB Load Balancing Algorithm Set the "load balancing algorithm" to "Round Robin"   Last step to do is bind the GLB service "GLB_glb.company.com" to our DNS virtual server.   Binding GLB Service Profile Navigate to "Services > Virtual Servers > vs_GLB_DNS > GLB Services > Add new GLB Service" Select "GLB_glb.company.com" from the list and click "Add Service" Now that we have GLB applied to the "glb.company.com" zone, we can test GLB in action. Using DNS tools such as DiG or nslookup (again, do not use ping as a DNS testing tool) make sure that you can query against your STM DNS virtual servers and see what happens to request for "www.glb.company.com". Following is test output from the Linux DiG command. We have added comments to the below section marked with the <--(i)--|: Step 3 - Testing Round Robin Now that we have GLB applied to the "glb.company.com" zone, we can test GLB in action. Using DNS tools such as DiG or nslookup (again, do not use ping as a DNS testing tool) make sure that you can query against your STM DNS virtual servers and see what happens to request for "www.glb.company.com". Following is test output from the Linux DiG command. We have added comments to the below section marked with the <--(i)--|:   Testing user@localhost $ dig @172.16.10.101 www.glb.company.com ; <<>> DiG 9.8.1-P1 <<>> @172.16.10.101 www.glb.company.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17761 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.glb.company.com. IN A ;; ANSWER SECTION: www.glb.company.com. 60 IN A 172.16.2(i)(i)0.100 <--(i)--| DataCentre-2 response ;; AUTHORITY SECTION: glb.company.com. 604800 IN NS stm1.glb.company.com. glb.company.com. 604800 IN NS stm2.glb.company.com. ;; ADDITIONAL SECTION: stm1.glb.company.com. 604800 IN A 172.16.10.101 stm2.glb.company.com. 604800 IN A 172.16.20.101 ;; Query time: 1 msec ;; SERVER: 172.16.10.101#53(172.16.10.101) ;; WHEN: Thu Mar 21 13:32:27 2013 ;; MSG SIZE rcvd: 123 user@localhost $ dig @172.16.10.101 www.glb.company.com ; <<>> DiG 9.8.1-P1 <<>> @172.16.10.101 www.glb.company.com ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9098 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2 ;; QUESTION SECTION: ;www.glb.company.com. IN A ;; ANSWER SECTION: www.glb.company.com. 60 IN A 172.16.1(i)0.100 <--(i)--| DataCentre-1 response ;; AUTHORITY SECTION: glb.company.com. 604800 IN NS stm2.glb.company.com. glb.company.com. 604800 IN NS stm1.glb.company.com. ;; ADDITIONAL SECTION: stm1.glb.company.com. 604800 IN A 172.16.10.101 stm2.glb.company.com. 604800 IN A 172.16.20.101 ;; Query time: 8 msec ;; SERVER: 172.16.10.101#53(172.16.10.101) ;; WHEN: Thu Mar 21 13:32:27 2013 ;; MSG SIZE rcvd: 123   Step 4: GLB Health Monitors Now that we have GLB running in round robin mode, the next thing to do is to set up HTTP health monitors so that GLB can know if the application in each DC is available before we send customers to the data centre for access to the website:     Create GLB Health Monitors Navigate to "Catalogs > Monitors > Monitors Catalog > Create new monitor" Fill out the form with the following variables: Name:   GLB_mon_www_AU Type:    HTTP monitor Scope:   GLB/Pool IP or Hostname to monitor: 172.16.10.100:80 Repeat for the other data centre: Name:   GLB_mon_www_US Type:    HTTP monitor Scope:   GLB/Pool IP or Hostname to monitor: 172.16.20.100:80   Navigate to "Catalogs > GLB Services > GLB_glb.company.com > Locations and Monitoring" In DataCentre-1, in the field labled "Add new monitor to the list" select "GLB_mon_www_AU" and click update. In DataCentre-2, in the field labled "Add new monitor to the list" select "GLB_mon_www_US" and click update.   Step 5: Activate your preffered GLB load balancing logic Now that you have GLB set up and you can detect application failures in each data centre, you can turn on the GLB load balancing algorithm that is right for your application.  You can chose between: GLB Load Balancing Methods Load Geo Round Robin Adaptive Weighted Random Active-Passive The online help has a good description of each of these load balancing methods.  You should take care to read it and select the one most appropriate for your business requirements and environment.   Step 6: Test everything Once you have your GLB up and running, it is important to test it for all the failure scenarios you want it to cover. Remember: failover that has not been tested is not failover...   Following is a test matrix that you can use to check the essentials: Test # Condition Failure Detected By / Logic implemented by GLB Responded as designed 1 All pool members in DataCentre-1 not available GLB Health Monitor Yes / No 2 All pool members in DataCentre-2 not available GLB Health Monitor Yes / No 3 Failure of STM1 GLB Health Monitor on STM2 Yes / No 4 Failure of STM2 GLB Health Monitor on STM1 Yes / No 5 Customers are sent to the geographically correct DataCentre GLB Load Balancing Mechanism Yes / No   Notes on testing GLB: The reason we instruct you to use DiG or nslookup in this guide for testing your DNS rather than using a tool that also does an DNS resolution, like ping, is because Dig and nslookup tools bypass your local host's DNS cache.  Obviously cached DNS records will prevent you from seeing changes in status of your GLB while the cache entries are valid.     The Final Step - Create your CNAME: Now that you have a working GLB entry for "www.glb.company.com", all that is left to do is to create or change the record for the real site "www.company.com" to be a CNAME for "www.glb.company.com". Sample Zone File ; ; BIND data file for company.com ; $TTL 604800 @ IN SOA ns1.company.com. info.company.com. ( 201303211312 ; Serial 7200 ; Refresh 120 ; Retry 2419200 ; Expire 604800 ; Default TTL ) ; @ IN NS ns1.company.com. ; Here is our CNAME www IN CNAME www.glb.company.com.
View full article
You've deployed the PyRunner.jar extension to Traffic Manager so that you can run Python code (see PyRunner.jar: Running Python code in Traffic Manager).  What's the easiest way to deploy the Python code on Traffic Manager?   The following script makes this easy.  It runs a quick syntax check against the Python code, then uses the REST API (Tech Tip: Using the RESTful Control API with Python - Overview) to PUT the python file in the conf/extra part of the Traffic Manager configuration.   publish.py   The source of the publish script:   #!/usr/bin/python import requests import sys import py_compile # FIXME: these need to be correct for your deployment url = 'https://stingray:9070/api/tm/1.0/config/active/' auth = ( 'admin', 'admin' ) file = sys.argv[1] # Syntax-check script before uploading try: py_compile.compile( file, '/dev/null', file, True ) except Exception, e: print "Compilation check failed:", e sys.exit( 1 ) src=open( file, 'r' ).read() # Deploy to Stingray client = requests.Session() client.auth = auth client.verify = 0 try: response = client.put( url+'extra/'+file, data = src ) except Exception, e: print "Error: Unable to connect to " + url + ": ", e sys.exit( 1 ) print "Uploaded " + file   Save this script on your development environment, check the URL and auth parameters, and make the script executable ( chmod +x ).   Deploying Python code to Traffic Manager   Upload the PyRunner.jar file to Traffic Manager, as per the instructions in PyRunner.jar: Running Python code in Traffic Manager.   Create a simple TrafficScript rule and associate it with your virtual server:   java.run( "PyRunner", "vars.py" );   Create a python file named vars.py   from javax.servlet.http import HttpServlet class vars(HttpServlet): def doGet(self, request, response): reqsText = ' %30s: %s\n' % ( "URL", request.getRequestURL() ) reqsText += ' %30s: %s\n' % ( "URI", request.getRequestURI() ) reqsText += ' %30s: %s\n' % ( "Query String", request.getQueryString() ) headText = '' names = request.getHeaderNames() for n in names: headText += ' %30s: %s\n' % ( n, request.getHeader( n ) ) paramText = '' names = request.getParameterNames() for n in names: paramText += ' %30s: %s\n' % ( n, request.getParameter( n ) ) attrText = '' names = request.getAttributeNames() for n in names: attrText += ' %30s: %s\n' % ( n, request.getAttribute( n ) ) attrText += ' %30s: %s\n' % ( "args", request.getAttribute( "args" ) ) toClient = response.getWriter() response.setContentType ("text/html") htmlOut = ''' <html><head><title>vars.py</title><body> <h3>Request</h3><pre>%s</pre> <h3>Headers</h3><pre>%s</pre> <h3>Parameters</h3><pre>%s</pre> <h3>Attributes</h3><pre>%s</pre> ''' % ( reqsText, headText, paramText, attrText ) toClient.println(htmlOut)   Upload it using publish.py:   $ ./publish.py vars.py Uploaded vars.py   Then test it out!   The key advantage of this technique is that it makes publishing Python/Jython code very quick and easy.  Traffic Manager will notice that the Python code has changed and re-load it immediately, giving you a quick test cycle.
View full article
Overview This article illustrates how you can create a custom 'program' action that is triggered when a selection of events is raised.  The action will seek to take the appropriate debugging or remedial action to address the problem associated with each event. Candidate actions If a node fails, we will capture network traffic to and from that node If a node begins to underperform, we will obtain process information from that node If the number of file descriptors gets too low, we will generate a report of file descriptor usage If the Traffic Manager encounters a FATAL problem, we will generate a technical support report To help us create and debug the event handler, we'll first create a very simple debugging action.  Go to the System -> Alerting -> Manage Actions page. Create a Program Action named 'Debug Problem', and configure it to call /bin/echo: Creating the Action To help us create and debug the event handler, we'll first create a very simple debugging action.  Go to the System -> Alerting -> Manage Actions page. Create a Program Action named 'Debug Problem', and configure it to call /bin/echo: The program (/bin/echo) is passed two parameters by default: the name of the event type that triggered the action and information about the specific event reported within that event type. This will suffice for now - we will add more arguments later when we have finished writing the program. Creating an event type   Next, we create a set of events (an 'event type') that will trigger the action:   Go to System -> Alerting -> Manage Event Types and create a new event type called 'Problems to Debug'. You will be presented with a list of all the events that Traffic Manager can catch in a tree structure. Select the following events:   Nodes -> General Events -> Serious Errors -> Node has failed SLM Classes -> Information Messages -> Node information when SLM is non-conforming General -> Warnings -> Running out of free file descriptors General -> ZXTM Software -> Internal software error   Save the event type by clicking 'Update' Linking the event type to the action   The next step is to configure Traffic Manager to trigger the action when one of the events in our event type occurs.   Go to the System -> Alerting page and select the 'Problems to Debug' event type from the drop-down box at the bottom of the page. The event type will appear in the list of mappings alongside a drop-down box containing a list of all the actions that have been configured. Select the 'Debug Problem' action from the list.     It would also be useful to receive a notification that some debug output has been produced, so select 'E-Mail' from the list of actions as well. Click 'Update' to save the changes and then, if you haven't already done so, configure the E-Mail action to use your mail server and e-mail address.   Writing the Program   Currently the 'Debug Problem' action will not do anything useful when it is triggered, so we need to write a program for it to run.  The code for this program is attached to this article.   The program examines the event information it receives and, for certain events, performs some debugging actions. The program determines which event it is handling by matching the primary tag (as presented in the 'Event Type' configuration list). When a node fails... The Perl program looks for the 'nodefail' tag, then extracts the name of the node and its port from the message.   if( $message =~ /\tnodefail\t/ ) { my( $node, $port ) = ( $1, $2 ) if $message =~ /\tnodes\/(\S+):(\d+)\t/; }   It then starts capturing traffic going between Traffic Manager and that node to see if there are any clues as to what is causing the failure. The node might, for example, be ignoring invalid requests from a particular client, thus causing the passive monitoring feature of Traffic Manager to mark it as failed. `tcpdump -c 1000 -n -s 0 -i any -w $diagnostic_file host $node`;   The captured traffic is then sent to a different machine so it can be analysed.   `scp $diagnostic_file $scpuser\@$scpdest`;   The program uses scp to send the information, which usually requires a password to be entered to access the remote machine. Because scp is being invoked by the program there is no opportunity to enter a password. To get around this problem, you can configure scp to contact a particular remote machine without requiring a password. Alternatively, if no location is passed to the program, it will just write the files to a specific location on the Traffic Manager machine so you can access them manually.   When Traffic Manager encounters a problem...   If there is a problem with Traffic Manager, the program will create a technical support report that you can send to the support team should you need further assistance with the problem. Information about the specific problem that occurred in the software will be sent in the notification e-mail that we configured earlier.   `$ENV{ZEUSHOME}/zxtm/bin/support-report $diagnostic_file`; When the number of free file descriptors is running low... If Traffic Manager detects that it is running low on free file descriptors, the program will obtain information about current memory usage, disk usage, active connections and file descriptor settings.   `ulimit -a >> $diagnostic_file`; `vmstat -s >> $diagnostic_file`; `df -h >> $diagnostic_file`; `netstat -an >> $diagnostic_file`;   By examining this information, you should be able to determine why the system is running low on file descriptors. Often it is because the maximum number of file descriptors (as reported by ulimit) is too low, though it could also be caused by the system running out of memory or disk space or there simply being an abnormally high number of active connections. When a Service Level Monitoring class fails... Finally, if SLM fails the program is triggered with the ' slmnodeinfo ' event that identifies which nodes contributed to the SLM failure. In this case, the program will log on to the nodes in question and obtain information about the running processes to see what is going wrong. To do this it uses rsh, which means that you need to have the appropriate permissions configured in the '.rhosts' files on each node to allow the machine running Traffic Manager to access them without a password.   `rsh -l $rshuser $node "ps -eo pid,ppid,rss,vsize,pcpu,pmem,cmd -ww --sort=-pcpu" >> $diagnostic_file`; `rsh -l $rshuser $node "vmstat -s" >> $diagnostic_file`; Testing the program The program also looks out for a 'testaction' event, which is reported when you use the 'Update and Test' button on the action page. We will use this later to make sure the program is working correctly and copies the debug output to the correct location.   Adding the Program to Traffic Manager   We can now configure the 'Debug Problem' action to use the correct program. Upload the program to Traffic Manager's Action Programs catalog (in the 'Extra Files' section.)     Go to System -> Alerting -> Manage Actions, and edit the Debug Problem action; change the program from 'Custom...' to the program you just uploaded.   You will have noticed that the program takes several arguments beyond just the event information. These arguments include the location to which files should be sent and the scp and rsh usernames to use when connecting to remote machines. You can use the 'Argument Descriptions' section of the page to configure the action to supply these arguments. After expanding the Argument Descriptions section, enter 'rshuser' into the name box and 'Username used to log on to failing nodes' in the description box. Click update and then add the remaining arguments - scpuser and scpdest - in the same way.   The arguments will appear in the 'Additional Settings' section where you can configure them with the appropriate values for your system. Click 'Update' to save the configuration and scroll down to the Additional Settings section again. The command that will be executed when the action is triggered is shown at the bottom of this section:       It would also be helpful to enable 'Verbose' mode on the action at this point so any problems that occur are reported in the Event Log.   If you want to test the program out, click 'Update and Test' from the Debug Problem action's page and you should find a file called 'test-event.txt' in the location you put in the 'scpdest' parameter. If not then double check that you can use scp to copy files from the Traffic Manager machine to that location without requiring any user interaction.   If you did get the file then when any of the events in the 'Debug Problems' event type occur you will receive some additional debugging information!
View full article
  Traffic Manager does not provide a ‘connection mirroring’ or ‘transparent failover’ capability.  This article describes contemporary connection mirroring techniques and their strengths and limitations, and explains how Traffic Manager may be used with VMware Fault Tolerance to create an effective solution that preserves all connections in the event of a hardware failure, while processing them fully at layer 7. What is connection mirroring?   A fault tolerant load balancer cluster eliminates single points of failure:  When load balancers are deployed in a fault tolerant cluster, they present a reliable endpoint for the services they manage.  If one load balancer device fails, its peers are able to step in and accept traffic so the service can continue to operate.   …but a failover event will drop all established TCP connections: However, if a load balancer fails, any TCP connections that are established to that load balancer will be dropped.  Clients will either receive a RST or FIN close message, or they may just experience a timeout.  The clients will need to re-establish the TCP connection.  This is an inconvenience for long-lived protocols that do not support automatic reconnects, such as FTP.     Connection Mirroring offers a solution: If the load balancers are operating in a basic layer-4 packet forwarding mode, the only actions they perform is to NAT the packets to the correct target node, and to apply sequence number translation.  They can share this connection information with their peer.  If a load balancer fails, the TCP client will retransmit its packets after an appropriate timeout.  The packets will be received by the peer who can then apply the correct NAT and sequence number operations.   When is it appropriate to use connection mirroring?   Connection mirroring is best used when only very basic packet-based load balancing is in use.  For example, F5 recommend that you "enable connection mirroring on Performance (Layer 4) virtual servers only" and comment "mirroring short-term connections such as HTTP and UDP is not recommended, as this will cause a decrease in system performance... is typically not necessary, as those protocols allow for failure of individual requests without loss of the entire session".   Cisco also support layer 4 connection mirroring (referring to it as ‘Stateful Failover’) and note that it is only possible for layer 4 connections.  When using a Cisco ACE device, it is not possible to failover connections that are proxied, including connections that employ SSL decryption or HTTP compression.   Layer 7 connection mirroring imposes a significant network and CPU overhead   Layer 7 connection mirroring puts a very high load on the dedicated heartbeat link (all incoming packets are replicated to the standby peer) and is CPU intensive (both traffic managers must process the same transactions at layer 7). It may add latency or interfere with normal system operation, and not all ADC features are supported in a mirrored configuration.  Because of these limitations, F5 advise "the overhead incurred by mirroring HTTP connections is excessive given the minimal advantages."   Does connection mirroring guarantee seamless failover?   Due to timing and implementation details, connection mirroring does not guarantee seamless failover.  State data must be shared to the peer once the TCP connection is established, and this must be done asynchronously to avoid delaying every TCP connection.  If a load balancer fails before it has shared the state information, the TCP session cannot be resumed.   Typical duration of a TCP transaction (not including lingering keepalives) 500 ms Typical window before which state information is synchronized (implementation dependent) 200 ms (state exchanged 5 times per second) On failure, percentage of connections that cannot be re-established 200/500 = 40%   Connection mirroring does not guarantee seamless failover because connections must proceed while state is being shared   What is the effect of connection mirroring on uptime?   Connection mirroring carries a cost: increased internal traffic for state sharing, and severe limitations on the functionality that may be used at the load balancing tier.  What effect does it have on a service’s uptime?   Typical duration of a TCP transaction (not including lingering keepalives) 500 ms Typical number of individual load balancer failures in a 12 month period 5 Percentage of transactions that would be dropped if a load balancer failed 50% (assuming an active-active pair of load balancers)     Percentage of transactions that would be recovered on a failure 60% (analysis above: 40% would not be recovered)     What is the probability that an individual connection would be impacted by a load balancer failure? 500/(365.5*24*3600*1000) * 50% * 5 = 0.000000040 What is the probability that connection could be ‘rescued’ with connection mirroring? 60% = 0.6 What proportion of transactions would be impacted by a failure, and then recovered by connection mirroring? 0.000000040 * 0.6 = 0.000000024 (i.e. 0.0000024%)   Connection mirroring improves uptime by an infinitesimal amount   General advice   Consider using connection mirroring when: Operating in L2-4 NAT load balancing modes Performing NAT load balancing with no content inspection (no delayed binding) No content processing e.g. SSL, compression, caching, cookie injection is required Base protocol does not support automatic reconnects – e.g. FTP Connections are long-lived and a dropped connection would inconvenience the user, e.g. SSH Your load balancer is unreliable and failures are sufficiently frequent that the overhead of mirroring is worthwhile You are running a fault-tolerant pair of load balancers   Don’t use connection mirroring when: Operating in full proxy modes Performing NAT or full proxy load balancing with content inspection Compressing content, SSL decrypting, caching, session persistence methods that inject cookies, application firewall Base protocol supports reconnects – e.g. RDP Connections are short-lived and easily re-established e.g HTTP Your load balancers are reliable and you can accommodate instantaneous loss of connections in the event that one does fail You plan to run a cluster of three or more load balancers (this configuration is not supported by the major vendors who offer connection mirroring)   Benefits of using Connection Mirroring Improves uptime by 0.0000024% (typical) (2.4 millionths of a percent)   Costs of using Connection Mirroring Limits traffic inspection or manipulation in load balancer. Increases internal traffic and increases load on load balancer   Balance the benefits of connection limiting against the additional risk and complexity of enabling it and the potential loss in performance and functionality that will result.  Be aware that, based on the preceding analysis, unless your goal is to achieve more than 7-9’s uptime (99.99999%), connection mirroring will not measurably contribute to the reliability of your service.   When connections are too valuable to lose…   Pulse customers include emergency and first-response services around the world, NGO services publishing disaster-response information and even major political fund-raising concerns. In each case, extremely high availability and consistent performance in the face of large spikes of traffic are paramount to the organizations who selected Traffic Manager.   A number of customers use VMware Fault Tolerance with Traffic Manager to achieve enhanced uptime without compromising the any of the functionality that Traffic Manager offers. VMware Fault Tolerance maintains a perfect shadow of a running virtual machine, running on a separate host.  If the primary virtual machine fails due to a catastrophic hardware failure, the shadow seamlessly takes over all traffic, including established connections, with a typical latency of less than 1 ms. All application-level workloads, such as SSL decryption, TrafficScript processing and Authentication are maintained without any interruption in service:   VMware Fault Tolerance runs a secondary virtual machine in ‘lock step’ with the primary. Network traffic and other non-determinstic events are replicated to the secondary, ensuring that it maintains an identical execution state to the primary. If the primary fails, the secondary takes over seamlessly and a new secondary is started.   Such configurations leverage standard VMware technology and are fully supported. They have been proven in production and offer enhanced connection mirroring functionality compared to proprietary ADC solutions
View full article
Java Extensions are one of the 'data plane' APIs provided by Traffic Manager to process network transactions.  Java Extensions are invoked from TrafficScript using the java.run() function.   This article contains a selection of technical tips and solutions to illustrate the use of Java Extensions.   Basic Language Examples   Writing Java Extensions - an introduction (presenting a template and 'Hello World' application) Writing TrafficScript functions in Java (illustrating how to use the GenericServlet interface) Tech Tip: Prompting for Authentication in a Java Extension Tech Tip: Reading HTTP responses in a Java Extension   Advanced Language Examples   Apache Commons Logging (TODO) Authenticating users with Active Directory and Stingray Java Extensions Watermarking Images with Traffic Manager and Java Extensions Watermarking PDF documents with Traffic Manager and Java Extensions Being Lazy with Java Extensions XML, TrafficScript and Java Extensions Merging RSS feeds using Java Extensions (12/17/2008) Serving Web Content from Traffic Manager using Java Stingray-API.jar: A Java Interface Library for Traffic Manager's SOAP Control API TrafficManager Status - Using the Control API from a Java Extension   Java Extensions in other languages   PyRunner.jar: Running Python code in Traffic Manager Making Traffic Manager more RAD with Jython! Scala, Traffic Manager and Java Extensions (06/30/2009)   More information   Feature Brief: Java Extensions in Traffic Manager Java Development Guide documentation in the Product Documentation
View full article