by Aidan Clarke   Traffic IP (TIP) Groups are the key to how Brocade vADC delivers intelligent clustering, as we saw in the previous article. This is because we handle Traffic IP Addresses in a novel way - Traffic IP (TIP) Groups allow you to define one or more IP addresses to be used for an application endpoint, and you can decide how you want these IP addresses distributed across your cluster.   This means that you are not restricted to a single IP address allocated to a Virtual Server. Once your virtual server is configured, you simply bind it to one or more Traffic IP Groups, which gives you much greater flexibility in how you design your service.     A Traffic IP (TIP) Group is a “Listener” for incoming traffic to be “Load Balanced” TIP Groups can have one or more Traffic IP addresses TIP Groups can live on one or multiple Traffic Managers By default, TIP Groups are “Round Robin” distributed across the cluster   Service Example: With Brocade vADC: Application #1 must be Active/Active/Active on three nodes of a three-node cluster, but you want a warm standby node? Create a TIP Group with three IP addresses on a four-node vTM cluster with one of the nodes marked as passive (T1 above) Application #2 needs a simple Active/Standby configuration with a single IP address? Create a simple TIP group with one of the nodes as passive (T2 above) Application #3 must be Active/Active/Standby on a three-node cluster? Create a TIP Group with two IP addresses on a three-node cluster and (optionally) mark one of the cluster nodes as passive (T3 above) Application #4 must be active on all nodes of an eight node cluster but only have one IP address? Use a multicast enabled environment and deploy a multi-hosted Traffic IP Group. vADC will ensure the workload is evenly distributed across the cluster All of the above, at the same time for different Virtual Servers on the same cluster? No problem. Brocade vADC excels at all aspects of clustering     What happens when a node fails?   Brocade vADC monitors the health on all nodes, and when a node fails, then each service is reconfigured gracefully. In this example, if the second node fails, then:   Application #1 transfers workload to standby (node #4) Application #2 transfers workload to standby (node #3) Application #3 continues unchanged, but shares workload on node #4     During failover, session mapping is maintained for all nodes that remain active; and as standby nodes are brought online, session persistence can pin new user sessions to the new nodes. For recovery, or for planned maintenance, a node can be “drained” - no new sessions are pinned to the node - allowing for graceful reconfiguration or shutdown.   Traffic IP Groups allow for flexible allocation of workload as applications are brought online or reconfigured across a cluster, allowing you to express the relative priorities of applications in a shared infrastructure, an the desired behavior for failover and recovery.   And by increasing the number of cluster nodes dynamically, the scope of a node failure is reduced. By reducing the size of fault domains, services can recover more quickly, and additional nodes can be brought online to return services to full resilience.       This article is part of a series, beginning with: Staying Afloat in the Application Economy More to Explore: Prev: Intelligent N+M Clustering Next: To be continued...     ... View more

by Aidan Clarke   In a previous article, we looked at how Brocade vADC is designed to be clustered in virtual and cloud environments. Unlike traditional HA architectures, you don't need cluster members to be Layer 2 adjacent, and nor are you restricted to simple Active/Standby configurations. In fact, there are THREE types of clustering which you might look for:   Clustering for Scale - Brocade vADC does not even limit you to two-way clustering - you can scale out to 64 nodes in a single cluster. And with each node able to drive over 140 Gbps in a single virtual instance, you have the choice to scale UP or scale OUT to suit any type of application architecture.   Clustering for Availability - Brocade vADC is not restricted to simple Active/Active and Active/Standby. You can build flexible N+M failover models, with shared or non-shared standby nodes, using Traffic IP Groups to define which services are hosted on which nodes, within a single cluster.   Clustering for Synchronization - In some architectures, you need to synchronize: each node needs to know the end points for every cluster member, so you have to replicate the configuration each time. With Brocade vADC, you define the cluster, and the configuration is replicated to all members - not just the end point IPs, but the business rules, traffic policies and access rights.     Brocade vADC excels at all three types of clustering, and there’s an extra bonus: all key capabilities such as web application security, content optimization, global load balancing and TrafficScript rules are supported and synchronized across all cluster members. Which lets you focus on what your application needs, rather than on restrictions imposed by networking and load balancing.   By contrast, traditional IT architectures meant that key capabilities were often not supported in clusters, so you might have to choose between performance, resilience and management - and lose critical capabilities.   The Brocade vADC portfolio is designed to cluster and scale horizontally - no matter what your workload, we can scale to meet it without compromising on the features offered. Configure your application once, and choose how you want the application spread across the cluster using Traffic IP Groups.     This article is part of a series, beginning with: Staying Afloat in the Application Economy More to Explore: Prev: Active/Active Clustering for High Availability Next: Traffic IP Groups vs Virtual IP Addresses   ... View more

by Aidan Clarke   Traditional IT applications were simple: they lived in one place, in your data center. If you wanted more capacity, you added more servers, storage and networks. If you wanted to make the application more reliable, you doubled it to make it highly available: you had one system running “active” - while the other system waited on “standby.” This concept of “redundancy” was simple, so long as you could buy two of everything, and were happy that only half of the infrastructure was active at any one time - not an efficient solution.   But modern applications need a modern approach to performance, security and reliability: which is why Pulse vADC approaches things differently, a software solution for a software world, where distributed applications need an “always-active” architecture.   We often hear from IT professionals that they used to avoid Active/Active architectures; for fear that performance would be compromised under failure. Our customers routinely deploy Pulse vADC in Active/Active, or even Active/Active/Active/Active solutions all the time: they can choose the right balance between node and cluster size, to optimize the availability, while reducing the size of the fault domain.     Similarly, high-availability architectures used to require that HA peers were installed as Layer 2 adjacent (ie: on the same network). These architectures simply don't work in today's clouds; for example, AWS availability zones, by their very design, are on different Layer 3 networks. In order to run a Layer 2 HA pair in Amazon AWS, you need to put your whole solution in a single AWS Availability zone - a practice that Amazon architects strongly discourage.   With Pulse vADC, if you can connect to each other via a network, then you can cluster your application. Which means that you can choose an availability architecture to suit your application - whether it lives in your data center, in a cloud, or both.   Get started with Pulse vADC today, our Community Edition is free to download and try out in your test and development environment.     This article is part of a series, beginning with: Staying Afloat in the Application Economy More to Explore: Prev: One ADC Platform, Any Environment Next: Intelligent N+M Clustering    ... View more

by Aidan Clarke   The Brocade vADC suite is designed to be flexible, extensible and portable software. Regardless of whether your applications run in the enterprise data center, in a private cloud, a public cloud or anything in between, Brocade's vADC can get you there.   Our solution was purpose-built for software deployment, and fits naturally into any virtual or cloud environment: and it was the first full functioning ADC solution available on VMWare, and has been in public clouds since the beginning - originally named Zeus ZXTM, it was launched on Amazon EC2 in 2009. The Brocade vADC platform only needs one simple thing to operate: a platform that can run Linux on an Intel platform. If you can do that, you can run Brocade vADC.     Brocade vADC offers native images for Amazon AWS, Microsoft Azure, Google Cloud Engine, Rackspace, Joyent, Sunguard and many more - and it is also available as a Virtual Appliance for VMware, HyperV, Xen Server, KVM and OracleVM.   Furthermore, Brocade Services Director can manage vADC workloads in all of these environments simultaneously: our customers can deploy Brocade Services Director in an enterprise Data Centre (DC) and use it to manage workloads in both the DC and the cloud at the same time.   Simply put, no matter where your applications run, Brocade vADC can be right there with them. And no matter where you go, it's the same vADC software ensuring your applications are Available, Scalable, Fast and Secure. Get started with Brocade vADC today, our Developer Edition is free to download and try out in your test and development environment.     This article is part of a series, beginning with: Staying Afloat in the Application Economy More to Explore: Prev: Right-Size for Capacity Next: Active/Active Clustering for High Availability   ... View more

  The Pulse Services Director makes it easy to manage a fleet of virtual ADC services, with each application supported by dedicated vADC instances, such as Pulse Virtual Traffic Manager (Pulse vTM). In fact, Services Director can even support mixed versions of Pulse vTM, which means that some applications can be managed with an older version of Pulse vTM, while others with the very latest version of Pulse vTM.   Generally speaking, compatibility with older, supported versions of Services Director will be maintained in each new vTM release. In other words, you should be able to upgrade vTM without losing Services Director functionality. Some Service Director features rely on changes introduced into vTM, and will only be available when Services Director is managing vTM versions that expose the feature in question.   This table summarises the compatibility between supported versions of Services Director and Virtual Traffic Manager:     Services Director         2.4 (EoS) 17.2 (LTS) 18.1 (EoS) 18.2 18.3 19.1 20.1 (LTS)   Traffic Manager                 9.9 (EoS) 1 1 1 1 1 1 1   10.4 (EoS) Y 1 1 1 1 1 1   17.2 (LTS) Y Y Y Y Y Y Y    18.2 (LTS) Y Y Y Y  Y Y Y   18.3 Y Y  Y  Y  Y Y Y   19.1 Y Y Y Y Y Y Y   19.2 (LTS) Y Y Y Y Y Y Y   19.3 Y Y Y Y Y Y Y   20.1 (LTS) Y Y Y Y Y Y Y   20.2 Y Y Y Y Y Y Y     Limitations of feature support: Although the table above indicates that most combinations are supported to some extent, some key capabilities are of course dependent on the respective versions of SD and of vTM. The capability must be available by both your installation of Services Director and the instance of vTM, in order to be fully functional.   For example, the capability for instances of vTM to “Self-Register” with Services Director is only supported in Services Director 2.4 and higher, and in vTM versions 10.4 and higher:   Example SD Capability Available from which version     Services Director vTM vTM Cluster Awareness 2.3 10.3 vTM Instance Health 2.4 10.2 vTM Self Registration 2.4 10.4 vTM Backup/Restore 2.5 (note 2) 11.0 vTM Enterprise Management 18.1 (note 2) 18.1 vTM Traffic Analytics 18.1 (note 3) 17.2 SD/vTM Communications through NAT (note 4) 19.1 19.1 LDAPS/STARTTLS Admin Authentication (note 5) 20.1 20.1 Key to the Table   Y  This combination is fully compatible, supporting all capabilities which are supported in both of the corresponding versions of SD and vTM.  This should be interpreted that a given feature is compatible, if both the SD and vTM support that feature in the same way. It does not imply (for example) that an older version of SD will support all features in a newer version of vTM.   1  This combination is compatible, but some features are NOT fully supported, depending on the respective versions of SD and vTM.   2  From SD 18.3, Centralized Backup/Restore is enabled for each vTM instance managed by SD.   3  From SD 18.3, Traffic Analytics, Data Export and the Analytics Application requires an optional Analytics Feature Pack to be installed in SD.   4 From SD & vTM 19.1, An alternate communications channel is created between SD and all managed vTMs which provides improved monitoring in Kubernetes and NAT deployments.   5 From SD & vTM 20.1, LDAPS/STARTLS are recommended for admin authentication profiles. EoS This software version is no longer supported.   EOL/EOS Information For complete information about EoL and EoS dates, see the support pages: EOL/EOS for vTM EOL/EOS for SD This data is correct at the time of last update - July 2020. For combinations of SD and vTM not shown in this table, please contact your Pulse technical sales representative.     ... View more

by Aidan Clarke and Paul Wallace   Today’s applications are built for innovation and customer experience, and it can be hard to predict how they will evolve if they hit a rapid growth curve. Which makes it very hard to plan ahead for capacity, especially when you don't know how your systems will scale under increased workloads.   Traditionally, IT organizations would need to plan far, far ahead. Not just for systems resources such as CPU, memory, storage and networks, but also for software licensing for larger-scale systems. This used to very complex, as software sizing often depended on workloads: you might need to translate your projected capacity (guess) into the numbers of CPUs required (guess) in order to calculate the number and type of software licensing required (another guess).   In order to hit the projected workloads, you might need more CPUs, for which you might need to buy bigger licenses. And just in case, you might round up to make sure that your application did not hit the CPU license limit at peak periods.     With Brocade vADC, we have taken some of the guesswork out of capacity planning. We don't limit the number of CPUs you can run on an instance. If you need more horsepower, simply add more CPUs to the workload and you can scale up to meet demand, up to the licensed capacity you have selected.   With a pure software architecture, Brocade vADC can monitor throughput and capacity, while optimizing the available CPU and memory. So if you provision a vADC with 1 Gbps ADC capacity, then it will only be limited by the available CPU/memory/networking. You can add complex business rules, deep security scanning, compression and SSL/TLS security, and you will still be able to deliver 1 Gbps throughput so long as the system has enough resources.   So while traditional IT architectures meant that you had to over-size your systems - sometimes you had to install 10 Gbps of capacity just to run a 1 Gbps workload - with Brocade vADC, you just need to provision enough CPU and memory to right-size your workload.   Get started with Brocade vADC today, our Developer Edition is free to download and try out in your test and development environment.     This article is part of a series, beginning with: Staying Afloat in the Application Economy More to Explore: Prev: Agile Licensing for Agile Applications Next: One ADC Platform, Any Environment    ... View more

We have made it easier to see which features are offered in which model of Pulse Virtual Traffic Manager: there are two feature groups, which are common to both fixed-sized licenses using the Pulse vTM, and in the capacity-based licensing scheme using the Pulse Services Director:   Advanced Edition: Includes the most common LB capabilities, including SSL/TLS offload, session persistence, service level monitoring, simple TrafficScript Rule Builder, and support for IPv6 and HTTP/2; and also includes capabilities such as Global Load Balancing, Route Health Injection, and customisation using the powerful TrafficScript scripting language and Java Extensions;   Enterprise Edition: Includes premium L7 services such as Web Content Optimization (WCO) and Web Application Firewall (WAF) and FIPS compliance.     Model Pulse vTM Bandwidth Options Throughput 50M 400M 1G 3G 5G 10G 20G 40G 80G SSL/TLS TPS Uncapped Functionality Choose from Advanced or Enterprise Editions Deployment model Choose from Software, Virtual Appliance or Bare Metal image License Style Choose from Perpetual or Subscription   Functionality Advanced Edition Enterprise Edition   Community Edition 10 Mbps limit  4 cluster nodes Pulse vTM Y Y   Y Pulse Services Director Y Y   -           Load Balancing Y Y   Y HTTP/2 Support Y Y   Y Content Routing Y Y   Y Health Monitoring Y Y   Y Simple TrafficScript Rule Builder Y Y   Y SSL/TLS Offload Y Y   Y HTTP Compression Y Y   Y Event and Action System Y Y   Y Service Protection Y Y   Y Activity Graphs Y Y   Y HTTP Caching Y Y   Y Autoscale Y Y   Y XML Parsing Y Y   Y Bandwidth Management Y Y   Y Rate Shaping Y Y   Y Service Level Monitoring Y Y   Y TrafficScript Y Y   Y Java Extensions Y Y   Y Multi Site Manager Y Y   Y Global Load Balancing Y Y   Y Route Health Injection Y Y   Y Web Accelerator Express - Y   Y Web Accelerator - Y   Y Web Application Firewall - Y   Y Enterprise Authentication - Y   Y FIPS - Y   Y     Feature Summary  Feature Description Adv Ent Load Balancing Traffic Manager can use a wide variety of algorithms and techniques and balance load based on different criteria (e.g. can send more requests to higher spec machines). Servers can be drained for easy maintenance and uninterrupted service. The client never has to see a server fail. Y Y HTTP/2 Support Faster web pages with support for HTTP/2 connections. HTTP/2 is
a significant enhancement to the HTTP/1.1 standard: Traffic Manager can automatically negotiate an HTTP/2 connection with the client web browser, which may improve web page load time with techniques such as connection sharing, page request multiplexing and header compression. For even more advanced HTML and web content optimization, the optional Web Accelerator technology is available in the Enterprise Edition, to create custom optimization profiles for individual applications. Y Y Content Routing Use Traffic Manager to apply business policies to each request for custom routing decisions, applying HTTP pool selection routing based on L7 attributes such as URL and hostname. Content inspection allows rapid web changes such as the insertion of marketing tags, branding changes, and dynamic watermarking, procedures that may be difficult to achieve by modifying the application itself. Y Y Session Persistence   Ensures all requests from a client go to the same server, enabling application data to persist throughout a session without using cookies (e.g. an e-commerce shopping basket). Y Y Health Monitoring Monitor the health and correct operation of servers with built-In and custom checks. Detect failures of servers and errors in applications, and route traffic away from these servers so that the performance of the application is not compromised and the user experience is maintained. Y Y Simple TrafficScript RuleBuilder Define rules to control applications with the TrafficScript Rule Builder, using an easy-to-use graphical user interface to create traffic rules and policies. Click and choose from drop-down menus to create simple conditions and actions. Y Y SSL/TLS Offload Off-loading SSL/TLS key exchanges and decryption to the Traffic Manager frees up the back-end servers use their full resources for generating content and responding to user requests. Decryption on the Traffic Manager allows for deep packet inspection. Content can be re-encrypted for secure forwarding of requests to the back-end infrastructure. Y Y HTTP Compression Traffic Manager can compress content returned to the client rather than have that workload undertaken by the back- end servers. Compression of content can result in bandwidth being used more efficiently. offloading this workload from the back-end servers can enable it to serve requests faster. Y Y Event Handling and Action System Configure appropriate responses for key infrastructure events, including email and SNMP alerts, syslog logging and custom user-supplied scripts. Y Y Service Protection Traffic Manager can enforce an IP black/white list and limit the number
of connections to a service. It can also enforce rules on HTTP content (e.g. enforce RFC compliance) and help protect against malicious attacks such as Denial of Service. Y Y Activity Graphs Measures performance and load and gives a graphical representation of the results which can identify bottlenecks and identify where and when high loading occurs which can be useful for identifying future upgrade needs. Y Y HTTP Caching Traffic Manager can store copies of frequently-requested data on the Traffic Manager rather than the back end servers, freeing them up to deliver newly requested content. This can reduce the need for additional servers as traffic grows and speed up the response to end user requests. Y Y Autoscaling Ensure reliable application service delivery by automatically managing traffic changes in real time, distributing traffic among a pool of virtual servers. It can orchestrate the provisioning and rightsizing of applications, helping to migrate traffic across multiple virtual and cloud platforms. Y Y Bandwidth Management You can limit the total bandwidth (kbits/ sec) a set of connections can use
which can be used to stop a popular
site or application taking up so much bandwidth other sites or applications become unavailable. This can enable service providers to enforce access limits based on criteria such as account type or location. Y Y Rate Shaping Traffic Manager can restrict the number of requests (per min or sec) to a service, from either all or a set of clients. This can stop a small group of intensive users (including spiders) hogging a service, leading to a poor user experience for all users. Y Y Service Level Monitoring Monitors the performance of a service
or application and can issue an alert if it falls below a pre-determined level such as going out of scope of an SLA. Y Y TrafficScript TrafficScript is a sophisticated programming language integrated within the core of Traffic Manager that enables high performance, highly-configurable control of traffic management policies. TrafficScript rules can control all aspects of how traffic is managed and can choose when and where to apply request rate shaping, bandwidth shaping, routing, compression, and caching to prioritize the most valuable users and deliver the best possible levels of service. Y Y XML Parsing It can also help parse complex XML data using XPath in order to make informed routing decisions based on embedded content. Also includes supports for the offload and acceleration of the translation between XML variants via XSL Transformations (XSLT). Y Y Java Extensions Java Extensions can be used to re-use existing code libraries to implement business policies. You can write rules in any language that can target the JVM, including Java, Python, Ruby, and many others. You can use third party libraries, and invoke business rules against specific transactions. Y Y Multi-Site Capable Deploy services across multiple sites with location-specific configuration and simplify and the management of services from multiple datacenter locations. Y Y Advanced Session Persistence Ensures all requests from a client go to the same server, enabling application data to persist throughout a session without using cookies (e.g. an e-commerce shopping basket). In addition to session persistence based on IP addressing, Advanced Persistence mechanisms can be leveraged via TrafficScript, including Named Node and Universal Persistence techniques. Y Y Global Load Balancing Improve service availability by automatically failing over to an alternative datacenter or cloud deployment in the event of a catastrophic failure. Improve service performance by performance- sensitive load balancing and location- based traffic routing. Y Y Route Health Injection Route Health Injection (RHI) helps to maintain service availability and low-latency networking, by providing rapid service redirection to alternate service hosts. Y Y Web Accelerator Express Simple content optimization to accelerate the delivery of most web pages, requiring no configuration or tuning.   Y Web Accelerator Advanced Web Content Optimization (WCO) technologies, to accelerate page load times up to 4x for HTML applications, including Microsoft SharePoint, content management systems and cloud applications. WCO profiles can be customized for each application.   Y Web Application Firewall A scalable Layer-7 Web Application Firewall (WAF) to apply business rules to your online traffic, inspect and block attacks such as SQL injection and cross-site scripting (XSS), and help achieve compliance with PCI-DSS and HIPAA and other regulatory demands.   Y Enterprise Authentication Support for authentication services such as SAML SP and Kerberos Common Access Cards (CAC)   Y FIPS Embedded FIPS 140-2 level 1 cryptographic module per FIPS 140-2 implementation guidance section g.5 guidelines, to support deployments that require FIPS 140-2 level 1 compliance.   Y   Architectural Features In addition, all Traffic Manager models have the following common architectural benefits: Feature Description Scalability Traffic Manager can scale horizontally and vertically very easily, across IT environments and different forms of infrastructure ensuring that it can always scale up to match and support demand for an application or a service. Clustering Traffic Manager has unmatched scale and performance, and is able to scale-up with the latest generation of multi-core CPUs, and scale out with N+M clustering for reliability and throughput. Note that the Community Edition allow no more than four nodes in a cluster. RESTful Control API Allows Traffic Manager to be configured and controlled by a third-party application and simplifies administration of large/ complex configurations. The Control API enables configuration changes to be automated (e.g. In response to an event).     ... View more

I have zipped up some icons and Visio stencils that our technical teams use when they are creating diagrams. I have included different formats, including solid and sketch styles:   Attached three files: brocade-vadc-product-icons.zip - PNG files brocade-vadc-visio-stencils-1.zip - Visio files brocade-vadc-visio-stencils-2.zip - Visio files         ... View more

Getting Started with Pulse vADC Welcome to Pulse Secure Application Delivery solutions! Whether you are scaling out your secure access capabilities, or building the next-generation of high-performance online applications, Pulse vADC helps you build dynamic applications which are more resilient, more secure, and more responsive at global scale. This article gives a quick five-step guide to how you can download Pulse Virtual Traffic Manager, including how to download the Community Edition of the software, installing and configuring your first services, and then how to request a full-performance 30-day license key to experience the full power of Pulse Application Delivery solutions.   1. Download Pulse vADC The quickest way to get started with Pulse vADC is to download the Community Edition of Pulse Virtual Traffic Manager. This will give you access to all the features and full programmability of Pulse vADC software, including add-on options for web application firewall (WAF) and web content optimization (WCO). The software needs no license key, but is limited to 10 Mbps throughput, so it can be used to explore the software run applications in production.   2. Install Pulse vADC Grab either the Software or Virtual Appliance (VMware, Xen or OracleVM) installation and follow the instructions in the appropriate Getting Started guide. We have created dedicated installation and configuration guides for each type of environment, as part of the documentation set for Pulse Virtual Traffic Manager - choose the right environment, and install the software and you are ready to go.   (You can find the complete set of user documentation here)   3. Discover Pulse vADC These Pulse community pages include a wide range of resources to help you explore Pulse vADC solutions. From setting up simple services, through to remote management with REST and SOAP, and high-performance data-plane control using TrafficScript, Pulse gives you a comprehensive set of tools to differentiate and prioritise applications and services. See below for some good starting points!   4. Scale up Pulse vADC Ready to scale up your performance? When you are ready to move to the next level, contact us to request a 30-day evaluation license to test the full power of Pulse Virtual Traffic Manager. You will be sent a license key by email, which you can upload into the Community Edition - then you can run complete performance and load testing in your own data center or cloud platforms. This evaluation license key will include Pulse Virtual Traffic Manager, again with add-on options for web application firewall (WAF) and web content optimization (WCO).     5. Five Ideas to Explore on the Pulse Community Ok, so you have downloaded and installed Pulse vADC, and you want to find out how it can help you build smarter applications. You have already heard it is more than just a software load balancer, but where do you start with such a powerful platform? We have collected five of our favorite things to explore with Pulse vADC:   Smarter Load-Balancing with Pulse vADC The first thing you can do with Pulse vADC is to set up a simple Load-Balancing Service for your application. We’ve made it really easy, with a built-in Wizard to gather the key information and set up your service. This great article covers the basic load-balancing, and then shows you how to set up host redirects, embedded inks and health monitors. Getting Started with Pulse vADC and Load Balancing   Optimal Gateway Selection Do you need to improve the productivity of mobile users? Pulse vADC makes it easy to implement Optimal Gateway Selection (OGS), so that users are automatically connected to the nearest available application gateway. For example, using Pulse Connect Secure for mobile access and home workers, OGS will check the service availability each location, and then redirect new sessions to the nearest location, helping your business stay online. Using DNS-based load-balancing, OGS uses geolocation to determine the nearest available gateway, and return the CNAME of the nearest gateway to redirect new sessions to the optimal location. In the background, OGS keeps track of the service health at each location, to ensure that new sessions are routes appropriately. OGS can even be customised to implement your own business policies, and even check license headroom at each location to ensure that sessions are evenly distributed between nearby locations. Load-Balancing Remote Access Solutions How do you optimize the performance and utilization of application gateways? Do you need to balance sessions evenly across platforms of different sizes? Pulse vADC provides even distribution of sessions, even when server appliances and gateways have different sized capacity. For example, using Pulse Connect Secure Pulse vADC will check the health of each appliance, and balance license usage across each appliance in the cluster, steering traffic towards lightly-loaded appliances, increasing the utilisation of PCS appliances and licenses.   Using Smart Local Load Balancing, Pulse vADC can test the health and license usage at local PCS appliances, and route sessions in real time across the cluster, Pulse vADC applies session persistence even when used in a large cluster of appliances, and can even apply service protection methods such as shielding login screens against credential stuffing, and blocking sessions during times of high workloads. What is a Traffic Manager, Anyway? What’s the difference between a “Load Balancer” and an “ADC” - and what is a “Traffic Manager” anyway? Check out this short series of articles to look into the basics of load balancing, and how you can layer additional service control and protection for your applications.   What is a Traffic Manager, Anyway? Three ways to Use Pulse Traffic Manager How to set up Load Balancing Health Monitoring with Pulse Traffic Manager Content Caching for Dynamic Web Applications Control and Flexibility with Pulse Traffic Manager Controlling Service Levels with Pulse Traffic Manager Fixing errors on a website with Pulse Traffic Manager     Global Load Balancing with Pulse vADC When you ready, you can scale out your application to reach a global audience, with built-in Global Load Balancing. This short series of articles digs even deeper into how Global Load Balancing works, and looks at the different ways in which Pulse vADC can integrate with your DNS services to deliver global application resilience.   Global Load Balancing with Pulse vADC The Layman's Guide to Global Load Balancing Global Load Balancing and DNS How does Pulse vADC Global Load Balancing Work? An Insider's Guide to DNS and Global Load Balancing Deployment Guide Global Load Balancing with Parallel DNS   6. Even More to Explore:   The Unique Traffic Manager Architecture Traffic Manager is the core virtual application engine which makes it all possible - this Feature Brief gives a great insight into how it works. Pulse Traffic Manager Technical Architecture   Pulse vADC in Action There is so much more to discover on the Pulse Community - this page has gathered some of our favorite examples, including inserting RSS feeds into your web pages, embedding Google Maps, watermarking PDFs, optimizing application performance,  protecting your web applications from spiders and other security challenges. Enjoy! Top Pulse vADC Examples       ... View more

Installing and Upgrading Pulse vTM If you are looking to Install Pulse vTM, or to upgrade Pulse vTM or to the latest version, then we have created dedicated installation and configuration guides for each type of deployment option, as part of the complete documentation set for Pulse Secure Virtual Traffic Manager (vTM).   You can choose from a number of different deployment options, depending on whether you want to install vTM in a Docker container, as a virtual appliance, as a cloud service, on a bare-metal hardware appliance, or on a private server using a software installation.   Whether you are looking to install or upgrade your Pulse vTM instance, choose your target platform from the list here, and follow the link to the dedicated "Getting Started" guide: Upgrading your Pulse vTM instances? Each of the Getting Started Guides below includes a section on upgrading your instances to the latest version - refer to the guide in the sections below, depending on the platform type.   Pulse vTM in a Docker Container? Install Pulse vTM from Docker Hub - no need to register, giving quick, easy access for container and microservices deployment. For a detailed guide, see Pulse Virtual Traffic Manager: Docker Deployment Guide Pulse vTM as a Virtual Appliance? Looking to run a trial on Microsoft Hyper-V, VMware, Xen, QVM/KEMU, or Oracle VM? See Pulse Secure Virtual Traffic Manager 20.2: Virtual Appliance Installation and Getting Started Guide Pulse vTM in a Cloud? For information on installing in Google Cloud Platform, Amazon EC2, or Microsoft Azure, see Pulse Secure Virtual Traffic Manager 20.2: Cloud Services Installation and Getting Started Guide Pulse vTM on a Bare-Metal Hardware Appliance? To deploy the Pulse vTM appliance image on an approved server hardware platform, see Pulse Secure Virtual Traffic Manager 20.2: Appliance Image Installation and Getting Started Guide For hardware compatibility information, see the Pulse vTM Hardware Compatibility List. Pulse vTM installed as Software? If you are installing onto a private server, or inside a VM running Linux, see Pulse Secure Virtual Traffic Manager 20.2: Software Installation and Getting Started Guide   Note that these links are valid for the Pulse Secure vTM 20.1 software release. The most recent set of user documentation can always be found on https://www.pulsesecure.net/techpubs/ under the "Pulse vADC Solutions" section. This includes detailed configuration, REST API and TrafficScript programming guides.   (Copies of the "Getting Started" guides are attached to this article)   ... View more

SOA applications need just as much help as traditional web applications when it comes to reliability, performance and traffic management. This article provides four down-to-earth TrafficScript examples to show you how you can inspect the XML messages and manage SOA transactions.   Why is XML difficult?   SOA traffic generally uses the SOAP protocol, sending XML data over HTTP. It's not possible to reliably inspect or modify the XML data using simple tools like search-and-replace or regular expressions. In Computer Science terms, regular expressions match regular languages, whereas XML is a much more structured context-free language.   Instead of regular expressions, standards like XPath and XSLT are used to inspect and manipulate XML data. Using TrafficScript rules, Stingray can inspect the payload of an SOAP request or response and use XPath operations to extract data from it, making traffic management decisions on this basis. Stingray can check the validity of XML data, and use XSLT operations to transform the payload to a different dialect of XML.   The following four articles give examples of traffic inspection and management in an SOA application contect. Other examples of XML processing include embedding RSS data in an HTML document.   Routing SOAP traffic   Let’s say that the network is handling requests for a number of different SOAP methods. The traffic manager is the single access point – all SOAP traffic is directed to it. Behind the scenes, some of the methods have dedicated SOAP servers because they are particularly resource intensive; all other methods are handled by a common set of servers.   The following example uses Stingray's pools. A pool is a group of servers that provide the same service. Individual pools have been created for some SOA components, and a ‘SOAP-Common-Servers’ pool contains the nodes that host the common SOA components.   # Obtain the XML body of the SOAP request $request = http.getBody(); $namespace = "xmlns:SOAP-ENV=\"http://schemas.xmlsoap.org/soap/envelope/\""; $xpath = "/SOAP-ENV:Envelope/SOAP-ENV:Body/*[1]"; # Extract the SOAP method using an XPath expression $method = xml.XPath.matchNodeSet( $request, $namespace, $xpath ); # For ‘special’ SOAP methods, we have a dedicated pool of servers for each if( pool.getActiveNodes( "SOAP-".$method ) > 0 ) { pool.select( "SOAP-".$method ); } else { pool.select( "SOAP-Common-Servers" ); }   TrafficScript: Routing SOAP requests according to the method   Why is this useful?   This allows you to deploy SOA services in a very flexible manner. When a new instance of a service is added, you do not need to modify every caller that may invoke this service. Instead, you need only add the service endpoint to the relevant pool.   You can rapidly move a service from one server to another, for resourcing or security reasons (red zone, green zone), and an application can be easily built from services that are found in different locations.   Ensuring fair access to resources   With Stingray, you can also monitor the performance of each pool of servers to determine which SOAP methods are running the slowest. This can help troubleshoot performance problems and inform decisions to re-provision resources where they are needed the most.   You can shape traffic – bandwidth or transactions per second – to limit the resources used and smooth out flash floods of traffic. With the programmability, you can shape different types of traffic in different ways. For example, the following TrafficScript code sample extracts a ‘username’ node from the SOAP request. It then rate-shapes SOAP requests so that each remote source (identified by remote IP address and ‘username’ node value) can submit SOAP requests at a maximum of 60 times per minute:   # Obtain the source of the request $ip = request.getRemoteIP(); # Obtain the XML body of the SOAP request $request = http.getBody(); $namespace = "xmlns:SOAP-ENV=\"http://schemas.xmlsoap.org/soap/envelope/\""; $xpath = "/SOAP-ENV:Envelope/SOAP-ENV:Body/*/username/text()"; # Extract the username using an XPath expression $username = xml.XPath.matchNodeSet( $request, $namespace, $xpath ); # $key uniquely identifies this type of request from this source. $key = $ip . ", " . $username; # The 'transactions' rate shaping class limits each type to 60 per minute rate.use( "transactions", $key );   TrafficScript: Rate-shaping different users of SOAP traffic   Why is this important?   An SOA component may be used by multiple different SOA applications. Different applications may have different business priorities, so you might wish to prioritize some requests to a component over others. Applying ‘service governance’ policies using Stingray's rate shaping functionality ensures that all SOA applications get fair and appropriate access to critical components, and that no one application can overwhelm a component to the detriment of other applications.   This can be compared to time-sharing systems – each SOA application is a different ‘user’, and users can be granted specific access to resources, with individual limits where required.   When some SOA applications are externally accessible (via a web-based application for example), this is particularly important because a flash flood or malicious denial-of-service attack could ripple through, affecting many internal SOA components and internal applications.   Securing Traffic   Suppose that someone created a web services component for a travel company that enumerated all of the possible flights from one location to another on a particular day. The caller of the component could specify how many hops they were prepared to endure on the journey.   Unfortunately, once the component was deployed, a serious bug was found. If a caller asked for a journey with the same start and finish, the component got stuck in an infinite loop. If a caller asked for a journey with a large number of hops (1000 hops perhaps), the computation cost grew exponentially, creating a simple, effective denial of service attack.   Fixing the component is obviously the preferred solution, but it’s not always possible to do so in a timely fashion. Often, procedural barriers make it difficult to make changes to a live application. However, by controlling and manipulating the SOA requests as they travel over the network, you can very quickly roll out a security rule on your SDC to drop or modify the SOAP request. Here’s a snippet:   $request = http.getBody(); $from = xml.XPath.matchNodeSet( $request, $namespace, "//from/text()" ); $dest = xml.XPath.matchNodeSet( $request, $namespace, "//dest/text()" ); # The error response; can read a precanned response from disk and return # it as a SOAP response if( $from == $dest ) { $response = resource.get( "FlightPathFaultResponse.xml" ); connection.sendResponse( $response ); } $hops = xml.XPath.matchNodeSet( $request, $namespace, "//maxhops/text()" ); if( $hops > 3 ) { # Apply an XSLT that sets the hops node to 3 $transform = resource.get( "FlightPath3Hops.xslt" ); http.setBody( xml.XSLT.transform( $request, $transform ) ); }   TrafficScript: Checking validity of SOAP requests   Why is this important?   Using the Service Delivery Controller to manage and rewrite SOA traffic is a very rapid and lightweight alternative to rewriting SOA components.   Patching the application in this way may not be a permanent solution, although it’s often sufficient to resolve problems. The real benefit is that once a fault is detected, it can be resolved quickly, without requiring in-depth knowledge of the application. Development staff need not be pulled away from other projects immediately. A full application-level fix can wait until the staff and resources are available; for example, at the next planned update of the component code.   Validating SOAP responses   If a SOAP server encounters an error, it may still return a valid SOAP response with a ‘Fault’ element inside.   If you can look deep inside the SOAP response, you’ve got a great opportunity to work around such transient application errors. If a server returns a fault message where the faultcode indicates there was a problem with the server, wouldn’t it be great if you could retry the request against a different SOAP server in the cluster?   $response = http.getResponseBody(); $ns = "xmlns:SOAP-ENV=\"http://schemas.xmlsoap.org/soap/envelope/\""; $xpath = "/SOAP-ENV:Envelope/SOAP-ENV:Body/SOAP-ENV:Fault/faultcode/text()"; $faultcode = xml.XPath.matchNodeSet( $request, $namespace, $xpath ); if( string.endsWith( $faultcode, "Server" ) ) { if( request.retries() < 2 ) { request.avoidNode( connection.getNode() ); request.retry(); } }   TrafficScript: If we receive a Server fault code in the SOAP response, retry the request at most 2 times against different servers   Why is this important?   This particular example shows how the error checking used by an SDC can be greatly extended to detect a wide range of errors, even in responses that appear “correct” to less intelligent traffic managers.   It is one example of a wide range of applications where responses can be verified, scrubbed and filtered. Undesirable responses may include fault codes, sensitive information (like credit card or social security numbers), or even incorrectly-localized or formatted responses that may be entirely legitimate, but cannot be interpreted by the calling application.   Pinpointing errors in a loosely-coupled SOA application is a difficult and invasive process, often involving the equivalent of adding ‘printf’ debug statements to the code of individual components. By inspecting responses at the network, it becomes much easier to investigate and diagnose application problems and then work round them, either by retrying requests or transforming and rewriting responses as outlined in the previous example. ... View more

The TrafficScript function http.changeSite() makes it easy to redirect clients from one domain to another.  You can also use it to reliably redirect clients from http to https (or https to http), or from one document tree on a website (e.g. /products) to another (e.g /sales).   # Example: Redirect client from www.site.com to www.site.co.uk if( geo.getCountryCode( request.getRemoteIP() ) == "GB" ) { http.changeSite( "www.site.co.uk" ); } # Example: Force client to https (assuming this rule is attached to an HTTP virtual server) http.changeSite( "https://" . http.getHostHeader() ); # Example: move client from one tree to another $path = http.getPath(); if( string.startsWith( $path, "/products" ) ) http.changeSite( http.getHostHeader(). "/sales" );   For more fine-grained control of HTTP redirects, you can also use the http.redirect() function.   Read More   Collected Tech Tips: TrafficScript examples ... View more

  Introduction   Many DDoS attacks work by exhausting the resources available to a website for handling new connections.  In most cases, the tool used to generate this traffic has the ability to make HTTP requests and follow HTTP redirect messages, but lacks the sophistication to store cookies.  As such, one of the most effective ways of combatting DDoS attacks is to drop connections from clients that don't store cookies during a redirect.   Before you Proceed   It's important to point out that using the solution herein may prevent at least the following legitimate uses of your website (and possibly others):   Visits by user-agents that do not support cookies, or where cookies are disabled for any reason (such as privacy); some people may think that your website has gone down! Visits by internet search engine web-crawlers; this will prevent new content on your website from appearing in search results! If either of the above items concern you, I would suggest seeking advice (either from the community, or through your technical support channels).   Solution Planning   Implementing a solution in pure TrafficScript will prevent traffic from reaching the web servers.  But, attackers are still free to consume connection-handling resources on the traffic manager.  To make the solution more robust, we can use iptables to block traffic a bit earlier in the network stack.  This solution presents us with a couple of challenges:   TrafficScript cannot execute shell commands, so how do we add rules to iptables? Assuming we don't want to permanently block all IP addresses that are involved in a DDoS attack, how can we expire the rules?   Even though TrafficScript cannot directly run shell commands, the Event Handling system can.  We can use the event.emit() TrafficScript function to send jobs to a custom event handler shell script that will add an iptables rule that blocks the offending IP address. To expire each rule can use the at command to schedule a job that removes it.  This means that we hand over the scheduling and running of that job over to the control of the OS (which is something that it was designed to do).   The overall plans looks like this:   Write a TrafficScript rule that emits a custom event when it detects a client that doesn't support cookies and redirects Write a shell script that takes as its input: an --eventtype argument (the event handler includes this automatically) a --duration argument (to define the length of time that an IP address stays blocked for) a string of information that includes the IP address that is to be blocked Create an event handler for the events that our TrafficScript is going to emit TrafficScript   Code 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 33 $cookie = http.getCookie( "DDoS-Test" );   if ( ! $cookie ) {              # Either it's the visitor's first time to the site, or they don't support cookies      $test = http.getFormParam( "cookie-test" );              if ( $test != "1" ) {         # It's their first time.  Set the cookie, redirect to the same page         # and add a query parameter so we know they have been redirected.         # Note: if they supplied a query string or used a POST,         # we'll respond with a bare redirect         $path = http.getPath();                    http.sendResponse( "302 Found" , "text/plain" , "" ,            "Location: " . string.escape( $path ) .            "?cookie-test=1\r\nSet-Cookie: DDoS-Test=1" );                 } else {                    # We've redirected them and attempted to set the cookie, but they have not         # accepted.  Either they don't support cookies, or (more likely) they are a bot.                    # Emit the custom event that will trigger the firewall script.         event.emit( "firewall" , request.getremoteip());                    # Pause the connection for 100 ms to give the firewall time to catch up.         # Note: This may need tuning.         connection. sleep ( 100 );                    # Close the connection.         connection. close ( "HTTP/1.1 200 OK\n" );       }  }  Installation   This code will need to be applied to the virtual server as a request rule.  To do that, take the following steps:   In the traffic manager GUI, navigate to Catalogs → Rule Enter ts-firewaller in the Name field Click the Use TrafficScript radio button Click the Create Rule button Paste the code from the attached ts-firewaller.rts file Click the Save button Navigate to the Virtual Server that you want to protect ( Services → <Service Name> ) Click the Rules link In the Request Rules section, select ts-firewaller from the drop-down box Click the Add Rule button   Your virtual server should now be configured to execute the rule.   Shell Script   Code   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 #!/bin/bash       # Use getopt to collect parameters.  params=`getopt -o e:,d: -l eventtype:,duration: -- "[email protected]" `       # Evaluate the set of parameters.  eval set -- "$params"   while true; do           case "$1" in     --duration ) DURATION= "$2" ; shift 2 ;;     --eventtype ) EVENTTYPE= "$2" ; shift 2 ;;     -- ) shift ; break ;;     * ) break ;;     esac  done       # Awk the IP address out of ARGV  IP=$(echo "${BASH_ARGV}" | awk ' { print ( $(NF) ) }' )       # Add a new rule to the INPUT chain.  iptables -A INPUT -s ${IP} -j DROP &&       # Queue a new job to delete the rule after DURATION minutes.  # Prevents warning about executing the command using /bin/sh from  # going in the traffic manager event log.  echo "iptables -D INPUT -s ${IP} -j DROP" |  at -M now + ${DURATION} minutes &> /dev/null  Installation   To use this script as an action program, you'll need to upload it via the GUI.  To do that, take the following steps:   Open a new file with the editor of your choice (depends on what OS you're using) Copy and paste the script code into the editor Save the file as ts-firewaller.sh In the traffic manager UI, navigate to Catalogs → Extra Files → Action Programs Click the Choose File button Select the ts-firewaller.sh file that you just created Click the Upload Program button Event Handler   Now that we have a rule that emits a custom event, and a script that we can use as an action program, we can configure the event handler that will tie the two together. First, we need to create a new event type:   In the traffic manager's UI, navigate to System → Alerting Click the Manage Event Types button Enter Firewall in the Name field Click the Add Event Type button Click the + next to the Custom Events item in the event tree Click the Some custom events... radio button Enter firewall in the empty field Click the Update button   Now that we have an event type, we need to create a new action:   In the traffic manager UI, navigate to System → Alerting Click on the Manage Actions button In the Create New Action section, enter firewall in the Name field Click the Program radio button Click the Add Action button In the Program Arguments section, enter duration in the Name field Enter Determines the length of time in minutes that an IP will be blocked for in the Description field Click the Update button Enter 10 in the newly-appeared arg!duration field Click the Update button   Now that we have an action configured, the only thing that we have left to do is to connect the custom event to the new action:   In the traffic manager UI, navigate to System → Alerting In the Event Type column, select firewall from the drop-down box In the Actions column, select firewall from the drop-down box Click the Update button That concludes the installation steps; this solution should now be live!   Testing   Testing the functionality is pretty simple for this solution. Basically, you can monitor the state of iptables while you run specific commands from a command line.  To do this, ssh into your traffic manager and execute iptables -L as root.  You should check this after tech of the upcoming tests.   Since I'm using a Linux machine for testing, I'm going to use the curl command to send crafted requests to my traffic manager.  The 3 scenarios that I want to test are:   Initial visit: The user-agent is missing a query string and a cookie Successful second visit: The user-agent has a query string and has provided the correct cookie Failed second visit: The user ages has a query string (indicating that they were redirected), but hasn't provided a cookie The respective curl commands that need to be run are:   1 2 3 curl -v http:///  curl -v http:///?cookie-test=1 -b "DDoS-Test=1"   curl -v http:///?cookie-test=1    Note: If you run these commands from your workstation, you will be unable to connect to the traffic manager in any way for a period of 10 minutes! ... View more

In DOD, many times implementing Web App Firewalls is limited by form-factor, mutual TLS encryption, end-to-end authentication, Security Assertion Markup Language (SAML), etc.  Not to mention the various web servers (IIS, Apache, Tomcat, etc) running in DOD. This makes it difficult to implement a global web application security strategy, especially when many are appliance-based and require you to break or modify your end-to-end TLS encryption and CAC authentication.  However, DISA's AppSec STIGs, and other Federal & Industry Policies, require web application security be in place for this dangerous and rapidly growing attack vector.   With Brocade's SteelApp Distributed WAF (dWAF), which is software-based, these limitations are easily addressed.  SteelApp dWAF is implemented as a module in IIS, Apache, Tomcat and other web servers.  It conducts web app security on the web traffic AFTER it has been authenticated, authorized and decrypted by the web server.  This ensures your existing and robust end-to-end authentication and authorization isn't broken along the path, exposing other security risks.  This approach also ensures horizontal & elastic scalability for massive application workloads - whether in private clouds, public clouds, or tiny tactical solutions. If a unique requirement isn't present in SteelApp dWAF don't worry, it can be extended via Python scripts, or interact with third-party systems via its REST API and other means.   These capabilities make SteelApp dWAF a great option for Government Furnished Software (GFS) for DOD web application projects. By furnishing SteelApp dWAF to contractors the US Government can increase their global control over web application security policies, reduce variability in quality in web app security across projects, and save money by offloading some of the responsibility from contractors (who aren't specialized in web app sec). A recent example, of where DOD could have leveraged this is with the ShellShock vulnerability. SteelApp dWAF had a virtual patch published to block this attack over HTTP(S), which if centrally implemented would have enabled DOD to block these attacks across protected servers - no matter where they were at in the world.   For DOD contracts, using SteelApp dWAF ensures you can deliver a standardized, repeatable and low-cost web application security capability across many projects with various types of servers (IIS, Apache, Tomcat, etc), whether they are in private clouds, public clouds or tactically deployed to the edge of the battle-space.   This cutting edge web security approach ensures consistency in policy, delivers agile global web app security capabilities without the limitations of appliances or virtual machines, saves money on application development costs and reduces administration overhead costs.   SteelApp dWAF has been successfully used in some of the largest commercial cloud applications in the world where hundreds or even thousands of active dWAFs are centrally managed by small, agile teams leveraging the power of automation, orchestration, elasticity and horizontal scale. It enables them to spin up new servers in real-time and at second #1 have robust web application security to keep the bad guys out.   The attached white paper dives into the technical details and operational requirements of doing enterprise-scale web application security in DOD - anywhere, anytime. ... View more

Since this previous article /t5/SteelApp-Docs/Disabling-SSL-v3-0-for-SteelApp/ta-p/73982, security researchers have determined that TLS 1.x, including TLS 1.2, may also be vulnerable to POODLE-type attacks if an incorrect padding check is used. However, SteelApp is not vulnerable to this latest issue (CVE 2014-8730), because its TLS stack performs the complete padding checks required by TLS.   The original POODLE vulnerability only applies to SSLv3 (ProtocolVersion.major = 3 and ProtocolVersion.minor = 0 in the ClientHello and ServerHello) and is a protocol-level weakness.  It therefore affects all implementations of SSLv3, including that of SteelApp traffic manager.   POODLE 2.0 is not a protocol-level weakness, but a bug in certain TLSv1.0 - TLSv1.2 (ProtocolVersion.major = 3 and ProtocolVersion.minor = 1,2,3) implementations.  SteelApp traffic manager's TLS implementation does all the proper checks in all TLS versions (1.0 - 1.2) and is therefore not affected by POODLE 2.0.   More details on POODLE and TLS 1.2 here: https://www.imperialviolet.org/2014/12/08/poodleagain.html ... View more