How we tested Juniper's EX 4200
In Network World's exclusive Clear Choice test, we subjected the EX 4200-48T switch to the same rigorous battery of benchmarks we used to assess seven other vendors' 10G Ethernet access switches earlier this year. (See comparative 10G Ethernet switch test.)
The verdict: This is one fast box. The EX 4200 delivered line-rate throughput in every case, the only switch we've tested this year to do so. What's more, 10G Ethernet latency is the lowest we've ever measured. We also were impressed by the EX 4200's feature set and powerful JUNOS command-line interface (CLI).
That's not to suggest Cisco and others should fold up their tents, though. This is Juniper's first effort in enterprise switching, and that inexperience shows in a few places. Multicast support is still a bit rough, and our tests also uncovered a couple of security concerns. Still, this is an impressive device, especially for a first try. (Compare products.)
We tested the $16,800 EX 4200-48T, which offers 48 10/100/1000Mbps gigabit ports, two 10G Ethernet ports, PoE capability on 8 ports, and stacking capability for up to 10 switches. Juniper also offers the EX 4200-48P with 48 ports of PoE capacity from a single power supply for $18,400. Both devices offer optional redundant power supplies and support virtually all switching and routing protocols (see Features spreadsheet).
In access switch tests earlier this year we found throughput no longer is the differentiator as it once was, with most boxes pushing packets either nearly at, or within one percent of, line rate.
With Juniper's EX 4200, there's no need to say "nearly". Even under the heaviest loads our Spirent TestCenter traffic generator threw at it, the switch delivered line-rate throughput in every single unicast and multicast test, both in layer-2 and layer-3 configurations. No other switch did that.
Latency – often a more important metric than throughput, especially for time-sensitive voice and video traffic – was low and consistent across all tests. Measured at line rate, the Juniper switch delayed 64-byte frames across 10G Ethernet links for an average of 1.96 microsec and a maximum of 2.01 microsec.
Those are the lowest latencies we've ever recorded in an Ethernet switch. In fact, even the maximum latency of the EX 4200 is less than the lowest average result we measured in the previous round of tests.
With large 1,518-byte frames, latencies hovered in the 2 to 3 microsec range on 10G Ethernet ports and in the 20 to 30 microsec range on gigabit Ethernet ports. The gigabit numbers are either comparable to or better than most other switches we've tested; the 10G Ethernet latencies, again, set record lows.
Multicast latency also hovered in the low microseconds, compared with numbers that in some cases were dozens of times higher in previous tests. The Juniper switch won't hold up traffic long enough to adversely affect the performance of any enterprise application.
Multicast growing pains
While the EX 4200 put up stellar numbers in the throughput and latency benchmarks, testing also made clear that its multicast code is newer and less robust than other parts of the system.
First the good news. The switch fared well in a test of multicast group capacity – the maximum number of IGMP groups the device can concurrently support. The EX 4200 moved traffic to 1,001 IGMPv2 groups – around 500 less than the leader of the previous tests, the HP ProCurve 3500yl, but still good enough to rank the Juniper switch second in multicast group capacity among access switches we've tested this year.
But multicast testing also revealed some rough spots. First and most seriously, the switch spontaneously rebooted once during layer-3 multicast tests. Granted, these were stress tests, and Juniper's system certainly isn't the first we've caused to reboot while running multicast benchmarks. But the others were over their multicast group counts limits at the time, while the 500 groups used in this test should have been no problem for the Juniper switch. And in any event, a switch should never spontaneously reboot, no matter how burdensome the load.
Second, we tested other switches using IGMPv3, the current version of that protocol. The Juniper software version we tested supported IGMPv2, though the vendor says it's working to add IGMPv3 support later this year. As described in RFC 3376, Appendix B, IGMPv3 offers numerous improvements over IGMPv2. Chief among these are source filtering and the ability to monitor group states based on source plus group address. This latter feature is helpful in situations where transmitters or receivers in different groups share common switch ports.
Third, in initial testing the switch created duplicate copies of some multicast traffic, rendering results invalid. Juniper quickly issued a new software build (already available to customers at press time) that corrected a problem when the switch ran in standalone rather than stackable mode. We verified that the new software eliminated duplication.With interest growing in multicast, especially in certain vertical industries such as financial services, these misadventures may pose a cause for concern. Still, given Juniper's rapid response on the duplication issue and its ongoing multicast development, we don't consider any of these bugs to be showstoppers.
In what's become a regular part of device testing, we also measured the EX 4200's power consumption, when idle and when maxed out.
Using a Fluke 335 clamp meter, the Juniper switch consumed 185 watts when idle and 199 watts when its control and data planes were fully loaded. In comparison, the average consumption across seven other 10G Ethernet access switches were 150 and 174 watts for idle and full loads, respectively.
That puts the Juniper switch on the power-hungry side of average. It's nowhere near the maximum draw of 316 watts (from a fully loaded Foundry FastIron Edge X448) but also far from the paltry 79 watts consumed by an idle Alcatel-Lucent OmniSwitch 6850.
Considering Juniper's longtime advocacy of network access control (NAC), it's not surprising that the EX 4200 did well in our authentication tests. The switch passed all six scenarios, five of which used 802.1X. These tests examined authentication into a statically defined virtual LAN; authentication of multiple clients per port; authentication into a dynamically allocated VLAN; authentication with dynamically applied access control lists (ACL); and placement into a restricted VLAN upon authentication failure.
In the ACL test the switch applied rules previously defined on the switch; this is far less cumbersome than the approach taken by some other switches, where ACLs must be entered into the RADIUS server then returned to supplicants during authentication.
The switch also passed a sixth test involving authentication by a media access control (MAC) address; this scenario represents the case where an end-station, such as a printer, lacks 802.1X supplicant software. One catch here was that the switch's CLI did not display clients currently authenticated by MAC addresses, as it did with 802.1X-authenticated clients. Juniper says it expects an August software release to remedy that.
The Juniper switch passed all access control tests with minor configuration changes needed for each scenario. In comparison, Cisco’s Catalyst 3750E required no configuration changes for any of our scenarios except for multi-auth. Then again, the Cisco switch failed the multi-auth test, authenticating only the first user and forwarding unauthenticated traffic from the second and subsequent users. Few other switches we’ve tested (Extreme’s Summit X450 and Foundry’s FastIron Edge X448 are exceptions) passed all these test cases, with or without configuration changes.
Like other enterprise switches deployed at the edge of corporate networks, the EX 4200 offers a "storm control" feature to limit rates of potentially malicious traffic. We tested this feature using two denial-of-service (DoS) attacks, a broadcast storm and a SYN flood, and found the switch blocked broadcasts but forwarded SYNs.
For both tests, we configured a Mu Dynamics Mu-4000 security analyzer to generate DoS attacks at 100,000 frames per second, and then configured the Juniper switch to restrict such traffic to 1% of line rate, or around 1,500 frames per second. Using Spirent TestCenter's real-time rate counters, we verified that the Juniper switch did rate-limit broadcast traffic.
However, the switch didn't control the rate of Mu's SYN flood attack. Juniper says the current JUNOS release imposes rate controls only on broadcast and unknown unicast traffic (that is, traffic with no existing entry in the switch's MAC address table). That makes storm control useful in thwarting "bot" attacks against random, unknown destinations. It's not useful in stopping an attacker targeting specific servers.
Manageability and usability
Assessing switch manageability is a two-part affair, with objective and subjective components. The objective part is easy, because it's based on empirical observations: We verified the EX 4200 supports management over IPv4 networks via SNMP, telnet, Secure Shell, Web, SSL and syslog. Commendably, none of these methods are enabled by default, and each (along with an FTP server) can be individually toggled on and off.
In terms of usability, the JUNOS CLI very easy to operate, even though our experience with JUNOS was limited and dated going into this test.
Unix geeks are sure to appreciate JUNOS's FreeBSD heritage; indeed, the system's CLI is a process running atop a C shell that users can drop into. The CLI also supports matching of output against regular expressions, and the syntax of many configuration parameters resembles that of many Unix configuration files. Anyone who's spent significant time in a Unix or Linux shell probably will feel at home with the JUNOS CLI.
IPv6 isn't yet fully supported in the EX line. The switch does not yet support routing of IPv6 traffic (this is slated for a release by year-end), though of course L2 switching is possible. Switch management over an IPv6 network is possible, but Web and SSL access methods aren't supported.
Not quite reset
Our final check of device management involved a factory reset, which is generally considered a best practice when decommissioning a device (it's also a regulatory requirement in some industries).
Juniper offers four reset methods: There's a front-panel LED option, a CLI command and USB and TFTP file transfers of a new image. Unfortunately, the easiest of these – using the front-panel LED menu – doesn't fully restore the switch to its factory settings. After the reset, we found SSH keys and configuration files we'd previously stored. The USB and TFTP downloads actually do overwrite the existing file system. In any event, users are well advised to verify that any reset device really has been wiped clean.
Even considering the few shortcomings we found, the EX 4200 turned in solid results for a new product – more solid, in fact, than some other vendors' third or fourth efforts. While Juniper clearly still has work to do, especially in its multicast code, the EX 4200 represents a real challenge to Cisco for enterprise access switching.
Newman is president of Network Test, an independent test lab in Westlake Village, Calif. He can be reached at firstname.lastname@example.org.
Thanks gratefully acknowledges the test equipment vendors that supported this project. Spirent Communications supplied its Spirent TestCenter Gigabit and 10 Gigabit generator/analyzer. Mu Dynamics provided its Mu-4000 security and protocol conformance analyzer. Juniper provided Steel-Belted Radius Enterprise Edition 6.1 and Odyssey 802.1X client software for 802.1X testing. And Fluke provided Fluke 322 and 335 clamp meters for measuring power consumption.
Newman is also a member 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.