Cisco Safe Harbor Testing for Financial
Enterprise Customers, Release 12.1(13)E11
Version History
Version Number Date
1
Notes
November 18, 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 contains the following introductory sections:
•
About Cisco IOS Safe Harbor, page 2
•
Financial Lab Topology, page 2
•
Test Results Summary, page 18
•
DDTS Summary, page 23
•
Feature Sets Testing, page 24
This document contains the following test sections:
•
Memory Leaks, page 24
•
Hardware Redundancy, page 26
•
Layer 2 Features, page 34
•
Layer 3 Routing, page 58
•
Network Management, page 174
•
Miscellaneous Features, page 180
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 are the following: hardware redundancy, Layer 2 features,
hardware forwarding (switching) 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 24.
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.
Note
All topologies, devices, and configurations were updated to include additional features and hardware.
Details are available in the results document.
Financial Lab Topology
The base Cisco Native IOS financial lab topology is defined in the following sections and illustrated in
Figure 1 through Figure 12:
•
Basic Topology: Port Channel Deployment, page 3
•
Basic Topology: Routing Protocols, page 3
•
Basic Topology: Testbed Diagrams, page 4
•
Test Device Configurations, page 17
The financial services network environment configured in the lab includes the following hardware:
•
Sixteen Catalyst 6500 switches running Cisco Native IOS Release 12.1(13)E11 (SH1-97 to
SH1-110, SH1-113, and SH1-114)
•
Two Catalyst 6500 switches that are running Hybrid CatOS 6.4(6) train with no routing (Dista-1 and
Dista-2)
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
2
About Cisco IOS Safe Harbor
•
Pagent test devices to simulate the Internet Service Providers (ISPs) in Border Gateway Protocol
(BGP) ASes 10 and 20, Open Shortest Path First (OSPF) Areas 2, 4 and 6, and Enhanced Interior
Gateway Routing Protocol (EIGRP) process 1320.
•
IXIA test devices to generate simulated customer traffic
The hardware configuration in the financial test lab includes a combination of pure fabric,
fabric-capable, and nonfabric modules.
Note
The Switch Fabric Module is supported only with the Supervisor Engine 2 in the Catalyst 6500 series
switch.
Basic Topology: Port Channel Deployment
Figure 1 through Figure 12 show the portchannel deployment for the Safe Harbor testing. Catalyst 6500
series switches running Cisco Native IOS support both Layer 2 and Layer 3 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 portchannel.
The portchannels configured for Safe Harbor testing are Gigabit EtherChannels (GECs). The following
types of GEC portchannels 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 12 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(13)E11
3
About Cisco IOS Safe Harbor
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 provides a detailed view of the Safe Harbor network OSPF routing topology.
•
Figure 3 on page 7 provides a detailed view of the Safe Harbor network EIGRP routing topology.
•
Figure 4 on page 8 provides a detailed view of the Safe Harbor network BGP routing topology.
•
Figure 5 on page 9 shows Ether Channeling—Part A 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 6 on page 10 shows EtherChannels—Part B 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 7 on page 11 shows IP interfaces—Part A configuration of the Safe Harbor testbed.
•
Figure 8 on page 12 shows IP interfaces—Part B configuration of the Safe Harbor testbed.
•
Figure 9 on page 13 shows the Safe Harbor network multicast configuration overview based on one
of Cisco’s largest financial customers. It presents a real-world scenario. This figure shows the extent
that devices participate in the overall multicast scheme.
•
Figure 10 on page 14 shows background traffic running to emulate real-world network conditions
with three multicast streams traversing the network and the devices they cross in a majority of the
test plan.
•
Figure 11 on page 15 shows background traffic running to emulate real-world network conditions
with four unicast streams traversing the network and the devices they cross in a majority of the test
plan.
•
Figure 12 on page 16 shows the Safe Harbor network multicast test traffic configuration based on
one of Cisco’s largest financial customers. It presents a real-world scenario.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
4
About Cisco IOS Safe Harbor
Figure 1
Safe Harbor Device Modules and Chassis Positions
Mo dules
1 WS-X6K-S2U-MSFC2
1 WS-F6K-PFC2
1 WS-F6K-MSFC2
2 WS-X6K-S2U-MSFC2
2 WS-F6K-PFC2
2 WS-F6K-MSFC2
3 WS-X6816-GBIC
3 WS-F6K-DFC
4 WS-X6324-100FX-MM
5 WS-X6500-SFM2
6 WS-X6500-SFM2
7 WS-X6516-GBIC
8 WS-X6348-RJ-45
SH 1-103
1 WS-X6K-S2U-MSFC2
1 WS-F6K-PFC2
1 WS-F6K-MSFC2
2 WS-X6K-S2U-MSFC2
2 WS-F6K-PFC2
2 WS-F6K-MSFC2
3 WS-X6816-GBIC
3 WS-F6K-DFC
4 WS-X6816-GBIC
4 WS-F6K-DFC
5 WS-X6500-SFM2
6 WS-X6500-SFM2
7 WS-X6516-GBIC
8 WS-X6516-GBIC
9 WS-X6548-RJ-45
SH 1-109
1 WS-X6K-S2U-MSFC2
1 WS-F6K-PFC2
1 WS-F6K-MSFC2
2 WS-X6K-S2U-MSFC2
2 WS-F6K-PFC2
2 WS-F6K-MSFC2
3 WS-X6816-GBIC
3 WS-F6K-DFC
4 WS-X6816-GBIC
4 WS-F6K-DFC
5 WS-X6500-SFM2
6 WS-C6500-SFM
7 WS-X6516-GBIC
8 WS-X6816-GBIC
8 WS-F6K-DFC
9 WS-X6548-RJ-45
SH 1-98
1 WS-X6K-S2U-MSFC2
1 WS-F6K-PFC2
1 WS-F6K-MSFC2
2 WS-X6K-S2U-MSFC2
2 WS-F6K-PFC2
2 WS-F6K-MSFC2
3 WS-X6816-GBIC
3 WS-F6K-DFC
4 WS-X6324-100FX-MM
5 WS-X6500-SFM2
6 WS-X6500-SFM2
7 WS-X6516-GBIC
8 WS-X6348-RJ-45
SH 1-104
1 WS-X6K-S2U-MSFC2
1 WS-F6K-PFC2
1 WS-F6K-MSFC2
2 WS-X6K-S2U-MSFC2
2 WS-F6K-PFC2
2 WS-F6K-MSFC2
3 WS-X6816-GBIC
3 WS-F6K-DFC
4 WS-X6516-GBIC
5 WS-X6500-SFM2
6 WS-X6500-SFM2
7 WS-X6516-GBIC
8 WS-X6516-GBIC
9 WS-X6324-100FX-MM
SH 1-110
1 WS-X6K-S2U-MSFC2
WS-F6K-PFC2
WS-F6K-MSFC2
2 WS-X6K-S2U-MSFC2
WS-F6K-PFC2
WS-F6K-MSFC2
3 WS-X6816-GBIC
WS-F6K-DFC
4 WS-X6816-GBIC
WS-F6K-DFC
5 WS-X6500-SFM2
6 WS-X6500-SFM2
7 WS-X6516-GBIC
8 WS-X6516-GBIC
9 WS-X6148-RJ-45
SH 1-99
1 WS-X6K-S2U-MSFC2
1 WS-F6K-PFC2
1 WS-F6K-MSFC2
2 WS-X6K-S2U-MSFC2
1 WS-F6K-PFC2
1 WS-F6K-MSFC2
3 WS-X6816-GBIC
3 WS-F6K-DFC
4 WS-X6816-GBIC
4 WS-F6K-DFC
5 WS-X6500-SFM2
6 WS-X6500-SFM2
7 WS-X6348-RJ-45
9 WS-X6516-GBIC
SH 1-105
1 WS-X6K-SUP1A-2GE
1 WS-F6K-PFC
1 WS-F6K-MSFC
2 WS-X6K-SUP1A-2GE
2 WS-F6K-PFC
2 WS-F6K-MSFC
3 WS-X6408A-GBIC
4 WS-X6408A-GBIC
5 WS-X6408A-GBIC
6 WS-X6408A-GBIC
7 WS-X6324-100FX-MM
9 WS-X6348-RJ-45
9 WS-F6K-PWR
SH 1-113
1 WS-X6K-SUP1A-2GE
1 WS-F6K-PFC
1 WS-F6K-MSFC2
2 WS-X6516-GBIC
3 WS-X6516-GBIC
9 WS-X6148-RJ-45
SH 1-100
1 WS-X6K-S2U-MSFC2
1 WS-F6K-PFC2
1 WS-F6K-MSFC2
2 WS-X6K-S2U-MSFC2
2 WS-F6K-PFC2
2 WS-F6K-MSFC2
3 WS-X6816-GBIC
3 WS-F6K-DFC
4 WS-X6816-GBIC
4 WS-F6K-DFC
5 WS-X6500-SFM2
6 WS-X6500-SFM2
7 WS-X6548-RJ-45
9 WS-X6516-GBIC
9 WS-F6K-DFC
SH 1-106
1 WS-X6K-SUP1A-2GE
1 WS-F6K-PFC
1 WS-F6K-MSFC
2 WS-X6K-SUP1A-2GE
2 WS-F6K-PFC
2 WS-F6K-MSFC
3 WS-X6408A-GBIC
4 WS-X6408A-GBIC
5 WS-X6408A-GBIC
6 WS-X6408A-GBIC
7 WS-X6324-100FX-MM
9 WS-X6348-RJ-45
9 WS-F6K-PWR
SH 1-114
1 WS-X6K-SUP1A-2GE
1 WS-F6K-PFC
1 WS-F6K-MSFC2
2 WS-X6516-GBIC
3 WS-X6516-GBIC
9 WS-X6148-RJ-45
SH 1-101
1 WS-X6K-S2U-MSFC2
1 WS-F6K-PFC2
1 WS-F6K-MSFC2
2 WS-X6K-S2U-MSFC2
2 WS-F6K-PFC2
2 WS-F6K-MSFC2
3 WS-X6816-GBIC
3 WS-F6K-DFC
5 WS-X6500-SFM2
6 WS-X6500-SFM2
7 WS-X6516-GBIC
8 WS-X6324-100FX-MM
9 WS-X6148-RJ-45
SH 1-107
1 WS-X6K-SUP1A-2GE
1 WS-F6K-PFC
1 WS-F6K-MSFC2
2 WS-X6K-SUP1A-2GE
2 WS-F6K-PFC
2 WS-F6K-MSFC2
3 WS-X6408A-GBIC
4 WS-X6408A-GBIC
5 WS-X6324-100FX-MM
9 WS-X6548-RJ-45
Dista-1
1 WS-X6K-SUP2-2GE
1 WS-F6K-PFC2
2 WS-X6416-GE-MT
3 WS-X6408A-GBIC
4 WS-X6416-GE-MT
5 WS-X6408-GBIC
6 WS-X6248A-RJ-45
SH 1-102
1 WS-X6K-S2U-MSFC2
1 WS-F6K-PFC2
1 WS-F6K-MSFC2
2 WS-X6K-S2U-MSFC2
1 WS-F6K-PFC2
1 WS-F6K-MSFC2
3 WS-X6816-GBIC
3 WS-F6K-DFC
4 WS-X6348-RJ-45
4 WS-F6K-PWR
5 WS-X6500-SFM2
6 WS-X6500-SFM2
7 WS-X6516-GBIC
8 WS-X6324-100FX-MM
SH 1-108
1 WS-X6K-SUP1A-2GE
1 WS-F6K-PFC
1 WS-F6K-MSFC2
2 WS-X6K-SUP1A-2GE
2 WS-F6K-PFC
2 WS-F6K-MSFC2
3 WS-X6408A-GBIC
4 WS-X6408A-GBIC
5 WS-X6324-100FX-MM
9 WS-X6148-RJ-45
Dista-2
1 WS-X6K-SUP2-2GE
1 WS-F6K-PFC2
2 WS-X6416-GE-MT
3 WS-X6408A-GBIC
4 WS-X6416-GE-MT
5 WS-X6324-100FX-MM
6 WS-X6248A-RJ-45
4333
SH 1-97
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
5
About Cisco IOS Safe Harbor
Figure 2
Safe Harbor OSPF Routing
Routing - OSPF
Area 0
SH1-97
Sup2 2
IXIA
5
SH1-98
Sup22
0,6
0,6
SH1-99
Sup2 2
SH1-100
Sup22
Area 3
IXIA
3
Area 5
Pagent
6
Area 6
0-5
0-5
Area 2
Area 4
SH1-105
Sup1 1
2
SH1-113
Sup12
4
SH1-106
Sup1 1
SH1-103
Sup22
SH1-104
Sup22
1
1
SH1-114
Sup12
SH1-101
Sup22
2
4
SH1-102
Sup2 2
Dista-2
SH1-107
Sup12
1
SH1-108
Sup1 2
SH1-109
Sup22
1
1
Area 1
Dista-1
1
Dista-2
94334
Dista-1
SH1-110
Sup2 2
Dista-1
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
6
About Cisco IOS Safe Harbor
Figure 3
Safe Harbor EIGRP Routing
SH1-97
Sup22
Routing - EIGRP
SH1-98
Sup2 2
IXIA
IXIA
SH1-99
Sup22
Pagent
SH1-100
Sup2 2
SH1-105
Sup11
SH1-113
Sup1 2
SH1-106
Sup11
SH1-103
Sup2 2
SH1-114
Sup12
SH1-101
Sup2 2
SH1-104
Sup2 2
SH1-102
Sup22
Dista-2
SH1-107
Sup1 2
SH1-110
Sup22
Dista-1
EIGRP 1320
Dista-1
SH1-109
Sup2 2
Dista-2
94335
SH1-108
Sup12
Dista-1
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
7
About Cisco IOS Safe Harbor
Figure 4
Safe Harbor BGP Routing
R outi
ng -B G P
Pagent
Pagent
AS 20
AS 10
SH1-97
Sup22
AS 100
SH1-98
Sup2 2
100,10,20
100,10,20
SH1-99
Sup22
SH1-100
Sup2 2
100
100
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
8
About Cisco IOS Safe Harbor
Safe Harbor EtherChannel—Part A
SH1-97
Po
2
11
Po
1
3
SH1-99
14
Po
7
Po
11
Po
11
Po
Po
16
Po
15
Po166
SH1-106
Po1
0
Po
64
Po
16
Po6
4
SH1-113
5
Po
156
5
SH1-114
0
Po1
0
Po2
0
Po1
Dista-2
Dista-2
7
SH1-105
16
Po
67
Po
SH1-104
7
SH1-103
64
16
SH1-102
6
11
Po
66
Po
SH1-101
5
11
Po
Po
1
5
11
Po
16
1
Po
P
Po o64
67
Po
16
Po
15
4
Po17
4
1
Po1
Po
156
5
11
Po
Po6
5
66
Po
Po17
14
Po
SH1-100
Po12
Po13
Dista-2
EtherChannel
Part B
94337
Auto
12
Po
Po1
0
PoXX
3
Po2
0
Desirable
Po12
PoXX
Po
1
Po12
On
Po11
Po13
EtherChannel Modes:
PoXX
SH1-98
Po11
Po113
EtherChannel - Part A
7
Po166
Figure 5
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
9
About Cisco IOS Safe Harbor
Figure 6
Safe Harbor EtherChannel—Part B
EtherChannel - Part B
EtherChannel
Part A
EtherChannel Modes:
Desirable
PoXX
Auto
SH1-103
Po
71
9
Po17
0
Po
6
9
16
Po
Po7
1
SH1-109
Po1
Po1
Po
Po
20
10
Dista-2
94338
Dista-1
Po
17
1
SH1-110
Po1
Po
10
Po1
0
SH1-108
7
Po
Po69
68
68
Po
Po1
SH1-107
Po
71
8
Po6
70
Po
Po69
68
Po
SH1-104
Po
20
On
PoXX
Po70
PoXX
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
10
About Cisco IOS Safe Harbor
Safe Harbor IP Interfaces—Part A
SH1-97
SH1-98
IP Interfaces - Part A
7/1-2 (1)
(93
)
29)
215.114
216.114
217.114
218.114
219.114
220.114
/1
(
SH1-105
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
4/9-10
VLANs
-6
106
100.67
101.67
102.67
103.67
104.67
Dista-2
31.
3/9-
10,2
/1-2
11.
2)
SH1-113
(172
(1
72
.3
1.
11
.31.
.1
11.6
4)
)
SH1-114
,5/7
3/7
4/5
105
100.66
101.66
102.66
103.66
104.66
0 (1
72.
SH1-106
0
-2
3/1
A table of IP addresses configured on vl an
VLANs 40 through 50 on devices SH1- 40
105 and SH1-106. The address format
41
is 172.31.x.x/24. The two HSRP
42
addresses for these interfaces are
43
172.31.[100-110].[1,254].
44
70
)
40-50
IP Interfaces
Part B
/9-1
Dista-1
94339
(94
)
3-4
3/7-8
1
4/
3-
2 /1
-2,3
5-6
/1
3-4/1,3-4/
9 (34)
30)
,3/1
1(
3/3
9/1
-2
SH1-104
4)
(5
20
0-1
s 11
/16 VLAN
2-3
0-50 7/6,7/8
215.113
216.113
217.113
218.113
219.113
220.113
2/
910
,3
/1
-2
10)
SH1-103
,3
9
4/
1.
1.1
10
,4/
(6
6)
0- 5
s4
AN
VL
-50
VLA
Ns 4
115
116
117
118
119
120
11
.1
3)
2.3
(17
3/2
)
(50
-8
40
Ns
VLA
3/6,3
/8
(1
72
.3
1.
114
210.114
211.114
212.114
213.114
214.114
10
/92,2
)
(4 6
34/
1
3/7
2
7/1-
Dista-1
-1
0
113
210.113
211.113
212.113
213.113
214.113
3/1
10
/9-
1)
vl an
110
111
112
113
114
5-6/1 (98)
2,3
SH1-100 4/5
-6
,9
/9
(41)
4/12 5)
3/4,
(4
0
-4/1 49) )
/2,3 /12 (
3
3 -4
3
(5
,
4/4
11
4/
3,
3
4/
3-
)
(38
10
3/1
4/5,
9/73/1
8 (1
3,
72.3
9/5 3/15,
1.11
9/9
-6
.5)
9/
-10
(
169
(17
)
2
2.3
(6
1.1
5)
1.
,3/
4/2
SH1-102
3-4/1,3-4/8,3-4/9,3-4/16 (14)
2/2,
)
(37
(42)
3/11
3/3,
3-4/1,3-4/8,3-4/9,3-4/16 (13)
2
3/1
1
3/
SH1-101
6)
(2
SH1-99
,
4/4
0
-1
/9
,3
-2
/14
3/6,4
1-2/2
,3/6
,4/14
(22)
(18)
)
1.9
1.1
2.3
(17
-8
,9/7
,3/7
9/5-6 (97)
2,
4/
3-
10
4/
3-
5)
(2
,4/1
2(
75.14
76.14
77.14
78.14
79.14
80.14
3)
75.14
76.14
77.14
78.14
79.14
80.14
3/4
45
46
47
48
49
50
3-4/3,3-4/
11 (3
102
70.14
71.14
72.14
73.14
74.14
A table of IP addresses configured on
VLANs 110 through 120 on devices SH1113 and SH1-114. The address format is
172.31.x.x/24. The two HSRP addresses
for these interfaces are 172.31.[100110].[1,254].
1/1
101
70.14
71.14
72.14
73.14
74.14
/1
3/2,3
(21)
7)
0 (1
3/1,3/9 (9)
3/5,4/13 (10)
vl an
40
41
42
43
44
1-2/2
,3/2
,3/1
0
1-2/1,3/1,3/9 (5)
1-2/1,3/5,4/13 (6)
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].
7/1-2 (2)
3/4,5
/4,3/5
,5/5
VLA
Ns 1 2-3/8
10-1 ,2-3/1
20
6
Figure 7
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
11
About Cisco IOS Safe Harbor
Figure 8
Safe Harbor IP Interfaces—Part B
IP Interfaces - Part B
SH1-103
11
4)
(1
05
)
4/15
-16,8
/15-1
6 (10
9)
8/
710
(110
)
/5
/7
,4/1
2
VL ,4/3
AN
s 1 7-8
0-2 /3,
7-8
0
,7
7/3
1
,1/
1/2
,4/1
3
4
4/1
1
,2/
1/1
1/2
,2/
2-4
0
0-2
-20
10
s1
AN
VL
s
AN
VL
Dista-2
Interfaces local to SH1-110 connecting to Dista-2 are g3/5-6 and g4/5-6.
94340
3
,4/
4/1
4/1
-4
4(
(86
)
3-4/7 (202)
3-4/7 (201)
10
-20
/3 -
8/1
SH1-110
3-4/7 (118)
VL
AN
s
4,4
3/
56,
4/
56
3/3
2)
(8
(78)
1
8/
71,
4/
3-
(1
06
)
1)
1,7
-
SH1-109
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
12
)
(8
4
3/1-
3-4
/
Dista-1
Note
3
11
6
SH1-108
3-4/7 (117)
4(
(77)
SH1-107
3-1
10
8/7-
(85
)
3/5-6
,4/5-6
7/7
-10
(73
)
1)
(10
-10
7
/
7
1
,8/
3-1
4
4
3-1
,8/
1
IP addresses configured on VLANs 10
through 20 on devices SH1-109 and
SH1-110. The address format is
172.31.x.x/24. The two HSRP
addresses for these interfaces are
172.31.[20-30].[1,254].
vl an 109
110 15 25.70 25.71
10 20.70 20.71 16 26.70 26.71
11 21.70 21.71 17 27.70 27.71
12 22.70 22.71 18 28.70 28.71
13 23.70 23.71 19 29.70 29.71
14 24.70 24.71 20 30.70 30.71
3 /1
7/1
3-1
4
2)
10
6(
/54
,
-6
3/5
3/1
-4
(74
)
SH1-104
-1
15
8/
6,
-1
15
7/
IP addresses configured on VLANs 40
through 50 on devices SH1-107 and
SH1-108. The address format is
172.31.x.x/24. The two HSRP
addresses for these interfaces are
172.31.[9-19].[1,254].
vl an 107
108 15 15.68 15.69
10 10.68 10.69 16 16.68 16.69
11 11.68 11.69 17 17.68 17.69
12 12.68 12.69 18 18.68 18.69
13 13.68 13.69 19 19.68 19.69
14 14.68 14.69 20 20.68 20.69
About Cisco IOS Safe Harbor
Safe Harbor Multicast
Multicast
SH1-97
This diagram represents a view of the general multicast
design for this topology. This topology includes four local
multicast areas, one regional areas, and one global area.
Each area highlights a pair of routers that server as the PIMRPs for that area, whether global, regional, or local. The
Global and Regional RP pairs are running Auto-RP with
Anycast and MSDP. The Local RP pairs are running Static
RP with Anycast and MSDP. Each area is restricted to
sending and receiving traffic within the addressing scope.
All devices can send or receive traffic within the scope of
global addresses. Only devices within the givenregion can
send or receive traffic within the scope of regionaladdresses
(this includes all devices downstream from the regional RP
pair, in this topology). Local multicast traffic is restricted to the
local area and its senders or receivers.
SH1-98
RP/DR
SH1-99
SH1-100
RP/DR
SH1-105
SH1-113
SH1-106
SH1-114
SH1-101
SH1-103
SH1-104
RP/DR
PIM-DR
RP/DR
SH1-102
Dista-1
Dista-2
RP/DR
SH1-107
SH1-110
Dista-1
SH1-108
SH1-109
PIM-DR
PIM-DR
Dista-1
Local
239.255.0.0 239.255.255.255
Regional
239.100.0.0 239.100.255.255
Global
239.98.0.0 239.98.255.255
Dista-2
94341
Figure 9
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
13
About Cisco IOS Safe Harbor
Figure 10
Safe Harbor Background Traffic—Multicast
SH1-97
Background
Multicast Traffic
1
4/5
L3
Transmitting to multicast groups
239.98.50.1 to 239.98.50.10
from a single IP source.
2 4/7
Transmitting to multicast groups
239.100.50.1 to 239.100.50.10
from a single IP source.
1|2|3 2/8
VLAN44
6/6
3 2/2
VLAN45
6/5
L3
SH1-98
There are Global, Regional, and Local multicast areas in Release 13 E
configuration. The background multicast traffic incorporates each of these.
There is a single transmitter for groups in the Global scope. SH1-97 and
SH1-98 are the PIM-RPs for these global groups. There is a single
transmitter for groups in the Regional scope, for which SH1-99 and SH1-100
are the PIM-RPs. The RPs for the local scopes are represented in subsets
{SH1-101,SH1-102}, {SH1-105,SH1-106}, {SH1-113,SH1-114}, and
{SH1-103,SH1-104}. The local multicast groups use similar addressing
schemes so that any leakage from one Local area to another can be found.
Fa8/11
SH1-99
SH1-100
Fa7/2
SH1-101
SH1-113
Dis ta-1
Dis ta-1
SH1-102
SH1-114
6/9
6/2
VLAN113
VLAN115
3/4
1|2|5
4/1
5
Transmitting to multicast groups
239.255.50.1 to 239.255.50.10
from a single IP source.
Transmitting to multicast groups
239.255.50.1 to 239.255.50.10
from a single IP source.
SH1-107
SH1-105
SH1-103
Dista-1
4
2/3
VLAN40
6/1
VLAN47
6/7
Dist a-2
4/6
3/3
VLAN16
VLAN20
SH1-108
SH1-106
8/2 1|2|6|7
13/1 6
Transmitting to multicast groups
239.255.50.1 to 239.255.50.10
from a single IP source.
Transmitting to multicast groups
239.255.50.1 to 239.255.50.10
from a single IP source.
SH1-109
SH1-104
Dista-2
6/5
6/4
SH1-110
VLAN17
VLAN19
5/1 1|2|6|7
5/2
7
Transmitting to multicast groups
239.255.51.1 to 239.255.51.10
from a single IP source.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
14
94342
1|2|4 2/5
About Cisco IOS Safe Harbor
Figure 11
Safe Harbor Background Traffic—Unicast
SH1-97
Background
Unicast Traffic
4|5 4/5
All unicast streams are sent from a single IP source.
SH1-99
1 4/7
2/8
6/6
VLAN44
SH1-100
Fa7/2
L3
SH1-101
2
SH1-98
Fa8/11
L3
SH1-113
Dis ta-1
Dis ta-1
SH1-102
SH1-114
6/9
3/4
VLAN113
4
6/10
5/4
VLAN111
6
3
SH1-107
SH1-105
SH1-103
2/5
6/1
VLAN40
Dista-1
4/6
8/2
VLAN16
1
Dista-2
6/5
5/1
VLAN17
3
Dist a-2
SH1-108
SH1-106
SH1-109
SH1-104
2|6
SH1-110
94343
5
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
15
About Cisco IOS Safe Harbor
Figure 12
Safe Harbor Multicast Test Traffic
Multicast Test Traffic
a 12/1
a
2/1
b
1/2
c
2/7
VLAN41
6/1
VLAN43
5/1
VLAN43
6/7
L3
Gi7/16
SH1-101
SH1-99
SH1-100
PIM-RP
PIM-RP
There are three transmitters of the multicast test
trafficsending to a total of 30 groups. Each transmitter
issending from ten separate IP sources, to ensure load
balancing across the EtherChannels. SH1-99 and SH1100 are the PIM-RPs for all 30 multicast groups, and
are running Auto-RP.
SH1-113
Fa9/2
Dist a-1
2/4
4/6
Dis ta-1
SH1-102
c
L3
L3
b
6/8
VLAN110
3/3 a
SH1-114
Transmitting to multicast groups
239.100.1.1 to 239.100.1.10 from
ten incrementing IP sources.
Fa4/5
SH1-107
a
1/1
L3 Gi3/2
(2O Subnet)
Fa9/3
SH1-105
L3
5/3
b
SH1-103
Dista-1
b
2/6
4/2
VLAN49
6/3
SH1-106
Gi4/8
L3
a
VLAN11
2/1
VLAN11
10/1 a
2/6
VLAN16
10/2 b
7/2 a
L3
Gi3/8
(2O Subnet)
Transmitting to multicast groups
239.100.1.1 to 239.100.1.10 from
ten incrementing IP sources.
SH1-109 Gi3/16
L3
Gi7/16
L3
7/1
c
9/1
c
9/2
a
SH1-104
Dista-2
3/3
VLAN20
SH1-110
Gi4/16
L3
(2O Subnet)
Gi8/16
L3
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
13/2 c
11/1 b
12/2 a
Transmitting to multicast groups
239.100.1.1 to 239.100.1.10 from
ten incrementing IP sources.
16
8/1
4/1
SH1-108
94344
c
VLAN41 6/2 Dis ta-2
About Cisco IOS Safe Harbor
Test Device Configurations
The following devices are hyper linked to the configuration used in the Safe Harbor testbed for Release
12.1(13)E11 testing
•
SH1-97
•
SH1-98
•
SH1-99
•
SH1-100
•
SH1-101
•
SH1-102
•
SH1-103
•
SH1-104
•
SH1-105
•
SH1-106
•
SH1-107
•
SH1-108
•
SH1-109
•
SH1-110
•
SH1-113
•
SH1-114
•
Dista-1
•
Dista-2
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
17
Test Results Summary
Test Results Summary
Table 1 summarizes the tests to be executed as part of the Cisco IOS Safe Harbor initiative. Table 1
includes the feature or function tested, the section that describes the feature set the feature or function
belongs to, the component tests for each feature or function, and whether the test is new in this iteration
of Safe Harbor testing.
Table 1
Safe Harbor Test Results Summary
Test Case
Feature Set
Tests
Results
Memory
Leaks
Memory Leaks, page 24
Multicast Flap Memory Leak
CSCdz30906
CSCea21798
Hardware
Redundancy
Hardware Redundancy, page 26
Switch Fabric Module Failover
Pass
Supervisor 1 Failover
Pass
Supervisor 2 Failover
Pass
Power Supply Failure—Supervisor 1
Pass
Power Supply Failure—Supervisor 2
Pass
RPR+—Supervisor Hot-Insert
Pass
Unidirectional Link
Detection—Aggressive Mode,
page 34
Basic UDLD on Layer 2 Link
Pass
Basic UDLD on Layer 3 Link
Pass
Trunking, page 37
Supervisor 1 Configuration and Failure Recovery
Pass
Supervisor 2 Configuration and Failure Recovery
Pass
Basic Layer 2 Channeling Configuration
Pass
Basic Layer 3 Channeling Configuration
Pass
Layer 2 EtherChannel Load Balance
Pass
Layer 3 EtherChannel Load Balance
Pass
Layer 2 GEC Failure and Recovery—Supervisor 1
Pass
Layer 3 GEC Failure and Recovery—Supervisor 1
Pass
Layer 2 GEC Failure and Recovery—Supervisor 2
Pass
Layer 3 GEC Failure and Recovery—Supervisor 2
Pass
Gigabit Ethernet Module Reset—Supervisor 1
Pass
Gigabit Ethernet Module Reset—Supervisor 2
Pass
Basic VLAN Trunking Protocol Configuration
Pass
Layer 2
Features
Port Aggregation Protocol
(Channeling), page 40
VLAN Trunking Protocol, page 56
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
18
Test Results Summary
Table 1
Safe Harbor Test Results Summary (continued)
Test Case
Feature Set
Tests
Results
Layer 3
Routing
IP Multicast, page 58
Last Hop Router Functionality
Pass
First Hop Router Functionality
Pass
Basic Static RP Functionality—Supervisor 11
Pass
Basic Static RP Functionality—Supervisor 22
CSCea21798
CSCdx48854
Basic Auto RP Functionality—Supervisor 22
Pass
Auto PIM-RP Failover—First Hop Router
Impact—Supervisor 11
Pass
Auto PIM-RP Failover—First Hop Router
Impact—Supervisor 12
Pass
Auto PIM-RP Failover—First Hop Router
Impact—Supervisor 22
Pass
Auto PIM-RP Failover—Traffic Impact—Supervisor
22
Pass
Static PIM-RP Failover—Supervisor 11
Pass
Static PIM-RP Failover—Supervisor 22—RP Impact
Pass
Static PIM-RP Failover—Supervisor 22—First Hop
Router Impact
Pass
Static PIM-RP Failover—Supervisor 22—Traffic
Impact
Pass
Basic IGMP Functionality
Pass
IGMP Join/Leave Functionality
Pass
Multicast Stub and Non-Reverse Path Forwarding Rate Pass
Limiting—Supervisor 1
Multicast Stub and Non-Reverse Path Forwarding Rate Pass
Limiting—Supervisor 2
Layer 2 GEC Failover—SH1-110 to Dista-2
Pass
Layer 2 GEC Failover—SH1-108 to Dista-1
Pass
Layer 2 GEC Failover—SH1-114 to Dista-1
Pass
Layer 2 GEC Failover—SH1-106 to Dista-2
Pass
Layer 2 GEC Failover—SH1-102 to Dista-1
Pass
Layer 3 GEC Failover—SH1-104 to SH1-110
Pass
Layer 3 GEC Failover—SH1-104 to SH1-109
Pass
Layer 3 GEC Failover—SH1-104 to SH1-108
Pass
Layer 3 GEC Failover—SH1-104 to SH1-107
Pass
Layer 3 GEC Failover—SH1-100 to SH1-104
Pass
Layer 3 GEC Failover—SH1-100 to SH1-113
Pass
Layer 3 GEC Failover—SH1-100 to SH1-106
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
19
Test Results Summary
Table 1
Safe Harbor Test Results Summary (continued)
Test Case
Feature Set
Tests
Results
Layer 3
Routing
IP Multicast, page 58
Layer 3 GEC Failover—SH1-100 to SH1-105
Pass
Layer 3 GEC Failover—SH1-100 to SH1-102
Pass
Layer 3 GEC Failover—SH1-100 to SH1-101
Pass
Layer 3 GEC Failover—SH1-100 to SH1-97
Pass
Switch Fabric Module Failover—Supervisor 22
Pass
GEM Failover—Supervisor 11 as First Hop Router
Pass
GEM Failover—Supervisor 11 as Last Hop Router
Pass
GEM Failover—Supervisor 11 with Directly
Connected Layer 3 Interface
Pass
GEM Failover—Supervisor 22 as First Hop Router
Pass
GEM Failover—Supervisor 22 as Last Hop Router
Pass
GEM Failover—Supervisor 22 as Static RP
Pass
GEM Failover—Supervisor 22 as Auto RP
Pass
GEM Failover—Supervisor 22 with Directly
Connected Layer 3 Interface
Pass
Protocol Independent Module-Designated Router
Failover—Supervisor 11
Pass
Protocol Independent Module-Designated Router
Failover—Supervisor 22
Pass
Auto PIM-RP Failover—Supervisor 22—RP Impact
CSCea21798
CEF Packet Switching
Pass
CEF Table Entries
Pass
CEF Load-Balance—Many to One
Pass
Cisco Express Forwarding, page 129
CEF Load-Balance—Many to Many with Polarization Pass
Open Shortest Path First, page 138
Border Gateway Protocol, page 146
OSPF Autocost
Pass
OSPF Passive Interface
Pass
OSPF Filtering
Pass
Redistribute EIGRP into OSPF
Pass
OSPF Topology Database Verification
Pass
Add 120,000 Routes
Pass
Redistributing OSPF into BGP
Pass
Redistributing EIGRP into BGP
Pass
Redistributing OSPF and EIGRP into BGP
Pass
BGP Neighbor Flap
Pass
BGP Route Flap—With Dampening
Pass
BGP Route Flap—No Dampening
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
20
Test Results Summary
Table 1
Safe Harbor Test Results Summary (continued)
Test Case
Feature Set
Tests
Results
Layer 3
Routing
Hot Standby Router Protocol,
page 157
HSRP Failover with Default Timers—Supervisor 11
Pass
HSRP Failover with Default Timers—Supervisor
22—Compact Switching Mode
Pass
HSRP Failover with Default Timers—Supervisor
22—Switching in Truncated Mode
Pass
HSRP Failover with Fast Timers—Supervisor 11
Pass
HSRP Failover with Fast Timers—Supervisor 22
Pass
Impact of HSRP Traffic on CPU
Pass
Maximum HSRP Group Limit
Pass
GE Module Failover with Attached HSRP Groups
Pass
Enhanced Interior Gateway Routing
Protocol, page 170
EIGRP Summarization
Pass
Redistribute OSPF into EIGRP
Pass
Simple Network Management
Protocol, page 174
Basic Functionality Shut/No Shut
Interface—Supervisor 11
Pass
Basic Functionality Shut/No Shut
Interface—Supervisor 22
Pass
Protos Negative Testing
Pass
Verify User Authentication—Supervisor 11
Pass
Verify User Authentication—Supervisor 22
Pass
DHCP Broadcast Forwarding—Supervisor 11
Pass
DHCP Broadcast Forwarding—Supervisor 22
Pass
SPAN Basic Functionality
Pass
Network
Management
TACACS, page 177
Miscellaneous Dynamic Host Control Protocol,
Features
page 180
SPAN, page 183
Large Access Control Lists, page 185 ACL 110
Pass
ACL 131
Pass
Show-All Script with Relogin via Telnet
Pass
Show-All Script with Relogin via SSH
CSCec56837
Static NAT Using 2 Hosts
Pass
Static NAT Using 40 Hosts
Pass
Extended Static NAT Using 40 Hosts
Pass
Static NAT Using 2 Networks
Pass
Static Inside Dynamic Outside
Pass
Dynamic Inside Static Outside
Pass
NAT Addition and Removal of NAT Statements
Pass
Overnight Static NAT Using 40 Hosts
Pass
Static Inside/Random Outside with 40 Hosts
Pass
CLI Parser Testing, page 187
Network Address Translation,
page 189
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
21
Test Results Summary
Table 1
Test Case
Safe Harbor Test Results Summary (continued)
Feature Set
Tests
Results
NTP Basic Functionality—Supervisor 1
Pass
NTP Basic Functionality—Supervisor 2
Pass
NTP Server Failover—Supervisor 1 and 2
Pass
Syslog Basic Functionality—Supervisor 1
Pass
Syslog Basic Functionality—Supervisor 2
Pass
User Datagram Protocol Broadcast
Flooding, page 204
UDP Broadcast Flooding
Pass
System Upgrade, page 206
System Upgrade—12.1(8b)E15 to
12.1(13)E11—Supervisor 11
CSCdv26643
System Upgrade—12.1(8b)E15 to
12.1(13)E11—Supervisor 12
CSCdv26643
System Upgrade—12.1(8b)E15 to
12.1(13)E11—Supervisor 22
CSCdv26643
System Upgrade—12.1(13)E6 to
12.1(13)E11—Supervisor 11
Pass
System Upgrade—12.1(13)E6 to
12.1(13)E11—Supervisor 22
Pass
System Upgrade—12.1(13)E6 to
12.1(13)E11—Supervisor 22
Pass
SSH Server Vulnerability
Pass
Miscellaneous Network Time Protocol, page 199
Features
Syslog, page 202
Secure Shell, page 212
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
22
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(13)E11 testing. Table 3 lists
DDTS and descriptions encountered during Cisco Native IOS Release 12.1(13)E11 testing.
Table 2
DDTS
Summary of DDTS Filed During Cisco Safe Harbor Native IOS 12.1(13)E11 Testing
Description
CSCec37303 IP traffic incorrectly blocked when ACL-matching traffic hw-switched
CSCec56837 13E11: parser: %SYS-6-BLKINFO: 0x63E2037C poison over BLOCKMAGIC
CSCec58642 13E11: Spurious access: Traceback in pm_fc_print_fc_of_idb
Table 3
DDTS
Summary of DDTS Encountered During Cisco Safe Harbor Native IOS 12.1(13)E11 Testing
Description
CSCdx48854 PIM joins continue after OIL is null
CSCea21798 Packet loadbalancing is inconsistent between 12.1E and 12.2S
CSCea10930 Const2: spurious mem access in mlsm_proc_ipnat_mapping_change+0x1bc
CSCdv26643 herschel-Seaquest:traceback at Icc_card_restart by reload command
CSCdz30906 const2:at non-DR (S,G) stuck in registering (data-header)
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
23
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:
•
Memory Leaks, page 24
•
Hardware Redundancy, page 26
•
Layer 2 Features, page 34
•
Layer 3 Routing, page 58
•
Network Management, page 174
•
Miscellaneous Features, page 180
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 Leaks
Testing for memory leaks occurred each evening of a regular workday. The last regular test of the day
that was performed was repeated throughout the night, with the memory being recorded for each device
in the network. The duration of each memory leak test was 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 test was performed:
•
Multicast Flap Memory Leak, page 24
Multicast Flap Memory Leak
This test tracked the effects on memory utilization of the continuous addition and removal of multicast
routes (mroutes) on a given device. Three sets of multicast traffic were used, one for each platform:
Supervisor 11, Supervisor 12, and Supervisor 22. In each case, a Layer 2 switch is the first hop device.
For the 500 groups 239.100.[1,11].[1-250], SH1-114 and SH1-113 are PIM neighbors on the traffic
source VLAN. SH1-114 is the first hop router and maintains (*, G) and (S, G) entries for each of the 250
groups. An automated script shuts down the Layer 2 link (portchannel 10) to the Layer 2 switch (Dista-1)
for a period of 15 minutes. SH1-113 becomes the first hop router at this point, building (*, G) and (S, G)
states for the 250 groups. The 15-minute time period is long enough for all group mroute states to time
out and be deleted on SH1-114. After 15 minutes, the Layer 2 link is brought back up, SH1-114 will
rebuild the mroute entries for each group. This link will remain up for another 15 minutes, long enough
for all entries on SH1-113 to time out and be deleted.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
24
Memory Leaks
SH1-114 and SH1-113 are Supervisor 1/MSFC 2 devices. The same pattern also was created for
Supervisor 11 and Supervisor 22 devices. SH1-106 and SH1-105 were the Supervisor 11 first hop routers
for groups 239.100.[2,12].[1-250]. SH1-110 and SH1-109 were the Supervisor 22 first hop routers for
groups 239.100.[3,13].[1-250].
At the same time as the mroute entries are being created or deleted on the three pairs of devices, the
following action is taking place on other devices in the network:
•
SH1-102 connectivity is being broken to the rest of the network, causing any traffic to go through
SH1-101.
•
SH1-100 connectivity is being broken to the rest of the network, causing SH1-99 to become the
primary PIM-RP for 1500 plus mcast groups.
•
A clear ip mroute * command is being issued on SH1-104 every 6 minutes.
•
A clear ip route * command is being issued on SH1-98 every 5 minutes.
•
A clear ip route * command is being issued on SH1-101 every 5 minutes.
•
Fast Ethernet interface 8/14 on SH1-97 is being flapped every 10 minutes, removing the 5000 OSPF
routes being supplied by the Pagent test tool.
•
BGP peer flapping is configured to run as it did in the BGP Neighbor Flap test.
A summary of the plan of action for this test is here:
mem_leaks/mcast_flap_mem/plan_of_action.txt
Devices under test: SH1-97, SH1-98, SH1-99, SH1-100, SH1-101, SH1-102, SH1-103, SH1-104,
SH1-105, SH1-106, SH1-107, SH1-108, SH1-109, SH1-110, SH1-113, SH1-114
Test Procedure
The procedure used to perform the Multicast Flap Memory Leak test follows:
Step 1
Use the appropriate script to gather preliminary logging and version information. This script will also
begin the SNMP polling for CPU and memory usage for all Cisco Native IOS devices in the SH1
network.
Step 2
Gather an initial snapshot of all memory processes for all devices in the network.
Step 3
Alter the IXIA stream/receiver configuration so that the three sources are sending to 250 groups, from a
single IP source address, and the receivers are joining 250 groups.
Step 4
Begin the flap test. Let this test run over a weekend, at the least.
Step 5
Stop the flap test.
Step 6
Gather a final snapshot of all memory processes for all devices in the network.
Step 7
Verify that there has been no memory degradation from the initial snapshot to the final snapshot.
Step 8
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 9
Display the results of the memory monitoring of the devices in the SH1 network.
Note
The polling occurred over a 36-hour period.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
25
Hardware Redundancy
Expected Results
•
We expect the Memory Free and Memory Largest Free values to trend steady over the duration of
the test for each of the respective devices.
•
No diminishing trend was detected in memory for any of the devices in the network during the 36
hours that the procedure was in effect. This time period allowed for mroutes to be removed and
added about 60 times, and the OSPF routes to be removed and added about 120 times.
Results
Table 4 shows the Multicast Flap Memory Leak test results.
Table 4
Multicast Flap Memory Leak Test Results
Tests
Results
Multicast Flap Memory Leak Pass with exception CSCdz30906, and CSCea21798
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.
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.
The following tests were performed:
•
Switch Fabric Module Failover, page 26
•
Supervisor 1 Failover, page 28
•
Supervisor 2 Failover, page 29
•
Power Supply Failure—Supervisor 1, page 30
•
Power Supply Failure—Supervisor 2, page 31
•
RPR+—Supervisor Hot-Insert, page 33
Switch Fabric Module Failover
This test verified multicast functionality during Switch Fabric Module (SFM) failover. Unicast traffic
was sourced from IXIA and transits through SH1-102. The traffic was switched using the crossbar fabric.
This test performed a series of resets on the active SFM and measure traffic loss at each iteration.
In several of the following steps, verification that the traffic was using the SFM was requested. Examine
how the Medusa ASIC was handling traffic. The Medusa ASIC interfaces were between the line card
local bus and the backplane of the Catalyst 6500. If traffic was using the SFM (no legacy, or
nonfabric-enabled cards present), the Medusa mode was “Compact” for all line cards, indicating that it
was sending a compact header on the backplane for the switching decision
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
26
Hardware Redundancy
Note
Any WS-X6816 modules were always in "Compact" mode, because they were 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_chapter09
186a008007fb2a.html
Goals
•
Verify that the router is using the crossbar fabric to switch the traffic prior to SFM failover.
•
Verify that the router is using the crossbar fabric to switch the traffic after the SFM failover.
•
Verify that failover times are within acceptable parameters.
Primary Devices Used
•
SH1-102: Supervisor 22; first hop router for unicast test traffic stream
Primary IXIA Ports Used
•
2/8, 5/1
Test Procedure
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.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-102 is receiving unicast traffic on portchannel 10 and sending the traffic on portchannels
15 and 115.
Step 5
Verify that portchannels 10, 15, and 115 consist of interfaces on fabric-enabled line cards.
Step 6
Verify that all fabric-enabled modules are using the crossbar fabric to switch the traffic.
Step 7
Start the test script that will fail over the active fabric module on SH1-102 50 times while running traffic.
Step 8
Analyze the results from the script and verify that failover times are within tolerance.
Step 9
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 10
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect failovers to occur within an acceptable time and minimal traffic loss due to fabric failure.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
27
Hardware Redundancy
Results
•
The mean time for the standby fabric module to become active was 9.2 milliseconds, which is
acceptable.
•
The mean time for the failed fabric module to come back online in standby mode was 25.9 sec,
which is acceptable.
•
The mean time for which traffic was interrupted due to the fabric module failover was 0.629 sec,
which is acceptable.
•
There was no unacceptable impact on either the CPU or memory during this test.
Table 5 shows the Switch Fabric Module Failover test results.
Table 5
Switch Fabric Module Failover Test Results
Tests
Results
Switch Fabric Module Failover
Pass
Supervisor 1 Failover
This test verified the proper operation of redundant supervisors, during a series of 20 continual resets.
This test verified that the box failed between the supervisors as designed, recovers, and forwarded traffic.
This test was further designed to verify that failure operations are within the design guidelines for the
applicable hardware and software versions under test. Although this test measured time, it was by no
means a measure of the speed at which failover can take place (which was dependent upon the
configuration and line cards in the system).
Supervisor Engines 1 was covered in this test.
A traffic stream was sent from Dista-1 to Dista-2 a fixed rate. The amount of traffic loss during device
resets was used to determine the recovery time (failover time).
Device under test: SH1-107
Test Procedure
The procedure used to perform the Supervisor 1 Failover test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Display 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 5
Shut down interface portchannel 10 on device SH1-108. This will verify that the test traffic goes through
SH1-107 to get to its destination.
Step 6
Begin the IXIA background unicast traffic stream number 1. This will send traffic at 10,000 pps from
Dista-1 to SH1-99. Send a 5-minute burst of traffic.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
28
Hardware Redundancy
Step 7
Perform a forced switchover on SH1-107.
Step 8
Display how much traffic was received out of 3 million packets sent. Measure the time that the switch
was down.
Step 9
Repeat the switchover sequence four times, each time gathering statistics on traffic loss.
Step 10
Display the average time it took for the device to switch over, over the five iterations.
Step 11
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 12
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
Note
We expect all resets of the supervisor to occur within the 1 to 2 minutes.
This time differs from the results in 12.1(8b)E15 testing as RPR+ is now the redundancy feature,
allowing for faster switchover times.
•
We expect supervisors to come back online without any manual intervention.
•
The average down time from the switchover is 1 minute 15 sec over 5 runs.
Results
Table 6 shows the Supervisor 1 Failover test results.
Table 6
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.
This test verified that the box fails between the supervisors as designed, recovers, and forwards traffic.
This test was further designed to verify that failure operations are within the design guidelines for the
applicable hardware and software versions under test. While this test measures time, it was by no means
a measure of the speed at which failover can take place (as this was dependent upon the configuration
and line cards in the system).
Supervisor Engines 2 are covered in this test.
A traffic stream was sent from Dista-2 to Dista-1 a a fixed rate. The amount of traffic loss during device
resets was used to determine the recovery time (failover time).
Device under test: SH1-110
Test Procedure
The procedure used to perform the Supervisor 2 Failover test follows:
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
29
Hardware Redundancy
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Display 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 5
Shut down interface portchannel20 on device SH1-109. This will verify that the test traffic goes through
SH1-110 to get to its destination.
Step 6
Begin the IXIA background unicast traffic stream number 3. This will send traffic at 10,000 pps from
Dista-2 to Dista-1. Send a 5-minute burst of traffic.
Step 7
Perform a redundancy force-switchover on SH1-110.
Step 8
Display how much traffic was received out of 3 million packets sent. Measure the time that the switch
was down.
Step 9
Repeat the switchover sequence four times, each time gathering statistics on traffic loss.
Step 10
Display the average time it took for the device to switch over, over the five iterations.
Step 11
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 12
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect all resets of the supervisor to occur within 1 to 2 minutes.
•
We expect supervisors to come back online without manual intervention.
Results
Table 7 shows the Supervisor 2 Failover test results.
Table 7
Supervisor 1 Failover Test Results
Tests
Results
Supervisor 2 Failover
Pass
Power Supply Failure—Supervisor 1
This test verified the failure of a power supply in a Supervisor 1-based system. The power supply was
failed via removal of the power module.
Test Procedure
The procedure used to perform the Power Supply Failure—Supervisor 1 test follows:
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
30
Hardware Redundancy
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the power supplies of SH1-106 are operating in redundant mode and that the capacity of each
individual power supply is sufficient to meet the needs of the device.
Step 5
Begin sending a test traffic stream through SH1-106. In this case it will be background unicast stream
number 5.
Step 6
Simulate a power supply failure.
Step 7
Verify that the system is still operational with only one power supply.
Step 8
Measure any traffic loss that occurred as a result of the simulated power supply failure.
Step 9
Begin sending a test traffic stream through SH1-106.
Step 10
Re-insert the power supply in SH1-106.
Step 11
Verify that the second power supply has come back online.
Step 12
Measure any traffic loss that occurred as a result of the power supply reinsertion.
Step 13
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 14
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect no line card failures due to the removal or insertion of the power supply.
•
We expect no packet loss due to the removal or insertion of the power supply.
Results
Table 8 shows the Power Supply Failure—Supervisor 1 test results.
Table 8
Power Supply Failure—Supervisor 1 Test Results
Tests
Results
Power Supply Failure—Supervisor 1
Pass
Power Supply Failure—Supervisor 2
This test verified the failure of a power supply in a Supervisor 2-based system. The power supply was
failed via removal of the power module.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
31
Hardware Redundancy
Test Procedure
The procedure used to perform the Power Supply Failure—Supervisor 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the power supplies of SH1-101 are operating in redundant mode and that the capacity of each
individual power supply is sufficient to meet the needs of the device.
Step 5
Begin sending a test traffic stream through SH1-101. In this case it will be multicast test traffic stream
A, for which SH1-101 has a directly connected Layer 3 receiver.
Step 6
Simulate a power supply failure.
Step 7
Verify that the system is still operational with only one power supply.
Step 8
Measure any traffic loss that occurred as a result of the simulated power supply failure.
Step 9
Begin sending a test traffic stream through SH1-101.
Step 10
Re-insert the power supply in SH1-101.
Step 11
Verify that the second power supply has come back online.
Step 12
Measure any traffic loss that occurred as a result of the power supply reinsertion.
Step 13
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 14
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect no line card failures due to the removal or insertion of the power supply.
•
We expect no packet loss due to the removal or insertion of the power supply.
Results
Table 9 shows the Power Supply Failure—Supervisor 2 test results.
Table 9
Power Supply Failure—Supervisor 2 Test Results
Tests
Results
Power Supply Failure—Supervisor 2
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
32
Hardware Redundancy
RPR+—Supervisor Hot-Insert
This test verified the ability of an unconfigured supervisor to be inserted as redundant into a device and
to be loaded with the system configuration.
Test Procedure
The procedure used to perform the RPR+—Supervisor Hot-Insert test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Remove the redundant supervisor of device SH1-110.
Step 5
Perform a write erase/reload sequence on SH1-110 to erase any configuration.
Step 6
Remove the unconfigured supervisor and reinsert the configured supervisor.
Step 7
Hot-insert the unconfigured supervisor.
Step 8
Verify that the new supervisor comes online. Force a switchover to verify that the redundant supervisor
has a full configuration.
The redundant supervisor comes online in active state with a full configuration.
Step 9
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 10
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the blank (unconfigured) supervisor should come online and obtain a copy of the
configuration from the active supervisor.
•
We expect the standby supervisor will have the correct configuration in the event it becomes active.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 10 shows the RPR+—Supervisor Hot-Insert test results.
Table 10
RPR+—Supervisor Hot-Insert Test Results
Tests
Results
RPR+—Supervisor Hot-Insert
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
33
Layer 2 Features
Layer 2 Features
Layer 2 feature testing for Safe Harbor consists of the following tests:
•
Unidirectional Link Detection—Aggressive Mode, page 34
•
Trunking, page 37
•
Port Aggregation Protocol (Channeling), page 40
•
VLAN Trunking Protocol, page 56
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 was 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 was received. However, UDLD goes into an undetermined state.
The lowest value of a UDLD-AM message interval can be only 7 sec, and the hold-down time can be 21
sec.
Note
Since the lowest value of UDLD-AM message interval can only be 7 sec, and Holddown time can be
21 sec. While by default, HSRP hello timer is 3 sec. and holddown 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 shut down the unidirectional port, the HSRP will stay up stable.
Note
The lowest value of UDLD-AM message interval can be only 7 sec, and the hold-down time can be
21 sec. By default, EIGRP hello timer was 5 sec and hold-down timer was 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 Layer 3 switches, the interface shows the
UDLD message interval was 7 sec, which was actually "running message interval." Once the UDLD
neighbor was established, the message interval changed to 60 sec. Refer to CSCdv74001, which was
integrated in Herschel 8EX and will be in Cisco IOS Release 13 E but not in Cisco IOS Release 8 E.
For an explanation of UDLD, refer to UDLD Q&A Reference.
The following tests were performed:
•
Basic UDLD on Layer 2 Link, page 35
•
Basic UDLD on Layer 3 Link, page 36
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
34
Layer 2 Features
Basic UDLD on Layer 2 Link
This test created a unidirectional link between DUT SH1-109 and Dista-2. Console messages were
logged during the mock failure, and port states were recorded.
Device under test: SH1-109
Procedure
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.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that UDLD is configured globally on the DUT and that UDLD AM 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. Verify the interface state of g7/3 on the DUT.
Step 6
Reconnect the transmit fiber. Record any log messages on the DUT and verify the interface state. Issue
the udld reset command on the DUT, if the interface g7/3 does not return to up/up state.
Note
Step 7
The udld reset command is needed because automatic error-recovery for UDLD is no longer
configured. This feature would only attempt to recover a port in UDLD state only one time. The
timing of the recovery attempt could not be synchronized with our test.
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect UDLD to err-disable the port when the fiber is pulled.
•
We expect the port to recover when fiber is plugged back in.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 11 shows the Basic UDLD on Layer 2 Link test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
35
Layer 2 Features
Table 11
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 and interface states
were logged throughout the process.
Devices under test: SH1-104 and SH1-109
Test Procedure
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.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that UDLD is configured globally on both DUTs and that UDLD AM is configured locally on the
interfaces g4/15 of SH1-104 and g3/5 of SH1-109. Also verify terminal monitoring is active on this
session.
Step 5
Once it has been verified that the interfaces connecting the DUTs are in up/up state, pull the transmit
side of the g3/5 interface on SH1-109. Record logging messages from both DUTs and their interface
states.
Step 6
Reconnect the fiber pulled out in Step 5. Use the udld reset command to verify that the interfaces are
again up/up.
Note
The udld reset command is needed because automatic error-recovery for UDLD is no longer
configured. This feature would attempt to recover a port in UDLD state only one time. The timing of
the recovery attempt could not be synchronized with our test.
Step 7
Pull out the receive side of the g3/5 interface on SH1-109. Record all messages and the interface states
from both DUTs.
Step 8
Reconnect the fiber pulled out in Step 7. Use the udld reset command to verify the interfaces are again
up/up (see note in Step 6).
Step 9
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 10
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
36
Layer 2 Features
Expected Results
•
We expect UDLD to err-disable the port when the fiber is pulled.
•
We expect the port to recover when fiber is plugged back in.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 12 shows the Basic UDLD on Layer 3 Link test results.
Table 12
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 13 lists and describes the five modes of trunking on Cisco
switches.
Table 13
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 tests were performed:
•
Supervisor 1 Configuration and Failure Recovery, page 38
•
Supervisor 2 Configuration and Failure Recovery, page 39
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
37
Layer 2 Features
Supervisor 1 Configuration and Failure Recovery
This test verified that the configuration and recovery of both static and dynamically formed trunks was
tested. Trunk links between SH1-107 and dista-1 were configured, then failed and recovered to verify
that trunking was reestablished.
Device under test: SH1-107
Test Procedure
The procedure used to perform the Supervisor 1 Configuration and Failure Recovery test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
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 the ports begin trunking again.
Step 6
Fail one of the trunking links on SH1-107 and verify it is down.
Step 7
Bring the port back up, and verify the port begins trunking again.
Step 8
Change the configuration on both sides back to static trunking, and verify the ports begin trunking again.
Note
You need not explicitly "set trunk 2/1 on" because the port channel will change it automatically after
trunk 1/1 is changed.
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 the port begins trunking again.
Step 11
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 12
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect the DUT to be able to trunk in both static and dynamic mode.
•
We expect the trunk port to recover from a port failure.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 14 shows the Supervisor 1 Configuration and Failure Recovery test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
38
Layer 2 Features
Table 14
Supervisor 1 Configuration and Failure Recovery Test Results
Tests
Results
Supervisor 1 Configuration and Failure Recovery Pass
Supervisor 2 Configuration and Failure Recovery
This test verified that the configuration of both static and dynamically formed trunks was tested. It tested
the recovery of both static and dynamic trunks. Trunk links between SH1-109 and dista-2 were
configured, then failed and recovered to verify that trunking was reestablished.
Device under test: SH1-109
Test Procedure
The procedure used to perform the Supervisor 2 Configuration and Failure Recovery test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
The standard configuration for this link in the Safe Harbor network is both sides configured for dynamic
trunking. Verify 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 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 the port begins trunking again.
Step 8
Change the configuration on both sides back to dynamic trunking, and verify 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 the port begins trunking again.
Step 11
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 12
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect the DUT to be able to trunk in both static and dynamic mode.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
39
Layer 2 Features
•
We expect the trunk port to recover from a port failure.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 15 shows the Supervisor 2 Configuration and Failure Recovery test results.
Table 15
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 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 has 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, thus preventing out-of-order packet delivery.
The following tests were performed:
•
Basic Layer 2 Channeling Configuration, page 40
•
Basic Layer 3 Channeling Configuration, page 42
•
Layer 2 EtherChannel Load Balance, page 44
•
Layer 3 EtherChannel Load Balance, page 45
•
Layer 2 GEC Failure and Recovery—Supervisor 1, page 47
•
Layer 3 GEC Failure and Recovery—Supervisor 1, page 48
•
Layer 2 GEC Failure and Recovery—Supervisor 2, page 50
•
Layer 3 GEC Failure and Recovery—Supervisor 2, page 51
•
Gigabit Ethernet Module Reset—Supervisor 1, page 53
•
Gigabit Ethernet Module Reset—Supervisor 2, page 54
Basic Layer 2 Channeling Configuration
In Cisco Native IOS, a portchannel interface is created, and then individual interfaces were joined to that
portchannel interface. The configuration of the individual interfaces determines whether the channel is
static or dynamic.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
40
Layer 2 Features
This test verified the basic aspects of Layer 2 PAgP configuration to verify that the basic functionality
worked correctly. For this test, a set of links between SH1-107 and Dista-1 were given a configuration
for static channeling. Dynamic channeling was tested in the bundling of links between SH1-110 and
Dista-2.
Figure 13 shows the relevant topology configuration.
Figure 13
Basic Layer 2 Channeling Configuration Topology
Devices under test: SH1-107, SH1-110
Test Procedure
The procedure used to perform the Basic Layer 2 Channeling Configuration test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the channel between devices SH1-107 and Dista-1 is configured as a static channel.
The ports that comprise the portchannel on Dista-1 (1/1 and 2/1) should show channel mode as on. The
individual interfaces in portchannel 10 on SH1-107 should show "On" under EC state. The status of the
ports and channel should be "connected" for both Dista-1 and SH1-107.
Step 5
Verify that the channel between devices SH1-110 and Dista-1 is configured as a dynamic channel.
The ports that comprise the portchannel on Dista-2 (3/2-3/5) should show channel mode as auto. The
individual interfaces in portchannel 20 on SH1-110 should show "Desirable" under EC state. The status
of the ports and channel should be "connected" for both Dista-2 and SH1-110.
Step 6
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 7
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
41
Layer 2 Features
Expected Results
•
We expect the Layer 2 channels to form with their respective static and dynamic configurations.
Results
Table 16 shows the Basic Layer 2 Channeling Configuration test results.
Table 16
Basic Layer 2 Channeling Configuration Test Results
Tests
Results
Basic Layer 2 Channeling Configuration
Pass
Basic Layer 3 Channeling Configuration
This test verified Layer 3 portchannel 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 17 maps the six steps
to the combination covered.
Devices under test: SH1-103, SH1-99, SH1-104, SH1-107, SH1-109, SH1-110
Table 17
Basic Layer 3 Channeling Configuration Matrix
Devices dCEF?
Channeling?
103-99
Yes
Static
104-99
Yes
Dynamic
103-109
Mixed Static
103-110
Mixed Dynamic
103 -107
No
Static
104-107
No
Dynamic
Figure 14 and Figure 15 shows relevant topology configurations.
Figure 14
Basic Layer 3 Channeling Configuration Topology
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
42
Layer 2 Features
Figure 15
Basic Layer 3 Channeling Configuration Topology
Test Procedure
The procedure used to perform the Basic Layer 3 Channeling Configuration test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
The portchannel (4 ports) between SH1-103 (Po16) and SH1-99 (Po16) resides on dCEF-only modules.
Step 5
Step 6
Step 7
•
Verify that it is configured for static channeling and that it is functioning correctly.
•
Verify that the status for Po16 on both SH1-99 and SH1-103 is “connected.”
•
Verify that the EC state for Po16 on both SH1-99 and SH1-103 is "On."
The portchannel (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.
•
Verify that the status for Po17 on both SH1-99 and SH1-104 is "connected."
•
Verify that the EC state for Po17 on SH1-99 is "Desirable-sl."
•
Verify that the EC state for Po17 on SH1-104 is "Automatic-sl."
The portchannel (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.
•
Verify that the status for Po70 on both SH1-109 and SH1-103 is "connected."
•
Verify that the EC state for Po70 on both SH1-109 and SH1-103 is "On."
The portchannel (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.
•
Verify that the status for Po71 on both SH1-110 and SH1-103 is "connected."
•
Verify that the EC state for Po71 on SH1-110 is "Automatic-sl."
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
43
Layer 2 Features
•
Step 8
Step 9
Step 10
Verify that the EC state for Po71 on SH1-103 is "Desirable-sl."
The portchannel (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.
•
Verify that the status for Po68 on both SH1-107 and SH1-103 is "connected."
•
Verify that the EC state for Po68 on both SH1-107 and SH1-103 is "On."
The portchannel (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.
•
Verify that the status for Po68 on SH1-104 and Po168 on SH1-107 is "connected."
•
Verify that the EC state for Po68 on SH1-104 is "Desirable-sl."
•
Verify that the EC state for Po168 on SH1-107 is "Automatic-sl."
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the portchannels to form correctly in each configuration and line card combination.
Results
Table 18 shows the Basic Layer 3 Channeling Configuration test results.
Table 18
Basic Layer 3 Channeling Configuration Test Results
Tests
Results
Basic Layer 3 Channeling Configuration
Pass
Layer 2 EtherChannel Load Balance
This test verified that load distribution took place across the individual interfaces in a Layer 2
EtherChannel. An IXIA traffic stream was generated, sending traffic from 20 emulated sources to a
single destination. This traffic was sent from one side of the SH1 network to the other, passing through
the Layer 2 GEC between SH1-110 and Dista-2 and the Layer 2 GEC between SH1-114 and Dista-1.
Load distribution was verified by examining the traffic statistics on individual interfaces. All traffic sent
from the multiple sources was received on the other end of the network, though balanced across many
interfaces.
Traffic (300,000 packets) was sent at 1000 pps from IXIA port 5/1 to IXIA port 3/4. SH1-114 was a
Supervisor 1 and SH1-110 was a Supervisor 2.
Devices under test: SH1-110, SH1-114
Test Procedure
The procedure used to perform the Layer 2 EtherChannel Load Balance test follows:
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
44
Layer 2 Features
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that portchannel 20 on SH1-110 and portchannel 10 on SH1-114 are Layer 2 EtherChannels.
Step 5
Verify that the load-balance algorithm on the SP indicates that traffic should be passed out all four
interfaces of portchannel 10 on SH1-114.
Step 6
Clear the counters on SH1-110 and SH1-114.
Step 7
Make certain all other background unicast traffic is stopped. Begin the test traffic stream of 300,000
packets.
Step 8
After the stream has finished sending, verify that all the interfaces in portchannels 20 and 10 on SH1-110
and SH1-114, respectively, have passed some traffic.
Step 9
Verify that all traffic that was sent was received.
Step 10
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that all traffic sent from the multiple sources to be received on the other end of the
network, though balanced across many interfaces.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 19 shows the Layer 2 EtherChannel Load Balance test results.
Table 19
Layer 2 EtherChannel Load Balance Test Results
Tests
Results
Layer 2 EtherChannel Load Balance
Pass
Layer 3 EtherChannel Load Balance
This test verified that load distribution took place across the individual interfaces in a Layer 3
EtherChannel. Two IXIA traffic streams were used, each sending traffic from 20 emulated sources to a
single destination. The first traffic stream used has SH1-110 as the first hop router. SH1-110 should
balance the traffic to the next hop routers over the interfaces of portchannels 71 and 171. The second
traffic stream used has SH1-114 as the first hop router. SH1-114 should balance the traffic to the next
hop routers over the interfaces of portchannels 65 and 165. All traffic sent from the multiple sources was
received on the other end of the network, though balanced across many interfaces.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
45
Layer 2 Features
Traffic (300,000 packets) was sent at 1000 pps from IXIA port 5/1 to IXIA port 3/4 (first stream) and
from IXIA port 5/4 to IXIA port 5/1. SH1-114 is a Supervisor 1 and SH1-110 is a Supervisor 2.
Devices under test: SH1-110, SH1-114
Test Procedure
The procedure used to perform the Layer 3 EtherChannel Load Balance test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that portchannels 71 and 171 on SH1-110 are Layer 3 EtherChannels.
Step 5
Verify that SH1-110 knows multiple paths to the destination.
Step 6
Verify that portchannels 65 and 165 on SH1-114 are Layer 3 EtherChannels.
Step 7
Verify that SH1-114 knows multiple paths to the destination.
Step 8
Clear the counters on SH1-110 and SH1-114.
Step 9
Begin the test traffic streams of 300,000 packets.
Step 10
After the stream has been sent, verify that all the interfaces in portchannels 20 and 10 on SH1-110 and
SH1-114, respectively, have passed some traffic.
Step 11
Verify that all traffic that was sent was received.
Step 12
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 13
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect SH1-110 to balance the traffic to the next hop routers over the interfaces of
portchannels 71 and 171. The second traffic stream used has SH1-114 as the first hop router. We
expect SH1-114 to balance the traffic to the next hop routers over the interfaces of portchannels 65
and 165. We expect all traffic sent from the multiple sources to be received on the other end of the
network, though balanced across many interfaces.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 20 shows the Layer 3 EtherChannel Load Balance test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
46
Layer 2 Features
Table 20
Layer 3 EtherChannel Load Balance Test Results
Tests
Results
Layer 3 EtherChannel Load Balance
Pass
Layer 2 GEC Failure and Recovery—Supervisor 1
This test verified the ability of Layer 2 EtherChannels to handle software cycling. IXIA unicast traffic
was sent from 20 incrementing IP addresses to a single IP destination. The first hop router is SH1-108.
Gigabit Ethernet interfaces 4/1 through 4, bundled into Layer 2 EtherChannel portchannel 10, connect
SH1-108 to Dista-1. The next hop router is out Layer 3 interface portchannel 69, which consists of
bundled Gigabit Ethernet interfaces 3/1 through 4. First, portchannel 10 was shut down and brought back
up. Portchannel 69 was brought down and back up. In each case it is verified that the Layer 2 and Layer
3 EtherChannels were reformed correctly, and that traffic passed across all the bundled interfaces.
Figure 16 shows the topology for Layer 2 GEC Failure and Recovery—Supervisor 1.
Figure 16
Layer 2 EtherChannel Failure and Recovery—Sup 1 Topology
Device under test: SH1-108
Test Procedure
The procedure used to perform the Layer 2 GEC Failure and Recovery—Supervisor 1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the traffic is being load-balanced across all the aggregated interfaces of portchannel 10 of
device SH1-108.
Step 5
Shut down interface portchannel 10 of SH1-108.
Step 6
Bring interface portchannel 10 of SH1-108 back online.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
47
Layer 2 Features
Step 7
Verify that the channel reforms correctly after the interface comes back online and that those interfaces
on module 4 that were passing traffic before are again passing traffic.
Step 8
Verify that the CBL values are all correct for the affected interfaces on all eleven VLANs that are being
trunked by portchannel 10.
Step 9
Shut down the four interfaces that make up portchannel 10.
Step 10
Bring those four interfaces back online.
Step 11
Verify that the channel reforms correctly after the interfaces comes back online and that those interfaces
on module 4 that were passing traffic before are again passing traffic.
Step 12
Verify that the CBL values are all correct for the affected interfaces on all eleven VLANs that are being
trunked by portchannel 10.
Step 13
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 14
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the interfaces on that module to be reaggregated into their respective portchannels and to
again pass traffic following the reset of the module.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 21 shows the Layer 2 GEC Failure and Recovery—Supervisor 1 test results.
Table 21
Layer 2 GEC Failure and Recovery—Supervisor 1 Test Results
Tests
Results
Layer 2 GEC Failure and Recovery—Supervisor 1 Pass
Layer 3 GEC Failure and Recovery—Supervisor 1
This test verified the ability of a Layer 3 EtherChannel to handle software cycling. IXIA unicast traffic
was sent from 20 incrementing IP addresses to a single IP destination. The first hop router is SH1-108.
Gigabit Ethernet interfaces 3/1 through 4, bundled into Layer 3 EtherChannel portchannel 69, connect
SH1-108 to SH1-104. Portchannel 69 was brought down and back up. It is verified that the Layer 3
EtherChannel is reformed correctly, and that traffic passed across all the bundled interfaces.
Figure 17 shows the topology for Layer 3 GEC Failure and Recovery—Supervisor 1.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
48
Layer 2 Features
Figure 17
Layer 3 EtherChannel Failure and Recovery—Sup 1 Topology
Device under test: SH1-108
Test Procedure
The procedure used to perform the Layer 3 GEC Failure and Recovery—Supervisor 1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the traffic is being load-balanced across all the aggregated interfaces of portchannel 10 of
device SH1-108.
Step 5
Shut down interface portchannel 69 of SH1-108.
Step 6
Bring interface portchannel 69 of SH1-108 back online.
Step 7
Verify that the channel reforms correctly after the interface comes back online and that those interfaces
on module 3 that were passing traffic before are again passing traffic.
Step 8
Shut down the four interfaces that make up portchannel 69.
Step 9
Bring those four interfaces back online.
Step 10
Verify that the channel reforms correctly after the interfaces come back online and that those interfaces
on module 3 that were passing traffic before are again passing traffic.
Step 11
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 12
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
49
Layer 2 Features
Expected Results
•
We expect the interfaces on that module to be reaggregated into their respective portchannels and to
again pass traffic following the reset of the module.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 22 shows the Layer 3 GEC Failure and Recovery—Supervisor 1 test results.
Table 22
Layer 3 GEC Failure and Recovery—Supervisor 1 Test Results
Tests
Results
Layer 3 GEC Failure and Recovery—Supervisor 1 Pass
Layer 2 GEC Failure and Recovery—Supervisor 2
This test verified the ability of Layer 2 EtherChannels to handle software cycling. IXIA unicast traffic
was sent from 20 incrementing IP addresses to a single IP destination. The first hop router is SH1-110.
Gigabit Ethernet interfaces 7/3 and 5 and Gigabit Ethernet interfaces 8/3 and 5, bundled into Layer 2
EtherChannel portchannel 20, connect SH1-110 to Dista-2. portchannel 20 was shut down and brought
back up. It is verified that the Layer 2 EtherChannel was reformed correctly, and that traffic passed across
all the bundled interfaces.
Figure 18 shows the topology for Layer 2 GEC Failure and Recovery—Supervisor 2.
Figure 18
Layer 2 EtherChannel Failure and Recovery—Sup 2 Topology
Device under test: SH1-110
Test Procedure
The procedure used to perform the Layer 2 GEC Failure and Recovery—Supervisor 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
50
Layer 2 Features
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the traffic is being load-balanced across all the aggregated interfaces of portchannel 20 of
device SH1-110.
Step 5
Shut down interface portchannel 20 of SH1-110.
Step 6
Bring interface portchannel 20 of SH1-110 back online.
Step 7
Verify that the channel reforms correctly after the interface comes back online and that those interfaces
on modules 7 and 8 that were passing traffic before are again passing traffic.
Step 8
Verify that the CBL values on the SP are all correct for the affected interfaces on all eleven VLANs that
are being trunked by portchannel 20.
Step 9
Shut down the four interfaces that make up portchannel 20.
Step 10
Bring those four interfaces back online.
Step 11
Verify that the channel reforms correctly after the interfaces comes back online and that those interfaces
on module 4 that were passing traffic before are again passing traffic.
Step 12
Verify that the CBL values on the SP are all correct for the affected interfaces on all eleven VLANs that
are being trunked by portchannel 20.
Step 13
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 14
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the interfaces on that module to be reaggregated into their respective portchannels and to
again pass traffic following the reset of the module.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 23 shows the Layer 2 GEC Failure and Recovery—Supervisor 2 test results.
Table 23
Layer 2 GEC Failure and Recovery—Supervisor 2 Test Results
Tests
Results
Layer 2 GEC Failure and Recovery—Supervisor 2 Pass
Layer 3 GEC Failure and Recovery—Supervisor 2
This test verified the ability of a Layer 3 EtherChannel to handle software cycling. IXIA unicast traffic
was sent from 20 incrementing IP addresses to a single IP destination. The first hop router is SH1-110.
Gigabit Ethernet interfaces 3/3 through 4 and Gigabit Ethernet interfaces 4/3 through 4, bundled into
Layer 3 EtherChannel portchannel 69, connect SH1-110 to SH1-104. portchannel 171 was brought down
and back up. It is verified that the Layer 3 EtherChannel was reformed correctly, and that traffic passed
across all the bundled interfaces.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
51
Layer 2 Features
Figure 19 shows the topology for Layer 3 GEC Failure and Recovery—Supervisor 2.
Figure 19
Layer 3 EtherChannel Failure and Recovery—Sup 2 Topology
Device under test: SH1-110
Test Procedure
The procedure used to perform the Layer 3 GEC Failure and Recovery—Supervisor 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the traffic is being load-balanced across all the aggregated interfaces of portchannel 171 of
device SH1-110.
Step 5
Shut down interface portchannel 171 of SH1-110.
Step 6
Bring interface portchannel 171 of SH1-110 back online.
Step 7
Verify that the channel reforms correctly after the interface comes back online and that those interfaces
on module 3 that were passing traffic before are again passing traffic.
Step 8
Shut down the four interfaces that make up portchannel 171.
Step 9
Bring those four interfaces back online.
Step 10
Verify that the channel reforms correctly after the interfaces comes back online and that those interfaces
on module 3 and 4 that were passing traffic before are again passing traffic.
Step 11
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 12
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
52
Layer 2 Features
Expected Results
•
We expect the interfaces on that module to be reaggregated into their respective portchannels and to
again pass traffic following the reset of the module.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 24 shows the Layer 3 GEC Failure and Recovery—Supervisor 2 test results.
Table 24
Layer 3 GEC Failure and Recovery—Supervisor 2Test Results
Tests
Results
Layer 3 GEC Failure and Recovery—Supervisor 2 Pass
Gigabit Ethernet Module Reset—Supervisor 1
This test verified the ability of Layer 2 and Layer 3 EtherChannels to handle module resets and failures.
IXIA unicast traffic was sent from 20 incrementing IP addresses to a single IP destination. The first hop
router was SH1-108. Gigabit Ethernet interfaces 4/1 through 4, bundled into Layer 2 EtherChannel
portchannel 10, connect SH1-108 to Dista-1. The next hop router was out Layer 3 interface portchannel
69, which consists of bundled Gigabit Ethernet interfaces 3/1 through 4. A test stream was sent first
while module 4 was reset. The same test stream was sent again; this time module 3 is reset. In each case
it was verified that the Layer 2 and Layer 3 EtherChannels were reformed correctly. Traffic loss was
measured for each case.
Figure 20 shows the topology for Gigabit Ethernet Module Reset—Supervisor 1.
Figure 20
GEM Reset—Sup 1 Topology
Device under test: SH1-108
Test Procedure
The procedure used to perform the Gigabit Ethernet Module Reset—Supervisor 1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
53
Layer 2 Features
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the traffic is being load-balanced across all the aggregated interfaces of portchannels 10 and
69 of device SH1-108.
Step 5
Start the test traffic stream, sending 300 sec worth of traffic at 1000 pps.
Step 6
Reset module 4 of SH1-108.
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
Determine the amount of traffic loss.
Step 9
Start the test traffic stream, sending 300 sec worth of traffic at 1000 pps.
Step 10
Reset module 3 of SH1-108.
Step 11
Verify that the interfaces on module 3 are aggregated into portchannel 69 correctly, and that they are
again passing traffic.
Step 12
Determine the amount of traffic loss.
Step 13
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 14
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the interfaces on that module to be reaggregated into their respective portchannels and to
again pass traffic following the reset of the module.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 25 shows the Gigabit Ethernet Module Reset—Supervisor 1 test results.
Table 25
Gigabit Ethernet Module Reset—Supervisor 1 Test Results
Tests
Results
Gigabit Ethernet Module Reset—Supervisor 1
Pass
Gigabit Ethernet Module Reset—Supervisor 2
This test verified the ability of Layer 2 and Layer 3 EtherChannels to handle module resets and failures.
IXIA unicast traffic was sent from 20 incrementing IP addresses to a single IP destination. The first hop
router is SH1-110. Gigabit Ethernet interfaces 3/5 through 6, and 4/5 through 6, bundled into Layer 2
EtherChannel portchannel 20, connect SH1-110 to Dista-2. The next hop router was out Layer 3
interface portchannel 171, which consists of bundled Gigabit Ethernet interfaces 3/3 through 3/4,and 4/3
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
54
Layer 2 Features
through 4/4. A test stream was sent first while module 4 was reset. The same test stream was sent again;
this time module 3 is reset. In each case it was verified that the Layer 2 and Layer 3 EtherChannels were
reformed correctly. Traffic loss was measured for each case.
Figure 21 shows the topology configuration, but the ports assignments do not reflect the current
configuration described above. To test failure to Dista-2 (that is, portchannel 20) separately from failure
to outgoing portchannel 170, SH1-109 must be used instead of SH1-110. To enable the traffic to flow
over SH1-109, portchannels 20, 70, and 171 on SH1-110 must be shutdown first.
Figure 21
GEM Reset—Sup 2 Topology
Device under test: SH1-109
Test Procedure
The procedure used to perform the Gigabit Ethernet Module Reset—Supervisor 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Deactivate portchannels 20, 71, and 171 on SH1-110 from the console port.
Step 5
Start the test traffic stream, sending 300 sec worth of traffic at 1000 pps.
Step 6
Verify that the traffic is being load-balanced across all the aggregated interfaces of portchannels 20 and
170 of device SH1-109.
Step 7
Reset module 7 of SH1-109.
Step 8
While unicast traffic is still flowing, verify that the portchannel 20 reforms correctly after the module
comes back online and that those interfaces on module 7 that were passing traffic before are again
passing traffic.
Step 9
Determine the amount of traffic loss.
Step 10
Start the test traffic stream, sending 300 sec worth of traffic at 1000 pps.
Step 11
Reset modules 3 and 4 of SH1-109.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
55
Layer 2 Features
Step 12
While unicast traffic is still flowing, verify that the interfaces on modules 3 and 4 are aggregated into
portchannel 170 correctly, and that they are again passing traffic.
Step 13
Determine the amount of traffic loss.
Step 14
Activate portchannels 20, 71, and 171 on SH1-110.
Step 15
Verify portchannels 20, 71, and 171 are back online on SH1-110.
Step 16
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 17
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the interfaces on that module to be reaggregated into their respective portchannels and to
again pass traffic following the reset of the module.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 26 shows the Gigabit Ethernet Module Reset—Supervisor 2 test results.
Table 26
Gigabit Ethernet Module Reset—Supervisor 2 Test Results
Tests
Results
Gigabit Ethernet Module Reset—Supervisor 2
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
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 56
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 tested, VLANs were configured and behavior was
checked to be normal.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
56
Layer 2 Features
Device under test: SH1-107
Test Procedure
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.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Note
Step 2
The crash observed on SH1-101 was deliberately caused by another test and had no effect on this test.
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-107 and Dista-1 are in VTP transparent mode and that both devices are in the domain
named FIN.
Step 5
Verify that a trunk link is configured between SH1-107 (g4/1, g4/3) and Dista-1 (1/1, 2/1).
Verify that the status of Po10 on SH1-107 is trunking.
Verify that each of the ports on Dista-1 in the port channel connecting to SH1-107 are trunking.
Step 6
Run the script that will execute the following tasks:
•
With both SH1-107 and Dista-1 in transparent mode, configure VLAN 200 on SH1-107. Verify that
VLAN 200 is created on SH1-107 but not on Dista-1.
•
Configure SH1-107 for VTP server mode (Dista-1 still in transparent mode) and add VLAN 201 to
the VLAN database of SH1-107. Verify that VLAN 201 is created on SH1-107 but not on Dista-1.
•
Configure Dista-1 for VTP mode client (SH1-107 is server) and add VLAN 202 to the VLAN
database on SH1-107. Verify that VLAN 202 was added to both SH1-107 and Dista-1.
•
Configure Dista-1 for VTP server mode (SH1-107 in server mode), add VLAN 203 to SH1-107.
Verify that VLAN 203 is created on both SH1-107 and Dista-1.
•
With SH1-107 and Dista-1 both in server mode, enable VTP Version 2 on Dista-1 (VTP V2 disabled
on SH1-107). Configure VLAN 204 on SH1-107. Verify that VLAN 204 is created on both SH1-107
and Dista-1.
•
Create VLAN 205 on Dista-1. Verify that VLAN 205 is created on both SH1-107 and Dista-1.
•
With SH1-107 in Server mode, configure Dista-1 for VTP transparent mode and SH1-108 for VTP
Client mode. Configure VLAN 206 on SH1-107. Verify that VLAN 206 is not created on Dista-1,
but is created on SH1-108.
Step 7
Review the output of the script, to verify both cases passed.
Step 8
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 9
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
57
Layer 3 Routing
Expected Results
•
We expect a switch in VTP transparent mode, to not accept any VLAN changes from a VTP server
but to 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.
•
We expect that a switch in VTP server mode to propagate local VLANs to other VTP servers and
VTP clients.
•
We expect a switch in VTP server mode, local VLAN to be propagated to other VTP servers and
vtVTP p clients.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 27 shows the Basic VLAN Trunking Protocol Configuration test results.
Table 27
Basic VLAN Trunking Protocol Configuration Test Results
Tests
Results
Basic VLAN Trunking Protocol Configuration
Pass
Layer 3 Routing
Layer 3 routing feature testing for Safe Harbor consists of the following tests:
•
IP Multicast, page 58
•
Cisco Express Forwarding, page 129
•
Open Shortest Path First, page 138
•
Border Gateway Protocol, page 146
•
Hot Standby Router Protocol, page 157
•
Enhanced Interior Gateway Routing Protocol, page 170
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.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
58
Layer 3 Routing
Note
On PFC1, the (*, G) can be software switched only. If the ip pim spt-threshold infinity command
is used on PFC1, there might be high CPU usage and multicast packets might be lost during heavy
traffic.
Note
For this iteration of Cisco Safe Harbor Native IOS testing, and for all subsequent iterations, the
following interfaces have been equipped with the Texas-2 GBIC, which transmits GigE 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 enabled.
Note
The following tests use streams outlined on either Figure 10 on page 14 or Figure 12 on page 16.
The following IP Multicast tests were performed:
•
Last Hop Router Functionality, page 60
•
First Hop Router Functionality, page 62
•
Basic Static RP Functionality—Supervisor 11, page 63
•
Basic Static RP Functionality—Supervisor 22, page 64
•
Basic Auto RP Functionality—Supervisor 22, page 66
•
Auto PIM-RP Failover—First Hop Router Impact—Supervisor 11, page 68
•
Auto PIM-RP Failover—First Hop Router Impact—Supervisor 12, page 69
•
Auto PIM-RP Failover—First Hop Router Impact—Supervisor 22, page 71
•
Auto PIM-RP Failover—Traffic Impact—Supervisor 22, page 72
•
Static PIM-RP Failover—Supervisor 11, page 73
•
Static PIM-RP Failover—Supervisor 22—RP Impact, page 75
•
Static PIM-RP Failover—Supervisor 22—First Hop Router Impact, page 76
•
Static PIM-RP Failover—Supervisor 22—Traffic Impact, page 78
•
Basic IGMP Functionality, page 79
•
IGMP Join/Leave Functionality, page 80
•
Multicast Stub and Non-Reverse Path Forwarding Rate Limiting—Supervisor 1, page 82
•
Multicast Stub and Non-Reverse Path Forwarding Rate Limiting—Supervisor 2, page 84
•
Layer 2 GEC Failover—SH1-110 to Dista-2, page 86
•
Layer 2 GEC Failover—SH1-108 to Dista-1, page 87
•
Layer 2 GEC Failover—SH1-114 to Dista-1, page 89
•
Layer 2 GEC Failover—SH1-106 to Dista-2, page 91
•
Layer 2 GEC Failover—SH1-102 to Dista-1, page 92
•
Layer 3 GEC Failover—SH1-104 to SH1-110, page 94
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
59
Layer 3 Routing
•
Layer 3 GEC Failover—SH1-104 to SH1-109, page 95
•
Layer 3 GEC Failover—SH1-104 to SH1-108, page 97
•
Layer 3 GEC Failover—SH1-104 to SH1-107, page 99
•
Layer 3 GEC Failover—SH1-100 to SH1-104, page 100
•
Layer 3 GEC Failover—SH1-100 to SH1-113, page 102
•
Layer 3 GEC Failover—SH1-100 to SH1-106, page 103
•
Layer 3 GEC Failover—SH1-100 to SH1-105, page 105
•
Layer 3 GEC Failover—SH1-100 to SH1-102, page 106
•
Layer 3 GEC Failover—SH1-100 to SH1-101, page 108
•
Layer 3 GEC Failover—SH1-100 to SH1-97, page 110
•
Switch Fabric Module Failover—Supervisor 22, page 111
•
GEM Failover—Supervisor 11 as First Hop Router, page 113
•
GEM Failover—Supervisor 11 as Last Hop Router, page 114
•
GEM Failover—Supervisor 11 with Directly Connected Layer 3 Interface, page 116
•
GEM Failover—Supervisor 22 as First Hop Router, page 117
•
GEM Failover—Supervisor 22 as Last Hop Router, page 118
•
GEM Failover—Supervisor 22 as Static RP, page 120
•
GEM Failover—Supervisor 22 as Auto RP, page 121
•
GEM Failover—Supervisor 22 with Directly Connected Layer 3 Interface, page 123
•
Protocol Independent Module-Designated Router Failover—Supervisor 11, page 124
•
Protocol Independent Module-Designated Router Failover—Supervisor 22, page 126
•
Auto PIM-RP Failover—Supervisor 22—RP Impact, page 128
Last Hop Router Functionality
This test verified basic multicast functionality on the last-hop router, including the creation of hardware
shortcuts for multicast entries.
Goals
•
Verify that the correct mroute entries are created on the correct devices.
•
Verify that the correct flags are set for the mroute entries.
•
Verify that traffic is being hardware-switched where appropriate.
Primary Devices Used
•
SH1-105: Supervisor 11; directly attached Layer 3 receiver on secondary subnet; backup PIM-DR;
groups 239.100.1.[1-10]
•
SH1-113: Supervisor 12; RP-on-a-stick scenario; directly attached Layer 3 receiver on primary
subnet; groups 239.100.1.[1-10]
•
SH1-110: Supervisor 22; directly attached Layer 3 receiver on secondary subnet; primary PIM-DR;
groups 239.100.2.[1-10]
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
60
Layer 3 Routing
•
SH1-102: Supervisor 22; receivers are VLANs on primary subnets; primary PIM-DR; groups
239.100.[1-3].[1-10]
Primary IXIA Ports Used
•
1/1, 4/6, 11/1, 2/1, 1/2, 2/7
Test Procedure
The procedure used to perform the Last Hop Router Functionality test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the correct mroute entries and flags are created on SH1-105 for groups 239.100.1.[1-10], and
that this traffic is being hardware-switched.
Step 5
Verify that the correct mroute entries and flags are created on SH1-113 for groups 239.100.2.[1-10], and
that this traffic is being hardware-switched.
Step 6
Verify that the correct mroute entries and flags are created on SH1-110 for groups 239.100.2.[1-10], and
that this traffic is being hardware-switched.
Step 7
Verify that the correct mroute entries and flags are created on SH1-102 for groups 239.100.1.[1-10], and
that this traffic is being hardware-switched.
Step 8
Verify that the correct mroute entries and flags are created on SH1-102 for groups 239.100.2.[1-10], and
that this traffic is being hardware-switched.
Step 9
Verify that the correct mroute entries and flags are created on SH1-102 for groups 239.100.3.[1-10], and
that this traffic is being hardware-switched.
Step 10
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that, for each receiver looked at during this test, proper mroute entries and flags are
installed.
•
We expect multicast groups to be hardware-switched, where appropriate.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
61
Layer 3 Routing
Results
•
In the cases where the last-hop router is a Supervisor 2, hardware entries were correctly installed.
In the cases where the last-hop router was a Supervisor 1, there were no hardware entries installed,
as the PFC 1 software switches the (*, G) entries that are caused by the SPT threshold being
configured to infinity.
Table 28 shows the Last Hop Router Functionality test results.
Table 28
Last Hop Router Functionality Test Results
Tests
Results
Last Hop Router Functionality
Pass
First Hop Router Functionality
This test verified basic multicast functionality on the first hop router, including the creation of hardware
shortcuts for multicast entries.
Goals
•
Verify that the correct mroute entries are created in the correct devices.
•
Verify that the correct flags are set for the mroute entries.
•
Verify that traffic is being hardware-switched, where appropriate.
Primary Devices Used
•
SH1-114: Supervisor 12; sender is connected to Dista-1 on VLAN 110; groups 239.100.1.[1-10]
•
SH1-106: Supervisor 11; sender is connected to Dista-2 on VLAN 49; groups 239.100.2.[1-10]
•
SH1-110: Supervisor 22; sender is connected to Dista-2 on VLAN 20; groups 239.100.3.[1-10]
Primary IXIA Ports Used
•
3/3, 4/2, 13/2
Test Procedure
The procedure used to perform the First Hop Router Functionality test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Display which device SH1-114 considers to be the primary PIM-RP for test groups 239.100.1.[1-10].
Step 5
Verify that the correct mroute entries and flags are created on SH1-114 for groups 239.100.1.[1-10], and
that this traffic is being hardware-switched.
Step 6
Display which device SH1-106 considers to be the primary PIM-RP for test groups 239.100.2.[1-10].
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
62
Layer 3 Routing
Step 7
Verify that the correct mroute entries and flags are created on SH1-106 for groups 239.100.2.[1-10], and
that this traffic is being hardware-switched.
Step 8
Display which device SH1-110 considers to be the primary PIM-RP for test groups 239.100.3.[1-10].
Step 9
Verify that the correct mroute entries and flags are created on SH1-110 for groups 239.100.3.[1-10], and
that this traffic is being hardware-switched.
Step 10
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that, for each receiver looked at during this test, proper mroute entries and flags are
installed.
•
We expect multicast groups to be hardware-switched, where appropriate.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 29 shows the First Hop Router Functionality test results.
Table 29
First Hop Router Functionality Test Results
Tests
Results
First Hop Router Functionality
Pass
Basic Static RP Functionality—Supervisor 11
This test verified basic static RP functionality using the Supervisor 11 engine.
Goals
•
Verify the RP configuration on all rendezvous points.
•
Verify the static RP configuration on any downstream devices.
•
Verify that downstream devices, if any, know of the correct RP for the given traffic groups.
•
Verify that the static RPs have the correct mroute entries and flags for the given traffic groups.
•
Verify that the static RPs have MMLS entries consistent with the mroute table and are switching the
test traffic.
Primary Devices Used
•
SH1-105 and SH1-106: Supervisor 11; static RPs for groups 239.255.50.[1-10]
Primary IXIA Ports Used
•
2/3, 2/5
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
63
Layer 3 Routing
Note
In the Safe Harbor topology, no routers are downstream from SH1-105 and SH1-106. These two
routers act in the role of PIM-RPs running Anycast Static RP with MSDP, and in the role of PIM-DR
and non-PIM-DR (NDR) for the VLAN segments to which they are connected.
Test Procedure
The procedure used to perform the Basic Static RP Functionality—Supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the
box has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify the static RP configuration on SH1-105 and SH1-106.
Step 5
Verify that SH1-105 and SH1-106 see the proper device as the static RP for the appropriate group range.
Step 6
Verify that SH1-106 is the PIM-DR on the networks shared with SH1-105.
Step 7
Verify that SH1-106 has the correct mroute entries and flags for all test traffic and that that traffic is being
hardware switched.
Step 8
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 9
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the primary PIM-RP to have the proper mroute entries and flags set for all test groups.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 30 shows the Basic Static RP Functionality—Supervisor 11 test results.
Table 30
Basic Static RP Functionality—Supervisor 11 Test Results
Tests
Results
Basic Static RP Functionality—Supervisor 11
Pass
Basic Static RP Functionality—Supervisor 22
This test verified basic static RP functionality using the Supervisor 22 engine.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
64
Layer 3 Routing
Goals
•
Verify the RP configuration on all rendezvous points.
•
Verify the static RP configuration on any downstream devices.
•
Verify that downstream devices, if any, know of the correct RP for the given traffic groups.
•
Verify that the static RPs have the correct mroute entries and flags for the given traffic groups.
•
Verify that the static RPs have MMLS entries consistent with the mroute table and are switching the
test traffic.
Primary Devices Used
•
SH1-103 and SH1-104: Supervisor 22; static RPs for groups 239.255.[50-51].[1-10]
•
SH1-107 and SH1-108: Supervisor 12; routers downstream from SH1-103 and SH1-104
•
SH1-109 and SH1-110: Supervisor 22; routers downstream from SH1-103 and SH1-104
Primary IXIA Ports Used
•
5/1, 5/2, 8/2, 13/1
Test Procedure
The procedure used to perform the Basic Static RP Functionality—Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify the static RP configuration on SH1-103 and SH1-104.
Step 5
Verify the static RP configuration on SH1-107, SH1-108, SH1-109, and SH1-110.
Step 6
Verify that SH1-110 is the PIM-DR on the networks shared with SH1-109.
Step 7
Verify that SH1-108 is the PIM-DR on the networks shared with SH1-107.
Step 8
Verify that SH1-108 and SH1-110, the PIM-DRs, see the proper device as the static RP for the
appropriate group range.
Step 9
Verify that SH1-110 has the correct mroute entries for all test traffic and that that traffic is being
hardware switched.
Step 10
Verify that SH1-108 has the correct mroute entries for all test traffic and that that traffic is being
hardware switched.
Step 11
Verify that SH1-104 (the PIM-RP) has the correct mroute entries and flags for the test traffic groups and
that traffic is being hardware switched.
Step 12
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
65
Layer 3 Routing
Step 13
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect all downstream routers to know the correct device as the RP for the 20 multicast test
groups.
•
We expect the PIM-DRs to have the proper mroute entries and flags set for groups for which they
are the last-hop router.
•
We expect the PIM-DRs to have the proper mroute entries and flags set for groups for which they
are the first hop router.
•
We expect the primary PIM-RP to have the proper mroute entries and flags set for all test groups.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
•
The primary PIM-RP had all the correct mroute (S, G) entries, but was inconsistent in setting the
A-flag. This is due to CSCea21798.
Results
Table 31 shows the Basic Static RP Functionality—Supervisor 22 test results.
Table 31
Basic Static RP Functionality—Supervisor 22 Test Results
Tests
Results
Basic Static RP Functionality—Supervisor 22 Pass with exception CSCea21798, and CSCdx48854
Basic Auto RP Functionality—Supervisor 22
This test verified basic auto-RP functionality using the Supervisor 22 engine.
Goals
•
Verify the auto-RP configuration on all RP candidates.
•
Verify the auto-RP configuration on the downstream devices SH1-106 (Supervisor11) and SH1-110
(Supervisor22).
•
Verify that downstream devices know of the correct RP for the given traffic groups.
•
Verify that the first hop router has the correct mroute entries and flags for the given multicast test
groups.
•
Verify that the first hop router has MMLS entries consistent with the mroute table and is switching
the test traffic.
•
Verify that the elected RP has the correct mroute entries and flags for the given traffic groups.
•
Verify that the elected RP has MMLS entries consistent with the mroute table and is switching the
test traffic.
Primary Devices Used
•
SH1-99 and SH1-100: Supervisor 22; auto-RP candidates for groups 239.100.[1-3].[1-10]
•
SH1-106: Supervisor 11; first hop router for groups 239.100.2.[1-10]
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
66
Layer 3 Routing
•
SH1-110: Supervisor 22; first hop router for groups 239.100.3.[1-10]
Primary IXIA Ports Used
•
4/2, 13/2
Test Procedure
The procedure used to perform the Basic Auto RP Functionality—Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify the auto-RP configuration on SH1-99 and SH1-100.
Step 5
Verify the auto-RP configuration on downstream devices SH1-106 (Sup11) and SH1-110 (Sup22).
Step 6
Verify that SH1-106 and SH1-110, the first hop routers, see the proper device as the elected RP for the
appropriate group ranges.
Step 7
Verify that SH1-106, the first hop router for groups 239.100.2.[1-10], has the correct mroute entries for
all test traffic and that that traffic is being hardware switched.
Step 8
Verify that SH1-110, the first hop router for groups 239.100.3.[1-10], has the correct mroute entries for
all test traffic and that that traffic is being hardware switched.
Step 9
Verify that SH1-100 (the elected PIM-RP) has the correct mroute entries and flags for the test traffic
groups and that traffic is being hardware switched.
Step 10
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the first hop routers to learn the correct (elected) RP and RP-to-group mapping
information.
•
We expect the first hop routers to have the correct (S, G) entries and flags set for each group.
•
We expect the elected RP to have the correct (S, G) entries and flags set for each group.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 32 shows the Basic Auto RP Functionality—Supervisor 22 test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
67
Layer 3 Routing
Table 32
Basic Auto RP Functionality—Supervisor 22 Test Results
Tests
Results
Basic Auto RP Functionality—Supervisor 22
Pass
Auto PIM-RP Failover—First Hop Router Impact—Supervisor 11
This test verified multicast functionality on the first hop router during an auto PIM-RP failover on a
Supervisor 11 platform. SH1-100 was the elected PIM-RP for 30 multicast test groups:
239.100.[1-3].[1-10]. SH1-106 was the Sup11 first hop router for groups 239.100.2.[1-10]. SH1-100 was
reloaded, and the correct changes in the mroute and MMLS tables of SH1-106 was verified. Once
SH1-100 was back online, it was verified that SH1-106 reverted back to its initial state.
Goals
•
Verify that the first hop router has the correct mroute entries, flags, and MMLS entries for all 10 test
groups.
•
Verify that the first hop router uses the new RP (SH1-99) for each of the 10 test groups when
SH1-100 is failed over.
•
Verify that the first hop router builds correct state again, sending traffic to the original PIM-RP for
all 10 test groups, when it is back online.
Primary Devices Used
•
SH1-106: Supervisor 11; first hop router for groups 239.255.2.[1-10]
Primary IXIA Ports Used
•
12/1, 2/1, 1/2, 2/7, 2/4, 1/1, 2/6, 4/2, 4/6, 3/3, 5/3, 8/1, 7/2, 7/1, 9/1, 9/2, 10/1, 10/2, 13/2, 11/1, 12/2
Test Procedure
The procedure used to perform the Auto PIM-RP Failover—First Hop Router Impact—Supervisor 11
test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the first hop router, SH1-106, knows SH1-100 as the elected PIM-RP for the groups
239.100.2.[1-10].
Step 5
Verify that the first hop router, SH1-106, has the proper mroute and MMLS entries, with the correct flags
for the groups 239.100.2.[1-10].
Step 6
Reload SH1-100.
Step 7
Verify that the first hop router, SH1-106, has the proper mroute and MMLS entries, with the correct flags
for the groups 239.100.2.[1-10] while SH1-100 is offline.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
68
Layer 3 Routing
Step 8
Once SH1-100 comes back online, verify that the first hop router, SH1-106, has the proper mroute and
MMLS entries, with the correct flags for the groups 239.100.2.[1-10].
Step 9
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 10
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect SH1-106, the first hop router for groups 239.100.2.[1-10], to have all the correct mroute
entries and flags for those 10 groups prior to the failover.
•
We expect SH1-106 to have the correct MMLS entries, consistent with the mroute entries, and be
hardware-switching traffic.
•
We expect SH1-106 to adjust its mroute and MMLS entries to reflect the RP change after the
failover.
•
We expect SH1-106 to return its mroute and MMLS entries to their original state, once the original
RP is back online and forwarding traffic,.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 33 shows the Auto PIM-RP Failover—First Hop Router Impact—Supervisor 11 test results.
Table 33
Auto PIM-RP Failover—First Hop Router Impact—Supervisor 11 Test Results
Tests
Results
Auto PIM-RP Failover—First Hop Router Impact—Supervisor 11 Pass
Auto PIM-RP Failover—First Hop Router Impact—Supervisor 12
This test verified multicast functionality on the first hop router during an auto PIM-RP failover on a
Supervisor 12 platform. SH1-100 was the elected PIM-RP for 30 multicast test groups:
239.100.[1-3].[1-10]. SH1-114 was the Sup12 first hop router for groups 239.100.1.[1-10]. SH1-100 was
reloaded, and the correct changes in the mroute and MMLS tables of SH1-114 was verified. Once
SH1-100 was back online, it was verified that SH1-114 reverted back to its initial state.
Goals
•
Verify that the first hop router has the correct mroute entries, flags, and MMLS entries for all 10 test
groups.
•
Verify that the first hop router uses the new RP (SH1-99) for each of the 10 test groups when
SH1-100 is failed over.
•
Verify that the first hop router builds correct state again, sending traffic to the original PIM-RP for
all 10 test groups, when it is back online.
Primary Devices Used
•
SH1-114: Supervisor 12; first hop router for groups 239.255.1.[1-10]
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
69
Layer 3 Routing
Primary IXIA Ports Used
•
12/1, 2/1, 1/2, 2/7, 2/4, 1/1, 2/6, 4/2, 4/6, 3/3, 5/3, 8/1, 7/2, 7/1, 9/1, 9/2, 10/1, 10/2, 13/2, 11/1, 12/2
Test Procedure
The procedure used to perform the Auto PIM-RP Failover—First Hop Router Impact—Supervisor 12
test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the first hop router, SH1-114, knows SH1-100 as the elected PIM-RP for the groups
239.100.2.[1-10].
Step 5
Verify that the first hop router, SH1-114, has the proper mroute and MMLS entries, with the correct flags
for the groups 239.100.1.[1-10].
Step 6
Reload SH1-100.
Step 7
Verify that the first hop router, SH1-114, has the proper mroute and MMLS entries, with the correct flags
for the groups 239.100.1.[1-10] while SH1-100 is offline.
Step 8
Once SH1-100 comes back online, verify that the first hop router, SH1-114, has the proper mroute and
MMLS entries, with the correct flags for the groups 239.100.1.[1-10].
Step 9
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 10
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect SH1-114, the first hop router for groups 239.100.1.[1-10], to have all the correct mroute
entries and flags for those 10 groups prior to the failover.
•
We expect SH1-114 to have the correct MMLS entries, consistent with the mroute entries, and be
hardware-switching traffic.
•
We expect SH1-114 to return its mroute and MMLS entries to their original state once the original
RP is back online and forwarding traffic. And after the failover, SH1-114 to adjust its mroute and
MMLS entries to reflect the RP change.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 34 shows the Auto PIM-RP Failover—First Hop Router Impact—Supervisor 12 test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
70
Layer 3 Routing
Table 34
Auto PIM-RP Failover—First Hop Router Impact—Supervisor 12 Test Results
Tests
Results
Auto PIM-RP Failover—First Hop Router Impact—Supervisor 12 Pass
Auto PIM-RP Failover—First Hop Router Impact—Supervisor 22
This test verified multicast functionality on the first hop router during an auto PIM-RP failover on a
Supervisor 22 platform. SH1-100 was the elected PIM-RP for 30 multicast test groups:
239.100.[1-3].[1-10]. SH1-110 was the Sup22 first hop router for groups 239.100.3.[1-10]. SH1-100 was
reloaded, and the correct changes in the mroute and MMLS tables of SH1-110 was verified. Once
SH1-100 was back online, it was verified that SH1-110 reverts to its initial state.
Goals
•
Verify that the first hop router has the correct mroute entries, flags, and MMLS entries for all 10 test
groups.
•
Verify that the first hop router uses the new RP (SH1-99) for each of the 10 test groups when
SH1-100 is failed over.
•
Verify that the first hop router builds correct state again, sending traffic to the original PIM-RP for
all 10 test groups, when it is back online.
Primary Devices Used
•
SH1-110: Supervisor 11; first hop router for groups 239.255.3.[1-10]
Primary IXIA Ports Used
•
12/1, 2/1, 1/2, 2/7, 2/4, 1/1, 2/6, 4/2, 4/6, 3/3, 5/3, 8/1, 7/2, 7/1, 9/1, 9/2, 10/1, 10/2, 13/2, 11/1, 12/2
Test Procedure
The procedure used to perform the Auto PIM-RP Failover—First Hop Router Impact—Supervisor 22
test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the first hop router, SH1-110, knows SH1-100 as the elected PIM-RP for the groups
239.100.2.[1-10].
Step 5
Verify that the first hop router, SH1-110, has the proper mroute and MMLS entries, with the correct flags
for the groups 239.100.3.[1-10].
Step 6
Reload SH1-100.
Step 7
Verify that the first hop router, SH1-110, has the proper mroute and MMLS entries, with the correct flags
for the groups 239.100.3.[1-10] while SH1-100 is offline.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
71
Layer 3 Routing
Step 8
Once SH1-100 comes back online, verify that the first hop router, SH1-110, has the proper mroute and
MMLS entries, with the correct flags for the groups 239.100.3.[1-10].
Step 9
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 10
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect SH1-110, the first hop router for groups 239.100.3.[1-10], to have all the correct mroute
entries and flags for those 10 groups prior to the failover.
•
We expect SH1-110 to have the correct MMLS entries, consistent with the mroute entries, and be
hardware-switching traffic.
•
We expect SH1-110 to adjust its mroute and MMLS entries to reflect the RP change after the
failover.
•
We expect SH1-110 to return its mroute and MMLS entries to their original state, once the original
RP is back online and forwarding traffic.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 35 shows the Auto PIM-RP Failover—First Hop Router Impact—Supervisor 22 test results.
Table 35
Auto PIM-RP Failover—First Hop Router Impact—Supervisor 22 Test Results
Tests
Results
Auto PIM-RP Failover—First Hop Router Impact—Supervisor 22 Pass
Auto PIM-RP Failover—Traffic Impact—Supervisor 22
This test verified the impact on the traffic during a PIM-RP failover on a Supervisor 22 platform.
SH1-100 was the elected PIM-RP for 30 multicast test groups: 239.255.[1-3].[1-10]. SH1-100 was
reloaded, and the traffic impact was measured.
Goals
•
Verify that the impact to the traffic from a PIM-RP failover is acceptable.
Primary Devices Used
•
SH1-104: Supervisor 22; static RP for groups 239.255.[1-3].[1-10]
Primary IXIA Ports Used
•
12/1, 2/1, 1/2, 2/7, 2/4, 1/1, 2/6, 4/2, 4/6, 3/3, 5/3, 8/1, 7/2, 7/1, 9/1, 9/2, 10/1, 10/2, 13/2, 11/1, 12/2
Test Procedure
The procedure used to perform the Auto PIM-RP Failover—Traffic Impact—Supervisor 22 test follows:
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
72
Layer 3 Routing
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin sending a fixed stream of traffic.
Step 5
Force the primary supervisor on SH1-100 to switch to the backup.
Step 6
Measure the traffic loss that occurs.
Step 7
Repeat the reload sequence four times, each time measuring traffic loss.
Step 8
Determine the average amount of traffic loss.
Step 9
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 10
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect the average traffic loss resulting from the failover and recovery of the elected PIM-RP to
be acceptable.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 36 shows the Auto PIM-RP Failover—Traffic Impact—Supervisor 22 test results.
Table 36
Auto PIM-RP Failover—Traffic Impact—Supervisor 22 Test Results
Tests
Results
Auto PIM-RP Failover—Traffic Impact—Supervisor 22
Pass
Static PIM-RP Failover—Supervisor 11
This test verified multicast functionality of a Supervisor 11 platform during a static PIM-RP failover.
SH1-106 was the primary PIM-RP for 10 multicast test groups: 239.255.50.[1-10]. SH1-106 was
reloaded, verifying the correct failover of mrouting state to SH1-105 and the reversion of state to
SH1-106, once it was back online.
Goals
•
Verify that the static RP has the correct mroute entries, flags, and MMLS entries for all 10 test
groups.
•
Verify that each of the 10 test groups fails over to the backup PIM-RP after the failure of the primary,
with correct mroute and MMLS state.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
73
Layer 3 Routing
•
Verify that all 10 groups build correct state again on the primary PIM-RP when it is back online.
Primary Devices Used
•
SH1-106: Supervisor 11; static RP for groups 239.255.50.[1-10]
Primary IXIA Ports Used
•
2/2, 2/8
Test Procedure
The procedure used to perform the Static PIM-RP Failover—Supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin sending a fixed stream of traffic
Step 5
Verify that the primary PIM-RP, SH1-106, has the proper mroute and MMLS entries, with the correct
flags for all 10 groups.
Step 6
Reload SH1-106.
Step 7
Verify that the new primary PIM-RP, SH1-105, has the correct mroute and MMLS entries, with the
correct flags set, for all 10 groups.
Step 8
Once SH1-106 comes back online, verify that it is again the RP for all 10 groups and that its mrouting
table and MMLS entries are correct.
Step 9
Determine the amount of traffic loss from the PIM-RP failover.
Step 10
Repeat the failover sequence, with traffic, four times, each time determining traffic loss.
Step 11
Determine the average amount of traffic loss over the five failovers.
Step 12
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 13
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect SH1-106, the primary PIM-RP, to have all the correct mroute entries and flags for the 10
groups for which it is the RP, prior to the failover.
•
We expect SH1-106 to have the correct MMLS entries, consistent with the mroute entries, and be
hardware-switching traffic.
•
We expect SH1-105 to take over the role of primary PIM-RP when SH1-106 is reloaded, and
correctly populate its mroute and MMLS entries.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
74
Layer 3 Routing
•
We expect SH1-106 to resume the role of primary PIM-RP when it is back online and capable of
forwarding traffic.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 37 shows the Static PIM-RP Failover—Supervisor 11 test results.
Table 37
Static PIM-RP Failover—Supervisor 11 Test Results
Tests
Results
Static PIM-RP Failover—Supervisor 11
Pass
Static PIM-RP Failover—Supervisor 22—RP Impact
This test verified multicast functionality on the PIM-RP during a PIM-RP failover on a Supervisor 22
platform. SH1-104 was the primary PIM-RP for 20 multicast test groups: 239.255.[50-51].[1-10].
SH1-104 was reloaded, verifying the correct failover of mrouting state to SH1-103 and the reversion of
state to SH1-104, once it was back online.
Goals
•
Verify that the static RP has the correct mroute entries, flags, and MMLS entries for all 20 test
groups.
•
Verify that each of the 20 test groups fails over to the backup PIM-RP after the failure of the primary,
with correct mroute and MMLS state.
•
Verify that all 20 groups build correct state again on the primary PIM-RP when it is back online.
Primary Devices Used
•
SH1-104: Supervisor 22; static RP for groups 239.255.[50-51].[1-10]
Primary IXIA Ports Used
5/1, 5/2, 8/2, 13/1
Test Procedure
The procedure used to perform the Static PIM-RP Failover—Supervisor 22—RP Impact test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the primary PIM-RP, SH1-104, has the proper mroute and MMLS entries, with the correct
flags for all 20 groups.
Step 5
Reload SH1-104.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
75
Layer 3 Routing
Step 6
Verify that the new primary PIM-RP, SH1-103, has the correct mroute and MMLS entries, with the
correct flags set, for all 20 groups while SH1-104 is offline.
Step 7
Once SH1-104 comes back online, verify that it is again the RP for all 20 groups and that its mrouting
table and MMLS entries are correct.
Step 8
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 9
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect SH1-104, the primary PIM-RP, to have all the correct mroute entries and flags for the 20
groups for which it is the RP, prior to the failover.
•
We expect SH1-104 to have the correct MMLS entries, consistent with the mroute entries, and be
hardware-switching traffic.
•
We expect SH1-103 to take over the role of primary PIM-RP when SH1-106 is reloaded, and
correctly populate its mroute and MMLS entries.
•
We expect SH1-103 to resume the role of primary PIM-RP when it is back online and capable of
forwarding traffic.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 38 shows the Static PIM-RP Failover—Supervisor 22—RP Impact test results.
Table 38
Static PIM-RP Failover—Supervisor 22—RP Impact Test Results
Tests
Results
Static PIM-RP Failover—Supervisor 22—RP Impact
Pass
Static PIM-RP Failover—Supervisor 22—First Hop Router Impact
This test verified multicast functionality on the first hop router during a static PIM-RP failover on a
Supervisor 22 platform. SH1-110 was the first hop router for 10 multicast test groups:
239.255.51.[1-10]. SH1-104 (the primary PIM-RP) was reloaded, and the correct failover of mrouting
state to SH1-103 was verified. The reversion of state to SH1-104, once it was back online, was verified.
Goals
•
Verify that the first hop router has the correct mroute entries, flags, and MMLS entries for all 10 test
groups.
•
Verify that each of the 10 test groups fails over to the backup PIM-RP after the failure of the primary,
with correct mroute and MMLS state.
•
Verify that all 10 groups build correct state again on the primary PIM-RP when it is back online.
Primary Devices Used
•
SH1-110: Supervisor 22; first hop router for groups 239.255.51.[1-10]
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
76
Layer 3 Routing
Primary IXIA Ports Used
•
5/2, 4/6
Test Procedure
The procedure used to perform the Static PIM-RP Failover—Supervisor 22—First Hop Router Impact
test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the first hop router SH1-110 (for groups 239.255.51.[1-10]) see SH1-104 as the primary
PIM-RP.
Step 5
Verify that the first hop router SH1-110 has the correct mroute and MMLS entries, with the correct flags
for groups 239.255.51.[1-10].
Step 6
Reload SH1-104.
Step 7
Verify that the first hop router now sees SH1-103 as the primary PIM-RP.
Step 8
Verify that the first hop router has updated its mroute and MMLS tables to reflect the RP change.
Step 9
Once SH1-104 comes back online, verify that the first hop router SH1-110 uses SH1-104 as the primary
PIM-RP again.
Step 10
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 11
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect SH1-110 to have all the correct mroute entries and flags for those groups for which it is
the first hop router.
•
We expect SH1-110 to be hardware-switching the multicast traffic for the 10 test groups.
•
We expect SH1-110 to properly reflect the change in the primary PIM-RP in its own mroute and
MMLS tables, both with the failover and recovery of SH1-104.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 39 shows the Static PIM-RP Failover—Supervisor 22—First Hop Router Impact test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
77
Layer 3 Routing
Table 39
Static PIM-RP Failover—Supervisor 22—First Hop Router Impact Test Results
Tests
Results
Static PIM-RP Failover—Supervisor 22—First Hop Router Impact Pass
Static PIM-RP Failover—Supervisor 22—Traffic Impact
This test verified the impact on the traffic during a PIM-RP failover on a Supervisor 22 platform.
SH1-104 was the primary PIM-RP for groups 20 multicast test groups: 239.255.[50-51].[1-10]. SH1-104
was reloaded, and the traffic impact was measured.
Goals
•
Verify that the impact to the traffic from a PIM-RP failover is acceptable.
Primary Devices Used
•
SH1-104: Supervisor 22; static RP for groups 239.255.[50-51].[1-10]
Primary IXIA Ports Used
•
5/1, 5/2, 8/2, 13/1
Test Procedure
The procedure used to perform the Static PIM-RP Failover—Supervisor 22—Traffic Impact test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin sending a fixed stream of traffic.
Step 5
Reload SH1-104, the primary PIM-RP.
Step 6
Measure the traffic loss that occurs.
Step 7
Repeat the reload sequence four times, each time measuring traffic loss.
Step 8
Determine the average amount of traffic loss.
The raw traffic data was not saved for this test.
Step 9
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 10
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
78
Layer 3 Routing
Expected Results
•
We expect the average traffic loss resulting from the failover and recovery of the primary PIM-RP
to be acceptable.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 40 shows the Static PIM-RP Failover—Supervisor 22—Traffic Impact test results.
Table 40
Static PIM-RP Failover—Supervisor 22—Traffic Impact Test Results
Tests
Results
Static PIM-RP Failover—Supervisor 22—Traffic Impact
Pass
Basic IGMP Functionality
This test verified basic IGMP functionality.
Goals
•
Verify that IGMP entries are created on the proper devices for both Layer 3 and VLAN interfaces.
Primary Devices Used
•
SH1-106: Supervisor 11; VLAN 41; groups 239.100.3.[1-10]
•
SH1-105: Supervisor 11; Layer 3 interface on secondary subnet on non-PIM-DR (NDR); groups
239.100.1.[1-10]
•
SH1-110: Supervisor 22; VLAN 11; VLAN 16; Layer 3 interface on secondary subnet on PIM-DR;
groups 239.100.[1-2].[1-10]
•
SH1-102: Supervisor 22; VLAN 43; Layer 3 interface on PIM-DR; groups 239.100.3.[1-10]
•
SH1-109: Supervisor 22; Layer 3 interface on NDR; groups 239.100.1.[1-10]
Primary IXIA Ports Used
•
2/6, 1/1, 10/1, 11/1
Test Procedure
The procedure used to perform the Basic IGMP Functionality test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-102 has IGMP entries for groups 239.100.3.[1-10], which contain the correct interfaces.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
79
Layer 3 Routing
Step 5
Verify that SH1-105 has IGMP entries for groups 239.100.1.[1-10], which contain the correct interfaces.
Step 6
Verify that SH1-106 has IGMP entries for groups 239.100.3.[1-10], which contain the correct interfaces.
Step 7
Verify that SH1-109 has IGMP entries for groups 239.100.1.[1-10], which contain the correct interfaces.
Step 8
Verify that SH1-110 has IGMP entries for groups 239.100.1.[1-10], which contain the correct interfaces.
Step 9
Verify that SH1-110 has IGMP entries for groups 239.100.2.[1-10], which contain the correct interfaces.
Step 10
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect IGMP to function correctly on a variety of receiving interfaces, including VLANs, Layer
3 interfaces, and secondary subnets.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 41 shows the Basic IGMP Functionality test results.
Table 41
Basic IGMP Functionality Test Results
Tests
Results
Basic IGMP Functionality
Pass
IGMP Join/Leave Functionality
This test verified basic IGMP functionality.
Goals
•
Verify that IGMP leave requests are processed correctly on the router and that traffic is stopped.
•
Verify that IGMP join requests are processed correctly and that traffic is restarted.
Primary Devices Used
•
SH1-105: Supervisor 11; Layer 3 interface on secondary subnet on NDR; groups 239.100.1.[1-10]
•
SH1-108: Supervisor 12; VLAN 11; groups 239.100.1.[1-10]
•
SH1-110: Supervisor 22; Layer 3 interface on DR; groups 239.100.2.[1-10]
Primary IXIA Ports Used
•
1/1, 8/1, 12/2
Test Procedure
The procedure used to perform the IGMP Join/Leave Functionality 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(13)E11
80
Layer 3 Routing
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-105 has IGMP entries for groups 239.100.1.[1-10] with Gigabit Ethernet interface 3/2
listed as a receiver.
Step 5
Verify that SH1-105 has mroute entries for the groups 239.100.1.[1-10] and is forwarding traffic out the
appropriate interface.
Step 6
Turn on debugging for IGMP on SH1-105.
Step 7
Stop the IGMP protocol receiver on IXIA port 1/1, record any debugs, and verify that traffic to the
receiver has stopped.
Note
A small amount of background traffic may be seen still going to the receiver. It can be ignored for
this test.
Step 8
Start the IGMP protocol receiver on IXIA port 1/1, record any debugs, and verify that traffic is being
sent to the receiver again.
Step 9
Turn off all debugging on SH1-105.
Step 10
Verify that SH1-108 has IGMP entries for groups 239.100.1.[1-10] with interface VLAN 11 listed as
receiver.
Step 11
Verify that SH1-108 has mroute entries for the groups 239.100.1.[1-10] with VLAN 11 in the OIL, and
that the Dista-1 device is forwarding traffic out to the receiver.
Step 12
Turn on debugging for IGMP on SH1-107 and SH1-108.
Step 13
Stop the IGMP protocol receiver on IXIA port 8/1, record any debugs, and verify that traffic to the
receiver has stopped.
Note
SH1-107 is the IGMP Querier for VLAN 11, and so will also participate in the leave process for that
VLAN.
Step 14
Note
Start the IGMP protocol receiver on IXIA port 8/1, record any debugs, and verify that traffic is being
sent to the receiver again.
Because As SH1-107 is the IGMP Querier for VLAN 11, it is involved in the joining process for the
multicast test groups.
Step 15
Turn off all debugging on SH1-107 and SH1-108.
Step 16
Verify that SH1-110 has IGMP entries for groups 239.100.1.[1-10] with Gigabit Ethernet interface 8/16
listed as a receiver.
Step 17
Verify that SH1-110 has mroute entries for the groups 239.100.1.[1-10] and is forwarding traffic out the
appropriate Gigabit Ethernet interface 8/16.
Step 18
Turn on debugging for IGMP on SH1-110.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
81
Layer 3 Routing
Step 19
Stop the IGMP protocol receiver on IXIA port 12/2, record any debugs, and verify that traffic to the
receiver has stopped.
Step 20
Start the IGMP protocol receiver on IXIA port 12/2, record any debugs, and verify that traffic is being
sent to the receiver again.
Step 21
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 22
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the router to cease sending traffic to the receiver when the IGMP leaves are received and
processed.
•
We expect the router to process the new IGMP reports received and begin sending traffic to the
receiver again.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 42 shows the IGMP Join/Leave Functionality test results.
Table 42
IGMP Join/Leave Functionality Test Results
Tests
Results
IGMP Join/Leave Functionality
Pass
Multicast Stub and Non-Reverse Path Forwarding Rate Limiting—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 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 RPF failures by entering the mls ip multicast stub
command on the redundant router, the following ACLs automatically download to the PFC and were
applied to the interface you specify:
access-list
access-list
access-list
access-list
access-list
100
100
100
100
100
permit ip A.B.C.0 0.0.0.255 any
permit ip A.B.D.0 0.0.0.255 any
permit ip any 224.0.0.0 0.0.0.255
permit ip any 224.0.1.0 0.0.0.255
deny ip any 224.0.0.0 15.255.255.255
The ACLs filter RPF failures and drop them in hardware so that they were 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.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
82
Layer 3 Routing
In this part of the test, SH1-107 was configured to be the multicast stub router. Ten groups of multicast
traffic (groups 239.100.1.1 through 239.100.1.10) 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 was used.
Coupled with the mls ip multicast stub command on SH1-107 was 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.
Devices under test: SH1-107, SH1-108, SH1-104
Test Procedure
The procedure used to perform the Multicast Stub and Non-Reverse Path Forwarding Rate
Limiting—Supervisor 1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
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
portchannel 68. 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 7
Begin the IXIA traffic stream. This is multicast test traffic stream A sending from 10 incrementing IP
sources to 10 multicast groups, 230.100.1.[1-10]. It will send 5 minutes of traffic at 1000 pps.
Step 8
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 9
Verify that RPF rate-limiting is done in hardware on the stub router.
Step 10
Determine the path of traffic to the receiver, starting at SH1-104 (the rendezvous point).
Step 11
Verify that 100 percent of the multicast traffic that was sent is received on the appropriate port (zero
packet loss).
Step 12
Negate the commands configured in Step 4 through Step 6.
Step 13
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 14
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
83
Layer 3 Routing
Expected Results
•
We expect SH1-107 to act as a multicast stub router and forward IGMP packets to its helper address,
on SH1-104.
•
We expect SH1-104 to receive and process the IGMP packets sent by SH1-107.
•
We expect SH1-104 to not have SH1-107 listed in its PIM neighbor table, when the neighbor-filter
command is configured.
•
We expect rate-limiting of non-RPF failures to be done in hardware.
•
We expect all traffic sent to be received by the appropriate receiver(s), following the correct path.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 43 shows the Multicast Stub and Non-Reverse Path Forwarding Rate Limiting—Supervisor 1 test
results.
Table 43
Multicast Stub and Non-RPF Rate Limiting—Supervisor 1 Test Results
Tests
Results
Multicast Stub and Non-Reverse Path Forwarding Rate Limiting—Supervisor 1 Pass
Multicast Stub and Non-Reverse Path Forwarding Rate Limiting—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 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 RPF failures by entering the mls ip multicast stub
command on the redundant router, the following ACLs automatically download to the PFC and were
applied to the interface you specify:
access-list
access-list
access-list
access-list
access-list
100
100
100
100
100
permit ip A.B.C.0 0.0.0.255 any
permit ip A.B.D.0 0.0.0.255 any
permit ip any 224.0.0.0 0.0.0.255
permit ip any 224.0.1.0 0.0.0.255
deny ip any 224.0.0.0 15.255.255.255
The ACLs filter RPF failures and drop them in hardware so that they were 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. Ten groups of multicast
traffic (groups 239.100.1.1 through 239.100.1.10) 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 were 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 was
used.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
84
Layer 3 Routing
Coupled with the mls ip multicast stub command on SH1-109 was 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.
Devices under test: SH1-109, SH1-110, SH1-104
Test Procedure
The procedure used to perform the Multicast Stub and Non-Reverse Path Forwarding Rate
Limiting—Supervisor 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
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.
Step 6
Configure SH1-104 to filter out IP PIM neighbor updates coming from SH1-109 on the interface
portchannel 70. 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).
Step 7
Begin the IXIA traffic stream. This is multicast test traffic stream A sending from 10 incrementing IP
sources to 10 multicast groups, 230.100.1.[1-10]. It will send 5 minutes of traffic at 1000 pps.
Step 8
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 9
Verify that RPF rate-limiting is done in hardware on the stub router.
Step 10
Determine the path of traffic to the receiver, starting at SH1-104 (the rendezvous point).
Step 11
Verify that 100 percent of the multicast traffic that was sent is received on the appropriate port (zero
packet loss).
Step 12
Negate the commands configured in Step 4 through Step 6.
Step 13
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 14
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect SH1-109 to act as a multicast stub router and forward IGMP packets to its helper address,
on SH1-104.
•
We expect SH1-104 to receive and process the IGMP packets sent by SH1-109.
•
We expect SH1-104 to not have SH1-109 listed in its PIM neighbor table, when the neighbor-filter
command is configured.
•
We expect rate-limiting of non-RPF failures to be done in hardware.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
85
Layer 3 Routing
•
We expect all traffic sent to be received by the appropriate receiver(s), following the correct path.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 44 shows the Multicast Stub and Non-Reverse Path Forwarding Rate Limiting—Supervisor 2 test
results.
Table 44
Multicast Stub and Non-RPF Rate Limiting—Supervisor 2 Test Results
Tests
Results
Multicast Stub and Non-Reverse Path Forwarding Rate Limiting—Supervisor 2 Pass
Layer 2 GEC Failover—SH1-110 to Dista-2
This test verified the ability of the devices to recover from a Layer 2 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 20 on SH1-110 was failed. It consists of four
ports spread evenly over two WS-X6516-GBIC modules.
Goals
•
Verify that the NDR, SH1-109, builds the correct multicast routing states when the DR, SH1-110,
is severed from the Layer 2 device, Dista-2.
•
Verify that SH1-109 takes over the first hop router role from SH1-110.
•
Verify that SH1-110 resumes the first hop router and PIM-DR roles when the GEC is brought back
up.
•
Verify that traffic loss is minimal.
Primary Devices Used
•
SH1-110: Supervisor 22; last-hop router for groups 239.100.[1-2].[1-10]; last-hop router (DR) for
groups 239.100.3.[1-10].
•
SH1-109: Supervisor 22; will take over first- and last-hop router roles from SH1-110 for the groups
Primary IXIA Ports Used
•
All
Test Procedure
The procedure used to perform the Layer 2 GEC Failover—SH1-110 to Dista-2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-110 is beginning the procedure with the correct multicast routing states.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
86
Layer 3 Routing
Step 5
Verify that SH1-110 is passing traffic both ways over all four interfaces in portchannel 20.
Step 6
Begin sending a fixed stream of traffic
Step 7
Shut down portchannel 20 on SH1-110.
Step 8
Verify that SH1-109 builds the correct multicast routing states as the new first- and last-hop router for
the various groups.
Step 9
Measure traffic loss due to the EtherChannel failure.
Step 10
Bring portchannel 20 of SH1-110 back online.
Step 11
With traffic running continuously, verify that SH1-110 again builds the correct multicast routing states
for the 30 test groups.
Step 12
Verify that all four interfaces in portchannel 20 are passing traffic.
Step 13
Verify that the CBL values for SH1-110 portchannel 20 show forwarding state for all four interfaces.
Step 14
Repeat the failover sequence four times with a fixed amount of traffic, each time measuring the traffic
loss caused by the failover.
Step 15
Determine the average amount of traffic loss over the five failovers.
Step 16
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 17
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic to failover and be forwarded by SH1-109 when portchannel 20 between SH1-110
and Dista-2 is torn down.
•
We expect this failover to take place in a reasonable time (within the 10-sec HSRP dead timer value
for local receivers and within the 40 sec OSPF dead time for remote receivers).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
•
All traffic was sent by SH1-109, correctly, within a reasonable time (average about 8 sec over 5
iterations for local receivers and about 18 sec for remote receivers).
Results
Table 45 shows the Layer 2 GEC Failover—SH1-110 to Dista-2 test results.
Table 45
Layer 2 GEC Failover—SH1-110 to Dista-2 Test Results
Tests
Results
Layer 2 GEC Failover—SH1-110 to Dista-2
Pass
Layer 2 GEC Failover—SH1-108 to Dista-1
This test verified the ability of the devices to recover from a Layer 2 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 10 on SH1-108 was failed. It consists of four
ports, all on a single WS-X6408-GBIC module.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
87
Layer 3 Routing
Goals
•
Verify that the NDR, SH1-107, builds the correct multicast routing states when the DR, SH1-108,
is severed from the Layer 2 device, Dista-1.
•
Verify that SH1-108 resumes the PIM-DR role when the GEC is brought back up.
•
Verify that traffic loss is minimal.
Primary Devices Used
•
SH1-108: Supervisor 12; last-hop router (DR) for groups 239.100.[1,3].[1-10]
•
SH1-107: Supervisor 12; will take over last-hop router role from SH1-108 for the groups.
Primary IXIA Ports Used
•
All
Test Procedure
The procedure used to perform the Layer 2 GEC Failover—SH1-108 to Dista-1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-108 is beginning the procedure with the correct multicast routing states.
Step 5
Verify that SH1-108 is passing traffic both ways over all four interfaces in portchannel 10.
Step 6
Begin sending a fixed stream of traffic.
Step 7
Shut down portchannel 10 on SH1-108.
Step 8
Verify that SH1-107 builds the correct multicast routing states as the new last-hop router for the various
groups.
Step 9
Measure traffic loss due to the EtherChannel failure.
Step 10
Bring portchannel 10 of SH1-108 back online.
Step 11
With traffic running continuously, verify that SH1-108 again builds the correct multicast routing states
for the 10 test groups.
Step 12
Verify that all four interfaces in portchannel 10 are passing traffic.
Step 13
Verify that the CBL values for SH1-108 portchannel 10 show forwarding state for all four interfaces.
Step 14
Repeat the failover sequence four times with a fixed amount of traffic, each time measuring the traffic
loss caused by the failover.
Step 15
Determine the average amount of traffic loss over the five failovers.
Step 16
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
88
Layer 3 Routing
Step 17
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic to failover and be forwarded by SH1-107 when the portchannel between SH1-108
and SH1-104 is torn down.
•
We expect this failover to take place in a reasonable time (within the 10-sec HSRP dead timer value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 46 shows the Layer 2 GEC Failover—SH1-108 to Dista-1 test results.
Table 46
Layer 2 GEC Failover—SH1-108 to Dista-1 2 Test Results
Tests
Results
Layer 2 GEC Failover—SH1-108 to Dista-1
Pass
Layer 2 GEC Failover—SH1-114 to Dista-1
This test verified the ability of the devices to recover from a Layer 2 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 10 on SH1-114 was failed. It consists of four
ports spread evenly over two WS-X6516-GBIC modules.
Goals
•
Verify that the NDR, SH1-113, builds the correct multicast routing states when the DR, SH1-114,
is severed from the Layer 2 device, Dista-1.
•
Verify that SH1-113 takes over the first hop router role from SH1-114.
•
Verify that SH1-114 resumes the first hop router role when the GEC is brought back up.
•
Verify that traffic loss is minimal.
Primary Devices Used
•
SH1-114: Supervisor 12; first hop router for groups 239.100.1.[1-10]
•
SH1-113: Supervisor 12; will take over first hop router role from SH1-110 for the groups.
Primary IXIA Ports Used
•
All
Test Procedure
The procedure used to perform the Layer 2 GEC Failover—SH1-114 to Dista-1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
89
Layer 3 Routing
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-114 is beginning the procedure with the correct multicast routing states.
Step 5
Verify that SH1-114 is passing traffic both ways over all four interfaces in portchannel 10.
Step 6
Begin sending a fixed stream of traffic.
Step 7
Shut down portchannel 10 on SH1-114.
Step 8
Verify that SH1-113 builds the correct multicast routing states as the new first hop and last hop router
for the various groups.
Step 9
Measure traffic loss due to the EtherChannel failure.
Step 10
Bring portchannel 10 of SH1-114 back online.
Step 11
With traffic running continuously, verify that SH1-114 again builds the correct multicast routing states
for the 30 test groups.
Step 12
Verify that all four interfaces in portchannel 10 are passing traffic.
Step 13
Verify that the CBL values for SH1-114 portchannel 10 show forwarding state for all four interfaces.
Step 14
Repeat the failover sequence four times with a fixed amount of traffic, each time measuring the traffic
loss caused by the failover.
Step 15
Determine the average amount of traffic loss over the five failovers.
Step 16
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 17
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic to failover and be forwarded by SH1-113 with the correct multicast routing states
when the DR, SH1-114, is severed from the Layer 2 device, Dista-1.
•
We expect this failover to take place in a reasonable time (within the 10 sec HSRP dead timer value
for local receivers and within the 40 sec OSPF dead time for remote receivers).
•
We expect that SH1-114 will take over again when the GEC (Po10) is brought back up.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 47 shows the Layer 2 GEC Failover—SH1-114 to Dista-1 test results.
Table 47
Layer 2 GEC Failover—SH1-114 to Dista-1 Test Results
Tests
Results
Layer 2 GEC Failover—SH1-114 to Dista-1
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
90
Layer 3 Routing
Layer 2 GEC Failover—SH1-106 to Dista-2
This test verified the ability of the devices to recover from a Layer 2 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 20 on SH1-106 was failed. It consists of two
ports on a WS-X6408-GBIC module.
Goals
•
Verify that the NDR, SH1-105, builds the correct multicast routing states when the DR, SH1-106,
is severed from the Layer 2 device, Dista-2.
•
Verify that SH1-105 takes over the first hop router role from SH1-106.
•
Verify that SH1-110 resumes the first hop router and PIM-DR roles when the GEC is brought back
up.
•
Verify that traffic loss is minimal.
Primary Devices Used
•
SH1-106: Supervisor 11; first hop router for groups 239.100.2.[1-10]; last-hop router (DR) for
groups 239.100.3.[1-10]
•
SH1-105: Supervisor 11; will take over first- and last-hop router roles from SH1-106 for the groups
Primary IXIA Ports Used
•
All
Test Procedure
The procedure used to perform the Layer 2 GEC Failover—SH1-106 to Dista-2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-106 is beginning the procedure with the correct multicast routing states.
Step 5
Verify that SH1-106 is passing traffic both ways over both interfaces in portchannel 20.
Step 6
Begin sending a fixed stream of traffic.
Step 7
Shut down portchannel 20 on SH1-106.
Step 8
Verify that SH1-105 builds the correct multicast routing states as the new first- and last-hop router for
the various groups.
Step 9
Measure traffic loss due to the EtherChannel failure.
Step 10
Bring portchannel 20 of SH1-106 back online.
Step 11
With traffic running continuously, verify that SH1-106 again builds the correct multicast routing states
for the 20 test groups.
Step 12
Verify that both interfaces in portchannel 20 are passing traffic.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
91
Layer 3 Routing
Step 13
Verify that the CBL values for SH1-106 portchannel 20 show forwarding state for both interfaces.
Step 14
Repeat the failover sequence four times with a fixed amount of traffic, each time measuring the traffic
loss caused by the failover.
Step 15
Determine the average amount of traffic loss over the five failovers.
Step 16
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 17
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic to failover and be forwarded by SH1-105 when DR, SH1-106, is severed from the
Layer 2 device, Dista-2.
•
We expect that SH1-106 resumes the PIM-DR role when the GEC (Po20) is brought back up
•
We expect this failover to take place in a reasonable time (within the 10-sec HSRP dead timer value
for local receivers and within 40 second OSPF dead time for remote receivers)
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 48 shows the Layer 2 GEC Failover—SH1-106 to Dista-2 test results.
Table 48
Layer 2 GEC Failover—SH1-106 to Dista-2 Test Results
Tests
Results
Layer 2 GEC Failover—SH1-106 to Dista-2
Pass
Layer 2 GEC Failover—SH1-102 to Dista-1
This test verified the ability of the devices to recover from a Layer 2 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 10 on SH1-102 was failed. It consists of two
ports on a WS-X6516-GBIC module.
Goals
•
Verify that the NDR, SH1-101, builds the correct multicast routing states when the DR, SH1-102,
is severed from the Layer 2 device, Dista-2.
•
Verify that SH1-102 resumes the PIM-DR role when the GEC is brought back up.
•
Verify that traffic loss is minimal.
Primary Devices Used
•
SH1-102: Supervisor 22; last-hop router for groups 239.100.[1-3].[1-10]
•
SH1-101: Supervisor 22; will take over last-hop router role from SH1-102 for the groups.
Primary IXIA Ports Used
•
All
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
92
Layer 3 Routing
Test Procedure
The procedure used to perform the Layer 2 GEC Failover—SH1-102 to Dista-1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-102 is beginning the procedure with the correct multicast routing states.
Step 5
Verify that SH1-102 is passing multicast traffic both ways over both interfaces in portchannel 10.
Step 6
Begin sending a fixed stream of traffic.
Step 7
Shut down portchannel 10 on SH1-102.
Step 8
Verify that SH1-101 builds the correct multicast routing states as the new last-hop router for the various
groups.
Step 9
Measure traffic loss due to the EtherChannel failure.
Step 10
Bring portchannel 10 of SH1-102 back online.
Step 11
With traffic running continuously, verify that SH1-102 again builds the correct multicast routing states
for the 30 test groups.
Step 12
Verify that both interfaces in portchannel 10 are passing traffic.
Step 13
Verify that the CBL values for SH1-102 portchannel 10 show forwarding state for both interfaces.
Step 14
Repeat the failover sequence four times with a fixed amount of traffic, each time measuring the traffic
loss caused by the failover.
Step 15
Determine the average amount of traffic loss over the five failovers.
Step 16
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 17
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic to failover and be forwarded by SH1-101 when DR, SH1-102, is severed from the
Layer 2 device, Dista-2.
•
We expect that SH1-102 resumes the PIM-DR role when the GEC (Po10) is brought back up
•
We expect this failover to take place in a reasonable time (within the 10-sec HSRP dead timer value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 49 shows the Layer 2 GEC Failover—SH1-102 to Dista-1 test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
93
Layer 3 Routing
Table 49
Layer 2 GEC Failover—SH1-102 to Dista-1 Test Results
Tests
Results
Layer 2 GEC Failover—SH1-102 to Dista-1
Pass
Layer 3 GEC Failover—SH1-104 to SH1-110
This test verified the ability of the devices to recover from a Layer 3 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 171 on SH1-110 was failed. It consists of four
ports spread evenly over two WS-X6816-GBIC modules.
Goals
•
Verify that devices SH1-103, SH1-104, SH1-109, and SH1-110 maintain correct multicast routing
states for the various groups during the EtherChannel failure and after it was reestablished.
•
Verify that traffic loss is minimal.
Primary Devices Used
•
SH1-110: Supervisor 22; first hop router for groups 239.100.3.[1-10]; last-hop router (DR) for
groups 239.100.[1-2].[1-10]
•
SH1-104: Supervisor 22; transit router for groups 239.100.[1-3].[1-10]
•
SH1-103: Supervisor 22; new transit router for groups 239.100.[1-3].[1-10] after GEC failover
•
SH1-109: Supervisor 22; new last-hop router for groups 239.100.[1-2].[1-10] after GEC failover
Primary IXIA Ports Used
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-104 to SH1-110 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-110 is beginning the procedure with the correct multicast routing states.
Step 5
Verify that SH1-104 is beginning the procedure with the correct multicast routing states.
Step 6
Verify that SH1-110 is passing traffic both ways over all four interfaces in portchannel 171.
Step 7
Begin sending a fixed stream of traffic.
Step 8
Shut down portchannel 171 on SH1-110.
Step 9
Verify that SH1-110 builds the correct multicast routing states.
Step 10
Verify that SH1-104 builds the correct multicast routing states.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
94
Layer 3 Routing
Step 11
Measure traffic loss due to the EtherChannel failure.
Step 12
Bring portchannel 171 of SH1-110 back online.
Step 13
With traffic running continuously, verify that SH1-110 again builds the correct multicast routing states
for the 30 test groups.
Step 14
Verify that SH1-104 again builds the correct multicast routing states for the test groups.
Step 15
Verify that all four interfaces in portchannel 171 are passing traffic.
Step 16
Repeat the failover sequence four times with a fixed amount of traffic, each time measuring the traffic
loss caused by the failover.
Step 17
Determine the average amount of traffic loss over the five failovers.
Step 18
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 19
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic to failover and be forwarded by SH1-103 when the portchannel between SH1-110
and SH1-104 is torn down.
•
We expect this failover to take place in a reasonable time (within the 40 sec OSPF dead timer value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 50 shows the Layer 3 GEC Failover—SH1-104 to SH1-110 test results.
Table 50
Layer 3 GEC Failover—SH1-104 to SH1-110 Test Results
Tests
Results
Layer 3 GEC Failover—SH1-104 to SH1-110
Pass
Layer 3 GEC Failover—SH1-104 to SH1-109
This test verified the ability of the devices to recover from a Layer 3 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 170 on SH1-109 was failed. It consists of four
ports spread evenly over two WS-X6816-GBIC modules.
Goals
•
Verify that the devices SH1-104, SH1-103, and SH1-109 build the correct multicast routing states
when the GEC is failed and brought back up.
•
Verify that traffic loss is minimal.
Primary Devices Used
•
SH1-104: Supervisor 22; transit router for groups 239.100.1.[1-10]
•
SH1-109: Supervisor 22; last-hop router for groups 239.100.[1,3].[1-10]
•
SH1-103: Supervisor 22; after failover, transit router for groups 239.100.1.[1-10]
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
95
Layer 3 Routing
Primary IXIA Ports Used
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-104 to SH1-109 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-109 is beginning the procedure with the correct multicast routing states.
Step 5
Verify that SH1-110 is beginning the procedure with the correct multicast routing states.
Step 6
Verify that SH1-104 is beginning the procedure with the correct multicast routing states.
Step 7
Verify that SH1-103 is beginning the procedure with the correct multicast routing states.
Step 8
Verify that traffic is coming in on all four interfaces in portchannel 170 on SH1-109.
Step 9
Begin sending a fixed stream of traffic.
Step 10
Shut down portchannel 170 on SH1-109.
Step 11
Verify that SH1-109 builds the correct multicast routing states following the GEC failure.
Step 12
Verify that SH1-110 builds the correct multicast routing states following the GEC failure.
Step 13
Verify that SH1-103 builds the correct multicast routing states following the GEC failure.
Step 14
Verify that SH1-104 builds the correct multicast routing states following the GEC failure.
Step 15
Measure traffic loss due to the EtherChannel failure.
Step 16
Bring portchannel 170 of SH1-109 back online.
Step 17
With traffic running continuously, verify that SH1-109 again builds the correct multicast routing states
for the 20 test groups.
Step 18
With traffic running continuously, verify that SH1-110 again builds the correct multicast routing states
for the 20 test groups.
Step 19
Verify that SH1-104 again builds the correct multicast routing states for the test groups.
Step 20
Verify that SH1-103 again builds the correct multicast routing states for the test groups.
Step 21
Verify that all four interfaces in portchannel 170 are passing traffic.
Step 22
Repeat the failover sequence four times with a fixed amount of traffic, each time measuring the traffic
loss caused by the failover.
Step 23
Determine the average amount of traffic loss over the five failovers.
Step 24
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
96
Layer 3 Routing
Step 25
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic to failover and be forwarded by SH1-103 when the portchannel between SH1-109
and SH1-104 is torn down.
•
We expect this failover to take place in a reasonable time (within the 40 sec OSPF dead timer value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 51 shows the Layer 3 GEC Failover—SH1-104 to SH1-109 test results.
Table 51
Layer 3 GEC Failover—SH1-104 to SH1-109 Test Results
Tests
Results
Layer 3 GEC Failover—SH1-104 to SH1-109
Pass
Layer 3 GEC Failover—SH1-104 to SH1-108
This test verified the ability of the devices to recover from a Layer 3 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 169 on SH1-108 was failed. It consists of four
ports spread evenly over two WS-X6408-GBIC modules.
Goals
•
Verify that devices SH1-108, SH1-104, and SH1-103 build the correct multicast routing states
following the GEC failure and recovery.
•
Verify that traffic loss is minimal.
Primary Devices Used
•
SH1-108: Supervisor 12; last-hop router for groups 239.100.[1-2].[1-10]
•
SH1-104: Supervisor 22; transit router for groups 239.100.[1-2].[1-10]
•
SH1-103: Supervisor 22; new transit router for groups 239.100.[1-2].[1-10] following the GEC
failover
Primary IXIA Ports Used
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-104 to SH1-108 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the
box has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
97
Layer 3 Routing
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-108 is beginning the procedure with the correct multicast routing states.
Step 5
Verify that SH1-104 is beginning the procedure with the correct multicast routing states.
Step 6
Verify that SH1-108 is passing traffic both ways over all four interfaces in portchannel 169.
Step 7
Begin sending a fixed stream of traffic
Step 8
Shut down portchannel 169 on SH1-108.
Step 9
Verify that SH1-108 builds the correct multicast routing states.
Step 10
Verify that SH1-103 builds the correct multicast routing states as the new first- and last-hop router for
the various groups.
Step 11
Measure traffic loss due to the EtherChannel failure.
Step 12
Bring portchannel 169 of SH1-108 back online.
Step 13
With traffic running continuously, verify that SH1-108 again builds the correct multicast routing states
for the 20 test groups.
Step 14
Verify that SH1-104 again builds the correct multicast routing states for the test groups.
Step 15
Verify that all four interfaces in portchannel 169 are passing traffic.
Step 16
Repeat the failover sequence four times with a fixed amount of traffic, each time measuring the traffic
loss caused by the failover.
Step 17
Determine the average amount of traffic loss over the five failovers.
Step 18
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 19
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic to failover and be forwarded through RP SH1-103 when the portchannel between
SH1-108 and SH1-104 is torn down.
•
We expect this failover to take place in a reasonable time (within the 40 sec default OSPF dead time
value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 52 shows the Layer 3 GEC Failover—SH1-104 to SH1-108 test results.
Table 52
Layer 3 GEC Failover—SH1-104 to SH1-108 Test Results
Tests
Results
Layer 3 GEC Failover—SH1-104 to SH1-108
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
98
Layer 3 Routing
Layer 3 GEC Failover—SH1-104 to SH1-107
This test verified the ability of the devices to recover from a Layer 3 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 168 on SH1-107 was failed. It consists of four
ports spread evenly over two WS-X6408-GBIC modules.
Goals
•
Verify that the devices SH1-107, SH1-104, and SH1-103 build the correct multicast routing states
to cope with the failure and recovery.
•
Verify that traffic loss is minimal.
Primary Devices Used
•
SH1-107: Supervisor 12; last-hop router for groups 239.100.2.[1-10]
•
SH1-104: Supervisor 22; transit router for groups 239.100.2.[1-10]
•
SH1-103: Supervisor 22; new transit router for groups 239.100.2.[1-10] following the GEC failure
Primary IXIA Ports Used
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-104 to SH1-107 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-107 is beginning the procedure with the correct multicast routing states.
Step 5
Verify that SH1-104 is beginning the procedure with the correct multicast routing states.
Step 6
Verify that SH1-107 is passing traffic both ways over all four interfaces in portchannel 168.
Step 7
Begin sending a fixed stream of traffic
Step 8
Shut down portchannel 168 on SH1-107.
Step 9
Verify that SH1-107 builds the correct multicast routing states following the GEC failure.
Step 10
Verify that SH1-103 builds the correct multicast routing states following the GEC failure.
Step 11
Measure traffic loss due to the EtherChannel failure.
Step 12
Bring portchannel 168 of SH1-107 back online.
Step 13
With traffic running continuously, verify that SH1-107 again builds the correct multicast routing states
for the 10 test groups.
Step 14
Verify that SH1-104 again builds the correct multicast routing states for the test groups.
Step 15
Verify that all four interfaces in portchannel 168 are passing traffic.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
99
Layer 3 Routing
Step 16
Repeat the failover sequence four times with a fixed amount of traffic, each time measuring the traffic
loss caused by the failover.
Step 17
Determine the average amount of traffic loss over the five failovers.
Step 18
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 19
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic to failover and be forwarded through RP SH1-103 when the portchannel between
SH1-107 and SH1-104 is torn down.
•
We expect this failover to take place in a reasonable time (within the 40 sec default OSPF dead time
value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 53 shows the Layer 3 GEC Failover—SH1-104 to SH1-107 test results.
Table 53
Layer 3 GEC Failover—SH1-104 to SH1-107 Test Results
Tests
Results
Layer 3 GEC Failover—SH1-104 to SH1-107
Pass
Layer 3 GEC Failover—SH1-100 to SH1-104
This test verified the ability of the devices to recover from a Layer 3 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 117 on SH1-104 was failed.
Goals
•
Verify that the devices SH1-104, SH1-100, and SH1-99 maintain the correct multicast routing states
during the GEC failover.
•
Verify that traffic loss is minimal.
Primary Devices Used
•
SH1-104: Supervisor 22; transit router for groups 239.100.[1-3].[1-10]
•
SH1-100: Supervisor 22; elected RP for groups 239.100.0.0/16
•
SH1-99: Supervisor 22; backup RP for groups 239.100.0.0/16
Primary IXIA Ports Used
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-100 to SH1-104 test follows:
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
100
Layer 3 Routing
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-104 is beginning the procedure with the correct multicast routing states.
Step 5
Verify that SH1-100 is beginning with the correct multicast routing states.
Step 6
Verify that SH1-104 is passing traffic both ways over all four interfaces in portchannel 114.
Step 7
Begin sending a fixed stream of traffic
Step 8
Shut down portchannel 117 on SH1-104.
Step 9
Verify that SH1-103 builds the correct multicast routing state to the backup RP, SH1-99.
Step 10
Verify that SH1-99 builds the correct routing state down to SH1-103.
Step 11
Verify that SH1-100 builds the correct routing state from SH1-103.
Step 12
Measure traffic loss due to the EtherChannel failure.
Step 13
Bring portchannel 117 of SH1-104 back online.
Step 14
With traffic running continuously, verify that SH1-104 again builds the correct multicast routing states
for the 30 test groups.
Step 15
Verify that SH1-100 again builds the correct multicast routing states.
Step 16
Verify that all four interfaces in portchannel 117 are passing traffic.
Step 17
Repeat the failover sequence four times with a fixed amount of traffic, each time measuring the traffic
loss caused by the failover.
Step 18
Determine the average amount of traffic loss over the five failovers.
Step 19
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 20
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic to failover and be forwarded through RP SH1-99 when the portchannel between
SH1-104 and SH1-100 is torn down.
•
We expect this failover to take place in a reasonable time (within the 40 sec default OSPF dead time
value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 54 shows the Layer 3 GEC Failover—SH1-100 to SH1-104 test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
101
Layer 3 Routing
Table 54
Layer 3 GEC Failover—SH1-100 to SH1-104 Test Results
Tests
Results
Layer 3 GEC Failover—SH1-100 to SH1-104
Pass
Layer 3 GEC Failover—SH1-100 to SH1-113
This test verified the ability of the devices to recover from a Layer 3 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 164 on SH1-113 was failed.
Goals
•
Verify that the devices SH1-113, SH1-100, and SH1-99 maintain the correct multicast routing states
during the GEC failover.
•
Verify that traffic loss is minimal.
Primary Devices Used
•
SH1-113: Supervisor 12; last-hop router for groups 239.100.3.[1-10]
•
SH1-100: Supervisor 22; elected RP for groups 239.100.0.0/16
•
SH1-99: Supervisor 22; backup RP for groups 239.100.0.0/16
Primary IXIA Ports Used
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-100 to SH1-113 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-113 is beginning the procedure with the correct multicast routing states.
Step 5
Verify that SH1-100 is beginning with the correct multicast routing states.
Step 6
Verify that SH1-113 is passing traffic both ways over all four interfaces in portchannel 164.
Step 7
Begin sending a fixed stream of traffic
Step 8
Shut down portchannel 164 on SH1-113.
Step 9
Verify that SH1-113 builds the correct multicast routing state to the backup RP, SH1-99.
Step 10
Verify that SH1-99 builds the correct routing state down to SH1-113.
Step 11
Measure traffic loss due to the EtherChannel failure.
Step 12
Bring portchannel 164 of SH1-113 back online.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
102
Layer 3 Routing
Step 13
With traffic running continuously, verify that SH1-113 again builds the correct multicast routing states
for the 10 test groups.
Step 14
Verify that SH1-100 again builds the correct multicast routing states.
Step 15
Verify that both interfaces in portchannel 164 are passing traffic.
Step 16
Repeat the failover sequence four times with a fixed amount of traffic, each time measuring the traffic
loss caused by the failover.
Step 17
Determine the average amount of traffic loss over the five failovers.
Step 18
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 19
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic to failover and be forwarded through RP SH1-99 when the portchannel between
SH1-113 and SH1-100 is torn down.
•
We expect this failover to take place in a reasonable time (within the 40 sec default OSPF dead time
value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 55 shows the Layer 3 GEC Failover—SH1-100 to SH1-113 test results.
Table 55
Layer 3 GEC Failover—SH1-100 to SH1-113 Test Results
Tests
Results
Layer 3 GEC Failover—SH1-100 to SH1-113
Pass
Layer 3 GEC Failover—SH1-100 to SH1-106
This test verified the ability of the devices to recover from a Layer 3 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 167 on SH1-106 was failed.
Goals
•
Verify that the devices SH1-106, SH1-100, and SH1-99 maintain the correct multicast routing states
during the GEC failover.
•
Verify that traffic loss is minimal.
Primary Devices Used
•
SH1-106: Supervisor 11; last-hop router for groups 239.100.3.[1-10]; first hop router for groups
239.100.2.[1-10]
•
SH1-100: Supervisor 22; elected RP for groups 239.100.1.[1-10]
•
SH1-99: Supervisor 22; backup RP for groups 239.100.1.[1-10]
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
103
Layer 3 Routing
Primary IXIA Ports Used
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-100 to SH1-106 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-106 is beginning the procedure with the correct multicast routing states.
Step 5
Verify that SH1-100 is beginning with the correct multicast routing states.
Step 6
Verify that SH1-106 is passing traffic both ways over both interfaces in portchannel 167.
Step 7
Begin sending a fixed stream of traffic
Step 8
Shut down portchannel 167 on SH1-106.
Step 9
Verify that SH1-106 builds the correct multicast routing state to the backup RP, SH1-99.
Step 10
Verify that SH1-105 takes over the role of first hop router for the 239.100.2.x groups. This occurs
because of the equal cost paths to SH1-100 from both SH1-105 and SH1-106. This causes SH1-100 to
remain the preferred PIM DR through SH1-105 for 239.100.2.x groups rather than use SH1-99 through
SH1-106 after portchannel 167 on SH1-106 is shut down.
Step 11
Verify that SH1-99 builds the correct routing state down to SH1-106.
Step 12
Verify that SH1-100 knows SH1-105 as the first hop router for groups 239.100.2.[1-10].
Step 13
Measure traffic loss due to the EtherChannel failure.
Step 14
Bring portchannel 167 of SH1-106 back online.
Step 15
With traffic running continuously, verify that SH1-106 again builds the correct multicast routing states
for the 20 test groups.
Step 16
Verify that SH1-100 again builds the correct multicast routing states.
Step 17
Verify that both interfaces in portchannel 167 are passing traffic.
Step 18
Repeat the failover sequence four times with a fixed amount of traffic, each time measuring the traffic
loss caused by the failover.
Step 19
Determine the average amount of traffic loss over the five failovers.
Step 20
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 21
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
104
Layer 3 Routing
Expected Results
•
We expect traffic to failover and be forwarded through RP SH1-99 when the portchannel between
SH1-106 and SH1-100 is torn down.
•
We expect this failover to take place in a reasonable time (within the 40 sec default OSPF dead time
value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 56 shows the Layer 3 GEC Failover—SH1-100 to SH1-106 test results.
Table 56
Layer 3 GEC Failover—SH1-100 to SH1-106 Test Results
Tests
Results
Layer 3 GEC Failover—SH1-100 to SH1-106
Pass
Layer 3 GEC Failover—SH1-100 to SH1-105
This test verified the ability of the devices to recover from a Layer 3 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 166 on SH1-105 was failed.
Goals
•
Verify that the devices SH1-105, SH1-100, and SH1-99 maintain the correct multicast routing states
during the GEC failover.
•
Verify that traffic loss is minimal.
Primary Devices Used
•
SH1-105: Supervisor 11; last-hop router for groups 239.100.1.[1-10]
•
SH1-100: Supervisor 22; elected RP for groups 239.100.0.0/16
•
SH1-99: Supervisor 22; backup RP for groups 239.100.0.0/16
•
SH1-99 and SH1-100 are sharing the RP Anycast address 172.31.0.100; but SH1-100 is the elected
RP for groups 239.100.0.0/16 because it has the higher IP address
Primary IXIA Ports Used
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-100 to SH1-105 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the
box has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
105
Layer 3 Routing
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-105 is beginning the procedure with the correct multicast routing states.
Step 5
Verify that SH1-100 is beginning with the correct multicast routing states.
Step 6
Verify that SH1-105 is passing traffic both ways over all four interfaces in portchannel 166.
Step 7
Begin sending a fixed stream of traffic
Step 8
Shut down portchannel 166 on SH1-105.
Step 9
Verify that SH1-105 builds the correct multicast routing state to the backup RP, SH1-99.
Step 10
Verify that SH1-99 builds the correct routing state down to SH1-105.
Step 11
Measure traffic loss due to the EtherChannel failure.
Step 12
Bring portchannel 166 of SH1-105 back online.
Step 13
With traffic running continuously, verify that SH1-105 again builds the correct multicast routing states
for the 10 test groups.
Step 14
Verify that SH1-100 again builds the correct multicast routing states.
Step 15
Verify that both interfaces in portchannel 166 are passing traffic.
Step 16
Repeat the failover sequence four times with a fixed amount of traffic, each time measuring the traffic
loss caused by the failover.
Step 17
Determine the average amount of traffic loss over the five failovers.
Step 18
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 19
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic to failover and be forwarded through RP SH1-99 when the portchannel between
SH1-105 and SH1-100 is torn down.
•
We expect this failover to take place in a reasonable time (within the 40 sec default OSPF dead time
value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 57 shows the Layer 3 GEC Failover—SH1-100 to SH1-105 test results.
Table 57
Layer 3 GEC Failover—SH1-100 to SH1-105 Test Results
Tests
Results
Layer 3 GEC Failover—SH1-100 to SH1-105
Pass
Layer 3 GEC Failover—SH1-100 to SH1-102
This test verified the ability of the devices to recover from a Layer 3 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 115 on SH1-102 was failed.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
106
Layer 3 Routing
Goals
•
Verify that the devices SH1-102, SH1-100, and SH1-99 maintain the correct multicast routing states
during the GEC failover.
•
Verify that traffic loss is minimal.
Primary Devices Used
•
SH1-102: Supervisor 22; last-hop router for groups 239.100.[1-3].[1-10]
•
SH1-100: Supervisor 22; elected RP for groups 239.100.0.0/16
•
SH1-99: Supervisor 22; backup RP for groups 239.100.0.0/16
Primary IXIA Ports Used
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-100 to SH1-102 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-102 is beginning the procedure with the correct multicast routing states.
Step 5
Verify that SH1-100 is beginning with the correct multicast routing states.
Step 6
Verify that SH1-102 is passing traffic both ways over all four interfaces in portchannel 115.
Step 7
Begin sending a fixed stream of traffic
Step 8
Shut down portchannel 115 on SH1-102.
Step 9
Verify that SH1-102 builds the correct multicast routing state to the backup RP, SH1-99.
Step 10
Verify that SH1-99 builds the correct routing state down to SH1-102.
Step 11
Measure traffic loss due to the EtherChannel failure.
Step 12
Bring portchannel 115 of SH1-102 back online.
Step 13
With traffic running continuously, verify that SH1-102 again builds the correct multicast routing states
for the 30 test groups.
Step 14
Verify that SH1-100 again builds the correct multicast routing states.
Step 15
Verify that all four interfaces in portchannel 115 are passing traffic.
Step 16
Repeat the failover sequence four times with a fixed amount of traffic, each time measuring the traffic
loss caused by the failover.
Step 17
Determine the average amount of traffic loss over the five failovers.
Step 18
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
107
Layer 3 Routing
Step 19
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic to failover and be forwarded through RP SH1-99 when the portchannel between
SH1-102 and SH1-100 is torn down.
•
We expect this failover to take place in a reasonable time (worst case the 45-sec default EIGRP hold
time).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 58 shows the Layer 3 GEC Failover—SH1-100 to SH1-102 test results.
Table 58
Layer 3 GEC Failover—SH1-100 to SH1-102 Test Results
Tests
Results
Layer 3 GEC Failover—SH1-100 to SH1-102
Pass
Layer 3 GEC Failover—SH1-100 to SH1-101
This test verified the ability of the devices to recover from a Layer 3 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 114 on SH1-101 was failed.
Goals
•
Verify that the devices SH1-101, SH1-100, and SH1-99 maintain the correct multicast routing states
during the GEC failover.
•
Verify that traffic loss is minimal.
Primary Devices Used
•
SH1-101: Supervisor 22; last-hop router for groups 239.100.1.[1-10]
•
SH1-100: Supervisor 22; elected RP for groups 239.100.1.[1-10]
•
SH1-99: Supervisor 22; backup RP for groups 239.100.1.[1-10]
•
SH1-99 and SH1-100 are sharing the RP Anycast address 172.31.0.100; but SH1-100 is the elected
RP for groups 239.100.0.0/16 because it has the higher IP address
Primary IXIA Ports Used
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-100 to SH1-101 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
108
Layer 3 Routing
Note
Step 2
This test was rerun after the entire run of 12.1(13)E11 was completed. For this reason, only SH1-99,
SH1-100, and SH1-101 are running Cisco 12.1(13)E11 for this test. All other routers are running
Cisco 12.1(20)E. Only the three devices mentioned prior are directly involved in the failovers of this
test case.
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-101 is beginning the procedure with the correct multicast routing states.
Step 5
Verify that SH1-100 is beginning with the correct multicast routing states.
Step 6
Verify that SH1-101 is passing traffic over portchannel 114.
Step 7
Begin sending a fixed stream of traffic
Step 8
Shut down portchannel 114 on SH1-101.
Step 9
Verify that SH1-101 builds the correct multicast routing state to the backup RP, SH1-99.
Step 10
Verify that SH1-99 builds the correct routing state down to SH1-101.
Step 11
Measure traffic loss due to the EtherChannel failure.
Step 12
Bring portchannel 114 of SH1-101 back online.
Step 13
With traffic running continuously, verify that SH1-101 again builds the correct multicast routing states
for the 10 test groups.
Step 14
Verify that SH1-100 again builds the correct multicast routing states.
Step 15
Verify that the interface portchannel 114 is passing traffic.
Step 16
Repeat the failover sequence four times with a fixed amount of traffic, each time measuring the traffic
loss caused by the failover.
Step 17
Determine the average amount of traffic loss over the five failovers.
Step 18
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 19
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic to failover and be forwarded through RP SH1-99 when the portchannel between
SH1-101 and SH1-100 is torn down.
•
We expect this failover to take place in a reasonable time (within the 45 second EIGRP hold time
value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 59 shows the Layer 3 GEC Failover—SH1-100 to SH1-101 test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
109
Layer 3 Routing
Table 59
Layer 3 GEC Failover—SH1-100 to SH1-101 Test Results
Tests
Results
Layer 3 GEC Failover—SH1-100 to SH1-101
Pass
Layer 3 GEC Failover—SH1-100 to SH1-97
This test verified the ability of the devices to recover from a Layer 3 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 13 on SH1-100 was failed.
Goals
•
Verify that the devices SH1-100 and SH1-97 maintain the correct multicast routing states during the
GEC failover.
•
Verify that traffic loss is minimal.
Primary Devices Used
•
SH1-100: Supervisor 22; transit router for groups 239.98.50.[1-10]
•
SH1-97: Sup22 and SH1-98: Sup22 are sharing the RP Anycast address 172.31.0.98; but SH1-97 is
the elected RP for groups 239.98.0.0/16 because it is the RP directly connected to the source.
•
SH1-99: Supervisor 22; becomes router used for RPF when GEC is failed between SH1-97 and
SH1-100.
Primary IXIA Ports Used
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-100 to SH1-97 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-100 is beginning the procedure with the correct multicast routing states.
Step 5
Verify that SH1-97 is beginning with the correct multicast routing states.
Step 6
Verify that SH1-100 is passing traffic in portchannel 13.
Step 7
Begin sending a fixed stream of traffic
Step 8
Shut down portchannel 13 on SH1-100.
Step 9
Verify that SH1-100 builds the correct multicast routing state to the backup RP, SH1-98.
Step 10
Verify that SH1-97 builds the correct routing following the topology change.
Step 11
Measure traffic loss due to the EtherChannel failure.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
110
Layer 3 Routing
Step 12
Bring portchannel 13 of SH1-100 back online.
Step 13
With traffic running continuously, verify that SH1-100 again builds the correct multicast routing states
for the 10 test groups.
Step 14
Verify that SH1-97 again builds the correct multicast routing states.
Step 15
Verify that the interface portchannel 13 is passing traffic.
Step 16
Repeat the failover sequence four times with a fixed amount of traffic, each time measuring the traffic
loss caused by the failover.
Step 17
Determine the average amount of traffic loss over the five failovers.
Step 18
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 19
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic to failover and be forwarded through SH1-99 when the portchannel between
SH1-97 and SH1-100 is torn down.
•
We expect this failover to take place in a reasonable time (within the 40 sec default OSPF dead time
value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 60 shows the Layer 3 GEC Failover—SH1-100 to SH1-97 test results.
Table 60
Layer 3 GEC Failover—SH1-100 to SH1-97 Test Results
Tests
Results
Layer 3 GEC Failover—SH1-100 to SH1-97
Pass
Switch Fabric Module Failover—Supervisor 22
This test verified multicast functionality during Switch Fabric Module (SFM) failover. Multicast traffic
was sourced from IXIA and transits through SH1-106. The traffic was switched using the crossbar fabric.
This test will perform a series of resets on the active SFM and measure traffic loss at each iteration.
In several of the following steps, verification that the traffic was using the SFM was requested. Verify
by examining how the Medusa ASIC was handling traffic. The Medusa ASIC interfaces were between
the line card local bus and the backplane of the Catalyst 6500. If traffic was using the SFM (no legacy,
or nonfabric-enabled, cards present), the Medusa mode was "Compact" for all line cards, indicating that
it was sending a compact header on the backplane for the switching decision. Note that any WS-X6816
modules were always in "Compact" mode, because they were 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
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
111
Layer 3 Routing
Goals
•
Verify that the router is using the crossbar fabric to switch the traffic prior to SFM failover.
•
Verify that the router is using the crossbar fabric to switch the traffic after the SFM failover.
•
Verify that failover times are within acceptable parameters.
Primary Devices Used
•
SH1-102: Supervisor 22; last-hop router for groups 239.100.2.[1-10]
Primary IXIA Ports Used
•
4/2, 1/2
Test Procedure
The procedure used to perform the Switch Fabric Module Failover—Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-102 is a last-hop router for test groups 239.100.2.[1-10].
Step 5
Verify that SH1-102 is receiving traffic on portchannel 115 and sending traffic on portchannel 10, and
that the traffic is being hardware-switched.
Step 6
Verify that portchannels 10 and 115 consist of interfaces on fabric-enabled line cards.
Step 7
Verify that all fabric-enabled modules are using the crossbar fabric to switch the traffic.
Step 8
Start the test script, that will fail over the active fabric module on SH1-102 500 times while running
traffic.
Step 9
Analyze the results from the script and verify that failover times are within tolerances. Log output from
the test is provided.
Step 10
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect failovers to occur within an acceptable time and that traffic loss due to fabric failure
should be minimal.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
112
Layer 3 Routing
Results
•
The mean time for the standby fabric module to become active was 10.1 milliseconds, which is
acceptable.
•
The mean time it took for the failed fabric module to come back online in standby mode was 25.9
sec, which is acceptable.
•
The mean time that traffic was interrupted due to the fabric module failover was 0.611 sec, which is
acceptable.
Table 61 shows the Switch Fabric Module Failover—Supervisor 22 test results.
Table 61
Switch Fabric Module Failover—Supervisor 22 Test Results
Tests
Results
Switch Fabric Module Failover—Supervisor 22
Pass
GEM Failover—Supervisor 11 as First Hop Router
This test verified multicast functionality during Gigabit Ethernet (GE) module failover at the first hop
router. There were four Gigabit Ethernet modules in SH1-106, that was the first hop router for groups
239.100.2.[1-10]. Three of these were reset with traffic passing through them. It was verified that traffic
continues to reach the destination and that mrouting and MMLS states were consistent with what was
expected.
Goals
•
Verify that the impact on traffic due to a GEM reset is minimal.
•
Verify that any impact to mrouting and MMLS states is consistent with what it expected.
Primary Devices Used
•
SH1-106: Supervisor 11; first hop router for groups 239.255.2.[1-10]
Primary IXIA Ports Used
•
4/2, 1/2
Test Procedure
The procedure used to perform the GEM Failover—Supervisor 11 as First Hop Router test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-106 is the first hop router for groups 239.100.2.[1-10].
Step 5
Display which modules are used by which EtherChannels on SH1-106.
Step 6
Verify that some multicast traffic is passing through the interfaces of each of these modules.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
113
Layer 3 Routing
Step 7
Reset module 3 on SH1-106.
Step 8
Once module 3 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 9
Verify that the interfaces on module 3 are again passing traffic.
Step 10
Reset module 5 on SH1-106.
Step 11
Once module 5 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 12
Verify that the interfaces on module 5 are again passing traffic.
Step 13
Reset module 6 on SH1-106.
Step 14
Once module 6 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 15
Verify that the interfaces on module 6 are again passing traffic.
Step 16
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 17
Verify that there was no significant impact on the CPU or memory of the DUT.
Expected Results
•
We expect mroute and MMLS entries to be restored to their correct states when the reset module and
its interfaces are back online.
•
We expect interfaces of the reset module to pass traffic as before the reset, once they come back
online.
•
We expect CPU and memory impact to be within acceptable limits.
Results
Table 62 shows the GEM Failover—Supervisor 11 as First Hop Router test results.
Table 62
Gigabit Ethernet Module Failover—Supervisor 11 as First Hop Router Test Results
Tests
Results
GEM Failover—Supervisor 11 as First Hop Router
Pass
GEM Failover—Supervisor 11 as Last Hop Router
This test verified multicast functionality during Gigabit Ethernet (GE) module failover at the last-hop
router. There were four Gigabit Ethernet modules in SH1-106, that was the last-hop router for groups
239.100.3.[1-10]. Three of these were reset with traffic passing through them. It was verified that traffic
continues to reach the destination and that mrouting and MMLS states were consistent with what was
expected.
Goals
•
Verify that the impact on traffic due to a GEM reset is minimal.
•
Verify that any impact on mrouting and MMLS states is consistent with what it expected.
Primary Devices Used
•
SH1-106: Supervisor 11; last-hop router for groups 239.255.3.[1-10]
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
114
Layer 3 Routing
Primary IXIA Ports Used
•
None
Test Procedure
The procedure used to perform the GEM Failover—Supervisor 11 as Last Hop Router test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-106 is the last-hop router for groups 239.100.3.[1-10].
Step 5
Display which modules are used by which EtherChannels on SH1-106.
Step 6
Verify that some multicast traffic is passing through the interfaces of each of these modules.
Step 7
Reset module 3 on SH1-106.
Step 8
Once module 3 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 9
Verify that the interfaces on module 3 are again passing traffic.
Step 10
Reset module 5 on SH1-106.
Step 11
Once module 5 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 12
Verify that the interfaces on module 5 are again passing traffic.
Step 13
Reset module 6 on SH1-106.
Step 14
Once module 6 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 15
Verify that the interfaces on module 6 are again passing traffic.
Step 16
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 17
Verify that there was no significant impact on the CPU or memory of the DUT.
Expected Results
•
We expect proper mroute and MMLS entries to be reinstalled following the reset of the various GE
modules.
•
We expect the proper interfaces on the reset modules to return to forwarding or receiving traffic.
•
We expect CPU and memory impact to be within acceptable limits.
•
CSCdy64447 was hit following the reset of modules 5 and 6. This is a cosmetic bug and
non-impacting.
Results
Table 63 shows the GEM Failover—Supervisor 11 as Last Hop Router test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
115
Layer 3 Routing
Table 63
GEM Failover—Supervisor 11 as Last Hop Router Test Results
Tests
Results
GEM Failover—Supervisor 11 as Last Hop Router
Pass
GEM Failover—Supervisor 11 with Directly Connected Layer 3 Interface
This test determines the effect of resetting a GEM that has a directly connected Layer 3 interface.
Module 3 of SH1-105 has a directly connected Layer 3 interface on a secondary subnet. This interface
was connected to the receiver for groups 239.100.1.[1-10]. This module was reset, and it was verified
that traffic resumes and that mrouting and MMLS states were consistent with what was expected, once
the module comes back online.
Goals
•
Verify that the impact on traffic to a Layer 3 receiver due to a GEM reset is minimal.
•
Verify that any impact on mrouting and MMLS states is consistent with what it expected.
Primary Devices Used
•
SH1-105: Supervisor 11; has directly connected Layer 3 receiver for groups 239.255.1.[1-10] on a
secondary subnet
Primary IXIA Ports Used
•
None
Test Procedure
The procedure used to perform the GEM Failover—Supervisor 11 with Directly Connected Layer 3
Interface test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that Gigabit Ethernet interface 3/2 is a Layer 3 interface.
Step 5
Verify that SH1-105 has the correct mroute and MMLS entries for groups 239.100.1.[1-10].
Step 6
Verify that Gigabit Ethernet interface 3/2 is passing traffic to the receiver port.
Step 7
Reset module 3.
Step 8
Once module 3 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 9
Verify that Gigabit Ethernet interface 3/2 is again passing traffic.
Step 10
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
116
Layer 3 Routing
Step 11
Verify that there was no significant impact on the CPU or memory of the DUT.
Expected Results
•
We expect mroute and MMLS entries to be restored after the reset of the GEM with the Layer 3
interface on it.
•
We expect Layer 3 interface to again send traffic to the receiver when the module comes back online.
•
We expect CPU and memory impact to be within acceptable limits.
Results
Table 64 shows the GEM Failover—Supervisor 11 with Directly Connected Layer 3 Interface test
results.
Table 64
GEM Failover—Supervisor 11 with Directly Connected Layer 3 Interface Test Results
Tests
Results
GEM Failover—Supervisor 11 with Directly Connected Layer 3 Interface
Pass
GEM Failover—Supervisor 22 as First Hop Router
This test verified multicast functionality during Gigabit Ethernet (GE) module failover at the first hop
router. There were four Gigabit Ethernet modules in SH1-110, that was the first hop router for groups
239.100.3.[1-10]. All of these were reset with traffic passing through them. It was verified that traffic
resumes through these modules and that mrouting and MMLS states were consistent with what was
expected.
Goals
•
Verify that the impact on traffic due to a GEM reset is minimal.
•
Verify that any impact on mrouting and MMLS states is consistent with what it expected.
Primary Devices Used
•
SH1-110: Supervisor 22; first hop router for groups 239.255.3.[1-10]
Primary IXIA Ports Used
•
None
Test Procedure
The procedure used to perform the GEM Failover—Supervisor 22 as First Hop Router test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
117
Layer 3 Routing
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-110 is the first hop router for groups 239.100.3.[1-10].
Step 5
Display which modules are used by which EtherChannels on SH1-110.
Step 6
Verify that some multicast traffic is passing through the interfaces of each of these modules.
Step 7
Reset module 3 on SH1-110.
Step 8
Once module 3 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 9
Verify that the interfaces on module 3 are again passing traffic.
Step 10
Reset module 4 on SH1-110.
Step 11
Once module 4 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 12
Verify that the interfaces on module 4 are again passing traffic.
Step 13
Reset module 7 on SH1-110.
Step 14
Once module 7 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 15
Verify that the interfaces on module 7 are again passing traffic.
Step 16
Reset module 8 on SH1-110.
Step 17
Once module 8 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 18
Verify that the interfaces on module 8 are again passing traffic.
Step 19
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 20
Verify that there was no significant impact on the CPU or memory of the DUT.
Expected Results
•
We expect mroute and MMLS entries to be correct on SH1-110 after each module reset.
•
We expect all proper interfaces to again pass traffic following each module reset.
•
We expect CPU and memory impact to be within acceptable limits.
Results
Table 65 shows the GEM Failover—Supervisor 22 as First Hop Router test results.
Table 65
GEM Failover—Supervisor 22 as First Hop Router Test Results
Tests
Results
GEM Failover—Supervisor 22 as First Hop Router
Pass
GEM Failover—Supervisor 22 as Last Hop Router
This test verified multicast functionality during Gigabit Ethernet (GE) module failover at the first hop
router. There were two Gigabit Ethernet modules in SH1-102, that was the last-hop router for groups
239.100.[1-3].[1-10]. Both of these were reset with traffic passing through them. It was verified that
traffic resumes through these modules and that mrouting and MMLS states were consistent with what
was expected.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
118
Layer 3 Routing
Goals
•
Verify that the impact on traffic due to a GEM reset is minimal.
•
Verify that any impact on mrouting and MMLS states is consistent with what it expected.
Primary Devices Used
•
SH1-102: Supervisor 22; first hop router for groups 239.255.[1-3].[1-10]
Primary IXIA Ports Used
•
None
Test Procedure
The procedure used to perform the GEM Failover—Supervisor 22 as Last Hop Router test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Note
Step 2
There was a crash recorded on SH1-101 before the beginning of this test. It was caused intentionally
while another issue is investigated.
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-102 is the last-hop router for groups 239.100.[1-3].[1-10].
Step 5
Display which modules are used by which EtherChannels on SH1-102.
Step 6
Verify that some multicast traffic is passing through the interfaces of each of these modules.
Step 7
Reset module 3 on SH1-102.
Step 8
Once module 3 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 9
Verify that the interfaces on module 3 are again passing traffic.
Step 10
Reset module 7 on SH1-102.
Step 11
Once module 7 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 12
Verify that the interfaces on module 7 are again passing traffic.
Step 13
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 14
Verify that there was no significant impact on the CPU or memory of the DUT.
Expected Results
•
We expect traffic to failover within an acceptable time frame.
•
We expect CPU and memory impact to be within acceptable limits.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
119
Layer 3 Routing
Results
Table 66 shows the GEM Failover—Supervisor 22 as Last Hop Router test results.
Table 66
GEM Failover—Supervisor 22 as Last Hop Router Test Results
Tests
Results
GEM Failover—Supervisor 22 as Last Hop Router
Pass
GEM Failover—Supervisor 22 as Static RP
This test verified multicast functionality during Gigabit Ethernet (GE) module failover on a static
PIM-RP. There were four Gigabit Ethernet modules in SH1-104, that was the static RP for groups
239.255.[50-51].[1-10]. Two of these modules were reset with traffic passing through them. It was
verified that traffic resumes through these modules and that mrouting and MMLS states were consistent
with what was expected.
Goals
•
Verify that the impact on traffic due to a GEM reset is minimal.
•
Verify that any impact on mrouting and MMLS states is consistent with what it expected.
Primary Devices Used
•
SH1-104: Supervisor 22; static PIM-RP for groups 239.255.[50-51].[1-10]
Primary IXIA Ports Used
•
None
Test Procedure
The procedure used to perform the GEM Failover—Supervisor 22 as Static RP test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-104 is the static RP for groups 239.255.[50-51].[1-10].
Step 5
Verify that SH1-104 has the correct mroute and MMLS entries for the groups 239.255.[50-51].[1-10].
Step 6
Display which modules are used by which EtherChannels on SH1-104.
Step 7
Verify that some multicast traffic is passing through the interfaces of each of these modules.
Step 8
Reset module 3 on SH1-104.
Step 9
Once module 3 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 10
Verify that the interfaces on module 3 are again passing traffic.
Step 11
Reset module 8 on SH1-104.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
120
Layer 3 Routing
Step 12
Once module 8 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 13
Verify that the interfaces on module 8 are again passing traffic.
Step 14
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 15
Verify that there was no significant impact on the CPU or memory of the DUT.
Expected Results
•
We expect mroute and MMLS entries to be correct on SH1-104 after each module reset.
•
We expect all proper interfaces to again pass traffic following each module reset.
•
We expect CPU and memory impact to be within acceptable limits.
Results
Table 67 shows the GEM Failover—Supervisor 22 as Static RP test results.
Table 67
GEM Failover—Supervisor 22 as Static RP Test Results
Tests
Results
GEM Failover—Supervisor 22 as Static RP
Pass
GEM Failover—Supervisor 22 as Auto RP
This test verified multicast functionality during Gigabit Ethernet module failover on an elected RP. There
were two Gigabit Ethernet modules in SH1-97, that was the elected RP for groups 239.98.50.[1-10]. One
of these were reset with traffic passing through it. The standby and active supervisors was reset, also,
because their uplink interfaces were used in the EtherChannels. It was verified that traffic resumes
through these modules and that mrouting and MMLS states were consistent with what was expected.
Goals
•
Verify that the impact on traffic due to a GEM reset is minimal.
•
Verify that any impact on mrouting and MMLS states is consistent with what it expected.
Primary Devices Used
•
SH1-97: Supervisor 22; elected RP for groups 239.98.50.[1-10]
Primary IXIA Ports Used
•
None
Test Procedure
The procedure used to perform the GEM Failover—Supervisor 22 as Auto RP test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
121
Layer 3 Routing
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-97 is the elected RP for groups 239.98.50.[1-10].
Step 5
Verify that SH1-97 has the correct mroute and MMLS entries for groups 239.98.50.[1-10].
Step 6
Display which modules are used by which EtherChannels on SH1-97.
Step 7
Verify that some multicast traffic is passing through the interfaces of each of these modules on SH1-97.
Step 8
Reset module 3 on SH1-97.
Step 9
Once module 3 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 10
Verify that the interfaces on module 3 are again passing traffic.
Step 11
Reset the standby supervisor on SH1-97.
Step 12
Once the standby supervisor comes back online, verify that the correct mrouting and MMLS entries are
reinstalled.
Step 13
Verify that the interfaces of the supervisors for SH1-97 are still passing traffic.
Step 14
Reset the active supervisor on SH1-97.
Step 15
Once SH1-97 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 16
Verify that the interfaces of the supervisors of SH1-97 are still passing traffic.
Step 17
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 18
Verify that there was no significant impact on the CPU or memory of the DUT.
Expected Results
•
We expect mroute and MMLS entries to be correct on SH1-97 after each module reset.
•
We expect all proper interfaces to again pass traffic following each module reset.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 68 shows the GEM Failover—Supervisor 22 as Auto RP test results.
Table 68
GEM Failover—Supervisor 22 as Auto RP Test Results
Tests
Results
GEM Failover—Supervisor 22 as Auto RP
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
122
Layer 3 Routing
GEM Failover—Supervisor 22 with Directly Connected Layer 3 Interface
This test determines the effect of resetting a GEM that has a directly connected Layer 3 interface.
Modules 4 and 8 of SH1-110 and modules 3 and 7 of SH1-109 each have a directly connected Layer 3
interface. These interfaces were connected to receivers for various multicast groups. These modules
were reset and it was verified that traffic resumes and that mrouting and MMLS states were consistent
with what was expected, once each module comes back online.
Goals
•
Verify that the impact on traffic to a Layer 3 receiver due to a GEM reset is minimal.
•
Verify that any impact on mrouting and MMLS states is consistent with what it expected.
Primary Devices Used
•
SH1-109: Supervisor 22; has directly connected Layer 3 receiver on module 3 for groups
239.255.3.[1-10]
•
SH1-109: Supervisor 22; has directly connected Layer 3 receiver on module 7 for groups
239.255.1.[1-10]
•
SH1-110: Supervisor 22; has directly connected Layer 3 receiver on module 4 for groups
239.255.2.[1-10] on a secondary subnet
•
SH1-110: Supervisor 22; has directly connected Layer 3 receiver on module 8 for groups
239.255.1.[1-10]
Primary IXIA Ports Used
•
None
Test Procedure
The procedure used to perform the GEM Failover—Supervisor 22 with Directly Connected Layer 3
Interface test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that Gigabit Ethernet interface 3/16 on SH1-109 is a Layer 3 interface.
Step 5
Verify that SH1-109 has the correct mroute and MMLS entries for groups 239.100.3.[1-10].
Step 6
Verify that Gigabit Ethernet interface 3/16 is passing traffic to the receiver port.
Step 7
Reset module 3.
Step 8
Once module 3 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 9
Verify that Gigabit Ethernet interface 3/16 is again passing traffic. Verify that Gigabit Ethernet
interface 7/16 on SH1-109 is a Layer 3 interface.
Step 10
Verify that SH1-109 has the correct mroute and MMLS entries for groups 239.100.1.[1-10].
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
123
Layer 3 Routing
Step 11
Verify that Gigabit Ethernet interface 7/16 is passing traffic to the receiver port.
Step 12
Reset module 7.
Step 13
Once module 7 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 14
Verify that Gigabit Ethernet interface 7/16 of SH1-109 is again passing traffic.
Step 15
Verify that interfaces Gigabit Ethernet 4/16 and Gigabit Ethernet 8/16 on SH1-110 are Layer 3
interfaces.
Step 16
Verify that SH1-110 has the correct mroute and MMLS entries for groups 239.100.2.[1-10].
Step 17
Verify that Gigabit Ethernet interface 4/16 is passing traffic to the receiver port.
Step 18
Reset module 4 on SH1-110.
Step 19
Once module 4 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 20
Verify that Gigabit Ethernet interface 4/16 is again passing traffic.
Step 21
Verify that SH1-110 has the correct mroute and MMLS entries for groups 239.100.1.[1-10].
Step 22
Verify that Gigabit Ethernet interface 8/16 is passing traffic to the receiver port.
Step 23
Reset module 8.
Step 24
Once module 8 comes back online, verify that the correct mrouting and MMLS entries are reinstalled.
Step 25
Verify that Gigabit Ethernet interface 8/16 is again passing traffic.
Step 26
Display the log for error messages.
Step 27
Verify that there was no significant impact on the CPU or memory of the DUT.
Expected Results
•
We expect mroute and MMLS entries to be restored after the reset of the GEM with the Layer 3
interface on it.
•
We expect Layer 3 interface to again send traffic to the receiver when the module comes back online.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 69 shows the GEM Failover—Supervisor 22 with Directly Connected Layer 3 Interface test
results.
Table 69
GEM Failover—Supervisor 22 with Directly Connected Layer 3 Interface Test Results
Tests
Results
GEM Failover—Supervisor 22 with Directly Connected Layer 3 Interface
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. Traffic for 10 multicast groups was routed through the PIM-DR, that was SH1-106 (Sup11).
The backup, that took over the forwarding role when SH1-106 was failed, was SH1-105.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
124
Layer 3 Routing
Goals
•
Verify that the proper mroute and MMLS entries are installed on the PIM-DR (SH1-106) before the
failover, and after it is recovered.
•
Verify that the proper mroute and MMLS entries are installed on the backup PIM-DR (SH1-105)
when SH1-106 is reloaded.
•
Verify that the impact to the traffic from a PIM-DR failover is acceptable.
Primary Devices Used
•
SH1-106: Supervisor 11; PIM-DR for groups 239.255.3.[1-10]
•
SH1-105: Supervisor 11; backup PIM-DR for groups 239.255.3.[1-10]
Primary IXIA Ports Used
•
13/2, 2/6
Test Procedure
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.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-105 and SH1-106 are PIM neighbors and that SH1-106 is the PIM-DR.
Step 5
Verify that the PIM-DR, SH1-106, has the correct mroute and MMLS entries for the groups for which it
is the DR.
Step 6
Begin sending a fixed stream of traffic through the PIM-DR SH1-106.
Step 7
Force the primary supervisor on PIM-DR SH1-106 to switch to the backup supervisor.
This causes the primary PIM-RP to switch from SH1-106 to SH1-105.
Step 8
Verify that SH1-105 has assumed the role of PIM-DR and has the proper mroute and MMLS entries.
Step 9
Once SH1-106 comes back online, verify that it resumes its role as PIM-DR and recreates proper mroute
and MMLS entries.
Step 10
Determine the amount of traffic that was lost during the PIM-DR failover.
Step 11
Repeat the PIM-DR failover sequence four times, each time determining the amount of traffic loss.
Step 12
Determine the average down time over the five test runs.
Step 13
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 14
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
125
Layer 3 Routing
Expected Results
•
We expect the primary PIM-DR (SH1-106) to have the correct mroute and MMLS entries before the
reload and after recovery.
•
We expect the backup PIM-DR (SH1-105) to create the correct mroute and MMLS entries after the
reload of SH1-106 and assume the forwarding role for all test groups.
•
We expect any impact on traffic during the failover process to be minimal and acceptable.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 70 shows the Protocol Independent Module-Designated Router Failover—Supervisor 11 test
results.
Table 70
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. Traffic for 10 multicast groups was routed through the PIM-DR, which was SH1-110. The
backup, that took over the forwarding role when SH1-110 was failed, is SH1-109.
Goals
•
Verify that the proper mroute and MMLS entries are installed on the PIM-DR (SH1-106) before the
failover, and after it is recovered.
•
Verify that the proper mroute and MMLS entries are installed on the backup PIM-DR (SH1-105)
when SH1-106 is reloaded.
•
Verify that the impact to the traffic from a PIM-DR failover is acceptable.
Primary Devices Used
•
SH1-110: Supervisor 22; LHR and PIM-DR for groups 239.100.[1-2].[1-10]
•
SH1-109: Supervisor 22; backup PIM-DR for groups 239.100.[1-2].[1-10] after failover
Primary IXIA Ports Used
•
4/2, 3/3, 11/1, 12/2, 10/1, 10/2
Test Procedure
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.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
126
Layer 3 Routing
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-109 and SH1-110 are PIM neighbors and that SH1-110 is the PIM-DR.
Step 5
Verify that the PIM-DR, SH1-110, has the correct mroute and MMLS entries for the groups for which it
is the DR.
Step 6
Begin sending a fixed stream of traffic through the PIM-DR SH1-110.
Step 7
Force the primary supervisor on PIM-DR SH1-110 to switch to the backup supervisor.
This causes the primary PIM-RP to switch from SH1-110 to SH1-109.
Step 8
Verify that SH1-109 has assumed the role of PIM-DR and has the proper mroute and MMLS entries.
Step 9
Once SH1-110 comes back online, verify that it resumes its role as PIM-DR and recreates proper mroute
and MMLS entries.
Step 10
Determine the amount of traffic that was lost during the PIM-DR failover.
Step 11
Repeat the PIM-DR failover sequence four times, each time determining the amount of traffic loss.
Step 12
Determine the average amount of traffic loss the IXIA received over the five test runs.
Step 13
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 14
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect primary PIM-DR (SH1-110) to have the correct mroute and MMLS entries before the
reload and after recovery.
•
We expect backup PIM-DR (SH1-109) to create the correct mroute and MMLS entries after the
reload of SH1-110 and assume the forwarding role for all test groups.
•
We expect any impact on traffic during the failover process to be minimal and acceptable.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 71 shows the Protocol Independent Module-Designated Router Failover—Supervisor 22 test
results.
Table 71
Protocol Independent Module-Designated Router Failover—Supervisor 22 Test Results
Tests
Results
Protocol Independent Module-Designated Router Failover—Supervisor 22
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
127
Layer 3 Routing
Auto PIM-RP Failover—Supervisor 22—RP Impact
This test verified multicast functionality on the elected PIM-RP during a PIM-RP failover on a
Supervisor 22 platform. SH1-100 was the elected PIM-RP for groups 30 multicast test groups:
239.100.[1-3].[1-10]. SH1-100 was reloaded, verifying the correct failover of mrouting state to SH1-99
and the reversion of state to SH1-100, once it was back online.
Goals
•
Verify that the elected RP has the correct mroute entries, flags, and MMLS entries for all 30 test
groups.
•
Verify that each of the 30 test groups fails over to the backup PIM-RP after the failure of the primary,
with correct mroute and MMLS state.
•
Verify that all 30 groups build correct state again on the original PIM-RP when it is back online.
Primary Devices Used
•
SH1-100: Supervisor 22; elected RP for groups 239.255.[1-3].[1-10]
Primary IXIA Ports Used
•
12/1, 2/1, 1/2, 2/7, 2/4, 1/1, 2/6, 4/2, 4/6, 3/3, 5/3, 8/1, 7/2, 7/1, 9/1, 9/2, 10/1, 10/2, 13/2, 11/1, 12/2
Test Procedure
The procedure used to perform the Auto PIM-RP Failover—Supervisor 22—RP Impact test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the elected PIM-RP, SH1-100, has the proper mroute and MMLS entries, with the correct
flags for all 30 groups.
Step 5
Reload SH1-100.
Step 6
Verify that the new primary PIM-RP, SH1-99, has the correct mroute and MMLS entries, with the correct
flags set, for all 30 groups while SH1-100 is offline.
Step 7
Once SH1-100 comes back online, verify that it is again the RP for all 30 groups and that its mrouting
table and MMLS entries are correct.
Step 8
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 9
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
128
Layer 3 Routing
Expected Results
•
We expect SH1-100, the primary PIM-RP, to have all the correct mroute entries and flags for the 30
groups for which it is the RP prior to the failover,.
•
We expect SH1-100 to have the correct MMLS entries, consistent with the mroute entries, and be
hardware-switching traffic.
•
We expect SH1-99 to take over the role of primary PIM-RP when SH1-100 is reloaded, and correctly
populate its mroute and MMLS entries.
•
We expect SH1-100 to resume the role of primary PIM-RP when it is back online and capable of
forwarding traffic.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
•
SH1-100 had all the correct mroute entries, flags (with the exception of the A-flag being
inconsistently set due to CSCea21798), and MMLS entries prior to the reload, and after the recovery.
•
SH1-99 assumed its role as primary PIM-RP, with all the correct mroute entries, flags (with the
exception of the A-flag being inconsistently set due to CSCea21798), and MMLS entries, following
the reload of SH1-100.
Results
Table 72 shows the Auto PIM-RP Failover—Supervisor 22—RP Impact test results.
Table 72
Auto PIM-RP Failover—Supervisor 22—RP Impact Test Results
Tests
Results
Auto PIM-RP Failover—Supervisor 22—RP Impact Pass with exception CSCea21798
Cisco Express Forwarding
Cisco Express Forwarding (CEF) evolved to best accommodate the changing network dynamics and
traffic characteristics resulting from increasing numbers of short duration 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 is routed via routing table
information and, as part of that forwarding operation, a route-cache entry for that destination is then
added. This behavior allows subsequent packets 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, there is a one-to-one correspondence between FIB table entries and routing table prefixes;
therefore no need to maintain a route cache.
The following tests were performed:
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
129
Layer 3 Routing
•
CEF Packet Switching, page 130
•
CEF Table Entries, page 131
•
CEF Load-Balance—Many to One, page 132
•
CEF Load-Balance—Many to Many with Polarization, page 135
CEF Packet Switching
This test verified that IP Unicast traffic was hardware switched. If traffic was not hardware switched (by
the PFC) the traffic would have been fast-switched by the MSFC.
The devices were connected as shown in Figure 22:
Figure 22
CEF Packet Switching Topology
A fixed number of ping packets were sent from SH1-104 to SH1-103, across SH1-99. The ping and
response totals were compared against the number of MLS CEF Layer 3 packets switched. An extended
ping of 500 packets was 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, SH1-103
Test Procedure
The procedure used to perform the CEF Packet Switching test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
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 Po68, Po69, Po70, and Po71 interfaces).
Step 5
If any background traffic streams are running, stop them for this test. They may interfere with the counter
statistics observed on SH1-99.
Step 6
Display the MLS statistics for module 3 on SH1-99. This will give a base packet count from which to
compare.
Step 7
Clear out the MLS entries on module 3 of SH1-99 and verify that there are none.
Step 8
Send 500 ping packets from SH1-104 (172.31.1.38) to SH1-103 (172.31.1.34).
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
130
Layer 3 Routing
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 portchannel interfaces (Po68 to Po71)
that were shut down in Step 4.
Step 12
Restart any traffic streams that were stopped.
Step 13
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 14
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect MLS counters on SH1-99 to be incremented by 1000 when 500 ping packets are sent from
SH1-104 to SH1-103, through SH1-99.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 73 shows the CEF Packet Switching test results.
Table 73
CEF Packet Switching Test Results
Tests
Results
CEF Packet Switching
Pass
CEF Table Entries
This test verified that correct Cisco Express Forwarding (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. portchannel 16 was used to connect SH1-99 to SH1-103 and
portchannel 17 was used to connect SH1-99 to SH1-104.
Devices under test: SH1-104
Test Procedure
The procedure used to perform the CEF Table Entries test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
131
Layer 3 Routing
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
Display 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
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 9
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect corresponding CEF table entries for each routing table entry for networks that are a)
directly connected, b) one hop away, and c) more than one hop away.
•
We expect entries on the PFC2 to be on the DFC of Module 3.
Results
Table 74 shows the CEF Table Entries test results.
Table 74
CEF Table Entries Test Results
Tests
Results
CEF Table Entries
Pass
CEF Load-Balance—Many to One
This test was performed to verify that HW shortcuts and CEF distribution functioned properly with IP
unicast traffic. We monitored unicast traffic streams of "many-to-one" with 20 incremented IP addresses
sending traffic to a single destination IP address. Figure 23 is a brief diagram illustrating the devices
used in this test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
132
Layer 3 Routing
Figure 23
Note
CEF Many-to-One Distribution Load Balance 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, SH1-110
Test Procedure
The procedure used to perform the CEF Load-Balance—Many to One test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
133
Layer 3 Routing
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that all the portchannel interfaces involved in this test are up and that the proper interfaces are
bundled in them.
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.27.51. The source IP addresses incremented from 172.31.16.82
to 172.31.16.101.
The traffic source port Ix8/2 connected to switch Dista-1. The destination IP address was IXIA-1 port
Ix-5/1 connected to switch Dista-2. Router SH1-108 received the traffic from Dista-1 and distributed it
into the test network. Send a total of 1 million packets at 10,000 pps. 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 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. This will demonstrate that CEF load-balancing did occur along the
traffic path.
Step 8
Begin a continuous burst traffic stream with the same characteristics of the stream used above (20 source
IP addresses to 1 destination IP address). This stream will also be sent out IXIA port 8/2 1/8/2/4 and
enter Dista-1. Traffic counters are not important for this test; that is why a continuous burst of traffic is
sent.
Step 9
Look at the MLS entries on each router along the traffic path. There should be a total of 20 entries at
each level (that is, 20 entries on SH1-108; 20 entries on SH1-103 and SH1-104, combined; and 20 entries
on SH1-109 and SH1-110, combined). Count each entry with a destination IP address (DstIP) of
172.31.27.51. Note that, in some cases, it may be necessary to look at the MLS entries on the DFC cards
of certain modules.
Step 10
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic sourced from multiple IP hosts to a single IP host will use multiple paths if they
are available.
•
We expect traffic sourced from multiple IP hosts to a single IP host will be hardware switched.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 75 shows the CEF Load-Balance—Many to One test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
134
Layer 3 Routing
Table 75
CEF Load-Balance—Many to One Test Results
Tests
Results
CEF Load-Balance—Many to One
Pass
CEF Load-Balance—Many to Many with Polarization
This test was performed to verify that HW shortcuts and CEF distribution functioned properly with IP
unicast traffic. We monitored unicast traffic streams of "many-to-many" with 100 source and 100
destination address pairs. Figure 24 is a brief diagram illustrating the devices used in this test.
Figure 24
Note
CEF Many-to-Many Distribution Polarization Load Balance 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.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
135
Layer 3 Routing
Devices under test: SH1-103, SH1-104, SH1-107, SH1-108, SH1-110
Test Procedure
The procedure used to perform the CEF Load-Balance—Many to Many with Polarization test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that all the portchannel interfaces involved in this test are up and that the proper interfaces are
bundled in them. The following table lists the devices and which EtherChannel IDs to check:
Under the ports column the label "P" indicates that the interface is "in portchannel." Under the
portchannel column the Label "R" indicates it is a routed (Layer 3) port channel, and the Label "U"
indicates that the portchannel is "in-use." All EtherChannels are Layer 3 and set to up, and all bundled
interfaces are in the parent channel.
Test Two (Many-to-Many)
Test Two use 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 is IXIA port 8/4 connected to switch Dista-2. The destination IP address is IXIA port
8/2 connected to switch Dista-1. Router SH1-110 receives the traffic from Dista-2 and distributes it into
the test network. Send a total of 10 million packets at 100,000 pps. The path of the traffic for this test is
as follows (Figure 25):
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 all have the same pathcount. A description of the problem
follows.
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(13)E11
136
Layer 3 Routing
Figure 25
CEF Many-to-Many Distribution Polarization Load Balance Topology
In order to address the polarization issue, Cisco Native IOS Release 12.1(13)E11 allows the
configuration of 3 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. In our testing, we use the default
algorithm (universal), but still encounter 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, but
rather will look only at the traffic to verify it is load-balanced correctly.
Step 5
Clear the traffic counters on the test devices. Begin the IXIA traffic stream sending traffic from Dista-2
to Dista-1.
Step 6
Verify that all of the 1 million packets that were sent were received on the proper IXIA port.
Step 7
Display the interface traffic counters on devices SH1-110, SH1-103, SH1-104, SH1-107, and SH1-108.
This will demonstrate that CEF load-balancing did occur along the traffic path.
Step 8
Display the log for error messages.
Step 9
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
137
Layer 3 Routing
Expected Results
•
We expect traffic sourced from multiple IP hosts to multiple IP hosts will use multiple paths if they
are available (with polarization taken into account).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 76 shows the CEF Load-Balance—Many to Many with Polarization test results.
Table 76
CEF Load-Balance—Many to Many with Polarization Test Results
Tests
Results
CEF Load-Balance—Many to Many with Polarization
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 138
•
OSPF Passive Interface, page 140
•
OSPF Filtering, page 142
•
Redistribute EIGRP into OSPF, page 143
•
OSPF Topology Database Verification, page 145
OSPF Autocost
This test verified that the auto-cost reference-bandwidth value command functions correctly. OSPF
uses the interface cost to compute routing metrics. By default:
cost = 100/bandwidth (in Mbps)
The lowest cost is 1, which is for 100 Mbps interfaces. In order to let GE, GEC or 10 GE, and so on.
interfaces 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 auto-cost
reference-bandwidth for the Cisco Native IOS Safe Harbor testing was 100,000.
Device under test: SH1-97
Test Procedure
The procedure used to perform the OSPF Autocost test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
138
Layer 3 Routing
Note
Step 2
There was a crash recorded on SH1-101 before the beginning of this test. It was caused intentionally
while another issue was investigated.
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin the test script.
Step 5
Display the auto cost configuration for SH1-97.
Step 6
Display the OSPF interface costs for interfaces portchannel 11 and portchannel 13 on SH1-97. Display
that portchannel 11 is a 2-port channel, and portchannel 13 is a 4-port channel. The auto cost
configuration allows the 4-port portchannel to have one-half of the cost of the 2-port portchannel.
Portchannel 11 is a 2-port channel and portchannel 13 is a 4-port channel. The OSPF interface cost of
the 2-port channel is 50. The OSPF interface cost of the 4-port channel is 25, exactly 1/2 the value of the
2-port channel.
Step 7
Reconfigure the reference bandwidth to the default bandwidth 100. Display that both portchannel
interfaces now have the same minimum cost of one (in this case, they would be compared equally with
a single fast-Ethernet interface).
Step 8
Change the auto cost value to 500000, and verify that the interface costs have changed to 250 and 125
for portchannel 11 and portchannel 13, respectively.
Step 9
Change the auto cost value back to 100000, and verify that the interface costs have changed back to their
original values.
Step 10
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the OSPF interface cost to change accordingly with the change in configuration of the
auto cost reference value.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 77 shows the OSPF Autocost test results.
Table 77
Autocost Test Results
Tests
Results
OSPF Autocost
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
139
Layer 3 Routing
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 was an OSPF neighbor to devices SH1-99 and SH1-100 in OSPF area 2. SH1-100
and SH1-99 were being sent OSPF routes by Pagent. SH1-100 and SH1-106 were connected by the
portchannel 67 interface on SH1-100 and the portchannel 167 interface on SH1-106. SH1-99 and
SH1-106 were connected by the portchannel 67 interface on SH1-100 and the portchannel 67 interface
on SH1-106. The passive-interface command was configured on Po67 on SH1-100 and on Po67 on
SH1-99. The neighbor tables on SH1-100 and SH1-99 was checked to verify the command worked
(SH1-106 should be removed). By the same accord, SH1-106 should 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 26 is a brief diagram of the relevant topology.
Figure 26
OSPF Passive Interface Topology
Devices under test: SH1-99, SH1-100, SH1-106
Test Procedure
The procedure used to perform the OSPF Passive Interface test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Note
Step 2
There was a crash recorded on SH1-101 before the beginning of this test. It was caused intentionally
while another issue was investigated.
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
140
Layer 3 Routing
Step 4
Shut down the portchannel 20 interface on device SH1-105. This will verify 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 they 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
Display the number of OSPF routes that SH1-106 has in its routing table.
Step 8
Configure a passive interface on portchannel 67 of SH1-99 and on portchannel 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. Verify that the OSPF
routes SH1-106 was receiving from its neighbors are no longer in its routing table. SH1-106 should only
have 2500 OSPF routes in its routing table (from another Pagent source connected to Dista-2).
Step 10
Remove the passive interfaces configuration.
Step 11
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 12
Bring up the portchannel 20 interface on SH1-105 that was shut down earlier.
Step 13
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 14
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect neighbor relationships between SH1-99, SH1-100 and SH1-106 to be broken down when
the passive-interface commands are applied.
•
We expect SH1-106 to destroy the ~17,500 routes it was learning from SH1-99 and SH1-100 when
it loses those two devices as neighbors.
•
We expect neighbor relationships to reform properly when the passive-interface commands are
removed.
•
We expect SH1-106 to fully populate its routing table with the new updates from SH1-99 and
SH1-100.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
•
The number of routes that SH1-106 new via OSPF was correctly reduced to 2,500 when it's
neighbors were suspended.
Results
Table 78 shows the OSPF Passive Interface test results.
Table 78
Passive Interface Test Results
Tests
Results
OSPF Passive Interface
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
141
Layer 3 Routing
OSPF Filtering
This procedure tests the capability of OSPF to filter out routes using the distribute-list command.
SH1-97, SH1-100, and SH1-106 were connected as follows: SH1-97 -- SH1-100 -- SH1-106. These
connections were Layer 3 links (channels). The link between SH1-100 and SH1-106 (Po13) was network
172.31.1.96/30. SH1-97 knows, through OSPF, this network via portchannel 13. In this test, SH1-97 is
configured with an access list and the distribute-list command, so that SH1-97 no longer knows this
route; it was filtered out.
Figure 27 shows the relevant topology configuration.
Figure 27
OSPF Filtering Topology
Devices under test: SH1-97, SH1-100, SH1-106
Test Procedure
The procedure used to perform the OSPF Filtering test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Note
Step 2
There was a crash recorded on SH1-101 before the beginning of this test. It was caused intentionally
while another issue is investigated.
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-97, SH1-100, and SH1-106 are running OSPF and have network statements for their
respective connecting networks (refer to Figure 27).
Step 5
Verify that SH1-97 knows the route to network 172.31.1.96 via portchannel 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.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
142
Layer 3 Routing
Step 8
Verify that the route to the 172.31.1.96 network is no longer known via Po13 in SH1-97. 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 portchannel 13.
Step 11
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 12
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect SH1-97 to not know the route to network 172.31.1.96 out interface portchannel 13 when
the filter is applied.
•
We expect SH1-97 to relearn the route to the 172.31.1.96 network out interface portchannel 13 when
the filter is removed.
•
We expect the application and removal of the filter to have no unacceptable effects on CPU or
memory.
Results
Table 79 shows the OSPF Filtering test results.
Table 79
Filtering Test Results
Tests
Results
OSPF Filtering
Pass
Redistribute EIGRP into OSPF
This test verified that the redistribution of EIGRP routes into OSPF functions properly. The baseline
configuration for the Cisco Safe Harbor Native IOS testbed includes having all EIGRP routes
redistributed into OSPF by devices SH1-99 and SH1-100. For this test, verify that the EIGRP routes from
EIGRP 1320 were known to device SH1-97 via OSPF, first, then remove the redistribute configuration
statements from SH1-99 and SH1-100. The routes from EIGRP 1320 should no longer be known by
SH1-97. Then reconfigure redistribution on SH1-99 and SH1-100. The routes from EIGRP 1320 should,
once again, be known to SH1-97 via OSPF.
Figure 28 shows the relevant topology.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
143
Layer 3 Routing
Figure 28
OSPF Redistribution Topology
Devices under test: SH1-97, SH1-99, SH1-100, SH1-101
Test Procedure
The procedure used to perform the Redistribute EIGRP into OSPF test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin the test script.
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
Display 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.
Step 10
Determine if the route entries seen in Step 7 are still present on SH1-97.
Step 11
Display the number of OSPF routes known to SH1-97 (there should be only about 10,000).
Step 12
Reconfigure redistribution on SH1-99 and SH1-100.
Step 13
Verify that the route entries in Step 7 are once again present on SH1-97.
Step 14
Display the number of OSPF routes known to SH1-97 (there should be over 20,000).
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
144
Layer 3 Routing
Step 15
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 16
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect route entries observed in Step 7 to no longer be known via OSPF 1 with the removal of
the redistribution configuration.
•
We expect route entries to be created again, when redistribution is reconfigured.
•
We expect OSPF redistribution to have no unacceptable impact on CPU or memory.
Results
Table 80 shows the Redistribute EIGRP into OSPF test results.
Table 80
Redistribute EIGRP into OSPF Test Results
Tests
Results
Redistribute EIGRP into OSPF
Pass
OSPF Topology Database Verification
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/IXIA
interfaces shut down or disabled) and in the case of Pagent and IXIA feeding extra routes.
Test Procedure
The procedure used to perform the OSPF Topology Database Verification test follows:
Step 1
From each router in the Safe Harbor network, gather information about the OSPF interfaces and the
OSPF processes that are running.
Step 2
From each ABR in the Safe Harbor network, gather information about the OSPF database maintained
for each area.
Step 3
Verify router LSA. In each area, verify there is one router LSA in the database for each router in that
area.
Step 4
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 is generated because no other OSPF router is on the subnet. So, in order to know which multiaccess
subnets should have a Network LSA generated for them, look for a BDR on that subnet. In each area,
verify that there is one Network LSA for each BDR interface in the output of show ip ospf interface.
Step 5
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 show ip ospf interface. Verify that the number of summary network
LSA's 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.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
145
Layer 3 Routing
Step 6
Verify Summary ASBR. 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 happen to be 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 7
Verify external LSAs. Verify that there is an external LSA for each external route redistributed into
OSPF.
Expected Results
•
The various types of LSAs measured should be consistent with the existing testbed topology.
Results
Table 81 shows the OSPF Topology Database Verification test results.
Table 81
OSPF Topology Database Verification Test Results
Tests
Results
OSPF Topology Database Verification
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 AS-path), and a list of other path attributes.
The following tests were performed:
•
Add 120,000 Routes, page 146
•
Redistributing OSPF into BGP, page 148
•
Redistributing EIGRP into BGP, page 149
•
Redistributing OSPF and EIGRP into BGP, page 151
•
BGP Neighbor Flap, page 153
•
BGP Route Flap—With Dampening, page 154
•
BGP Route Flap—No Dampening, page 156
Add 120,000 Routes
This test verified 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(13)E11
146
Layer 3 Routing
During the course of this test, OSPF routes was 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. 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, SH1-100
Test Procedure
The procedure used to perform the Add 120,000 Routes test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
If the routes from the test tools have already been added to the various places in the network, stop them
now.
Step 5
Display a route summary for the 4 core devices with no test tool routes added.
Note
There were just over 600 routes because OSPF was running on the IXIA at the start of the test, which
accounts for an additional 500 routes.
Step 6
Add all the BGP routes.
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.
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
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 13
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect all 120,000 routes to be added to the core devices without unacceptable impact on the
CPU or memory.
Results
Table 82 shows the Add 120,000 Routes test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
147
Layer 3 Routing
Table 82
Add 120,000 Routes Test Results
Tests
Results
Add 120,000 Routes
Pass
Redistributing OSPF into BGP
This test verified that route redistribution works correctly between BGP and OSPF. Device SH1-100 was
a border router between OSPF and BGP. Apply the configuration for redistribution on this router and its
neighbor SH1-99. Redistribute only a limited number of OSPF routes into BGP. Use device SH1-97 to
check whether the routes have been redistributed.
Figure 29 is a diagram of the relevant topology and information.
Figure 29
Redistribution OSPF into BGP Topology
Devices under test: SH1-97, SH1-99, SH1-100
Test Procedure
The procedure used to perform the Redistributing OSPF into BGP test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
On device SH1-97, determine by what protocol the route for 170.1.1.0 is known.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
148
Layer 3 Routing
Step 5
Display the default BGP configuration of SH1-99 and SH1-100.
Step 6
Configure redistribution from BGP into OSPF on both devices SH1-99 and SH1-100.
Step 7
Verify that access list 16 is configured on SH1-97, and that it denies the 170.1.1.0 network.
Step 8
Apply a inbound distribute-list using access list 16 in the OSPF configuration on SH1-97 to block
network 170.1.1.0 from being known by OSPF.
Step 9
Verify that the route to 170.1.1.0 is now know via BGP 100 on SH1-97 and has a metric of 100, as
configured.
Step 10
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 11
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 12
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect OSPF routes to be correctly redistributed into BGP.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 83 shows the Redistributing OSPF into BGP test results.
Table 83
Redistributing OSPF into BGP Test Results
Tests
Results
Redistributing OSPF into BGP
Pass
Redistributing EIGRP into BGP
This test verified that route redistribution works correctly between BGP and OSPF. Device SH1-100 was
a border router between OSPF and BGP. Apply the configuration for redistribution on this router and its
neighbor SH1-99. Redistribute only a limited number of OSPF routes into BGP. Use device SH1-97 to
check whether the routes have been redistributed.
Figure 30 A diagram of relevant topology information.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
149
Layer 3 Routing
Figure 30
Redistribution EIGRP into BGP Topology
Devices under test: SH1-97, SH1-99, SH1-100
Test Procedure
The procedure used to perform the Redistributing EIGRP into BGP test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the routes to 180.1.1.0 and 180.1.2.0 are known on SH1-97 via OSPF 1, redistributed from
EIGRP (identified by the "type extern 2" label).
Step 5
Verify that the access list 18 exists in SH1-99 and SH1-100 and permits only the even numbered subnets
within 180.1.x.x/24.
Step 6
Verify that a route map called EIGRP2BGPis on SH1-99 and SH1-100 that matches IP addresses to
access list 18.
Step 7
Configure redistribution of EIGRP into BGP on SH1-99 and SH1-100 using the route map EIGRP2BGP,
which allows only the even numbered subnets within 180.1.x.x.
Step 8
Remove the redistribution statement from the OSPF configuration on SH1-99 and SH1-100.
Note
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.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
150
Layer 3 Routing
Step 9
Verify that the even numbered networks within 180.1.x.0/24 are known to SH1-97 via BGP 100.
Step 10
Remove the redistribution configurations applied in BGP on devices SH1-99 and SH1-100.
Step 11
Reapply the EIGRP redistribution configuration in OSPF on SH1-99 and SH1-100 that was deleted.
Step 12
Verify that the routes are known, again, via OSPF 1.
Step 13
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 14
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect EIGRP routes to be correctly redistributed into BGP.
•
We expect the application of a route map to correctly alter the rules by which BGP redistributes
routes.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 84 shows the Redistributing EIGRP into BGP test results.
Table 84
Redistributing EIGRP into BGP Test Results
Tests
Results
Redistributing EIGRP into BGP
Pass
Redistributing OSPF and EIGRP into BGP
This test verified that route redistribution works correctly between BGP and both OSPF and EIGRP.
Device SH1-100 was a border router between OSPF, EIGRP, and BGP. Apply the configuration for
redistribution on this router and its neighbor SH1-99. OSPF and EIGRP were redistributed into BGP at
the same time. Redistribute only a limited number of routes. Use device SH1-97 to check whether the
routes have been redistributed.
Figure 31 is a diagram of relevant topology information.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
151
Layer 3 Routing
Figure 31
Redistribution OSPF and EIGRP into BGP Topology
Devices under test: SH1-97, SH1-99, SH1-100
Test Procedure
The procedure used to perform the Redistributing OSPF and EIGRP into BGP test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
On device SH1-97, determine by what protocol the route for 170.1.1.0 is known.
Step 5
Verify that the routes to 180.1.1.0 and 180.1.2.0 are known on SH1-97 via OSPF 1, redistributed from
EIGRP (identified by the "type extern 2" label).
Step 6
Display the default BGP configuration of SH1-99 and SH1-100.
Step 7
Configure redistribution from OSPF into BGP on both devices SH1-99 and SH1-100.
Step 8
Verify that access list 16 is configured on SH1-97, and that it denies the 170.1.1.0 network.
Step 9
Apply a inbound distribute-list using access list 16 in the OSPF configuration on SH1-97 to block
network 170.1.1.0 from being known by OSPF.
Step 10
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 11
Verify that a route map called EIGRP2BGP is on SH1-99 and SH1-100 that matches IP addresses to
access list 18.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
152
Layer 3 Routing
Step 12
Configure redistribution of EIGRP into BGP on SH1-99 and SH1-100 using the route map EIGRP2BGP,
which allows only the even numbered subnets within 180.1.x.x.
Step 13
Remove the redistribution statement from the OSPF configuration on SH1-99 and SH1-100.
Note
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 14
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 7.
Step 15
Verify that the even numbered networks within 180.1.x.0/24 are known to SH1-97 via BGP 100.
Step 16
Reapply the EIGRP redistribution configuration in OSPF on SH1-99 and SH1-100 that was deleted in
Step 13.
Step 17
Remove the redistribution configurations applied in BGP on devices SH1-99 and SH1-100 in Step 7 and
Step 12.
Step 18
Remove the distribute-list from SH1-97, applied in Step 9.
Step 19
Verify that the routes are known, again, via OSPF 1.
SH1-97 knows the routes from OSPF and EIGRP via OSPF 1.
Step 20
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 21
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect EIGRP routes to be correctly redistributed into BGP.
•
We expect OSPF routes to be correctly redistributed into BGP.
•
We expect the application of a route map to correctly alter the rules by which BGP redistributes
routes.
•
We expect redistribution of both OSPF and EIGRP routes into BGP at the same time.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 85 shows the Redistributing OSPF and EIGRP into BGP test results.
Table 85
Redistributing Both OSPF and EIGRP into BGP Test Results
Tests
Results
Redistributing OSPF and EIGRP into BGP
Pass
BGP Neighbor Flap
This test verified that a flapping nondampened BGP peer does 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 procedure will simulate constant flapping of those BGP
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
153
Layer 3 Routing
neighbors. Specifically, the Pagent device rtp-wbu-te-p4 was 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, SH1-100
Test Procedure
The procedure used to perform the BGP Neighbor Flap test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-97 is an eBGP peer with a Pagent router. The Pagent router is sending 35,000 route
updates from AS 10.
Step 5
Log in to the Pagent test tool and configure the lne bgp interface fa 2/0 command (BGP route feed) to
flap every 30 to 60 sec followed by a nonflapping period of 60 to 120 sec. Turn router flap on and allow
it to continue overnight.
Step 6
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 7
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect free memory for each device being monitored to be about the same, indicating no memory
leaks.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 86 shows the BGP Neighbor Flap test results.
Table 86
BGP Neighbor Flap Test Results
Tests
Results
BGP Neighbor Flap
Pass
BGP Route Flap—With Dampening
Route dampening is a method created to stop unstable routes from being forwarded throughout an
internetwork.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
154
Layer 3 Routing
This test verified that a flapping dampened BGP peer does 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 procedure will simulate constant flapping of those BGP
neighbors. Specifically, the Pagent device rtp-wbu-te-p4 was 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, SH1-100
Test Procedure
The procedure used to perform the BGP Route Flap—With Dampening test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-97 is an eBGP peer with a Pagent router. The Pagent router is sending 35000 route
updates from AS 10.
Step 5
Verify that route-dampening is configured on core devices SH1-97, SH1-98, SH1-99, and SH1-100,
which connect to the Pagent test tool running the BGP emulator.
Step 6
Log in to the Pagent test tool and configure lne bgp interface fa1/0 command (BGP route feed) to
withdraw 10 routes every 1 second and keep each route withdrawn for 10 minutes. Let this test run
overnight.
Step 7
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect free memory for each device being monitored to be about the same, indicating no memory
leaks.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 87 shows the BGP Route Flap—With Dampening test results.
Table 87
BGP Route Flap—With Dampening Test Results
Tests
Results
BGP Route Flap—With Dampening
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
155
Layer 3 Routing
BGP Route Flap—No Dampening
This test verified that a flapping nondampened BGP peer does 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 procedure will simulate constant flapping of those BGP
neighbors. Specifically, the Pagent device rtp-wbu-te-p4 was feeding 65,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, SH1-100
Test Procedure
The procedure used to perform the BGP Route Flap—No Dampening test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-97 is an eBGP peer with a Pagent router. The Pagent router is sending 65,000 route
updates from AS 20.
Step 5
Verify that route-dampening is not configured on core devices SH1-97, SH1-98, SH1-99, and SH1-100,
which connect to the Pagent test tool running the BGP emulator.
Step 6
Log in to the Pagent test tool and configure lne bgp interface fa1/0 command (BGP route feed) to
withdraw 10 routes every 1 second and keep each route withdrawn for 10 minutes. Let this test run
overnight.
Step 7
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect free memory for each device being monitored to be about the same, indicating no memory
leaks.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 88 shows the BGP Route Flap—No Dampening test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
156
Layer 3 Routing
Table 88
BGP Route Flap—No Dampening Test Results
Tests
Results
BGP Route Flap—No Dampening
Pass
Hot Standby Router 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:
•
HSRP Failover with Default Timers—Supervisor 11, page 157
•
HSRP Failover with Default Timers—Supervisor 22—Compact Switching Mode, page 159
•
HSRP Failover with Default Timers—Supervisor 22—Switching in Truncated Mode, page 161
•
HSRP Failover with Fast Timers—Supervisor 11, page 163
•
HSRP Failover with Fast Timers—Supervisor 22, page 165
•
Impact of HSRP Traffic on CPU, page 166
•
Maximum HSRP Group Limit, page 168
•
GE Module Failover with Attached HSRP Groups, page 169
HSRP Failover with Default Timers—Supervisor 11
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 32 is a diagram of relevant topology information.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
157
Layer 3 Routing
Figure 32
HSRP Failover Default Timers—Sup 11 Topology
Devices under test: SH1-105, SH1-106
Test Procedure
The procedure used to perform the HSRP Failover with Default Timers—Supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify the HSRP configurations on devices SH1-105 and SH1-106 for VLANs 40 through 50.
Step 5
Verify that the links between SH1-105 and Dista-1 and the links between SH1-106 and Dista-1 are trunks
and that VLANs 40 to 50 are active within them.
Step 6
Verify that HSRP is active on SH1-106 for VLAN 40 Group 2 (this is the VLAN on which traffic will
be sent by IXIA) and standby on SH1-105 for VLAN 40.
Note
The IXIA traffic stream is configured with the MAC address of the default gateway for group 2.
Step 7
Verify that traffic is being sent to the active HSRP router.
Step 8
Begin the IXIA unicast traffic stream. This stream sends 300,000 packets at 10,000 pps.
Step 9
On SH1-106, shut down the portchannel 20 interface, which should force the unicast traffic stream to
fail over to SH1-105.
Step 10
Verify that the active HSRP router for VLAN 40, group 2 is now SH1-105.
Step 11
Measure the time (using traffic loss) required for the switchover to occur.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
158
Layer 3 Routing
Step 12
Bring the portchannel 20 interface back up on SH1-106.
Step 13
Verify that HSRP on SH1-106 preempts SH1-105 and once again becomes the active HSRP router.
Step 14
Perform a series of four port cycles on the portchannel 20 interface of SH1-106. Measure the average
time required for switchover following interface shutdown (include the results from the first run).
Step 15
Measure the average time required for switchover following interface shutdown (include the results from
the first run).
Step 16
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 17
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic to failover in a reasonable time and no unacceptable impact to the CPU or memory.
Results
Table 89 shows the HSRP Failover with Default Timers—Supervisor 11 test results.
Table 89
HSRP Failover with Default Timers—Supervisor 11 Test Results
Tests
Results
HSRP Failover with Default Timers—Supervisor 11
Pass
HSRP Failover with Default Timers—Supervisor 22—Compact Switching Mode
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 33 is a diagram of relevant topology information.
Figure 33
HSRP Failover Default Timers—Sup 22—CSM Topology
SH1-109 and SH1-110 switch the traffic on the Layer 2 GECs in compact mode.
Devices under test: SH1-109, SH1-110
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
159
Layer 3 Routing
Test Procedure
The procedure used to perform the HSRP Failover with Default Timers—Supervisor 22—Compact
Switching Mode test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify the HSRP configurations on devices SH1-109 and SH1-110 for VLANs 10 through 20.
Step 5
Verify that the links between SH1-109 and Dista-2 and the links between SH1-110 and Dista-2 are trunks
and that VLANs 10 to 20 are active within them.
Step 6
Verify that HSRP is active on SH1-110 for VLAN 17 (this is the VLAN on which traffic will be sent by
IXIA) and standby on SH1-109 for VLAN 17.
Note
The IXIA traffic stream is configured with the MAC address of the default gateway for group 9.
Step 7
Verify that the CEF adjacencies for each of the virtual IP addresses of each of the 11 VLANs are punt,
and not drop, on SH1-110.
Step 8
Verify that traffic is being sent to the active HSRP router.
Step 9
Verify that traffic is being switched in compact mode on the interfaces in portchannel 20.
Step 10
Begin the IXIA unicast traffic stream. This stream sends 30,000 packets at 1000 pps.
Step 11
On SH1-110, shut down the portchannel 20 interface, which should force the unicast traffic stream to
fail over to SH1-109.
Step 12
Verify that the active HSRP router for VLAN 17, group 9 is now SH1-109.
Step 13
Measure the time (using traffic loss) required for the switchover to occur.
Step 14
Bring the portchannel 20 interface back up on SH1-110.
Step 15
Verify that the CEF adjacencies for each of the virtual IP addresses of each of the 11 VLANs are punt,
and not drop, on SH1-110.
Step 16
Verify that HSRP on SH1-110 preempts SH1-109 and once again becomes the active HSRP router.
Step 17
Perform a series of four port cycles on the portchannel 20 interface of SH1-110. Measure the average
time required for switchover following interface shutdown (include the results from the first run).
Step 18
Measure the average time required for switchover following interface shutdown (include the results from
the first run).
Step 19
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 20
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
160
Layer 3 Routing
Expected Results
•
We expect traffic to failover in a reasonable time and no unacceptable impact to the CPU or memory.
Results
Table 90 shows the HSRP Failover with Default Timers—Supervisor 22—Compact Switching Mode test
results.
Table 90
HSRP Failover with Default Timers—Supervisor 22—Compact Switching Mode Test
Results
Tests
Results
HSRP Failover with Default Timers—Supervisor 22—Compact Switching Mode
Pass
HSRP Failover with Default Timers—Supervisor 22—Switching in Truncated Mode
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 34 is a diagram of relevant topology information.
Figure 34
HSRP Failover Default Timers—Sup 22—STM Topology
SH1-101 and SH1-102 switch the traffic on the Layer 2 GECs in truncated mode.
Devices under test: SH1-101, SH1-102
Test Procedure
The procedure used to perform the HSRP Failover with Default Timers—Supervisor 22—Switching in
Truncated Mode test follows:
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
161
Layer 3 Routing
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
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
Verify that HSRP is active on SH1-102 for VLAN 44 (this is the VLAN on which traffic will be sent by
IXIA) and standby on SH1-101 for VLAN 44.
Note
The IXIA traffic stream is configured with the MAC address of the default gateway for group 6.
Step 7
Verify that the CEF adjacencies for each of the virtual IP addresses of each of the 11 VLANs are punt,
and not drop, on SH1-102.
Step 8
Verify that traffic is being sent to the active HSRP router.
Step 9
Verify that traffic is being switched in truncated mode on the interfaces in portchannel 10.
Step 10
Begin the IXIA unicast traffic stream. This stream sends 30,000 packets at 1000 pps.
Step 11
On SH1-102, shut down the portchannel 10 interface, which should force the unicast traffic stream to
fail over to SH1-101.
Step 12
Verify that the active HSRP router for VLAN 44, group 6 is now SH1-101.
SH1-101 is now the active HSRP router on VLAN 44 Group 6.
Step 13
Measure the time (using traffic loss) required for the switchover to occur.
Step 14
Bring the portchannel 10 interface back up on SH1-102.
Step 15
Verify that the CEF adjacencies for each of the virtual IP addresses of each of the 11 VLANs are punt,
and not drop, on SH1-102.
Step 16
Verify that HSRP on SH1-102 preempts SH1-101 and once again becomes the active HSRP router.
SH1-102 is again the active HSRP router for VLAN 44 Group 6.
Step 17
Perform a series of four port cycles on the portchannel 10 interface of SH1-102. Measure the average
time required for switchover following interface shutdown (include the results from the first run).
Step 18
Measure the average time required for switchover following interface shutdown (include the results from
the first run).
Step 19
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 20
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
162
Layer 3 Routing
Expected Results
•
We expect traffic to failover in a reasonable time and no unacceptable impact to the CPU or memory.
Results
Table 91 shows the HSRP Failover with Default Timers—Supervisor 22—Switching in Truncated Mode
test results.
Table 91
HSRP Failover with Default Timers—Supervisor 22—Switching in Truncated Mode Test
Results
Tests
Results
HSRP Failover with Default Timers—Supervisor 22—Switching in Truncated Mode Pass
HSRP Failover with Fast Timers—Supervisor 11
This test verified HSRP failover when a link was down with fast timers configured on the test VLAN.
Fast timers consist of a 1-sec hello timer and a 3-sec dead timer. The traffic was incoming on VLAN 40.
Figure 35 is a diagram of relevant topology information.
Figure 35
HSRP Failover Fast Timers—Sup 11 Topology
Devices under test: SH1-105, SH1-106
Test Procedure
The procedure used to perform the HSRP Failover with Fast Timers—Supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
163
Layer 3 Routing
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify the HSRP configurations on devices SH1-105 and SH1-106 for VLAN 40.
Step 5
Verify that HSRP is active on SH1-106 for VLAN 40 Group 2 (this is the VLAN on which traffic will
be sent by IXIA) and standby on SH1-105 for the same.
Note
The IXIA traffic stream is configured with the MAC address of the default gateway for group 2.
SH1-105 is in standby mode for VLAN 40 Group 2, while SH1-106 is active for the same group.
Step 6
Verify that traffic is being sent to the active HSRP router.
Step 7
Reconfigure Group 2 of VLAN 40 on both SH1-105 and SH1-106 so that the hello and hold timers are
1-sec and 3-sec, respectively.
Step 8
Begin the IXIA unicast traffic stream. This stream sends 300,000 packets at 10,000 pps.
Step 9
On SH1-106, shut down the portchannel 20 interface, which should force the unicast traffic stream to
fail over to SH1-105.
Step 10
Measure the time (using traffic loss) required for the switchover to occur.
Of the 300,000 packets sent, only 276,096 were received. This is a packet loss of 23,904 packets, or a
failover time of 2.39 sec.
Step 11
Bring the portchannel 20 interface back up on SH1-106.
Step 12
Perform a series of four port cycles on the portchannel 20 interface of SH1-106. Measure the average
time required for switchover following interface shutdown (include the results from the first run).
Step 13
Measure the average time required for switchover following interface shutdown (include the results from
the first run).
Step 14
Remove the fast timers configuration from VLAN 40 of SH1-105 and SH1-106.
Step 15
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 16
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Figure 36
HSRP Failover Fast Timers—Sup 11 DUT CPU Usage
Expected Results
•
We expect traffic to failover in a reasonable time and no unacceptable impact to the CPU or memory.
Results
Table 92 shows the HSRP Failover with Fast Timers—Supervisor 11 test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
164
Layer 3 Routing
Table 92
HSRP Failover with Fast Timers—Supervisor 11 Test Results
Tests
Results
HSRP Failover with Fast Timers—Supervisor 11
Pass
HSRP Failover with Fast Timers—Supervisor 22
This test verified HSRP failover when a link was down with fast timers configured on the test VLAN.
Fast timers consist of a 1-sec hello timer and a 3-sec hold timer. The traffic was incoming on VLAN 44.
Figure 37 is a diagram of relevant topology information.
Figure 37
HSRP Failover Fast Timers—Sup 22 Topology
Devices under test: SH1-101, SH1-102
Test Procedure
The procedure used to perform the HSRP Failover with Fast Timers—Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify the HSRP configurations on devices SH1-101 and SH1-102 for VLAN 44.
Step 5
Verify that HSRP is active on SH1-102 for VLAN 44 Group 6 (this is the VLAN on which traffic will
be sent by IXIA) and standby on SH1-101 for the same.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
165
Layer 3 Routing
Note
The IXIA traffic stream is configured with the MAC address of the default gateway for group 6.
Step 6
Verify that traffic is being sent to the active HSRP router.
Step 7
Reconfigure Group 6 of VLAN 44 on both SH1-101 and SH1-102 so that the hello and hold timers are
1-sec and 3-sec, respectively.
Step 8
Begin the IXIA unicast traffic stream. This stream sends 300,000 packets at 10,000 pps.
Step 9
On SH1-102, shut down the portchannel 10 interface, which should force the unicast traffic stream to
fail over to SH1-101.
Step 10
Measure the time (using traffic loss) required for the switchover to occur.
Step 11
Bring the portchannel 10 interface back up on SH1-102.
Step 12
Perform a series of four port cycles on the portchannel 20 interface of SH1-102. Measure the average
time required for switchover following interface shutdown (include the results from the first run).
Step 13
Measure the average time required for switchover following interface shutdown (include the results from
the first run).
Step 14
Remove the fast timers configuration from VLAN 44 of SH1-101 and SH1-102.
Step 15
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 16
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Figure 38
HSRP Failover Fast Timers—Sup 22 SH1-101 CPU Usage
Expected Results
•
We expect traffic to failover in a reasonable time and no unacceptable impact to the CPU or memory.
Results
Table 93 shows the HSRP Failover with Fast Timers—Supervisor 22 test results.
Table 93
HSRP Failover with Fast Timers—Supervisor 22 Test Results
Tests
Results
HSRP Failover with Fast Timers—Supervisor 22
Pass
Impact of HSRP Traffic on CPU
This test measures the impact of traffic on the CPU of the Sup22 when traffic was going through a VLAN
that has 16 HSRP groups configured on it. VLANs 60 and 61 were configured on SH1-101 and SH1-102.
Sixteen separate HSRP groups (101 to 116) were configured on each VLAN interface. Traffic was
sourced from IXIA, connected to Dista-1, on VLAN 60. The destination was an IXIA port also
connected to Dista-1, on VLAN 61. Traffic was sent at increasing rates of 100,000 pps, 250,000 pps,
500,000 pps, and 1 million pps. The CPU and memory utilization was measured during the test.
Figure 39 is a diagram of relevant topology information.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
166
Layer 3 Routing
Figure 39
Impact of HSRP Traffic on CPU Usage Topology
Devices under test: SH1-101, SH1-102
Test Procedure
The procedure used to perform the Impact of HSRP Traffic on CPU test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Write the running-configuration to memory (NVRAM) so that it can be recalled later. Do this for
SH1-101 and SH1-102.
Step 5
Determine which VLAN interfaces are present on the device.
Step 6
Remove any VLANs discovered inStep 5 for both SH1-101 and SH1-102, with the exception of
VLAN 1. Perform this function on each device, for its respective VLANs.
Step 7
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 numbered groups, and SH1-102 will be active HSRP router for the even
numbered groups. Also configure each VLAN to participate in multicast PIM-SM.
Step 8
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 9
Verify that ports 6/5 and 6/6 on Dista-1 are on VLANs 60 and 61, respectively.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
167
Layer 3 Routing
Step 10
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. A total of 22.5 million packets will be sent, at these
varying rates.
Step 11
Verify that 100% of the traffic sent was received on the proper port.
Step 12
Remove the VLAN 60 and VLAN 61 configurations from SH1-101 and SH1-102.
Step 13
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 6), restoring the default configuration for the
devices under test.
Step 14
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 15
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Figure 40
Impact of HSRP Traffic on CPU Usage SH1-101 CPU Usage
Expected Results
•
We expect 100% of the traffic sent at the varying rates to be received correctly, with no unacceptable
impact on CPU or memory.
Results
Table 94 shows the Impact of HSRP Traffic on CPU test results.
Table 94
Impact of HSRP Traffic on CPU Test Results
Tests
Results
Impact of HSRP Traffic on CPU
Pass
Maximum HSRP Group Limit
The PFC2/MSFC2 supports a maximum of 16 unique HSRP groups. There have been issues that in
recent Cisco IOS code no warnings were given should more than 16 unique HSRP groups be configured.
This test demonstrates that an error message was displayed as the attempt was made to configure the 17th
group.
Device under test: SH1-103
Test Procedure
The procedure used to perform the Maximum HSRP Group Limit test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
168
Layer 3 Routing
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Configure 16 HSRP groups on VLAN 100 of SH1-103.
Step 5
Attempt to configure the 17th HSRP group.
Step 6
Remove VLAN 100 from the configuration on SH2-104.
Step 7
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect an error message to appear on an attempt to configure the 17th HSRP group, and the 17th
group to not be configurable.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 95 shows the Maximum HSRP Group Limit test results.
Table 95
Maximum HSRP Group Limit Test Results
Tests
Results
Maximum HSRP Group Limit
Pass
GE Module Failover with Attached HSRP Groups
This test involves resetting one or more GE modules to which HSRP groups were attached. The traffic
was incoming on VLAN 20.
Device under test: SH1-110
Test Procedure
The procedure used to perform the GE Module Failover with Attached HSRP Groups test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-110 is the active HSRP router for VLAN 20 group 12.
Step 5
Reset module 3 on SH1-110.
Step 6
Once module 3 comes back online, verify that SH1-110 is still the active HSRP router for VLAN 20
group 12.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
169
Layer 3 Routing
Step 7
Determine the amount of traffic loss.
Step 8
Start the test traffic stream.
Step 9
Verify that SH1-110 is the active HSRP router for VLAN 20 group 12.
Step 10
Reset module 4 on SH1-110.
Step 11
Verify that SH1-110 is still the active HSRP router for VLAN 20 group 12.
Step 12
Determine the amount of traffic loss.
Step 13
Start the test traffic stream.
Step 14
Verify that SH1-110 is the active HSRP router for VLAN 20 group 12.
Step 15
Reset both modules 3 and 4 on SH1-110.
Step 16
Verify that SH1-110 is no longer the standby HSRP router for VLAN 20 group 12.
Step 17
Determine the amount of traffic loss.
Step 18
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 19
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect traffic to stop flowing over portchannel 20 when module 3 is reset because module 3
affects portchannels 20, along with 1, 70 and 71. SH1-109 takes over as the FHR due to the greater
bandwidth (that is, more active ports per portchannel). Once the ports on SH1-110 became active
again, we expect the traffic to switch back over to SH1-110.
•
We expect HSRP on SH1-109 to take over when all 4 Gigabit Ethernet interfaces are failed on
portchannel 20 of SH1-110.
•
We expect failover in a reasonable time and no unacceptable impact to the CPU or memory.
Results
Table 96 shows the GE Module Failover with Attached HSRP Groups test results.
Table 96
GE Module Failover with Attached HSRP Groups Test Results
Tests
Results
GE Module Failover with Attached HSRP Groups
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
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
170
Layer 3 Routing
change to synchronize at the same time. Routers that were not affected by topology changes were not
involved in recomputations. The convergence time with DUAL rivals that of any other existing routing
protocol.
The following tests were performed:
•
EIGRP Summarization, page 171
•
Redistribute OSPF into EIGRP, page 172
EIGRP Summarization
This test verified manual EIGRP summarization by using the ip summary-address interface
configuration command.
Several /24 networks known via EIGRP by device SH1-101 can be summarized as a single /22 network
on the portchannels of devices SH1-99 and SH1-100 (portchannels 14 and 15). This test involved the
summarization of the routes 172.31.20.0/24 to 172.31.23.0/24 into 172.31.20.0/22.
Devices under test: SH1-99, SH1-100, SH1-101
Test Procedure
The procedure used to perform the EIGRP Summarization test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Run the test script.
Step 5
Display that the routes are not summarized and exist as /24 routes on SH1-101.
Step 6
Configure the ip summary-address eigrp command on the portchannel 14 and portchannel 15 interfaces
of SH1-100 and SH1-99.
Step 7
Verify that the routes to the networks that were shown in Step 5 now have an entry on the summary
subnet of 172.31.20.0/22.
Step 8
Remove the summarization configuration statements applied in Step 6.
Step 9
Verify that the routing entries appear as /24 networks.
Step 10
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the /24 networks shown to be correctly summarized as /22 networks without a sustained
or abnormal impact on the CPU or memory.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
171
Layer 3 Routing
Results
Table 97 shows the EIGRP Summarization test results.
Table 97
EI GRP Summarization Test Results
Tests
Results
EIGRP Summarization
Pass
Redistribute OSPF into EIGRP
This test verified that EIGRP route redistribution works correctly, with and without access lists (ACLs)
and route map filtering. SH1-99 and SH1-100 were redistributing OSPF routes into EIGRP 1320, of
which SH1-101 is a member (Figure 41).
Figure 41
EIGRP Redistribution Topology
This test uses 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 were 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 were 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 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 reconfigured redistribution as it was in the default setup for
this network allowing all 160.x.x.x networks to be redistributed.
Devices under test: SH1-97, SH1-99, SH1-100, SH1-101
Test Procedure
The procedure used to perform the Redistribute OSPF into EIGRP test follows:
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
172
Layer 3 Routing
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin the test script.
Step 5
Display the default EIGRP configuration for devices SH1-99 and SH1-100.
Step 6
Display that, with the default EIGRP configuration (allowing redistribution), the 160.x.x.x networks are
propagated to SH1-101.
Step 7
Display that SH1-101 has a full routing table with about 20,000 total routes (10,000 routes from OSPF
1 and 10,000 routes from EIGRP 1320).
Step 8
Remove the redistribution configuration from devices SH1-99 and SH1-100.
Step 9
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 trimmed by about 10,000 routes. It may be several minutes before the old routes time out
and are eliminated.
Step 10
Display the route map OSPF2EIGRP-odd and access list 22 on SH1-99 and SH1-100.
Step 11
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 12
Verify that the only routes for the 160.x.x.x networks that are on SH1-101 are for the odd networks,
160.1.1.0, 160.1.3.0, 160.1.5.0, and so on.
Step 13
Display that the number of subnets in the routing table of SH1-101 has been decreased by 5000.
Step 14
Reconfigure the default redistribution configuration that was removed in Step 8.
Step 15
Verify that all of the 160.x.x.x networks are redistributed into SH1-101 (odd and even), and that the
routing table on SH1-101 is back to normal status (seen in Step 5).
Step 16
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 17
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect when the default redistribution configuration is removed from SH1-99 and SH1-100,
none of the 10,000 OSPF routes is propagated to SH1-101.
•
We expect when the route map OSPF2EIGRP-odd is applied, with redistribution, on SH1-99 and
SH1-100, only the odd subnets within 160.x.x.x is propagated to SH1-101.
•
We expect when the default redistribution configuration is reapplied to SH1-99 and SH1-100, all of
the routes for the 160.x.x.x networks are in the routing table of SH1-101 and that the routing table
is populated correctly in its default state.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
173
Network Management
Results
Table 98 shows the Redistribute OSPF into EIGRP test results.
Table 98
Redistribute OSPF into EIGRP Test Results
Tests
Results
Redistribute OSPF into EIGRP
Pass
Network Management
Network Management testing for Safe Harbor consists of the following tests:
•
Simple Network Management Protocol, page 174
•
TACACS, page 177
Simple Network Management Protocol
The Simple Network Management Protocol (SNMP) system consists of three parts: An SNMP manager,
an SNMP agent, and a Management Information Base (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 were designed to provoke undesired behavior of the subject implementation. In
summary, 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 174
•
Basic Functionality Shut/No Shut Interface—Supervisor 22, page 175
•
Protos Negative Testing, page 176
Basic Functionality Shut/No Shut Interface—Supervisor 11
This test verified the basic SNMP functionality of the Supervisor 11. In this procedure, SNMP traps were
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 Procedure
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.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
174
Network Management
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-106 is configured to send SNMP traps generated by configuration messages to the server
172.18.177.135.
Step 5
Enter and leave configuration mode on SH1-106, generating a log message.
Step 6
Verify that the traps are received by a machine that is set up as the SNMP trap receiver. Display the
output from the log files of that machine.
Step 7
Display the log for error messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect SNMP to function according to specifications, generating and sending a trap to the
configured host.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 99 shows the Basic Functionality Shut/No Shut Interface—Supervisor 11 test results.
Table 99
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 were
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 Procedure
The procedure used to perform the Basic Functionality Shut/No Shut Interface—Supervisor 22 test
follows:
Step 1
Note
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.Record
the version, start time, and CPU utilization from each DUT.
There was a crash recorded on SH1-101 before the beginning of this test. It was caused intentionally
while another issue is investigated.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
175
Network Management
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-110 is configured to send SNMP traps generated by configuration messages to the server
172.18.177.135.
Step 5
Enter and leave configuration mode on SH1-110, generating a log message.
Step 6
Verify that the traps are received by a machine that is set up as the SNMP trap receiver. Display the
output from the log files of that machine.
Step 7
Display the log for error messages.
Step 8
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect SNMP to function according to specifications, generating and sending a trap to the
configured host.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 100 shows the Basic Functionality Shut/No Shut Interface—Supervisor 22 test results.
Table 100
Basic Functionality Shut/No Shut Interface—Supervisor 22 Test Results
Tests
Results
Basic Functionality Shut/No Shut Interface—Supervisor 22
Pass
Protos Negative Testing
This test verified that no SNMP vulnerabilities exist in the Cisco Native IOS code. Protos testing
involves sending erroneous SNMP packets to the device under test. Run these tests on all permutations
of supervisor and MSFC. This is a negative test, so the only verification available is that the DUT was
unaffected.
Test Procedure
The procedure used to perform the Protos Negative Testing test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
176
Network Management
Step 4
Start background unicast and multicast traffic at 25,000 pps.
Step 5
Verify the SNMP Community String settings default.
Step 6
Execute the protos traffic generation scripts. The protos test cases will be sent to each DUT using
packetmaster test engine.
Step 7
After background traffic is done, verify that no packets were lost. Display the results.
Step 8
Display the log for error messages.
Step 9
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect all DUTs to not drop any of the background traffic while the test is being run.
•
We expect all DUTs to not pause indefinitely, or give any tracebacks while the test is being run.
Results
Table 101 shows the Protos Negative Testing test results.
Table 101
Protos Negative Testing Test Results
Tests
Results
Protos Negative Testing
Pass
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 tests were performed:
•
Verify User Authentication—Supervisor 11, page 177
•
Verify User Authentication—Supervisor 22, page 179
Verify User Authentication—Supervisor 11
This test verified that the TACACS login authentication works correctly on a Supervisor 1/MSFC1
system. The server 172.18.177.132 was a TACACS server. It was used in this test as the source of user
authentication information.
Device under test: SH1-106
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
177
Network Management
Note
Use console on access server (172.18.177.169 2011) to get to SH1-106, not Telnet.
Test Procedure
The procedure used to perform the Verify User Authentication—Supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-106 has connectivity to the TACACS server 172.18.177.132.
Step 5
Configure SH1-106 to be a TACACS device with 172.18.177.132 as its server.
Step 6
Verify that user authentication is necessary on SH1-106. Telnet from SH1-105 to SH1-106.
Step 7
Shut down the interface connecting SH1-106 with the TACACS server.
Step 8
Verify that SH1-106 no longer has connectivity to the TACACS server.
Step 9
Telnet to SH1-105 to SH1-106 and verify that the login process reverts to Cisco IOS default.
Step 10
Remove the TACACS configuration from SH1-106.
Step 11
Bring the flashnet interface back online.
Step 12
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 13
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect TACACS login authentication to work correctly.
•
We expect when the TACACS server becomes unavailable, the login process reverts to the Cisco IOS
default.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 102 shows the Verify User Authentication—Supervisor 11 test results.
Table 102
Verify User Authentication—Supervisor 11 Test Results
Tests
Results
Verify User Authentication—Supervisor 11
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
178
Network Management
•
There was no unacceptable impact on either the CPU or memory of the devices under test.
Verify User Authentication—Supervisor 22
This test verified that the TACACS login authentication works correctly on a Supervisor 2/MSFC 2
system. The server 172.18.177.132 was a TACACS server. It was used in this test as the source of user
authentication information.
Device under test: SH1-104.
Note
Use console on access server (172.18.177.171 2104) to get to SH1-104, not Telnet.
Test Procedure
The procedure used to perform the Verify User Authentication—Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-104 has connectivity to the TACACS server 172.18.177.132.
Step 5
Configure SH1-104 to be a TACACS device with 172.18.177.132 as its server.
Step 6
Verify that user authentication is necessary on SH1-104. Telnet from SH1-110 to SH1-104.
Step 7
Shut down the interface connecting SH1-104 with the TACACS server.
Step 8
Verify that SH1-104 no longer has connectivity to the TACACS server.
Step 9
Telnet SH1-110 to SH1-104 from and verify that the login process reverts to Cisco IOS default.
Step 10
Remove the TACACS configuration from SH1-104.
Step 11
Bring the flashnet interface back online.
Step 12
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 13
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect TACACS login authentication to work correctly.
•
We expect when the TACACS server becomes unavailable, the login process reverts to the Cisco IOS
default.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
179
Miscellaneous Features
Results
Table 103 shows the Verify User Authentication—Supervisor 22 test results.
Table 103
Verify User Authentication—Supervisor 22 Test Results
Tests
Results
Verify User Authentication—Supervisor 22
Pass
Miscellaneous Features
Network management testing for Safe Harbor consists of the following tests:
•
Dynamic Host Control Protocol, page 180
•
SPAN, page 183
•
Large Access Control Lists, page 185
•
CLI Parser Testing, page 187
•
Network Address Translation, page 189
•
Network Time Protocol, page 199
•
Syslog, page 202
•
User Datagram Protocol Broadcast Flooding, page 204
•
System Upgrade, page 206
•
Secure Shell, page 212
Dynamic Host Control Protocol
As explained in RFC 2131, Dynamic Host Configuration Protocol, DHCP provides configuration
parameters to Internet hosts. DHCP has two components: a protocol for delivering host-specific
configuration parameters from a DHCP server to a host and a mechanism for allocating network
addresses to hosts. DHCP is built on a client/server model, where designated DHCP server hosts allocate
network addresses and deliver configuration parameters to dynamically configured hosts.
The following tests were performed:
•
DHCP Broadcast Forwarding—Supervisor 11, page 180
•
DHCP Broadcast Forwarding—Supervisor 22, page 182
DHCP Broadcast Forwarding—Supervisor 11
Figure 42 shows the basic steps that occur when a DHCP client requests an IP address from a DHCP
server. The client, Host A, sends a DHCPDISCOVER broadcast message to locate a Cisco IOS DHCP
server. A DHCP server offers configuration parameters (such as an IP address, a MAC address, a domain
name, and a lease for the IP address) to the client in a DHCPOFFER unicast message.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
180
Miscellaneous Features
Figure 42
Basic DHCP—Sup 11 Topology
Because the DHCPDISCOVER and DHCPREQUEST packets were broadcast, only hosts on the same
LAN segment will receive them. If the DHCP server was on a different LAN segment, additional
configuration was necessary in order for the server to receive the client's packets. On the router interface
that was on a directly connected LAN segment with the client, configure an IP helper address pointing
to the DHCP server. This address will enable the forwarding of User Datagram Protocol (UDP)
broadcasts, including BOOTP and DHCP, received on that interface to the DHCP server.
Test Procedure
The procedure used to perform the DHCP Broadcast Forwarding—Supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the DUT has an IP helper address configured on the incoming interface.
Step 5
Verify that the DHCP server is configured on the device specified by the IP helper address.
Verify that the no dhcp server conflict logging command is configured. Verify that all the router IP
addresses on the client subnet have been excluded. Verify that a DHCP pool for the client subnet has
been configured.
Step 6
Clear any previous DHCP server statistics on the DHCP server and enable DHCP debugging.
Verify that the server statistics have been zeroed out.
Step 7
Launch, configure, and run the script.
Step 8
Verify that the DHCP discover and request messages are forwarded by the DUT to the DHCP server.
Verify that a DHCPDISCOVER message was received from the script through the DUT as relay. Verify
that after the DHCPOFFER is sent, a DHCPREQUEST is received from the same client.
Step 9
Turn off DHCP debugging on the DHCP server.
Step 10
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
181
Miscellaneous Features
Expected Results
•
We expect all DHCP broadcast messages sent from the IXIA to be forwarded to the DHCP server.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 104 shows the DHCP Broadcast Forwarding—Supervisor 11 test results.
Table 104
DHCP Broadcast Forwarding—Supervisor 11 Test Results
Tests
Results
DHCP Broadcast Forwarding—Supervisor 11
Pass
DHCP Broadcast Forwarding—Supervisor 22
Figure 43 shows the basic steps that occur when a DHCP client requests an IP address from a DHCP
server. The client, Host A, sends a DHCPDISCOVER broadcast message to locate a Cisco IOS DHCP
server. A DHCP server offers configuration parameters (such as an IP address, a MAC address, a domain
name, and a lease for the IP address) to the client in a DHCPOFFER unicast message.
Figure 43
Basic DHCP—Sup 22 Topology
Since the DHCPDISCOVER and DHCPREQUEST packets were broadcast, only hosts on the same LAN
segment will receive them. If the DHCP server was on a different LAN segment, additional configuration
was necessary in order for the server to receive the client's packets. On the router interface that was on
a directly connected LAN segment with the client, configure an IP helper-address pointing to the DHCP
server. This will enable the forwarding of UDP broadcasts, including BOOTP and DHCP, received on
that interface to the DHCP server.
Test Procedure
The procedure used to perform the DHCP Broadcast Forwarding—Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the DUT has an IP helper address configured on the incoming interface.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
182
Miscellaneous Features
Step 5
Verify that the DHCP server is configured on the device specified by the IP helper address.
Verify that the no dhcp server conflict logging command is configured. Verify that all the router IP
addresses on the client subnet have been excluded. Verify that a DHCP pool for the client subnet has
been configured.
Step 6
Clear any previous DHCP server statistics on the DHCP server and enable DHCP debugging.
Verify that the server statistics have been zeroed out.
Step 7
Launch, configure, and run the script.
Step 8
Verify that the DHCP discover and request messages are forwarded by the DUT to the DHCP server.
Verify that a DHCPDISCOVER message was received from the script through the DUT as relay. Verify
that after the DHCPOFFER is sent, a DHCPREQUEST is received from the same client.
Step 9
Turn off DHCP debugging on the DHCP server.
Step 10
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect all DHCP broadcast messages sent from the IXIA to be forwarded to the DHCP server.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 105 shows the DHCP Broadcast Forwarding—Supervisor 22 test results.
Table 105
DHCP Broadcast Forwarding—Supervisor 22 Test Results
Tests
Results
DHCP Broadcast Forwarding—Supervisor 22
Pass
SPAN
Local 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 183
SPAN Basic Functionality
This test verified the basic functionality of the SPAN feature across both the Supervisor 1 and Supervisor
2 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 (Sup22), SH1-108 (Sup12), and SH1-102 (Sup22) along the way to the two
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
183
Miscellaneous Features
destinations. There were four interfaces in these three devices configured to monitor the multicast traffic.
These four interfaces were on various modules, the WS-X6348-RJ-45, the WS-X6408-GBIC, the
WS-X6516-GBIC, and the WS-X6816-GBIC.
Devices under test: SH1-110, SH1-108, SH1-102
Test Procedure
The procedure used to perform the SPAN Basic Functionality test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Configure the SPAN sessions on SH1-102, SH1-106, SH1-10, and SH1-110 after clearing any existing
sessions.
Step 5
Clear the counters on all four devices.
Step 6
Begin an IXIA stream sending 300,000 packets from multiple sources to multiple destinations. The
Background Unicast and Test Multicast traffic is used here; the Background Multicast traffic is not used.
Step 7
Display the results of the packets received on the monitoring interfaces (those packets sent to the
attached IXIA ports).
Step 8
Compare the counters from each monitored interface with the packets reported received by IXIA.
Step 9
Remove the SPAN configurations from the devices.
Step 10
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 11
Verify that there was no significant impact on the CPU or memory of the DUT.
Expected Results
•
We expect each packet sent in the test traffic stream to be duplicated on each of the four monitor
destination interfaces.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 106 shows the SPAN Basic Functionality test results.
Table 106
SPAN Basic Functionality Test Results
Tests
Results
SPAN Basic Functionality
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
184
Miscellaneous Features
Large Access Control Lists
Access Control Lists (ACL) are used to classify traffic and permit or deny forwarding based on this
classification.
The following tests were performed:
•
ACL 110, page 185
•
ACL 131, page 186
ACL 110
ACL 110 is a 1404-line access list taken from customer configuration. The 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.
10,000 packets from each stream were sent through the router and back to the IXIA. The script then
checks the IXIA statistics to verify that for each stream which matched a permit, 10,000 packets were
received and for each stream that matched a deny, no packets were received. This script was run against
a Supervisor 11, Supervisor 12, and Supervisor 22.
Test Procedure
The procedure used to perform the ACL 110 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin the ACL test script on SH1-105, SH1-107, and SH1-102.
Step 5
Using the script's output file, verify that all packets were permitted or denied correctly.
Step 6
Display the log for error messages.
Step 7
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect each DUT to not permit denied traffic, and to not deny permitted traffic.
•
We expect all traffic to be hardware switched, and no permitted packets dropped.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 107 shows the ACL 110 test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
185
Miscellaneous Features
Table 107
ACL 110 Test Results
Tests
Results
ACL 110
Pass
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
which matches the ACL. 10,000 packets from each stream were sent through the router and back to the
IXIA. The script then checks the IXIA statistics to verify that for each stream which matched a permit,
10,000 packets were received and for each stream which matched a deny, no packets were received.
Note
In order to fit this ACL in the TCAM you need to be using the ODM aclmerge algorithm. This feature
was not supported until Release 12.1(11b)E4. Until then the ACL must be split into two ACLs and
run separately.
Test Procedure
The procedure used to perform the ACL 131 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin the ACL test script on SH1-105, SH1-107, and SH1-102.
Step 5
Verify using script output file that all packets were permitted or denied correctly.
Step 6
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 7
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect each DUT to not permit denied traffic, and to not deny permitted traffic.
•
We expect all traffic to be hardware switched, and no permitted packets dropped.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 108 shows the ACL 131 test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
186
Miscellaneous Features
Table 108
ACL 131 Test Results
Tests
Results
ACL 131
Pass
CLI Parser Testing
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, show tag-switching
tdp, show mpls).
The following tests were performed:
•
Show-All Script with Relogin via Telnet, page 187
•
Show-All Script with Relogin via SSH, page 188
Show-All Script with Relogin via Telnet
An automated script was used to test over 19,000 valid show and clear commands on a Supervisor 11,
Supervisor 12, and Supervisor 22. Certain commands were left out (for example, show memory, show
tag-switching tdp, and show mpls) due to the length of time they take to execute. After executing 25
valid commands, the script would log out and then relogin to the device under test.
Test Procedure
The procedure used to perform the Show-All Script with Relogin via Telnet test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin executing show and clear commands on the devices under test.
Step 5
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 6
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect all commands to be executed without the router suspending indefinitely, giving
tracebacks, rebooting, or having CPU problems.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
187
Miscellaneous Features
Results
Table 109
Host
Note
Command Execution Validation by Host Device with Relogin via Telnet
Valid Commands Executed Invalid Commands Executed
SH1-109 33783
73751
SH1-105 19427
89348
SH1-107 19997
90286
Actual logged results are available upon request, but are too extensive for output.
Table 110 shows the Show-All Script with Relogin via Telnet test results.
Table 110
Show-All script with Relogin via Telnet Test Results
Tests
Results
Show-All Script with Relogin via Telnet
Pass
Show-All Script with Relogin via SSH
An automated script was used to test over 19,000 valid show and clear commands on a Supervisor 11,
Supervisor 12, and Supervisor 22. Certain commands were left out (for example, show memory, show
tag-switching tdp, and show mpls) due the length of time they take to execute. After executing 10 valid
commands, the script would log out and to then relogin to the device under test.
Test Procedure
The procedure used to perform the Show-All Script with Relogin via SSH test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that each DUT is configured with a host name, domain name, and TACACS authentication on vty
lines.
Step 5
Verify the SSH server on each DUT is enabled by generating an RSA key pair. Configure the vty lines
to allow SSH, and verify that each DUT is accepting SSH connections.
Step 6
Begin executing show and clear commands on the devices under test.
Step 7
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
188
Miscellaneous Features
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect all commands to be executed without the router suspending indefinitely, giving
tracebacks, rebooting, or having CPU problems.
Results
Table 111
Note
Command Execution Validation by Host Device with Relogin via SSH
Host
Valid Commands Executed Invalid Commands Executed
SH1-98
33,331
73,437
SH1-105 19,597
89,694
SH1-107 20,193
90,651
Actual logged results are available upon request, but are too extensive for output.
Table 112 shows the Show-All Script with Relogin via SSH test results.
Table 112
Show-All Script with Relogin via SSH Test Results
Tests
Results
Show-All Script with Relogin via SSH Pass with exception CSCec56837
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 non-globally 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 NAT Using 2 Hosts, page 190
•
Static NAT Using 40 Hosts, page 191
•
Extended Static NAT Using 40 Hosts, page 192
•
Static NAT Using 2 Networks, page 193
•
Static Inside Dynamic Outside, page 194
•
Dynamic Inside Static Outside, page 195
•
NAT Addition and Removal of NAT Statements, page 196
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
189
Miscellaneous Features
•
Overnight Static NAT Using 40 Hosts, page 197
•
Static Inside/Random Outside with 40 Hosts, page 198
Static NAT Using 2 Hosts
This test verified the basic functionality of the NAT feature on a Supervisor 2/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 Procedure
The procedure used to perform the Static NAT Using 2 Hosts test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
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 4
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
While traffic is being sent, turn monitoring on the inside interface, then 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 5
After traffic has been sent, verify that no packets were lost and stop SNMP data collection. Display
current status of NAT, interfaces, and buffers on the DUT. Verify that the memory and CPU did not suffer
severe or sustained impact during the test.
Step 6
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 7
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect all unicast packets to be translated correctly.
•
We expect all multicast packets forwarded correctly.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 113 shows the Static NAT Using 2 Hosts test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
190
Miscellaneous Features
Table 113
Static NAT Using 2 Hosts Test Results
Tests
Results
Static NAT Using 2 Hosts
Pass
Static NAT Using 40 Hosts
This test verified the basic functionality of the NAT feature on a Supervisor 2/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 Procedure
The procedure used to perform the Static NAT Using 40 Hosts test follows:
Step 1
Begin monitoring the DUT's CPU utilization and memory usage. Also, verify joins are being sent from
the IXIA to the NAT outside interface.
Step 2
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 3
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
While traffic is being sent, turn monitoring on the inside interface, then the outside interface, and capture
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 4
After traffic has been sent, verify that no packets were lost and stop SNMP data collection. Display the
current status of NAT, the interfaces, and buffers on the DUT. Verify that the memory and CPU did not
suffer severe or sustained impact during the test.
Step 5
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 6
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect all unicast packets to be translated correctly.
•
We expect all multicast packets forwarded correctly.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 114 shows the Static NAT Using 40 Hosts test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
191
Miscellaneous Features
Table 114
Static NAT Using 40 Hosts Test Results
Tests
Results
Static NAT Using 40 Hosts
Pass
Extended Static NAT Using 40 Hosts
This test verified the basic functionality of the NAT feature on a Supervisor 2/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 Procedure
The procedure used to perform the Extended Static NAT Using 40 Hosts test follows:
Step 1
Use the appropriate script to gather preliminary logging and version information.
Step 2
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 3
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
While traffic is being sent, turn monitoring on the inside interface, then 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 4
After traffic has been sent, verify that no packets were lost and stop SNMP data collection. Display the
current status for NAT, interfaces, and buffers on the DUT. Verify that the memory and CPU did not
suffer severe or sustained impact during the test.
Step 5
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 6
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect all unicast packets to be translated correctly.
•
We expect all multicast packets forwarded correctly.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 115 shows the Extended Static NAT Using 40 Hosts test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
192
Miscellaneous Features
Table 115
Extended Static NAT Using 40 Hosts Test Results
Tests
Results
Extended Static NAT Using 40 Hosts
Pass
Static NAT Using 2 Networks
This test verified the basic functionality of the NAT feature on a Supervisor 2/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 Procedure
The procedure used to perform the Static NAT Using 2 Networks test follows:
Step 1
Use the appropriate script to gather preliminary logging and version information.
Step 2
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 3
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
While traffic is being sent, turn monitoring on the inside interface, then the outside interface, and capture
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 4
After traffic has completed, confirm that no packets were lost and stop SNMP data collection. Display
current status NAT, interfaces, and buffers on the DUT. Verify that the memory and CPU did not suffer
severe or sustained impact during the test.
Step 5
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 6
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect all unicast packets to be translated correctly.
•
We expect all multicast packets forwarded correctly.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 116 shows the Static NAT Using 2 Networks test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
193
Miscellaneous Features
Table 116
Static NAT Using 2 Networks Test Results
Tests
Results
Static NAT Using 2 Networks
Pass
Static Inside Dynamic Outside
This test verified the basic functionality of the NAT feature on a Supervisor 2/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 Procedure
The procedure used to perform the Static Inside Dynamic Outside test follows:
Step 1
Use the appropriate script to gather preliminary logging and version information.
Step 2
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 3
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
While traffic is being sent, turn monitoring on the inside interface, then the outside interface, and capture
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 4
After traffic has been sent, verify that no packets were lost and stop SNMP data collection. Display
current status NAT, interfaces, and buffers on the DUT. Verify that the memory and CPU did not suffer
severe or sustained impact during the test.
Step 5
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 6
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect all unicast packets to be translated correctly.
•
We expect all multicast packets forwarded correctly.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 117 shows the Static Inside Dynamic Outside test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
194
Miscellaneous Features
Table 117
Static Inside Dynamic Outside Test Results
Tests
Results
Static Inside Dynamic Outside
Pass
Dynamic Inside Static Outside
This test verified the basic functionality of the NAT feature on a Supervisor 2/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 Procedure
The procedure used to perform the Dynamic Inside Static Outside test follows:
Step 1
Use the appropriate script to gather preliminary logging and version information.
Step 2
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 3
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
While traffic is being sent, turn monitoring on the inside interface, then the outside interface, and capture
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 4
After traffic has completed, confirm that no packets were lost and stop SNMP data collection. Show
current status NAT, interfaces, and buffers on the DUT. Verify that the memory and CPU did not suffer
severe or sustained impact during the test on the DUT.
Step 5
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 6
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect all unicast packets to be translated correctly.
•
We expect all multicast packets forwarded correctly.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 118 shows the Dynamic Inside Static Outside test results.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
195
Miscellaneous Features
Table 118
Dynamic Inside Static Outside Test Results
Tests
Results
Dynamic Inside Static Outside
Pass
NAT Addition and Removal of NAT Statements
This test measured the impact on the CPU for the removal and addition of NAT statements, while those
translations were in use. Four NAT statements are on switch SH1-97, translating four outside global
addresses into four outside local addresses. Traffic was passed with source IP addresses of the four
outside global addresses. As traffic was being passed, the NAT statements for those four particular
translations were removed, and then readded again, while the CPU was being monitored.
Device under test: SH1-97
Test Procedure
The procedure used to perform the NAT Addition and Removal of NAT Statements test follows:
Step 1
Use the appropriate script to gather preliminary logging and version information.
Step 2
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 3
Begin sending unicast NAT traffic. While traffic is being sent, turn monitoring on the inside interface,
then the outside interface, and capture 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 4
Remove each of the static NAT statements every 10 sec and readd them again. Then remove all 4 NAT
statements at once, and then readd them again. Remove the first two NAT statements 10 sec apart,
followed by removing the last two statements at once. Then readd all four statements again.
Step 5
After NAT statements readded, turn monitoring on the inside interface, then the outside interface, and
capture 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 6
After traffic has been sent, show current status of NAT, interfaces, and buffers on the DUT. Verify that
the memory and CPU did not suffer severe or sustained impact during the test.
Step 7
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 8
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect all translations to be correct.
•
We expect removal and addition of NAT statements to not cause NAT to fail.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
196
Miscellaneous Features
Results
Table 119 shows the NAT Addition and Removal of NAT Statements test results.
Table 119
NAT Add/Removal of NAT Statements Test Results
Tests
Results
NAT Addition and Removal of NAT Statements
Pass
Overnight Static NAT Using 40 Hosts
This test verified the basic functionality of the NAT feature on a Supervisor 2/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 Procedure
The procedure used to perform the Overnight Static NAT Using 40 Hosts test follows:
Step 1
Begin monitoring the DUT's CPU utilization and memory usage.
Step 2
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 3
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
While traffic is being sent, turn monitoring on the inside interface, then the outside interface, and capture
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 4
After traffic has been sent, verify that no packets were lost and stop SNMP data collection. Display
current status NAT, interfaces, and buffers on the DUT. Verify that the memory and CPU did not suffer
severe or sustained impact during the test.
Note
Even though the script says the packet count portion of the test FAILED, it actually passed. The false
negative was due to user error in entering the wrong number of packets to expect. 805 million is the
actual number of packets sent during this test, and is the number received.
Step 5
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 6
Display the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect all unicast packets to be translated correctly.
•
We expect all multicast packets forwarded correctly.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
197
Miscellaneous Features
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 120 shows the Overnight Static NAT Using 40 Hosts test results.
Table 120
Overnight Static NAT Using 40 Hosts Test Results
Tests
Results
Overnight Static NAT Using 40 Hosts
Pass
Static Inside/Random Outside with 40 Hosts
This test verified the basic functionality of the NAT feature on a Supervisor 2/MSFC 2. The DUT was
configured to translate outside global addresses into outside local addresses and inside global addresses
to inside local addresses. IXIA sent 1 million packets in each direction for each test using overlapping
inside and outside static NAT. IXIA also sent a background multicast stream of 500,000 packets from
the inside interface to the outside interface.
Device under test: SH1-97
Test Procedure
The procedure used to perform the Static Inside/Random Outside with 40 Hosts test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
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.
While traffic is being sent, turn monitoring on the inside interface, then the outside interface, and capture
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 6
After traffic has been sent, verify that no packets were lost and stop SNMP data collection. Display
current status NAT, interfaces, and buffers on the DUT. Verify that the memory and CPU did not suffer
severe or sustained impact during the test.
Step 7
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
198
Miscellaneous Features
Expected Results
•
We expect all unicast packets to be translated correctly.
•
We expect all multicast packets forwarded correctly.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 121 shows the Static Inside/Random Outside with 40 Hosts test results.
Table 121
Static Inside/Random Outside with 40 Hosts Test Results
Tests
Results
Static Inside/Random Outside with 40 Hosts
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), which runs over IP.
The following tests were performed:
•
NTP Basic Functionality—Supervisor 1, page 199
•
NTP Basic Functionality—Supervisor 2, page 200
•
NTP Server Failover—Supervisor 1 and 2, page 201
NTP Basic 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 Procedure
The procedure used to perform the NTP Basic Functionality—Supervisor 1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that one or more servers is configured as the NTP server on the DUT.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
199
Miscellaneous Features
The servers 172.18.177.132 (preferred) and 172.18.177.131 are configured as the NTP server on
SH1-106.
Step 5
Verify that the association between the NTP server and the client is active.
Step 6
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).
Step 7
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the test device to be synchronized to the configured NTP server and the clocks on the
device and server are in synchronization.
Results
Table 122 shows the NTP Basic Functionality—Supervisor 1 test results.
Table 122
NTP Basic Functionality—Supervisor 1 Test Results
Tests
Results
NTP Basic Functionality—Supervisor 1
Pass
NTP Basic 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.
Devices under test: SH1-104
Test Procedure
The procedure used to perform the NTP Basic Functionality—Supervisor 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that one or more servers is configured as the NTP server on the DUT.
Step 5
Verify that the association between the NTP server and the client is active.
Step 6
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).
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
200
Miscellaneous Features
Step 7
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the test device to be synchronized to the configured NTP server and the clocks on the
device and server are in synchronization.
Results
Table 123 shows the NTP Basic Functionality—Supervisor 2 test results.
Table 123
NTP Basic Functionality—Supervisor 2 Test Results
Tests
Results
NTP Basic Functionality—Supervisor 2
Pass
NTP Server Failover—Supervisor 1 and 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 in case the primary server fails.
Devices under test: SH1-106, SH1-104
Test Procedure
The procedure used to perform the NTP Server Failover—Supervisor 1 and 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
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 5
On the server 172.18.177.132, stop the NTP daemon.
Step 6
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 may take a long while, because the timeout interval is very lengthy.)
Note
Synchronization required more than 2 hours to complete on some devices.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
201
Miscellaneous Features
Step 7
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 may take about 15 minutes, because the timeout
interval is very lengthy.)
Step 8
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 9
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the test device to be synchronized to the configured NTP server and the clocks on the
device and server are in synchronization.
Results
Table 124 shows the NTP Server Failover—Supervisor 1 and 2 test results.
Table 124
NTP Server Failover—Supervisor 1 and Supervisor 2 Test Results
Tests
Results
NTP Server Failover—Supervisor 1 and 2
Pass
Syslog
The Syslog protocol provides a transport to allow a machine to send event notification messages across
IP networks to event message collectors, also known as syslog servers.
The following tests were performed:
•
Syslog Basic Functionality—Supervisor 1, page 202
•
Syslog Basic Functionality—Supervisor 2, page 203
Syslog Basic Functionality—Supervisor 1
The System Log (syslog) protocol provides a transport to allow a machine to send event notification
messages across IP networks to event message collectors, which are also known as syslog servers.
This test verified Syslog functionality.
Devices under test: SH1-105
Test Procedure
The procedure used to perform the Syslog Basic Functionality—Supervisor 1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
202
Miscellaneous Features
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that syslog is configured on the DUT and that the designated server is 172.18.177.132.
Step 5
Enable the terminal monitor command on the DUT and enable IP PIM debugging for a few seconds
until a few debug messages are generated.
Step 6
Display output from the syslog server. Compare it to messages received on the DUT.
Step 7
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect each message logged to the vty session to be logged to the syslog server.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 125 shows the Syslog Basic Functionality—Supervisor 1 test results.
Table 125
Syslog Basic Functionality—Supervisor 1 Test Results
Tests
Results
Syslog Basic Functionality—Supervisor 1
Pass
Syslog Basic Functionality—Supervisor 2
The syslog protocol provides a transport to allow a machine to send event notification messages across
IP networks to event message collectors, which are also known as syslog servers.
This test verified Syslog functionality.
Devices under test: SH1-104
Test Procedure
The procedure used to perform the Syslog Basic Functionality—Supervisor 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
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(13)E11
203
Miscellaneous Features
Step 5
Enable the terminal monitor command on SH1-104 and enable IP PIM debugging for a few seconds
until a few debug messages are generated.
Step 6
Display output from the syslog server. Compare it to messages received on SH1-104.
Step 7
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect debug messages logged to the vty session to be logged to the syslog server.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 126 shows the Syslog Basic Functionality—Supervisor 2 test results.
Table 126
Syslog Basic Functionality—Supervisor 2 Test Results
Tests
Results
Syslog Basic 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. The Transmission
Control Protocol/Internet Protocol (TCP/IP) supports the following types of broadcast packets:
•
All ones—The broadcast address is set to all ones (255.255.255.255), all hosts on the network
receive the broadcast.
•
Subnet—The broadcast address is set 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.
•
Network—The broadcast address is set 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 127.1.255.255, all hosts on network number 127.1 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, and 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 205
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
204
Miscellaneous Features
UDP Broadcast Flooding
There are several facets to this test. An IXIA broadcast stream was used for each aspect of the procedure.
First, the broadcast stream was sent into the network at a single device. It was verified that this device
forwards the broadcast out all physical interfaces. Next the device is configured to use an IP helper
address. To 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 were configured have been done so with UDP port 53 (DNS). The next part of the
procedure tests the functionality of the no ip forward-protocol command, that was supposed to halt the
forwarding of any broadcasts using the protocol specified (in this case DNS).
Device under test: SH1-101
Test Procedure
The procedure used to perform the UDP Broadcast Flooding test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the ip helper-address and the no ip forward-protocol commands are not yet configured on
the device.
Step 5
Begin the broadcast IXIA stream on Ix-16/8 (SH1-101 Fa9/6). The stream should have a length of
74 bytes and be sent at 5,000 pps. The broadcast stream has a DMAC of FFFF.FFFF.FFFF and a 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 6
Configure an IP helper-address of 172.31.1.25 on the VLAN 40 interface of SH1-101. This IP address
belongs to the remote side of portchannel 14, connecting to SH1-99.
Step 7
Verify that the traffic coming in is now being sent out Po14, as unicast traffic.
Step 8
Configure the no ip forward-protocol udp domain command globally on SH1-101. This will cause the
router to stop forwarding any UDP traffic with an Layer 4 port of 53 (DNS). Verify that traffic stops
being sent out Po14.
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
Remove the IP helper address configuration from SH1-101
Step 11
Stop the IXIA traffic for about 2 minutes. Reconfigure the IXIA stream to send at 2500 pps, instead of
the previous at 5000 pps.
Step 12
Send traffic for about 2 minutes to get a measure of what halving the traffic rate does for helping CPU
utilization.
Step 13
Stop the IXIA traffic for about 2 minutes. Reconfigure the IXIA stream to send at 5000 pps, but with a
packet size of 500 Bytes (was 74 Bytes previously).
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
205
Miscellaneous Features
Step 14
Send traffic for about 2 minutes to get a measure of what increasing the packet size does for the CPU
utilization.
Step 15
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 16
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect SH1-101 to forward all broadcast packets on the same VLAN (40) on which they come in.
•
We expect packets to be forwarded to the IP helper address as unicast packets when configured to
do so.
•
We expect packets to not be forwarded when the DNS protocol is blocked, and should resume when
the filter is lifted.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 127 shows the UDP Broadcast Flooding test results.
Table 127
UDP Broadcast Flooding Test Results
Tests
Results
UDP Broadcast Flooding
Pass
System Upgrade
This test verified that the Cisco IOS upgrade process works correctly.
The following tests were performed:
•
System Upgrade—12.1(8b)E15 to 12.1(13)E11—Supervisor 11, page 206
•
System Upgrade—12.1(8b)E15 to 12.1(13)E11—Supervisor 12, page 207
•
System Upgrade—12.1(8b)E15 to 12.1(13)E11—Supervisor 22, page 208
•
System Upgrade—12.1(13)E6 to 12.1(13)E11—Supervisor 11, page 209
•
System Upgrade—12.1(13)E6 to 12.1(13)E11—Supervisor 22, page 210
•
System Upgrade—12.1(13)E6 to 12.1(13)E11—Supervisor 22, page 211
System Upgrade—12.1(8b)E15 to 12.1(13)E11—Supervisor 11
This test measured the basic ability of the code to boot correctly. The boot process was followed from
the console and screened for any errors.
This test verified that the Cisco IOS upgrade process worked correctly.
Device under test: SH1-106
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
206
Miscellaneous Features
Test Procedure
The procedure used to perform the System Upgrade—12.1(8b)E15 to 12.1(13)E11—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 Cisco Native IOS image, Release 12.1(8b)E15.
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.
Note
Step 7
With the upgrade from Release 12.1(8b)E to 12.1(13)E, both supervisors need to be upgraded at the
same time. The reason is that 12.1(13)E supports the RPR+ redundancy feature, and 12.1(8b)E
supports only EHSA mode redundancy. The two are not compatible and the bootup of whichever
supervisor is upgrading to 12.1(13)E will suspend for that reason.
Verify that both supervisors come online successfully and that the new image is running.
Expected Results
•
We expect the upgrade process from Release 12.1(8b)E15 to 12.1(13)E11 to proceed without error.
Results
Table 128 shows the System Upgrade—12.1(8b)E15 to 12.1(13)E11—Supervisor 11 test results.
Table 128
System Upgrade—12.1(8b)E15 to 12.1(13)E11—Supervisor 11 Test Results
Tests
Results
System Upgrade—12.1(8b)E15 to 12.1(13)E11—Supervisor 11 Pass with exception CSCdv26643
System Upgrade—12.1(8b)E15 to 12.1(13)E11—Supervisor 12
This test measured the basic ability of the code to boot correctly. The boot process was followed from
the console and screened for any errors.
This test verified that the Cisco IOS upgrade process worked correctly.
Device under test: SH1-107
Test Procedure
The procedure used to perform the System Upgrade—12.1(8b)E15 to 12.1(13)E11—Supervisor 12 test
follows:
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
207
Miscellaneous Features
Step 1
Record the start time of this test.
Step 2
On Sup 12, verify that SH1-107 is running the old Cisco Native IOS image, Release 12.1(8b)E15.
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.
Note
Step 7
With the upgrade from Release 12.1(8b)E to 12.1(13)E, both supervisors need to be upgraded at the
same time. The reason is that 12.1(13)E supports the RPR+ redundancy feature, and 12.1(8b)E
supports only EHSA mode redundancy. The two are not compatible and the bootup of whichever
supervisor is upgrading to 12.1(13)E will suspend for that reason.
Verify that both supervisors come online successfully and that the new image is running.
Expected Results
•
We expect the upgrade process from Release 12.1(8b)E15 to 12.1(13)E11 to proceed without error.
Results
Table 129 shows the System Upgrade—12.1(8b)E15 to 12.1(13)E11—Supervisor 12 test results.
Table 129
System Upgrade—12.1(8b)E15 to 12.1(13)E11—Supervisor 12 Test Results
Tests
Results
System Upgrade—12.1(8b)E15 to 12.1(13)E11—Supervisor 12 Pass with exception CSCdv26643
System Upgrade—12.1(8b)E15 to 12.1(13)E11—Supervisor 22
This test measured the basic ability of the code to boot correctly. The boot process was followed from
the console and screened for any errors.
This test verified that the Cisco IOS upgrade process worked correctly.
Device under test: SH1-109
Test Procedure
The procedure used to perform the System Upgrade—12.1(8b)E15 to 12.1(13)E11—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 Cisco Native IOS image, Release 12.1(8b)E15.
Step 3
Verify that the Sup22 image under test is on the proper file devices.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
208
Miscellaneous Features
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.
Note
Step 7
With the upgrade from Release 12.1(8b)E to 12.1(13)E, both supervisors need to be upgraded at the
same time. The reason is that 12.1(13)E supports the RPR+ redundancy feature, and 12.1(8b)E
supports only EHSA mode redundancy. The two are not compatible and the bootup of whichever
supervisor is upgrading to 12.1(13)E will suspend for that reason.
Verify that both supervisors come online successfully and that the new image is running.
Expected Results
•
We expect the upgrade process from Release 12.1(8b)E15 to 12.1(13)E11 to proceed without error.
Results
Table 130 shows the System Upgrade—12.1(8b)E15 to 12.1(13)E11—Supervisor 22 test results.
Table 130
System Upgrade—12.1(8b)E15 to 12.1(13)E11—Supervisor 22 Test Results
Tests
Results
System Upgrade—12.1(8b)E15 to 12.1(13)E11—Supervisor 22 Pass with exception CSCdv26643
System Upgrade—12.1(13)E6 to 12.1(13)E11—Supervisor 11
This test measured the basic ability of the code to boot correctly. The boot process was followed from
the console and screened for any errors.
This test verified that the Cisco IOS upgrade process worked correctly.
Device under test: SH1-106
Test Procedure
The procedure used to perform the System Upgrade—12.1(13)E6 to 12.1(13)E11—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 Cisco Native IOS image, Release 12.1(13)E6.
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.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
209
Miscellaneous Features
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
•
We expect the upgrade process from Release 12.1(13)E6 to 12.1(13)E11 to proceed without error.
Results
Table 131 shows the System Upgrade—12.1(13)E6 to 12.1(13)E11—Supervisor 11 test results.
Table 131
System Upgrade—12.1(13)E6 to 12.1(13)E11—Supervisor 11 Test Results
Tests
Results
System Upgrade—12.1(13)E6 to 12.1(13)E11—Supervisor 11
Pass
System Upgrade—12.1(13)E6 to 12.1(13)E11—Supervisor 22
This test measured the basic ability of the code to boot correctly. The boot process was followed from
the console and screened for any errors.
This test verified that the Cisco IOS upgrade process worked correctly.
Device under test: SH1-108
Test Procedure
The procedure used to perform the System Upgrade—12.1(13)E6 to 12.1(13)E11—Supervisor 22 test
follows:
Step 1
Record the start time of this test.
Step 2
On Sup 12, verify that SH1-107 is running the old Cisco Native IOS image, Release 12.1(13)E6.
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
•
We expect the upgrade process from Release 12.1(13)E6 to 12.1(13)E11 to proceed without error.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
210
Miscellaneous Features
Results
Table 132 shows the System Upgrade—12.1(13)E6 to 12.1(13)E11—Supervisor 22 test results.
Table 132
System Upgrade—12.1(13)E6 to 12.1(13)E11—Supervisor 22 Test Results
Tests
Results
System Upgrade—12.1(13)E6 to 12.1(13)E11—Supervisor 22
Pass
System Upgrade—12.1(13)E6 to 12.1(13)E11—Supervisor 22
This test measured the basic ability of the code to boot correctly. The boot process was followed from
the console and screened for any errors.
This test verified that the Cisco IOS upgrade process worked correctly.
Device under test: SH1-110
Test Procedure
The procedure used to perform the System Upgrade—12.1(13)E6 to 12.1(13)E11—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 Cisco Native IOS image, Release 12.1(13)E6.
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
•
We expect the upgrade process from Release 12.1(13)E6 to 12.1(13)E9 to proceed without error.
Results
Table 133 shows the System Upgrade—12.1(13)E6 to 12.1(13)E11—Supervisor 22 test results.
Table 133
System Upgrade—12.1(13)E6 to 12.1(13)E9—Supervisor 22 Test Results
Tests
Results
System Upgrade—12.1(13)E6 to 12.1(13)E11—Supervisor 22
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
211
Miscellaneous Features
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 and TACACS+, and the use of
locally stored usernames and passwords.
The following test was performed:
•
SSH Server Vulnerability, page 212
SSH Server Vulnerability
This test verified that the SSH server built into Cisco IOS crypto images was not susceptible to SSH
Malformed Packet Vulnerabilities as described at
http://www.cisco.com/warp/public/707/ssh-packet-suite-vuln.shtml.
The test PDUs sent to the device were downloaded from:
http://www.rapid7.com/Product-Download.html.
Test Procedure
The procedure used to perform the SSH Server Vulnerability test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the Cisco IOS version under test. Verify the uptime and that the box
has not reloaded unnecessarily. Verify that no process is spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify SH1-101 is configured with a host name, domain name, and TACACS authentication on vty lines.
Step 5
Verify 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.
Step 6
Send malformed SSH packets at SH1-101 while monitoring the device. Ensure that the device does not
hang, crash, or reload.
Step 7
Remove the configuration added in this test case.
The configuration was left on SH1-98 for this iteration of testing.
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
212
Miscellaneous Features
Note
Step 8
Zeroizing the RSA key is the only way to shut off the SSH server process. However, removing SSH
from the transport input statement is enough to disallow incoming SSH connections. If the key is
zeroized, the next time the test case is performed, prior to Step 4, the tester will need to remove the
old key stored in ~/.ssh/known_hosts before SSH will allow the connection to be made.
Display the log for error messages.
Display the log buffer to verify that there are no erroneous log messages.
Step 9
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that SSH vulnerability testing does not cause the router to reload, hang, or crash.
Results
Table 134 shows the SSH Server Vulnerability test results.
Table 134
SSH Server Vulnerability Test Results
Tests
Results
SSH Server Vulnerability
Pass
Cisco Safe Harbor Testing for Financial Enterprise Customers, Release 12.1(13)E11
213
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(13)E11
214