Table Of Contents
Cisco Release 12.1(8b)E12 Safe Harbor Testing for Financial Enterprise Customers
About Cisco IOS Safe Harbor
Financial Lab Topology
Test Results Summary
Feature Sets Testing
Hardware Redundancy
Fabric Flap
Supervisor Failover
Layer 2 Features
Spanning Tree Protocol
Unidirectional Link Detection-Aggressive Mode
Trunking
Port Aggregation Protocol (Channeling)
VLAN Trunking Protocol
Hardware Forwarding Features
IP Unicast
IP Multicast
Layer 3 Routing Features
Cisco Express Forwarding
Open Shortest Path First
Border Gateway Protocol
Hot Standby Routing Protocol
Enhanced Interior Gateway Routing Protocol
Network Management Features
Simple Network Management Protocol
TACACS
Miscellaneous Features
NTP Basic Functionality
Syslog Basic Functionality
User Datagram Protocol Broadcast Flooding
System Upgrade
Cisco Release 12.1(8b)E12 Safe Harbor Testing for Financial Enterprise Customers
Version History
Version Number
|
Date
|
Notes
|
1
|
November 15, 2002
|
This document was created.
|
Executive Summary
Cisco IOS Safe Harbor is an initiative that provides the global financial services enterprise customer with a stable Cisco IOS 12.1 E version-of-choice. Safe Harbor focuses on satisfying customer quality requirements in key vertical markets. This program links and expands upon several Cisco testing projects, including development, regression testing, and systems testing critical to the success of the financial services business. Safe Harbor is the successful completion of extensive validated testing for each release targeting the financial enterprise market.
The Cisco nEverest program will integrate testing for many diverse vertical markets and will leverage Safe Harbor testing to ensure a "holistic" approach to the general improvement of Cisco IOS software.
This document describes the testing environment, test plans, and results.
This document contains the following sections:
•
About Cisco IOS Safe Harbor
• Test Results Summary
• Feature Sets Testing
• Hardware Redundancy
• Layer 2 Features
• Hardware Forwarding Features
• Layer 3 Routing Features
• Network Management Features
• Miscellaneous Features
About Cisco IOS Safe Harbor
The goal of Cisco IOS Safe Harbor is to provide improved network stability, reliability, and performance with respect to Cisco IOS software. Safe Harbor involves testing the feature sets and protocols in a particular Cisco IOS Release 12.1 E image on the Catalyst 6500 platform to provide high quality code for the financial services business. This combination of features, hardware, and image is tested in a laboratory environment that simulates the financial services business network environment using regularly updated topologies and configurations provided by the financial customer. For information on the hardware tested and the network setup of the test environment, see the "Financial Lab Topology" section.
The groups of feature sets that are tested include the following: hardware redundancy, Layer 2 features, hardware forwarding features, Layer 3 routing features, network management features, and several miscellaneous features. Regression tests are conducted to validate existing features and ensure that functionality is maintained. Negative tests are designed and conducted to stress the features and their interoperability. For information on each feature and its testing, see the "Feature Sets Testing" section.
During the testing, the network is placed under loads that are consistent with those in a financial services network. A standard suite of tools (for example, Netcom Smartbits, IXIA packet generator, or Cisco Pagent) is used to generate network traffic. Network testing includes a combination of automated and manual tests. Simple Network Management Protocol (SNMP) is used to poll the network during the tests, and all tests are analyzed. For a summary of the test results, see the "Test Results Summary" section.
Note Safe Harbor testing does not address issues that might exist in the customer change control and operations processes.
Financial Lab Topology
Figure 1 through Figure 5 show the base Native IOS financial lab topology. The financial services network environment configured in the lab includes the following hardware:
•Forteen Catalyst 6500 switches running Cisco Native IOS Release 12.1(8b)E12 (SH1-97 to SH1-110)
•Two Catalyst 6500 switches that are running Hybrid CatOS 6.3(8) with no routing (Dist A-1 and Dist A-2)
•Pagent test devices to simulate the Internet Service Provider's (ISPs), Area 3, and Area 4, injecting Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), and Enhanced Interior Gateway Routing Protocol (EIGRP) routes
•IXIA test devices to generate simulated customer traffic
The hardware configuration in the financial test lab includes a combination of distributed fabric, fabric-capable, and nonfabric modules.
Note The Switch Fabric Module is supported only with the Supervisor Engine 2 in the Catalyst 6500 series switch.
Basic Topology: Port Channel Deployment
Figure 1 through Figure 5 show the port channel deployment for the Safe Harbor testing. Catalyst 6500 series switches running Native Cisco IOS support both Layer 2 (L2) and Layer 3 (L3) EtherChannels, with up to eight ports aggregated in a single Etherchannel interface. All interfaces in each EtherChannel must be identically configured (the same speed, all Layer 2 or Layer 3, and so on).
EtherChannel load balancing can use either MAC addresses or IP addresses, and either source or destination or both source and destination addresses. The selected mode applies to all EtherChannels configured on the switch.
EtherChannel is a trunking technology that groups together multiple full-duplex 802.3 Ethernet interfaces to provide fault-tolerant high-speed links between switches, routers, and servers. An EtherChannel interface (consisting of up to eight Ethernet interfaces) is treated as a single interface; this is called a port channel.
The port channels configured for Safe Harbor testing are Gigabit EtherChannels (GECs). The following types of GEC port channels are configured and tested for Safe Harbor:
•Layer 3 GEC distributed forwarding card (DFC)
•Layer 3 GEC DFC and non-DFC mixed
•Layer 3 GEC using fabric-capable modules, nonfabric modules, and combinations of both
•Layer 2 GEC using fabric-capable modules, nonfabric modules, and combinations of both
Basic Topology: Routing Protocols
The following routing protocols are configured for Safe Harbor testing:
•BGP
–External Border Gateway Protocol (eBGP)
–Interior Border Gateway Protocol (iBGP)
•EIGRP
•OSPF
Figure 1 through Figure 5 shows the following:
•Where each routing protocol is configured in the basic test lab topology.
•The eBGP and iBGP routing protocol deployment for the Safe Harbor testing.
•The EIGRP routing protocol deployment for Safe Harbor testing.
•OSPF routing protocol areas configured for Safe Harbor testing.
Figure 1 Routing Topology
Figure 2 Quadrant 1 Detailed Interconnections Information
Figure 3 Quadrant 2 Detailed Interconnections Information
Figure 4 Quadrant 3 Detailed Interconnections Information
Figure 5 Quadrant 4 Detailed Interconnections Information
Test Results Summary
Table 1 summarizes the results of all completed testing as part of the Cisco IOS Safe Harbor initiative. Table 1 includes the following information: The feature or function tested, the section that describes the feature set to which the feature or function belongs, the results of the feature or function tests (pass or fail), the component tests for each feature/function, and any DDTS found during the Safe Harbor testing.
Note These test results are specific to the technologies covered and the actual test scenarios in which they were tested. Safe Harbor is designed to cover critical path areas and augment ongoing regression and systems testing.
For a compete list of IOS commands and usage in this document, refer to http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/index.htm.
Feature Sets Testing
Functionality critical to the global financial service business tested for the Cisco IOS Safe Harbor release is described in the following sections:
• Hardware Redundancy
• Layer 2 Features
• Hardware Forwarding Features
• Layer 3 Routing Features
• Network Management Features
• Miscellaneous Features
Hardware Redundancy
Whenever a fault is encountered, the redundant module takes over the functions of the failed hardware module. Testing hardware redundancy for Safe Harbor involves performing various failover scenarios to verify that internal hardware redundancy fails over as expected. The tests described in the following sections were performed:
• Fabric Flap
• Supervisor Failover
Fabric Flap
This test reset the active SFM in the system repeatedly to verify that SFM failover operates as designed. The device under test (DUT) was SH1-103. With an IXIA traffic stream passing through it, the DUT SFM was failed 20 times. Test results included measures of the period during which no traffic was passed and the time required for the failed SFM to come back online to the "standby" state.
Test Plan
The procedure used to perform the hardware redundancy fabric flap test follows:
Step 1 Enter the show memory summary command to take an initial memory snapshot of the DUT. Final memory and CPU utilization results are provided in the last step of this procedure.
Step 2 Verify that the background unicast traffic is flowing (rate = 10,000 packets per second [pps}) from devices Dista-1 (IXIA 13/1) and Dista-2 (IXIA 13/2) to SH1-105 (IXIA 1/1).
Step 3 Configure the ip ospf cost 100 command on the following interfaces to verify that traffic coming from Dista-1 and Dista-2 chooses the path through SH1-103: SH1-104 port-channel 69, port-channel 71; SH1-108 port-channel 169; SH1-110 port-channel 171:
Commands
•ip ospf cost 100
Step 4 Verify that traffic is being switched using the crossbar fabric on device SH1-103:
Commands
•show fabric switching-mode
•show interfaces interface counters
Step 5 Enter the following commands to determine the active SFM in the DUT and reset it:
Commands
•show module
•hw-module module 5|6 reset
Step 6 Track the time stamps between the time it is reset and the time it comes back online and the time required for the standby SFM to become active. Record these values.
Step 7 Repeat Step 5 and Step 6 nineteen times.
Step 8 Determine the total number of packets dropped and calculate the mean for the total test period.
Step 9 Determine the mean down time for the reset module and the mean time that traffic is not passed ( Table 2).
Table 2 Reset Module Mean Down Time and Mean Time Traffic Not Passed
Component
|
Fastest (sec)
|
Average (sec)
|
Slowest (sec)
|
Standby >> Active
|
0.008
|
0.012
|
0.009
|
Reset Recovery
|
25.365
|
0.012
|
25.371
|
Traffic Loss (from Dista-1)
|
-
|
-
|
~1.5
|
Traffic Loss (from Dista-2)
|
-
|
-
|
~1.5
|
Step 10 Use the show memory summary and show processes cpu commands to verify that memory and CPU did not suffer severe or sustained impact during the test on the DUT.
Expected Results
We expect that SFM failover operates as designed after repeatedly resetting the active SFM in the system.
Results
Table 3 shows the fabric flap test results.
Table 3 Fabric Flap Test Results
Tests
|
Results
|
Fabric Flap
|
Pass
|
Supervisor Failover
This test verified the proper operation of redundant supervisors during a series of twenty continual resets. The goal of this test was to verify that the box failed between the supervisors as designed, recovered, and forwarded traffic. This test was further designed to verify that failure operations were within the design guidelines for the applicable hardware and software versions under test. Although this test measured time, it by no means measures the speed at which failover can take place (which is dependent upon the configuration and line cards in the system).
Because both supervisor engines 1 and 2 are covered in this test, two devices were used during this procedure. These devices were SH1-107 (Sup1) and SH1-109 (Sup2). A traffic stream was sent from Dista-1 to Dista-2 at a fixed rate. Configurations were altered so that this traffic stream can go only through SH1-108 or SH1-110, depending on the test being run. The amount of traffic loss during device resets was used to determine the recovery time (failover time).
Test Plan
The procedure used to perform the supervisor failover test follows.
Step 1 For Sup1, enter the show ip route summary command to display some of the factors that may contribute to reload times. Such factors may include configuration size, memory used, size of the IP routing table:
Commands
•show ip route summary
•show processes memory | include Used
•directory nvram:
•show running-config
Step 2 Shut down interface port-channel 10 on device SH1-107, which will ensure that the traffic generated in Step 3 goes through SH1-108 to get to its destination.
Step 3 Begin an IXIA traffic stream (1.6 million packets) from Dista-1 to Dista-2. Send this traffic at a rate of 10,000 pps.
Step 4 Issue the reload command on SH1-108.
Step 5 Measure the period of time between when traffic stopped and it was started again. This period of time is considered the failover time.
Step 6 Repeat Step 1 through Step 4 ten times, recording the failover times. The following is raw data for repeated Steps 2 to 10 (see Table 4).
Table 4 Supervisor1 (SH1-108) Summarized Results
Component
|
Fastest (sec)
|
Average (sec)
|
Slowest (sec)
|
Failover time
|
138.3
|
139.0
|
139.8
|
Step 1 For Sup2, enter the show ip route summary command to display some of the factors that may contribute to reload times. Such factors may include configuration size, memory used, and size of the IP routing table:
Commands
•show ip route summary
•show processes memory | include used
•directory nvram:
•show running-config
Step 2 Shut down interface port-channel 20 on device SH1-109 which will ensure that the traffic generated in Step 3 goes through SH1-110 to get to its destination.
Step 3 Begin an IXIA traffic stream (1.2 million packets) from Dista-1 to Dista-2. Send this traffic at a rate of 10,000 pps.
Step 4 Enter the reload command on SH1-110.
Step 5 Measure the period of time between when the traffic stopped and when it was started again. This period of time is considered the failover time.
Step 6 Repeat Step 1 through Step 4 ten times, recording the failover times. The following is raw data for repeated Steps 2 to 20 (see Table 5).
Table 5 Supervisor2 (SH1-110) Summarized Results
Component
|
Fastest (sec)
|
Average (sec)
|
Slowest (sec)
|
Failover time
|
87.1
|
94.8
|
108.9
|
Expected Results
We expect that failure operations are within the design guidelines for the given hardware and software versions under test with no configuration or functionality loss.
Results
Table 6 shows the supervisor failover test results.
Layer 2 Features
Layer 2 feature testing for Safe Harbor involves the features:
• Spanning Tree Protocol
• Unidirectional Link Detection-Aggressive Mode
• Trunking
• Port Aggregation Protocol (Channeling)
• VLAN Trunking Protocol
Spanning Tree Protocol
The spanning-tree algorithm provides path redundancy by defining a tree that spans all of the switches in an extended network and then forces certain redundant data paths into a standby (blocked) state. At regular intervals, the switches in the network send and receive spanning-tree packets that they use to identify the path. If one network segment becomes unreachable, or if spanning-tree costs change, the spanning-tree algorithm reconfigures the spanning-tree topology and reestablishes the link by activating the standby path. Because this feature has limited use in the financial customer networks, it received limited coverage in testing here.
The following test was performed:
• Basic Spanning Tree Protocol Configuration
Basic Spanning Tree Protocol Configuration
This test tested the basic functionality of the Spanning Tree Protocol (STP), including verifying that the various STP states occurred within the defined times; that STP properly converged, with all switches pointing to the correct device as root; and that the CPU did not reach unreasonable levels. The DUTs are SH1-109, SH1-110, and Dista-2.
Note The coverage of STP in Safe Harbor testing for Native IOS is limited because the implementation of STP is limited in the network of Cisco customers.
Test Plan
The procedure used to perform the basic Spanning Tree Protocol configuration test follows.
Step 1 Enter the show memory summary command to take an initial memory snapshot of devices SH1-109 and SH1-110. Final memory and CPU utilization results are provided in the last step of this procedure.
Step 2 Verify that trunk links are configured between SH1-109 and Dista-2 and also between SH1-110 and Dista-2, and that they are trunking VLANs 10-20 by using the following commands:
Commands
•show interfaces interface trunk
•show trunk mod/port
Step 3 Verify that SH1-110 is the root switch for VLANs 10-20 using the show spanning-tree root command:
Commands
•show spanning-tree root
Step 4 Disable the EtherChannel between SH1-110 and Dista-2.
Step 5 Verify that STP has converged with the new topology (no SH1-110) and that SH1-109 is now root for VLANs 10-20 using the show spanning-tree root command:
Commands
•show spanning-tree root
Step 6 Reenable the channel that was disabled in Step 4.
Step 7 Verify that STP reconverges with SH1-110 once again as root. Make certain that the convergence times did not exceed configured specifications:
Commands
•show spanning-tree root
Step 8 Use the show memory summary and show processes cpu commands to verify memory and CPU utilization results for devices SH1-109 and SH1-110.
Expected Results
We expect spanning-tree recalculation occurs in an anticipated time frame. This value depends on the parameters of the spanning-tree domain.
Results
Table 7 shows the basic Spanning Tree Protocol configuration test results.
Unidirectional Link Detection-Aggressive Mode
The Unidirectional Link Detection-Aggressive Mode (UDLD-AM) protocol allows devices connected through fiber-optic or copper Ethernet cables (for example, Category 5 cabling) to monitor the physical configuration of the cables and detect when a unidirectional link exists. When a unidirectional link is detected, UDLD shuts down the affected port and alerts the user. Unidirectional links can cause a variety of problems, including spanning-tree topology loops and erroneous Layer 3 routing.
Note The lowest value of the UDLD-AM message interval can be only 7 seconds, and the hold down time can be 21 seconds. By default, the HSRP hello timer is 3 seconds and the hold down timer is 10 seconds, and the EIGRP hello timer is 5 seconds and hold down timer is 15 seconds. When the link becomes unidirectional, before the UDLD-AM can shut down the port, the HSRP and EIGRP neighbor will flap. After UDLD-AM shut down the unidirectional port, the HSRP and EIGRP neighbor will stay up stable.
Note If UDLD mode or UDLD-AM is enabled globally on Safe Harbor switches, the interface shows the UDLD message interval as 7 seconds, which is actually the "running message interval." Once the UDLD neighbor is established, the message interval changes to 60 seconds. See CSCdv74001.
The following tests were performed:
• Basic UDLD Test on Layer 2 Link
• Basic UDLD Test on Layer 3 Link
Basic UDLD Test on Layer 2 Link
This test created a unidirectional link between SH1-109 (the device under test [DUT]) and Dista-2. Console messages were logged during the mock failure, and port states were recorded.
Test Plan
The procedure used to perform the basic UDLD test on Layer 2 link test follows.
Step 1 Enter the show memory summary command to take an initial memory snapshot of device SH1-109. Final memory and CPU utilization results are provided in the last step of this procedure.
Step 2 Verify that UDLD is configured globally on the DUT and that UDLD aggressive mode is configured locally on the interface g7/3 by using the following commands:
Commands
•show running-config | include udld
•show running-config interfaces g7/3
•show udld g7/3
Step 3 Verify that errdisable recovery is configured for a UDLD cause on SH1-109 which means that the system will attempt to recover the interface after the timer interval (30 seconds) by using the following commands:
Note If the system attempts to recover an interface if errdisable state fails, the interface will no longer be shown on the list of err disabled interfaces, but will show an up or down condition.
Commands
•show running-config | include udld
•show errdisable recovery
Step 4 Change the timer interval of the errdisable recovery to 90 seconds. This change is for testing purposes only so that there is enough time to gather data before the timer expires.
Commands
•errdisable recovery interval 90
•show errdisable recovery
Step 5 Verify that the terminal monitor is enabled on the DUT.
Step 6 With the interface g7/3 in the up/up state (Dista-2 port 1/1 showing "connected"), and both g6/3 and g7/3 bundled in port-channel 20, pull the receive fiber from port 1/1 on Dista-2. Log any messages on the DUT. Determine the interface state of g7/3 on the DUT.
Commands
•show interfaces g7/3
•show udld g7/3
Step 7 Check the errdisable recovery interface list to verify that g7/3 is on it. Watch as the timer diminishes, and log any messages after the timer reaches zero. Display the current state of the interfaces:
Commands
•show errdisable recovery
•show interfaces g7/3
•show udld g7/3
Step 8 Reinsert the receive fiber into port 1/1 of Dista-2. Copy any log messages here and determine the port/interface states. Verify that interface g7/3 returns to the up/up state and that it resumes its role in port-channel 20:
Commands
•show interfaces g7/3
•show udld g7/3
Step 9 Reset the errdisable recovery interval to 30 seconds by entering the following commands:
Commands
•errdisable recovery interval 30
Step 10 Use the show memory summary and show processes cpu commands to verify memory and CPU utilization results for device SH1-109.
Expected Results
We expect that UDLD-AM will detect a unidirectional Layer 2 link, shut down the affected port, and alert the user. We also expect that the link is reestablished when physical connectivity is restored and UDLD-disabled ports are reset.
Results
Table 8 shows the basic UDLD test on Layer 2 link test results.
Basic UDLD Test on Layer 3 Link
This test involved the emulation of a unidirectional link on a Layer 3 interface. Console messages and interface states were logged throughout the process. The DUTs are SH1-104 and SH1-109.
Test Plan
The procedure used to perform the basic UDLD test on Layer 3 link test follows.
Step 1 Enter the show memory summary command to take an initial memory snapshot of devices SH1-109 and SH1-104. Final memory and CPU utilization results are provided in the last step of this procedure.
Step 2 Verify that UDLD is configured globally on both DUTs and that UDLD-AM is configured locally on the interfaces g4/15 of SH1-104 and g3/5 of SH1-109 by using the following commands:
Commands
•show running-config | include udld
•show running-config interfaces interface
•show udld interface
Step 3 Verify that errdisable recovery is configured for a UDLD cause on both SH1-104 and SH1-109, which means that the system will attempt to recover the interface after the timer interval (30 seconds):
Note If the system attempts to recover an interface in errdisable state fails, the interface will no longer be shown on the list of errdisable interfaces, but will show an up or down condition.
Commands
•show running-config | include udld
•show errdisable recovery
Step 4 Change the timer interval of the errdisable recovery to 90 seconds. This change is for testing purposes only so that there is enough time to gather data before the timer expires.
Commands
•errdisable recovery interval 90
•show errdisable recovery
Step 5 Verify that terminal monitoring is enabled on both DUTs.
Step 6 With the interfaces connecting SH1-104 and SH1-109 in the up/up state, and g3/5 of SH1-109 as part of interface port-channel 170, pull the transmit fiber from g3/5 on SH1-109. Log any messages on both devices. Determine the interface state of g3/5 on SH1-109 and g4/15 on SH1-104.
Commands
•show interfaces interface
•show udld interface
Step 7 Check the errdisable recovery interface list to verify that g3/5 of SH1-109 is on it. Watch as the timer diminishes, and log any messages after the timer reaches zero. Display the current state of the interfaces:
Commands
•show errdisable recovery
•show interfaces interface
Step 8 Reinsert the transmit fiber into g3/5 of SH1-109. Copy any log messages here and determine the port and interface states. Verify that g3/5 of SH1-109 returns to the up/up state and that it is rebundled with port-channel 170:
Commands
•show interfaces interface
•show udld interface
Step 9 Reset the errdisable recovery interval to 30 seconds by using the following commands:
Commands
•errdisable recovery interval 30
Step 10 Use the show memory summary and show processes cpu commands to verify memory and CPU utilization results for device SH1-109.
Expected Results
We expect that UDLD-AM will detect a unidirectional Layer 3 link, shut down the affected port, and alert the user. We also expect that the link is reestablished when physical connectivity is restored and UDLD-disabled ports are reset.
Results
Table 9 shows the basic UDLD test on Layer 3 link test results.
Trunking
A trunk is a point-to-point link between one or more switch ports and another networking device such as a router or a switch. Trunks carry the traffic of multiple VLANs over a single link and allow VLANs to be extended across an entire network. Table 10 lists and describes the five modes of trunking on Cisco switches.
Table 10 Trunking Modes on Cisco Switches
Mode
|
Description
|
On
|
Local interface trunks. Sends Dynamic Trunking Protocol (DTP) packets. Puts the port into permanent trunking mode and negotiates to convert the link to a trunk link. The port becomes a trunk port even if the neighboring port does not agree to the change.
|
Off
|
Local interface does not trunk. Puts the port into nontrunking mode and negotiates to convert the link into a nontrunk link. The port becomes a nontrunk port even if the neighboring port does not agree to the change.
|
Auto
|
Local interface trunks if it receives DTP packets. Enables the port to convert the link to a trunk link. The port becomes a trunk port if the neighboring port is set to on or desirable mode. This is the default mode for Fast Ethernet and Gigabit Ethernet ports.
|
Desirable
|
Local interface sends DTP packets. Makes the port actively attempt to convert the link to a trunk line. The port becomes a trunk port if the neighboring port is set to on, desirable, or auto mode.
|
Nonnegotiate
|
Local interface forms a trunk and does not send DTP packets. Puts the port into permanent trunking mode, but prevents the port from generating DTP frames. You must configure the neighboring port normally as a trunk port to establish a trunk link.
|
The following trunking tests were performed:
• Basic Trunk Configuration
• Failure and Recovery
Basic Trunk Configuration
This test verified the basic functionality of the various trunking configurations. A static trunking configuration was tested between devices SH1-107 and Dista-1. A dynamic trunking configuration also was tested between devices SH1-108 and Dista-1.
Test Plan
The procedure used to perform the basic trunk configuration test follows.
Step 1 Verify that static trunking is configured and working on each side of the connection between SH1-107 and Dista-1 by using the following commands. The ports and interfaces are SH1-107 g4/1, g4/3, and Dista-1 1/1, 2/1.
Commands
•show running-config interfaces interface
•show trunk mod/port
•show interfaces interface trunk
Step 2 Verify that dynamic trunking is configured and working on each side of the connection between SH1-108 and Dista-1 by using the following commands. The ports and interfaces are SH1-108 g4/1-4 and Dista-1 1/2, 2/2-4.
Commands
•show running-config interfaces interface
•show trunk mod/port
•show interfaces interface trunk
Expected Results
We expect basic trunking functionality to work properly and perform correctly in failure and recovery scenarios.
Results
Table 11 shows the basic trunk configuration test results.
Failure and Recovery
This test verified failure and recovery of both statically and dynamically configured trunks. The static trunk links were between SH1-107 and Dista-1. The dynamic trunk links were between SH1-108 and Dista-1. These links were failed and then recovered, to verify that trunking was reestablished.
Test Plan
The procedure used to perform the failure and recovery test follows.
Step 1 Enter the show memory summary command to take an initial memory snapshot of SH1-107 and SH1-108, and use the show processes cpu command to begin tracking CPU utilization. Final memory and CPU utilization results are provided in the last step of this procedure.
Step 2 Verify that static trunking is configured between SH1-107 and Dist A-1, and that the ports are trunking by using the following commands:
Commands
•show interfaces interface trunk
•show trunk
Step 3 Verify that dynamic trunking is configured between SH1-108 and Dist A-1, and that the ports are trunking by using the following commands:
Commands
•show interfaces interface trunk
•show trunk
Step 4 Shut down interface g4/1 on SH1-107 (static trunk) and verify that it is down by using the following commands:
Commands
•shutdown
•show interfaces
•show interfaces interface trunk
Step 5 Bring up interface g4/1 on SH1-107 and verify that the trunk is reestablished by using the following commands:
Commands
•no shutdown
•show interfaces
•show interfaces interface trunk
Step 6 Shut down interface g4/1 on SH1-108 (dynamic trunk) and verify that it is down by using the following commands:
Commands
•shutdown
•show interfaces
•show interfaces interface trunk
Step 7 Bring up interface g4/1 on SH1-108 and verify that the trunk is reestablished by using the following commands:
Commands
•no shutdown
•show interfaces
•show interfaces interface trunk
Step 8 Use the show memory summary and show processes cpu commands to verify memory and CPU utilization results for devices SH1-107 and SH1-108.
Expected Results
We expect basic trunking functionality to work properly and perform correctly in failure and recovery scenarios.
Results
Table 12 shows the failure and recovery test results.
Port Aggregation Protocol (Channeling)
The port aggregation protocol (PAgP) facilitates the automatic creation of EtherChannels by exchanging packets between Ethernet ports. PAgP packets are exchanged only between ports in auto and desirable modes. Ports configured in on or off mode do not exchange PAgP packets. The protocol learns the capabilities of port groups dynamically and informs the other ports. Once PAgP identifies correctly matched EtherChannel links, it groups the ports into an EtherChannel. The EtherChannel is then added to the spanning tree as a single bridge port.
EtherChannel includes four user-configurable modes: on, off, auto, and desirable. Only auto and desirable are PAgP modes. The auto and desirable modes can be modified with the silent and non-silent keywords. By default, ports are in auto silent mode.
An EtherChannel distributes frames across the links in a channel by reducing part of the binary pattern formed from the addresses in the frame to a numerical value that selects one of the links in the channel.
EtherChannel frame distribution is based on a Cisco-proprietary hashing algorithm. The algorithm is deterministic; given the same addresses and session information, you always hash to the same port in the channel, preventing out-of-order packet delivery.
The following tests were performed:
• Basic Layer 2 Channeling Configuration
• Basic Layer 3 Channeling Configuration
• Layer 2 and Layer 3 EtherChannel Load Balance
• Gigabit Ethernet Module Reset
Basic Layer 2 Channeling Configuration
This test verified the basic aspects of Layer 2 PAgP configuration to verify that the basic functionality worked correctly. For this test, a set of links between SH1-109 and Dista-1 was given a configuration for static channeling. Dynamic channeling was tested in the bundling of links between SH1-110 and Dista-2.
Test Plan
The procedure used to perform the Basic Layer 2 Channeling Configuration test follows.
Step 1 Verify the configuration of static channeling between SH1-109 and Dist A-1 by using the following commands:
Note In Native IOS, a port-channel interface is created, and then individual interfaces are joined to that port-channel interface. The configuration of those individual interfaces determines whether the channel is static or dynamic.
Commands
•show running-config interfaces interface
Step 2 Verify the configuration of dynamic channeling between SH1-110 and Dist A-1 by using the following commands:
Commands
•show running-config interfaces interface
Step 3 Verify that all ports are bundled that are supposed to be in each channel, and that channels are working by using the following commands:
Commands
•show interfaces interface status
•show interfaces interface etherchannel
•show interfaces interface
Expected Results
We expect that EtherChannels are created and frames exchange across Layer 2 links properly.
Results
Table 13 shows the basic Layer 2 channeling test results.
Basic Layer 3 Channeling Configuration
This test verified that Layer 3 port-channel functionality was tested. This test verified static and dynamic channel configurations for each of the following combinations: dCEF::dCEF channels, non-dCEF::non-dCEF channels, and mixed::mixed (involving both non-dCEF and dCEF modules). Table 14 maps each of the six steps to the combination covered.
Table 14 Basic Layer 3 Channeling Configuration Matrix
Step
|
dCEF
|
Channeling
|
1
|
Yes
|
Static
|
2
|
Yes
|
Dynamic
|
3
|
Mixed
|
Static
|
4
|
Mixed
|
Dynamic
|
5
|
No
|
Static
|
6
|
No
|
Dynamic
|
Test Plan
The procedure used to perform the basic Layer 3 channeling configuration test follows.
Step 1 The port-channel (4 ports) between SH1-103 (Po16) and SH1-99 (Po16) resides on dCEF-only modules. Verify that it is configured for static channeling and that it is functioning correctly by using the following commands:
Commands
•show running-config interfaces interface
•show interfaces interface status
•show interfaces interface etherchannel
•show module
Step 2 The port-channel (4 ports) between SH1-104 (Po117) and SH1-99 (Po17) resides on dCEF-only modules. Verify that it is configured for dynamic channeling and that it is functioning correctly by using the following commands:
Commands
•show running-config interfaces interface
•show interfaces interface status
•show interfaces interface etherchannel
•show module
Step 3 The port-channel (4 ports) between SH1-103 (Po70) and SH1-109 (Po70) resides on mixed modules. Verify that it is configured for static channeling and that it is functioning correctly by using the following commands:
Commands
•show running-config interfaces interface
•show interfaces interface status
•show interfaces interface etherchannel
•show module
Step 4 The port-channel (4 ports) between SH1-103 (Po71) and SH1-110 (Po71) resides on mixed modules. Verify that it is configured for dynamic channeling and that it is functioning correctly by using the following commands:
Commands
•show running-config interfaces interface
•show interfaces interface status
•show interfaces interface etherchannel
•show module
Step 5 The port-channel (4 ports) between SH1-103 (Po68) and SH1-107 (Po68) resides on non-dCEF modules. Verify that it is configured for static channeling and that it is functioning correctly by using the following commands:
Commands
•show running-config interfaces interface
•show interfaces interface status
•show interfaces interface etherchannel
•show module
Step 6 The port-channel (4 ports) between SH1-104 (Po68) and SH1-107 (Po168) resides on non-dCEF modules. Verify that it is configured for dynamic channeling and that it is functioning correctly by using the following commands:
Commands
•show running-config interfaces interface
•show interfaces interface status
•show interfaces interface etherchannel
•show module
Expected Results
We expect that EtherChannels are created and frames exchange across Layer 3 links properly.
Results
Table 15 shows the basic Layer 3 channeling test results.
Layer 2 and Layer 3 EtherChannel Load Balance
This test verified that load distribution took place across the individual interfaces in an EtherChannel. An IXIA traffic stream was generated, sending traffic from 20 emulated sources to a single destination. This traffic was sent from one side of the SH1 network to the other, passing through several GECs along the way. Along each hop in the path to the destination, load distribution was verified by examining the traffic statistics on individual interfaces. All traffic sent from the multiple sources was received on the other end of the network, though balanced across many interfaces. Traffic was forwarded from sources to destination via hardware shortcuts.
Traffic (10 million packets) was sent at a rate of 25,000 pps from Dista-1 to Dista-2. Devices SH1-107 and SH1-108 used supervisor 1 engines, and devices SH1-109 and SH1-110 used supervisor 2 engines. Because traffic was forwarded through all devices (except SH1-107), coverage of both Sup1 and the Sup2 was implied. Both Layer 2 and Layer 3 EtherChannels were tested. The Layer 2 channels in this network were those between SH1-107, SH1-108, and Dista-1, and between SH1-109, SH1-110, and Dista-2.
Test Plan
The procedure used to perform the Layer 2 and Layer 3 EtherChannel load balance test follows.
Step 1 Enter the show memory summary command to take an initial memory snapshot of devices SH1-103, SH1-104, SH1-107, SH1-108, SH1-109, and SH1-110. Final memory and CPU utilization results are provided in the last step of this procedure.
Step 2 Clear the counters on all of the devices listed in Step
