- Silicon Valley's 19 Coolest Places to Work
- Is Windows 8 Development Worth the Trouble?
- 8 Books Every IT Leader Should Read This Year
- 10 Hot Hadoop Startups to Watch
Page 2 of 4
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.