Juniper switch proves to be credible choice
- 15 July, 2008 09:10
Cisco take note: Juniper's new EX 4200 switch not only fills a hole in a leading competitor's product line, but also represents a credible alternative for enterprise access switching.
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.
We tested the US$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.
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.
How we tested Juniper's switch
We assessed Juniper's new enterprise switch using the same methodology we previously used to test other vendors' access switches. The one exception, as noted below, was in our use of IGMPv2 instead of IGMPv3 this time around.
This methodology comprises 10 sets of tests covering L2 and L3 unicast performance; IGMP group multicast capacity; L2 and L3 multicast performance; network access control (NAC)/802.1X; storm control; power consumption; switch manageability, security, and usability; and switch features.
In the L2 unicast performance tests, we configured each switch with a single virtual LAN (VLAN) encompassing all ports. We attached a Spirent TestCenter generator/analyzer to all 48 gigabit Ethernet and two 10-Gigabit ports on the switch and ran three sets of tests: all ports, gigabit ports only, and 10-Gigabit ports only. We offered traffic to the gigabit ports in a fully meshed pattern and to the 10-Gigabit ports in a meshed pattern. For each test, we conducted separate 60-second runs with 64-, 256- and 1,518-byte frames, and measured throughput, average latency and maximum latency for each frame length.
The L3 unicast performance tests were similar to the L2 unicast tests, except in this case we configured each switch port to use a different VLAN and IP subnet.
In the IGMP group capacity tests, we reverted to an L2 configuration, enabled IGMP snooping, and set the switch to act as an IGMP querier. In this test, 47 of 48 TestCenter gigabit Ethernet ports joined some number of IGMPv2 groups; the 48th TestCenter port acted as a monitor to detect flooding.
After sending group membership (join) messages and waiting at least twice the switch's IGMP query interval, TestCenter's ScriptMaster software then offered multicast traffic to the switch's first 10-Gigabit port, destined for all multicast groups. Per RFC 3918, if all groups received at least one frame, the test iteration was considered a pass. If loss or flooding occurred, the iteration was considered a failure. Using a binary search algorithm, we repeated this procedure to determine multicast group capacity.
In the L2 multicast performance tests, we configured all switch ports to join a single VLAN, to use IGMP snooping, and to act as an IGMP querier. Then TestCenter's 48 gigabit ports joined 500 IGMPv2 groups (or fewer, depending on results from the group capacity test). The Juniper switch did not support IGMPv3 at test time, requiring the use of IGMPv2; this is the one significant departure from earlier tests of access switches.
After waiting at least twice the switch's IGMP query interval, TestCenter's ScriptMaster software then offered multicast traffic to the switch's first 10-gigabit port, destined for all multicast groups. Using a binary search algorithm, TestCenter determined the throughput rate. In a separate test, TestCenter measured average and maximum latency at the throughput rate.
In the L3 multicast throughput and latency tests, we configured each switch port to use a separate VLAN and IP subnet, enabled protocol independent multicast-sparse mode routing on each port, and set the switch to act as a PIM rendezvous point. The test setup and traffic pattern was similar to the L2 multicast test. We again determined the throughput rate and measured average and maximum latency at that rate.
To assess 802.1X/NAC support, we developed six scenarios that describe roles a switch might play as part of the NAC infrastructure. In this case we attached the switch to a Windows 2003 server running Juniper Steel-Belted Radius Enterprise Edition 6.1 (SBR). The SBR configuration used Windows Active Directory credentials to authenticate users.
In the first scenario, the switch places an authenticated client (in all cases, a PC running Windows XP Professional and Juniper Odyssey client software) into a previously configured VLAN. The second case is like the first, but requires authentication of multiple clients attached to a single port. In the third case, the switch dynamically assigns a VLAN after authentication. In the fourth case, the switch dynamically applies an access control list after authentication. In the fifth case, the switch places a client into a guest or restricted VLAN upon authentication failure. Finally, the sixth case determines whether a switch port concurrently supports 802.1X and media access control authentication support.
To assess storm control, we used common attack techniques such as broadcast and TCP SYN flooding as generated by a Mu Dynamics Mu-4000 security analyzer and by Spirent TestCenter. We configured the Juniper switch to limit forwarding rates of attack traffic, and verified these limits using real-time rate counters in Spirent TestCenter.
We measured power consumption using Fluke 322 and Fluke 335 clamp meters. This test involved three measurements: AC line voltage; AC amperage when idle; and AC amperage when fully loaded. We fully loaded the switch control and data planes by configuring Spirent TestCenter to offer traffic at line rate to all ports consisting of IPv4 packets with IP options set. We derived wattage by multiplying voltage and amperage.
Our tests of switch manageability, security and usability had objective and subjective components. In the objective component, we determined which management methods the switch supported over IPv4 and IPv6, as well as its ability to conform to best security practices (for example, by disabling vulnerable services such as telnet and enabling secure service such as SSHv2). We also determined which management methods were enabled by default, and which could be enabled/disabled by users. In addition, we determined whether erasing configuration files would remove all personally identifiable information, a regulatory requirement and security best practice.
The subjective part of our assessment consisted of our judgments on ease of accomplishing these and all other tests described here.
To assess the final area, switch features, we asked vendors to complete a detailed questionnaire. We did not verify every answer to this questionnaire.
Newman is president of Network Test, an independent test lab in the US. He can be reached at firstname.lastname@example.org.