How we tested the stackable Cisco Catalyst 3750.
We loaded three switches in a rack as follows.• Top switch – 3750G-24T (24 port 10/100/1000BaseT)• Middle switch – 3750-24TS (24 port 10/100BaseT with 2 gigabit SFP GBIC ports)• Bottom switch – 3750G-24TS (24 port 10/100/1000BaseT with 4 gigabit SFP GBIC ports)
All switches were connected in a ring using the stack connections.
All switches were running the Cisco IOS 12.1(0.151)AX software image.
All tests were executed using a Spirent SMB 6000 chassis with one two-port Terametrics 10/100/1000BaseT card, four, six-port Smartmetrics 10/100BaseT cards, and 15 two-port Smartmetrics 10/100/1000BaseT cards. Spirents’ Smartwindow, Smartflow, and TeraRouting test applications were used in the testing. We ran four categories of tests – stack functions, performance, redundancy, and management. The following lists the test methodology by category.
Stack Function Tests
Replicated Console Port
The serial connection was moved between the console ports on each of the switches in the stack. The user interface was identical in each case.
Reboot Time
The reboot times were measured for the following cases.• Single switch with configuration• Single switch with no configuration• 3 switch stack with configuration
Switch Renumber
The purpose of this tests is to observe what happens when the switches in a stack are renumbered. Each switch was renumbered as follows.• Top switch renumbered from 2 to 1• Middle switch renumbered from 5 to 2• Bottom switch renumbered from 1 to 3
The switches were renumbered using the ‘switch
This operation required a reboot of the switches. After rebooting, the interface numbering changed to reflect the new switch numbers, i.e. the second gigabit Ethernet port of the top switch was numbered GigabitEthernet1/0/2. This made all configuration and monitoring operations much easier.
Master Switch Priority
The purpose of this test is to observe the results of changing a switch’s master priority configuration. The master switch priorities were changes as follows.• switch 1 – priority 5• switch 2 – priority 10• switch 3 – priority 15
The following top level configuration command was entered through the CLI – ‘switch
The master priorities were reconfigured as follows.• switch 1 – priority 15• switch 2 – priority 10• switch 3 – priority 5 In this case, switch 1 always becomes the master. After switch 1 is turned off, switch 2 becomes the master. After switch 2 is powered down, switch 3 becomes the master (the only switch left in the stack). The master priorities were then reconfigured as follows.• switch 1 – priority 15• switch 2 – priority 5• switch 3 – priority 10
Switch 1 is always the master after a reboot of the stack. When switch 1 is powered down, switch 3 becomes the master switch.
Redundancy
Redundant Power Supply
This test determines the behavior of the redundant power supply option. The redundant power supply functions were implemented by a Cisco RPS675.
1. Unplug AC power on a switch in the stack (to remove primary power source)
The switch stays up.
2. Push active/standby button on the Cisco RPS675 (to turn off redundant power)
The switch loses power and goes down.
3. Push active standby button on the Cisco RPS675 (to turn on redundant power)
The switch powers on.
4. Plug in AC power on the switch (to resume primary power source)
The switch remains powered up
5. Push active/standby button on the Cisco RPS675 (to turn off redundant power)
The switch remains powered up
Cross Stack Etherchannel
This test determines the ability of the stack to support cross stack etherchannel connections. An etherchannel bundle was configured between a two-switch stack and another 3750 switch. Four ports from each switch in the stack were connected to eight ports on the single switch. These eight links were configured to be members of one logical etherchannel bundle. The logical etherchannel port and a gigabit port were added to a vlan on the stack and the single switch. Traffic was configured to fill the etherchannel. Links were removed to show the continued flow of traffic with reduced bandwidth.
Performance
Throughput
This test determines the throughput performance of the stack ring. The maximum throughput before loss was measured using two Spirent SMB 6000 chassis with 34 gigabit ports loaded in the chassis. The test was run for 64B, 128B, 256B, 512B, 1024B, 1280B, and 1518B packet sizes. The three Cisco switches were configured in a stack and 17 ports of both gigabit switches were configured with IP addresses. IP routing was enabled in the stack. The following stack configurations were tested.• Full ring• Ring with fault (one stack connection was unplugged)
Packet Latency
This test determines the packet latency through the stack. The packet latency was measured using two Spirent SMB 6000 chassis with 34 gigabit ports loaded in the chassis. The test was run for 64B, 128B, 256B, 512B, 1024B, 1280B, and 1518B packet sizes. The three Cisco switches were configured in a stack and 17 ports of both gigabit switches were configured with IP addresses. IP routing was enabled in the stack. The following stack configurations were tested.• Full ring• Ring with fault (one stack connection was unplugged)
Management
Cluster Management Services (CMS)
The purpose of this test is to characterize the usefulness of CMS as an administration tool. CMS was used where possible while configuring the stack.
CMS is very similar to CMS reviewed for the Cisco 3550v (See review). CMS is implemented in Java and is served from a web server that runs on the stack.
The Java applet is picky about the browser type and version as well as the version of the browser java plug-in. This is an issue with Java, not CMS. CMS would not support my Apple PowerBook running the latest version of Internet Explorer for OSX. Here is a list of supported OS/browsers.
|
