EMEA BBT F5 V9 Report - Broadband Testing · First published September 2004 (V1.0) Published by Broadband-Testing La Calade, 11700 Moux, Aude, France Tel : +33 (0)4 68 43 99 70 Fax

F5 Networks V9 Report

A Broadband-Testing Report

First published September 2004 (V1.0)

Published by Broadband-Testing La Calade, 11700 Moux, Aude, France Tel : +33 (0)4 68 43 99 70 Fax : +33 (0)4 68 43 99 71 E-mail : [email protected] Internet : http://www.broadband-testing.co.uk 2004 Broadband-Testing All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the authors. Please note that access to or use of this Report is conditioned on the following: 1. The information in this Report is subject to change by Broadband-Testing without notice. 2. The information in this Report, at publication date, is believed by Broadband-Testing to be accurate and reliable, but is not guaranteed. All use

of and reliance on this Report are at your sole risk. Broadband-Testing is not liable or responsible for any damages, losses or expenses arising from any error or omission in this Report.

3. NO WARRANTIES, EXPRESS OR IMPLIED ARE GIVEN BY Broadband-Testing. ALL IMPLIED WARRANTIES, INCLUDING IMPLIED

WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT ARE DISCLAIMED AND EXCLUDED BY Broadband-Testing. IN NO EVENT SHALL Broadband-Testing BE LIABLE FOR ANY CONSEQUENTIAL, INCIDENTAL OR INDIRECT DAMAGES, OR FOR ANY LOSS OF PROFIT, REVENUE, DATA, COMPUTER PROGRAMS, OR OTHER ASSETS, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.

4. This Report does not constitute an endorsement, recommendation or guarantee of any of the products (hardware or software) tested or the

hardware and software used in testing the products. The testing does not guarantee that there are no errors or defects in the products, or that the products will meet your expectations, requirements, needs or specifications, or that they will operate without interruption.

5. This Report does not imply any endorsement, sponsorship, affiliation or verification by or with any companies mentioned in this report. 6. All trademarks, service marks, and trade names used in this Report are the trademarks, service marks, and trade names of their respective

owners, and no endorsement of, sponsorship of, affiliation with, or involvement in, any of the testing, this Report or Broadband-Testing is implied, nor should it be inferred.

TABLE OF CONTENTS

INTRODUCTION .................................................................................................................. 1 Networking Reinvented ........................................................................................... 1

V9 – FEATURES AND FUNCTIONALITY – WHAT’S IMPORTANT AND WHAT’S NEW 3 V9: Performance And Traffic Control Features Overview....................................... 5

The Universal Inspection Engine (UIE) and iRules .................................... 5 iControl ....................................................................................................... 5 Looking To The Future ............................................................................... 6 TCP Optimisation - OneConnect................................................................ 7 Health Monitoring ....................................................................................... 8 Compression .............................................................................................. 9 Rate Shaping............................................................................................ 10 Content Spooling Buffering....................................................................... 10 IPv6 Gateway ........................................................................................... 10 Response Error Handling ......................................................................... 11

Security Features Overview .................................................................................. 11 SSL Bulk Encryption Acceleration............................................................ 11 Protocol Sanitization................................................................................. 12 Intelligent SNAT........................................................................................ 12 Resource Cloaking ................................................................................... 12 Advanced Client Authentication ............................................................... 13 Selective Content Encryption ................................................................... 13 Cookie Encryption And Authentication ..................................................... 14 Content Protection.................................................................................... 14 Load Balancing......................................................................................... 15

Fault Tolerance...................................................................................................... 16 Persistence............................................................................................................ 17 Configuring and Managing The BIG-IP With V9.................................................... 18

PUTTING IT TO THE TEST –V9 FUNCTIONALITY TESTED AT LAYER 7 .................... 19 Test Overview........................................................................................................ 19 Functionality Tests................................................................................................. 20 Analysis ................................................................................................................. 26

OVERALL SUMMARY....................................................................................................... 35

APPENDIX A: V9 - WHAT’S IMPORTANT, WHAT’S CLASS-LEADING – IN SUMMARY36

APPENDIX B: SPIRENT WEBAVALANCHE AND WEBREFLECTOR WEB TRAFFIC GENERATORS .................................................................................................................. 38 TABLE OF FIGURES Figure 1 – F5 BIG-IP V9 UIE .............................................................................................................................................................................................. 5 Figure 2 – How iControl Works........................................................................................................................................................................................... 6 Figure 3 – BIG-IP Enabling Traffic Control Between Any Client Or Application Server Types ........................................................................................... 7 Figure 4 – The New V9 GUI ............................................................................................................................................................................................. 18 Figure 5 – LCD Status And Management Screen ............................................................................................................................................................ 19 Figure 6 – V9 GUI - Redlining Stats ................................................................................................................................................................................. 21 Figure 7 – Cisco CSM “GUI”............................................................................................................................................................................................. 22 Figure 8 – Rate Shaping with the BIG-IP system ............................................................................................................................................................. 24 Figure 9 – iControl SOAP/XML Interface Test.................................................................................................................................................................. 25 Figure 10 – V9 GUI – Main Configuration Screen ............................................................................................................................................................ 26 Figure 11 – UIE iRules Windows Messenger Login Test ................................................................................................................................................. 29 Figure 12 – iRules redirecting An Error Code Web Page ................................................................................................................................................. 30 Figure 13 – Cloaked Headers Test –Before The iRule..................................................................................................................................................... 30 Figure 14 – Cloaked Headers Test –After The iRule – No Header Info ........................................................................................................................... 31 Figure 15 – iRule Used For Compression Policy Test ...................................................................................................................................................... 32 Figure 16 –Content Spooling............................................................................................................................................................................................ 33 Figure 17 – Spirent WebAvalanche 2500......................................................................................................................................................................... 38 Figure 18 – Creating A WebAvalanche Test .................................................................................................................................................................... 39

Broadband-Testing Broadband-Testing is Europe’s foremost independent network testing facility and consultancy organisation for broadband and network infrastructure products. Based in the south of France, Broadband-Testing offers extensive labs, demo and conference facilities. From this base, Broadband-Testing provides a range of specialist IT, networking and development services to vendors and end-user organisations throughout Europe, SEAP and the United States. Broadband-Testing is an associate of the following: • NSS Network Testing Laboratories (specialising in security product testing) • Broadband Vantage (broadband consultancy group) • Limbo Creatives (bespoke software development) Broadband-Testing Laboratories are available to vendors and end-users for fully independent testing of networking, communications and security hardware and software. Broadband-Testing Laboratories operates an Approval scheme which enables products to be short-listed for purchase by end-users, based on their successful approval. Output from the labs, including detailed research reports, articles and white papers on the latest network-related technologies, are made available free of charge on our web site at http://www.broadband-testing.co.uk The conference centre in Moux in the south of France is the ideal location for sales training, general seminars and product launches, and Broadband-Testing can also provide technical writing services for sales, marketing and technical documentation, as well as documentation and test-house facilities for product development. Broadband-Testing Consultancy Services offers a range of network consultancy services including network design, strategy planning, Internet connectivity and product development assistance.

Broadband-Testing F5 BIG-IP 2400 Layer 7 Test

Page 1

INTRODUCTION

Networking Reinvented There’s a commonly agreed rule about the progress of networking and that rule is that “Ethernet always wins”. Well, to date at least, that is perfectly true and for one, simple reason – Ethernet itself is a relatively simple technology. For this reason it is set to dominate at the “plumbing” level of networking for the foreseeable future. But, the way that plumbing is controlled is set to change significantly. We’ve all seen those slides at network vendor presentations, depicting the history of networking. They start with the birth of Ethernet and move through routing and switching, 10-Megabit to 100-Megabit (Fast) to Gigabit, then 10-Gig, ending with 40-Gig and a question mark – where next? The answer is usually some other quoted number – 100-Gigabit, for example. But the real answer is, forget the bandwidth progression, the real change is here with us now and that is adding real networking intelligence at Layer 7. So, you say, what’s new about Layer 7 switching – it’s been around for a few years, hasn’t it? Well yes it has, but only now are we starting to see what can be truly described as a genuine revolution in the way networking traffic can be, and is being, managed; something as fundamental a change as routing was when it was first introduced. For a moment forget hardware – forget port density, backplane switch fabrics, 40-Gig backbones and the like. Yes, they are all important elements of a network, now and into the future, but they will never resolve the kind of problems that have been around since the first network was put into place; namely that the network traffic – the application data – is, whatever the ISVs say – not network aware, not network friendly, quite simply not designed to run on networks. Many years ago, we wrote about early ATM deployment and argued that if the applications were not completely re-developed to take advantage of ATM’s native features, then that technology would simply die. And we all know what happened to ATM… The reality is that, even with Ethernet, enterprise applications work on a contrived, “best effort” basis across the ‘net. The result is less than ideal performance, to be polite. If these applications were really network and Internet friendly, then why is there such a huge market for enterprise software acceleration products? Now, here’s where it gets interesting. Over the past couple of years, a number of players have arrived on the Layer 7 traffic management scene, some concentrating almost exclusively on this very application, typically to increase performance of these mammoth applications over the Internet, through data compression primarily. But this still only solves one other issue. What is really, really required is the need to be able to manipulate any application data at Layer 7 and talk directly to the applications and network services, notably the web services that are now becoming prevalent. In this way the applications do become network aware, network friendly. Now we are talking about a revolutionary change in networking; suddenly networking becomes a software technology, not one with a limited lifespan courtesy of embedding technology into a series of ASICs alone. Remember how the router market went in the ‘90’s? First it was in software, then hardware, then software, then hardware, depending on the progression and state of chip technology?


Page 2

Well now the decision is made, the die is cast – the future of networking is in software. Which means that it does not head-butt performance limits every time an ASIC reaches the end of its natural life. Which means that there are no physical limits to what you can do and where you can go. It creates a truly ubiquitous development platform which allows the network to be changed and developed constantly, without the same kind of impact there is now when making physical adds and changes. Yes, for sure, we will still need to have and to add tin – to add bandwidth, ports, routes – but these are simple extensions of the network logic, roads without speed limits or other traffic rules; instead the intelligent network takes these additions and manages them directly, in association with the applications and services running over them. If networking is one giant, near infinite, rule-based, development environment, talking directly to hardware and applications simultaneously, then we finally have our intelligent network that people have been hyping – largely without substance – for years, And we have our first genuine advancement since routing was introduced. Welcome to the future of networking….

The Aims Of This Report Within the scope of this report we’re looking to test the features and functionality of F5 Networks’ V9 release, by creating a series of tests that were both diverse and extremely challenging. All are based around real-world scenarios, real applications and real data. So the results really do mean something to the network manager or anyone who has to deal with the problems of traffic management on a daily basis. F5 has taken the approach that intelligence and total networking - applications/service integration - is the way forward, so we’ve been putting it to the test in our labs. Broadband-Testing has also verified some internal testing that F5 has carried out exhaustively, on the features and functionality of some of their competitors’ products, as part of a project that ran for thousands of man hours. After all, we’re talking here about the future of networking – not something that can be taken lightly. That’s not us being glib – simply stating the truth. Anyone wishing to follow up on any aspects of the report with the author, is welcome to contact me by email at [email protected]


Page 3

V9 – FEATURES AND FUNCTIONALITY – WHAT’S IMPORTANT AND WHAT’S NEW

When F5 originally launched its BIG-IP product, it was conceptually a simple, gateway-esque, “in one end out the other” approach to managing Internet traffic and load-balancing devices such as servers, VPN gateways and firewalls. More Layer 4 than Layer 7 in reality. Since then, the company has broadened its BIG-IP product range into, first switches, and now a complete, ground-up redevelopment, resulting in V9 – a true Layer 7 architecture for handling all aspects of bi-directional traffic flows across the network and out onto the Internet and back. The V9 code is initially being made available across a range of three hardware platforms, the 1500, the 3400 and the 6400, though it is also backwards compatible on a subset of existing F5 products which can be upgraded to the new release.

The BIG-IP V9 Product Options The V9 code is common across all the new BIG-IP products, as are a number of new features such as an integrated LCD display and keypad and true lights out management via a dedicated management port (see later). At the entry level is the 1500, a four-port (copper Gigabit) device, with two optional fibre Gigabit ports, hard disk and 1 PCI add-in card slot. The 3400 is the same 1U format as the 1500 but doubles up on copper port density with eight, plus the same optional fibre ports. It adds a Compact Flash drive to the hard disk, for improved logging, and uses a packet velocity ASIC to improve performance. The initial top of the range product is the 6400 – extending on all that the 3400 has, as a 2U unit with dual processors, 16 copper Gigabit, two fibre Gigabit (plus two optional) ports, a field accessible Compact Flash and hard disk, more internal expansion options, plus hot-swappable redundant PSUs and fans. With the 6400, F5 is looking to significantly exceed existing performance limitations of Layer 7 products, aiming to deliver up to 220,000 Layer 4 requests per second, 50,000 Layer 7 requests per second, and in excess of 15,000 SSL transactions per second, while supporting up to eight million concurrent connections. These performance claims will be put to the test in a follow on report. Watch this space…


Page 4

The recipe for V9 has been to keep the key components of previous generations of product, add in some new features – many of which have come from customer requests – and really expand on the functionality that made the F5 products interesting in the first place, notably in the areas of iRules and iControl, the “brains” of the system in other words. In terms of the basic methodology – creating virtual servers (VIPs) to front pools of real servers and then apply load-balancing at Layer 4 and traffic management rules at Layer 7 – anyone familiar with the F5 way need not worry. It’s simply that everything has been improved. Even the management - which has always been class-leading, as we’ve documented before in reports - has been completely revamped, with a new interface required in order to enable all the new features to be controlled from the GUI – a real F5 speciality this and a good one – as we’ll see later.

How A BIG-IP Product Works: The Basics One of the big aspects of F5’s architecture is the relative simplicity of it, one which has been mirrored by most vendors who have come onto the Layer 7 scene more recently. Basically, you create a virtual IP address to front a specific application or scenario. Behind this IP address you typically have a pool of servers, or other networking devices, such as caches or firewalls, which you control access to and from, using either a simple load-balancing function, and/or a set of rules. And that, in essence, is a typical, basic configuration. In practice, of course, a full deployment will consist of 10s or 100s of device pools, fronted by different VIPs, enabling multiple different applications and services to be run simultaneously across a BIG-IP. The real benefit of having such a simple, basic logic to a configuration, is that it is then very easy to add lots of extra functionality – intelligence – to this setup. With V9, F5 has added the concept of profiles – see later – which enable templates to be created for very fast deployment of new services, with a minimum of tweaking required each time. Also, the company has improved its iControl interface – again see later – to make it easier than ever to talk to the outside world from within a BIG-IP configuration. Best yet, however, is the improvement in the products iRules capabilities, to the extent that it is feasible to actually control the entire network, including the BIG-IPs themselves, from this integrated programming interface. Simple on the surface, very powerful beneath – that’s the way F5 has approached the art of networking. And it works.


Page 5

V9: Performance And Traffic Control Features Overview

The Universal Inspection Engine (UIE) and iRules F5 introduced the UIE in the previous generation of BIG-IP products and has significantly enhanced its capabilities this time around. While initially F5’s approach was more packet inspection based, now it is a full, two-way, flow-based engine – isolating client from server-side flows - which can manage a two way conversation and translate fully between parties on both sides. This means that, whatever the client and server/network device combination that are in conversation, the traffic flow can be optimised for those specific end nodes. It is akin to the difference between a network monitor/analyser that listens to just one way conversations – not very useful - compared to one that listen to two-way conversations. Moreover, it pro-actively makes traffic decisions based on the nature of that end node – bandwidth availability, application/service usage etc, so it is truly intelligent.

Figure 1 – F5 BIG-IP V9 UIE

In order to take advantage of the UIE, F5 created what can best be described as a simplified, integrated programming language called iRules, for defining the application traffic that administrators wish to direct, filter, or persist on. Again, F5 has significantly expanded the iRule syntax set, so give it a near infinite ability to examine chunks of network data, such as TCP, UDP, or HTTP payloads and make traffic management decisions based on these examinations. So, individual iRules can be defined to optimise the handling of traffic - where and when to send it for the fastest response based on application type, category, and priority, for example – and used by any of the VIPs created as part of the BIG-IP configuration. Multiple iRules can be used in tandem even. Indeed, F5 appears to be heading in the direction where every aspect of the BIG-IP, its configuration and its traffic handling and decision-making, is simply a set of iRules. This is truly intelligent networking - again.

iControl Where the story gets even better is when iRules are combined with iControl, an open Application Programming Interface based on SOAP/XML with controls that can be extended to third-party network elements – see later for examples. With iControl, a network flow can be tuned, based upon the application or service conditions, helping to automate communications


Page 6

between 3rd party applications and the BIG-IP system, eliminating the need for manual intervention. Using it, F5 networking device features and functionality are programmatically accessible to virtually any application. There are situations when web based applications are optimal for distributed management, but web interfaces have limitations and are most optimally run with the least amount of client side code as possible. iControl can simplify development of these types of applications. Originally developed with a CORBA interface but now redeveloped completely to support .Net and Java frameworks as well, iControl has been designed to allow the developer to use their own choice of tools. For example, F5 is the only networking company to offer complete interface support for Microsoft .NET, currently making the company a key partner for supporting Web services based on Microsoft enterprise technologies.

Figure 2 – How iControl Works

F5 exposes its traffic management methods to external sources via iControl. Invoking these functions are accomplished using SOAP/XML as specified in the F5 iControl SDK (Software Development Kit). F5 ships this for free, which provides instructions for using the API (1,600+ methods) with complete WSDL support and including integration with leading Microsoft, BEA, and Oracle development tools to speed application creation. So, for example an “instruction” might be to set an iRule while the “response” would be to load an iRule. Or an instruction might be to set a load-balancing method and the response would be to – say – set round robin mode. To further help developers, extensive Sample application code and documentation is provided, enhanced by the DevCentral developer program, with a complete website dedicated to what is now a true iControl community. Anything that can be done from an F5 device can now be accomplished programmatically through iControl. More importantly, programmatic use of iControl can be streamlined via use of Visual Studio .NET, which just happens to be the most widely used development environment in the world currently. So, with iControl you can perform nearly all F5 product GUI/CLI functions programmatically from any external application. Its API enables network devices to appear like software to other applications for true, software-native integration with integrated support for SOAP/XML over HTTPS, which adds a secure element to what is already fast and convenient.

Looking To The Future Where the story more interesting again is when you look at networking applications being developed directly in conjunction with the Layer 7 devices – and there are radical takes on enterprise software emerging which are perfect for this scenario, such as The Thingamy from www.thingamy.com - and this kind of integration is only possible because the networking device is basically software.


Page 7

In this case a combination of F5’s iRules – essentially a programming language – and iControl, an open interface to the F5 devices supporting all the major development frameworks such as .Net and Java, means that you can literally program networking. So a network flow can be tuned, based upon the application or service conditions, helping to automate communications between 3rd party applications and the F5 system, eliminating the need for manual intervention. One example would be to communicate via a SOAP/XML interface. In this way the Layer 7 device completely manages every application on the network. This is real network management in the true sense of the phrase. Another key point to make here is that – given that few people can realistically and accurately predict what will happen over the next 10 years at the client end of the network, with this new approach to networking, the client type is irrelevant – all can be supported. This means that applications can be developed now which you won’t have to simply ditch in a few years time, but which can adapt to the nature of the user network around them.

Figure 3 – BIG-IP Enabling Traffic Control Between Any Client Or Application Server Types

TCP Optimisation - OneConnect In order to reduce the TCP overhead on networks, F5 developed what it calls OneConnect. This is a connection aggregation technology designed to solve latency, bandwidth, and server/network problems by consolidating and maintaining a single TCP connection for HTTP traffic between the user and the web system - regardless of the number and type of requests being made.

CRM CRM

SFA

ERP

ERP

ERP

SFA CRM

SFA

The F5 Solution Applications Users

Customise Application

Mobile Phone

PDA

Laptop

Desktop

Co-location

The BIG-IP


Page 8

OneConnect lowers the overhead on the user and server by minimising the number of TCP sessions that need to be opened and closed for each object being requested. In doing so it minimises the number of network round-trips needed for user/server interaction, thereby reducing bandwidth costs because TCP connections over the network are reduced, at the same time increasing the capacity of back-end servers for other tasks. In practice, then, OneConnect optimises resources by attempting to serve many HTTP requests with the fewest number of open connections to the server, taking millions of client connections and consolidate them down to a few hundred server side connections, so reducing server load. This technology has been further enhanced in V9 by adding the ability for the BIG-IP system to transform HTTP/1.0 to HTTP/1.1. In addition to HTTP support, F5 has also implemented universal connection pooling to offload TCP handling from the back-end servers and applications, further increasing server capacity.

OneConnect In A Content Switching Scenario In a content switching scenario, OneConnect enables BIG-IP to individually handle each request within the same connection and direct them to different back-end servers. In V9, content switching on a per-request basis is always supported. OneConnect can also be used to encourage server-side connections to remain open when clients are using HTTP 1.0, or communications that typically do not allow for server-side connection pooling. This is valuable because the BIG-IP attempts to maintain the server benefits of connection pooling, reducing TCP overhead, even when clients are incompatible. .

Health Monitoring One of the real standout features of BIG-IP has always been its monitoring capabilities. These are effectively a collection of predefined scripts for testing the health and availability of the servers and applications that comprise your web system, given that applications and servers of any kind can and do fail. So, for example, you can use the health monitors to check if a server is responding to WEB, FTP, LDAP, or other requests - or to verify that an application (web, database, credit card verification, etc.) is operating properly before sending traffic to that server. With V9, a number of new monitors have been added, including: Service Based Monitoring This enables BIG-IP to monitor shared services effectively. By monitoring a particular service on a server, if one service fails, the other services on that server will remain available. Another important use is for performance monitoring. Performance monitors such as WMI do not report the health of their target system, they simply compute a metric for dynamic ratio load balancing and always report as being “up”. With this feature the WMI monitor would be assigned to get metrics from the server, while the BIG-IP HTTP monitor could assert its actual health. It also supports effective server consolidation. Shared services can be independently monitored and disabled so as not to bring the entire server down when only one service


Page 9

fails. So, other applications can continue to use a server even when a single service or application has failed. DB monitors - Oracle and MYSQL Monitors Often database failures are caused by manual errors, as administrators or automated processes might omit valid data tables. Similarly, a device might be available but the database table itself is corrupted. These content failures can be a source or downtime and are difficult to detect because all systems look as if they are responding. So these monitors allow for users to send an SQL statement to be executed and then receive the value back to mark the resource as being up or down. The monitor allows for the use of any SQL statement to test availability of the database and back-end table.

SOAP Monitor This monitor can test a SOAP-based Web service. It will submit a request to a given Web Service and, optionally, verify a return value or fault.

Monitor as a Pool Attribute The new generation of Web servers allows several processes to exist at the same IP address and port. So BIG-IP can service check each process individually. For example, all members of a pool can be associated with a monitor by listing the monitor as a pool attribute. This is similar in practice to specifying the persistence method for a pool. Each member of the pool is then associated with the monitor. When a member is added to a pool, it inherits the pool’s monitor. When a member of the pool is deleted, it is no longer monitored. In addition, it is possible to associate a monitor with a specific pool member, so a monitor rule may apply to the pool as a whole, but a different monitor rule may be applied to an individual member.

Service-Based Monitoring Put Into Practice – Performance Monitoring Performance monitors such as WMI do not report the health of their target system; they simply compute a metric for dynamic ratio load balancing and always report as being “up”. With this feature, the WMI monitor would be assigned to get metrics from the server, while the BIG-IP HTTP monitor could assert its actual health. It also supports effective server consolidation. Shared services can be independently monitored and disabled so as not to bring the entire server down when only one service fails. So other applications can continue to use a server even when a single service or application has failed.

Compression One feature that was missing from the BIG-IP until now is compression. This has now been added in a format where you pay for the level of compression you want. More importantly, the compression is completely configurable, so it not simply a case of all on or all off, regardless of the benefit. This is especially important when you have a wide range of users from very low bandwidth client connections to very high bandwidth. Similarly, a wide range of traffic types will benefit. For example, compression can be applied towards URI/URLs, MIME, Layer 7 rules, JAVA Script and Client Aware (RTT/MS) targets. F5 claims up to three times improvement in application performance and up to 80% bandwidth savings.


Page 10

Rate Shaping Another new feature to V9, Rate Shaping allows for traffic limiting, prioritisation and borrowing, for maintaining enough bandwidth and fast service for high priority applications and traffic. BIG-IP users can define traffic and application limits, control the rate at which those resources are allowed to spike or burst, provide queuing to prioritise traffic types, and define relationships where certain traffic types can borrow from other traffic types. It is configured by defining Rate Classes, which specify the bandwidth limitations to be enforced, and then applying those Rate Classes to selected traffic patterns. It can be used to limit the flow of traffic in one direction and may be utilised within a packet filter (device or VLAN specific), within a virtual server (a specific pool or set of nodes), or within an iRule (using any classification/event that is supported in an iRule). So, Rate Shaping can be used to shape traffic/bandwidth usage on a shared link or network segment or to shape traffic destined for a pool of servers. Rate-shaping is especially useful for controlling the behaviour of traffic on lower-bandwidth WAN links, since it can be enabled on a per-application, per-protocol and per-user basis to help determine what’s actually on the network and how it is behaving and affecting other traffic. Based on this information, administrators can classify, queue, shape, and rate-control traffic with policies to give better application response time for priority traffic, by eliminating bandwidth congestion and competition for their priority applications.

Content Spooling Buffering One problem for servers is that their load is often increased because they chunk up their responses to various clients so the data is consumable. This is a negotiation that happens been client and server to establish an acceptable size or rate of transfer. So with V9 F5 has introduced Content Spooling to the BIG-IP, which enables it to accept and buffer the complete server response, allowing the server to free the associated resources immediately. BIG-IP then delivers the data to the client in “bite-size” chunks, allowing the server to send data at its optimum rate, while the client receives data at the required rate. F5 claims that Content Spooling can increase server capacity by up to 15% for any application, thereby lowering infrastructure costs.

IPv6 Gateway BIG-IP can convert IPv6 client traffic to IPv4 node traffic and back to IPv4 client traffic (and vice versa). It also allows you to actually mix IPv6 and IPv4 nodes in the same pool. This allows a system administrator to gradually convert nodes to IPv6, or they could mix them. And they could have all those nodes respond to traffic from both and IPv6 and IPv4 protocols. You can also have both an IPv6 and IPv4 virtual server direct traffic to that pool. The BIG-IP system can do full-blown IPv4 and IPv6, L4 translate between them (translating out-of band ICMP control messages accordingly), and L7 terminate them as separate connections, using the BIG-IP system to bridge the gap between the stacks.


Page 11

IPv4-IPv6 – BIG-IP As A Migration Tool

Moving from IPv4 to IPv6 is anything but trivial. It requires a tremendous amount of work and significant rearchitecture of most systems. But with growing demand in Asia and within government verticals especially, IPv6 support is a significant advantage for a customer looking to bridge into the next generation of IP address space. Where BIG-IP comes into its own here, is as a key solution for bridging the gap between these transitions. Since it virtualises both IPv6 and IPv4 endpoints, it means that environments can support both addressing schemes simultaneously. So it will be possible to mix IPv6 and IPv4 virtual servers within a virtual server, meaning that you can migrate from old to new over as long a period of time as you need.

Response Error Handling With V9, BIG-IP system can look at any server response code such as standard 404 errors, or custom server errors like 900 errors, and make decisions based on observing server responses. Customers can then use iRules to customise actions to be taken, such as redirecting the request to another location or reload balancing the request back into the pool to servers with valid content. Since, historically, having lots of monitors consumes resources on the traffic management device and other network resources, administrators must often limit the number and frequency of the availability checks (specifically content checks). The result is that not all content can be monitored for availability, and failures that are detected may happen midway through a longer than desired polling cycle, leaving many legitimate users directed to a resource that has been down for several minutes. Through Response Error Handling, BIG-IP solves both of these problems by creating an observed monitoring capability that can see all errors and take corrective action to redistribute requests before that error is transmitted to a user.

Security Features Overview

SSL Bulk Encryption Acceleration With V9, F5 has added SSL Bulk Encryption Hardware Acceleration. To explain, SSL involves two main parts; a key exchange and then encrypting or decrypting traffic. Most SSL acceleration technologies only accelerate the key exchange with special hardware. F5’s new technology accelerates both the key exchange and the encryption and decryption - called bulk encryption. This, quite simply, equates to higher SSL throughput for a higher total SSL capacity and more capacity for advanced iRules or other intensive functions, because the processor offloads the function of the SSL.


Page 12

Protocol Sanitization With V9, F5 has looked to provide a complete network attack barrier, via its TM/OS (Traffic Management Operating System) Application Proxy, in that it fully terminates both TCP between client and server. So, by acting as a full broker, BIG-IP first sanitizes the communications looking for attack patterns and exceptions, and then cleans up traffic for server and application consumption. In this way it protects against various DoS attacks such as Out of Order TCP packets, MSS Mismatches or TCP Window Attacks and all other forms of unanticipated malformed packets by default, but using iRules can detect and block any attack. With V9, the firewall packet filter is also significantly enhanced to act as a truly flexible and integrated perimeter security mechanism. The packet filter operates at L4, inspecting traffic types as they enter BIG-IP, acting as the first line of defence. Users can set a globally-defined default action, as well as specific rules for handling specified traffic types by using packet filter rules. Advanced controls within the Packet Filter engine include:

Sortable rule evaluation Option: automatically accept a number of important ICMP

Messages Option: Allow “trusted” Traffic; define source IP addresses, MAC

addresses and ingress VLANs Statistics – instance count for each rule Initiation Rate Shaping - by using Rate Classes within the filter

Intelligent SNAT iSNAT Secure Network Address Translations (SNAT) is a type of SNAT that causes the BIG-IP system to select a translation address to map to an original client IP address based on any piece of packet data that you specify. This piece of data can be an original client IP address, but this is not required. Like a selective SNAT, an iSNAT maps an original client IP address to a SNAT pool, rather than to an individual translation address. iSNAT adds significant translation flexibility, especially for sites that are managing multiple links. For example, many customers want to translate source addresses based on HTTP, SMTP and SIP service port numbers. This was required to collect statistics for all these services so that they can be used for billing purposes. iSNAT is needed to make multi-homing work, hide internal resources – such as internal server addresses - and provide this billing capability.

Resource Cloaking There is a lot – repeat, a lot – of information about your network passing across the ‘net in headers, that can provide valuable information for network terrorists. For example, Web servers return status codes based on the page request status – for example, “403 – access is forbidden” and often details about the web server application software, which is in clear text. Another example is database errors. When a hacker can generate a successful error, the Web application typically brings out the error message returned by the


Page 13

database along with the queries run. From the error message, the hacker can extract information about the database schema and about the way queries are generated by the application. This information can help hackers plan inputs that would generate successful hostile queries. So, to nullify this, with V9, BIG-IP can be configured to block response headers or portions of the headers which contain information about the Web server, important libraries, or the language the application was written in, for example. Most customers do not want to broadcast that they are using IIS or Apache servers, yet typically this kind of information is present in a server header such as: Server: Microsoft-IIS/5.0 Server: Apache/2.0.49 (Unix) PHP/4.3.6 Server: Apache/1.3.26 (Unix) PHP/4.1.2 mod_ssl/2.8.10 OpenSSL/0.9.6b) Another application is removing source code comments, where developers typically make notes in source code to aid troubleshooting, comment out code, note development reminders, revision history, and many other clues to the inner-working of their code. Since web page code and comments can be easily viewed in a browser, this information is accessible for easy exploits. BIG-IP can remove the source code comments, not allowing users to view these comments.

Advanced Client Authentication If FTP or HTTP traffic comes to the device, BIG-IP can take login information and interface with a 3rd party authorisation device, just like SSL does. Authentication policies can be customised for various traffic types and are ultimately applied using rules or within an authorisation profile. Five common authentication profile types are supported: LDAP, RADIUS, TACACS+, Client Certificate-based LDAP, and OCSP. A sixth authentication profile type supports advanced authentication requirements by exposing the ability to configure a corresponding PAM service directly. By acting as an authentication proxy for various traffic types, enterprises can provide top-level authentication for applications at the BIG-IP. This allows them to push their security perimeter one level further in the network (away from the applications), offering greater protection for their Web and application tiers. Customers can also offload top-level authentication processing from the servers, reducing overhead and management that typically chew up server farm resources.

Selective Content Encryption Through selective encryption, BIG-IP is able to holistically, partially, or conditionally encrypt data. In conjunction with any iRule event it can trigger any number of actions, such as, selecting content to be encrypted to business partners, VLANs or other public traversals, or selecting only the portions of content that need to be encrypted, improving the performance and lowering the resource impact.


Page 14

Cookie Encryption And Authentication While cookies are part and parcel of the modern Internet world, there are a variety of cookie vulnerabilities that hackers can exploit to access protected systems, falsify user identify, or mount application attacks. So, with V9, BIG-IP protects against a variety of exploits aimed at penetrating critical applications by using legitimate user IDs to falsify user identify. By encrypting cookies and other tokens that transparently distributed to legitimate users, BIG-IP users gain superior security for all stateful applications (ecommerce, CRM, ERP and many other business critical applications) and a higher level of user identity trust overall. BIG-IP allows sites to encrypt Cookies to protect against a number of attacks, including: Session Hijacking – Many cookies contain information such as JSession IDs or other information which is used to identify the user to an application or system. Through sniffing the network, taking this ID and using it to establish another connection, hackers essentially piggyback on a session using the valid user ID. Because HTTP is stateless, applications cannot determine that two distinct users are actually connected, providing a door for both a legitimate and a falsified user. By encrypting cookies, BIG-IP encrypts all IDs and ensures that only legitimate user connections are allowed through the system. Cookie Tampering – Similarly to above, capturing a cookie can give hackers a tool to find other valid IDs and legal cookies by which to hack a system. Basically, there is no way to tell if a cookie has been changed or tampered with inside the application itself. By encrypting the content, hackers do not have the opportunity to read or modify cookies in any way. Sensitive information leaks – Often cookies contain internal IP addresses and other absolute references that hackers may target attacks against. In addition to encrypting this information, BIG-IP can also sanitize a cookie by removing all sensitive information from being passed in the cookie.

Content Protection A key part of application security is ensuring that the most sensitive information is well protected. BIG-IP provides a customisable toolkit for defining content filtering policies that ensure information is secure. It’s new TM/OS and enhanced iRules provide an engine for specifying, identifying and blocking sensitive content from escaping from a site. Examples include: Filtering Server Requests - Using iRules, BIG-IP searches and blocks invalid requests made to backend systems. For example, BIG-IP can block a select* SQL call for a specified table that contains user’s account information. In addition, you can specify that the same table may be accessed from a specified IP address or VLAN. Filtering Content from Servers - Similarly, users can define a specific set of content that should not pass to the outside world. In this scenario, BIG-IP can search, block and log when a document is sent by the server farm.


Page 15

Load Balancing As we’ve already explained, one of the real advances in traffic routing and control to emerge in recent times is content routing and switching; that is, the ability for a device to make an intelligent decision about how to route a packet, based on that packet’s contents. But Layer 4 and layer 7 combined also make for a powerful story, which is why the load-balancing capabilities of a BIG-IP are as important as ever. For example with cache management, the BIG-IP, on reading a request header can intelligently determine whether content is cacheable or not – for example a static versus active web server page - then intelligently directs only the correct content to the cache. It also recognises “hot content” based on the number of hits a particular web object is receiving and uses the available caching accordingly, load balancing as necessary. Groups of caches can also be created and assigned to specific functions, such as handling a particular service. Similarly, load-balancing firewalls is still a very common application for BIG-IP. Load Balancing Scenarios The BIG-IP is designed to load balance a number of different devices on the network. In addition to classic server load balancing, it can equally load balance any type of applications server or directory server, including multimedia/streaming servers, Internet servers, firewalls, routers, cache devices, proxy servers and VPN gateways. Load Balancing Methodologies In addition to the “industry standard” round robin and weighted round robin/ratio modes there are a number of more complex dynamic alternatives, which are described on the following page. For example, with V9, F5 has expanded its Observed load-balancing mode to include a slow-ramp attribute. As with all the BIG-IP features, these are selected using a browser-based GUI which we can only describe as the best we’ve ever seen on any product in our labs, but more on the interface later. Static Modes

Round Robin - In Round Robin mode, the BIG-IP distributes connections evenly across the nodes that it manages. Each time a new connection is requested, the BIG-IP passes the connection to the next node in line.

Ratio - The Ratio mode allows you to assign weights to each node.

Over time, the total number of connections for each node is in proportion to the specified weights.

Priority - In Priority mode, you create groups of nodes and assign

a priority level to each group. The BIG-IP distributes connections in a round robin fashion to all nodes in the highest priority group. Should all the nodes in the highest priority group go down, the BIG-IP begins to pass connections on to nodes in the next lower priority group.


Page 16

Dynamic Modes Least Connections - The BIG-IP passes a new connection to the

node with the least number of current connections. Fastest - The Fastest mode passes a new connection to a node

based on the fastest measured response time of all currently active nodes. This mode selects the node with the fastest measured response time. Response time is determined by measuring the time that elapses between sending each packet to the node and receiving each packet from the node.

Observed - This mode is a combination of "least connections" and

"fastest". Nodes are ranked based on a combination of the number of current connections and the response time.

Predictive - In Predictive mode, the BIG-IP analyses the trend of

the Observed ranking over time, determining whether a node’s performance is currently improving or declining. The node with the best performance ranking that is currently improving, rather than declining, receives the next connection.

Dynamic Ratio - Using this, the BIG-IP can receive information

directly from application servers such as Windows 2000, Real Server and other SNMP systems to directly change the ratios set for load-balancing without human intervention. Clever…

Fault Tolerance One of the big selling points of the BIG-IP products has always been is its range of fault tolerant features and with V9 an important addition has been made. This is in the form of controlled synchronisation between a redundant pair, to ensure that the wrong configuration cannot accidentally be used to “sync” up a pair of BIG-IPs. It will always recommend the “best” configuration as a failsafe option. Fault Tolerance, BIG-IP style, includes a number of features to prevent downtime in the event of a hardware failure, the common approach in each case being to eliminate the classic single point of failure. In a configuration with dual-BIG-IPs, it is possible to set up the systems in a number of different ways to support fail-over from the first to the second, both in stateful and persistence modes. A watch dog card is supplied with every switch, so in a redundant pair, these cards are connected to provide a claimed fail-over time of less than .07 seconds. So should a single server or all servers fail, BIG-IP allows automatic redirection of traffic to a different server or site. In the event of a back-end server or service failure or unavailability, the server or service is removed from the availability table instantaneously (from the point of the user specified time-out interval). The server or service it then continually checked for availability at a user specified interval, and is brought back into the availability table once the server or service is back on line. No manual user intervention is required. With BIG-IP you can also assign priority levels to servers in a group to create a set of standby servers. If a certain number of higher priority servers ever fail in the group, a lower priority group will automatically be added to handle the load.


Page 17

The basic fail-over configuration options are as below: Active/Active Mode When engaged, this allows both switches to simultaneously manage traffic for different virtual addresses. This option allows you to take advantage of the throughput of both devices simultaneously. In the event of a failure on one of the switches, the remaining active switch assumes the virtual servers of the failed device. Mirroring Connection Information for Fail-Over Mirroring provides seamless fail-over of client connections and persistence records from an active BIG-IP to a standby switch. This allows a user session to continue even if the primary BIG-IP fails. The device also supports individual and advanced port mirroring, as well as Spanning-Tree Protocol. Network-Based Fail-Over Network-based fail-over allows you to configure a redundant BIG-IP to use a network connection to determine the status of the active switch. Network-based fail-over can be used in addition to, or in place of, hard-wired fail-over. This is a significant feature because it gives more flexibility to the network manager. With network-based fail-over, redundant BIG-IPs are not limited to the physical proximity caused by the 25-foot serial port fail-over cable and is therefore ideal in the WAN scenarios we tested here.

Persistence Definition The BIG-IPs handling of persistence – a patented technology - is another key selling point for the product range as a whole. But what exactly does F5 mean by “persistence”? Basically persistence is necessary when a server has data associated with the user and the data is not dynamically shared with the other servers. A classic example lies with online Internet shopping. So let us take the scenario where a customer builds a "shopping cart" of goods at a web site, and then leaves the site before completing the transaction. If, upon returning to the site, the BIG-IP directs the customer’s request to a different server, that new server may not know about the user and his or her shopping cart. Of course, if all the servers stored the user information and their selected goods in a single back-end database server, this would not be a problem. But if the site is not designed this way, the specific shopping cart data resides on just one server. In this case, the BIG-IP must select the same server that the user was directed to in the past, in order to seamlessly process the user’s request. Similarly, this applies to a POP3 email session. With V9, F5 has expanded on the “Universal Persistence” methodology, so using the revised iRules and UIE engine, persistence can be assigned, tracked and remembered, based on any value in an application flow.


Page 18

Persistence Modes With the BIG-IP, F5 offers six modes of persistence: Source, Server, VIP, SSL, Cookie Persistence, and Destination Address Affinity. Not only is this a very extensive range of options but the cookie persistence has three modes where one of the modes does not require any change to the web host application, making it easier to configure. These are Rewrite Mode, Insert Mode, and Passive Mode. The cookie persistence uses cookie information stored by a client to direct the client connection to the appropriate server. The primary difference between the BIG-IP Cookie Persistence modes and SSL Persistence is that with Cookie Persistence, data is stored at the client, not in BIG-IP, so the infinite resources of the client are available for use. That is, Cookie Persistence persists on the HTTP Cookie and information is stored on the client’s disk drive.

Configuring and Managing The BIG-IP With V9 All the features and functionality in the world are largely useless if they are impossible to set up. One really excellent aspect of setting up and managing a BIG-IP is the interface itself, a web-based system, though a CLI alternative is also available as is secure access via SSH (Secure Shell). The GUI has always been available via a dedicated management port on the device. However, new - and importantly so – to V9 is that the management port is now totally isolated from the main device, with a separate IP stack, running on a separate micro-kernel, so even if problems arise with the main system, or even if it is – for some reason – totally overloaded, it is still possible to manage it.

Figure 4 – The New V9 GUI


Page 19

Also new, and equally important, due to the number of new features in V9, F5 has been forced to rewrite its GUI, which now has a different appearance, designed to cope with far more options than before, yet still allow total control of the device from the user interface. The new GUI revolves around a main screen which gives you all the configuration feature options down the left hand side. Selecting one of these presents you with the specific detail screen for that feature, such as Virtual Servers, as shown on the screenshot. For each feature a separate submenu bar, above the working screen area appears. Clicking on any of these feature options brings up the relevant screen. Since many F5 customers will have configurations consisting of hundreds of components, rather than having scroll down through endless lines on the same screen, the GUI auto-paginates so that you can more easily get to the data you want to work on. Also new is an LCD panel and keypad on the front of the BIG-IP which allow you access to a limited number of key management features, as well as acting as a first-line status report tool.

Figure 5 – LCD Status And Management Screen

Exactly how you then configure a number of BIG-IPs depends on exactly what you intend making them do. In order to test several different scenarios within the labs we created multiple configurations. These are very easy to save and switch around, adding to the flexibility of the product. Online, context sensitive help and a full search facility are both available at all times. The GUI also helps when creating any new configurations by offering a number of wizard-style guides with prompts for many of the functions. Once up and running, the sheer amount of networking statistics available from the BIG-IP is impressive, these being linked directly to specific features via their sub-menu bars. Using the health monitor functions described earlier it is also possible to check on the status of key devices on the network at all times. Log files are also created to view a range of historical events with. At the CLI level you also can run a number of monitors to trace very specific traffic types, or view general activity.

PUTTING IT TO THE TEST –V9 FUNCTIONALITY TESTED AT LAYER 7

Test Overview For the feature and functionality testing we created a test bed with web traffic being generated by both Ixia and Spirent test platforms. These create real client/server traffic with ping-able IP addresses and real services – in other words, it is not an out an out simulation, but as close as we can get to real world testing, without involving thousands of people sat at their PCs. We looked at the V9 code using a BIG-IP 6400 platform and compared the feature set, as we ran through the tests, with those of F5’s key competitors,


Page 20

all on bang up to date platforms with current software releases. Primarily here, we’re looking to see just how far F5 has advanced the world of Layer 7 networking with its complete rewrite of the BIG-IP software. For logic’s sake we’ve split the testing into two categories – functionality and analysis, the latter being analysis of data content type tests.

Functionality Tests System Instrumentation Here we compared and contrasted how easy it is to see the status of the L7 device to give an instant appraisal of its – and the network’s – health. With the new V9 GUI we get a very clear representation of all the key system components of an L7 switch and its traffic, with memory and CPU utilisation on the one hand, and new/active connections and throughput on the other, all graphically displayed on the one page. There are also statistics available on just about every element of the device, as well as colour-coded status displays on every page of the GUI.

And of the rival vendors…

While some of the user interfaces of the rival L7 products offer some useful information – notably NetScaler – none provides the instant depth of status information that the F5 GUI does. The main problem with the NetScaler statistics dashboard is that it is accessed separate to the main configuration screens, so really you need two browsers open – as indeed we did when testing the product in our test labs earlier this year. Redline’s GUI has three icons that demonstrate whether network, CPU or memory need attention, though this is a basic “yes” or “no”, with more details only available via the CLI. There was also a slightly disturbing pause every time we consulted these. Radware gave us CPU usage but little else. However, Nortel and Cisco – both with ageing product lines that have shown little sign of recent update – offer even less – nothing at all on the Alteon (Nortel) or Cisco CSM products, and just current CPU/Memory usage on the Cisco CSS, which is very disappointing. Bottom Line: When initially configuring the box and whenever, thereafter, there is a problem on the network, immediate access to key management data can save hours = $$$$$$. It is simply inexcusable not to offer an instant status view of a device’s key components. Hardly rocket science…


Page 21

Figure 6 – V9 GUI - Redlining Stats

Management Looking at the management GUIs in more detail, as well as redesigning its interface for V9, F5 has added some new management features, the most notable of which is the “Profiles” concept. Typically, when dealing with large configurations, two key problems exist: traffic management attributes need to be repeatedly configured across all objects, and changing settings across these objects can be painful in the extreme. With Profiles you can define any number of standard traffic policies and apply those policies as and when you wish, across any or all of the virtual servers. Using a Profile, customers can also change a setting for traffic across many different applications. This means that configuration management can be controlled centrally but easily deployed locally and remotely. Simple and neat, eh?


Page 22

F5 has also provided two important features to make management more resilient. The first is in providing a dedicated, totally self-sufficient management port, which means “lights out” management is now possible – even if the device has problems you can always get to the management interfaces. The second is the aforementioned “intelligent configsync” feature, which means that in a redundant pair setup, you cannot accidentally synchronise both devices with the wrong configuration.

Figure 7 – Cisco CSM “GUI”


Starting with the best of the rest, NetScaler’s GUI is generally easy to use, but very slow when you need to add a lot of repeat information and is clearly comparable with the previous generation F5 interface, which we liked, but the game has moved on. The Redline GUI could have been better thought out – for example there is no sectional split for navigating and config pages are very long, so it is easy to miss entries. The Radware terminology is mercilessly confusing – just what is a WSD? – Nortel’s is basic, old and non-intuitive – while Cisco’s is… well, there’s always the CLI. Bottom Line: What is the point of developing a GUI if it doesn’t offer total – or at least, near total – functionality, compared with the CLI alternative? In some cases here, the blatant lack of effort that has gone into developing a browser-based interface is shameful, especially so when you consider how much these products cost – Cisco and Nortel especially take note. The customer is basically being “ripped off”, nothing less.


Page 23

Application Level Security Here we’re looking at just how fine you can make the security defences when it comes to preventing attack from, not just “generic” DDoS attacks but very specific threats. With V9, iRules provide the means to create a huge range of tailored defence mechanisms, such as a block to an attack like MyDoom or the SQL Slammer worm. As long as you have sufficient information on what to look for in a data flow, you can create an iRule to identify a rogue item and then take any number of actions on it, blocking being just one option. Coding Example 1: F5 Networks iRules sql_slammer_protect when CLIENT_DATA { if { [UDP::payload] contains "SQL"} { log local0. "SQL access detected from [IP::remote_addr]" discard } else { log local0. "SQL connection from [IP::remote_addr]" } } Coding Example 2: Nortel (add-on product – only partial code) /c/slb/real 100 ena rip 30.30.30.100 addport 80 addport 5060 addport 1434 /c/slb/real 101 ena rip 30.30.30.101 addport 80 addport 5060 addport 1434

And of the rival vendors… Cisco’s defence mechanism is pointed towards HTTP attacks only – not UDP – and therefore has obvious limitations. However, Nortel and Radware can provide security tools but only as expensive add-ons; they don’t come as standard. Even worse, if we consider the Nortel example above, not only is the required coding very difficult to understand, but the sample shown is only a fraction of what is required in order to achieve the same with – a far easier to use language in – iRules in just a few lines of code. NetScaler and Redline also appear to be focused towards HTTP only currently, at least. Bottom Line: The world is not a pure HTTP environment. If you are going to provide security features, then it makes sense to cover the whole TCP/IP scene, otherwise you leave yourself wide open.


Page 24

Rate Shaping To date, many features of L7 devices have been of the “on” or “off” variety, but with rate shaping we’re looking to find a way of providing very specific and finite control of data traffic and connections by application and client type. In order to test the V9 code, we created a mock application that took two different clients – “fast” and “slow” – and limited the transfer rate capabilities of the latter, using an iRule. We then generated two HTTP file transfers, one for each mock client and let the BIG-IP device use the iRule we’d created to control the traffic flows. As we’d intended, the “slow” client transferred the same file as the “fast” client at the slower rate we’d defined, which we monitored using a traffic flow utility.

Figure 8 – Rate Shaping with the BIG-IP system


Of the alternative L7 product suppliers here, Nortel and Radware do best. The former offers rate shaping based on IP address, VLAN, Physical Port, Virtual Server, URL Path or cookie, while Radware can handle physical ports, VLANs, source/destination IP address and any content that triggers a bandwidth decision. But again, they could both be far easier to set up, though in Radware’s case it is mainly the bizarre terminology and syntax that cause problems. These should be simple elements to amend and it amazes us that products in the 21st century are still released with this kind of “black art” approach to networking. Is it simply designed to keep engineers in business and let consultants get fatter? Of the other products, Cisco’s CSM is limited to L4 and neither NetScaler nor Redline appear to offer any rate shaping in their boxes. Bottom Line: If you are looking to extend traffic management beyond simple Internet-based optimisation and create true, client-specific, end to end bandwidth control, then there is only one approach to take and that is what F5 has done in V9, true bi-directional flow management on a per-client basis. Otherwise you simply have to go out and purchase an additional product, adding not only extra initial expense, but also additional management and integration headaches. So what’s the point?


Page 25

Open API With iControl, we know from experience that F5 offers a truly open API. Here we wanted to test the flexibility of it, by making iControl act, not only as a responder to an alert from a 3rd party application, but to invoke an action as a result of that alert, creating a mock application based around the increasingly popular SOAP/XML interface.

Figure 9 – iControl SOAP/XML Interface Test

In Figure 8, Mercury Interactive Topaz is used, although this could be any number of network management applications. In this example, iControl instructions set the new Dynamic Ratio for server D from 4 to 3.


NetScaler offers an API but it doesn’t appear to be anything like as flexible as the new incarnation of iControl. Cisco offers limited open access, in the form of supporting XML documents to configure its product over HTTP. The others appear to have no API functionality, unless you count FTP’ing files into directories as an API – hardly! So much for the wonderful world of the open “noughties”, where proprietary is a no-no, allegedly… Bottom Line: The ability to extend the functionality of an L7 product almost indefinitely simply cannot be ignored. In the Broadband-Testing labs we’ve created a number of iControl based applications – such as billing and SLA monitors – in a very short space of time, that add real value.


Page 26

Analysis User Interface One really excellent aspect of setting up and managing a BIG-IP device has always been the management interface itself, a Web-based system (though a CLI alternative is also available).

Figure 10 – V9 GUI – Main Configuration Screen

Now, due to the huge number of additional features in V9, the GUI itself has been totally redesigned, so that it still – outstandingly – gives you access to the entire BIG-IP product feature set. The operation of the GUI is consistent throughout, with online help always available, and each subject – Virtual Servers for example – expanding in across the screen, with a menu bar where all the sub-options are listed with drop-down sub-menus from each of these. Where the number of items to display exceeds a “regular” screen’s worth of web page, the GUI automatically creates extra pages to view, so you don’t have the problem of scanning down hundreds of lines of entries on one screen. Simple stuff, but all part of what makes a really good GUI… As we’ve already mentioned – but it is worth reiterating – with V9, F5 has created a dedicated management port based on its own micro kernel/IP stack which therefore enables access to the GUI at all times, regardless of the state of the BIG-IP itself. This means that you can get to the management GUI at exactly the times you most need to – when there is an apparent problem with the device.


Page 27

Broadband-Testing – GUI Observations From The Past In the past we’ve often been cynical – and rightly so – about Web-based interfaces. Too often they’ve been limited in terms of functionality or just downright flaky. We’ve even had situations where a vendor’s GUI couldn’t find its own switch on the network to configure in the first place, yet Deltalert, a 3rd party management tool we use in-house, not only found it, but then let us manage it. But F5 takes the GUI seriously and it shows again in this new incarnation. Where vendors have gone wrong in the past, and still are going wrong, in truth, is in one of two ways: - They simply don’t make any real effort to make a solid, reliable

interface, so you can never actually trust that it is a) working correctly: imagine committing precious changes to configuration and having to keep your fingers crossed that they were written correctly – or b) it falls over all the time.

- The GUI is at least stable and reliable, but there is almost zero

functionality available from it, so that the CLI is the only real option. So, what we say to all the vendors out there, with respect to their GUIs is:

“Either do it properly or don’t bother”. There is nothing worse than trying to use an interface that is not 100% reliable when configuring networks, period. Just ask any network administrator. Almost as bad is when you start to use the GUI, trust it, then find it can’t do half the stuff you’re trying to configure, so you have to start over again with the CLI.

Client (connection) Aggregation As we’ve mentioned earlier in the report, with OneConnect, F5 has a very flexible client aggregation tool, which works especially well in a content switching scenario. Here, OneConnect enables the BIG-IP device to individually handle each request within the same connection and direct them to different back-end servers. In V9, content switching on a per-request basis is always supported. OneConnect can also be used to encourage server-side connections to remain open when clients are using HTTP 1.0, or communications that typically do not allow for server-side connection pooling. This is valuable because the BIG-IP device attempts to maintain the server benefits of connection pooling, reducing TCP overhead, even when clients are incompatible.


Page 28

And of the rival vendors… Both NetScaler and Redline Networks offer client aggregation but in an on/off mode only. Cisco, Radware and Nortel do not appear to offer any such functionality. Bottom Line: Any TCP optimisation is a good thing, but in the real world client request speeds and bandwidth availability vary enormously, so you need to be able to tailor the aggregation accordingly, otherwise you are simply creating more inefficiencies – the very thing it is designed to avoid.

Networking Flexibility With V9, F5 offers the best combination of VLAN/trunking support available in an L7 device, as well as being very easy to set up under test. When combined with packet filtering, it offers more still. With V9, the firewall packet filter has been significantly enhanced so it acts as a truly flexible and integrated perimeter security mechanism. The packet filter operates at L4, inspecting traffic types as they enter the BIG-IP system, acting as the first line of defence. Users can set a globally defined default action, as well as specific rules for handling specified traffic types by using packet filter rules. Advanced controls within the Packet Filter engine we considered include a sortable rule evaluation, the option to automatically accept a number of important ICMP Messages, and to allow “trusted” traffic; define source IP addresses, MAC addresses and ingress VLANs. You can also perform Initiation Rate Shaping by using Rate Classes within the filter. For statistics, there is an instance count for each rule.


None offer the same combination of VLAN/trunking support. Packet filtering is prevalent at L4, but more basic at L7 compared with F5’s iRules based flexibility. Nortel and Cisco offer load balancing of non TCP/UDP IP traffic, but the former vendor’s methodology is very complicated to use and Cisco still lacks the flexibility of an iRules equivalent. Bottom Line: Again we’re talking about defining traffic management at each and every point on the network and bringing in that all-important flexibility which prevents constant, expensive upgrades.


Page 29

UIE And iRules As another test of iRules flexibility and the performance of the UIE, we created a test running multiple types of traffic, including SIP over UDP and HTTP. We used Windows Messenger as our client application, and then created and applied iRules to make a traffic direction decision, as well as an application filtering decision on the passing traffic. We created two users, one who had a valid login and one who didn’t, who was to be timed out. We then put this to the test and there were no surprises, it worked as expected.

Figure 11 – UIE iRules Windows Messenger Login Test


Of the alternatives to F5 we’re considering in this report, only Redline has true rules that can operate on response traffic and that can modify arbitrary data, but for HTTP only. Whereas F5 supports any IP, Cisco can read HTTP traffic but with no regular expressions or programmatic logic. It’s also extremely long-winded. Nortel also has a very crude methodology and no multi-policy combinations, so the most complicated action you can take is to rate shape based on a URL. Radware has a far more flexible inspection rules option, but no data can be changed and the interface is based on conditions or groups of conditions, so is not a true programming interface. NetScaler does not have a direct iRules equivalent and is HTTP/requests only oriented. Moreover, none supports the iRules style development like F5, which is even adding an iControl equivalent community site to DevCentral for iRules developers, so they can share ideas and create code libraries. This is real commitment to developing L7 applications. Bottom Line: With a combination of iRules and iControl, F5 has given its customers near infinite control over data manipulation. Do you realise just how powerful a combination this is? It means that you are really in control of the network traffic; networking becomes a development language. This is very serious stuff indeed… applications and networking truly integrated.


Page 30

Inbound And Outbound Event Based Decisions In order to show how we could apply iRules across an inbound flow as well as an outbound, as well as how powerful the monitors are, we set up a scenario where a client request comes in, the BIG-IP system directs the request, the server returns an error code which the BIG-IP device listens for and if found redirects to another server pool. We did this by creating two servers/pools, sent it to server1 by default – the basic error code scenario – and to server2 when the iRule was redirecting the client request – see below.

Figure 12 – iRules redirecting An Error Code Web Page

We then looked to demonstrate how we could combine the V9 resource cloaking and content sanitization features, by enabling a rewrite of payload content for content masking. We did this in two ways – first taking a Social Security numbers (SSN) scenario, where we wished to hide the actual figures with blanking characters. Then we took a scenario where the Web server was returning data that included its product details in the header – perfect for a potential attacker – and cloaked these so that nothing was visible any longer. In each case we created the scenarios and then ran the tests against them, using a Web content monitor to see exactly what was in the header information (or lack of information!) once the data flows had been managed by the iRules. The following screenshots show the header info before, and then afterwards – nothing! The results were 100% secure. This is a really good example of a very, very useful feature which is both simple to apply and – at the same time – can be applied to hundreds of scenarios right now.

Figure 13 – Cloaked Headers Test –Before The iRule


Page 31

Figure 14 – Cloaked Headers Test –After The iRule – No Header Info

And of the rival vendors… Redline is the only competitor that can inspect HTTP responses and can also rewrite some content, but with no pattern matching and no encryption capabilities, so couldn’t deliver the above tests. And there is no programmatic interface. Cisco’s CSM product can mark a server as unavailable based on HTTP response codes but therein lay its limits. In terms of the rewrite example, Redline’s limit is that it cannot pattern match, but simply append/prepend/replace data. So, if our SSN was hard-coded into a rule this would be possible to mask, effectively by search & replace, but this makes it very inflexible. And there is no support for lists. Bottom Line: It is one thing to identify network traffic – and a potential problem, for example – but it is another thing altogether to then be able to do something about it. With content rewrite and iRules flexibility, this is precisely what you can do with V9 – act upon that observation and respond automatically to a potential problem situation. The networking world goes on and on about “pre-emptive management” and the importance of being “pro-active” rather than “reactive”, but how many vendors really offer any help in this way? It’s similar to the security world where the IDS (Intruder Detection System) was replaced with the IPS (Intruder Prevention System) because it was able to do something about intruders, not simply generate an alarm. And talking of security, given the amount of network, OS and application information flying around in headers across the Internet, resource cloaking is one of those priceless features. Who knows just how much it could save a company? Its existence maybe? Automation of tasks like these also removes the “human error” element which, again, can save a company millions.

Authentication Models As we mentioned earlier, the authentication proxy capability of the BIG-IP system is pretty unique, so we put it to the test here against a variety of different authentication servers, including LDAP, TACAS and Radius, and a variety of protocols, with no problems arising.


Page 32

And of the rival vendors… Only Redline is of interest here. The Redline product can proxy authenticate for LDAP and RADIUS but has no support for TACACS or OSCP. OSCP support is entirely unique to F5, which offers dynamic CRL updates. Bottom Line: Authentication is a big strain on a network server. So the ability to offload it is another major benefit and another reason to not upgrade those expensive servers every other year. And if you’re supporting one authentication service, you might as well support them all…

Compression Policy With the compression test, the key here is to look at the flexibility of F5’s implementation, given that it can totally customise compression on a per pool and VLAN basis, and further customise using iRule parameters. Here we show the rule we used to selectively enable different levels of compression depending on the compressibility of the data stream.

set_compress_gzip_level when HTTP_REQUEST { set gzip_param "gzip_level=high" set gzip_level_set 0 if {[HTTP::uri] contains $gzip_param } { set gzip_level_set 1 } } when HTTP_RESPONSE { if {$gzip_level_set == 1 } { COMPRESS::enable COMPRESS::gzip level 9 } }

Figure 15 – iRule Used For Compression Policy Test

And of the rival vendors… Nortel, Radware and Cisco offer no compression functionality at all. In the case of Redline, compression is a key feature, but it is not configurable so lacks flexibility. With NetScaler, it is possible to disable compression, based on an HTTP inspection, but it is not dynamically configurable via the equivalent of an iRule. The key here is to be client aware – if you try to compress already compressed data, then the chances are that you decrease performance, which is not exactly the idea behind the optimisation. Bottom Line: It is just as easy to slow traffic down by adding compression as it is to accelerate it. Try compressing a load of zipped files and you’ll see what we mean. We’ve proved it in the labs countless times. So the ability to choose just what traffic flows you compress is an essential part of optimising the network. All pretty obvious really…


Page 33

Secure Policy We tested the – unique to F5 – capability of cookie encryption, using the time-honoured “before” and “after” technique. Here’s the rule we created – hardly complex…

when HTTP_RESPONSE { HTTP::cookie encrypt "MyCookie" "password" } when HTTP_REQUEST { HTTP::cookie decrypt “MyCookie” “password” }

Yet that is all it took to encrypt the cookie information. As we’ve stated, there is no way of doing this currently outside of the F5 environment, so this really is a “USP” or Unique Selling Point. Content Spooling We set up a test to spool database content and examine its impact on database record locks, using the WAPT tool to dummy the system. Again we had no problems spooling the content and data integrity was maintained throughout the session.

Figure 16 –Content Spooling

And of the rival vendors… NetScaler is able to perform TCP buffering, not spooling, but only the buffer size appears to be configurable which makes its affect extremely limited. Likewise, Redline is able to buffer HTTP responses but with no apparent configurability at all. The others do not appear to have this functionality at all. Bottom Line: Again, it’s about the ability to get right down to the bare bones of traffic control and truly optimise at a per flow, per application level – doing the job properly in other words. Otherwise you risk having an unbalanced network where some elements are totally efficient and others are anything but…


Page 34

Encrypted Storage This is another, unique to F5, feature, which we evaluated creating a complex iRule that used the AES encryption standard and did a search and replace on SSN numbers, successfully encrypting the data in each case. Historically organisations in security sensitive industries such as financial, healthcare, and government agencies have been required to comply with strict security standards such as HIPPA, Sarbanes-Oxley and FIPS. Now these requirements are extending to all organisations and enterprises that conduct business over the Internet. Bills such as California House Bill 1031 carry strict penalties when private user information is abstracted from an organisation's system. The BIG-IP system is the only product on the market that allows enterprises to meet these type of regulatory security requirements, yet target their security in a way that does not dramatically reduce performance.


What rival vendors? Bottom Line: Now we’re really talking end-to-end encryption!


Page 35

OVERALL SUMMARY We started this report by announcing, rather grandly, that F5 is now in the process of helping to change the very nature of application networking for the better… Grand maybe, but we stand by that statement. Revolution – not evolution – is long overdue in application networking, but it needn’t be bloody. Here we have a situation where, with the combination of V9’s iRules and iControl capabilities, it is possible to re-engineer the network completely, but over as long a period of time as you need to do so. As such, V9 provides us with a true migration toolkit, whether that be with respect to IPv6, moving between enterprise software applications, changing authentication servers and services, or any scenario where a change for the better should be made, but previously would have been too painful. We really are looking at a situation where the software is overtaking the hardware when it comes to degrees of importance in networking. Look at the F5 situation – the 1500, 3400 and 6400 are hardware products, but all the interest is in the V9 code release they are running, and that is software. By completely re-engineering its software architecture from the ground up, F5 has given both itself and users of that product the opportunity to change the face of networking, especially given the open-ness of the product, courtesy of iControl. In doing so, it has also leap-frogged the competition by offering, quite simply, a far broader networking landscape on which to build your future applications. All this is not, however, at a price which also far outweighs the opposition. Normally, at Broadband-Testing, given the total cost of network implementations, we don’t worry ourselves about the cost of an individual product, but it is work pointing out the pricing of the new BIG-IP range, starting at around $15,000 for the 1500 and $35,000 for the top of the range 6400 is very competitive indeed. It means that you could buy a fully redundant, two-device configuration of the 6400 for the price of just one device from some of the rival vendors. This kind of price benefits cannot be ignored. So it is without hesitation that we suggest you look at the V9 release if you were in the market for an L7 product – and especially so if you believed that L7 technology was not for you. There isn’t a single networked user who couldn’t take advantage of some of the features in this technology. Not one… And on top of this, it is very competitively priced too, so the possible markets are now far and wide for Layer 7. The future of networking indeed.


Page 36

APPENDIX A: V9 - WHAT’S IMPORTANT, WHAT’S CLASS-LEADING – IN SUMMARY

For Version 9, F5 has completely redeveloped its product architecture from the ground up. This has lead to the introduction of a new product range – the BIG-IP 1500, 3400 and 6400 IP Application Switches – but, more importantly, a Layer 7 architecture to use now and well into the future. F5 looked long and hard at both its existing product range and those of the competition, with a view to redefining both feature and performance levels across the board in the new release. As such, it can now claim a lead in the following areas: TM/OS: At the heart of the new BIG-IP system is a revolutionary new architecture called TM/OS (Traffic Management / Operating System) which F5 has designed to deliver what it believes is the only system for unified application infrastructure services to secure and optimize business application delivery. With TM/OS, the BIG-IP system provides application fluency, total control and complete flexibility to solve the root problems facing today’s IT staff: adapting to the diverse and evolving application needs. The TM/OS is absolutely unique in the marketplace. System Instrumentation: No other vendor offers the same immediate access to such a range of vital statistics that give you a capacity measurement view of the device and the network, which can mean the difference between up time and downtime. Management: F5 has completely redeveloped its GUI so it leads the way in being truly browser-independent, quick to use and – most importantly – offering access to the complete range of functions available on the product. Through the use of Profiles, application policies (see later for more details) on security, optimisation, or delivery can be standardized and repeatable, lowering management costs and complexity. It also offers true “lights-out” management via a dedicated and totally independent management port and interface. UIE and iRules – Inbound and Outbound Traffic Control: F5’s Universal Inspection Engine (UIE) and iRules have been re-engineered so you can inspect any bi-directional IP traffic flow at any level of detail without impacting the performance of other aspects of the device, such as SSL termination or health monitoring. The power of iRules is in the ability to invoke any application infrastructure service that F5 provides at any given moment in time on any application session. iRules are a complete event-driven and relational programming language giving tremendous flexibility in how someone would want to define and implement policies. Application Level Security: Using iRules, it is possible now to block any type of malicious attack at the Application layer without worrying about protocol support or inspection complexity. Rate Shaping: The BIG-IP system can now control network traffic by a combination of application type and user type, allowing the network to be fine-tuned to a new degree and ensuring that mission critical applications


Page 37

are given the priority and reserved bandwidth they need, and rate limiting others for quality of service or even security purposes. Open API: F5’s iControl® API has been expanded to include eventing, where iControl can publish information to a web service consumer based upon events. It also uniquely supports all major development frameworks and languages, working directly in conjunction with its own iRules and even supporting its own development community with the DevCentral (http://devcentral.f5.com/) website. Client (connection) Aggregation: V9 offers a very flexible and secure approach to connection aggregation, notably in conjunction with content switching. Networking Flexibility: F5 has taken the lead in providing for truly flexible networking, with its combination of top-drawer VLAN and trunking support. With iRules, its packet filtering options at L7 are unmatched. At L4, its ability to balance any IP traffic – such as IPSec VPNs – is equally outstanding. Authentication Models: F5’s advanced authentication proxy capabilities in V9 are simply more extensive than any other L7 player, supporting LDAP, TACACS, Radius and via HTTPS, and a wide variety of SSL security support such as client certificates with OCSP. Compression Policy: F5 has now added compression by Pool, VLAN, or iRules to enable it to be truly optimised for each and every user type and situation rather than simply switched on or off. Secure Policy: With V9, F5 has extended its cookie flexibility, and really the entire iRules feature-set, to include such features as cookie encryption, regardless of the application/protocol combination – stateful or stateless. And it is not just cookies, but any IP content can be specified to be selectively encrypted. Content Spooling: With V9, the BIG-IP system can accept and buffer a complete server response to a client request, allowing the server to free the associated resources immediately and let the BIG-IP device serve the client at the appropriate speed for their available bandwidth. Encrypted Storage: Another feature unique to the BIG-IP system is the ability to selectively encrypt and decrypt stored information as required, using AES encryption.


Page 38

APPENDIX B: SPIRENT WEBAVALANCHE AND WEBREFLECTOR WEB TRAFFIC GENERATORS

Internet architectures are becoming increasingly complex. Whether you're building network equipment or providing a service, you must deliver consistent performance under all conditions. Until now, capacity assessment at high-loads has been a costly and complex process. For this reason Spirent Communications introduced the WebAvalanche and WebReflector appliances to assist with the challenge. At Broadband-Testing we have taken these web application simulation and planning products and integrated them into our test-bed simulating real-life Internet conditions; those that the average user experiences daily.

Figure 17 – Spirent WebAvalanche 2500

WebAvalanche is described by Spirent as a capacity assessment product that challenges any computing infrastructure or network device to stand up to the real-world load and complexity of the Internet or intranets The system determines the architectural effectiveness, points of failure, and the performance capabilities of a network or system. Using WebAvalanche to generate Internet user traffic and WebReflector to emulate large clusters of data servers, you can simulate even the world's largest customer environments. The system provides invaluable information about a site's architectural effectiveness, points of failure, modes of performance degradation, robustness under critical load, and potential performance bottlenecks. It is able to set up, transfer data over, and tear down connections at very high rates - all while handling cookies, IP masquerading for large numbers of addresses, and traversing tens of thousands of URLs. WebAvalanche initiates and maintains more than a million concurrent connections, each appearing to come from a different IP address. This allows realistic and accurate capacity assessment of routers, firewalls, load-balancing switches, and Web, application, and database servers. It helps identify potential bottlenecks from the router connection all the way to the database. This accuracy is especially critical for gauging Layer 4-7 performance. The ability to additionally simulate error conditions such as http aborts, packet loss, and TCP/IP stack idiosyncrasies can help anticipate-and avoid-significant and previously unknown impacts on


Page 39

performance. To enable more accurate load simulations across multi-tiered Web site architectures, the system also supports extremely realistic user modelling behaviours such as think times, click stream, and http aborts that cause Web servers to terminate connections while back-end application servers continue to process requests. Configuring in this way is simple as both WebAvalanche and WebReflector directly from a desktop browser to set up tests, review feedback in real time, and easily reconfigure test parameters.

Figure 18 – Creating A WebAvalanche Test

The WebAvalanche also supports browser cookies, html forms, http posts, and SSL-encrypted traffic. The system therefore gives you the flexibility to specify data sources and mix and match data sets to recreate accurate user behaviour at very high performance levels. It also simulates SSL loads that can stress the world's most sophisticated secure e-commerce platforms. It also includes configurable cipher suites that enable you to emulate different types of browsers. WebAvalanche includes a high-accuracy delay factor that mimics latencies in users' connections by simulating the long-lived connections that tie up networking resources. Long-lived, slow links can have a far more detrimental effect on performance than a large number of short-lived connections, so this approach delivers more realistic test results. While WebAvalanche focuses on the client activity, WebReflector realistically simulates the behaviour of large Web, application, and data server environments. Combined with WebAvalanche it therefore provides a total solution for recreating the world's largest server environments. By generating accurate and consistent http responses to WebAvalanche's high volume of realistic Internet user requests, WebReflector tests to capacity any equipment or network you connect between the two systems, whatever the device under test.

Documents

EMEA BBT F5 V9 Report - Broadband Testing · First published September 2004 (V1.0) Published by Broadband-Testing La Calade, 11700 Moux, Aude, France Tel : +33 (0)4 68 43 99 70 Fax