How we tested Juniper's switch
By
David Newman
,
Network World
, 07/14/2008
- Share/Email
- Tweet This
- Print
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.
Partner Content
Simplify Your Branch Infrastructure
Learn how to simplify your branch infrastructure while dramatically increasing app performance with Citrix Branch Repeater.
Download the Free Info Kit
Next-Gen Load Balancing
Free Guide: "Next Gen Load Balancing: 8 Things You Need to Handle Today's Network Traffic" shows you the functionality needed in your next load balancer.
Download the Free Guide
Accelerate Your Web Apps by up to 5x
Free Guide: "The Secret to Getting Maximum Speed from your Web Applications."' Learn how you can deliver Web apps up to 5x faster.
Download the Free Guide
Comment