Review: F5 Networks' BIG-IP

F5 revamps its hardware and OS, putting distance between it and the incumbent competition. However, new competitors await.

October 1, 2004

10 Min Read
Network Computing logo

Claim: BIG-IP is now a true application front end, providing security, protocol optimization, and traffic management.

Context: F5, Nortel, Cisco, and Foundry may be strong in packet switching-based load balancing, but they let niche players such as Redline, NetScaler, and now Zeus define the emerging application front-end market. With this announcement, F5 catches up considerably.

Credibility: F5 is the 800-pound gorilla in this market, so while it's good news for the start-ups that the gorilla wants to dance to their tune, they also need to be very careful not to get stepped on.

On September 9th, F5 Networks announced a sweeping overhaul of its BIG-IP product line, complete with an OS rewrite, a new ASIC design, and new applications. With this step, F5 has moved beyond content switching and load balancing to more wide-ranging application acceleration. All is not golden, however: The company is still behind the pack in terms of caching, symmetrical compression, and failover. Still, F5's announcement puts pressure on Cisco Systems, Nortel Networks, and Foundry Networks to update their product lines, while at the same time validating the architecture of products from start-ups NetScaler, Redline Networks, and Zeus Technology. COMPETITIVE LANDSCAPE

Not so long ago, the way to get redundancy and scalability for IP-based applications was to get yourself a big pile of servers and then put a content-aware switch in front of them. The switch balanced traffic requests among the servers in the pool, while allowing servers to be added or retired as needed. Virtually no Web site of any consequence runs without a server load-balancing switch sitting in front of a bunch of redundant Web servers. F5 was a pioneer in this space, quickly joined by Foundry, Cisco, Nortel, and a host of smaller players. But while F5 and its competitors stuck to their load-balancing roots, a number of other products sprung up that made use of new technology to both speed and secure application delivery.

What now sits in front of application and Web servers is a pile of special-purpose appliances that, while critical for application performance, are also often feature-redundant, latency-inducing, and difficult to holistically manage. Radware in particular has fared well in this environment, selling point boxes that address particular pain points. However, the market is maturing and looking for more complete solutions. Start-ups have seized on the opportunity, putting functions such as SSL acceleration, caching, TCP termination, TCP connection management, rate limiting, Distributed Denial of Service (DDoS) attack detection, and deep packet inspection all in one box. With its September announcement, F5 has also chosen to follow that path, making the choice of the application front end a matter for careful study.

The announcement also puts significant pressure on Cisco and Foundry to update their product offerings. (Nortel seems to have greatly slowed development of its Alteon product line.) The most likely play, particularly in the case of Cisco, will be to purchase one of the start-ups. Without such a purchase, Cisco risks losing market share to F5 for at least the next 12 to 18 months, as well as opening a nice enterprise niche for Juniper Networks--something the company is unlikely to tolerate. Foundry doesn't innovate by acquisition, but it could partner with one of the start-ups.

Regardless of mergers and acquisitions in this sector, there's a careful balancing act between providing the fastest possible performance, which appeals to service providers and large Internet-based companies such as Google or eBay, and providing good performance with a rich feature set that appeals to typical enterprise customers. For the likes of Google and eBay, rewriting a Web-based application to squeeze the most performance out of it or to fix a security hole is a part of their business model. Enterprise customers, on the other hand, are often stuck with applications that they can't or won't modify regardless of the performance problems at hand. In the past, F5 has striven to meet the needs of both types of customers, and its current announcement is no different. The company's SSL performance--at least in terms of raw, vendor-provided numbers--is industry-leading, as are other performance metrics. But while performance is important, it's flexibility and features that matter for most enterprise customers.MORE FLAMES THAN HEAT

Since this is a major evolution in F5's product line, it isn't surprising that the announcement is stronger in terms of performance and platform than it is in terms of a complete feature set. F5 can and must build on its new OS and hardware. Thus, F5's announcement puts the BIG-IP in good stead for both Web-centric installations and legacy applications. However, it faces stiff competition on both fronts. The company says its enterprise customers report that half of their traffic is non-HTTP, and F5 has made accommodations for both Web and legacy systems.

In its last OS update, F5 gave us iControl, which offers the ability to programmatically set traffic processing rules based on highly specific end-user or ISV-derived criteria. While that Simple Object Access Protocol (SOAP)/XML capability has met with mixed reviews because of the complexity of the programming interface, it persists in BIG-IP 9.0. It may not be easy to use for end users, but it does provide detailed control for both legacy applications and for ISVs that have adopted F5's interface.

NEW COMPETITION

Architecturally speaking, it's worth considering solutions such as NetScaler's for help with legacy enterprise applications. For one thing, F5's approach is purely asymmetrical--the BIG-IP switch sits in the data center and does what it can to optimize traffic flows with clients, but it offers no client-side agent to help in the process. NetScaler offers AppCompress, which involves an agent on the client. With AppCompress, NetScaler typically offers two to four times compression on IP traffic, something F5 currently can't do.While F5 lacks a non-HTTP compression solution, the announcement is replete with desirable features. New to F5's repertoire are three categories of features: traffic direction, optimization, and security. While F5 has previously offered some features in each area, traffic direction was clearly its strength, while optimization was particularly limited. In addition to the new functionality, F5 has also updated its management GUI.

Perhaps the most fundamental underlying change to F5's core OS is its ability to manage data as an application flow rather than on a packet-by-packet basis. Direction, optimization, and security all benefit from flow-based traffic management. With it, F5 can terminate both sides of TCP and SSL connections and make optimizations in load balancing, as well as at the protocol level. Both NetScaler and Redline have taken advantage of TCP offload and its ability to save on server overhead for a while now.

Also new to F5 but old hat to NetScaler and Redline is the ability to multiplex TCP connections headed toward the server. Recent market entrant Zeus, a U.K.-based company that's made its name in very-high-performance Web servers, also offers a similar set of features. All four vendors cite the ability to drop the number of connections that servers see by as much as 95 percent. This greatly improves the efficiency of the server and lessens the need for certain application licenses. The gains have been so great that in some cases these boxes pay for themselves in just a few months.

Earlier this year, F5 purchased Magnifire, whose TrafficShield appliance specializes in picking out zero-day Web attacks. While the TrafficShield technology hasn't been integrated with this release of BIG-IP, there's clearly a good deal of attention to security in F5's announcement. Among the new security features cited by F5 are source masking (hiding the identity of source servers), cookie encryption, early user authentication, firewalling, and protocol sanitization.

What F5 is missing, however, is the caching capability found in the Zeus, NetScaler, and Redline products. While F5 currently relies on external caching systems, internal caching is on its roadmap. At first blush, this may seem a reasonable piece of work to save for later, but the competition offers highly sophisticated caching systems. Redline in particular announced version 4.0 of its software last month. The new version now fully integrates its caching system, allowing the use of Redline's OverDrive rules to override the default cacheability settings of Web content.One other area where F5, Zeus, Redline, and NetScaler diverge is in their redundancy and failover schemes. Redline and Zeus are the most advanced with N+1 and N+M active failover schemes, respectively. F5 supports 1+1 active failover, and NetScaler supports an active/passive configuration. The Zeus and Redline approaches permit clustering of their boxes, which yields a highly scalable architecture.

While there's still a place for server load balancing as performed by Cisco, Nortel, and Foundry, virtually any environment will benefit more from the capabilities found in NetScaler, Redline, Zeus, and now F5's updated product line. The choice of which vendor to choose depends on the problem at hand and your predisposition toward dealing with relatively young or small companies. NetScaler's symmetrical compression and evolved caching architecture make it a fine choice for enterprises looking to improve the performance of both legacy and Web applications. Redline's focus on the Web tier, its high-quality caching and compression, and its superior failover scheme make it a good choice for enterprise Web-based applications.

Finally, Zeus has produced a software-only application front end that's optimized for dual Opteron systems. Its performance numbers and feature set compete with and often exceed its appliance-based competition. One of Zeus' most interesting features is its ability to process XML XPath routing, a feature that's either on the drawing board of the competition or left to partners. This makes Zeus an interesting possibility for those who are heavily into the Web services model. Zeus uses no SSL acceleration hardware, so its SSL numbers are lower, but still quite impressive nonetheless.

Even with this announcement, F5 still has some ground to make up. But if you're looking for a market-leading vendor with a good platform and room to grow, F5 increasingly stands by itself. Add to that its unique iControl product and the possibility of better integration with Magnifire, and there's plenty to like about F5.

Editor-in-Chief Art Wittmann can be reached at [email protected].

Inside the Hardware

F5 is also updating its hardware. The company announced two new ASICs that give its systems exceptional marks in processing layer-4 requests and SSL acceleration. Those ASICs are available in F5's high-end offerings, with three new products being announced. These range from a four-copper, two-optical port version at the low end to a dual processor 16-copper, four-optical port system at the high end. F5's new OS software will run on these new systems, as well as on the 1000, 2400, and 5100 platforms.

Whether or not those ASICs are an advantage for F5 is arguable, however. Both NetScaler and Redline use off-the-shelf Intel-based hardware and have benefited from Intel's ever-increasing performance curve. Zeus runs on virtually any box, with significant optimization for 64-bit dual Opteron systems. For Zeus, upgrading performance can be as simple as buying new hardware. The integration of F5's ASICs is less important than it was in the mid-1990s, both because the core CPU is so much faster and because there's far less packet switching and far more layer-7 inspection going into current application front-end architectures.

About the Numbers

While the performance numbers provided by the vendors are probably observable, they aren't indicative of real-world performance. For instance, maximum caching performance is realized by simulating a million or so machines requesting the same Web page, which happens to be the only one sitting in cache. The vendors will readily admit that real-world numbers are substantially lower. Lower numbers on this chart aren't necessarily an indication of lower real-world performance, but rather a more reasonable assessment of actual performance.Even taking a conservative stance and trimming these numbers by a factor of 10, each of these boxes will likely fill a couple of T3 lines, and that's a lot of Web traffic. In cases where more performance is needed, systems will likely be architected so as to divide the traffic among multiple sites, or to chop it up in some other way. Our advice: Look at the feature sets, not the performance numbers. It's not a matter of how fast the cache is, but how cleverly it's implemented.

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like


More Insights