Cisco IOS Profiled Release 12.2(16b)M,
12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1)
System Testing for Global Enterprise Customers
Version History
Version Number
Date
Notes
1
July 30, 2003
This document was created. The term “Safe Harbor” was
changed to “Profiled Release.”
2
September 5, 2003
Additional technical edits incorporated.
Executive Summary
The nEverest program is a quality initiative that focuses on satisfying customer requirements by
coordinating Cisco IOS release system-level and reliability testing under “real world” conditions. The
nEverest testing uses the following five profiles, the designs of which are based solely on customer
requirements:
•
Global Enterprise
•
Financial Enterprise
•
Service Provider/IP backbone
•
Service Provider/MPLS backbone
•
Broadband
This document provides a summary of the system-level and reliability testing completed atop the Global
Enterprise profile for the following releases:
Cisco IOS Release 12.2(16b)M
Cisco IOS Release 12.1(13)E9
Cisco IOS Release 12.1(13)EW2
Cisco IOS Release 12.1(13)EA1c
Cisco IOS Release 12.2(15)T5
Catalyst OS 7.6(1)
Catalyst OS 6.4(3)
Corporate Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Copyright © 2003. Cisco Systems, Inc. All rights reserved.
Table 1 lists all of the software releases tested and the platforms on which they were tested.
Table 1
Tested Software Releases and Platforms
Release
Platform
Cisco IOS Release
12.2(16b)M
•
WAN/branches platforms (7500, 7200, 36x0,
2620)
Cisco IOS Release
12.1(13)E9
•
7600 and Catalyst 6500 - Native
(See Note 1 & Note 2)
Cisco IOS Release
12.1(13) EW2
•
Catalyst 4000/4500 - Native - sup3
Cisco IOS Release
12.1(13)EA1c
•
Catalyst 3550
•
Catalyst 2950
Cisco IOS Release
12.2(15)T5
•
7200 with NPE-G1
•
(3745 and other platforms) for Voice, QoS,
and IP Security
•
Catalyst 4000/4500 Access Gateway Module
VoIP line card
•
Catalyst 6500 - Hybrid
(See Note 1 & Note 2)
•
Catalyst 4000/4500 - Hybrid - sup2
Catalyst OS 7.6(1)
Catalyst OS 6.4(3)
Note
Notes
•
1. Cat6000 Hybrid image:
c6msfc2-jsv-mz.121-13.E9 + CATOS 7.6.1
Cat6000 Supervisor IOS (native):
c6sup22-jsv-mz.121-13.E9
•
2. Cisco 7600 Router Image:
c6sup22-jsv-mz.121-13.E9
•
1. Cat6000 Hybrid image:
c6msfc2-jsv-mz.121-13.E9 + CATOS 7.6.1
Cat6000 Supervisor IOS (native):
c6sup22-jsv-mz.121-13.E9
•
2. Cisco 7600 Router Image:
c6sup22-jsv-mz.121-13.E9
Catalyst 5x00
The software versions listed in this document were tested using the test procedures described. All
relevant unresolved DDTSs found during testing are listed in the Test Results Summary table. In
addition to the information contained in this report, we highly recommend that you review the
Release Notes for each release to see the latest list of open caveats for specific features not tested or
caveats found after publication.
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 Results Summary” section.
This document contains the following sections:
•
About Global Enterprise System Test, page 3
•
Test Results Summary, page 17
•
Test Suite 1: San Jose Campus with Data Center, page 22
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
2
About Global Enterprise System Test
•
Test Suite 2: Boston Campus, page 60
•
Test Suite 3: Washington, D.C. Campus with Data Center, page 89
•
Test Suite 4: Denver Campus, page 120
•
Test Suite 5: Dallas Campus, page 154
•
Test Suite 6: Remote Campuses, page 186
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.
What was Tested
This test effort focused on verifying the functionality, reliability and performance requirements of the
following technology features in the large enterprise global test topology:
•
IP Routing
•
NMS
•
QoS
•
VoIP
•
Multicast
•
Security (IPSec)
Global Enterprise Topology
The global enterprise topology consisted of five multilayer-design campuses—two large campuses with
data centers, and three regional campuses—plus 12 remote sites, as follows:
•
San Jose campus with data center
•
Boston campus
•
Washington, D.C. campus with data center
•
Denver campus
•
Dallas campus
•
Remote campuses
– Los Angeles
– Colorado Springs
– Phoenix
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
3
About Global Enterprise System Test
– Santa Fe
– New Orleans
– Pittsburgh
– Houston
– Austin
– New York
– Miami
– Arlington
– Boca Raton
Figure 1 shows the topology for the global enterprise network at a high level. Each campus is represented
in the topology.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
4
About Global Enterprise System Test
Figure 1
High-Level Enterprise Global Topology
T1 (PTP)
ATM/FR (nx64k)
E1 (PTP)
ATM E1
T3 (PTP)
ATM T3
7609
T1
7500
7500
7206
POS OC3
7609
Washington, D.C.
Data Center
GE
GE
7609
7609
7507
7206
ATM
OC3
ATM
Provider
ATM OC3
7500
HSSI (P2P)
ISP1
Multichannel
E3
FE
7500
FE
.
7206
7206
Denver
2600 7507
7206
FE
ATM E3
7206
7206
Dallas
7206
FE
ATM/FR
ATM/FR
7507
ATM T3 (P2P)
88421
San Jose - HQ
Data Center
ISP3
7206
Boston
7206 FE
FR/FR
ATM/FR
T1
ISDN
BRI
3640
Los Angeles
7204
Phoenix
2651
Colorado
Springs
2651
Sante Fe
2651
New
Orleans
T1
T1
3640
Arlington
1760 2651
3640
7206 3640
Boca Austin 3660
Houston Pittsburgh
Miami
Raton
3620
New York
ATM-to-ATM links and leased lines (with back-to-backWANs) were used in the topology. Multiple types
of high-speed WAN links were used to establish the connections to all campuses, including OC-3
Packet-Over-SONET (POS) line card interface links, OC-3 ATM line card interface links, T1 links, and
High-Speed Serial Interface (HSSI) links.
The remote sites were 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 were 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 7200VXR router, the Cisco 3600 router, the Cisco 2600 router, the Catalyst 6500
switch, the Catalyst 5500 switch, the Catalyst 4500 switch, the Catalyst 4000 switch, the Catalyst 3550
switch, and the Catalyst 2950 switch.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
5
About Global Enterprise System Test
The topologies for each campus within the larger global enterprise topology are detailed in separate
sections of this document. Table 2 shows where you can find more information about the topology for a
specific campus.
Table 2
Where to Find the Topology Information for Each Campus
Campus
Section
San Jose campus with data center
Test Suite 1: San Jose Campus with Data
Center, page 22
Boston campus
Test Suite 2: Boston Campus, page 60
Washington, D.C. campus with data center
Test Suite 3: Washington, D.C. Campus with
Data Center, page 89
Denver campus
Test Suite 4: Denver Campus, page 120
Dallas campus
Test Suite 5: Dallas Campus, page 154
Remote campuses
Test Suite 6: Remote Campuses, page 186
The Testing Approach
The end-to-end system test approach for global enterprise consists of defining and executing a series of
functionality, system, and reliability test cases in the large global enterprise campuses. The nEverest
Phase 2 System Test focused on IP routing with EIGRP, BGP, and OSPF, plus network management,
multicast, security, voice, and QoS testing.
This test plan focused primarily on the following areas:
•
Functionality testing
•
System testing
•
Reliability testing
Functionality Test Description
The functionality test category verified the reliability and performance of basic IP functionality. The
tests are described in the following sections:
•
Basic IP
•
Network Management
•
Multicast
•
Security
•
Voice
•
QoS
The overall objectives of the functionality test were as follows:
•
Verify the basic network operation (that is, network connectivity).
•
Verify the configurability and stability in a controlled environment for each of the functionality tests
listed.
•
Verify that the software versions recommended for nEverest Phase 2 could be loaded into the devices
under test.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
6
About Global Enterprise System Test
•
Verify that the major IP features worked as expected in the Global Enterprise Test Network.
The following test sequence took place during the functionality test case execution:
•
Basic IP testing was performed in conjunction with network management testing (NMS). Network
Management was utilized to collect the test information. After completion of the basic IP test, IP
configurations were made stable, and any traffic loading was terminated in preparation for the next
test.
•
Multicast testing was performed, again with NMS monitoring. After completion of the multicast
test, IP configurations were made stable, and any traffic loading was terminated in preparation for
the next test.
•
Security testing was performed in conjunction with NMS monitoring. After completion of the
security test, IP configurations were made stable, and any traffic loading was terminated in
preparation for the next test.
•
Voice testing was performed in conjunction with NMS monitoring. After completion of the voice
test, IP configurations were made stable, and any traffic loading was terminated in preparation for
the next test.
•
QoS testing was performed in conjunction with NMS monitoring. After completion of the QoS test,
IP configurations were made stable, and any traffic loading was terminated in preparation for the
next test.
Basic IP
The objective of the basic IP test was to verify the functionality and reliability requirements of the basic
IP in a large enterprise topology environment. For Phase 2, the primary focus was on basic IP with
EIGRP, OSPF, and BGP.
The basic IP testing category covered the deployment and verification of the following Layer 2 features
and Layer 3 routing protocols:
•
Layer 3
– EIGRP or OSPF
– eBGP and iBGP
•
Layer 2 LAN
– VTP and VLAN
– VLAN trunking
– STP
– HSRP
The enterprise global topology consisted of five different "multilayer design" campuses comprising two
large campuses with data centers, two medium-size regional campuses, one small campus, and 12 remote
sites. The ATM-to-ATM and leased lines with back-to-back WAN connections with different WAN links
such as ATM-OC-3, POS-OC-3, T3, E3, and HSSI were used to connect all campuses.
The remote sites were connected to the campuses by FR-to-FR, ATM-to-FR, and leased-line connections
with various fractional T1/E1 and T1/T3 link speeds, respectively. Also, there were connections between
some campuses and ISP topology by T1/T3 leased lines.
The tested platforms were Cisco 7600, Cisco 7500, Cisco 7200VXR, Cisco 3600, Cisco 2600, Catalyst
6500, Catalyst 5500, Catalyst 4500, Catalyst 4000, Catalyst 3550, and Catalyst 2950.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
7
About Global Enterprise System Test
The network connectivity within the enterprise global topology and from the global to ISP topology were
verified. The network parameters, such as CPU utilization, memory usage, and route convergence time,
were captured using various test tools.
Routing for the basic IP test was divided into two major sections: Interior Gateway Protocols (EIGRP
and OSPF) and Exterior Gateway Protocols (BGP). Figure 2 shows an overview of the intercampus links
and what protocol the links used, IGP or EGP.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
8
About Global Enterprise System Test
Figure 2
Enterprise Global IGP and EGP Routing Topology Overview
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-7206-w3
egwas-7507-w3
ATM
eBGP
Washington, D.C.
T3
-A
TM
ISP 1
AS 1
OC3-ATM
San Jose
Denver
Dallas
Boca
Raton
egden-6509-c1
Austin
V
egdal-6506-c1
V
egden-6509-c2
egdal-6506-c2
egdal-7206-w3
ATM/FR
egden-7507-w4
V
V
Los
Phoenix Colorado
Angeles
Springs
V
V
V
V
V
Santa Fe
New
Orleans
Houston
Pittsburgh
New York
V
V
V
Arlington
95531
V
egden-7206-w3
Miami
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
9
About Global Enterprise System Test
Network Management
During the first phase, the high-level feature and functionality test was performed to verify that any
major feature or functionality that was supported but not present or not functioning was identified in a
timely manner. Also, detailed testing was performed. For a description of the available test case
definitions and expected results, refer to the testing tools, scripts, and files listed in the various test
sections. The network management testing included the following:
•
Manually tested new and enhanced MIBs.
•
Used the existing scripts to test all identified MIBs.
•
Performed a basic functionality check on traps in v1 and v2c.
•
Checked the MIBs support list and compared with the show snmp mib command output.
•
Completed detailed tests and performed newly developed test scripts on all technology.
•
Used network management software such as CiscoWorks2000 RME, Campus Manager DFM,
CiscoView, and HP OpenView to maximize interoperability, compatibility, and other tests.
The procedures used for SNMP MIB testing in this phase were to verify that the information stored in a
MIB database can be accessed, propagated, read, and written if applicable, to verify that the operation
of the OID values reflected the actual operation on the device.
Network Management Feature Coverage
Following is the list of network management features and the testing objectives of those tested features:
•
Basic functionality check of SNMPv1 and v2 basic operations of GET, GETNEXT, SET and TRAP.
•
MIB database and OID test:
– Verify the MIB database by different operations in the covered topologies.
•
Propagating the MIB database:
– Verify that the MIB variable was set and that its value was propagated to the other MIB variable,
as defined.
•
MIB compliance:
– Test whether various MIB implementations conform to the respective MIB specification. Verify
that the real operations that were set in the OIDs were correctly reflected on the device. The test
was performed manually, by automation scripts, and by comparing the results with show
command output.
•
SNMP Trap tests:
– Verify that SNMPv1 and v2 traps and informs were appropriately generated.
•
Network Management Test:
– Verify various network management tools (CiscoWorks 2000, CiscoView, HP OpenView) and
other network management applications on various operating systems (for example, Solaris and
Windows 2000).
•
Verify documents:
•
Negative testing peer with memory leak tests:
– Verify that all SNMP operations did not cause any memory leaks.
•
New technologies and new hardware MIB tests:
– Verify SNMP operation on new hardware MIBs.
Following are other features that were integrated and tested prior to the network management tests:
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
10
About Global Enterprise System Test
•
OSPF, EIGRP, and BGP routing
•
SYSLOG
•
NTP
•
TFTP
•
DNS
•
TACACS+
•
ACL
•
HSRP
•
SPT
•
802.1q trunking
Multicast
The goal of multicast testing was to verify functional features, which integrate across multiple Cisco
platforms, with various sets of Cisco IOS and CatOS releases at a system level that is commonly used
by target enterprise customers.
The strategy was to implement and test multicast features within the nEverest E2E-Global test beds and
to discover and to fix any software defects by working closely with designated development engineers,
before customers find them in their complex operational networks.
The results from this testing were shared with our partner teams, such as the Development Test group
(DevTest), the Enterprise Solutions Engineering group (ESE), the Engineering System Test group (EST),
and the enterprise customers of the nEverest program.
In nEverest Phase 2, priority was given to the features, platforms, and configurations that are most
widely deployed today by customers.
The following was the structure of each test case execution instance. This structure was a part of the
functionality and system test cases.
•
Input parameters—multiple combinations of basic configuration sets, multicast configuration sets,
and flow sets:
– Basic configuration set—the portion of the configuration of network devices that addresses
nonmulticast features used during testing. This set includes IP routing (EIGRP, OSPF, and
BGP), basic SNMP, and security. These features had been tested prior to the multicast test
execution instance.
– Multicast configuration set—the configuration of network devices that would typically use
more than one multicast feature.
– Flow set—the set of flows or traffic generator configuration that was used with the multicast
configuration set.
•
Output parameters—the network health show command set and the feature show command set:
– Network health show command set—the set of show commands that were needed to determine
the general health of the network, such as memory and CPU.
– Feature show commands set—the set of show commands that were needed to determine if a
specific multicast feature is working.
•
Results—from the output, a result information set was generated and a pass or fail determination
was made.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
11
About Global Enterprise System Test
– Result information set—the relevant information that was parsed from the show commands, and
the results obtained by test tools that determined if the test execution instance passed.
Multicast Feature Coverage
Following is the list of multicast features and the testing objectives of those tested features:
•
CGMP: Verify that CGMP is communicated among routers and switches to dynamically join or
leave a multicast group on a LAN segment.
•
IGMP v2: Verify that IGMPv2 is communicated among routers and hosts to dynamically register or
leave a multicast group on a LAN segment.
•
IGMP snooping: Verify that IGMP snooping manages multicast traffic at Layer 2 by configuring a
Layer 2 LAN port dynamically to forward multicast traffic to only those ports that want to receive
it. Verify that IGMP snooping constrains multicast traffic that exits through LAN ports to which
hosts are connected.
•
MMLS: Verify that multicast flows create MMLS entries and that switching of the flow is performed
using hardware shortcuts in the Catalyst 6500.
•
PIM sparse-dense mode: Verify that multicast forwarding is achieved using PIM. PIM interacts with
the IP unicast forwarding table to determine the correct path to the source of the multicast packets
(RPF), and interacts with IGMP to recognize networks that have members of the multicast group.
•
Auto-RP: Verify that auto-RP dynamically updates the RP information in every network device.
•
Anycast-RP with Auto-RP: Verify that Anycast RP information was distributed to the routers and
that none of the multicast groups reverted to dense mode.
•
Admin scoping and multicast boundary: Verify that the router learned RP mapping information
within the defined time-to-live (TTL) number of hops and that multicast flows were restrained in the
TTL range. Verify that RP messages were prevented from traveling beyond the boundaries of the
network using multicast boundaries.
•
Multicast rate limit: Verify the rate that a sender from the source list could send to a multicast group
in the group list
Security
The primary security test goals for nEverest Phase 2 were as follows:
•
Verify the functionality of IPSec and AAA features commonly used by enterprise customers that
integrate across multiple Cisco platforms and Cisco IOS releases at the system level.
•
Prepare for the integration of those features with other features commonly used by target enterprise
customers in future nEverest phases.
The approach was to cover three areas of security based on the nEverest customer template within the
enterprise global topology, as follows:
•
IPSec IKE with preshared keys.
•
IPSec IKE with certificate server.
•
AAA with TACACS+ and other security commands.
Priority was given to the features, platforms, and configurations that are most widely deployed today by
customers.
Security testing covered three types of tests: functionality test, system test, and reliability test. The
following was the structure of each test case execution instance. This structure was a part of the system
test case.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
12
About Global Enterprise System Test
•
Input parameters—multiple combinations of basic configuration sets, security configuration sets,
and flow sets:
– Basic configuration set—the portion of the configuration of network devices that addresses
nonsecurity features used during testing. This set included IP routing (EIGRP, OSPF, and BGP),
basic SNMP, and security. These features had been tested prior to the multicast test execution
instance.
– Multicast configuration set—the configuration of network devices that would typically use
more than one security feature.
– Flow set—the set of flows or traffic generator configuration that was used with the security
configuration set.
•
Output parameters—the network-health show command set and the feature show command set:
– Network health show command set—the set of show commands that were needed to determine
the general health of the network, such as memory and CPU.
– Feature show commands set—the set of show commands that were needed to determine if a
specific security feature was working.
•
Results—from the output, a result information set was generated and a pass or fail determination
was made.
– Result information set—the relevant information that was parsed from the show commands, and
the results obtained by test tools that determined if the test execution instance passed.
Security Feature Coverage
Following is the list of IPSec features that were tested:
•
168-bit 3DES encryption
•
MD5 and SHA-1 hashing, plus support for IPSec AH and HMAC transforms
•
Diffie-Hellman and preshared key exchange
•
Group1—768 bits, Group 2—1024 bits
•
RSA public key signature
•
GRE tunnel
•
Tunnel and transport mode
•
IPSec certificate authentication
•
CLI
•
IKE (ISAKMP)
•
AAA with TACACS+
Following are other features that were integrated and tested prior to security testing:
•
SNMP
•
Logging
•
NTP
•
DNS
•
OSPF, EIGRP, and BGP
•
HSRP
•
ACL
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
13
About Global Enterprise System Test
•
Spanning tree
•
802.1q
Voice
The objective of voice over IP (VoIP) testing was to verify the convergence of the following two general
areas of VoIP telephony within the enterprise global topology:
•
The traditional H.323 gateway-based VoIP or "legacy network."
•
The newer yet-to-be-added IP telephone CallManager architecture (termed the "AVVID" additions).
Both of these architectures, plus some additional new features and hardware, were added to the
enterprise global data topology in a phased manner. It was hoped that time would allow all phases of the
design to be implemented, but the testing did not depend on having all of the phases complete. The
strategy was such that after any phase, testing could commence and the remaining phases could be added
later.
Feature Test
The following feature set was tested during the VoIP functionality testing:
•
H.323—Took place between all legacy gateways, c4k blades, vg200, ATA186, gatekeeper, and from
the gatekeeper and gateway to Cisco CallManager.
•
SCCP—Took place between all real or simulated IP telephones, c6k blades, c4k transcoding, SRST
gateways and Cisco CallManager.
•
RTP—These voice streams took place after all call setups.
•
Transcoding—Took place in selected paths at the data center or other regional sites.
•
G.711—Took place as the codec of choice on the LANs.
•
G.729—Took place as the codec of choice on the WANs.
•
SRST—Took place at the Los Angeles, Colorado Springs, and Pittsburgh remote sites.
Scope
Besides the features already listed, the scope included testing matrices in the following three areas:
•
Signaling protocols
•
Call types
•
Gateway types
These three matrices were built in to the final dial plan document as follows:
•
Signaling:
– H.323 to H.323 calls—covered across the entire VoIP legacy network
– H.323 to SCCP calls—covered across the entire AVVID network
– SCCP to SCCP calls—covered across the entire AVVID network
•
Call types covered across entire network:
– FXS to FXS
– FXS to T1
– FXS to IP
– T1 to T1
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
14
About Global Enterprise System Test
– T1 to IP
– IP to IP
•
Gateway types:
– Catalyst 6000 only—covered in Washington, D.C.
– Catalyst 4000 only—covered in Denver
– Catalyst 6000 to Catalyst 6000—covered between San Jose and Washington, D.C.
– Catalyst 6000 to Catalyst 4000—covered in San Jose
– Catalyst 6000 to GW—covered between San Jose and Los Angeles
– Catalyst 4000 and Catalyst 4500—covered between San Jose and Denver
– Catalyst 4000 to GW—covered between Boston and Pittsburgh
– GW to GW—covered by legacy network gateways
QoS
The objective of QoS testing was to verify the integration of QoS features with other features commonly
used by target enterprise customers. The strategy was to implement and test QoS within the E2E global
test beds and to discover defects before customers find them in their complex networks.
The components of QoS can be broken into six general categories. These categories were evaluated on
an individual basis. There may be more than one specific mechanism in each category; only the
following QoS mechanisms and features were tested:
•
Classification and Marking, including the following:
– Access lists
– Network-based application recognition (NBAR)
– Class maps
– Differentiated services code point (DSCP)
– Policy maps using 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 Traffic Shaping
•
Signaling: None
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
15
About Global Enterprise System Test
•
Link Efficiency Mechanisms, including the following:
– Multi-Link Point-to-Point Protocol (MLPPP)
– Compressed Real-Time Transport Protocol (cRTP)
– Distributed cRTP (dcRTP)
– Link Fragmentation and Interleaving (LFI)
These features were configured for use with the QoS functionality described in the following sections.
Modular QoS CLI (MQC)
The MQC is the Cisco IOS framework for implementing QoS features. The MQC is a 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 with 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, voice, and video (multicast) traffic. Packets were
marked using policy-map commands, and the DSCP. Packet classification and marking was used on the
outbound interfaces of the access and distribution layer switches in all campuses. The Layer 2 CoS to
Layer 3 QoS trust mechanism, also known as remarking or marking, was also tested, whenever possible.
Classification also took place at the other routers and switches in the network to enforce predictable
Per-Hop Behaviors (PHBs). Layer 2 to Layer 3 trust mechanisms were also tested.
Congestion Avoidance
Weighted Random Early Detection (WRED) is the congestion avoidance mechanism that was used in the
test plan. WRED provides buffer management to the output queues and was applied using the
random-detect dscp-based command on the outbound interfaces of the WAN aggregation routers with
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 of all routers
and Layer 3 switches.
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.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
16
Test Results Summary
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) was enabled on the WAN or edge outbound interfaces.
Because the bandwidth on these low-speed WAN connections is very valuable, the increased workload
of compressing the headers of the voice packets was justified. cRTP also was enabled on the outbound
interfaces to conserve bandwidth.
System Test Description
The goal of the system test case was to simulate a realistic customer environment by configuring all
functional features under test and executing all Cisco IOS functionality simultaneously with various
planned levels of traffic generation. The negative test cases were also executed during the system test
case.
Reliability Test Description
The reliability test was an extension of the system test case. The environment that was set up and
successfully executed in the system test case was executed for a duration of 150 hours to verify that no
new critical or severe defects were found during the extended test time.
Test Results Summary
Table 3 summarizes the results of all the testing that was completed as part of the Global Enterprise
System Test initiative. Table 3 has the following information: the name of the test suite, the test category,
the tests that were performed, the test results, the DDTS number (if applicable), and comments.
Table 3
Test Results Summary
Test Suites
Test Category
Test Suite 1: San San Jose
Jose Campus with Functionality Test,
page 27
Data Center,
page 22
San Jose System
Test, page 53
Tests
Results
DDTS/Comments
Basic IP, page 28
Passed
—
Network Management, Passed
page 34
—
Multicast, page 35
Passed
—
Security, page 43
Passed
—
Voice, page 44
Passed
—
QoS, page 47
Passed
—
System, page 53
Passed
—
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
17
Test Results Summary
Table 3
Test Results Summary (continued)
Test Suites
Test Category
Tests
San Jose Reliability Reliability, page 57
Test, page 57
Test Suite 2:
Boston Campus,
page 60
Boston
Functionality Test,
page 64
Passed with
exceptions
DDTS/Comments
•
Because of an automated job scheduling
conflict with a data collection tool, 14
hours of test data was not collected. The
test results were not affected.
•
The IXIA traffic generator was turned
off to allow problem-characterization
work on Chariot and was not turned on
until several hours after the start of the
test. There were no problems in the
network and the test results were not
affected.
Passed
—
Network Management, Passed
page 68
—
Multicast, page 69
Passed
—
Security, page 74
Passed
—
Voice, page 75
Passed
—
QoS, page 77
Passed
—
Boston System
Test, page 81
System, page 81
Passed
—
Boston Reliability
Test, page 84
Reliability, page 84
Passed with
exceptions
Washington, D.C.
Test Suite 3:
Washington, D.C. Functionality Test,
Campus with Data page 92
Center, page 89
Basic IP, page 64
Results
Basic IP, page 92
Passed
•
Because of an automated job scheduling
conflict with a data collection tool, 14
hours of test data was not collected. The
test results were not affected.
•
The IXIA traffic generator was turned
off to allow problem-characterization
work on Chariot and was not turned on
until several hours after the start of the
test. There were no problems in the
network and the test results were not
affected.
•
Chariot endpoint station bos-ux1 failed
during the test. Chariot reported the
problem as a bus error in the Sun
workstation that served as bos-ux1 and
did not reflect any problems in the
network. The test results were not
affected.
—
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
18
Test Results Summary
Table 3
Test Results Summary (continued)
Test Suites
Test Suite 4:
Denver Campus,
page 120
Test Category
Tests
Results
DDTS/Comments
Network Management, Passed
page 97
—
Multicast, page 99
Passed
—
Security, page 105
Passed
—
Voice, page 106
Passed
—
QoS, page 109
Passed
—
Washington, D.C.
System Test,
page 112
System, page 112
Passed
—
Washington, D.C.
Reliability Test,
page 116
Reliability, page 116
Passed with
exceptions
Denver
Functionality Test,
page 123
Denver System
Test, page 146
Basic IP, page 124
•
Because of an automated job scheduling
conflict with a data collection tool, 14
hours of test data was not collected. The
test results were not affected.
•
The IXIA traffic generator was turned
off to allow problem-characterization
work on Chariot and was not turned on
until several hours after the start of the
test. There were no problems in the
network and the test results were not
affected.
•
About two-thirds into the test, 2 Chariot
endpoint stations (EPs) failed due to
problems with their network interface
cards. The failures were with the
Chariot EPs and did not reflect any
problems in the network. The test
results were not affected.
Passed
—
Network Management, Passed
page 130
—
Multicast, page 132
Passed
—
Security, page 137
Passed
—
Voice, page 138
Passed
—
QoS, page 141
Passed
—
System, page 146
Passed
—
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
19
Test Results Summary
Table 3
Test Results Summary (continued)
Test Suites
Test Suite 5:
Dallas Campus,
page 154
Test Suite 6:
Remote
Campuses,
page 186
Test Category
Tests
Results
Denver Reliability
Test, page 150
Reliability, page 150
Passed with
exceptions
Dallas
Functionality Test,
page 157
•
Because of an automated job scheduling
conflict with a data collection tool, 14
hours of test data was not collected. The
test results were not affected.
•
The IXIA traffic generator was turned
off to allow problem-characterization
work on Chariot and was not turned on
until several hours after the start of the
test. There were no problems in the
network and the test results were not
affected.
•
An H.323 VoIP traffic generator failed
to start, resulting in a 2-hours delay of
the start of VoIP traffic between the
Denver campus and the remote
campuses. The test results were not
affected.
Passed
—
Network Management, Passed
page 161
—
Multicast, page 163
Passed
—
Security, page 167
Passed
—
Voice, page 170
Passed
—
QoS, page 172
Passed
—
Dallas System Test, System, page 177
page 177
Passed
—
Dallas Reliability
Test, page 181
Passed with
exceptions
Remote
Functionality Test,
page 189
Basic IP, page 157
DDTS/Comments
Reliability, page 181
Basic IP, page 190
Passed
•
Because of an automated job scheduling
conflict with a data collection tool, 14
hours of test data was not collected. The
test results were not affected.
•
The IXIA traffic generator was turned
off to allow problem-characterization
work on Chariot and was not turned on
until several hours after the start of the
test. There were no problems in the
network and the test results were not
affected.
—
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
20
Test Suite Overview
Table 3
Test Results Summary (continued)
Test Suites
Test Category
Tests
Results
DDTS/Comments
Network Management, Passed
page 193
—
Multicast, page 194
Passed
—
Security, page 198
Passed
—
Voice, page 200
Passed
—
QoS, page 202
Passed
—
Remote System
Test, page 206
System, page 206
Passed
—
Remote Reliability
Test, page 211
Reliability, page 211
Passed with
exceptions
•
Because of an automated job scheduling
conflict with a data collection tool, 14
hours of test data was not collected. The
test results were not affected.
•
The IXIA traffic generator was turned
off to allow problem-characterization
work on Chariot and was not turned on
until several hours after the start of the
test. There were no problems in the
network and the test results were not
affected.
•
An H.323 VoIP traffic generator failed
to start, resulting in a 2-hours delay of
the start of VoIP traffic between the
Denver campus and the remote
campuses. The test results were not
affected.
•
One of the multicast clients was turned
off to allow problem-characterization
work on Chariot and was not turned on
until several hours after the start of the
test. There was no multicast traffic
between San Jose and Los Angeles
while the client was off, but there were
no problems in the network and the test
results were not affected.
Test Suite Overview
There were 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 contained three or more feature-specific test
categories that addressed 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 4 lists each test suite, the category of testing conducted in the suite, the feature-specific tests, and
the section that contains detailed topology information.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
21
Test Suite 1: San Jose Campus with Data Center
Table 4
Test Suite Overview
Test Plan Suite
Category of Testing Conducted
Suite 1: San Jose Campus
with Data Center
Suite 2: Boston Campus
Suite 3: Washington, D.C. Campus
with Data Center
Suite 4: Denver Campus
Suite 5: Dallas Campus
Suite 6: Remote Campuses
•
Functionality testing
•
System testing
•
Reliability testing
•
Functionality testing
•
System testing
•
Reliability testing
•
Functionality testing
•
System testing
•
Reliability testing
•
Functionality testing
•
System testing
•
Reliability testing
•
Functionality testing
•
Scalability performance testing
•
System testing
•
Reliability testing
•
Functionality testing
•
System testing
•
Reliability testing
Test Suite Chapter
Test Suite 1: San Jose Campus with
Data Center, page 22
Test Suite 2: Boston Campus,
page 60
Test Suite 3: Washington, D.C.
Campus with Data Center, page 89
Test Suite 4: Denver Campus,
page 120
Test Suite 5: Dallas Campus,
page 154
Test Suite 6: Remote Campuses,
page 186
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 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 comprises five multilayer-design campuses—two large campuses with data
centers and three regional campuses—and ten 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:
•
Functionality testing: This test category verified basic IP functionality. The functionality testing
involved basic IP testing (Layer 2 and HSRP, EIGRP and BGP routing, routing traffic setup and
routing convergence testing, negative testing, and verification and traffic load testing), network
management testing, multicast testing, security testing, voice testing, and QoS testing.
•
System testing: This test category verified system performance, using IP routing, NMS, voice,
multicast, security, and QoS
•
Reliability testing: This test category verified system reliability.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
22
Test Suite 1: San Jose Campus with Data Center
This test suite contains the following sections:
•
Topology Description, page 23
•
San Jose Functionality Test, page 27
•
San Jose System Test, page 53
•
San Jose Reliability Test, page 57
Topology Description
The San Jose campus topology represents a large enterprise headquarters campus with a data center.
The WAN aggregation routers, connecting to the other global enterprise sites and to the ISP, consisted
of two Cisco 7609 Optical Services Routers (OSRs). The WAN aggregation router connecting to the
remote sites was a Cisco 7206VXR router.
Multiple types of high-speed WAN links were used, including OC-3 POS, OC-3 ATM, T1, T3, T3 ATM,
and High-Speed Serial Interface (HSSI). The core of the campus consisted of four Catalyst 6509
switches with dual Multilayer Switch Feature (MSFC2) cards and Policy Feature (PFC2) cards.
High-speed core Layer 3 Gigabit Ethernet (GE) links were used to connect two user buildings and one
data center building. In one building, two Catalyst 6506 switches were used as distribution layer
switches and multiple Catalyst switches, such as the 4003, 5505 and 6506 switches, were used as the
access layer switches. In another building, two Catalyst 4000 switches were used as distribution layer
switches and multiple Catalyst switches, such as the 4006, 4506, and 6506 switches, were used as the
access layer switches. In the data center, two Catalyst 6506 switches were used as distribution layer
switches and multiple Catalyst switches, such as the 5505 and 6506 switches, were used as the access
layer switches. A Cisco 3640 router was used as a VoIP voice gateway, and another Cisco 3640 router
was used as a VoIP gatekeeper for the entire global enterprise topology.
EIGRP was the IP IGP routing protocol and approximately 800 routes were used at various points in the
topology. BGP was the IP EGP routing protocol used for the ISP connection. Global application servers
located at the San Jose campus data center served all campuses within the entire global enterprise
topology.
The simulated database servers (located at the data center of this campus) served this campus and stored
data for the entire global enterprise topology. A redundant database server was included in the
Washington, D.C. campus.
Applications such as voice, RealMedia, FTP, HTTP, and Simple Network Management Protocol (SNMP)
were simulated by Callgen, Chariot, IXIA, and Pagent. The testbed simulated end users by the use of
traffic generators and actual PC and UNIX workstations. IPTV was used to generate multicast traffic.
Figure 3 shows the San Jose campus with data center topology at a high level and includes the names of
the individual routers.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
23
Test Suite 1: San Jose Campus with Data Center
Figure 3
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-v2
Voice gateway and
gatekeeper
egsj-4506-b2d2
egsj-6506-b1d1
egsj-6506-b1d2
egsj-4003-b1a1 egsj-5505-b1a2 egsj-6506-b1a3
egsj-4006-b2a1 egsj-6506-b2a2
Building 1
Building 2
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
24
95533
egsj-4006-b2d1
FE
GE
HSSI(P2P)
POS OC3(P2P)
ATM OC3
T1(P2P)
T3(P2P)
ATM T3
Test Suite 1: San Jose Campus with Data Center
Figure 4 shows the San Jose campus with data center topology at a more detailed level and includes the
interface names.
Figure 4
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
a3/0/0
s2/1/0
g6/3 - g6/3
egsj-5505-sa1
1/1,2
g2/16 - g2/16
g1/1,2
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-6506-sd1
egsj-7609-w2
g1/1,2
f4/1,2
g1/1,2
g1/1,2
egsj-6509-c1
ISP 1
Washington, D.C.
p3/1/0
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-v2
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-4003-b1a1
egsj-6506-b1d2
g1/1
egsj-4506-b2d2
g2/16 - g2/16
g2/1,2,3 egsj-4006-b2d1
1/1,2
1/1,2
egsj-5505-b1a2 egsj-6506-b1a3
2/1,2
egsj-4006-b2a1
1/1,2
egsj-6506-b2a2
FE
GE
HSSI(P2P)
POS OC3(P2P)
ATM OC3
T1(P2P)
T3(P2P)
ATM T3
95534
g1/1,2
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
25
Test Suite 1: San Jose Campus with Data Center
Figure 5 shows the San Jose campus with data center topology with the IP addresses.
Figure 5
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
.1
.1
.21
.2
egsj-6509-c2
. 53
.17
.18
.54
.2
.4
.22
.11
egsj-6506-b1d2
.12
.21
.21
. 22
.1
.18 7
.13
.14
.5 .6
egsj-5505-sa2
4
egsj-6506-sa3
7
.5
8
.5
.8
egsj-6509-c4
.9 .1 0
egsj-6506-b1d1
.9 .10
.102
egsj-6506-sd2
egsj-6509-c1
.5
.6
.3
.2
.1
.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
.9
egsj-3640-gk egsj-3640-v2
egsj-4506-b2d2
.22
Building 2
address range:
1.1.32.0/19
1.2.32.0/19
1.3.32.0/19
96.5.16.0/21
egsj-4006-b2d1
egsj-4006-b2a1 egsj-6506-b2a2
95532
egsj-4003-b1a1 egsj-5505-b1a2 egsj-6506-b1a3
FE
GE
HSSI(P2P)
POS OC3(P2P)
ATM OC3
T1(P2P)
T3(P2P)
ATM T3
Platform and Software Version Information
Table 5 lists the platforms, router names, software versions, and software images configured in the San
Jose network topology for this test suite.
Table 5
San Jose Platform, Router Name, Software Version, and Software Images
Platform
Router Name
Software Version
Software Image
Cisco 7609
egsj-7609-w1
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Cisco 7609
egsj-7609-w2
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Cisco 7206
egsj-7206-w3
12.2(16b)
c7200-jk8s-mz.122-16b
Catalyst 6500
egsj-6509-c1
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Catalyst 6500
egsj-6509-c2
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
26
Test Suite 1: San Jose Campus with Data Center
Table 5
San Jose Platform, Router Name, Software Version, and Software Images (continued)
Platform
Router Name
Software Version
Software Image
Catalyst 6500
egsj-6509-c3
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Catalyst 6500
egsj-6509-c4
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Catalyst 6500
egsj-6506-b1d1
12.1(13)E9
c6msfc2-jsv-mz.121-13.E9
Catalyst 6500
egsj-6506-b1d2
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Catalyst 4000
egsj-4006-b2d1
12.1(13)EW2
cat4000-is-mz.121-13.EW2
Catalyst 4500
egsj-4506-b2d2
12.1(13)EW2
cat4000-is-mz.121-13.EW2
Catalyst 6500
egsj-6506-sd1
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Catalyst 6500
egsj-6506-sd2
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Cisco 3640
egsj-3640-gk
12.2(15)T5
c3640-jsx-mz.122-15.T5
Cisco 3640
egsj-3640-v
12.2(16a)
c3640-a3js-mz.122-16a
Catalyst 5500
egsj-5505-sa1
6.4(3)
cat5000-sup3.6-4-3
Catalyst 5500
egsj-5505-sa2
6.4(3)
cat5000-sup3.6-4-3
Catalyst 6500
egsj-6506-sa3
7.6(1)
cat6000-sup2k8.7-6-1
Catalyst 4000
egsj-4003-b1a1
7.6(1)
cat4000-k8.7-6-1
Catalyst 5500
egsj-5505-b1a2
6.4(3)
cat5000-sup3.6-4-3
Catalyst 6500
egsj-6506-b1a3
7.6(1)
cat6000-sup2k8.7-6-1
Catalyst 4000
egsj-4006-b2a1
7.6(1)
cat4000-k8.7-6-1
Catalyst 6500
egsj-6506-b2a2
7.6(1)
cat6000-sup2k8.7-6-1
San Jose Functionality Test
The functionality test category verified basic IP functionality. The tests are described in the following
sections:
•
Basic IP
•
Network Management
•
Multicast
•
Security
•
Voice
•
QoS
The testing in each section was performed sequentially and as independently as possible. The San Jose
functionality testing was conducted as follows:
1.
Basic IP testing was performed in conjunction with Network Management Testing (NMS). Network
management was utilized to collect the test information.
2.
After completion of the basic IP test, IP configurations were made stable, and any traffic loading
was terminated in preparation for the next test.
3.
Multicast testing was performed, again with NMS monitoring.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
27
Test Suite 1: San Jose Campus with Data Center
4.
After completion of the multicast test, IP configurations were made stable, and any traffic loading
was terminated in preparation for the next test.
5.
Security testing was performed in conjunction with NMS monitoring.
6.
After completion of the security test, IP configurations were made stable, and any traffic loading
was terminated in preparation for the next test.
7.
Voice testing was performed in conjunction with NMS monitoring.
8.
After completion of the voice test, IP configurations were made stable, and any traffic loading was
terminated in preparation for the next test.
9.
QoS testing was performed in conjunction with NMS monitoring.
10. After completion of the QoS test, IP configurations were made stable, and any traffic loading was
terminated in preparation for the next test.
Basic IP
The overall objective of this test case is as follows:
•
Verify the basic network operation (that is, network connectivity).
•
Verify the configurability and stability in a controlled environment for each of the functionality
tests.
•
Verify that the selected Cisco IOS software versions can be loaded into the devices.
•
Verify that the major IP routing features work as expected.
In addition to basic IP, the following features were configured:
•
Layer 2 and HSRP
•
EIGRP and BGP Routing
Layer 2 Protocols and HSRP
This test verified various Layer 2 protocols and HSRP. The following features were included in the test
plan:
•
VLAN Trunking Protocol (VTP) and VLAN
•
Spanning-tree Protocol (STP)
•
HSRP
Test Plan
The procedure used to perform the Layer 2 protocols and HSRP test follows:
Step 1
Set up the VLANs. The access switch VLAN model is model number 1, “share VLANs across Access
Layer switches,” for this campus. Each building is in a separate VTP domain. The two distribution layer
switches work in VTP server mode, and all access layer switches work in VTP transparent mode.
VLAN 1 is for control traffic on all switches by default. VLAN 10 is for a backdoor network connection,
configured only on the access layer switches. VLANs 11 to 20 are used for end-user networks that are
configured across all access switches and the distribution layer switches. VLANs 21 to 110 are used to
generate routes, which are configured only on distribution layer switches.
Step 2
Use the CatOS show vlan command, the CatOS show vtp domain command, and the Cisco IOS show
vtp status command to verify the VTP and VLAN configuration.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
28
Test Suite 1: San Jose Campus with Data Center
Step 3
Set up VLAN trunking. All links between switches are L2 dot1q trunking. The trunk mode is
desirable/desirable.
Step 4
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 5
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 6
Set up HSRP. The left distribution layer switch serves as the HSRP active group for all odd-numbered
VLANs. The right distribution layer switch serves as the HSRP active group for all even-numbered
VLANs. The HSRP interface track feature is turned on so that if both uplinks from any distribution layer
switch to the core go down, the HSRP active group will fail over to the other distribution layer switch.
Step 7
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 8
Conduct a negative test of STP and HSRP. Shut down any one of the distribution switches in the same
building and use the Cisco IOS 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 command to
verify that the HSRP secondary router takes over the active state for all the VLANs.
Expected Results
We expect the following results:
•
The VTP and VLAN configuration will work correctly.
•
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 6 shows the San Jose Layer 2 protocols and HSRP test results.
Table 6
San Jose Layer 2 Protocols and HSRP Test Results
Test
Results
San Jose Layer 2 protocols and HSRP
Passed
EIGRP with BGP Routing
This test involved testing EIGRP with BGP routing. The following features were included in the test
plan:
•
Route summarization
•
Route filtering
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
29
Test Suite 1: San Jose Campus with Data Center
•
EIGRP stub router functionality
•
Route redistribution and default route generation
•
Log event or change functionality
•
BGP policy control (specifically, autonomous system prepend and route filtering)
•
EIGRP metric tuning—link delay and bandwidth
Test Plan
This test verified route summarization, route filtering, route redistribution, EIGRP stub router
functionality, route redistribution and default route generation, log event or change functionality, BGP
policy control, and EIGRP metric tuning. There are several parts to this test plan, and they are described
in the sections that follow.
Route Summarization and Filtering Test
The procedure used to perform the route summarization and filtering 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 building and data center distribution layer routers and voice routers as EIGRP stub
routers, so that the EIGRP queries do not propagate to the distribution layer routers or the voice routers.
Route Redistribution and Default Route Generation Test
The procedure used to perform the route redistribution and default route generation test follows:
Step 1
Configure BGP and EIGRP routing on the campus WAN aggregation routers egsj-7609-w1 and
egsj-7609-w2. BGP will receive ISP advertised routes in addition to intercampus routes.
Step 2
Redistribute BGP into EIGRP and permit only the intercampus routes to be tagged and redistributed into
EIGRP. A static default route will be created by the router connected to the ISP and advertised into the
whole EIGRP AS and will be permitted into remote sites.
A backup static default route will be advertised by the secondary ISP connected router, using a floating
static route. The default route will not be advertised by BGP. Varying metrics will be applied to the routes
being redistributed based on the number of BGP ASs that the intercampus route learned.
BGP Policy Control Test
The procedure used to perform the BGP policy control test follows:
Step 1
Configure logging of changes on all the EIGRP- and BGP-enabled routers by using the Cisco IOS
eigrp log-neighbor-changes command and the bgp log-neighbor-changes command.
Step 2
Configure BGP and EIGRP routing on the campus WAN access router egsj-7609-w2.
Step 3
Redistribute BGP into EIGRP, and permit only internal EIGRP routes to be redistributed.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
30
Test Suite 1: San Jose Campus with Data Center
Step 4
Configure the egsj-7609-w2 BGP policy so that the traffic from the ISP destined for the local campus
prefixes get high priority (by using AS prepending) to the advertised prefixes of the remote campuses.
All intercampus routes will be advertised to the ISP, but the AS will be prepended three times.
Step 5
Leak a 24-bit route to the Chariot endpoints into the remote AS via link POS3/1/0 on egsj-7609-w2. Set
the community attribute to no-advertise on these routes.
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 building 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 microseconds to 50 microseconds. This configuration enables the left distribution layer switch
to advertise a less desirable routing metric to the core routers for all the even-numbered VLAN
interfaces. Similarly configure the right distribution layer switch.
Step 2
Configure all the SVI interfaces on the distribution layer routers as EIGRP passive interfaces.
Step 3
Configure the Cisco IOS no peer neighbor-route command for all the encapsulated PPP WAN
interfaces to avoid suboptimal routing for these WAN interface routes.
Step 4
Analyze the output of the Cisco IOS show commands listed in Table 7, which lists each command and
the role it plays in the EIGRP with BGP routing test.
Table 7
show Commands Used in the EIGRP with BGP Routing Test
Command
show ip route summary
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 or other
memory errors.
show logging
•
Verifies that there are no significant errors for
EIGRP or BGP routing.
show ip bgp summary
•
Verifies that BGP routing is working correctly.
show ip bgp
•
Verifies BGP AS prepending policy control on
the ISP routers.
and
show ip route
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
31
Test Suite 1: San Jose Campus with Data Center
Table 7
show Commands Used in the EIGRP with BGP Routing Test (continued)
Command
Purpose
show interfaces [interface type]
•
Verifies that there are no 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 specific WAN interface routes are
not in the routing table.
Expected Results
We expect the following results:
•
The routes are summarized correctly.
•
The route filters function correctly.
•
CPU utilization is less than 90 percent.
•
Memory consumption is stable.
•
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 significant EIGRP or BGP routing errors and 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 8 shows the San Jose EIGRP with BGP routing test results.
Table 8
San Jose EIGRP with BGP Routing Test Results
Test
Results
San Jose EIGRP with BGP routing
Passed
Traffic Routing Convergence
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:
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
32
Test Suite 1: San Jose Campus with Data Center
Step 1
Set up a continuous ping between two PCs located in two points in the topology. Set the ping packet size
to 512 bytes. Set the ping timeout to 1 sec.
Step 2
During the ping test, make various link-to-router connections fail.
Step 3
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 timeout setting.
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 9 shows the San Jose traffic routing convergence test results.
Table 9
San Jose Traffic Routing Convergence Test Results
Tests
Results
San Jose traffic routing convergence
Passed
Traffic Load Capacity Test
This test was intended to test the network configuration at zero percent of traffic load capacity, at
50 percent of traffic load capacity, and at 90 percent of traffic load capacity 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 percent 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 for WAN links to 100 percent.
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.
Expected Results
We expect that the network configuration continues to function correctly at each level of traffic load
capacity.
Results
Table 10 shows the San Jose traffic load capacity test results.
Table 10
San Jose Traffic Load Capacity Test Results
Test
Results
San Jose traffic load capacity
Passed
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
33
Test Suite 1: San Jose Campus with Data Center
Network Management
This section describes the network management testing in the San Jose campus with data center. The
following features were included in the test plan:
•
MIB Walk automation script (snmp_walk_test) and traps
•
Syslog and NTP
The objectives of the SNMP MIB testing were as follows:
•
Ensure that the information stored in the MIB database can be accessed, propagated, read, and
written if applicable.
•
Ensure that the operation of the OID values reflects the actual operation on the device.
•
Ensure that there were no SNMP traps.
Test Plan
The procedure used to perform the network management test follows:
Step 1
Configure MIB walk and traps.
The MIB Walk automation script (snmp_walk_test) will test the OID and traps by platforms and
technologies, report their value, and monitor the UUT behavior. HP OpenView and CiscoWorks2000 are
used as the SNMP receivers.
Step 2
Configure all the routers and switches so that the snmp_walk_test script will work properly.
Step 3
Upload the following MIBs to the snmp_walk_test script:
•
Basic IP:
– CISCO-VTP-MIB
– CISCO-BGP4-MIB
– CISCO-HSRP-MIB
– CISCO-EIGRP-MIB
•
Multicast:
– CISCO-IPMROUTE-MIB.my
– CISCO-IGMP-MIB.my
– CISCO-MSDP-MIB.my
– CISCO-PIM-MIB.my
•
Voice:
– CISCO-VOICE-DIAL-CONTROL-MIB.my
– CISCO-CCM-MIB
•
QoS:
– CISCO-QOS-MIB
•
Security:
– CISCO-IPSEC-FLOW-MONITOR-MIB
Step 4
Set up the eg-cw2k (CiscoWorks2000) server in the San Jose campus as the UNIX NTP and syslog
server.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
34
Test Suite 1: San Jose Campus with Data Center
Step 5
Use DART to capture show command output from the routers.
Step 6
Use the show processes cpu command to verify the CPU utilization and to verify that the CPU capacity
is not being monopolized by a single router.
Step 7
Use the show memory summary command to verify that there are no memory leaks or errors.
Step 8
On server eg-cw2k, verify that syslogd is still running.
Step 9
Use the Cisco IOS show clock command and the CatOS show time command to verify that the clock is
synchronized with the NTP server.
Step 10
Verify that the Pat scripts are able to send e-mail notification for error conditions on the routers or
switches.
Step 11
Use the show crypto mib ipsec flowmib version command to verify that the device has IPsec MIB
support.
Step 12
Use the show log command or the show align command to verify that there are no other significant
errors.
Step 13
Use the show snmp command to verify the SNMP configuration information.
Expected Results
We expect the following results:
•
Information stored in the MIB can be accessed, propagated, read, and written.
•
Operation of the OID values reflect the actual operation of the device.
Results
Table 11 shows the San Jose network management test results.
Table 11
San Jose Network Management Test Results
Test
Results
San Jose network management
Passed
Multicast
The objective of the San Jose campus with data center multicast testing was to verify the functionality
of multicast features across multiple Cisco platforms with various sets of Cisco IOS and CatOS releases.
The following features were included in the test plan:
•
CGMP
•
IGMP-v2
•
IGMP snooping
•
MMLS
•
MDS-7500 specific feature
•
PIM sparse-dense mode
•
Auto-RP
•
Anycast-RP with Auto-RP
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
35
Test Suite 1: San Jose Campus with Data Center
•
Admin scoping and multicast boundary
•
Multicast Rate Limit
The test was set up to use Cisco IP/TV as a one-to-many video and audio streaming application by
configuring an IP/TV server at the San Jose campus data center to stream six multicast groups. There
were three video and three audio groups.
Test Plan
Setup
The procedure used to set up the multicast test follows:
Step 1
Step 2
Step 3
Configure Cisco IP/TV by performing the following steps:
a.
Connect the IP/TV server to switch egsj-6505-sa3.
b.
Connect the IP/TV clients to the egsj-5505-b1a2 device on the San Jose campus.
c.
Configure the IP/TV server to stream three programs as follows:
•
The first program contains a 239.192.0.1/14 multicast address scope and consists of a 128-kbps
video stream and a 100-kbps audio stream. The IP/TV clients at all campuses and remote sites
will receive this program.
•
The second program contains a 239.255.0.1/16 multicast address scope and consists of a
500-kbps video stream and a 100-kbps audio stream. The IP/TV clients at all campuses will
receive this program.
•
The third program contains a 239.194.0.1/14 multicast address scope and consists of a
1500-kbps video stream and a 100-kbps audio stream. Only the IP/TV client at the San Jose
campus will receive this program.
Enable CGMP on the following San Jose campus Layer 2 access switches:
•
egsj-5505-b1a2
•
egsj-5505-sa1
•
egsj-5505-sa2
•
egsj-4003-b1a1
•
egsj-4006-b2a1
Enable CGMP on the Layer 3 distribution switches on the following campuses:
•
San Jose
•
Denver
•
Boston
Step 4
Enable IGMP-v2. This feature is enabled by default in Native IOS and Cisco IOS software, so no
additional configuration is required.
Step 5
Enable IGMP snooping on the egsj-6506-sa3 San Jose campus Layer 2 switch.
This feature is enabled by default in Native IOS, so no additional configuration for Layer 3 is required.
Step 6
Enable MMLS. This feature is enabled by default in Native IOS, so no additional configuration is
required.
Step 7
Enable PIM sparse-dense mode on all Layer 3 Native IOS and Cisco IOS multicast devices.
Step 8
Enable Anycast-RP with Auto-RP on the following RP routers:
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
36
Test Suite 1: San Jose Campus with Data Center
Step 9
•
egsj-6506-sd1
•
egwas-6506-sd1
Enable multicast admin scoping and multicast boundary on the following devices:
•
San Jose campus—egsj-7609-w1, egsj-7609-w2, and egsj-7206-w3
•
Washington, D.C campus—egwas-7505-w3
•
Dallas campus—egdal-7507-w4
Verification
The procedure used to perform the multicast verification test follows:
Step 1
Use DART to capture the output of the generic show commands listed in Table 12.
Table 12
Generic show Commands Used in the San Jose Multicast Verification Test
Command
Purpose
•
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 or other
memory errors.
show buffer failure
•
Verifies a buffer or memory failure.
show interfaces [interface type]
•
Verifies that there are no input errors, output
errors, or queue drops.
•
Verifies the router's throughput.
•
Verifies that there are no other significant errors.
show processes cpu
show logging
Step 2
Using the show commands listed in Table 13, verify that CGMP is communicated among routers and
switches to dynamically join or leave a multicast group on a LAN segment.
Table 13
show Commands Used in the San Jose Multicast CGMP Verification Test
Command
Step 3
Purpose
show cgmp statistics
•
Displays the CGMP statistics.
show cgmp leave
•
Verifies the status of the CGMP leave feature.
show multicast router
•
Displays the ports that have IGMP or
RGMP-capable routers assigned to them.
show multicast group
•
Verifies the multicast group information.
show multicast group cgmp
•
Displays the multicast group configuration
information learned via CGMP.
Using the show commands listed in Table 14, verify that IGMPv2 is communicated among routers and
switches to dynamically register or leave a multicast group on a LAN segment. In addition, verify the
following:
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
37
Test Suite 1: San Jose Campus with Data Center
•
The router with the lower IP address is the correct IGMP querier.
•
The router installs group members upon receipt of IGMP join messages.
•
All groups are seen for all IGMP joined groups.
•
The router sends PIM join messages as a consequence of receiving IGMP join messages and creates
the corresponding (*,G) entries.
Table 14
show Commands Used in the San Jose Multicast IGMPv2 Verification Test
Command
Step 4
Purpose
show ip igmp interface
•
Verifes that IGMP v2 is communicated among
routers and hosts to dynamically register or
leave a multicast group on a LAN segment.
show ip igmp groups
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
Using the show commands listed in Table 15, verify that IGMP snooping functions as follows:
•
IGMP snooping manages multicast traffic at Layer 2 by configuring the Layer 2 LAN port
dynamically to forward multicast traffic to only those ports that want to receive it.
•
IGMP snooping constrains multicast traffic that exits through LAN ports to which hosts are
connected.
Table 15
show Commands Used in the San Jose Multicast IGMP Snooping Verification Test
Command
Purpose
show igmp statistics
On Layer 2 switches:
•
show multicast group igmp
On Layer 2 switches:
•
show multicast group count igmp
Verifies that the correct multicast router has
been learned.
On Layer 3 switches:
•
Step 5
Verifies that IGMP snooping is globally
enabled.
On Layer 3 switches:
•
show mac-address-table multicast vlan-id
Verifies the total count of multicast addresses
(groups) in a VLAN learned via IGMP.
On Layer 3 switches:
•
show ip igmp snooping mrouter
Verifies the multicast group configuration
information learned via IGMP.
On Layer 2 switches:
•
show ip igmp interface
Verifies the IGMP statistics for a particular
VLAN.
Verifies that the correct multicast addresses are
present in the output.
Using the show commands listed in Table 16, verify that MMLS functions as follows:
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
38
Test Suite 1: San Jose Campus with Data Center
•
Multicast flows create MMLS entries and switching of the flow is performed using hardware
shortcuts. In the Catalyst 6500s, the flows are taking the correct paths.
•
The flows are using the expected multicast forwarding entry (*,G) or (S,G).
•
Hardware-based flows are created where expected.
•
The lowest rate of the traffic flow at which a hardware shortcut is created is identified.
•
CPU utilization does not increase. If it does, then there is a possibility that flows are being software
switched.
•
On DFC cards, forwarding tables on line cards are the same as on the processor card.
Table 16
show Commands Used in the San Jose Multicast MMLS Verification Test
Command
Step 6
Purpose
show mls ip multicast summary
•
Verifies that hardware-based flows are created
where expected.
show mls ip multicast
•
Verifes that multicast flows create MMLS
entries and that switching of the flow is
performed.
show mls ip multicast group
•
Displays multilayer IP multicast group
information.
show mls ip multicast source
•
Displays the MLS IP information for a specific
destination IP address.
show mls ip multicast interface
•
Displays the MLS IP information for a specific
interface.
show mls ip multicast statistics
•
Displays the statistics for the MLS IP multicast
entries.
Using the show commands listed in Table 17, verify that multicast distributed switching (MDS)
functions as follows:
•
The VIP interfaces on Cisco 7500 routers are MDS-enabled.
•
Multicast distributed switching is enabled.
•
Multicast traffic is distributed-switched.
Table 17
show Commands Used in the San Jose Multicast MDS Verification Test
Command
Step 7
Purpose
show ip mds interface
•
Verifies the status of MDS interfaces.
show ip pim interface detail
•
Displays detailed information about each
interface configured for Protocol Independent
Multicast (PIM).
show ip mds forwarding
•
Verifies the MFIB table and forwarding
information for MDS.
show ip mds summary
•
Displays a summary of the MFIB table for
MDS.
Using the show commands listed in Table 18, verify that PIM sparse-dense mode functions as follows:
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
39
Test Suite 1: San Jose Campus with Data Center
•
Multicast forwarding is achieved using PIM. PIM interacts with the IP unicast forwarding table to
determine the correct path to the source of the multicast packets (RPF), and interacts with IGMP to
recognize networks that have members of the multicast group.
•
All expected PIM neighbors are present and no unknown routers appear.
•
The correct DR election is made on the LAN segment.
•
The correct IIF and OIF lists, RPF, and flags are present in the (*,G) or (S,G) entries.
•
The correct RP mapping is shown for all groups.
Table 18
show Commands Used in the San Jose Multicast PIM Sparse-Dense Mode Verification
Test
Command
Step 8
Purpose
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
show ip pim rp mapping
•
Verifies all the group-to-RP mappings of which
the router is aware (either configured or learned
from Auto-RP).
show ip pim rp
•
Verifies that the active rendezvous points (RPs)
are cached with the associated multicast routing
entries.
show ip mroute
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
show ip mroute count
•
Displays statistics about the group and source,
including number of packets, packets per
second, average packet size, and bytes per
second.
Using the show commands listed in Table 19, verify that Anycast-RP with Auto-RP functions as follows:
•
Auto-RP dynamically updates the RP information in every device in the network.
•
Traffic for the two Auto-RP groups 224.0.1.39 and 224.0.1.40 are dense-mode flooded network.
•
All routers learn about RP mapping information.
•
The correct RP mapping is shown for the specified group.
•
The RP mapping information is consistent through the network.
•
Anycast RP information is distributed to the routers and no multicast groups are reverting to dense
mode.
•
MSDP peers are operational.
•
There is an SA cache entry for each source.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
40
Test Suite 1: San Jose Campus with Data Center
Table 19
show Commands Used in the San Jose Multicast Anycast-RP with Auto-RP Verification
Test
Command
Step 9
Purpose
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip pim interface count
•
Verifies the switching counts for MDS and other
fast-switching statistics.
show ip mroute count
•
Displays statistics about the group and source,
including number of packets, packets per
second, average packet size, and bytes per
second.
show ip mroute
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
show ip pim rp
•
Verifies that the active rendezvous points (RPs)
are cached with the associated multicast routing
entries.
show ip pim rp mapping
•
Verifies all the group-to-RP mappings of which
the router is aware (either configured or learned
from Auto-RP).
show ip msdp peer
•
Verifies that MSDP peers are operational.
show ip msdp sa-cache
•
Verifies that there is an SA cache entry for each
source.
Using the show commands listed in Table 20, verify that admin scoping and multicast boundary
functions as follows:
•
RP messages are prevented from traveling beyond the boundaries of the network using multicast
boundaries.
•
Routers within the TTL number of hops from the source RP mapping agent receive the Auto-RP
discovery messages.
•
Routers learn about correct RP mapping information within the TTL range.
•
Routers out of the TTL range cannot receive the Auto-RP Discovery messages.
•
A border router with a multicast boundary configured will not leak Auto-RP messages out of the
network.
•
Multicast traffic cannot be forwarded out of the defined admin scope.
Table 20
show Commands Used in the San Jose Admin Scoping and Multicast Boundary
Verification Test
Command
Purpose
show ip pim rp mapping
•
Verifies all the group-to-RP mappings of which
the router is aware (either configured or learned
from Auto-RP).
show ip pim rp
•
Verifies that the active rendezvous points (RPs)
are cached with the associated multicast routing
entries.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
41
Test Suite 1: San Jose Campus with Data Center
Table 20
show Commands Used in the San Jose Admin Scoping and Multicast Boundary
Verification Test (continued)
Command
Step 10
Purpose
show ip mroute count
•
Displays statistics about the group and source,
including number of packets, packets per
second, average packet size, and bytes per
second.
show ip mroute
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
Using the show commands listed in Table 21, verify that multicast rate limit functions as follows:
•
The rate that a sender can send to a multicast group in the group list is appropriate.
•
Multicast traffic can be forwarded out of the WAN interface with the rate setup.
•
IP/TV receives an acceptable video stream from the server.
Table 21
show Commands Used in the San Jose Multicast Rate Limit Verification Test
Command
Purpose
show ip mroute count
•
Displays statistics about the group and source,
including number of packets, packets per
second, average packet size, and bytes per
second.
show ip mroute
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
show ip pim interface count
•
Verifies the switching counts for MDS and other
fast-switching statistics.
Expected Results
We expect the following results:
•
CGMP is communicated among routers and switches to dynamically join or leave a multicast group
on a LAN segment.
•
IGMPv2 is communicated among routers and hosts to dynamically register or leave a multicast
group on a LAN segment.
•
IGMP snooping manages multicast traffic at Layer 2 by configuring Layer 2 LAN ports dynamically
to forward multicast traffic to only those ports that want to receive it.
•
IGMP snooping constrains multicast traffic that exits through LAN ports to which hosts are
connected.
•
Multicast flows create MMLS entries and switching of the flow is performed using hardware
shortcuts in the Catalyst 6500.
•
Multicast forwarding is achieved using PIM.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
42
Test Suite 1: San Jose Campus with Data Center
•
Auto-RP dynamically updates the RP information in every device in the network.
•
Anycast RP information is distributed to the routers and none of the multicast groups reverts to
dense mode.
•
Routers learn RP mapping information within the defined TTL number of hops and multicast flows
are restrained in the TTL range.
•
RP messages are prevented from traveling beyond the boundaries of the network by using multicast
boundaries.
•
The rate that a sender from the source list can send to a multicast group in the group list is
appropriate.
Results
Table 22 shows the San Jose multicast test results.
Table 22
San Jose Multicast Test Results
Test
Results
San Jose multicast
Passed
Security
This security test was conducted for the San Jose campus with data center. This test catagory verified
the functionality of AAA and SNMP features commonly used by enterprise customers that integrate
across multiple Cisco platforms and Cisco IOS releases at the system level.
The objectives of the security test were as follows:
•
Verify TACACS+ and AAA services at a system level for all access, distribution, core, and WAN
edge devices in the global topology.
The following features were configured for the security test:
•
AAA and TACACS+
•
IPSec certificate server
•
Other security commands
Test Plan
Setup
The procedure used to set up the San Jose security test follows:
Step 1
Configure encryption service facility and AAA and TACACS+.
Step 2
Configure the time-stamping service facility for logging.
Step 3
Disable all unnecessary services.
Step 4
Configure an enable password.
Step 5
Configure a console port password.
Step 6
Configure an AUX port password, if applicable.
Step 7
Disable CDP on edge interfaces that do not require it.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
43
Test Suite 1: San Jose Campus with Data Center
Step 8
Configure a warning banner.
Step 9
Configure all CatOS devices for security.
Verification
The procedure used to perform the San Jose security verification test follows:
Step 1
Use the show tacacs command to verify the TACACS+ configuration values.
Step 2
Use the show accounting command to verify the user account on the router and switch.
Step 3
Verify the Passed Authentication report from the Cisco Secure ACS.
Step 4
Verify the TACACS Account report from the Cisco secure ACS.
Step 5
Verify the Failed Attempts report from the Cisco secure ACS.
Expected Results
We expect the following results:
•
TACACS+ AAA services function properly at a system level for all access, distribution, core, and
WAN edge devices in the global topology.
Results
Table 23 shows the San Jose security test results.
Table 23
San Jose Security Test Results
Test
Results
San Jose security
Passed
Voice
The purpose of the voice test was to deploy and verify the VoIP deployment scenarios for large
Enterprise customers that want to minimize the operations cost of telephony by utilizing IP telephony
over traditional services. The overall objectives of the voice test case were as follows:
•
Verify that voice can be incorporated into the San Jose campus.
•
Verify the operation of the Cisco IOS release to test the AVVID and legacy voice interoperability.
•
Collect and document the test results.
•
Ensure that the system behaves as expected.
The following features and equipment were tested:
•
Centralized CallManager architecture
•
Gateways: VG200 and ATA186
•
Call setup and control: H.323 and SCCP
•
Codec: G.729 over WAN, G.711 over LAN, transcoding
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
44
Test Suite 1: San Jose Campus with Data Center
•
Equipment facility capabilities: In-line power on Catalyst 6000, Catalyst 4000, Access Gateway
Module on Catalyst 4000, Vespa, SRST
•
Equipment Interoperability: Analog on Catalyst 6000, Catalyst 4000, T1 blade
Voice Testing
The following features were configured for voice testing:
•
Legacy H.323 VoIP
•
SCCP
Test Plan
The voice test verified that voice traffic operated properly accross the network.
Set Up Legacy H.323
The procedure used to set up the legacy H.323 voice test follows:
Step 1
Configure the H.323 voice gateway egsj-3660-v for T1 CAS and FXS.
Step 2
Check that egwas-3640-v1 is registered with gatekeeper egsj-3640-gk in the San Jose campus by using
the show gateway command on the egwas-3660-v1 router.
Step 3
Configure Callgen telephony.
Step 4
Check that egsj-3640-v is registered with gatekeeper egsj-3640-gk in the San Jose campus by using the
show gateway command on the egsj-3640-v router.
Set Up SCCP
The procedure used to set up the SCCP voice test follows:
Step 1
Configure T1 CAS and FXS SCCP voice gateways on the Catalyst 6506.
Step 2
Configure T1 CAS and FXS SCCP voice gateways on the Catalyst 4507.
Step 3
Configure inline power and real IP telephones on the Catalyst 6506.
Step 4
Configure inline power and real IP telephones on the Catalyst 4507.
Step 5
Verify that the T1 CAS, the FXS, any transcoding devices, and all real or simulated IP telephones on the
Catalyst 6506 and Catalyst 4507 appear and are registered in CallManager.
Step 6
Configure Callgen SCCP to generate test traffic.
Step 7
The WS-X6608-T1/E1 blade is used as a T1 or E1 gateway in egsj-6506-b1d1-sup. It uses the Skinny
protocol to communicate with the Cisco CallManager server to set up and tear down calls. Use the set
port voice interface dhcp disable tftp gateway command to disable DHCP on a port and assign IP
parameters manually.
Step 8
The WS-X6624 is used in egsj-6506-b1d1-sup and has a single MAC address and a single IP address.
Use the set port voice interface dhcp disable tftp gateway command to disable DHCP on a port and
assign IP parameters manually.
The IP address, IP default gateway, and TFTP server address parameters can be configured manually or
they can be configured dynamically from a DHCP server. This test uses manually configured (static)
parameters.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
45
Test Suite 1: San Jose Campus with Data Center
Step 9
The Catalyst 4000 8-port RJ21 FXS module for the access gateway module is a high-density analog
phone and fax relay interface. VoIP gateway is the default mode for the access gateway module. Before
you can use the conferencing and transcoding services, you must enable the IP telephony gateway mode,
configure the services, and reboot.
Step 10
Enable IP telephony gateway mode by using the voicecard sccp manager command.
Step 11
Enable IP telephony transcoding service by using the voicecard transcode command.
A transcoder is a device that takes the output stream of one codec and transcodes (converts) it from one
compression type to another compression type. For example, a transcoder could take an output stream
from a G.711 codec and transcode (convert) it in real time to a G.729 input stream accepted by a G.729
codec. Transcoders for this Cisco CallManager release transcode between G.711, G.723, and G.729
codecs. Use the set port voice interface dhcp disable tftp gateway command to disable DHCP on a
port and assign IP parameters manually.
Step 12
Configure the VG200 and ATA186 voice ports with H.323.
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 use to perform the voice traffic verification test follows:
Step 1
Configure an IP phone manually, install it in each campus, and make calls to test voice quality.
Step 2
Start the bulk call traffic generators by performing the following steps:
a.
Start all BCG channels to Washington (19 calls), Boston (4 calls), Dallas (3 calls), Denver (13 calls),
and Los Angeles (10 calls). Note: Refer to the dial plan and voice design document.
b.
Using the show channel command on the Callgens, verify for 5 minutes that all originate and
terminate BCG channels have started and are progressing correctly with no problems.
Step 3
Verify for 5 minutes that all originate and terminate Callgen SCCP endpoints have started and are
progressing correctly with no problems.
Step 4
Analyze the output of the show commands listed in Table 24. Use the listed commands on all the WAN
routers using the DART tool every 60 seconds for the show processes cpu command, and every
5 minutes for all the others—for a duration of 2 hours.
Table 24
show Commands Used for the Voice Traffic Verification Test
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Verifies 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 24 were used on the WAN routers and interfaces listed in Table 25.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
46
Test Suite 1: San Jose Campus with Data Center
Table 25
Step 5
Step 6
San Jose WAN Routers and Interfaces
Router
Interface
egsj-7609-w1
ATM3/1/0, Serial3/0/0, POS4/1/0
egsj-7609-w2
Serial3/1/0/1, ATM3/0/0
egsj-7206-w3
Serial4/0/1:0, Serial4/0/0:0, ATM4/1/0.768
Capture voice quality information by performing the following steps:
a.
Use the show channel command of the Callgen testing tool to verify that the Callgen channels to
Washington, D.C. (19 calls), Boston (4 calls), Dallas (3 calls), Denver (13 calls), and Los Angeles
(10 calls) are functioning correctly.
b.
Use CIC to measure the call attempts and 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 generators and verify results by performing the following steps:
a.
Stop Callgen after 1 hour of run time.
b.
Use the show channel command of the Callgen testing tool to verify that all originate and terminate
BCG channels are functioning correctly without any significant errors.
c.
Capture the output statistics of Callgen by using CIC.
d.
Use Performance monitor to check real time the number of gateways and IP Phones registered and
CDR on the CallManager to also check the percentage of successful calls.
Expected Results
We expect the following results:
•
Voice traffic was sent efficiently and all voice channels originated and terminated properly.
•
All originate and terminate BCG channels work properly and without any significant errors.
•
All Callgen SCCP calls completed.
Results
Table 26 shows the San Jose voice traffic verification test results.
Table 26
San Jose Voice Traffic Verification Test Results
Test
Results
San Jose voice traffic verification
Passed
QoS
The high-level objective of the QoS testing was to validate a robust QoS solution for protecting critical
application data, including real-time VoIP, on interarea WAN links, including classification and marking
as close to the network edge as possible, and remarking from L2 CoS to L3 ToS.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
47
Test Suite 1: San Jose Campus with Data Center
QoS Setup Test
The QoS setup test verified that QoS features were configured correctly and that the QoS features were
applied to traffic classes as anticipated. In this test, the MQC three-step model was used to configure the
traffic classes, class maps, and policy maps.
The following features were included in the test plan:
•
Classification and Marking: Access lists, NBAR, table maps, IP precedence, and DSCP
•
Congestion avoidance: dWRED (differentiated services-based WRED)
•
Congestion Management: LLQ and dLLQ
•
Traffic Conditioning: GTS and ATM Traffic Shaping
•
Link efficiency Mechanisms: MLPPP LFI, cRTP, and dcRTP
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 on the distribution layer switches (egsj-6509-b1d1,
egsj-6509-b1d2, egsj-4006-b2d1, and egsj-4506-b2d2) using the following guidelines:
•
Classify VoIP traffic into a class map called “Real-Time.”
•
Classify applications with small or infrequently sent packets, such as Telnet and voice signaling,
into a class map called “Interactive.”
•
Classify the mission-critical traffic or traffic that can consume large amounts of bandwidth, such as
Lotus Notes and Oracle, into a class map called “Transactional.”
•
Classify IP/TV multicast video conferencing and multicast signaling into the “Streaming” class.
•
Classify HTTP and FTP traffic into the “class-default” class.
Associate the policy maps and actions with each class of traffic by performing the following steps:
a.
Configure a policy map called "IN-bound" on distribution layer switches egsj-6509-b1d1,
egsj-6509-b1d2, egsj-4006-b2d1, and egsj-4506-b2d2. This configuration tests the DSCP feature.
b.
Configure a policy map called "OUT-bound-XXX" on the core switches egsj-6509-C1,
egsj-6509-C2, egsj-6509-C3, and egsj-6509-C4. This configuration tests the LLQ feature of QoS.
c.
Configure a policy map called "OUT-bound-XXX" on intercampus WAN aggregation routers
egsj-7609-w1, and egsj-7609-w2. This configuration tests the dWRED and LLQ features of QoS.
d.
Configure a policy map called "OUT-bound-XXX" on campus-remote WAN aggregation router
egsj-7204-w3. This configuration tests the MLPP LFI, cRTP, and dTS features of QoS.
e.
Configure a policy map called “OUT-Voice” on the egsj-3640-v router. This configuration tests the
access lists, port numbers, and DSCP features of QoS.
Attach policy maps to the interfaces listed in Table 27, and apply the other appropriate QoS features.
Table 27 shows the router name, the policy map created, and the interface to which the policy map was
applied (attached).
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
48
Test Suite 1: San Jose Campus with Data Center
Table 27
Routers, Policy Maps, and Interfaces for the QoS Setup Test
Router
Policy Map
Interface
egsj-7609-w2
OUT-WAN-HW1
Serial2/0/0
egsj-7609-w2
OUT-WAN-HW2
P3/1/0
egsj-7609-w2
OUT-LAN-FE
Fa4/1, Fa4/2
egsj-7609-w2
OUT-LAN-GE
Gi1/1, Gi1/2
egsj-7609-w1
OUT-WAN-HW7
H2/0/0
egsj-7609-w1
OUT-LAN-GE
Gi1/1, Gi1/2, Gi6/3
egsj-7206-w3
OUT-LAN-FE
Fa1/0, Fa2/0
egsj-7206-w3
OUT-WAN-DT1
Serial4/0:0
egsj-6506-b1d1
OUT-LAN-GE
Vlan11, Vlan12, Vlan13, Vlan18,
Vlan19, Vlan20, Vlan800, Vlan801
egsj-6506-b1d2
OUT-LAN-GE
Gi1/1, Gi1/2
egsj-4006-b2d1
OUT-LAN-GE
Gi1/1, Gi1/2, Gi2/1, Gi2/2
egsj-4506-b2d2
OUT-LAN-GE
Gi1/1, Gi1/2, Gi2/1, Gi2/2
egsj-6509-c1
OUT-LAN-GE
Gi3/1, Gi3/2, Gi3/3, Gi3/11, Gi3/12,
Gi3/15, Gi3/16
egsj-6509-c1
OUT-LAN-FE
Fa6/1
egsj-6509-c2
OUT-LAN-GE
G3/1, 3/2, 3/3, 3/11, 3/12, 3/15, 3/16
egsj-6509-c2
OUT-LAN-FE
Fa6/1
egsj-6509-c3
OUT-LAN-GE
Gi3/1, Gi3/2, Gi3/3, Gi3/14, Gi3/15,
Gi3/16
egsj-6509-c4
OUT-LAN-GE
Gi3/1, Gi3/2, Gi3/3, Gi3/14, Gi3/15,
Gi3/16
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 28 shows the San Jose QoS setup test results.
Table 28
San Jose QoS Setup Test Results
Test
Results
San Jose QoS setup
Passed
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
49
Test Suite 1: San Jose Campus with Data Center
QoS Verification Test
This test verified that incoming and outgoing 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, data traffic was 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 Chariot traffic testing tool to congest the network.
Step 2
Analyze the output of the Cisco IOS show commands listed in Table 29. The show processes cpu
command was used every 30 seconds for 2 hours. The other commands were used every 5 minutes for
2 hours.
Table 29
show Commands Used on the WAN Aggregation Routers and Interfaces
Command
Purpose
show clock
•
Verifies the current time.
show policy-map interface [interface name]
•
Verifies that data traffic in the Real-Time class
gets 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 shaped rate is dropped.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
show ip rtp header compression
•
Verifies that IP RTP header compression is
turned on and if there are any errors.
The show commands listed in Table 29 were used on the WAN aggregation routers and interfaces listed
in Table 30.
Table 30
Step 3
San Jose WAN Aggregation Routers and Interfaces
Router
Interface
egsj-7209-w1
ATM2/1/0
egsj-7209-w2
Serial2/0/0, ATM3/0/0, POS3/1/0
egsj-7206-w3
Serial4/0:0
Analyze the output of the Cisco IOS show commands listed in Table 31. The show processes cpu
command was used every 30 seconds for 2 hours. The other commands were used every 5 minutes for
2 hours.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
50
Test Suite 1: San Jose Campus with Data Center
Table 31
show Commands Used on the Core Switches and Interfaces
Command
Purpose
show clock
•
Verifies the current time.
show policy-map interface [interface name]
•
Verifies that data traffic in the Real-Time class
gets 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 shaped rate is dropped.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
The show commands listed in Table 31 were used on the core switches and interfaces listed in Table 32.
Table 32
Step 4
San Jose Core Switches and Interfaces
Router
Interface
egsj-6509-c1
Gi3/1, Gi3/2, Gi3/3, Gi3/15, Gi3/16
egsj-6509-c2
Gi3/1, Gi3/2, Gi3/3, Gi3/15, Gi3/16
egsj-6509-c3
Gi3/1, Gi3/2, Gi3/3, Gi3/16
egsj-6509-c4
Gi3/1, Gi3/2, Gi3/3, Gi3/16
Analyze the output of the Cisco IOS show commands listed in Table 33. The show processes cpu
command was used every 30 seconds for 2 hours. The other commands were used every 5 minutes for
2 hours.
Table 33
show Commands Used on the Distribution Layer Switches and Interfaces
Command
Purpose
show clock
•
Verifies the current time.
show policy-map interface [interface name]
•
Verifies that data traffic in the Real-Time class
gets 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 shaped rate is dropped.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
The show commands listed in Table 33 were used on the distribution layer switches and interfaces listed
in Table 34.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
51
Test Suite 1: San Jose Campus with Data Center
Table 34
Step 5
San Jose Distribution Layer Switches and Interfaces
Router
Interface
egsj-6506-b1d1
Gi2/1, Gi2/2, Gi2/3, Gi2/16
egsj-6506-b1d2
Gi2/1, Gi2/2, Gi2/3, Gi2/16
egsj-4006-b2d1
Gi2/1, Gi2/1, Gi2/16
egsj-4506-b2d2
Gi2/1, Gi2/1, Gi2/16
egsj-6506-sd1
Gi2/1, Gi2/2, Gi2/3, Gi2/16
egsj-6506-sd2
Gi2/1, Gi2/2, Gi2/3, Gi2/16
Analyze the output of the show commands listed in Table 35. The show processes cpu command was
used every 30 seconds for 2 hours. The other commands were used every 5 minutes for 2 hours.
Table 35
show Commands Used on the Access Layer Switches and Interfaces
Command
Purpose
show clock
•
Verifies 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 shaped rate is dropped.
The show commands listed in Table 35 were used on the access layer switches and interfaces listed in
Table 36.
Table 36
Step 6
San Jose Access Layer Switches and Interfaces
Router
Interface
egsj-4003-b1a1
Gi2/1, Gi2/2
egsj-5505-b1a2
Gi1/1, Fa2/2
egsj-6505-b1a3
Gi1/1, Gi1/2
egsj-4006-b2a1
Gi2/1, Gi2/2
egsj-6505-b2a2
Gi1/1, Gi1/2
Analyze the output of the Cisco IOS show commands listed in Table 37 after the two-hour test referred
to in Step 2 is completed. These commands were used on all the WAN routers and core switches.
Table 37
show Commands Used for the QoS Verification Test
Command
show class-map
Purpose
•
Verifies that the class map configured for the
device is displayed.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
52
Test Suite 1: San Jose Campus with Data Center
Table 37
show Commands Used for the QoS Verification Test (continued)
Command
Step 7
Purpose
show policy-map
•
Verifies that the policy map configured for the
device is displayed.
show access-lists
•
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 two-hour test
referred to in Step 2 is completed.
Expected Results
We expect the following results:
•
CPU utilization was always less than 90 percent.
•
No system or feature errors (such as router or switch crashes, reloads, or CPU hogs) occurred during
testing.
•
No significant errors occurred, such as memory allocation errors, memory access errors, memory
leaks, or unexpected interface toggles.
•
Routing tables correctly reflected all available supernets and subnets.
•
All client/server traffic traversed from source to destination through the expected route for the
duration of the test.
•
Routes converged correctly without major delay.
Results
Table 38 shows the San Jose QoS verification test results.
Table 38
San Jose QoS Verification Test Results
Test
Results
San Jose QoS verification
Passed
San Jose System Test
The overall objectives of this test case were as follows:
•
Verify that the IP routing, SNMP, security, multicast, VoIP, and QoS features could be incorporated
into the San Jose campus.
•
Verify the successful operation of the Cisco IOS release.
•
Verify that the system behaved as expected.
This test category verified system performance using IP routing, SNMP, security, multicast, VoIP, and
QoS. The features that were configured for the San Jose functionality test were carried over to this test.
The following additional features were configured in this test case:
•
BGP 4
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
53
Test Suite 1: San Jose Campus with Data Center
•
CBWFQ
•
PQ
•
MLPPP performance enhancements
•
CEF support for IP routing
•
CGMP
•
dCBWFQ
•
dLLQ
•
dTS
•
dWRED
•
GTS
•
HSRP
•
IEEE 802.1Q VLAN support
•
IGMP MIB support enhancements for SNMP
•
IGMP snooping querier
•
IGMP version 2
•
IPSec certificate server
•
MD5 password encryption
•
PIM version 2
•
QoS enhancements
•
RTP header compression
•
LLQ
•
TACACS+
•
VoIP
•
WRED
Test Plan
The procecure used to perform the San Jose system test follows:
Step 1
Start the traffic streams for 100 percent of the traffic load as follows:
a.
Start the BCG (Callgen) to generate calls.
b.
Start Chariot to simulate NetMeeting, Telnet, Lotus, Oracle, FTP, and HTTP traffic.
c.
Start IP/TV, for multicast traffic.
d.
Start IXIA, for background traffic.
Step 2
Use DART to capture information from the routers for four hours.
Step 3
Analyze the output of the Cisco IOS show commands listed in Table 39 at the start and end of the
four-hour test.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
54
Test Suite 1: San Jose Campus with Data Center
Table 39
show Commands Used for the San Jose System Test Start and End View
Command
Step 4
Purpose
show vtp status
•
Verifies that the VTP feature is enabled.
show vlan brief
•
Verifies VLAN status and port assignments.
show memory summary
•
Verifies that there are no memory leaks or
errors.
show ip bgp summary
•
Verifies the BGP routes.
show ip eigrp neighbors detail
•
Verifies that the remote WAN routers are
EIGRP stub-enabled.
show ip eigrp interface
•
Verifies if the EIGRP adjacent neighbor count
is higher than the neighbor count. If so, the
neighbor list could be corrupted.
show interfaces
•
Verifies that there are no input or output errors
or queue drops.
•
Verifies the routers’ throughput.
show clock
•
Verifies that the clock is synchronized with the
NTP server.
show buffer failure
•
Verifies a buffer or memory failure.
show ip igmp interface
•
Verifes that IGMP v2 is communicated among
routers and hosts to dynamically register or
leave a multicast group on a LAN segment.
show ip igmp groups
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
show mac-address-table multicast vlan vlan-id
•
Verifies that the correct multicast addresses
are present in the output.
show mls ip multicast
•
Verifes that multicast flows create MMLS
entries and that switching of the flow is
performed.
show tacacs
•
Verifies that you are logging in to the correct
TACACS+ server.
show accounting
•
Verifies the user account on the router and
switches with privilege 15.
show gateway
•
Verifies that the voice gateway is connected to
gatekeeper egsj-3640-GK.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface that was configured by the
virtual template.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
Analyze the output of the Cisco IOS show commands listed in Table 40 at 60-minute intervals.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
55
Test Suite 1: San Jose Campus with Data Center
Table 40
show Commands Used for the San Jose System Test 60-Minute View
Command
Step 5
Purpose
show interface trunk
•
Verifies that the VLAN trunkings are formed
correctly.
show ip route summary
•
Verifies the current state of the routing table.
show memory summary
•
Verifies that there are no memory leaks or
errors.
show ip eigrp neighbors
•
Verifies the remote WAN routers.
show policy interface
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy maps.
show ip rtp header compression
•
Verifies that IP RTP header compression is
enabled for the voice traffic and if there are
any errors.
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip mroute summary
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
Analyze the output of the Cisco IOS show command listed in Table 41 at 10-minute intervals.
Table 41
show Command Used for the San Jose System Test 10-Minute View
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
•
Verifies that CPU capacity is not being
monopolized by a single router.
Expected Results
We expect the following results:
•
CPU utilization was always less than 90 percent.
•
No system or feature errors (such as router or switch crashes, reloads, or CPU hogs) occurred during
testing.
•
No significant errors occurred, such as memory allocation errors, memory access errors, memory
leaks, or unexpected interface toggles.
•
Routing tables correctly reflected all available supernets and subnets.
•
All client/server traffic traversed from source to destination through the expected route for the
duration of the test.
•
Routes converged correctly without major delay.
Results
Table 42 shows the San Jose system test results.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
56
Test Suite 1: San Jose Campus with Data Center
Table 42
San Jose System Test Results
Test
Results
San Jose system
Passed
San Jose Reliability Test
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 IP routing, NMS, voice,
multicast, security, and QoS features enabled.
The following additional features were configured in this test category:
•
BGP 4
•
CBWFQ
•
PQ
•
MLPPP performance enhancements
•
CEF support for IP routing
•
CGMP
•
dCBWFQ
•
dLLQ
•
dTS
•
dWRED
•
GTS
•
HSRP
•
IEEE 802.1Q VLAN support
•
IGMP MIB support enhancements for SNMP
•
IGMP snooping querier
•
IGMP version 2
•
IPSec certificate server
•
MD5 password encryption
•
PIM version 2
•
QoS enhancements
•
RTP header compression
•
LLQ
•
TACACS+
•
VoIP
•
WRED
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
57
Test Suite 1: San Jose Campus with Data Center
The objective of this test case was to verify that the software (at 100 percent traffic load capacity on each
WAN link) performed reliably for the 150-hour test period.
Test Plan
The procedure used to perform the San Jose reliability test follows:
Step 1
Start traffic streams for a 100 percent traffic load by performing the following steps:
a.
Start the BCG (Callgen) to generate calls.
b.
Start Chariot to simulate NetMeeting, Telnet, Lotus, Oracle, FTP, and HTTP traffic.
c.
Start IP/TV, for multicast traffic.
d.
Start IXIA, for background traffic.
Step 2
Use DART to capture information from the routers for 150 hours.
Step 3
Analyze the output of the Cisco IOS show commands listed in Table 43 at the start and end of the
150-hour test period.
Table 43
show Commands Used for the San Jose Reliability Test Start and End View
Command
Purpose
show vtp status
•
Verifies that the VTP feature is enabled.
show vlan brief
•
Verifies VLAN status and port assignments.
show memory summary
•
Verifies that there are no memory leaks or
errors.
show ip bgp summary
•
Verifies the BGP routes.
show ip eigrp neighbors detail
•
Verifies that the remote WAN routers are
EIGRP stub-enabled.
show ip eigrp interface
•
Verifies if the EIGRP adjacent neighbor count
is higher than the neighbor count. If so, the
neighbor list could be corrupted.
show interfaces
•
Verifies that there are no input or output errors
or queue drops.
•
Verifies the routers’ throughput.
show clock
•
Verifies that the clock is synchronized with
the NTP server.
show buffer failure
•
Verifies a buffer or memory failure.
show ip igmp interface
•
Verifes that IGMP v2 is communicated among
routers and hosts to dynamically register or
leave a multicast group on a LAN segment.
show ip igmp groups
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
show mac-address-table multicast vlan vlan-id
•
Verifies that the correct multicast addresses
are present in the output.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
58
Test Suite 1: San Jose Campus with Data Center
Table 43
show Commands Used for the San Jose Reliability Test Start and End View (continued)
Command
Step 4
Purpose
show mls ip multicast
•
Verifes that multicast flows create MMLS
entries and that switching of the flow is
performed.
show tacacs
•
Verifies that you are logging in to the correct
TACACS+ server.
show accounting
•
Verifies the user account on the router and
switches with privilege 15.
show gateway
•
Verifies that the voice gateway is connected to
gatekeeper egsj-3640-GK.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface that was configured by the
virtual template.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
Analyze the output of the Cisco IOS show commands listed in Table 44 at 24-hour intervals.
Table 44
show Commands Used for the San Jose Reliability Test 24-Hour View
Command
Step 5
Purpose
show interface trunk
•
Verifies that the VLAN trunkings are formed
correctly.
show ip route summary
•
Verifies the current state of the routing table.
show memory summary
•
Verifies that there are no memory leaks or
errors.
show ip eigrp neighbors
•
Verifies the remote WAN routers.
show policy interface
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy maps.
show ip rtp header compression
•
Verifies that IP RTP header compression is
enabled for the voice traffic and if there are
any errors.
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip mroute summary
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
Analyze the output of the Cisco IOS show command listed in Table 45 at 6-hour intervals.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
59
Test Suite 2: Boston Campus
Table 45
show Commands Used for the San Jose Reliability Test 6-Hour View
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
•
Verifies that CPU capacity is not being
monopolized by a single router.
Expected Results
We expect that the software (at 100 percent traffic load capacity on each WAN link) performs reliably
during the 150-hour test period.
Results
Table 46 shows the San Jose reliability test results.
Table 46
San Jose Reliability Test Results
Test
Results
San Jose reliability
Passed with exceptions
Passed with Exceptions Explanation
The San Jose reliability test passed with exceptions for the following reasons:
•
Because of an automated job scheduling conflict with a data collection tool, 14 hours of test data
was not collected. The test results were not affected.
•
The IXIA traffic generator was turned off to allow problem-characterization work on Chariot and
was not turned on until several hours after the start of the test. There were no problems in the
network and the test results were not affected.
Test Suite 2: Boston Campus
This test suite consisted of three test cases intended to verify the functionality, reliability, and
performance of basic IP QoS at the Boston campus.
The Boston campus is one component of the larger global enterprise topology. The global enterprise
topology comprises five multilayer-design campuses—two large campuses with data centers and three
regional campuses—and ten 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 Boston campus, the following categories (or types) of testing were conducted:
•
Functionality testing: This test category verified basic IP functionality. The test involves Layer 2
protocols—VTP, VLAN trunking, Layer 3 protocol for EIGRP as the interior routing protocol and
BGP as exterior routing protocol, SNMP, multicast, security, VoIP, QoS, convergence, and negative
testing.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
60
Test Suite 2: Boston Campus
•
System testing: This test category verified system performance, using IP routing, NMS, voice,
multicast, security, and QoS
•
Reliability testing: This test category verified system reliability.
This test suite contains the following sections:
•
Topology Description, page 61
•
Boston Functionality Test, page 64
•
Boston System Test, page 81
•
Boston Reliability Test, page 84
Topology Description
The Enterprise Global Boston testbed represents a small enterprise campus that would be located in a
North American region. The WAN routers connecting to the other global enterprise sites and to the
Internet consist of two Cisco 7206VXR NPE-400 WAN routers and one Cisco 7206VXR NPE-G1 WAN
router running Serial P2P and ATM links. The campus also consists of a GE and an FE LAN. There are
two Catalyst 6506s, each with an MSFC2/PFC2 in the core, and which also provide the distribution layer
functionality. One Catalyst 6506 and two Catalyst 4006s make up the access layer. A Cisco 2651 router
is used as a VoIP voice gateway that registers into a gatekeeper located at San Jose headquarters, and
which places real VoIP calls to other gateways located at different campuses.
The test beds are used to perform the test for functionality, which includes IP routing, SNMP, multicast,
security, VoIP, and QoS. EIGRP is the IP IGP routing protocol and route generators inject a total of five
simulated subnets at various points in the topology. Global application servers are located at the WAN
regional aggregation routers to the remote campuses. Applications such as voice, NetMeeting, FTP, and
HTTP are simulated by Chariot and other traffic-generating test tools. Each remote campus will simulate
end users through the use of traffic generators and real Linux and UNIX workstations.
Figure 6 shows the Boston campus topology with IP addresses.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
61
Test Suite 2: Boston Campus
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
ISP 3
.69
96.1.0.68
ebgos-7206-w2
221.10.0.2/32
.2
.13
.17
.21
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
T1 (P2P)
T3
GE
FE
ebgos-4006-a3
76330
Figure 6
bos-pc3
1.17.1.100
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
62
Test Suite 2: Boston Campus
Figure 7 shows the Boston campus topology with interface types.
Figure 7
Boston Campus Topology with Interface Types
bos-pc1
ebgos-7206-w1
s4/0
San Jose
fa2/0
fa3/0
Washinton, D.C.
s3/0
fa1/0
fa1/0
g3/5
fa4/0
g1/1
fa3/16
bos-ux1
g1/2
g3/13
fa4/14
fa2/0
ebgos-7206-w2
fa3/14
ebgos-6506-c1
fa4/25
g3/11
fa0/0
s6/0:0
ISP 3
ebgos-6506-a1
bos-pc2
g3/15
g3/1
ebgos-4006-a2
fa1/0
fa5/14
g1/1
g1/2
ebgos-2651-v1
New York
128
fa4/14
ISDN BRI
ATM/FR
fa1/0
bri6/0
s3/0:0
fa4/16
bos-ux2
g3/1 g3/11
fa4/25
g2/0
bos-pc3
g3/13
g1/1
g3/15
g1/2
ebgos-7206-w3
fa5/16
fa2/14
fa2/16
ebgos-6506-c2
ebgos-4006-a3
T1 (P2P)
T3
GE
FE
bos-ux3
95535
Pittsburgh
Platform and Software Version Information
Table 47 lists the platforms, router names, software versions, and software images configured in the
Boston network topology for this test suite.
Table 47
Boston Platform, Router Name, Software Version, and Software Images
Platform
Router Name
Software Version
Software Image
Cisco 7206
egbos-7206-w1
12.2(16b)
c7200-js-mz.122-16b
Cisco 7206
egbos-7206-w2
12.2(16b)
c7200-js-mz.122-16b
Cisco 7206
egbos-7206-w3
12.2(15)T5
c7200-js-mz.122-15.T5
Cisco 2651
egbos-2651-v1
12.2(16b)
c2600-js-mz.122-16b
Catalyst 6500
egbos-6506-c1
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Catalyst 6500
egbos-6506-c2
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Catalyst 6500
egbos-6506-a1
7.6(1)
cat6000-sup2k8.7-6-1
Catalyst 4000
egbos-4006-a2
7.6(1)
cat4000-k8.7-6-1
Catalyst 4000
egbos-4006-a3
7.6(1)
cat4000-k8.7-6-1
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
63
Test Suite 2: Boston Campus
Boston Functionality Test
The functionality test category verified basic IP functionality and the tests are described in the following
sections:
•
Basic IP
•
Network Management
•
Multicast
•
Security
•
Voice
•
QoS
Basic IP
The overall objective of the basic IP test case was as follows:
•
Verify the basic network operation (that is, network connectivity).
•
Verify the configurability and stability in a controlled environment for each of the functionality
tests.
•
Verify that the selected software versions can be loaded into the devices.
•
Verify that the major IP routing features work as expected.
The following features were included in the test plan:
•
VTP and VLAN
•
VLAN trunking
•
STP
•
HSRP
•
Routing summarization
•
Route filtering
•
EIGRP stub router
•
Route redistribution and default route generation
•
Log event or change
•
BGP policy control
•
Tuning EIGRP routing metric via link delay and bandwidth
•
Route convergence
Test Plan
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).
The procedure used to perform the Boston campus basic IP test follows:
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
64
Test Suite 2: Boston Campus
Step 1
Set up the VLANs. The access switch VLAN model is “unique VLANs per Access Layer switches” for
this campus. The entire building is in a standalone VTP domain. All switches work in VTP transparent
mode.
VLAN 1 is for control traffic on all switches by default. VLAN 10 is for a backdoor network connection,
configured only on the access layer switches. Five unique VLANs are assigned per access layer switches
in addition to VLANs 1 and 2. VLANs 11 to 15 are for the first access layer switch, VLANs 16 to 20 are
for the second access layer switch, VLANs 21 to 25 are for the third access layer switch, and so on.
VLANs 1 and 2 are filtered on the trunk link to make Layer 2 loop free. VLANs 26 to 110 are used to
generate routes, which are configured only on core layer switches.
Step 2
Set up VLAN trunking. The links between access layer switches and core layer switches are L2 dot1q
trunking. The trunk mode is desirable/desirable. Th link between core layer switches is L3 P2P.
Step 3
Set up the STP feature in case a misconfiguration causes a Layer 2 loop. STP portfast is enabled on all
access switches end-user ports. All other STP features are on by default.
Step 4
Set up HSRP. Switch egbos-6506-c1 serves as the HSRP active group for all odd-numbered VLANs.
Switch egbos-6506-c2 serves as the HSRP active group for all even-numbered VLANs. HSRP preempt
is used to ensure that the high-priority group is the active group. Load balancing is per VLAN.
Step 5
Set up route summarization. Boston is a small campus in a single building. The network is organized into
three layers: WAN access, L3 core, and L2 access, with distribution being done in the core. The Boston
WAN router connects to two remote sites, with a routing summarization ratio of about 10 to 1.
Configure WAN routers egbos-7206-w1 and egbos-7206-w2 to summarize the end-user networks within
the building to /20 and /21 prefixes. Summarize the campus devices interconnectivity and loopback
routes into one /21 route. These summarizations are done on the WAN links connected to the remote
sites. Configure WAN regional aggregation router egbos-7206-w3 to summarize the end-users networks
in the building to /20 and /21 prefixes. Summarize the campus devices interconnectivity and loopback
routes into one /21 route. These summarizations are done on the WAN links connected to the remote
sites. Configure WAN regional aggregation router egbos-7206-w3 to summarize routes to the remote
sites to one /21 route for each remote site group and apply statements to the LAN interfaces of
egbos-7206-w3. Auto-summary is turned off.
Step 6
For route filtering, configure a distribution list on WAN aggregation router egbos-7206-w3 to allow only
local summarized routes and default routes to be advertised out to the remote sites.
Step 7
Configure the voice router to be a stub router.
Step 8
Configure BGP and EIGRP routing on WAN access router egbos-7206-w2. BGP will acquire the default
route from ISP3. Redistribute BGP into EIGRP and permit the default route and the intercampus routes
to be redistributed into EIGRP. Redistribute untagged EIGRP routes into BGP.
Step 9
Configure eigrp log-neighbor-changes under router eigrp 2 on all the WAN routers.
Step 10
BGP AS 64502 is used for the Boston campuses' AS border routers. Routes to SJ and WAS are filtered
through egbos-7206-w1 and egbos-7206-w2 by the route-map. This default route and the intercampus
routes are redistributed into EIGRP for the connection to ISP3 from the Boston campus. Configure
egbos-7206-w1 and egbos-7206-w2 BGP for inter-BGP routing.
Step 11
On egbos-7206-w3, change the bandwidth of Bri6/0 to 128 kbps. Adjust the bandwidth command to
match the QoS bandwidth settings.
Step 12
Verify the test setup by analyzing the output of the Cisco IOS show commands listed in Table 48.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
65
Test Suite 2: Boston Campus
Table 48
show Commands Used for the Boston Basic IP Test Verification
Command
Purpose
show trunk (CatOS)
•
Verifies that the VLAN trunkings are formed
correctly.
show vtp status
•
Verifies that the VTP feature is enabled.
show vlan brief
•
Verifies VLAN status and port assignments.
show ip route
•
Verifies that the routes are summarized as
expected.
•
Verifies that the routing filters work as
expected.
•
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 or
errors.
show log
•
Verifies that there are no other significant
errors for EIGRP routing.
show vlan
•
Verifies the VTP and VLAN configurations.
•
Verifies that each core router is the the active
HSRP router for half of the VLANs.
show interface trunk
and
show ip route summary
show processes cpu
show vtp domain (CatOS)
show vtp status
show standby brief
Step 13
Conduct a negative HSRP test by shutting down or disconnecting the uplink from egbos-6506-a1 to
egbos-6506-c1. Use the show standby brief command to verify that the HSRP active group fails over
to egbos-6506-c2. Bring the uplink back up to verify that the HSRP active group switches back on.
Step 14
Analyze the output of the Cisco IOS show commands listed in Table 49.
Table 49
Additional show Commands Used for the Boston Basic IP Test Verification
Command
show ip route
Purpose
•
Verifies that the routes are summarized as
expected.
•
Verifies that the routing filters work as
expected.
•
Verifies that the closest path to ISP3 is used
for the traffic from or destined to the campus.
and
show ip route summary
show interfaces
For all the WAN routers:
•
Verifies that there are no input or output errors
or queue drops.
•
Verifies the routers’ throughput.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
66
Test Suite 2: Boston Campus
Table 49
Additional show Commands Used for the Boston Basic IP Test Verification (continued)
Command
Purpose
show ip eigrp neighbors detail
On router egbos-7206-w3:
•
show ip bgp
On router egsj-7609-w2:
and
•
Verifies the BGP route filtering.
show ip route
•
Verifies the network reachability to ISP3.
and
•
Verifies BGP AS policy control on the ISP
routers.
ping
Step 15
Verifies that the router is stub-enabled.
Verify route convergence by performing the following steps:
a.
Use the show ip route command to verify that all simulated routes exists.
b.
Set up continuous 512-byte pings between the bos-ux3 PC and the hou-ux1 PC in the topology. Set
the ping timeout to 1 sec.
c.
During the pinging, fail the egbos-7206-w2 link.
d.
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 timeout.
e.
Restore the failed link.
f.
After the link is up, repeat steps b through e with bos-ux3 PC and phx-ux1 PC by failing
egbos-7206-w1.
Expected Results
We expect the following results:
•
The selected software versions can be loaded into the devices.
•
The major IP routing features work as expected.
•
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 HSRP 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.
•
The spanning tree roots on the distribution switches work correctly.
Results
Table 50 shows the Boston basic IP test results.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
67
Test Suite 2: Boston Campus
Table 50
Boston Basic IP Test Results
Test
Results
Boston basic IP
Passed
Network Management
This section describes the network management testing in the Boston campus. The following features
were included in the test plan:
•
MIB walk (snmp_walk_test) and traps
•
Syslog and NTP
The objectives of the SNMP MIB testing were as follows:
•
Ensure that the information stored in the MIB database can be accessed, propagated, read, and
written if applicable.
•
Ensure that the operation of the OID values reflects the actual operation on the device.
•
Ensure that there were no SNMP traps.
Test Plan
The procedure used to perform the network management test follows:
Step 1
Configure MIB walk and traps.
MIB walk will test the OID and traps by platforms and technologies, report their value, and monitor the
UUT behavior. HP OpenView and CiscoWorks2000 are used as the SNMP receivers.
Step 2
Configure all the routers and switches so that the MIB Walk script will work properly.
Step 3
Upload the following MIBs to the MIB Walk script:
•
Basic IP:
– OLD-CISCO-CPU-MIB
– CISCO-PROCESS-MIB
– OLD-CISCO-INTERFACE-MIB
– OLD-CISCO-ENV-MIB
– OLD-CISCO-MEMORY-MIB
– CISCO-EIGRP-MIB
– CISCO-OSPF-MIB
•
Multicast:
– CISCO-IPMROUTE-MIB
– CISCO-IGMP-MIB
– CISCO-PIM-MIB
•
Voice:
– CISCO-VOICE-DIAL-CONTROL-MIB
– CISCO-CCM-MIB
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
68
Test Suite 2: Boston Campus
•
QoS:
– CISCO-QOS-MIB
Step 4
Set up the eg-cw2k (CiscoWorks2000) server in the San Jose campus as the UNIX NTP and syslog
server.
Step 5
Use DART to capture show command output from the routers.
Step 6
Use the show processes cpu command to verify the CPU utilization and to verify that the CPU capacity
is not being monopolized by a single router.
Step 7
Use the show memory summary command to verify that there are no memory leaks or errors.
Step 8
On server eg-cw2k, verify that syslogd is still running.
Step 9
Use the Cisco IOS show clock command to verify that the clock is synchronized with the NTP server.
Step 10
Verify that the Pat scripts are able to send email notification for error conditions on the routers or
switches.
Step 11
Use the show log command or the show align command to verify that there are no other significant
errors.
Step 12
Use the show snmp command to verify the SNMP configuration information.
Expected Results
We expect the following results:
•
Information stored in the MIB can be accessed, propagated, read, and written.
•
Operation of the OID values reflect the actual operation of the device.
Results
Table 51 shows the Boston network management test results.
Table 51
Boston Network Management Test Results
Test
Results
Boston network management
Passed
Multicast
The objective of the Boston campus multicast testing was to verify the functionality of multicast features
across multiple Cisco platforms with various sets of Cisco IOS and CatOS releases.
The following features were included in the test plan:
•
CGMP
•
IGMP-v2
•
IGMP snooping
•
PIM sparse-dense mode
The test was set up to use Cisco IP/TV as a one-to-many video and audio streaming application by
configuring an IP/TV server at the San Jose campus data center to stream six multicast groups. There
were three video and three audio groups.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
69
Test Suite 2: Boston Campus
Test Plan
Setup
The procedure used to set up the multicast test follows:
Step 1
Configure Cisco IP/TV by performing the following steps:
a.
Connect the IP/TV server to switch egsj-6505-sa3.
b.
Connect the IP/TV client to switch egden-6506-a1.
c.
Configure the IP/TV server to stream three programs as follows:
•
The first program contains a 239.192.0.1/14 multicast address scope and consists of a 128-kbps
video stream and a 100-kbps audio stream. The IP/TV clients at all campuses and remote sites
will receive this program.
•
The second program contains a 239.255.0.1/16 multicast address scope and consists of a
500-kbps video stream and a 100-kbps audio stream. The IP/TV clients at all campuses will
receive this program.
•
The third program contains a 239.194.0.1/14 multicast address scope and consists of a
1500-kbps video stream and a 100-kbps audio stream. Only the IP/TV client at the San Jose
campus will receive this program.
Step 2
Enable CGMP on the egbos-4006-a3 Boston campus Layer 2 access switch.
Step 3
Enable IGMP-v2. This feature is enabled by default in Native IOS and Cisco IOS software, so no
additional configuration is required.
Step 4
Enable IGMP snooping on the egbos-6506-a1 Boston campus Layer 2 switch. This feature is enabled by
default in Native IOS, so no additional configuration for Layer 3 is required.
Step 5
Enable PIM sparse-dense mode on all Boston campus Layer 3 Native IOS and Cisco IOS multicast
devices.
Verification
The procedure used to perform the multicast verification test follows:
Step 1
Use DART to capture the output of the generic show commands listed in Table 52.
Table 52
Generic show Commands Used in the Boston Multicast Verification Test
Command
Purpose
•
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 or other
memory errors.
show buffer failure
•
Verifies a buffer or memory failure.
show processes cpu
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
70
Test Suite 2: Boston Campus
Table 52
Generic show Commands Used in the Boston Multicast Verification Test (continued)
Command
Purpose
show interfaces [interface type]
show logging
Step 2
•
Verifies the router's throughput.
•
Verifies that there are no other significant errors.
show Commands Used in the Boston Multicast CGMP Verification Test
Command
Purpose
show cgmp statistics
•
Displays the CGMP statistics.
show cgmp leave
•
Verifies the status of the CGMP leave feature.
show multicast router
•
Displays the ports that have IGMP or
RGMP-capable routers assigned to them.
show multicast group
•
Verifies the multicast group information.
show multicast group cgmp
•
Displays the multicast group configuration
information learned via CGMP.
Using the show commands listed in Table 54, verify that IGMPv2 is communicated among routers and
switches to dynamically register or leave a multicast group on a LAN segment. In addition, verify the
following:
•
The router with the lower IP address is the correct IGMP querier.
•
The router installs group members upon receipt of IGMP join messages.
•
All groups are seen for all IGMP joined groups.
•
The router sends PIM join messages as a consequence of receiving IGMP join messages and creates
the corresponding (*,G) entries.
Table 54
show Commands Used in the San Jose Multicast IGMPv2 Verification Test
Command
Step 4
Verifies that there are no input errors, output
errors, or queue drops.
Using the show commands listed in Table 53, verify that CGMP is communicated among routers and
switches to dynamically join or leave a multicast group on a LAN segment.
Table 53
Step 3
•
Purpose
show ip igmp interface
•
Verifes that IGMP v2 is communicated among
routers and hosts to dynamically register or
leave a multicast group on a LAN segment.
show ip igmp groups
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
Using the show commands listed in Table 55, verify that IGMP snooping functions as follows:
•
IGMP snooping manages multicast traffic at Layer 2 by configuring the Layer 2 LAN port
dynamically to forward multicast traffic to only those ports that want to receive it.
•
IGMP snooping constrains multicast traffic that exits through LAN ports to which hosts are
connected.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
71
Test Suite 2: Boston Campus
Table 55
show Commands Used in the Boston Multicast IGMP Snooping Verification Test
Command
Purpose
show igmp statistics
On Layer 2 switches:
•
show multicast group igmp
On Layer 2 switches:
•
show multicast group count igmp
Verifies that the correct multicast router has
been learned.
On Layer 3 switches:
•
Step 5
Verifies that IGMP snooping is globally
enabled.
On Layer 3 switches:
•
show mac-address-table multicast vlan-id
Verifies the total count of multicast addresses
(groups) in a VLAN learned via IGMP.
On Layer 3 switches:
•
show ip igmp snooping mrouter
Verifies the multicast group configuration
information learned via IGMP.
On Layer 2 switches:
•
show ip igmp interface
Verifies the IGMP statistics for a particular
VLAN.
Verifies that the correct multicast addresses are
present in the output.
Using the show commands listed in Table 56, verify that PIM sparse-dense mode functions as follows:
•
Multicast forwarding is achieved using PIM. PIM interacts with the IP unicast forwarding table to
determine the correct path to the source of the multicast packets (RPF), and interacts with IGMP to
recognize networks that have members of the multicast group.
•
All expected PIM neighbors are present and no unknown routers appear.
•
The correct DR election is made on the LAN segment.
•
The correct IIF and OIF lists, RPF, and flags are present in the (*,G) or (S,G) entries.
•
The correct RP mapping is shown for all groups.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
72
Test Suite 2: Boston Campus
Table 56
show Commands Used in the Boston Multicast PIM Sparse-Dense-Mode Verification Test
Command
Purpose
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
show ip pim rp mapping
•
Verifies all the group-to-RP mappings of which
the router is aware (either configured or learned
from Auto-RP).
show ip pim rp
•
Verifies that the active rendezvous points (RPs)
are cached with the associated multicast routing
entries.
show ip mroute
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
show ip mroute count
•
Displays statistics about the group and source,
including number of packets, packets per
second, average packet size, and bytes per
second.
Expected Results
We expect the following results:
•
CGMP is communicated among routers and switches to dynamically join or leave a multicast group
on a LAN segment.
•
IGMPv2 is communicated among routers and hosts to dynamically register or leave a multicast
group on a LAN segment.
•
IGMP snooping manages multicast traffic at Layer 2 by configuring Layer 2 LAN ports dynamically
to forward multicast traffic to only those ports that want to receive it.
•
IGMP snooping constrains multicast traffic that exits through LAN ports to which hosts are
connected.
•
Multicast forwarding is achieved using PIM.
Results
Table 57 shows the Boston multicast test results.
Table 57
Boston Multicast Test Results
Test
Results
Boston multicast
Passed
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
73
Test Suite 2: Boston Campus
Security
This security test was conducted for the Boston campus. This test catagory verified the functionality of
AAA and SNMP features commonly used by enterprise customers that integrate across multiple Cisco
platforms and Cisco IOS releases at the system level.
The objectives of the security test were as follows:
•
Verify TACACS+ AAA services at a system level for all access, distribution, core, and WAN edge
devices in the global topology.
The following features were configured for the security test:
•
AAA and TACACS+
•
Other security commands
Test Plan
Setup
The procedure used to set up the Boston security test follows:
Step 1
Configure encryption service facility and AAA and TACACS+.
Step 2
Configure the times-stamping service facility for logging.
Step 3
Disable all unnecessary services.
Step 4
Configure an enable password.
Step 5
Configure a console port password.
Step 6
Configure a vty password.
Verification
The procedure used to perform the Boston security verification test follows:
Step 1
Use the show tacacs command to verify the TACACS+ configuration values.
Step 2
Use the show accounting command to verify the user account on the router and switch.
Expected Results
We expect the following results:
•
TACACS+ AAA services function properly at a system level for all access, distribution, core, and
WAN edge devices in the global topology.
Results
Table 58 shows the Boston security test results.
Table 58
Boston Security Test Results
Test
Results
Boston security
Passed
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
74
Test Suite 2: Boston Campus
Voice
The purpose of the Boston voice test was to verify that voice can be incorporated into the Boston campus,
to verify the successful operation of the Cisco IOS release, to test AVVID and legacy voice
interoperability, to collect and document the necessary results, and to verify that the system functions as
expected.
The following features were configured for voice testing:
•
Legacy H.323 VoIP
•
SCCP
Test Plan
The voice test verified that voice traffic operated properly across the network.
Set Up Legacy H.323
The procedure used to set up the legacy H.323 voice test follows:
Step 1
Configure the H.323 voice gateway egbos-2651-v1.
Step 2
Check that egbos-2651-v1 is registered with gatekeeper egsj-3640-gk in the San Jose campus by using
the show gateway command on the egbos-2651-v1 router.
Step 3
Configure Callgen telephony.
Set Up SCCP
The procedure used to set up the SCCP voice test follows:
Step 1
Configure T1 CAS and FXS SCCP voice gateways on the Catalyst 4006.
Step 2
Configure inline power and real IP telephones on the Catalyst 4006.
Step 3
Verify that the T1 CAS, the FXS, any transcoding devices, and all real or simulated IP telephones on the
Catalyst 4006 appear and are registered in CallManager.
Step 4
Configure Callgen SCCP to generate test traffic.
Step 5
Enable IP telephony gateway mode on the Catalyst 4006.
Step 6
Use the set port voice interface dhcp disable tftp gateway command to disable DHCP on a port and
assign IP parameters manually.
Step 7
Configure Callgen telephony.
Voice Traffic Verification Test
This test verified that incoming and outgoing voice traffic is handled properly on the network.
Test Plan
The procedure use to perform the voice traffic verification test follows:
Step 1
Start all BCG channels to Boston (2 calls).
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
75
Test Suite 2: Boston Campus
Step 2
Using the show channel command on the Callgens, verify for 5 minutes that all originate and terminate
BCG channels have started and are progressing correctly with no problems.
Step 3
Verify for 5 minutes that all originate and terminate Callgen SCCP endpoints have started and are
progressing correctly with no problems.
Step 4
Analyze the output of the show commands listed in Table 59. Use the listed commands on all the WAN
routers using the DART tool every 60 seconds for the show processes cpu command, and every
5 minutes for all the others—for a duration of 1 hour.
Table 59
show Commands Used for the Boston Campus Voice Traffic Verification Test
Command
Purpose
show clock
•
show interfaces [interface type]
Verifies the current time.
On all outbound WAN interfaces:
•
Verifies the link speed and drop rate.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
The show commands listed in Table 59 were used on the WAN routers and interfaces listed in Table 60.
Table 60
Boston WAN Routers and Interfaces
Router
Interface
egbos-7206-w1
Serial4/0
egbos-7206-w2
Serial3/0
egbos-7206-w3
Serial3/0:0
Step 5
Use the show channel command of the Callgen testing tool to verify that all originate and terminate
BCG channels function properly, without any significant errors.
Step 6
Verify for 5 minutes that all originate and terminate Callgen SCCP endpoints have started and are
progressing correctly with no problems.
Step 7
Stop the bulk call traffic generators and verify results by performing the following steps:
Step 8
a.
Stop Callgen SCCP endpoints after 1 hour of run time.
b.
Use the show channel command of the Callgen testing tool to verify that all originate and terminate
BCG channels are functioning correctly without any significant errors.
c.
Capture the output statistics of Callgen by using CIC.
d.
Capture the output statistics of Callgen SCCP endpoints.
e.
Use Performance monitor to check real time the number of gateways and IP phones registered and
CDR on the CallManager to also check the percentage of successful calls.
Configure an IP phone manually, install it in each campus, and make calls to test voice quality.
Expected Results
We expect the following results:
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
76
Test Suite 2: Boston Campus
•
Voice traffic sent efficiently and all voice channels originated and terminated properly.
•
All originate and terminate BCG channels work properly and without any significant errors.
Results
Table 61 shows the Boston voice traffic verification test results.
Table 61
Boston Voice Traffic Verification Test Results
Test
Results
Boston voice traffic verification
Passed
QoS
The high-level objective of the QoS testing was to validate a robust QoS solution for protecting critical
application data, including real-time VoIP, on interarea WAN links, including classification and marking
as close to the network edge as possible, and remarking from L2 CoS to L3 ToS.
The following features were included in the test plan:
•
Classification and marking: access lists, DSCP values, port numbers, IP precedence, and NBAR
•
Congestion management: CBWFQ and LLQ
•
Traffic conditioning: FRTS and GTS
•
Link efficiency mechanisms: cRTP and MLP interleaving
QoS Setup Test
The QoS setup test verified that QoS features were configured correctly and that the QoS features were
applied to traffic classes as anticipated. In this test, the 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
Perform L2CoS to L3QoS remarking on the egbos-6506-a1, egbos-4006-a2, and egbos-4006-a3 access
layer switches.
Step 2
Define the access lists and traffic classes using the following guidelines:
Step 3
•
Classify VoIP traffic into a class map called “Real-Time.”
•
Classify applications with small or infrequently sent packets, such as Telnet and voice signaling,
into a class map called “Interactive.”
•
Classify the mission-critical traffic or traffic that can consume large amounts of bandwidth, such as
Lotus Notes and Oracle, into a class map called “Transactional.”
•
Classify IP/TV multicast video conferencing and multicast signaling into the “Streaming” class.
•
Classify HTTP and FTP traffic into the “class-default” class, which is the class map for best-effort
service.
Associate the policy maps and actions with each class of traffic by performing the following steps:
a.
Configure a policy map called “OUT-Voice” on the egbos-2651-v1 router.
b.
Configure a policy map called "IN-bound" on egbos-7206-w1 and egbos-7206-w2.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
77
Test Suite 2: Boston Campus
c.
Step 4
Configure a policy map called "out-bound-dt1" on egbos-7206-w3.
Attach policy maps to the interfaces listed in Table 62, and apply the other appropriate QoS features.
Table 62 shows the router name, the policy map created, and the interface to which the policy map was
applied (attached).
Table 62
Routers, Policy Maps, and Interfaces for the Boston QoS Setup Test
Router
Policy Map
Interface
egbos-2651-v1
OUT-VOICE
Fa0/1
egbos-7206-w1
OUT-LAN-FE
Fa1/0, Fa2/0, Fa3/0
egbos-7206-w1
OUT-WAN-HW1
Serial4/0
egbos-7206-w2
OUT-LAN-FE
Fa0/0, Fa1/0, Fa2/0
egbos-7206-w2
OUT-WAN-HW4
Serial3/0
egbos-7206-w2
OUT-LAN-FE
Fa1/0, Fa2/0
egbos-7206-w3
OUT-WAN-DT5
Serial3/0: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 63 shows the Boston QoS setup test results.
Table 63
Boston QoS Setup Test Results
Test
Results
Boston QoS setup
Passed
QoS Verification Test
This test verified that incoming and outgoing 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, data traffic was 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 Chariot traffic testing tool to congest the network.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
78
Test Suite 2: Boston Campus
Step 2
Analyze the output of the Cisco IOS show commands listed in Table 64. The show processes cpu
command was used every 30 seconds for 2 hours. The other commands were used every 5 minutes for
2 hours.
Table 64
show Commands Used for the Boston QoS Verification Test
Command
Purpose
show clock
•
Verifies the current time.
show policy-map interface [interface name]
•
Verifies that data traffic gets the percentage of
bandwidth assigned in the policy maps.
show interfaces [interface type]
On all the outbound WAN 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 shaped rate is 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.
show traffic-shape statistics
•
Verifies that traffic shaping is enabled.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface that was configured by the
virtual template.
show ppp multilink [interface type]
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
show ip rtp header compression
•
Verifies that IP RTP header compression is
turned on and if there are any errors.
The show commands listed in Table 64 were used on the WAN routers and interfaces listed in Table 65.
Table 65
Step 3
Boston WAN Routers and Interfaces
Router
Interface
egbos-2651-v1
Fa0/1
egbos-7206-w1
Fa1/0, Fa2/0
egbos-7206-w2
Fa0/0, Fa1/0, Fa2/0
egbos-7206-w3
Serial3/0:0
Use DART to capture the output of the Cisco IOS show commands listed in Table 66 on all routers once
at the end of the 2-hour test run.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
79
Test Suite 2: Boston Campus
Table 66
show Commands Used on the Boston Switches and Interfaces
Command
Purpose
show class-map
•
Displays the class map configured for the device
show policy-map
•
Displays the policy map configured for the
device.
show access-list
•
Verifies that the configured access lists have the
correct amount of packet matches.
The show commands listed in Table 66 were used on the routers and interfaces listed in Table 67.
Table 67
Step 4
Boston Routers and Interfaces
Router
Interface
egbos-2651-v1
Fa0/1
egbos-7206-w1
Fa1/0, Fa2/0
egbos-7206-w2
Fa0/0, Fa1/0, Fa2/0
egbos-7206-w3
Serial3/0:0
Capture the data statistics from Chariot, IXIA, and BCG after the 2-hour test run. Throughput observed
on the test equipmet should be comparable to what is observed on the router or switch.
Expected Results
We expect the following results:
•
CPU utilization was always less than 90 percent.
•
No system or feature errors occurred during testing, such as router or switch failures, reloads, CPU
hogs, or significant errors (that is, memory allocation errors, memory access errors, memory leaks,
or unexpected interface toggles).
•
Routing tables correctly reflected all available super- and subnets. All client/server traffic traversed
from source to destination through the expected route for the duration of the test. Routes converged
correctly without major delay.
•
All the other procedures were executed.
•
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 68 shows the Boston QoS verification test results.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
80
Test Suite 2: Boston Campus
Table 68
Boston QoS Verification Test Results
Test
Results
Boston QoS verification
Passed
Boston System Test
The overall objectives of this test case were as follows:
•
Verify that the IP routing, SNMP, security, multicast, VoIP, and QoS features could be incorporated
into all Boston campuses.
•
Verify the successful operation of the Cisco IOS release.
•
Verify that the system behaved as expected.
This test category verified system performance for a number of QoS features, using EIGRP and BGP as
the routing protocols. The features that were configured for the Boston functionality test were carried
over to this test. The following additional features were configured in this test category:
•
BGP 4
•
CBWFQ
•
PQ
•
MLPPP performance enhancements
•
CEF support for IP routing between IEEE 802.1Q VLANs
•
CGMP
•
CLI string search
•
dCBWFQ
•
dLLQ
•
dTS
•
dWRED
•
EIGRP stub routing
•
FRF.12 support on switched Frame Relay PVCs
•
GTS
•
H.323 gatekeeper
•
H.323 Version 2 support
•
HSRP
•
IEEE 802.1Q VLAN support
•
LFI for Frame Relay and ATM Virtual Circuits
•
MLPPP with LFI
•
NBAR real time streaming protocol
•
PIM version 2
•
RTP header compression
•
TACACS+
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
81
Test Suite 2: Boston Campus
•
VLAN Database
Test Plan
The procecure used to perform the Boston system test follows:
Step 1
Start the traffic streams for 100 percent of the traffic load as follows:
a.
Start the BCG (Callgen) to generate calls.
b.
Start Chariot to simulate NetMeeting, Telnet, Lotus, Oracle, FTP, and HTTP traffic.
c.
Start IP/TV, for multicast traffic.
d.
Start IXIA, for background traffic.
Step 2
Use DART to capture information from the routers for 4 hours.
Step 3
Analyze the output of the Cisco IOS show commands listed in Table 69 at the start and end of the 4-hour
test.
Table 69
show Commands Used for the Boston System Test Start and End View
Command
Purpose
show vtp status
•
Verifies that the VTP feature is enabled.
show vlan brief
•
Verifies VLAN status and port assignments.
show memory summary
•
Verifies that there are no memory leaks or
errors.
show ip bgp summary
•
Verifies the BGP routes.
show ip eigrp neighbors detail
•
Verifies that the remote WAN routers are
EIGRP stub-enabled.
show ip eigrp interface
•
Verifies if the EIGRP adjacent neighbor count
is higher than the neighbor count. If so, the
neighbor list could be corrupted.
show interfaces
•
Verifies that there are no input or output errors
or queue drops.
•
Verifies the routers’ throughput.
show clock
•
Verifies that the clock is synchronized with the
NTP server.
show buffer failure
•
Verifies a buffer or memory failure.
show ip igmp interface
•
Verifes that IGMP v2 is communicated among
routers and hosts to dynamically register or
leave a multicast group on a LAN segment.
show ip igmp groups
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
show mac-address-table multicast vlan vlan-id
•
Verifies that the correct multicast addresses
are present in the output.
show mls ip multicast
•
Verifes that multicast flows create MMLS
entries and that switching of the flow is
performed.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
82
Test Suite 2: Boston Campus
Table 69
show Commands Used for the Boston System Test Start and End View (continued)
Command
Step 4
Purpose
show tacacs
•
Verifies that you are logging in to the correct
TACACS+ server.
show accounting
•
Verifies user account on the router and
switches with privilege 15.
show gateway
•
Verifies that the voice gateway is connected to
gatekeeper egsj-3640-GK.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface that was configured by the
virtual template.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
Analyze the output of the Cisco IOS show commands listed in Table 70 at 60-minute intervals.
Table 70
show Commands Used for the Boston System Test 60-Minute View
Command
Step 5
Purpose
show interface trunk
•
Verifies that the VLAN trunkings are formed
correctly.
show ip route summary
•
Verifies the current state of the routing table.
show memory summary
•
Verifies that there are no memory leaks or
errors.
show ip eigrp neighbors
•
Verifies the remote WAN routers.
show policy interface
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy maps.
show ip rtp header compression
•
Verifies that IP RTP header compression is
enabled for the voice traffic and if there are
any errors.
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip mroute summary
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
Analyze the output of the Cisco IOS show command listed in Table 71 at 10-minute intervals.
Table 71
show Command Used for the Boston System Test 10-Minute View
Command
show processes cpu
Purpose
•
Verifies the CPU utilization.
•
Verifies that CPU capacity is not being
monopolized by a single router.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
83
Test Suite 2: Boston Campus
Expected Results
We expect the following results:
•
CPU utilization was always less than 90 percent.
•
No system or feature errors (such as router or switch crashes, reloads, or CPU hogs) occurred during
testing.
•
No significant errors occurred, such as memory allocation errors, memory access errors, memory
leaks, or unexpected interface toggles.
•
Routing tables correctly reflected all available supernets and subnets.
•
All client/server traffic traversed from source to destination through the expected route for the
duration of the test.
•
Routes converged correctly without major delay.
Results
Table 72 shows the Boston system test results.
Table 72
Boston System Test Results
Test
Results
Boston system
Passed
Boston Reliability Test
This section describes in detail the reliability test as it pertained to the Boston campus, using EIGRP as
the interior routing protocol and BGP as the exterior routing protocol. Successful execution of the
Boston system test was prerequisite to the execution of this test. The reliability test ran for 150 hours,
with IP routing, NMS, voice, multicast, security, and QoS features enabled.
The following additional features were configured in this test category:
•
BGP 4
•
CBWFQ
•
PQ
•
MLPPP performance enhancements
•
CEF support for IP routing
•
CGMP
•
CLI string search
•
dCBWFQ
•
dTS
•
dWRED
•
EIGRP stub routing
•
FRF.12 support on Switched Frame Relay PVCs
•
MQC - based FRTS
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
84
Test Suite 2: Boston Campus
•
GTS
•
H.323 gatekeeper
•
H.323 Version 2 support
•
H.323/H.320 gateway
•
HSRP
•
Cisco IP phone support
•
EIGRP route authentication
•
IEEE 802.1Q VLAN support
•
IGMP MIB support enhancements for SNMP
•
IGMP snooping querier
•
IGMP version 2
•
IP routing
•
LFI for Frame Relay and ATM virtual circuits
•
LLQ with priority percentage support
•
LLQ
•
MD5 password encryption
•
MLPPP with LFI
•
MQC
•
NBAR real-time streaming protocol
•
PIM MIB extension for IP multicast
•
PIM version 2
•
QoS enhancements
•
RTP header compression
•
TACACS+
•
VLAN database
•
VoIP
•
WRED
The overall objective of this test case was to verify that the IP routing, SNMP, security, multicast, VoIP,
and QoS features could be incorporated into all Boston Campuses, to verify the successful operation of
the Cisco IOS release, and to verify that the system behaved as expected and performed reliably for the
150-hour test period.
Test Plan
The procedure used to perform the Boston reliability test follows:
Step 1
Start traffic streams for a 100 percent traffic load by performing the following steps:
a.
Start the BCG (Callgen) to generate calls.
b.
Start Chariot to simulate NetMeeting, Telnet, Lotus, Oracle, FTP, and HTTP traffic.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
85
Test Suite 2: Boston Campus
c.
Start IP/TV, for multicast traffic.
d.
Start IXIA, for background traffic.
Step 2
Use DART to capture information from the routers for 150 hours.
Step 3
Analyze the output of the Cisco IOS show commands listed in Table 73 at the start and end of the
150-hour test period.
Table 73
show Commands Used for the Boston Reliability Test Start and End View
Command
Purpose
show vtp status
•
Verifies that the VTP feature is enabled.
show vlan brief
•
Verifies VLAN status and port assignments.
show memory summary
•
Verifies that there are no memory leaks or
errors.
show ip bgp summary
•
Verifies the BGP routes.
show ip eigrp neighbors detail
•
Verifies that the remote WAN routers are
EIGRP stub-enabled.
show ip eigrp interface
•
Verifies if the EIGRP adjacent neighbor count
is higher than the neighbor count. If so, the
neighbor list could be corrupted.
show interfaces
•
Verifies that there are no input or output errors
or queue drops.
•
Verifies the routers’ throughput.
show clock
•
Verifies that the clock is synchronized with
the NTP server.
show buffer failure
•
Verifies a buffer or memory failure.
show ip igmp interface
•
Verifes that IGMP v2 is communicated among
routers and hosts to dynamically register or
leave a multicast group on a LAN segment.
show ip igmp groups
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
show mac-address-table multicast vlan vlan-id
•
Verifies that the correct multicast addresses
are present in the output.
show mls ip multicast
•
Verifes that multicast flows create MMLS
entries and that switching of the flow is
performed.
show tacacs
•
Verifies that you are logging in to the correct
TACACS+ server.
show accounting
•
Verifies user account on the router and
switches with privilege 15.
show gateway
•
Verifies that the voice gateway is connected to
gatekeeper egsj-3640-GK.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
86
Test Suite 2: Boston Campus
Table 73
show Commands Used for the Boston Reliability Test Start and End View (continued)
Command
Step 4
Purpose
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface that was configured by the
virtual template.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
Analyze the output of the Cisco IOS show commands listed in Table 74 at 24-hour intervals.
Table 74
show Commands Used for the Boston Reliability Test 24-Hour View
Command
Step 5
Purpose
show interface trunk
•
Verifies that the VLAN trunkings are formed
correctly.
show ip route summary
•
Verifies the current state of the routing table.
show memory summary
•
Verifies that there are no memory leaks or
errors.
show ip eigrp neighbors
•
Verifies the remote WAN routers.
show policy interface
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy maps.
show ip rtp header compression
•
Verifies that IP RTP header compression is
enabled for the voice traffic and if there are
any errors.
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip mroute summary
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
Analyze the output of the Cisco IOS show command listed in Table 75 at 6-hour intervals.
Table 75
show Command Used for the Boston Reliability Test 6-Hour View
Command
Purpose
show processes cpu
•
Verifies the CPU utilization.
•
Verifies that CPU capacity is not being
monopolized by a single router.
Expected Results
We expect the following results:
•
CPU utilization was always less than 90 percent.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
87
Test Suite 2: Boston Campus
•
No system or feature errors (such as router or switch failures, reloads, or CPU hogs) occurred during
testing.
•
No significant errors occurred, such as memory allocation errors, memory access errors, memory
leaks, or unexpected interface toggles.
•
Routing tables correctly reflected all available supernets and subnets.
•
All client/server traffic traversed from source to destination through the expected route for the
duration of the test.
•
Routes converged correctly without major delay.
Results
Table 76 shows the Boston reliability test results.
Table 76
Boston Reliability Test Results
Test
Results
Boston reliability
Passed with exceptions
Passed with Exceptions Explanation
The Boston reliability test passed with exceptions for the following reasons:
•
Because of an automated job scheduling conflict with a data collection tool, 14 hours of test data
was not collected. The test results were not affected.
•
The IXIA traffic generator was turned off to allow problem-characterization work on Chariot and
was not turned on until several hours after the start of the test. There were no problems in the
network and the test results were not affected.
•
Chariot endpoint station bos-ux1 failed during the test. Chariot reported the problem as a bus error
in the Sun workstation that served as bos-ux1 and did not reflect any problems in the network. The
test results were not affected.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
88
Test Suite 3: Washington, D.C. Campus with Data Center
Test Suite 3: Washington, D.C. Campus with Data Center
This test suite consisted of three test cases intended to verify the functionality, reliability, and
performance of basic IP and 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 12 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:
•
Functionality testing: This test category verified basic IP functionality, using EIGRP and BGP as
the routing protocols.
•
System testing: This test category verified system performance, using IP routing, NMS, voice,
multicast, security, and QoS
•
Reliability testing: This test category verified system reliability.
This test suite contains the following sections:
•
Topology Description, page 89
•
Washington, D.C. Functionality Test, page 92
•
Washington, D.C. System Test, page 112
•
Washington, D.C. Reliability Test, page 116
Topology Description
The global enterprise Washington, D.C. testbed represents one of the medium-size enterprise campuses
that would be located in a United States region. The Washington, D.C. testbed simulates one of the large
enterprise headquarters campuses with a data center. It consists of two Catalyst 6506 switches with
MSFC2/PFC2 cards acting as core routers, two Cisco OSR-7609s as campus WAN routers, one
Cisco 7507 as the WAN aggregation router, one Catalyst 6506 as the distribution router for the data
center, and a Cisco 3640 acting as the voice gateway.
The two OSR-7609 routers provide connection to the internet and other large campuses in this testbed
through POS OC-3, ATM OC-3, ATM-T3, E3, and T3 WAN links. The Cisco 7507 router acts as the
WAN aggregation router for the many remote sites connected to this campus through ATM or Frame
Relay links with less bandwidth than a T1. High-speed L3 GE links are used to connect these devices
together, with sufficient redundancy.
The voice gateway is connected using Fast Ethernet connectivity. The voice gateway uses the gatekeeper
in the San Jose campus for registration, and places VoIP calls to the voice gateways in the other
campuses.
The Washington, D.C. testbed is used to perform the test for functionality, which includes IP routing,
SNMP, multicast, security, VoIP, and QoS. EIGRP is the IP IGP routing protocol, and a total of about
600 routes are generated in this campus. BGP is the IP EGP routing protocol.
Application servers located in the data center serve the end users in this campus. The database servers
located in the data center serving this campus and the database servers located in the data center store
the data for the whole enterprise global topology, with redundant database servers in the San Jose
campus.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
89
Test Suite 3: Washington, D.C. Campus with Data Center
Voice, NetMeeting, Telnet, Oracle, SAP, MS Exchange, Lotus Notes, HTTP, and FTP are the
applications simulated by the test tools in this campus. The testbed simulates 1000 end users through the
use of traffic generators and real PC and UNIX workstations.
Figure 8 shows the Washington, D.C. campus with data center topology with IP addresses.
Figure 8
Washington, D.C. Campus with Data Center Topology with IP Addresses
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
A3/0/0
1
6/1
6/2
isp3-7507
S3/0/0
32
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
0/1
1/2 3
6/3
1/1
Traffic generators
was-ux1
5/0/0
L3 Core
was-pc3
2/4
2/3
2/2
6/2
6/1
2/5
4
2/2
2/3
2/1
37 egwas6506-c1
was-ux3
5
X Loopback - 96.10.0.x
XX Backdoor - 223.255.10.XX
6/2
2/5
egwas6506-c2
was-pc2
35
6/1
was-ux2
Traffic generators
95529
Traffic generators
2/1
2/4
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
90
Test Suite 3: Washington, D.C. Campus with Data Center
Figure 9 shows the Washington, D.C. campus with data center topology with interface types.
Figure 9
Washington, D.C. Campus with Data Center Topology with Interface Types
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
.13 .21
egwas-3640-v1
31
1
.5
.17 .9
96.10.1.4
.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
.14
was-pc3
96.10.17.100
.34
.18
.22
.6
Data Center
was-pc1
96.10.137.100/V37
egwas-6506-sd1
.6
.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
96.10.1.24
34 96.10.17.1
egwas6506-c1
35
96.10.10.1
was-ux2
96.10.10.100
Traffic generators
95530
Traffic generators
.26
96.10.9.1 5
egwas6506-c2
Platform and Software Version Information
Table 77 lists the platforms, router names, software versions, and software images configured in the
Washington, D.C. network topology for this test suite.
Table 77
Washington, D.C. Platform, Router Name, Software Version, and Software Image Table
Platform
Router Name
Software Version
Software Image
Cisco 7609
egwas-7609-w1
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Cisco 7609
egwas-7609-w2
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Catalyst 6500
egwas-6506-sd1
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Catalyst 6500
egwas-6506-c1
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Cisco 3660
egwas-3660-v1
12.2(16b)
c3660-js-mz.122-16b
Cisco 7507
egwas-7507-w3
12.2(15)T5
rsp-pv-mz.122-15.T5
Catalyst 6500
egwas-6505-c2-sup2
7.6(1)
cat6000-sup2k8.7-6-1
Catalyst 6500
egwas-6505-c2-msfc2
12.1(13)E9
c6msfc2-jsv-mz.121-13.E9
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
91
Test Suite 3: Washington, D.C. Campus with Data Center
Washington, D.C. Functionality Test
The functionality test category verified basic IP functionality. The tests are described in the following
sections:
•
Basic IP
•
Network Management
•
Multicast
•
Security
•
Voice
•
QoS
The testing in each section was performed sequentially and as independently as possible. The
Washington, D.C. functionality testing was conducted as follows:
1.
Basic IP testing was performed in conjunction with Network Management Testing (NMS). Network
Management was utilized to collect the test information.
2.
After completion of the basic IP test, IP configurations were made stable, and any traffic loading
was terminated in preparation for the next test.
3.
Multicast testing was performed, again with NMS monitoring.
4.
After completion of the multicast test, IP configurations were made stable, and any traffic loading
was terminated in preparation for the next test.
5.
Security testing was performed in conjunction with NMS monitoring.
6.
After completion of the security test, IP configurations were made stable, and any traffic loading
was terminated in preparation for the next test.
7.
Voice testing was performed in conjunction with NMS monitoring.
8.
After completion of the voice test, IP configurations were made stable, and any traffic loading was
terminated in preparation for the next test.
9.
QoS testing was performed in conjunction with NMS monitoring.
10. After completion of the QoS test, IP configurations were made stable, and any traffic loading was
terminated in preparation for the next test.
Basic IP
This is a basic IP functionality test for the Washington, D.C. campus with data center. This test case
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).
The objectives for this test case were as follows:
•
Verify the basic network operation (that is, network connectivity).
•
Verify the configurability and stability in a controlled environment for each of the functionality
tests.
•
Verify that the software can be loaded and used in the devices.
•
Verify that the major IP routing features work as expected.
•
Collect the network baseline information and provide the necessary test results.
In this test case, the following individual tests were conducted:
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
92
Test Suite 3: Washington, D.C. Campus with Data Center
•
Layer 2 Protocols and HSRP
•
EIGRP with BGP routing test
In addition to basic IP, the VTP and VLAN feature was configured.
Layer 2 Protocols and HSRP
This test involved testing various Layer 2 protocols and HSRP. The VTP and VLAN feature was included
in the test plan.
Test Plan
The procedure used to perform the Layer 2 protocols and HSRP test follows:
Step 1
Set up the VLANs. The access switch VLAN model is model number 1, “share VLANs across Access
Layer switches,” for this campus. Each building is in a separate VTP domain. The two distribution layer
switches work in VTP server mode, and all access layer switches work in VTP transparent mode.
VLAN 1 is for control traffic on all switches by default. VLAN 2 is for a backdoor network connection,
configured only on the access layer switches. VLANs 11 to 20 are used for end-user networks that are
configured across all access layer switches and the distribution layer routers. VLANs 21 to 110 are used
to generate routes, which are configured only on distribution layer routers.
Step 2
In the data center, configure the distribution layer switch egwas-6506-sd1 as a VTP server.
Step 3
Perform the Layer 2 configuration on egwas-6505-sd1, the distribution switch in the data center.
VLAN 1 is configured for control traffic and VLANs 11 to 110 are configured to carry end-user network
traffic in the data center. VLAN interfaces from 11 to 110 are configured to route the VLAN traffic in
this distribution switch.
Step 4
On switch egwas-6505-sd1, use the CatOS show vlan brief command, and the Cisco IOS show vtp
status command to verify the VTP and VLAN configuration.
Expected Results
We expect that the VTP and VLAN configuration will work correctly.
Results
Table 78 shows the Washington, D.C. Layer 2 protocols and HSRP test results.
Table 78
Washington, D.C. Layer 2 Protocols and HSRP Test Results
Test
Results
Washington, D.C. Layer 2 protocols and HSRP Passed
EIGRP with BGP Routing
This test involved testing EIGRP with BGP routing. The following features were included in the test
plan:
•
Route summarization
•
Route filtering
•
EIGRP stub router functionality
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
93
Test Suite 3: Washington, D.C. Campus with Data Center
•
Route redistribution and default route generation
•
Log event or change functionality
•
BGP policy control (specifically, autonomous system [AS] prepend and route filtering)
•
EIGRP metric tuning—link delay and bandwidth
Test Plan
This test verified route summarization, route filtering, route redistribution, EIGRP stub router
functionality, route redistribution and default route generation, log event or change functionality, BGP
policy control, and EIGRP metric tuning. Several parts to this test plan are described in the sections that
follow.
Route Summarization and Filtering Test
The procedure used to perform the route summarization and filtering test follows:
Step 1
Turn off EIGRP auto-summary on all EIGRP-enabled routers. Route summarization is manually done
on the following devices:
a.
On WAN access routers egwas-7509-w1 and egwas-7509-w2, end-user networks from the buildings
are summarized into /20 and /21 routes. The devices’ interconnectivity network and loopback
interface routes within the whole campus including data center will be summarized into one /21
route.
b.
On campus WAN aggregation router egwas-7507-w1, the summarized routes are redistributed into
BGP and advertised to BGP neighbors. Intercampus WAN connectivity network routes are
summarized, by the sourcing campus, into one /21 route and advertised into the local campus.
Intercampus eBGP connections are sourced and destined to the respective loopback interfaces on
the routers. iBGP is configured between WAN aggregation routers' respective loopback interfaces.
c.
EIGRP (passive-interface) is disabled on the WAN links to the other major campuses. Other campus
routes learned by BGP are redistributed into EIGRP with varying metrics to ensure that the core
layer routers select the best intercampus route.
d.
On campus distribution layer router egwas-6506-sd1, building routes are summarized to /21 and /20
routes and subsequently advertised to the connected core layer routers.
e.
On campus WAN aggregation router egwas-7507-w1, all remote site WAN links routes in remote
group 1 are summarized into one /21 route. The summary route is then advertised by the WAN
aggregation router to the campus core layer routers.
Summarized local campus routes and the default route are advertised to the remote sites by the WAN
aggregation router. Filtration may use tag matching using route maps. The remote site branch router
has the same local campus route summarization schema as the campus WAN aggregation routers
mentioned earlier.
Step 2
Configure a distribution list on the core layer routers, the egwas-6506-c1 and egwas-mfsc2-c2, to allow
only local campus routes and default routes to be advertised to the distribution layer routers. Redistribute
untagged EIGRP routes into BGP.
Step 3
Configure a distribution list on the WAN aggregation router, egwas-7507-w3, to allow only local campus
summarized routes and the default route to be advertised to the remote sites. As an alternative, configure
a route map to permit routes matching local campus tags to be advertised to remote sites.
Step 4
Configure all the building and data center distribution layer routers and voice routers as EIGRP stub
routers, so that the EIGRP queries do not propagate to the distribution layer routers or the voice routers.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
94
Test Suite 3: Washington, D.C. Campus with Data Center
Step 5
Configure distribution layer router egwas-6506-sd1 as an EIGRP stub router to prevent advertisement of
EIGRP queries into the access layer. Voice gateway egwas-3660-v1 is also configured as an EIGRP stub
router.
Route Redistribution and Default Route Generation Test
The procedure used to perform the route redistribution and default route generation test follows:
Step 1
Configure BGP and EIGRP routing on the campus WAN aggregation router egwas-7509-w2. BGP will
receive ISP advertised routes in addition to intercampus routes.
Step 2
Redistribute BGP into EIGRP and permit only the intercampus routes to be tagged and redistributed into
EIGRP. A static default route will be created by the router connected to the ISP and advertised into the
whole EIGRP AS and will be permitted into the remote sites.
A backup static default route will be advertised by the secondary ISP-connected router, using a floating
static route. The default route will not be advertised by BGP. Varying metrics will be applied to the routes
being redistributed based on the number of BGP ASs that the intercampus route learned.
BGP Policy Control Test
The procedure used to perform the BGP policy control test follows:
Step 1
Configure logging of changes on all the EIGRP- and BGP-enabled routers by using the Cisco IOS
eigrp log-neighbor-changes command and the bgp log-neighbor-changes command. The BGP AS
64503 is the AS used for all Washington, D.C. campus AS border routers. All BGP routes are accepted
on the BGP routers.
Step 2
Configure egwas-7509-w2 for route filtering. This default route is redistributed into EIGRP for the
connection to the ISP.
Step 3
Configure the egwas-7609-w2 BGP policy so that the traffic from the ISP destined for the local campus
prefixes gets high priority (by using AS prepending) to the advertised prefixes of the nonlocal campuses.
All intercampus routes will be advertised to the ISP, but the AS will be prepended three times.
Step 4
Leak a 24-bit route to the Chariot endpoints into the remote AS via link ATM3/0/0 on egwas-7609-w2.
Set the community attribute no-advertise on these routes.
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 routers to enable symmetric
routing for the building 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 microseconds to 50 microseconds. This configuration enables the left distribution layer switch
to advertise a less desirable routing metric to the core routers for all the even-numbered VLAN
interfaces. Similarly configure the right distribution layer switch.
Step 2
Analyze the output of the Cisco IOS show commands listed in Table 79.
Table 79 lists each show command and the role it plays in the Washington, D.C. EIGRP with BGP
routing test.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
95
Test Suite 3: Washington, D.C. Campus with Data Center
Table 79
show Commands Used in the Washington, D.C. EIGRP with BGP Routing Test
Command
Purpose
show ip route
On all routers:
and
•
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 summary
show ip route
On the core layer and distribution layer routers:
•
show processes cpu
show memory summary
show logging
show ip bgp
and
Verifies the symmetric routing for the building
end-user networks.
On all routers every 10 minutes:
•
Verifies the CPU utilization.
•
Verifies that CPU capacity is not being
monopolized by a single router.
On all routers every 60 minutes:
•
Verifies that there are no memory leaks or other
memory errors.
•
Verifies that there are no significant errors for
EIGRP or BGP routing.
On egwas-7509-w2
•
Verifies that BGP routing is working correctly.
show ip bgp summary
show ip bgp
On the ISP routers:
and
•
Verifies BGP AS prepending policy control.
show ip route
and
Note
ping
show interfaces [interface type]
show ip eigrp neighbors detail
The show ip bgp command in this phase
of testing will be a verbose output (at
least 50,000 lines long), so only two
captures (beginning and end) of this
command output should be collected.
On all the WAN routers:
•
Verifies that there are no input errors, output
errors, or queue drops.
•
Verifies the router's throughput.
On the core layer routers egwas-6506-c1 and
egwas-mfsc2-c2:
•
Verifies that the distribution layer routers are
EIGRP stub-enabled.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
96
Test Suite 3: Washington, D.C. Campus with Data Center
Table 79
show Commands Used in the Washington, D.C. EIGRP with BGP Routing Test (continued)
Command
Purpose
show ip eigrp neighbors
On the distribution layer routers:
show ip route [interface name]
•
Verifies that the EIGRP neighbor was not
created between two distribution layer routers.
•
Verifies that specific WAN interface routes are
not in the routing table.
Expected Results
We expect the following results:
•
The routes are summarized correctly.
•
The route filters function correctly.
•
CPU utilization is less than 90 percent.
•
Memory consumption is stable.
•
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 significant EIGRP or BGP routing errors and 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 80 shows the Washington, D.C. EIGRP with BGP routing test results.
Table 80
Washington, D.C. EIGRP with BGP Routing Test Results
Test
Results
Washington, D.C. EIGRP with BGP routing
Passed
Network Management
This section describes the network management testing in the Washington, D.C. campus with data center.
The following features were included in the test plan:
•
MIB walk automation script (snmp_walk_test) and traps
•
Syslog and NTP
The objectives of the SNMP MIB testing were as follows:
•
Ensure that the information stored in the MIB database can be accessed, propagated, read, and
written if applicable.
•
Ensure that the operation of the OID values reflects the actual operation on the device.
•
Ensure that there were no SNMP traps.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
97
Test Suite 3: Washington, D.C. Campus with Data Center
Test Plan
The procedure used to perform the network management test follows:
Step 1
Configure MIB walk and traps.
The MIB walk automation script (snmp_walk_test) will test the OID and traps by platforms and
technologies, report their value, and monitor the UUT behavior. HP OpenView and CiscoWorks2000 are
used as the SNMP receivers.
Step 2
Configure all the routers and switches so that the script will work properly.
Step 3
Upload the following MIBs to the snmp_walk_test script:
•
Basic IP:
– CISCO-BGP4-MIB
– CISCO-VTP-MIB
– CISCO-HSRP-MIB
•
Multicast:
– CISCO-IPMROUTE-MIB.my
– CISCO-IGMP-MIB.my
– CISCO-MSDP-MIB.my
– CISCO-PIM-MIB.my
•
Voice:
– CISCO-VOICE-DIAL-CONTROL-MIB
•
QoS:
– CISCO-QOS-MIB
Step 4
Set up the eg-cw2k (CiscoWorks2000) server in the San Jose campus as the UNIX NTP and syslog
server.
Step 5
Use DART to capture show command output from the routers.
Step 6
Use the show processes cpu command to verify the CPU utilization and to verify that the CPU capacity
is not being monopolized by a single router.
Step 7
Use the show memory summary command to verify that there are no memory leaks or errors.
Step 8
On server eg-cw2k, verify that syslogd is still running.
Step 9
Use the Cisco IOS show clock command and the CatOS show time command to verify that the clock is
synchronized with the NTP server.
Step 10
Verify that the Pat scripts are able to send e-mail notification for error conditions on the routers or
switches.
Step 11
Use the show crypto mib ipsec flowmib version command to verify that the device has IPsec MIB
support.
Step 12
Use the show log command or the show align command to verify that there are no other significant
errors.
Step 13
Use the show snmp command to verify the SNMP configuration information.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
98
Test Suite 3: Washington, D.C. Campus with Data Center
Expected Results
We expect the following results:
•
Information stored in the MIB can be accessed, propagated, read, and written.
•
Operation of the OID values reflect the actual operation of the device.
Results
Table 81 shows the Washington, D.C. network management test results.
Table 81
Washington, D.C. Network Management Test Results
Test
Results
Washington, D.C. network management
Passed
Multicast
The objective of the Washington, D.C. campus with data center multicast testing was to verify the
functionality of multicast features across multiple Cisco platforms with various sets of Cisco IOS and
CatOS releases.
The following features were included in the test plan:
•
MDS
•
PIM sparse-dense mode
•
Multicast boundary
•
Anycast-RP with Auto-RP
•
IGMP-v2
•
IGMP snooping
•
MMLS
•
Auto-RP
The test was set up to use Cisco IP/TV as a one-to-many video and audio streaming application by
configuring an IP/TV server at the San Jose campus data center to stream six multicast groups. There
were three video and three audio groups.
Test Plan
Setup
The procedure used to set up the multicast test follows:
Step 1
Configure Cisco IP/TV by performing the following steps:
a.
Connect the IP/TV server to switch egsj-6505-sa3.
b.
Connect the IP/TV client to switch egwas-6506-c1.
c.
Configure the IP/TV server to stream two programs as follows:
•
The program “G1” contains a 239.192.1.0/24 multicast address scope and consists of a
600-kbps video and audio stream.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
99
Test Suite 3: Washington, D.C. Campus with Data Center
•
The program “G2” contains a 239.192.2.0/24 multicast address scope and consists of a
300-kbps video and audio stream.
Step 2
Enable MDS on router egwas-7505-w3.
Step 3
Enable PIM sparse-dense mode on all Layer 3 Native IOS and Cisco IOS multicast devices.
Step 4
Enable multicast boundary on router egwas-7505-w3.
Step 5
Enable Anycast-RP with Auto-RP on switches egwas-6506-sd1 and egsj-6506-sd1.
Step 6
Enable IGMP snooping on the Layer 2 switches.
Step 7
Enable MMLS on the Layer 3 switches. This feature is enabled by default in Native IOS, so no additional
configuration is required.
Verification
The procedure used to perform the multicast verification test follows:
Step 1
Use DART to capture the output of the generic show commands listed in Table 82.
Table 82
Generic show Commands Used in the Washington, D.C. Multicast Verification Test
Command
Purpose
•
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 or other
memory errors.
show interfaces [interface type]
•
Verifies that there are no input errors, output
errors, or queue drops.
•
Verifies the router's throughput.
•
Verifies that there are no other significant errors.
show processes cpu
show logging
Step 2
Using the show commands listed in Table 83, verify that IGMPv2 is communicated among routers and
switches to dynamically register or leave a multicast group on a LAN segment.
Table 83
show Commands Used in the Washington, D.C. Multicast IGMPv2 Verification Test
Command
show ip igmp interface
Purpose
•
Verifes that the router with the lower IP address
is the correct IGMP querier, and that the router
with the higher IP address is the correct
multicast DR.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
100
Test Suite 3: Washington, D.C. Campus with Data Center
Table 83
show Commands Used in the Washington, D.C. Multicast IGMPv2 Verification Test
Command
Purpose
show ip igmp groups
show ip mroute
Step 3
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
•
Verifies that all groups are seen for all
IGMP-joined groups.
•
Verifies that the router sends PIM join messages
as a consequence of receiving IGMP join
messages and creates the corresponding (*,G)
entries.
Using the show commands listed in Table 84, verify that MDS functions as follows:
•
The VIP interfaces on Cisco 7500 routers are MDS-enabled.
•
Multicast distributed switching is enabled.
•
Multicast traffic is distributed-switched.
Table 84
show Commands Used in the Washington, D.C. Multicast MDS Verification Test
Command
Purpose
show ip mds interface
•
Verifies the status of multicast distributed
switching (MDS) interfaces.
show ip pim interface count
•
Verifies that the switching state is distributed.
show ip mds stats switching
•
Verifies that multicast traffic is
distributed-switched.
show ip mds forwarding
On the line card console:
•
show ip mds summary
On the line card console:
•
Step 4
Verifies the MFIB table and forwarding
information for MDS.
Displays a summary of the MFIB table for
MDS.
Using the show commands listed in Table 85, verify that PIM sparse-dense mode functions as follows:
•
Multicast forwarding is achieved using PIM. PIM interacts with the IP unicast forwarding table to
determine the correct path to the source of the multicast packets (RPF), and interacts with IGMP to
recognize networks that have members of the multicast group.
•
All expected PIM neighbors are present and no unknown routers appear.
•
The correct DR election is made on the LAN segment.
•
The correct IIF and OIF lists, RPF, and flags are present in the (*,G) or (S,G) entries.
•
The correct RP mapping is shown for all groups.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
101
Test Suite 3: Washington, D.C. Campus with Data Center
Table 85
show Commands Used in the Washington, D.C. Multicast PIM Sparse-Dense Mode
Verification Test
Command
Step 5
Purpose
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
show ip mroute
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
Using the show commands listed in Table 86, verify that multicast boundary functions as follows:
•
RP messages are prevented from traveling beyond the boundaries of the network using multicast
boundaries.
•
Routers within the TTL number of hops from the source RP mapping agent receive the Auto-RP
discovery messages.
•
Routers learn about correct RP mapping information within the TTL range.
•
Routers out of the TTL range cannot receive the Auto-RP Discovery messages.
•
A border router with a multicast boundary configured will not leak Auto-RP messages out of the
network.
•
Multicast traffic cannot be forwarded out of the defined admin scope.
Table 86
show Commands Used in the Washington, D.C. Multicast Boundary Verification Test
Command
Purpose
show ip mroute
•
Verifies that multicast traffic cannot be
forwarded out of the defined boundary.
show ip pim interface count
•
Verifies that the multicast traffic on the interface
is correct.
show ip mroute
and
On the New York and Miami routers:
•
show ip mroute active
Step 6
Verifies that the downstream routers receive the
correct multicast traffic rate.
Using the show commands listed in Table 87, verify that Anycast-RP with Auto-RP functions as follows:
•
Auto-RP dynamically updates the RP information in every device in the network.
•
Traffic for the two Auto-RP groups 224.0.1.39 and 224.0.1.40 are dense-mode flooded network.
•
All routers learn about RP mapping information.
•
The correct RP mapping is shown for the specified group.
•
The RP mapping information is consistent through the network.
•
Anycast RP information is distributed to the routers and no multicast groups are reverting to dense
mode.
•
MSDP peers are operational.
•
There is an SA cache entry for each source.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
102
Test Suite 3: Washington, D.C. Campus with Data Center
Table 87
show Commands Used in the Washington, D.C. Multicast Anycast-RP with Auto-RP
Verification Test
Command
Step 7
Purpose
show ip pim rp mapping
•
Verifies all the group-to-RP mappings of which
the router is aware (either configured or learned
from Auto-RP).
show ip msdp peer
•
Verifies that MSDP peers are operational.
show ip msdp sa-cache
•
Verifies that there is an SA cache entry for each
source.
Using the show commands listed in Table 88, verify that IGMP snooping is functioning correctly. IGMP
snooping manages multicast traffic at Layer 2 by configuring the Layer 2 LAN port dynamically to
forward multicast traffic to only those ports that should receive it.
Table 88
show Commands Used in the Washington, D.C. Multicast IGMP Snooping Verification
Test
Command
Step 8
Purpose
show ip igmp snooping
•
Verifies that IGMP snooping is globally
enabled.
show ip igmp snooping
•
Verifies that the correct multicast router has
been learned.
Using the show commands listed in Table 89, verify that multicast flows create MMLS entries, and that
switching of the flow is performed using hardware shortcuts.
Table 89
show Commands Used in the Washington, D.C. Multicast MMLS Verification Test
Command
Step 9
Purpose
show mls ip multicast
•
Verifies that the flows are using the expected
multicast forwarding entry, (*,G) or (S,G).
show mls ip multicast summary
•
Verifies that the hardware-based flows are
created where expected.
Using the show commands listed in Table 90, verify that Auto-RP dynamically updates the RP
information in every device in the network.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
103
Test Suite 3: Washington, D.C. Campus with Data Center
Table 90
show Commands Used in the Washington, D.C. Multicast Auto-RP Verification Test
Command
show ip pim rp mapping
Purpose
•
Verifies that all routers learn about RP mapping
information.
•
Verifies that the correct RP mapping is shown
for the specified group.
•
Verifies that the RP mapping information is
consistent throughout the network.
•
Verifies that the traffic for the two Auto-RP
groups (224.0.1.39 and 224.0.1.40) is dense
mode.
and
show ip pim rp mapping in-use
show ip mroute 224.0.1.39/40
Expected Results
We expect the following results:
•
CGMP is communicated among routers and switches to dynamically join or leave a multicast group
on a LAN segment.
•
IGMPv2 is communicated among routers and hosts to dynamically register or leave a multicast
group on a LAN segment.
•
IGMP snooping manages multicast traffic at Layer 2 by configuring Layer 2 LAN ports dynamically
to forward multicast traffic to only those ports that want to receive it.
•
IGMP snooping constrains multicast traffic that exits through LAN ports to which hosts are
connected.
•
Multicast flows create MMLS entries and switching of the flow is performed using hardware
shortcuts in the Catalyst 6500.
•
Multicast forwarding is achieved using PIM.
•
Auto-RP dynamically updates the RP information in every device in the network.
•
Anycast RP information is distributed to the routers and none of the multicast groups reverts to
dense mode.
•
Routers learn RP mapping information within the defined TTL number of hops and multicast flows
are restrained in the TTL range.
•
RP messages are prevented from traveling beyond the boundaries of the network by using multicast
boundaries.
•
The rate that a sender from the source list can send to a multicast group in the group list is
appropriate.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
104
Test Suite 3: Washington, D.C. Campus with Data Center
Results
Table 91 shows the Washington, D.C. multicast test results.
Table 91
Washington, D.C. Multicast Test Results
Test
Results
Washington, D.C. multicast
Passed
Security
This security test was conducted for the Washington, D.C. campus with data center. This test case
verified the functionality of AAA and SNMP features commonly used by enterprise customers that
integrate across multiple Cisco platforms and Cisco IOS releases at the system level.
The objectives of the security test were as follows:
•
Verify TACACS+ services, authentication, authorization, and accounting, at a system level for all
access, distribution, core, and WAN edge devices in the global topology.
The following features were configured for the security test:
•
AAA TACACS+
•
Other security commands
Test Plan
Setup
The procedure used to set up the Washington, D.C. security test follows:
Step 1
Perform Step 2 through Step 7 to configure security features on the following devices:
•
egwas-7600-w1
•
egwas-7600-w2
•
egwas-7505-w3
•
egwas-3660-v1
•
egwas-6506-c1
•
egwas-6506-msfc2
•
egwas-6506-sd1
Step 2
Configure encryption service facility and AAA TACACS+.
Step 3
Configure the time-stamping service facility for logging.
Step 4
Disable all unnecessary services.
Step 5
Configure an enable password.
Step 6
Configure a console port password.
Step 7
Configure a vty password.
Verification
The procedure used to perform the Washington, D.C. security verification test follows:
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
105
Test Suite 3: Washington, D.C. Campus with Data Center
Step 1
Use the show tacacs command to verify the TACACS+ configuration values.
Step 2
Use the show accounting command to verify the user account on the router and switch.
Expected Results
We expect the following results:
•
TACACS+ AAA services function properly at a system level for all access, distribution, core, and
WAN edge devices in the global topology.
Results
Table 92 shows the Washington, D.C. security test results.
Table 92
Washington, D.C. Security Test Results
Test
Results
Washington, D.C. security
Passed
Voice
The purpose of the voice test was to deploy and verify the VoIP deployment scenarios for large
Enterprise customers that want to minimize the operations cost of telephony by utilizing IP telephony
over traditional services. The overall objectives of the voice test case were as follows:
•
Verify that voice can be incorporated into the Washington, D.C. campus.
•
Verify the operation of the Cisco IOS release to test the AVVID and legacy voice interoperability.
•
Collect and document the test results.
•
Ensure that the system behaves as expected.
Voice Testing
The following features were configured for voice testing:
•
Legacy H.323 VoIP
•
SCCP
Test Plan
The voice test verified that voice traffic operated properly accross the network. There are several parts
to this test plan, described in the sections that follow.
Set Up Legacy H.323
The procedure used to set up the legacy H.323 voice test follows:
Step 1
Configure H.323 voice gateway egwas-3640-v for T1 CAS and FXS.
Step 2
Check that egwas-3640-v is registered with gatekeeper egsj-3640-gk in the San Jose campus by using
the show gateway command on the egwas-3640-v router.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
106
Test Suite 3: Washington, D.C. Campus with Data Center
Step 3
Configure Callgen telephony.
Set Up SCCP
The procedure used to set up the SCCP voice test follows:
Step 1
Configure T1 CAS and FXS SCCP voice gateways on the Catalyst 6506.
Step 2
Configure inline power and real IP telephones on the Catalyst 6506.
Step 3
Verify that the T1 CAS, the FXS, and all real or simulated IP telephones on the Catalyst 6506 appear and
are registered in CallManager.
Step 4
Configure Callgen SCCP to generate test traffic.
Step 5
The WS-X6608-T1/E1 blade is used as a T1 or E1 gateway in egwas-6506-c2. It uses the Skinny protocol
to communicate with the Cisco CallManager server to set up and tear down calls. Use the set port voice
interface dhcp disable tftp gateway command to disable DHCP on a port and assign IP parameters
manually.
Step 6
The WS-X6624 is used in egwas-6506-c2 and has a single MAC address and a single IP address.
The IP address, IP default gateway, and TFTP server address parameters can be configured manually or
they can be configured dynamically from a DHCP server. This test uses manually configured (static)
parameters.
Step 7
Use the set port voice interface dhcp disable tftp gateway command to disable DHCP on a port and
assign IP parameters manually.
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 use to perform the voice traffic verification test follows:
Step 1
Configure an IP phone manually, install it in each campus, and make calls to test voice quality.
Step 2
Start the bulk call traffic generators by performing the following steps:
a.
Start all BCG channels to San Jose (19 calls), Boston (3 calls), Dallas (6 calls), Miami (2 calls), and
New York (2 calls). Note: Refer to the dial plan and voice design document.
b.
Using the show channel command on the Callgens, verify for 5 minutes that all originate and
terminate BCG channels have started and are progressing correctly with no problems.
Step 3
Verify for 5 minutes that all originate and terminate SimClient+ channels have started and are
progressing correctly with no problems.
Step 4
Analyze the output of the show commands listed in Table 93. Use the listed commands on all the WAN
routers using the DART tool every 60 seconds for the show processes cpu command, and every
5 minutes for all the others—for a duration of 2 hours.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
107
Test Suite 3: Washington, D.C. Campus with Data Center
Table 93
show Commands Used for the Washington, D.C. Voice Traffic Verification Test
Command
Purpose
show clock
•
show interfaces [interface type]
Verifies the current time.
On all outbound WAN 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 memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
The show commands listed in Table 93 were used on the WAN routers and interfaces listed in Table 94.
Table 94
Step 5
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
Stop the bulk call traffic generators and verify results by performing the following steps:
a.
Stop all BCGs after 1 hour of run time.
b.
Use the show channel command of the Callgen testing tool to verify that all originate and terminate
BCG channels are functioning correctly without any significant errors.
c.
Capture the output statistics of Callgen by using CIC.
d.
Use Performance monitor to check real time the number of gateways and IP phones registered and
CDR on the CallManager to also check the percentage of successful calls.
Expected Results
We expect the following results:
•
Voice traffic sent efficiently and all voice channels originated and terminated properly.
•
All originate and terminate BCG channels work properly and without any significant errors.
Results
Table 95 shows the voice traffic verification test results.
Table 95
Washington, D.C. Voice Traffic Verification Test Results
Test
Results
Washington, D.C. voice traffic verification
Passed
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
108
Test Suite 3: Washington, D.C. Campus with Data Center
QoS
The high-level objective of the QoS testing was to validate a robust QoS solution for protecting critical
application data, including real-time VoIP, on interarea WAN links, including classification and marking
as close to the network edge as possible, and remarking from L2 CoS to L3 ToS.
QoS Setup Test
The QoS setup test verified that QoS features were configured correctly and that the QoS features were
applied to traffic classes as anticipated. In this test, the MQC three-step model was used to configure the
traffic classes, class maps, and policy maps.
The following features were included in the test plan:
•
Classification and marking—Access lists, NBAR, Table maps, IP precedence, and DSCP
•
Congestion avoidance—dWRED (differentiated services-based WRED)
•
Congestion management—LLQ and dLLQ
•
Traffic conditioning—FRTS, GTS, and ATM Traffic Shaping
•
Link efficiency mechanisms—MLPPP LFI
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 using the following guidelines:
•
Classify VoIP traffic into a class map called “Real-Time.”
•
Classify applications with small or infrequently sent packets, such as Telnet and voice signaling,
into a class map called “Interactive.”
•
Classify the mission-critical traffic or traffic that can consume large amounts of bandwidth, such as
Lotus Notes and Oracle, into a class map called “Transactional.”
•
Classify IP/TV multicast video conferencing and multicast signaling into the “Streaming” class.
•
Classify HTTP and FTP traffic into the “class-default” class, which is the class map for best-effort
service.
Associate the policy maps and actions with each class of traffic by performing the following steps:
a.
Configure a policy map called "OUT-LAN-XX" on the core switches egwas-6506-sd1,
egwas-6506-c1, and ewas-6506-c2. This configuration tests the LLQ feature of QoS.
b.
Configure a policy map called "OUT-WAN-XX" on intercampus WAN aggregation routers
egwas-7600-w1 and egwas-7600-w2. This configuration tests the dWRED and LLQ features of
QoS.
c.
Configure a policy map called "OUT-WAN-XX" on campus-remote WAN aggregation router
egwas-7505-w3. This configuration tests the MLPP LFI and cRTP features of QoS.
d.
Configure a policy map called “OUT-LAN-XX” on the egwas-3660-v1 router. This configuration
tests the access lists, port numbers, and DSCP features of QoS.
Attach policy maps to the interfaces listed in Table 96, and apply the other appropriate QoS features.
Table 96 shows the router name, the policy map created, and the interface to which the policy map was
applied (attached).
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
109
Test Suite 3: Washington, D.C. Campus with Data Center
Table 96
Routers, Policy Maps, and Interfaces for the Washington, D.C. QoS Setup Test
Router
Policy Map
Interface
egwas-7609-w1
OUT-LAN-GE
Gi6/1, Gi6/2, Gi6/3
egwas-7609-w1
OUT-WAN-HW2
POS4/1/0
egwas-7609-w1
OUT-WAN-HW4
Serial3/0/0
egwas-6506-sd1
OUT-LAN-GE
Gi1/1, Gi1/2
egwas-7609-w2
OUT-LAN-GE
Gi6/1, Gi6/2, Gi6/3
egwas-6506-c1
OUT-LAN-GE
Gi2/1,Gi2/2, Gi2/3, Gi2/4, Gi2/5
egwas-7507-w3
OUT-LAN-GE
Gi0/0/0
egwas-7507-w3
OUT-WAN-DT6
Serial4/0/0
egwas-7507-w3
OUT-WAN-DT7
Serial4/0/1
egwas-3660-v1
OUT-LAN-FE
F0/1
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 97 shows the QoS setup test results.
Table 97
Washington, D.C. QoS Setup Test Results
Test
Results
Washington, D.C. QoS setup
Passed
QoS Verification Test
This test verified that incoming and outgoing 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, data traffic was 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 Chariot traffic testing tool to congest the network.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
110
Test Suite 3: Washington, D.C. Campus with Data Center
Step 2
Analyze the output of the Cisco IOS show commands listed in Table 98. The show processes cpu
command was used every 30 seconds for 2 hours. The other commands were used every 5 minutes for
2 hours.
Table 98
show Commands Used on the Washington, D.C. WAN Routers
Command
Purpose
show clock
•
Verifies the current time.
show policy-map interface [interface name]
•
Verifies that data traffic in the Real-Time class
gets 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 shaped rate is dropped.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
show ip rtp header compression
•
Verifies that IP RTP header compression is
turned on and if there are any errors.
The show commands listed in Table 98 were used on the Washington, D.C. WAN aggregation routers
and interfaces listed in Table 99.
Table 99
Step 3
Washington, D.C. WAN Aggregation 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-7606-w3
Serial4/0/1:0, Serial4/0/0:0, ATM4/1/0.768
Use DART to capture the output of the Cisco IOS show commands listed in Table 100. Use the
commands on the routers and switches listed in Table 99 and issue the commands once at the end of the
two-hour test.
Table 100
show Commands Used for the Washington, D.C. QoS Verification Test
Command
Purpose
show class-map
•
Verifies that the class map configured for the
device is displayed.
show policy-map
•
Verifies that the policy map configured for the
device is displayed.
show access-lists verify
•
Verifies that the configured access lists have the
correct amount of matching packets.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
111
Test Suite 3: Washington, D.C. Campus with Data Center
Step 4
Capture the data statistics from the Chariot, IXIA, and Callgen testing tools after the 2-hour test referred
to in Step 2 is completed.
Expected Results
We expect the following results:
•
CPU utilization was always less than 90 percent.
•
No system or feature errors (such as router or switch crashes, reloads, or CPU hogs) occurred during
testing.
•
No significant errors occurred, such as memory allocation errors, memory access errors, memory
leaks, or unexpected interface toggles.
•
Routing tables correctly reflected all available supernets and subnets.
•
All client/server traffic traversed from source to destination through the expected route for the
duration of the test.
•
Routes converged correctly without major delay.
Results
Table 101 shows the Washington, D.C. QoS verification test results.
Table 101
Washington, D.C. QoS Verification Test Results
Test
Results
Washington, D.C. QoS verification
Passed
Washington, D.C. System Test
The overall objectives of this test case were as follows:
•
Verify that the IP routing, SNMP, security, multicast, VoIP, and QoS features could be incorporated
into the Washington, D.C. campus.
•
Verify the successful operation of the Cisco IOS release.
•
Verify that the system behaved as expected.
This test category verified system performance for a number of QoS features, using EIGRP and BGP as
the routing protocols. The features that were configured for the Washington, D.C. functionality test were
carried over to this test. The following additional features were configured in this test case:
•
Auto-RP RP select on scope
•
BGP MIB feature
•
BGP 4
•
CBWFQ
•
Cisco-Process-MIB
•
CGMP
•
EIGRP
•
H.323 gateway trunk and carrier-based routing enhancements
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
112
Test Suite 3: Washington, D.C. Campus with Data Center
•
H.323/H.320 gateway
•
IGMP MIB support enhancements for SNMP
•
IGMP snooping querier
•
IGMP Version 2
•
IP MMLS global threshold
•
MLPPP performance enhancements
•
MSDP
•
PIM MIB extension for IP multicast
•
PIM Version 2
•
PQ
•
QoS—classification and WRED
•
QoS—policing and DSCP classification
•
QoS—packet marking
•
RFC1850 OSPFv2 MIB Support
•
RTP header compression
•
TACACS+
Test Plan
The procedure used to perform the Washington, D.C. system test follows:
Step 1
Start the traffic streams for 100 percent of the traffic load as follows:
a.
Start the BCG (Callgen) to generate calls.
b.
Start Chariot to simulate NetMeeting, Telnet, Lotus, Oracle, FTP, and HTTP traffic.
c.
Start IP/TV, for multicast traffic.
d.
Start IXIA, for background traffic.
Step 2
Use DART to capture information from the routers for 4 hours.
Step 3
Analyze the output of the Cisco IOS show commands listed in Table 102 at the start and end of the
4-hour test.
Table 102
show Commands Used for the Washington, D.C. System Test Start and End View
Command
Purpose
show vtp status
•
Verifies that the VTP feature is enabled.
show vlan brief
•
Verifies VLAN status and port assignments.
show memory summary
On all the WAN routers:
•
Verifies that there are no memory leaks or
errors.
show ip bgp summary
•
Verifies the BGP routes.
show ip eigrp neighbors detail
•
Verifies that the remote WAN routers are
EIGRP stub-enabled.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
113
Test Suite 3: Washington, D.C. Campus with Data Center
Table 102
show Commands Used for the Washington, D.C. System Test Start and End View
Command
Step 4
Purpose
show ip eigrp interface
•
Verifies if the EIGRP adjacent neighbor count
is higher than the neighbor count. If so, the
neighbor list could be corrupted.
show interfaces
•
Verifies that there are no input or output errors
or queue drops.
•
Verifies the routers’ throughput.
show clock
•
Verifies that the clock is synchronized with the
NTP server.
show buffer failure
•
Verifies a buffer or memory failure.
show ip igmp interface
•
Verifies that IGMP v2 is communicated
among routers and hosts to dynamically
register or leave a multicast group on a LAN
segment.
show ip igmp groups
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
show mac-address-table multicast vlan vlan-id
•
Verifies that the correct multicast addresses
are present in the output.
show mls ip multicast
•
Verifies that multicast flows create MMLS
entries and that switching of the flow is
performed.
show tacacs
•
Verifies that you are logging in to the correct
TACACS+ server.
show accounting
•
Verifies user account on the router and
switches with privilege 15.
show gateway
•
Verifies that the voice gateway is connected to
gatekeeper egsj-3640-GK.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface that was configured by the
virtual template.
show frame-relay pvc dlci
•
Verifies the encapsulation type, min cir,
fragmentation information, and policies
applied to this PVC.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
Analyze the output of the Cisco IOS show commands listed in Table 103 at 60-minute intervals.
Table 103
show Commands Used for the Washington, D.C. System 60-Minute View
Command
Purpose
show interface trunk
•
Verifies that the VLAN trunkings are formed
correctly.
show ip route summary
•
Verifies the current state of the routing table.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
114
Test Suite 3: Washington, D.C. Campus with Data Center
Table 103
show Commands Used for the Washington, D.C. System 60-Minute View (continued)
Command
Step 5
Purpose
show memory summary
•
Verifies that there are no memory leaks or
errors.
show ip eigrp neighbors
•
Verifies the remote WAN routers.
show policy interface
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy-maps.
show ip rtp header compression
•
Verifies that IP RTP header compression is
enabled for the voice traffic and if there are
any errors.
show call-manager-fallback all
•
Verifies that the remote campus can still make
calls within the campus.
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip mroute summary
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
Analyze the output of the Cisco IOS show command listed in Table 104 at 10-minute intervals.
Table 104
show Commands Used for the Washington, D.C. System Test 10-Minute View
Command
Purpose
show processes cpu
On all the WAN routers:
•
Verifies the CPU utilization.
•
Verifies that CPU capacity is not being
monopolized by a single router.
Expected Results
We expect the following results:
•
CPU utilization was always less than 90 percent.
•
No system or feature errors (such as router or switch failures, reloads, or CPU hogs) occurred during
testing.
•
No significant errors occurred, such as memory allocation errors, memory access errors, memory
leaks, or unexpected interface toggles.
•
Routing tables correctly reflected all available supernets and subnets.
•
All client/server traffic traversed from source to destination through the expected route for the
duration of the test.
•
Routes converged correctly without major delay.
Results
Table 105 shows the Washington, D.C. system test results.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
115
Test Suite 3: Washington, D.C. Campus with Data Center
Table 105
Washington, D.C. System Test Results
Test
Results
Washington, D.C. system
Passed
Washington, D.C. Reliability Test
This section describes in detail the reliability test case as it pertains to the Washington, D.C. campus,
using EIGRP as the interior routing protocol and BGP as the exterior routing protocol. Successful
execution of the system test case is a prerequisite for the execution of this test. The reliability test ran
continuously for 150 hours, with IP routing, NMS, voice, multicast, security, and QoS features enabled.
The following additional features were configured in this test category:
•
Auto-RP RP select on scope
•
BGP MIB feature
•
BGP 4
•
CBWFQ
•
MLPPP performance enhancements
•
CGMP
•
Cisco-Enhanced-Mempool-MIB
•
Cisco-Process-MIB
•
EIGRP
•
H.323 gateway trunk and carrier-based routing enhancements
•
H.323/H.320 gateway
•
IGMP MIB support enhancements for SNMP
•
IGMP snooping querier
•
IGMP Version 2
•
IP MMLS global threshold
•
MSDP
•
PIM MIB extension for IP multicast
•
PIM Version 2
•
PQ
•
QoS—classification and WRED
•
QoS—policing and DSCP classification
•
QoS—packet marking
•
RTP header compression
•
TACACS+
The objective of this test case was to verify that the software (at 100 percent traffic load capacity on each
WAN link) performed reliably for the 150-hour test period.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
116
Test Suite 3: Washington, D.C. Campus with Data Center
Test Plan
The procedure used to perform the Washington, D.C. reliability test follows:
Step 1
Start traffic streams for a 100 percent traffic load by performing the following steps:
a.
Start the BCG (Callgen) to generate calls.
b.
Start Chariot to simulate NetMeeting, Telnet, Lotus, Oracle, FTP, and HTTP traffic.
c.
Start IP/TV, for multicast traffic.
d.
Start IXIA, for background traffic.
Step 2
Use DART to capture information from the routers for 150 hours.
Step 3
Analyze the output of the Cisco IOS show commands listed in Table 106 at the start and end of the
150-hour test period.
Table 106
show Commands Used for the Washington, D.C. Reliability Test Start and End View
Command
Purpose
show vtp status
•
Verifies that the VTP feature is enabled.
show vlan brief
•
Verifies VLAN status and port assignments.
show memory summary
On all the WAN routers:
•
Verifies that there are no memory leaks or
errors.
show ip bgp summary
•
Verifies the BGP routes.
show ip eigrp neighbors detail
•
Verifies that the remote WAN routers are
EIGRP stub-enabled.
show ip eigrp interface
•
Verifies if the EIGRP adjacent neighbor count
is higher than the neighbor count. If so, the
neighbor list could be corrupted.
show interfaces
•
Verifies that there are no input or output errors
or queue drops.
•
Verifies the routers’ throughput.
show clock
•
Verifies that the clock is synchronized with the
NTP server.
show buffer failure
•
Verifies a buffer or memory failure.
show ip igmp interface
•
Verifies that IGMP v2 is communicated
among routers and hosts to dynamically
register or leave a multicast group on a LAN
segment.
show ip igmp groups
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
show mac-address-table multicast vlan vlan-id
•
Verifies that the correct multicast addresses
are present in the output.
show mls ip multicast
•
Verifies that multicast flows create MMLS
entries and that switching of the flow is
performed.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
117
Test Suite 3: Washington, D.C. Campus with Data Center
Table 106
show Commands Used for the Washington, D.C. Reliability Test Start and End View
Command
Step 4
Purpose
show tacacs
•
Verifies that you are logging in to the correct
TACACS+ server.
show accounting
•
Verifies user account on the router and
switches with privilege 15.
show gateway
•
Verifies that the voice gateway is connected to
gatekeeper egsj-3640-GK.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface that was configured by the
virtual template.
show frame-relay pvc dlci
•
Verifies the encapsulation type, min cir,
fragmentation information, and policies
applied to this PVC.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
Analyze the output of the Cisco IOS show commands listed in Table 107 at 24-hour intervals.
Table 107
show Commands Used for the Washington, D.C. Reliability Test 24-Hour View
Command
Step 5
Purpose
show interface trunk
•
Verifies that the VLAN trunkings are formed
correctly.
show ip route summary
•
Verifies the current state of the routing table.
show memory summary
•
Verifies that there are no memory leaks or
errors.
show ip eigrp neighbors
•
Verifies the remote WAN routers.
show policy interface
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy maps.
show ip rtp header compression
•
Verifies that IP RTP header compression is
enabled for the voice traffic and if there are
any errors.
show call-manager-fallback all
•
Verifies that the remote campus can still make
calls within the campus.
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip mroute summary
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
Analyze the output of the Cisco IOS show command listed in Table 108 at 6-hour intervals.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
118
Test Suite 3: Washington, D.C. Campus with Data Center
Table 108
show Command Used for the Washington, D.C. Reliability Test 6-Hour View
Command
Purpose
show processes cpu
On all the WAN routers:
•
Verifies the CPU utilization.
•
Verifies that CPU capacity is not being
monopolized by a single router.
Expected Results
We expect the following results:
•
CPU utilization was always less than 90 percent.
•
No system or feature errors (such as router or switch failures, reloads, or CPU hogs) occurred during
testing.
•
No significant errors occurred, such as memory allocation errors, memory access errors, memory
leaks, or unexpected interface toggles.
•
Routing tables correctly reflected all available supernets and subnets.
•
All client/server traffic traversed from source to destination through the expected route for the
duration of the test.
•
Routes converged correctly without major delay.
Results
Table 109 shows the Washington, D.C. reliability test results.
Table 109
Washington, D.C. Reliability Test Results
Test
Results
Washington, D.C. reliability
Passed with exceptions
Passed with Exceptions Explanation
The Washington, D.C. reliability test passed with exceptions for the following reasons:
•
Because of an automated job scheduling conflict with a data collection tool, 14 hours of test data
was not collected. The test results were not affected.
•
The IXIA traffic generator was turned off to allow problem-characterization work on Chariot and
was not turned on until several hours after the start of the test. There were no problems in the
network and the test results were not affected.
•
About two-thirds into the test, 2 Chariot endpoint stations (EPs) failed due to problems with their
network interface cards. The failures were with the Chariot EPs and did not reflect any problems in
the network. The test results were not affected.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
119
Test Suite 4: Denver Campus
Test Suite 4: Denver Campus
This test suite consisted of three test cases intended to verify the functionality, reliability, and
performance of basic IP QoS at the Denver campus.
The Denver campus is one component of the larger global enterprise topology. The global enterprise
topology comprises five multilayer-design campuses—two large campuses with data centers and three
regional campuses—and 12 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 Denver campus, the following categories (or types) of testing were conducted:
•
Functionality testing: This test case verified basic IP functionality. The test involves Layer 2
protocols—VTP, VLAN trunking, Layer 3 protocol for EIGRP as the interior routing protocol and
BGP as exterior routing protocol, SNMP, multicast, security, VoIP, QoS, Convergence, and Negative
Testing.
•
System testing: This test category verified system performance, using IP routing, NMS, voice,
multicast, security, and QoS
•
Reliability testing: This test case verified system reliability.
This test suite contains the following sections:
•
Topology Description, page 120
•
Denver Functionality Test, page 123
•
Denver System Test, page 146
•
Denver Reliability Test, page 150
Topology Description
The Enterprise Global Denver testbed represents one of the medium-size enterprise campuses in the
North America region. The WAN aggregation routers connecting to the other enterprise global campuses
and to the Internet consist of three Cisco 7206VXR NPE400 routers and a Cisco 7507 RSP8 router
running ATM-T1/T3, P2P T1, HSSI, ATM/FR, or FR/FR links, with ISDN on a Cisco 2600 router as a
backup. The campus also consists of a GE/FE backbone core layer and distribution layer comprised of
four Catalyst 6506s, each with an MSFC2/PFC2. One Catalyst 6506, one Catalyst 4506, and one Catalyst
4003 make up the access layer. A Cisco 3640 router is used as a VoIP voice gateway and registers into
the gatekeeper located at the San Jose headquarters, which places real VoIP calls to other gateways
located at different campuses.
The testbed is used to perform the test for functionality, which includes: IP routing, SNMP, multicast,
security, VoIP, and QoS. EIGRP is the IP IGP routing protocol, and a total of approximately 10,000
routes will be injected by Pagent's route generator at various points in the topology. BGP is the IP EGP
routing protocol for the ISP connection. Global application servers are located at this campus serving
the other campuses and remote sites. The testbed simulates a large amount of end users by using traffic
generators and real UNIX or Linux workstations. Applications such as voice, Telnet, Lotus Notes,
Oracle, FTP, and HTTP are simulated by Callgen, Chariot, IXIA, and Pagent. IPTV is used to generate
multicast traffic.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
120
Test Suite 4: Denver Campus
Figure 10 shows the Denver campus topology with IP addresses.
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
.21
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
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
.18
1.215.240.0 221.1.0.3/32
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-4506-a3
ISDN BRI
ISDN PRI
T1 (P2P)
GE
FE
den-pc3
1.8.1.100
den-ux3
1.9.1.100
98809
Figure 10
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
121
Test Suite 4: Denver Campus
Figure 11 shows the Denver campus topology with interface types.
Figure 11
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
g2/0
fa1/0
egden-7206-w2
g3/3
g3/9
g3/7
g3/1
den-ux1
g1/2
g3/9
fa4/14
g3/5
fa4/0
den-pc2
g3/3
g3/1
g3/5
g3/11
fa1/0
fa4/16
g1/1
g3/7
fa0/0
s6/0-2
ISP 1
egden-6506-d1
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
fa4/16
g3/1
g3/5
g3/3
g3/1
fa4/1/0
g3/7
g3/5
g3/3
s5/0/0:0
New Orleans
128
g3/11
g3/1
egden-6506-c2
egden-6506-d2
fa3/14
g3/2
fa3/16
egden-4506-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
ISDN BRI
ISDN PRI
T1 (P2P)
GE
FE
g1/00
egden-7507-w4
L.A.
98810
Houston
384
den-pc3
Platform and Software Version Information
Table 110 lists the platforms, router names, software versions, and software images configured in the
Denver network topology for this test suite.
Table 110
Denver Platform, Router Name, Software Version, and Software Image Table
Platform
Router Name
Software Version
Software Image
Cisco 7206VXR
egden-7206-w1
12.2(16b)
c7200-js-mz.122-16b
Cisco 7206VXR
egden-7206-w2
12.2(16b)
c7200-js-mz.122-16b
Cisco 7206VXR
egden-7206-w3
12.2(16b)
c7200-js-mz.122-16b
Cisco 7507
egden-7507-w4
12.2(15)T5
rsp-jsv-mz.122-15.T5
Cisco 3640
egden-3640-v1
12.2(16b)
c3640-a3js-mz.122-16b
Cisco 2621
egden-2600-isdn
12.2(16b)
c2600-js-mz.122-16b
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Catalyst 6500 MSFC egden-6506-c1
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
122
Test Suite 4: Denver Campus
Table 110
Denver Platform, Router Name, Software Version, and Software Image Table (continued)
Platform
Router Name
Software Version
Software Image
Catalyst 6500 MSFC egden-6506-c2
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Catalyst 6500 MSFC egden-6506-d1
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Catalyst 6500 MSFC egden-6506-d2
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Catalyst 6500
egden-6506-a1
7.6(1)
cat6000-sup2k8.7-6-1
Catalyst 4000
egden-4003-a2
7.6(1)
cat4000-k8.7-6-1
Catalyst 4500
egden-4506-a3
12.1(13)EW2
cat4000-is-mz.121-13.EW2
Denver Functionality Test
This is the functionality test case for the Cisco IOS nEverest Enterprise Global project as it pertains to
the Denver campus. The test involves basic IP testing (Layer 2 protocols, such as STP and VLAN
trunking, and Layer 3 protocols, such as HSRP, EIGRP for the interior routing protocol, and BGP for the
exterior routing protocol.), network management testing, multicast testing, security testing, voice
testing, and QoS testing. The functionality test case verified basic IP functionality. The tests are
described in the following sections:
•
Basic IP
•
Network Management
•
Multicast
•
Security
•
Voice
•
QoS
The testing in each section was performed sequentially and as independently as possible. The Denver
functionality testing was conducted as follows:
1.
Basic IP testing was performed in conjunction with Network Management Testing (NMS). Network
Management was utilized to collect the test information.
2.
After completion of the basic IP test, IP configurations were made stable, and any traffic loading
was terminated in preparation for the next test.
3.
Multicast testing was performed, again with NMS monitoring.
4.
After completion of the multicast test, IP configurations were made stable, and any traffic loading
was terminated in preparation for the next test.
5.
Security testing was performed in conjunction with NMS monitoring.
6.
After completion of the security test, IP configurations were made stable, and any traffic loading
was terminated in preparation for the next test.
7.
Voice testing was performed in conjunction with NMS monitoring.
8.
After completion of the voice test, IP configurations were made stable, and any traffic loading was
terminated in preparation for the next test.
9.
QoS testing was performed in conjunction with NMS monitoring.
10. After completion of the QoS test, IP configurations were made stable, and any traffic loading was
terminated in preparation for the next test.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
123
Test Suite 4: Denver Campus
Basic IP
The objectives for this test case were as follows:
•
Verify the basic network operation (that is, network connectivity).
•
Verify that the routing protocol features can be incorporated into the Denver campus.
•
Verify that the major IP routing features work as expected.
In this test case, the following individual tests were conducted:
•
Layer 2 Protocols and HSRP
•
EIGRP with BGP routing test
Layer 2 Protocols and HSRP
This test involved testing various Layer 2 protocols and HSRP. The following features were included in
the test plan:
•
VTP and VLAN
•
VLAN trunking
•
STP
•
HSRP
Test Plan
The procedure used to perform the Layer 2 protocols and HSRP test follows:
Step 1
Set up the VLANs. The access switch VLAN model is model number 1, “share VLANs across Access
Layer switches,” for this campus. Each building is in a separate VTP domain. The two distribution layer
routers work in VTP server mode, and all access layer switches work in VTP transparent mode.
VLAN 1 is for control traffic on all switches by default. VLAN 2 is for a backdoor network connection,
configured only on the access layer switches. VLANs 11 to 20 are used for end-user networks that are
configured across all access layer switches and the distribution layer routers. VLANs 21 to 110 are used
to generate routes, which are configured only on distribution layer routers.
Step 2
Use the CatOS show vlan command, the CatOS show vtp domain command, and the Cisco IOS show
vtp status command to verify the VTP and VLAN configuration.
Step 3
Set up VLAN trunking. All links between switches are L2 dot1q trunking. The trunk mode is
desirable/desirable.
Step 4
Use the Cisco Native IOS show interface trunk command and the CatOS show trunk command to
verify that the VLAN trunks are formed correctly.
Step 5
Set up the STP feature (root placement). Enable portfast on all ports of the access layer switches. Enable
uplinkfast on all access layer switches. Use the Cisco IOS show spanning-tree root command to verify
that the spanning tree roots are on the distribution layer routers.
The left distribution layer router in a building block is the primary root for all odd-numbered VLANs
and the secondary root for all even-numbered VLANs. The right distribution router in a building block
is the primary root for all even-numbered VLANs and the secondary root for all odd-numbered VLANs.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
124
Test Suite 4: Denver Campus
Step 6
Step 7
Step 8
Set up HSRP. The left distribution layer router serves as the HSRP active group for all odd-numbered
VLANs. The right distribution layer router serves as the HSRP active group for all even-numbered
VLANs.
a.
Enable the HSRP interface track feature so that if both uplinks from any distribution layer router to
the core go down, then the HSRP active group will fail over to the other distribution layer router.
b.
Use HSRP preempt to ensure that the high-priority group is the active group.
c.
Set HSRP active group and STP root consistently to keep symmetry between Layer 2 and Layer 3.
Layer 2 and Layer 3 load balancing are per VLAN and are done through STP and HSRP.
Use the Cisco IOS show standby brief command every 5 minutes to verify that each distribution layer
router is the active HSRP router for half of the VLANs (either the even-numbered VLANs or the
odd-numbered VLANs). The expected output should show the following:
•
The HSRP state is either active or standby.
•
The proper router is active for the appropriate HSRP groups (the left router should be active for
odd-numbered groups, the right router should be active for even-numbered groups).
•
HSRP priority is either 110 or 95 respective to the active or standby state.
•
The router sees other HSRP routers for the VLAN.
•
HSRP group numbers are unique per switched domain.
•
The HSRP group address is correct.
Conduct a negative test of STP and HSRP by performing the following steps:
a.
Shut down any one of the distribution routers in the same building and use the Cisco IOS show
spanning-tree root command to verify that the spanning tree root changed to the active distribution
layer router in the building.
b.
Use the show standby brief command to verify that the HSRP secondary router takes over the active
state for all the VLANs. The expected output should show the following:
•
The HSRP state is either active or standby.
•
The proper router is active for the appropriate HSRP groups (the left router should be active for
odd-numbered groups, the right router should be active for even-numbered groups).
•
HSRP priority is either 110 or 95 respective to the active or standby state.
•
The router sees other HSRP routers for the VLAN.
•
HSRP group numbers are unique per switched domain.
•
The HSRP group address is correct.
c.
Disconnect (unplug) both uplinks from one distribution layer router to the core layer in the building
and use the Cisco IOS show standby brief command to verify that the HSRP active group will fail
over to another distribution layer router.
d.
Recover the uplinks, then use the show standby brief command to verify that the HSRP active
group will switch back. The expected output should show the following:
•
The HSRP state is either active or standby.
•
The proper router is active for the appropriate HSRP groups (the left router should be active for
odd-numbered groups, the right router should be active for even-numbered groups).
•
HSRP priority is either 110 or 95 respective to the active or standby state.
•
The router sees other HSRP routers for the VLAN.
•
HSRP group numbers are unique per switched domain.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
125
Test Suite 4: Denver Campus
•
The HSRP group address is correct.
Expected Results
We expect the following results:
•
The VTP and VLAN configuration will work correctly.
•
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 111 shows the Denver Layer 2 protocols and HSRP test results.
Table 111
Denver Layer 2 Protocols and HSRP Test Results
Test
Results
Denver Layer 2 protocols and HSRP
Passed
EIGRP with BGP Routing
This test involved testing EIGRP with BGP routing. The following features were included in the test
plan:
•
Route summarization
•
Route filtering
•
EIGRP stub router functionality
•
Route redistribution and default route generation
•
Log event or change functionality
•
BGP policy control (specifically, autonomous system [AS] prepend and route filtering)
•
EIGRP metric tuning—link delay and bandwidth
Test Plan
This test verified route summarization, route filtering, route redistribution, EIGRP stub router
functionality, route redistribution and default route generation, log event or change functionality, BGP
policy control, and EIGRP metric tuning. Several parts to this test plan are described in the sections that
follow.
Route Summarization and Filtering Test
The procedure used to perform the route summarization and filtering test follows:
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
126
Test Suite 4: Denver Campus
Step 1
Turn off EIGRP auto-summary on all EIGRP-enabled routers. Route summarization is manually done
on the following devices:
a.
On campus core layer routers egden-6506-c1 and egden-6506-c2, end-user networks from the
buildings will be summarized into /20 and /21 routes. The devices’ interconnectivity network and
loopback interface routes within the whole campus including data center are summarized into one
/21 route.
b.
On campus WAN aggregation routers egden-7206-w1 and egden-7206-w2, the summarized routes
are redistributed into BGP and advertised to BGP neighbors. Inter-campus WAN connectivity
network routes are summarized, by the sourcing campus, into one /21 route and advertised into the
local campus.
Intercampus eBGP connections are sourced and destined to the respective loopback interfaces on
the routers. iBGP is configured between WAN Aggregation routers' respective loopback interfaces.
c.
Disable EIGRP (passive-interface) on the WAN links to the other major campuses.
Other campus routes learned by BGP are redistributed into EIGRP with varying metrics to ensure
that the core layer routers select the best intercampus route.
d.
On campus distribution layer routers egden-6506-d1 and egden-6506-d2, building routes are
summarized to /21 and /20 routes and subsequently advertised to the connected core layer routers.
e.
On campus WAN aggregation routers egden-7206-w3 and egden-7507-w4, all remote site WAN
links routes in remote group 1 are summarized into one /21 route. The summary route is then
advertised by the WAN aggregation router to the campus core layer routers.
Summarized local campus routes and the default route are advertised to the remote sites by the WAN
aggregation router. Filtration may use tag matching using route maps. The remote site branch router
has the same local campus route summarization schema as the campus WAN aggregation routers
mentioned earlier.
Step 2
Configure a distribution list on the core layer routers egden-6506-c1 and egden-6506-c2 to allow only
local campus routes and default routes to be advertised to the distribution layer routers.
Step 3
Configure a distribution list on the WAN aggregation routers egden-7206-w3 and egden-7507-w4 to
allow only local campus summarized routes and the default route to be advertised to the remote sites. As
an alternative, configure a route map to permit routes matching local campus tags to be advertised to the
remote sites.
Step 4
Configure all the building and data center distribution layer routers and voice routers as EIGRP stub
routers, so that the EIGRP queries do not propagate to the distribution layer routers or the voice routers.
Route Redistribution and Default Route Generation Test
The procedure used to perform the route redistribution and default route generation test follows:
Step 1
Configure BGP and EIGRP routing on the campus WAN aggregation routers egden-7206-w1 and
egden-7206-w2. BGP will receive ISP advertised routes in addition to intercampus routes.
Step 2
Redistribute BGP into EIGRP and permit only the intercampus routes to be tagged and redistributed into
EIGRP. A static default route is created by the router connected to the ISP and advertised into the whole
EIGRP AS and will be permitted into the remote sites. Redistribute untagged EIGRP routes into BGP.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
127
Test Suite 4: Denver Campus
A backup static default route will be advertised by the secondary ISP-connected router, using a floating
static route. The default route will not be advertised by BGP. Varying metrics will be applied to the routes
being redistributed based on the number of BGP ASs that the intercampus route learned.
BGP Policy Control Test
The procedure used to perform the BGP policy control test follows:
Step 1
Configure logging of changes on all the EIGRP- and BGP-enabled routers by using the Cisco IOS
eigrp log-neighbor-changes command and the bgp log-neighbor-changes command.
The BGP AS 64504 is the AS used for all Denver campus AS border routers. All BGP routes are accepted
on the BGP routers.
Step 2
Configure egden-7206-w2 for route filtering. This default route is redistributed into EIGRP for the
connection to the ISP.
Step 3
Configure the egden-7206-w2 BGP policy so that the traffic from the ISP destined for the local campus
prefixes gets high priority (by using AS prepending) to the advertised prefixes of the nonlocal campuses.
All intercampus routes will be advertised to the ISP, but the AS will be prepended three times.
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 routers to enable symmetric
routing for the building end-user networks. On the left distribution layer router (the HSRP primary group
for all the odd-numbered VLANs), change the SVI delay on the even-numbered VLAN interface from
10 microseconds to 50 microseconds. This configuration enables the left distribution layer router to
advertise a less desirable routing metric to the core layer routers for all the even-numbered VLAN
interfaces. Similarly configure the right distribution layer router.
Step 2
Configure all the SVI interfaces on the distribution layer routers as EIGRP passive interfaces, so that an
EIGRP neighbor will not be created between two distribution layer routers.
Step 3
Configure the Cisco IOS no peer neighbor-route command for all the encapsulated PPP WAN
interfaces to avoid suboptimal routing for these WAN interface routes. The interfaces are as follows:
•
Interface h3/0 on egden-7206-w2
•
Interface s3/0:0 on egden-7206-w3
•
Interface s5/0/0:0 on egden-7507-w4
Step 4
Apply MD5 hashed authentication to all WAN links running EIGRP, provided the authentication
configuration passes a test bed configuration test, is configurable, neighbors are formed, and minimal
routes are advertised.
Step 5
Enable BGP route dampening on neighbor relationships between the ISP and intercampus neighbors.
Step 6
Analyze the output of the Cisco IOS show commands listed in Table 112, which lists each show
command and the role it plays in the Denver EIGRP with BGP routing test.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
128
Test Suite 4: Denver Campus
Table 112
show Commands Used in the Denver EIGRP with BGP Routing Test
Command
Purpose
show ip route
On all routers:
and
•
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 summary
show ip route
On the core layer and distribution layer routers:
•
show processes cpu
show memory summary
show logging
show ip bgp
and
Verifies the symmetric routing for the building
end-user networks.
On all routers every 10 minutes:
•
Verifies the CPU utilization.
•
Verifies that CPU capacity is not being
monopolized by a single router.
On all routers every 60 minutes:
•
Verifies that there are no memory leaks or other
memory errors.
•
Verifies that there are no significant errors for
EIGRP or BGP routing.
On egden-7206-w2
•
Verifies that BGP routing is working correctly.
show ip bgp summary
show ip bgp
On the ISP routers:
and
•
Verifies BGP AS prepending policy control.
show ip route
and
Note
ping
show interfaces [interface type]
show ip eigrp neighbors detail
The show ip bgp command in this phase
of testing will be a verbose output (at
least 50,000 lines long), so only two
captures (beginning and end) of this
command output should be collected.
On all the WAN routers:
•
Verifies that there are no input errors, output
errors, or queue drops.
•
Verifies the router's throughput.
On the core layer routers egden-6506-c1 and
egden-6506-c2:
•
Verifies that the distribution layer routers are
EIGRP stub-enabled.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
129
Test Suite 4: Denver Campus
Table 112
show Commands Used in the Denver EIGRP with BGP Routing Test (continued)
Command
Purpose
show ip eigrp neighbors
On the distribution layer routers:
show ip route [interface name]
•
Verifies that the EIGRP neighbor was not
created between two distribution layer routers.
•
Verifies that specific WAN interface routes are
not in the routing table.
Expected Results
We expect the following results:
•
The routes are summarized correctly.
•
The route filters function correctly.
•
CPU utilization is less than 90 percent.
•
Memory consumption is stable.
•
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 significant EIGRP or BGP routing errors and 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 113 shows the Denver EIGRP with BGP routing test results.
Table 113
Denver EIGRP with BGP Routing Test Results
Test
Results
Denver EIGRP with BGP routing
Passed
Network Management
This section describes the network management testing in the Denver campus. The following features
were included in the test plan:
•
MIB walk automation script (snmp_walk_test) and traps
•
Syslog and NTP
The objectives of the SNMP MIB testing were as follows:
•
Ensure that the information stored in the MIB database can be accessed, propagated, read, and
written if applicable.
•
Ensure that the operation of the OID values reflects the actual operation on the device.
•
Ensure that there were no SNMP traps.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
130
Test Suite 4: Denver Campus
Test Plan
The procedure used to perform the network management test follows:
Step 1
Configure MIB walk and traps.
The MIB walk automation script (snmp_walk_test) will test the OID and traps by platforms and
technologies, report their value, and monitor the UUT behavior. HP OpenView and CiscoWorks2000 are
used as the SNMP receivers.
Step 2
Configure all the routers and switches so that the snmp_walk_test script will work properly.
Step 3
Upload the following MIBs to the snmp_walk_test script:
•
Basic IP:
– CISCO-PROCESS-MIB
– OLD-CISCO-INTERFACE-MIB
– OLD-CISCO-ENV-MIB
– CISCO-BGP4-MIB
•
Multicast:
– CISCO-IPMROUTE-MIB.my
– CISCO-IGMP-MIB.my
– CISCO-MSDP-MIB.my
– CISCO-PIM-MIB.my
•
Voice:
– CISCO-VOICE-DIAL-CONTROL-MIB.my
•
QoS:
– CISCO-CLASS-BASED-QOS-MIB-CAPABILITY.my
– CISCO-CLASS-BASED-QOS-MIB.my
– CISCO-PORT-QOS-MIB.my
– CISCO-QOS-POLICY-CONFIG-MIB.my
Step 4
Set up the eg-cw2k (CiscoWorks2000) server in the San Jose campus as the UNIX NTP and syslog
server.
Step 5
Use DART to capture show command output from the routers.
Step 6
Use the show processes cpu command to verify the CPU utilization and to verify that the CPU capacity
is not being monopolized by a single router.
Step 7
Use the show memory summary command to verify that there are no memory leaks or errors.
Step 8
On server eg-cw2k, verify that syslogd is still running.
Step 9
Use the Cisco IOS show clock command and the CatOS show time command to verify that the clock is
synchronized with the NTP server.
Step 10
Verify that the Pat scripts are able to send e-mail notification for error conditions on the routers or
switches.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
131
Test Suite 4: Denver Campus
Step 11
Use the show log command or the show align command to verify that there are no other significant
errors.
Expected Results
We expect the following results:
•
Information stored in the MIB can be accessed, propagated, read, and written.
•
Operation of the OID values reflect the actual operation of the device.
Results
Table 114 shows the Denver network management test results.
Table 114
Denver Network Management Test Results
Test
Results
Denver network management
Passed
Multicast
The objective of the Denver campus multicast testing was to verify the functionality of multicast features
across multiple Cisco platforms with various sets of Cisco IOS and CatOS releases.
The following features were included in the test plan:
•
IGMP-v2
•
IGMP snooping
•
MMLS
•
MDS
•
PIM sparse-dense mode
The test was set up to use Cisco IP/TV as a one-to-many video and audio streaming application by
configuring an IP/TV server at the San Jose campus data center to stream six multicast groups. There
were three video and three audio groups.
Test Plan
Setup
The procedure used to set up the multicast test follows:
Step 1
Configure Cisco IP/TV by performing the following steps:
a.
Connect the IP/TV server to switch egsj-6505-sa3.
b.
Connect the IP/TV clients to switch egden-6506-a1.
c.
Configure the IP/TV server to stream two programs as follows:
•
The program “G1” contains a 239.192.1.0/24 multicast address scope and consists of a
600-kbps video and audio stream. The IP/TV clients at all campuses and remote sites will
receive this program.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
132
Test Suite 4: Denver Campus
•
The program “G2” contains a 239.192.2.0/24 multicast address scope and consists of a
300-kbps video and audio stream.
Step 2
Enable IGMP-v2. This feature is enabled by default in Native IOS and Cisco IOS software, so no
additional configuration is required.
Step 3
Enable IGMP snooping on the following Denver campus Layer 2 access switch egden-6506-a1.
Step 4
Enable MMLS. This feature is enabled by default in Native IOS, so no additional configuration is
required.
Step 5
Enable MDS on router egden-7505-w4.
Step 6
Enable PIM sparse-dense mode on all Layer 3 Native IOS and Cisco IOS multicast devices in the Denver
campus.
Verification
The procedure used to perform the multicast verification test follows:
Step 1
Use DART to capture the output of the generic show commands listed in Table 115.
Table 115
Generic show Commands Used in the Denver Multicast Verification Test
Command
Purpose
•
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 or other
memory errors.
show buffer failure
•
Verifies a buffer or memory failure.
show interfaces [interface type]
•
Verifies that there are no input errors, output
errors, or queue drops.
•
Verifies the router's throughput.
•
Verifies that there are no other significant errors.
show processes cpu
show logging
Step 2
Using the show commands listed in Table 116, verify that CGMP is communicated among routers and
switches to dynamically join or leave a multicast group on a LAN segment.
Table 116
show Commands Used in the Denver Multicast CGMP Verification Test
Command
Purpose
show cgmp statistics
•
Displays the CGMP statistics.
show cgmp leave
•
Verifies the status of the CGMP leave feature.
show multicast router
•
Displays the ports that have IGMP- or
RGMP-capable routers assigned to them.
show multicast group
•
Verifies the multicast group information.
show multicast group cgmp
•
Displays the multicast group configuration
information learned via CGMP.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
133
Test Suite 4: Denver Campus
Step 3
Using the show commands listed in Table 117, verify that IGMPv2 is communicated among routers and
switches to dynamically register or leave a multicast group on a LAN segment. In addition, verify the
following:
•
The router with the lower IP address is the correct IGMP querier.
•
The router installs group members upon receipt of IGMP join messages.
•
All groups are seen for all IGMP joined groups.
•
The router sends PIM join messages as a consequence of receiving IGMP join messages and creates
the corresponding (*,G) entries.
Table 117
show Commands Used in the Denver Multicast IGMPv2 Verification Test
Command
Step 4
Purpose
show ip igmp interface
•
Verifies that IGMP v2 is communicated among
routers and hosts to dynamically register or
leave a multicast group on a LAN segment.
show ip igmp groups
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
Using the show commands listed in Table 118, verify that IGMP snooping functions as follows:
•
IGMP snooping manages multicast traffic at Layer 2 by configuring the Layer 2 LAN port
dynamically to forward multicast traffic to only those ports that want to receive it.
•
IGMP snooping constrains multicast traffic that exits through LAN ports to which hosts are
connected.
Table 118
show Commands Used in the Denver Multicast IGMP Snooping Verification Test
Command
Purpose
show igmp statistics
On Layer 2 switches:
•
show multicast group igmp
On Layer 2 switches:
•
show multicast group count igmp
Verifies the multicast group configuration
information learned via IGMP.
On Layer 2 switches:
•
show ip igmp interface
Verifies the IGMP statistics for a particular
VLAN.
Verifies the total count of multicast addresses
(groups) in a VLAN learned via IGMP.
On Layer 3 switches:
•
Verifies that IGMP snooping is globally
enabled.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
134
Test Suite 4: Denver Campus
Table 118
show Commands Used in the Denver Multicast IGMP Snooping Verification Test
Command
Purpose
show ip igmp snooping mrouter
On Layer 3 switches:
•
show mac-address-table multicast vlan-id
On Layer 3 switches:
•
Step 5
Verifies that the correct multicast addresses are
present in the output.
Using the show commands listed in Table 119, verify that MMLS functions as follows:
•
Multicast flows create MMLS entries and switching of the flow is performed using hardware
shortcuts. In the Catalyst 6500s, the flows are taking the correct paths.
•
The flows are using the expected multicast forwarding entry (*,G) or (S,G).
•
Hardware-based flows are created where expected.
•
Identify the lowest rate of the traffic flow at which a hardware shortcut is created.
•
CPU utilization does not increase. If it does, then there is a possibility that flows are being software
switched.
•
On DFC cards, forwarding tables on line cards are the same as on the processor card.
Table 119
show Commands Used in the Denver Multicast MMLS Verification Test
Command
Step 6
Verifies that the correct multicast router has
been learned.
Purpose
show mls ip multicast summary
•
Verifies that hardware-based flows are created
where expected.
show mls ip multicast
•
Verifies that multicast flows create MMLS
entries and that switching of the flow is
performed.
show mls ip multicast group
•
Displays multilayer IP multicast group
information.
show mls ip multicast source
•
Displays the MLS IP information for a specific
destination IP address.
show mls ip multicast interface
•
Displays the MLS IP information for a specific
interface.
show mls ip multicast statistics
•
Displays the statistics for the MLS IP multicast
entries.
Using the show commands listed in Table 120, verify that MDS functions as follows:
•
The VIP interfaces on Cisco 7500 routers are MDS-enabled.
•
Multicast distributed switching is enabled.
•
Multicast traffic is distributed-switched.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
135
Test Suite 4: Denver Campus
Table 120
show Commands Used in the Denver Multicast MDS Verification Test
Command
Step 7
Purpose
show ip mds interface
•
Verifies the status of MDS interfaces.
show ip pim interface detail
•
Displays detailed information about each
interface configured for PIM.
show ip mds forwarding
•
Verifies the MFIB table and forwarding
information for multicast distributed switching
(MDS).
show ip mds summary
•
Displays a summary of the MFIB table for
MDS.
Using the show commands listed in Table 121, verify that PIM sparse-dense mode functions as follows:
•
Multicast forwarding is achieved using PIM. PIM interacts with the IP unicast forwarding table to
determine the correct path to the source of the multicast packets (RPF), and interacts with IGMP to
recognize networks that have members of the multicast group.
•
All expected PIM neighbors are present and no unknown routers appear.
•
The correct DR election is made on the LAN segment.
•
The correct IIF and OIF lists, RPF, and flags are present in the (*,G) or (S,G) entries.
•
The correct RP mapping is shown for all groups.
Table 121
show Commands Used in the Denver Multicast PIM Sparse-Dense-Mode Verification Test
Command
Purpose
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
show ip pim rp mapping
•
Verifies all the group-to-RP mappings of which
the router is aware (either configured or learned
from Auto-RP).
show ip pim rp
•
Verifies that the active rendezvous points (RPs)
are cached with the associated multicast routing
entries.
show ip mroute
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
show ip mroute count
•
Displays statistics about the group and source,
including number of packets, packets per
second, average packet size, and bytes per
second.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
136
Test Suite 4: Denver Campus
Expected Results
We expect the following results:
•
IGMPv2 is communicated among routers and hosts to dynamically register or leave a multicast
group on a LAN segment.
•
IGMP snooping manages multicast traffic at Layer 2 by configuring Layer 2 LAN ports dynamically
to forward multicast traffic to only those ports that want to receive it.
•
IGMP snooping constrains multicast traffic that exits through LAN ports to which hosts are
connected.
•
Multicast flows create MMLS entries and switching of the flow is performed using hardware
shortcuts in the Catalyst 6500.
•
Multicast forwarding is achieved using PIM.
•
The rate that a sender from the source list can send to a multicast group in the group list is
appropriate.
Results
Table 122 shows the Denver multicast test results.
Table 122
Denver Multicast Test Results
Test
Results
Denver multicast
Passed
Security
This security test was conducted for the Denver campus. This test case verified the functionality of AAA
and SNMP features commonly used by enterprise customers that integrate across multiple Cisco
platforms and Cisco IOS releases at the system level.
The objectives of the security test were as follows:
•
Verify TACACS+ AAA services at a system level for all access, distribution, core, and WAN edge
devices in the global topology.
The following features were configured for the security test:
•
AAA TACACS+
•
Other Security commands
Test Plan
Setup
The procedure used to set up the Denver security test follows:
Step 1
Configure encryption service facility and AAA TACACS+.
Step 2
Configure the time-stamping service facility for logging.
Step 3
Disable all unnecessary services.
Step 4
Configure an enable password.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
137
Test Suite 4: Denver Campus
Step 5
Configure a console port password.
Step 6
Configure a vty password.
Verification
The procedure used to perform the Denver security verification test follows:
Step 1
Use the show tacacs command to verify the TACACS+ configuration values.
Step 2
Use the show accounting command to verify the user account on the router and switch.
Expected Results
We expect the following results:
•
TACACS+ AAA services function properly at a system level for all access, distribution, core, and
WAN edge devices in the global topology.
Results
Table 123 shows the Denver security test results.
Table 123
Denver Security Test Results
Test
Results
Denver security
Passed
Voice
The purpose of the voice test was to deploy and verify the VoIP deployment scenarios for large
Enterprise customers that want to minimize the operations cost of telephony by utilizing IP telephony
over traditional services. The overall objectives of the voice test case were as follows:
•
Verify that voice can be incorporated into the Denver campus.
•
Verify the operation of the Cisco IOS release to test the AVVID and legacy voice interoperability.
•
Collect and document the test results.
•
Ensure that the system behaves as expected.
Voice Testing
The following features were configured for voice testing:
•
Legacy H.323 VoIP
•
SCCP
Test Plan
The voice test verified that voice traffic operated properly across the network. There are several parts to
this test plan, described in the sections that follow.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
138
Test Suite 4: Denver Campus
Set Up Legacy H.323
The procedure used to set up the legacy H.323 voice test follows:
Step 1
Configure voice gateway egden-3640-v1 for H.323.
Step 2
Check that egden-3640-v1 is registered with gatekeeper egsj-3640-gk in the San Jose campus by using
the show gateway command on the egden-3640-v1 router.
Step 3
Configure Callgen telephony.
Step 4
Configure the BCG to generate traffic.
Set Up SCCP
The procedure used to set up the SCCP voice test follows:
Step 1
Configure T1 CAS and FXS SCCP voice gateways on the Catalyst 4506.
Step 2
Configure inline power and real IP telephones on the Catalyst 4506
Step 3
Verify that the T1 CAS, the FXS, any transcoding devices, and all real or simulated IP telephones on the
Catalyst 4506 appear and are registered in CallManager.
Step 4
Configure Callgen SCCP to generate test traffic.
Step 5
Enable IP telephony gateway mode for the Catalyst the 4506.
Step 6
Enable IP telephony transcoding service.
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 use to perform the voice traffic verification test follows:
Step 1
Configure an IP phone manually, install it in each campus, and make calls to test voice quality.
Step 2
Start the bulk call traffic generators by performing the following steps:
a.
Start all BCG channels to San Jose (3 calls), Phoenix (8 calls), New Orleans (1 call), and Colorado
Springs (1 call). Note: Refer to the dial plan and voice design document.
b.
Using the show channel command on the Callgens, verify for 5 minutes that all originate and
terminate BCG channels have started and are progressing correctly with no problems.
Step 3
Verify for 5 minutes that all originate and terminate Callgen SCCP channels have started and are
progressing correctly with no problems.
Step 4
Analyze the output of the show commands listed in Table 124. Use the listed commands on all the WAN
routers using the DART tool every 60 seconds for the show processes cpu command, and every
5 minutes for all the others—for a duration of 2 hours.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
139
Test Suite 4: Denver Campus
Table 124
show Commands Used for the Denver Voice Traffic Verification Test
Command
Purpose
show clock
•
show interfaces [interface type]
Verifies the current time.
On all outbound WAN 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 memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
The show commands listed in Table 124 were used on the WAN routers and interfaces listed in
Table 125.
Table 125
Step 5
Denver WAN Aggregation Routers and Interfaces
Router
Interface
egden-7206-w2
HSSI3/0
egden-7206-w3
Serial3/0:0, ATM5/0.127
egden-7507-w4
ATM5/1/0
Stop the bulk call traffic generators and verify results by performing the following steps:
a.
Stop all BCGs after 1 hour of run time.
b.
Use the show channel command of the Callgen testing tool to verify that all originate and terminate
BCG channels are functioning correctly without any significant errors.
c.
Capture the BCG output statistics by using the show channel command in the BCG.
Expected Results
We expect the following results:
•
Voice traffic sent efficiently and all voice channels originated and terminated properly.
•
All originate and terminate BCG channels work properly and without any significant errors.
Results
Table 126 shows the voice traffic verification test results.
Table 126
Denver Voice Traffic Verification Test Results
Test
Results
Denver voice traffic verification
Passed
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
140
Test Suite 4: Denver Campus
QoS
The high-level objective of the QoS testing was to validate a robust QoS solution for protecting critical
application data, including real-time VoIP, on interarea WAN links, including classification and marking
as close to the network edge as possible, and remarking from L2 CoS to L3 QoS.
QoS Setup Test
The QoS setup test verified that QoS features were configured correctly and that the QoS features were
applied to traffic classes as anticipated. In this test, the MQC three-step model was used to configure the
traffic classes, class maps, and policy maps.
The following features were included in the test plan:
•
Classification and marking—ACLs, NBAR (remote campuses only), Table Maps, IP Precedence,
and DSCP
•
Congestion avoidance—dWRED (differentiated services-based WRED)
•
Congestion management—LLQ and dLLQ
•
Traffic conditioning—FRTS and ATM Traffic Shaping
•
Link efficiency mechanisms—MLPPP LF, cRTP, dcRTP, FRF.12
Test Plan
The procedure used to perform the QoS setup test follows:
Step 1
Step 2
Step 3
Configure L2 CoS to L3 QoS remarking on the following access layer switches:
•
egden-6505-a1
•
egden-4003-a2
•
egden-4507-a3
Define the access lists and traffic classes using the following guidelines:
•
Classify VoIP traffic into a class map called “Real-Time.”
•
Classify applications with small or infrequently sent packets, such as Telnet and voice signaling,
into a class map called “Interactive.”
•
Classify the mission-critical traffic or traffic that can consume large amounts of bandwidth, such as
Lotus Notes and Oracle, into a class map called “Transactional.”
•
Classify IP/TV multicast video conferencing and multicast signaling into the “Streaming” class.
•
Classify HTTP and FTP traffic into the “class-default” class, which is the class map for best-effort
service.
Associate the policy maps and actions with each class of traffic by performing the following steps:
a.
Configure a policy map called "OUT-LAN-GE" on distribution layer switches egden-6506-d1 and
egden-6504-d2. This configuration tests the DSCP feature.
b.
Configure a policy map called "OUT-LAN-XXX" on the core switches egden-6506-C1 and
egden-6506-C2. This configuration tests the LLQ feature of QoS.
c.
Configure a policy map called "OUT-WAN-XXX" on intercampus WAN aggregation routers
egden-7206-w1 and egden-7206-w2. This configuration tests the dWRED and LLQ features of QoS.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
141
Test Suite 4: Denver Campus
Step 4
d.
Configure a policy map called "OUT-WAN-XXX" on campus-remote WAN aggregation router
egden-7507-w4. This configuration tests the MLP interleaving, cRTP, FRTS, dTS, and ATM shaping
features of QoS.
e.
Configure a policy map called “OUT-LAN-FE” on the egden-3640-v1 router. This configuration
tests the ACLs, port numbers, and DSCP features of QoS.
Attach policy maps to the interfaces listed in Table 127, and apply the other appropriate QoS features.
Table 127 shows the router name, the policy map created, and the interface to which the policy map was
applied (attached).
Table 127
Routers, Policy Maps, and Interfaces for the Denver QoS Setup Test
Router
Policy Map
Interface
egden-7206-w1
OUT-LAN-FE
Fa1/0, Fa2/0, Fa3/0
egden-7206-w2
OUT-WAN-HSSI
Hssi 3/0
egden-7206-w2
OUT-LAN-FE
Fa0/0, Fa1/0, Fa2/0
egden-7206-w3
OUT-WAN-T1
Serial3/0:0
egden-7206-w3
OUT-WAN-128K
Virtual-Template 20, Virtual-Template 21
egden-7206-w3
OUT-LAN-GE
Gi2/0
egden-7206-w3
OUT-LAN-FE
Fa0/0, Fa1/0
egden-7507-w4
OUT-WAN-T1
Serial5/0/0:0
egden-7206-w4
OUT-LAN-GE
Gi0/0/0, Gi1/0/0
egden-7206-w4
OUT-LAN-FE
Fa4/1/0
egden-7507-w4
OUT-WAN-128K
Serial5/0/1:1
egden-6506-d1
OUT-LAN-GE
Gi3/1, Gi3/3
egden-6506-d2
OUT-LAN-GE
Gi3/1, Gi3/3
egden-6506-c1
OUT-LAN-GE
Gi3/3, Gi3/5, Gi3/11
egden-6506-c1
OUT-LAN-FE
Fa4/14, Fa4/25, Fa4/26
egden-6506-c2
OUT-LAN-GE
Gi3/1, Gi3/3, Gi3/5, Gi3/7, Gi3/9
egden-6506-c2
OUT-LAN-FE
Fa4/14, Fa4/16, Fa4/47
egden-3640-v1
OUT-LAN-FE
Fa1/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 128 shows the QoS setup test results.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
142
Test Suite 4: Denver Campus
Table 128
Denver QoS Setup Test Results
Test
Results
Denver QoS setup
Passed
QoS Verification Test
This test verified that incoming and outgoing 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, data traffic was 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 Chariot traffic testing tool to congest the network.
Step 2
Use DART to capture the output of the Cisco IOS show commands listed in Table 129 and analyze the
output of those commands. Use the commands on the WAN aggregation routers listed in Table 130. The
show processes cpu command was used every 30 seconds for 2 hours. The other commands were used
every 5 minutes for 2 hours.
Table 129
show Commands Used on the Denver WAN Aggregation Routers
Command
Purpose
show clock
•
Verifies the current time.
show policy-map interface [interface name]
•
Verifies that data traffic in the Real-Time class
gets 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 shaped rate is dropped.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
show ip rtp header compression
•
Verifies that IP RTP header compression is
turned on and if there are any errors.
The show commands listed in Table 129 were used on the Denver WAN aggregation routers and
interfaces listed in Table 130.
Table 130
Denver WAN Aggregation Routers and Interfaces
Router
Interface
egden-7206-w2
Hssi3/0
egden-7206-w3
Serial3/0:0, Virtual-Template 20, Virtual-Template 21
egden-7507-w4
Serial5/0/0:0, Serial5/0/1:1
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
143
Test Suite 4: Denver Campus
Step 3
Use DART to capture the output of the Cisco IOS show commands listed in Table 131 and analyze the
output of those commands. Use the commands on the core layer switches listed in Table 132. The show
processes cpu command was used every 30 seconds for 2 hours. The other commands were used every
5 minutes for 2 hours.
Table 131
show Commands Used on the Denver Core Layer Switches
Command
Purpose
show clock
•
Verifies the current time.
show policy-map interface [interface name]
•
Verifies that data traffic in the Real-Time class
gets 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 shaped rate is dropped.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
The show commands listed in Table 131 were used on the Denver core layer switches and interfaces
listed in Table 132.
Table 132
Step 4
Denver Core Layer Switches and Interfaces
Switch
Interface
egden 6506-c1
Gi3/1, Gi3/3, and Gi3/5
egden 6506-c2
Gi3/1, Gi3/3, and Gi3/5
Use DART to capture the output of the Cisco IOS show commands listed in Table 133 and analyze the
output of those commands. Use the commands on the distribution layer switches listed in Table 134. The
show processes cpu command was used every 30 seconds for 2 hours. The other commands were used
every 5 minutes for 2 hours.
Table 133
show Commands Used on the Denver Distribution Layer Switches
Command
Purpose
show clock
•
Verifies the current time.
show policy-map interface [interface name]
•
Verifies that data traffic in the Real-Time class
gets 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 shaped rate is dropped.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
144
Test Suite 4: Denver Campus
The show commands listed in Table 133 were used on the Denver distribution layer switches and
interfaces listed in Table 134.
Table 134
Step 5
Denver Distribution Layer Switches and Interfaces
Switch
Interface
egden 6506-d1
Gi3/5, Gi3/7, Gi3/9, and Gi3/11
egden 6506-d2
Gi3/5, Gi3/7, Gi3/9, and Gi3/11
Use DART to capture the output of the Cisco IOS show commands listed in Table 135 and analyze the
output of those commands. Use the commands on the access layer switches listed in Table 136. The
commands were used every 5 minutes for 2 hours.
Table 135
show Commands Used on the Denver Access Layer Switches
Command
Purpose
show clock
•
show interfaces [interface type]
Verifies the current time.
On all outbound WAN interfaces:
•
Verifies the link speed and drop rate.
The show commands listed in Table 135 were used on the Denver access layer switches and interfaces
listed in Table 136.
Table 136
Step 6
Denver Access Layer Switches and Interfaces
Switch
Interface
egden-6506-a1
Fa4/16, Fa4/14
egden-4003-a2
Fa3/16, Fa3/14
egden 4506-a3
Fa3/14, Fa3/16
Use DART to capture the output of the Cisco IOS show commands listed in Table 137. Use the
commands on the routers and switches listed in Table 130, Table 132, Table 134, and Table 136, and
issue the commands once at the end of the 2-hour test.
Table 137
show Commands Used for the Denver QoS Verification Test
Command
Purpose
show class-map
•
Verifies that the class map configured for the
device is displayed.
show policy-map
•
Verifies that the policy map configured for the
device is displayed.
show access-lists
•
Verifies that the configured access lists have the
correct amount of matching packets.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
145
Test Suite 4: Denver Campus
Step 7
Capture the data statistics from the Chariot, IXIA, and Callgen testing tools after the 2-hour test is
completed.
Expected Results
We expect the following results:
•
CPU utilization was always less than 90 percent.
•
No system or feature errors (such as router or switch failures, reloads, or CPU hogs) occurred during
testing.
•
No significant errors occurred, such as memory allocation errors, memory access errors, memory
leaks, or unexpected interface toggles.
•
Routing tables correctly reflected all available supernets and subnets.
•
All client/server traffic traversed from source to destination through the expected route for the
duration of the test.
•
All other procedures executed.
Results
Table 138 shows the Denver QoS verification test results.
Table 138
Denver QoS Verification Test Results
Test
Results
Denver QoS verification
Passed
Denver System Test
This is the system test case for IP routing, SNMP, security, multicast, VoIP and QoS features for the
nEverest Enterprise Global project as it pertains to the Denver campus.
The overall objectives of this test case were as follows:
•
Verify that the IP routing, SNMP, security, multicast, VoIP, and QoS features could be incorporated
into the Denver campus.
•
Verify the successful operation of the Cisco IOS release.
•
Verify that the system behaved as expected.
This test case verified system performance for a number of QoS features, using EIGRP and BGP as the
routing protocols. The features that were configured for the Denver functionality test were carried over
to this test. The following additional features were configured in this test case:
•
BGP MIB feature
•
BGP 4
•
CBWFQ
•
PQ
•
MLPPP performance enhancements
•
Cisco-Enhanced-Mempool-MIB
•
Cisco-Process-MIB
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
146
Test Suite 4: Denver Campus
•
DES/3DES VPN Encryption AIM for 2600/3600
•
EIGRP
•
Enhanced IGRP stub routing
•
FRF.12 support on switched Frame Relay PVCs
•
H.323 gateway trunk and carrier based routing enhancements
•
H.323/H.320 gateway
•
IGMP snooping querier
•
IGMP Version 2
•
QoS—classification and WRED
•
QoS—policing and DSCP classification
•
QoS—packet marking
•
RFC1850 OSPFv2 MIB Support
•
RTP header compression
•
TACACS+
Test Plan
The procedure used to perform the Denver system test follows:
Step 1
Start the traffic streams for 100 percent of the traffic load as follows:
a.
Start the BCG (Callgen) to generate calls.
b.
Start Chariot to simulate NetMeeting, Telnet, Lotus, Oracle, FTP, and HTTP traffic.
c.
Start IP/TV, for multicast traffic.
d.
Start IXIA, for background traffic.
Step 2
Use DART to capture information from the routers for 4 hours.
Step 3
Analyze the output of the Cisco IOS show commands listed in Table 139 at the start and end of the
4-hour test.
Table 139
show Commands Used for the Denver System Test Start and End View
Command
Purpose
show vtp status
•
Verifies that the VTP feature is enabled.
show vlan brief
•
Verifies VLAN status and port assignments.
show memory summary
On all the WAN routers:
•
Verifies that there are no memory leaks or
errors.
show ip bgp summary
•
Verifies the BGP routes.
show ip eigrp neighbors detail
•
Verifies that the remote WAN routers are
EIGRP stub-enabled.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
147
Test Suite 4: Denver Campus
Table 139
show Commands Used for the Denver System Test Start and End View (continued)
Command
show ip eigrp interface
show interfaces
Step 4
Purpose
•
Verifies if the EIGRP adjacent neighbor count
is higher than the neighbor count. If so, the
neighbor list could be corrupted.
On all the WAN routers:
•
Verifies that there are no input or output errors
or queue drops.
•
Verifies the routers’ throughput.
show clock
•
Verifies that the clock is synchronized with the
NTP server.
show buffer failure
•
Verifies a buffer or memory failure.
show ip igmp interface
•
Verifies that IGMP v2 is communicated
among routers and hosts to dynamically
register or leave a multicast group on a LAN
segment.
show ip igmp groups
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
show mac-address-table multicast vlan vlan-id
•
Verifies that the correct multicast addresses
are present in the output.
show mls ip multicast
•
Verifies that multicast flows create MMLS
entries and that switching of the flow is
performed.
show tacacs
•
Verifies that you are logging in to the correct
TACACS+ server.
show accounting
•
Verifies user account on the router and
switches with privilege 15.
show gateway
•
Verifies that the voice gateway is connected to
gatekeeper egsj-3640-GK.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface that was configured by the
virtual template.
show frame-relay pvc dlci
•
Verifies the encapsulation type, min cir,
fragmentation information, and policies
applied to this PVC.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
Analyze the output of the Cisco IOS show commands listed in Table 140 at 60-minute intervals.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
148
Test Suite 4: Denver Campus
Table 140
show Commands Used for the Denver System Test 60-Minute View
Command
Purpose
show interface trunk
•
Verifies that the VLAN trunkings are formed
correctly.
show ip route summary
•
Verifies the current state of the routing table.
show memory summary
Step 5
On all the WAN routers:
•
Verifies that there are no memory leaks or
errors.
show ip eigrp neighbors
•
Verifies the remote WAN routers.
show policy interface
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy maps.
show ip rtp header compression
•
Verifies that IP RTP header compression is
enabled for the voice traffic and if there are
any errors.
show call-manager-fallback all
•
Verifies that the remote campus can still make
calls within the campus.
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip mroute summary
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
Analyze the output of the Cisco IOS show command listed in Table 141 at 10-minute intervals.
Table 141
show Command Used for the Denver System Test 10-Minute View
Command
Purpose
show processes cpu
On all the WAN routers:
•
Verifies the CPU utilization.
•
Verifies that CPU capacity is not being
monopolized by a single router.
Expected Results
We expect the following results:
•
CPU utilization was always less than 90 percent.
•
No system or feature errors (such as router or switch failures, reloads, or CPU hogs) occurred during
testing.
•
No significant errors occurred, such as memory allocation errors, memory access errors, memory
leaks, or unexpected interface toggles.
•
Routing tables correctly reflected all available supernets and subnets.
•
All client/server traffic traversed from source to destination through the expected route for the
duration of the test.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
149
Test Suite 4: Denver Campus
•
Routes converged correctly without major delay.
Results
Table 142 shows the Denver system test results.
Table 142
Denver System Test Results
Test
Results
Denver system
Passed
Denver Reliability Test
This section describes in detail the reliability test case as it pertains to the Denver campus, using EIGRP
as the interior routing protocol and BGP as the exterior routing protocol. Successful execution of the
system test case is a prerequisite for the execution of this test. The reliability test ran continuously for
150 hours, with IP routing, NMS, voice, multicast, security, and QoS features enabled.
The following additional features were configured in this test category:
•
BGP MIB feature
•
BGP 4
•
CBWFQ
•
PQ
•
MLPPP performance enhancements
•
Cisco-Enhanced-Mempool-MIB
•
Cisco-Process-MIB
•
DES/3DES VPN encryption AIM for 2600/3600
•
EIGRP
•
Enhanced IGRP stub routing
•
FRF.12 support on switched Frame Relay PVCs
•
H.323 gateway trunk and carrier-based routing enhancements
•
H.323/H.320 Gateway
•
IGMP snooping querier
•
IGMP Version 2
•
QoS—classification and WRED
•
QoS—policing and DSCP classification
•
QoS—packet marking
•
RFC1850 OSPFv2 MIB support
•
RTP header compression
•
TACACS+
The objective of this test case was to verify that the software (at 100 percent traffic load capacity on each
WAN link) performed reliably for the 150-hour test period.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
150
Test Suite 4: Denver Campus
Test Plan
The procedure used to perform the Denver reliability test follows:
Step 1
Start traffic streams for a 100 percent traffic load by performing the following steps:
a.
Start the BCG (Callgen) to generate calls.
b.
Start Chariot to simulate NetMeeting, Telnet, Lotus, Oracle, FTP, and HTTP traffic.
c.
Start IP/TV, for multicast traffic.
d.
Start IXIA, for background traffic.
Step 2
Use DART to capture information from the routers for 150 hours.
Step 3
Analyze the output of the Cisco IOS show commands listed in Table 143 at the start and end of the
150-hour test period.
Table 143
show Commands Used for the Denver Reliability Test Start and End View
Command
Purpose
show vtp status
•
Verifies that the VTP feature is enabled.
show vlan brief
•
Verifies VLAN status and port assignments.
show memory summary
On all the WAN routers:
•
Verifies that there are no memory leaks or
errors.
show ip bgp summary
•
Verifies the BGP routes.
show ip eigrp neighbors detail
•
Verifies that the remote WAN routers are
EIGRP stub-enabled.
show ip eigrp interface
•
Verifies if the EIGRP adjacent neighbor count
is higher than the neighbor count. If so, the
neighbor list could be corrupted.
show interfaces
On all the WAN routers:
•
Verifies that there are no input or output errors
or queue drops.
•
Verifies the routers’ throughput.
show clock
•
Verifies that the clock is synchronized with the
NTP server.
show buffer failure
•
Verifies a buffer or memory failure.
show ip igmp interface
•
Verifies that IGMP v2 is communicated
among routers and hosts to dynamically
register or leave a multicast group on a LAN
segment.
show ip igmp groups
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
show mac-address-table multicast vlan vlan-id
•
Verifies that the correct multicast addresses
are present in the output.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
151
Test Suite 4: Denver Campus
Step 4
Table 143
show Commands Used for the Denver Reliability Test Start and End View (continued)
Command
Purpose
show mls ip multicast
•
Verifies that multicast flows create MMLS
entries and that switching of the flow is
performed.
show tacacs
•
Verifies that you are logging in to the correct
TACACS+ server.
show accounting
•
Verifies user account on the router and
switches with privilege 15.
show gateway
•
Verifies that the voice gateway is connected to
gatekeeper egsj-3640-GK.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface that was configured by the
virtual template.
show frame-relay pvc dlci
•
Verifies the encapsulation type, min cir,
fragmentation information, and policies
applied to this PVC.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
Analyze the output of the Cisco IOS show commands listed in Table 144 at 24-hour intervals.
Table 144
show Commands Used for the Denver Reliability Test 24-Hour View
Command
Purpose
show interface trunk
•
Verifies that the VLAN trunkings are formed
correctly.
show ip route summary
•
Verifies the current state of the routing table.
show memory summary
On all the WAN routers:
•
Verifies that there are no memory leaks or
errors.
show ip eigrp neighbors
•
Verifies the remote WAN routers.
show policy interface
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy maps.
show ip rtp header compression
•
Verifies that IP RTP header compression is
enabled for the voice traffic and if there are
any errors.
show call-manager-fallback all
•
Verifies that the remote campus can still make
calls within the campus.
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip mroute summary
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
152
Test Suite 4: Denver Campus
Step 5
Analyze the output of the Cisco IOS show command listed in Table 145 at 6-hour intervals.
Table 145
show Command Used for the Denver Reliability Test 6-Hour View
Command
Purpose
show processes cpu
On all the WAN routers:
•
Verifies the CPU utilization.
•
Verifies that CPU capacity is not being
monopolized by a single router.
Expected Results
We expect the following results:
•
CPU utilization was always less than 90 percent.
•
No system or feature errors (such as router or switch failures, reloads, or CPU hogs) occurred during
testing.
•
No significant errors occurred, such as memory allocation errors, memory access errors, memory
leaks, or unexpected interface toggles.
•
Routing tables correctly reflected all available supernets and subnets.
•
All client/server traffic traversed from source to destination through the expected route for the
duration of the test.
•
Routes converged correctly without major delay.
Results
Table 146 shows the Denver reliability test results.
Table 146
Denver Reliability Test Results
Test
Results
Denver reliability
Passed with exceptions
Passed with Exceptions Explanation
The Denver reliability test passed with exceptions for the following reasons:
•
Because of an automated job scheduling conflict with a data collection tool, 14 hours of test data
was not collected. The test results were not affected.
•
The IXIA traffic generator was turned off to allow problem-characterization work on Chariot and
was not turned on until several hours after the start of the test. There were no problems in the
network and the test results were not affected.
•
An H.323 VoIP traffic generator failed to start, resulting in a 2-hours delay of the start of VoIP traffic
between the Denver campus and the remote campuses. The test results were not affected.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
153
Test Suite 5: Dallas Campus
Test Suite 5: Dallas Campus
This test suite consisted of three test cases intended to verify the functionality, reliability, and
performance of basic IP QoS at the Dallas campus.
The Dallas campus is one component of the larger global enterprise topology. The global enterprise
topology comprises five multilayer-design campuses—two large campuses with data centers and three
regional campuses—and 12 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 Dallas campus, the following categories (or types) of testing were conducted:
•
Functionality testing: This test case verified basic IP functionality. This test also involved Layer 3
protocols (OSPF as the interior routing protocol and BGP as the exterior routing protocol), network
management, multicast, security, voice, and QoS.
•
System testing: This test category verified system performance, using IP routing, NMS, voice,
multicast, security, and QoS
•
Reliability testing: This test category verified system reliability.
This test suite contains the following sections:
•
Topology Description, page 154
•
Dallas Functionality Test, page 157
•
Dallas System Test, page 177
•
Dallas Reliability Test, page 181
Topology Description
The IOS Enterprise Global Dallas testbed represents one of the medium-size enterprise campuses that
would be located in a European region. The WAN routers connecting to the other enterprise global sites
and to the Internet consist of three Cisco 7206VXR NPE400 routers and a Cisco 7507 RSP8 router
running ATM and PPP on the WANs. The campus also consists of a GE and FE LAN connected to two
Catalyst 6506s, each with an MSFC2/PFC2. A Cisco 3640 router is used as a VoIP voice gateway and
registers into the gatekeeper located at the San Jose headquarters, which places real VoIP calls to other
gateways located at different campuses.
The testbed is used to perform the test for functionality, which includes IP routing, network
management, multicast, security, voice, and QoS. OSPF is the IP IGP routing protocol and route
generators inject a total of 320 simulated subnets 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, and HTTP are simulated by Chariot and other traffic generating test tools. The testbed
simulates large amount of end users through the use of traffic generators and real UNIX or Linux
workstations.
The Dallas enterprise campus networks are under one OSPF process with multiple OSPF areas,
including area 0.
Figure 12 shows the Dallas campus topology with IP addresses.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
154
Test Suite 5: Dallas Campus
Figure 12
Dallas Campus Topology with IP Addresses
96.1.0.17/30
ATM
Provider
Enterprise WAN
egboc1760-w1
.18
11
135
110
boc-ux1
T1
221.5.23.100
98
egaus2621-w1 8
96.1.0.41/30
Washington, D.C.
E3
WAN access
109
37
101 egdal7206-w1
1
97
3xE1
E3
egdal-3640-v
.42
38
2
egdal7206-w2
9
5
65
.58
42
102
41
5
105
egdal-7507-w4
13
4
17
21
109
45
3
113
25
egaus3550-a
9
96.1.0.57/30
ISP 3
San Jose
29
dal-ux13
106
104
105
46 101
103
10
egdal7206-w3
9
egarl3640-w1
110
134
egdal3660-w5
102
221.5.27.100
arl-ux1
133
221.5.28.100
aus-ux1
221.5.22.100
10
66
dal-ux4
6
106
221.5.10.100
egdal-6506c1-msfc2
33
dal-ux11
221.5.29.100
Miami
22
26
egdal-6506c1-sup2
221.5.9.100
dal-ux1
18
14
6
30
egdal-6506-c2
34
7
107
dal-ux12
221.5.30.100
dal-ux5
221.5.17.100
dal-ux6
FE
GE
ATM/FR (nx64k)
E1(P2P)
E3(P2P)
ATM E3
ATM T3
X 223.255.10.X
X 221.5.1.X - Loopback
95527
Layer 3 core
221.5.21.100
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
155
Test Suite 5: Dallas Campus
Figure 13 shows the Dallas campus topology with interface types.
Dallas Campus Topology with Interface Types
Enterprise WAN
egboc1760-w1
a4/0
11
fa0/0
135
s0/0
boc-ux1
egaus3550-a
isp 3-7507
Washington, D.C.
E3
WAN access
s6/2
f0/0
101
egdal7206-w1
1
s6/3
T1
f1/0
s0/0
egaus2621-w1 8
ISP 3
San Jose
ATM
Provider
g0/1
9 110
g0/2
g3/2
f0/0
102
dal-ux13
arl-ux1
f4/2
g3/1
g3/1
Layer 3 core
egdal-6506c1-msfc2
g1/1
dal-ux4 f4/13
6
f4/14
106
egdal-6506c1-sup2
f4/1
f4/2
egdal-6506-c2
f4/13
g1/1
7 107
f4/14
f4/15
dal-ux1
s6/0-2
5
105
f1/0
egdal-7507-w4
f0/0
f5/1/0 f0/1
10
134
g/1/0/0
4
104
g2/0
s0/1/1:0
egdalf5/0/0
3660-w5
g4/1/0
s1/0
3
103
f1/1
f1/0
9
133
f2/0 egdal7206-w3
egarl3640-w1
g3/2
109
f4/1
egdal-3640-v
s3/0
f0/0
2
egdal7206-w2
f4/0
g2/0
aus-ux1
3xE1
E3
dal-ux5
f4/17
dal-ux11
dal-ux12
dal-ux6
FE
GE
ATM/FR (nx64k)
E1(P2P)
E3(P2P)
ATM E3
ATM T3
X 223.255.10.X
X 221.5.1.X - Loopback
Platform and Software Version Information
Table 147 lists the platforms, router names, software versions, and software images configured in the
Dallas network topology for this test suite.
Table 147
Dallas Platform, Router Name, Software Version, and Software Image
Platform
Router Name
Software Version
Software Image
Cisco 7206
egdal-7206-w1
12.2(16b)
c7200-jk9s-mz.122-16b
Cisco 7206
egdal-7206-w2
12.2(16b)
c7200-jk9s-mz.122-16b
Cisco 7206
egdal-7206-w3
12.2(16b)
c7200-jk9s-mz.122-16b
Cisco 7507
egdal-7507-w4
12.2(15)T5
rsp-jsv-mz.122-15.T5
Cisco 3640
egdal-3640-v
12.2(16b)
c3640-a3js-mz.122-16b
Cisco 3660
egdal-3660-w5
12.2(16b)
c3660-jk9s-mz.122-16b
Catalyst 6500
egdal-6506-c1
7.6(1)
cat6000-sup2k8.7-6-1
Catalyst 6500
egdal-6506-c2
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Cisco 2621
egaus-2621-w1
12.2(16b)
c2600-jk9s-mz.122-16b
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
156
95528
Figure 13
Test Suite 5: Dallas Campus
Table 147
Dallas Platform, Router Name, Software Version, and Software Image (continued)
Platform
Router Name
Software Version
Software Image
Catalyst 3550
egaus-3550-a
12.1(13)EA1c
c3550-i5q3l2-mz.121-13.EA1c
Cisco 3640
egarl-3640-w1
12.2(16b)
c3640-jk9s-mz.122-16b
Cisco 1760
egboc-1760-w1
12.2(15)T5
c1700-k9o3sv8y7-mz.122-15.T5
Dallas Functionality Test
This is the functionality test case for the Cisco IOS nEverest Enterprise Global project as it pertains to
the Dallas campus. The test involves basic IP testing (Layer 3 protocols, such as HSRP, OSPF for the
interior routing protocol, and BGP for the exterior routing protocol.), network management testing,
multicast testing, security testing, voice testing and QoS testing. The functionality test case verified
basic IP functionality. The tests are described in the following sections:
•
Basic IP
•
Network Management
•
Multicast
•
Security
•
Voice
•
QoS
The testing in each section was performed sequentially and as independently as possible. The Dallas
functionality testing was conducted as follows:
1.
Basic IP testing was performed in conjunction with Network Management Testing (NMS). Network
Management was utilized to collect the test information.
2.
After completion of the basic IP test, IP configurations were made stable, and any traffic loading
was terminated in preparation for the next test.
3.
Multicast testing was performed, again with NMS monitoring.
4.
After completion of the multicast test, IP configurations were made stable, and any traffic loading
was terminated in preparation for the next test.
5.
Security testing was performed in conjunction with NMS monitoring.
6.
After completion of the security test, IP configurations were made stable, and any traffic loading
was terminated in preparation for the next test.
7.
Voice testing was performed in conjunction with NMS monitoring.
8.
After completion of the voice test, IP configurations were made stable, and any traffic loading was
terminated in preparation for the next test.
9.
QoS testing was performed in conjunction with NMS monitoring.
10. After completion of the QoS test, IP configurations were made stable, and any traffic loading was
terminated in preparation for the next test.
Basic IP
The objectives for this test case were as follows:
•
Verify the basic network operation (that is, network connectivity).
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
157
Test Suite 5: Dallas Campus
•
Verify that the selected Cisco IOS software versions can be successfully loaded into the devices.
•
Verify that the routing protocol features can be incorporated into the Dallas campus.
•
Verify that the major IP routing features work as expected.
OSPF with BGP Routing
This test involved testing OSPF with BGP routing. The following features were included in the test plan:
•
Route summarization
•
Route filtering
•
OSPF stub areas
•
Route redistribution and default route generation
•
Log event or change
•
BGP policy control: AS prepend and route filtering
Test Plan
This test verified route summarization, route filtering, OSPF stub router functionality, route
redistribution and default route generation, log event or change functionality, BGP policy control, and
other routing features. There are several parts to this test plan, described in the sections that follow.
Route Summarization and Filtering Test
OSPF will have area range and summary-address commands to be applied in the Dallas campus. The
area range commands will summarize all interarea routes and the summary-address commands will
summarize as many external routes as possible.
The procedure used to set up route summarization and filtering follows:
Step 1
On campus WAN and aggregration routers egdal-7206-w2, egdal-7206-w3, and egdal-7507-w4
summarize the area range.
Step 2
On campus WAN routers egdal-7206-w1 and egdal-7206-w2, summarize the summary address.
Step 3
On routers egdal-7206-w1 and egdal-7206-w2, use the no auto-summary command to enforce subnet
information to be propagated, unless manual summarization is applied.
Configure OSPF stub routing by performing the following steps:
a.
Configure a totally stubby area on the egdal-7206-w1 links to the IPSec Austin (egaus-2651-w1)
remote campus.
b.
Configure the voice gateway router egdal-3640-v as the stub area, which is connected to
egdal-7206-w2.
egdal-7206-w3 and egdal-7507-w4 have a virtual link to egdal-6506-c1-msfc2 and egdal-6506-c2 to
allow the totally stubby area to be cascaded off area 3 and area 4.
c.
Configure area 1 as the transit links for egdal-7206-w3 and egdal-7507-w4 to access core routers
egdal-6506-c1-msfc2 and egdal-6506-c2 by virtual-links.
d.
Configure a totally stubby area on egarl-3640-w1, egboc-1760-w1, and egaus-2621-w1.
Route Redistribution and Default Route Generation Test
The procedure used to set up for the route redistribution and default route generation test follows:
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
158
Test Suite 5: Dallas Campus
Step 1
Configure eBGP and iBGP WAN routers egdal-7206-w1 and egdal-7206-w2.
Default routes will be advertised by the WAN routers forming eBGP neighbors with the ISP routers.
These default routes will point to the null0 interface.
The BGP routers will inject a default route into their respective IGP. The default route will not be
advertised by BGP.
When advertising the default route into OSPF, configure the default route as metric-type 1 to include
internal cost to those AS border routers. This is to send traffic destined to the Internet as close as
possible. This default route will be advertised into the whole OSPF 1 and will be permitted into the
remote sites.
Alternative metrics, based on the number of ASs listed in the BGP path, will be applied to intercampus
routes being redistributed from BGP into OSPF.
Untagged OSPF routes will be redistributed into BGP. Intercampus routes will be tagged and
redistributed into OSPF.
Step 2
Configure "log-adjacency-changes" under "router ospf 1" on all the WAN routers, 7206VXRs, 7507s and
Layer 3 switches.
Step 3
Configure "bgp log-neighbor-changes" under "router bgp 64505" on egdal-7206-w1 and egdal-7206-w2.
BGP Policy Control Test
The procedure used to set up for the BGP policy control test follows:
Step 1
The BGP AS 64504 is the AS used for the Dallas campus AS border routers. All BGP routes are accepted
on the BGP routers.
Step 2
Configure egdal-7206-w2 for route filtering. This default route is redistributed into OSPF for the
connection to the ISP.
Step 3
Configure the egdal-7206-w2 BGP policy so that the traffic from the ISP destined for the local campus
prefixes gets high priority (by using AS prepending) to the advertised prefixes of the nonlocal campuses.
All intercampus routes will be advertised to the ISP, but the AS will be prepended three times.
Other Routing Features Test
The procedure used to set up the other routing features test follows:
Step 1
Apply route dampening to the BGP routers egdal-7206-w1 and egdal-7206-w2. Route dampening is used
to minimize the instability caused by route flapping and oscillation over the network.
Step 2
Configure authentication on egdal-7206-w1, egdal-7206-w2, egdal-7206-w3 and egdal-7507-w4. OSPF
authentication allows for the configuration of a password for a specific area. Routers that want to become
neighbors must exchange the same password on a particular segment.
Configure Local-Preference200 on egdal-7206-w1 and egdal-7206-w2. A path with a higher local
preference number is preferred. The default value for local preference is 100.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
159
Test Suite 5: Dallas Campus
Verification Test
The procedure used to set up the verification test follows:
Step 1
Use the show commands listed in the following steps and use DART to capture the information from the
routers.
Step 2
Analyze the output of the Cisco IOS show commands listed in Table 148.
Table 148
show Commands Used in the Dallas Core and WAN Routers
Command
Purpose
show ip route
On the core and WAN routers:
and
•
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 summary
Step 3
Fail the WAN connection s3/0 on the egdal-7206-w2 to Washington and use the show commands in
Table 148 to verify that the traffic is rerouted via an expected alternate path through the other campuses
and remote sites.
Step 4
Use the commands listed in Table 149 to verify that the egdal-7206-w1 and egdal-7206-w2 routers are
configured and functioning correctly.
Table 149
Commands Used in the Dallas WAN Routers
Command
Purpose
show ip bgp
On the WAN routers:
and
•
Verifies BGP route filtering.
show ip route
•
Verifies network reachability to ISP3.
and
•
Verifies BGP AS prepending policy control.
ping
Step 5
Use the show ip ospf neighbors command on all the routers to verify OSPF neighbors.
Step 6
Use the show ip ospf neighbors command on the egdal-7206-w1 and egdal-7206-w2 routers to verify
BGP neighbors
Step 7
Use the show memory summary command and the show processes cpu command on the core and WAN
routers every 30 seconds to verify CPU utilization and that CPU capacity is not being monopolized by
a single router.
Step 8
Use the show memory summary command and the show processes cpu command on all the routers
every 5 minutes to verify that there are no memory leaks or other memory errors.
Step 9
Use the show logging command to verify that there are no other significant errors.
Step 10
Use the show interfaces command on all the WAN routers to verify if there are any input errors, output
errors, or queue drops, and to verify the routers’ throughput.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
160
Test Suite 5: Dallas Campus
Expected Results
We expect the following results:
•
The routes are summarized correctly.
•
The route filters function correctly.
•
CPU utilization is less than 90 percent.
•
Memory consumption is stable.
•
The distribution layer routers are OSPF stub-enabled.
•
The default route is generated correctly.
•
The BGP AS prepending policy control is enabled on the ISP routers.
•
There are no significant OSPF or BGP routing errors and the link delay and bandwidth have been
tuned correctly.
•
BGP route filtering functions correctly.
•
The routing table displays the appropriate routes.
Results
Table 150 shows the Dallas OSPF with BGP routing test results.
Table 150
Dallas OSPF with BGP Routing Test Results
Test
Results
Dallas OSPF with BGP routing
Passed
Network Management
This section describes the network management testing in the Dallas campus. The following features
were included in the test plan:
•
MIB Walk automation script (snmp_walk_test) and Traps
•
Syslog and NTP
The objectives of the SNMP MIB testing were as follows:
•
Ensure that the information stored in the MIB database can be accessed, propagated, read, and
written if applicable.
•
Ensure that the operation of the OID values reflects the actual operation on the device.
•
Ensure that there were no SNMP traps.
Test Plan
The procedure used to perform the network management test follows:
Step 1
Configure MIB walk and traps.
The MIB walk automation script (snmp_walk_test) will test the OID and traps by platforms and
technologies, report their value, and monitor the UUT behavior. HP OpenView and CiscoWorks2000 are
used as the SNMP receivers.
Step 2
Configure all the routers and switches so that the snmp_walk_test script will work properly.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
161
Test Suite 5: Dallas Campus
Step 3
Upload the following MIBs to the snmp_walk_test script:
•
Basic IP:
– CISCO-BGP4-MIB
– CISCO-OSPF-MIB
•
Multicast:
– CISCO-IGMP-MIB.my
– CISCO-MSDP-MIB.my
– CISCO-PIM-MIB.my
•
Voice:
– CISCO-VOICE-DIAL-CONTROL-MIB
•
QoS:
– CISCO-QOS-MIB
•
Security:
– CISCO-IPSEC-FLOW-MONITOR-MIB
Step 4
Set up the eg-cw2k (CiscoWorks2000) server in the San Jose campus as the UNIX NTP and syslog
server.
Step 5
Use DART to capture show command output from the routers.
Step 6
Use the show processes cpu command to verify the CPU utilization and to verify that the CPU capacity
is not being monopolized by a single router.
Step 7
Use the show memory summary command to verify that there are no memory leaks or errors.
Step 8
On server eg-cw2k, verify that syslogd is still running.
Step 9
Use the Cisco IOS show clock command and the CatOS show time command to verify that the clock is
synchronized with the NTP server.
Step 10
Verify that the Pat scripts are able to send e-mail notification for error conditions on the routers or
switches.
Step 11
Use the show crypto mib ipsec flowmib version command to verify that the device has IPsec MIB
support.
Step 12
Use the show log command or the show align command to verify that there are no other significant
errors.
Expected Results
We expect the following results:
•
Information stored in the MIB can be accessed, propagated, read, and written.
•
Operation of the OID values reflect the actual operation of the device.
Results
Table 151 shows the Dallas network management test results.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
162
Test Suite 5: Dallas Campus
Table 151
Dallas Network Management Test Results
Test
Results
Dallas network management
Passed
Multicast
The objective of the Dallas campus multicast testing was to verify the functionality of multicast features
across multiple Cisco platforms with various sets of Cisco IOS and CatOS releases.
The following features were included in the test plan:
•
MDS
•
PIM sparse-dense mode
•
Admin scoping and multicast boundary
•
IGMP snooping
•
MMLS
The test was set up to use Cisco IP/TV as a one-to-many video and audio streaming application by
configuring an IP/TV server at the San Jose campus data center to stream six multicast groups. There
were three video and three audio groups.
Test Plan
Setup
The procedure used to set up the multicast test follows:
Step 1
Configure Cisco IP/TV by performing the following steps:
a.
Connect the IP/TV server to switch egsj-6505-sa3.
b.
Connect the IP/TV client to switch egdal-6506-c2.
c.
Configure the IP/TV server to stream two programs as follows:
•
The program “G1” contains a 239.192.1.0/24 multicast address scope and consists of a
600-kbps video and audio stream.
•
The program “G2” contains a 239.192.2.0/24 multicast address scope and consists of a
300-kbps video and audio stream.
•
The program TBD3 contains a 239.194.0.1/14 multicast address scope and consists of a
1500-kbps video stream and a 100-kbps audio stream. Only the IP/TV client at the San Jose
campus will receive this program.
Step 2
Enable MDS on Dallas router egdal-7507-w4.
Step 3
Enable PIM sparse-dense mode on all Layer 3 Native IOS and Cisco IOS multicast devices.
Step 4
Enable multicast admin scoping and multicast boundary on the Dallas campus—egdal-7507-w4
Verification
The procedure used to perform the multicast verification test follows:
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
163
Test Suite 5: Dallas Campus
Step 1
Use DART to capture the output of the generic show commands listed in Table 152.
Table 152
Generic show Commands Used in the Dallas Multicast Verification Test
Command
Purpose
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 or other
memory errors.
show buffer failure
•
Verifies a buffer or memory failure.
show interfaces [interface type]
•
Verifies that there are no input errors, output
errors, or queue drops.
•
Verifies the router's throughput.
•
Verifies that there are no other significant errors.
show logging
Step 2
Using the show commands listed in Table 153, verify that IGMPv2 is communicated among routers and
switches to dynamically register or leave a multicast group on a LAN segment. In addition, verify the
following:
•
The router with the lower IP address is the correct IGMP querier.
•
The router installs group members upon receipt of IGMP join messages.
•
All groups are seen for all IGMP joined groups.
•
The router sends PIM join messages as a consequence of receiving IGMP join messages and creates
the corresponding (*,G) entries.
Table 153
show Commands Used in the Dallas Multicast IGMPv2 Verification Test
Command
Step 3
Purpose
show ip igmp interface
•
Verifies that IGMP v2 is communicated among
routers and hosts to dynamically register or
leave a multicast group on a LAN segment.
show ip igmp groups
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
Using the show commands listed in Table 154, verify that MDS functions as follows:
•
The VIP interfaces on Cisco 7500 routers are MDS-enabled.
•
Multicast distributed switching is enabled.
•
Multicast traffic is distributed-switched.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
164
Test Suite 5: Dallas Campus
Table 154
show Commands Used in the Dallas Multicast MDS Verification Test
Command
Step 4
Purpose
show ip mds interface
•
Verifies the status of MDS interfaces.
show ip pim interface detail
•
Displays detailed information about each
interface configured for Protocol Independent
Multicast (PIM).
show ip mds forwarding
•
Verifies the MFIB table and forwarding
information for MDS.
show ip mds summary
•
Displays a summary of the MFIB table for
MDS.
Using the show commands listed in Table 155, verify that PIM sparse-dense mode functions as follows:
•
Multicast forwarding is achieved using PIM. PIM interacts with the IP unicast forwarding table to
determine the correct path to the source of the multicast packets (RPF), and interacts with IGMP to
recognize networks that have members of the multicast group.
•
All expected PIM neighbors are present and no unknown routers appear.
•
The correct DR election is made on the LAN segment.
•
The correct IIF and OIF lists, RPF, and flags are present in the (*,G) or (S,G) entries.
•
The correct RP mapping is shown for all groups.
Table 155
show Commands Used in the Dallas Multicast PIM Sparse-Dense Mode Verification Test
Command
Step 5
Purpose
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
show ip pim rp mapping
•
Verifies all the group-to-RP mappings of which
the router is aware (either configured or learned
from Auto-RP).
show ip pim rp
•
Verifies that the active rendezvous points (RPs)
are cached with the associated multicast routing
entries.
show ip mroute
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
show ip mroute count
•
Displays statistics about the group and source,
including number of packets, packets per
second, average packet size, and bytes per
second.
Using the show commands listed in Table 156, verify that admin scoping and multicast boundary
functions as follows:
•
RP messages are prevented from traveling beyond the boundaries of the network using multicast
boundaries.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
165
Test Suite 5: Dallas Campus
•
Routers within the TTL number of hops from the source RP mapping agent receive the Auto-RP
discovery messages.
•
Routers learn about correct RP mapping information within the TTL range.
•
Routers out of the TTL range cannot receive the Auto-RP Discovery messages.
•
A border router with a multicast boundary configured will not leak RP messages out of the network.
•
Multicast traffic cannot be forwarded out of the defined admin scope.
Table 156
show Commands Used in the Dallas Admin Scoping and Multicast Boundary Verification
Test
Command
Step 6
Purpose
show ip pim rp mapping
•
Verifies all the group-to-RP mappings of which
the router is aware (either configured or learned
from Auto-RP).
show ip pim rp
•
Verifies that the active rendezvous points (RPs)
are cached with the associated multicast routing
entries.
show ip mroute count
•
Displays statistics about the group and source,
including number of packets, packets per
second, average packet size, and bytes per
second.
show ip mroute
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
Using the show commands listed in Table 157, verify that IGMP snooping functions as follows:
•
IGMP snooping manages multicast traffic at Layer 2 by configuring the Layer 2 LAN port
dynamically to forward multicast traffic to only those ports that want to receive it.
•
IGMP snooping constrains multicast traffic that exits through LAN ports to which hosts are
connected.
Table 157
show Commands Used in the Dallas Multicast IGMP Snooping Verification Test
Command
Step 7
Purpose
show ip igmp interface
•
Verifies that IGMP snooping is globally
enabled.
show ip igmp snooping mrouter
•
Verifies that the correct multicast router has
been learned.
show mac-address-table multicast vlan-id
•
Verifies that the correct multicast addresses are
present in the output.
Using the show commands listed in Table 158, verify that MMLS functions as follows:
•
Multicast flows create MMLS entries and switching of the flow is performed using hardware
shortcuts. In the Catalyst 6500s, the flows are taking the correct paths.
•
The flows are using the expected multicast forwarding entry (*,G) or (S,G).
•
Hardware-based flows are created where expected.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
166
Test Suite 5: Dallas Campus
•
Identify the lowest rate of the traffic flow at which a hardware shortcut is created.
•
CPU utilization does not increase. If it does, then there is a possibility that flows are being software
switched.
•
On DFC cards, forwarding tables on line cards are the same as on the processor card.
Table 158
show Commands Used in the Dallas Multicast MMLS Verification Test
Command
Purpose
show mls ip multicast
•
Verifies that the flows are using the expected
multicast forwarding entry (*,G) or (S,G).
show mls ip multicast summary
•
Verifies that hardware-based flows are created
where expected.
show processes cpu
•
Verifies the CPU utilization.
•
Verifies that CPU capacity is not being
monopolized by a single router.
Expected Results
We expect the following results:
•
IGMP snooping manages multicast traffic at Layer 2 by configuring Layer 2 LAN ports dynamically
to forward multicast traffic to only those ports that want to receive it.
•
IGMP snooping constrains multicast traffic that exits through LAN ports to which hosts are
connected.
•
Multicast flows create MMLS entries and switching of the flow is performed using hardware
shortcuts in the Catalyst 6500.
•
Multicast forwarding is achieved using PIM.
•
RP messages are prevented from traveling beyond the boundaries of the network by using multicast
boundaries.
•
The rate that a sender from the source list can send to a multicast group in the group list is
appropriate.
Results
Table 159 shows the Dallas multicast test results.
Table 159
Dallas Multicast Test Results
Test
Results
Dallas multicast
Passed
Security
This security test was conducted for the Dallas campus. This test case verified the functionality of AAA,
and SNMP features commonly used by enterprise customers that integrate across multiple Cisco
platforms and Cisco IOS releases at the system level.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
167
Test Suite 5: Dallas Campus
The objectives of the security test were as follows:
•
Verify that the IPSec GRE tunnel is established between the campus and the remote WAN edge
routers. Authentication was done with IKE preshared keys.
•
Verify the ability of the campus and remote WAN edge routers to request and complete the
certificate authentication process with the CA server in the data center and establish an IPSec tunnel
between them.
•
Verify the interaction of encrypted data streams with unencrypted voice streams between the campus
and the remote WAN edge routers. Observe the ability of the router to do voice and IPSec.
•
Verify TACACS+ AAA services, at a system level for all access, distribution, core, and WAN edge
devices in the global topology.
The following features were configured for the security test:
•
IPSec IKE preshared keys GRE tunnel
•
IPSec IKE CA
•
IPSec IKE Pre-shared transport or tunnel mode
•
AAA TACACS+
•
Security commands
Test Plan
Setup
The procedure used to set up the Dallas security test follows:
Step 1
Perform Step 2 through Step 6 to configure security features on the following devices:
•
egdal-7206-w1
•
egaus-2621-w1
•
egboc-1760-w1
Step 2
Configure IKE policy.
Step 3
Configure IPSec transforms and protocol.
Step 4
Create access lists for encryption.
Step 5
Apply the crypto maps on the serial interfaces.
Step 6
Configure GRE tunnels.
Step 7
Perform Step 8 through Step 14 to configure security features on the following devices:
•
egdal-3640-w5
•
egarl-3660-w1
Step 8
Configure a hostname and IP domain name.
Step 9
Enable query mode to store certificates on the CA server.
Step 10
Configure to generate an RSA key pair.
Step 11
Request the certificate.
Step 12
Create a crypto map entry in IPSec ISAKMP mode.
Step 13
Assign the crypto maps to the tunnel and physical interfaces.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
168
Test Suite 5: Dallas Campus
Step 14
Perform Step 15 through Step 19 to configure security features on the following devices:
•
egdal-7206-w3
•
eghou-3660-vw
Step 15
Configure IKE policy.
Step 16
Configure IPSec transforms and protocol.
Step 17
Configure tunnel mode.
Step 18
Create access lists for encryption.
Step 19
Apply the crypto maps on the serial interfaces.
Step 20
Perform Step 21 through Step 26 to configure security features on the following devices:
•
egdal-7206-w1
•
egdal-7206-w2
•
egdal-7206-w3
•
egdal-7206-w4
•
egdal-7206-w5
•
egdal-3660-v
•
egdal-6506-c1
•
egdal-6506-c2
Step 21
Configure encryption service facility and AAA and TACACS+.
Step 22
Configure the time-stamping service facility for logging.
Step 23
Disable all unnecessary services.
Step 24
Configure an enable password.
Step 25
Configure a console port password.
Step 26
Configure a vty password.
Verification
The procedure used to perform the Dallas security verification test follows:
Step 1
Use the show crypto isakmp policy command to verify that the policy number has the correct security
algorithm.
Step 2
Use the show crypto isakmp sa command to verify the IKE security association with the source and
destination.
Step 3
Use the show crypto engine connections active command to verify that each Phase 2 SA is built and
the correct amount of traffic sent.
Step 4
Use the show crypto map command to verify that the crypto map is configured properly on the tunnel
and the physical interface.
Step 5
Use the show crypto key mypubkey rsa command to verify the router RSA public keys.
Step 6
Use the show crypto ca certificates command to view information about the CA's certificate.
Step 7
Use the show crypto ipsec sa command to verify that the packets are encap/encrypt/decrypt.
Step 8
Use the show crypto isakmp sa command to verify that the ISAKMP Security Association (SA) is built
between peers.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
169
Test Suite 5: Dallas Campus
Step 9
Use the show tacacs command to verify the user is logging in to the TACACS+ server 223.255.10.30.
Step 10
Use the show accounting command to verify the user account on the router and switches with
privilege 15.
Expected Results
We expect the following results:
•
The IPSec GRE Tunnel is established between the campus and remote WAN edge routers.
•
The campus and remote WAN edge routers can request and complete the CA process with the CA
server in the data center and establish an IPSec tunnel between them.
•
Encrypted data streams can interact with unencrypted voice streams between the Dallas campus and
the Austin remote WAN edge routers. The router can do Voice and IPSec.
•
TACACS+ AAA services function properly at a system level for all access, distribution, core, and
WAN edge devices in the global topology.
Results
Table 160 shows the Dallas security test results.
Table 160
Dallas Security Test Results
Test
Results
Dallas security
Passed
Voice
The purpose of the voice test was to deploy and verify the VoIP deployment scenarios for large
Enterprise customers that want to minimize the operations cost of telephony by utilizing IP telephony
over traditional services. The overall objectives of the voice test case were as follows:
•
Verify that voice can be incorporated into the Dallas campus.
•
Verify the operation of the Cisco IOS release to test the AVVID and legacy voice interoperability.
•
Collect and document the test results.
•
Ensure that the system behaves as expected.
Voice Testing
The following feature was configured for voice testing:
•
Legacy H.323 VoIP
Test Plan
The voice test verified that voice traffic operated properly across the network. There are several parts to
this test plan, described in the sections that follow.
Set Up Legacy H.323
The procedure used to set up the legacy H.323 voice follows:
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
170
Test Suite 5: Dallas Campus
Step 1
Configure H.323 voice gateway egdal-3640-v.
Step 2
Check that egdal-3640-v is registered with gatekeeper egsj-3640-gk in the San Jose campus by using the
show gateway command on the egdal-3640-v router.
Step 3
Configure Callgen telephony.
Voice Traffic Verification Test
This test verified that incoming and outgoing voice traffic is handled properly on the network. In this
test, no QoS features are configured and the network was free from traffic congestion.
Test Plan
The procedure use to perform the voice traffic verification test follows:
Step 1
Start the bulk call traffic generators by performing the following steps:
a.
Start all BCG channels to San Jose (19 calls), Boston (3 calls), Dallas (6 calls), Miami (2 calls), and
New York (2 calls). Note: Refer to the dial plan and voice design document.
b.
Using the show channel command on the Callgens, verify for 5 minutes that all originate and
terminate BCG channels have started and are progressing correctly with no problems.
Step 2
Verify for 5 minutes that all originate and terminate Callgen SCCP channels have started and are
progressing correctly with no problems.
Step 3
Analyze the output of the show commands listed in Table 161. Use the listed commands on all the WAN
routers using the DART tool every 60 seconds for the show processes cpu command, and every
5 minutes for all the others—for a duration of 2 hours.
Table 161
show Commands Used for the Dallas Voice Traffic Verification Test
Command
show clock
show interfaces [interface type]
Purpose
•
Verifies the current time.
On all outbound WAN interfaces:
•
Verifies the link speed and drop rate.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
show ppp multilink [interface type] On egdal-7206-w2:
•
Verifies multilink PPP status, such as the number of member
interfaces configured per bundled interface.
The show commands listed in Table 161 were used on the WAN routers and interfaces listed in
Table 162.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
171
Test Suite 5: Dallas Campus
Table 162
Step 4
Step 5
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, ATM0/0/0
Stop the bulk call traffic generators and verify results by performing the following steps:
a.
Stop all BCGs after 1 hour of run time.
b.
Use the show channel command of the Callgen testing tool to verify that all originate and terminate
BCG channels are functioning correctly without any significant errors.
c.
Capture the output statistics of Callgen by using CIC.
d.
Use Performance monitor to check real time the number of gateways and IP Phones registered and
CDR on the CallManager to also check the percentage of successful calls.
Configure an IP phone manually, install it in each campus, and make calls to test voice quality.
Expected Results
We expect the following results:
•
Voice traffic sent efficiently and all voice channels originated and terminated properly.
•
All originate and terminate BCG channels work properly and without any significant errors.
Results
Table 163 shows the Dallas voice traffic verification test results.
Table 163
Dallas Voice Traffic Verification Test Results
Test
Results
Dallas voice traffic verification
Passed
QoS
The high-level objective of the QoS testing was to validate a robust QoS solution for protecting critical
application data, including real-time VoIP, on interarea WAN links, including classification and marking
as close to the network edge as possible, and remarking from L2 CoS to L3 ToS.
QoS Setup Test
The QoS setup test verified that QoS features were configured correctly and that the QoS features were
applied to traffic classes as anticipated. In this test, the MQC three-step model was used to configure the
traffic classes, class maps, and policy maps.
The following features were included in the test plan:
•
Classification and marking—DSCP
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
172
Test Suite 5: Dallas Campus
•
Congestion avoidance—dWRED (differentiated services-based WRED)
•
Congestion management—LLQ
•
Traffic conditioning—FRTS, ATM shaping
•
Link Efficiency Mechanisms—MLPPP LFI, cRTP
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 using the following guidelines:
•
Classify VoIP traffic into a class map called “Real-Time.”
•
Classify applications with small or infrequently sent packets, such as Telnet and voice signaling,
into a class map called “Interactive.”
•
Classify the mission-critical traffic or traffic that can consume large amounts of bandwidth, such as
Lotus Notes and Oracle, into a class map called “Transactional.”
•
Classify IP/TV multicast video conferencing and multicast signaling into the “Streaming” class.
•
Classify HTTP and FTP traffic into the “class-default” class, which is the class map for best-effort
service.
Associate the policy maps and actions with each class of traffic by performing the following steps:
a.
Configure a policy map called "OUT-LAN-XX" on the core layer switches egdal-6506-c1 and
edal-6506-c2. This configuration tests the LLQ feature of QoS.
b.
Configure a policy map called "OUT-WAN-XX" on the intercampus WAN aggregation routers. This
configuration tests the WRED feature of QoS.
c.
Configure a policy map called "OUT-WAN-XX" on campus-Remote WAN aggregation routers
egdal-7206-w3 and egdal-7206-w4. This configuration tests the MLPP LFI and FRTS features of
QoS.
Attach policy maps to the interfaces listed in Table 164, and apply the other appropriate QoS features.
Table 164 shows the router name, the policy map created, and the interface to which the policy map was
applied (attached).
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
173
Test Suite 5: Dallas Campus
Table 164
Routers, Policy Maps, and Interfaces for the Dallas QoS Setup Test
Router
Policy Map
Interface
egdal-7206-w1
OUT-LAN-FE
Fa0/0, Fa1/0, and F2/0
egdal-7206-w1
OUT-WAN-DT0
Serial6/2
egdal-7206-w1
OUT-WAN-DT8
Serial6/3
egdal-7206-w2
OUT-LAN-FE
Fa0/0, Fa1/0, Fa4/0, and F2/0
egdal-7206-w3
OUT-LAN-FE
F0/0, F1/0, F2/0
egdal-7206-w3
OUT-WAN-DT4
Serial6/0:0
egdal-7507-w4
OUT-LAN-GE
Gi4/1/0, and Gi1/0/0
egdal-7507-w4
OUT-LAN-FE
F5/0/0
egdal-7507-w4
OUT-WAN-FF2
Serial0/1/0:1.128
egdal-7507-w4
OUT-WAN-DT9
Serial0/1/1:0
egdal-6506-c2
OUT-LAN-GE
Gi3/2, Gi1/1
egdal-6506-c2
OUT-LAN-FE
F4/1, F4/37, F4/2
egdal-3640-V
OUT-VOICE
F0/0
egboc-1760-w1
OUT-LAN-FE
F0/0
egboc-1760-w1
OUT-WAN-DT0
Serial0/0
egaus-2621-w1
OUT-LAN-FE
F0/1
egaus-2621-w1
OUT-WAN-DT8
Serial0/0
egarl-3640-w1
OUT-LAN-FE
F1/1
egarl-3640-w1
OUT-LAN-DT9
Serial1/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 165 shows the Dallas QoS setup test results.
Table 165
Dallas QoS Setup Test Results
Test
Results
Dallas QoS setup
Passed
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
174
Test Suite 5: Dallas Campus
QoS Verification Test
This test verified that incoming and outgoing 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, data traffic was used, QoS features were configured, and the network was experiencing traffic
congestion.
Test Plan
The procedure used to perform the Dallas QoS verification test follows:
Step 1
Start the Chariot traffic testing tool to congest the network.
Step 2
Use DART to capture the output of the Cisco IOS show commands listed in Table 166. The show
processes cpu command was used every 30 seconds for 2 hours. The other commands were used every
5 minutes for 2 hours.
Table 166
show Commands Used on the Dallas WAN Routers
Command
Purpose
show clock
•
Verifies the current time.
show policy-map interface [interface name]
•
Verifies that data traffic in the Real-Time class
gets the percentage of bandwidth assigned in the
policy maps.
show interfaces [interface type]
On all outbound WAN 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 shaped rate is dropped.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
show ip rtp header compression
•
Verifies that IP RTP header compression is
turned on and if there are any errors.
The show commands listed in Table 166 were used on the Dallas WAN aggregation routers and
interfaces listed in Table 167.
Table 167
Step 3
Dallas WAN Aggregation 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
Use DART to capture the output of the Cisco IOS show commands listed in Table 168 on the Dallas core
layer switches. The show processes cpu command was used every 30 seconds for 2 hours. The other
commands were used every 5 minutes for 2 hours.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
175
Test Suite 5: Dallas Campus
Table 168
show Commands Used on the Dallas Core Layer Switches
Command
Purpose
show clock
•
Verifies the current time.
show policy-map interface [interface name]
•
Verifies that data traffic in the Real-Time class
gets the percentage of bandwidth assigned in the
policy maps.
show interfaces [interface type]
On all outbound WAN 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 shaped rate is dropped.
show memory summary
•
Verifies that there are no memory leaks.
show processes cpu
•
Verifies the CPU utilization.
show ip rtp header compression
•
Verifies that IP RTP header compression is
turned on and if there are any errors.
show class-map
•
Verifies that the class map configured for the
device is displayed.
show policy-map
•
Verifies that the policy map configured for the
device is displayed.
show access-lists verify
•
Verifies that the configured access lists have the
correct amount of matching packets.
The show commands listed in Table 168 were used on the Dallas core layer switches and interfaces listed
in Table 169.
Table 169
Step 4
Dallas Core Layer Switches and Interfaces
Router
Interface
egdal-6506-c1
Gi3/2, Gi3/1, Fa4/1, Fa4/2
egdal-6506-c2
Gi3/1, Gi3/2and Fa4/1, Fa4/2
Capture the data statistics from the Chariot, IXIA, and Callgen testing tools after the 2-hour test is
completed.
Expected Results
We expect the following results:
•
CPU utilization was always less than 90 percent.
•
No system or feature errors (such as router or switch crashes, reloads, or CPU hogs) occurred during
testing.
•
No significant errors occurred, such as memory allocation errors, memory access errors, memory
leaks, or unexpected interface toggles.
•
Routing tables correctly reflected all available supernets and subnets.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
176
Test Suite 5: Dallas Campus
•
All client/server traffic traversed from source to destination through the expected route for the
duration of the test.
•
Routes converged correctly without major delay.
•
All other procedures executed correctly.
Results
Table 170 shows the Dallas QoS verification test results.
Table 170
Dallas QoS Verification Test Results
Test
Results
Dallas QoS verification
Passed
Dallas System Test
This is the system test case for IP routing, SNMP, security, multicast, VoIP, and QoS features for the
nEverest Enterprise Global project as it pertains to the Dallas campus.
The overall objectives of this test case were as follows:
•
Verify that the IP routing, SNMP, security, multicast, VoIP, and QoS features could be incorporated
into the Dallas campus.
•
Verify the successful operation of the Cisco IOS release.
•
Verify that the system behaved as expected.
This test case verified system performance for a number of QoS features, using OSPF and BGP as the
routing protocols. The features that were configured for the Dallas functionality test were carried over
to this test. The following additional features were configured in this test case:
•
BGP MIB feature
•
BGP 4
•
CBWFQ
•
CGMP
•
Cisco IP phone support
•
Crypto key management interface
•
DES/3DES VPN encryption AIM for 1700
•
Encrypted pre-shared key
•
FRF.12 support on switched Frame Relay PVCs
•
GRE tunnel support
•
H.323 gateway trunk and carrier-based routing enhancements
•
H.323/H.320 gateway
•
IGMP snooping querier
•
IGMP Version 2
•
IKE extended authentication (Xauth)
•
IKE mode configuration
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
177
Test Suite 5: Dallas Campus
•
IKE security protocol
•
LFI for Frame Relay and ATM virtual circuits
•
MLPPP performance enhancements
•
MLPPP with LFI
•
MSDP
•
OSPF ABR type 3 LSA filtering
•
OSPF stub router advertisement
•
OSPF
•
PIM MIB extension for IP multicast
•
PIM Version 2
•
PQ
•
QoS—classification and WRED
•
QoS—packet marking
•
RFC1850 OSPFv2 MIB support
•
RTP header compression
•
TACACS+
Test Plan
The procedure used to perform the Dallas system test follows:
Step 1
Start the traffic streams for 100 percent of the traffic load as follows:
a.
Start the BCG (Callgen) to generate calls.
b.
Start Chariot to simulate NetMeeting, Telnet, Lotus, Oracle, FTP, and HTTP traffic.
c.
Start IP/TV, for multicast traffic.
d.
Start IXIA, for background traffic.
Step 2
Use DART to capture information from the routers for 4 hours.
Step 3
Analyze the output of the Cisco IOS show commands listed in Table 171 at the start and end of the
4-hour test.
Table 171
show Commands Used for the Dallas System Test Start and End View
Command
Purpose
show vtp status
•
Verifies that the VTP feature is enabled.
show vlan brief
•
Verifies VLAN status and port assignments.
show memory summary
On all the WAN routers:
•
Verifies that there are no memory leaks or
errors.
show ip bgp neighbors detail
•
Verifies the intracampus WAN routers.
show ip ospf neighbors detail
•
Verifies that the OSPF neighbor information
on a per-interface basis.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
178
Test Suite 5: Dallas Campus
Table 171
show Commands Used for the Dallas System Test Start and End View (continued)
Command
show ip ospf interface
show interfaces
Purpose
•
Verifies if the OSPF adjacent neighbor count
is higher than the neighbor count. If so, the
neighbor list could be corrupted.
•
Verifies the OSPF area and determines if
OSPF is enabled.
On all the WAN routers:
•
Verifies that there are no input or output errors
or queue drops.
•
Verifies the routers’ throughput.
show clock
•
Verifies that the clock is synchronized with the
NTP server.
show buffer failure
•
Verifies a buffer or memory failure.
show ip igmp interface
•
Verifies that IGMP v2 is communicated
among routers and hosts to dynamically
register or leave a multicast group on a LAN
segment.
show ip igmp groups
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
show mac-address-table multicast vlan vlan-id
•
Verifies that the correct multicast addresses
are present in the output.
show mls ip multicast
•
Verifies that multicast flows create MMLS
entries and that switching of the flow is
performed.
show crypto isakmp policy
•
Verifies that the IKE policy number has the
correct security algorithm.
show crypto map [interface x | tag map-name]
•
Verifies that the crypto map is configured
properly on the tunnel and the physical
interface.
show crypto key mypubkey rsa
•
Verifies the router's RSA public keys.
show tacacs
•
Verifies that you are logging in to the correct
TACACS+ server.
show accounting
•
Verifies user account on the router and
switches with privilege 15.
show gateway
•
Verifies that the voice gateway is connected to
gatekeeper egsj-3640-GK.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface that was configured by the
virtual template.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
179
Test Suite 5: Dallas Campus
Table 171
show Commands Used for the Dallas System Test Start and End View (continued)
Command
Step 4
Purpose
show frame-relay pvc dlci
•
Verifies the encapsulation type, min cir,
fragmentation information, and policies
applied to this PVC.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
Analyze the output of the Cisco IOS show commands listed in Table 172 at 60-minute intervals.
Table 172
show Commands Used for the Dallas System Test 60-Minute View
Command
show interface trunk
•
Verifies that the VLAN trunkings are formed
correctly.
show ip route summary
•
Verifies the current state of the routing table.
show memory summary
Step 5
Purpose
On all the WAN routers:
•
Verifies that there are no memory leaks or
errors.
show ip bgp neighbors
•
Verifies the Dallas intracampus WAN router
neighbors.
show ip ospf neighbors
•
Verifies the state of the OSPF neighbors.
show crypto isakmp sa
•
Verifies the IKE security association with the
source and destination.
show crypto engine connections active
•
Verifies that each Phase 2 SA was built and
the amount of traffic sent.
show crypto ipsec sa
•
Verifies that the packets are
encap/encrypt/decrypt.
show policy interface
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy maps.
show ip rtp header compression
•
Verifies that IP RTP header compression is
enabled for the voice traffic and if there are
any errors.
show call-manager-fallback all
•
Verifies that the remote campus can still make
calls within the campus.
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip mroute summary
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
Analyze the output of the Cisco IOS show command listed in Table 173 at 10-minute intervals.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
180
Test Suite 5: Dallas Campus
Table 173
show Command Used for the Dallas System Test 10-Minute View
Command
Purpose
show processes cpu
On all the WAN routers:
•
Verifies the CPU utilization.
•
Verifies that CPU capacity is not being
monopolized by a single router.
Expected Results
We expect the following results:
•
CPU utilization was always less than 90 percent.
•
No system or feature errors (such as router or switch failures, reloads, or CPU hogs) occurred during
testing.
•
No significant errors occurred, such as memory allocation errors, memory access errors, memory
leaks, or unexpected interface toggles.
•
Routing tables correctly reflected all available supernets and subnets.
•
All client/server traffic traversed from source to destination through the expected route for the
duration of the test.
•
Routes converged correctly without major delay.
•
All other procedures executed.
Results
Table 174 shows the Dallas system test results.
Table 174
Dallas System Test Results
Test
Results
Dallas system
Passed
Dallas Reliability Test
This section describes in detail the reliability test case as it pertains to the Dallas campus, using OSPF
as the interior routing protocol and BGP as the exterior routing protocol. Successful execution of the
Dallas system test case is a prerequisite for the execution of this test. The reliability test ran continuously
for 150 hours, with IP routing, NMS, voice, multicast, security, and QoS features enabled.
This test case verified system performance for a number of QoS features, using OSPF and BGP as the
routing protocols. The features that were configured for the Dallas functionality test were carried over
to this test. The following additional features were configured in this test category:
•
BGP MIB feature
•
BGP 4
•
CBWFQ
•
PQ
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
181
Test Suite 5: Dallas Campus
•
MLPPP performance enhancements
•
CGMP
•
Encrypted pre-shared key
•
FRF.12 support on switched Frame Relay PVCs
•
GRE tunnel support
•
H.323 gateway trunk and carrier-based routing enhancements
•
H.323/H.320 gateway
•
Cisco IP phone Support
•
Crypto key management interface
•
IGMP snooping querier
•
IGMP Version 2
•
IKE extended authentication (Xauth)
•
IKE mode configuration
•
IKE security protocol
•
LFI for Frame Relay and ATM Virtual Circuits
•
MLPPP with LFI
•
MSDP
•
OSPF ABR Type 3 LSA filtering
•
OSPF stub router advertisement
•
OSPF
•
PIM MIB extension for IP multicast
•
PIM Version 2
•
QoS—Classification and WRED
•
QoS—Packet marking
•
RFC1850 OSPFv2 MIB support
•
RTP header compression
•
TACACS+
The objective of this test is to verify that the software is stable and reliable in the testbed during the
150-hour test period, with 100 percent or more traffic load on each WAN link.
Test Plan
The procedure used to perform the Dallas reliability test follows:
Step 1
Start the traffic streams for 100 percent of the traffic load by performing the following steps:
a.
Start the BCG (Callgen) to generate calls.
b.
Start Chariot to simulate NetMeeting, Telnet, Lotus, Oracle, FTP, and HTTP traffic.
c.
Start IP/TV, for multicast traffic.
d.
Start IXIA, for background traffic.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
182
Test Suite 5: Dallas Campus
Step 2
Use DART to capture information from the routers for 4 hours.
Step 3
Analyze the output of the Cisco IOS show commands listed in Table 175 at the start and end of the
4-hour test.
Table 175
show Commands Used for the Dallas Reliability Test Start and End View
Command
Purpose
show vtp status
•
Verifies that the VTP feature is enabled.
show vlan brief
•
Verifies VLAN status and port assignments.
show memory summary
On all the WAN routers:
•
Verifies that there are no memory leaks or
errors.
show ip bgp neighbors detail
•
Verifies the intracampus WAN routers.
show ip ospf neighbors detail
•
Verifies the OSPF neighbor information on a
per-interface basis.
show ip ospf interface
•
Verifies if the OSPF adjacent neighbor count
is higher than the neighbor count. If so, the
neighbor list could be corrupted.
•
Verifies the OSPF area and determines if
OSPF is enabled.
show interfaces
On all the WAN routers:
•
Verifies that there are no input or output errors
or queue drops.
•
Verifies the routers’ throughput.
show clock
•
Verifies that the clock is synchronized with the
NTP server.
show buffer failure
•
Verifies a buffer or memory failure.
show ip igmp interface
•
Verifies that IGMP v2 is communicated
among routers and hosts to dynamically
register or leave a multicast group on a LAN
segment.
show ip igmp groups
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
show mac-address-table multicast vlan vlan-id
•
Verifies that the correct multicast addresses
are present in the output.
show mls ip multicast
•
Verifies that multicast flows create MMLS
entries and that switching of the flow is
performed.
show crypto isakmp policy
•
Verifies that the IKE Policy number has the
correct security algorithm.
show crypto map [interface x | tag map-name]
•
Verifies that the crypto map is configured
properly on the tunnel and the physical
interface.
show crypto key mypubkey rsa
•
Verifies the router's RSA public keys.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
183
Test Suite 5: Dallas Campus
Table 175
show Commands Used for the Dallas Reliability Test Start and End View (continued)
Command
Step 4
Purpose
show tacacs
•
Verifies that you are logging in to the correct
TACACS+ server.
show accounting
•
Verifies user account on the router and
switches with privilege 15.
show gateway
•
Verifies that the voice gateway is connected to
gatekeeper egsj-3640-GK.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface that was configured by the
virtual template.
show frame-relay pvc dlci
•
Verifies the encapsulation type, min cir,
fragmentation information, and policies
applied to this PVC.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
Analyze the output of the Cisco IOS show commands listed in Table 176 at 24-hour intervals.
Table 176
show Commands Used for the Dallas Reliability Test 24-Hour View
Command
Purpose
show interface trunk
•
Verifies that the VLAN trunkings are formed
correctly.
show ip route summary
•
Verifies the current state of the routing table.
show memory summary
On all the WAN routers:
•
Verifies that there are no memory leaks or
errors.
show ip bgp neighbors
•
Verifies the Dallas intracampus WAN router
neighbors.
show ip ospf neighbors
•
Verifies the state of the OSPF neighbors.
show crypto isakmp sa
•
Verifies the IKE security association with the
source and destination.
show crypto engine connections active
•
Verifies that each Phase 2 SA was built and
the amount of traffic sent.
show crypto ipsec sa
•
Verifies that the packets are
encap/encrypt/decrypt.
show policy interface
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy maps.
show ip rtp header compression
•
Verifies that IP RTP header compression is
enabled for the voice traffic and if there are
any errors.
show call-manager-fallback all
•
Verifies that the remote campus can still make
calls within the campus.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
184
Test Suite 5: Dallas Campus
Table 176
show Commands Used for the Dallas Reliability Test 24-Hour View (continued)
Command
Step 5
Purpose
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip mroute summary
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
Analyze the output of the Cisco IOS show command listed in Table 177 at 6-hour intervals.
Table 177
show Command Used for the Dallas Reliability Test 6-Hour View
Command
Purpose
show processes cpu
On all the WAN routers:
•
Verifies the CPU utilization.
•
Verifies that CPU capacity is not being
monopolized by a single router.
Expected Results
We expect the following results:
•
CPU utilization was always less than 90 percent.
•
No system or feature errors (such as router or switch failures, reloads, or CPU hogs) occurred during
testing.
•
No significant errors occurred, such as memory allocation errors, memory access errors, memory
leaks, or unexpected interface toggles.
•
Routing tables correctly reflected all available supernets and subnets.
•
All client/server traffic traversed from source to destination through the expected route for the
duration of the test.
•
Routes converged correctly without major delay.
•
All other procedures executed.
Results
Table 178 shows the Dallas reliability test results.
Table 178
Dallas Reliability Test Results
Test
Results
Dallas reliability
Passed with exceptions
Passed with Exceptions Explanation
The Dallas reliability test passed with exceptions for the following reasons:
•
Because of an automated job scheduling conflict with a data collection tool, 14 hours of test data
was not collected. The test results were not affected.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
185
Test Suite 6: Remote Campuses
•
The IXIA traffic generator was turned off to allow problem-characterization work on Chariot and
was not turned on until several hours after the start of the test. There were no problems in the
network and the test results were not affected.
Test Suite 6: Remote Campuses
This test suite consisted of three test cases intended to verify the functionality, reliability, and
performance of basic IP and QoS at the remote campuses.
The remote campuses are one component of the larger global enterprise topology. The global enterprise
topology comprises five multilayer-design campuses—two large campuses with data centers and three
regional campuses—plus 12 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 Remote campuses, the following categories (or types) of testing were conducted:
•
Functionality testing
This test case verified basic IP functionality. The functionality testing involved basic IP testing
(Layer 2: VTP and VLAN trunking; Layer 3: EIGRP and OSPF as interior routing protocols, BGP
routing, routing traffic setup and routing convergence testing, negative testing, and verification and
traffic load testing), network management testing, multicast testing, security testing, voice testing,
and QoS testing.
•
System testing: This test category verified system performance, using IP routing, NMS, voice,
multicast, security, and QoS
•
Reliability testing
This test category verified system reliability.
This test suite contains the following sections:
•
Topology Description, page 186
•
Remote Functionality Test, page 189
•
Remote System Test, page 206
•
Remote Reliability Test, page 211
Topology Description
The remote campuses consisted of only a single branch layer. The network devices were mostly
Catalyst 2950s, Catalyst 3550s, Catalyst 6506s, Cisco 2651s, Cisco 3600s, Cisco 3745s, and Cisco
7206s. The Miami and Phoenix campuses had a GE link to the WAN router. The remainder of the remote
campuses consisted of an FE link to the WAN router.
Two Catalyst 6506s, each with an MSFC2/PFC2, located in Miami performed both Layer 2 and Layer 3
functions. UNIX end-stations and PCs were used to simulate user traffic with Chariot and other test
tools. All WAN routers, except for the Miami Cisco 7206, were used as VoIP voice gateways, registering
into a gatekeeper located at San Jose headquarters and placing real VoIP calls to other gateways located
at other campuses.
The testbeds were used to perform the test for functionality, which included IP routing, network
management, multicast, security, VoIP, and QoS. EIGRP and OSPF were the IP IGP routing protocols,
and route generators injected a total of 5 simulated subnets at various points in the topology. Global
application servers were located at the WAN regional aggregation routers to the remote campuses.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
186
Test Suite 6: Remote Campuses
Applications such as Voice, FTP, and HTTP were simulated by Chariot and other traffic-generating test
tools. Each of the remote campuses simulated end users by using traffic generators and real Linux
stations. Real FTP and HTTP going from remote workstations to the Boston and Dallas campuses were
tested by the scripting tool.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
187
Test Suite 6: Remote Campuses
Figure 14 shows the remote campuses topology at a high level and includes the names of the individual
routers.
Figure 14
Remote Campuses 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
CS-UX1
NEO-PC1 NEO-UX1
Colorado Springs
768
New Orleans
128
PIT-PC1
MIA-UX1
MIA-UX2
MIA-PC1
MIA-PC2
PIT-UX1
Pittsburgh
Dallas
384
Miami
Washington, D.C.
768
E1
T1
EGPHX-7204-VW
EGSAF-2651-VW
EGHOU-3660-VW
EGNY-3745-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-UX1
New York
Dallas
Dallas
Dallas
T1
T1
T1
egaus-2621-w1
NY-PC1
egarl-3640-w1
egboc-1760-w1
aus-ux1
arl-ux1
boc-ux1
Austin
Arlington
Boca Raton
egaus-3550-a
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
188
95536
LA-PC1
Test Suite 6: Remote Campuses
Platform and Software Version Information
Table 179 lists the platforms, router names, software versions, and software images that were configured
in the remote campuses network topology for this test suite.
Table 179
Remote Campuses Platform, Router Name, Software Version, and Software Image
Platform
Router Name
Software Version
Software Image
Cisco 3640
egla-3640-vw
12.2(15)T5
c3640-jsx-mz.122-15.T5
Catalyst 3550
egla-3550-a
12.1(13)EA1c
c3550-i5q3l2-mz.121-13.EA1c
Cisco 7204
egphx-7204-vw
12.2(16b)
c7200-js-mz.122-16b
Catalyst 3550
egphx-3550-a
12.1(13)EA1c
c3550-i5q3l2-mz.121-13.EA1c
Cisco 2651
egcs-2651-vw
12.2(15)T5
c2600-js-mz.122-15.T5
Catalyst 2950
egcs-2950-a
12.1(13)EA1c
c2950-i6q4l2-mz.121-13.EA1c
Cisco 2651
egsaf-2651-vw
12.2(16b)
c2600-js-mz.122-16b
Catalyst 2950
egsaf-2950-a
12.1(13)EA1c
c2950-i6q4l2-mz.121-13.EA1c
Cisco 2651
egneo-2651-vw
12.2(16b)
c2600-js-mz.122-16b
Catalyst 2950
egneo-2950-a
12.1(13)EA1c
c2950-i6q4l2-mz.121-13.EA1c
Catalyst 3550
egaus-3550-a
12.1(13)EA1c
c3550-i5q3l2-mz.121-13.EA1c
Cisco 2621
egaus-2621-w1
12.2(16b)
c2600-jk9s-mz.122-16b
Cisco 3660
eghou-3660-vw
12.2(16b)
c3660-jk9s-mz.122-16b
Catalyst 3550
eghou-3550-a
12.1(13)EA1c
c3550-i5q3l2-mz.121-13.EA1c
Cisco 3640
egpit-3640-vw
12.2(15)T5
c3640-jsx-mz.122-15.T5
Catalyst 3550
egpit-3550-a
12.1(13)EA1c
c3550-i5q3l2-mz.121-13.EA1c
Catalyst 6500
egmia-6506-a1
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Catalyst 6500
egmia-6506-a2
12.1(13)E9
c6sup22-jsv-mz.121-13.E9
Cisco 7206
egmia-7206-w1
12.2(15)T5
c7200-js-mz.122-15.T5
Cisco 3640
egmia-3640-vw2
12.2(16b)
c3640-a3js-mz.122-16b
Cisco 3745
egny-3745-vw
12.2(15)T5
c3745-js-mz.122-15.T5
Catalyst 3550
egny-3550-a
12.1(13)EA1c
c3550-i5q3l2-mz.121-13.EA1c
Cisco 3640
egarl-3640-w1
12.2(16b)
c3640-jk9s-mz.122-16b
Cisco 1760
egboc-1760-w1
12.2(15)T5
c1700-k9o3sv8y7-mz.122-15.T5
Remote Functionality Test
This is a functionality test for the nEverest Enterprise Global project as it pertains to the remote
campuses. The test involved Layer 2 protocols—VTP, VLAN trunking, Layer 3 protocols for EIGRP and
OSPF as the interior routing protocol, SNMP, multicast, security, VoIP, QoS, convergence, and negative
testing.
The functionality test catgegory verified basic IP functionality and included the following sections:
•
Basic IP
•
Network management
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
189
Test Suite 6: Remote Campuses
•
Multicast
•
Security
•
Voice
•
QoS
•
Negative testing
Basic IP
The objectives for this test case were as follows:
•
Verify the basic network operation (that is, network connectivity).
•
Verify the configurability and stability in a controlled environment for each of the functionality
tests.
•
Verify that the selected software versions can be successfully loaded into the devices.
•
Verify that the major IP routing features work as expected.
The following features were included in the test plan:
•
VTP and VLAN
•
VLAN trunking
•
Routing summarization
•
EIGRP stub router
•
OSPF areas
•
Default route generation from WAN aggregation routers
•
Log event or change
•
Other EIGRP feature
•
Route convergence
Test Plan
This is a basic IP functionality test for the remote campuses. The test category verified basic IP
functionality, the Layer 2 protocols such as STP and VLAN trunking, and Layer 3 protocols, such as
OSPF and EIGRP (for interior routing), and BGP (for exterior routing).
The procedure used to perform the Remote campuses basic IP test follows:
Step 1
Set up the VLANs. All switches work in VTP transparent mode.
VLAN 1 is for control traffic on all switches by default. VLAN 10 is for a backdoor network connection
for all remote campuses except Santa Fe, New Orleans, and Colorado Springs. VLANs 11, 12, and 13
are used for the end users in all remote campuses except Santa Fe, New Orleans, Miami, and Colorado
Springs.
For the Catalyst 6506 switches in Miami, VLANs 11 and 12 are used on the first Catalyst 6506 switch,
and VLANs 13 and 14 are used on the second Catalyst 6506 switch for the end users.
For Colorado Springs, New Orleans, and Santa Fe, VLAN 1 is used for the back door and VLAN 11 is
used for the end users.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
190
Test Suite 6: Remote Campuses
Step 2
Set up VLAN Trunking. There is no VLAN trunking on Colorado Springs, Santa Fe, New Orleans, and
Miami.
Step 3
Set up route summarization.
All remote campuses are configured as a stub campus except Miami. The WAN links are summarized
into one /21 route. Remote campuses accept only WAN regional aggregation routers summarized routes
and default routes. The WAN regional aggregation routers have the same local campus routing
summarization schema as the campus WAN access router. Auto-summary is turned off on all remote
campuses WAN routers and distribution switches.
Step 4
Configure the remote site WAN access routers (egla-3640-vw, egphx-7204-vw, egcs-2651-vw,
egneo-2651-vw, eghou-3660-vw, egpit-3640-vw, egny-3620-vw, and egmia-3640-vw2) as stub routers,
so that the query scope is limited to the WAN regional aggregation routers.
Step 5
Configure the OSPF areas for the remote campuses as follows:
•
egphx-7204-vw—area 3
•
egcs-2651-vw—area 3
•
egsaf-2651-vw—area 3 and 4
•
eghou-3660-vw—area 3
•
egmia-7206-vw—area 4 (Miami performs mutual redistribution between OSPF and EIGRP AS 6
[egmia-3640-vw2]).
•
egmia-6506-c1 and egmia-6506-c2—area 4.
Step 6
For default route generation, on the WAN regional aggregation routers, such as egden-7507-w4,
egden-7206-w3, egbos-7206-w3, and egwas-7507-w3, configure distribution lists to control the routes
advertised into the remote campuses. Only default routes and local campus summary routes are
permitted. As the result, the remote campuses will have a primary path to the directly connected campus
via the directly connected link.
Step 7
Configure eigrp log-neighbor-changes for egmia-3640-vw2, egphx-7204-vw, egny-3620-vw,
egla-3640-vw, egcs-2651-vw, egneo-2651-vw, eghou-3660-vw, and egpit-3640-vw.
Step 8
Configure log-adjacency-changes for egmia-7206-w1, egphx-7204-vw, egcs-2651-vw, egsaf-2651-vw,
and eghou-3660-vw.
Step 9
Add the no peer neighbor-route command to all the encapsulation ppp WAN interfaces to avoid
suboptimal routing problems for remote campus WAN interface routes.
Step 10
Apply MD5 hashed authentication to all WAN links running EIGRP and OSPF.
Step 11
Use DART to capture the output of the Cisco IOS show commands listed in Table 180.
Step 12
Verify the test setup by analyzing the output of the Cisco IOS show commands captured in Step 11.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
191
Test Suite 6: Remote Campuses
Table 180
show Commands Used for the Remote Campuses Basic IP Test Verification
Command
Purpose
show interface trunk
•
Verifies that the VLAN trunkings are formed
correctly.
show vtp status
•
Verifies that the VTP feature is enabled.
show vlan brief
•
Verifies VLAN status and port assignments.
show ip route
On all the WAN routers:
and
•
Verifies that the routes are summarized as
expected.
•
Verifies that the routing filters work as
expected.
show ip route summary
show processes cpu
show memory summary
Every 30 seconds on all WAN routers:
•
Verifies that CPU capacity is not being
monopolized by a single router.
•
Verifies that there are no memory leaks or
errors.
•
Verifies that there are no other significant
errors for EIGRP routing.
On all the WAN routers:
show ip eigrp neighbors detail
show ip ospf neighbor
Verifies the CPU utilization.
On all the WAN routers:
show log
show interfaces
•
•
Verifies that there are no input or output errors
or queue drops.
•
Verifies the routers’ throughput.
•
Verifies that the remote WAN routers are
EIGRP stub-enabled.
On all the routers:
•
Verifies the state of the OSPF neighbors.
Expected Results
We expect the following results:
•
The selected software versions can be loaded into the devices.
•
The major IP routing features work as expected.
•
The VTP and VLAN configuration will work correctly.
•
The spanning-tree roots on the distribution switches work correctly.
Results
Table 181 shows the remote campuses basic IP test results.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
192
Test Suite 6: Remote Campuses
Table 181
Remote Campuses Basic IP Test Results
Test
Results
Remote campuses basic IP
Passed
Network Management
This section describes the network management testing in the remote campuses. The following features
were included in the test plan:
•
MIB walk automation script (snmp_walk_test) and traps
•
Syslog and NTP
The objectives of the SNMP MIB testing were as follows:
•
Ensure that the information stored in the MIB database can be accessed, propagated, read, and
written if applicable.
•
Ensure that the operation of the OID values reflects the actual operation on the device.
•
Ensure that there were no SNMP traps.
Test Plan
The procedure used to perform the network management test follows:
Step 1
Configure MIB Walk and Traps.
The MIB walk automation script (snmp_walk_test) will test the OID and traps by platforms and
technologies, report their value, and monitor the UUT behavior. HP OpenView and CiscoWorks2000 are
used as the SNMP receivers.
Step 2
Configure all the routers and switches so that the snmp_walk_test script will work properly.
Step 3
Upload the following MIBs to the snmp_walk_test script:
•
Basic IP:
– CISCO-VTP-MIB
– CISCO-OSPF-MIB
•
Multicast:
– CISCO-IGMP-MIB
– CISCO-PIM-MIB
– CISCO-IPMROUTE-MIB
•
Voice:
– CISCO-VOICE-DIAL-CONTROL-MIB
– CISCO-CCM-MIB
•
QoS:
– CISCO-QOS-MIB
•
IPSec:
– CISCO_IPSEC_MIB
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
193
Test Suite 6: Remote Campuses
– CISCO_IPSEC_FLOW_MONITOR_MIB
Step 4
Set up the eg-cw2k (CiscoWorks2000) server in the San Jose campus as the UNIX NTP and syslog
server.
Step 5
Use DART to capture show command output from the routers.
Step 6
Use the show processes cpu command to verify the CPU utilization and to verify that the CPU capacity
is not being monopolized by a single router.
Step 7
Use the show memory summary command to verify that there are no memory leaks or errors.
Step 8
On server eg-cw2k, verify that syslogd is still running.
Step 9
Use the Cisco IOS show clock command to verify that the clock is synchronized with the NTP server.
Step 10
Verify that the Pat scripts are able to send e-mail notification for error conditions on the routers or
switches.
Step 11
Use the show log command or the show align command to verify that there are no other significant
errors.
Expected Results
We expect the following results:
•
Information stored in the MIB can be accessed, propagated, read, and written.
•
Operation of the OID values reflect the actual operation of the device.
Results
Table 182 shows the remote network management test results.
Table 182
Remote Network Management Test Results
Test
Results
Remote network management
Passed
Multicast
The objective of the remote campuses multicast testing was to verify the functionality of multicast
features across multiple Cisco platforms with various sets of Cisco IOS and CatOS releases.
The following features were included in the test plan:
•
IGMP-v2
•
IGMP snooping
•
MMLS
•
PIM sparse-dense mode
The test was set up to use Cisco IP/TV as a one-to-many video and audio streaming application by
configuring an IP/TV server at the San Jose campus data center to stream six multicast groups. There
were three video and three audio groups.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
194
Test Suite 6: Remote Campuses
Test Plan
Setup
The procedure used to set up the multicast test follows:
Step 1
Configure Cisco IP/TV by performing the following steps:
a.
Connect the IP/TV server to switch egsj-6505-sa3.
b.
Connect the IP/TV clients to the following devices:
c.
•
Los Angeles remote site— egla-3550-a
•
Pittsburgh remote site—egpit-3550-a
•
New York remote site—egny-3550-a
•
Miami remote site—egmia-6506-a1
Configure the IP/TV server to stream the “G2” program, which contains a 239.192.2.0/24 multicast
address scope and consists of a 300-kbps video and audio stream.
Note
The IP/TV client at Pittsburgh receives only a 100-kbps video stream from the Boston
campus.
Step 2
Enable IGMP-v2. This feature is enabled by default in Native IOS and Cisco IOS software, so no
additional configuration is required.
Step 3
Enable IGMP snooping on the following Remote campus Layer 2 switches:
•
egla-3550-a
•
egpit-3550-a
•
egny-3550-a
•
egmia-6506-a1
This feature is enabled by default in Native IOS, so no additional configuration for Layer 3 is required.
Step 4
Enable MMLS on the Catalyst 6500 and Catalyst 4000 Layer 3 distribution switches. This feature is
enabled by default in Native IOS, so no additional configuration is required.
Step 5
Enable PIM sparse-dense mode on the following remote routers:
•
egla-3640-vw
•
egpit-3640-vw
•
egny-3620-vw
•
egmia-7206-w1
Verification
The procedure used to perform the multicast verification test follows:
Step 1
Use DART to capture the output of the generic show commands listed in Table 183.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
195
Test Suite 6: Remote Campuses
Table 183
Generic show Commands Used in the Remote Multicast Verification Test
Command
Purpose
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 or other
memory errors.
show buffer failure
•
Verifies a buffer or memory failure.
show interfaces [interface type]
•
Verifies that there are no input errors, output
errors, or queue drops.
•
Verifies the router's throughput.
•
Verifies that there are no other significant errors.
show logging
Step 2
Using the show commands listed in Table 184, verify that IGMPv2 is communicated among routers and
switches to dynamically register or leave a multicast group on a LAN segment. In addition, verify the
following:
•
The router with the lower IP address is the correct IGMP querier.
•
The router installs group members upon receipt of IGMP join messages.
•
All groups are seen for all IGMP joined groups.
•
The router sends PIM join messages as a consequence of receiving IGMP join messages and creates
the corresponding (*,G) entries.
Table 184
show Commands Used in the Remote Multicast IGMPv2 Verification Test
Command
Step 3
Purpose
show ip igmp interface
•
Verifies that IGMP v2 is communicated among
routers and hosts to dynamically register or
leave a multicast group on a LAN segment.
show ip igmp groups
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
Using the show commands listed in Table 185, verify that IGMP snooping functions as follows:
•
IGMP snooping manages multicast traffic at Layer 2 by configuring the Layer 2 LAN port
dynamically to forward multicast traffic to only those ports that want to receive it.
•
IGMP snooping constrains multicast traffic that exits through LAN ports to which hosts are
connected.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
196
Test Suite 6: Remote Campuses
Table 185
show Commands Used in the Remote Multicast IGMP Snooping Verification Test
Command
Purpose
show ip igmp snooping mroute
On Layer 3 switches:
•
show mac-address-table multicast vlan-id
On Layer 3 switches:
•
Step 4
Verifies that the correct multicast addresses are
present in the output.
Using the show command listed in Table 186, verify that MMLS functions as follows:
•
Multicast flows create MMLS entries and switching of the flow is performed using hardware
shortcuts. In the Catalyst 6500s, the flows are taking the correct paths.
•
The flows are using the expected multicast forwarding entry (*,G) or (S,G).
•
Hardware-based flows are created where expected.
•
Identify the lowest rate of the traffic flow at which a hardware shortcut is created.
•
CPU utilization does not increase. If it does, then there is a possibility that flows are being software
switched.
•
On DFC cards, forwarding tables on line cards are the same as on the processor card.
Table 186
show Command Used in the Remote Multicast MMLS Verification Test
Command
show mls ip multicast
Step 5
Verifies that the correct multicast router has
been learned.
Purpose
•
Verifies that multicast flows create MMLS
entries, and that switching of the flow is
performed.
Using the show commands listed in Table 187, verify that PIM sparse-dense mode functions as follows:
•
Multicast forwarding is achieved using PIM. PIM interacts with the IP unicast forwarding table to
determine the correct path to the source of the multicast packets (RPF), and interacts with IGMP to
recognize networks that have members of the multicast group.
•
All expected PIM neighbors are present and no unknown routers appear.
•
The correct DR election is made on the LAN segment.
•
The correct IIF and OIF lists, RPF, and flags are present in the (*,G) or (S,G) entries.
•
The correct RP mapping is shown for all groups.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
197
Test Suite 6: Remote Campuses
Table 187
show Commands Used in the Remote Multicast PIM Sparse-Dense-Mode Verification
Test
Command
Purpose
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
show ip mroute
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
Expected Results
We expect the following results:
•
IGMPv2 is communicated among routers and hosts to dynamically register or leave a multicast
group on a LAN segment.
•
IGMP snooping manages multicast traffic at Layer 2 by configuring Layer 2 LAN ports dynamically
to forward multicast traffic to only those ports that want to receive it.
•
IGMP snooping constrains multicast traffic that exits through LAN ports to which hosts are
connected.
•
Multicast flows create MMLS entries and switching of the flow is performed using hardware
shortcuts in the Catalyst 6500.
•
Multicast forwarding is achieved using PIM.
Results
Table 188 shows the remote multicast test results.
Table 188
Remote Multicast Test Results
Test
Results
Remote multicast
Passed
Security
This security test was conducted for the remote campuses. This test case verified the functionality of
IPSec, AAA, and SNMP features commonly used by enterprise customers that integrate across multiple
Cisco platforms and Cisco IOS releases at the system level.
The objectives of the security test were as follows:
•
Verify that the IPSec tunnel is established between the campus and the remote WAN edge routers.
Authentication was done with IKE preshared keys.
•
Verify the interaction of encrypted data streams with unencrypted voice streams between the campus
and the remote WAN edge routers. Observe the ability of the router to do voice and IPSec.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
198
Test Suite 6: Remote Campuses
•
Verify TACACS+ AAA services at a system level for all access, distribution, core, and WAN edge
devices in the global topology.
The following features were configured for the security test:
•
IPSec IKE pre-shared transport/tunnel mode
•
AAA TACACS+
•
Security commands
Test Plan
Setup
The procedure used to set up the remote security test follows:
Step 1
Perform Step 2 through Step 11 to configure security features on the following devices:
•
egdal-7206-w3
•
eghou-3660-vw
Step 2
Configure IKE policy.
Step 3
Configure IPSec transforms and protocol.
Step 4
Create access lists for encryption.
Step 5
Apply the crypto maps on the serial interfaces.
Step 6
Configure encryption service facility and AAA TACACS+.
Step 7
Configure the time-stamping service facility for logging.
Step 8
Disable all unnecessary services.
Step 9
Configure an enable password.
Step 10
Configure a console port password.
Step 11
Configure a vty password.
Verification
The procedure used to perform the Remote security verification test follows:
Step 1
Use the show crypto isakmp policy command to verify that the policy number has the correct security
algorithm.
Step 2
Use the show crypto isakmp sa command to verify the IKE security association with the source and
destination.
Step 3
Use the show crypto engine connections active command to verify that each Phase 2 SA is built and
the correct amount of traffic sent.
Step 4
Use the show crypto map command to verify that the crypto map is configured properly on the tunnel
and the physical interface.
Step 5
Use the show crypto key mypubkey rsa command to verify the router RSA public keys.
Step 6
Use the show crypto ipsec sa command to verify that the packets are encap/encrypt/decrypt.
Step 7
Use the show crypto isakmp sa command to verify that the ISAKMP Security Association (SA) is built
between peers.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
199
Test Suite 6: Remote Campuses
Step 8
Use the show tacacs command to verify that the user is logging in to the TACACS+ server
223.255.10.30.
Step 9
Use the show accounting command to verify the user account on the router and switches with
privilege 15.
Expected Results
We expect the following results:
•
The IPSec tunnel is established between the campus and remote WAN edge routers.
•
Encrypted data streams can interact with unencrypted voice streams between the Dallas campus and
the Austin remote WAN edge routers. The router can do voice and IPSec.
•
TACACS+ AAA services function properly at a system level for all access, distribution, core, and
WAN edge devices in the global topology.
Results
Table 189 shows the remote security test results.
Table 189
Remote Security Test Results
Test
Results
Remote security
Passed
Voice
The Cisco CallManager in the San Jose campus is designed with centralized architecture. There were IP
Phones installed, connected to the Remote WAN routers that were running Cisco IOS software with the
Survivable Remote Site Telephony (SRST) feature set. These IP phones registered to the central
CallManager.
After the voice testing was done between the remotes and the main campuses, a negative test was
performed by tearing down the WAN link on these gateways to verify that the IP phones reregistered to
the SRST-enabled gateways and could make analog and digital calls to the end devices on the same
gateway.
The following features were configured for voice testing:
•
Legacy H.323 VoIP
•
SRST
Test Plan
The voice test verified that voice traffic operated properly across the network.
The procedure used to conduct the remote campuses voice test follows:
Step 1
Configure the H.323 voice gateways on the following remote campus routers:
•
egla-3640-vw
•
egphx-7204-vw
•
egsaf-2651-vw
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
200
Test Suite 6: Remote Campuses
•
egneo-2651-vw
•
egcs-2651-vw
•
egny-3620-vw
•
eghou-3660-vw
•
egpit-3640-vw
•
egmia-3640-vw2
Step 2
Configure the BCG test tool.
Step 3
Configure the SRS telephony feature on the Los Angeles, Colorado Springs, and Pittsburgh campuses.
Step 4
Configure CallManager Fallback.
Step 5
Enable the Cisco CallManager Fallback capability.
Step 6
Enable the routers to receive skinny messages. The default port is 2000.
Step 7
Analyze the output of the show commands listed in Table 190. Use the listed commands on all the
routers and collect the output using the DART tool.
Table 190
show Commands Used for the Remote Campuses Voice Test
Command
Purpose
show gateway
•
Verifies that the voice gateway is connected to the gatekeeper
egsj-3640-gk.
show processes cpu
•
Verifies the CPU utilization.
show clock
•
Verifies 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.
show call-manager-fallback all
For SRST verification:
•
Verifies that the remote campus can still make calls within the
campus.
Step 8
Capture the output statistics of Callgen by using CIC.
Step 9
Use performance monitor to check real time the number of gateways and IP phones registered.
Step 10
Configure an IP phone manually, install it in each campus, and make call to test voice quality.
Expected Results
We expect the following results:
•
Voice traffic sent efficiently and all voice channels originated and terminated properly.
•
All originate and terminate BCG channels work properly and without any significant errors.
•
SRST functioned properly.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
201
Test Suite 6: Remote Campuses
Results
Table 191 shows the remote campus voice test results.
Table 191
Remote Campus Voice Test Results
Test
Results
Remote voice verification
Passed
QoS
The high-level objective of the QoS testing was to validate a robust QoS solution for protecting critical
application data, including real-time VoIP, on interarea WAN links, including classification and marking
as close to the network edge as possible, and remarking from L2 CoS to L3 ToS.
QoS Setup Test
The QoS setup test verified that QoS features were configured correctly and that the QoS features were
applied to traffic classes as anticipated. In this test, the MQC three-step model was used to configure the
traffic classes, class maps, and policy maps.
The following features were included in the test plan:
•
Classification and marking—Access lists, DSCP values, port numbers, IP precedence and NBAR
•
Congestion management—CBWFQ and LLQ
•
Traffic conditioning—FRTS and GTS
•
Link efficiency mechanisms—Compressed Real-Time Protocol (cRTP) and MLP Interleaving
Test Plan
The procedure used to perform the QoS setup test follows:
Step 1
Step 2
Define the access lists and traffic classes using the following guidelines:
•
Classify VoIP traffic into a class map called “Real-Time.”
•
Classify applications with small or infrequently sent packets, such as Telnet and voice signaling,
into a class map called “Interactive.”
•
Classify IP/TV multicast video conferencing and multicast signaling into the “Conferencing” class.
•
Classify the mission-critical traffic or traffic that can consume large amounts of bandwidth, such as
Oracle and SAP, into a class map called “Transactional.”
•
Classify Real Media, a UDP-based application for video streaming, into the “Streaming” class.
•
Classify routing traffic into the “Control” class.
•
Classify HTTP and FTP traffic into the “class-default” class, which is the class map for best-effort
service.
Associate the policy maps and actions with each class of traffic by performing the following steps:
a.
Configure policy maps "OUT-WAN-FF1," "OUT-WAN-AF3," and "OUT-WAN-FF2" on
egsaf-2651-vw, egneo-2651-vw, egcs-2651-vw, eghou-3660-vw, egpit-3640-vw, egny-3620-vw, and
egphx-7204-vw routers that have link speeds of 768 kbps and lower.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
202
Test Suite 6: Remote Campuses
b.
Step 3
Configure policy maps "OUT-WAN-DT1," "OUT-WAN-DT3," "OUT-WAN-DT4,"
"OUT-WAN-DT5," "OUT-WAN-DT7,"on egmia-7206-w1, egla-3640-vw, egphx-7204-vw,
eghou-3660-vw, egpit-3640-vw, egny-3620-vw, and egmia-3640-vw2 routers that have T1/E1/T3
links.
Attach policy maps to the interfaces listed in Table 192, and apply the other appropriate QoS features.
Table 192 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.
Table 192
Routers, Policy Maps, and Interfaces for Remote QoS Setup Test
Router
Policy Map or Feature
Interface
egcs-2651-vw
OUT-LAN-FE
Fa0/1
egcs-2651-vw
OUT-WAN-FF1
Serial0/0
egla-3640-vw
OUT-LAN-FE
Fa1/0
egla-3640-vw
OUT-WAN-DT1
Serial0/0:0
egmia-3640-vw2
OUT-LAN-FE
Fa0/1
egmia-3640-vw2
OUT-LAN-FE
Fa1/0
egmia-3640-vw2
OUT-WAN-DT7
Serial1/0
egmia-7206-w1
OUT-LAN-FE
Fa1/0
egmia-7206-w1
OUT-LAN-FE
Fa2/0
egmia-7206-w1
OUT-LAN-GE
Gi0/1
egneo-2651-vw
OUT-WAN-FE
Fa0/1
egneo-2651-vw
OUT-WAN-AF3
Virtual-Template20
egny-3745-vw
OUT-LAN-FE
Fa0/1
egny-3745-vw
OUT-WAN-DT6
Serial0/0
egphx-7204-vw
OUT-LAN-GE
Gi0/0
egphx-7204-vw
OUT-WAN-DT3
Serial4/0:0
egpit-3640-vw
OUT-LAN-FE
Fa1/0
egpit-3640-vw
OUT-WAN-DT5
Serial0/0
eghou-3660-vw
OUT-LAN-FE
Fa0/0
eghou-3660-vw
OUT-WAN-DT4
Serial3/0:0
egsaf-2651-vw
OUT-LAN-FE
Fa0/1
egsaf-2651-vw
OUT-WAN-FF2
Serial0/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.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
203
Test Suite 6: Remote Campuses
•
QoS features were configured and were functioning properly.
Results
Table 193 shows the remote QoS setup test results.
Table 193
Remote QoS Setup Test Results
Test
Results
Remote QoS setup
Passed
QoS Verification Test
This test verified that incoming and outgoing 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, data traffic were used, QoS features were configured, and the network was experiencing traffic
congestion.
Test Plan
The procedure used to perform the remote QoS verification test follows:
Step 1
Start the Chariot traffic testing tool to congest the network.
Step 2
Use DART to capture the output of the Cisco IOS show commands listed in Table 194. The show
processes cpu command was used every 30 seconds for 2 hours. The other commands were used every
5 minutes for 2 hours.
Table 194
show Commands Used on the Remote WAN Routers
Command
Purpose
show clock
•
Verifies the current time.
show policy-map interface [interface name]
•
Verifies that data traffic gets the percentage of
bandwidth assigned in the policy maps.
show interfaces [interface type]
On all outbound WAN 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 shaped rate is 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.
show traffic-shape statistics
•
Verifies that traffic shaping is enabled.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface that was configured by the
virtual template.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
204
Test Suite 6: Remote Campuses
Table 194
show Commands Used on the Remote WAN Routers (continued)
Command
Purpose
show ppp multilink [interface type]
•
Verifies multilink PPP status, such as number of
member interfaces configured per bundled
interface.
show ip rtp header compression
•
Verifies that IP RTP header compression is
turned on and if there are any errors.
Expected Results
We expect the following results:
•
CPU utilization was always less than 90 percent.
•
No system or feature errors (such as router or switch failures, reloads, or CPU hogs) occurred during
testing.
•
No significant errors occurred, such as memory allocation errors, memory access errors, memory
leaks, or unexpected interface toggles.
•
Routing tables correctly reflected all available supernets and subnets.
•
All client/server traffic traversed from source to destination through the expected route for the
duration of the test.
•
Routes converged correctly without major delay.
•
All other procedures executed.
Results
Table 195 shows the remote QoS verification test results.
Table 195
Remote QoS Verification Test Results
Test
Results
Remote QoS verification
Passed
Negative Test
This test verifies the QoS functionality if a primary WAN link fails.
Test Plan
The procedure used to perform the negative test follows:
Step 1
Ensure that the BCG, Chariot, and IXIA traffic testing tools are running.
Step 2
Use the show ip route command to verify that all simulated routes exist.
Step 3
Set up a continuous ping between two PCs located in two points in the topology. Set the ping packet size
to 512 bytes. Set the ping timeout to 500 ms.
Step 4
During the ping test, make one of the following link-to-router connections fail during each pass:
•
New York primary link
•
Pittsburgh primary link
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
205
Test Suite 6: Remote Campuses
•
Houston primary link
•
Phoenix primary link
•
New Orleans primary link
Step 5
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 timeout setting.
Step 6
Restore the failed link.
Step 7
After the link-to-router connection is up, repeat Step 4 through Step 6 for each link.
Expected Results
We expect the following results:
•
The QoS features will function correctly if a primary WAN link fails.
•
No system or feature errors (such as router or switch failures, reloads, or CPU hogs) occurred during
testing.
•
No significant errors occurred, such as memory allocation errors, memory access errors, memory
leaks, or unexpected interface toggles.
•
Routing tables correctly reflected all available supernets and subnets.
•
All client/server traffic traversed from source to destination through the expected route for the
duration of the test.
•
Routes converged correctly without major delay.
•
All other procedures executed correctly.
Results
Table 196 shows the results of the remote negative test.
Table 196
Remote Negative Test Results
Test
Results
Remote negative
Passed
Remote System Test
This is the system test case for IP routing, SNMP, security, multicast, VoIP, and QoS features for the
nEverest Enterprise Global project as it pertains to the remote campuses.
The overall objectives of this test case were as follows:
•
Verify that the IP routing, SNMP, security, multicast, VoIP, and QoS features could be incorporated
into the remote campuses.
•
Verify the successful operation of the Cisco IOS release.
•
Verify that the system behaved as expected.
This test case verified system performance for a number of QoS features, using OSPF and BGP as the
routing protocols. The features that were configured for the Remote functionality test were carried over
to this test. The following additional features were configured in this test case:
•
CBWFQ
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
206
Test Suite 6: Remote Campuses
•
PQ
•
MLPPP performance enhancements
•
CEF support for IP routing between IEEE 802.1Q vLANs
•
CGMP
•
DES/3DES VPN encryption AIM for 2600/3600
•
EIGRP
•
Enhanced IGRP stub routing
•
Frame Relay—FRF.5 and FRF.8
•
MQC – based FRTS
•
GRE tunnel support
•
H.323/H.320 gateway
•
Cisco IP phone support
•
IEEE 802.1Q VLAN support
•
IGMP snooping querier
•
IGMP Version 2
•
IKE security protocol
•
IP routing
•
SRST Version 3.0
•
LFI for Frame Relay and ATM virtual circuits
•
LLQ with priority percentage support
•
MLPPP with LFI
•
MQC
•
MSDP
•
OSPF
•
PIM MIB extension for IP multicast
•
PIM Version 2
•
RFC 1850 OSPFv2 MIB support
•
TACACS+
Test Plan
The procedure used to perform the remote system test follows:
Step 1
Step 2
Start the traffic streams for 100 percent of the traffic load as follows:
a.
Start the BCG (Callgen) to generate calls.
b.
Start Chariot to simulate NetMeeting, Telnet, Lotus, Oracle, FTP, and HTTP traffic.
c.
Start IP/TV, for multicast traffic.
d.
Start IXIA, for background traffic.
Use DART to capture information from the routers for 4 hours.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
207
Test Suite 6: Remote Campuses
Step 3
Analyze the output of the Cisco IOS show commands listed in Table 197 at the start and end of the
4-hour test.
Table 197
show Commands Used for the Remote System Test Start and End View
Command
Purpose
show vtp status
•
Verifies that the VTP feature is enabled.
show vlan brief
•
Verifies VLAN status and port assignments.
show memory summary
On all the WAN routers:
•
Verifies that there are no memory leaks or
errors.
show ip eigrp neighbors detail
•
Verifies that the remote WAN routers are
EIGRP stub-enabled.
show ip ospf neighbors detail
•
Verifies that the OSPF neighbor information
on a per-interface basis.
show ip ospf interface
•
Verifies if the OSPF adjacent neighbor count
is higher than the neighbor count. If so, the
neighbor list could be corrupted.
•
Verifies the OSPF area and determines if
OSPF is enabled.
•
Verifies if the EIGRP adjacent neighbor count
is higher than the neighbor count. If so, the
neighbor list could be corrupted.
show ip eigrp interface
show interfaces
On all the WAN routers:
•
Verifies that there are no input or output errors
or queue drops.
•
Verifies the routers’ throughput.
show clock
•
Verifies that the clock is synchronized with the
NTP server.
show buffer failure
•
Verifies a buffer or memory failure.
show ip igmp interface
•
Verifies that IGMP v2 is communicated
among routers and hosts to dynamically
register or leave a multicast group on a LAN
segment.
show ip igmp groups
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
show mac-address-table multicast vlan vlan-id
•
Verifies that the correct multicast addresses
are present in the output.
show mls ip multicast
•
Verifies that multicast flows create MMLS
entries and that switching of the flow is
performed.
show crypto isakmp policy
•
Verifies that the IKE Policy number has the
correct security algorithm.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
208
Test Suite 6: Remote Campuses
Table 197
show Commands Used for the Remote System Test Start and End View (continued)
Command
Step 4
Purpose
show crypto map [interface x | tag map-name]
•
Verifies that the crypto map is configured
properly on the tunnel and the physical
interface.
show crypto key mypubkey rsa
•
Verifies the router's RSA public keys.
show tacacs
•
Verifies that you are logging in to the correct
TACACS+ server.
show accounting
•
Verifies user account on the router and
switches with privilege 15.
show gateway
•
Verifies that the voice gateway is connected to
gatekeeper egsj-3640-GK.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface that was configured by the
virtual template.
show frame-relay pvc dlci
•
Verifies the encapsulation type, min cir,
fragmentation information, and policies
applied to this PVC.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
Analyze the output of the Cisco IOS show commands listed in Table 198 at 60-minute intervals.
Table 198
show Commands Used for the Remote System Test 60-Minute View
Command
Purpose
show interface trunk
•
Verifies that the VLAN trunkings are formed
correctly.
show ip route summary
•
Verifies the current state of the routing table.
show memory summary
On all the WAN routers:
•
Verifies that there are no memory leaks or
errors.
show ip eigrp neighbors
•
Verifies the Remote WAN router neighbors.
show ip ospf neighbors
•
Verifies the state of the OSPF neighbors.
show crypto isakmp sa
•
Verifies the IKE security association with the
source and destination.
show crypto engine connections active
•
Verifies that each Phase 2 SA was built and
the amount of traffic sent.
show crypto ipsec sa
•
Verifies that the packets are
encap/encrypt/decrypt.
show policy interface
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy maps.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
209
Test Suite 6: Remote Campuses
Table 198
show Commands Used for the Remote System Test 60-Minute View (continued)
Command
Step 5
Purpose
show ip rtp header compression
•
Verifies that IP RTP header compression is
enabled for the voice traffic and if there are
any errors.
show call-manager-fallback all
•
Verifies that the remote campus can still make
calls within the campus.
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip mroute summary
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
Analyze the output of the Cisco IOS show command listed in Table 199 at 10-minute intervals.
Table 199
show Command Used for the Remote System Test 10-Minute View
Command
Purpose
show processes cpu
On all the WAN routers:
•
Verifies the CPU utilization.
•
Verifies that CPU capacity is not being
monopolized by a single router.
Expected Results
We expect the following results:
•
CPU utilization was always less than 90 percent.
•
No system or feature errors (such as router or switch failures, reloads, or CPU hogs) occurred during
testing.
•
No significant errors occurred, such as memory allocation errors, memory access errors, memory
leaks, or unexpected interface toggles.
•
Routing tables correctly reflected all available supernets and subnets.
•
All client/server traffic traversed from source to destination through the expected route for the
duration of the test.
•
Routes converged correctly without major delay.
•
All other procedures executed.
Results
Table 200 shows the remote system test results.
Table 200
Remote System Test Results
Test
Results
Remote system
Passed
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
210
Test Suite 6: Remote Campuses
Remote Reliability Test
This section describes in detail the reliability test case as it pertains to the remote campuses, using
EIGRP and OSPF as the interior routing protocols. Successful execution of the remote system test case
is a prerequisite for the execution of this test. The reliability test ran continuously for 150 hours, with IP
routing, NMS, voice, multicast, security, and QoS features enabled.
This test category verified system performance for a number of QoS features. The features that were
configured for the Remote functionality test were carried over to this test. The following additional
features were configured in this test category:
•
CBWFQ
•
PQ
•
MLPPP performance enhancements
•
CEF Support for IP routing between IEEE 802.1Q VLANs
•
DES/3DES VPN encryption AIM for Cisco 2600/3600
•
EIGRP
•
Enhanced IGRP Stub Routing
•
Frame Relay—FRF.5 and FRF.8
•
MQC)-based FRTS
•
GRE tunnel support
•
H.323/H.320 gateway
•
Cisco IP phone support
•
IEEE 802.1Q VLAN support
•
IGMP snooping querier
•
IGMP Version 2
•
IKE security protocol
•
IP routing
•
SRST Version 3.0
•
LFI for Frame Relay and ATM virtual circuits
•
LLQ with priority percentage support
•
MD5 password encryption
•
MLPPP with LFI
•
MQC
•
NBAR Real Time Control Protocol
•
OSPF
•
PIM MIB extension for IP multicast
•
PIM Version 2
•
RFC 1850 OSPFv2 MIB support
•
RTP header compression
•
TACACS+
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
211
Test Suite 6: Remote Campuses
The objective of this case was to verify that the software is stable and reliable in the testbed during the
150-hour test period, with 100 percent or more traffic load on each WAN link.
Test Plan
The procedure used to perform the remote reliability test follows:
Step 1
Start traffic streams for a 100 percent traffic load by performing the following steps:
a.
Start the BCG (Callgen) to generate calls.
b.
Start Chariot to simulate NetMeeting, Telnet, Lotus, Oracle, FTP, and HTTP traffic.
c.
Start IP/TV, for multicast traffic.
d.
Start IXIA, for background traffic.
Step 2
Use DART to capture information from the routers for 4 hours.
Step 3
Analyze the output of the Cisco IOS show commands listed in Table 201 at the start and end of the
4-hour test.
Table 201
show Commands Used for the Remote Reliability Test Start and End View
Command
Purpose
show vtp status
•
Verifies that the VTP feature is enabled.
show vlan brief
•
Verifies VLAN status and port assignments.
show memory summary
On all the WAN routers:
•
Verifies that there are no memory leaks or
errors.
show ip eigrp neighbors detail
•
Verifies that the remote WAN routers are
EIGRP stub-enabled.
show ip ospf neighbors detail
•
Verifies that the OSPF neighbor information
on a per-interface basis.
show ip ospf interface
•
Verifies if the OSPF adjacent neighbor count
is higher than the neighbor count. If so, the
neighbor list could be corrupted.
•
Verifies the OSPF area and determines if
OSPF is enabled.
•
Verifies if the EIGRP adjacent neighbor count
is higher than the neighbor count. If so, the
neighbor list could be corrupted.
show ip eigrp interface
show interfaces
On all the WAN routers:
•
Verifies that there are no input or output errors
or queue drops.
•
Verifies the routers’ throughput.
show clock
•
Verifies that the clock is synchronized with the
NTP server.
show buffer failure
•
Verifies a buffer or memory failure.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
212
Test Suite 6: Remote Campuses
Table 201
show Commands Used for the Remote Reliability Test Start and End View (continued)
Command
Step 4
Purpose
show ip igmp interface
•
Verifies that IGMP v2 is communicated
among routers and hosts to dynamically
register or leave a multicast group on a LAN
segment.
show ip igmp groups
•
Verifies that the routers install group members
upon receipt of IGMP join messages.
show mac-address-table multicast vlan vlan-id
•
Verifies that the correct multicast addresses
are present in the output.
show mls ip multicast
•
Verifies that multicast flows create MMLS
entries and that switching of the flow is
performed.
show crypto isakmp policy
•
Verifies that the IKE policy number has the
correct security algorithm.
show crypto map [interface x | tag map-name]
•
Verifies that the crypto map is configured
properly on the tunnel and the physical
interface.
show crypto key mypubkey rsa
•
Verifies the router's RSA public keys.
show tacacs
•
Verifies that you are logging in to the correct
TACACS+ server.
show accounting
•
Verifies user account on the router and
switches with privilege 15.
show gateway
•
Verifies that the voice gateway is connected to
gatekeeper egsj-3640-GK.
show interfaces virtual-access
•
Verifies the configuration of the active virtual
access interface that was configured by the
virtual template.
show frame-relay pvc dlci
•
Verifies the encapsulation type, min cir,
fragmentation information, and policies
applied to this PVC.
show ip pim interface
•
Verifies the correct DR election on the LAN
segment.
Analyze the output of the Cisco IOS show commands listed in Table 202 at 24-hour intervals.
Table 202
show Commands Used for the Remote Reliability Test 24-Hour View
Command
Purpose
show interface trunk
•
Verifies that the VLAN trunkings are formed
correctly.
show ip route summary
•
Verifies the current state of the routing table.
show memory summary
On all the WAN routers:
•
Verifies that there are no memory leaks or
errors.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
213
Test Suite 6: Remote Campuses
Table 202
show Commands Used for the Remote Reliability Test 24-Hour View (continued)
Command
Step 5
Purpose
show ip eigrp neighbors
•
Verifies the Remote WAN router neighbors.
show ip ospf neighbors
•
Verifies the state of the OSPF neighbors.
show crypto isakmp sa
•
Verifies the IKE security association with the
source and destination.
show crypto engine connections active
•
Verifies that each Phase 2 SA was built and
the amount of traffic sent.
show crypto ipsec sa
•
Verifies that the packets are
encap/encrypt/decrypt.
show policy interface
•
Verifies that voice and data traffic get the
percentage of bandwidth assigned in the
policy maps.
show ip rtp header compression
•
Verifies that IP RTP header compression is
enabled for the voice traffic and if there are
any errors.
show call-manager-fallback all
•
Verifies that the remote campus can still make
calls within the campus.
show ip pim neighbor
•
Verifies that all expected PIM neighbors are
present.
show ip mroute summary
•
Verifies the correct IIF and OIF lists, RPF, and
flags in the (*,G) or (S,G) entries.
Analyze the output of the Cisco IOS show command listed in Table 203 at 6-hour intervals.
Table 203
show Command Used for the Remote Reliability Test 6-Hour View
Command
Purpose
show processes cpu
On all the WAN routers:
•
Verifies the CPU utilization.
•
Verifies that CPU capacity is not being
monopolized by a single router.
Expected Results
We expect the following results:
•
CPU utilization was always less than 90 percent.
•
No system or feature errors (such as router or switch failures, reloads, or CPU hogs) occurred during
testing.
•
No significant errors occurred, such as memory allocation errors, memory access errors, memory
leaks, or unexpected interface toggles.
•
Routing tables correctly reflected all available supernets and subnets.
•
All client/server traffic traversed from source to destination through the expected route for the
duration of the test.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
214
Supplementary Information
•
Routes converged correctly without major delay.
•
All other procedures executed.
Results
Table 204 shows the remote reliability test results.
Table 204
Remote Reliability Test Results
Test
Results
Remote reliability
Passed with exceptions
Passed with Exceptions Explanation
The Remote reliability test passed with exceptions for the following reasons:
•
Because of an automated job scheduling conflict with a data collection tool, 14 hours of test data
was not collected. The test results were not affected.
•
The IXIA traffic generator was turned off to allow problem-characterization work on Chariot and
was not turned on until several hours after the start of the test. There were no problems in the
network and the test results were not affected.
•
An H.323 VoIP traffic generator failed to start, resulting in a 2-hours delay of the start of VoIP traffic
between the Denver campus and the remote campuses. The test results were not affected.
•
One of the multicast clients was turned off to allow problem-characterization work on Chariot and
was not turned on until several hours after the start of the test. There was no multicast traffic between
San Jose and Los Angeles while the client was off, but there were no problems in the network and
the test results were not affected.
Supplementary Information
This section contains additional information about the global enterprise system testing. It includes
device characteristics for the devices used in the lab environment.
Device Characteristics
Table 205 through Table 291 contain the device characteristics for the devices used in the global
enterprise campus testbed.
Table 205 shows the device characteristics for egsj-7609-w1.
Table 205
Device Characteristics for egsj-7609-w1
Hostname
egsj-7609-w1
Platform
Cisco 7609
Memory
458752K
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
215
Supplementary Information
Table 205
Hardware
Device Characteristics for egsj-7609-w1 (continued)
Slot 2: FWS-X6182-2PA
Bay 0: Mx HSSI PA, 2 ports
Bay 1: ENHANCED ATM OC3 MM PA, 1 port
Slot 4: FWS-X6182-2PA
Slot 6: 2-port POS-OC12-MM-SR controller
Table 206 shows the device characteristics for egsj-7609-w2.
Table 206
Device Characteristics for egsj-7609-w2
Hostname
egsj-7609-w2
Platform
Cisco 7609
Memory
458752K
Hardware
Slot 2: FWS-X6182-2PA
Bay 0: T3+ Serial PA, 2 ports
Bay 1: CT3 single wide PA, 1 port
Slot 3: FWS-X6182-2PA
Bay 0: ENHANCED ATM DS3 PA, 1 port
Bay 1: POS PA, 1 port, PA-POSSW-MM
Slot 6: 2-port POS-OC12-MM-SR controller
Table 207 shows the device characteristics for egsj-7206-w3.
Table 207
Device Characteristics for egsj-7206-w3
Hostname
egsj-7206-w3
Platform
Cisco 7206
Memory
122880K
Hardware
Slot
Slot
Slot
Slot
Slot
0:
1:
2:
3:
4:
C7200-IO-FE-MII/RJ45
PA-FE-TX
PA-FE-TX-nISL
PA-FE-TX
PA-MC-2T1
Table 208 shows the device characteristics for egsj-6509-c1.
.
Table 208
Device Characteristics for egsj-6509-c1
Hostname
egsj-6509-c1
Platform
Catalyst 6500
Memory
458752K
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
216
Supplementary Information
Table 208
Hardware
Device Characteristics for egsj-6509-c1 (continued)
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-SUP2-2GE
2
0 Supervisor-Other
unknown
3
16 Pure SFM-mode 16 port 1000mb GBIC
WS-X6816-GBIC
4
2 Network Analysis Module
WS-X6380-NAM
5
0 Switching Fabric Module-128 (Active)
WS-C6500-SFM
6
48 48 port 10/100 mb RJ45
WS-X6348-RJ-45
Mod
--1
2
3
4
5
6
MAC addresses
Hw
Fw
---------------------------------- ------ -----------0001.c9da.eeac to 0001.c9da.eead
3.2
6.1(3)
0000.0000.0000 to 0000.0000.0000
0.0
Unknown
0002.7ee1.55d0 to 0002.7ee1.55df
1.2
12.1(5r)E1
0008.a430.30b2 to 0008.a430.30b3
1.3
4B4LZ0XA
0001.0002.0003 to 0001.0002.0003
1.2
6.1(3)
0005.7481.d858 to 0005.7481.d887
6.0
5.4(2)
Mod
--1
1
3
6
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Distributed Forwarding Card
Inline Power Module
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-DFC
WS-F6K-PWR
Serial No.
----------SAD0604019E
unknown
SAD055101NW
SAD060301JP
SAL0552FQA0
SAL0601FY1Z
Sw
-----------7.5(0.6)HUB1
Unknown
12.1(nightly
1.2(1)
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Unknown
Ok
Ok
Ok
Ok
Serial
Hw
--------------- ------SAD060300ZB
3.0
SAD060402BG
1.3
SAD060100DS
2.0
1.0
Status
------Ok
Ok
Ok
Ok
Table 209 shows the device characteristics for egsj-6509-c2.
Table 209
Device Characteristics for egsj-6509-c2
Hostname
egsj-6509-c2
Platform
Catalyst 6500
Memory
458752K
Hardware
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-SUP2-2GE
2
0 Supervisor-Other
unknown
3
16 Pure SFM-mode 16 port 1000mb GBIC
WS-X6816-GBIC
4
2 Network Analysis Module
WS-X6380-NAM
5
0 Switching Fabric Module-128 (Active)
WS-C6500-SFM
6
48 48 port 10/100 mb RJ45
WS-X6348-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.6415.bc5e to 0001.6415.bc5f
3.2
6.1(3)
2 0000.0000.0000 to 0000.0000.0000
0.0
Unknown
3 0001.63d4.4bc2 to 0001.63d4.4bd1
1.2
12.1(5r)E1
4 0003.3287.bd2c to 0003.3287.bd2d
1.3
4B4LZ0XA
5 0001.0002.0003 to 0001.0002.0003
1.2
6.1(3)
6 0004.6d42.2320 to 0004.6d42.234f
1.4
5.4(2)
Mod
--1
1
3
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Distributed Forwarding Card
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-DFC
Serial No.
----------SAD060300HG
unknown
SAD055101JX
SAD060301KE
SAD060200CA
SAL05031CUC
Sw
-----------7.5(0.6)HUB1
Unknown
12.1(nightly
1.2(1)
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Unknown
Ok
Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD060300UE
3.0
Ok
SAD060102T3
1.3
Ok
SAD060100FM
2.0
Ok
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
217
Supplementary Information
Table 210 shows the device characteristics for egsj-6509-c3.
Table 210
Device Characteristics for egsj-6509-c3
Hostname
egsj-6509-c3
Platform
Catalyst 6500
Memory
112640K
Hardware
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-SUP2-2GE
2
0 Supervisor-Other
unknown
3
16 Pure SFM-mode 16 port 1000mb GBIC
WS-X6816-GBIC
4
48 48 port 10/100 mb RJ45
WS-X6348-RJ-45
5
0 Switching Fabric Module-128 (Active)
WS-C6500-SFM
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.6414.f0fa to 0001.6414.f0fb
2.2
6.1(3)
2 0000.0000.0000 to 0000.0000.0000
0.0
Unknown
3 0001.6477.561a to 0001.6477.5629
1.1
12.1(5r)E1
4 0002.fc1f.4298 to 0002.fc1f.42c7
2.1
5.4(2)
5 0001.0002.0003 to 0001.0002.0003
1.2
6.1(3)
Mod
--1
1
3
4
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Distributed Forwarding Card
Inline Power Module
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-DFC
WS-F6K-PWR
Serial No.
----------SAD05060K6D
unknown
SAD0548014T
SAD044103J6
SAD060200BS
Sw
-----------7.5(0.6)HUB1
Unknown
12.1(nightly
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Unknown
Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD050610PY
1.3
Ok
SAD05060YLS
1.2
Ok
SAD060301EE
2.0
Ok
1.0
Ok
Table 211 shows the device characteristics for egsj-6509-c4.
Table 211
Device Characteristics for egsj-6509-c4
Hostname
egsj-6509-c4
Platform
Catalyst 6500
Memory
458752K
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
218
Supplementary Information
Table 211
Hardware
Device Characteristics for egsj-6509-c4 (continued)
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-S2U-MSFC2
2
0 Supervisor-Other
unknown
3
16 Pure SFM-mode 16 port 1000mb GBIC
WS-X6816-GBIC
4
48 48 port 10/100 mb RJ45
WS-X6348-RJ-45
5
0 Switching Fabric Module-128 (Active)
WS-C6500-SFM
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0002.7e38.7490 to 0002.7e38.7491
3.2
6.1(3)
2 0000.0000.0000 to 0000.0000.0000
0.0
Unknown
3 0002.7ee1.2360 to 0002.7ee1.236f
1.1
12.1(5r)E1
4 0005.7481.a858 to 0005.7481.a887
6.0
5.4(2)
5 0001.0002.0003 to 0001.0002.0003
1.2
6.1(3)
Mod
--1
1
3
4
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Distributed Forwarding Card
Inline Power Module
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-DFC
WS-F6K-PWR
Serial No.
----------SAD06020342
unknown
SAD05480183
SAL0501FUWY
SAD060200FG
Sw
-----------7.5(0.6)HUB1
Unknown
12.1(nightly
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Unknown
Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD060204JU
3.0
Ok
SAD05520623
1.3
Ok
SAD060100GE
2.0
Ok
1.0
Ok
Table 212 shows the device characteristics for egsj-6506-b1d2.
Table 212
Device Characteristics for egsj-6506-b1d2
Hostname
egsj-6506-b1d2
Platform
Catalyst 6500
Memory
227328K
Hardware
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-S2U-MSFC2
2
16 SFM-capable 16 port 1000mb GBIC
WS-X6516-GBIC
3
2 2-port OC-12 ATM MM
WS-X6101-OC12-MMF
4
8 T1
WS-X6608-T1
5
8 T1
WS-X6608-T1
6
48 48-port 10/100 mb RJ45
WS-X6148-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.6415.b0da to 0001.6415.b0db
3.2
6.1(3)
2 0001.6477.55da to 0001.6477.55e9
3.0
6.1(3)
3 00d0.d333.c88c to 00d0.d333.c8ab
1.0
Unknown
4 0001.6413.6100 to 0001.6413.6107
1.1
Unknown
5 0001.6477.5a0e to 0001.6477.5a15
1.2
Unknown
6 000b.fdf1.48f0 to 000b.fdf1.491f
1.1
5.4(2)
Mod
--1
1
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
Serial No.
----------SAD055106FW
SAD0551001A
SAD03420972
SAD04380DAS
SAD060403GX
SAL0710A141
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
Unknown
Unknown
Unknown
7.5(0.6)HUB1
Status
------Ok
Ok
PwrDown
PwrDown
PwrDown
Ok
Serial
Hw
Status
--------------- ------- ------SAD055200FT
3.0
Ok
SAD055101U9
1.3
Ok
Table 213 shows the device characteristics for egsj-4006-b2d1.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
219
Supplementary Information
Table 213
Device Characteristics for egsj-4006-b2d1
Hostname
egsj-4006-b2d1
Platform
Catalyst 4000
Memory
262144K
Hardware
Mod Ports Card Type
Model
Serial No.
----+-----+--------------------------------------+-----------------+----------1
2 1000BaseX (GBIC) Supervisor(active)
WS-X4014
JAB06400796
2
6 1000BaseX (GBIC)
WS-X4306-GB
JAE063608LK
3
32 10/100BaseTX (RJ45)
WS-X4232-RJ-XX
JAB034206PV
M MAC addresses
Hw Fw
Sw
Status
--+--------------------------------+---+------------+----------------+--------1 0008.a33f.2700 to 0008.a33f.2701 2.1 12.1(12r)EW 12.1(13)EW2, EAR Ok
2 0008.a3cf.fb18 to 0008.a3cf.fb1d 2.2
Ok
3 0030.8074.d6d0 to 0030.8074.d6ff 1.0
Ok
Table 214 shows the device characteristics for egsj-4506-b2d2.
Table 214
Device Characteristics for egsj-4506-b2d2
Hostname
egsj-4506-b2d2
Platform
Catalyst 4000
Memory
262144K
Hardware
Mod Ports Card Type
Model
Serial No.
----+-----+--------------------------------------+-----------------+----------1
2 1000BaseX (GBIC) Supervisor(active)
WS-X4014
JAB064007G3
2
34 10/100BaseTX (RJ45), 1000BaseX (GBIC) WS-X4232
JAB034900UM
M MAC addresses
Hw Fw
Sw
Status
--+--------------------------------+---+------------+----------------+--------1 000a.4165.9780 to 000a.4165.9781 2.1 12.1(12r)EW 12.1(13)EW2, EAR Ok
2 0030.1958.3cb0 to 0030.1958.3cd1 2.0
Ok
Table 215 shows the device characteristics for egsj-6506-sd1.
Table 215
Device Characteristics for egsj-6506-sd1
Hostname
egsj-6506-sd1
Platform
Catalyst 6500
Memory
227328K
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
220
Supplementary Information
Table 215
Hardware
Device Characteristics for egsj-6506-sd1 (continued)
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-S2U-MSFC2
2
16 SFM-capable 16 port 1000mb GBIC
WS-X6516-GBIC
3
48 48 port 10/100 mb RJ-45 ethernet
WS-X6248-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.6415.a81a to 0001.6415.a81b
3.2
6.1(3)
2 00d0.c0d6.c5e4 to 00d0.c0d6.c5f3
3.0
6.1(3)
3 0010.7bff.68c8 to 0010.7bff.68f7
1.1
4.2(0.24)VAI
Mod
--1
1
2
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Distributed Forwarding Card
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-DFC
Serial No.
----------SAD055006ED
SAD054200DT
SAD03235475
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD055004KG
3.0
Ok
SAD05500770
2.0
Ok
SAD054305WE
2.0
Ok
Table 216 shows the device characteristics for egsj-6506-sd2.
Table 216
Device Characteristics for egsj-6506-sd2
Hostname
egsj-6506-sd2
Platform
Catalyst 6500
Memory
227328K
Hardware
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-S2U-MSFC2
2
16 SFM-capable 16 port 1000mb GBIC
WS-X6516-GBIC
3
48 48-port 10/100 mb RJ45
WS-X6148-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.6477.2e3e to 0001.6477.2e3f
3.2
6.1(3)
2 00d0.c0d7.1af4 to 00d0.c0d7.1b03
3.0
6.1(3)
3 000c.30a3.f870 to 000c.30a3.f89f
1.1
5.4(2)
Mod
--1
1
2
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Distributed Forwarding Card
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-DFC
Serial No.
----------SAD055006RH
SAD054302VE
SAL0710A15H
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD055004EC
3.0
Ok
SAD055007FF
2.0
Ok
SAD05380438
2.0
Ok
Table 217 shows the device characteristics for egsj-3640-gk.
Table 217
Device Characteristics for egsj-3640-gk
Hostname
egsj-3640-gk
Platform
Cisco 3640
Memory
125952K
Hardware
Slot 0: NM-1E1R2W
Slot 1: NM-1E1R2W
Slot 2: NM-1FE-TX
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
221
Supplementary Information
Table 218 shows the device characteristics for egsj-3640-v.
Table 218
Device Characteristics for egsj-3640-v
Hostname
egsj-3640-v
Platform
Cisco 3640
Memory
124928K
Hardware
Slot 0: NM-2E2W
WIC 1: WIC-1B-S/T
Slot
Slot
WIC
WIC
1:
2:
0:
1:
NM-1FE-TX
NM-2V
VIC-2FXS
VIC-2FXO
Slot 3: NM-HDV-2T1-48
WIC 0: VWIC-2MFT-T1-DI
Table 219 shows the device characteristics for egbos-7206-w1.
Table 219
Device Characteristics for egbos-7206-w1
Hostname
egbos-7206-w1
Platform
Cisco 7206
Memory
491520K
Hardware
Slot
Slot
Slot
Slot
Slot
0:
1:
2:
3:
4:
C7200-IO-FE-MII/RJ45
PA-FE-TX
PA-FE-TX
PA-FE-TX
PA-2T3+
Table 220 shows the device characteristics for egbos-7206-w2.
Table 220
Device Characteristics for egbos-7206-w2
Hostname
egbos-7206-w2
Platform
Cisco 7206
Memory
491520K
Hardware
Slot
Slot
Slot
Slot
Slot
Slot
Slot
0:
1:
2:
3:
4:
5:
6:
C7200-IO-FE-MII/RJ45
PA-FE-TX
PA-FE-TX
PA-FE-TX
PA-2T3+
PA-FE-TX
PA-MC-2T1
Table 221 shows the device characteristics for egbos-7206-w3.
Table 221
Hostname
Device Characteristics for egbos-7206-w3
egbos-7206-w3
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
222
Supplementary Information
Table 221
Device Characteristics for egbos-7206-w3 (continued)
Platform
Cisco 7206
Memory
245760K
Hardware
Slot
Slot
Slot
Slot
Slot
Slot
1:
2:
3:
4:
5:
6:
PA-FE-TX
PA-1GE
PA-MC-2T1
PA-IMA-T1
PA-8E
PA-4B-U
Table 222 shows the device characteristics for egbos-2651-v1.
Table 222
Device Characteristics for egbos-2651-v1
Hostname
egbos-2651-v1
Platform
Cisco 2651
Memory
124928K
Hardware
Slot 0: Cisco2651 2FE Mainboard
Slot 1: PA-VXC-2TE1
VIC 0: VWIC-2MFT-T1-DI
Table 223 shows the device characteristics for egbos-6506-c1.
Table 223
Device Characteristics for egbos-6506-c1
Hostname
egbos-6506-c1
Platform
Catalyst 6500
Memory
227328K
Hardware
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-S2U-MSFC2
3
16 SFM-capable 16 port 1000mb GBIC
WS-X6516-GBIC
4
48 48 port 10/100 mb RJ-45 ethernet
WS-X6248-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0002.7e38.6f2c to 0002.7e38.6f2d
3.2
6.1(3)
3 00d0.c0d6.b284 to 00d0.c0d6.b293
3.0
6.1(3)
4 00d0.bcef.ef00 to 00d0.bcef.ef2f
1.1
4.2(0.24)VAI
Mod
--1
1
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
Serial No.
----------SAD060100AG
SAD0541045S
SAD03465614
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD0552051B
3.0
Ok
SAD0552068L
1.3
Ok
Table 224 shows the device characteristics for egbos-6506-c2.
Table 224
Device Characteristics for egbos-6506-c2
Hostname
egbos-6506-c2
Platform
Catalyst 6500
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
223
Supplementary Information
Table 224
Device Characteristics for egbos-6506-c2 (continued)
Memory
227328K
Hardware
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-S2U-MSFC2
3
16 SFM-capable 16 port 1000mb GBIC
WS-X6516-GBIC
4
48 48 port 10/100 mb RJ45
WS-X6348-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.6477.2e1a to 0001.6477.2e1b
3.2
6.1(3)
3 00d0.c0d6.b704 to 00d0.c0d6.b713
3.0
6.1(3)
4 000a.417b.1cf0 to 000a.417b.1d1f
6.1
5.4(2)
Mod
--1
1
4
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Inline Power Module
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-PWR
Serial No.
----------SAD0550068D
SAD054103VS
SAL062720UJ
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD055004K9
3.0
Ok
SAD05500702
2.0
Ok
1.0
Ok
Table 225 shows the device characteristics for egwas-7609-w1.
Table 225
Device Characteristics for egwas-7609-w1
Hostname
egwas-7609-w1
Platform
Cisco 7609
Memory
458752K
Hardware
Slot 3: WS-X6182-2PA
PA 0: [T3+ Serial PA]
PA 1: [Enhanced ATM DS3 PA]
Slot 4: WS-X6182-2PA
PA 0: [CT3 single wide PA]
PA 1: PA-POSSW-MM
Table 226 shows the device characteristics for egwas-7609-w2.
Table 226
Device Characteristics for egwas-7609-w2
Hostname
egwas-7609-w2
Platform
Cisco 7609
Memory
458752K
Hardware
Slot 3: WS-X6182-2PA
PA 0: [Enhanced ATM OC3 MM PA]
PA 1: [CE3 PA]
Table 227 shows the device characteristics for egwas-6506-sd1.
Table 227
Device Characteristics for egwas-6506-sd1
Hostname
egwas-6506-sd1
Platform
Catalyst 6500
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
224
Supplementary Information
Table 227
Device Characteristics for egwas-6506-sd1 (continued)
Memory
227328K
Hardware
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-S2U-MSFC2
6
48 SFM-capable 48-port 10/100 Mbps RJ45
WS-X6548-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.c9da.e264 to 0001.c9da.e265
3.2
6.1(3)
6 0001.63d4.cf5a to 0001.63d4.cf89
4.0
6.3(1)
Mod
--1
1
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
Serial No.
----------SAD0601008P
SAD060304UW
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD0552054S
3.0
Ok
SAD0552068P
1.3
Ok
Table 228 shows the device characteristics for egwas-6506-c1.
Table 228
Device Characteristics for egwas-6506-c1
Hostname
egwas-6506-c1
Platform
Catalyst 6500
Memory
227328K
Hardware
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-S2U-MSFC2
2
16 SFM-capable 16 port 1000mb GBIC
WS-X6516-GBIC
6
48 SFM-capable 48-port 10/100 Mbps RJ45
WS-X6548-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.c9da.d5e8 to 0001.c9da.d5e9
3.2
6.1(3)
2 00d0.c0d6.a734 to 00d0.c0d6.a743
3.0
6.1(3)
6 0001.63d4.c74a to 0001.63d4.c779
4.0
6.3(1)
Mod
--1
1
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
Serial No.
----------SAD055006KZ
SAD05410446
SAD060304UC
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD055200SF
3.0
Ok
SAD055101UJ
1.3
Ok
Table 229 shows the device characteristics for egwas-3660-v1.
Table 229
Device Characteristics for egwas-3660-v1
Hostname
egwas-3660-v1
Platform
Cisco 3660
Memory
92160K
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
225
Supplementary Information
Table 229
Hardware
Device Characteristics for egwas-3660-v1 (continued)
Slot 0: C3600 Mother board 2FE(TX) PA, 2 ports
Slot 1: PA-VXC-2TE1
WIC 0: [VWIC-2MFT-T1-DI]
Slot 2: NM-2V
WIC 0: VIC-2FXS
WIC 1: VIC-2FXS
Slot 4: PA-VXC-2TE1
WIC 0: [VWIC-2MFT-T1-DI]
Table 230 shows the device characteristics for egwas-7507-w3.
Table 230
Device Characteristics for egwas-7507-w3
Hostname
egwas-7507-w3
Platform
Cisco 7507
Memory
262144K
Hardware
Slot 0: GEIP controller
PA 0: PA-GE
Slot 1: VIP2 R5K controller
PA 0: PA-FE-TX
PA 1: PA-FE-TX
Slot
Slot
Slot
PA
PA
2:
3:
4:
0:
1:
RSP8
RSP8
VIP4-80 RM7000 controller
PA-MC-8T1
PA-A3-T3
Slot 5: GEIP controller
PA 0: PA-GE
Slot 6: VIP2 controller
PA 0: PA-FE-TX
Table 231 shows the device characteristics for egden-7206-w1.
Table 231
Device Characteristics for egden-7206-w1
Hostname
egden-7206-w1
Platform
Cisco 7206VXR
Memory
491520K
Hardware
Slot
Slot
Slot
Slot
Slot
0:
1:
2:
3:
4:
C7200-IO-FE-MII/RJ45
PA-FE-TX
PA-FE-TX
PA-FE-TX
PA-A3-T3
Table 232 shows the device characteristics for egden-7206-w2.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
226
Supplementary Information
Table 232
Device Characteristics for egden-7206-w2
Hostname
egden-7206-w2
Platform
Cisco 7206VXR
Memory
491520K
Hardware
Slot
Slot
Slot
Slot
Slot
Slot
Slot
0:
1:
2:
3:
4:
5:
6:
C7200-IO-FE-MII/RJ45
PA-FE-TX
PA-FE-TX
PA-H1+
PA-FE-TX
PA-8E
PA-MC-4T1
Table 233 shows the device characteristics for egden-7206-w3.
Table 233
Device Characteristics for egden-7206-w3
Hostname
egden-7206-w3
Platform
Cisco 7206VXR
Memory
491520K
Hardware
Slot
Slot
Slot
Slot
Slot
Slot
0:
1:
2:
3:
4:
5:
C7200-IO-FE-MII/RJ45
PA-FE-TX
PA-1GE
PA-MC-2T1
PA-8E
PA-IMA-T1
Table 234 shows the device characteristics for egden-7507-w4.
Table 234
Device Characteristics for egden-7507-w4
Hostname
egden-7507-w4
Platform
Cisco 7507
Memory
262144K
Hardware
Slot 0: GEIP controller
PA 0: PA-GE
Slot 1: GEIP controller
PA 0: PA-GE
Slot
Slot
PA
PA
2:
4:
0:
1:
RSP8
VIP4-80 RM7000 controller
PA-8E
PA-FE-TX
Slot 5: VIP4-80 RM7000 controller
PA 0: PA-MC-4T1
PA 1: PA-A3-8E1IMA
Table 235 shows the device characteristics for egden-3640-v1.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
227
Supplementary Information
Table 235
Device Characteristics for egden-3640-v1
Hostname
egden-3640-v1
Platform
Cisco 3640
Memory
123904K
Hardware
Slot
Slot
Slot
WIC
WIC
Slot
WIC
0:
1:
2:
0:
1:
3:
0:
NM-2FE2W
NM-1FE-TX
NM-2V
VIC-FXS
VIC-FXO
PA-VXC-2TE1
VWIC-2MFT-T1-DI
Table 236 shows the device characteristics for egden-2600-isdn.
Table 236
Device Characteristics for egden-2600-isdn
Hostname
egden-2600-isdn
Platform
Cisco 2621
Memory
49152K
Hardware
Slot 0: C2621 2FE Mainboard PA
WIC 1: WIC-1B-U-V2
Table 237 shows the device characteristics for egden-6506-c1.
Table 237
Device Characteristics for egden-6506-c1
Hostname
egden-6506-c1
Platform
Catalyst 6500 MSFC
Memory
227328K
Hardware
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-S2U-MSFC2
3
16 SFM-capable 16 port 1000mb GBIC
WS-X6516-GBIC
4
48 48 port 10/100 mb RJ45
WS-X6348-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.c9da.e1fc to 0001.c9da.e1fd
3.2
6.1(3)
3 0001.63d2.a9e2 to 0001.63d2.a9f1
3.0
6.1(3)
4 0005.7481.d138 to 0005.7481.d167
6.0
5.4(2)
Mod
--1
1
4
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Inline Power Module
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-PWR
Serial No.
----------SAD0601008S
SAD0541045G
SAL0501FUW0
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD05520507
3.0
Ok
SAD05520665
1.3
Ok
1.0
Ok
Table 238 shows the device characteristics for egden-6506-c2.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
228
Supplementary Information
Table 238
Device Characteristics for egden-6506-c2
Hostname
egden-6506-c2
Platform
Catalyst 6500 MSFC
Memory
227328K
Hardware
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-S2U-MSFC2
3
16 SFM-capable 16 port 1000mb GBIC
WS-X6516-GBIC
4
48 48 port 10/100 mb RJ45
WS-X6348-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.c9da.e1b4 to 0001.c9da.e1b5
3.2
6.1(3)
3 00d0.c0d6.b7b4 to 00d0.c0d6.b7c3
3.0
6.1(3)
4 0005.7481.d528 to 0005.7481.d557
6.0
5.4(2)
Mod
--1
1
4
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Inline Power Module
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-PWR
Serial No.
----------SAD0601008V
SAD0541042K
SAL0601FZCU
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD05520562
3.0
Ok
SAD055205WS
1.3
Ok
1.0
Ok
Table 239 shows the device characteristics for egden-6506-d1.
Table 239
Device Characteristics for egden-6506-d1
Hostname
egden-6506-d1
Platform
Catalyst 6500 MSFC
Memory
227328K
Hardware
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-S2U-MSFC2
3
16 SFM-capable 16 port 1000mb GBIC
WS-X6516-GBIC
4
48 48 port 10/100 mb RJ45
WS-X6348-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.6415.a51e to 0001.6415.a51f
3.2
6.1(3)
3 0001.63d4.597a to 0001.63d4.5989
3.0
6.1(3)
4 0005.7481.d3a8 to 0005.7481.d3d7
6.0
5.4(2)
Mod
--1
1
4
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Inline Power Module
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-PWR
Serial No.
----------SAD0549072V
SAD0542009L
SAL0601FZCB
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD055000P3
3.0
Ok
SAD0549061J
1.3
Ok
1.0
Ok
Table 240 shows the device characteristics for egden-6506-d2.
Table 240
Device Characteristics for egden-6506-d2
Hostname
egden-6506-d2
Platform
Catalyst 6500 MSFC
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
229
Supplementary Information
Table 240
Device Characteristics for egden-6506-d2 (continued)
Memory
227328K
Hardware
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-S2U-MSFC2
3
16 SFM-capable 16 port 1000mb GBIC
WS-X6516-GBIC
4
48 48 port 10/100 mb RJ45
WS-X6348-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.6415.a7ba to 0001.6415.a7bb
3.2
6.1(3)
3 00d0.c0d6.ac04 to 00d0.c0d6.ac13
3.0
6.1(3)
4 0005.740f.2078 to 0005.740f.20a7
6.0
5.4(2)
Mod
--1
1
4
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Inline Power Module
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-PWR
Serial No.
----------SAD055006KF
SAD054103ZM
SAL0552FTEY
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD055004X7
3.0
Ok
SAD054902U8
2.0
Ok
1.0
Ok
Table 241 shows the device characteristics for egdal-7206-w1.
Table 241
Device Characteristics for egdal-7206-w1
Hostname
egdal-7206-w1
Platform
Cisco 7206VXR
Memory
491520K
Hardware
Slot
Slot
Slot
Slot
Slot
Slot
0:
1:
2:
4:
5:
6:
C7200-IO-FE-MII/RJ45
PA-FE-TX
PA-FE-TX
PA-A3-E3
PA-8E
PA-4T+
Table 242 shows the device characteristics for egdal-7206-w2.
Table 242
Device Characteristics for egdal-7206-w2
Hostname
egdal-7206-w2
Platform
Cisco 7206VXR
Memory
491520K
Hardware
Slot
Slot
Slot
Slot
Slot
Slot
Slot
0:
1:
2:
3:
4:
5:
6:
C7200-IO-FE-MII/RJ45
PA-FE-TX
PA-FE-TX
PA-MC-E3
PA-FE-TX
PA-8E
PA-8E1/120, PA-MC-8E1/120
Table 243 shows the device characteristics for egdal-7206-w3.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
230
Supplementary Information
Table 243
Device Characteristics for egdal-7206-w3
Hostname
egdal-7206-w3
Platform
Cisco 7206VXR
Memory
491520K
Hardware
Slot
Slot
Slot
Slot
Slot
Slot
0:
1:
2:
3:
5:
6:
C7200-IO-FE-MII/RJ45
PA-FE-TX
PA-FE-TX
PA-IMA-E1
PA-4E
PA-MC-2E1-120
Table 244 shows the device characteristics for egdal-7507-w4.
Table 244
Device Characteristics for egdal-7507-w4
Hostname
egdal-7507-w4
Platform
Cisco 7507
Memory
262144K
Hardware
Slot 0: VIP4-80 RM7000 controller
PA 0: PA-A3-T3
PA 1: PA-MC-2T1
Slot 1: GEIP controller
PA 0: PA-1GE
Slot 2: RSP8
Slot 4: GEIP controller
PA 1: PA-1GE
Slot 5: VIP4-80 RM7000 controller
PA 0: PA-FE-TX
PA 1: PA-FE-TX
Slot 6: VIP4-80 RM7000 controller
PA 0: PA-A3-8E1IMA
PA 1: PA-8E
Table 245 shows the device characteristics for egdal-3640-v.
Table 245
Device Characteristics for egdal-3640-v
Hostname
egdal-3640-v
Platform
Cisco 3640
Memory
122880K
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
231
Supplementary Information
Table 245
Hardware
Device Characteristics for egdal-3640-v (continued)
Slot 0: NM-2FE2W
Slot 1: NM-2V
WIC 0: VIC-2FXS
Slot 2: PA-VXC-2TE1
WIC 0: VWIC-2MFT-T1-DI
Slot 3: PA-VXC-2TE1
WIC 0: VWIC-2MFT-T1-DI
Table 246 shows the device characteristics for egdal-3660-w5.
Table 246
Device Characteristics for egdal-3660-w5
Hostname
egdal-3660-w5
Platform
Cisco 3660
Memory
90112K
Hardware
Slot 0: C3600 Mother board 2FE(TX) PA, 2 ports
Slot 2: NM-4E
Table 247 shows the device characteristics for egdal-6506-c2.
Table 247
Device Characteristics for egdal-6506-c2
Hostname
egdal-6506-c2
Platform
Catalyst 6500
Memory
227328K
Hardware
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-S2U-MSFC2
3
8 8 port 1000mb GBIC Enhanced QoS
WS-X6408A-GBIC
4
48 SFM-capable 48-port 10/100 Mbps RJ45
WS-X6548-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0002.7e38.6fc0 to 0002.7e38.6fc1
3.2
6.1(3)
3 0003.32ba.5ea6 to 0003.32ba.5ead
1.3
5.4(2)
4 0001.63d4.be8a to 0001.63d4.beb9
4.0
6.3(1)
Mod
--1
1
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
Serial No.
----------SAD0601006K
SAL05041YR9
SAD060304W4
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD0552058W
3.0
Ok
SAD055205YA
1.3
Ok
Table 248 shows the device characteristics for egla-3640-vw.
Table 248
Device Characteristics for egla-3640-vw
Hostname
egla-3640-vw
Platform
Cisco 3640
Memory
92160K
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
232
Supplementary Information
Table 248
Hardware
Device Characteristics for egla-3640-vw (continued)
Slot
Slot
Slot
WIC
WIC
0:
1:
2:
0:
1:
NM-2CT1-CSU
NM-1FE-TX
NM-2V
VIC-2FXS
VIC-2FXS
Slot 3: NM-2E2W
Table 249 shows the device characteristics for egla-3550-a.
Table 249
Device Characteristics for egla-3550-a
Hostname
egla-3550-a
Platform
Catalyst 3550
Memory
65526K
Hardware
Fast Ethernet
Gigabit Ethernet
Table 250 shows the device characteristics for egphx-7204-vw.
Table 250
Device Characteristics for egphx-7204-vw
Hostname
egphx-7204-vw
Platform
Cisco 7204VXR
Memory
229376K
Hardware
Slot 0: C7200-I/O-GE+E
Slot 3: PA-VXC-2T1E1
Slot 4: PA-MC-2T1
Table 251 shows the device characteristics for egphx-3550-a.
Table 251
Device Characteristics for egphx-3550-a
Hostname
egphx-3550-a
Platform
Catalyst 3550
Memory
65526K
Hardware
Fast Ethernet
Gigabit Ethernet
Table 252 shows the device characteristics for egcs-2651-vw.
Table 252
Device Characteristics for egcs-2651-vw
Hostname
egcs-2651-vw
Platform
Cisco 2651
Memory
125952K
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
233
Supplementary Information
Table 252
Hardware
Device Characteristics for egcs-2651-vw (continued)
Slot 0: C2651 2FE Mainboard PA, 4 ports
WIC 0: FT1
WIC 1: FT1
Slot 1: NM-2V
VIC 0: VIC-2FXS
VIC 1: VIC-2FXS
Table 253 shows the device characteristics for egcs-2950-a.
Table 253
Device Characteristics for egcs-2950-a
Hostname
egcs-2950-a
Platform
Catalyst 2950
Memory
20839K
Hardware
Fast Ethernet
Gigabit Ethernet
Table 254 shows the device characteristics for egsaf-2651-vw.
Table 254
Device Characteristics for egsaf-2651-vw
Hostname
egsaf-2651-vw
Platform
Cisco 2651
Memory
125952K
Hardware
Slot 0: C2651 2FE Mainboard PA, 4 ports
WIC 0: FT1
WIC 1: FT1
Slot 1: NM-2V
VIC 0: VIC-2FXS
VIC 1: VIC-2FXS
Table 255 shows the device characteristics for egsaf-2950-a.
Table 255
Device Characteristics for egsaf-2950-a
Hostname
egsaf-2950-a
Platform
Catalyst 2950
Memory
20839K
Hardware
Fast Ethernet
Gigabit Ethernet
Table 256 shows the device characteristics for egneo-2651-vw.
Table 256
Hostname
Device Characteristics for egneo-2651-vw
egneo-2651-vw
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
234
Supplementary Information
Table 256
Device Characteristics for egneo-2651-vw (continued)
Platform
Cisco 2651
Memory
125952K
Hardware
Slot 0: C2651 2FE Mainboard PA, 4 ports
WIC 0: FT1
WIC 1: BRI U 2091 WAN
Slot 1: NM-2V
VIC 0: VIC-2FXS
VIC 1: VIC-2FXS
Table 257 shows the device characteristics for egneo-2950-a.
Table 257
Device Characteristics for egneo-2950-a
Hostname
egneo-2950-a
Platform
Cisco 2950
Memory
20839K
Hardware
Fast Ethernet
Gigabit Ethernet
Table 258 shows the device characteristics for egaus-3550-a.
Table 258
Device Characteristics for egaus-3550-a
Hostname
egaus-3550-a
Platform
Catalyst 3550
Memory
65526K
Hardware
Fast Ethernet
Gigabit Ethernet
Table 259 shows the device characteristics for egaus-2621-w1.
Table 259
Device Characteristics for egaus-2621-w1
Hostname
egaus-2621-w1
Platform
Cisco 2621
Memory
49152K
Hardware
Slot 0: C2621 2FE Mainboard PA, 3 ports
WIC 1: Serial 1T WAN
Table 260 shows the device characteristics for eghou-3660-vw.
Table 260
Device Characteristics for eghou-3660-vw
Hostname
eghou-3660-vw
Platform
Cisco 3660
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
235
Supplementary Information
Table 260
Device Characteristics for eghou-3660-vw (continued)
Memory
121856K
Hardware
Slot
Slot
WIC
WIC
0:
1:
0:
1:
C3600 Mother board 2FE(TX) PA, 2 ports
NM-2V
VIC-2FXS
VIC-2FXS
Slot 3: NM-1CE1B
Slot 5: PA-VXC-2TE1
WIC 0: VWIC-2MFT-T1-DI
Slot 6: NM-2CT1-CSU
Table 261 shows the device characteristics for eghou-3550-a.
Table 261
Device Characteristics for eghou-3550-a
Hostname
eghou-3550-a
Platform
Catalyst 3550
Memory
65526K
Hardware
Fast Ethernet
Gigabit Ethernet
Table 262 shows the device characteristics for egpit-3640-vw.
Table 262
Device Characteristics for egpit-3640-vw
Hostname
egpit-3640-vw
Platform
Cisco 3640
Memory
124928K
Hardware
Slot 0: NM-2E2W
WIC 0: FT1
WIC 1: FT1
Slot 1: NM-1FE-TX
Slot 2: NM-2V
WIC 0: VIC-2FXS
Slot 3: PA-VXC-2TE1
WIC 0: VWIC-2MFT-T1-DI
Table 263 shows the device characteristics for egpit-3550-a.
Table 263
Device Characteristics for egpit-3550-a
Hostname
egpit-3550-a
Platform
Catalyst 3550
Memory
65526K
Hardware
Fast Ethernet
Gigabit Ethernet
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
236
Supplementary Information
Table 264 shows the device characteristics for egmia-6506-a1.
Table 264
Device Characteristics for egmia-6506-a1
Hostname
egmia-6506-a1
Platform
Catalyst 6500
Memory
458752K
Hardware
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-SUP2-2GE
3
48 48 port 10/100 mb RJ45
WS-X6348-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.c9da.d814 to 0001.c9da.d815
3.2
6.1(3)
3 0005.740e.6af4 to 0005.740e.6b23
6.0
5.4(2)
Mod
--1
1
3
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Inline Power Module
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-PWR
Serial No.
----------SAD055101GV
SAL0552FQYX
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD055004EJ
3.0
Ok
SAD0550079A
2.0
Ok
1.0
Ok
Table 265 shows the device characteristics for egmia-6506-a2.
Table 265
Device Characteristics for egmia-6506-a2
Hostname
egmia-6506-a2
Platform
Catalyst 6500
Memory
458752K
Hardware
Mod Ports Card Type
Model
--- ----- -------------------------------------- -----------------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-SUP2-2GE
3
48 48 port 10/100 mb RJ45
WS-X6348-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0002.7e38.66b0 to 0002.7e38.66b1
3.2
6.1(3)
3 0005.7481.d648 to 0005.7481.d677
6.0
5.4(2)
Mod
--1
1
3
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Inline Power Module
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-PWR
Serial No.
----------SAD054909R0
SAL0601FZDZ
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD055004WE
3.0
Ok
SAD055007CK
2.0
Ok
1.0
Ok
Table 266 shows the device characteristics for egmia-7206-w1.
Table 266
Device Characteristics for egmia-7206-w1
Hostname
egmia-7206-w1
Platform
Cisco 7206
Memory
245760K
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
237
Supplementary Information
Table 266
Hardware
Device Characteristics for egmia-7206-w1 (continued)
Slot
Slot
Slot
Slot
1:
2:
4:
6:
PA-FE-TX
PA-FE-TX
PA-8E
PA-A3-T3
Table 267 shows the device characteristics for egmia-3640-vw2.
Table 267
Device Characteristics for egmia-3640-vw2
Hostname
egmia-3640-vw2
Platform
Cisco 3640
Memory
57344K
Hardware
Slot 0: NM-2FE2W
Slot 1: NM-2FE2W
WIC 1: FT1
Slot 2: NM-2V
WIC 0: VIC-2FXS
Slot 3: PA-VXC-2TE1
WIC 0: VWIC-2MFT-T1-DI
Table 268 shows the device characteristics for egny-3745-vw.
Table 268
Device Characteristics for egny-3745-vw
Hostname
egny-3745-vw
Platform
Cisco 3745
Memory
118784K
Hardware
Slot
WIC
WIC
WIC
0:
0:
1:
2:
C3745 Mother board 2FE(TX) - 3W Port adapter, 2 ports
FT1
FT1
BRI U 2091 WAN
Slot 1: NM-2V
WIC 0: VIC-2FXS
WIC 1: VIC-2FXS
Table 269 shows the device characteristics for egny-3550-a.
Table 269
Device Characteristics for egny-3550-a
Hostname
egny-3550-a
Platform
Catalyst 3550
Memory
65526K
Hardware
Fast Ethernet
Gigabit Ethernet
Table 270 shows the device characteristics for egarl-3640-w1.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
238
Supplementary Information
Table 270
Device Characteristics for egarl-3640-w1
Hostname
egarl-3640-w1
Platform
Cisco 3640
Memory
69632K
Hardware
Slot 0: AIM Carrier PA
AIM 0: [NM-VPN/MP]
Slot 1: NM-2FE2W
WIC 0: FT1
Slot 2: NM-4E
Table 271 shows the device characteristics for egboc-1760-w1.
Table 271
Device Characteristics for egboc-1760-w1
Hostname
egboc-1760-w1
Platform
Cisco 1760
Memory
59427K
Hardware
Slot 0: C1760 1FE VE 4SLOT DV Mainboard PA, 3 ports
WIC 0: WIC-2T
Slot 3: MOD1700-VPN
Table 272 shows the device characteristics for egsj-5505-sa1.
Table 272
Device Characteristics for egsj-5505-sa1
Hostname
egsj-5505-sa1
Platform
Catalyst 5500
Memory
32768K
Hardware
Mod Port Model
Serial # Versions
--- ---- ---------- --------- -----------1
2
WS-X5550
027745488 Hw : 1.2
Fw : 5.1(1)
Fw1: 5.2(1)
Sw : 6.4(3)
2
24
WS-X5013
008673376 Hw : 1.3
Fw : 2.3(1)
Sw : 6.4(3)
3
24
WS-X5224
011683516 Hw : 1.4
Fw : 3.1(1)
Sw : 6.4(3)
5
9
WS-X5410
014966283 Hw : 1.0
Fw : 4.2(1)
Fw1: 4.2(1)
Sw : 5.1(1)
Table 273 shows the device characteristics for egsj-5505-sa2.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
239
Supplementary Information
Table 273
Device Characteristics for egsj-5505-sa2
Hostname
egsj-5505-sa2
Platform
Catalyst 5500
Memory
65536K
Hardware
Mod Port Model
Serial # Versions
--- ---- ---------- --------- ----------1
2
WS-X5530
013386213 Hw : 3.2
Fw : 3.1.2
Fw1: 4.4(1)
Sw : 6.4(3)
WS-F5531
013379831 Hw : 1.0
WS-U5534
027541666 Hw : 1.3
2
24
WS-X5234
017403319 Hw : 1.0
Fw : 4.5(2)
Sw : 6.4(3)
5
9
WS-X5410
021601033 Hw : 1.1
Fw : 4.2(5)
Fw1: 4.2(5)
Sw : 6.3(2)
Table 274 shows the device characteristics for egsj-6506-sa3.
Table 274
Device Characteristics for egsj-6506-sa3
Hostname
egsj-6506-sa3
Platform
Catalyst 6500
Memory
131072K
Hardware
Mod Port Model
Serial #
Versions
--- ---- ------------------- ----------- ----------1
2
WS-X6K-SUP2-2GE
SAD050608J5 Hw : 2.5
Fw : 6.1(4)
Fw1: 6.1(3)
Sw : 7.6(1)
Sw1: 7.6(1)
WS-X6K-SUP2-2GE
SAD050608J5 Hw : 2.5
Sw :
2
48
WS-X6148-RJ-45
SAL06417EAQ Hw : 1.1
Fw : 5.4(2)
Sw : 7.6(1)
Table 275 shows the device characteristics for egsj-4003-b1a1.
Table 275
Device Characteristics for egsj-4003-b1a1
Hostname
egsj-4003-b1a1
Platform
Catalyst 4000
Memory
65536K
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
240
Supplementary Information
Table 275
Hardware
Device Characteristics for egsj-4003-b1a1 (continued)
Mod Port Model
Serial #
Versions
--- ---- ------------------ -------------------- ------------1
0
WS-X4012
JAB035002QN
Hw : 2.0
Gsp: 7.6(1.0)
Nmp: 7.6(1)
2
6
WS-X4306
JAE044301F0
Hw : 2.0
3
48
WS-X4148-RJ45V
JAE060603CU
Hw : 1.6
Table 276 shows the device characteristics for egsj-5505-b1a2.
Table 276
Device Characteristics for egsj-5505-b1a2
Hostname
egsj-5505-b1a2
Platform
Catalyst 5500
Memory
65536K
Hardware
Mod Port Model
Serial # Versions
--- ---- ---------- --------- ----------1
2
WS-X5530
008949810 Hw : 1.8
Fw : 3.1.2
Fw1: 4.1(1)
Sw : 6.4(3)
WS-F5520
008923200 Hw : 1.1
WS-U5534
012143987 Hw : 1.0
2
24
WS-X5225R 013377174 Hw : 3.1
Fw : 4.3(1)
Sw : 6.4(3)
Table 277 shows the device characteristics for egsj-6506-b1a3.
Table 277
Device Characteristics for egsj-6506-b1a3
Hostname
egsj-6506-b1a3
Platform
Catalyst 6500
Memory
mmm
Hardware
Mod Port Model
Serial #
Versions
--- ---- ------------------- ----------- -----------1
2
WS-X6K-SUP2-2GE
SAD055101G4 Hw : 3.2
Fw : 6.1(4)
Fw1: 6.1(3)
Sw : 7.6(1)
Sw1: 7.6(1)
WS-X6K-SUP2-2GE
SAD055101G4 Hw : 3.2
Sw :
2
48
WS-X6148-RJ-45
SAL06417E8Y Hw : 1.1
Fw : 5.4(2)
Sw : 7.6(1)
Table 278 shows the device characteristics for egsj-4006-b2a1.
Table 278
Hostname
Device Characteristics for egsj-4006-b2a1
egsj-4006-b2a1
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
241
Supplementary Information
Table 278
Device Characteristics for egsj-4006-b2a1 (continued)
Platform
Catalyst 4000
Memory
65536K
Hardware
Mod Port Model
Serial #
Versions
--- ---- ------------------ -------------------- -----------1
2
WS-X4013
JAB054804FA
Hw : 3.2
Gsp: 7.6(1.0)
Nmp: 7.6(1)
2
34
WS-X4232
JAB034900XA
Hw : 2.0
3
48
WS-X4148-RJ45V
JAE060603CJ
Hw : 1.6
5
1
WS-X4604-GWY
JAB0446053F
Hw : 1.8
Table 279 shows the device characteristics for egsj-6506-b2a2.
Table 279
Device Characteristics for egsj-6506-b2a2
Hostname
egsj-6506-b2a2
Platform
Catalyst 6500
Memory
131072K
Hardware
Mod Port Model
Serial #
Versions
--- ---- ------------------- ----------- -------------------------------------1
2
WS-X6K-SUP2-2GE
SAD05380B2W Hw : 3.2
Fw : 6.1(4)
Fw1: 6.1(3)
Sw : 7.6(1)
Sw1: 7.6(1)
WS-X6K-SUP2-2GE
SAD05380B2W Hw : 3.2
Sw :
2
48
WS-X6348-RJ-45
SAL0552FUJ0 Hw : 6.0
Fw : 5.4(2)
Sw : 7.6(1)
WS-F6K-VPWR
Hw : 1.0
Sw : 1.0
Table 280 shows the device characteristics for egbos-6506-a1.
Table 280
Device Characteristics for egbos-6506-a1
Hostname
egbos-6506-a1
Platform
Catalyst 6000
Memory
131072K
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
242
Supplementary Information
Table 280
Hardware
Device Characteristics for egbos-6506-a1 (continued)
Mod Port Model
Serial #
Versions
--- ---- ------------------- ----------- ----------1
2
WS-X6K-SUP2-2GE
SAD05520191 Hw : 3.2
Fw : 6.1(4)
Fw1: 6.1(3)
Sw : 7.6(1)
Sw1: 7.6(1)
WS-X6K-SUP2-2GE
SAD05520191 Hw : 3.2
Sw :
3
48
WS-X6348-RJ-45
SAL0601FZB5 Hw : 6.0
Fw : 5.4(2)
Sw : 7.6(1)
WS-F6K-VPWR
Hw : 1.0
Sw : 1.0
Table 281 shows the device characteristics for egbos-4006-a2.
Table 281
Device Characteristics for egbos-4006-a2
Hostname
egbos-4006-a2
Platform
Catalyst 4000
Memory
131072K
Hardware
Mod Port Model
Serial #
Versions
--- ---- ------------------ -------------------- -----------1
2
WS-X4013
00000000000
Hw : 0.0
Gsp: 7.6(1.0)
Nmp: 7.6(1)
3
48
WS-X4148-RJ45V
JAE060603CE
Hw : 1.6
5
34
WS-X4232
JAB024100BQ
Hw : 1.0
Table 282 shows the device characteristics for egbos-4006-a3.
Table 282
Device Characteristics for egbos-4006-a3
Hostname
egbos-4006-a3
Platform
Catalyst 4000
Memory
65536K
Hardware
Mod Port Model
Serial #
Versions
--- ---- ------------------ -------------------- --------------------------------1
2
WS-X4013
JAB0522081G
Hw : 1.5
Gsp: 7.6(1.0)
Nmp: 7.6(1)
2
48
WS-X4148-RJ
JAB04470736
Hw : 0.1
3
48
WS-X4148-RJ45V
JAE0606032W
Hw : 1.6
4
1
WS-X4604-GWY
JAB04460554
Hw : 1.8
Table 283 shows the device characteristics for egwas-6505-c2-sup2.
Table 283
Device Characteristics for egwas-6505-c2-sup2
Hostname
egwas-6505-c2-sup2
Platform
Catalyst 6500
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
243
Supplementary Information
Table 283
Device Characteristics for egwas-6505-c2-sup2 (continued)
Memory
262144K
Hardware
Mod Port Model
Serial #
Versions
--- ---- ------------------- ----------- -------------------------------------1
2
WS-X6K-S2U-MSFC2
SAD055106C1 Hw : 3.2
Fw : 6.1(4)
Fw1: 6.1(3)
Sw : 7.6(1)
Sw1: 7.6(1)
WS-X6K-S2U-MSFC2
SAD055106C1 Hw : 3.2
Sw :
2
16
WS-X6516-GBIC
SAD054606WD Hw : 3.0
Fw : 6.1(3)
Sw : 7.6(1)
3
8
WS-X6608-T1
SAD064201DW Hw : 1.3
Fw : 5.4(2)
Sw : 7.6(1)
HP1: D00403010034; DSP1: D005L031 (3.6.14)
HP2: D00403010034; DSP2: D005L031 (3.6.14)
HP3: D004I3A0; DSP3: D005H300 (3.6.12)
HP4: D004I3A0; DSP4: D005H300 (3.6.12)
HP5: D004I3A0; DSP5: D005H300 (3.6.12)
HP6: D004I3A0; DSP6: D005H300 (3.6.12)
HP7: D004I3A0; DSP7: D005H300 (3.6.12)
HP8: M0010004; DSP8: M002E031 (3.3.2)
4
24
WS-X6624-FXS
SAD064100PG Hw : 3.2
Fw : 5.4(2)
Sw : 7.6(1)
HP : A00203010027; DSP : A003L031 (3.6.14)
5
48
WS-X6348-RJ-45
SAL06282SVW Hw : 6.1
Fw : 5.4(2)
Sw : 7.6(1)
WS-F6K-VPWR
Hw : 1.0
Sw : 1.0
6
48
WS-X6548-RJ-45
SAD060304JX Hw : 4.0
Fw : 6.3(1)
Sw : 7.6(1)
15 1
WS-F6K-MSFC2
SAD05510786 Hw : 2.0
Fw : 12.1(13)E9
Sw : 12.1(13)E9
Table 284 shows the device characteristics for egwas-6505-c2-msfc2.
Table 284
Device Characteristics for egwas-6505-c2-msfc2
Hostname
egwas-6505-c2-msfc2
Platform
Catalyst 6500
Memory
458752K
Hardware
19 Virtual Ethernet/IEEE 802.3 interfaces
Table 285 shows the device characteristics for egden-6506-a1.
Table 285
Hostname
Device Characteristics for egden-6506-a1
egden-6506-a1
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
244
Supplementary Information
Table 285
Device Characteristics for egden-6506-a1 (continued)
Platform
Catalyst 6500
Memory
131072K
Hardware
Mod Port Model
Serial #
Versions
--- ---- ------------------- ----------- ------------1
2
WS-X6K-SUP2-2GE
SAD055003N7 Hw : 3.2
Fw : 6.1(4)
Fw1: 6.1(3)
Sw : 7.6(0.57)
Sw1: 7.6(0.56)
WS-X6K-SUP2-2GE
SAD055003N7 Hw : 3.2
Sw :
4
48
WS-X6348-RJ-45
SAL0601FY3B Hw : 6.0
Fw : 5.4(2)
Sw : 7.6(0.56)
WS-F6K-VPWR
Hw : 1.0
Sw : 1.0
Table 286 shows the device characteristics for egden-4003-a2.
Table 286
Device Characteristics for egden-4003-a2
Hostname
egden-4003-a2
Platform
Catalyst 4000
Memory
65536K
Hardware
Mod Port Model
Serial #
Versions
--- ---- ------------------ -------------------- ------------1
0
WS-X4012
JAB034400RY
Hw : 2.0
Gsp: 7.6(0.57)
Nmp: 7.6(0.57)
2
48
WS-X4148-RJ
JAB03510044
Hw : 2.3
3
34
WS-X4232
JAB0343040N
Hw : 2.0
Table 287 shows the device characteristics for egden-4506-a3.
Table 287
Device Characteristics for egden-4506-a3
Hostname
egden-4506-a3
Platform
Catalyst 4500
Memory
262144K
Hardware
48 FastEthernet/IEEE 802.3 interfaces
3 Gigabit Ethernet/IEEE 802.3 interfaces
Table 288 shows the device characteristics for egaus-2621-w1.
Table 288
Device Characteristics for egaus-2621-w1
Hostname
egaus-2621-w1
Platform
Cisco 2621
Memory
49152K
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
245
Supplementary Information
Table 288
Device Characteristics for egaus-2621-w1 (continued)
Hardware
Slot 0: C2621 2FE Mainboard Port adapter, 3 ports
WIC 1: Serial 1T WAN daughter card
Table 289 shows the device characteristics for egaus-3550-a.
Table 289
Device Characteristics for egaus-3550-a
Hostname
egaus-3550-a
Platform
Catalyst 3550
Memory
65526K
Hardware
12 Gigabit Ethernet/IEEE 802.3 interfaces
Table 290 shows the device characteristics for egarl-3640-w1.
Table 290
Device Characteristics for egarl-3640-w1
Hostname
egarl-3640-w1
Platform
Cisco 3640
Memory
69632K
Hardware
Slot 0: AIMCarrier Port adapter
Slot 1: NM-2FE2W Port adapter, 3 ports
Slot 2: Ethernet Port adapter, 4 ports
Table 291 shows the device characteristics for egboc-1760-w1.
Table 291
Device Characteristics for egboc-1760-w1
Hostname
egboc-1760-w1
Platform
Cisco 1760
Memory
60124K
Hardware
Slot 0: C1760 1FE VE 4SLOT DV Mainboard Port adapter, 3 ports
WIC 0: WIC-2T Serial 2T (12in1)
Slot 3: MOD1700-VPN Virtual Private Network (VPN) Module Port adapter, 1 port
See Also
For additional information, refer to the following Cisco documents:
Resource or Publication Title
Location
Cisco IOS Release 12.3 Configuration Guides and http://www.cisco.com/univercd/cc/td/doc/product
Command References
/software/ios123/123cgcr/index.htm
Release Notes for Cisco IOS Release 12.3
http://www.cisco.com/univercd/cc/td/doc/product
/software/ios123/123relnt/index.htm
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
246
Supplementary Information
CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, the Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing,
FormShare, iQ Breakthrough, iQ FastTrack, the iQ Logo, iQ Net Readiness Scorecard, Networking Academy, ScriptShare, SMARTnet, TransPath,
and Voice LAN are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, The Fastest Way to Increase Your
Internet Quotient, 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, LightStream, MGX, MICA, the Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX,
Registrar, SlideCast, StrataView Plus, Stratm, SwitchProbe, TeleRouter, 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. (0301R)
Copyright © 2003, Cisco Systems, Inc.
All rights reserved.
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
247
Supplementary Information
Cisco IOS Profiled Release 12.2(16b)M, 12.1(13)E9, 12.2(15)T5, and Catalyst OS 7.6(1) System Testing for Global Enterprise Customers
248