But tests show issues with security reporting and manageability
If the Guinness Book of World Records had an entry for "biggest firewall ever," Juniper's new SRX 5800 would certainly qualify.
How we tested Juniper's SRX 5800
In our exclusive Clear Choice test, this hulking brute of a machine sped traffic at rates approaching 140Gbps through its 16 10Gigabit Ethernet interfaces, making it by far the largest and fastest firewall we or anyone else has ever tested.
But "biggest" isn't the same as "most capable." For example, enabling intrusion prevention caused forwarding rates to drop to 30Gbps, even when handling only benign traffic.
And there were issues with security policy management. The Network and Security Manager (NSM) appliance Juniper supplied doesn't yet accept security alerts from the SRX. In other words, it's a security management platform that won't say how or even whether the network is under attack.
As a firewall, the SRX/NSM combo is fine, even for managers of the very largest networks. But because of the lack of security alerts and some serious usability drawbacks in the NSM, we can't yet recommend the system as a combined firewall/IPS.
What a chassis
The SRX 5800 is a chassis-based system. Pre-populated with two switch control boards to manage inter-card communications, it's up to the customer to insert I/O cards or Service Processing Cards (SPC) as needed. The I/O cards come in two flavors: four-port 10G Ethernet or 40-port 1-gigabit Ethernet. You can mix and match I/O cards with the SPCs, which handle services such as firewall and intrusion prevention.
While this system is clearly aimed at nonstop environments, Juniper hasn't gotten all of its hot-swap technology in the single-chassis version. You can't insert or remove cards without interrupting traffic flow. Juniper's solution is chassis clustering -- linking two of these monster boxes into a cluster that lets you take a chassis down for maintenance, upgrade or repairs, while still passing traffic.
The SRX's operating system is JunOS through-and-through, with firewall and intrusion prevention features from Juniper's NetScreen acquisition layered on top. If you like managing routers from the command line and have a modest firewall policy, you'll take to the SRX 5800 right away. It's got the JunOS you love, a rock-solid stateful firewall and the fastest performance of any firewall on Earth.
When Juniper initially told us it would supply its SRX 5600 firewall, a 60-Gbps system, we sized our test bed accordingly. So it was a bit of a surprise when Juniper instead sent the larger SRX 5800, which the vendor's data sheet lists as a 120-Gbps firewall. Both systems support up to 16 10G Ethernet interfaces, but the 5800 offers twice the forwarding capacity – and twice what our test bed could generate in terms of TCP traffic. Juniper populated this chassis with eight of its dual-CPU Service Processing Cards, completely filling the 14-slot chassis.
Although the test bed at Spirent's Sunnyvale SPOC lab offered "only" 80Gbps of TCP traffic for this particular project (using 16 Spirent Avalanche 2900 appliances), we were able to fully exercise the SRX 5800 by offering up to 160Gbps of stateless UDP traffic (using a Spirent TestCenter traffic generator/analyzer). We ran separate sets of TCP and UDP tests, and assessed the system's features and usability.
The UDP tests demonstrated the SRX 5800's high capacity. In tests with maximum-length 1,518-byte frames, the firewall's throughput was more than 137Gbps, with average latency of 76 microsec. Enabling network access translation (NAT) on the firewall exacted no performance penalty; both throughput and latency were virtually identical as in the no-NAT case.
The system was far slower when handling 64- and 256-byte frames, with throughput of 6.9G and 29Gbps respectively. Average latency was also higher, at 152 and 292 microsec for 64- and 256-byte frames.
But lower performance with UDP isn't necessarily a problem for most users. UDP represents 5% or less of total Internet traffic, according to samples observed by CAIDA and other sources. TCP forwarding capability is a far more meaningful performance metric for most security devices.
To assess TCP performance, we configured the Spirent Avalanche appliances to act as Web clients and servers, with 2,400 emulated users each requesting 512-kbyte objects through the firewall. We ran this test repeatedly, in a variety of configurations.
* As a firewall alone, the SRX 5800 is a stellar performer. It moved HTTP traffic at an aggregate rate of 78Gbps, the maximum possible from our test bed. We didn't enable NAT, but given the results of our UDP tests we don't believe there would be any performance penalty for doing so. Response times held steady throughout the test, with users getting their objects in an average of 131 millisec.
* When we enabled intrusion prevention, it was a very different story. Aggregate forwarding rates plummeted from 78Gbps to around 30Gbps even with no attack traffic present. We enabled the 252 attack signatures Juniper recommends, those representing major and critical events. Again, this test was run only with benign traffic. Thus, users who need intrusion prevention can expect a major performance hit even before any attacks come along. This performance hit was not unexpected, though: Juniper's own data sheet offers 30Gbps as the speed to expect with the SRX 5800.
* Running the same configuration with NAT and intrusion detection produced virtually the same result as intrusion prevention alone. Moreover, response times were only marginally higher than when the SRX was configured as a firewall alone, with users getting their objects in 160 millisec or less.
However, these tests were all done with Juniper's "Recommended" IPS policy, a carefully selected and tuned policy designed to balance security with connectivity and performance. One important part of these policies is that they are focused on client-to-server interactions. In other words, they identify malicious traffic aimed at servers but do not catch server-to-client malware. Because our test traffic was largely HTTP, that means the IPS spent most of its time looking at attack traffic to the Web servers, only about 650Mbps. The rest of the traffic, over 29Gbps, coming from the Web server, while subject to some inspection for protocol anomalies and other lower-layer attacks, was not examined in-depth by the IPS.
* When we added in server-to-client protections from their IPS signature library, performance dropped even further, to as little as 8Gbps. The lesson is clear: be very careful what IPS policy you use, because picking the wrong elements can dramatically affect performance.
IPS tests with actual attacks
If packet inspection alone caused a traffic slowdown, we were interested to see what would happen if we put the SRX firewall under actual attack. Would it slow down even further? Or would it shed the attacks with no additional impact? Using a Spirent ThreatEx security assessment tool, we aimed 13 UDP-based attacks at targets behind the SRX firewall while continuing to offer benign Web traffic from the Avalanche appliances.
Unfortunately, because of problems in the testbed, which were only uncovered long after testing was completed, we don't have any performance numbers while the Juniper product was under attack to share with you. However, we did not identify these issues with the testbed in time to stop the inaccurate results from being published in the print edition of this article. Those results should be disregarded. We apologize to both Juniper and to our readers for the error.
We hope to work with Juniper in the near future to re-test the SRX firewall/IPS while under attack so that we can better determine system performance in that use case.
IPS management falls short
As part of the integration of firewall, VPN and IPS security features from its Netscreen product line into JunOS, Juniper has extended its security management tool, Netscreen Security Manager, to cover the JunOS platform, while re-badging the product as Network and Security Manager.
While trying to manage the SRX 5800, we found ourselves stumbling through an unusable configuration interface and inconsistent attack databases. Worse, we were completely blind when it came to IPS management, an unacceptable position. The combination of poor IPS performance along with difficult configuration and nearly impossible management suggest that while the SRX 5800 may be a fine, speedy firewall, the IPS should not be used until Juniper resolves significant and substantial manageability problems.
Snyder is a senior partner at Opus One in Tucson, Ariz. He can be reached at email@example.com. Newman is president of Network Test, a benchmarking and network design consultancy. He can be reached at firstname.lastname@example.org.
Network World gratefully acknowledges the support of Spirent Communications, which made this project possible. Spirent supplied its Sunnyvale SPoC lab for testing as well as its Avalanche, ThreatEx and Spirent TestCenter instruments. Many Spirent employees offered engineering and logisitical support, including Daniel Agcaoili, Jeff Brown, Chris Chapman, Dinkar Chivaluri, Ambar de la Cruz, Mike Jack, Michael Lynge, Charles McAuley, Thuy Pham, Timmons Player, Michelle Rhines and Navin Tekchandani.
Newman and Snyder are also members of the Network World Lab Alliance, a cooperative of the premier reviewers in the network industry each bringing to bear years of practical experience on every review. For more Lab Alliance information, including what it takes to become a member, go to www.networkworld.com/alliance.
Bryan Lunduke talks with Martin Wimpress—the man behind Ubuntu MATE—about why he decided to make his...
I love my iPhone 6 Plus—and that’s Apple’s problem.
The Internet of Things is predicted to grow to a $1.4 trillion market by 2020, which means there are...
The website of toy maker Maisto was infected with malicious code that distributed CryptXXX, a new and...
Follow these steps to reap the benefits of SDN without disrupting your IT environment
Three ways to respond to demands for a fast, iterative, rapid-feedback monitoring solution
Flame wars in the bug tracker might be exactly the right (harsh) feedback your code needs