Cisco Safe Harbor Testing for Financial
Enterprise Customers, Release 12.1(8b)E14
Version History
Version Number
Date
Notes
1
June 1, 2003
This document was created upon test plan completion.
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 verify 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 introductory sections:
•
About Cisco IOS Safe Harbor, page 2
•
Financial Lab Topology, page 2
•
Test Results Summary, page 13
•
DDTS Summary, page 18
•
Feature Sets Testing, page 19
This document contains the following test sections:
•
Memory Leak, page 19
•
Hardware Redundancy, page 21
•
Layer 2 Features, page 25
•
Hardware Forwarding Features, page 40
•
Layer 3 Routing Features, page 79
•
Network Management Features, page 111
•
Miscellaneous Features, page 115
Corporate Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Copyright © 2003. Cisco Systems, Inc. All rights reserved.
About Cisco IOS Safe Harbor
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 sector. 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 customers. For information on
the hardware tested and the network setup of the test environment, see the “Financial Lab Topology”
section on page 2.
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 verify that
functionality is maintained. Negative tests are designed and conducted to stress the features and their
inter operability. For information on each feature and its testing, see the “Feature Sets Testing” section
on page 19.
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 “Basic Topology: Testbed
Diagrams” section on page 4.
Note
Safe Harbor testing does not address issues that might exist in the customer change control and
operations processes.
Financial Lab Topology
The base Native IOS financial lab topology is defined in the following sections and illustrated in Figure 1
through Figure 8:
•
Basic Topology: Port Channel Deployment, page 3
•
Basic Topology: Routing Protocols, page 3
•
Basic Topology: Testbed Diagrams, page 4
The financial services network environment configured in the lab includes the following hardware:
•
Fourteen Catalyst 6500 switches running Cisco Native IOS Release 12.1(8b)E14 (SH1-97 to
SH1-110)
•
Two Catalyst 6500 switches that are running Hybrid CatOS 6.4 train with no routing (Dista-1 and
Dista-2)
•
Pagent test devices to simulate the Internet Service Providers (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.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
2
Financial Lab Topology
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 8 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 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 BGP (eBGP)
– Interior BGP (iBGP)
•
EIGRP
•
OSPF
Figure 1 through Figure 8 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.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
3
Financial Lab Topology
Basic Topology: Testbed Diagrams
•
Figure 1 on page 5 summarizes hardware module types per device and their position in the chassis.
This data is taken directly from the output of the show module command.
•
Figure 2 on page 6 shows the Ether Channeling configuration of the Safe Harbor testbed. It displays
the number of ports in each channel, the Channel ID, the static or dynamic configuration of the
channel, and whether the channel is Layer 3 or Layer 2.
•
Figure 3 on page 7 is the most detailed illustration of the Safe Harbor topology configuration. It
contains the physical ports connecting each of the main devices, and network addresses of those
connections. Where Hot Standby Routing Protocol (HSRP) is configured, the addressing scheme of
all VLANs is provided.
•
Figure 4 on page 8 provides a high-level view of the Safe Harbor network routing topology. OSPF,
BGP, and EIGRP protocols are delimited here and devices involved in each.
•
Figure 5 on page 9 shows the Safe Harbor network multicast configuration based on one of our
largest financial customers. It presents a real-world scenario. This figure shows the extent that
devices participate in the overall multicast scheme, highlighting Multicast Source Discovery
Protocol (MSDP) and Rendezvous Point (RP).
•
Figure 6 on page 10 shows where chassis connections are made with network devices (IXIA
Connections Map) using the IXIA test tool for traffic generation, and some OSPF route generation.
•
Figure 7 on page 11 shows how Pagent and IXIA test tools are connected to the testbed, and specific
routes they generate (Route Feed). These generated routes are not inherent in the Safe Harbor
network and combine OSPF, BGP, and EIGRP generated feeds equal to 130,000 total routes.
•
Figure 8 on page 12 shows background traffic running to emulate real-world network conditions
with three multicast and four unicast streams traversing the network and the devices they cross in a
majority of the test plan.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
4
Financial Lab Topology
Figure 1
Safe Harbor Device Modules and Chassis Positions
Modules
97
1
2
3
4
5
6
7
8
98
1
2
3
4
5
6
7
8
WS-X6K-S2U-MSFC2
WS-X6K-S2U-MSFC2
WS-X6816-GBIC
WS-X6324-100FXMMWS-X6500-SFM2
WS-X6500-SFM2
WS-X6516-GBIC
WS-X6348-RJ-45
WS-X6K-S2U-MSFC2
WS-X6K-S2U-MSFC2
WS-X6816-GBIC
WS-X6500-SFM2
WS-X6500-SFM2
WS-X6516-GBIC
WS-X6324-100FX-MM
1
2
3
4
5
6
7
8
1
2
3
4
5
6
7
8
9
WS-X6K-S2U-MSFC2
WS-X6K-S2U-MSFC2
WS-X6816-GBIC
WS-X6348-RJ-45
WS-X6500-SFM2
WS-X6500-SFM2
WS-X6516-GBIC
WS-X6324-100FX-MM
1
2
3
4
5
6
7
8
9
109
WS-X 6K- SUP1A-2G E
WS-X 6K- SUP1A-2G E
WS-X 640 8-G BI C
WS-X 640 8-G BI C
WS-X 640 8-G BI C
WS-X 640 8-G BI C
WS-X 632 4-1 00 FX- MM
WS-X 634 8-R J- 45
1
2
3
4
5
6
7
1
2
3
4
5
6
WS-X6K-S UP1A- 2GE
WS-X6K-S UP1A- 2GE
WS-X64 08 -GB IC
WS-X64 08 -GB IC
WS-X64 08 -GB IC
WS-X64 08 -GB IC
WS-X63 24 -10 0F X-MM
1
2
3
4
5
6
WS-X6K-S2U-MSFC2
WS-X6K-S2U-MSFC2
WS-X681 6-G BIC
WS-X681 6-G BIC
WS-X650 0-S FM2
WS-X651 6-G BIC
WS-X651 6-G BIC
WS-X681 6-G BIC
1
2
3
4
5
6
7
8
WS-X 6K-S2U-M SFC2
WS-X 6K-S2U-M SFC2
WS-X 681 6-G BI C
WS-X 681 6-G BI C
WS-X 650 0-S FM2
WS-X 650 0-S FM2
WS-X 651 6-G BI C
WS-X 651 6-G BI C
111
WS-X 6K-SUP1A-2 GE
WS-X 6K-SUP1A-2 GE
WS-X 640 8-GBI C
WS-X 640 8-GBI C
WS-X 632 4-100 FX-MM
WS-X 654 8-RJ- 45
1
2
3
4
5
6
WS-X6K-SUP2-2GE
WS-X6416-GE-MT
WS-X6408A-GBIC
WS-X6416-GE-MT
WS-X6324-100FX-MM
WS-X6248A-RJ-45
112
108
WS-X6K-S2U-MSFC2
WS-X6K-S2U-MSFC2
WS-X6816-GBIC
WS-X6516-GBIC
WS-X6500-SFM2
WS-X6500-SFM2
WS-X6516-GBIC
WS-X6516-GBIC
WS-X6324-100FX-MM
1
2
3
4
5
6
7
8
110
107
WS-X6K-S2U-MSFC2
WS-X6K-S2U-MSFC2
WS-X6816-GBIC
WS-X6816-GBIC
WS-X6500-SFM2
WS-X6500-SFM2
WS-X6516-GBIC
WS-X6516-GBIC
WS-X6548-RJ-45
104
WS-X6K- S2U-MSFC2
WS-X6K- S2U-MSFC2
WS-X681 6-G BIC
WS-X681 6-G BIC
WS-X650 0-S FM2
WS-X650 0-S FM2
WS-X654 8-R J-4 5
WS-X651 6-G BIC
1
2
3
4
5
6
7
9
106
103
WS-X6K-S 2U-MSFC2
WS-X6K-S 2U-MSFC2
WS-X6816 -G BIC
WS-X6816 -G BIC
WS-X6500 -S FM2
WS-X6500 -S FM2
WS-X6348 -R J-4 5
WS-X6516 -G BIC
100
1
2
3
4
5
6
7
9
1
2
3
5
6
7
8
102
99
1
2
3
4
5
6
7
9
105
101
WS-X6K-S2U-MSFC2
WS-X6K-S2U-MSFC2
WS-X6816-GBIC
WS-X6324-100FX-MM
WS-X6500-SFM2
WS-X6500-SFM2
WS-X6516-GBIC
WS-X6348-RJ-45
WS-X6K-S UP1A- 2GE
WS-X6K-S UP1A- 2GE
WS-X6408 -GB IC
WS-X6408 -GB IC
WS-X6324 -10 0F X-MM
WS-X6348 -RJ -4 5
1
2
3
4
5
6
WS-X6K-SUP2-2GE
WS-X6416-GE-MT
WS-X6408A-GBIC
WS-X6416-GE-MT
WS-X6324-100FX-MM
WS-X6248A-RJ-45
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
5
Financial Lab Topology
Figure 2
Safe Harbor EtherChannel Configuration
SH1-101
EtherChannel
Dista-1
SH1-107
EtherChannel modes:
PoXX
On
PoXX
Desirable
PoXX
Auto
SH 1-102
Dista-1
All EtherChannels are
L3 channels, unless
otherwise noted
SH1-97
SH1-99
Po12
Po16 SH1-103
Po16
SH1-108
Po12
SH1-109
SH1-98
SH1-100
Po13
SH1-104
Po113
Po17
Po117
Dista-2
SH 1-105
SH1-110
SH1-106
Dista-2
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
6
Financial Lab Topology
Figure 3
Safe Harbor Comprehensive IP Interface Topology Configuration
IP Interfaces
A table of IP addresses configured on
VLANs 40 through 50 on devices SH1101 and SH1-102. The address format
is 172.31.x.x/24. The two HSRP
addresses for these interfaces are
172.31.[70-80].[1,254].
vl an
40
41
42
43
44
101
70.14
71.14
72.14
73.14
74.14
102
70.14
71.14
72.14
73.14
74.14
45
46
47
48
49
50
75.14
76.14
77.14
78.14
79.14
80.14
IP addresses configuredonVLAN s vlan
40 hrou
t gh 50 on dev
ices SH1-107 10
and SH1-108. The addres
s format 11
12
is 172.
31.x.x/24. The tw
o HSR P
13
addres
ses o
frthese int
erf
aces are
14
172.31.[9-19].[1,254].
SH1-101
75.14
76.14
77.14
78.14
79.14
80.14
Dista-1
107
10.68
11.68
12.68
13.68
14.68
108
10.69
11.69
12.69
13.69
14.69
15
16
17
18
19
20
15.68
16.68
17.68
18.68
19.68
20.68
15.69
16.69
17.69
18.69
19.69
20.69
SH1-107
SH1-102
Dista-1
SH 1-97
SH 1-99
SH1-108
1-2/1,3/1,3/9 (5)
1-2/1,3/5,4/13 (6)
SH1-103
Unless otherwise noted, all IP interfaces described in this
diagram use the format 172.31.1.x/30, where x is replaced
with the (value) given next to the interface list.
SH1-104
SH1-109
SH 1-100
SH1-97
3/1,3/9 (9)
3/5,4/13 (10)
Dista-2
SH1-105
SH1-110
Dista-2
A table of IP addresses configured on
VLANs 40 through 50 on devices SH1105 and SH1-106. The address format
is 172.31.x.x/24. The two HSRP
addresses for these interfaces are
172.31.[100-110].[1,254].
vl an
40
41
42
43
44
105
100.66
101.66
102.66
103.66
104.66
106
100.67
101.67
102.67
103.67
104.67
45
46
47
48
49
50
105.66
106.66
107.66
108.66
109.66
110.66
105.67
106.67
107.67
108.67
109.67
110.67
SH1-106
3/7-8
IP addresses configured on VLANs vl an
10 through 20 on devices SH1-109 10
11
and SH1-110. The address format
12
is 172.31.x.x/24. The two HSRP
13
addresses for these interfaces are
14
172.31.[20-30].[1,254].
109
20.70
21.70
22.70
23.70
24.70
110
20.71
21.71
22.71
23.71
24.71
15
16
17
18
19
20
25.70
26.70
27.70
28.70
29.70
30.70
25.71
26.71
27.71
28.71
29.71
30.71
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
7
Financial Lab Topology
Figure 4
Safe Harbor Network Routing Topology
Layer 3
AS 100
Dista-1
SH1-107
SH1-101
AREA 5
EIGRP
1320
AREA 6
SH1-97
SH1-102
Dista-1
SH1-99
SH1-103
SH1-108
AS 10
AREA 0
AS 20
AREA 1
SH1-109
SH1-100
SH1-98
SH1-104
Dista-2
SH1-105
AREA 3
AREA 4
SH1-106
AREA 2
SH1-110
Dista-2
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
8
Financial Lab Topology
Figure 5
Safe Harbor Multicast Configuration
Multicast
SH1-101
This diagram represents a view of the general multicast
design for this topology. This topology includes two local
multicast areas, three regional areas, and one global area.
Each area includes a pair of PIM-RPs, only one active at a
time (that with the highest IP address on the Lo0 interface.
The active RP is also the PIM-DR for any attached subnets
with clients (local areas only). The RPs in each area are
responsible for the forwarding of multicast traffic for a certain
range of addresses, shown in the text boxes attached to the
areas in the diagram. Each pair of routers in an area has an
MSDP peering relationship.
SH1-107
Lo0: 4.107
Lo1: 0.8
239.255.102.0 239.255.102.255
SH1-102
Lo0: 4.102
Lo1: 0.102
Each loopback address begins with the octet pair 172.31.x.x
and uses a 32-bit mask.
LOCAL
Dista-1
Lo0: 4.101
Lo1:0.102
Dista-1
239.255.8.0 239.255.8.255
RP/DR
SH1-97
SH1-99
SH1-103
Lo0: 4.97
Lo0: 4.99
Lo1: 0.200
Lo0: 4.103
Lo1: 0.104
REGIONAL
SH1-108
Lo0: 4.108
Lo1: 0.8
RP/DR
GLOBAL
239.255.200.0 239.255.200.255
239.255.104.0 239.255.104.255
SH1-109
SH1-98
Lo0: 4.98
Each router contains the following configuration:
ip pim rp-address 1 72.31.0.8 1 override
ip pim rp-address 1 72.31.0.10 2 override
ip pim rp-address 1 72.31.0.102 3 override
ip pim rp-address 1 72.31.0.104 4 override
ip pim rp-address 1 72.31.0.106 5 override
ip pim rp-address 1 72.31.0.200 6 override
!
access-list 1 permit 239.255.8.0 0.0.0.255
access-list 2 permit 239.255.10.0 0.0.0.255
access-list 3 permit 239.255.102.0 0.0.0.255
access-list 4 permit 239.255.104.0 0.0.0.255
access-list 5 permit 239.255.106.0 0.0.0.255
access-list 6 permit 239.255.200.0 0.0.0.255
access-list 6 permit 224.0.0.0 0.0.255.255
SH1-100
SH1-104
Lo0: 4.100
Lo1: 0.200
Lo0: 4.104
Lo1: 0.104
RP/DR
RP/DR
Lo0: 4.109
Lo1: 0.10
239.255.10.0 239.255.10.255
SH1-105
Dista-2
Lo0: 4.105
Lo1: 0.106
SH1-110
Lo0: 4.110
Lo1: 0.10
239.255.106.0 239.255.106.255
SH1-106
Dista-2
RP/DR
Lo0: 4.106
Lo1: 0.106
RP/DR
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
9
Financial Lab Topology
Figure 6
Safe Harbor IXIA Connections Map
IXIA
SH1-101
g3/16
11/2
Dista-1
g7/16
6/1
12/1
2/1
6/5
2/2
SH1-107
g3/8
10.194.17.111
10.194.17.101
g4/8
SH1-102
16/1
16/2
10.194.17.107
fa4/1
fa4/5
10.194.17.102
2/3
Dist
a-1
3/3
4/1
4/6
2/4
13/1
8/1
8/2
10.194.17.111
SH1-97
SH1-103
SH1-99
SH1-108
g3/8
g4/8
10.194.17.9
7
7/1
7/2
10.194.17.103
10.194.17.99
10.194.17.108
SH1-109
SH 1-98
g3/8
g4/8
g3/16
SH1-104
SH1-100
g7/16
15/1
15/2
9/1
9/2
10.194.17.109
10.19
4.17.9
8
10.194.17.104
10.194.17
.100
Dist
a-2
SH1-105
g3/2
fa9/13
fa9/14
2/1
1/1
1/1
2/6
1/1
10.194.17.112
SH1-110
10.194.17.105
g4/16
6/1
SH1-106
Dist
a-2
6/2
6/5
6/6
2/5
2/6
2/7
2/8
10.194.17.112
10.194.17.106
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
10
3/3
g8/16
10.194.17.110
11/1
12/2
13/2
10/1
10/2
Financial Lab Topology
Figure 7
Safe Harbor Pagent and IXIA Generated Route Feed
rtp-wbu-te -p5
172.18.179.184
Pagent and IXIA Route Feeds
EIGRP 1320: 180.1.1.0/24 ++10000
BGP AS20: 120.1.1.0/24 ++65000
BGP AS10: 110.1.1.0/24 ++35000
OSPF Area6: 160.1.1.0/24 ++5000
6/37
Dista-1
fa8/1
fa8/47
fa7/47
SH1-97
SH1-99
fa8/48
fa7/48
fa7/38
OSPF Area3: 130.1.1.0/24 ++125
OSPF Area3: 130.2.1.0/24 ++125
OSPF Area5: 150.1.1.0/24 ++125
OSPF Area5: 150.2.1.0/24 ++125
OSPF Area4: 140.1.1.0/24 ++2000
BGP AS20: 120.1.1.0/24 ++65000
BGP AS10: 110.1.1.0/24 ++35000
OSPF Area6: 160.1.1.0/24 ++5000
fa8/1
fa8/47
fa7/47
SH1-98
OSPF Area3: 130.1.1.0/24 ++125
OSPF Area3: 130.2.1.0/24 ++125
SH1-100
fa7/48
fa8/48
fa7/38
OSPF Area5: 150.1.1.0/24 ++125
OSPF Area5: 150.2.1.0/24 ++125
OSPF Area4: 140.1.1.0/24 ++2000
OSPF Area2: 170.1.1.0/24 ++2500
rtp-wbu-te
-p4
172.18.179.185
6/47
Dista-2
rtp-wbu -te-ix ia1
172.18.179.189
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
11
Financial Lab Topology
Figure 8
Safe Harbor Background Traffic
Background Traffic
1
Ix > D-2 > 106 > 100 > 104 > 108 > D-1 > Ix
1
IP Multicast: Group 239.255.8.50
2
Ix > D-2 > 110 > 104 > 100 > 102 > D-1 > Ix
2
IP Multicast: Group 239.255.102.50
3
Ix > 110 > 104 > 100 > 104 > 108 > Ix
3
IP Multicast: Group 239.255.200.50
4
IP Unicast
5
IP Unicast
6
IP Unicast
7
IP Unicast
SH1-101
Dist
a-1
6/1
2/1
6 2
SH1-107
SH1-102
Dist a-1
SH1-97
SH1-99
3/3
13/1
4
4/1
8/1
7 1
SH1-103
IP/TV Clients
SH1-108
5
g4/8
IP/TV Clients
7/2 3
SH1-109
SH1-98
SH1-100
SH1-104
IP/TV Clients
2347
136
IP/TV Clients
Dist a-2
SH1-105 g3/2
2/6
1/1 4
SH1-110
SH1-1 6
6/1
0
Dista-2
1
4
Ix > D-1 > 108 > 104 > 100 > 105 > D-2 > Ix
5
Ix > D-2 > 110 > 103 > 99 > Ix
6
Ix > D-1 > 102 > 100 > 104 > 110 > D-2 > Ix
7
Ix > D-1 > 108 > 104 > 100 > 105 > D-2 > Ix
2/5
1 7
IP/TV Server
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
12
3/3
g8/16
12/2
3
13/2
5 6
10/2
2
Test Results Summary
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 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 or function, and any related defects, or bugs, found during the Safe Harbor testing.
Note
Table 1
Test results are specific to technologies covered and actual scenarios in which they were tested. Safe
Harbor is designed to cover critical path areas and augment ongoing regression and systems testing.
Safe Harbor Test Results Summary
Test Suites
Feature/Function
Memory Leak,
page 19
Memory Leak, page 19
Hardware
Redundancy, page 21
Hardware Redundancy, page 21
Layer 2 Features,
page 25
Tests
Results
DDTS
Pass
None
Pass
None
•
Extended Memory Leak, page 19
•
Repeated Telnet, page 20
•
Fabric Flap, page 21
•
Supervisor 1 Failover, page 22
•
Supervisor 2 Failover, page 23
Spanning Tree Protocol,
page 25
•
Basic Spanning Tree Protocol
Configuration, page 25
Pass
None
Unidirectional Link
Detection-Aggressive Mode,
page 26
•
Basic UDLD on Layer 2 Link,
page 27
Pass
None
•
Basic UDLD on Layer 3 Link,
page 28
Trunking, page 29
•
Supervisor 1 Configuration and
Failure Recovery, page 29
Pass
None
•
Supervisor 2 Configuration and
Failure Recovery, page 30
•
Basic Layer 2 Channeling
Configuration, page 32
Pass
None
•
Basic Layer 3 Channeling
Configuration, page 33
•
Gigabit Ethernet Module Reset,
page 35
•
Basic VLAN Trunking Protocol
Configuration, page 37
Pass
None
•
Layer 2 Gigabit EtherChannel
Failover—Supervisor 1, page 40
Pass
None
•
Layer 2 Gigabit EtherChannel
Failover—Supervisor 2, page 41
•
Layer 3 Gigabit EtherChannel
Failover, page 42
Port Aggregation Protocol
(Channeling), page 31
VLAN Trunking Protocol,
page 37
Hardware Forwarding IP Unicast, page 40
Features, page 40
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
13
Test Results Summary
Table 1
Test Suites
Safe Harbor Test Results Summary (continued)
Feature/Function
IP Multicast, page 44
Tests
•
Local Multicast, page 45
•
Regional Multicast with IGMP
Functionality, page 46
•
Non-Reverse Path Forwarding
Rate Limiting and Multicast
Stub—Supervisor 1, page 48
•
Non-Reverse Path Forwarding
Rate Limiting and Multicast
Stub—Supervisor 2, page 50
•
Gigabit EtherChannel Failover:
Non-dCEF, page 53
•
Gigabit EtherChannel Failover:
Mixed-dCEF, page 55
•
Gigabit EtherChannel Failover:
dCEF, page 58
•
Switch Fabric Module Failover,
page 60
•
Gigabit Ethernet Module
Failover—Supervisor 1, page 62
•
Gigabit Ethernet Module
Failover—Supervisor 2, page 64
•
Protocol Independent
Module-Designated Router
Failover—Supervisor 11, page 66
•
Protocol Independent
Module-Designated Router
Failover—Supervisor 22, page 68
•
Auto-Rendezvous Point
Functionality and Failover,
page 70
•
Layer 3 Interface Multicast
Negative, page 72
•
Protocol Independent
Module-Rendezvous Point
Failover—Supervisor 22, page 74
•
MSDP Failover, page 76
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
14
Results
DDTS
Pass
CSCea50652
CSCdw95457
Test Results Summary
Table 1
Safe Harbor Test Results Summary (continued)
Test Suites
Feature/Function
Tests
Layer 3 Routing
Features, page 79
Cisco Express Forwarding,
page 79
Open Shortest Path First,
page 88
Border Gateway Protocol,
page 95
Hot Standby Routing Protocol,
page 100
Enhanced Interior Gateway
Routing Protocol, page 107
Results
•
Cisco Express Forwarding Packet Pass
Switching, page 79
•
Cisco Express Forwarding Route
Entries on DFC, page 81
•
Cisco Express Forwarding
Many-to-One Distribution Load
Balance, page 82
•
Cisco Express Forwarding
Many-to-Many Distribution with
Polarization Load Balance,
page 84
•
OSPF Autocost, page 88
•
OSPF Passive Interface, page 89
•
OSPF Filtering, page 91
•
OSPF Redistribution, page 93
•
OSPF Topology Database,
page 94
•
Scale to Ten Neighbors and 100K Pass
Routes in Core (Add 120,000
Routes), page 95
•
Route Redistribution Between
Other Protocols and
BGP—ACL/Route Map, page 97
•
BGP Neighbor Flap—No
Dampening, page 99
•
Basic HSRP, page 100
•
HSRP Failover with Standard
Timers—Supervisor 22, page 101
•
HSRP Failover Using Fast
Timers—Supervisor 22, page 103
•
HSRP Failover—Supervisor 22,
page 105
•
HSRP Maximum Group
Limit—Supervisor 22, page 106
•
EIGRP Summarization, page 107
•
EIGRP Redistribution, page 108
DDTS
Pass
CSCea74804
CSCdt00287
Pass
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
15
Test Results Summary
Table 1
Safe Harbor Test Results Summary (continued)
Test Suites
Feature/Function
Network Management Simple Network Management
Features, page 111
Protocol, page 111
Basic Functionality Shut/No Shut Pass
Interface—Supervisor 11,
page 111
•
Basic Functionality Shut/No Shut
Interface—Supervisor 22,
page 112
•
Protos Negative Request
Application, page 113
•
User Authentication—Supervisor
11, page 114
•
User Authentication—Supervisor
22, page 115
Switched Port Analyzer,
page 116
•
SPAN Basic Functionality,
page 116
Pass
Access Control Lists, page 118
•
Scripted Test of ACL 110,
page 118
Pass
•
Scripted Test of ACL 131,
page 119
Pass
CSCdz69491
CSCdz78710
CSCdx89464
•
Show-All Script, page 120
Pass
Network Address Translation,
page 121
•
Static 2 Hosts, page 121
Pass
•
Static 40 Hosts, page 122
•
Static 40 Hosts Extended,
page 123
•
Static 2 Networks, page 124
•
Static Inside Dynamic Outside,
page 125
•
Dynamic Inside Static Outside,
page 127
•
Verify CSCdx40232, page 128
•
Addition/Removal of NAT
Statements, page 129
•
Static 40 Hosts Overnight,
page 130
•
Basic NTP
Functionality—Supervisor 1,
page 131
•
Basic NTP
Functionality—Supervisor 2,
page 132
•
NTP Failover—Supervisor 1 and
Supervisor 2, page 133
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
DDTS
CSCdw62852
Parser, page 120
Network Time Protocol,
page 131
16
Results
•
TACACS, page 114
Miscellaneous
Features, page 115
Tests
Fail
CSCdx77078
CSCdu21785
Pass
Test Results Summary
Table 1
Test Suites
Safe Harbor Test Results Summary (continued)
Feature/Function
Tests
Syslog, page 133
Results
•
Basic Syslog
Functionality—Supervisor 1,
page 134
•
Basic Syslog
Functionality—Supervisor 2,
page 134
User Datagram Protocol
Broadcast Flooding, page 135
•
UDP Broadcast Flooding,
page 136
Pass
System Upgrade, page 137
•
Cisco IOS 12.1(8b)E9 to
12.1(8b)E14
Upgrade—Supervisor 11,
page 137
Pass
•
Cisco IOS 12.1(8b)E9 to
12.1(8b)E14
Upgrade—Supervisor 12,
page 138
•
Cisco IOS 12.1(8b)E9 to
12.1(8b)E14
Upgrade—Supervisor 22,
page 139
•
Cisco IOS 12.1(8b)E12 to
12.1(8b)E14
Upgrade—Supervisor 11,
page 140
•
Cisco IOS 12.1(8b)E12 to
12.1(8b)E14
Upgrade—Supervisor 12,
page 140
•
Cisco IOS 12.1(8b)E12 to
12.1(8b)E14
Upgrade—Supervisor 22,
page 141
•
SSH Server Vulnerability,
page 142
Secure Shell, page 142
DDTS
Pass
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
17
DDTS Summary
DDTS Summary
Table 2 lists Development Defect Tracking System (DDTS) software bugs, descriptions, and comments
filed by the Safe Harbor testing team during Cisco Native IOS Release 12.1(8b)E14 testing. Table 3 lists
DDTS and descriptions encountered during Cisco Native IOS Release 12.1(8b)E14 testing.
Table 2
Summary of DDTS Filed During Safe Harbor Native Cisco IOS 12.1(8b)E14 Testing
DDTS
Description
CSCea50652 IGMP v2 report ignored after host-attached module (Helios) reset
Table 3
Summary of DDTS Encountered During Safe Harbor Native Cisco IOS 12.1(8b)E14 Testing
DDTS
Description
CSCdp45359
While RP is booting, %DEC21140-5-LATECOLL: EOBC0 transmit error
CSCdt00287
Some OSPF counters (DCBitless LSA, indication, DNA) are never reset
CSCdu21785
NEBULA: clear counter command not working when issued first time
CSCdu56638
CPUHOG in table_walk
CSCdv26643
Herschel-Seaquest:traceback at Icc_card_restart by reload command
CSCdv36693
Herschel:No mem available to unregister card- on 2nd sup OIR
CSCdw62852
Unprotected bugtrace
CSCdw95457
Help output is incorrect for debug ip pim - qdm
CSCdx74064
MMLS: show mls ip multicast group <g> source <s> bogus output
CSCdx77078
Source static network NAT translations fail on msfc2/sup2
CSCdx89464
cosmos-e: RP crashed in ip_nacl_extended_nvgen while removing ACL
CSCdz69491
Range purge every 1 minute when default route command is configured
CSCdz78710
NAT NetFlow entries purged and not reinstalled
CSCea15655
CDP neighbors for port-channels show same local interface for member
CSCea70798
CDP on port-channel is broken in nightly builds
CSCea74804
Unnecessary LSAs generated when area with no interface created and deleted
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
18
Feature Sets Testing
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:
Note
•
Memory Leak, page 19
•
Hardware Redundancy, page 21
•
Layer 2 Features, page 25
•
Hardware Forwarding Features, page 40
•
Layer 3 Routing Features, page 79
•
Network Management Features, page 111
•
Miscellaneous Features, page 115
For a compete list of Cisco IOS commands and usage, refer to:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/index.htm
Memory Leak
Testing for memory leaks occurred each evening of a regular workday. The last regular test of the day
that is performed was repeated throughout the night, with the memory being recorded for each device in
the network. The duration of each memory leak test is approximately 16 hours, or from 5 p.m. to 9 a.m.
the next morning. On weekends, the test was run for the entire weekend, or approximately 64 hours, from
5 p.m. Friday evening until 9 a.m. Monday morning.
The testing that occurred for this iteration was a repetition of the EIGRP route summarization test.
Summarization was configured on devices SH1-99 and SH1-100, followed by a 5-minute sleep period.
Then summarization was removed from the same devices, followed by another 5-minute sleep period.
This cycle was repeated overnight. SNMP polls were taken every 5 minutes and the results for the
Memory Free for each device displayed.
Whenever a fault was encountered, the redundant module took over the functions of the failed hardware
module. Memory leak testing for Safe Harbor involved performing various failover scenarios to verify
that internal hardware redundancy failed over as expected.
The following tests were performed:
•
Extended Memory Leak, page 19
•
Repeated Telnet, page 20
Extended Memory Leak
This test summarized final memory leak testing for 8bE14. The test began at approximately 7pm
5/21/2003 and ended at approximately 9am 5/27/2003. The total run time was about 134 hours.
The testing focused on three devices, SH1-110 (sup22), SH1-108 (sup12), and SH1-106 (sup11). Each
of the three devices had 250 mroute entries created and removed, and 5000 OSPF routes added and
removed within a 30-minute period. This was repeated about 268 times for the entire testing period.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
19
Memory Leak
An initial "show proc mem" was taken at the beginning of the test, and a final at the end. The following
before and after memory information is summarized for each device and memory statistics from polls
taken every 10 seconds are captured for the testing period.
Devices under test: SH1-97, SH1-98, SH1-99, SH1-100, SH1-101, SH1-102, SH1-103, SH1-104,
SH1-105, SH1-106 (sup11), SH1-107, SH1-108 (sup12), SH1-109, and SH1-110 (sup22).
Test Plan
The procedure used to perform the extended memory leak test follows:
Step 1
Verify that all the Layer 3 devices in the network are running Cisco IOS Release 12.1(8b)E14 and that
there are no memory leaks on any device during the testing period.
Expected Results
The following test results are expected:
•
That all devices do not become unresponsive or leak memory.
Results
Table 5 shows the extended memory leak test results.
Table 4
Extended Memory Leak Test Results
Tests
Results
Extended Memory Leak
Pass
Repeated Telnet
This test verified that repeated Telnets to supervisor 11, supervisor 12, and supervisor 22 did not impact
memory or system stability.
Devices under test: SH1-106 (sup 11), SH1-107 (sup 12), and SH1-97 (sup 22).
Test Plan
The procedure used to perform the repeated Telnet test follows:
Step 1
Verify that DUTs are running Native Cisco IOS Release 12.1(8b)E14.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Telnet into each DUT repeatedly.
Step 4
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
That all the DUTs do not become unresponsive or leak memory.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
20
Hardware Redundancy
Results
Table 5 shows the repeated Telnet test results.
Table 5
Repeated Telnet Test Results
Tests
Results
Repeated Telnet
Pass
Hardware Redundancy
Whenever a fault was encountered, the redundant module took over the functions of the failed hardware
module. Testing hardware redundancy for Safe Harbor involved performing various failover scenarios
to verify that internal hardware redundancy failed over as expected.
The following tests were performed:
Note
•
Fabric Flap, page 21
•
Supervisor 1 Failover, page 22
•
Supervisor 2 Failover, page 23
For this iteration, and all subsequent iterations of testing, the total number of OSPF routes fed into
the network was reduced to 10,000. This change better reflected recommendations established and
outlined in Cisco IOS Release Notes for release 12.1 E at
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/12_1e/ol_2310.htm#62683 for use
with RPs that have 128 MB of memory. Many devices in the Safe Harbor network have only 128 MB
of memory, limiting total routes to 20,000, using fixed-length masks.
Fabric Flap
This test reset the active Switch Fabric Module (SFM) in the system repeatedly to verify that SFM
failover operated as designed. With an IXIA traffic stream passing through it, the DUT SFM is failed 20
times. Test results include measures of the period during which no traffic was passed and the time
required for the failed SFM to come back online to "standby" state.
Device under test: SH1-103.
Test Plan
The procedure used to perform the fabric flap test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
To verify that the unicast stream used for testing will flow through the DUT, configure the ip ospf cost
100 command on interfaces: SH1-104 port-channel 69, SH1-104 port-channel 117, SH1-108
port-channel 169, and SH1-100 port-channel 17.
Step 5
Verify that traffic is being switched in compact mode on DUT.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
21
Hardware Redundancy
Step 6
Determine the active fabric module and start playing the test stream.
Step 7
While monitoring the log messages and traffic loss, reset the active fabric module.
Step 8
Record the time required for the standby fabric module to become active and for the fabric module to
come online again, and the time traffic was lost during the failover.
Step 9
Repeat Step 6 through Step 8 20 times.
Step 10
Calculate the fastest, slowest, and average times for each event.
Step 11
Verify that the DUT did not record any tracebacks.
Step 12
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Step 13
Reset the configuration to the original state.
Expected Results
The following test results are expected:
•
Standby fabric modules should become active in fewer than 30 ms.
•
Reset fabric modules should become standby in 20 to 30 seconds.
•
Each failover should have fewer than 1 or 2s of lost data.
Results
Table 6 shows the fabric flap test results.
Table 6
Fabric Flap Test Results
Tests
Results
Fabric Flap
Pass
Supervisor 1 Failover
This test verified the proper operation of redundant supervisors during a series of 20 continual resets.
The goal of this test is to verify that the box fails between the supervisors as designed, recovers, and
forwards traffic. This test is further designed to verify that failure operations are within the design
guidelines for the applicable hardware and software versions under test. Although this test measures
time, it is by no means a measure of the speed at which failover can take place, which as this is dependent
upon the configuration and line cards in the system.
Supervisor Engine 2s are covered in this test. The device under test is SH1-107. A traffic stream was sent
from Dista-1 to Dista-2 a a fixed rate. 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 1 failover test follows:
Step 1
Verify that the DUT is running Cisco IOS Release 12.1(8b)E14.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
22
Hardware Redundancy
Step 2
Show some of the factors that may contribute to reload times. Such factors may include configuration
size, memory used, and size of IP routing table.
Step 3
Shut down interface port-channel 10 on device SH1-108 to verify that the traffic generated in Step 2 goes
through SH1-107 to get to its destination.
Step 4
Begin an IXIA traffic stream (1.6 million packets) from Dista-1 to Dista-2. Send this traffic at a rate of
10,000 packets per second (pps). Use the reload command on SH1-107.
Step 5
Measure the period of time between which traffic stopped and it was started again. This period of time
is considered the failover time.
Step 6
Repeat Step 4 through Step 5 19 more times.
Expected Results
The following test results are expected:
•
All 20 resets of the supervisor should fail within the range of 2 to 3 minutes.
•
Supervisors should come back online without any manual intervention.
Results
Table 7 shows the supervisor 1 failover test results.
Table 7
Supervisor 1 Failover Test Results
Tests
Results
Supervisor 1 Failover
Pass
Supervisor 2 Failover
This test verified the proper operation of redundant supervisors during a series of 20 continual resets.
The goal of this test is to verify that the box fails between the supervisors as designed, recovers, and
forwards traffic. This test is further designed to verify that failure operations are within the design
guidelines for the applicable hardware and software versions under test. Although this test measures
time, it is by no means a measure of the speed at which failover can take place, which is dependent upon
the configuration and line cards in the system.
Supervisor Engine 2s are covered in this test. The device under test is SH1-110. A traffic stream was sent
from Dista-1 to Dista-2 a a fixed rate. 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 2 failover test follows:
Step 1
Verify that the DUT is running Cisco IOS Release 12.1(8b)E14.
Step 2
Show some of the factors that may contribute to reload times. Such factors may include configuration
size, memory used, and size of IP routing table.
Step 3
Shut down interface port-channel 20 on device SH1-109 to verify that the traffic generated in Step 2 goes
through SH1-110 to get to its destination.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
23
Hardware Redundancy
Step 4
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. Issue the reload command on SH1-110.
Step 5
Measure the period of time between which traffic stopped and it was started again. This period of time
is considered the failover time.
Step 6
Repeat Step 4 through Step 5 19 more times.
Expected Results
The following test results are expected:
•
All 20 resets of the supervisor should fail within the range of 1.5 to 2.5 minutes.
•
Supervisors should come back online without any manual intervention.
Results
Table 8 shows the supervisor 2 failover test results.
Table 8
Supervisor 2 Failover Test Results
Tests
Results
Supervisor 2 Failover
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
24
Layer 2 Features
Layer 2 Features
Layer 2 feature testing for Safe Harbor involves the features:
•
Spanning Tree Protocol, page 25
•
Unidirectional Link Detection-Aggressive Mode, page 26
•
Trunking, page 29
•
Port Aggregation Protocol (Channeling), page 31
•
VLAN Trunking Protocol, page 37
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.
Note
STP has limited use in the financial customer topology, so it receives limited attention in testing.
The following test was performed:
•
Basic Spanning Tree Protocol Configuration, page 25
Basic Spanning Tree Protocol Configuration
This test verified that 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.
Devices under test: SH1-109, SH1-110, and Dista-2.
Note
Safe Harbor testing for Native IOS limits STP coverage because customer implementation is limited.
Test Plan
The procedure used to perform the basic functionality of Spanning Tree Protocol test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Verify that trunk links are configured between SH1-109 and Dista-2 and also between SH1-110 and
Dista-2.
Step 5
Verify that SH2-109 is the root switch for all VLANs in the 10 to 20 range.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
25
Layer 2 Features
Note
The empty root port and root cost of 0 above signifies that this DUT is root on these VLANs.
Step 6
Disable the link between SH1-110 and Dista-2.
Step 7
Verify that spanning-tree converges and a new root is elected on each VLAN.
Step 8
Disable the link between SH1-110 and Dista-2.
Step 9
Verify that spanning-tree converges and the original root is reelected on each VLAN.
Step 10
Verify that the DUT did not record any tracebacks.
Step 11
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Spanning tree convergence times should not exceed configured specifications.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 9 shows the basic Spanning Tree Protocol configuration test results.
Table 9
Basic Spanning Tree Protocol Configuration Test Results
Tests
Results
Basic Spanning Tree Protocol Configuration
Pass
Unidirectional Link Detection-Aggressive Mode
The Unidirectional Link Detection (UDLD) protocol allows devices connected through fiber-optic or
copper Ethernet cables (for example, Category 5 cabling) to monitor the physical status 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.
In a bidirectional relationship, the UDLD-AM (aggressive mode) protocol disables the port at the end of
a link-up sequence if no reply is received. However, UDLD goes into an undetermined state.
The lowest value of a UDLD-AM message interval can be only 7 seconds, and the hold down time can
be 21 seconds.
Note
The lowest value of UDLD-AM message interval can be only 7 seconds, and the hold down time can
be 21 sec. By default, the HSRP hello timer is 3 sec. and the hold down timer is 10 sec. When the
link becomes unidirectional, before the UDLD-AM can shut down the port, the HSRP will flap. After
UDLD-AM shuts down the unidirectional port, the HSRP will stay up and be stable.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
26
Layer 2 Features
Note
The lowest value of UDLD-AM message interval can be only 7 seconds, and the hold down time can
be 21 sec. By default, EIGRP hello timer is 5 sec. and hold down timer is 15 sec. When the link
becomes unidirectional, before the UDLD-AM can shut down the port, the EIGRP neighbor will flap.
After UDLD-AM shuts down the unidirectional port, the EIGRP neighbor will stay up and be stable.
Note
If UDLD mode or UDLD-AM are enabled globally on WFDM switches, the interface shows the
UDLD message interval is 7 sec which is actually "running message interval." Once the UDLD
neighbor is established, the message interval changed to 60 sec. See CSCdv74001, which is
integrated in Herschel 8EX and will be in Cisco IOS Release 13E but not Cisco IOS Release 8E.
The following tests were performed:
•
Basic UDLD on Layer 2 Link, page 27
•
Basic UDLD on Layer 3 Link, page 28
Basic UDLD on Layer 2 Link
This test created a unidirectional link between SH1-109 (DUT) and Dista-2. Console messages are
logged during the mock failure, and port states are recorded.
Test Plan
The procedure used to perform the basic UDLD on Layer 2 link test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Verify that UDLD is configured globally on the DUT and that UDLD Aggressive Mode is configured
locally on the interface g7/3.
Step 5
With terminal monitoring configured, pull the receive fiber from port 1/1 on Dista-2. Log any messages
on the DUT.
Step 6
Verify the interface state of g7/3 on the DUT.
Step 7
Reconnect the send fiber.
Step 8
Record any log messages on the DUT.
Step 9
Verify the interface state. Issue the reset udld command on the DUT if the interface g7/3 does not return
to up/up state.
Step 10
Verify that the DUT did not record any tracebacks.
Step 11
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
UDLD should err-disable the port when the fiber was pulled.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
27
Layer 2 Features
•
The port should recover when the fiber is plugged back in.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 10 shows the basic UDLD on Layer 2 link test results.
Table 10
Basic UDLD on Layer 2 Link Test Results
Tests
Results
Basic UDLD on Layer 2 Link
Pass
Basic UDLD on Layer 3 Link
This test emulated a unidirectional link on a Layer 3 interface. Console messages are logged, and
interface states throughout the process.
Devices under test: SH1-104, and SH1-109.
Test Plan
The procedure used to perform the basic UDLD on Layer 3 link test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Verify that UDLD is configured globally on both DUTs and that UDLD Aggressive Mode is configured
locally on the interfaces g4/15 of SH1-104 and g3/5 of SH1-109. Also verify that terminal monitoring
is active on this session.
Step 5
Once it has been verified that the interfaces connecting the DUTs are in state up/up, pull the send side
of the g3/5 interface on SH1-109.
Step 6
Record logging messages from both DUTs and their interface states.
Step 7
Reconnect the fiber pulled out in Step 4. Use the reset udld command to verify the interfaces are again
up/up.
Step 8
Pull out the receive side of the g3/5 interface on SH1-109 and record all messages and the interface states
from both DUTs.
Step 9
Reconnect the fiber pulled out in Step 7. Use the reset udld command to verify the interfaces are again
up/up.
Step 10
Verify that the DUT did not record any tracebacks.
Step 11
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
UDLD should err-disable the port when the fiber was pulled.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
28
Layer 2 Features
•
The port should recover when the fiber is plugged back in.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 11 shows the basic UDLD on Layer 3 link test results.
Table 11
Basic UDLD on Layer 3 Link Test Results
Tests
Results
Basic UDLD on Layer 3 Link
Pass
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 12 lists and describes the five modes of trunking on Cisco
switches.
Table 12
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:
•
Supervisor 1 Configuration and Failure Recovery, page 29
•
Supervisor 2 Configuration and Failure Recovery, page 30
Supervisor 1 Configuration and Failure Recovery
In this procedure tested the configuration of both static and dynamically formed trunks, the recovery of
both static and dynamic trunks, and trunk links that exist between SH1-107 and dista-1. These links were
configured, then failed and recovered to verify that trunking is reestablished.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
29
Layer 2 Features
Test Plan
The procedure used to perform the trunking supervisor 1 configuration and failure recovery test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
The standard configuration for this link in the Safe Harbor network is both sides configured for static
trunking. Verify this is the current configuration and the trunk is currently working.
Step 5
Change the configuration on both sides to dynamic trunking, and verify that the ports begin trunking
again.
Step 6
Fail one of the trunking links on SH1-107 and verify that it is down.
Step 7
Bring the port back up, and verify that the port begins trunking again.
Step 8
Change the configuration on both sides back to static trunking, and verify that the ports begin trunking
again.
Step 9
Fail one of the trunking links on SH1-107 and verify that it is down.
Step 10
Bring the port back up, and verify that the port begins trunking again.
Step 11
Verify that the DUT did not record any tracebacks.
Step 12
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
The DUT should be able to trunk in both static and dynamic mode.
•
The trunk port should recover from a port failure.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 13 shows the trunking supervisor 1 configuration and failure recovery test results.
Table 13
Trunking Supervisor 1 Configuration and Failure Recovery Test Results
Tests
Results
Supervisor 1 Configuration and Failure Recovery Pass
Supervisor 2 Configuration and Failure Recovery
In this procedure tested the configuration of both static and dynamically formed trunks, the recovery of
both static and dynamic trunks, and trunk links that exist between SH1-109 and dista-1. These links were
configured, then failed and recovered to verify that trunking is reestablished.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
30
Layer 2 Features
Test Plan
The procedure used to perform the trunking supervisor 2 configuration and failure recovery test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
The standard configuration for this link in the Safe Harbor network is both sides configured for dynamic
trunking. Verify that this is the current configuration and the trunk is currently working.
Note
The lack of switchport mode configuration implies that the port is configured as desirable.
Step 5
Change the configuration on both sides to static trunking, and verify that the ports begin trunking again.
Step 6
Fail one of the trunking links on SH1-109 and verify that it is down.
Step 7
Bring the port back up, and verify that the port begins trunking again.
Step 8
Change the configuration on both sides back to dynamic trunking, and verify that the ports begin
trunking again.
Step 9
Fail one of the trunking links on SH1-109 and verify that it is down.
Step 10
Bring the port back up, and verify that the port begins trunking again.
Step 11
Verify that the DUT did not record any tracebacks.
Step 12
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
The DUT should be able to trunk in both static and dynamic mode.
•
The trunk port should recover from a port failure.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 14 shows the trunking supervisor 2 configuration and failure recovery test results.
Table 14
Trunking Supervisor 2 Configuration and Failure Recovery Test Results
Tests
Results
Supervisor 2 Configuration and Failure Recovery Pass
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
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
31
Layer 2 Features
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, page 32
•
Basic Layer 3 Channeling Configuration, page 33
•
Gigabit Ethernet Module Reset, page 35
Basic Layer 2 Channeling Configuration
In Native IOS, a port-channel interface is created, and then individual interfaces are joined to that
port-channel interface. The configuration of the individual interfaces determines whether the channel is
static or dynamic.
This test verified the basic aspects of Layer 2 PAgP configuration to verify that the basic functionality
worked correctly. A set of links between SH1-107 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.
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.
Figure 9 shows the topology for PAgP Basic Layer 2 channeling configuration.
Figure 9
PAgP Basic Layer 2 Channeling Topology
Devices under test: SH1-107, and SH1-110.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
32
Layer 2 Features
Test Plan
The procedure used to perform the PAgP basic Layer 2 channeling test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that the channel between devices SH1-107 and Dista-1 is configured as a static channel.
Step 3
Verify that the channel between devices SH1-110 and Dista-1 is configured as a dynamic channel.
Expected Results
The following test results are expected:
•
The Layer 2 channels should form with their respective static and dynamic configurations.
Results
Table 15 shows the PAgP basic Layer 2 channeling test results.
Table 15
PAgP Basic Layer 2 Channeling Test Results
Tests
Results
Basic Layer 2 Channeling Configuration
Pass
Basic Layer 3 Channeling Configuration
This test verified Layer 3 port-channel functionality. 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 16 maps each of the
six steps to the combination covered.
Table 16
Step #
Basic Layer 3 Channeling Configuration Matrix
Devices
dCEF?
Channeling?
Step 1 103-99
Yes
Static
Step 2 104-99
Yes
Dynamic
Step 3 103-109
Mixed Static
Step 4 103-110
Mixed Dynamic
Step 5 103-107
No
Static
Step 6 104-107
No
Dynamic
Figure 10 and Figure 11 show the topologies for PAgP basic Layer 3 channeling configuration.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
33
Layer 2 Features
Figure 10
PAgP Basic Layer 3 Channeling Topology
port-channel
Figure 11
PAgP Basic Layer 3 Channeling Topology
Devices under test: SH1-103, SH1-99, SH1-104, SH1-107, SH1-109, and SH1-110.
Test Plan
The procedure used to perform the PAgP basic Layer 3 channeling test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
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.
Step 3
The port-channel (4 ports) between SH1-104 (Po17) and SH1-99 (Po17) resides on dCEF-only modules.
Verify that it is configured for dynamic channeling and that it is functioning correctly.
Step 4
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.
Step 5
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.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
34
Layer 2 Features
Step 6
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.
Step 7
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.
Expected Results
The following test results are expected:
•
The port-channels should form correctly in each configuration and line card combination.
Results
Table 17 shows the basic PAgP basic Layer 3 channeling test results.
Table 17
Basic PAgP Layer 3 Channeling Test Results
Tests
Results
Basic Layer 3 Channeling Configuration
Pass
Gigabit Ethernet Module Reset
This test verified the ability of Layer 2 and Layer 3 EtherChannels to handle module resets and failures.
The supervisor 1 and supervisor 2 were both tested with IXIA traffic (configured for 20 source IP
addresses and 1 destination IP address) sent from Dista-1 to Dista-2. Two modules were reset,
individually, on device SH1-108 (Sup1). One of the modules was involved in a Layer 2 Gigabit
EtherChannel (GEC) and the other in a Layer 3 GEC. For Sup2 coverage, a single module was reset on
SH1-110. This module has interfaces involved in both Layer 2 and Layer 3 GECs.
Figure 12 shows the topology for PAgP Gigabit Ethernet module reset configuration:
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
35
Layer 2 Features
Figure 12
PAgP Gigabit Ethernet Module Reset Topology
Devices under test: SH1-108, and SH1-110.
Test Plan
The procedure used to perform the PAgP Gigabit Ethernet module reset test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Stop the background unicast traffic streams temporarily so that they do not interfere in the counter
observation.
Step 4
Begin an IXIA traffic stream, sourcing from 20 IP addresses, on Dista-1, destined for a single IP address
connected to Dista-2.
Step 5
Verify that the traffic is being load-balanced across all the aggregated interfaces of port-channels 10, 69,
and 169 of device SH1-108.
Step 6
Reset module 4 of SH1-108. This module has interfaces (g4/1-g4/4) that make up a Layer 2 channel and
interfaces (g4/5-6) that make up half of a Layer 3 channel.
Step 7
Verify that the channel reforms correctly after the module comes back online and that those interfaces
on module 4 that were passing traffic before are again passing traffic.
Step 8
Reset module 3 of SH1-108. This module has interfaces involved in two separate Layer 3 GECs
(g3/1-g3/4 of port-channel 69 and g3/5-g3/6 of port-channel 169).
Step 9
Verify that the interfaces on module 3 are aggregated back into port-channels 69 and 169 correctly, and
that they are again passing traffic.
Step 10
Verify that the interfaces on module 7 of SH1-110 that are involved in port-channels 20 and 71 are
passing traffic.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
36
Layer 2 Features
Step 11
Reset module 7 of SH1-110. This module has interfaces (g7/3 and g7/5) that are involved in a Layer 2
channel (port-channel 20) and an interface (g7/1) that is involved in a Layer 3 GEC (port-channel 71).
Step 12
Verify that the interfaces in module 7 are aggregated back into their respective port-channels correctly
and that they are again passing traffic.
Step 13
Verify that the interfaces on module 3 that are involved in port-channels 71 and 171 are passing traffic.
Step 14
Reset module 3 of SH1-110. This module has an interface (g3/1) that is involved in a Layer 3 channel
(port-channel 71) and two interfaces (g3/3-4) that are involved in a Layer 3 GEC (port-channel 171).
Step 15
Verify that the interfaces in module 3 are aggregated back into their respective port-channels correctly
and that they are again passing traffic.
Step 16
Restart the background unicast traffic streams.
Step 17
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Following the reset of the module, the interfaces on that module should be reaggregated back into
their respective port-channels and again pass traffic.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 18 shows the PAgP Gigabit Ethernet module reset test results.
Table 18
PAgP Gigabit Ethernet Module Reset Test Results
Tests
Results
Gigabit Ethernet Module Reset
Pass
VLAN Trunking Protocol
VLAN Trunking Protocol (VTP) is a Layer 2 messaging protocol that maintains VLAN configuration
consistency by managing the addition, deletion, and renaming of VLANs on a network-wide basis. VTP
minimizes misconfigurations and configuration inconsistencies that can result in a number of problems,
such as duplicate VLAN names, incorrect VLAN-type specifications, and security violations.
You can use VTP to manage VLANs 1 to 1005 in your network. (Note that VTP does not support VLANs
1025 to 4094.) With VTP, you can make configuration changes centrally on one switch and have those
changes automatically communicated to all the other switches in the network.
The following test was performed:
•
Basic VLAN Trunking Protocol Configuration, page 37
Basic VLAN Trunking Protocol Configuration
This procedure tests the various combinations of VTP client, server, and transparent modes between
devices SH1-107 and Dista-1. With each combination that is tested, VLANs are configured and behavior
is checked for normalcy.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
37
Layer 2 Features
Device under test: SH1-107.
Test Plan
The procedure used to perform the basic VLAN trunking protocol configuration test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify that SH1-107 and Dista-1 are in VTP transparent mode and that both devices are in the domain
named FIN.
Step 4
Verify that a trunk link is configured between SH1-107 (g4/1, g4/3) and Dista-1 (1/1, 2/1).
Step 5
Run the script that will execute the remaining steps of this test.
Step 6
Check the output of the script, to verify that both cases passed.
Step 7
With both SH1-107 and Dista-1 in transparent mode, configure VLAN 200 on SH1-107.
Step 8
Verify that VLAN 200 is created on SH1-107 but not on Dista-1.
Step 9
Configure SH1-107 for VTP server mode (Dista-1 still in transparent mode) and add VLAN 201 to the
VLAN database of SH1-107.
Step 10
Verify that VLAN 201 is created on SH1-107 but not on Dista-1.
Step 11
Configure Dista-1 for VTP mode client (SH1-107 is server) and add VLAN 202 to the VLAN database
on SH1-107.
Step 12
Verify that VLAN 202 was added to both SH1-107 and Dista-1.
Step 13
Configure Dista-1 for VTP server mode (SH1-107 in server mode), and add VLAN 203 to SH1-107.
Step 14
Verify that VLAN 203 is created on both SH1-107 and Dista-1.
Step 15
With SH1-107 and Dista-1 both in server mode, enable VTP Version 2 on Dista-1 (VTP V2 disabled on
SH1-107).
Step 16
Configure VLAN 204 on SH1-107.
Step 17
Verify that VLAN 204 is created on both SH1-107 and Dista-1.
Step 18
With the same VTP configurations as in Step 13, create VLAN 205 on Dista-1.
Step 19
Verify that VLAN 205 is created on both SH1-107 and Dista-1.
Step 20
With SH1-107 in server mode, configure Dista-1 for VTP transparent mode and SH1-108 for VTP client
mode.
Step 21
Configure VLAN 206 on SH1-107.
Step 22
Verify that VLAN 206 is not created on Dista-1 but is created on SH1-108.
Step 23
Verify the CPU and memory of the device under test.
Expected Results
The following test results are expected:
•
When a switch is in VTP transparent mode, it should not accept any VLAN changes from a VTP
server but should still forward the changes to other VTP switches in the domain. Locally created
VLANs should not be propagated to other VTP clients or VTP servers.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
38
Layer 2 Features
•
When a switch is in VTP client mode, it should accept VLAN changes from a VTP server, but no
changes should be allowed locally.
•
When a switch is in VTP server mode, local VLAN changes should be propagated to other VTP
servers and VTP clients.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 19 shows the basic VLAN trunking protocol configuration test results.
Table 19
Basic VLAN Trunking Protocol Configuration Test Results
Tests
Results
Basic VLAN Trunking Protocol Configuration
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
39
Hardware Forwarding Features
Hardware Forwarding Features
Hardware forwarding testing for Safe Harbor involves these features:
•
IP Unicast, page 40
•
IP Multicast, page 44
IP Unicast
The Internet Protocol (IP) is a packet-based protocol used to exchange data over computer networks. IP
handles addressing, fragmentation, reassembly, and protocol demultiplexing. It is the foundation on
which all other IP protocols (collectively referred to as the IP Protocol suite) are built. A network-layer
protocol, IP contains addressing and control information that allows data packets to be routed.
The Transmission Control Protocol (TCP) is built upon the IP layer. TCP is a connection-oriented
protocol that specifies the format of data and acknowledgments used in the transfer of data. TCP also
specifies the procedures that the networking devices use to verify that the data arrives correctly. TCP
allows multiple applications on a system to communicate concurrently because it handles all
demultiplexing of the incoming traffic among the application programs.
The following tests were performed:
•
Layer 2 Gigabit EtherChannel Failover—Supervisor 1, page 40
•
Layer 2 Gigabit EtherChannel Failover—Supervisor 2, page 41
•
Layer 3 Gigabit EtherChannel Failover, page 42
Layer 2 Gigabit EtherChannel Failover—Supervisor 1
This test sent traffic over an Layer 2 GEC, and the links in that GEC were failed one at a time until the
traffic was forced to find a different path to the destination.
Devices under test: SH1-108, which has an Layer 2 GEC connecting it with Dista-1.
Test Plan
The procedure used to perform the Layer 2 Gigabit EtherChannel failover—supervisor 1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Verify that the GEC (interface port-channel 10) between the SH1-108 and Dista-1 is up and the
appropriate physical interfaces are active within that channel.
Step 5
Start an IXIA traffic stream emulating 20 IP sources on Dista-1 sending to a single destination on
Dista-2.
Step 6
Verify that the first-hop for this traffic is the SH1-108 (HSRP active router).
Step 7
Use the etherchannel loadbalance command on the switch processor (SP) to verify that load is being
distributed evenly over all four interfaces of the GEC, based on source/destination IP pair.
Step 8
Shut down one interface of the GEC on the SH1-108.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
40
Hardware Forwarding Features
Step 9
Measure any traffic loss and verify that the traffic load is being balanced again over the remaining links.
Step 10
Repeat Step 8 through Step 9 three more times, until all interfaces of the SH1-108 have been shut down.
Step 11
Verify that all traffic now goes through SH1-107 (HSRP Standby Router) and measure traffic loss.
Step 12
Bring all the interfaces that have been shut down back up, so that port-channel 10 is up/up and all traffic
flows through DUT again.
Step 13
Measure any traffic loss.
Step 14
Shut down all interfaces in port-channel 10 at once.
Step 15
Measure traffic loss.
Step 16
Verify that the DUT did not record any tracebacks.
Step 17
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Step 18
Bring all the interfaces that have been shut down back up, so that port-channel 10 is up/up.
Expected Results
The following test results are expected:
•
When one port in EtherChannel is shut down, traffic should fail to operation ports.
•
When the entire EtherChannel goes down, traffic should fail to the standby HSRP router.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 20 shows the Layer 2 Gigabit EtherChannel failover—supervisor 1 test results.
Table 20
Layer 2 Gigabit EtherChannel Failover—Supervisor 1 Test Results
Tests
Results
Layer 2 Gigabit EtherChannel Failover—Supervisor 1
Pass
Layer 2 Gigabit EtherChannel Failover—Supervisor 2
This test verified that traffic was sent over a Layer 2 GEC, and the links in that GEC was failed one at a
time until the traffic is forced to find a different path to the destination.
Devices under test: SH1-110, which has an Layer 2 GEC connecting it with Dista-2.
Test Plan
The procedure used to perform the Layer 2 Gigabit EtherChannel failover—supervisor 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Verify that the GEC (interface port-channel 20) between the DUT (now SH1-110) and Dista-2 is up and
the appropriate physical interfaces are active within that channel.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
41
Hardware Forwarding Features
Step 5
Start an IXIA traffic stream emulating 20 IP sources on Dista-2 sending to a single destination on
Dista-1.
Step 6
Verify that the first hop for this traffic is the DUT (HSRP active router).
Step 7
Use the etherchannel loadbalance command on the SP to verify that load is being distributed evenly
over all four interfaces of the GEC, based on source/destination IP pair.
Step 8
Shut down one interface of the GEC on the DUT.
Step 9
Measure any traffic loss and verify that the traffic load is being balanced again over the remaining links.
Step 10
Repeat Step 8 through Step 9 three more times, until all interfaces of the SH1-110 have been shut down.
Step 11
Verify that all traffic now goes through SH1-109 (HSRP Standby Router) and measure traffic loss.
Step 12
Bring all the interfaces that have been shut down back up, so that port-channel 20 is up/up and all traffic
flows through DUT again.
Step 13
Measure any traffic loss.
Step 14
Shut down all interfaces in port-channel 20 at once.
Step 15
Measure traffic loss.
Step 16
Verify that the DUT did not record any tracebacks.
Step 17
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Step 18
Bring all the interfaces that have been shut down back up, so that port-channel 20 is up/up.
Expected Results
The following test results are expected:
•
When one port in EtherChannel is shut down, traffic should fail to operation ports.
•
When the entire EtherChannel goes down, traffic should fail to the standby HSRP router.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 21 shows the Layer 2 Gigabit EtherChannel failover—supervisor 2 test results.
Table 21
Layer 2 Gigabit EtherChannel Failover—Supervisor 2 Test Results
Tests
Results
Layer 2 Gigabit EtherChannel Failover—Supervisor 2 Pass
Layer 3 Gigabit EtherChannel Failover
This test verified the ability of a system to cope with a Layer 3 GEC failure, with a minimum amount of
traffic loss. IXIA traffic was directed through the Layer 3 GEC being tested, and the Layer 3 GEC will
undergo a forced failure, first one interface at a time, and then all interfaces at once. With the GEC
between SH1-108 and SH1-103 being tested, coverage for both the supervisor 1 (SH1-108) and the
supervisor 2 (SH1-103) is included in a single procedure.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
42
Hardware Forwarding Features
Test Plan
The procedure used to perform the Layer 3 Gigabit EtherChannel failover test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Verify that the GEC (interface port-channel 69) between the DUT (SH1-108) and SH1-103 is up and that
the appropriate physical interfaces are active within that channel.
Step 5
Change the OSPF cost on port-channel 169 between SH1-108 and SH1-104 so that port-channel 69 will
be preferred until all ports in that channel are shut down.
Step 6
Start an IXIA traffic stream emulating 20 IP sources on Dista-1 sending to a single destination on
Dista-2.
Step 7
Verify that this traffic is being forwarded through the Layer 3 port-channel under test.
Step 8
Use the etherchannel loadbalance command on the SP to verify that load is being distributed evenly
over all four interfaces of the GEC, based on source/destination IP pair.
Step 9
Shut down one interface of the GEC on the DUT.
Step 10
Measure any traffic loss and verify that the traffic load is being balanced again over the remaining links.
Step 11
Repeat Step 9 through Step 10 three more times, until all interfaces of the GEC have been shut down.
Step 12
Verify that all traffic now goes through SH1-104 and measure traffic loss.
Step 13
Bring all the interfaces that have been shut down back up, so that port-channel 69 is up/up and all traffic
flows through DUT again.
Step 14
Measure any traffic loss.
Step 15
Shut down all interfaces in port-channel 69 at once.
Step 16
Measure traffic loss.
Step 17
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Step 18
Bring all the interfaces that have been shut down back up, so that port-channel 69 is up/up.
Expected Results
The following test results are expected:
•
When one port in EtherChannel is shut down, traffic should fail to operation ports.
•
When the entire EtherChannel goes down, traffic should fail to the other route.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 22 shows the Layer 3 Gigabit EtherChannel failover test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
43
Hardware Forwarding Features
Table 22
Layer 3 Gigabit EtherChannel Failover Test Results
Tests
Results
Layer 3 Gigabit EtherChannel Failover
Pass
IP Multicast
Traditional IP communication allows a host to send packets to a single host (unicast transmission) or to
all hosts (broadcast transmission). IP multicast provides a third scheme, allowing a host to send packets
to a subset of all hosts (group transmission). These hosts are known as group members.
Packets delivered to group members are identified by a single multicast group address. Multicast packets
are delivered to a group using best-effort reliability, just like IP unicast packets.
The multicast environment consists of senders and receivers. Any host, regardless of whether it is a
member of a group, can send to a group. However, only the members of a group receive the message.
A multicast address is chosen for the receivers in a multicast group. Senders use that address as the
destination address of a datagram to reach all members of the group.
Membership in a multicast group is dynamic; hosts can join and leave at any time. There is no restriction
on the location or number of members in a multicast group. A host can be a member of more than one
multicast group at a time.
Note
On PFC1, the (*, G) can only be software switched. If the ip pim spt-threshold infinity command
is used on PFC1, there may be high CPU usage, and multicast packets might be lost under heavy
traffic.
Note
For this iteration of Safe Harbor Native IOS testing, and for all subsequent iterations, the following
interfaces have been equipped with the Texas-2 GBIC, which sends Gigabit Ethernet over copper:
SH1-103: g7/13 & g8/13, SH1-110: g3/1 & g7/1.
Note
All tests have been run with the mls ip multicast consistency-checker command enabled.
The following tests were performed:
•
Local Multicast, page 45
•
Regional Multicast with IGMP Functionality, page 46
•
Non-Reverse Path Forwarding Rate Limiting and Multicast Stub—Supervisor 1, page 48
•
Non-Reverse Path Forwarding Rate Limiting and Multicast Stub—Supervisor 2, page 50
•
Gigabit EtherChannel Failover: Non-dCEF, page 53
•
Gigabit EtherChannel Failover: Mixed-dCEF, page 55
•
Gigabit EtherChannel Failover: dCEF, page 58
•
Switch Fabric Module Failover, page 60
•
Gigabit Ethernet Module Failover—Supervisor 1, page 62
•
Gigabit Ethernet Module Failover—Supervisor 2, page 64
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
44
Hardware Forwarding Features
•
Protocol Independent Module-Designated Router Failover—Supervisor 11, page 66
•
Protocol Independent Module-Designated Router Failover—Supervisor 22, page 68
•
Auto-Rendezvous Point Functionality and Failover, page 70
•
Layer 3 Interface Multicast Negative, page 72
•
Protocol Independent Module-Rendezvous Point Failover—Supervisor 22, page 74
•
MSDP Failover, page 76
Local Multicast
This test verified multicast functionality on a local level, including the creation of hardware shortcuts
for multicast entries. In this test, IXIA was used to send traffic streams to five multicast groups,
239.255.8.100 through 239.255.8.104. The traffic entered the network at an interface on SH1-108, and
exited the network at three points, one on SH1-108 and two on Dista-1. Two million packets were sent
at a rate of 10,000 pps.
Figure 13 shows the topology for local multicast.
Figure 13
Local Multicast Topology
Device under test: SH1-108.
Test Plan
The procedure used to perform the local multicast test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Start the IGMP join traffic for the five multicast groups 239 255.8.100 through 239.255.8.104 on IXIA
ports 8/1 (Dista-1 4/1), 8/2 (Dista-1 4/6), and 7/1 (SH1-108 g3/8).
Step 4
Begin sending traffic on IXIA port 7/2.
Step 5
Verify that the proper (S, G) entries are created on SH1-108.
Step 6
Verify that the multicast traffic is being hardware-switched.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
45
Hardware Forwarding Features
Step 7
Verify that all multicast traffic that is sent is also received by the intended interfaces and ports.
Step 8
Stop the test traffic stream and the IXIA IGMP reports.
Step 9
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
That the multicast traffic for all 5 groups should be delivered to each intended recipient.
•
That the 5 multicast traffic flows to be hardware-switched in device under test.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 23 shows the local multicast test results.
Table 23
Local Multicast Test Results
Tests
Results
Local Multicast
Pass
Regional Multicast with IGMP Functionality
Internet Group Management Protocol (IGMP) software components run on both the Cisco router and the
switch. An IGMP-capable IP multicast router sees all IGMP packets and can inform the switch when
specific hosts join or leave IP multicast groups.
When the IGMP-capable router receives an IGMP control packet, it creates an IGMP packet that
contains the request type (either join or leave), the multicast group address, and the MAC address of the
host. The router sends the packet to a well-known address to which all switches listen. When a switch
receives the packet, the supervisor engine interprets the packet and modifies the forwarding table
automatically. Cisco Group Management Protocol (CGMP) should seamlessly integrate with IGMP and
performs the same function.
This test verified IGMP and CGMP basic functionality, including the IGMP and CGMP status, and
verified that no multicast traffic was flooded into ports that do not have a multicast client. IGMP joins
generated by IXIA-8/2 are sent to Dista-1 4/6 (VLAN 16) for multicast groups 239.255.104.105 through
239.255.104.109. Traffic for these groups was generated by IXIA 8/1 and sent to Dista-1 4/1 (VLAN
11). The traffic was 2 million packets sent at a rate of 10,000 pps. Success of the test was measured by
100 percent of traffic being received by the single receiver interface, no traffic going to unintended
interfaces, and no sustained or abnormal impact to the memory or CPU utilization.
Figure 14 shows the topology for regional multicast with IGMP functionality.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
46
Hardware Forwarding Features
Figure 14
Regional Multicast Topology
Devices under test: SH1-104, and SH1-108.
Test Plan
The procedure used to perform the regional multicast with IGMP functionality test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify that the SPT threshold for the devices under test is configured for "infinity." If it is not, reconfigure
the devices so that it is.
Step 4
Start the IGMP join messages on IXIA port 8/2 (Dista-1 4/6).
Step 5
Stop the background traffic stream on IXIA port 8/1.
Step 6
Begin sending multicast traffic using IXIA port 8/1 into Dista-1 port 4/1.
Step 7
Verify that device SH1-104 is the primary PIM-RP for multicast groups 239.255.104.105 through
239.255.104.109.
Step 8
On Dist A-1, determine that IGMP is working correctly by looking at the IGMP status.
Step 9
Verify that the primary PIM-RP, SH1-104, has the necessary entries in its multicast routing (mroute)
table (including the correct outgoing interface list) and the necessary multicast multilayer switching
(MMLS) entries.
Step 10
Verify that the PIM-DR for its local segment, SH1-108, has the correct entries in its mroute table
(including the correct outgoing interface list) and the necessary MMLS entries.
Step 11
Verify that 100 percent of packets sent were received by the appropriate port and not by the unintended
interfaces.
Step 12
Restart the background traffic stream that was stopped in Step 5 and stop the IGMP reports that were
started for this test.
Step 13
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
47
Hardware Forwarding Features
Expected Results
The following test results are expected:
•
IGMP and CGMP basic functionality should work properly, and that no multicast traffic is flooded
into ports that do not have a multicast client.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 24 shows the regional multicast with IGMP functionality test results.
Table 24
Regional Multicast with IGMP Functionality Test Results
Tests
Results
Regional Multicast with IGMP Functionality
Pass
Non-Reverse Path Forwarding Rate Limiting and Multicast Stub—Supervisor 1
Stub multicast routing allows you to configure remote and stub routers as IGMP proxy agents. Instead
of fully participating in PIM, these stub routers simply forward IGMP messages from the hosts to the
upstream multicast router.
This test verified that the multicast stub command worked and that non-Reverse Path Forwarding (RPF)
rate limiting functionality worked on Policy Feature Cards (PFC1 and PFC2), and dCEF, including a
hardware shortcut.
PFC1, PFC2, and the DFCs support ACL-based filtering of RPF failures for sparse mode stub networks.
When you enable the ACL-based method of filtering Reverse Path Forwarding failures by entering the
mls ip multicast stub command on the redundant router, the ACLs automatically download to the PFC
and are applied to the interface you specify.
The ACLs filter Reverse Path Forwarding failures and drop them in hardware so that they are not
forwarded to the router. This test grades multicast stub functionality on the PFC1 (on SH1-107).
Multicast traffic was sent from one side of the network to the other (from Dista-2 to Dista-1). As a
component of this test, the non-RPF rate-limiting functionality was observed.
In this part of the test, SH1-107 was configured to be the multicast stub router. Five groups of multicast
traffic (groups 239.255.104.110 through 239.255.104.114) were sent from Dista-2. Joins for these five
groups were sent from Dista-1. The IP address of the remote interface connecting SH1-107 to SH1-104
was configured as the IGMP helper address. The IGMP join packets that were received by SH1-107 were
forwarded via this address statement to SH1-104. All five groups should appear on SH1-104, when the
show ip igmp groups command is used.
Coupled with the mls ip multicast stub command on SH1-107 is the ip pim neighbor-filter access-list
command configured on SH1-104. This configuration blocked PIM neighbor updates coming from
SH1-107, and made SH1-107 truly transparent to the rest of multicast functionality.
Figure 15 shows the topology for the Non-RFP rate limiting and multicast stub—supervisor 1 test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
48
Hardware Forwarding Features
Figure 15
Multicast Stub—Supervisor 1 Topology
Devices under test: SH1-107, SH1-108, and SH1-104.
Test Plan
The procedure used to perform the non-RPF rate limiting and multicast stub—supervisor 1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that the SPT threshold is set to infinity on devices SH1-107 and SH1-108. If it is not, configure
it to be so.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Configure the VLAN 11 interface (source of IGMP joins) on SH1-107 as a multicast stub.
Step 5
Configure the IP helper address for SH1-107 VLAN 11, the address on SH1-104 to which SH1-107 will
forward the IGMP join packets.
Step 6
Configure SH1-104 to filter out IP PIM neighbor updates coming from SH1-107 on the interface
port-channel 169.
Step 7
Verify that access list 10 exists and points to the correct IP address of the blocked PIM updates (the IP
address of the interface on SH1-107 connected to SH1-104, or 172.31.1.102).
Step 8
Begin the IGMP join messages for the five multicast groups on Dista-1 port 4/1 (IXIA port 8/1).
Step 9
Begin the IXIA traffic stream for the five multicast groups on Dista-2 port 2/1.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
49
Hardware Forwarding Features
Step 10
Verify that the IGMP join messages have been forwarded from SH1-107 to SH1-104 and that SH1-104
does not register SH1-107 as an IP PIM neighbor.
Step 11
Verify that RPF rate limiting is done in hardware on the stub router.
Step 12
Determine the path of traffic to the receiver, starting at SH1-104 (the rendezvous point). Traffic is
expected to be sent out both interfaces of port-channel 68 and port-channel 69 from SH1-104, to
SH1-107 and SH1-108, respectively, because there are IGMP joins coming from port-channel 68
(forwarded from SH1-107) and PIM requests coming from port-channel 69 (from SH1-108). The traffic
should be forwarded, beyond that, only by SH1-108, because that is the PIM-DR for that segment.
SH1-107 should not be forwarding traffic.
Step 13
Verify that 100 percent of the multicast traffic that was sent is received on the appropriate port (zero
packet loss).
Step 14
Negate the commands configured in Step 4 through Step 6.
Step 15
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
SH1-107 should act as a multicast stub router and forward IGMP packets to its helper address, on
SH1-104.
•
SH1-104 should receive and process the IGMP packets sent by SH1-107.
•
SH1-104 should not have SH1-107 listed in its PIM neighbor table when the neighbor-filter
command is configured.
•
Rate-limiting of non-RPF failures should be done in hardware.
•
All traffic sent should be received by the appropriate receivers, following the correct path.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 25 shows the non-RPF rate limiting and multicast stub—supervisor 1 test results.
Table 25
Non-RFP Rate Limiting and Multicast Stub—Supervisor 1Test Results
Tests
Results
Non-Reverse Path Forwarding Rate Limiting and Multicast Stub—Supervisor 1 Pass
Non-Reverse Path Forwarding Rate Limiting and Multicast Stub—Supervisor 2
Stub multicast routing allows you to configure remote and stub routers as IGMP proxy agents. Instead
of fully participating in PIM, these stub routers simply forward IGMP messages from the hosts to the
upstream multicast router.
This test verified that the multicast stub command worked and that non-Reverse Path Forwarding (RPF)
rate limiting functionality worked on Policy Feature Cards (PFC1 and PFC2), and dCEF, including a
hardware shortcut.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
50
Hardware Forwarding Features
PFC1, PFC2, and the DFCs support ACL-based filtering of RPF failures for sparse mode stub networks.
When you enable the ACL-based method of filtering RPF failures by entering the mls ip multicast stub
command on the redundant router, the ACLs automatically download to the PFC and are applied to the
interface you specify.
The ACLs filter Reverse Path Forwarding failures and drop them in hardware so that they are not
forwarded to the router. Multicast traffic was sent from one side of the network to the other (from Dista-1
to Dista-2). As a component of this test, the non-RPF rate limiting functionality was observed.
In this part of the test, SH1-109 was configured to be the multicast stub router. Five groups of multicast
traffic (groups 239.255.104.115 through 239.255.104.119) were sent from an IXIA port connected to
Dista-1. Joins for these five groups were sent from an IXIA port connected to Dista-2. The IP address of
the remote interface connecting SH1-109 to SH1-104 was configured as the IGMP helper address. The
IGMP join packets that are received by SH1-109 were forwarded via this address statement to SH1-104.
All five groups should appear on SH1-104, when the show ip igmp groups command is used.
Coupled with the mls ip multicast stub command on SH1-109 is the ip pim neighbor-filter access-list
command configured on SH1-104. This configuration blocked PIM neighbor updates coming from
SH1-109, and made SH1-109 truly transparent to the rest of multicast functionality.
Figure 16 shows the topology for Non-RPF rate limiting and multicast stub—supervisor 2 test.
Figure 16
Multicast Stub—Supervisor 2 Topology
Devices under test: SH1-109, SH1-110, and SH1-104.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
51
Hardware Forwarding Features
Test Plan
The procedure used to perform the non-RPF rate limiting and multicast stub—supervisor 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that the SPT threshold is set to infinity on devices SH1-109 and SH1-110. If it is not, configure
it to be so.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Configure the VLAN 11 interface (source of IGMP joins) on SH1-109 as a multicast stub.
Step 5
Configure the IP helper address for SH1-109 VLAN 11, the address on SH1-104 to which SH1-107 will
forward the IGMP join packets.
With this helper address configured, SH1-109 will process the IGMP packets itself, and will also forward
them to SH1-104.
Step 6
Configure SH1-104 to filter out IP PIM neighbor updates coming from SH1-109 on the interface
port-channel 170.
Step 7
Verify that access list 20 exists and points to the correct IP address of the blocked PIM updates (the IP
address of the interface on SH1-109 connected to SH1-104, or 172.31.1.110).
SH1-104 will no longer accept PIM updates from SH1-109.
This access list will cause any traffic coming from SH1-109 (IP address 172.31.1.110, the address of the
remote side of port-channel 70, which is SH1-104's connection to SH1-109), including PIM neighbor
updates, to be denied.
Step 8
Begin the IGMP join messages for the five multicast groups on Dista-2 port 2/1 (IXIA port 10/1).
Step 9
Begin the IXIA traffic stream for the five multicast groups on Dista-1 port 4/6.
Step 10
Verify that the IGMP join messages have been forwarded from SH1-109 to SH1-104 and that SH1-104
does not register SH1-109 as an IP PIM neighbor.
Step 11
Verify that RPF rate limiting is done in hardware on the stub router.
Step 12
Determine the path of traffic to the receiver, starting at SH1-104 (the rendezvous point). Traffic is
expected to be sent out both interfaces, port-channel s 70 and 71 from SH1-104, to SH1-109 and
SH1-110, respectively, because there are IGMP joins coming from port-channel 70 (forwarded from
SH1-109) and PIM requests coming from port-channel 71 (from SH1-110). The traffic should be
forwarded, beyond that, only by SH1-110, because that is the PIM-DR for that segment. SH1-109 should
not be forwarding traffic.
Step 13
Verify that 100 percent of the multicast traffic that was sent is received on the appropriate port (zero
packet loss).
A script was used to start the test traffic stream and collect statistics.
Step 14
Negate the commands configured in Step 4 through Step 6.
Step 15
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
SH1-109 should act as a multicast stub router and forward IGMP packets to its helper address, on
SH1-104.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
52
Hardware Forwarding Features
•
SH1-104 should receive and process the IGMP packets sent by SH1-109.
•
SH1-104 should not have SH1-109 listed in its PIM neighbor table, when the neighbor-filter
command is configured.
•
Rate limiting of non-RPF failures should be done in hardware.
•
All traffic sent should be received by the appropriate receivers, following the correct path.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 26 shows the non-RPF rate limiting and multicast stub—supervisor 2 test results.
Table 26
Non-RFP Rate Limiting and Multicast Stub—Supervisor 2 Test Results
Tests
Results
Non-Reverse Path Forwarding Rate Limiting and Multicast Stub—Supervisor 2 Pass
Gigabit EtherChannel Failover: Non-dCEF
This test verified multicast and MSDP functionality during a non distributed Cisco Express Forwarding
(dCEF) GEC failover.
Traffic for multicast groups 239.255.104.115 through 239.255.104.119 was sent out via IXIA from
Dista-1 and received at Dista-2. Traffic was sent at a rate of 10,000 pps. The port-channel between
devices SH1-104 (Po69) and SH1-108 (Po169) was failed, first two of four ports, then all four ports.
Figure 17 shows the topology for non-dCEF Gigabit EtherChannel failover test.
Figure 17
Non-dCEF Gigabit EtherChannel Failover Topology
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
53
Hardware Forwarding Features
Devices under test: SH1-103, SH1-104, SH1-107, SH1-108, SH1-109, and SH1-110.
Note
Background traffic remained running for this test at a rate of 25,000 pps. Results for zero-packet loss
of this traffic are not given, though, because the test involved failovers and traffic was certain to be
lost.
Test Plan
The procedure used to perform the Gigabit EtherChannel failover: non-dCEF test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that SH1-103 and SH1-104 are running MSDP Anycast and are peered with each other.
Step 3
Verify that the SPT-threshold is configured for "infinity" on devices SH1-109 and SH1-110.
Step 4
Begin monitoring memory and CPU utilization for the devices being tested.
Step 5
Start IGMP join traffic for multicast groups 239.255.104.115 through 239.255.104.119 on IXIA port
10/1, which is connected to Dista-2 2/1.
Step 6
Start the test traffic stream.
Step 7
Configure the test traffic stream to run in continuous mode.
Step 8
Verify that SH1-104 is the primary PIM rendezvous point for the given multicast groups and that
SH1-108 is forwarding the test multicast group traffic to SH1-104.
Step 9
Verify that the MMLS entries for the test multicast groups are consistent with the mroute entries seen.
Step 10
Verify that the modules connecting SH1-104 and SH1-108 are non-dCEF modules. The ports connecting
them are g8/7-g8/10 on the SH1-104 side, and g3/5-6, g4/5-6 on the SH1-108 side.
Step 11
Use the test etherchannel command on the supervisor (SP, not Route Processor) of SH1-108 to verify
that each link of the GEC should pass some multicast traffic.
Step 12
Verify that traffic is actually being passed across each of the physical interfaces using the interface
counters.
Step 13
Configure the test traffic stream to stop after sending 500,000 packets.
Step 14
Stop and restart the test traffic stream.
Step 15
Fail two links of the 4-port GEC between SH1-104 and SH1-108, forcing some multicast traffic to move
to two other links.
Step 16
Measure any traffic loss.
Step 17
Verify that traffic is now flowing through device SH1-107, which has the lower OSPF cost to SH1-104
now, and that the mroute table entries on SH1-104 and SH1-107 are consistent with the devices'
respective MMLS entries.
Step 18
Bring up the two links that were failed.
Step 19
Verify that traffic is flowing again through SH1-108, and that the mroute table entries on SH1-104 and
SH1-108 are consistent with the devices' respective MMLS entries.
Step 20
Restart the IXIA test traffic stream.
Step 21
Fail the entire port-channel interface between SH1-104 and SH1-108, forcing multicast traffic to go
through SH1-107 to get to SH1-104.
Step 22
Measure the traffic loss.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
54
Hardware Forwarding Features
Step 23
Verify that traffic is now flowing through device SH1-107, and that the mroute table entries on SH1-104
and SH1-107 are consistent with the devices' respective MMLS entries.
Step 24
Bring the channel back online.
Step 25
Verify that traffic once again flows through SH1-108, and that the mroute table entries on SH1-104 and
SH1-108 are consistent with the devices' respective MMLS entries.
Step 26
Fail the port-channel interface four more times, recording the traffic loss each time.
Step 27
Determine the average amount of downtime over the five tests.
Step 28
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Traffic should failover and be forwarded by SH1-107 when half and then all of the port-channel
between SH1-108 and SH1-104 is torn down.
•
Failover should take place in a reasonable time (within the 10-second HSRP dead timer value).
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 27 shows the Gigabit EtherChannel failover: non-dCEF test results.
Table 27
Gigabit EtherChannel Failover: Non-dCEF Test Results
Tests
Results
Gigabit EtherChannel Failover: Non-dCEF
Pass
Gigabit EtherChannel Failover: Mixed-dCEF
This test verified multicast and MSDP functionality during the failover of a port-channel on dCEF and
non-dCEF modules. There is a four-port-channel between devices SH1-103 and SH1-110. On the
SH1-103 side, those four ports are divided evenly between two modules, a dCEF-capable module and a
non-dCEF module. During this test, multicast traffic was sent from Dista-2 to Dista-1. The two ports on
the non-dCEF module were disabled and enabled, one port on each dCEF and non-dCEF module was
disabled and enabled, both ports on the dCEF card were disabled and enabled, and, all four ports were
disabled and enabled. Traffic for multicast groups 239.255.104.120 through 239.255.104.124 was sent
at a rate of 10,000 pps. The source IP address of the traffic streams is incremented so that the traffic is
coming from four sources which assures that traffic was distributed over all the interfaces in the
port-channel.
Note
Applicable to this test, among others, is the static topology change in which SH1-103 interfaces
g7/13 and g8/13, and SH1-110 g3/1 and g7/1, are using the Texas 2 GBICs (WS-X5383) to run
Gigabit Ethernet over copper.
Figure 18 shows the topology for the mixed-dCEF Gigabit EtherChannel failover test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
55
Hardware Forwarding Features
Figure 18
Mixed-dCEF Gigabit EtherChannel Failover Topology
Devices under test: SH1-103, SH1-104, SH1-107, SH1-108, SH1-109, and SH1-110.
Test Plan
The procedure used to perform the Gigabit EtherChannel failover: mixed-dCEF test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that SH1-103 and SH1-104 are running MSDP Anycast and are peered with each other.
Step 3
Verify that the SPT-threshold is configured for "infinity" on devices SH1-107 and SH1-108.
Step 4
Begin monitoring memory and CPU utilization for the devices being tested.
Step 5
Configure the OSPF cost to be 100 on the Loop back 1 interface of SH1-104. This will cause SH1-103
to become the RP for the multicast groups under test.
Step 6
Start IGMP join traffic for multicast groups 239.255.104.120 through 239.255.104.124 on IXIA port 8/2,
which is connected to Dista-1 4/6.
Step 7
Start the test traffic stream.
Step 8
Configure the test traffic stream to run in continuous mode.
Step 9
Verify that SH1-103 is the primary PIM rendezvous point for the given multicast groups and that
SH1-110 is forwarding the test multicast group traffic to SH1-103.
Step 10
Verify that the MMLS entries for the test multicast groups are consistent with the mroute entries seen.
Step 11
Verify that the modules connecting SH1-103 and SH1-110 are mixed-dCEF modules. The ports
connecting them are g7/13-14, g8/13-14 on the SH1-103 side, and g3-4/1, g7-8/1 on the SH1-110 side.
Step 12
Use the test etherchannel command on the supervisor (SP, not Route Processor) of SH1-110 to verify
that each link of the GEC should pass some multicast traffic.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
56
Hardware Forwarding Features
Step 13
Verify that traffic is actually being passed across each of the physical interfaces using the interface
counters.
Step 14
Configure the test traffic stream to stop after sending 500,000 packets.
Step 15
Stop and restart the test traffic stream.
Step 16
Fail interfaces g7/1 and g8/1 on SH1-110 of the 4-port GEC between SH1-103 and SH1-110, forcing
some multicast traffic to move to two other links. Measure any traffic loss.
Step 17
Verify that traffic is now flowing through device SH1-109, which has the lower OSPF cost to SH1-110
now, and that the mroute table entries on SH1-103 and SH1-109 are consistent with the devices'
respective MMLS entries.
Step 18
Bring up the two links failed.
Step 19
Verify that traffic is flowing again through SH1-110.
Step 20
Verify that the mroute table entries on SH1-103 and SH1-110 are consistent with the devices' respective
MMLS entries.
Step 21
Start the IXIA traffic stream again.
Step 22
Fail interfaces g3/1 and g7/1 on SH1-110 of the 4-port GEC between SH1-103 and SH1-110, forcing
some multicast traffic to move to two other links.
Step 23
Measure any traffic loss.
Step 24
Verify that traffic is flowing through device SH1-109, which has the lower OSPF cost to SH1-103 now,
and that the mroute table entries on SH1-103 and SH1-109 are consistent with the devices' respective
MMLS entries.
Step 25
Bring up the two links failed.
Step 26
Verify that traffic is flowing again through SH1-110, and that the mroute table entries on SH1-103 and
SH1-110 are consistent with the devices' respective MMLS entries.
Step 27
Fail interfaces g3/1 and g4/1 on SH1-110 of the 4-port GEC between SH1-103 and SH1-110, forcing
some multicast traffic to move to two other links.
Step 28
Measure any traffic loss.
Step 29
Verify that traffic is flowing through device SH1-109, which has the lower OSPF cost to SH1-103 now,
and that the mroute table entries on SH1-103 and SH1-109 are consistent with the devices' respective
MMLS entries.
Step 30
Bring up the two links failed.
Step 31
Verify that traffic is flowing again through SH1-110, and that the mroute table entries on SH1-103 and
SH1-110 are consistent with the devices' respective MMLS entries.
Step 32
Restart the IXIA test traffic stream.
Step 33
Fail the entire port-channel interface between SH1-103 and SH1-110, forcing multicast traffic to go
through SH1-109 to get to SH1-103.
Step 34
Measure the traffic loss.
Step 35
Verify that traffic is now flowing through device SH1-109, and that the mroute table entries on SH1-104
and SH1-109 are consistent with the devices' respective MMLS entries.
Step 36
Bring the channel back online.
Step 37
Verify that traffic once again flows through SH1-110.
Step 38
Verify that the mroute table entries on SH1-103 and SH1-110 are consistent with the devices' respective
MMLS entries.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
57
Hardware Forwarding Features
Step 39
Fail the port-channel interface four more times, recording the traffic loss each time.
Step 40
Determine the average amount of downtime over the five tests.
Step 41
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Traffic should failover and be forwarded by SH1-109 when half and then all of the port-channel
between SH1-110 and SH1-103 is torn down.
•
This failover should take place in a reasonable time (within the 10-second HSRP dead timer value).
•
There should be a consistency in the information contained in the MMLS entries and the mroute
entries for each test group.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 28 shows the Gigabit EtherChannel failover: mixed dCEF test results.
Table 28
Gigabit EtherChannel Failover: Mixed-dCEF Test Results
Tests
Results
Gigabit EtherChannel Failover: Mixed-dCEF
Pass
Gigabit EtherChannel Failover: dCEF
This test verified multicast and MSDP functionality during a dCEF GEC failover.
Traffic for multicast groups 239.255.104.115 through 239.255.104.119 was sent out via IXIA from
Dista-1 and received at Dista-2. Traffic was sent at a rate of 10,000 pps. The port-channel between
devices SH1-104 (Po71) and SH1-110 (Po171) was failed on the SH1-110 side, first two of four ports,
then all four ports.
Figure 19 shows the topology for the dCEF Gigabit EtherChannel failover test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
58
Hardware Forwarding Features
Figure 19
dCEF Gigabit EtherChannel Failover Topology
Devices under test: SH1-103, SH1-104, SH1-107, SH1-108, SH1-109, and SH1-110
Note
Background traffic remained running for this test at a rate of 25,000 pps. Results for zero-packet loss
of this traffic are not given, though, because the test involved failovers and traffic was certain to be
lost.
Test Plan
The procedure used to perform the Gigabit EtherChannel failover: dCEF test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that SH1-103 and SH1-104 are running MSDP Anycast and are peered with each other.
Step 3
Verify that the SPT-threshold is configured for "infinity" on devices SH1-109 and SH1-110.
Step 4
Begin monitoring memory and CPU utilization for the devices being tested.
Step 5
Start IGMP join traffic for multicast groups 239.255.104.115 through 239.255.104.119 on IXIA port
10/1, which is connected to Dista-2 2/1.
Step 6
Start the test traffic stream.
Step 7
Configure the test traffic stream to run in continuous mode.
Step 8
Verify that SH1-104 is the primary PIM rendezvous point for the given multicast groups and that
SH1-110 is receiving the test multicast group traffic from SH1-104.
Step 9
Verify that the MMLS entries for the test multicast groups are consistent with the mroute entries seen.
Step 10
Verify that the modules connecting SH1-110 to SH1-104 are dCEF modules. The ports connecting them
are g3/13-14, g8/13-14 on the SH1-104 side, and g3/3-4, g4/3-4 on the SH1-110 side.
Step 11
Use the test etherchannel command on the supervisor (SP, not Route Processor) of SH1-104 to verify
that each link of the GEC should pass some multicast traffic.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
59
Hardware Forwarding Features
Step 12
Verify that traffic is actually being passed across each of the physical interfaces using the interface
counters.
Step 13
Configure the test traffic stream to stop after sending 500,000 packets.
Step 14
Stop and restart the test traffic stream.
Step 15
Fail two links of the 4-port GEC between SH1-104 and SH1-110, forcing some multicast traffic to move
to two other links.
Step 16
Measure any traffic loss.
Step 17
Bring up the two links failed.
Step 18
Restart the IXIA test traffic stream.
Step 19
Fail the entire port-channel interface between SH1-104 and SH1-110, forcing multicast traffic to go
through SH1-103 to get to Dista-2.
Step 20
Measure the traffic loss.
Step 21
Verify that traffic is now flowing through device SH1-103, and that the mroute table entries on SH1-103
and SH1-110 are consistent with the devices' respective MMLS entries.
Step 22
Bring the channel back online.
Step 23
Verify that traffic once again flows through SH1-104, and that the mroute table entries on SH1-104 and
SH1-110 are consistent with the devices' respective MMLS entries.
Step 24
Fail the port-channel interface four more times, recording the traffic loss each time.
Step 25
Determine the average amount of downtime over the five tests.
Step 26
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Traffic should failover and be forwarded by SH1-103 when half and then all of the port-channel
between SH1-110 and SH1-104 is torn down.
•
This failover should take place in a reasonable time.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 29 shows the Gigabit EtherChannel Failover: dCEF test results.
Table 29
Gigabit EtherChannel Failover: dCEF Test Results
Tests
Results
Gigabit EtherChannel Failover: dCEF
Pass
Switch Fabric Module Failover
This test verified multicast functionality during Switch Fabric Module (SFM) failover. Multicast traffic
generated by IXIA is sent through the network from Dista-2 to Dista-1, through SH1-104. The active
SFM is failed a number of times. Traffic is tracked in each case, and traffic loss is calculated.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
60
Hardware Forwarding Features
In several of the following steps, verification that the traffic is using the SFM is requested. Verify by
examining how the Medusa Application-Specific Integrated Circuit (ASIC) is handling traffic. The
Medusa ASIC interfaces are between the line card local bus and the backplane of the Catalyst 6500. If
traffic is using the SFM (no legacy, or nonfabric-enabled, cards present), the Medusa mode was
"Compact" for all line cards, indicating that it is sending a compact header on the backplane for the
switching decision. Note that any WS-X6816 modules are always in "Compact" mode, because they are
fabric-only cards. More on the switching modes involving the SFM can be found at the Cisco Catalyst
6500 Series Switches site:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter0918
6a008007fb2a.html
Figure 20 shows the topology for the switch fabric module failover test.
Figure 20
Switch Fabric Module Failover Topology
Device under test: SH1-104.
Test Plan
The procedure used to perform the switch fabric module failover test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify that the SPT threshold is configured for infinity on SH1-108, and backup designated router (BDR)
SH1-107 to ensure that the multicast routing state (*,G) is used, and not (S,G).
Step 4
Begin sending the IGMP join messages for multicast groups 239.255.104.120 to 239.255.104.124 to
Dista-1 g4/6.
Step 5
Start the IXIA test stream. Temporarily configure the stream to run in continuous burst mode.
Step 6
Verify that SH1-104 is being used as the PIM-RP by SH1-110 and that the test traffic is flowing through
SH1-104.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
61
Hardware Forwarding Features
Step 7
Reconfigure the IXIA test stream to stop after sending 350,000 packets, or 35 seconds of traffic.
Step 8
Start the test script, which will failover the active fabric module on SH1-104 20 times while running
traffic.
Step 9
Show the results from the script and verify that failover times are within tolerances.
Step 10
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Failovers should occur within an acceptable time and traffic loss due to fabric failure should be
minimal.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 30 shows the switch fabric module failover test results.
Table 30
Switch Fabric Module Failover Test Results
Tests
Results
Switch Fabric Module Failover
Pass
Gigabit Ethernet Module Failover—Supervisor 1
This test verified multicast functionality during Gigabit Ethernet module failover. There are four Gigabit
Ethernet modules in SH1-110. Each was reset multiple times with traffic passing through them. The
ability of the devices to compensate for these failovers was measured by traffic loss.
Figure 21 shows the topology for the supervisor 1 Gigabit Ethernet module failover test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
62
Hardware Forwarding Features
Figure 21
Supervisor 1 Gigabit Ethernet Module Failover Topology
Device under test: SH1-108.
Test Plan
The procedure used to perform the Gigabit Ethernet module failover—supervisor 1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify that the SPT threshold is set to infinity on SH1-107 and SH1-108.
Step 4
Verify that SH1-108 is the PIM-DR for its VLAN segments. For whatever interface the two are
connected, SH1-107 sees SH1-108 as the designated router (DR) for that LAN segment.
Step 5
Start IGMP join messages from IXIA to Dista-1 4/1, Dista-1 4/6, SH1-108 g3/8, and SH1-108 g4/8 for
multicast groups 239.255.104.110 to 239.255.104.114.
Step 6
Begin the IXIA traffic stream. This stream is sending traffic to multicast groups 239.255.104.110 to
239.255.104.114 at a rate of 10,000 pps. The traffic enters the network at device Dista-2 2/1.
Step 7
Configure the traffic stream so that it is being sent from four different source IP addresses, ensuring that
the traffic is spread across all four GEC links.
Step 8
Verify that SH1-104 is the RP and that the test traffic is passing through it, coming in from port-channel
71 and going out port-channel 69.
Step 9
Verify that traffic is being switched by SH1-108, across all appropriate links and modules.
Step 10
Reset SH1-108 Gigabit Ethernet module 3 while sending 1 million packets.
Step 11
After the module comes back on line, verify that traffic is still passing through interfaces on module 3.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
63
Hardware Forwarding Features
Step 12
In the case of interfaces that serve as the final destination to the IXIA receiver, verify that there is still
an mroute entry for that interface in the Outgoing Interface List (OIL).
Step 13
Determine traffic loss.
Step 14
Repeat Step 10 through Step 13 four more times, each time determining traffic loss and verifying that
traffic resumes through the interfaces on the failed module.
Step 15
Reset SH1-108 Gigabit Ethernet module 4.
Step 16
After the module comes back on line, verify that traffic is still passing through interfaces on module 4.
Step 17
In the case of interfaces that serve as the final destination to the IXIA receiver, verify that there is still
an mroute entry for that interface in the OIL.
Step 18
Determine traffic loss.
Step 19
Repeat Step 15 through Step 18 four more times, each time determining traffic loss and verifying that
traffic resumes through the interfaces on the failed module.
Step 20
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Traffic should fail over within an acceptable time frame.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 31 shows the Gigabit Ethernet module failover—supervisor 1 test results.
Table 31
Gigabit Ethernet Module Failover—Supervisor 1 Test Results
Tests
Results
Gigabit Ethernet Module Failover—Supervisor 1
Pass
Gigabit Ethernet Module Failover—Supervisor 2
This test verified multicast functionality during Gigabit Ethernet module failover. There are four Gigabit
Ethernet modules in SH1-110. Each was reset multiple times with traffic passing through them. The
ability of the devices to compensate for these failovers was measured by traffic loss.
Figure 22 shows the topology for the supervisor 2 Gigabit Ethernet module failover test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
64
Hardware Forwarding Features
Figure 22
Supervisor 2 Gigabit Ethernet Module Failover Topology
Device under test: SH1-110.
Test Plan
The procedure used to perform the Gigabit Ethernet module failover—supervisor 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify that the SPT threshold is set to infinity on the device under test.
Step 4
Verify that SH1-110 is the PIM-DR on its segment.
Step 5
Start IGMP join messages from IXIA to Dista-2 4/10, SH1-110 g8/16 and SH1-110 g4/16 for multicast
groups 239.255.127.100 to 239.255.127.104.
Step 6
Begin the IXIA traffic stream. This stream is sending traffic to multicast groups 239.255.127.100 to
239.255.127.104 at a rate of 10,000 pps. The traffic enters the network at device Dista-1.
Step 7
Configure the traffic stream so that it is being sent from four different source IP addresses. This will
verify that the traffic is spread across all four GEC links.
Step 8
Verify that SH1-104 is the RP and that the test traffic is passing through it, coming in port-channel 69
and going out port-channel 71.
Step 9
Verify that traffic is being switched by SH1-110, across all appropriate links and modules.
Step 10
Reset SH1-110 Gigabit Ethernet module 7.
Step 11
After the module comes back on line, verify that traffic is still passing through interfaces on module 7.
Step 12
Determine traffic loss.
Step 13
Repeat Step 10 through Step 12 four more times, each time determining traffic loss and verifying that
traffic resumes through the interfaces on the failed module.
Step 14
Reset SH1-110 Gigabit Ethernet module 8.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
65
Hardware Forwarding Features
Step 15
After the module comes back on line, verify that traffic is still passing through interfaces on module 8.
Step 16
Determine traffic loss.
Step 17
Repeat Step 14 through Step 16 four more times, each time determining traffic loss and verifying that
traffic resumes through the interfaces on the failed module.
Step 18
Reset SH1-110 Gigabit Ethernet module 3.
Step 19
After the module comes back on line, verify that traffic is still passing through interfaces on module 3.
Step 20
Determine traffic loss
Step 21
Repeat Step 18 through Step 20 four more times, each time determining traffic loss and verifying that
traffic resumes through the interfaces on the failed module.
Step 22
Reset SH1-110 Gigabit Ethernet module 4.
Step 23
After the module comes back on line, verify that traffic is still passing through interfaces on module 4.
Step 24
Determine traffic loss
Step 25
Repeat Step 22 through Step 24 four more times, each time determining traffic loss and verifying that
traffic resumes through the interfaces on the failed module.
Step 26
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Traffic should fail over within an acceptable time frame.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 32 shows the Gigabit Ethernet module failover—supervisor 2 test results.
Table 32
Gigabit Ethernet Module Failover—Supervisor 2 Test Results
Tests
Results
Gigabit Ethernet Module Failover—Supervisor 2
Pass
Protocol Independent Module-Designated Router Failover—Supervisor 11
This test verified multicast functionality during designated router (PIM-DR) failover on a supervisor 11
platform. IXIA traffic for five multicast groups is sourced from the IXIA connected to Dista-1 and
collected from Dista-2. The PIM-DRs in this part of the network is SH1-106 (Sup11). The backup is
SH1-105.
SH1-106 is isolated from the network by shutting down its port-channel interfaces to its neighbors.
SH1-105 is thus forced to take over the PIM-DR role and forward traffic. The average downtime is taken
after five such failovers.
Figure 23 shows the topology for the supervisor 11 protocol independent module-designated router
failover test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
66
Hardware Forwarding Features
Figure 23
Supervisor 11 Protocol Independent Module-Designated Router Failover Topology
Devices under test: SH1-105, SH1-106, and SH1-100.
Test Plan
The procedure used to perform the protocol independent module-designated router failover—supervisor
11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify that the SPT-threshold is set to infinity on SH1-105 and SH1-106 to verify that the multicast
routing state (*,G) is used, and not (S,G).
Step 4
Verify that SH1-105 and SH1-106 are PIM neighbors and that SH1-106 is the PIM-DR.
Step 5
Start IGMP join traffic for multicast groups 239.255.200.100 to 239.255.200.104 on Dista-2 6/2.
Step 6
Start an IXIA traffic stream for multicast groups 239.255.200.100 to 239.255.200.104 on Dista-1 4/6.
Step 7
Configure the stream to stop after sending 500,000 packets.
Step 8
Verify that SH1-100 is the RP for the five multicast test groups.
Step 9
Show the mroute that the test packets are taking through the PIM-RP, SH1-100, and verify that the
MMLS entries are consistent with the mroute entries.
Step 10
Shut down port-channels 67, 167, and 20 on SH1-106, isolating SH1-106 from its neighbors.
Step 11
Verify that SH1-105 becomes the PIM-DR and that the test multicast traffic is forwarded through it.
Step 12
Measure any traffic loss.
Step 13
Bring up the interfaces that were shut down, so SH1-106 becomes the PIM-DR again.
Step 14
Verify that traffic being routed through SH1-100 is again going out interface port-channel 67, and verify
that SH1-106 is again the PIM-DR for this segment.
Step 15
Repeat Step 10 and Step 14 four more times, each time determining the amount of traffic loss.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
67
Hardware Forwarding Features
Step 16
Determine the average amount of loss over five failovers.
Step 17
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Test traffic should be forwarded onto the receiving VLAN segment only by the PIM-DR for that
segment in the starting state, and after recovery from any failover.
•
The backup PIM-DR (SH1-105) should assume forwarding responsibilities for the test traffic when
the primary PIM-DR (SH1-106) becomes unavailable. This behavior should happen within an
acceptable time.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 33 shows the protocol independent module-designated router failover—supervisor 11 test results.
Table 33
Protocol Independent Module-Designated Router Failover—Supervisor 11 Test Results
Tests
Results
Protocol Independent Module-Designated Router Failover—Supervisor 11 Pass
Protocol Independent Module-Designated Router Failover—Supervisor 22
This test verified multicast functionality during designated router (PIM-DR) failover on a supervisor 22
platform. IXIA traffic for five multicast groups is sourced from the IXIA connected to Dista-1 and
collected from Dista-2. The PIM-DRs in this part of the network is SH1-110 (Sup22). The backup is
SH1-109.
SH1-110 is isolated from the network by shutting down its port-channel interfaces to its neighbors.
SH1-109 is thus forced to take over the PIM-DR role and forward traffic. The average downtime is taken
after five such failovers.
Figure 23 shows the topology for the supervisor 22 protocol independent module-designated router
failover test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
68
Hardware Forwarding Features
Figure 24
Supervisor 22 Protocol Independent Module-Designated Router Failover Topology
Devices under test: SH1-104, SH1-109, and SH1-110.
Test Plan
The procedure used to perform the protocol independent module-designated router failover—supervisor
22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify that the SPT-threshold is set to infinity on SH1-109 and SH1-110 to verify that the multicast
routing state (*,G) is used, and not (S,G).
Step 4
Verify that SH1-109 and SH1-110 are PIM neighbors and that SH1-110 is the PIM-DR.
Step 5
Start IGMP join traffic for multicast groups 239.255.104.115 to 239.255.104.119 on Dista-2 2/1.
Step 6
Start an IXIA traffic stream for multicast groups 239.255.104.115 to 239.255.104.119 on Dista-1 4/6.
Step 7
Configure the stream to stop after sending 500,000 packets.
Step 8
Verify that SH1-104 is the RP for the five multicast test groups.
Step 9
Show the mroute that the test packets are taking through the PIM-RP, SH1-104, and verify that the
MMLS entries are consistent with the mroute entries.
Step 10
Shut down port-channels 71, 171, and 20 on SH1-110, isolating it from its neighbors.
Step 11
Verify that SH1-109 becomes the PIM-DR and that the test multicast traffic is forwarded through it.
Step 12
Measure any traffic loss.
Step 13
Bring up the interfaces that were shut down, so SH1-110 becomes the PIM-DR again.
Step 14
Verify that traffic being routed through SH1-104 is again going out interface port-channel 71, or into
port-channel 171 on SH1-110, and that SH1-110 is again the PIM-DR for this segment.
Step 15
Repeat Step 10 through Step 14 four more times, each time determining the amount of traffic loss.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
69
Hardware Forwarding Features
Step 16
Determine the average amount of loss over five failovers.
Step 17
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Test traffic should be forwarded onto the receiving VLAN segment only by the PIM-DR for that
segment in the starting state, and after recovery from any failover.
•
The backup PIM-DR (SH1-109) should assume forwarding responsibilities for the test traffic when
the primary PIM-DR (SH1-110) becomes unavailable. This behavior should happen within an
acceptable time.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 34 shows the protocol independent module-designated router failover—supervisor 22 test results.
Table 34
Protocol Independent Module-Designated Router Failover—Supervisor 22 Test Results
Tests
Results
Protocol Independent Module-Designated Router Failover—Supervisor 22 Pass
Auto-Rendezvous Point Functionality and Failover
Auto-RP eliminates the need to statically (manually) configure RP information in every router in the
network. Selected routers in the network can be configured to be candidate RPs for a given set of
multicast groups (as defined by access control lists). These routers advertise their candidacy in the form
of RP-Announce messages at a configurable interval (default is 60 seconds).
One or more (for redundancy) routers are configured as Mapping Agents, which will cache active
Group-to-RP information. Mapping Agents learn which routers are candidate RPs for given groups by
joining the well-known Cisco-RP-Announce multicast group (224.0.1.39) to receive candidate RP
announcements. Once an RP is selected (based on highest IP address) by the Mapping Agent, the other
routers in the network will learn of the IP address of the RP for the given groups by listening to the
well-known Cisco-RP-Discovery multicast group (224.0.1.40) that they had joined at startup.
The command to configure a router as a candidate RP is:
ip pim send-rp-announce interface scope ttl [group-list
acl] [interval x]
The command to configure the Mapping Agent is:
ip pim send-rp-discovery scope ttl
To test the Auto-RP feature, two candidates were configured with each of those routers also acting as the
Mapping Agents. Test success was based on whether the candidate with the highest IP address is
correctly advertised as the RP for the active groups. A test involving the failure of the “elected”
candidate RP will also be performed, to verify traffic failover the candidate with the lower IP address,
to verify that traffic will revert to its path through the candidate with the higher IP address once it comes
back online.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
70
Hardware Forwarding Features
SH1-103 and SH1-104 were the candidate RPs and the Mapping Agents. The default configurations of
SH1-103, SH1-104, SH1-107, SH1-108, SH1-109, and SH1-110 were removed and replaced with
configurations necessary for Auto-RP. Traffic was sent from Dista-1 to Dista-2 for groups
239.255.104.105 to 239.255.104.109. Traffic loss was measured as the elected RP is failed over.
Figure 25 shows the topology for auto-rendezvous point functionality and failover.
Figure 25
Auto-Rendezvous Point Functionality and Failover Topology
Devices under test: SH1-103, SH1-104, SH1-107, SH1-108, SH1-109, and SH1-110.
Test Plan
The procedure used to perform the auto-RP functionality and failover test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Save the running configuration to NVRAM on the devices under test.
Note
Because this is not the default configuration for the majority of the multicast tests, Auto-RP must be
configured at the beginning of this test. This is why a write memory in done at the beginning of this
test; so that the previous configuration can be recalled out of NVRAM at the end of the test.
Step 4
There are six commands on each of the device that must be removed. These commands represent the
configuration of a static RP, which is not used during this procedure.
Step 5
Configure SH1-103 and SH1-104 to be Auto-RP candidates and Mapping Agents. Show access list 4 and
which groups it restricts SH1-103 and SH1-104 to. Also show the IP addresses of the Loop back 0
interfaces by which SH1-103 and SH1-104 are running Auto-RP.
The RP candidates are configured with a group-list qualifier, to limit the groups for which they are RPs:
Step 6
Configure switches SH1-107, SH1-108, SH1-109, and SH1-110 to accept RP statements from Auto-RP
mapping agents. This will define for these devices which router is the active RP.
Step 7
Verify that commands entered in Step 4 and Step 5 are the only ones defining RP behavior on the devices.
Step 8
Begin IGMP join messages for multicast groups 239.255.104.105 to 239.255.104.109 on Dista-2 2/1.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
71
Hardware Forwarding Features
Step 9
Begin IXIA traffic streams for multicast groups 239.255.104.105 to 239.255.104.109 on Dista-1 4/1.
This stream will send 500,000 packets at a rate of 10,000 pps.
Step 10
Verify that SH1-104 is the elected RP, because of the higher IP address of its Loopback0 interface, and
that SH1-108 (the first-hop router) recognizes SH1-104 as the RP.
Step 11
Verify that the elected RP (SH1-104) is the one receiving and forwarding the test traffic and that the
MMLS entries are consistent with the mrouting entries.
Step 12
Shut down the etherchannel interfaces on the elected RP, SH1-104, to simulate a router reload.
Step 13
Verify that traffic is successfully diverted through the other candidate RP.
Step 14
Determine the time required for this diversion to occur.
Step 15
Reintroduce SH1-104 into the network.
Step 16
When SH1-104 is back online, verify that traffic once again passes through it.
Step 17
Repeat Step 12 through Step 15 four more times, each time measuring traffic loss.
Step 18
Determine the average amount of downtime for the five switch overs.
Step 19
Remove the commands configured in Step 5 through Step 6 on the appropriate switches.
Step 20
Copy the configuration stored in NVRAM to the current running configuration.
Step 21
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Basic Auto-RP configuration should work, with a group-list configured, and one of the two
candidate-RPs should be elected and forward traffic.
•
When the elected RP is failed, the other candidate RP should assume the RP role and take over
forwarding responsibilities within a reasonable time.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 35 shows the auto-RP functionality and failover test results.
Table 35
Auto-RP Functionality and Failover Test Results
Tests
Results
Auto-Rendezvous Point Functionality and Failover
Pass
Layer 3 Interface Multicast Negative
This test introduces faults into the topology and verifies that multicast functionality remains consistent
with functional specifications on Layer 3 ports. Online insertion and removal (OIR) of line cards,
resetting individual line cards, reloading the switch, and Supervisor Engine/Switch Fabric Module
failover were introduced.
Interface Gig4/16 on device SH1-110 is used as the Layer 3 interface for the duration of this test. It is
receiving traffic for multicast groups 239.255.104.105 to 239.255.104.109. Gig4/16 is also sending
traffic to groups 239.255.104.110 to 239.255.104.114 (with a receiver connected to SH1-108).
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
72
Hardware Forwarding Features
Dista-1 port 4/1 on SH1-108 is sending the traffic for groups 239.255.104.105 to 239.255.104.109. It is
also receiving traffic in groups 239.255.104.110 to 239.255.104.114.
Traffic was sent at 10,000 pps for periods of 50 seconds. A 50,000-packet burst was used at each step in
which failure is introduced in order to measure traffic loss.
Device under test: SH1-110.
Test Plan
The procedure used to perform the Layer 3 interface multicast negative test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify that interface g4/16 of SH1-110 is configured as a Layer 3 interface. This interface is connected
to IXIA port 11/1.
Step 4
Verify that the IXIA port (11/1) connected to SH1-110 is receiving traffic destined for multicast groups
239.255.104.105 to 239.255.104.109 and is sending to multicast groups 239.255.104.110 to
239.255.104.114.
Step 5
Verify that the IXIA port 8/1, which is connected to Dista-1 4/1, is configured exactly the opposite from
Step 4, that it is receiving traffic destined for multicast groups 239.255.104.110 to 239.255.104.114, and
that it is sending to multicast groups 239.255.104.105 to 239.255.104.109.
Step 6
Reload the active supervisor in SH1-110 while sending 300 seconds of traffic in either direction (3
million packets).
Step 7
After SH1-110 comes back online, verify that it resumes the forwarding role for all multicast test groups.
Step 8
Measure any traffic loss.
Step 9
Perform OIR on the active supervisor on SH1-110.
Step 10
After SH1-110 comes back online, verify that it resumes the forwarding role for all multicast test groups.
Step 11
Measure any traffic loss.
Step 12
Reset module 4 on SH1-110.
Step 13
After module 4 comes back online, verify that it resumes the forwarding role for all multicast test groups.
Step 14
Measure any traffic loss.
Step 15
Perform OIR on module 4 on SH1-110.
Step 16
After module 4 comes back online, verify that it resumes the forwarding role for all multicast test groups.
Step 17
Measure any traffic loss.
Step 18
Verify that the traffic on SH1-110 is being switched by the fabric module.
Step 19
Fail over the active SFM on SH1-110.
Step 20
Once the fabric has failed over, verify that SH1-110 resumes forwarding for all multicast test groups.
Step 21
Measure any traffic loss.
Step 22
Cycle interface g4/16 on SH1-110.
Step 23
After interface g4/16 comes back online, verify that it resumes the forwarding role for all multicast test
groups.
Step 24
Measure any traffic loss.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
73
Hardware Forwarding Features
Step 25
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
The failed device/module/interface should recover as expected and the mroute entries should be
maintained or recreated correctly, following the recovery.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 36 shows the Layer 3 interface multicast negative test results.
Table 36
Layer 3 Interface Multicast Negative Test Results
Tests
Results
Layer 3 Interface Multicast Negative
Pass
Protocol Independent Module-Rendezvous Point Failover—Supervisor 22
This test verified multicast functionality during a PIM-RP failover on a supervisor 22 platform. IXIA
traffic for five multicast groups is sourced from the IXIA connected to Dista-1 and collected from seven
different receivers throughout the network. SH1-103 and SH1-104 are running Anycast RP for the test
traffic groups, with SH1-104 being the primary PIM-RP.
SH1-104 is reloaded, forcing SH1-103 to take over the PIM-RP role and forward traffic. The average
downtime is taken after ten such failovers.
Figure 26 shows the topology for the supervisor 22 protocol independent module-rendezvous point
failover test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
74
Hardware Forwarding Features
Figure 26
Supervisor 22 Protocol Independent Module-Rendezvous Point Failover Topology
Devices under test: SH1-100, SH1-103, SH1-104, SH1-108, SH1-109, SH1-110, SH1-102, and
SH1-106.
Test Plan
The procedure used to perform the supervisor 22 protocol independent module-rendezvous point failover
test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify that SH1-109 and SH1-110 are PIM neighbors and that SH1-110 is the PIM-DR. Do the same for
the pair SH1-105 and SH1-106, and for SH1-107 and SH1-108, verifying that SH1-106 and SH1-108 are
the PIM-DRs.
Step 4
Start IGMP join traffic for multicast groups 239.255.104.115 to 239.255.104.119 on the seven receiver
interfaces, IXIA ports 7/2, 9/1, 9/2, 10/1, 11/1, 2/4, and 2/6.
Step 5
Start an IXIA traffic stream for multicast groups 239.255.104.115 to 239.255.104.119 on Dista-1 4/6.
Step 6
Configure the stream to stop after sending 1 million packets.
Step 7
Verify that SH1-104 is considered to be the PIM-RP for the five multicast test groups, by SH1-108.
Step 8
Show the mroute that the test packets are taking through the PIM-RP, SH1-104, and verify that the
MMLS entries are consistent with the mroute entries. The incoming interface in each case should be
port-channel 69, with the traffic coming from SH1-108. The OIL should contain the interfaces
port-channel 70, port-channel 71, and port-channel 117.
Step 9
Reset SH1-104, the PIM-RP, and determine the amount of traffic loss.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
75
Hardware Forwarding Features
Step 10
Verify that SH1-103 becomes the PIM-RP and populates its mrouting table accordingly, and verify that
the MMLS entries on SH1-103 are consistent with the mroute entries for the test groups. The incoming
interface should be port-channel 69 for SH1-103, (from SH1-108). The OIL for SH1-103 should contain
interfaces port-channel 70, port-channel 71, and port-channel 17.
Step 11
Once SH1-104 comes back online, verify that it is again the RP for the test traffic and that its mrouting
table and MMLS entries are correct.
Step 12
Repeat Step 8 through Step 11 four more times, each time determining only the amount of traffic loss at
each receiver.
Step 13
Determine the average amount of loss over five failovers.
Step 14
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
SH1-104 should be the primary PIM-RP until it is failed (reloaded), at which point SH1-103 should
take over as the PIM-RP.
•
There should be a minimum amount of traffic loss as a result of the failover.
•
SH1-104 should resume the PIM-RP role after it is online again.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 37 shows the supervisor 22 protocol independent module-rendezvous point failover test results.
Table 37
Protocol Independent Module-Rendezvous Point Failover—Supervisor 22 Test Results
Tests
Results
Protocol Independent Module-Rendezvous Point Failover—Supervisor 22
Pass
MSDP Failover
This test verified that multicast traffic was forwarded in hardware when the destination is on a secondary
subnet. Interface g4/16 of SH1-110 is configured with a secondary IP address, the subnet on which a
multicast receiver resides.
Figure 26 shows the topology for the MSDP failover test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
76
Hardware Forwarding Features
Figure 27
MSDP Failover Topology
Device under test: SH1-110.
Test Plan
The procedure used to perform the MSDP failover test follows.
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Begin the IGMP join messages on IXIA port 11/1.
Step 4
Begin sending the test traffic using the IXIA test tool.
Step 5
Verify that SH1-110 has a secondary IP address configured on its interface g4/16, and that the IXIA port
is connected to it (can ping it) and known on its secondary subnet.
Step 6
Verify that SH1-110 has the correct mroute and MMLS entries for the test groups.
Step 7
Disable MMLS on SH1-110 and verify that the traffic is no longer hardware-switched.
Step 8
After about 1 minute, reenable MMLS so that traffic is again hardware-switched.
Step 9
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Traffic destined to a host on a secondary subnet should be switched in hardware.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
77
Hardware Forwarding Features
Results
Table 38 shows the MSDP failover test results.
Table 38
MSDP Failover Test Results
Tests
Results
MSDP Failover
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
78
Layer 3 Routing Features
Layer 3 Routing Features
Layer 3 routing feature testing for Safe Harbor involves these features:
•
Cisco Express Forwarding, page 79
•
Open Shortest Path First, page 88
•
Border Gateway Protocol, page 95
•
Hot Standby Routing Protocol, page 100
•
Enhanced Interior Gateway Routing Protocol, page 107
Cisco Express Forwarding
Cisco Express Forwarding (CEF) evolved to best accommodate the changing network dynamics and
traffic characteristics resulting from increasing numbers of short period flows typically associated with
web-based applications and interactive type sessions. Existing Layer 3 switching paradigms use a
route-cache model to maintain a fast lookup table for destination network prefixes. The route-cache
entries are traffic-driven in that the first packet to a new destination was routed via routing table
information and, as part of that forwarding operation, a route-cache entry for that destination was then
added. This behavior allows subsequent packet flows to that same destination network to be switched
based on an efficient route cache match. These entries are periodically aged out to keep the route cache
current and can be immediately invalidated if the network topology changes. This "demand-caching"
scheme—maintaining a very fast access subset of the routing topology information—is optimized for
scenarios whereby the majority of traffic flows are associated with a subset of destinations. However,
given that traffic profiles at the core of the Internet (and potentially within some large enterprise
networks) are no longer resembling this model, a new switching paradigm was required that would
eliminate the increasing cache maintenance resulting from growing numbers of topologically dispersed
destinations and dynamic network changes.
CEF avoids the potential overhead of continuous cache churn by instead using a Forwarding Information
Base (FIB) for the destination switching decision that mirrors the entire contents of the IP routing table;
that is, that there was a one-to-one correspondence between FIB table entries and routing table prefixes.
Therefore, there was no need to maintain a route cache.
The following tests were performed:
•
Cisco Express Forwarding Packet Switching, page 79
•
Cisco Express Forwarding Route Entries on DFC, page 81
•
Cisco Express Forwarding Many-to-One Distribution Load Balance, page 82
•
Cisco Express Forwarding Many-to-Many Distribution with Polarization Load Balance, page 84
Cisco Express Forwarding Packet Switching
This test verified that IP Unicast traffic was hardware-switched. If traffic was not hardware-switched by
the Policy Feature Card (PFC), the traffic would have been fast-switched by the MSFC.
Figure 9 shows the topology for the Cisco Express Forwarding Packet-Switching test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
79
Layer 3 Routing Features
Figure 28
Cisco Express Forwarding Packet-Switching Topology
A fixed number of ping packets are sent from SH1-104 to SH1-103, across SH1-99. The ping and
response totals are compared against the number of MLS CEF Layer 3 packets switched. An extended
ping of 500 packets is used to calculate the number of packets hardware-switched across the interim
switch, SH1-99. The result should be 1000 FIB switched packets on SH1-99.
Devices under test: SH1-104, SH1-99, and SH1-103.
Test Plan
The procedure used to perform the Cisco express forwarding packet-switching test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Shut down any alternate paths that the ping packets may take through the network from SH1-104 to
SH1-103 (on SH1-104, shut down the port-channel 68, port-channel 69, port-channel 70, and
port-channel 71 interfaces). Because these interfaces are shut down, all traffic sent from SH1-104 to
SH1-103 will be switched through SH1-99.
Step 5
If there are any background traffic streams running, stop them for this test. They may interfere with the
counter statistics observed on SH1-99.
Step 6
Show the MLS statistics for Module 3 on SH1-99. This will give a base packet count from which to work.
SH1-99 begins the test with 1,736,266,428 packets having been FIB switched.
Step 7
Clear out the MLS entries on module 3 of SH1-99 and verify that there are none. No MLS flows are
registered in module 3.
Step 8
Send 500 ping packets from SH1-104 (172.31.1.38) to SH1-103 (172.31.1.34).
Step 9
Verify that the 1000 packets (500 from echo request, 500 from echo reply) have been logged in the MLS
statistics on SH1-99.
Step 10
Verify that MLS entries have been created for the unicast flows.
Step 11
Return the configuration of SH1-104 to default by reenabling the port-channel interfaces (68 and 71) that
were shut down in Step 4.
Step 12
Verify that the DUT did not record any tracebacks.
Step 13
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
The MLS counters on SH1-99 should be incremented by 1000 when 500 ping packets are sent from
SH1-104 to SH1-103, through SH1-99.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
80
Layer 3 Routing Features
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 39 shows the Cisco express forwarding packet switching test results.
Table 39
Cisco Express Forwarding Packet Switching Test Results
Tests
Results
Cisco Express Forwarding Packet Switching
Pass
Cisco Express Forwarding Route Entries on DFC
This test verified that correct CEF table entries were used to forward IP unicast traffic passing through
a switch on a ws-x6816 module (with DFC). Devices SH1-99, SH1-103, and SH1-104 were used for the
test. port-channel 16 is used to connect SH1-99 to SH1-103 and port-channel 17 is used to connect
SH1-99 to SH1-104.
Device under test: SH1-104.
Test Plan
The procedure used to perform the CEF route entries on DFC test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
On device SH1-104, show the routing table entries for the networks 172.31.1.32, 172.31.1.36, and
172.31.1.0. The 172.31.1.32 network is one hop away from SH1-104. The 172.31.1.36 network is
directly connected to SH1-104. The 172.31.1.0 network is remote (more than one hop away from) to
SH1-104.
Step 5
Verify that there are entries in the CEF table on the PFC2 for these networks and any host within them.
Step 6
Show which module of SH1-104 has the DFC module.
Step 7
Verify that the same CEF table entries on the PFC are also on the DFC of Module 3.
Step 8
Verify that the DUT did not record any tracebacks.
Step 9
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
There should be corresponding CEF table entries for each routing table entry for networks that are
directly connected, one hop away, and more than one hop away.
•
The entries on the PFC2 should also be on the DFC of Module 3.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
81
Layer 3 Routing Features
Results
Table 40 shows the CEF route entries on DFC test results.
Table 40
Cisco Express Forwarding Route Entries on DFC Test Results
Tests
Results
Cisco Express Forwarding Route Entries on DFC
Pass
Cisco Express Forwarding Many-to-One Distribution Load Balance
These tests were performed to verify that HW shortcuts and CEF distribution functioned properly with
IP unicast traffic. Two tests were performed that monitored unicast traffic streams of "many-to-one" with
20 incremented IP addresses sending traffic to a single destination IP address and "many-to-many" with
100 source and 100 destination address pairs.
Figure 29 shows the topology for the CEF many-to-one distribution: load balance test.
Figure 29
Cisco Express Forwarding Packet-Switching Topology
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
82
Layer 3 Routing Features
Note
Background traffic was not used in this test because it would have confused the interface traffic
counters used to gauge traffic path and delivery.
Devices under test: SH1-103, SH1-104, SH1-107, SH1-108, SH1-109, and SH1-110.
Test Plan
The procedure used to perform the CEF many-to-one distribution test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Verify that all the port-channel interfaces involved in this test are up and that the proper interfaces are
bundled in them. Table 41 lists devices and which EtherChannel IDs to check.
Table 41
Device
Many-to-One Port-Channel Interfaces Readied and Bundled
Channel ID
SH1-103 68, 69, 70, 71
SH1-104 68, 69, 70, 71
SH1-107 68, 168
SH1-108 69, 169
SH1-109 70, 170
SH1-110 71, 171
Test One (Many-to-One)
Test One used traffic streams with 20 incrementing source IP addresses destined to a single IP address.
The destination IP address was 172.31.26.102. The source IP addresses incremented from 172.31.16.82
to 172.31.16.101.
The traffic source was IXIA-1 port Ix8/2 connected to switch Dista-1. The destination IP address was
IXIA-1 port Ix-10/2 connected to switch Dista-2. Router SH1-108 received the traffic from Dista-1 and
distributed it into the test network. A total of 10 million packets at 100,000 pps was sent. The path of the
traffic for this test was as follows:
IXIAtx -> Dista-1 -> SH1-108 -> (SH1-103 / SH1-104) -> (SH1-109 / SH1-110) -> Dista-2 -> IXIArx
Step 5
Clear the traffic counters on the test devices and begin playing the traffic stream.
Step 6
Verify that at all 10 million packets sent were received.
Step 7
Once the traffic stream has completed, show the interface traffic counters on devices SH1-108, SH1-103,
SH1-104, SH1-109, and SH1-110 to demonstrate that CEF load balancing did occur along the traffic
path.
Traffic Distribution (Following the Traffic from Dista-1 to Dista-2)
Step 8
Begin a continuous burst traffic stream with the same characteristics of the stream used earlier (20 source
IP addresses to 1 destination IP address). This stream will also be sent out IXIA port 8/2 and enter
Dista-1. Traffic counters are not important for this test, which is why a continuous burst of traffic is sent.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
83
Layer 3 Routing Features
Step 9
Display the MLS entries on each router along the traffic path. There should be a total of 20 entries at
each level (i.e. 20 entries on SH1-108; 20 entries on SH1-103 and SH1-104, combined; 20 entries on
SH1-109 and SH1-110, combined).
Step 10
Count each entry with a destination IP address (DstIP) of 172.31.26.102.
Note
In some cases, it may be necessary to display the MLS entries on the DFC cards of certain modules.
Step 11
Verify that the DUT did not record any tracebacks.
Step 12
Verify CPU and memory usage during this second phase of test one to ensure that no anomalies occurred.
Expected Results
The following test results are expected:
•
Traffic sourced from multiple IP hosts to a single IP host should use multiple paths if available.
•
Traffic sourced from multiple IP hosts to a single IP host should be hardware-switched.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 42 shows the CEF many-to-one distribution test results.
Table 42
Cisco Express Forwarding Many-to-One Distribution Test Results
Tests
Results
Cisco Express Forwarding Many-to-One Distribution Load Balance
Pass
Cisco Express Forwarding Many-to-Many Distribution with Polarization Load Balance
These tests verified that HW shortcuts and CEF distribution functioned properly with IP unicast traffic.
Two tests were performed that monitored unicast traffic streams of "many-to-one" with 20 incremented
IP addresses sending traffic to a single destination IP address and "many-to-many" with 100 source and
100 destination address pairs.
Figure 30 shows the topology for the CEF many-to-many distribution with polarization load balance test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
84
Layer 3 Routing Features
Figure 30
Note
Cisco Express Forwarding Packet-Switching with polarization Topology
Background traffic was not used in this test because it would have confused the interface traffic
counters used to gauge traffic path and delivery.
Devices under test: SH1-103, SH1-104, SH1-107, SH1-108, SH1-109, and SH1-110.
Test Plan
The procedure used to perform the CEF many-to-many distribution with polarization test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Verify that all the port-channel interfaces involved in this test are up and that the proper interfaces are
bundled in them. Table 43 lists devices and which EtherChannel IDs to check.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
85
Layer 3 Routing Features
Table 43
Device
Many-to-Many Port-Channel Interfaces Readied and Bundled
Channel ID
SH1-103 68, 69, 70, 71
SH1-104 68, 69, 70, 71
SH1-107 68, 168
SH1-108 69, 169
SH1-109 70, 170
SH1-110 71, 171
Test Two (Many-to-Many)
Test Two uses traffic streams with 100 incrementing source IP addresses destined to 100 incrementing
IP addresses. The source IP addresses increment from 172.31.26.102 to 172.31.26.201. The destination
IP addresses increment from 172.31.16.82 to 172.31.16.181.
The traffic source was IXIA-1 port Ix10/2 connected to switch Dista-2. The destination IP address was
IXIA-1 port Ix-8/2 connected to switch Dista-1. Router SH1-110 received the traffic from Dista-2 and
distributed it into the test network. A total of 10 million packets at 100,000 pps was sent. The path of the
traffic for this test is as follows:
IXIAtx -> Dista-2 -> SH1-110 -> (SH1-103 / SH1-104) -> (SH1-107 / SH1-108) -> Dista-1 -> IXIArx
Polarization
The Sup2/MSFC2 uses the ipSrc, ipDst and pathcount to make frame distribution decisions. Under
certain network configurations traffic may not always use all paths available in the CEF table. In the test
configuration switches 110, 103 and 104 have the same pathcount. Figure 31 shows a description and
illustration of the problem.
If traffic B and D will hash to the right path of the two output paths, then that same traffic will hash to a
single path even if multiple paths are available. Traffic B and D do not take the separate paths available.
This behavior is expected, and is due to the original hash algorithm used by CEF.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
86
Layer 3 Routing Features
Figure 31
Cisco Express Forwarding Packet-Switching with Polarization Topology
To address the polarization issue, Native IOS version 12.1(13)E3 allows the configuration of three
different CEF distribution algorithms. These are called original, universal (configured by default), and
tunnel. These algorithms, however, apply only to traffic that is software-switched; traffic that is
hardware-switched in the PFC2 uses the original algorithm. The test uses the default algorithm
(universal), but still encounters the polarization problem, due to hardware limits in the PFC2. This
problem is addressed with the introduction of the EARL7 ASIC in the coming supervisor 3.
Because there are now 100 different SrcIP::DstIP pairs, this test will not look at the MLS entries. Rather
it will look only at the traffic to endure that it is load-balanced correctly.
Step 5
Clear the traffic counters on the test devices.
Step 6
Begin the IXIA traffic stream sending traffic from Dista-2 to Dista-1.
Step 7
Verify that all of the 10 million packets that were sent were received on the proper IXIA port.
Step 8
Show the interface traffic counters on devices SH1-108, SH1-103, SH1-104, SH1-109, and SH1-110 to
demonstrate that CEF load-balancing did occur along the traffic path.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
87
Layer 3 Routing Features
Traffic Distribution (Following the Traffic from Dista-1 to Dista-2)
Step 9
Verify that the DUT did not record any tracebacks.
Step 10
Verify CPU and memory usage during the first two steps of test one to ensure that no anomalies occurred.
Expected Results
The following test results are expected:
•
Traffic sourced from multiple IP hosts to a single IP host should use multiple paths if available.
•
Traffic sourced from multiple IP hosts to a single IP host should be hardware-switched.
•
Traffic sourced from multiple IP hosts to multiple IP hosts should use multiple paths if available
(with polarization taken into account).
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 44 shows the CEF many-to-many distribution with polarization test results.
Table 44
Cisco Express Forwarding Many-to-Many Distribution with Polarization Test Results
Tests
Results
Cisco Express Forwarding Many-to-Many Distribution with Polarization Load Balance Pass
Open Shortest Path First
Open Shortest Path First (OSPF) is an Interior Gateway Protocol (IGP) developed by the OSPF working
group of the Internet Engineering Task Force (IETF). Designed expressly for IP networks, OSPF
supports IP subnetting and tagging of externally derived routing information. OSPF also allows packet
authentication and uses IP multicast when sending and receiving packets.
The following tests were performed:
•
OSPF Autocost, page 88
•
OSPF Passive Interface, page 89
•
OSPF Filtering, page 91
•
OSPF Redistribution, page 93
•
OSPF Topology Database, page 94
OSPF Autocost
This test verified that the auto-cost reference-bandwidth value command functions correctly. OSPF
used the interface cost to compute routing matrixes. By default: cost = 100/bandwidth (in Mbps)
The lowest cost is 1, which is for 100 Mbps interfaces. In order to let Gigabit Ethernet, GEC, or
10 Gigabit Ethernet, have a cost that will allow comparison of the higher speed connections, use the
auto-cost command to set up a higher reference bandwidth other than 100 Mbps. The default autocost
reference-bandwidth for the Native IOS Safe Harbor testing is 100,000.
Device under test: SH1-97.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
88
Layer 3 Routing Features
Test Plan
The procedure used to perform the OSPF autocost test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Show the autocost configuration for SH1-97.
Step 4
Show the OSPF interface costs for interfaces port-channel 11 and port-channel 13 on SH1-97. Show that
port-channel 11 is a two-port-channel, and that port-channel 13 is a four port-channel. The autocost
configuration allows the 4-port port-channel to have half the cost of the 2-port port-channel.
Step 5
Reconfigure the reference bandwidth to the default bandwidth 100. Show that both port-channel
interfaces now have the same minimum cost of one (in this case, they would be compared equally with
a single Fast Ethernet interface).
Step 6
Change the autocost value to 500000, and verify that the interface costs have changed to 250 and 125
for port-channel 11 and port-channel 13, respectively.
Step 7
Change the autocost value back to 100000, and verify that the interface costs have changed back to their
original values.
Step 8
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
The OSPF interface cost should will change accordingly with the change in configuration of the
autocost reference value.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 45 shows the OSPF autocost test results.
Table 45
OSPF Autocost Test Results
Tests
Results
OSPF Autocost
Pass
OSPF Passive Interface
This test verified that the passive-interface command functions correctly. Routers should not send
routing updates out passive interfaces. In the case of OSPF, hello packets will not be sent out passive
interfaces, so neighbors will not be formed.
For this test, SH1-106 is an OSPF neighbor to devices SH1-99 and SH1-100 in OSPF area 2. SH1-100
and SH1-99 are being sent OSPF routes by Pagent. SH1-100 and SH1-106 are connected by the
port-channel 67 interface on SH1-100 and the port-channel 167 interface on SH1-106. SH1-99 and
SH1-106 are connected by the port-channel 67 interface on SH1-100 and the port-channel 67 interface
on SH1-106. The passive-interface command was configured on port-channel 67 on SH1-100 and on
port-channel 67 on SH1-99. The neighbor tables on SH1-100 and SH1-99 were checked to verify the
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
89
Layer 3 Routing Features
command worked (SH1-106 should be removed). SH1-106 should likewise lose about 25,000 OSPF
routes out of its routing table (this includes both 15,000 OSPF routes generated by Pagent and 10,000
EIGRP routes redistributed into OSPF by SH1-99 and SH1-100). The passive-interface commands were
removed and the neighbor relationships and route table updates were reestablished.
Figure 32 shows the topology for the OSPF passive interface test.
Figure 32
OSPF Passive Interface Topology
Devices under test: SH1-99, SH1-100, and SH1-106.
Test Plan
The procedure used to perform the OSPF passive interface test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Turn off the background traffic, if running, for the duration of this test.
Step 4
Shut down the port-channel 20 interface on device SH1-105 to ensure that SH1-106 will have no
secondary way to get the routes from SH1-99 and SH1-100.
Step 5
Verify that SH1-99, SH1-100 and SH1-106 are running OSPF (process ID 1) and that both belong to
Area 2.
Step 6
Verify the neighbor relationship between SH1-100 and SH1-106 and between SH1-99 and SH1-106.
Step 7
Show the number of OSPF routes that SH1-106 has in its routing table.
Step 8
Configure a passive interface on port-channel 67 of SH1-99 and on port-channel 67 of SH1-100.
Step 9
After the Dead Timer expires for the neighbors on SH1-106, verify that the neighbor relationship no
longer exists between SH1-100 and SH1-106 or between SH1-99 and SH1-106.
Step 10
Verify that the OSPF routes SH1-106 was receiving from its neighbors are no longer in its routing table.
SH1-106 should have only 5000 OSPF routes in its routing table (from another Pagent source connected
to Dista-2).
Step 11
Remove the passive interfaces configured in Step 4.
Step 12
Verify that the neighbor relationship between SH1-100/SH1-99 and SH1-106 has been reestablished and
verify that SH1-106 again received routing updates from its neighbors.
Step 13
Bring up the port-channel 20 interface on SH1-105 that was shut down earlier.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
90
Layer 3 Routing Features
Step 14
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
The neighbor relationships between SH1-99, SH1-100 and SH1-106 should be broken down when
the passive-interface commands are applied.
•
SH1-106 should destroy the ~17,500 routes that it was learning from SH1-99 and SH1-100 when it
loses those two devices as neighbors.
•
The neighbor relationships should reform properly when the passive-interface commands are
removed.
•
SH1-106 should, once again, fully populate its routing table with the new updates from SH1-99 and
SH1-100.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 46 shows the OSPF passive interface test results.
Table 46
OSPF Passive Interface Test Results
Tests
Results
OSPF Passive Interface
Pass
OSPF Filtering
This procedure tested the capability of OSPF to filter out routes using the distribute-list command.
SH1-97, SH1-100, and SH1-106 are connected as such: SH1-97 to SH1-100 to SH1-106. These
connections are Layer 3 links (channels). The link between SH1-100 and SH1-106 (Po13) is network
172.31.1.96/30. Figure 33 shows the relevant topology. SH1-97 knows, through OSPF, this network via
port-channel 13. SH1-97 was configured with an access list and the distribute-list command, so that
SH1-97 no longer knows this route; it is filtered out.
Figure 33
OSPF Filtering Topology
Devices under test: SH1-97, SH1-100, and SH1-106.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
91
Layer 3 Routing Features
Test Plan
The procedure used to perform the OSPF filtering test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Stop the background traffic streams, if running, for the duration of this test.
Step 4
Verify that SH1-97, SH1-100, and SH1-106 are running OSPF and have network statements for their
respective connecting networks (Figure 33).
Step 5
Verify that SH1-97 knows the route to network 172.31.1.96 via port-channel 13.
Step 6
Verify that access list 30 is configured, on SH1-97, to deny network 172.31.1.96.
Step 7
Configure the distribute-list command for access list 30 on SH1-97, OSPF process ID 1.
Step 8
Verify that the route to the 172.31.1.96 network is no longer known via port-channel 13 in SH1-97.
Note
SH1-97 has connections to other routers running OSPF and, so, should learn the route to that network
via another interface.
Step 9
Remove the distribute-list command configured on SH1-97.
Step 10
Verify that the route to the 172.31.1.96 network is, once again, in the routing table of SH1-97, known
via port-channel 13.
Step 11
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
SH1-97 should not know the route to network 172.31.1.96 out interface port-channel13 when the
filter is applied.
•
SH1-97 should relearn the route to the 172.31.1.96 network out interface port-channel13 when the
filter is removed.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 47 shows the OSPF filtering test results.
Table 47
OSPF Filtering Test Results
Tests
Results
OSPF Filtering
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
92
Layer 3 Routing Features
OSPF Redistribution
This test verified that the redistribution of EIGRP routes into OSPF functions properly. The baseline
configuration for the Safe Harbor Native Cisco IOS testbed includes having all EIGRP routes
redistributed into OSPF by devices SH1-99 and SH1-100. We verified that the EIGRP routes from
EIGRP 1320 are known to device SH1-97 via OSPF. The redistribute configuration statements from
SH1-99 and SH1-100 is then removed so the routes from EIGRP 1320 should no longer be known by
SH1-97. Redistribution on SH1-99 and SH1-100 is then reconfigured and the routes from EIGRP 1320
should, again, be known to SH1-97 via OSPF.
Figure 29 shows the topology for the OSPF redistribution test.
Figure 34
OSPF Redistribution Topology
Devices under test: SH1-97, SH1-99, SH1-100, and SH1-101.
Test Plan
The procedure used to perform the OSPF redistribution test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Stop the background traffic streams, if running, for the duration of this test.
Step 4
Verify that SH1-99 and SH1-100 are running both OSPF process ID 1 and EIGRP 1320.
Step 5
Verify that SH1-101 is running EIGRP 1320.
Step 6
Verify that SH1-97 is running OSPF process ID 1.
Step 7
Verify that the routes 172.31.1.25 and 172.31.1.42 are known to SH1-97 via OSPF.
Step 8
Show the number of OSPF routes known to SH1-97 (there should be about 20,000).
Step 9
Remove the redistribution configuration from both SH1-99 and SH-100.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
93
Layer 3 Routing Features
Step 10
See if the route entries seen in Step 7 are still present on SH1-97.
Step 11
Show the number of OSPF routes known to SH1-97 (there should be only about 10,000 now).
Step 12
Re-configure redistribution on SH1-99 and SH1-100.
Step 13
Verify that the route entries seen in Step 7 are once again present on SH1-97.
Step 14
Show the number of OSPF routes known to SH1-97 (there should be over 20,000).
Step 15
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
The route entries observed in Step 7 should no longer be known via OSPF 1 with the removal of the
redistribution configuration.
•
These route entries should be created again when redistribution is reconfigured.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 48 shows the OSPF redistribution test results.
Table 48
OSPF Redistribution Test Results
Tests
Results
OSPF Redistribution
Pass
OSPF Topology Database
This test verified that the OSPF topology database functions correctly. Each section of the test observes
the OSPF database both in the case of no Pagent or IXIA test tools feeding extra routes (Pagent and IXIA
interfaces shut down or disabled) and in the case of Pagent and IXIA feeding extra routes.
Devices under test: SH1-97, SH1-98, SH1-99, and SH1-100.
Test Plan
The procedure used to perform the OSPF topology database test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
From each router in the Safe Harbor network, gather information about the OSPF interfaces and the
OSPF processes that are running.
Step 3
From each ABR in the Safe Harbor network, gather information about the OSPF database maintained
for each area.
Step 4
Verify router LSA. In each area, verify that there is one router LSA in the database for each router in
that area.
Step 5
Verify network LSA. For each multiaccess network that has more than one OSPF router on it, a DR and
BDR are elected and the DR generates a network LSA for this subnet. However, an OSPF router with an
interface on a multiaccess network with no other OSPF routers still shows up as DR, but no network LSA
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
94
Layer 3 Routing Features
is generated because no other OSPF router is on the subnet. To know which multiaccess subnets should
have a network LSA generated for them, look for an existing BDR on that subnet. In each area, verify
that there is one network LSA for each BDR interface in the output of the show ip ospf interface
command.
Step 6
Verify summary network LSA. In each area, count the number of DR or loopback interfaces [*] that are
in the up/up state in the output of the show ip OSPF interface command.
Step 7
Verify that the number of summary network LSAs in each area is equal to the sum of the previous counts
of all the other areas times the number of ABRs advertising those routes.
Step 8
Verify summary autonomous system boundary router (ASBR), with test tools, and without test tools. An
ABR between areas X and Y will generate a summary ASBR into X for an ASBR that exists in Y.
However, an ABR that is an ASBR will not advertise itself. Safe Harbor has a unique topology in that
every area has dual ABRs that also are ASBRs. So each ABR or ASBR sees its partner as an ASBR in
both areas, and will advertise its partner with a Summary ASBR LSA in both areas.
In each area, verify that there is a summary ASBR LSA from each ABR in that area for each ASBR
outside this area.
Step 9
Verify external LSAs; that there is an external LSA for each external route redistributed into OSPF.
Results
Table 49 shows the OSPF topology database test results.
Table 49
OSPF Topology Database Test Results
Tests
Results
OSPF Topology Database
Pass
Border Gateway Protocol
Border Gateway Protocol (BGP) is an exterior gateway protocol designed to exchange network
reachability information with other BGP systems in other autonomous systems. BGP exchanges routing
information in the form of routing updates. An update includes a network number, a list of autonomous
systems that the routing information has passed through (the autonomous system path), and a list of other
path attributes.
The following tests were performed:
•
Scale to Ten Neighbors and 100K Routes in Core (Add 120,000 Routes), page 95
•
Route Redistribution Between Other Protocols and BGP—ACL/Route Map, page 97
•
BGP Neighbor Flap—No Dampening, page 99
Scale to Ten Neighbors and 100K Routes in Core (Add 120,000 Routes)
This test ensured that no memory leaks or unexpected CPU load occurs with 8 BGP neighbors in the core
(4 core routers and 4 pagent neighbors) and a total of 100,000 BGP routes, 10,000 OSPF routes, and
10,000 EIGRP routes. The test begins with the core routers SH1-97, SH1-98, SH1-99, and SH1-100
having no routes added from the test tools.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
95
Layer 3 Routing Features
During the course of this test, OSPF routes were added to the network via the Pagent and IXIA test tools.
EIGRP and BGP routes were added via the Pagent test tool. All of the routes were added successively,
with no scaling up. The CPU and memory were monitored on the core routers to verify that there were
no anomalies.
Devices under test: SH1-97, SH1-98, SH1-99, and SH1-100.
Test Plan
The procedure used to perform the scale to ten neighbors and 100K routes in core test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
If the routes from the test tools have already been added to the various places in the network, stop them
now.
Step 3
Begin SNMP monitoring of CPU and memory usage for the four core routers.
Step 4
Begin SNMP monitoring of CPU and memory usage for the remaining devices in the network.
Step 5
Show a route summary for the four core devices with no test tool routes added.
Step 6
Add all the BGP routes using the test tools.
Step 7
Verify that the 100,000 BGP routes are now in the routing tables of the core routers.
Step 8
Add all the OSPF routes using the test tools.
Step 9
Verify that the 10,000 OSPF routes are now in the routing tables of the core routers.
Step 10
Add all the EIGRP routes.
Step 11
Verify that the 10,000 EIGRP routes are now in the routing tables of the core routers.
Step 12
Verify that any CPU and memory impact on the four core routers is acceptable.
Step 13
Verify that any CPU and memory impact on the other routers in the network is acceptable.
Expected Results
The following test results are expected:
•
All 120,000 routes should be added to the core devices.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 50 shows the scale to ten neighbors and 100K routes in core test results.
Table 50
Scale to Ten Neighbors and 100K Routes in Core Test Results
Tests
Results
Scale to Ten Neighbors and 100K Routes in Core (Add 120,000 Routes) Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
96
Layer 3 Routing Features
Route Redistribution Between Other Protocols and BGP—ACL/Route Map
This test verified that route redistribution works correctly between BGP and both OSPF and EIGRP.
Device SH1-100 is a border router between OSPF, EIGRP, and BGP. It is on this router and its neighbor
SH1-99 that the configuration for redistribution was applied. OSPF and EIGRP were redistributed into
BGP individually, at first, and then both were redistributed at the same time. In each of the three cases,
only a limited number of routes were redistributed. Device SH1-97 was used to check whether the routes
had been redistributed.
Figure 35 shows the topology for route redistribution between other protocols and BGP—ACL/Route
map:
Figure 35
BGP ACL/Route Map Topology
Devices under test: SH1-97, SH1-99, and SH1-100.
Test Plan
The procedure used to perform the route redistribution between other protocols and BGP—ACL/route
map test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
On device SH1-97, determine by what protocol the route for 170.1.1.0 is known.
Step 4
Show the default BGP configuration of SH1-99 and SH1-100.
Step 5
Configure redistribution from BGP into OSPF on both devices SH1-99 and SH1-100.
Step 6
Verify that ecclesiastic 16 is configured on SH1-97, and that it denies the 170.1.1.0 network.
Step 7
Apply an inbound distribution list using access list 16 in the OSPF configuration on SH1-97 to block
network 170.1.1.0 from being known by OSPF.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
97
Layer 3 Routing Features
Step 8
Verify that the route to 170.1.1.0 is now known via BGP 100 on SH1-97 and has a metric of 100, as
configured in Step 5.
Step 9
Remove the redistribution from SH1-99 and SH1-100 and the distribute-list command from SH1-97.
Verify that the 170.1.1.0 network is known again via OSPF 1.
Step 10
Verify that the route to 180.1.1.0 is known on SH1-97 via OSPF 1, redistributed from EIGRP (identified
by the "type extern 2" label).
Step 11
Verify that access list 18 exists in SH1-99 and SH1-100 and permits only the even numbered subnets
within 180.1.x.x/24.
Step 12
Verify that a route-map called EIGRP2BGP is on SH1-99 and SH1-100 that uses matches IP addresses
to access list 18.
Step 13
Configure redistribution of EIGRP into BGP on SH1-99 and SH1-100 using the routemap EIGRP2BGP,
which allows only the even-numbered subnets within 180.1.x.x.
Step 14
Remove the redistribution statement from the OSPF configuration on SH1-99 and SH1-100. If this step
is not taken, SH1-97 will continue to know the 180.x.x.x networks via OSPF 1, because OSPF has a
lower administrative distance than BGP.
Step 15
Verify that the even-numbered networks within 180.1.x.0/24 are known to SH1-97 via BGP 100.
Step 16
With EIGRP redistribution configured, reconfigure OSPF redistribution into BGP as in Step 5 and Step
7.
Step 17
Verify that device SH1-97 knows the EIGRP and OSPF routes via BGP 100, as earlier.
Step 18
Reapply the EIGRP redistribution configuration in OSPF on SH1-99 and SH1-100 that was deleted in
Step 14.
Step 19
Remove the redistribution configurations applied in BGP on devices SH1-99 and SH1-100 in Step 13
and Step 16.
Step 20
Remove the distribute-list from SH1-97, applied in Step 16.
Step 21
Verify that the routes seen in Step 3 are known, again, via OSPF 1.
Step 22
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
EIGRP routes should be correctly redistributed into BGP.
•
OSPF routes should be correctly redistributed into BGP.
•
The application of a route-map should correctly alter the rules by which BGP redistributes routes.
•
Redistribution of both OSPF and EIGRP routes into BGP at the same time.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 51 shows the route redistribution between other protocols and BGP—ACL/route map test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
98
Layer 3 Routing Features
Table 51
Route Redistribution Between Other Protocols and BGP—ACL/Route map Test Results
Tests
Results
Route Redistribution Between Other Protocols and BGP—ACL/Route Map Pass
BGP Neighbor Flap—No Dampening
This test verified that a flapping nondampened BGP peer did not cause any memory leaks or prolonged
high CPU utilization, and that the DUT functions properly after the peer stops flapping. With BGP routes
being fed into devices SH1-97 and SH1-98, this test will simulate constant flapping of those BGP
neighbors. Specifically, the Pagent device rtp-wbu-te-p4 is feeding 35,000 BGP routes into SH1-97 from
interface fa1/0. The Pagent configuration on this interface was modified to enable flapping and the test
was run overnight.
Devices under test: SH1-97, SH1-98, SH1-99, and SH1-100.
Test Plan
The procedure used to perform the BGP neighbor flap test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify that SH1-97 is an eBGP peer with a Pagent router. The Pagent router is sending 35000 route
updates from autonomous system (AS) 10.
Step 4
Log into the Pagent test tool and configure the lne bgp interface fa2/0 command (BGP route feed) to
flap every 30 to 60 seconds followed by a nonflapping period of 60 to 120 seconds. Turn router flap on
and allow it to continue overnight.
Step 5
Verify that there was no unacceptable impact to the CPU or memory of the four devices under test.
Step 6
Verify that there was no unacceptable impact to the CPU or memory of other devices under test.
Expected Results
The following test results are expected:
•
The amount of memory free for each device being monitored should be about the same, indicating
no memory leaks.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 52 shows the BGP neighbor flap—no dampening test results.
Table 52
BGP Neighbor Flap T—No Dampening est Results
Tests
Results
BGP Neighbor Flap—No Dampening
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
99
Layer 3 Routing Features
Hot Standby Routing Protocol
For IP, the Hot Standby Router Protocol (HSRP) allows one router to automatically assume the function
of the second router if the second router fails. HSRP is particularly useful when the users on one subnet
require continuous access to resources in the network.
The following tests were performed:
•
Basic HSRP, page 100
•
HSRP Failover with Standard Timers—Supervisor 22, page 101
•
HSRP Failover Using Fast Timers—Supervisor 22, page 103
•
HSRP Failover—Supervisor 22, page 105
•
HSRP Maximum Group Limit—Supervisor 22, page 106
Basic HSRP
This test verified the basic functionality of HSRP. SH1-109 and SH1-110 were configured as HSRP
routers for VLANs 10 to 20, peered to each other through Layer 2 switch Dista-2. This test verified that
the configuration on each Layer 3 switch produced the desired results. The unicast traffic stream that was
running in the background from Dista-2 to SH1-105 was used to prove that traffic chose the active HSRP
router.
Figure 36 shows the topology for basic HSRP test.
Figure 36
Basic HSRP Topology
Devices under test: SH1-109, and SH1-110.
Test Plan
The procedure used to perform the basic HSRP test follows:
Step 1
Record the version and initial CPU time for the devices being tested. Also record the start time.
Step 2
Verify that SH1-109 and SH1-110 are configured with HSRP on their interfaces for VLANs 10 through
20.
Step 3
Verify that trunking is configured for VLANs 10 to 20 on the links between SH1-109 and Dista-2, and
SH1-110 and Dista-2. The trunking of these VLANs is what allows the two HSRP routers to negotiate
for status.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
100
Layer 3 Routing Features
Step 4
Verify that SH1-109 and SH1-110 are running multiple HSRP groups on VLAN 10 through VLAN 20.
Expected Results
The following test results are expected:
•
All VLAN interfaces on both SH1-109 and SH1-110 should be in Active or Standby state.
•
The VLAN interfaces with the higher priority should be in Active state.
•
If a VLAN interface has a higher priority, the Active address should be listed as local, and the
Standby address given should be the interface of the HSRP neighbor.
•
If a VLAN interface has a lower priority, the Standby address should be listed as local, and the
Active address given should be the interface of the HSRP neighbor.
•
The group address listed should be consistent with that given in the configuration.
Results
Table 53 shows the basic HSRP test results.
Table 53
Basic Hot Standby Routing Protocol Test Results
Tests
Results
Basic HSRP
Pass
HSRP Failover with Standard Timers—Supervisor 22
This test verified HSRP failover when a link was down. This test also verified that the HSRP preempt
command worked when the link returned to an up/up state, if the interface was configured with a higher
priority than the currently active router interface in the same HSRP group.
Figure 37 shows the topology for the HSRP failover with standard timers—supervisor 22 test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
101
Layer 3 Routing Features
Figure 37
HSRP Failover with Standard Timers—Supervisor 22 Topology
Devices under test: SH1-101, and SH1-102.
Test Plan
The procedure used to perform the HSRP failover with standard timers—supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify the HSRP configurations on devices SH1-101 and SH1-102 for VLANs 40 through 50.
Step 4
Verify that the links between SH1-101 and Dista-1 and the links between SH1-102 and Dista-1 are trunks
and that VLANs 40 to 50 are active within them.
Step 5
Stop the transmission of the background traffic stream being generated by IXIA port 2/1. This is the port
that will be used for this test.
Step 6
Begin the IXIA unicast traffic stream. This stream sends 500,000 packets at 10,000 pps.
Step 7
Verify that HSRP is active on SH1-102 for VLAN 41 (this is the VLAN on which traffic will be sent by
IXIA), and standby on SH1-101 for VLAN 41.
Note
The IXIA traffic stream is configured with the MAC address of the default gateway for group 3.
Step 8
Verify that traffic is being sent to the active HSRP router.
Step 9
On SH1-102, shut down the port-channel 10 interface, which should force the unicast traffic stream to
fail over to SH1-101. Measure the time (using traffic loss) required for that switch over to occur.
Step 10
Verify that the active HSRP router for VLAN 41, group 3 is now SH1-101.
Step 11
Bring the port-channel 10 interface back up on SH1-102.
Step 12
Verify that HSRP on SH1-102 preempts SH1-101 and once again becomes the active HSRP router.
Step 13
Perform a series of nine more port cycles on the port-channel 10 interface of SH1-102.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
102
Layer 3 Routing Features
Step 14
Measure the average time required for switch over following interface shut down. Include the results
from Step 9.
Step 15
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Traffic should fail over within a reasonable time.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 54 shows the HSRP failover with standard timers—supervisor 22 test results.
Table 54
HSRP Failover with Standard Timers—Supervisor 22 Test Results
Tests
Results
HSRP Failover with Standard Timers—Supervisor 22 Pass
HSRP Failover Using Fast Timers—Supervisor 22
This test verified HSRP failover when a link was down. This test also verified that the HSRP preempt
command worked when the link returned to an up/up state, if the interface was configured with a higher
priority than the currently active router interface in the same HSRP group. In this test, the hello and dead
timers are configured to 1 and 3 seconds, respectively to allow for faster switch over of traffic from the
active HSRP router to the standby HSRP router in case the active router is not reachable.
Figure 38 shows the topology for the HSRP failover using fast timers—supervisor 22 test:
Figure 38
HSRP Failover Using Fast Timers—Supervisor 22 Topology
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
103
Layer 3 Routing Features
Devices under test: SH1-101, and SH1-102.
Test Plan
The procedure used to perform the HSRP failover using fast timers—supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Configure the fast timers of 1 (hello) and 3 (dead) seconds on the appropriate HSRP groups of the VLAN
interfaces 40 to 50. Perform this configuration on both devices SH1-101 and SH1-102.
Step 4
Verify the HSRP configurations on devices SH1-101 and SH1-102 for VLANs 40 through 50.
Step 5
Verify that the links between SH1-101 and Dista-1 and the links between SH1-102 and Dista-1 are trunks
and that VLANs 40 to 50 are active within them.
Step 6
Stop the transmission of the background traffic stream being generated by IXIA port 2/1. This is the port
that will be used for this test.
Step 7
Begin the IXIA unicast traffic stream. This stream sends 250,000 packets at 10,000 pps.
Step 8
Verify that HSRP is active on SH1-102 for VLAN 41 (this is the VLAN on which traffic will be sent by
IXIA), and standby on SH1-101 for VLAN 41.
Note
The IXIA traffic stream is configured with the MAC address of the default gateway for group 3.
Step 9
Verify that traffic is being sent to the active HSRP router.
Step 10
On SH1-102, shut down the port-channel 10 interface, which should force the unicast traffic stream to
fail over to SH1-101. Measure the time (using traffic loss) required for that switch over to occur.
Step 11
Verify that the active HSRP router for VLAN 41, group 3 is now SH1-101.
Step 12
Bring the port-channel 10 interface back up on SH1-102.
Step 13
Verify that HSRP on SH1-102 preempts SH1-101 and once again becomes the active HSRP router.
Step 14
Perform a series of nine more port cycles on the port-channel 10 interface of SH1-102.
Step 15
Measure the average time required for switch over following interface shut down. Include the results
from Step 10.
Step 16
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Step 17
Return both devices to their original, default configurations.
Expected Results
The following test results are expected:
•
Traffic should fail over within a reasonable time.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 55 shows the HSRP failover using fast timers—supervisor 22 test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
104
Layer 3 Routing Features
Table 55
HSRP Failover Using Fast Timers—Supervisor 22 Test Results
Tests
Results
HSRP Failover Using Fast Timers—Supervisor 22 Pass
HSRP Failover—Supervisor 22
This test measures the impact of traffic on the CPU of the supervisor 22 when traffic is going through a
VLAN that has 16 HSRP groups configured on it. VLANs 60 and 61 are configured on SH1-101 and
SH1-102; 16 separate HSRP groups (101-116) are configured on each VLAN interface. Traffic is
sourced from IXIA, connected to Dista-1, on VLAN 60. The destination is an IXIA port also connected
to Dista-1, on VLAN 61. Traffic is sent at increasing rates of 100,000 pps, 250,000 pps, 500,000 pps,
and 1 million pps. The CPU and memory utilization is measured.
Figure 39 shows the topology for the HSRP failover—supervisor 22 test.
Figure 39
HSRP Failover—Supervisor 22 Topology
Devices under test: SH1-101, and SH1-102.
Test Plan
The procedure used to perform the HSRP maximum group limit—supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Write the running configuration to memory (NVRAM) so that it can be recalled.
Step 4
Determine which VLAN interfaces are present on the device.
Step 5
Remove any VLANs discovered in Step 4, with the exception of VLAN 1. Perform this function on each
device, for its respective VLANs.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
105
Layer 3 Routing Features
Step 6
Configure VLANs 60 and 61 on each device SH1-101 and SH1-102. Each of these VLANs will
participate in HSRP with the other device on 16 groups within each VLAN. SH1-101 will be the active
HSRP router for the odd groups, and SH1-102 will be the active HSRP router for the even groups. Also
configure each VLAN to participate in multicast PIM-SM.
Step 7
Verify that the HSRP states on each device, for each VLAN and group, are as they should be. For
SH1-101, all odd-numbered groups should be active, and the even-numbered groups should be standby.
For SH1-102, all odd-numbered groups should be standby and all even-numbered groups active.
Step 8
Verify that ports 6/5 and 6/6 on Dista-1 are on VLANs 60 and 61, respectively.
Step 9
Begin the traffic stream. This stream will run at the following rates (packets per second) for 1 minute
each: 25,000, 50,000, 75,000, 100,000, 125,000; 22.5 million packets total will be sent at these varying
rates.
Step 10
Verify that 100 percent of the traffic sent was received on the proper port.
Step 11
Remove the VLAN 60 and VLAN 61 configurations from the devices under test.
Step 12
Copy the startup configuration in NVRAM to the running configuration, and bring the VLAN interfaces
up (VLANs 40 to 50 and those others removed in Step 5, restoring the default configuration for the
devices under test.
Step 13
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
100 percent of the traffic sent at the varying rates should be received correctly.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 56 shows the HSRP failover—supervisor 22 test results.
Table 56
HSRP Failover—Supervisor 22 Test Results
Tests
Results
HSRP Failover—Supervisor 22
Pass
HSRP Maximum Group Limit—Supervisor 22
The PFC2 and MSFC2 support a maximum of 16 unique HSRP groups. There are concerns, that in recent
Cisco IOS code, no warnings are given if more than 16 unique HSRP groups are configured. This test
demonstrates that an error message is displayed when an attempt is made to configure the 17th group.
Device under test: SH1-103.
Test Plan
The procedure used to perform the HSRP maximum group limit—supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
106
Layer 3 Routing Features
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Configure 16 HSRP groups on VLAN 100 of SH1-103.
Step 4
Attempt to configure the 17th HSRP group.
Step 5
Remove VLAN 100 from the configuration on SH2-104.
Step 6
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
An error message should appear on attempt to configure the 17th HSRP group, and the 17th group
should not be configurable.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 57 shows the HSRP maximum group limit—supervisor 22 test results.
Table 57
HSRP Maximum Group Limit—Supervisor 22 Test Results
Tests
Results
HSRP Maximum Group Limit—Supervisor 22
Pass
Enhanced Interior Gateway Routing Protocol
The Enhanced Interior Gateway Routing Protocol (EIGRP) is an enhanced version of the IGRP protocol
developed by Cisco Systems. Enhanced IGRP uses the same distance vector algorithm and distance
information as IGRP. However, the convergence properties and the operating efficiency of Enhanced
IGRP have improved significantly over IGRP.
The convergence technology is based on research conducted at SRI International and employs an
algorithm referred to as the Diffusing Update Algorithm (DUAL). This algorithm guarantees loop-free
operation at every instant throughout a route computation and allows all devices involved in a topology
change to synchronize at the same time. Routers that are not affected by topology changes are not
involved in recomputations. The convergence time with DUAL rivals other routing protocol.
The following tests were performed:
•
EIGRP Summarization, page 107
•
EIGRP Redistribution, page 108
EIGRP Summarization
This test verified manual EIGRP summarization by using the ip summary-address interface
configuration command.
Several /24 networks are known via EIGRP by device SH1-101 that can be summarized as a single /22
network on the port-channels of devices SH1-99 and SH1-100 (port-channels 14 and 15). This test will
involve the summarization of the routes 172.31.20.0/24 to 172.31.23.0/24 into 172.31.20.0/22.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
107
Layer 3 Routing Features
Devices under test: SH1-99, SH1-100, and SH1-101.
Test Plan
The procedure used to perform the EIGRP summarization test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Show that the routes are not summarized and exist as /24 routes on SH1-101.
Step 4
Configure the ip summary-address eigrp command on the port-channel 14 and port-channel 15
interfaces of SH1-100 and SH1-99.
Step 5
Verify that the routes to the networks that were shown in Step 3 now have an entry on the summary
subnet of 172.31.20.0/22.
Step 6
Remove the summarization configuration statements applied in Step 4.
Step 7
Verify that the routing entries appear, again, as they should and as they did in Step 3.
Step 8
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
The /24 networks shown should be correctly summarized as /22 networks.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 58 shows the EIGRP summarization test results.
Table 58
EIGRP Summarization Test Results
Tests
Results
EIGRP Summarization
Pass
EIGRP Redistribution
This test verified that EIGRP route redistribution works correctly, with and without access lists (ACLs)
and route map filtering. Figure 40 shows SH1-99 and SH1-100 redistributing OSPF routes into EIGRP
1320 (of which SH1-101 is a member).
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
108
Layer 3 Routing Features
Figure 40
EIGRP Redistribution CPU Usage
The routes examined in this test are OSPF routes for 10,000 networks with a /24 mask, beginning at
160.1.1.0, 160.1.2.0, 160.1.3.0, and so on. These routes are fed directly into device SH1-97 via the
Pagent test tool.
Because redistribution is a part of the normal configuration in the Safe Harbor topology, the first part of
the test was to remove that configuration on devices SH1-99 and SH1-100, and verify that the 160.x.x.x
networks are no longer propagated to SH1-101 in the EIGRP domain. Redistribution will then be
configured with a route map added, which will allow only the odd-numbered networks to be redistributed
(160.1.1.0, 160.1.3.0, 160.1.5.0, and so on). The even-numbered networks will not appear in the routing
table of SH1-101. The final part of the test was to reconfigure redistribution as it is in the default setup
for this network to allow all 160.x.x.x networks to be redistributed.
Devices under test: SH1-97, SH1-99, SH1-100, and SH1-101.
Test Plan
The procedure used to perform the EIGRP redistribution test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Show the default EIGRP configuration for devices SH1-99 and SH1-100.
Step 4
Show that, with the default EIGRP configuration (allowing redistribution), the 160.x.x.x networks are
propagated to SH1-101.
Step 5
Show that SH1-101 has a full routing table with about 30,000 total routes (20,000 routes from OSPF 1
and 10,000 routes from EIGRP 1320).
Step 6
Remove the redistribution configuration from devices SH1-99 and SH1-100.
Step 7
Verify that the routes for the 160.x.x.x networks are no longer present in SH1-101 and that the routing
table has been reduced by about 10,000 routes. Several minutes may pass before the old routes time out
and are eliminated.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
109
Layer 3 Routing Features
Step 8
Show the route map OSPF2EIGRP-odd and the access list 22 on SH1-99 and SH1-100.
Step 9
Configure redistribution on SH1-99 and SH1-100, applying the route map OSPF2EIGRP-odd, so that the
even-numbered networks are blocked from being redistributed.
Step 10
Verify that the only routes for the 160.x.x.x networks that are on SH1-101 are for the odd-numbered
networks, 160.1.1.0, 160.1.3.0, 160.1.5.0, and so on.
Step 11
Show that the number of subnets in the routing table of SH1-101 has been decreased by 5000.
Step 12
Reconfigure the default redistribution configuration that was removed in Step 6.
Step 13
Verify that all of the 160.x.x.x networks are redistributed into SH1-101 (odd-numbered and
even-numbered), and that the routing table on SH1-101 is back to normal status (seen in Step 5).
Step 14
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
When the default redistribution configuration is removed from SH1-99 and SH1-100, none of the
20,000 OSPF routes should be propagated to SH1-101.
•
When the route map OSPF2EIGRP-odd is applied, with redistribution, on SH1-99 and SH1-100,
only the odd-numbered subnets within 160.x.x.x should be propagated to SH1-101.
•
When the default redistribution configuration is reapplied to SH1-99 and SH1-100, all of the routes
for the 160.x.x.x networks should be in the routing table of SH1-101 and that the routing table should
be populated correctly in its default state.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 59 shows the EIGRP redistribution test results.
Table 59
EIGRP Redistribution Test Results
Tests
Results
EIGRP Redistribution
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
110
Network Management Features
Network Management Features
Network management feature testing for Safe Harbor is described in the following sections:
•
Simple Network Management Protocol, page 111
•
TACACS, page 114
Simple Network Management Protocol
The Simple Network Management Protocol (SNMP) system consists of an SNMP manager, an SNMP
agent, and a MIB.
SNMP is an application-layer protocol that provides a message format for communication between
SNMP managers and agents.
Protos tests send exceptional elements to SNMP agents and managers in the form of requests and traps.
These elements are designed to provoke undesired behavior of the subject implementation. An
exceptional element is an input that might not have been considered properly when implementing the
software.
The following tests were performed:
•
Basic Functionality Shut/No Shut Interface—Supervisor 11, page 111
•
Basic Functionality Shut/No Shut Interface—Supervisor 22, page 112
•
Protos Negative Request Application, page 113
Basic Functionality Shut/No Shut Interface—Supervisor 11
This test verified the basic SNMP functionality of the Supervisor 11. In this procedure, SNMP traps are
created by a shut/no shut of an interface on device SH1-108. The logging messages created on the device
should be logged to the SNMP trap receiver.
Device under test: SH1-106.
Test Plan
The procedure used to perform the basic functionality shut/no shut interface—supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify that SH1-106 is configured to send SNMP traps generated by configuration messages to the server
172.18.177.135.
Step 4
Enter and leave configuration mode on SH1-106, generating a log message.
Step 5
Verify that the traps are received by a machine that is set up as the SNMP trap receiver.
Step 6
Display the output from the log files of that machine.
Step 7
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
111
Network Management Features
Expected Results
The following test results are expected:
•
SNMP should generate and send a trap to the configured host.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 60 shows the basic functionality shut/no shut interface—supervisor 11 test results.
Table 60
Basic Functionality Shut/No Shut Interface- Supervisor 11 Test Results
Tests
Results
Basic Functionality Shut/No Shut Interface—Supervisor 11 Pass
Basic Functionality Shut/No Shut Interface—Supervisor 22
This test verified the basic SNMP functionality of the supervisor 22. In this procedure, SNMP traps are
created by a shut/no shut of an interface on device SH1-110. The logging messages created on the device
should be logged to the SNMP trap receiver.
Device under test: SH1-110.
Test Plan
The procedure used to perform the basic functionality shut/no shut interface—supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify that SH1-110 is configured to send SNMP traps generated by configuration messages to the server
172.18.177.135.
Step 4
Enter and leave configuration mode on SH1-110, generating a log message.
Step 5
Verify that the traps are received by a machine that is set up as the SNMP trap receiver.
Step 6
Display the output from the log files of that machine.
Step 7
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
SNMP should function according to specifications, generating and sending a trap to the configured
host.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 61 shows the basic functionality shut/no shut interface—supervisor 22 test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
112
Network Management Features
Table 61
Basic Functionality Shut/No Shut Interface—Supervisor 22 Test Results
Tests
Results
Basic Functionality Shut/No Shut Interface—Supervisor 22 Pass
Protos Negative Request Application
This test verified that no SNMP vulnerabilities exist in the Native Cisco IOS code. Protos testing
involves sending erroneous SNMP packets to the device under test. These tests are run on all
permutations of supervisor and MSFC. This is a negative test, so the only verification is that the DUT
was unaffected.
Test Plan
The procedure used to perform the Protos negative request application test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Start background unicast and multicast traffic (rate = 25,000 pps).
Step 5
Execute the protos c06-snmpv1-req-app-r1.jar and c06-snmpv1-req-app-r1.jar on each host.
Step 6
After background traffic is done, verify that no packets were lost. Show the results.
Step 7
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Step 8
Verify that the switch or router did not pause indefinitely, reload, or give tracebacks.
Expected Results
The following test results are expected:
•
All DUTs should not drop any background traffic while running the test.
•
All DUTs should not pause indefinitely, reload, or give tracebacks while running the test.
Results
Table 62 shows the Protos negative request application test results.
Table 62
Protos Negative Request Application Test Results
Tests
Results
Protos Negative Request Application
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
113
Network Management Features
TACACS
Terminal Access Controller Access Control System (TACACS) is an authentication protocol that
provides remote access authentication and related services, such as event logging. User passwords are
administered in a central database rather than in individual routers, providing an easily scalable network
security solution.
Login authentication increases the security of the system by keeping unauthorized users from guessing
the password. The user is limited to a specific number of attempts to successfully log in to the switch. If
the user fails to authorize the password, the system delays access and captures the user ID and the IP
address of the station in the syslog file and in the SNMP trap.
The following test was performed:
•
User Authentication—Supervisor 11, page 114
•
User Authentication—Supervisor 22, page 115
User Authentication—Supervisor 11
This test verified that the TACACS login authentication works correctly on a supervisor 1 on MSFC 1
system. The server 172.18.177.132 is a TACACS server. It was used in this test as the source of user
authentication information.
Device under test: SH1-106.
Test Plan
The procedure used to perform the user authorization—supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify that SH1-106 has connectivity to the TACACS server 172.18.177.132.
Step 4
Configure SH1-106 to be a TACACS device with 172.18.177.132 as its server.
Step 5
Verify that user authentication is necessary on SH1-106.
Step 6
Remove the TACACS configuration from SH1-106.
Step 7
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
TACACS login authentication should work correctly.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 63 shows the user authorization—supervisor 11 test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
114
Miscellaneous Features
Table 63
User Authorization—Supervisor 11 Test Results
Tests
Results
User Authentication—Supervisor 11
Pass
User Authentication—Supervisor 22
This test verified that the TACACS login authentication works correctly on a supervisor 2 on MSFC 2
system. The server 172.18.177.132 is a TACACS server. It was used in this test as the source of user
authentication information.
Device under test: SH1-104.
Test Plan
The procedure used to perform the user authorization—supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify that SH1-104 has connectivity to the TACACS server 172.18.177.132.
Step 4
Configure SH1-104 to be a TACACS device with 172.18.177.132 as its server.
Step 5
Verify that user authentication is necessary on SH1-104. Authentication works as designed:
Step 6
Remove the TACACS configuration from SH1-104.
Step 7
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
TACACS login authentication should work correctly.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 64 shows the user authorization—supervisor 22 test results.
Table 64
User Authorization—Supervisor 22 Test Results
Tests
Results
User Authentication—Supervisor 22
Pass
Miscellaneous Features
Miscellaneous features tested for Safe Harbor are described in the following sections:
•
Switched Port Analyzer, page 116
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
115
Miscellaneous Features
•
Access Control Lists, page 118
•
Parser, page 120
•
Network Address Translation, page 121
•
Network Time Protocol, page 131
•
Syslog, page 133
•
User Datagram Protocol Broadcast Flooding, page 135
•
System Upgrade, page 137
•
Secure Shell, page 142
Switched Port Analyzer
Local switched port analyzer (SPAN) selects network traffic to send to a network analyzer such as a
switch probe device or other Remote Monitoring (RMON) probe. SPAN does not affect the switching of
network traffic on source ports or VLANs. SPAN sends a copy of the packets received or sent by the
source ports and VLANs to the destination port. The destination port must be dedicated for SPAN use.
The following test was performed:
•
SPAN Basic Functionality, page 116
SPAN Basic Functionality
This test verified the basic functionality of the SPAN feature across both the supervisor 12 and
supervisor 22 platforms, and across a number of different modules. A multicast stream with a single
group destination was sent into the network at Dista-2. There were two receivers, both on Dista-1. Traffic
passes through SH1-110 (supervisor 22), SH1-108 (supervisor 12) and SH1-102 (supervisor 22) along
the way to the two destinations. There are four interfaces in these three devices configured to monitor
the multicast traffic. These four interfaces are on the WS-X6348-RJ-45, WS-X6408-GBIC,
WS-X6516-GBIC, and WS-X6816-GBIC modules.
Figure 41 shows the topology for the SPAN basic functionality test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
116
Miscellaneous Features
Figure 41
Switched Port Analyzer (SPAN) Topology
Devices under test: SH1-110, SH1-108, and SH1-102.
Test Plan
The procedure used to perform the SPAN basic functionality test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Stop all background traffic streams.
Step 4
Configure the SPAN sessions on SH1-102, SH1-108, and SH1-110, as shown in Figure 41.
Step 5
Start the IGMP joins on IXIA ports 2/1 and 8/1 for multicast group 239.255.200.100.
Step 6
Start the test traffic stream using IXIA. This traffic stream generates 1 million packets destined to
multicast group 239.255.200.100, at a rate of 10,000 packets per second.
Step 7
Verify that all 1 million packets were received by the multicast destinations, and that all 1 million packets
were sent to the monitoring interfaces.
Step 8
Remove the SPAN configurations from the devices.
Step 9
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Each packet sent in the traffic stream should be duplicated on each of the four monitor destination
interfaces.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
117
Miscellaneous Features
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 65 shows the SPAN basic functionality test results.
Table 65
SPAN Basic Functionality Test Results
Tests
Results
SPAN Basic Functionality
Pass
Access Control Lists
Access control lists (ACLs) are used to classify traffic and permit or deny forwarding based on this
classification.
The following tests were performed:
•
Scripted Test of ACL 110, page 118
•
Scripted Test of ACL 131, page 119
Scripted Test of ACL 110
ACL 110 is a 1404 line access list taken from customer configuration. Our ACL test script configures
this ACL on a router. For each line of the ACL, the script creates a stream on an IXIA box that matches
the ACL; 10,000 packets from each stream are sent through the router and back to the IXIA. The script
then checks the IXIA statistics to verify that 10,000 packets were received for each stream that matched
a permit, and that no packets were received for each stream that matched a deny. This script is run against
a supervisor 11, supervisor 12, and supervisor 22.
Test Plan
The procedure used to perform the scripted test of ACL 110 test follows:
Step 1
Verify that the DUTs are running Cisco IOS Release 12.1(8b)E14.
Step 2
Begin SNMP monitoring.
Step 3
Begin the ACL test script on SH1-105, SH1-107, and SH1-102.
Step 4
Using the script's output file, verify that all packets were permitted and denied correctly.
Step 5
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Each DUT will not permit any denied traffic, and will not deny any permitted traffic.
•
All traffic should be hardware-switched, and no permitted packets dropped.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
118
Miscellaneous Features
Results
Table 66 shows the scripted test of ACL 110 test results.
Table 66
Scripted Test of ACL 110 Test Results
Tests
Results
Scripted Test of ACL 110
Pass
Scripted Test of ACL 131
ACL 131 is a 2985 line access control list taken from a customer configuration. Our ACL test script
configures this ACL on a router. For each line of the ACL, the script creates a stream on an IXIA box
that matches the ACL; 10,000 packets from each stream are sent through the router and back to the IXIA.
The script then checks the IXIA statistics to verify that 10,000 packets were received for each stream
that matched a permit, and that no packets were received for each stream that matched a deny.
Test Plan
The procedure used to perform the scripted test of ACL 131 test follows:
Note
To fit this ACL in the TCAM you need to be using the ODM ACL merge algorithm. This feature is
not supported until Cisco IOS Release 12.1(11b)E4. Until then we must split the ACL into two ACLs
and run them separately.
Step 1
Verify that the DUTs are running Cisco IOS Release 12.1(8b)E14.
Step 2
Begin SNMP monitoring.
Step 3
Begin the ACL test script on SH1-105, SH1-107, and SH1-102.
Step 4
Using script output file verify that all packets were permitted or denied correctly.
Step 5
Begin SNMP and CPU monitoring and verify supervisor and MSFCs are running the correct version of
Cisco IOS software.
Step 6
Begin the ACL test script on SH1-105, SH1-107, and SH1-102.
Step 7
Using the script's output file, verify that all packets were permitted or denied correctly.
Expected Results
The following test results are expected:
•
Each DUT should not permit any denied traffic, and should not deny any permitted traffic.
•
All traffic should be hardware-switched, and no permitted packets dropped.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 67 shows the Scripted Test of ACL 131 test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
119
Miscellaneous Features
Table 67
Scripted Test of ACL 131 Test Results
Tests
Results
Scripted Test of ACL 131
Pass
Parser
Parser testing robustly exercises the command-line interface (CLI) of a router. The testing walks the
parser tree, executing completed commands and filling in options as it comes to them. Certain branches
of the parser tree were left out due to time constraints of the testing (for example, the show
tag-switching tdp, and show mpls commands.
The following test was performed:
•
Show-All Script, page 120
Show-All Script
An automated script was used to test over 14,000 valid show and clear commands on a supervisor 11,
supervisor 12 and supervisor 22. Certain commands were left out (for example, the show memory; show
tag-switching tdp; show mpls) due the to length of time they take to execute.
Test Plan
The procedure used to perform the parser show-all script test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Begin executing show and clear commands on the device under test.
Step 4
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Commands should execute without the router reloading, giving tracebacks, pausing indefinitely, or
having CPU problems.
Results
Table 68 shows the reloads, indefinite pauses, or show-all script test results.
Table 68
Show-All Script Test Results
Tests
Results
Show-All Script
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
120
Miscellaneous Features
Network Address Translation
Two key problems facing the Internet are depletion of IP address space and scaling in routing. Network
Address Translation (NAT) is a feature that allows the IP network of an organization to appear from the
outside to use different IP address space than what it is actually using. Thus, NAT allows an organization
with nonglobally routable addresses to connect to the Internet by translating those addresses into
globally routable address space. NAT also allows a more graceful renumbering strategy for organizations
that are changing service providers or voluntarily renumbering into classless interdomain routing
(CIDR) blocks. NAT is also described in RFC 1631.
The following tests were performed:
•
Static 2 Hosts, page 121
•
Static 40 Hosts, page 122
•
Static 40 Hosts Extended, page 123
•
Static 2 Networks, page 124
•
Static Inside Dynamic Outside, page 125
•
Dynamic Inside Static Outside, page 127
•
Verify CSCdx40232, page 128
•
Addition/Removal of NAT Statements, page 129
•
Static 40 Hosts Overnight, page 130
Static 2 Hosts
This test verified the basic functionality of the NAT feature on a supervisor 2 on MSFC 2. The DUT was
configured to translate outside global addresses into outside local addresses and inside global addresses
to inside local addresses. IXIA will send 1 million packets in each direction for each test using
overlapping inside and outside static NAT. IXIA will also send a background multicast stream from the
inside interface to the outside interface.
Device under test: SH1-97.
Test Plan
The procedure used to perform the static 2 hosts test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Verify joins are being sent from the IXIA to the NAT outside interface.
Step 5
Verify that the DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, ARP entries to next hop routers, and monitor sessions for the inside and outside interfaces set
up but not active.
Step 6
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
121
Miscellaneous Features
Step 7
While traffic is being sent, turn on monitoring on the inside interface, then on the outside interface, and
capture inbound and outbound packets on both interfaces. Verify that the packets from the inside
interface have the inside local and outside local IP addresses, and that the packets from the outside
interface have the inside global and outside global IP addresses.
Step 8
After traffic has been sent, verify that no packets were lost.
Step 9
Stop SNMP data collection.
Step 10
Show current status of NAT, interfaces, and buffers on the DUT.
Step 11
Verify that the DUT did not give any tracebacks.
Step 12
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
All unicast packets should be translated correctly.
•
All multicast packets should be forwarded correctly.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 69 shows the static 2 hosts test results.
Table 69
Static 2 Hosts Test Results
Tests
Results
Static 2 Hosts
Pass
Static 40 Hosts
This test verified the basic functionality of the NAT feature on a supervisor 2 or MSFC 2. The DUT was
configured to translate outside global addresses into outside local addresses and inside global addresses
to inside local addresses. IXIA will send 1 million packets in each direction for each test using
overlapping inside and outside static NAT. IXIA will also send a background multicast stream from the
inside interface to the outside interface.
Device under test: SH1-97.
Test Plan
The procedure used to perform the static 40 hosts test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Verify that the DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, ARP entries to next hop routers, and monitor sessions on inside and outside interfaces set up
but not active.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
122
Miscellaneous Features
Step 5
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
Step 6
While traffic is being sent, turn on monitoring on the inside interface, then on the outside interface, and
capture with a sniffer an inbound and outbound packet on both interfaces. Verify that the packets from
the inside interface have the inside local and outside local IP addresses, and that the packets from the
outside interface have the inside global and outside global IP addresses.
Step 7
After traffic has completed, verify that no packets were lost.
Step 8
Show current status NAT, interfaces, and buffers on the DUT.
Step 9
Stop SNMP data collection.
Step 10
Verify that the DUT did not give any tracebacks.
Step 11
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
All unicast packets should be translated correctly.
•
All multicast packets should be forwarded correctly.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 70 shows the static 40 hosts test results.
Table 70
Static 40 Hosts Test Results
Tests
Results
Static 40 Hosts
Pass
Static 40 Hosts Extended
This test verified the basic functionality of the NAT feature on a supervisor 2 or MSFC 2. The DUT was
configured to translate outside global addresses into outside local addresses and inside global addresses
to inside local addresses. IXIA will send 10 million packets in each direction for each test using
overlapping inside and outside static NAT. IXIA will also send a background multicast stream from the
inside interface to the outside interface.
Device under test: SH1-97.
Test Plan
The procedure used to perform the static 40 hosts extended test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
123
Miscellaneous Features
Step 4
Verify that the DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, ARP entries to next hop routers, and monitor sessions on inside and outside interfaces set up
but not active.
Step 5
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
Step 6
While traffic is being sent, turn on monitoring on the inside interface, then on the outside interface, and
capture inbound and outbound packets on both interfaces. Verify that the packets from the inside
interface have the inside local and outside local IP addresses, and that the packets from the outside
interface have the inside global and outside global IP addresses.
Step 7
After traffic has completed, verify that no packets were lost.
Step 8
Show current status NAT, interfaces, and buffers on the DUT.
Step 9
Stop SNMP data collection.
Step 10
Verify that the DUT did not give any tracebacks.
Step 11
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
All unicast packets should be translated correctly.
•
All multicast packets should be forwarded correctly.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 71 shows the static 40 hosts extended test results.
Table 71
Static 40 Hosts Extended Test Results
Tests
Results
Static 40 Hosts Extended
Pass
Static 2 Networks
This test verified the basic functionality of the NAT feature on a supervisor 2 or MSFC 2. The DUT was
configured to translate outside global addresses into outside local addresses and inside global addresses
to inside local addresses. IXIA will send 1 million packets in each direction for each test using
overlapping inside and outside static NAT. IXIA will also send a background multicast stream from the
inside interface to the outside interface.
Device under test: SH1-97.
Test Plan
The procedure used to perform the static 2 networks test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
124
Miscellaneous Features
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Verify that the DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, ARP entries to next hop routers, and monitor sessions on inside and outside interfaces set up
but not active.
Step 5
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
Step 6
While traffic is being sent, turn on monitoring on the inside interface, then on the outside interface, and
capture with a sniffer an inbound and outbound packet on both interfaces. Verify that the packets from
the inside interface have the inside local and outside local IP addresses, and that the packets from the
outside interface have the inside global and outside global IP addresses.
Step 7
After traffic has completed, verify that no packets were lost.
Step 8
Show current status NAT, interfaces, and buffers on the DUT.
Step 9
Stop SNMP data collection.
Step 10
Verify that the DUT did not give any tracebacks.
Step 11
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
All unicast packets should be translated correctly.
•
All multicast packets should be forwarded correctly.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
The following exceptions were reported.
•
No packets sourced from the outside were received on the inside.
•
Sniffer showed that inside packets were not being translated, and outside packets were not being
forwarded.
•
Memory and CPU usage were unaffected through the test because packets were hardware-switched.
Table 72 shows the static 2 networks test results.
Table 72
Static 2 Networks Test Results
Tests
Results
Static 2 Networks Fail; fixed in 13E, not SS, has a work around (use individual NAT statements)
Static Inside Dynamic Outside
This test verified the basic functionality of the NAT feature on a supervisor 2 or MSFC 2. The DUT was
configured to translate outside global addresses into outside local addresses and inside global addresses
to inside local addresses. IXIA will send 1 million packets in each direction for each test using
overlapping inside and outside static NAT. IXIA will also send a background multicast stream from the
inside interface to the outside interface.
Device under test: SH1-97.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
125
Miscellaneous Features
Test Plan
The procedure used to perform the static inside dynamic outside test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Verify joins are being sent from the IXIA to the NAT outside interface.
Step 5
Verify that the DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, ARP entries to next hop routers, and monitor sessions on inside and outside interfaces set up
but not active.
Step 6
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
Step 7
While traffic is being sent, turn on monitoring on the inside interface, then on the outside interface, and
capture with a sniffer an inbound and outbound packet on both interfaces. Verify that the packets from
the inside interface have the inside local and outside local IP addresses, and that the packets from the
outside interface have the inside global and outside global IP addresses.
Step 8
After traffic has completed, verify that no packets were lost.
Step 9
Show current status NAT, interfaces, and buffers on the DUT.
Step 10
Stop SNMP data collection.
Step 11
Verify that the DUT did not give any tracebacks.
Step 12
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
All unicast packets should be translated correctly.
•
All multicast packets should be forwarded correctly.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 73 shows the static inside dynamic outside test results.
Table 73
Static Inside Dynamic Outside Test Results
Tests
Results
Static Inside Dynamic Outside
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
126
Miscellaneous Features
Dynamic Inside Static Outside
This test verified the basic functionality of the NAT feature on a supervisor 2 or MSFC 2. The DUT was
configured to translate outside global addresses into outside local addresses and inside global addresses
to inside local addresses. The DUT for this test is SH1-97. IXIA will send 1 million packets in each
direction for each test using overlapping inside and outside static NAT. IXIA will also send a background
multicast stream from the inside interface to the outside interface.
Test Plan
The procedure used to perform the dynamic inside static outside test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Verify joins are being sent from the IXIA to the NAT outside interface.
Step 5
Verify that the DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, ARP entries to next hop routers, and monitor sessions on inside and outside interfaces set up
but not active.
Step 6
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
Step 7
While traffic is being sent, turn on monitoring on the inside interface, then on the outside interface, and
capture with a sniffer an inbound and outbound packet on both interfaces. Verify that the packets from
the inside interface have the inside local and outside local IP addresses, and that the packets from the
outside interface have the inside global and outside global IP addresses.
Step 8
After traffic has completed, verify that no packets were lost.
Step 9
Show current status NAT, interfaces, and buffers on the DUT.
Step 10
Stop SNMP data collection.
Step 11
Verify that the DUT did not give any tracebacks.
Step 12
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
All unicast packets should be translated correctly.
•
All multicast packets should be forwarded correctly.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 74 shows the dynamic inside static outside test results.
Table 74
Dynamic Inside—Static Outside Test Results
Tests
Results
Dynamic Inside Static Outside
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
127
Miscellaneous Features
Verify CSCdx40232
This test verified that CSCdx40232 exists. The DUT was configured to dynamically translate inside
global addresses to inside local addresses. IXIA will send 1 million packets in each direction for each
test using overlapping inside and outside static NAT.
Device under test: SH1-97.
Test Plan
The procedure used to perform the verify CSCdx40232 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Verify that the DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, ARP entries to next hop routers, and monitor sessions on inside and outside interfaces set up
but not active.
Step 5
Clear statistics and counters, and begin sending unicast NAT traffic.
Step 6
While traffic is being sent, turn on monitoring on the inside interface, then on the outside interface, and
capture with a sniffer an outbound packet. Verify that the packets are being translated properly.
Step 7
While traffic is being sent, verify that there are 8000 dynamic translations from several different pools.
Step 8
While traffic is being sent, verify that the CPU did not suffer from severe or sustained impact.
Step 9
Stop SNMP data collection.
Step 10
Verify that the DUT did not give any tracebacks.
Step 11
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
All unicast packets should be translated correctly.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 75 shows the verify CSCdx40232 test results.
Table 75
Verify CSCdx40232 Test Results
Tests
Results
Verify CSCdx40232
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
128
Miscellaneous Features
Addition/Removal of NAT Statements
This test measured the impact on the CPU from the removal and addition of NAT statements while those
translations were in use. There are four NAT statements on switch SH1-97, translating four outside
global addresses into four outside local addresses. Traffic is passed with source IP addresses of the four
outside global addresses. As traffic is being passed, the NAT statements for those four particular
translations are removed, and then readded, while the CPU was being monitored.
Test Plan
The procedure used to perform the addition/removal of NAT statements test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Verify joins are being sent from the IXIA to the NAT outside interface.
Step 5
Verify that the DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, ARP entries to next hop routers, and monitor sessions on inside and outside interfaces set up
but not active.
Step 6
Begin sending unicast NAT traffic.
Step 7
While traffic is being sent, turn on monitoring on the inside interface, then on the outside interface, and
capture with a sniffer an inbound and outbound packet on both interfaces. Verify that the packets from
the inside interface have the inside local and outside local IP addresses, and that the packets from the
outside interface have the inside global and outside global IP addresses.
Step 8
Remove each of the static NAT statements every 10 seconds and readd them. Then remove all 4 NAT
statements at once, and then readd them. Remove the first two NAT statements 10 seconds apart,
followed by removing the last two statements after 1 second. Then readd all four statements.
Step 9
After NAT statements readded, turn on monitoring on the inside interface, then on the outside interface,
and capture with a sniffer an inbound and outbound packet on both interfaces. Verify that the packets
from the inside interface have the inside local and outside local IP addresses, and that the packets from
the outside interface have the inside global and outside global IP addresses.
Step 10
Stop SNMP data collection.
Step 11
Verify that the DUT did not give any tracebacks.
Step 12
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
All unicast packets should be translated correctly.
•
Removal and addition of NAT statements should not cause NAT to fail.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 76 shows the addition/removal of NAT statements test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
129
Miscellaneous Features
Table 76
Addition/Removal of NAT Statements Test Results
Tests
Results
Addition/Removal of NAT Statements
Pass
Static 40 Hosts Overnight
This test verified the basic functionality of the NAT feature on a supervisor 2 or MSFC 2. The DUT was
configured to translate outside global addresses into outside local addresses and inside global addresses
to inside local addresses. IXIA will send 400 million packets in each direction for each test using
overlapping inside and outside static NAT. IXIA will also send a background multicast stream from the
inside interface to the outside interface.
Device under test: SH1-97.
Test Plan
The procedure used to perform the static 40 hosts overnight test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Verify that the DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, ARP entries to next hop routers, and monitor sessions on inside and outside interfaces set up
but not active.
Step 5
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
Step 6
While traffic is being sent, turn on monitoring on the inside interface, then on the outside interface, and
capture with a sniffer an inbound and outbound packet on both interfaces. Verify that the packets from
the inside interface have the inside local and outside local IP addresses, and that the packets from the
outside interface have the inside global and outside global IP addresses.
Step 7
After traffic has been sent, verify that no packets were lost.
Step 8
Show current status NAT, interfaces, and buffers on the DUT.
Step 9
Stop SNMP data collection.
Step 10
Verify that the DUT did not give any tracebacks.
Step 11
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
All unicast packets should be translated correctly.
•
All multicast packets should be forwarded correctly.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
130
Miscellaneous Features
Results
Table 77 shows the static 40 hosts overnight test results.
Table 77
Static 40 Hosts Overnight Test Results
Tests
Results
Static 40 Hosts Overnight
Pass
Network Time Protocol
Network Time Protocol (NTP) synchronizes timekeeping among a set of distributed time servers and
clients. This synchronization allows events to be correlated when system logs are created and other
time-specific events occur.
An NTP server must be accessible by the client switch. NTP runs over User Datagram Protocol (UDP),
that runs over IP. NTP is extremely efficient; no more than one packet per minute is necessary to
synchronize two machines to within a millisecond of one another.
This test verified basic functionality. It used a local Sun server (IP address: 172.18.177.132) as the NTP
server. SH1-104 was configured as the NTP client.
The following tests were performed:
•
Basic NTP Functionality—Supervisor 1, page 131
•
Basic NTP Functionality—Supervisor 2, page 132
•
NTP Failover—Supervisor 1 and Supervisor 2, page 133
Basic NTP Functionality—Supervisor 1
This test verified the basic functionality of NTP on the supervisor 1. It used a local Sun server (IP
address: 172.18.177.132), and a local Cisco 6500 router running native as NTP servers. SH1-106 was
configured as the NTP client.
Device under test: SH1-106.
Test Plan
The procedure used to perform the basic NTP functionality—supervisor 1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that one or more servers are configured as the NTP server on the DUT.
Step 3
Verify that the association between the NTP server and the client is active.
Step 4
Verify that the NTP status is "synchronized" and that the time and date shown on SH1-104 are the same
as those shown on the server (NTP is working).
Expected Results
The following test results are expected:
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
131
Miscellaneous Features
•
The test device should be synchronized to the configured NTP server and the clocks on the device
and the server are synchronized.
Results
Table 78 shows the basic NTP functionality—supervisor 1 test results.
Table 78
Basic NTP Functionality—Supervisor 1 Test Results
Tests
Results
Basic NTP Functionality—Supervisor 1
Pass
Basic NTP Functionality—Supervisor 2
This test verified the basic functionality of NTP on the supervisor 2. It used a local Sun server (IP
address: 172.18.177.132), and a local Cisco 6500 router running native as NTP servers. SH1-104 was
configured as the NTP client.
Device under test: SH1-104.
Test Plan
The procedure used to perform the basic NTP functionality—supervisor 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that one or more servers are configured as the NTP server on the DUT.
Step 3
Verify that the association between the NTP server and the client is active.
Step 4
Verify that the NTP status is "synchronized" and that the time and date shown on SH1-104 are the same
as those shown on the server (NTP is working).
Expected Results
The following test results are expected:
•
The test device should be synchronized to the configured NTP server and the clocks on the device
and the server are synchronized.
Results
Table 79 shows the basic NTP functionality—supervisor 2 test results.
Table 79
Basic NTP Functionality—Supervisor 2 Test Results
Tests
Results
Basic NTP Functionality—Supervisor 2
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
132
Miscellaneous Features
NTP Failover—Supervisor 1 and Supervisor 2
Two NTP servers are configured on each device in the test network. This test verified the ability of the
device to switch over to the backup NTP server if the primary server fails.
Devices under test: SH1-106, and SH1-104.
Test Plan
The procedure used to perform the NTP failover—supervisor 1 and supervisor 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that the servers with IP addresses 172.18.177.131 and 172.18.177.132 (preferred) are configured
as the NTP servers on SH1-104 and SH1-106 and that 172.18.177.132 is synchronized to SH1-106 as
the master.
Step 3
On the server 172.18.177.132, stop the NTP daemon.
Step 4
Verify that the server 172.18.177.131 is now the master server for each SH1-104 and SH1-106 and that
NTP is functioning again. (This verification may take some time because the timeout interval is lengthy.)
Step 5
Start the NTP daemon on the server 172.18.177.132 again and verify that it once again becomes the
active master server for SH1-104 and SH1-106. (This verification may take some time because the
timeout interval is lengthy.)
Expected Results
The following test results are expected:
•
The test device should be synchronized to the configured NTP server and the clocks on the device
and the server are synchronized.
Results
Table 80 shows the NTP failover—supervisor 1 and supervisor 2 test results.
Table 80
Basic NTP Failover—Supervisor 1 and Supervisor 2 Test Results
Tests
Results
NTP Failover—Supervisor 1 and Supervisor 2 Pass
Syslog
The system log (syslog) protocol provides a transport to allow a machine to send event notification
messages across IP networks to event message collectors, that are also known as syslog servers.
The following tests were performed:
•
Basic Syslog Functionality—Supervisor 1, page 134
•
Basic Syslog Functionality—Supervisor 2, page 134
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
133
Miscellaneous Features
Basic Syslog Functionality—Supervisor 1
This test verified syslog functionality.
Device under test: SH1-105.
Test Plan
The procedure used to perform the basic syslog functionality—supervisor 1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify that syslog is configured on the DUT and that the designated server is 172.18.177.132.
Step 4
Enable the terminal monitor command on the DUT and enable IP PIM debugging.
Step 5
Once you receive debug messages on the DUT, turn debugging off.
Step 6
Show output from the syslog server. Compare it to messages received on the DUT.
Step 7
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Each message that is logged to the vty session should also be logged to the syslog server.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 81 shows the basic syslog functionality—supervisor 1 test results.
Table 81
Basic Syslog Functionality—Supervisor 1 Test Results
Tests
Results
Basic Syslog Functionality—Supervisor 1
Pass
Basic Syslog Functionality—Supervisor 2
This test verified syslog functionality.
Device under test: SH1-104.
Test Plan
The procedure used to perform the basic syslog functionality—supervisor 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify that syslog is configured on SH1-104 and that the designated server is 172.18.177.132.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
134
Miscellaneous Features
Step 4
Enable the terminal monitor command on SH1-104 and enable IP PIM debugging.
Step 5
Once you receive debug messages on SH1-104, turn debugging off.
Step 6
Show output from the syslog server. Compare it to messages received on SH1-104.
Step 7
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
Each message that is logged to the vty session should also be logged to the syslog server.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 82 shows the basic syslog functionality—supervisor 2 test results.
Table 82
Basic Syslog Functionality—Supervisor 2 Test Results
Tests
Results
Basic Syslog Functionality—Supervisor 2
Pass
User Datagram Protocol Broadcast Flooding
A broadcast is a data packet that is destined for multiple hosts. Broadcasts can occur at the data link
layer and the network layer. Data-link broadcasts are sent to all hosts attached to a particular physical
network. Network layer broadcasts are sent to all hosts attached to a particular logical network. TCP/IP
supports the following types of broadcast packets:
•
All ones—By setting the broadcast address to all ones (255.255.255.255), all hosts on the network
receive the broadcast.
•
Network—By setting the broadcast address to a specific network number in the network portion of
the IP address and setting all ones in the host portion of the broadcast address, all hosts on the
specified network receive the broadcast. For example, when a broadcast packet is sent with the
broadcast address of 131.108.255.255, all hosts on network number 131.108 receive the broadcast.
•
Subnet—By setting the broadcast address to a specific network number and a specific subnet
number, all hosts on the specified subnet receive the broadcast. For example, when a broadcast
packet is set with the broadcast address of 131.108.4.255, all hosts on subnet 4 of network 131.108
receive the broadcast.
Because broadcasts are recognized by all hosts, a significant goal of router configuration is to control
unnecessary proliferation of broadcast packets. Cisco routers support two kinds of broadcasts: directed
and flooded. A directed broadcast is a packet sent to a specific network or series of networks, whereas a
flooded broadcast is a packet sent to every network. In IP internetworks, most broadcasts take the form
of UDP broadcasts.
The following test was performed:
•
UDP Broadcast Flooding, page 136
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
135
Miscellaneous Features
UDP Broadcast Flooding
There are several facets to this test. An IXIA broadcast stream is used for each aspect of the procedure.
First, the broadcast stream is sent into the network at a single device. It is verified that this device
forwards the broadcast out all physical interfaces. Next the device is configured to use an IP helper
address, which will cause the IP destination portion of the header, originally a broadcast address, to be
replaced by a unicast address, destined for the IP helper address.
The IXIA streams that are configured have been done so with UDP port 53 (domain name system, DNS).
The next part of the procedure tests the functionality of the no ip forward-protocol command, that is
expected to halt the forwarding of any broadcasts using the protocol specified (in this case DNS).
Device under test: SH1-101.
Test Plan
The procedure used to perform the UDP broadcast flooding test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Begin monitoring memory and CPU utilization for the devices being tested.
Step 3
Verify that the ip helper-address command and the no ip forward-protocol commands are not yet
configured on the device.
Step 4
Begin the broadcast IXIA stream on Ix-12/1 (SH1-101 g7/16). The stream should have a length of 74
bytes and be sent at a rate of 5000 pps. The broadcast stream has a destination media access control
(DMAC) of FFFF.FFFF.FFFF and a destination IP (DIP) of 255.255.255.255. This stream will come in
on VLAN 40 and should be broadcast out all interfaces carrying VLAN 40. Verify that it is.
Step 5
Configure an IP helper address of 172.31.64.112 on the VLAN40 interface of SH1-101. This IP address
belongs to IXIA port 11/2, also connected to SH1-101 via interface g3/16.
Step 6
Verify that the traffic coming in is now being sent out interface g3/16 as unicast traffic.
Step 7
Configure the no ip forward-protocol udp domain command globally on SH1-101 to cause the router
to stop forwarding any UDP traffic with a Layer 4 port of 53 (DNS).
Step 8
Verify that traffic stops being sent out interface g3/16.
Step 9
Allow IP forwarding of DNS packets again, and verify that unicast traffic is being sent to the IP helper
address again.
Step 10
Stop the IXIA traffic for about 2 minutes.
Step 11
Reconfigure the IXIA stream to send at a rate of 2500 pps, instead of the previous 5000 pps.
Step 12
Send traffic for about two minutes, enough to get a measure of what halving the traffic rate does for
helping CPU utilization.
Step 13
Stop the IXIA traffic for a short period of time.
Step 14
Reconfigure the IXIA stream to send at a rate of 5000 pps, but with a packet size of 500 bytes (was
74 bytes previously).
Step 15
Send traffic for about 2 minutes, enough to get a measure of what increasing the packet size does for the
CPU utilization.
Step 16
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
136
Miscellaneous Features
Expected Results
The following test results are expected:
•
SH1-101 should forward all broadcast packets on the same VLAN (VLAN 40) they come in on.
•
The packets should forward to the IP helper address as unicast packets when configured to do so.
•
The packets should not be forwarded when the DNS protocol is blocked, and should resume when
the filter is lifted.
•
The CPU and memory should not suffer from severe, sustained, or unacceptable impact.
Results
Table 83 shows the UDP broadcast flooding test results.
Table 83
UDP Broadcast Flooding Test Results
Tests
Results
UDP Broadcast Flooding
Pass
System Upgrade
This test measured the basic ability of the code to boot correctly. The boot process was followed in each
case from the console and screened for any errors. The output shows three separate sections, one for each
supervisor and MSFC combination: supervisor 11, supervisor 12, and supervisor 22.
This test verified that the Cisco IOS upgrade process worked correctly.
The following tests were performed:
•
Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 Upgrade—Supervisor 11, page 137
•
Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 Upgrade—Supervisor 12, page 138
•
Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 Upgrade—Supervisor 22, page 139
•
Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 Upgrade—Supervisor 11, page 140
•
Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 Upgrade—Supervisor 12, page 140
•
Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 Upgrade—Supervisor 22, page 141
Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 Upgrade—Supervisor 11
This test verified that the Cisco IOS upgrade process worked correctly. It measured the basic ability of
the code to boot correctly on supervisor 11 for a Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 upgrade. The
boot process was followed from the console and screened for errors.
Device under test: SH1-106
Test Plan
The procedure used to perform the Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 upgrade—supervisor 11 test
follows:
Step 1
Record the start time of this test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
137
Miscellaneous Features
Step 2
On Sup 11, verify that SH1-106 is running the old Native Cisco IOS image, 12.1(8b)E9.
Step 3
Verify that the Sup11 image under test is on the proper file devices.
Step 4
Verify that the MSFC1 boot image is on the proper file devices.
Step 5
Verify that the boot string points to the proper device and filename for both the test image and the MSFC
boot image. Save any changes to NVRAM when done.
Step 6
Either power-cycle the device or perform a reset on the standby supervisor followed by a reload, to verify
that both primary and standby supervisors reload with the new image. Report any error messages seen
during reload.
Step 7
Verify that both supervisors come online successfully and that the new image is running.
Expected Results
•
The Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 upgrade process should complete without error.
Results
Table 84 shows the Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 upgrade—supervisor 11 test results.
Table 84
Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 Upgrade—Supervisor 11 Test Results
Tests
Results
Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 Upgrade—Supervisor 11 Pass
Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 Upgrade—Supervisor 12
This test verified that the Cisco IOS upgrade process worked correctly. It measured the basic ability of
the code to boot correctly on supervisor 12 for a Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 upgrade. The
boot process was followed from the console and screened for errors.
Device under test: SH1-107.
Test Plan
The procedure used to perform the Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 upgrade—supervisor 12 test
follows:
Step 1
Record the start time of this test.
Step 2
On Sup 12, verify that SH1-107 is running the old Native Cisco IOS image, 12.1(8b)E9.
Step 3
Verify that the Sup12 image under test is on the proper file devices.
Step 4
Verify that the MSFC2 boot image is on the proper file devices.
Step 5
Verify that the boot string points to the proper device and filename for both the test image and the MSFC
boot image. Save any changes to NVRAM when done.
Step 6
Either power-cycle the device or perform a reset on the standby supervisor followed by a reload, to verify
that both primary and standby supervisors reload with the new image. Report any error messages seen
during reload.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
138
Miscellaneous Features
Step 7
Verify that both supervisors come online successfully and that the new image is running.
Expected Results
•
The Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 upgrade process should complete without error.
Results
Table 85 shows the Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 upgrade—supervisor 12 test results.
Table 85
Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 Upgrade—Supervisor 12 Test Results
Tests
Results
Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 Upgrade—Supervisor 12 Pass
Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 Upgrade—Supervisor 22
This test verified that the Cisco IOS upgrade process worked correctly. It measured the basic ability of
the code to boot correctly on supervisor 22 for a Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 upgrade. The
boot process was followed from the console and screened for errors.
Device under test: SH1-109.
Test Plan
The procedure used to perform the Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 upgrade—supervisor 22 test
follows:
Step 1
Record the start time of this test.
Step 2
On Sup 22, verify that SH1-109 is running the old Native Cisco IOS image, 12.1(8b)E9.
Step 3
Verify that the Sup22 image under test is on the proper file devices.
Step 4
Verify that the MSFC2 boot image is on the proper file devices.
Step 5
Verify that the boot string points to the proper device and filename for both the test image and the MSFC
boot image. Save any changes to NVRAM when done.
Step 6
Either power-cycle the device or perform a reset on the standby supervisor followed by a reload, to verify
that both primary and standby supervisors reload with the new image. Report any error messages seen
during reload.
Step 7
Verify that both supervisors come online successfully and that the new image is running.
Expected Results
•
The Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 upgrade process should complete without error.
Results
Table 86 shows the Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 upgrade—supervisor 22 test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
139
Miscellaneous Features
Table 86
Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 Upgrade—Supervisor 22 Test Results
Tests
Results
Cisco IOS 12.1(8b)E9 to 12.1(8b)E14 Upgrade—Supervisor 22 Pass
Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 Upgrade—Supervisor 11
This test verified that the Cisco IOS upgrade process worked correctly. It measured the basic ability of
the code to boot correctly on supervisor 11 for a Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 upgrade. The
boot process was followed from the console and screened for errors.
Device under test: SH1-106.
Test Plan
The procedure used to perform the Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 upgrade—supervisor 11 test
follows:
Step 1
Record the start time of this test.
Step 2
On Sup 11, verify that SH1-106 is running the old Native Cisco IOS image, 12.1(8b)E12.
Step 3
Verify that the Sup11 image under test is on the proper file devices.
Step 4
Verify that the MSFC1 boot image is on the proper file devices.
Step 5
Verify that the boot string points to the proper device and filename for both the test image and the MSFC
boot image. Save any changes to NVRAM when done.
Step 6
Either power-cycle the device or perform a reset on the standby supervisor followed by a reload, to verify
that both primary and standby supervisors reload with the new image. Report any error messages seen
during reload.
Step 7
Verify that both supervisors come online successfully and that the new image is running.
Expected Results
•
The Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 upgrade process should complete without error.
Results
Table 88 shows the Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 upgrade—supervisor 11 test results.
Table 87
Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 Upgrade—Supervisor 11 Test Results
Tests
Results
Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 Upgrade—Supervisor 11 Pass
Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 Upgrade—Supervisor 12
This test verified that the Cisco IOS upgrade process worked correctly. It measured the basic ability of
the code to boot correctly on supervisor 12 for a Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 upgrade. The
boot process was followed from the console and screened for errors.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
140
Miscellaneous Features
Device under test: SH1-107.
Test Plan
The procedure used to perform the Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 upgrade—supervisor 12 test
follows:
Step 1
Record the start time of this test.
Step 2
On Sup 12, verify that SH1-107 is running the old Native Cisco IOS image, 12.1(8b)E12.
Step 3
Verify that the Sup12 image under test is on the proper file devices.
Step 4
Verify that the MSFC2 boot image is on the proper file devices.
Step 5
Verify that the boot string points to the proper device and filename for both the test image and the MSFC
boot image. Save any changes to NVRAM when done.
Step 6
Either power-cycle the device or perform a reset on the standby supervisor followed by a reload, to verify
that both primary and standby supervisors reload with the new image. Report any error messages seen
during reload.
Step 7
Verify that both supervisors come online successfully and that the new image is running.
Expected Results
•
The Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 upgrade process should complete without error.
Results
Table 88 shows the Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 upgrade—supervisor 12 test results.
Table 88
Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 Upgrade—Supervisor 12 Test Results
Tests
Results
Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 Upgrade—Supervisor 12 Pass
Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 Upgrade—Supervisor 22
This test verified that the Cisco IOS upgrade process worked correctly. It measured the basic ability of
the code to boot correctly on supervisor 22 for a Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 upgrade. The
boot process was followed from the console and screened for errors.
Device under test: SH1-109.
Test Plan
The procedure used to perform the Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 upgrade—supervisor 22 test
follows:
Step 1
Record the start time of this test.
Step 2
On Sup 22, verify that SH1-109 is running the old Native Cisco IOS image, 12.1(8b)E12.
Step 3
Verify that the Sup22 image under test is on the proper file devices.
Step 4
Verify that the MSFC2 boot image is on the proper file devices.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
141
Miscellaneous Features
Step 5
Verify that the boot string points to the proper device and filename for both the test image and the MSFC
boot image. Save any changes to NVRAM when done.
Step 6
Either power-cycle the device or perform a reset on the standby supervisor followed by a reload, to verify
that both primary and standby supervisors reload with the new image. Report any error messages seen
during reload.
Step 7
Verify that both supervisors come online successfully and that the new image is running.
Expected Results
•
The Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 upgrade process should complete without error.
Results
Table 89 shows the Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 upgrade—supervisor 22 test results.
Table 89
Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 Upgrade—Supervisor 22 Test Results
Tests
Results
Cisco IOS 12.1(8b)E12 to 12.1(8b)E14 Upgrade—Supervisor 22 Pass
Secure Shell
Secure Shell (SSH) is an application and a protocol that provide a secure replacement to the Berkeley
r-tools. The protocol secures the sessions using standard cryptographic mechanisms, and the application
can be used similarly to the Berkeley rexec and rsh tools. Two versions of SSH are available: SSH
Version 1 and SSH Version 2. Only SSH Version 1 is implemented in the Cisco IOS software.
The SSH Server feature enables a SSH client to make a secure, encrypted connection to a Cisco router.
This connection provides functionality that is similar to that of an inbound Telnet connection. Before
SSH, security was limited to Telnet security. SSH allows a strong encryption to be used with the
Cisco IOS software authentication. The SSH server in Cisco IOS software will work with publicly and
commercially available SSH clients.
The user authentication mechanisms supported for SSH are RADIUS, TACACS+, and the use of locally
stored user names and passwords.
The following test was performed:
•
SSH Server Vulnerability, page 142
SSH Server Vulnerability
This test verified that the SSH server built into Cisco IOS crypto images is not succeptible to SSH
malformed packet vulnerabilities as described at:
•
http://www.cisco.com/warp/public/707/ssh-packet-suite-vuln.shtml.
The test protocol data units (PDUs) sent to the device were downloaded from:
•
http://www.rapid7.com/Product-Download.html.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
142
Miscellaneous Features
Test Plan
The procedure used to perform the SSH server vulnerability test follows:
Step 1
Verify that SH1-101 is running Native Cisco IOS Release 12.1(13)E4 with a 3DES cryptography feature
set.
Step 2
Begin monitoring CPU and memory of SH1-101.
Step 3
Verify that SH1-101 is configured with a host name, domain name, and TACACS authentication on vty
lines.
Step 4
Verify that the SSH server on SH1-101 is enabled by generating an rsa key pair. Configure the vty lines
to allow SSH, and verify that SH1-101 is accepting SSH connections.
Note
If the following step causes the error message “WARNING: REMOTE HOST IDENTIFICATION
HAS CHANGED!” this device has generated a different key than last time this test was performed.
You will need to delete the line that contains the old key in the file ~/.ssh/known_hosts and reconnect.
Step 5
Send malformed SSH packets at SH1-101 while monitoring the device.
Step 6
Verify that the device does not reload or pause indefinitely.
Step 7
Remove the configuration added in this test case.
Note
Zeroizing the rsa key is the only way to shut off the SSH server process. However, removing SSH
from the transport input statement will is enough to disallow incoming SSH connections. If the key
is zeroized, the next time the test case is performed prior to Step 5, the tester will need to remove the
old key stored in ~/.ssh/known_hosts before SSH will allow the connection to be made.
Step 8
Show the CPU, memory, and log output.
Step 9
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
SSH vulnerability testing should not cause the router to pause indefinitely, or reload.
Results
Table 90 shows the SSH server vulnerability test results.
Table 90
SSH Server Vulnerability Test Results
Tests
Results
SSH Server Vulnerability
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
143
Miscellaneous Features
CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, Cisco Unity, Follow Me Browsing, FormShare, and StackWise are
trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.;
and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco
IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver,
EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard,
LightStream, MGX, MICA, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX,
Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet
Quotient, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply
a partnership relationship between Cisco and any other company. (0304R)
Copyright © 2003, Cisco Systems, Inc.
All rights reserved.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(8b)E14
144