If the Guinness Book of World Records had an entry for “biggest firewall ever,” Juniper’s new SRX 5800 would certainly qualify.
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.
Performance metrics
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 comp
