Juniper SRX 5800: Biggest firewall ever
But tests show issues with security reporting and manageability
By
David Newman
and
Joel Snyder
,
Network World
, 02/23/2009
- Share/Email
- Tweet This
- Print
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 5800Archive of Network World testsManageability problems with Juniper's firewall
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.
Comments (27)
WOWBy Anonymous on February 23, 2009, 2:41 pmYet anopther device rushed to market before it's really ready for the enterprise!
Reply | Read entire comment
UNREALBy Anonymous on February 23, 2009, 4:15 pmCome on guys...-- Time to upgrade your test bed... you basically tested the SRX with UDP traffic and 16 UDP attacks? This is a high performance, application aware...
Reply | Read entire comment
Shows the importance of realisim in testingBy Kyle Flaherty on February 23, 2009, 5:25 pmReading this review today I couldn't help but notice how it missed the boat on realistic testing (including Layer 4-7 app traffic) and was shocked in its complexity...
Reply | Read entire comment
I don't get "missed the boat?"By Marco Parity on February 23, 2009, 5:31 pmKyle: Don't you think that HTTP counts as L4-7 testing? I don't get what you don't get. Marco
Reply | Read entire comment
regarding BPS commentBy Anonymous on February 23, 2009, 7:23 pmBPS is really trying to make a stick and they got it wrong
Reply | Read entire comment
L4-L7 Testing BlogBy bwolmarans on February 23, 2009, 7:35 pmWell, I just found this new blog http://l4l7-thoughts.blogspot.com/ it looks promising. At least it's well written.
Reply | Read entire comment
View all comments