Skip Links

How we tested Juniper's switch

By , Network World
July 14, 2008 12:36 PM ET

Network World - 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. A detailed, complete methodology is available here.

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.

Our Commenting Policies
Latest News
rssRss Feed
View more Latest News