Download http://www.cisco.com/systemtest/ge_1/ge2.pdf

Global Enterprise System Test for Cisco IOS
Release 12.1(12c)E1, Release 12.2(12), CatOS
6.3(6), and CatOS 7.2(1)
Version History
Version Number
Date
Notes
1
October 31, 2002
This document was created. The term “Safe Harbor” was
changed to “Profile Release.”
2
January 10, 2003
Additional technical edits incorporated.
Executive Summary
The nEverest program focuses on satisfying customer requirements in key vertical markets. The program
links and expands several existing Cisco quality programs that were designed to address customer
quality issues. It also coordinates system-level and reliability testing of Cisco IOS releases that are
targeted for specific vertical markets. The nEverest program also ensures that Cisco takes a “holistic”
approach to the general improvement of Cisco IOS software. Global Enterprise System Test is one of the
preliminary projects that contributed significant system and reliability testing for subsequent nEverest
projects.
This document describes the testing environment, a description of the features tested, and a summary of
the test results. This document specifies what was included in the end-to-end system test effort for basic
IP and quality of service (QoS) testing. The execution of this test plan verified the functionality,
scalability, and performance requirements in a global enterprise topology environment.
During the testing, the network is placed under loads that are consistent with those in a global enterprise
network. A standard suite of traffic testing tools (for example, Chariot) is used during the network
testing. This network testing includes a combination of automated and manual tests. For a summary of
the test results, see the “Test Suite 1: San Jose Campus with Data Center” section.
This document contains the following sections:
•
About Global Enterprise System Test, page 2
•
Test Results Summary, page 16
•
Test Suite Overview, page 21
•
Test Suite 1: San Jose Campus with Data Center, page 22
•
Test Suite 2: Washington, D.C. Campus with Data Center, page 46
•
Test Suite 3: Denver Campus, page 65
Corporate Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Copyright © 2002. Cisco Systems, Inc. All rights reserved.
Test Suite 1: San Jose Campus with Data Center
•
Test Suite 4: Boston Campus, page 88
•
Test Suite 5: Dallas Campus, page 108
•
Test Suite 6: Remote Campuses, page 136
About Global Enterprise System Test
The goal of the Global Enterprise System Test project was to provide improved network stability,
reliability, and performance with respect to Cisco IOS software. This project involved testing the feature
sets and protocols in several Cisco IOS Release images on certain platforms to provide high-quality code
for global enterprises.
This combination of features, hardware, and images was tested in a laboratory environment that
simulated the global enterprise business network environment. For information on the tested hardware
and the network setup of the test environment, see the “Global Enterprise Topology”section.
Global Enterprise Topology
The global enterprise topology consisted of five multilayer-design campuses — two large campuses with
data centers, and three regional campuses — and nine remote sites, listed below.
•
San Jose campus with data center
•
Washington, D.C. campus with data center
•
Denver campus
•
Boston campus
•
Dallas campus
•
Remote campuses
– Los Angeles
– Phoenix
– Colorado Springs
– Santa Fe
– New Orleans
– Houston
– Pittsburgh
– Miami
– New York
Figure 1 shows the topology for the global enterprise network at a high level. Each campus is represented
in the topology.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
2
Test Suite Overview
Figure 1 includes the name of the router for a given campus (for example, router egsj-7609-w2 is a router
in the San Jose campus with data center), along with the IP address for each router.
Figure 1
Enterprise Global Topology at a High Level
T1 (PTP)
ATM/FR (nx64k)
E1 (PTP)
ATM E1
T3 (PTP)
ATM T3
San Jose - HQ
Data Center
ISP3
7206
Boston
7206 FE
7609
7500
7500
7206
POS OC3
7609
Washington, D.C.
Data Center
GE
GE
7609
7609
7507
7206
ATM
Provider
ATM OC3
7500
HSSI (P2P)
Multichannel
E3
FE
.
7206
7206
Denver
7507
7206
FE
ATM E3
7206
7206
Dall as
7206
FE
7507
82513
ISP1
7500
ATM
OC3
ATM/FR
ATM T3 (P2P)
3640
Los Angeles
7204
2651
Phoenix Colorado Springs
2651
Sante Fe
…
2651
New Orleans
3660
Houston
3640
Pittsburgh
7206 3640
Miami
3620
New York
ATM-to-ATM links and leased lines (with back-to-back wide-area networks (WANs) are used in the
topology. Multiple types of high-speed WAN links are used to establish the connections to all campuses,
including OC3 POS line card interface links, OC3 ATM line card interface links, T1 links, and
High-Speed Serial Interface (HSSI) links.
The remote sites are connected to the campuses using ATM-to-Frame Relay (FR) and leased-line
connections with various fractional T1/E1 and T1/T3 link speeds, respectively.
In addition, there are connections between selected campuses and the Internet service provider (ISP)
through the use of T1/T3 leased lines. The platforms tested include the Cisco 7600 router, the Cisco 7500
router, the Cisco 7200 VXR router, the Cisco 3600 router, the Cisco 2600 router, the Catalyst 6500
switch, the Catalyst 5500 switch, the Catalyst 4000 switch, the Catalyst 3550 switch, and the Catalyst
2950 switch.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
3
Test Suite 1: San Jose Campus with Data Center
The topology for each campus within the larger global enterprise topology is detailed in a separate
chapter of this document. Table 1 lists the name of the chapter you can turn to for more information
about the topology for a specific campus.
Table 1
Where to Find the Topology Information for Each Campus
Campus
Chapter
San Jose campus with data center
Test Suite 1: San Jose Campus with Data
Center, page 22
Washington, D.C. campus with data center
Test Suite 2: Washington, D.C. Campus with
Data Center, page 46
Denver campus
Test Suite 3: Denver Campus, page 65
Boston campus
Test Suite 4: Boston Campus, page 88
Dallas campus
Test Suite 5: Dallas Campus, page 108
Remote campuses
Test Suite 6: Remote Campuses, page 136
The Testing Approach
This test plan focused primarily on the following areas:
•
Basic IP testing
•
System testing (specifically, quality of service)
•
Reliability testing
•
Scalability testing
Basic IP Test Description
For the basic IP testing, Enhanced Interior Gateway Routing Protocol (EIGRP) and Border Gateway
Protocol (BGP) were included in the test plan. In the basic IP testing category, the network connectivity
tests and traffic routing convergence tests were performed and the associated network parameters were
captured.
Basic IP testing covered the deployment and verification of a number of layer 2 features and layer 3
routing protocols, as described below.
Layer 2 Features
Layer 2 features included the following:
•
VLAN Trunking Protocol (VTP)
•
Spanning-Tree Protocol (STP)
•
VLAN
•
VLAN trunking
•
Hot Standby Router Protocol (HSRP)
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
4
Test Suite Overview
•
SNMP and the following related features enabled to support network management tools:
– Network Time Protocol (NTP)
– Hypertext Transfer Protocol (HTTP)
– Terminal Access Controller Access Control System (TACACS+)
Layer 3 Routing Protocols
Layer 3 routing protocols included the following:
•
EIGRP
•
BGP
Figure 2 shows the topology used for including EIGRP and BGP in the basic IP test plan.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
5
Test Suite 1: San Jose Campus with Data Center
Figure 2
EIGRP and BGP Topology
EGBP logical connection
ATM physical conection
Physical leased-line connection
Physical GE/FE connection
Boston
EBGP
ISP 3
AS 3
egbos-7200-w1
egwas-6506-c1
egsj-6509-c3
egwas-6506-c2
egwas7600-w2
egsj-6509-c4
egsj-7200-w
egwas-7500-w
ATM
EBGP
ISP 1
AS 1
T3
-A
TM
Washington, D.C.
OC3-ATM
EIGRP AS 1
for the whole Encore
Enterprise Global Topology
San Jose
Denver
Dallas
BGP AS 64500
for the whole Encore
Enterprise Global Topology
egden-6509-c1
egdal-6506-c1
egden-6509-c2
ATM/FR
egdal-6506-c2
egdal-7200-w
egden-7200-w
V
V
V
V
V
V
V
V
Los
Angeles
Phoenix
Colorado
Springs
Santa Fe
New
Orleans
Houston
Pittsburgh
New York
V
Miami
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
6
V
82512
egden-7500-w
Test Suite Overview
Figure 3 shows the topology for the route convergence test for the entire global enterprise network.
Figure 3
Route Convergence Topology for the Entire Global Enterprise Network
egbos-6506-a1
source poi nt 1
4/ 48
Si
T1 (PTP)
ATM/FR (nx64k)
E1 (PTP)
ATM E1
T3 (PTP)
ATM T3
Bos
POS OC3
San Jose - HQ
Data Center
GE
GE
Washington, D.C.
Data Center
egsj-6509-c3
f4 /1
3/19
destination
point
eg-7513- lne
ATM
OC3
ATM OC3
ATM
Provider
HSSI (P2P)
E3
(P2P)
3/2
source poi nt 2
3/8
egden-6506-a1
FE
egdal-72 06-w2
egdal-7206-w1
Dallas
egdal-7206-w3
egdal-7507-w4
ATM E3
Denver
FE
3/48
ATM/FR
FE
ATM T3 (P2P)
New
Orleans
…
Los
Angeles
Phoenix
Colorado
Springs
Houston
Santa Fe
f0/17
egneo-2950-a
Pittsburgh
New York
Miami
f3 /33
source point 4
source poi nt 3
egmia-6506-a1
82515
3/6
eg-5005-lne
3/4
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
7
Test Suite 1: San Jose Campus with Data Center
Figure 4 shows the route convergence topology along with information about the simulated routes
generated for testing.
Figure 4
Route Convergence Topology and Simulated Routes used in Testing
ATM physical conection
Physical leased-line connection
Physical GE/FE connection
L : simulate large campus;
generate 60 summary routes
B : simulate campus building;
generate 100 routes
egbos-7200-w1
Boston
M : simulate medium campus; R : simulate remote site;
generate 20 summary routes generate 1 route in the case
of EIGRP; generate 4 routes
S : simulate small campus;
generate 10 summary routes in the case of OSPF
egbos-7206-w3
40 x R
egsj-6509-c3
egwas-7609-w1 egwas-6506-c1
egsj-7609-w2
3xL 8xM 9xS
3xB
5xB
egsj-7609-w1
egwas-7609-w2
egsj-6509-c4
egwas-6506-c2
egsj-7200-w3
ATM
80 x R
egwas-7500-w3
40 x R
San Jose
Denver
82514
T3
-A
TM
Washington, D.C.
OC3-ATM
Dallas
egden-6509-c1
egdal-6506-c1
egdal-7206-w2
egden-6509-c2
1xB
2xB
ATM/FR
40 x R
80 x R
egden-7500-w4
egdal-7206-w1
egdal-6506-c2
40 x R
egdal-7200-w3
egdal-7500-w4
egden-7200-w3
80 x R
V
V
V
V
V
V
V
V
Los
Angeles
Phoenix
Colorado
Springs
Santa Fe
New
Orleans
Houston
Pittsburgh
New York
V
V
Miami
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
8
Test Suite Overview
Figure 5 shows the routing convergence path topology for the San Jose campus.
Figure 5
Routing Convergence Topology for the San Jose Campus
egsj-6506-sd1
egsj-5505-sa1
egsj-5505-sa2
pos s ible bac k up pat h
pr im ar y pat h
egsj-6506-sd2
egsj-6506-sa3
egs j- 6509- c 1
egsj-6509-c2
egs j- 6509- c 3
egsj-6509-c4
egsj-6506-b2d2
eg s j- 6506- b1d1
egsj-6506-b1d2
82509
egsj-6506-b2d1
eg sj-4 006- b1a1
egs j- 6 5 0 6 - b 1 a 3
egs j- 5505- b1a2
egsj-4003-b2a1
egsj-6506-b2a2
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
9
Test Suite 1: San Jose Campus with Data Center
Figure 6 shows the topology for a routing convergence path between the San Jose campus and the Denver
campus.
Figure 6
Routing Convergence Path Between the San Jose Campus and the Denver Campus
EGSJ7600-W2
OC-3
EGWAS7600-W1
EGSJ-7600-W1
EGWAS7600-W2
ATM
Washington, D.C.
T3-ATM
OC3-ATM
San Jose
HSSI
= possible backup path
= primary path
EGDEN-7206-W2
Denver
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
10
82146
EGDEN-7206-W1
Test Suite Overview
Figure 7 shows the topology for a routing convergence path between the San Jose campus and the Denver
campus, and between the Washington, D.C. campus and the Dallas campus.
Figure 7
Traffic Routing Convergence Topology Between the San Jose and Denver Campuses and
Between the Washington, D.C. and Dallas Campuses
= possible backup path
= primary path
EGSJ7600-W2
OC-3
EGWAS7600-W1
EGSJ7600-W1
EGWAS7600-W2
T3-ATM
Washington, D.C.
OC3-ATM
OC3-ATM
T3
-AT
TM
M
San Jose
ATM
E3
HSSI
Dallas
- E3
ATM
Denver
EGDEN-7206-W2
EGDAL7206-W2
EGDEN-7206-W1
EGDEN-7206-W3
768K
T1
EGPHX-7206-VW
Phoenix
ATM
E1
EGWAS7600-W1
EGDAL7507-W4
82510
ATM/FR
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
11
Test Suite 1: San Jose Campus with Data Center
Figure 8 shows the topology for a routing convergence path between the New York campus and the
Santa Fe campus.
Figure 8
Traffic Routing Convergence Topology Between the New York and Santa Fe Campuses
Boston
= possible backup path
= primary path
EGBOS-7206-W1
EGBOS-7206-W2
EGBOS-7206-W3
Washington, D.C.
T3
T3
OC-3
EGWAS7600-W1
EGSJ7600-W2
EGWAS7600-W2
EGWAS7505-W3
EGSJ7600-W1
T3
-AT
TM
M
T3-ATM
ATM
OC3-ATM
OC3-ATM
San Jose
768K
-E3
ATM
T1
EGNY-3620-VW
Dallas
EGDAL7206-W3
ATM E1
EGDAL7206-W2
New York
EGSAF-2651-VW
ATM/FR
128K
128K
M
AT
Sante Fe
82511
E1
EGDAL7206-W1
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
12
Test Suite Overview
System Test Description
System testing focused primarily on testing quality of service (QoS). The purpose of QoS system testing
was to implement and verify the QoS deployment scenarios for global enterprise customers who want to
protect their critical application data, including real-time Voice over IP (VoIP) on WAN links.
For QoS testing, the QoS policies were defined and applied to the various types of (WAN) connections
and link speeds, as described in the “Global Enterprise Topology” section. The real-time traffic and
applications with voice and data were simulated.
Figure 9 shows the topology used for simulating voice traffic. The numbers and arrows in parentheses
indicate the number of voice calls sent and the direction of the voice calls.
Figure 9
Voice Traffic Topology
Boston
2651
13
V
Users on
the phone
(1
25
3640
Users on
the phone
Gatekeeper
1)
(
)
2
)
(5
San Jose - HQ
Data Center
(1
)
2
Washington, D.C.
Data Center
3660
3640
(7 )
( 6)
13
Users on
the phone
9
( 3)
(3 )
( 1
)
(1 )
( 3)
(3 )
6
2
Users on
the phone
3640
2
2
)
( 1
)
8)
(1
(
1)
( 5
)
V
(
2
)
2651
(1
)
2651
3640
3640
7200
V
V
V
V
V
V
V
Los
Angeles
Phoenix
Colorado
Springs
Santa Fe
New
Orleans
Houston
Pittsburgh
3640
V
3620
V
New York
Miami
82516
2651
(5
(1
)
(7
7200
)
( 4
(1
)
1)
( 1)
( 1)
10
(
2
2
)
V
(1 )
25
(1 )
3640
20
Users on
the phone
6
Dallas
( 1)
Denver
15
V
25
V
2
3640
( 1)
QoS Features Tested
The QoS features listed below were included in the system test:
•
Classification and marking, including the following:
– Access lists
– Network-Based Application Recognition (NBAR)
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
13
Test Suite 1: San Jose Campus with Data Center
– Distributed NBAR (dNBAR)
– Differentiated services code point (DSCP)
•
Congestion avoidance, including the following:
– Weighted Random Early Detection (WRED)
– Distributed WRED (dWRED)
•
Congestion management, including the following:
– Low latency queueing (LLQ)
– Distributed LLQ (dLLQ)
– Class-based weighted fair queueing (CBWFQ
– Distributed CBWFQ (dCBWFQ)
•
Traffic conditioning, including the following:
– Frame Relay traffic shaping (FRTS)
– Generic Traffic Shaping (GTS)
– Distributed traffic shaping (dTS)
– ATM shaping
•
Link efficiency mechanisms, including the following:
– Compressed Real-Time Protocol (cRTP)
– Distributed CRTP (dCRTP)
– Multilink PPP (MLP) Interleaving
These features are configured for use with the following QoS functionality, described below:
Modular QoS CLI (MQC)
The MQC is the Cisco IOS framework for implementing QoS features. The MQC is a command-line
interface (CLI) structure that allows you to create traffic policies and attach these policies to interfaces.
In the MQC, the class-map command is used to define a traffic class (which is then associated with a
traffic policy). The purpose of a traffic class is to classify traffic.
The Modular QoS CLI structure consists of the following three processes:
•
Defining a traffic class with the class-map command.
•
Creating a traffic policy by associating the traffic class with one or more QoS features (using the
policy-map command).
•
Attaching the traffic policy to the interface with the service-policy command.
Classification and Marking
Classification and marking are two separate actions that are always done together. This test plan used
access lists, class maps, and NBAR to classify data streams, including voice traffic. Packets were marked
using policy-map commands, and the DSCP. Packet classification and marking was used on the inbound
interfaces (the LAN-side Ethernet ports) of the WAN edge routers for all campuses except the San Jose
campus with data center and the Denver campus. The San Jose campus with data center and the Denver
campus used classification and marking on the inbound interfaces of the distribution layer switches.
These two campuses used NBAR (on the WAN edge) to classify and mark packets, and NBAR (on the
voice routers) to classify and mark voice packets.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
14
Test Suite Overview
Congestion Avoidance
Weighted Random Early Detection (WRED) is the congestion avoidance mechanism used in the test
plan. WRED provides buffer management and was applied using the random-detect dscp-based
command on the outbound WAN interfaces of the T3/E3, HSSI, and OC-3 links.
Congestion Management
Congestion management is achieved by setting up queues of differing priorities. In the testing, the LLQ
priority and bandwidth commands were used to establish a set of queues to service all traffic. These
commands were added to the policy map applied to the outbound (WAN-side) interfaces.
Traffic Conditioning
The policing and shaping features make up traffic conditioning. In the test plan, GTS, dTS, and ATM
shaping (using the vbr-nrt command) were used for conditioning traffic. In addition, Frame Relay
Traffic Shaping (FRTS) was used on the WAN or edge outbound interfaces to account for the disparity
between the link and the permanent virtual circuit (PVC) clock rates in the ATM/Frame Relay and ATM
clouds.
Signaling
Signaling features such as Resource Reservation Protocol (RSVP) were not included in the QoS features
tested. Voice signaling was categorized into the “Interactive” application class.
Link Efficiency Mechanisms
Large packets can create an unacceptable delay on lower-speed WAN links for small voice packets
waiting behind them. To resolve this potential problem, link fragmentation and interleaving (LFI) or
Multilink Point-to-Point Protocol (MLPPP) were enabled on the WAN or edge outbound interfaces.
Since the bandwidth on these low-speed WAN connections is very valuable, the increased workload of
compressing the headers of the voice packets is justified. We also enabled cRTP on the outbound
interfaces for header compression.
Reliability Test Description
For reliability testing, network management tools were used to monitor the network performance (that
is, the CPU and memory usage) and to capture test results.
The software tested included the latest Cisco IOS 12.2 M, 12.1E releases, and the Catalyst OS releases.
The reliability test was performed for a period of 150 hours with a traffic load of 100% on the WAN
links. To complete the test successfully, there must be no severity 1 or 2 defects found during this time.
All error logs were monitored and the routers were periodically checked for memory leaks and high CPU
utilization.
Scalability Test Description
This test measured the scalability and the performance of the Cisco 7500 series and Cisco 7200 VXR
routers. The test was performed on an ATM-T3 link between the Dallas campus and the Miami remote
site. One hundred to four hundred PVCs were configured with link speeds varying from 64k to 768k.
Only head-end testing was done because the scale was simulated. 100% traffic load was generated on
the WAN link and the PVCs were brought up 100 at the time. CPU utilization, memory, input errors, and
output errors on the interface level were monitored and captured.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
15
Test Suite 1: San Jose Campus with Data Center
At the end of a successful system test, output from the following show commands was captured on all
WAN routers and relevant distribution layer switches:
•
show class-map command
•
show policy-map command
•
show access-lists command
•
show ip protocol command
•
show running-config command
Test Results Summary
Table 2 summarizes the results of all the testing that was completed as part of the Global Enterprise
System Test initiative. Table 2 includes the following information: the name of the test suite, the test
category, the test results, the DDTS number (if applicable) and comments.
Table 2
Test Results Summary
Test Suite
Test Category
Results
DDTS/Comments
Test Suite 1: San
Jose Campus with
Data Center,
page 22
Basic IP Test with
EIGRP
Passed
CSCdv00656, CSCdx38946, CSCdx38960
System Test with
EIGRP
Passed
—
Reliability Test with
EIGRP
Passed
Experienced a failure on the supervisor module and line card.
However, this failure did not interrupt the testing process or
affect the testing results.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
16
Test Suite Overview
Table 2
Test Results Summary (continued)
Test Suite
Test Category
Results
DDTS/Comments
Test Suite 2:
Washington, D.C.
Campus with Data
Center, page 46
Basic IP Test with
EIGRP
Passed with
exceptions
CSCdx43517
•
A traceback on the gigabit ethernet IP card occurred.
CSCdx43683
•
The message “c6k_pwr_get_fru_present(): can't find
fru_info for fru type 6, #24” was observed on the console
of the Cisco 7609 router.
CSCdx45114
•
The message “%POLARIS-SP-4-ERR_INTRPT:
Interrupt NT_PERR_INT occurring in Polaris Layer”
appeared on the console of the Catalyst 6500 router.
Unable to reproduce.
CSCdx48311
•
When traffic was running at 90% of the rate of the link,
and first-in first-out (FIFO) queueing was configured,
TCP traffic was dropped. This was observed with bursty
TCP traffic only.
At speeds less than 90% of the rate of the link, or if
weighted fair queueing was configured, TCP traffic was
not dropped.
CSCdy04736
•
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
17
Test Suite 1: San Jose Campus with Data Center
Table 2
Test Results Summary (continued)
Test Suite
Test Category
Results
DDTS/Comments
Test Suite 2:
Washington, D.C.
Campus with Data
Center, page 46
System Test with
EIGRP
Passed with
exceptions
Selected QoS features were implemented as outlined below.
This implementation varied from what was originally called
for in the strategy for implementing QoS.
•
Classification and marking
The strategy for implementing QoS originally called for
packet classification and marking to be implemented as
close to the ingress of the network as possible.
Since some access switches (for instance, the
Catalyst 5000 and the Catalyst 4000) are unable to
perform this task, classification and marking was
implemented at the distribution layer where Catalyst 6500
switches with Multilayer Switch Feature (MFSC2) cards
and Policy Feature (PFC2) cards could be used.
However, further testing revealed that even these layer
3-capable switches did not support the MQC command
set. The police command could be used to mark packets
but not in a hierarchical fashion. Therefore, classification
and marking was implemented at the WAN edge.
Also, the strategy for implementing QoS called for packet
classification and marking to always take place on the
inbound interfaces of all routers and switches, except for
voice routers. Testing revealed that only the Cisco 7600
routers support the MQC command set on the FlexWAN
module. Therefore, classification and marking was
implemented on the outbound interfaces on the Cisco
7600 routers.
•
MLP Interleaving and cRTP
The strategy for implementing QoS called for using ATMto-Frame Relay links to connect the Denver and Dallas
campuses to-and-from the remote sites.
Many of these links originated from a Cisco 7500 series
platform in the Denver and Dallas campuses. Testing
revealed that MultiLink PPP (MLP) Fragmentation and
cRTP has not been implemented in the Cisco Express
Forwarding (CEF) switching path in mainline code.
Since only CEF-switching is supported on the Cisco 7500
series platform, fragmentation and compression cannot be
engaged on these links. Currently, CEF virtual-template
MLP Interleaving and cRTP are only supported on the T
train.
Reliability Test with
EIGRP
Test Suite 3: Denver Basic IP Test with
Campus, page 65
EIGRP
Passed
—
Passed
—
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
18
Test Suite Overview
Table 2
Test Suite
Test Results Summary (continued)
Test Category
Results
DDTS/Comments
System Test with
EIGRP
Passed
—
Reliability Test with
EIGRP
Passed with
exceptions
•
Reduced QoS on voice traffic during periods of network
congestion.
Voice traffic between the Dallas and Santa Fe campuses,
and between the Denver and New Orleans campuses
suffered a QoS reduction. This reduced QoS occurred in
the regional-to-remote site direction, when the links were
congested with data traffic going in the same direction.
This reduction in QoS appeared as a 15-20% path
confirmation degradation to the RTP streams in the
Dallas-to-Santa Fe direction. Little or no QoS reduction
was observed in the RTP streams of the same calls in the
other RTP direction. Work is progressing to further
characterize this issue.
•
Router rebooted at 145th hour of 150-hour test
This occurred during the troubleshooting work done to
resolve the QoS reduction noted above. This router
rebooting is an exception. The link for this router had run
successfully for the 150-hour test period in two previous
test cycles. Therefore, there is no reason to believe that it
would have encountered any problems during the
remaining 5 hours.
CSCdy69833
•
When testing and tuning the ATM interface for QoS
functionality to support voice, the tx-ring was set to 3 (the
minimum) on interface ATM5/0 (egden-7206-w3).
This caused the virtual-access interfaces (on top of the
ATM interface) to hang and no longer transmit traffic.
(The interfaces still received traffic.) Adjusting the setting
of the tx-ring higher had no effect. Shutting the ATM
interface caused the router to reload, and the ATM
interface began forwarding traffic again.
Testing resumed and the problem was later reproduced in
the lab.
Test Suite 4: Boston Basic IP Test with
Campus, page 88
EIGRP
Passed
CSCdx94638, CSCdx94691
System Test with
EIGRP
Passed
—
Reliability Test with
EIGRP
Passed
—
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
19
Test Suite 1: San Jose Campus with Data Center
Table 2
Test Results Summary (continued)
Test Suite
Test Category
Results
DDTS/Comments
Test Suite 5: Dallas
Campus, page 108
Basic IP Test with
EIGRP
Passed with
exceptions
CSCdx33917
•
The VIP4-80 processor in a Cisco 7507 router crashes
continuously at the checkheaps_process stage of the test
cycle, when the router is loaded with the newest image of
code (specifically, the rsp-jsv-mz.122-9.4a image).
Identical hardware and configuration runs successfully
with the previous image (for example, the
rsp-jsv-mz.122-8.1 image).
System Test with
EIGRP
Passed
—
Scalability Test with
EIGRP
Passed
—
Reliability Test with
EIGRP
Passed with
exceptions
•
Reduced QoS on voice traffic during periods of network
congestion.
Voice traffic between the Dallas and Santa Fe campuses,
and between the Denver and New Orleans campuses
suffered a QoS reduction. This reduced QoS occurred in
the regional-to-remote site direction, when the links were
congested with data traffic going in the same direction.
This reduction in QoS appeared as a 15-20% path
confirmation degradation to the RTP streams in the
Dallas-to-Santa Fe direction. Little or no QoS reduction
was observed in the RTP streams of the same calls in the
other RTP direction. Work is progressing to further
characterize this issue.
Test Suite 6: Remote Basic IP Test with
Campuses, page 136 EIGRP
Passed
—
System Test with
EIGRP
Passed
—
Reliability Test with
EIGRP
Passed with
exceptions
•
Reduced QoS on voice traffic during periods of network
congestion.
Voice traffic between the Dallas and Santa Fe campuses,
and between the Denver and New Orleans campuses
suffered a QoS reduction. This reduced QoS occurred in
the regional-to-remote site direction, when the links were
congested with data traffic going in the same direction.
This reduction in QoS appeared as a 15-20% path
confirmation degradation to the RTP streams in the
Dallas-to-Santa Fe direction. Little or no QoS reduction
was observed in the RTP streams of the same calls in the
other RTP direction. Work is progressing to further
characterize this issue.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
20
Test Suite Overview
Test Suite Overview
There are a total of six test suites, one for each campus (San Jose, Washington, D.C., Denver, Boston,
and Dallas), and one for the remote sites. Each test suite contains three or more feature-specific test
categories that address a specific type of testing conducted (that is, basic IP testing, system testing, and
reliability testing). Within each of these test categories, feature-specific test plans were designed and
implemented.
Table 3 lists each test suite, the category of testing conducted in the suite, the feature-specific tests, and
the chapter to turn to for detailed topology information.
.
Table 3
Test Suite Overview Table
Test Plan Suite
Category of Testing Conducted
Suite 1: San Jose Campus with Data
Center
Suite 2: Washington, D.C. Campus with
Data Center
Suite 3: Denver Campus
Suite 4: Boston Campus
Suite 5: Dallas Campus
Suite 6: Remote Campuses
•
Basic IP testing with EIGRP
•
System testing with EIGRP
•
Reliability testing with EIGRP
•
Basic IP testing with EIGRP
•
System testing with EIGRP
•
Reliability testing with EIGRP
•
Basic IP testing with EIGRP
•
System testing with EIGRP
•
Reliability testing with EIGRP
•
Basic IP testing with EIGRP
•
System testing with EIGRP
•
Reliability testing with EIGRP
•
Basic IP testing with EIGRP
•
System testing with EIGRP
•
Reliability testing with EIGRP
•
Basic IP testing with EIGRP
•
System testing with EIGRP
•
Reliability testing with EIGRP
Test Suite Chapter
Test Suite 1: San Jose Campus with
Data Center, page 22
Test Suite 2: Washington, D.C.
Campus with Data Center, page 46
Test Suite 3: Denver Campus,
page 65
Test Suite 4: Boston Campus,
page 88
Test Suite 5: Dallas Campus,
page 108
• Scalability performance testing with
EIGRP
Test Suite 6: Remote Campuses,
page 136
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
21
Test Suite 1: San Jose Campus with Data Center
Test Suite 1: San Jose Campus with Data Center
This test suite consisted of three test cases intended to verify the functionality, reliability and
performance of basic IP and quality of service (QoS) at the San Jose campus with data center.
The San Jose campus with data center is one component of the larger global enterprise topology. The
global enterprise topology consists of five multilayer-design campuses — two large campuses with data
centers and three regional campuses — and nine remote sites. For more information about the global
enterprise topology, see the “Global Enterprise Topology” section of this document.
In the test suite for the San Jose campus with data center, the following categories (or types) of testing
were conducted:
•
Basic IP testing
This test category verified the reliability and performance of basic IP functionality, using Enhanced
Interior Gateway Routing Protocol (EIGRP) and Border Gateway Protocol (BGP) as the routing
protocols.
•
System testing
This test category verified system performance for a number of QoS features, using EIGRP and BGP
as the routing protocols.
•
Reliability testing
This test category verified system reliability.
This test suite contains the following sections:
•
Topology Description, page 22
•
Basic IP Test with EIGRP, page 26
•
System Test with EIGRP, page 34
•
Reliability Test with EIGRP, page 44
Topology Description
The San Jose campus topology represents a large enterprise headquarters campus with a data center.
The WAN access routers, connecting to the other global enterprise sites and to the Internet service
provider (ISP), consist of two Cisco 7609 Optical Services Routers (OSR). The WAN aggregation router,
connecting to remote sites, is a Cisco 7206 VXR router.
Multiple types of high-speed WAN links are used, including OC3 POS line card interface links, OC3
ATM line card interface links, T1 links, and High-Speed Serial Interface (HSSI) links. The core of the
campus consists of four Catalyst 6509 switches with two Multilayer Switch Feature (MSFC2) cards and
Policy Feature (PFC2) cards.
High-speed core layer 3 Gigabit Ethernet (GE) links are used to connect two user buildings and one data
center building. Within each building, two Catalyst 6506 switches are used as distribution layer switches
and multiple Catalyst switches, such as the 4006, 5505 and 6506 switches, are used as the access layer
switches. A Cisco 3640 router is used as a Voice over IP (VoIP) voice gateway. Another Cisco 3640
router is used as a VoIP gatekeeper. This VoIP gatekeeper is used for the entire global enterprise
topology.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
22
Test Suite Overview
EIGRP is the IP interior gateway protocol (IGP) routing protocol, and approximately 600 routes will be
used at various points in the topology. BGP is the IP exterior gateway protocol (EGP) routing protocol
used for the ISP connection. Global application servers located at the San Jose campus serve all
campuses within the entire global enterprise topology.
The database servers (located at the data center of this campus) serve this campus and store data for the
entire global enterprise topology. A redundant database server is included in the Washington, D.C.
campus.
Applications such as Voice, NetMeeting, FTP, HTTP, Simple Network Management Protocol (SNMP)
are simulated by traffic generating test tools. The testbed simulates traffic through the use of traffic
generators and PC (UNIX) stations.
Figure 10 shows the San Jose campus with data center topology at a high level and includes the names
of the individual routers.
Figure 10
San Jose Campus with Data Center High Level Topology
Dallas
Washington, D.C.
Boston
ATM
Los Angeles
ISP 1
Denver
Washington, D.C.
WAN Access
egsj-7609-w1
egsj-6506-sd1
egsj-7609-w2
egsj-5505-sa1
egsj-7206-w3
WAN Regional
Aggregation
egsj-5505-sa2
egsj-6506-sd2
Core
egsj-6509-c1
egsj-6509-c2
egsj-6509-c3
egsj-6509-c4
egsj-6506-sa3
Data Center Servers
egsj-3640-gk egsj-3640-v
Voice gateway and
gatekeeper
egsj-6506-b2d2
egsj-6506-b1d1
egsj-6506-b1d2
egsj-4006-b1a1 egsj-5505-b1a2 egsj-6506-b1a3
egsj-4003-b2a1 egsj-6506-b2a2
Building 1
Building 2
82506
egsj-6506-b2d1
FE
GE
HSSI(P2P)
POS OC3(P2P)
ATM OC3
T1(P2P)
T3(P2P)
ATM T3
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
23
Test Suite 1: San Jose Campus with Data Center
Figure 11 shows the San Jose campus with data center topology at a more detailed level and includes the
interface names.
Figure 11
San Jose Campus with Data Center Detailed Topology
Dallas
Washington, D.C.
ATM
Boston
Denver
s2/0/0
Los Angeles
s4/0
h2/0/0
egsj-7609-w1
egsj-7206-w3
g1/0,2/0
a2/1/0
Washington, D.C.
p3/1/0
a3/0/0
s2/1/0
g6/3 - g6/3
egsj-6506-sd1
egsj-7609-w2
g1/1,2
f4/1,2
g1/1,2
g1/1,2
g2/16 - g2/16
g3/13,11,12,15,16
egsj-6506-sd2
g3/13,11,12,15,16
egsj-6509-c2
g3/1 - g3/1
g3/2,3
g3/2,3
g3/14,15
g3/14,15
1/1,2
egsj-5505-sa1
1/1,2
g1/1,2
egsj-6509-c1
ISP 1
egsj-5505-sa2
1/1,2
egsj-6506-sa3
f1/0
f1/0
g3/16 - g3/16
egsj-6509-c4
egsj-6509-c3
egsj-3640-gk egsj-3640-v
g3/1,2,3
g3/1,2,3
g1/1,2
egsj-6506-b1d1
g1/1
g2/16 - g2/16
g2/1,2,3
1/1,2
egsj-4006-b1a1
egsj-6506-b1d2
g1/1
egsj-6506-b2d2
g2/16 - g2/16
g2/1,2,3 egsj-6506-b2d1
1/1,2
1/1,2
egsj-5505-b1a2 egsj-6506-b1a3
2/1,2
egsj-4003-b2a1
1/1,2
egsj-6506-b2a2
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
24
FE
GE
HSSI(P2P)
POS OC3(P2P)
ATM OC3
T1(P2P)
T3(P2P)
ATM T3
82507
g1/1,2
Test Suite Overview
Figure 12 shows the San Jose campus with data center topology with the IP addresses.
Figure 12
San Jose Campus with Data Center Topology with IP Addresses
Dallas
Washington, D.C.
Boston
ATM
Los Angeles
ISP 1
Denver
Washington, D.C.
.5
egsj-7609-w1
.9 .10
.1
egsj-6509-c1
.5
.6
.3
.2
egsj-6509-c2
. 53
.17
.18
.54
.2
.21
.4
.22
.21
. 22
.1
.18 7
.13
.14
.11
egsj-6506-b1d2
.12
.21
.9
egsj-3640-gk egsj-3640-v
egsj-6506-b2d2
.22
egsj-6506-b2d1
egsj-4003-b2a1 egsj-6506-b2a2
Building 2
address range:
1.1.32.0/19
1.2.32.0/19
1.3.32.0/19
96.5.16.0/21
FE
GE
HSSI(P2P)
POS OC3(P2P)
ATM OC3
T1(P2P)
T3(P2P)
ATM T3
82508
egsj-4006-b1a1 egsj-5505-b1a2 egsj-6506-b1a3
egsj-6506-sa3
7
.5
8
.5
.8
egsj-6509-c4
.9 .1 0
.5 .6
egsj-5505-sa2
4
.102
egsj-6506-sd2
.1
.2
.1
egsj-6506-b1d1
.5
egsj-5505-sa1
.6
.1
.13
egsj-6509-c3
1.1.0.0/19
1.2.0.0/19
1.3.0.0/19
96.5.8.0/21
.1 .2
.38
.37
. 13
.14
Building 1
address range:
.3
.2 0
9
96.5.1.x/30 (P2P)
96.5.3.x/30 (P2P)
96.5.4.x/30 (P2P)
96.5.0.x/32 (loopback)
.26
.25
egsj-6506-sd1
.101
.6
egsj-7609-w2
4
.3 3
.3
.46
.45
. 50
. 49
egsj-7206-w3
.41 .42
.9
.10
.7
DC address range:
1.1.160.0/19
1.2.160.0/19
1.3.160.0/19
96.5.136.0/21
Platform and Software Version Information
Table 4 lists the platforms, router names, software versions, and software images configured in the
network topology for this test suite.
Table 4
Platform, Router Names, Software Version, and Software Image Table
Platform
Router Name
Software Version
Software Image
Catalyst 6500
egsj-6509-c1
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 6500
egsj-6509-c2
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 6500
egsj-6509-c3
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 6500
egsj-6509-c4
12.1(12c)E1
c6sup2_rp-JSV-M
Cisco 7600
egsj-7609-w1
12.1(12c)E1
c6sup2_rp-JSV-M
Cisco 7600
egsj-7609-w2
12.1(12c)E1
c6sup2_rp-JSV-M
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
25
Test Suite 1: San Jose Campus with Data Center
Table 4
Platform, Router Names, Software Version, and Software Image Table (continued)
Platform
Router Name
Software Version
Software Image
Cisco 7200
egsj-7206-w3
12.2(12
C7200-A3JS-M
Cisco 3640
egsj-3640-gk
12.2(12)
C3640-IX-M
Cisco 3640
egsj-3640-v
12.2(12)
C3640-A3JS-M
Catalyst 6500
egsj-6506-b1d1
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 6500
egsj-6506-b1d2
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 4000
egsj-4006-b1a1
7.2(1)
NmpSW
Catalyst 5500
egsj-5505-b1a2
6.3(6)
NmpSW
Catalyst 6500
egsj-6506-b1a3
6.3(6)
NmpSW
Catalyst 6500
egsj-6506-b2d1
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 6500
egsj-6506-b2d2
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 4000
egsj-4003-b2a1
7.2(1)
NmpSW
Catalyst 6500
egsj-6506-b2a2
6.3(6)
NmpSW
Catalyst 6500
egsj-6506-sd1
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 6500
egsj-6506-sd2
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 5500
egsj-5505-sa1
6.3(3)
NmpSW
Catalyst 5500
egsj-5505-sa2
6.3(6)
NmpSW
Catalyst 6500
egsj-6506-sa3
6.3(6)
NmpSW
Basic IP Test with EIGRP
This test category verified the reliability and performance of basic IP functionality, using EIGRP as the
routing protocol.
Along with basic IP, the following additional features were configured:
•
BGP 4
•
Cisco Express Forward (CEF) Support for IP Routing between IEEE 802.1Q VLANs
•
EIGRP
•
EIGRP Stub Routing
•
Hot Standby Router Protocol (HSRP)
•
IEEE 802.1Q virtual LAN (VLAN) Support
•
Terminal Access Controller Access Control System (TACACS+)
The objectives of this test category included the following:
•
To verify that the software can be loaded and used in the devices successfully.
•
To verify that the network operation (that is, the network connectivity) is working correctly.
•
To verify that the major IP routing features work as expected.
•
To collect the network baseline information and provide the necessary test results.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
26
Test Suite Overview
In this test category, the following individual tests were conducted:
•
Layer 2 protocols and HSRP test
•
EIGRP with BGP routing test
•
Traffic routing convergence test
•
Traffic load capacity test
Layer 2 Protocols and HSRP Test
This test involved testing various layer 2 protocols and HSRP. The following features were included in
the test plan:
•
VLAN Trunking Protocol (VTP) and VLAN
•
VLAN Trunking
•
Spanning-Tree Protocol (STP)
•
HSRP
Test Plan
The procedure used to perform the layer 2 protocols and HSRP test follows:
Step 1
Use the CatOS show vlan command, the CatOS show vtp domain command, and the CatOS show vtp
status command to verify the VTP and VLAN configuration.
Step 2
Use the Cisco Native IOS show interface trunk command and the CatOS show trunk command to
verify that the VLAN Trunkings are formed correctly.
Step 3
Set up the STP feature (root replacement). Use the Cisco IOS show spanning-tree root command to
verify that the spanning tree roots are on the distribution switches.
The left side of the distribution switch in a building block is the primary root for odd-numbered VLANs
and the secondary root for even-numbered VLANs. The right side of the distribution switch in a building
block is the primary root for even-numbered VLANs and the secondary root for odd-numbered VLANs.
Step 4
Set up HSRP. Use the Cisco IOS show standby brief command to verify that each distribution switch
is the active HSRP router for half of the VLANs (either the even-numbered VLANs or the odd-numbered
VLANs).
Step 5
Conduct negative test of STP and HSRP. To do this, shut down any one of the distribution switches in
the same building and use the show spanning-tree root command to verify that the spanning tree root
changed to the active distribution switch in the building. Then use the show standby brief to verify that
the HSRP secondary router takes over the active state for all the VLANs.
Step 6
Disconnect both uplinks from one distribution layer switch to the core in the building. Use the show
standby brief command to verify that the HSRP active group will fail over to another distribution layer
switch. Recover the uplinks, use the show standby brief command to verify that the HSRP active group
will switch back.
Expected Results
We expect the following results:
•
The VTP and VLAN configuration will work correctly.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
27
Test Suite 1: San Jose Campus with Data Center
•
The spanning tree roots on the distribution switches work correctly.
•
Each distribution switch is an active HSRP route for half of the VLANs (either the even-numbered
VLANs or the odd-numbered VLANs.
•
During negative testing of STP and HSRP, the HSRP secondary router takes over the active state for
all VLANs.
•
The HSRP active group switches back correctly.
Results
Table 5 shows the layer 2 protocols and HSRP test results.
Table 5
Layer 2 Protocols and HSRP Test Results
Tests
Results
Layer 2 protocols and HSRP
Pass
EIGRP with BGP Routing Test
This test involved testing EIGRP with BGP routing. The following features were included in the test
plan:
•
Route summarization, filtering, and redistribution
•
EIGRP stub router functionality
•
BGP policy control (specifically, autonomous system (AS) prepend and route filtering)
•
EIGRP metric tuning
Test Plan
This test verified route summarization, route filtering, route redistribution, EIGRP stub router
functionality, BGP policy control, and EIGRP metric tuning. There are several parts to this test plan,
described in the sections that follow.
Route Summarization, Filtering, and Redistribution Test
The procedure used to perform the route summarization, filtering, and redistribution test follows:
Step 1
Turn off EIGRP auto-summary on all EIGRP-enabled routers.
Step 2
Configure a distribution list on the core routers, the egsj-6509-c3 router and the egsj-6509-c4 router, to
allow local campus routes and default routes advertised to the distribution layer routers only.
Step 3
Configure a distribution list on the WAN aggregation router, the egsj-7206-w3 router, to allow local
campus summarized routes and the default route to be advertised to the remote sites only.
Step 4
Configure all the distribution layer routers and voice routers as EIGRP stub routers, so that the EIGRP
queries do not go to the distribution layer routers or the voice routers.
BGP Policy Control Test
The procedure used to perform the BGP policy control test follows:
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
28
Test Suite Overview
Step 1
Configure BGP and EIGRP routing on the campus WAN access router, the egsj-7609-w2 router.
Step 2
Redistribute BGP into EIGRP, and permit only the default route to be redistributed into EIGRP.
Step 3
Configure the Cisco IOS eigrp log-neighbor-changes command on all the EIGRP-enabled routers.
Step 4
Configure the egsj-7609-w2 BGP policy so that the traffic from the ISP destined to the local campus
prefixes get high priority (by using AS prepending) to the advertised prefixes of the remote campuses.
EIGRP Metric Tuning Test
The procedure used to perform the EIGRP metric tuning test follows:
Step 1
Tune the switch virtual interface (SVI) delay on the distribution layer switches to enable symmetric
routing for the end-user networks. On the left distribution layer switch (the HSRP primary group for all
the odd-numbered VLANs), change the SVI delay on the even-numbered VLAN interface from
10 milliseconds (usec) to 50 usec. This configuration enables the left distribution layer switch to
advertise an undesirable routing metric to the core routers for all the even-numbered VLAN interfaces.
A similar configuration is done on the right distribution layer switch.
Step 2
Tune the link bandwidth for all the DS3 (and higher) links, including interfaces h2/0/0 and a2/1/0 (on
the egsj-7609-w1 router) and interfaces a3/0/0, pos3/1/0, and s2/0/0 (on the egsj-7609-w2 router). Set
the bandwidth to 10 Mbps.
Step 3
Configure all the SVI interfaces on the distribution layer routers as EIGRP passive interfaces.
Step 4
Configure the Cisco IOS no peer neighbor-route command for all the encapsulated PPP WAN
interfaces to avoid sub-optimal routing for these WAN interface routes.
Step 5
Analyze the output of the Cisco IOS show commands listed in Table 6.
Table 6 lists each command and the role it plays in the EIGRP with BGP test.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
29
Test Suite 1: San Jose Campus with Data Center
Table 6
show Commands Used in the EIGRP with BGP Routing Test
Command
show ip route
Purpose
•
Verifies that the routes are summarized as
expected.
•
Verifies that the route filters work as expected.
•
Verifies that the default route is generated as
expected.
show ip route
•
Verifies the symmetric routing for the building
end-user networks.
show processes cpu
•
Verifies the CPU utilization.
•
Verifies that CPU capacity is not being
monopolized by a single router.
show memory summary
•
Verifies that there are no memory leaks and
other memory errors.
show logging
•
Verifies that there are no significant errors for
EIGRP routing.
show ip bgp
•
Verifies that BGP route filtering is working
correctly.
•
Verifies the network connectivity.
•
Verifies BGP AS prepending policy control on
the ISP routers.
•
Verifies if there are any input errors, output
errors, or queue drops.
•
Verifies the router's throughput.
show ip eigrp neighbors detail
•
Verifies that the distribution layer routers are
EIGRP stub enabled.
show ip eigrp neighbors
•
Verifies that the EIGRP neighbor was not
created between two distribution layer routers.
show ip route [interface name]
•
Verifies that these specific WAN interface routes
are not in the routing table.
and
show ip route summary
and
show ip bgp summary
show ip bgp
and
show ip route
show interfaces [interface type]
Expected Results
We expect the following results:
•
The routes are summarized correctly.
•
The route filters function correctly.
•
The distribution layer routers are EIGRP stub-enabled.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
30
Test Suite Overview
•
The default route is generated correctly.
•
The BGP AS prepending policy control is enabled on the ISP routers.
•
There are no EIGRP routing errors and that the link delay and bandwidth have been tuned correctly.
•
BGP route filtering functions correctly.
•
The EIGRP neighbor was not created between two distribution layer routers.
•
The routing table displays the appropriate routes.
Results
Table 7 shows the EIGRP with BGP routing test results.
Table 7
EIGRP with BGP Routing Test Results
Test Conducted
Pass/Fail
EIGRP with BGP routing
Pass
Traffic Routing Convergence Test
The following section describes the procedures for setting up traffic routing and conducting the traffic
routing convergence testing.
Test Plan
The procedure used to perform the traffic routing convergence test follows:
Step 1
Use the Cisco IOS show ip route command to verify that all simulated routes exist.
Step 2
Set up a continuous ping between two PCs located in two points in the topology. For the ping packet
size, use 512 bytes. For the ping time-out setting, use 500 milliseconds (ms).
Step 3
During the ping test, make the link-to-router connection fail as described above.
Step 4
Capture the number of ping packets lost, and derive the convergence time from the product of the total
number of packets lost and the ping time-out setting.
Step 5
After the link-to-router connection is up, created another link-to-router connection failure (if any are
link-to-router combinations are available) and repeat Step 2 and Step 3. As an example, there are four
different link-to-router connection failures for testing the New York-to-Santa Fe link, four iterations are
needed.
Expected Results
We expect that all simulated routes exist and that the link connections between two points in the topology
will be established and maintained.
Results
Table 8 shows the traffic routing convergence test results.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
31
Test Suite 1: San Jose Campus with Data Center
Table 8
Traffic Routing Convergence Test Results
Tests
Results
Traffic routing convergence
Pass
Table 9 shows the results from traffic routing convergence test 480310.0, which shows the results from
a 0% traffic load.
Table 9
Traffic Routing Convergence Test 480310.0 Results
End-to-end Traffic Path Primary Link
Failure Scenario
Within San Jose
campus
GE
Interface was shut down < 1 second
San Jose–Denver
campus
HSSI
Interface on one side
was shut down
~ 2 seconds
The physical cable was
plugged out
~ 2 seconds
Interface on one side
was shut down
~ 12 seconds
The physical cable was
plugged out
~ 4 seconds
Denver
campus–Phoenix
remote site
New York remote
site–Santa Fe remote
site
Channelized T1
FR or ATM PVC
Convergence Time
The subinterface on one ~ 12 seconds
side was shut down
Table 10 shows the results from traffic routing convergence test 480310.1, which shows the results from
a 50% traffic load.
Table 10
Traffic Routing Convergence Test 480310.1 Results
End-to-end Traffic Path Primary Link
Failure Scenario
Within San Jose
campus
GE
Interface was shut down < 1 second
San Jose–Denver
campus
HSSI
Interface on one side
was shut down
~ 2 seconds
The physical cable was
plugged out
~ 2 seconds
Interface on one side
was shut down
~ 12 seconds
The physical cable was
plugged out
~ 4 seconds
Denver
campus–Phoenix
remote site
New York remote
site–Santa Fe remote
site
Channelized T1
FR or ATM PVC
Convergence Time
The subinterface on one ~ 12 seconds
side was shut down
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
32
Test Suite Overview
Table 11 shows the results from traffic routing convergence test 480310.2, which shows the results from
a 90% traffic load.
Table 11
Traffic Routing Convergence Test 480310.2 Results
End-to-end Traffic Path Primary Link
Failure Scenario
Within San Jose
campus
GE
Interface was shut down < 1 second
San Jose–Denver
campus
HSSI
Interface on one side
was shut down
~ 2 seconds
The physical cable was
plugged out
~ 2 seconds
Interface on one side
was shut down
~ 13 seconds
The physical cable was
plugged out
~ 5 seconds
Denver
campus–Phoenix
remote site
New York remote
site–Santa Fe remote
site
Channelized T1
FR or ATM PVC
Convergence Time
The subinterface on one ~ 13 seconds
side was shut down
Traffic Load Capacity Test
This test was intended to test the network configuration at 0% of traffic load capacity, at 50% of traffic
load capacity, and at 90% of traffic load for a period of 2 to 4 hours.
Test Plan
The procedure used to perform the traffic load capacity test follows:
Step 1
At 0% of network traffic capacity, repeat the steps for the Layer 2 Protocols and HSRP test plan, the
EIGRP with BGP routing test plan, and the routing traffic convergence test plan.
Step 2
Increase network traffic capacity to 50%.
Step 3
Repeat the steps for the Layer 2 Protocols and HSRP test plan, the EIGRP with BGP routing test plan,
and the routing traffic convergence test plan.
Step 4
Increase network traffic capacity to 90%.
Step 5
Repeat the steps for the Layer 2 Protocols and HSRP test plan, the EIGRP with BGP routing test plan,
and the routing traffic convergence test plan.
Expected Results
We expect that the network configuration continues to work correctly at each level of traffic load
capacity.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
33
Test Suite 1: San Jose Campus with Data Center
Results
Table 12 shows the traffic load capacity test results.
Table 12
Traffic Load Capacity Test Results
Tests
Results
Traffic load capacity
Pass
System Test with EIGRP
This section describes in detail the system testing for QoS features (listed below) on the San Jose campus
with data center, using EIGRP and BGP as the routing protocols.
The following QoS features were included in this test category:
•
Classification and marking, including the following:
– Access lists
– Network-based application recognition (NBAR)
– Port numbers
– IP Precedence
– Differentiated services code point (DSCP)
•
Congestion avoidance, including the following:
– Weighted Random Early Detection (WRED)
•
Congestion management, including the following:
– Class-based weighted fair queueing (CBWFQ)
– Distributed CBWFQ (dCBWFQ)
– Priority queueing (PQ)
– Low latency queueing (LLQ)
– Distributed LLQ (dLLQ)
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
34
Test Suite Overview
In addition to those features listed above, the following features were configured in this test category:
•
BGP 4
•
Priority queueing (PQ)
•
Multilink PPP (MLPPP) performance enhancements
•
ATM virtual circuit (VC) scaling
•
Distributed Traffic Shaping (DTS)
•
Generic Traffic Shaping (GTS)
•
H.323 Version 2 Support
•
H.323 Gate Keeper
•
H.323/H.320 Gateway
•
HSRP
•
IEEE 802.1Q VLAN Support
•
IP
•
VoIP
•
Weighted Random Early Detection (WRED)
The objectives of this test category include the following:
•
To verify that the QoS features can be incorporated into the San Jose campus.
•
To verify the successful operation of the Cisco IOS release.
•
To ensure that the system behaves as expected.
•
To collect the network baseline information and provide the necessary test results.
In the test category, the following individual tests were conducted:
•
Voice gateway test
•
Voice traffic verification test
•
Voice and data traffic verification test
•
QoS setup test
•
QoS verification test
•
Traffic routing convergence test
Voice Gateway Test
The Voice Gateway test verified that the remote gateways and gatekeeper were configured correctly and
functioning as expected for handling the voice traffic on the network.
Test Plan
The procedure used to perform the voice gateway test follows:
Step 1
Configure the egsj-3640-v router as a voice gateway.
Step 2
Configure the egsj-3640-gk router as a voice gatekeeper.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
35
Test Suite 1: San Jose Campus with Data Center
Step 3
Check that the San Jose, Dallas, Washington, D.C., Denver, Boston, and all remote sites gateways are
functioning by verifying that these gateways are registered with the gatekeeper, egsj-3640-gk, in the San
Jose campus. Do this by using the Cisco IOS show gatekeeper endpoints command.
Step 4
Check that the San Jose campus gateway is registered with the gatekeeper using the Cisco IOS show
gateway command on the egsj-3640-v router.
Step 5
Configure the bulk call traffic generator (BCG) to generate traffic.
Expected Results
We expect that the voice gateways and gatekeepers are configured as anticipated, are registered correctly,
and are functioning properly.
Results
Table 13 shows the voice gateway test results.
Table 13
Voice Gateway Test Results
Test
Results
Voice gateway
Pass
Voice Traffic Verification Test
This test verified that incoming and outgoing voice traffic is handled properly on the network. In this test
plan, no QoS features are configured and the network was free from traffic congestion.
Test Plan
The procedure used to perform the voice traffic verification test follows:
Step 1
Step 2
Start the bulk call traffic generator by completing the following steps:
a.
Start the Callgen channels to Washington, D.C. (7 calls), Boston (1 call), Dallas (1 call), Denver
(3 calls) and Los Angeles (1 call).
b.
Verify that all Callgen channels are functioning correctly. Do this by using the show channel
command of the Callgen testing tool for 5 minutes.
Analyze the output of the Cisco IOS show commands listed in Table 14.
Table 14
show Commands Used for the Voice Traffic Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Displays the current time.
show memory summary
•
Verifies that there are no memory leaks.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic shaping is
configured on the interface, the output rate should not exceed
the shaped rate. Traffic exceeding the rate will be dropped.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
36
Test Suite Overview
The show commands listed in Table 14 were used on the distribution layer switches and interfaces listed
in Table 15.
Table 15
Step 3
San Jose Distribution Layer Switches and Interfaces
Router
Interface
egsj-6506-b1d1
g3/1, g3/2, g3/3
egsj-6506-b1d2
g3/1, g3/2, g3/3
egsj-6506-b2d1
g3/1, g3/2
egsj-6506-b2d2
g3/1, g3/2
egsj-6506-sd1
g3/1, g3/2, g3/3
egsj-6506-sd2
g3/1, g3/2, g3/3
Analyze the output of the show commands listed in Table 14. The show processes cpu command was
used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1 hour.
The show commands listed in Table 14 were used on the WAN routers and interfaces listed in Table 16.
Table 16
Step 4
Step 5
San Jose WAN Routers and Interfaces
Router
Interface
egsj-7609-w1
HSSI2/0/0, ATM2/1/0
egsj-7609-w2
Serial2/0/0, ATM3/0/0, POS3/1/0
egsj-7206-w3
Serial4/0:0
Capture voice quality information by completing the following steps:
a.
Verify that the Callgen channels to Washington, D.C. (7 calls), Boston (1 call), Denver (3 calls),
Dallas (1 call) and Los Angeles (1 call) are functioning correctly. Do this by using the show channel
command of the Callgen testing tool.
b.
Use CIC to measure the call attempts/accepts and path confirmation for end users between San Jose
and Washington, D.C., between San Jose and Boston, between San Jose and Denver, between San
Jose and Dallas, and between San Jose and Los Angeles.
Stop the bulk call traffic generator and verify results by completing the following steps:
a.
Stop Callgen after 1 hour of run time.
b.
Verify that all Callgen channels are functioning correctly. Do this by using the show channel
command of the Callgen testing tool for 5 minutes.
c.
Capture the output statistics generated by the bulk call traffic generator (BCG). Do this by using the
show channel command of the Callgen testing tool.
Expected Results
We expect that voice traffic transmitted efficiently and that all voice channels originated and terminated
properly.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
37
Test Suite 1: San Jose Campus with Data Center
Results
Table 17 shows the voice traffic verification test results.
Table 17
Voice Traffic Verification Test Results
Test
Results
Voice traffic verification
Pass
Voice and Data Traffic Verification Test
This test plan verified that incoming and outgoing voice and data traffic was handled properly on the
network. In this test, no QoS features were configured and the network was experiencing traffic
congestion.
Test Plan
Before conducting this test plan, we verified that all data generators and the Callgen testing tool were
configured.
The procedure used to perform the voice and data traffic verification test follows:
Step 1
Step 2
Start the bulk call traffic generator by completing the following steps:
a.
Start Callgen channels to Washington, D.C. (7 calls), Boston (1 call), Dallas (1 call), Denver
(3 calls) and to Los Angeles (1 call).
b.
Verify that all Callgen channels are functioning correctly. Do this by using the show channel
command of the Callgen testing tool for 5 minutes.
Analyze the output of the show commands listed in Table 14. The show processes cpu command was
used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1 hour.
The Cisco IOS show commands listed in Table 14 were used on the distribution layer switches and
interfaces listed in Table 18.
Table 18
Step 3
San Jose Distribution Layer Switches and Interfaces
Router
Interface
egsj-6506-b1d1
g3/1, g3/2, g3/3
egsj-6506-b1d2
g3/2, g3/3
egsj-6506-b2d1
g3/1, g3/2
egsj-6506-b2d2
g3/1, g3/2
egsj-6506-sd1
g3/1, g3/2, g3/3
egsj-6506-sd2
g3/1, g3/2, g3/3
Analyze the output of the Cisco IOS show commands listed in Table 14. The show processes cpu
command was used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1
hour.
The show commands listed in Table 14 were used on the WAN routers and interfaces listed in Table 19.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
38
Test Suite Overview
Table 19
Step 4
Step 5
San Jose WAN Routers and Interfaces
Router
Interface
egsj-7609-w1
HSSI2/0/0, ATM2/1/0
egsj-7609-w2
Serial2/0/0, ATM3/0/0, POS3/1/0
egsj-7206-w3
Serial4/0:0
Capture voice quality information by completing the following steps:
a.
Verify that the Callgen channels to Washington, D.C. (7 calls), Boston (1 call), Denver (3 calls),
Dallas (1 call) and Los Angeles (1 call) are functioning correctly. Do this by using the show channel
command of the Callgen testing tool.
b.
Use CIC to measure call attempts/accepts and path confirmation for the end users between San Jose
and Washington, D.C., between San Jose and Boston, between San Jose and Denver, between San
Jose and Dallas, and between San Jose and Los Angeles.
Stop the bulk call traffic generator and verify results by completing the following steps:
a.
Stop Callgen after 1 hour of run time.
b.
Verify that all Callgen channels are functioning correctly. Do this by using the show channel
command of the Callgen testing tool for 5 minutes.
c.
Capture the output statistics generated by the bulk call traffic generator (BCG). Do this by using the
show channel command of the Callgen testing tool.
Expected Results
We expect that voice and data traffic transmit efficiently and that all voice and data channels originate
and terminate properly.
Results
Table 20 shows the voice and data traffic verification test results.
Table 20
Voice and Data Traffic Verification Test Results
Test
Results
Voice and data traffic
Pass
QoS Setup Test
The test verified that QoS features were configured correctly and that the QoS features were applied to
traffic classes as anticipated. In this test, the Modular Quality of Service Command-Line Interface
(MQC) three-step model was used to configure the traffic classes, class maps, and policy maps.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
39
Test Suite 1: San Jose Campus with Data Center
Test Plan
The procedure used to perform the QoS setup test follows:
Step 1
Step 2
Step 3
Define the access lists and traffic classes following the guidelines listed below.
•
Voice traffic is classified into a class-map called “Real-Time.”
•
Applications with small or infrequently sent packets such as Telnet, Citrix, and voice signaling are
classified into a class-map called “Interactive.”
•
Classify the mission-critical traffic or traffic that can consume large amounts of bandwidth into a
class-map called “Transactional.”
•
NetMeeting traffic is classified into the “Interactive-Video” class.
•
The “Control” class is configured for routing traffic.
•
HTTP and FTP traffic is classified into the “class-default” class.
Associate the policy maps and actions with each class of traffic by completing the following steps:
a.
Configure a policy map called IN-NBAR on the Cisco 7609 and the Cisco 7206 WAN routers. This
configuration tests the NBAR QoS features.
b.
Configure a policy map called IN-LAN on all distribution layer switches. This configuration tests
the access lists, port numbers, IP Precedences, and DSCP features of QoS.
c.
Configure a policy map called OUT-Bound-T1 on the Cisco 7206 WAN router. This configuration
tests the LLQ and CBWFQ features of QoS.
d.
Configure a policy map called OUT-Bound-10M on the 7609 WAN router. This configuration tests
the dWRED, dLLQ, and dCBWFQ features of QoS.
e.
Configure a policy map called OUT-Voice on the egsj-3640-v router. This configuration test the
access lists, port Number, and DSCP features of QoS.
Attach policy maps to the interfaces listed in Table 21.
Table 21 shows the router name, the policy map created, and the interface to which the policy map was
applied (attached).
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
40
Test Suite Overview
Table 21
Routers, Policy Maps, and Interfaces for the QoS Setup Test
Router
Policy Map
Interface
egsj-6506-b1d1
IN-LAN
g3/1, g3/2, g3/3
egsj-6506-b1d1
IN-LAN
g3/1, g3/2, g3/3
egsj-6506-b1d2
IN-LAN
g3/1, g3/2, g3/3
egsj-6506-b2d1
IN-LAN
g3/1, g3/2
egsj-6506-b2d2
IN-LAN
g3/1, g3/2
egsj-6506-sd1
IN-LAN
g3/1, g3/2, g3/3
egsj-6506-sd2
IN-LAN
g3/1, g3/2, g3/3
egsj-7609-w1
IN-NBAR
g1/1, g1/2, g6/3
egsj-7609-w1
OUT-Bound-10M
ATM2/1/0, HSSI2/0/0
egsj-7609-w2
IN-NBAR
g1/1, g1/2,g6/3
egsj-7609-w2
OUT-Bound-10M
Serial2/0/0, ATM3/0/0, POS3/1/0
egsj-7609-w3
IN-NBAR
g1/0, g2/0
egsj-7206-w3
OUT-Bound-T1
Serial4/0:0
egsj-3640-v
OUT-Voice
f1/0
Expected Results
We expect the following results:
•
Access lists and traffic classes were correctly defined.
•
Policy maps and actions were correctly associated.
•
Policy maps were attached to the appropriate interfaces.
•
QoS features were configured and were functioning properly.
Results
Table 22 shows the QoS setup test results.
Table 22
QoS Setup Test Results
Test
Results
QoS setup
Pass
QoS Verification Test
This test plan verified that incoming and outgoing voice and data traffic was handled properly on the
network, and that various QoS features (such as traffic shaping and QoS policy maps) were functioning
correctly. In this test, both voice and data traffic were used, QoS features were configured, and the
network was experiencing traffic congestion.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
41
Test Suite 1: San Jose Campus with Data Center
Test Plan
The procedure used to perform the QoS verification test follows:
Step 1
Start the Callgen, IXIA, and Chariot traffic testing tools to congest the network.
Step 2
Analyze the output of the Cisco IOS show commands listed in Table 23. The show processes cpu
command was used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1
hour.
Table 23
show Commands Used for the QoS Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Displays the current time.
show policy-map interface [interface name]
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the policy
maps.
show memory summary
•
Verifies that there are no memory leaks.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
The show commands listed in Table 23 were used on the distribution layer switches and interfaces listed
in Table 24.
Table 24
Step 3
San Jose Distribution Layer Switches and Interfaces
Router
Interface
egsj-6506-b1d1
g3/1, g3/2, g3/3
egsj-6506-b1d2
g3/1, g3/2, g3/3
egsj-6506-b2d1
g3/1, g3/2
egsj-6506-b2d2
g3/1, g3/2
egsj-6506-sd1
g3/1, g3/2, g3/3
egsj-6506-sd2
g3/1, g3/2, g3/3
egsj-3640-v
f1/0
Analyze the output of the show commands listed in Table 25. The show processes cpu command was
used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1 hour.
Table 25
show Commands Used for the QoS Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Displays the current time.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
42
Test Suite Overview
Table 25
show Commands Used for the QoS Verification Test
Command
Purpose
show policy-map interface [interface name]
•
Verifies that voice traffic in the “Real-Time”
class gets the percentage of bandwidth that was
assigned to it.
show memory summary
•
Verifies that there are no memory leaks.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show traffic-shape statistics
•
Verifies that traffic shaping is enabled.
The show commands listed in Table 25 were used on the WAN routers and interfaces listed in Table 26.
Table 26
Step 4
Step 5
San Jose WAN Routers and Interfaces
Router
Interface
egsj-7609-w1
HSSI2/0/0, ATM2/1/0
egsj-7609-w2
Serial2/0/0, ATM3/0/0, POS3/1/0
egsj-7206-w3
Serial4/0:0
Capture voice quality information by completing the following steps:
a.
Verify that the Callgen channels to Washington, D.C. (7 calls), Boston (1 call), Denver (3 calls),
Dallas (1 call), and Los Angeles (1 call) are functioning correctly. Do this by using the show
channel command of the Callgen testing tool.
b.
Use Chariot to measure the call attempts/accepts and path confirmation for the end users between
San Jose and Washington, D.C., between San Jose and Boston, between San Jose and Denver,
between San Jose and Dallas, and between San Jose and Los Angeles.
Analyze the output of the Cisco IOS show commands listed in Table 27 after the 1-hour test referred to
in Step 3 is completed. These commands were used on all the WAN routers and core switches.
Table 27
show Commands Used for the QoS Verification Test
Command
Step 6
Purpose
show class-map
•
Displays the configured class-map configured
for the device.
show policy-map
•
Displays the policy map configured for the
device.
show access-lists verify
•
Verifies that the configured access lists have the
correct amount of matching packets.
Capture the data statistics from the Chariot, IXIA, and Callgen testing tools after the 1-hour test referred
to in Step 3 is completed.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
43
Test Suite 1: San Jose Campus with Data Center
Expected Results
We expect the following results:
•
Access lists and traffic classes were correctly defined.
•
Traffic shaping was enabled and functioned correctly.
•
Class maps were correctly configured.
•
Policy maps and actions were correctly associated.
•
Policy maps were attached to the appropriate interfaces.
•
Voice and data traffic were assigned the proper amount of bandwidth in the policy maps.
Results
Table 28 shows the QoS verification test results.
Table 28
QoS Verification Test Results
Test
Results
QoS verification
Pass
Reliability Test with EIGRP
This section describes in detail the reliability test as it pertained to the San Jose campus, using EIGRP
as the routing protocol. The reliability test ran continuously for 150 hours, with basic IP routing and
switching enabled, and all QoS features configured.
The following additional features were configured in this test category:
•
BGP 4
•
CBWFQ
•
PQ
•
MLPPP performance enhancements
•
ATM VC scaling
•
dCBWFQ
•
dLLQ
•
dTS
•
GTS
•
HSRP
•
IEEE 802.1Q VLAN Support
•
LLQ
•
VoIP
•
WRED
The objective of this test category was to ensure that the software (at 100% traffic load capacity on each
WAN link) performed reliably for the 150-hour test period.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
44
Test Suite Overview
Test Plan
The procedure used to perform the reliability test with EIGRP test follows:
Step 1
Step 2
Start traffic streams by completing the following steps:
a.
Start the bulk call traffic generator (BCG) to generate calls.
b.
Start Chariot to simulate NetMeeting, Telnet, Citrix, FTP, and HTTP traffic.
c.
Start IXIA.
d.
Start LNE to simulate EIGRP routes.
Analyze the output of the Cisco IOS show commands listed in Table 29. These commands were used at
each router every hour for a 150-hour test period.
Table 29
show Commands Used for the Reliability Test with EIGRP Test
Command
Purpose
show clock
•
Displays the current time.
show ip route summary
•
Verifies the basic routing.
show access-lists verify
•
Verifies that the configured access lists have the
correct amount of matching packets.
show policy-map interface
•
Verifies that voice traffic in the Real-Time class
has the correct percentage of the link
bandwidth.
show interfaces
•
Verifies the link speed. If traffic shaping is
configured on the interface, the output rate
should not exceed the shaped rate. The
exceeding traffic will be dropped.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
show traffic-shape statistics
•
Verifies that traffic shaping is enabled.
show voice call summary
•
Verifies the call status for the voice calls placed
by the BCG.
Expected Results
We expect that the software (at 100% traffic load capacity on each WAN link) performs reliably during
the 150-hour test period.
Results
Table 30 shows the reliability test with EIGRP test results.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
45
Test Suite 1: San Jose Campus with Data Center
Table 30
Reliability Test with EIGRP Test Results
Tests
Results
Reliability test with EIGRP
Pass; Experienced a failure on the supervisor module and line
card. However, this failure did not interrupt the testing process.
Test Suite 2: Washington, D.C. Campus with Data Center
This test suite consisted of three test cases intended to verify the reliability and performance of basic IP
and quality of service (QoS) at the Washington, D.C. campus with data center.
The Washington, D.C. campus with data center is one component of the larger global enterprise
topology. The global enterprise topology consists of five multilayer-design campuses — two large
campuses with data centers and three regional campuses — and nine remote sites. For more information
about the global enterprise topology, see the “Global Enterprise Topology” section in this document.
In the test suite for the Washington, D.C. campus with data center, the following categories (or types) of
testing were conducted:
•
Basic IP testing
This test category verified the reliability and performance of basic IP functionality, using Enhanced
Interior Gateway Routing Protocol (EIGRP) and Border Gateway Protocol (BGP) as the routing
protocols.
•
System testing
This test category verified system performance for a number of QoS features, using EIGRP and BGP
as the routing protocol.
•
Reliability testing
This test category verified system reliability, using EIGRP as the routing protocol.
This test suite contains the following sections:
•
Topology Description, page 46
•
Basic IP Test with EIGRP, page 49
•
System Test with EIGRP, page 56
•
Reliability Test with EIGRP, page 63
Topology Description
The Washington, D.C. campus topology represents a large headquarters campus with a data center.
The topology consists of two Catalyst 6506 switches with two Multilayer Switch Feature (MSFC2) cards
and two Policy Feature (PFC2) cards as the core routers; two Cisco 7609 Optical Services Routers (OSR)
routers as the campus WAN routers; one Cisco 7507 router as the WAN aggregation router; one Catalyst
6506 router as the distribution router for the data center, and one Cisco 3640 router as the voice gateway.
The two Cisco 7609 OSR provide connectivity to the internet and to the other large campuses in this
topology through the use of the links such as the POS OC-3 line card interface link, the ATM OC-3 line
card interface link, the ATM-T3 line card interface link, the E3 line card interface link, and the T3 WAN
link.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
46
Test Suite Overview
The Cisco 7507 router acts as the WAN aggregation router for the remote sites connected to this campus,
through ATM or Frame Relay links with bandwidths slower than a T1 link. High-speed layer 3 Gigabit
Ethernet (GE) links connect these devices and provide sufficient redundancy. The voice gateway is
connected using a Fast Ethernet (FE) interface. The voice gateway uses the gatekeeper in the San Jose
campus for registration and places Voice over IP (VoIP) calls to the voice gateways in the other
campuses.
See Figure 9 on page 13 for the topology used for handling voice traffic.
EIGRP is the IP interior gateway protocol (IGP) routing protocol, and approximately 600 routes will be
used at various points in the topology. BGP is the IP exterior gateway protocol (EGP) routing protocol
for the Internet service provider (ISP) connection. The database servers (located at the data center of this
campus) serve this campus and store data for the entire global enterprise topology. A redundant database
server is included in the San Jose campus.
Applications such as Voice, NetMeeting, FTP, HTTP, and Simple Network Management Protocol
(SNMP) are simulated by traffic generating test tools. The testbed simulates traffic through the use of
traffic generators and PC (UNIX) stations.
Figure 13 shows the Washington, D.C. campus with data center topology at a high level and includes the
IP addresses for the routers.
Figure 13
Washington, D.C. Campus with Data Center Topology with IP Addresses
Pittsburg
96.1.0.28
San Jose
T3
ATM
96.1.0.40
San Jose
T1
96.1.0.12
E3
T1
ISP3
96.1.0.20
Dallas
ATM/FR
= GE
= FE
Boston
Miami
New York
Denver
POS
OC3
96.1.0.36
T3
T3
ATM-T3
ATM-OC3
isp3-7507
96.1.0.32
WAN Access
.6
.6
.6
.6
.6
1.231.248.4
1231.246.0
1.223248.0
2
egwas32 7609-w2
egwas7609-w1
.6
.13 .1
.1
7
37
egwas7507-w3
.6
1
.5
.17 .9
96.10.1.4
.13 .21
egwas-3640-v1
31
.38
.37 6
96.10.1.36
96.10.1.20
96.10.1.8
96.10.3.8
96.10.1.28
.6
36
96.10.3.4
96.10.1.16
96.10.1.12
96.10.1.32
L3 Core
was-pc3
96.10.17.100
.14
.34
.18
.10
.30
.10
was-pc2
96.10.9.100
3
.5
33
.9
96.10.138.100/38
Traffic
was-ux1
generators
X Loopback - 96.10.0.x
XX Backdoor - 223.255.10.XX
.25
96.10.18.1 4
was-ux3
96.10.18.100
.22
.6
Data Center
was-pc1
96.10.137.100/V37
egwas-6506-sd1
.6
96.10.1.24
34 96.10.17.1
egwas6506-c2
35
96.10.10.1
was-ux2
96.10.10.100
Traffic generators
82040
Traffic generators
.26
96.10.9.1 5
egwas6506-c3
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
47
Test Suite 1: San Jose Campus with Data Center
Figure 14 shows the Washington, D.C. Campus with Data Center topology at a more detailed level and
includes the interface types.
Figure 14
Washington, D.C. Campus with Data Center Topology with Interface Types
Pittsburg
Miami
New York
Dallas
ATM/FR
T3
Boston
San Jose
T1
ATM
San Jose
Denver
E3
T1
ATM-OC3
POS
OC3
ATM-T3
A3/0/0
T3
32
1
6/1
6/2
isp3-7507
S3/0/0
A3/0/0
6/1
= FE
= GE
T3
WAN Access
P4/1/0
S3/1/0/1
S4/0/1:0
A4/1/0.768 S4/0/0:0
2
egwas7600-w2
egwas7507-w3 6/3
7
37
0/0/0
ISP3
6/2
Data Center
was-pc1
egwas-6506-sd1
S3/0/1
6/2
egwas-3641-v1
31
5/1
6
36
33 6/1
1/2 3
0/1
6/3
1/1
Traffic generators
was-ux1
5/0/0
L3 Core
2/4
was-pc3
2/3
2/2
2/1
6/2
6/1
2/5
4
2/2
2/3
37 egwas6506-c2
was-ux3
5
X Loopback - 96.10.0.x
XX Backdoor - 223.255.10.XX
6/2
2/5
egwas6506-c3
was-pc2
35
6/1
was-ux2
Traffic generators
82041
Traffic generators
2/1
2/4
Platform and Software Version Information
Table 31 lists the platforms, router names, software versions, and software images configured in the
network topology for this test suite.
Table 31
Platform, Router Names, Software Version, and Software Image Table
Platform
Router Name
Software Version Software Image
Cisco 7609
egwas-7609-w1
12.1(12c)E1
c6sup2_rp-JSV-M
Cisco 7609
egwas-7609-w2
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 6500
egwas-6506-sd1
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 6500
egwas-6506-c1
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 6500
egwas-6506-c2
12.1(12c)E1
c6sup2_rp-JSV-M
Cisco 3660
egwas-3660-v1
12.2(12)
C3660-A3JS-M
Cisco 7507
egwas-7507-w3
12.2(12)
RSP-A3JSV-M
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
48
Test Suite Overview
Basic IP Test with EIGRP
This is a basic IP functionality test for the Washington, D.C. campus with data center. The test category
verified basic IP functionality, the layer 2 protocol VTP, and the layer 3 protocols EIGRP (for the interior
routing) and BGP (for the exterior routing). Along with basic IP, the following additional features were
configured:
•
BGP 4
•
EIGRP Stub Routing
The objectives for this test category included the following:
•
To verify that the software can be loaded and used in the devices successfully
•
To verify that the network operation (that is, the network connectivity) is working correctly
•
To verify that the major IP routing features work as expected
•
To collect the network baseline information and provide the necessary test results
In this test category, the following individual tests were conducted:
•
Layer 2 Protocol test
•
EIGRP with BGP routing test
•
Traffic routing convergence test
•
Traffic load capacity test
Layer 2 Protocol Test
This test involves testing the layer 2 protocol, Virtual Terminal Protocol (VTP), and the virtual LAN
(VLAN) configuration.
Test Plan
The procedure used to perform the layer 2 protocol test follows:
Step 1
Configure the distribution layer switch in the data center, egwas-6506-SD1, as a VTP server.
Step 2
Perform the L2 configuration on the egwas-6506-SD1 router, the distribution switch in the data center.
Step 3
Configure the VLAN 1 for control traffic and configure the VLAN interfaces numbered from 1 to 110 to
carry end user network traffic in the data center.
Step 4
Configure the VLAN interfaces numbered from 11 to 110 to route the VLAN traffic in the distribution
switch.
Step 5
Analyze the output of the CatOS show commands listed in Table 32. The commands in Table 32 were
used on the egwas-6506-sd1 router.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
49
Test Suite 1: San Jose Campus with Data Center
Table 32
show Commands Used for Verifying the Test Bed Setup
Command
Purpose
show vlan brief
•
Verifies the VLAN configuration.
show vtp status
•
Verifies the VTP configuration.
Expected Results
We expect that the VTP protocol and the VLAN configuration will work correctly.
Results
Table 33 shows the Layer 2 Protocol test results.
Table 33
Layer 2 Protocol Test Results
Tests
Results
Layer 2 protocol
Pass
EIGRP with BGP Routing Test
This test involved testing EIGRP with BGP routing. The following features were included in the test
plan:
•
Route summarization, filtering, and redistribution
•
EIGRP stub router functionality
•
BGP policy control (specifically, autonomous system (AS) prepend and route filtering)
•
EIGRP metric tuning
Test Plan
This test verified route summarization, route filtering, route redistribution, BGP policy control, and
EIGRP metric tuning. There were several parts to this test plan, described in the sections that follow.
Route Summarization, Filtering, and Redistribution Test
The procedure used to perform the route summarization, filtering, and redistribution test follows:
Step 1
Turn off EIGRP auto-summary on all EIGRP- enabled routers.
Step 2
Configure a distribution list on the core routers, egwas-6506-c1 and egwas-6506-c2, to allow local
campus routes and default route advertisement into the distribution switch egwas-6506-sd1.
Step 3
Configure a distribution list on the WAN aggregation router, egwas-6506-W3, to allow only summarized
local campus routes and default route to the remote sites.
Step 4
Configure the distribution layer router, the egwas-6506-sd1 router, as a EIGRP stub router to prevent
sending the EIGRP query into the access layer.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
50
Test Suite Overview
Step 5
Configure the Voice Gateway, the egwas-3660-v1 router, as a EIGRP stub router.
BGP Policy Control Test
The procedure used to perform the BGP policy control test follows:
Step 1
Configure BGP routing on the egwas-7609-w2 router. The BGP process receives the default route from
the ISP connection. The default route is re-distributed from the BGP process into the EIGRP process.
Step 2
Configure the Cisco IOS eigrp log-neighbor-changes command on all the EIGRP-enabled routers.
EIGRP Metric Tuning Test
The procedure used to perform the EIGRP metric tuning test follows:
Step 1
On the egwas-7609-w1 router, change the bandwidth of interfaces, Serial3/0/0, POS4/1/0, and
ATM3/1/0 to 10 Mbps.
Step 2
On the egwas-7609-w2 router, change the bandwidth of interfaces ATM3/0/0 and Multilink1 to 10 Mbps.
Step 3
On the egwas-7507-w3 router, change the bandwidth of interfaces Serial4/0/0:0 and Serial4/0/1:0 to
10 Mbps. Change the bandwidth of the ATM4/1/0.768 interface to 768 kbps.
Step 4
On the egwas-7507-w3 router, set the delay metric of the Multilink1 interface to 200 ms (usec).
Step 5
On the egwas-7609-w1 router, change the delay metric of the POS interface from 100 usec to 80 usec.
Step 6
Analyze the output of the Cisco IOS show commands listed in Table 34.
Table 34 lists each command and the role it plays in the EIGRP with BGP test.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
51
Test Suite 1: San Jose Campus with Data Center
Table 34
show Commands Used in the EIGRP with BGP Routing Test
Command
Purpose
show ip route
•
Verifies that the routes are summarized as expected.
and
•
Verifies that the route filters work as expected.
show ip route summary
•
Verifies that the default route is generated as expected.
show memory summary
•
Verifies that there are no memory leaks and other memory errors.
•
Verifies that CPU capacity is not being monopolized by a single
router.
•
Verifies the CPU utilization.
•
Verifies that CPU capacity is not being monopolized by a single
router.
show logging
•
Verifies that there are no significant errors for EIGRP routing.
show ip bgp
•
Verifies that BGP route filtering is working correctly.
and
•
Verifies the network connectivity.
•
Verifies BGP AS prepending policy control on the ISP routers.
•
Verifies that the distribution layer routers are EIGRP stub
enabled.
show processes cpu
show ip bgp summary
show ip bgp
and
show ip route
show ip eigrp neighbors
detail
Expected Results
We expect the following results:
•
The routes are summarized correctly.
•
The route filters function correctly.
•
The distribution layer routers are EIGRP stub-enabled.
•
The default route is generated correctly.
•
The BGP AS prepending policy control is enabled on the ISP routers.
•
There are no EIGRP routing errors and that the link delay and bandwidth have been tuned correctly.
•
BGP route filtering functions correctly.
•
The EIGRP neighbor was not created between two distribution layer routers.
•
The routing table displays the appropriate routes.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
52
Test Suite Overview
Results
Table 35 shows the EIGRP with BGP routing test results.
Table 35
EIGRP with BGP Routing Test Results
Tests
Results
EIGRP with BGP routing
Pass
Traffic Routing Convergence Test
The following section describes the procedures for setting up traffic routing and conducting the traffic
routing convergence testing.
Test Plan
The procedure used to perform the traffic routing convergence test follows:
Step 1
Use the Cisco IOS show ip route command to verify that all simulated routes exist.
Step 2
Set up a continuous ping between two PCs located in two points in the topology. For the ping packet
size, use 512 bytes. For the ping time-out setting, use 500 milliseconds (ms).
Step 3
During the ping test, make the link-to-router connection fail as described above.
Step 4
Capture the number of ping packets lost, and derive the convergence time from the product of the total
number of packets lost and the ping time-out setting.
Step 5
After the link-to-router connection is up, created another link-to-router connection failure (if any are
link-to-router combinations are available) and repeat Step 2 and Step 3. As an example, there are four
different link-to-router connection failures for testing the New York-to-Santa Fe link, four iterations are
needed.
Expected Results
We expect that all simulated routes exist and that the link connections between two points in the topology
can be established and maintained.
Results
Table 36 shows the traffic routing convergence test results.
Table 36
Traffic Routing Convergence Test Results
Tests
Results
Traffic routing convergence
Pass
Table 37 shows the results from traffic routing convergence test 480310.0, which shows the results from
a 0% traffic load.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
53
Test Suite 1: San Jose Campus with Data Center
Table 37
Traffic Routing Convergence Test 480310.0 Results
End-to-end Traffic Path Primary Link
Failure Scenario
Within San Jose
campus
GE
Interface was shut down < 1 second
San Jose–Denver
campus
HSSI
Interface on one side
was shut down
~ 2 seconds
The physical cable was
plugged out
~ 2 seconds
Interface on one side
was shut down
~ 12 seconds
The physical cable was
plugged out
~ 4 seconds
Denver
campus–Phoenix
remote site
New York remote
site–Santa Fe remote
site
Channelized T1
FR or ATM PVC
Convergence Time
The subinterface on one ~ 12 seconds
side was shut down
Table 38 shows the results from traffic routing convergence test 480310.1, which shows the results from
a 50% traffic load.
Table 38
Traffic Routing Convergence Test 480310.1 Results
End-to-end Traffic Path Primary Link
Failure Scenario
Within San Jose
campus
GE
Interface was shut down < 1 second
San Jose–Denver
campus
HSSI
Interface on one side
was shut down
~ 2 seconds
The physical cable was
plugged out
~ 2 seconds
Interface on one side
was shut down
~ 12 seconds
The physical cable was
plugged out
~ 4 seconds
Denver
campus–Phoenix
remote site
New York remote
site–Santa Fe remote
site
Channelized T1
FR or ATM PVC
Convergence Time
The subinterface on one ~ 12 seconds
side was shut down
Table 39 shows the results from traffic routing convergence test 480310.2, which shows the results from
a 90% traffic load.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
54
Test Suite Overview
Table 39
Traffic Routing Convergence Test 480310.2 Results
End-to-end Traffic Path Primary Link
Failure Scenario
Within San Jose
campus
GE
Interface was shut down < 1 second
San Jose–Denver
campus
HSSI
Interface on one side
was shut down
~ 2 seconds
The physical cable was
plugged out
~ 2 seconds
Interface on one side
was shut down
~ 13 seconds
The physical cable was
plugged out
~ 5 seconds
Denver
campus–Phoenix
remote site
New York remote
site–Santa Fe remote
site
Channelized T1
FR or ATM PVC
Convergence Time
The subinterface on one ~ 13 seconds
side was shut down
Traffic Load Capacity Test
This test was intended to test the network configuration at 0% of traffic load capacity, at 50% of traffic
load capacity, and at 90% of traffic load for a period of 2 to 4 hours.
Test Plan
The procedure used to perform the traffic load capacity test follows:
Step 1
At 0% of network traffic capacity, repeat the steps for the Layer 2 Protocol test plan, and the EIGRP with
BGP routing test plan.
Step 2
Increase network traffic capacity to 50%.
Step 3
Repeat the steps for the layer 2 protocol test plan, and the EIGRP with BGP routing test plan.
Step 4
Increase network traffic capacity to 90%.
Step 5
Repeat the steps for the layer 2 protocol and HSRP test plan, and the EIGRP with BGP routing test plan.
Expected Results
We expect that the network configuration will continue to work correctly at each level of traffic load
capacity.
Results
Table 40 shows the traffic load capacity test results.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
55
Test Suite 1: San Jose Campus with Data Center
Table 40
Traffic Load Capacity Test Results
Tests
Results
Traffic load capacity
Pass
System Test with EIGRP
This section describes in detail the system testing for QoS features (listed below) on the Washington,
D.C. campus with data center, using EIGRP and BGP as the routing protocols.
The following QoS features were included in this test category:
•
Classification and marking, including the following:
– Access lists
– IP Precedence
– Differentiated services code point (DSCP)
•
Congestion Avoidance, including the following:
– Weighted Random Early Detection (WRED)
•
Congestion management, including the following:
– Distributed class-based weighted fair queueing (dCBWFQ)
– Distributed low latency queueing (dLLQ)
•
Traffic conditioning, including the following:
– Distributed Traffic Shaping (dTS)
•
Link efficiency mechanisms, including the following:
– Multilink PPP (MLPPP) interleaving
In addition to those features listed above, the following features were configured in this test category:
•
Distributed Link Fragmentation and Interleaving over Frame Relay and ATM Interfaces
•
Frame Relay/ATM Interworking
•
VoIP
The objectives of this test category included the following:
•
To verify that the QoS features can be incorporated into the Washington, D.C. Campus.
•
To verify the successful operation of the Cisco IOS release.
•
To ensure that the system behaves as expected.
•
To collect the network baseline information and provide the necessary test results.
In this test category, the following individual tests were conducted:
•
Voice gateway test
•
Voice traffic verification test
•
Voice and data traffic verification test
•
QoS setup test
•
QoS verification test
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
56
Test Suite Overview
Voice Gateway Test
The voice gateway test verifies that the remote gateways and gatekeeper are configured correctly and
functioning as expected for handling the voice traffic on the network.
Test Plan
The procedure used to perform the voice gateway test follows:
Step 1
Configure the egwas-3640-v router as a voice gateway.
Step 2
Using the Cisco IOS show gateway command, verify that this gateway, the egwas-3640-v router, is
registered with the gatekeeper.
Step 3
Configure the bulk call traffic generator (BCG) to generate traffic.
Expected Results
We expect that the voice gateways and gatekeepers are configured as anticipated, are registered correctly,
and are functioning properly.
Results
Table 41 shows the voice gateway test results.
Table 41
Voice Gateway Test Results
Tests
Results
Voice gateway
Pass
Voice Traffic Verification Test
This test verified that incoming and outgoing voice traffic was handled properly on the network. In this
test plan, no QoS features were configured and the network was free from traffic congestion.
Test Plan
The procedure used to perform the voice traffic verification test follows:
Step 1
Step 2
Start the bulk call traffic generator by completing the following steps:
a.
Start a BCG channel to San Jose (6 calls), Boston (1 call), Dallas (3 calls), Miami (1 call) and to
New York (1 call).
b.
Verify that the BGC channels are functioning correctly. Do this by using the call traffic generator
show channel command for 5 minutes.
Analyze the output of the Cisco IOS show commands listed in Table 42. The show processes cpu
command was used every 60 seconds for 2 hours. The other commands were used every 5 minutes for 2
hours.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
57
Test Suite 1: San Jose Campus with Data Center
Table 42
show Commands Used for the Voice Traffic Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Displays the current time.
show memory summary
•
Verifies that there are no memory leaks.
show interfaces
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
The show commands listed in Table 42 were used on the WAN routers and interfaces listed in Table 43.
Table 43
Step 3
Step 4
Washington, D.C. WAN Routers and Interfaces
Router
Interface
egwas-7609-w1
ATM3/1/0, Serial3/0/0, POS4/1/0
egwas-7609-w2
Serial3/1/0/1, ATM3/0/0
egwas-7507-w3
Serial4/0/1:0, Serial4/0/0:0, ATM4/1/0.768
Capture voice quality information by completing the following steps:
a.
Verify that the Callgen channel statistics to Washington, D.C. (7 calls), Boston (1 call), Denver
(3 calls), Dallas (1 call), and Los Angeles (1 call) are functioning correctly. Do this by using the
show channel command of the Callgen testing tool.
b.
Use Chariot and QPro to measure the call attempts/accepts and path confirmation for the end users
between San Jose and Washington, D.C., between Washington, D.C. and Boston, between
Washington, D.C. and Miami, between Washington, D.C. and Dallas, and between Washington,
D.C. and New York.
Stop the bulk call traffic generator and verify results by completing the following steps:
a.
Stop BCG after 1 hour of run time.
b.
Verify that all BCG channels are functioning correctly. Do this by using the show channel command
for 5 minutes.
c.
Capture the output statistics generated by the bulk call traffic generator (BCG). Do this by using the
show channel command.
Expected Results
We expect that voice traffic will be transmitted efficiently and that all voice channels originate and
terminate properly.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
58
Test Suite Overview
Results
Table 44 shows the voice traffic verification test results.
Table 44
Voice Traffic Verification Test Results
Tests
Results
Voice traffic verification
Pass
Voice and Data Traffic Verification Test
This test plan verified that incoming and outgoing voice and data traffic was handled properly on the
network. In this test, no QoS features were configured and the network was experiencing traffic
congestion.
Test Plan
Before conducting this test plan, we verified that all data generators and the BCG were configured. Then
the steps listed below were performed.
The procedure used to perform the voice and data traffic verification test follows:
Step 1
Start the BCG, Chariot, and IXIA traffic testing tools to congest the network.
Step 2
Analyze the output of the show commands listed in Table 42. The show processes cpu command was
used every 60 seconds for 2 hours. The other commands were used t every 5 minutes for 2 hours.
The show commands listed in Table 42 were used on the WAN routers and interfaces listed in Table 43.
Step 3
Step 4
Capture voice quality information by completing the following steps:
a.
Verify that the BCG channel statistics to San Jose (6 calls), Boston (1 call), Dallas (3 calls), Miami
(1 call), and New York (1 call) are functioning correctly. Do this by using the show channel
command.
b.
Use Chariot to measure the call attempts/accepts and path confirmation for the end users between
San Jose and Washington, D.C., between Washington, D.C. and Boston, between Washington, D.C.
and Dallas, between Washington, D.C. and New York, and between Washington, D.C. and Miami.
Capture the data statistics from the QDM, Chariot testing tools, and the BCG after the 2-hour run.
Expected Results
We expect that voice and data traffic will be transmitted efficiently and that all voice and data channels
originate and terminate properly.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
59
Test Suite 1: San Jose Campus with Data Center
Results
Table 45 shows the voice and data traffic verification test results.
Table 45
Voice and Data Traffic Verification Test Results
Tests
Results
Voice and data traffic
Pass
QoS Setup Test
The test verified that QoS features were configured correctly and that the QoS features were applied to
traffic classes as anticipated. In this test, the Modular Quality of Service Command-Line Interface
(MQC) three-step model was used to configure the traffic classes, class maps, and policy maps.
Test Plan
The procedure used to perform the QoS setup test follows:
Step 1
Step 2
Step 3
Define the access lists and traffic classes following the guidelines listed below.
•
Voice traffic is classified into a class-map called “Real-Time.”
•
Applications with small or infrequently sent packets such as Telnet, Citrix, and voice signaling are
classified into a class-map called “Interactive.”
•
Classify the mission-critical traffic or traffic that can consume large amounts of bandwidth into a
class-map called “Transactional.”
•
NetMeeting traffic is classified into the “Interactive-Video” class.
•
The “Control” class is configured for routing traffic.
•
HTTP and FTP traffic is classified into the “class-default” class.
Associate the policy maps and actions with each class of traffic by completing the following steps.
a.
Configure a policy map called “IN-bound” on the Cisco 7609 and the Cisco 7507 WAN routers. This
configuration tests the access lists, IP Precedence, and DSCP QoS features.
b.
Configure a policy map called “OUT-bound-[interface name]” on the Cisco 7609 and the Cisco 7507
WAN routers. This configuration tests the dWRED, dLLQ, and dCBWFQ QoS features.
c.
Configure a policy map called “OUT-parent-[interface name]” on the Cisco 7609 router with
non-ATM point-to-point interfaces.
Attach policy maps to the interfaces listed in Table 46.
Table 46 shows the router name, the policy map created, and the interface to which the policy map was
applied (attached).
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
60
Test Suite Overview
Table 46
Routers, Policy Maps, and Interfaces for the QoS Setup Test
Router
Policy Map
Interface
egwas-7609-w1
IN-bound
g6/1, g6/2, g6/3
egwas-7609-w1
OUT-parent-10M
POS4/1/0, Serial3/0/0
egwas-7609-w1
OUT-bound-10M
ATM3/1/0
egwas-7609-w1
OUT-parent-10M
Shape POS4/1/0 to 10M
egwas-7609-w1
IN-bound
g6/1, g6/2, g6/3
egwas-7609-w2
OUT-parent-10M
Serial3/1/0/1
egwas-7609-w2
OUT-bound-10M
ATM3/0/0
egwas-7507-w3
IN-bound
g0/0/0, g5/0/0
egwas-7507-w3
OUT-bound-10M
Serial4/0/0:0, Serial4/0/1:0
egwas-7507-w3
OUT-bound-768
Virtual-Template1
Expected Results
We expect the following results:
•
Access lists and traffic classes are correctly defined.
•
Policy maps and actions have been correctly associated.
•
Policy maps are attached to the appropriate interfaces.
•
QoS features have been configured and are functioning properly.
Results
Table 47 shows the QoS setup test results.
Table 47
QoS Setup Test Results
Tests
Results
QoS setup
Pass
QoS Verification Test
This test plan verified that incoming and outgoing voice and data traffic was handled properly on the
network, and that various QoS features (such as traffic shaping and QoS policy maps) were functioning
correctly. In this test, both voice and data traffic were used, QoS features were configured, and the
network was experiencing traffic congestion.
Test Plan
The procedure used to perform the QoS verification test follows:
Step 1
Start the BCG, and the Chariot, and IXIA traffic testing tools to congest the network.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
61
Test Suite 1: San Jose Campus with Data Center
Step 2
Analyze the output of the Cisco IOS show commands listed in Table 48. The show processes cpu
command was used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1
hour.
Table 48
show Commands Used for the QoS Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Displays the current time.
show policy-map interface
•
Verifies that voice traffic in Real-Time class gets
the percentage of bandwidth that was assigned
to it.
show memory summary
•
Verifies that there are no memory leaks.
show interfaces
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show traffic-shape statistics
•
Verifies that traffic shaping is enabled.
The show commands listed in Table 48 were used on the WAN routers and interfaces listed in Table 49.
Table 49
Step 3
Step 4
Washington, D.C. WAN Routers and Interfaces
Router
Interface
egwas-7609-w1
ATM3/1/0, Serial3/0/0, POS4/1/0
egwas-7609-w2
Serial3/1/0/1, ATM3/0/0
egwas-7507-w3
Serial4/0/1:0, Serial4/0/0:0, ATM4/1/0.768
Capture voice quality information by completing the following steps:
a.
Verify that the BCG channel statistics to San Jose (6 calls), Boston (1 call), Dallas (3 calls), Miami
(1 call), and New York (1 call) are functioning correctly. Do this by using the show channel
command.
b.
Use Chariot to measure the call attempts/accepts and path confirmation for the end users between
San Jose and Washington, D.C., between Washington, D.C. and Boston, between Washington, D.C.
and Dallas, between Washington, D.C. and Miami, and between Washington, D.C. and New York.
Analyze the output of the Cisco IOS show commands listed in Table 50. These commands were used on
all the WAN routers and core switches.
Table 50
show Commands Used for the QoS Verification Test
Command
Purpose
show class-map
•
Displays the configured class-map configured
for the device.
show policy-map
•
Displays the policy map configured for the
device.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
62
Test Suite Overview
Step 5
Capture the data statistics from the BCG and Chariot testing tools after the 1-hour test referred to in
Step 2 is completed.
Expected Results
We expect the following results:
•
Access lists and traffic classes are correctly defined.
•
Traffic shaping has been enabled and is functioning correctly.
•
Class maps have been correctly configured.
•
Policy maps and actions have been correctly associated.
•
Policy maps are attached to the appropriate interfaces.
•
Voice and data traffic are assigned the proper amount of bandwidth in the policy maps.
Results
Table 51 shows the QoS verification test results.
Table 51
QoS Verification Test Results
Tests
Results
QoS verification
Pass
Reliability Test with EIGRP
This section describes in detail the reliability test as it pertained to the Washington, D.C. campus, using
EIGRP as the routing protocol. The reliability test ran continuously for 150 hours, with basic IP routing
and switching enabled, and all QoS features configured.
The following additional features were configured in this test category:
•
BGP 4
•
dCBWFQ
•
Distributed Link Fragmentation and Interleaving (dLFI) over Frame Relay and ATM Interfaces
feature
•
dLLQ
•
dTS
•
EGRP stub routing
•
Frame Relay/ATM Interworking
•
Multilink PPP Enable
•
VoIP
The objective of this test category was to ensure that the software (at 100% traffic load capacity on each
WAN link) performs reliably for the 150-hour test period.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
63
Test Suite 1: San Jose Campus with Data Center
Test Plan
The procedure used to perform the reliability test with EIGRP follows:
Step 1
Step 2
Start traffic streams by completing the following steps:
a.
Start the BCG to generate calls.
b.
Start Chariot to simulate NetMeeting, Telnet, Citrix, FTP, and HTTP traffic.
c.
Start IXIA.
d.
Start LNE to simulate EIGRP routes.
Using the DART testing tool, run the Cisco IOS show commands (listed in Table 52) at each router every
hour for a 150-hour test period.
Table 52
show Commands Used for the Reliability Test with EIGRP Test
Command
Purpose
show clock
•
Displays the current time.
show ip route summary
•
Verifies the basic routing.
show interfaces
•
Verifies the link speed. If there traffic shaping is
configured on the interface, the output rate
should not exceed the shaped rate. The
exceeding traffic will be dropped.
show policy-map interface
•
Verifies that voice traffic in the Real-Time class
has the correct percentage of the link
bandwidth.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
show traffic-shape statistics
•
Verifies that traffic shaping is enabled.
show voice call summary
•
Verifies the call status for the voice calls placed
by the BCG.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface was configured by the
virtual-template number.
show ppp multilink
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
Expected Results
We expect that the software (at 100% traffic load capacity on each WAN link) performs reliably during
the 150-hour test period.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
64
Test Suite Overview
Results
Table 53 shows the reliability test with EIGRP test results.
Table 53
Reliability Test with EIGRP Test Results
Tests
Results
Reliability test with EIGRP
Pass
Test Suite 3: Denver Campus
This test suite consisted of three test cases intended to verify the reliability and performance of basic IP
and quality of service (QoS) at the Denver campus.
The Denver campus is one component of the larger global enterprise topology. The global enterprise
topology consists of five multilayer-design campuses — two large campuses with data centers and three
regional campuses — and nine remote sites. For more information about the global enterprise topology,
see the “Global Enterprise Topology” section in this document.
In the test suite for the Denver campus, the following categories (or types) of testing were conducted:
•
Basic IP testing
This test category verified the reliability and performance of basic IP functionality, using Enhanced
Interior Gateway Routing Protocol (EIGRP) and Border Gateway Protocol (BGP) as the routing
protocols.
•
System testing
This test category verified system performance for a number of QoS features, using EIGRP and BGP
as the routing protocols.
•
Reliability testing
This test category verified system reliability, using EIGRP as the routing protocol.
This test suite contains the following sections:
•
Topology Description, page 65
•
Basic IP Test with EIGRP, page 69
•
System Test with EIGRP, page 76
•
Reliability Test with EIGRP, page 86
Topology Description
The Denver campus topology represents a medium size enterprise campus located in a region of North
America.
The WAN routers that connect to the other global enterprise sites and to the Internet consist of three
Cisco 7206 VXR Network Processor Engine (NPE400) routers and a Cisco 7507 Route Switch Processor
(RSP8) router, using serial PPP and ATM on the WANs. The campus also consists of a Gigabit Ethernet
(GE) and a Fast Ethernet (FE) LAN.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
65
Test Suite 1: San Jose Campus with Data Center
There are two Catalyst 6506 routers, each with a Multilayer Switch Feature (MSFC2) card and a Policy
Feature (PFC2) card, in the core; two Catalyst 6506 routers, each with MSFC2 and PFC2 cards, in the
distribution layer; one Catalyst 6506 router and two Catalyst 4003 routers in the access layer.
A Cisco 3640 router is used as a Voice over IP (VoIP) gateway. This gateway registers into a gatekeeper
located at the San Jose campus headquarters and places VoIP calls to the other gateways located at
different campuses.
See Figure 9 on page 13 for the topology used for handling voice traffic.
EIGRP is the IP interior gateway protocol (IGP) routing protocol, and approximately 320 routes will be
used at various points in the topology. Global application servers are located at this campus, serving the
smaller and remote campuses.
Applications such as Voice, NetMeeting, FTP, HTTP, Simple Network Management Protocol (SNMP)
simulated by traffic generating test tools. The testbed simulates traffic through the use of traffic
generators and PC (UNIX) stations.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
66
Test Suite Overview
Figure 15 shows the Denver campus topology at a high level and includes the IP addresses for the
routers.
Washington, D.C.
ATM
Denver Campus Topology with IP Addresses
egden-7206-w1
221.1.0.1/32
ATM OC3 .38
96.1.0.36
ISP 1
.9
egden-6506-c1
221.1.0.6/32
egden-6506-d1
221.1.0.8/32
221.1.14
221.1.1.0
96.1.0.8
HSSI
.10 .2
(P2P) .46
96.1.0.44
Building 1
address range:
1.8.0.0/19
1.9.0.0/19
1.10.0.0/19
221.1.8.0/21
.5
.1
San Jose
Submask:
Loopback, 32 bits
P2P, 30 bits
PC, 24 bits
221.1.18
den-pc1
1.8.0.100
egden-6506-a1
den-ux1
1.9.0.100
.6
.13
221.1.1.12 .14
.17
.26
.21
egden-7206-w2
221.1.0.2/32
221.1.1.16
221.1.1.20
.22
.1
221.1.4.0
.9
den-pc2
1.10.0.100
.2
.6
.13
.38 .45
221.1.48
221.1.1.44
221.1.4.12
egden-3640-v1
221.1.44
221.1.0.5/32
128
221.1.1.24
Colorado Springs
.10 .46
.14
Phoenix
egden-7206-w3
.10
.5
221.1.0.3/32
.18
1.215.240.0
Santa Fe
.25
.1
221.1.4.16
.30
ISDN
.29 221.1.1.28
.18
.17
.5
.42
.33
128
egden-6506-c2
egden-6506-d2
221.1.1.36
Col. Springs
221.1.1.32
221.1.0.7/32
221.1.0.9/32
128
221.1.1.40
Santa Fe
1.215.240.4
.34
.37
.1
1.207.240.0
.5
1.207.240.4 ATM/FR
.41
.9
1.207.248.8
.1
egden-7507-w4
221.1.0.4/32
New Orleans
1.199.2480
128
Houston
L.A.
384
egden-4003-a2
den-ux2
221.1.8.100
egden-4003-a3
ISDN BRI
ISDN PRI
T1 (P2P)
GE
FE
den-pc3
1.8.1.100
den-ux3
1.9.1.100
76328
Figure 15
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
67
Test Suite 1: San Jose Campus with Data Center
Figure 16 shows the Denver campus topology at a more detailed level and includes the interface types.
Figure 16
Denver Campus Topology with Interface Types
den-pc1
Washington, D.C.
egden-7206-w1
ATM OC3 a4/0
ATM
g2/0
fa1/0
fa3/0
San Jose
fa4/14
egden-6506-a1
egden-6506-c1
HSSI (P2P)
h3/0
fa0/0
s6/0-2
ISP 1
g2/0
fa1/0
egden-7206-w2
egden-6506-d1
g3/9
g3/3
g3/1
g3/5
g3/3
g3/7
den-ux1
g1/2
g3/9
fa4/14
fa4/0
g3/1
g3/5
g3/11
fa1/0
fa4/16
g1/1
g3/7
den-pc2
g3/11
egden-4003-a2
fa3/14
g3/1
128
Colorado Springs
Santa Fe
egden-3640-v1
g3/2
fa4/14
Phoenix
egden-7206-w3
fa1/0
s3/0:0
g2/0
g3/1
g3/5
g3/3
fa4/16
g3/1
fa4/1/0
g3/5
g3/7
g3/3
s5/0/0:0
New Orleans
128
g3/11
g3/1
fa3/14
egden-6506-c2
egden-6506-d2
g3/2
fa3/16
egden-4003-a3
g0/00
a5/1/0
ATM/FR
den-pc3
g3/9
fa0/0
128
Col. Springs
128
Santa Fe
den-pc2
g3/7
g3/9
ISDN
a5/0
fa3/16
den-pc3
ISDN BRI
ISDN PRI
T1 (P2P)
GE
FE
g1/00
egden-7507-w4
L.A.
76327
Houston
384
Platform and Software Version
Table 54 lists the platforms, router names, software versions, and software images configured in the
network topology for this test suite.
Table 54
Platforms, Router Names, Software Versions, and Software Images Table
Platform
Router Name
Software Version
Software Image
Cisco 7206
egden-7206-w1
12.2(12)
C7200-A3JS-M
Cisco 7206
egden-7206-w2
12.2(12)
C7200-A3JS-M
Cisco 7206
egden-7206-w3
12.2(12)
C7200-A3JS-M
Cisco 7507
egden-7507-w4
12.2(12)
RSP-A3JSV-M
Cisco 3640
egden-3640-v1
12.2(12)
C3640-A3JS-M
Catalyst 6500
egden-6506-c1
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 6500
egden-6506-c2
12.1(12c)E1
c6sup2_rp-JSV-M
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
68
Test Suite Overview
Table 54
Platforms, Router Names, Software Versions, and Software Images Table
Platform
Router Name
Software Version
Software Image
Catalyst 6500
egden-6506-d1
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 6500
egden-6506-d2
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 6500
egden-6506-a1
6.3(6)
NmpSW
Catalyst 4000
egden-4003-a2
7.2(1)
NmpSW
Catalyst 4000
egden-4003-a3
7.2(1)
NmpSW
Basic IP Test with EIGRP
This is a basic IP functionality test for the Denver campus. The test category verified basic IP
functionality, the layer 2 protocols such as VTP and VLAN trunking, and layer 3 protocols, such as
HSRP and EIGRP (for interior routing), and BGP (for exterior routing). Along with basic IP, the
following additional features were configured:
•
BGP 4
•
IEEE 802.1Q VLAN Support
The objectives of this test category included the following:
•
To verify that the software can be loaded and used in the devices successfully.
•
To verify that the network operation (that is, the network connectivity) is working correctly.
•
To verify that the major IP routing features work as expected.
•
To collect the network baseline information and provide the necessary test results.
In this test category, the following individual tests were conducted:
•
Layer 2 Protocol and HSRP test
•
EIGRP with BGP routing test
•
Traffic routing convergence test
•
Traffic load capacity test
Layer 2 Protocol and HSRP Test
The following features were included in the test bed for this procedure:
•
VTP and VLAN
•
VLAN Trunking
•
HSRP
Test Plan
The procedure used to perform the layer 2 protocol and HSRP test follows:
Step 1
Use the CatOS show vlan command, the CatOS show vtp domain command, and the CatOS show vtp
status command to verify the VTP and VLAN configuration.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
69
Test Suite 1: San Jose Campus with Data Center
Step 2
Use the Cisco IOS show interface trunk command and the CatOS show trunk command to verify that
the VLAN Trunkings are formed correctly.
Step 3
Set up HSRP. Use the Cisco IOS show standby brief command to verify that each distribution switch
is the active HSRP router for half of the VLANs (either the even-numbered VLANs or the odd-numbered
VLANs).
Step 4
Conduct negative testing of HSRP. To do this, shut down or disconnect the uplink from the
egden-6506-a1 router to the egden-6506-d1 router. Use the Cisco IOS show standby brief command to
verify that the HSRP active group will fail connecting over to the egden-6506-d2 router. Recover the
link. Then verify that the HSRP active group will switch back. Shut down both links from the
egden-6506-d1 router to core routers and verify that the egden-6506-d2 router takes over as the active
group.
Expected Results
We expect the following results:
•
The VTP and VLAN configuration will work correctly.
•
Each distribution switch is an active HSRP route for half of the VLANs (either the even-numbered
VLANs or the odd-numbered VLANs.
•
During negative testing of HSRP, the HSRP secondary router takes over the active state for all
VLANs.
•
The HSRP active group switches back correctly.
Results
Table 55 shows the layer 2 protocol and HSRP test results.
Table 55
Layer 2 Protocol and HSRP Test Results
Tests
Results
Layer 2 and HSRP
Pass
EIGRP with BGP Routing Test
This test involves testing EIGRP with BGP routing. The following features were included in the test
plan:
•
Route summarization, filtering, and redistribution
•
BGP policy control (specifically, autonomous system (AS) prepend and route filtering)
•
EIGRP metric tuning
Test Plan
This test verified route summarization, route filtering, route redistribution, EIGRP stub router
functionality, BGP policy control, and EIGRP metric tuning. There were several parts to this test plan,
described in the sections that follow.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
70
Test Suite Overview
Route Summarization, Filtering, and Redistribution Test
The procedure used to perform the route summarization, filtering, and redistribution test follows:
Step 1
Configure campus WAN routers, the egden-7206-w1 router and the egden-7206-w2 router, to summarize
the end-user networks within the building to /20 and /21 prefixes.
Step 2
Configure the WAN regional aggregation routers, the egden-7206-w3 router and the egdal-7507-w4
router, to summarize the end-user networks within the building to /20 and /21 prefixes.
Step 3
Configure WAN regional aggregation routers, the egden-7206-w3 router and the egdal-7507-w4 router,
to summarize the WAN links to the remote sites to one /21 route for each remote site.
Step 4
Turn off EIGRP auto-summary on all EIGRP-enabled routers.
Step 5
Configure a distribution list on the core routers, the egden-6506-c1 router and egden-6506-c2 router, to
allow only local campus routes and default routes to be advertised into the distribution routers.
Step 6
Configure a distribution list on the WAN aggregation routers, the egden-7206-w3 router and
egden-7507-w4 router, to only allow local summarized routes and default routes to advertise out to the
remote sites.
Step 7
Configure all the distribution layer routers, and the voice router to be stub routers, so that the EIGRP
query scope is limited.
BGP Policy Control Test
The procedure used to perform the BGP policy control test follows:
Step 1
Configure BGP and EIGRP routing on the WAN access router, the egden-7206-w2 router. BGP will
acquire the default route from ISP1.
Step 2
Redistribute BGP into EIGRP. and permit only the default route to be redistributed into EIGRP. This
default route will be advertised into the whole EIGRP AS including to the remote sites.
Step 3
Configure the eigrp log-neighbor-changes command under router eigrp1 on all the WAN routers.
Step 4
Configure egden-7206-w2 BGP policy so that the traffic destined to the local prefixes will get into the
correct AS, using the closest Internet connection via the prepending AS number.
EIGRP Metric Tuning Test
The procedure used to perform the EIGRP metric tuning test follows:
Step 1
On the egden-6506-d1 router (the HSRP primary distribution switch for the odd-numbered VLANs),
change the delay setting on the even-numbered VLAN interfaces from 10 ms (usec) to 50 usec.
Step 2
On the egden-6506-d2 router (the HSRP primary distribution switch for the even-numbered VLANs),
change the delay setting on the odd-numbered VLAN interfaces from 10 usec to 50 usec.
Step 3
On the egden-7206-w1 router, set the bandwidth of the HSSI3/0 interface to 10 Mbps.
Step 4
On the egden-7206-w2 router, set the bandwidth of the ATM4/0 interface to 10 Mbps.
Step 5
On the egden-7206-w3 router, set the bandwidth of both the ATM5/0.128 and ATM5/0.127 interfaces to
128 Kbps.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
71
Test Suite 1: San Jose Campus with Data Center
Step 6
On the egden-7507-w4 router, change the bandwidth of the ATM5/1/0.384 interface to 384 Kbps and
change the bandwidth on the ATM5/1/0.128 interface to 128 Kbps.
Step 7
Configure the bandwidth command to match the QoS bandwidth settings.
Step 8
Configure the Cisco IOS no peer neighbor-route command on all the back-to-back WAN links.
Step 9
Analyze the output of Cisco IOS show commands listed in Table 56.
Table 56 lists each command and the role it plays in verifying the EIGRP with BGP setup.
Table 56
Commands Used in the EIGRP with BGP Routing Test
Command
Purpose
show ip route
•
Verifies that the routes are summarized as expected.
and
•
Verifies that the route filters work as expected.
show ip route summary
•
Verifies that the closet path to ISP1 is used for the
traffic from or destined to the campus.
show memory summary
•
Verifies that there are no memory leaks and other
memory errors.
•
Verifies that CPU capacity is not being monopolized
by a single router.
show logging
•
Verifies that there are no significant errors.
show interfaces [interface name]
•
Verifies any input errors, output errors, or queue drops.
•
Verifies throughput of router.
show ip eigrp neighbors detail
•
Verifies that the distribution layer routers are EIGRP
stub enabled.
show ip bgp
•
Verifies that BGP route filtering is working correctly.
and
•
Verifies the network connectivity to ISP1.
show ip bgp summary
•
Verifies BGP AS prepending policy control on the ISP
routers.
•
Verifies symmetric routing for the building end-user
network.
and
show processes cpu
and
ping
show ip route
Expected Results
We expect the following results:
•
The routes are summarized correctly.
•
The route filters function correctly.
•
The distribution layer routers are EIGRP stub-enabled.
•
The default route is generated correctly.
•
The BGP AS prepending policy control is enabled on the ISP routers.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
72
Test Suite Overview
•
There are no EIGRP routing errors and that the link delay and bandwidth have been tuned correctly.
•
BGP route filtering functions correctly.
•
The EIGRP neighbor was not created between two distribution layer routers.
•
The routing table displays the appropriate routes.
Results
Table 57 shows the EIGRP with BGP routing test results.
Table 57
EIGRP with BGP Routing Test Results
Tests
Results
EIGRP with BGP routing
Pass
Traffic Routing Convergence Test
The following section describes the procedures for setting up traffic routing and conducting the traffic
routing convergence testing.
Test Plan
The procedure used to perform the traffic routing convergence test follows:
Step 1
Use the Cisco IOS show ip route command to verify that all simulated routes exist.
Step 2
Set up a continuous ping between two PCs located in two points in the topology. For the ping packet
size, use 512 bytes. For the ping time-out setting, use 500 milliseconds (ms).
Step 3
During the ping test, make the link-to-router connection fail as described above.
Step 4
Capture the number of ping packets lost, and derive the convergence time from the product of the total
number of packets lost and the ping time-out setting.
Step 5
After the link-to-router connection is up, created another link-to-router connection failure (if any are
link-to-router combinations are available) and repeat Step 2 and Step 3. As an example, there are four
different link-to-router connection failures for testing the New York-to-Santa Fe link, four iterations are
needed.
Expected Results
We expect that all simulated routes exist and that the link connections between two points in the topology
can be established and maintained.
Results
Table 58 shows the traffic routing convergence test results.
Table 58
Traffic Routing Convergence Test Results
Tests
Results
Traffic routing convergence
Pass
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
73
Test Suite 1: San Jose Campus with Data Center
Table 59 shows the results from traffic routing convergence test 480310.0, which shows the results from
a 0% traffic load.
Table 59
Traffic Routing Convergence Test 480310.0 Results
End-to-end Traffic Path Primary Link
Failure Scenario
Within San Jose
campus
GE
Interface was shut down < 1 second
San Jose–Denver
campus
HSSI
Interface on one side
was shut down
~ 2 seconds
The physical cable was
plugged out
~ 2 seconds
Interface on one side
was shut down
~ 12 seconds
The physical cable was
plugged out
~ 4 seconds
Denver
campus–Phoenix
remote site
New York remote
site–Santa Fe remote
site
Channelized T1
FR or ATM PVC
Convergence Time
The subinterface on one ~ 12 seconds
side was shut down
Table 60 shows the results from traffic routing convergence test 480310.1, which shows the results from
a 50% traffic load.
Table 60
Traffic Routing Convergence Test 480310.1 Results
End-to-end Traffic Path Primary Link
Failure Scenario
Within San Jose
campus
GE
Interface was shut down < 1 second
San Jose–Denver
campus
HSSI
Interface on one side
was shut down
~ 2 seconds
The physical cable was
plugged out
~ 2 seconds
Interface on one side
was shut down
~ 12 seconds
The physical cable was
plugged out
~ 4 seconds
Denver
campus–Phoenix
remote site
New York remote
site–Santa Fe remote
site
Channelized T1
FR or ATM PVC
Convergence Time
The subinterface on one ~ 12 seconds
side was shut down
Table 61 shows the results from traffic routing convergence test 480310.2, which shows the results from
a 90% traffic load.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
74
Test Suite Overview
Table 61
Traffic Routing Convergence Test 480310.2 Results
End-to-end Traffic Path Primary Link
Failure Scenario
Within San Jose
campus
GE
Interface was shut down < 1 second
San Jose–Denver
campus
HSSI
Interface on one side
was shut down
~ 2 seconds
The physical cable was
plugged out
~ 2 seconds
Interface on one side
was shut down
~ 13 seconds
The physical cable was
plugged out
~ 5 seconds
Denver
campus–Phoenix
remote site
New York remote
site–Santa Fe remote
site
Channelized T1
FR or ATM PVC
Convergence Time
The subinterface on one ~ 13 seconds
side was shut down
Traffic Load Capacity Test
This test is intended to test the network configuration at 0% of traffic load capacity, at 50% of traffic load
capacity, and at 90% of traffic load for a period of 2 to 4 hours.
Test Plan
The procedure used to perform the traffic load capacity test follows:
Step 1
At 0% of network traffic capacity, repeat the steps for the Layer 2 Protocol and HSRP test plan, the
EIGRP with BGP routing test plan, and the routing traffic convergence test plan.
Step 2
Increase network traffic capacity to 50%.
Step 3
Repeat the steps for the layer 2 protocol and HSRP test plan, the EIGRP with BGP routing test plan, and
the routing traffic convergence test plan.
Step 4
Increase network traffic capacity to 90%.
Step 5
Repeat the steps for the layer 2 protocol and HSRP test plan, the EIGRP with BGP routing test plan, and
the routing traffic convergence test plan.
Expected Results
We expect that the network configuration will continue to work correctly at each level of traffic load
capacity.
Results
Table 62 shows the traffic load capacity test results.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
75
Test Suite 1: San Jose Campus with Data Center
Table 62
Traffic Load Capacity Test Results
Tests
Results
Traffic load capacity
Pass
System Test with EIGRP
This section describes in detail the system testing for QoS features (listed below) on the Denver campus,
using EIGRP and BGP as the routing protocols.
The following QoS features were included in this test category:
•
Classification and marking, including the following:
– Access lists
– Network-based application recognition (NBAR)
– Port numbers
– IP Precedence
– Differentiated services code point (DSCP)
•
Congestion Avoidance, including the following:
– Weighted Random Early Detection (WRED)
•
Congestion management, including the following:
– Class-based weighted fair queueing (CBWFQ)
– Distributed CBWFQ (dCBWFQ)
– Low latency queueing (LLQ)
– Distributed LLQ (dLLQ)
•
Traffic conditioning, including the following:
– Generic Traffic Shaping (GTS)
– Distributed Traffic Shaping (dTS)
•
Link efficiency mechanisms, including the following:
– Multilink PPP (MLPPP) interleaving
In addition to those features listed above, the following additional features were configured in this test
category:
•
BGP 4
•
Priority queueing (PQ)
•
ATM VC scaling
•
Frame Relay-to-ATM Service Interworking (FRF.8)
•
H.323/H.320 Gateway
•
Hot Standby Router Protocol (HSRP)
•
PPP over Frame Relay
•
VoIP
The objectives of this test category included the following:
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
76
Test Suite Overview
•
To verify that the QoS features can be incorporated into the Denver campus.
•
To verify the successful operation of the Cisco IOS release.
•
To ensure that the system behaves as expected.
•
To collect the network baseline information and provide the necessary test results.
In the test category, the following individual tests were conducted:
•
Voice gateway test
•
Voice traffic verification test
•
Voice and data traffic verification test
•
QoS setup test
•
QoS verification test
Voice Gateway Test
The voice gateway test verified that the remote gateways and gatekeeper were configured correctly and
functioning as expected for handling the voice traffic on the network.
Test Plan
The procedure used to perform the voice gateway test follows:
Step 1
Configure the egden-3640-v1 router as a voice gateway.
Step 2
Using the Cisco IOS show gateway command, verify that this gateway, egden-3640-v1, is registered
with the gatekeeper, the egsj-3640-gk router, in the San Jose with data center campus.
Step 3
Configure the Bulk Call Traffic Generator (BCG) to generate traffic.
Expected Results
We expect that the voice gateway is configured as anticipated, is registered correctly, and is functioning
properly.
Results
Table 63 shows the voice gateway test results.
Table 63
Voice Gateway Test Results
Tests
Results
Voice gateway
Pass
Voice Traffic Verification Test
This test verified that incoming and outgoing voice traffic was handled properly on the network. In this
test plan, no QoS features were configured and the network was free from traffic congestion.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
77
Test Suite 1: San Jose Campus with Data Center
Test Plan
The procedure used to perform the voice traffic verification test follows:
Step 1
Step 2
Start the bulk call traffic generator by completing the following steps:
a.
Start a BCG channel to San Jose (3 calls), Phoenix (8 calls), Dallas (3 calls), Colorado Springs
(1 call) and to New Orleans (1 call).
b.
Verify that all BCG channels are functioning correctly. To this by using the show channel command
for 5 minutes.
Analyze the output of the Cisco IOS show commands listed in Table 64. The show processes cpu
command was used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1
hour.
Table 64
show Commands Used for the Voice Traffic Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Displays the current time.
show memory summary
•
Verifies that there are no memory leaks.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
The show commands listed in Table 64 were used on the distribution layer switches and interfaces listed
in Table 65.
Table 65
Step 3
Denver Distribution Layer Switches and Interfaces
Router
Interface
egden-6506-d1
g3/7, g3/9, g3/11
egden-6506-d2
g3/7, g3/9, g3/11
Analyze the output of the Cisco IOS show commands listed in Table 66. The show processes cpu
command was used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1
hour.
Table 66
show Commands Used for the Voice Traffic Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Displays the current time.
show memory summary
•
Verifies that there are no memory leaks.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
78
Test Suite Overview
Table 66
show Commands Used for the Voice Traffic Verification Test
Command
Purpose
show interfaces [interface type]
•
Verifies the link speed and drop rate. If there is
traffic shaping configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show ppp multilink
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
The show commands listed in Table 66 were used on the WAN routers and interfaces listed in Table 67.
Table 67
Step 4
Step 5
Denver WAN Routers and Interfaces
Router
Interface
egden-7206-w1
ATM4/0
egden-7206-w2
HSSI3/0
egden-7206-w3
ATM5/0/0.127, ATM5/0/0.128, s3/0:0
egden-7507-w4
ATM5/1/0.128, ATM5/1/0.384, s5/0/0:0
Capture voice quality information by completing the following steps:
a.
Verify that the BCG channel statistics to San Jose (3 calls), Phoenix (8 calls), Colorado Springs
(1 call), and to New Orleans (1 call) are functioning correctly by using the show channel command.
b.
Use CIC to measure the call attempts/accepts and path confirmation for the end users between
Denver and San Jose, and between Denver and Phoenix.
Stop bulk call traffic generators and verify results by completing the following steps:
a.
Stop BCG calls after 1 hour of run time.
b.
Verify that all BCG channels are functioning correctly by using the show channel command for
5 minutes.
Expected Results
We expect that voice traffic will be transmitted efficiently and that all voice channels originate and
terminate properly.
Results
Table 68 shows the voice traffic verification test results.
Table 68
Voice Traffic Verification Test Results
Test Conducted
Pass/Fail
Voice Traffic Verification Test
Pass
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
79
Test Suite 1: San Jose Campus with Data Center
Voice and Data Traffic Verification Test
This test plan verified that incoming and outgoing voice and data traffic was handled properly on the
network. In this test, no QoS features were configured and the network was experiencing traffic
congestion.
Test Plan
Before conducting this test plan, we verified that data generators, and the BCG were configured. In this
test, no QoS features were configured and the network was experiencing traffic congestion.
The procedure used to perform the voice and data traffic verification test follows:
Step 1
Start the BCG, and the Chariot and IXIA traffic testing tools to congest the network.
Step 2
Analyze the output of the Cisco IOS show commands listed in Table 69. The show processes cpu
command was used every 30 seconds. The other commands were used every 5 minutes for 1 hour.
Table 69
show Commands Used for Voice and Data Traffic Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Displays the current time.
show memory summary
•
Verifies that there are no memory leaks.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
The show commands listed in Table 69 were used on the distribution layer switches and interfaces listed
in Table 70.
Table 70
Step 3
Denver Distribution Layer Switches and Interfaces
Router
Interface
egden-6506-d1
g3/7, g3/9, g3/11
egden-6506-d2
g3/7, g3/9, g3/11
Analyze the output of the Cisco IOS show commands listed in Table 71. The show processes cpu
command was used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1
hour.
Table 71
show Commands Used for the Voice and Data Traffic Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Displays the current time.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
80
Test Suite Overview
Table 71
show Commands Used for the Voice and Data Traffic Verification Test
Command
Purpose
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show memory summary
•
Verifies that there are no memory leaks.
show ppp multilink
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
The show commands listed Table 71 were used on the WAN routers and interfaces listed in Table 72.
Table 72
Step 4
Step 5
Denver WAN Routers and Interfaces
Router
Interface
egden-7206-w1
ATM4/0
egden-7206-w2
HSSI3/0
egden-7206-w3
ATM5/0/0.127, ATM5/0/0.128, s3/0:0
egden-7507-w4
ATM5/1/0.128, ATM5/1/0.384, s5/0/0:0
Capture voice quality information by completing the following steps:
a.
Verify that the BCG channel to San Jose (3 calls), Phoenix (8 calls), Colorado Springs (1 call), and
to New Orleans (1 call) are functioning correctly. Do this by using the show channel command.
b.
Use CIC to measure the call attempts/accepts and path confirmation for the end users between
Denver and San Jose, and between Denver and Phoenix.
Capture the data statistics from the DART, and Chariot testing tools, and the BCG after 1 hour.
Expected Results
We expect that voice and data traffic will be transmitted efficiently and that all voice and data channels
originate and terminate properly.
Results
Table 73 shows the voice and data traffic verification test results.
Table 73
Voice and Data Traffic Verification Test Results
Tests
Results
Voice and data traffic
Pass
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
81
Test Suite 1: San Jose Campus with Data Center
QoS Setup Test
The test verified that QoS features were configured correctly and that the QoS features were applied to
traffic classes as anticipated. In this test, the Modular Quality of Service Command-Line Interface
(MQC) three-step model was used to configure the traffic classes, class maps, and policy maps.
Test Plan
The procedure used to perform the QoS setup test follows:
Step 1
Step 2
Step 3
Define the access lists and traffic classes following the guidelines listed below.
•
Voice traffic is classified into a class-map called “Real-Time.”
•
Applications with small or infrequently sent packets such as Telnet, Citrix, and voice signaling are
classified into a class-map called “Interactive.”
•
Classify the mission-critical traffic or traffic that can consume large amounts of bandwidth into a
class-map called “Transactional.”
•
NetMeeting traffic is classified into the “Interactive-Video” class.
•
The “Control” class is configured for routing traffic.
•
HTTP and FTP traffic is classified into the “class-default” class.
Associate the policy maps and actions with each class of traffic by completing the following steps:
a.
Configure a policy map called IN-LAN on all distribution layer switches. This configuration tests
the access lists, port numbers, IP Precedences, and DSCP Qos features.
b.
Configure a policy map called IN-NBAR on all WAN routers. This configuration tests the NBAR
and DSCP QoS features.
c.
Configure a policy map called OUT-bound-[interface name] on the Cisco 7200 WAN routers with
link speeds of 768 K and below. This configuration tests the CBWFQ, LLQ, GTS, and MLP
Interleaving QoS features.
d.
Configure a policy map called OUT-bound-[interface name] on the Cisco 7500 router, and all Cisco
7200 WAN routers with T1 links and above. This configuration tests the CBWFQ, dCBWFQ, LLQ,
dLLQ, WRED, GTS, and dTS QoS features.
e.
Configure a policy map called OUT-Voice on the egden-3640-v1 router. This configuration tests the
access lists, port numbers, and DSCP QoS features.
Attach policy maps to the interfaces listed in Table 74.
Table 74 shows the router name, the policy map created, and the interface to which the policy map was
attached (applied). In some instances, instead of attaching a policy map to the interface, a specific feature
is applied.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
82
Test Suite Overview
Table 74
Routers, Policy Maps, and Interfaces for the QoS Setup Test
Router
Policy Map or Feature
Interface
egden-6506-d1
IN-LAN
g3/7, g3/9, g3/11
egden-6506-d2
IN-LAN
g3/7, g3/9, g3/11
egden-7206-w1
IN-NBAR
fa1/0, fa3/0, g2/0
egden-7206-w1
OUT-bound-10M
ATM4/0
egden-7206-w2
IN-NBAR
fa0/0, fa1/0, fa4/0, g2/0
egden-7206-w2
OUT-bound-10M
HSSI3/0
egden-7206-w3
IN-NBAR
fa0/0, fa1/0, g2/0
egden-7206-w3
OUT-bound-128
Virtual-Template20
egden-7206-w3
OUT-bound-T1
s3/0:0
egden-7206-w3
Apply the MLP Interleaving feature
—
egden-7507-w4
IN-NBAR
fa4/1/0, g0/0/0, g1/0/0
egden-7507-w4
OUT-bound-128
Virtual-Template20
egden-7507-w4
OUT-bound-384
Virtual-Template20
egden-7507-w4
OUT-bound-dT1
s5/0/0:0
egden-7507-w4
Apply the MLP Interleaving feature
Expected Results
We expect that the following results:
•
Access lists and traffic classes are correctly defined.
•
Policy maps and actions have been correctly associated.
•
Policy maps are attached to the appropriate interfaces.
•
QoS features have been configured and are functioning properly.
Results
Table 75 shows the QoS setup test results.
Table 75
QoS Setup Test Results
Tests
Results
QoS setup
Pass
QoS Verification Test
This test plan verified that incoming and outgoing voice and data traffic was handled properly on the
network, and that various QoS features (such as traffic shaping and QoS policy maps) were functioning
correctly. In this test, both voice and data traffic were used, QoS features were configured, and the
network was experiencing traffic congestion.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
83
Test Suite 1: San Jose Campus with Data Center
Test Plan
The procedure used to perform the QoS verification test follows:
Step 1
Start the BCG and the Chariot, and IXIA traffic testing tools to congest the network.
Step 2
Analyze the output of the Cisco IOS show commands listed in Table 76. The show processes cpu
command was used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1
hour.
Table 76
show Commands Used for the QoS Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Displays the current time.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show policy-map interface [interface name]
•
Verifies that voice traffic and data traffic get the
percentage of bandwidth assigned in the policy
maps.
show memory summary
•
Verifies that there are no memory leaks.
The show commands listed in Table 76 were used on the distribution layer switches and interfaces listed
in Table 77.
Table 77
Step 3
Denver Distribution Layer Switches and Interfaces
Router
Interface
egden-6506-d1
g3/7, g3/9, g3/11
egden-6506-d2
g3/7, g3/9, g3/11
Analyze the output of the Cisco IOS show commands listed in Table 78. The show processes cpu
command was used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1
hour.
Table 78
show Commands Used for the QoS Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Displays the current time.
show policy-map interface [interface name]
•
Verifies that voice traffic in the Real-Time class
has the correct percentage of the link
bandwidth.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
84
Test Suite Overview
Table 78
show Commands Used for the QoS Verification Test
Command
Purpose
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show memory summary
•
Verifies that there are no memory leaks.
show traffic-shape statistics
•
Verifies that traffic shaping is enabled.
show ppp multilink
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
The show commands listed in Table 78 were used on the WAN routers and interfaces listed in Table 79.
Table 79
Step 4
Step 5
Denver WAN Routers and Interfaces
Router
Interface
egden-7206-w1
ATM4/0
egden-7206-w2
HSSI3/0
egden-7206-w3
ATM5/0/0.127, ATM5/0/0.128, s3/0:0
egden-7507-w4
ATM5/1/0.128, ATM5/1/0.384, s5/0/0:0
Capture voice quality information by completing the following steps:
a.
Verify that the BCG channel to San Jose (3 calls), Phoenix (8 calls), Colorado Springs (1 call), and
to New Orleans (1 call) are functioning correctly. Do this by using the show channel command on
the Callgen testing tool.
b.
Use Chariot and Callgen to measure the call attempts/accepts and path confirmation for the end users
between Denver and San Jose, and between Denver and Phoenix.
Analyze the output of the Cisco IOS show commands listed in Table 80. These commands were used on
all the WAN routers and distribution layer switches.
Table 80
show Commands Used for the QoS Verification Test
Command
Step 6
Purpose
show class-map
•
Displays the configured class-map configured
for the device.
show policy-map
•
Displays the policy-map configured for the
device.
show access-lists verify
•
Verifies that the configured access lists have the
correct amount of matching packets.
Capture the data statistics from the Chariot testing tools, and the BCG after the 1-hour test referred to in
Step 3 is completed.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
85
Test Suite 1: San Jose Campus with Data Center
Expected Results
We expect the following results:
•
Access lists and traffic classes are correctly defined.
•
Traffic shaping has been enabled and is functioning correctly.
•
Class maps have been correctly configured.
•
Policy maps and actions have been correctly associated.
•
Policy maps are attached to the appropriate interfaces.
•
Voice and data traffic are assigned the proper amount of bandwidth in the policy maps.
Results
Table 81 shows the QoS verification test results.
Table 81
QoS Verification Test Results
Tests
Results
QoS verification
Pass
Reliability Test with EIGRP
This section describes in detail the reliability test as it pertained to the Denver campus, using EIGRP as
the routing protocol. The reliability test was run continuously for 150 hours, with basic IP routing and
switching enabled, and all QoS features configured.
The following additional features were configured in this test category:
•
BGP 4
•
CBWFQ
•
PQ
•
MLPPP performance enhancements
•
ATM VC scaling
•
Frame Relay-to-ATM Service Interworking (FRF.8)
•
GTS
•
H.323/H.320 Gateway
•
HSRP
•
IEEE 802.1Q VLAN Support
•
IP
•
LLQ
•
PPP over Frame Relay
•
VoIP
•
WRED
The objective of this test category was to ensure that the software (at 100% traffic load capacity on each
WAN link) performs reliably for the 150-hour test period.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
86
Test Suite Overview
Test Plan
The procedure used to perform the reliability test with EIGRP test follows:
Step 1
Step 2
Start traffic streams by completing the following steps:
a.
Start the BCG to generate traffic.
b.
Start Chariot to simulate NetMeeting, Telnet, Citrix, FTP, and HTTP traffic.
c.
Start IXIA.
d.
Start LNE to simulate EIGRP routes.
Analyze the output of the Cisco IOS show commands listed in Table 82. These commands were used at
each router every hour for a 150-hour test period.
Table 82
show Commands Used for the Reliability Test with EIGRP Test
Command
Purpose
show clock
•
Displays the current time.
show ip route summary
•
Verifies the basic routing.
show interfaces
•
Verifies the link speed. If traffic shaping is
configured on the interface, the output rate
should not exceed the shaped rate. The
exceeding traffic will be dropped.
show policy-map interface [interface name]
•
Verifies that voice traffic in the Real-Time class
has the correct percentage of the link
bandwidth.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
show traffic-shape statistics
•
Verifies that traffic shaping is enabled.
show voice call summary
•
Verifies the call status for the voice calls placed
by the BCG.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface was configured by the
virtual-template number.
show ppp multilink [interface type]
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
Expected Results
We expect that the software (at 100% traffic load capacity on each WAN link) performs reliably during
the 150-hour test period.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
87
Test Suite 1: San Jose Campus with Data Center
Results
Table 83 shows the reliability test with EIGRP test results.
Table 83
Reliability Test with EIGRP Test Results
Tests
Results
Reliability test with EIGRP
Pass
Test Suite 4: Boston Campus
This test suite consisted of three test cases intended to verify the reliability and performance of basic IP
and quality of service (QoS) at the Boston campus.
The Boston campus is one component of the larger global enterprise topology. The global enterprise
topology consists of five multilayer-design campuses — two large campuses with data centers, and three
regional campuses — and nine remote sites. For more information about the global enterprise topology,
see the “Global Enterprise Topology” section in this document.
In the test suite for the Boston campus, the following categories (or types) of testing were conducted:
•
Basic IP testing
This test category verified the reliability and performance of basic IP functionality, using Enhanced
Interior Gateway Routing Protocol (EIGRP) and Border Gateway Protocol (BGP) as the routing
protocols.
•
System testing
This test category verified system performance for a number of QoS features, using EIGRP and BGP
as the routing protocols.
•
Reliability testing
This test category verified system reliability, using EIGRP as the routing protocol.
This test suite contains the following sections:
•
Topology Description, page 88
•
Basic IP Test with EIGRP, page 91
•
System Test with EIGRP, page 98
•
Reliability Test with EIGRP, page 106
Topology Description
The Boston campus topology represents a small enterprise campus located in a region of North America.
The WAN routers that connect to the other global enterprise sites and to the Internet consist of three
Cisco 7206 VXR Network Processor Engine (NPE400) WAN routers, running serial PPP and ATM links.
The campus also consists of a Gigabit Ethernet (GE) and a Fast Ethernet (FE) LAN. There are two
Catalyst 6506 routers, each with a Multilayer Switch Feature (MSFC2) card and a Policy Feature (PFC2)
card in the core. These two Catalyst 6506 routers provide the distribution layer functionality.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
88
Test Suite Overview
One Catalyst 6506 router and two Catalyst 4006 routers make up the access layer. A Cisco 2651 router
is used as a Voice over IP (VoIP) voice gateway. This gateway registers into a gatekeeper located at the
San Jose campus. This gateway places VoIP calls to the other gateways located at different campuses in
the topology.
See Figure 9 on page 13 for the topology used for handling voice traffic.
EIGRP is the IP interior gateway protocol (IGP) routing protocol, and approximately 160 routes will be
used at various points in the topology. Global application servers are located at this campus, serving the
smaller and remote campuses.
Applications such as Voice, NetMeeting, FTP, HTTP, Simple Network Management Protocol (SNMP)
are simulated by traffic generating test tools. The testbed simulates traffic through the use of traffic
generators and PC (UNIX) stations.
Figure 17 shows the Boston campus topology at a high level and includes the IP addresses for the routers.
Boston Campus Topology with IP Addresses
Submask:
Loopback, 32 bits
P2P, 30 bits
PC, 24 bits
ebgos-7206-w1
221.10.1/32
San Jose
.26
Building 1
address range:
1.16.0.0/19
1.17.0.0/19
1.18.0.0/19
221.10.8.0/21
.9
96.1.0.24
.1 .5
Washington, D.C.
.30 .2
ISP 3
.69
.13
96.1.0.68
.17
ebgos-7206-w2 .21
221.10.0.2/32
221.10.1.12
bos-pc2
1.18.0.100
.26
.33
221.10.1.14
ebgos-4006-a2
221.10.1.16
.22
.6
.5
1.231.240.4
.29
.1
bos-pc2
221.10.8.100
.34
.18
.25
ATM/FR
221.10.1.32
221.10.1.24
ISDN BRI
221.10.1.28
ebgos-7206-w3
221.10.0.3/32
bos-pc3
1.16.1.100
.30
ebgos-6506-c2
221.10.0.6/32
1.231.240.0
Pittsburgh
bos-pc1
1.17.0.100
.14
221.10.1.20
ebgos-2651-v1
New York 221.10.0.4/32
128
ebgos-6506-a1
ebgos-6506-c1
221.10.0.5/32
.10
221.10.1.8
221.10.1.0
96.1.0.28
bos-pc1
1.16.0.100
ebgos-4006-a3
T1 (P2P)
T3
GE
FE
76330
Figure 17
bos-pc3
1.17.1.100
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
89
Test Suite 1: San Jose Campus with Data Center
Figure 18 shows the Boston campus topology at a more detailed level, and includes the interface types.
Figure 18
Boston Campus Topology with Interface Types
bos-pc1
Enterprise Global Boston
ebgos-7206-w1
s4/0
San Jose
g2/0
fa1/0
fa3/0
Washinton, D.C.
s3/0
fa0/0
s6/0:0
ISP 3
ebgos-6506-a1
fa1/0
g3/5
fa4/0
g1/1
fa3/16
bos-ux1
g1/2
g3/13
fa4/14
g2/0
ebgos-7206-w2
fa3/14
ebgos-6506-c1
g3/3
g3/11
g3/1
bos-pc2
g3/15
ebgos-4006-a2
fa1/0
fa5/14
g1/1
g1/2
fa5/16
ebgos-2651-v1
New York
128
fa4/14
ISDN BRI
ATM/FR
g3/3
g2/0
s3/0:0
fa4/16
fa1/0
a4/0
bos-ux2
g3/1 g3/11
bos-pc3
g3/13
g1/1
g3/15
fa2/14
g1/2
ebgos-7206-w3
fa2/16
ebgos-6506-c2
ebgos-4006-a3
T1 (P2P)
T3
GE
FE
bos-ux3
76329
Pittsburgh
Platform and Software Version
Table 84 lists the platforms, router names, software versions, and software images configured in the
network topology for this test suite.
Table 84
Platform, Router Name, Software Version, and Software Image Table
Platform
Router Name
Software Version
Software Image
Cisco 7206
egbos-7206-w1
12.2(12)
C7200-A3JS-M
Cisco 7206
egbos-7206-w2
12.2(12)
C7200-A3JS-M
Cisco 7206
egbos-7206-w3
12.2(12)
C7200-A3JS-M
Cisco 2651
egbos-2651-v1
12.2(12)
C2600-A3JS-M
Catalyst 6500
egbos-6506-c1
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 6500
egbos-6506-c2
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 6500
egbos-6506-a1
6.3(6)
NmpSW
Catalyst 4000
egbos-4006-a2
7.2(1)
NmpSW
Catalyst 4000
egbos-4006-a3
7.2(1)
NmpSW
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
90
Test Suite Overview
Basic IP Test with EIGRP
This is a basic IP functionality test for the Boston campus. The test category verified basic IP
functionality, the layer 2 protocols such as STP and VLAN trunking, and layer 3 protocols, such as
HSRP and EIGRP (for interior routing), and BGP (for exterior routing). Along with basic IP, the
following additional features were configured:
•
BGP 4
•
IEEE 802.1Q VLAN Support
The objectives of this test category included the following:
•
To verify that the software can be loaded and used in the devices successfully.
•
To verify that the network operation (that is, the network connectivity) is working correctly.
•
To verify that the major IP routing features work as expected.
•
To collect the network baseline information and provide the necessary test results.
In this test category, the following individual tests were conducted:
•
Layer 2 protocols and HSRP test
•
EIGRP with BGP routing test
•
Traffic routing convergence test
•
Traffic load capacity test
Layer 2 Protocols and HSRP Test
This test involves testing various layer 2 protocols, virtual local-area networks (VLANs), VLAN
trunking, and HSRP. The following features were included in the test plan:
•
VLAN Trunking Protocol (VTP) and VLAN
•
VLAN Trunking
•
HSRP
Test Plan
The procedure used to perform the layer 2 protocols and HSRP test follows:
Step 1
Use the CatOS show vlan command, the CatOS show vtp domain command, and the CatOS
show vtp status command to verify the VTP and VLAN configuration.
Step 2
Use the Cisco native IOS show interface trunk command and the CatOS show trunk command to
verify that the VLAN Trunkings are formed correctly.
Step 3
Set up HSRP. Use the Cisco IOS show standby brief command to verify that each distribution switch
is the active HSRP router for half of the VLANs (either the even-numbered VLANs or the odd-numbered
VLANs).
Step 4
Conduct negative test of HSRP. To do this, shut down or disconnect the uplink from the egbos-6506-a1
router to the egbos-6506-c1. Use the show standby brief command to verify that the HSRP active group
fails over to the egbos-6506-c2 router. Recover the uplink to verify that the HSRP active group switches
back on.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
91
Test Suite 1: San Jose Campus with Data Center
Expected Results
We expect the following results:
•
The VTP and VLAN configuration will work correctly.
•
Each distribution switch is an active HSRP route for half of the VLANs (either the even-numbered
VLANs or the odd-numbered VLANs).
•
During negative testing HSRP, the HSRP secondary router takes over the active state for all VLANs.
•
The HSRP active group switches back correctly.
Results
Table 85 shows the layer 2 protocols and HSRP test results.
Table 85
Layer 2 Protocols and HSRP Test Results
Tests
Results
Layer 2 protocols and HSRP
Pass
EIGRP with BGP Routing Test
This test involves testing EIGRP with BGP routing. The following features were included in the test
plan:
•
Route summarization, filtering, and redistribution
•
BGP policy control (specifically, autonomous system (AS) prepend and route filtering)
•
EIGRP metric tuning
Test Plan
This test verified route summarization, route filtering, route redistribution, BGP policy control, and
EIGRP metric tuning. There were several parts to this test plan, described in the sections that follow.
Route Summarization, Filtering, and Redistribution Test
The procedure used to perform the route summarization, filtering, and redistribution test follows:
Step 1
Configure the WAN routers, the egbos-7206-w1 router and the egbos-7206-w2 router, to summarize the
end user networks within the building to /20 and /21 prefixes. Summarize the campus device
interconnectivity and loopback routes into one /21 route. These summarizations are done on the WAN
links connected to the remote sites.
Step 2
Configure the WAN regional aggregation router, the egbos-7206-w3 router, to summarize the end user
networks in the building to /20 and /21 prefixes. Summarize the campus device interconnectivity and
loopback routes into one /21 route. These summarizations are done on the WAN links connected to the
remote sites.
Step 3
Configure the WAN regional aggregation router, the egbos-7206-w3 router, to summarize routes to the
remote sites to one /21 route for each remote site, and apply statements to the LAN interfaces of the
egbos-7206-w3 router.
Step 4
Turn off EIGRP auto-summary on all EIGRP-enabled routers.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
92
Test Suite Overview
Step 5
Configure a distribution list on the WAN aggregation router egbos-7206-w3 to allow only local
summarized routes and default routes to be advertised out to the remote sites.
Step 6
Configure the voice router to be a stub router.
BGP Policy Control Test
The procedure used to perform the BGP policy control test follows:
Step 1
Configure BGP and EIGRP routing on the WAN access router, egbos-7206-w2.
Step 2
Redistribute BGP into EIGRP and permit only the default route to be redistributed into EIGRP. This
default route will be sent to the whole EIGRP AS, including the remote sites.
Step 3
Configure the eigrp log-neighbor-changes command under the eigrp 1 router on all the WAN routers.
Step 4
Configure BGP policy on the egbos-7206-w2 router so that the traffic destined to its local prefixes will
go into the correct AS, using the closest Internet connection via the prepending AS number.
EIGRP Metric Tuning Test
The procedure used to perform the EIGRP metric tuning test follows:
Step 1
On the egbos-7206-w1 router, change the bandwidth of the Serial4/0 interface to 10 Mbps.
Step 2
On the egbos-7206-w2 router, change the bandwidth of the Serial3/0 interface to 10 Mbps.
Step 3
On the egbos-7206-w3 router, change the bandwidth of the ATM4/0.768 interface to 768 Kbps.
Step 4
Adjust the bandwidth command to match the QoS bandwidth settings.
Step 5
Configure the no peer neighbor-route command on all back-to-back WAN links.
Step 6
Analyze the output of the show commands listed in Table 86.
Table 86 lists each Cisco IOS command and the role it plays in verifying the EIGRP with BGP routing
setup.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
93
Test Suite 1: San Jose Campus with Data Center
Table 86
Commands Used in the EIGRP with BGP Routing Test
Command
show ip route
Purpose
•
Verifies that the routes are summarized as
expected.
•
Verifies that the route filters work as expected.
•
Verifies that the closest path to ISP3 is used for
the traffic from or destined to the campus.
•
Verifies that there are no memory leaks and
other memory errors.
•
Verifies the CPU utilization; verifies that CPU
capacity is not being monopolized by a single
router.
show logging
•
Verifies that there are no significant errors for
EIGRP routing.
show interfaces [interface type]
•
Verifies if there are any input errors, output
errors, or queue drops.
•
Verifies the router's throughput.
show ip eigrp neighbors detail
•
Verifies that the router is EIGRP stub enabled.
show ip route
•
Verifies the symmetric routing for the building
end-user networks.
show ip bgp
•
Verifies BGP route filtering.
and
•
Verifies the network connectivity to ISP3.
show ip route
•
Verifies BGP AS prepending policy control on
the ISP routers.
and
show ip route summary
show memory summary
and
show processes cpu
and
ping
Expected Results
We expect the following results:
•
The routes are summarized correctly.
•
The route filters function correctly.
•
The distribution layer routers are EIGRP stub-enabled.
•
The default route is generated correctly.
•
The BGP AS prepending policy control is enabled on the ISP routers.
•
There are no EIGRP routing errors and that the link delay and bandwidth have been tuned correctly.
•
BGP route filtering functions correctly.
•
The EIGRP neighbor was not created between two distribution layer routers.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
94
Test Suite Overview
•
The routing table displays the appropriate routes.
Results
Table 87 shows the EIGRP with BGP routing test results.
Table 87
EIGRP with BGP Routing Test Results
Tests
Results
EIGRP with BGP routing
Pass
Traffic Routing Convergence Test
The following section describes the procedures for setting up traffic routing and conducting the traffic
routing convergence testing.
Test Plan
The procedure used to perform the traffic routing convergence test follows:
Step 1
Use the Cisco IOS show ip route command to verify that all simulated routes exist.
Step 2
Set up a continuous ping between two PCs located in two points in the topology. For the ping packet
size, use 512 bytes. For the ping time-out setting, use 500 milliseconds (ms).
Step 3
During the ping test, make the link-to-router connection fail as described above.
Step 4
Capture the number of ping packets lost, and derive the convergence time from the product of the total
number of packets lost and the ping time-out setting.
Step 5
After the link-to-router connection is up, create another link-to-router connection failure (if any are
link-to-router combinations are available) and repeat Step 2 and Step 3. As an example, there are four
different link-to-router connection failures for testing the New York-to-Santa Fe link, four iterations are
needed.
Expected Results
We expect that all simulated routes exist and that the link connections between two points in the topology
can be established and maintained.
Results
Table 88 shows the traffic routing convergence test results.
Table 88
Traffic Routing Convergence Test Results
Tests
Results
Traffic routing convergence
Pass
Table 89 shows the results from traffic routing convergence test 480310.0, which shows the results from
a 0% traffic load.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
95
Test Suite 1: San Jose Campus with Data Center
Table 89
Traffic Routing Convergence Test 480310.0 Results
End-to-end Traffic Path Primary Link
Failure Scenario
Within San Jose
campus
GE
Interface was shut down < 1 second
San Jose–Denver
campus
HSSI
Interface on one side
was shut down
~ 2 seconds
The physical cable was
plugged out
~ 2 seconds
Interface on one side
was shut down
~ 12 seconds
The physical cable was
plugged out
~ 4 seconds
Denver
campus–Phoenix
remote site
New York remote
site–Santa Fe remote
site
Channelized T1
FR or ATM PVC
Convergence Time
The subinterface on one ~ 12 seconds
side was shut down
Table 90 shows the results from traffic routing convergence test 480310.1, which shows the results from
a 50% traffic load.
Table 90
Traffic Routing Convergence Test 480310.1 Results
End-to-end Traffic Path Primary Link
Failure Scenario
Within San Jose
campus
GE
Interface was shut down < 1 second
San Jose–Denver
campus
HSSI
Interface on one side
was shut down
~ 2 seconds
The physical cable was
plugged out
~ 2 seconds
Interface on one side
was shut down
~ 12 seconds
The physical cable was
plugged out
~ 4 seconds
Denver
campus–Phoenix
remote site
New York remote
site–Santa Fe remote
site
Channelized T1
FR or ATM PVC
Convergence Time
The subinterface on one ~ 12 seconds
side was shut down
Table 91 shows the results from traffic routing convergence test 480310.2, which shows the results from
a 90% traffic load.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
96
Test Suite Overview
Table 91
Traffic Routing Convergence Test 480310.2 Results
End-to-end Traffic Path Primary Link
Failure Scenario
Within San Jose
campus
GE
Interface was shut down < 1 second
San Jose–Denver
campus
HSSI
Interface on one side
was shut down
~ 2 seconds
The physical cable was
plugged out
~ 2 seconds
Interface on one side
was shut down
~ 13 seconds
The physical cable was
plugged out
~ 5 seconds
Denver
campus–Phoenix
remote site
New York remote
site–Santa Fe remote
site
Channelized T1
FR or ATM PVC
Convergence Time
The subinterface on one ~ 13 seconds
side was shut down
Traffic Load Capacity Test
This test is intended to test the network configuration at 0% of traffic load capacity, at 50% of traffic load
capacity, and at 90% of traffic load for a period of 2 to 4 hours.
Test Plan
The procedure used to perform the traffic load capacity test follows:
Step 1
At 0% of network traffic capacity, repeat the steps for the layer 2 protocols and HSRP test plan and for
the EIGRP with BGP routing test plan.
Step 2
Increase network traffic capacity to 50%.
Step 3
Repeat the steps for the layer 2 protocols and HSRP test plan and the EIGRP with BGP routing test plan.
Step 4
Increase network traffic capacity to 90%.
Step 5
Repeat the steps for the layer 2 protocols and HSRP test plan and the EIGRP with BGP routing test plan.
Expected Results
We expect that the network configuration will continue to work correctly at each level of traffic load
capacity.
Results
Table 92 shows the traffic load capacity test results.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
97
Test Suite 1: San Jose Campus with Data Center
Table 92
Traffic Load Capacity Test Results
Tests
Results
Traffic load capacity
Pass
System Test with EIGRP
This section describes in detail the system testing for QoS features (listed below) on the Boston campus,
using EIGRP and BGP as the routing protocols.
The following QoS features were included in this test category:
•
Classification and marking, including the following:
– Access lists
– Network-based application recognition (NBAR)
– Port numbers
– IP Precedence
– Differentiated services code point (DSCP)
•
Congestion avoidance, including the following:
– Weighted Random Early Detection (WRED)
•
Congestion management, including the following:
– Class-based weighted fair queueing (CBWFQ)
– Low latency queueing (LLQ)
•
Traffic conditioning, including the following:
– Generic Traffic Shaping (GTS)
•
Link efficiency mechanisms, including the following:
– Multilink PPP (MLPPP) interleaving
In addition to those features listed above, the following additional features were configured in this test
category:
•
BGP 4
•
Priority queueing (PQ)
•
MLPPP performance enhancements
•
ATM VC scaling
•
Frame Relay-to-ATM Service Interworking (FRF.8)
•
Hot Standby Router Protocol (HSRP)
•
IP
•
PPP over Frame Relay
•
VoIP
The objectives of this test category included the following:
•
To verify that the QoS features can be incorporated into the Boston Campus.
•
To verify the successful operation of the Cisco IOS releases.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
98
Test Suite Overview
•
To ensure that the system behaves as expected.
•
To collect the network baseline information and provide the necessary test results.
In the test category, the following individual tests were conducted:
•
Voice gateway test
•
Voice traffic verification test
•
Voice and data traffic verification test
•
QoS setup test
•
QoS verification test
Voice Gateway Test
The voice gateway test verified that the voice gateway was configured correctly and functioning as
expected for handling the voice traffic on the network.
Test Plan
The procedure used to perform the voice gateway test follows:
Step 1
Configure the egbos-2651-v1 router as a voice gateway.
Step 2
Use the Cisco IOS show gateway command to verify that the egbos-2651-v1 router is functioning
correctly, and is registered with the gatekeeper, the egsj-3640-gk router, in the San Jose with data center
campus.
Step 3
Configure the Bulk Call Traffic Generator (BCG) to generate traffic.
Expected Results
We expect that the voice gateway is configured as anticipated, is registered correctly, and is functioning
properly.
Results
Table 93 shows the voice gateway test results.
Table 93
Voice Gateway Test Results
Tests
Results
Voice gateway
Pass
Voice Traffic Verification Test
This test verified that incoming and outgoing voice traffic was handled properly on the network. In this
test plan, no QoS features were configured and the network was free from traffic congestion.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
99
Test Suite 1: San Jose Campus with Data Center
Test Plan
The procedure used to perform the voice traffic verification test follows:
Step 1
Step 2
Start the bulk call traffic generators by completing the following steps:
a.
Start the BCG channels to San Jose (1 call), Washington D.C. (1 call), and to Pittsburgh (5 calls).
b.
Verify that the BCG channels are functioning correctly. To this by using the show channel command
for 5 minutes.
Analyze the output of the show commands listed in Table 94. The show processes cpu command was
used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1 hour.
Table 94
show Commands Used for the Voice Traffic Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Displays the current time.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show memory summary
•
Verifies that there are no memory leaks.
show ppp multilink [interface type]
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
The show commands listed in Table 94 were used on the WAN routers and interfaces listed in Table 95.
Table 95
Step 3
Step 4
Boston WAN Routers and Interfaces
Router
Interface
egbos-7206-w1
s4/0
egbos-7206-w2
s3/0
egbos-7206-w3
ATM4/0/0.768, s3/0:0
Capture voice quality information by completing the following steps:
a.
Verify that the Callgen channels to San Jose (1 call), Washington D.C. (1 call), and to Pittsburgh
(5 calls) are functioning correctly. Do this by using the show channel command of the Callgen
testing tool.
b.
Use CIC to measure the call attempts/accepts and path confirmation for the end users between
Boston and San Jose, and between Boston and Pittsburgh.
Stop bulk call traffic generators and verify results by completing the following steps:
a.
Stop the BCG after 1 hour of run time.
b.
Verify that the BCG channels are functioning correctly. Do this by using the show channel
command.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
100
Test Suite Overview
Expected Results
We expect that voice traffic will be transmitted efficiently, and that all voice channels originate and
terminate properly.
Results
Table 96 shows the voice traffic verification test results.
Table 96
Voice Traffic Verification Test Results
Tests
Results
Voice traffic verification
Pass
Voice and Data Traffic Verification Test
This test plan verified that incoming and outgoing voice and data traffic was handled properly on the
network. In this test, no QoS features were configured and the network was experiencing traffic
congestion.
Test Plan
Before conducting this test plan, we verified that all data generators and the BCG were configured. Then
the steps listed below were performed.
The procedure used to performing the voice and data traffic verification test follows:
Step 1
Start the BCG, and the Chariot, and IXIA traffic testing tools to congest the network.
Step 2
Analyze the output of the show commands listed in Table 97. The show processes cpu command was
used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1 hour.
Table 97
show Commands Used for the Voice and Data Traffic Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Displays the current time.
show policy-map interface [interface type]
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy-maps.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show memory summary
•
Verifies that there are no memory leaks.
show ppp multilink [interface type]
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
The show commands listed in Table 97 were used on the WAN routers and interfaces listed in Table 98.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
101
Test Suite 1: San Jose Campus with Data Center
Table 98
Step 3
Step 4
Boston WAN Routers and Interfaces
Router
Interface
egbos-7206-w1
s4/0
egbos-7206-w2
s3/0
egbos-7206-w3
ATM4/0/0.768, s3/0:0
Capture voice quality information by completing the following steps:
a.
Verify that the Callgen channels to San Jose (1 call), Washington D.C. (1 call), and to Pittsburgh
(5 calls) are functioning correctly. Do this by using the show channel command of the Callgen
testing tool.
b.
Use CIC to measure the call attempts/accepts and path confirmation for the end users between
Boston and San Jose, and between Boston and Pittsburgh.
Capture the data statistics from the BCG, and the DART and Chariot traffic testing tools after 1-hour test
run.
Expected Results
We expect that voice and data traffic will be transmitted efficiently and that all voice and data channels
originate and terminate properly.
Results
Table 99 shows the voice and data traffic verification test results.
Table 99
Voice and Data Traffic Verification Test Results
Tests
Results
Voice and data traffic verification
Pass
QoS Setup Test
The test verified that QoS features were configured correctly and that the QoS features were applied to
traffic classes as anticipated. In this test, the Modular Quality of Service Command-Line Interface
(MQC) three-step model was used to configure the traffic classes, class maps, and policy maps.
Test Plan
The procedure used to perform the QoS setup test follows:
Step 1
Define the access lists and traffic classes following the guidelines listed below.
•
Voice traffic is classified into a class-map called “Real-Time.”
•
Applications with small or infrequently sent packets such as Telnet, Citrix, and voice signaling are
classified into a class-map called “Interactive.”
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
102
Test Suite Overview
Step 2
Step 3
•
Classify the mission-critical traffic or traffic that can consume large amounts of bandwidth into a
class-map called “Transactional.”
•
NetMeeting traffic is classified into the “Interactive-Video” class.
•
The “Control” class is configured for routing traffic.
•
HTTP and FTP traffic is classified into the “class-default” class.
Associate the policy maps and actions with each class of traffic by completing the following steps:
a.
Configure a policy map called IN-bound on all WAN routers. This configuration tests the access
lists, NBAR, port numbers, IP Precedence, and DSCP QoS features.
b.
Configure a policy map called OUT-bound-[interface name] on the Cisco 7200 WAN routers with
links of 768K and below. This configuration tests the CBWFQ, LLQ, GTS, and MLP Interleaving
QoS features.
c.
Configure a policy map called OUT-bound-[interface name] on the 7200 WAN router with links of
T1 speed and above. This configuration tests the WRED, CBWFQ, LLQ, and GTS QoS features.
d.
Configure a policy map called OUT-Voice on the egbos-2651-v1 router. This configuration tests the
access lists, port numbers, and DSCP QoS features.
Attach policy maps to the interfaces listed in Table 100.
Table 100 shows the router name, the policy map created, and the interface to which the policy map was
applied (attached). In some instances, instead of attaching a policy map to the interface, a specific feature
is applied.
Table 100
Routers, Policy Maps, and Interfaces for the QoS Setup Test
Router
Policy Map or Feature
Interface
egbos-7206-w1
IN-bound
fa1/0, fa3/0, g2/0
egbos-7206-w1
OUT-bound-10M
s4/0
egbos-7206-w2
IN-bound
fa0/0, fa1/0, fa4/0, g2/0
egbos-7206-w2
OUT-bound-10M
s3/0
egbos-7206-w3
IN-bound
fa1/0, g2/0
egbos-7206-w3
OUT-bound-128
Virtual-Template20
egbos-7206-w3
OUT-bound-T1
s3/0:0
egbos-7206-w3
Apply the MLP Interleaving feature
—
Expected Results
We expect the following results:
•
Access lists and traffic classes are correctly defined.
•
Policy maps and actions have been correctly associated.
•
Policy maps are attached to the appropriate interfaces.
•
QoS features have been configured and are functioning properly.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
103
Test Suite 1: San Jose Campus with Data Center
Results
Table 101 shows the QoS setup test results.
Table 101
QoS Setup Test Results
Tests
Results
QoS setup
Pass
QoS Verification Test
This test plan verified that incoming and outgoing voice and data traffic was handled properly on the
network, and that various QoS features (such as traffic shaping and QoS policy maps) were functioning
correctly. In this test, both voice and data traffic were used, QoS features were configured, and the
network was experiencing traffic congestion.
Test Plan
The procedure used to perform the QoS verification test follows:
Step 1
Start the BCG, and the Chariot, and IXIA traffic testing tools to congest the network.
Step 2
Analyze the output of the Cisco IOS show commands listed in Table 102. The show processes cpu
command was used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1
hour.
Table 102
show Commands Used for the QoS Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Displays the current time.
show policy-map interface [interface type]
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy-maps.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show memory summary
•
Verifies that there are no memory leaks.
show traffic-shape statistics
•
Verifies that traffic shaping is enabled.
show ppp multilink [interface type]
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
The show commands listed in Table 102 were used on the WAN routers and interfaces listed in
Table 103.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
104
Test Suite Overview
Table 103
Step 3
Step 4
Boston WAN Routers and Interfaces
Router
Interface
egbos-7206-w1
s4/0
egbos-7206-w2
s3/0
egbos-7206-w3
ATM4/0/0.768, s3/0:0
Capture voice quality information by completing the following steps:
a.
Verify that the BCG channels to San Jose (1 call), Washington D.C. (1 call), and Pittsburgh (5 calls)
are functioning correctly. Do this by using the show channel command.
b.
Use CIC and Chariot to measure the call attempts/accepts and path confirmation for the end users
between Boston and San Jose, and between Boston and Pittsburgh.
Analyze the output of the Cisco IOS show commands listed in Table 104. after the 1-hour test referred
to in Step 2 is completed. These commands were used on all the WAN routers and core switches.
Table 104
Show Commands Used for the QoS Verification Test
Command
Step 5
Purpose
show class-map
•
Displays the configured class-map configured
for the device
show policy-map
•
Displays the policy-map configured for the
device.
Capture the data statistics from the BCG, and the DART and Chariot testing tools after the 1-hour test
referred to in Step 2 is completed.
Expected Results
We expect the following results:
•
Access lists and traffic classes are correctly defined.
•
Traffic shaping has been enabled and is functioning correctly.
•
Class maps have been correctly configured.
•
Policy maps and actions have been correctly associated.
•
Policy maps are attached to the appropriate interfaces.
•
Voice and data traffic are assigned the proper amount of bandwidth in the policy maps.
Results
Table 105 shows the QoS verification test results.
Table 105
QoS Verification Test Results
Tests
Results
QoS verification
Pass
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
105
Test Suite 1: San Jose Campus with Data Center
Reliability Test with EIGRP
This section describes the reliability test as it pertained to the Boston campus, using EIGRP as the
routing protocol. The reliability test ran continuously for 150 hours, with basic IP routing and switching
enabled, and all QoS features configured.
The following additional features were configured in this test category:
•
BGP 4
•
CBWFQ
•
PQ
•
MLPPP performance enhancements
•
ATM VC Scaling
•
Frame Relay-to-ATM Service Interworking (FRF.8)
•
GTS
•
HSRP
•
IEEE 802.1Q VLAN support
•
IP
•
LLQ
•
PPP over Frame Relay
•
VoIP
•
WRED
The objective of this test was to ensure that the software was stable and reliable in the testbed during the
150 hours test period, with 100% traffic load on each WAN link.
Test Plan
The procedure used to perform the reliability test with EIGRP follows:
Step 1
Step 2
Start traffic streams by completing the following steps:
a.
Start the BCG to generate traffic.
b.
Start Chariot to simulate NetMeeting, Telnet, Citrix, FTP, and HTTP traffic.
c.
Start IXIA.
d.
Start LNE to simulate EIGRP routes.
Analyze the output of the Cisco IOS show commands listed in Table 106. These commands were used
at each router every hour for a 150-hour test period.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
106
Test Suite Overview
Table 106
show Commands Used for the Reliability Test with EIGRP Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Displays the current time.
show interfaces
•
Verifies the link speed. If traffic shaping is
configured on the interface, the output rate
should not exceed the shaped rate. The
exceeding traffic will be dropped.
show policy-map interface [interface type]
•
Verifies that voice traffic in the Real-Time class
has the correct percentage of the link
bandwidth.
show ip route summary
•
Verifies the basic routing.
show access-list verify
•
Verifies that the configured access lists have the
correct amount of matching packets.
show memory summary
•
Verifies that there are no memory leaks.
show traffic-shape statistics
•
Verifies that traffic shaping is enabled.
show voice call summary
•
Verifies the call status for the voice calls placed
by the BCG.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface was configured by the
virtual-template number.
show ppp multilink [interface type]
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
Expected Results
We expect that the software (at 100% traffic load capacity on each WAN link) performs reliably during
the 150-hour test period.
Results
Table 107 shows the reliability test with EIGRP test results.
Table 107
Reliability Test with EIGRP Test Results
Tests
Results
Reliability test with EIGRP
Pass
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
107
Test Suite 1: San Jose Campus with Data Center
Test Suite 5: Dallas Campus
This test suite consisted of three test cases intended to verify the reliability and performance of basic IP
and Quality of Service (QoS) at the Dallas campus.
The Dallas campus with data center is one component of the larger global enterprise topology. The
global enterprise topology consists of five multilayer-design campuses — two large campuses with data
centers, and three regional campuses — and nine remote sites. For more information about the Global
Enterprise topology, see the “Global Enterprise Topology” section in this document.
In the test suite for the Dallas campus, the following categories (or types) of testing were conducted:
•
Basic IP testing
This test category verified the reliability and performance of basic IP functionality, using Enhanced
Interior Gateway Routing Protocol (EIGRP) and Border Gateway Protocol (BGP) as the routing
protocols.
•
Scalability performance testing
This test category verified the scalability for basic IP performance and QoS features at the Dallas
and Miami campuses.
•
System testing
This test category verified system performance for a number of QoS features, using EIGRP and BGP
as the routing protocols.
•
Reliability testing
This test category verifies system reliability, using EIGRP as the routing protocol.
This test suite contains the following sections:
•
Topology Description, page 108
•
Basic IP Test with EIGRP, page 112
•
Scalability Performance Test, page 118 (Miami campus only)
•
System Test with EIGRP, page 125
•
Reliability Test with EIGRP, page 134
Topology Description
The Dallas campus topology represents a medium size campus located in a region of southwestern
Unites States.
The WAN routers that connect to the other global enterprise sites and to the Internet consist of Cisco
7206 VXR Network Processor Engine (NPE400) routers and Cisco 7507 Route Switch Processor (RSP8)
routers, running ATM and PPP on the WANs.
The campus also consists of a Gigabit Ethernet (GE) and a Fast Ethernet (FE) LAN connected to two
Catalyst 6506 routers, each with a Multilayer Switch Feature (MSFC2) card and a Policy Feature (PFC2)
card. A Cisco 3640 router is used as a Voice over IP (VoIP) voice gateway. This voice gateway registers
into the gatekeeper located at the San Jose campus with data center. This gateway places real VoIP calls
to other gateways located at different campuses.
See Figure 9 on page 13 for the topology used for handling voice traffic.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
108
Test Suite Overview
EIGRP is the IP interior gateway protocol (IGP) routing protocol, and approximately 320 routes will be
used at various points in the topology. Global application servers are located at this campus, serving the
smaller and remote campuses.
Applications such as Voice, NetMeeting, FTP, HTTP, and Simple Network Management Protocol
(SNMP) are simulated by traffic generating test tools. The testbed simulates traffic through the use of
traffic generators and PC (UNIX) stations.
Figure 19 shows the Dallas campus topology at a high level and includes the IP addresses for the routers.
Dallas Campus Topology with IP Addresses
96.1.0.17/30
ATM
Provider
Enterprise WAN
ISP 3
San Jose
96.1.0.41/30
Washington, D.C.
E3
3xE1
E3
egdal-3640-v
.42
.18
egdal- 1
7206-w1
101
37
38
2
egdal7206-w2
9
WAN access
5
65
.58
42
102
41
4
17
3
25
29
Layer 3 core
66
221.5.9.100
dal-pc1
6
106
.5
46
.1
103
.1
.1
.5
egdal- .5
7206-w3
7
221.5.17.100
dal-pc2
107
dal-ux2
dal-ux1
Traffic generators
221.5.10.100
ATM/FR
Provider
1.223.248.2/30
Phoenix
1.207.248.2/30
128K Colorado
Springs
2x128K
E1
Sante Fe
Houston
1.239.248.2/30
1.239.240.2/30
1.207.248.6/30
30
34
egdal-6506-c2
egdal-6506-c1
768K
Miami
1.223.248.6/30
14
6
33
1.223.240.6/30
1.215.248.6/30
128K New Orleans
.1
104
22
26
Miami
105
45
21
18
1.223.240.2/30
5
egdal-7507-w4
13
10
96.1.0.57/30
Traffic generators
221.5.18.100
FE
GE
ATM/FR (nx64k)
E1(P2P)
E3(P2P)
ATM E3
ATM T3
X 223.255.10.X
X 221.5.1.X - Loopback
82517
Figure 19
X 1.200.8.X - Rm Loopback
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
109
Test Suite 1: San Jose Campus with Data Center
Figure 20 shows the Dallas campus topology at a more detailed level and includes the interface types.
Dallas Campus Topology with Interface Type
Enterprise WAN
ISP 3
San Jose
ATM
Provider
isp 3-7507
Washington, D.C.
E3
s3/0
a4/0
egdal- 1
7206-w1
101
f0/0
f0/0
2
egdal7206-w2
f4/0
WAN access
f1/0
g2/0
3xE1
E3
egdal-3640-v
s6/0-2
102
f0/0
5
105
f1/0
egdal-7507-w4 a0/0/0
g/1/0/0 4
g2/0
g4/1/0
f1/0
f4/1
g3/1
g3/2
Layer 3 core
g1/1
6
f4/14
106
a3/0
3
103 s6/0/0
f2/0 egdal- a4/0
7206-w3
f4/2
g1/1
f4/13
7
dal-pc2
107
f4/14
dal-ux2
dal-ux1
Traffic generators
Phoenix
128K Colorado
Springs
2x128K
E1
Miami
f4/7
egdal-6506-c2
egdal-6506-c1
Traffic generators
ATM/FR
Provider
Santa Fe
Houston
g3/1
dal-pc1
f4/13
768K
104 a0/1/0
f5/0/0a6/0/0
g3/2
f4/2
New Orleans
Miami 128K
FE
GE
ATM/FR (nx64k)
E1(P2P)
E3(P2P)
ATM E3
ATM T3
X 223.255.10.X
X 221.5.1.X - Loopback
X 1.200.8.X - Rm Loopback
82042
Figure 20
Topology for the Dallas Campus
The scalability performance test category verifies the scalability for basic IP performance and QoS
features at the Dallas and Miami campuses.
The global enterprise Miami testbed consists of a single layer performing WAN, distribution and
network access functionality. The WAN routers connecting to the other global enterprise sites and to the
Internet consist of a Cisco 7206VXR NPE400 router and a Cisco 3640 router running ATM on the
WANs. The campus also consists of GE and FE LANs, connected to two Catalyst 6506 routers, each with
an MSFC2/PFC2. The two Catalyst 6506 routers perform both layer 2 and layer 3 functions.
The QoS scalability performance test was performed on the ATM-T3 link only between the Dallas
campus (that is, using the first egdal-7206-w1 router and the second egdal-7507-w4 router) and the
egmia-7206-w1 router at the Miami campus.
Figure 21 shows the topology used for the scalability performance test.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
110
Test Suite Overview
Scalability Performance Test Topology
T1 (PTP)
ATM/FR (nx64k)
E1 (PTP)
ATM E1
T3 (PTP)
ATM T3
San Jose - HQ
Data Center
ISP3
7206
7500
Boston
7206 FE
7609
7500
7206
POS OC3
7609
Washington, D.C.
Data Center
GE
GE
7609
7609
7507
7206
ATM
OC3
ATM
Provider
ATM OC3
7500
E3
(P2P)
HSSI (P2P)
ISP1
7500
FE
.
7206
7206
Denver
7206
7507
FE
ATM E3
Dall as
7206
FE
ATM/FR
128
…
384
2651
Sante Fe
28
8
76
12
8
8
76
3640
7204
2651
Los Angeles Phoenix Colorado Springs
7206
7206
2651
New Orleans
3660
Houston
7507
1.223.232.0 /30
1.223.224.0 /30
1.223.216.0 /30
1.223.208.0 /30
1.223.200.0 /30
1.223.192.0 /30
1.223.184.0 /30
1.223.176.0 /30
1.223.168.0 /30
1.223.160.0 /30
3640
Pittsburgh
82672
Figure 21
76
8
7206 3640
Miami
3620
New York
Platform and Software Version
Table 108 lists the platforms, router names, software versions, and software images configured in the
network topology for this test suite.
Table 108
Platform, Router Name, Software Version, and Software Image Table
Platform
Router Name
Software Version
Software Image
Cisco 7206
egdal-7206-w1
12.2(12)
C7200-A3JS-M
Cisco 7206
egdal-7206-w2
12.2(12)
C7200-A3JS-M
Cisco 7206
egdal-7206-w3
12.2(12)
C7200-A3JS-M
Cisco 7507
egdal-7507-w4
12.2(12)
RSP-A3JSV-M
Cisco 3640
egdal-3640-v
12.2(12)
C3640-A3JS-M
Catalyst 6500
egdal-6506-c1
12.1(12c)E1
c6sup2_rp-JSV-M
Catalyst 6500
egdal-6506-c2
12.1(12c)E1
c6sup2_rp-JSV-M
Cisco 7206
egmia-7206-w1
12.2(12)
C7200-A3JS-M
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
111
Test Suite 1: San Jose Campus with Data Center
Basic IP Test with EIGRP
This test category verified the reliability and performance of basic IP functionality, using EIGRP and
BGP (specifically, BGP 4) as the routing protocols.
The objectives of this test category included the following:
•
To verify that the software can be loaded and used in the devices successfully.
•
To verify that the network operation (that is, the network connectivity) is working correctly.
•
To verify that the major IP routing features work as expected.
•
To collect the network baseline information and provide the necessary test results.
In this test category, the following individual tests were conducted:
•
EIGRP with BGP routing test
•
Traffic routing convergence test
•
Traffic load capacity test
EIGRP with BGP Routing Test
The following features were included in the EIGRP with BGP routing test:
•
Route summarization, filtering, and redistribution
•
BGP policy control (specifically, autonomous system (AS) prepend and route filtering)
•
EIGRP metric tuning
Test Plan
This test verified route summarization, route filtering, route redistribution, BGP policy control, and
EIGRP metric tuning. There were several parts to this test plan, described in the sections that follow.
Route Summarization, Filtering, and Redistribution Test
The procedure used to perform the route summarization, filtering, and redistribution test follows:
Step 1
Configure the WAN access routers, the egdal-7206-w1 router and the egdal-7206-w2 router, to
summarize the end user networks within the buildings using /20 and /21 prefixes. Summarize the device
interconnectivity and loopback routes into one /21 route.
Step 2
Configure the WAN regional aggregation routers, the egdal-7206-w3 router and the egdal-7507-w4
router, to summarize the end user networks within the buildings using /20 and /21 prefixes. Summarize
the device interconnectivity and loopback routes into one /21 route.
Step 3
Configure the WAN regional aggregation routers, the egdal-7206-w3 router and the egdal-7507-w4
router, to summarize routes from the remote sites to one /21 route for each remote site group and apply
summary statements to the LAN interfaces of the aggregation routers which are connected back to the
core routers.
Step 4
Configure a distribution list on the WAN routers, the egdal-7206-w3 router and the egdal-7507-w4
router, to allow local summarized routes and default route to advertise out to the remote sites only.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
112
Test Suite Overview
BGP Policy Control Test
The procedure used to perform the BGP policy control test follows:
Step 1
Configure BGP and EIGRP routing on the campus WAN access router, the egdal-7206-w2 router.
Step 2
Redistribute BGP into EIGRP, and permit only the default route to be redistributed into EIGRP. This
default route will be advertised into the whole EIGRP AS and will be permitted into remote sites.
Step 3
Configure the Cisco IOS eigrp log-neighbor-changes command under router eigrp 1 on all the WAN
routers, Cisco 7206 VXR routers, Cisco 7507 routers, and layer 3 switches.
Step 4
Configure a BGP policy on the egdal-7206-w2 router so that the traffic destined to the local prefixes will
get into the correct AS, using the closest Internet connection via prepending AS number.
EIGRP Metric Tuning Test
The procedure used to perform the EIGRP metric tuning test follows:
Step 1
On the egdal-7206-w1 router (the primary link to the San Jose campus with data center), change the
bandwidth of the a4/0 interface to 10 Mbps.
Step 2
On the egdal-7606-w1 router, change the link delay setting of the a4/0 interface from 100000 ms (usec)
to 200 usec.
Step 3
On the egdal-7206-w2 router (the primary link to the Washington D.C. campus), set the bandwidth of
the s3/0 interface to10 Mbps.
Step 4
On the egdal-7606-w2 router, change the link delay setting of the s3/0 interface from 100000 ms (usec)
to 200 usec.
Step 5
Configure the no peer neighbor-route command for the Multilink1 WAN interface on the
egdal-7206-w2 router.
Step 6
Analyze the output of the Cisco IOS show commands listed in Table 109.
Table 109 lists each command and the role it plays in the EIGRP with BGP Routing test.
Table 109
Commands Used in the EIGRP with BGP Routing Test
Command
show ip route
Purpose
•
Verifies that the routes are summarized as
expected.
•
Verifies that the route filters work as expected.
•
Fail WAN connection s3/0 on the
egdal-7206-w2 router to the Washington D.C.
campus, and verify that the traffic is rerouted via
an expected alternative path through the other
campuses and remote sites.
show ip bgp
•
Verifies BGP route filtering.
and
•
Verifies the network connectivity to ISP3.
show ip route
•
Verifies BGP AS prepending policy control on
the ISP routers.
and
show ip route summary
and
ping
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
113
Test Suite 1: San Jose Campus with Data Center
Table 109
Commands Used in the EIGRP with BGP Routing Test
Command
Purpose
show memory summary
•
Verifies that there are no memory leaks and
other memory errors.
•
Verifies the CPU utilization; verifies that CPU
capacity is not being monopolized by a single
router.
show logging
•
Verifies that there are no significant errors for
EIGRP routing.
show interfaces [interface type]
•
Verifies if there are any input errors, output
errors, or queue drops.
•
Verifies the throughput of the router.
and
show processes cpu
Expected Results
We expect the following results:
•
The routes are summarized correctly.
•
The route filters function correctly.
•
The distribution layer routers are EIGRP stub-enabled.
•
The default route is generated correctly.
•
The BGP AS prepending policy control is enabled on the ISP routers.
•
There are no EIGRP routing errors and that the link delay and bandwidth have been tuned correctly.
•
BGP route filtering functions correctly.
•
The EIGRP neighbor was not created between two distribution layer routers.
•
The routing table displays the appropriate routes.
Results
Table 110 shows the EIGRP with BGP routing test results.
Table 110
EIGRP with BGP Routing Test Results
Tests
Results
EIGRP with BGP routing
Pass
Traffic Routing Convergence Test
The following section describes the procedures for setting up traffic routing and conducting the traffic
routing convergence testing.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
114
Test Suite Overview
Test Plan
The procedure used to perform the traffic routing convergence test follows:
Step 1
Use the Cisco IOS show ip route command to verify that all simulated routes exist.
Step 2
Set up a continuous ping between two PCs located in two points in the topology. For the ping packet
size, use 512 bytes. For the ping time-out setting, use 500 milliseconds (ms).
Step 3
During the ping test, make the link-to-router connection fail as described above.
Step 4
Capture the number of ping packets lost, and derive the convergence time from the product of the total
number of packets lost and the ping time-out setting.
Step 5
After the link-to-router connection is up, created another link-to-router connection failure (if any are
link-to-router combinations are available) and repeat Step 2 and Step 3. As an example, there are four
different link-to-router connection failures for testing the New York-to-Santa Fe link, four iterations are
needed.
Expected Results
We expect that all simulated routes exist and that the link connections between two points in the topology
can be established and maintained.
Results
Table 111 shows the traffic routing convergence test results.
Table 111
Traffic Routing Convergence Test Results
Tests
Results
Traffic routing convergence
Pass
Table 112 shows the results from traffic routing convergence test 480310.0, which shows the results from
a 0% traffic load.
Table 112
Traffic Routing Convergence Test 480310.0 Results
End-to-end Traffic Path Primary Link
Failure Scenario
Convergence Time
Within San Jose
campus
GE
Interface was shut down < 1 second
San Jose–Denver
campus
HSSI
Interface on one side
was shut down
~ 2 seconds
The physical cable was
plugged out
~ 2 seconds
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
115
Test Suite 1: San Jose Campus with Data Center
Table 112
Traffic Routing Convergence Test 480310.0 Results
End-to-end Traffic Path Primary Link
Failure Scenario
Convergence Time
Denver
campus–Phoenix
remote site
Interface on one side
was shut down
~ 12 seconds
The physical cable was
plugged out
~ 4 seconds
New York remote
site–Santa Fe remote
site
Channelized T1
FR or ATM PVC
The subinterface on one ~ 12 seconds
side was shut down
Table 113 shows the results from traffic routing convergence test 480310.1, which shows the results from
a 50% traffic load.
Table 113
Traffic Routing Convergence Test 480310.1 Results
End-to-end Traffic Path Primary Link
Failure Scenario
Within San Jose
campus
GE
Interface was shut down < 1 second
San Jose–Denver
campus
HSSI
Interface on one side
was shut down
~ 2 seconds
The physical cable was
plugged out
~ 2 seconds
Interface on one side
was shut down
~ 12 seconds
The physical cable was
plugged out
~ 4 seconds
Denver
campus–Phoenix
remote site
New York remote
site–Santa Fe remote
site
Channelized T1
FR or ATM PVC
Convergence Time
The subinterface on one ~ 12 seconds
side was shut down
Table 114 shows the results from traffic routing convergence test 480310.2, which shows the results from
a 90% traffic load.
Table 114
Traffic Routing Convergence Test 480310.2 Results
End-to-end Traffic Path Primary Link
Failure Scenario
Convergence Time
Within San Jose
campus
GE
Interface was shut down < 1 second
San Jose–Denver
campus
HSSI
Interface on one side
was shut down
~ 2 seconds
The physical cable was
plugged out
~ 2 seconds
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
116
Test Suite Overview
Table 114
Traffic Routing Convergence Test 480310.2 Results
End-to-end Traffic Path Primary Link
Failure Scenario
Convergence Time
Denver
campus–Phoenix
remote site
Interface on one side
was shut down
~ 13 seconds
The physical cable was
plugged out
~ 5 seconds
New York remote
site–Santa Fe remote
site
Channelized T1
FR or ATM PVC
The subinterface on one ~ 13 seconds
side was shut down
Traffic Load Capacity Test
This test is intended to test the network configuration at 0% of traffic load capacity, at 50% of traffic load
capacity, and at 90% of traffic load for a period of 2 to 4 hours.
Test Plan
The procedure used to perform the traffic load capacity test follows:
Step 1
At 0% of network traffic capacity, repeat the steps for the EIGRP with BGP routing test plan.
Step 2
Increase network traffic capacity to 50%.
Step 3
Repeat the steps for the EIGRP with BGP routing test plan.
Step 4
Increase network traffic capacity to 90%.
Step 5
Repeat the steps for the EIGRP with BGP routing test plan.
Expected Results
We expect that the network configuration will continue to work correctly at each level of traffic load
capacity.
Results
Table 115 shows the traffic load capacity test results.
Table 115
Traffic Load Capacity Test Results
Tests
Results
Traffic load capacity
Pass
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
117
Test Suite 1: San Jose Campus with Data Center
Scalability Performance Test
This section describes in detail the scalability performance testing for QoS features at the Dallas and
Miami campuses, using EIGRP as the routing protocol.
The following QoS features were included in this test category:
•
Classification and marking, including the following:
– Access lists
– Port numbers
– IP Precedence
– Network-based application recognition (NBAR)
– Differentiated services code point (DSCP)
•
Congestion management, including the following:
– Class-based weighted fair queueing (CBWFQ)
– Distributed CBWFQ (dCBWFQ)
– Low latency queueing (LLQ)
– Distributed LLQ (dLLQ)
•
Traffic conditioning, including the following:
– Generic Traffic Shaping (GTS)
– Distributed Traffic Shaping (dTS)
– ATM shaping
In addition to those features listed above, the following features were configured in this test category:
•
Priority queueing (PQ)
•
ATM VC scaling
•
DSCP and QoS Group ID support for ATM Bundles feature
•
IP
The primary objective of this test was to observe system performance as an increasing number of
permanent virtual circuits (PVCs) (from 100 to 400, with and without QoS) were configured for use on
the network.
This test verified that packets from the critical applications were given priority over packets from
less-critical applications. That is, packets from less-critical applications were dropped first.
The secondary objective was to verify that CPU utilization remains low, given resource constraints such
as the following:
•
CPU utilization
•
Number of virtual circuits
•
Device throughput and volume
In this test category, the following individual tests were conducted:
•
Link speed test
•
Scalability performance test (at the Dallas and Miami campuses only)
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
118
Test Suite Overview
Link Speed Test
The test verified the system performance with an increasing number of PVCs configured with various
link speeds and differing amounts of bandwidth.
Test Plan
The procedure used to perform the link speed test follows:
Step 1
Step 2
Step 3
Step 4
Configure up to 100 PVCs with the following link speeds at 15 Mbps of bandwidth:
Number of PVCs
Link Speed
50
64 K
35
128 K
10
384 K
5
768 K
Configure up to 200 PVCs with the following link speeds at 30 Mbps of bandwidth:
Number of PVCs
Link Speed
100
64 K
50
128 K
40
384 K
10
768 K
Configure up to 300 PVCs with the following link speeds at 45 Mbps of bandwidth:
Number of PVCs
Link Speed
185
64 K
75
128 K
20
384 K
20
768 K
Configure up to 400 PVCs with the following link speeds at 60 Mbps bandwidth:
Number of PVCs
Link Speed
255
64 K
90
128 K
35
384 K
20
768 K
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
119
Test Suite 1: San Jose Campus with Data Center
Expected Results
We expect that the system using the increasing numbers of PVCs, configured with the varying link
speeds and bandwidths as listed above, will perform at optimal levels as expected.
Results
Table 116 shows the link speed test results.
Table 116
Link Speed Test Results
Tests
Results
Link speed
Pass
PVC Scalability Performance Test
This test verified system performance as an increasing number of permanent virtual circuits (PVCs)
(from 100 to 400, with and without QoS) were configured for use on the network. This test was
conducted between the Dallas campus and the Miami campus only.
The following tests were part of the scalability performance test:
Note
•
Scalability performance of PVCs without QoS test
•
Scalability performance of PVCs with QoS test
For this test, even-numbered IP addresses were used for the Dallas campus and odd-numbered IP
addresses were used for the Miami campus.
Scalability Performance of PVCs Without QoS Test
This test verified the system performance between the specific routers at the Dallas campus and the
egmia-7206-w1 router at the Miami campus. QoS features were not configured. There were two test
plans for this test, described in the sections that follow.
Test Plan 1
This test plan tested the PVCs on a component of the Dallas campus (specifically, the egdal-7206-w3
router) and the Miami campus (the egmia-7206-w1 router). QoS features were not configured.
The procedure used to perform Test Plan 1 of the scalability performance of PVCs without QoS test
follows:
Step 1
Shut down the atm0/0/0 interface on the egdal-7507-w4 router.
Step 2
Shut down the atm6/0 interface on the egmia-7206-w1 router.
Step 3
Configure the following WAN routers for the scalability performance test:
•
egdal-7206-w3: atm4/0
•
egmia-7206-w1: atm3/0
Step 4
Configure up to 100 PVCs as described in Step 1 of the Link Speed Test.
Step 5
Start Chariot and IXIA traffic streams to congest the T3 link.
Step 6
Verify and collect data for the 100 PVCs configured in Step 4 above.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
120
Test Suite Overview
Step 7
Analyze the output of the Cisco IOS show commands listed in Table 117. The show processes cpu
command was used every 30 seconds for 30 minutes. The other commands were used every 5 minutes
for 30 minutes.
The show commands listed in Table 117 were used on the WAN router (the egdal-7206-w3 router). These
commands were used for each iteration of 100 PVCs listed in the Link Speed Test.
Table 117
show Commands Used for the Scalability Performance of PVCs Without QoS Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show memory summary
•
Verifies that there are no memory leaks.
Step 8
Stop all traffic and clear counters.
Step 9
For the next set of 100 PVCs (as described in the Link Speed Test), repeat Step 5 through Step 8.
Test Plan 2
This test plan tested the PVCs on a component of the Dallas campus (specifically, the egdal-7507-w4
router) and the Miami campus (the egmia-7206-w1 router). QoS features were not configured.
The procedure used to perform Test Plan 2 of the scalability performance of PVCs without QoS test
follows:
Step 1
Shut down the atm0/0/0 interface on the egdal-7507-w4 router.
Step 2
Shut down the atm6/0 interface on the egmia-7206-w1 router.
Step 3
Configure the following WAN routers for the scalability performance test:
•
egdal-7507-w4: atm0/1/0
•
egmia-7206-w1: atm6/0
Step 4
Configure up to 100 PVCs as detailed in Step 1 of the Link Speed Test.
Step 5
Start Chariot and IXIA traffic streams to congest the T3 link.
Step 6
Verify and collect data for the 100 PVCs configured in Step 4 above.
Step 7
Analyze the output of the Cisco IOS show commands listed in Table 118. The show processes cpu
command was used every 30 seconds for 30 minutes. The other commands were used every 5 minutes
for 30 minutes.
The show commands listed in Table 118 were used on the WAN router (the egdal-7507-w4 router). These
commands were used for each iteration of 100 PVCs listed in the Link Speed Test.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
121
Test Suite 1: San Jose Campus with Data Center
Table 118
show Commands Used for the Scalability of PVCS Without QoS Performance Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show memory summary
•
Verifies that there are no memory leaks.
Step 8
Use Chariot to measure the call attempts/accepts and path confirmation between end users at the Dallas
campus and the Miami campus.
Step 9
Stop all traffic and clear counters.
Step 10
For the next set of 100 PVCs (as described in the Link Speed Test), repeat Step 5 through Step 9.
Expected Results
We expect that voice and data traffic will be transmitted efficiently and the system will perform at
optimal levels as expected.
Results
Table 119 shows the scalability performance of PVCs without QoS test results.
Table 119
Scalability Performance of PVCs Without QoS Test Results
Tests
Results
Scalability performance of PVCs without QoS
Pass
Scalability Performance of PVCs with QoS Test
This test verifies the system performance between the specific routers at the Dallas campus and the
egmia-7206-w1 router at the Miami campus. QoS features have been configured. There are two test plans
for this test, described in the sections that follow.
Test Plan 1
This test plan tested the PVCs on a component of the Dallas campus (specifically, the egdal-7507-w3
router) and the Miami campus (the egmia-7206-w1 router). QoS features have been configured.
The procedure used to perform Test Plan 1 of the scalability performance of PVCs with QoS test follows:
Step 1
Shut down the atm0/0/0 interface on the egdal-7507-w4 router.
Step 2
Shut down the atm6/0 interface on the egmia-7206-w1 router.
Step 3
Configure the following WAN routers for the scalability performance test:
•
egdal-7206-w3: atm4/0
•
egmia-7206-w1: atm3/0
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
122
Test Suite Overview
Step 4
Configure up to 100 PVCs as described in Step 1 of the Link Speed Test.
Step 5
Apply QoS policies to the different PVCs.
Note
The Modular Quality of Service Command-Line Interface (MQC) three-step model was used to
configure the QoS policies.
Step 6
Start Chariot and IXIA traffic streams to congest the T3 link.
Step 7
Verify and collect data for the 100 PVCs configured in Step 4 above.
Step 8
Analyze the output of the Cisco IOS show commands listed in Table 120. The show processes cpu
command was used every 30 seconds for 30 minutes. The other commands were used every 5 minutes
for 30 minutes.
The Cisco IOS show commands listed in Table 120 were used on the WAN routers, egdal-7507-w3 and
egmia-7206-w1. These commands were used for each iteration of 100 PVCs listed in the Link Speed
Test.
Table 120
show Commands Used for the Scalability Performance of PVCs with QoS Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show policy-map interface [interface type]
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy-maps.
show traffic-shape statistics
•
Verifies that traffic shaping is enabled.
show memory summary
•
Verifies that there are no memory leaks.
Step 9
Stop all traffic and clear counters.
Step 10
For the next set of 100 PVCs (as described in the Link Speed Test), repeat Step 5 through Step 9.
Test Plan 2
This test plan tests the PVCs on a component of the Dallas campus (specifically, the egdal-7507-w4
router) and the Miami campus (the egmia-7206-w1 router). QoS features have been configured.
The procedure used to perform Test Plan 2 of the scalability performance of PVCs with QoS test follows:
Step 1
Shut down the atm0/0/0 interface on the egdal-7507-w4 router.
Step 2
Shut down the atm6/0 interface on the egmia-7206-w1 router.
Step 3
Configure the following WAN routers for the scalability performance test:
•
egdal-7507-w4: atm0/1/0
•
egmia-7206-w1: atm6/0
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
123
Test Suite 1: San Jose Campus with Data Center
Step 4
Configure up to 100 PVCs as described in Step 1 of the Link Speed Test.
Step 5
Apply QoS policies to the different PVCs.
Step 6
Start IXIA traffic streams to congest the T3 link.
Step 7
Verify and collect data for the 100 PVCs configured in Step 4 above.
Step 8
Analyze the output of the Cisco IOS show commands listed in Table 121. The show processes cpu
command was used every 30 seconds for 30 minutes. The other commands were used every 5 minutes
for 30 minutes.
The show commands list in Table 121 were used on the WAN routers (the egdal-7507-w4 router and the
egmia-7206-w1 router). These commands were used for each iteration of 100 PVCs listed in the Link
Speed Test.
Table 121
show Commands Used for the Scalability Performance of PVCs with QoS Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show policy-map interface [interface type]
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy-maps.
show traffic-shape statistics
•
Verifies that traffic shaping is enabled.
show memory summary
•
Verifies that there are no memory leaks.
Step 9
Stop all traffic and clear counters.
Step 10
For the next set of 100 PVCs (as described in the Link Speed Test), repeat Step 5 through Step 9.
Expected Results
We expect the following results:
•
That voice and data traffic is transmitted efficiently.
•
The QoS features are functioning properly.
•
The system performs at optimal levels as expected.
Results
Table 122 shows the scalability performance of PVCs with QoS test results.
Table 122
Stability Performance of PVCs with QoS Test Results
Tests
Results
Scalability performance of PVCs with QoS
Pass
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
124
Test Suite Overview
System Test with EIGRP
This section describes in detail the system testing for QoS features (listed below) on the Dallas campus,
using EIGRP and BGP as the routing protocols.
The following QoS features were included in this test category:
•
Classification and marking, including the following:
– Access lists
– NBAR
– Port numbers
– IP Precedence
– DSCP
•
Congestion avoidance, including the following:
– WRED
•
Congestion management, including the following:
– CBWFQ
– dCBWFQ
– LLQ
– dLLQ
•
Traffic conditioning, including the following:
– GTS
– dTS
•
Link efficiency mechanisms, including the following:
– MLP interleaving
In addition to those features listed above, the following features were configured in this test category:
•
BGP 4
•
PQ
•
ATM VC scaling
•
Frame Relay-to-ATM Service Interworking (FRF.8)
•
IP
•
VoIP
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
125
Test Suite 1: San Jose Campus with Data Center
The objectives of this test category included the following:
•
To verify that the QoS features can be incorporated into the Dallas campus.
•
To verify the successful operation of the Cisco IOS release.
•
To ensure that the system behaves as expected.
•
To collect the network baseline information and provide the necessary test results.
In the test category, the following individual tests were conducted:
•
Voice gateway test
•
Voice traffic verification test
•
Voice and data traffic verification test
•
QoS setup test
•
QoS verification test
•
Traffic routing convergence test
Voice Gateway Test
The voice gateway test verified that the voice gateway was configured correctly and functioning as
expected for handling the voice traffic on the network.
Test Plan
The procedure used to perform the voice gateway test follows:
Step 1
Configure the egdal-3640-v router as a voice gateway.
Step 2
Use the Cisco IOS show gateway command to check that the egdal-3640-v router is functioning
correctly, and is registered with the gatekeeper, the egsj-3640-gk router, in the San Jose campus with
data center.
Step 3
Configure the Bulk Call Traffic Generator (BCG) to generate traffic.
Expected Results
We expect that the voice gateway is configured as anticipated, is registered correctly, and is functioning
properly.
Results
Table 123 shows the voice gateway test results.
Table 123
Voice Gateway Test Results
Tests
Results
Voice gateway
Pass
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
126
Test Suite Overview
Voice Traffic Verification Test
This test verified that incoming and outgoing voice traffic was handled properly on the network. In this
test plan, no QoS features were configured and the network was free from traffic congestion.
Test Plan
The procedure used to perform the voice traffic verification test follows:
Step 1
Step 2
Start the bulk call traffic generators by completing the following steps:
a.
Start the BCG channels to San Jose (1 call), Washington D.C. (3 calls), Santa Fe (1 call), and to
Houston (5 calls).
b.
Verify that all BCG channels are functioning correctly. Do this by using the call traffic generator
show channel command for 5 minutes.
Analyze the output of the Cisco IOS show commands listed in Table 124. The show processes cpu
command was used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1
hour.
Table 124
show Commands Used for the Voice Traffic Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Displays the current time.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show memory summary
•
Verifies that there are no memory leaks.
show ppp multilink [interface type]
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
The show commands listed in Table 124 were used on the WAN routers and interfaces listed in
Table 125.
Table 125
Step 3
Dallas WAN Routers and Interfaces
Router
Interface
egdal-7206-w1
ATM4/0
egdal-7206-w2
Multilink1
egdal-7206-w3
ATM3/0/0.126, ATM3/0/0.127, s6/0:0
egdal-7507-w4
ATM6/0/0.126, ATM6/0/0.127, ATM6/0/0.768, ATM 0/0/0
Capture voice quality information by completing the following steps:
a.
Verify that the BCG channels to San Jose (1 call), Washington D.C. (3 calls), Santa Fe (1 call) and
Houston (5 calls) are functioning correctly. Do this by using the show channel command.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
127
Test Suite 1: San Jose Campus with Data Center
b.
Step 4
Use Chariot or BCG to measure the call attempts/accepts and path confirmation for the end users
between Dallas and Washington D.C., and between Dallas and Santa Fe.
Stop the bulk call traffic generators and verify results by completing the following steps:
a.
Stop BCG after 1 hour of run time.
b.
Verify that all BCG channels are functioning correctly. Do this by using the show channel command
for 5 minutes.
c.
Capture BCG output statistics.
Expected Results
We expect that voice traffic will be transmitted efficiently and that all voice channels originate and
terminate properly.
Results
Table 126 shows the voice traffic verification test results.
Table 126
Voice Traffic Verification Test Results
Tests
Results
Voice traffic verification
Pass
Voice and Data Traffic Verification Test
This test plan verified that incoming and outgoing voice and data traffic was handled properly on the
network. In this test, no QoS features were configured and the network was experiencing traffic
congestion.
Test Plan
Before conducting this test plan, we verified that all data generators, and the BCG were configured. Then
the steps listed below were performed.
The procedure used to perform the voice and data traffic verification test follows:
Step 1
Start the BCG, and the Chariot traffic testing tools to congest the network.
Step 2
Analyze the output of the Cisco IOS show commands listed in Table 127. The show processes cpu
command was used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1
hour.
Table 127
show Commands Used for the Voice and Data Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization
show clock
•
Displays the current time.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
128
Test Suite Overview
Table 127
show Commands Used for the Voice and Data Verification Test
Command
Purpose
show policy-map interface [interface type]
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy-maps.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show memory summary
•
Verifies that there are no memory leaks.
show ppp multilink [interface type]
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
The show commands listed in Table 127 were used on all the WAN routers and interfaces listed in
Table 128.
Table 128
Step 3
Step 4
Dallas WAN Routers and Interfaces
Router
Interface
egdal-7206-w1
ATM4/0
egdal-7206-w2
Multilink1
egdal-7206-w3
ATM3/0/0.126, ATM3/0/0.127, s6/0:0
egdal-7507-w4
ATM6/0/0.126, ATM6/0/0.127, ATM6/0/0.768, ATM 0/0/0
Capture voice quality information by completing the following steps:
a.
Verify that the BCG channels to San Jose (1 call), Washington D.C. (3 calls), Santa Fe (1 call), and
Houston (5 calls) are functioning correctly. To this by using the show channel command.
b.
Use Chariot or BCG to measure the call attempts/accepts and path confirmation for the end users
between Dallas and Washington D.C., and between Dallas and Santa Fe.
Capture the data statistics from BCG, and the Chariot traffic testing tool after a 1-hour test run.
Expected Results
We expect that voice and data traffic will be transmitted efficiently and that all voice and data channels
originate and terminate properly.
Results
Table 129 shows the voice and data traffic verification test results.
Table 129
Voice and Data Traffic Verification Test Results
Tests
Results
Voice and data traffic
Pass
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
129
Test Suite 1: San Jose Campus with Data Center
QoS Setup Test
The test verified that QoS features were configured correctly and that the QoS features were applied to
traffic classes as anticipated. In this test, the Modular Quality of Service Command-Line Interface
(MQC) three-step model was used to configure the traffic classes, class maps, and policy maps.
Test Plan
The procedure used to perform the QoS setup test follows:
Step 1
Step 2
Step 3
Define the access lists and traffic classes following the guidelines listed below.
•
Voice traffic is classified into a class-map called “Real-Time.”
•
Applications with small or infrequently sent packets such as Telnet, Citrix, and voice signaling are
classified into a class-map called “Interactive.”
•
Classify the mission-critical traffic or traffic that can consume large amounts of bandwidth into a
class-map called “Transactional.”
•
NetMeeting traffic is classified into the “Interactive-Video” class.
•
The “Control” class is configured for routing traffic.
•
HTTP and FTP traffic is classified into the “class-default” class.
Associate the policy maps and actions with each class of traffic by completing the following steps:
a.
Configure a policy map called IN-bound on all WAN routers (that is, the egdal-7206-w1 router, the
egdal-7206-w2 router, the egdal-7206-w3 router, and the egdal-7507-w4 route). This configuration
tests the access list, NBAR, and DSCP QoS features.
b.
Configure a policy map called OUT-bound-128 on the egdal-7206-w3 router, the egdal-7507-w4
router, and any WAN routers with links of 768K and lower. This configuration tests the LLQ, dLLQ,
DTS, DSCP, NBAR, and MLP Interleaving QoS features.
c.
Configure a policy map called OUT-bound-768 on the egdal-7507-w4 router, and any WAN routers
with links of 768K and lower. This configuration tests the dLLQ, DTS, DSCP, NBAR, and MLP
Interleaving QoS features.
d.
Configure a policy map called OUT-bound-dT1 on the egdal-7206-w3 router, the egdal-7507-w4
router, and any WAN routers with links of T1 speed and higher. This configuration tests the WRED,
LLQ, dLLQ, DSCP, NBAR, dTS, and GTS QoS features.
e.
Configure a policy map called OUT-bound-10M on the egdal-7206-w1 router and any wAN routers
with links of T1 and higher. This configuration tests the WRED, LLQ DSCP, NBAR, and GTS QoS
features.
f.
Configure a policy map called OUT-Parent-10M on the egdal-7206-w2 router and any WAN router
with links of T1 and higher. This configuration tests the WRED, LLQ, DSCP, NBAR, and GTS QoS
features.
Attach the policies to the interfaces listed below, and apply the other appropriate QoS features.
Table 130 shows the router name, the policy map created, and the interface to which the policy map
should be applied (attached). In some instances, instead of attaching a policy map to the interface, a
specific feature is applied.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
130
Test Suite Overview
Table 130
Routers, Policy Maps, and Interfaces for the QoS Setup Test
Router
Policy Map or Feature
Interface
egdal-7206-w1
IN-bound
fa0/0, fa1/0, g2/0
egdal-7206-w1
OUT-bound-10M
ATM4/0
egdal-7206-w2
IN-bound
fa0/0, fa1/0, fa4/0, g2/0
egdal-7206-w2
OUT-Parent-10M
s3/0
egdal-7206-w3
IN-bound
fa0/0, fa1/0, fa2/0
egdal-7206-w3
OUT-bound-128
Virtual-Template20
egdal-7206-w3
Apply the MLPP Interleaving feature
Virtual-Template
egdal-7206-w3
OUT-bound-dT1
s6/0:0
egdal-7507-w4
IN-bound
fa5/0/0, g4/1/0, g1/0/0
egdal-7507-w4
OUT-bound-128
Virtual-Template20
egdal-7507-w4
Apply the MLP Interleaving feature
Virtual-Template
egdal-7507-w4
OUT-bound-768
Virtual-Template
egdal-7507-w4
OUT-bound-dT1
a0/0/0
Expected Results
We expect the following results:
•
Access lists and traffic classes are correctly defined.
•
Policy maps and actions have been correctly associated.
•
Policy maps are attached to the appropriate interfaces.
•
QoS features have been configured and are functioning properly.
Results
Table 131 shows the QoS setup test results.
Table 131
QoS Setup Test Results
Tests
Results
QoS setup
Pass
QoS Verification Test
This test plan verified that incoming and outgoing voice and data traffic was handled properly on the
network and that various QoS features (such as traffic shaping and QoS policy maps) were functioning
correctly. In this test, both voice and data traffic were used, QoS features were configured, and the
network was experiencing traffic congestion.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
131
Test Suite 1: San Jose Campus with Data Center
Test Plan
The procedure used to perform the QoS verification test follows:
Step 1
Start the BCG, and the Chariot, and IXIA traffic testing tools to congest the network.
Step 2
Analyze the output of the Cisco IOS show commands listed in Table 132. The show processes cpu
command was used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1
hour.
Table 132
show Commands Used for the QoS Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Displays the current time.
show policy-map interface [interface type]
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy-maps.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show memory summary
•
Verifies that there are no memory leaks.
show traffic-shape statistics
•
Verifies that traffic shaping is enabled.
show ppp multilink [interface type]
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
The show commands listed in Table 132 were used on the WAN routers and interfaces listed in
Table 133.
Table 133
Step 3
Step 4
Dallas WAN Routers and Interfaces
Router
Interface
egdal-7206-w1
ATM4/0
egdal-7206-w2
Multilink1
egdal-7206-w3
ATM3/0/0.126, ATM3/0/0.127, s6/0:0
egdal-7507-w4
ATM6/0/0.126, ATM6/0/0.127, ATM6/0/0.768, ATM 0/0/0
Capture voice quality information by completing the following steps:
a.
Verify that the BCG channels to San Jose (1 call), Washington D.C. (3 calls), Santa Fe (1 call), and
Houston (5 calls) function correctly. Do this by using the show channel command.
b.
Use Chariot to measure the call attempts/accepts and path confirmation for the end users between
Dallas and Washington D.C., and between Dallas and Santa Fe.
Analyze the output of the Cisco IOS show commands listed in Table 134 after the 1-hour test referred to
in Step 2 is completed. These command were used on all the WAN routers and core switches.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
132
Test Suite Overview
Table 134
show Commands Used for the QoS Verification Test
Command
Step 5
Purpose
show class-map
•
Displays the configured class-map configured
for the device.
show policy-map
•
Displays the policy-map configured for the
device.
show access-lists
•
Verifies that the configured access lists have the
correct amount of matching packets.
Capture the data statistics from the BCG, and the Chariot and IXIA testing tools after 1-hour test referred
to in Step 2 is completed.
Expected Results
We expect the following results:
•
Access lists and traffic classes are correctly defined.
•
Traffic shaping has been enabled and is functioning correctly.
•
Class maps have been correctly configured.
•
Policy maps and actions have been correctly associated.
•
Policy maps are attached to the appropriate interfaces.
•
Voice and data traffic are assigned the proper amount of bandwidth in the policy maps.
Results
Table 135 shows the QoS verification test results.
Table 135
QoS Verification Test Results
Tests
Results
QoS verification
Pass
Traffic Routing Convergence Test
The following section describes the procedures for setting up traffic routing and conducting the routing
convergence testing. In this test plan, both voice and data traffic were used, QoS features were
configured, and the network was experiencing traffic congestion.
Test Plan
The procedure used to perform the traffic routing convergence test follows:
Step 1
Use the Cisco IOS show ip route command to verify that all simulated routes exist.
Step 2
Set up a continuous ping between two PCs located in two points in the topology. For the ping packet
size, use 512 bytes. For the ping time-out setting, use 500 milliseconds (ms).
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
133
Test Suite 1: San Jose Campus with Data Center
Step 3
During the ping test, make the link-to-router connection fail as described above.
Step 4
Capture the number of ping packets lost, and derive the convergence time from the product of the total
number of packets lost and the ping time-out setting.
Step 5
After the link-to-router connection is up, created another link-to-router connection failure (if any are
link-to-router combinations are available) and repeat Step 2 and Step 3. As an example, there are four
different link-to-router connection failures for testing the New York-to-Santa Fe link, four iterations are
needed.
Expected Results
We expect that all simulated routes exist and that the link connections between two points in the topology
can be established and maintained.
Results
Table 136 shows the traffic routing convergence test results.
Table 136
Traffic Routing Convergence Test Results
Tests
Results
Traffic routing convergence
Pass
Reliability Test with EIGRP
This section describes the reliability test as it pertained to the Dallas campus, using EIGRP as the routing
protocol. The reliability test ran continuously for 150 hours, with basic IP routing and switching enabled,
and all QoS features configured.
The following additional features were configured in this test category:
•
BGP 4
•
CBWFQ
•
PQ
•
ATM VC scaling
•
dCBWFQ
•
dLLQ
•
WRED
•
Frame Relay-to-ATM Service Interworking (FRF.8)
•
GTS
•
IP
•
LLQ
•
VoIP
The objective of this test category was to ensure that the software (at 100% traffic load capacity on each
WAN link) performs reliably for the 150-hour test period.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
134
Test Suite Overview
Test Plan
The procedure used to perform the reliability test with EIGRP test follows:
Step 1
Step 2
Start traffic streams by completing the following steps:
a.
Start the BCG to generate traffic.
b.
Start Chariot to simulate Netmeeting, Telnet, Citrix, FTP, and HTTP traffic.
c.
Start IXIA.
d.
Start LNE to simulate EIGRP routes.
Analyze the output of the Cisco IOS show commands listed in Table 137. These commands were used
at each router every hour for a 150-hour test period.
Table 137
show Commands Used for the Reliability Test with EIGRP Test
Command
Purpose
show clock
•
Displays the current time.
show ip route summary
•
Verifies the basic routing.
show ppp multilink [interface type]
•
Verifies multilink PPP status, such as the
number of member interfaces configured per
bundled interface.
show policy-map interface [interface type]
•
Verifies that voice traffic in the Real-Time class
has the correct percentage of the link
bandwidth.
show interfaces
•
Verifies the link speed. If traffic shaping is
configured on the interface, the output rate
should not exceed the shaped rate. The
exceeding traffic will be dropped.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
show traffic-shape statistics
•
Verifies that traffic shaping is enabled.
show voice call summary
•
Verifies the call status for the voice calls placed
by the BCG.
Expected Results
We expect that the software (at 100% traffic load capacity on each WAN link) performs reliably during
the 150-hour test period.
Results
Table 138 shows the reliability test with EIGRP test results.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
135
Test Suite 1: San Jose Campus with Data Center
Table 138
Reliability Test with EIGRP Test Results
Tests
Pass/Fail
Reliability test with EIGRP
Pass
Test Suite 6: Remote Campuses
This test suite consisted of three test cases intended to verify the reliability and performance of basic IP
and quality of service (QoS) at the remote campuses. The remote campuses are located at sites in Los
Angeles, Phoenix, Colorado Springs, Santa Fe, New Orleans, Houston, Pittsburgh, Miami, and New
York.
Each remote campus is one component of the larger global enterprise topology. The global enterprise
topology consists of five multilayer-design campuses — two large campuses with data centers, and three
regional campuses — and nine remote sites. For more information about the global enterprise topology,
see the “Global Enteprise Topology” section in this document.
In the test suite for the remote sites, the following categories (or types) of testing were conducted:
•
Basic IP testing
This test category verified the reliability and performance of basic IP functionality, using Enhanced
Interior Gateway Routing Protocol (EIGRP) as the routing protocol.
•
System testing
This test category verified system performance for a number of QoS features, using EIGRP as the
routing protocol.
•
Reliability testing
This test category verified system reliability, using EIGRP as the routing protocol.
This test suite contains the following sections:
•
Topology Description, page 136
•
Basic IP Test with EIGRP, page 139
•
System Test with EIGRP, page 144
•
Reliability Test with EIGRP, page 159
Topology Description
The remote campus topology represents small campuses located at sites in Los Angeles, Phoenix,
Colorado Springs, Santa Fe, New Orleans, Houston, Pittsburgh, Miami, and New York.
Each remote campus consists of a single layer that performs the WAN, distribution, and network access
functions. The network devices are Catalyst 2950 routers, Catalyst 3550 routers, Catalyst 6506 routers,
Cisco 2651 routers, Cisco 3600 routers, and Cisco 7200 routers.
The Miami and Phoenix campuses have Gigabit Ethernet (GE) links to the WAN router. The remaining
remote campuses (Los Angeles, New York, Santa Fe, Colorado Springs, Houston, Pittsburgh, and New
Orleans) have a Fast Ethernet (FE) link to the WAN router.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
136
Test Suite Overview
Two Catalyst 6506 routers in the Miami campus, each with a Multilayer Switch Feature (MSFC2) card
and a Policy Feature (PFC2) card, perform both the layer 2 and layer 3 functions. UNIX end-stations and
PCs are used to simulate user traffic with Chariot and other test tools.
All WAN routers, with exception of the Cisco 7206 router at the Miami campus, are used as Voice over
IP (VoIP) voice gateways. These gateways register into a gatekeeper located at San Jose campus. These
gateways place VoIP calls to other gateways located at other campuses in the topology.
See Figure 9 on page 13 for the topology used for handling voice traffic.
EIGRP is the IP interior gateway protocol (IGP) routing protocol, and approximately five routes will be
used at various points in the topology. Global application servers located at the San Jose campus serve
all campuses within the entire global enterprise topology.
Applications such as Voice, NetMeeting, FTP, HTT), and Simple Network Management Protocol
(SNMP) are simulated by traffic generating test tools. The testbed simulates traffic through the use of
traffic generators and PC (UNIX) stations.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
137
Test Suite 1: San Jose Campus with Data Center
Figure 22 shows the remote campus topology.
Figure 22
Remote Campus Topology
Boston
Denver
FE
GE
ATM/FR (nx64k)
T1(P2P)
Dallas
San Jose
ATM E1
Washington, D.C.
E1(P2P)
ATM T3 (P2P)
UNIX
PC
Boston
San Jose Denver
128
T1
128
768
Dallas Washington, D.C.
T1
ATM T3
T1
EGLA-3640-VW
EGCS-2651-VW
EGNEO-2651-VW
EGPIT-3640-VW
EGMIA-7206-W1
EGMIA-3640-VW2
EGLA-3550-A
EGCS-2950-A
EGNEO-2950-A
EGPIT-3550-A
EGMIA-6506-A2
EGMIA-6506-A1
LA-UX1
CS-PC1
Los Angeles
Denver
T1
NEO-PC1 NEO-UX1
CS-UX1
Colorado Springs
New Orleans
128
768
PIT-PC1
MIA-UX1
MIA-UX2
MIA-PC1
MIA-PC2
PIT-UX1
Pittsburgh
Dallas
384
E1
Miami
Washington, D.C.
768
T1
EGPHX-7204-VW
EGSAF-2651-VW
EGHOU-3660-VW
EGNY-3620-VW
EGPHX-3550-A
EGSAF-2950-A
EGHOU-3550-A
EGNY-3550-A
PHX-PC1 PHX-UX1
SAF-PC1 SAF-UX1
HOU-PC1 HOU-UX1
Phoenix
Santa Fe
Houston
NY-PC1
NY-UX1
82144
LA-PC1
New York
Platform and Software Version Information
Table 139 lists the platforms, router names, and software versions, and software images configured in
the network topology for this test suite.
Table 139
Platform, Router Name, Software Version, and Software Image Table
Platform
Router Name
Software Version
Software Image
Cisco 7206
egmia-7206-w1
12.2(12)
C7200-A3JS-M
Cisco 3640
egmia-3640-vw2
12.2(12)
C3640-A3JS-M
Cisco 3640
egmia-3640-vw
12.2(12)
C3640-A3JS-M
Catalyst 6500
egmia-6506-a1
12.1(12c)E1
c6sup2_rp-JSV-M
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
138
Test Suite Overview
Table 139
Platform, Router Name, Software Version, and Software Image Table
Platform
Router Name
Software Version
Software Image
Catalyst 6500
egmia-6506-a2
12.1(12c)E1
c6sup2_rp-JSV-M
Cisco 3620
egny-3620-vw
12.2(12)
C3620-A3JS-M
Catalyst
3550-12T
egny-3550-a
12.1(8)EA1c
C3550-I5Q3L2-M
Cisco 7204
egphx-7204-vw
12.2(12)
C7200-A3JS-M
Catalyst
3550-12T
egphx-3550-a
12.1(8)EA1c
C3550-I5Q3L2-M
Cisco 3640
egla-3640-vw
12.2(12)
C3640-A3JS-M
Catalyst
3550-12T
egla-3550-a
12.1(8)EA1c
C3550-I5Q3L2-M
Cisco 2651
egcs-2651-vw
12.2(12)
C2600-A3JS-M
Catalyst
2950T-24
egcs-2950-a
12.1(6)EA2c
C2950-I6Q4L2-M
Cisco 2651
egsaf-2651-vw
12.2(12)
C2600-A3JS-M
Catalyst
2950T-24
egsaf-2950-a
12.1(6)EA2c
C2950-I6Q4L2-M
Cisco 2651
egneo-2651-vw
12.2(12)
C2600-A3JS-M
Catalyst
2950T-24
egneo-2950-a
12.1(6)EA2c
C2950-I6Q4L2-M
Catalyst
3550-12T
eghou-3550-a
12.1(8)EA1c
C3550-I5Q3L2-M
Cisco 3640
eghou-3640-vw
12.2(12)
C3640-A3JS-M
Cisco 3660
eghou-3660-vw
12.2(12)
C3660-A3JS-M
Catalyst
3550-12T
egpit-3550-a
12.1(8)EA1c
C3550-I5Q3L2-M
Cisco 3640
egpit-3640-vw
12.2(12)
C3640-JS-M
Basic IP Test with EIGRP
This is a basic IP functionality test for the remote campuses. The test category verifies basic IP
functionality, using the layer 2 Virtual Terminal Protocol (VTP), and the layer 3 protocols EIGRP (for
the interior routing) and BGP (for the exterior routing). Along with basic IP, the following additional
features were configured:
•
CEF Support for IP Routing between IEEE 802.1Q VLANs
•
EIGRP Stub Routing
•
IEEE 802.1Q virtual LAN (VLAN) support
The objectives of this test category included the following:
•
To verify that the software can be loaded and used in the devices successfully.
•
To verify that the network operation (that is, the network connectivity) is working correctly.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
139
Test Suite 1: San Jose Campus with Data Center
•
To verify that the major IP routing features work as expected.
•
To collect the network baseline information and provide the necessary test results.
In this test category, the following individual tests were conducted:
•
Layer 2 protocol test
•
EIGRP routing test
•
Traffic routing convergence test
•
Traffic load capacity test
Layer 2 Protocol Test
This test involved testing VTP, VLANs, and VLAN trunking. This test plan verified the following:
•
The VTP feature is enabled.
•
The VLAN status is correct.
•
The VLAN port assignments are correct.
•
The VLAN trunkings are formed correctly.
Test Plan
The procedure used to perform the layer 2 protocol test follows:
Step 1
Analyze the output of the show commands listed in Table 140. These commands were used on all the
routers.
Table 140
Show Commands Used for Test Bed Setup Verification
Command
Purpose
show interfaces trunk (Cisco IOS command)
•
Verifies that the VLAN trunkings are formed
correctly.
show VTP status (Native IOS command)
•
Verifies that the VTP feature is enabled.
show VLAN brief (CatOS command)
•
Verifies VLAN status and port assignments.
Expected Results
We expect the following results:
•
The VTP feature is enabled and working correctly.
•
The VLAN configuration works correctly.
•
The VLAN status is correct, and the port assignments are correct.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
140
Test Suite Overview
Results
Table 141 shows the layer 2 protocol test results.
Table 141
Layer 2 Protocols Test Results
Tests
Results
Layer 2 protocol
Pass
EIGRP Routing Test
This test involved testing EIGRP routing. The following features were included in the test plan:
Note
•
Route summarization, filtering, and redistribution
•
EIGRP metric tuning
The entire global enterprise topology is a single EIGRP AS 1 configuration.
Test Plan
This test verifies route summarization, route filtering, route redistribution, and EIGRP metric tuning.
There were two parts to this test plan, described in the sections that follow.
Route Summarization, Filtering, and Redistribution Test
The procedure used to perform the route summarization, filtering, and redistribution test follows:
Step 1
Disable auto-summary on all the remote campus WAN routers and distribution switches.
Step 2
Create distribution lists for the two WAN access routers, the egmia-7206-w1 router and the
egmia-3640-vw2 router, to permit Miami routes to the campus WAN aggregation routers only.
Step 3
Configure the Cisco IOS eigrp log-neighbor-changes command on the eigrp 1 router for all the remote
campus routers and layer 3 switches listed below.
•
egmia-7206-w1
•
egmia-3640-vw2
•
egmia-6506-a1
•
egmia-6506-a2
•
egphx-7204-vw
•
egny-3620-vw
•
egla-3640-vw
•
egcs-2651-vw
•
egsaf-2651-vw
•
egneo-2651-vw
•
eghou-3660-vw
•
egpit-3640-vw
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
141
Test Suite 1: San Jose Campus with Data Center
EIGRP Metric Tuning Test
The procedure used to perform the EIGRP metric tuning test follows:
Step 1
Tune the link bandwidth for all remote campuses with Frame Relay PVCs to the actual bandwidth used.
Do this for each of the routers listed below.
•
egcs-2651-vw
•
eghou-3660-vw
•
egneo-2651-vw
•
egny-3620-vw
•
egphx-7204-vw
•
egpit-3640-vw
•
egsaf-2651-vw
Step 2
Tune the link delay for the 128 k link from the New Orleans campus to the Dallas campus from 20000 ms
(usec) to 200000 usec. This ensures that the other two 128 k links to the Denver campus are the primary
links.
Step 3
Configure the Cisco IOS no peer neighbor-route command for all the encapsulated PPP WAN
interfaces. This configuration avoids sub-optimal routing for the WAN interface routes on the remote
campuses.
Step 4
Analyze the output of the Cisco IOS show commands listed in Table 142.
Table 142 lists each command and the role it plays in EIGRP routing test.
Table 142
Commands Used in the EIGRP Routing Test
Command
show ip route
Purpose
•
Verifies that the routes are summarized as
expected.
•
Verifies that the route filters work as expected.
show processes cpu
•
Verifies the CPU utilization; verifies that CPU
capacity is not being monopolized by a single
router.
show memory summary
•
Verifies that there are no memory leaks and
other memory errors.
show logging
•
Verifies that there are no significant errors for
EIGRP routing.
show interfaces [interface type]
•
Verifies if there are any input errors, output
errors, or queue drops.
•
Verifies the throughput of the router.
•
Verifies that the router is EIGRP stub-enabled.
and
show ip route summary
show ip eigrp neighbor detail
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
142
Test Suite Overview
Expected Results
We expect the following results:
•
The routes are summarized correctly.
•
The route filters function correctly.
•
The distribution layer routers are EIGRP stub-enabled.
•
The default route is generated correctly.
•
There are no EIGRP routing errors and that the link delay and bandwidth have been tuned correctly.
•
The EIGRP neighbor was not created between two distribution layer routers.
•
The routing table displays the appropriate routes.
Results
Table 143 shows the EIGRP routing test results.
Table 143
EIGRP Routing Test Results
Tests
Results
EIGRP routing
Pass
Traffic Routing Convergence Test
The following section describes the procedures for setting up traffic routing and conducting the traffic
routing convergence testing.
Test Plan
The procedure used to perform the traffic routing convergence test follows:
Step 1
Use the Cisco IOS show ip route command to verify that all simulated routes exist.
Step 2
Set up a continuous ping between two PCs located in two points in the topology. For the ping packet
size, use 512 bytes. For the ping time-out setting, use 500 milliseconds (ms).
Step 3
During the ping test, make the link-to-router connection fail as described above.
Step 4
Capture the number of ping packets lost, and derive the convergence time from the product of the total
number of packets lost and the ping time-out setting.
Step 5
After the link-to-router connection is up, created another link-to-router connection failure (if any are
link-to-router combinations are available) and repeat Step 2 and Step 3. As an example, there are four
different link-to-router connection failures for testing the New York-to-Santa Fe link, four iterations are
needed.
Expected Results
We expect that all simulated routes exist and that the link connections between two points in the topology
can be established and maintained.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
143
Test Suite 1: San Jose Campus with Data Center
Results
Table 144 shows the traffic routing convergence test results.
Table 144
Traffic Routing Convergence Test Results
Tests
Results
Traffic routing convergence
Pass
Traffic Load Capacity Test
This test was intended to test the network configuration at 0% of traffic load capacity, at 50% of traffic
load capacity, and at 90% of traffic load for a period of 2 to 4 hours.
Test Plan
The procedure used to perform the traffic load capacity test follows:
Step 1
At 0% of network traffic capacity, repeat the steps for the layer 2 protocol test plan, and the EIGRP
routing test plan.
Step 2
Increase network traffic capacity to 50%.
Step 3
Repeat the steps for the layer 2 protocol test plan and the EIGRP routing test plan.
Step 4
Increase network traffic capacity to 90%.
Step 5
Repeat the steps for the layer 2 protocol test plan, and the EIGRP routing test plan.
Expected Results
We expect that the network configuration will continue to work correctly at each level of traffic load
capacity.
Results
Table 145 shows the traffic load capacity test results.
Table 145
Traffic Load Capacity Test Results
Tests
Results
Traffic load capacity
Pass
System Test with EIGRP
This section describes in detail the system testing for QoS features (listed below) on the remote
campuses, using EIGRP as the routing protocol. The system testing also included negative testing, which
was verified by testing the QoS functionality as a primary WAN link fails.
The following QoS features were included in this test category:
•
Classification and marking, including the following:
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
144
Test Suite Overview
– Access lists
– Network-based application recognition (NBAR)
– Port numbers
– IP Precedence
– Differentiated services code point (DSCP)
•
Congestion management, including the following:
– Class-based weighted fair queueing (CBWFQ)
– Low latency queueing (LLQ)
•
Traffic conditioning, including the following:
– Frame Relay Traffic Shaping (FRTS)
– Generic Traffic Shaping (GTS)
•
Link efficiency mechanisms, including the following:
– Multilink PPP (MLPPP) interleaving
In addition to those features listed above, the following features were configured in this test category:
•
CBWFQ
•
Priority queueing (PQ)
•
ATM virtual circuit (VC) scaling
•
EIGRP Stub Routing
•
Frame Relay-to-ATM Service Interworking (FRF.8)
•
IEEE 802.1Q VLAN Support
•
IP
•
PPP over Frame Relay
•
VoIP
The objectives of this test category included the following:
•
To verify that the QoS features can be incorporated into all remote campuses.
•
To verify the successful operation of the Cisco IOS releases.
•
To ensure that the system behaves as expected.
•
To collect the network baseline information and provide the necessary test results.
In the test category, the following individual tests were conducted:
•
Voice gateway test
•
Voice traffic verification test
•
Voice and data traffic verification test
•
QoS setup test
•
QoS verification test
•
Negative test
•
Traffic routing convergence test
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
145
Test Suite 1: San Jose Campus with Data Center
Voice Gateway Test
The voice gateway test verified that the voice gateways were configured correctly and functioning as
expected for handling the voice traffic on the network.
Test Plan
The procedure used to perform the voice gateway test follows:
Step 1
Step 2
Step 3
Configure voice gateways on all the remote campuses routers listed below.
•
egla-3640-vw
•
egphx-7204vw
•
egsaf-2651-vw
•
egneo-2651-vw
•
egcs-2651-vw
•
egny-3620-vw
•
eghou-3660-vw
•
egpit-3640-vw
•
egmia-3640-vw2
Using the Cisco IOS show gateway command, verify that the gateways listed below are registered with
the gatekeeper (the egsj-3640-gk router).
•
egla-3640-vw
•
egphx-7204vw
•
egsaf-2651-vw
•
egneo-2651-vw
•
egcs-2651-vw
•
egny-3620-vw
•
eghou-3660-vw
•
egpit-3640-vw
•
egmia-3640-vw2
Configure the Bulk Call Traffic Generator (BCG) to generate traffic.
Expected Results
We expect that the voice gateways are configured as anticipated, are registered correctly, and are
functioning properly.
Results
Table 146 shows the voice gateway test results.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
146
Test Suite Overview
Table 146
Voice Gateway Test Results
Tests
Results
Voice gateway
Pass
Voice Traffic Verification Test
This test verified that incoming and outgoing voice traffic was handled properly on the network. In this
test plan, no QoS features were configured and the network was free from traffic congestion.
Test Plan
The procedure used to perform the voice traffic verification test follows:
Step 1
Step 2
Start the bulk call traffic generator by completing the following steps:
a.
Start the BCG channels from Phoenix (7 calls) to Denver, Colorado Springs and New Orleans
(1 call) to Denver, Santa Fee (1 call) to Dallas, Houston (5 calls) to Dallas, Pittsburgh (4 calls) to
Boston, Miami (1 call) to Washington, D.C., Los Angeles (1 call) to San Jose and New York (1 call)
to Washington, D.C.
b.
Verify that all BCG channels are functioning correctly. Do this by using the CIC tool for 5 minutes.
Analyze the output of the Cisco IOS show commands listed in Table 147. The show processes cpu
command was used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1
hour.
Table 147
Show Commands Used for the Voice Traffic Verification Test
Command
Purpose
show clock
•
Displays the current time.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
show ppp multilink [interface type]
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
The show commands listed in Table 147 were used on the WAN routers and interfaces in Table 148.
Table 148
Remote Campus WAN Routers and Interfaces
Router
Interface
egla-3640-vw
s0/0:0, s0/1:0
egphx-7204-vw
s1/0:0, s1/0.768
egny-2630-vw
s0/0, s0/1.768
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
147
Test Suite 1: San Jose Campus with Data Center
Table 148
Remote Campus WAN Routers and Interfaces
Router
Interface
egsaf-2651-vw
s0/0.126, s0/0.128
egcs-2651-vw
s0/0.127, s0/0.128
egneo-2651-vw
s0/0.126, s0/0.127, s0/0.128
eghou-3660-vw
s6/0:0.384, s3/0:0
egpit-3620-vw
s0/1.768, s0/0
egmia-3640-vw2
s1/0
egmia-7204-w1
atm6/0
Step 3
Verify that the BCG channels from Denver (8 calls) to Phoenix, Denver (1 call) to Colorado Springs and
New Orleans, Dallas (1 call) to Santa Fe, Dallas (5 calls) to Houston, Boston (5 calls) to Pittsburgh,
Washington, D.C. (1 call) to Miami, San Jose (1 call) to LA and Washington, D.C. (1 call) to New York
functioning correctly. Do this by using the CIC testing tool.
Step 4
Stop the bulk call traffic generator and verify results by completing the following steps:
a.
Stop the BCG and the Callgen traffic testing tool after 2 hours of run time.
b.
Verify that all BCG channels are functioning correctly. Do this by using the CIC testing tool.
c.
Capture BCG output statistics using the show chan command.
Expected Results
We expect that voice traffic will be transmitted efficiently and that all voice channels originate and
terminate properly.
Results
Table 149 shows the voice traffic verification test results.
Table 149
Voice Traffic Verification Test Results
Tests
Results
Voice traffic verification
Pass
Voice and Data Traffic Verification Test
This test plan verified that incoming and outgoing voice and data traffic was handled properly on the
network. In this test, no QoS features were configured and the network was experiencing traffic
congestion.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
148
Test Suite Overview
Test Plan
Before conducting this test plan, we verified that all data generators, and the BCG testing tool were
configured. Then the steps listed below were performed.
The procedure used to perform the voice and data traffic verification test follows:
Step 1
Start the BCG, and the Chariot, and IXIA traffic testing tools to congest the network.
Step 2
Analyze the output of the Cisco IOS show commands listed in Table 150. The show processes cpu
command was used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1
hour.
Table 150
show Commands Used for the Voice and Data Traffic Verification Test
Command
Purpose
show clock
•
Displays the current time.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
show ppp multilink [interface type]
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
The show commands listed in Table 150 were used on the WAN routers and interfaces in Table 151.
Table 151
Remote Campus WAN Routers and Interfaces
Router
Interface
egla-3640-vw
s0/0:0, s0/1:0
egphx-7204-vw
s1/0:0, s1/0.768
egny-2630-vw
s0/0, s0/1.768
egsaf-2651-vw
s0/0.126, s0/0.128
egcs-2651-vw
s0/0.127, s0/0.128
egneo-2651-vw
s0/0.126, s0/0.127, s0/0.128
eghou-3660-vw
s6/0:0.384, s/0:0
egpit-3620-vw
s0/1.768, s0/0
egmia-3640-vw2
s1/0
egmia-7204-w1
atm6/0
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
149
Test Suite 1: San Jose Campus with Data Center
Step 3
Verify that the BCG channels from Denver (8 calls) to Phoenix, Denver (1 call) to Colorado Springs and
New Orleans, Dallas (1 call) to Santa Fe, Dallas (5 calls) to Houston, Boston (5 calls) to Pittsburgh,
Washington, D.C. (1 call) to Miami, San Jose (1 call) to LA and Washington, D.C. (1 call) to New York
are functioning correctly. Do this by using the CIC testing tool.
Step 4
Capture the data statistics from Chariot and IXIA after the 1-hour test run.
Expected Results
We expect that voice and date traffic will be transmitted efficiently and that all voice and data channels
originate and terminate properly.
Results
Table 152 shows the voice and data traffic test results.
Table 152
Voice and Data Traffic Verification Test Results
Tests
Results
Voice and data traffic verification
Pass
QoS Setup Test
The test verified that QoS features were configured correctly and that the QoS features were applied to
traffic classes as anticipated. In this test, the Modular Quality of Service Command-Line Interface
(MQC) three-step model was used to configure the traffic classes, class maps, and policy maps.
Test Plan
The procedure used to perform the QoS setup test follows:
Step 1
Step 2
Define the access lists and traffic classes following the guidelines listed below.
•
Voice traffic is classified into a class-map called “Real-Time.”
•
Applications with small or infrequently sent packets such as Telnet, Citrix, and voice signaling are
classified into a class-map called “Interactive.”
•
Classify the mission-critical traffic or traffic that can consume large amounts of bandwidth into a
class-map called “Transactional.”
•
NetMeeting traffic is classified into the “Interactive-Video” class.
•
The “Control” class is configured for routing traffic.
•
HTTP and FTP traffic is classified into the “class-default” class.
Associate the policy maps and actions with each class of traffic by configuring the policy maps listed in
Table 153. Table 153 lists the policy map to be configured, the router on which it is configured, and the
QoS feature tested by the policy map.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
150
Test Suite Overview
Table 153
Policy Map Name, Router, and QoS Features Table
Policy Map
IN-bound
OUT-bound-128
OUT-bound-384
OUT-bound-768
Router
QoS Feature
•
egsaf-2651-vw
•
access lists
•
egneo-2651-vw
•
port numbers
•
egcs-2651-vw
•
IP Precedence
•
eghou-3660-vw
•
DSCP
•
egpit-3640-vw
•
egny-3620-vw
•
egphx-7204-vw
•
any routers with links of
768K and below.
•
egsaf-2651-vw,
•
CBWFQ
•
egneo-2651-vw
•
LLQ
•
egcs-2651-vw
•
eghou-3660-vw
•
egpit-3640-vw
•
egny-3620-vw
•
egphx-7204-vw
•
any routers with links of
768K and below
•
egsaf-2651-vw
•
CBWFQ
•
egneo-2651-vw
•
LLQ
•
egcs-2651-vw
•
eghou-3660-vw
•
egpit-3640-vw
•
egny-3620-vw
•
egphx-7204-vw
•
any routers with links of
768K and below
•
egsaf-2651-vw
•
CBWFQ
•
egneo-2651-vw
•
LLQ
•
egcs-2651-vw
•
eghou-3660-vw
•
egpit-3640-vw
•
egny-3620-vw
•
egphx-7204-vw
•
any routers with links of
768K and below
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
151
Test Suite 1: San Jose Campus with Data Center
Table 153
Policy Map Name, Router, and QoS Features Table
Policy Map
IN-bound
OUT-bound-dT1
IN-bound
OUT-bound-10M
Step 3
Router
QoS Feature
•
egla-3640-vw
•
access lists
•
egphx-7204-vw
•
port numbers
•
eghou-3660-vw
•
IP Precedence
•
egpit-3640-vw
•
DSCP
•
egny-3620-vw
•
egmia-3640-vw2
•
any routers with T1 links
•
egla-3640-vw
•
CBWFQ
•
egphx-7204-vw
•
LLQ
•
eghou-3660-vw
•
egpit-3640-vw
•
egny-3620-vw
•
egmia-3640-vw2
•
any routers with T1 links
•
egmia-7206-w1 router
(shapes the 45MB link to
the 10M link)
•
access lists
•
port numbers
•
IP Precedence
•
DSCP
•
CBWFQ
•
LLQ
•
egmia-7206-w1 router
(shapes the 45 MB link to
the 10M link)
Attach policy maps to the interfaces listed in Table 154.
Table 154 shows the router name, the policy map created, and the interface to which the policy map was
applied (attached). In some instances, instead of attaching a policy map to the interface, a specific feature
was applied.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
152
Test Suite Overview
Table 154
Routers, Policy Maps or Features, and Interfaces for the QoS Setup Test
Router
Policy Map or Feature
Interface
egcs-2651-vw
IN-bound
fa0/1
egcs-2651-vw
OUT-bound-128
Virtual-Template15
egcs-2651-vw
Virtual-Template15
s0/0.128
egcs-2651-vw
MLP Interleaving
Virtual-Template15
egcs-2651-vw
FRTS
s0/0
egneo-2651-vw
IN-bound
fa0/1
egneo-2651-vw
OUT-bound-128
Virtual-Template15
egneo-2651-vw
Virtual-Template15
s0/0.126
egneo-2651-vw
MLP Interleaving
Virtual-Template15
egneo-2651-vw
FRTS
s0/0
egneo-2651-vw
IN-bound
fa0/1
egneo-2651-vw
OUT-bound-128
Virtual-Template15
egneo-2651-vw
Virtual-Template15
s0/0.127
egneo-2651-vw
MLP Interleaving
Virtual-Template15
egneo-2651-vw
FRTS
s0/0
egcs-2651-vw
IN-bound
fa0/1
egcs-2651-vw
OUT-bound-128
Virtual-Template15
egcs-2651-vw
Virtual-Template15
s0/0.127
egcs-2651-vw
MLP Interleaving
Virtual-Template15
egcs-2651-vw
FRTS
s0/0
egsaf-2651-vw
IN-bound
fa0/1
egsaf-2651-vw
OUT-bound-128
Virtual-Template15
egsaf-2651-vw
Virtual-Template15
s0/0.126
egsaf-2651-vw
MLP Interleaving
Virtual-Template15
egsaf-2651-vw
FRTS
s0/0
egsaf-2651-vw
IN-bound
fa0/1
egsaf-2651-vw
OUT-bound-128
Virtual-Template15
egsaf-2651-vw
Virtual-Template15
s0/0.128
egsaf-2651-vw
MLP Interleaving
Virtual-Template15
egsaf-2651-vw
FRTS
s0/0
egneo-2651-vw
IN-bound
fa0/1
egneo-2651-vw
OUT-bound-128
Virtual-Template15
egneo-2651-vw
Virtual-Template15
s0/0.128
egneo-2651-vw
MLP Interleaving
Virtual-Template15
egneo-2651-vw
FRTS
s0/0
eghou-3660-vw
IN-bound
fa0/0
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
153
Test Suite 1: San Jose Campus with Data Center
Table 154
Routers, Policy Maps or Features, and Interfaces for the QoS Setup Test
Router
Policy Map or Feature
Interface
eghou-3660-vw
OUT-bound-384
Virtual-Template20
eghou-3660-vw
Virtual-Template20
s6/0:0.384
eghou-3660-vw
MLP Interleaving
Virtual-Template20
eghou-3660-vw
FRTS
s6/0:0
egny-3620-vw
IN-bound
fa 0/1
egny-3620-vw
OUT-bound-768
Virtual-Template20
egny-3620-vw
Virtual-Template20
s0/1.768
egny-3620-vw
MLP Interleaving
Virtual-Template20
egny-3620-vw
FRTS
s0/1
egpit-3640-vw
IN-bound
fa0/1
egpit-3640-vw
OUT-bound-768
Virtual-Template20
egpit-3640-vw
Virtual-Template20
s0/1.768
egpit-3640-vw
MLP Interleaving
Virtual-Template20
egpit-3640-vw
FRTS
s0/1
egphx-7204-vw
IN-bound
Gigabit ethernet 0/0
egphx-7204-vw
OUT-bound-768
Virtual-Template20
egphx-7204-vw
Virtual-Template20
serial 1/0.768.
egphx-7204-vw
MLP Interleaving
Virtual-Template20
egphx-7204-vw
FRTS
s1/0
egla-3640-vw
IN-bound
Fa 1/0
egla-3640-vw
OUT-bound-dT1
serial 0/0:0
egla-3640-vw
IN-bound
fa1/0
egla-3640-vw
OUT-bound-dT1
s0/1:0
egphx-7204-vw
IN-bound
Gibabit ethernet 0/0
egphx-7204-vw
OUT-bound-dT1
s1/0:0
eghou-3660-vw
IN-bound
fa0/0
eghou-3660-vw
OUT-bound-dT1
s3/0:0
egpit-3640-vw
IN-bound
fa0/1
egpit-3640-vw
OUT-bound-dT1
s0/0
egny-3620-vw
IN-bound
fa0/1
egny-3620-vw
OUT-bound-dT1
s0/0
egmia-3640-vw2
IN-bound
fa0/1, fa1/0, fa1/1
egmia-3640-vw2
OUT-bound-dT1
s1/0
egmia-7206-w1
IN-bound
fa0/0, fa1/0, fa2/0
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
154
Test Suite Overview
Expected Results
We expect that the following results:
•
Access lists and traffic classes are correctly defined.
•
Policy maps and actions have been correctly associated.
•
Policy maps are attached to the appropriate interfaces.
•
QoS features have been configured and are functioning properly.
Results
Table 155 shows the QoS setup test results.
Table 155
QoS Setup Test Results
Tests
Results
QoS setup
Pass
QoS Verification Test
This test plan verified that incoming and outgoing voice and data traffic was handled properly on the
network, and that various QoS features (such as traffic shaping and QoS policy maps) were functioning
correctly. In this test, both voice and data traffic were used, QoS features were configured, and the
network was experiencing traffic congestion.
Test Plan
The procedure used to perform the QoS verification test follows:
Step 1
Start the BCG, and the Chariot, and IXIA traffic testing tools to congest the network.
Step 2
Analyze the output of the Cisco IOS show commands listed in Table 156. The show processes cpu
command was used every 30 seconds for 1 hour. The other commands were used every 5 minutes for 1
hour.
Table 156
show Commands Used for the QoS Verification Test
Command
Purpose
show clock
•
Displays the current time.
show policy-map interface [interface type]
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy-maps.
show interfaces [interface type]
•
Verifies the link speed and drop rate. If traffic
shaping is configured on the interface, the
output rate should not exceed the shaped rate.
Traffic exceeding the rate will be dropped.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
155
Test Suite 1: San Jose Campus with Data Center
Table 156
show Commands Used for the QoS Verification Test
Command
Purpose
show frame-relay pvc dlci
•
Verifies the encapsulation type, min cir,
fragmentation information and policies applied
to this PVC. Also verifies the same information
as the show policy-map interface command.
show traffic-shape statistics
•
Verifies that traffic shaping is enabled.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface was configured by the
virtual-template number.
show ppp multilink [interface type]
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
The show commands listed in Table 156 were used on the WAN routers and interfaces in Table 157.
Table 157
Step 3
Remote Campus WAN Routers and Interfaces
Router
Interface
egla-3640-vw
s0/0:0, s0/1:0
egphx-7204-vw
s1/0:0, s1/0.768
egny-2630-vw
s0/0, s0/1.768
egsaf-2651-vw
s0/0.126, s0/0.128
egcs-2651-vw
s0/0.127, s0/0.128
egneo-2651-vw
s0/0.126, s0/0.127, s0/0.128
eghou-3660-vw
s6/0:0.384, s/0:0
egpit-3620-vw
s0/1.768, s0/0
egmia-3640-vw2
s1/0
egmia-7204-w1
atm6/0
Capture voice quality information by completing the following steps:
a.
Using the CIC testing tool, verify that all the BCG channels from the locations listed below are
functioning correctly.
– Phoenix (7 calls) to Denver
– Colorado Springs and New Orleans (1 call) to Denver
– Santa Fee (1 call) to Dallas
– Houston (5 calls) to Dallas
– Pittsburgh (5 calls) to Boston
– Miami (1 call) to Washington, D.C.
– Los Angeles (1 call) to San Jose
– New York (1 call) to Washington, D.C.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
156
Test Suite Overview
b.
Use Chariot and Callgen to measure the packet delay, jitter, and packet loss for the end users
between the following locations:
– San Jose and Los Angeles
– Denver and Phoenix
– Denver and Colorado Springs
– Denver and New Orleans
– Dallas and Santa Fe
– Dallas and Houston
– Boston and Pittsburgh
– Washington, D.C. and Miami
– Washington, D.C. and New York.
c.
Step 4
Use QDM to monitor the bandwidth utilization resulting from the various QoS mechanisms. For
each QoS traffic class, monitor both the inbound and outbound bit rate, the packet rate, the drop rate
(or the queue depth). QDM will be used in the Santa Fe campus only.
Analyze the output of the Cisco IOS show commands listed in Table 158 after the 1-hour test referred to
in Step 2 is completed. These commands were used on all the WAN routers and core switches.
Table 158
show Commands Used for the QoS Verification Test
Command
Step 5
Note
Purpose
show class-map
•
Displays the configured class-map configured
for the device.
show policy-map
•
Displays the policy-map configured for the
device.
show access-lists
•
Verifies that the configured access-lists have the
correct amount of matching packets.
Capture the data statistics from the BCG, and the Chariot traffic testing tool, and QDM after the 1-hour
test referred to in Step 2 is completed.
QDM, a tool used to gather graphical data on CPU utilization and link speed, will be used at the Santa
Fe campus only.
Expected Results
We expect the following results:
•
Access lists and traffic classes are correctly defined.
•
Traffic shaping has been enabled and is functioning correctly.
•
Class maps have been correctly configured.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
157
Test Suite 1: San Jose Campus with Data Center
•
Policy maps and actions have been correctly associated.
•
Policy maps are attached to the appropriate interfaces.
•
Voice and data traffic are assigned the proper amount of bandwidth in the policy maps.
Results
Table 159 shows the QoS verification test results.
Table 159
QoS Verification Test Results
Tests
Results
QoS verification
Pass
Negative Test
This test verifies the QoS functionality in the event a primary WAN link fails.
Test Plan
The procedure used to perform the negative test follows:
Step 1
Start the BCG, and the Chariot and IXIA traffic testing tools if they are stopped.
Step 2
From the New York remote campus, shut down the T1 link to the Washington, D.C. with data center
campus. See if the alternative link (serial 0/1.768) to the Boston campus is activated.
Step 3
Perform Step 2, Step 3, and Step 4 of the QoS Verification Test.
Step 4
Compare the packet delay, jitter, and packet loss information with the results of the QoS Verification
Test. The differences should not be significant.
Expected Results
We expect that the features of QoS function will function correctly in the event a primary WAN link fails.
Results
Table 160 shows the results of the negative test.
Table 160
Negative Test Results
Test Conducted
Pass/Fail
Negative
Pass
Traffic Routing Convergence Test
The following section describes the procedures for setting up traffic routing and conducting the routing
convergence testing. In this test plan, both voice and data traffic were used, QoS features were
configured, and the network was experiencing traffic congestion.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
158
Test Suite Overview
Test Plan
The procedure used to perform the traffic routing convergence test follows:
Step 1
Use the Cisco IOS show ip route command to verify that all simulated routes exist.
Step 2
Set up a continuous ping between two PCs located in two points in the topology. For the ping packet
size, use 512 bytes. For the ping time-out setting, use 500 milliseconds (ms).
Step 3
During the ping test, make the link-to-router connection fail as described above.
Step 4
Capture the number of ping packets lost, and derive the convergence time from the product of the total
number of packets lost and the ping time-out setting.
Step 5
After the link-to-router connection is up, created another link-to-router connection failure (if any are
link-to-router combinations are available) and repeat Step 2 and Step 3. As an example, there are four
different link-to-router connection failures for testing the New York-to-Santa Fe link, four iterations are
needed.
Expected Results
We expect that all simulated routes exist and that the link connections between two points in the topology
can be established and maintained.
Results
Table 161 shows the traffic routing convergence test results.
Table 161
Traffic Routing Convergence Test Results
Tests
Results
Traffic routing convergence
Pass
Reliability Test with EIGRP
This section describes the reliability test as it pertained to the remote campuses, using EIGRP as the
routing protocol. The reliability test ran continuously for 150 hours, with basic IP routing and switching
enabled, and all QoS features configured.
The following additional features were configured in this test category:
•
CBWFQ
•
PQ
•
ATM VC Scaling
•
EIGRP Stub Routing
•
Frame Relay-to-ATM Service Interworking (FRF.8)
•
GTS
•
H.323/H.320 Gateway
•
IEEE 802.1Q VLAN support
•
IP
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
159
Test Suite 1: San Jose Campus with Data Center
•
LLQ
•
PPP over Frame Relay
•
VoIP
The objective of this test was to ensure that the software was stable and reliable in the testbed during the
150 hours test period, with 100% traffic load on each WAN link.
Test Plan
The procedure used to perform the reliability test with EIGRP test follows:
Step 1
Step 2
Start traffic streams by completing the following steps:
a.
Start the BCG to generate traffic.
b.
Start Chariot to simulate Netmeeting, Telnet, Citrix, FTP, and HTTP traffic.
c.
Start IXIA.
d.
Start LNE to simulate EIGRP routes.
Analyze the output of the Cisco IOS show commands listed in Table 162. These commands were used
at each router every hour for a 150-hour test period:
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
160
Test Suite Overview
Table 162
show Commands Used for the Reliability Test with EIGRP Test
Command
Purpose
show clock
•
Displays the current time.
show ip route summary
•
Verifies the basic routing.
show policy-map interface [interface type]
•
Verifies that voice traffic in the Real-Time class
has the correct percentage of the link
bandwidth.
show interfaces
•
Verifies the link speed. If traffic shaping is
configured on the interface, the output rate
should not exceed the shaped rate. The
exceeding traffic will be dropped.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
show frame-relay pvc dlci
•
Verifies the encapsulation type, min cir,
fragmentation information and policies applied
to this PVC. Also verifies the same information
as the show policy-map interface command.
show traffic-shape statistics
•
Verifies that traffic shaping is enabled.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface was configured by the
virtual-template number.
show ppp multilink [interface type]
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
show voice call summary
•
Verifies the call status for the voice calls placed
by the BCG.
Expected Results
We expect that the software (at 100% traffic load capacity on each WAN link) performs reliably during
the 150-hour test period.
Results
Table 163 shows the reliability test with EIGRP test results.
Table 163
Reliability Test with EIGRP Test Results
Tests
Results
Reliability test with EIGRP
Pass
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
161
Test Suite 1: San Jose Campus with Data Center
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 © 2002, Cisco Systems, Inc.
All rights reserved.
Global Enterprise System Test for Cisco IOS Release 12.1(12c)E1, Release 12.2(12), CatOS 6.3(6), and CatOS 7.2(1)
162