Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5,
and 12.3(11)T2, and CatOS Releases 12.2(18)SXD2
and 12.2(18)EW2 Testing for Enterprise Global
Customers
Version History
Version Number
Date
Notes
1
December 1, 2004
This document was created.
2
December 17, 2004 Figure 1 was revised.
Executive Summary
This document describes the nEverest enterprise global testing topology, the plans for testing that focus
on IP routing with the Enhanced Interior Gateway Routing Protocol (EIGRP), Border Gateway Protocol
(BGP), and Open Shortest Path First (OSPF) routing protocols; with various Layer 2 LAN switching
features such as UplinkFast and PortFast, multicast, quality of service (QoS), Voice over IP (VoIP), and
IP Security (IPSec); and with network management systems (NMS).
This document also provides a summary of the test results, including relevant defect numbers. The
execution of this test plan verified the functionality, system, reliability, and performance requirements
as defined by the nEverest aggregated requirements document in an enterprise global topology
environment.
The following test types were conducted for each of the test configurations described in this document
and the nEverest: Enterprise Global Test Plan—Phase 4:
•
Functionality testing—Verified basic network operation and its configurability and stability in a
controlled environment.
•
System testing—Simulated a realistic customer environment by configuring defined features under
test and executing all Cisco IOS software functionality simultaneously with planned various levels
of traffic generation. Negative test cases were also executed during the system test.
•
Reliability testing—Tested the environment that was set up and executed in the system test for
150 hours, to ensure that no new critical or severe defects were found.
This document contains the following main sections:
•
About Enterprise Global Testing, page 2
•
nEverest Enterprise Global Testing Environment, page 2
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
1
About Enterprise Global Testing
•
Test Results Summary, page 12
•
Functionality Testing, page 13
•
System Testing, page 15
•
Reliability Testing, page 16
•
Test Case Descriptions, page 17
•
Supplementary Information, page 38
About Enterprise Global Testing
This section contains the following information:
•
About the nEverest Program, page 2
•
Targeted Software for Phase 4 Testing, page 2
About the nEverest Program
The nEverest program is a quality initiative that focuses on satisfying customer requirements by
coordinating Cisco IOS release system-level and reliability testing under realistic conditions. The
nEverest testing uses the following five profiles, the designs of which are based solely on customer
requirements:
•
Enterprise global
•
Enterprise financial
•
Service provider/IP backbone
•
Service provider/Multiprotocol Label Switching (MPLS) backbone
•
Broadband
Targeted Software for Phase 4 Testing
This document provides a summary of the system-level and reliability testing completed atop the profile
for the specified release. Following are the target releases that were tested in nEverest phase 4 for
enterprise global:
•
Cisco IOS Release 12.3(12)fc2
•
Cisco IOS Release 12.3(8)T5
•
Cisco IOS Release 12.3(11)T2
•
CatOS Release 12.2(18)EW2 for Cisco Catalyst 4000 and 4500 series switches
•
CatOS Release 12.2(18)SXD2 for Cisco Catalyst 6500 and 7600 series switches
nEverest Enterprise Global Testing Environment
This section provides an overview of the nEverest enterprise global testing environment, and includes
the following information:
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
2
nEverest Enterprise Global Testing Environment
•
Enterprise Global Test Program Goals, page 3
•
Enterprise Global Topology, page 3
•
Enterprise Global Tests and Topologies Matrix, page 9
Enterprise Global Test Program Goals
The primary goal of the nEverest enterprise global test program is to harden a specific release of the
Cisco IOS software for large enterprise global campuses. The testing consists of defining and executing
a series of functionality, system, and reliability test cases in large enterprise global campuses. A
Cisco IOS software release is considered hardened once it has been subjected to the testing defined in
the nEverest aggregated requirements document and meets exit criteria defined for this project in the
nEverest: Enterprise Global Test Plan—Phase 4.
Enterprise Global Topology
Figure 1 shows the high-level topology for the phase 4 enterprise global network.
Figure 1
Representative Enterprise Global Network Topology
FE
GE
HSSI(P2P)
POS OC3(P2P)
ATM OC3
T1(P2P)
ATM/FR (nx64k)
E1(P2P)
ATM E1
T3(P2P)
ATM T3
E3(P2P)
ATM E3
ATM T3 (P2P)
Enterprise Global Overview Topology
egbos-7206-w2
egbos-7206-w1
egbos-7206-w3
egsj-7609-w2
egwas-7609-w1
egwas-7609-w2
egsj-7609-w1
egsj-7206-w3
egden-7206-w3
egsj-7206-w3
egwas-7507-w3
egdal-7206-w2
egden-7206-w1
egdal-7206-w1
Denver
egden-7507-w4 egden-7206-w3
egdal-7206-w3
egdal-7507-w4
FR/FR
ISDN
egla-3745-vw
egphx-7204-vw
Los Angeles
egsfo-3745-w1
egsf
egsfo-3845-w1
o-3745-w1
Los Angeles 2
Phoenix
egcs-2651-vw
Colorado
Springs
egsfo-3745-w1
egsfo-3845-w1
o-3745-w1 egoak-3640-w1
Phoenix 2
Oakland
egsaf-2651-vw
Sante Fe
egny-3620-vw
egmia-3640-vw2 egny-3620-vw
eghou-3660-vw egpit-3745-vw1
egneo-2651-vw
egmia-7206-w1
egaus-2651-vw
New Orleans
o-3745-w1
egsan-2611xm-w1 egsfo-3745-w1
San Diego
San Francisco
Austin
Houston
Pittsburgh
Miami
egsfo-3745-w1
egsfo-3845-w1
o-3745-w1
egsfo-3745-w1
egsf
egsfo-3845-w1
o-3745-w1
Houston 2
Pittsburgh 2
New York
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
3
nEverest Enterprise Global Testing Environment
The phase 4 enterprise global testing topology consisted of 5 multilayer-design campuses (2 large
campuses with data centers and 3 regional campuses), plus 17 remote campuses, as follows:
•
San Jose Campus
•
Boston Campus
•
Washington, D.C. Campus
•
Denver Campus
•
Dallas Campus
Remote Campuses are: Arlington, Austin, Boca Raton, Colorado Springs, Houston, Houston 2, Los
Angeles, Los Angeles 2, Miami, New Orleans, New York, Phoenix, Phoenix 2, Pittsburgh, Pittsburgh 2,
Santa Fe, San Diego, Oakland, and San Francisco.
Refer to Figure 1 for the campus descriptions in the following sections.
San Jose Campus
The San Jose campus test bed represented a large enterprise headquarters campus with a data center.
Hardware Description
•
Two Cisco 7609 Optical Services Router (OSR) WAN aggregation routers connected to the other
enterprise global sites and to the Internet service provider (ISP). One Cisco 7206 VXR router WAN
aggregation router connected to remote sites.
•
Multiple types of high-speed WAN links were used: Packet over SONET (POS) optical carrier
(OC)-3, ATM-OC-3 , T1, T3, and ATM-T3.
•
The core of the campus consisted of four Cisco Catalyst 6509 switches with dual Multilayer Switch
Feature Card 2 (MSFC2) and Policy Feature Card 2 (PFC2).
•
High-speed core Layer 3 Gigabit Ethernet (GE) links were used to connect two user buildings and
one data center building.
•
Within one building, two Cisco Catalyst 6506 switches were used as distribution layer switches, and
multiple switches such as the Catalyst 4006, Catalyst 5505, and Catalyst 6506 models were used as
access layer switches. In another building, two Cisco Catalyst 4500 switches, one of which was
using the SUP2+, were used as distribution layer switches; multiple Cisco Catalyst switches such as
the Catalyst 4006 and Catalyst 6506 models were used as access layer switches.
•
A separate Cisco 3640 router was used as a VoIP voice gateway, and a Cisco 3745 router was used
as a gatekeeper.
Routing Description
EGP
•
ISP connections on egsj-7609-w2
•
External BGP (eBGP) connections to egbos-7206-w1, egwas-7609-w1, egdal-7206-w1, and
egden-7206-w2
•
Internal BGP (iBGP) connection to egsj-7609-w1 and egsj-7609-w2
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
4
nEverest Enterprise Global Testing Environment
IGP
•
EIGRP autonomous system 1
•
EIGRP within the entire campus, and extending to Los Angeles via egsj-7206-w3
•
EIGRP authentication on the WAN link to the Los Angeles campus, and within the distribution layer
of SJB1
Boston Campus
The Boston campus test bed represented a small enterprise campus located in a North American region.
Hardware Description
•
The WAN routers connecting to the other enterprise global sites and to the Internet consisted of two
Cisco 7206 VXR NPE400 WAN routers, one Cisco 7206 VXR NPE-G1 running serial peer-to-peer
and ATM links, and one Cisco 2800 router. The campus also consisted of a GE and a Fast Ethernet
(FE) LAN.
•
There were two Cisco Catalyst 6506 switches, each with a SUP720 processor in the core, and which
also provided distribution layer functionality.
•
One Cisco Catalyst 6506 and two Cisco Catalyst 4006 switches (one with a Cisco 4604 Gateway
module for T1 and FXS voice testing, and one using the SUP2+), made up the access layer.
•
A Cisco 2651 router was used as a VoIP voice gateway, which registered into a gatekeeper located
at San Jose headquarters and placed real VoIP calls to other gateways located at different campuses.
Routing Description
EGP
•
ISP connections on egbos-7206-w3
•
eBGP connections on egsj-7609-w2 and egwas-7609-w1
•
iBGP connections on egbos-7206-w1 and egbos-7206-w2
IGP
•
EIGRP autonomous system 2
•
EIGRP within the entire campus, and extending to the New York and Pittsburgh via egbos-7206-w3
•
EIGRP authentication on the WAN link to Pittsburgh and New York
Washington, D.C. Campus
The Washington, D.C. campus test bed represented a medium-sized enterprise campus located in the
eastern United States region. The test bed simulated one of the large enterprise headquarter campuses
with a data center.
Hardware Description
•
Two Cisco 7609 OSR routers functioned as campus WAN routers. These two routers provided
connection to the Internet and other large campuses in this test bed through POS OC-3, ATM OC-3,
ATM-T3, E3, T3, and T1 WAN links.
•
Two Cisco Catalyst 6506 switches, each with an MSFC2 or PFC2, functioned as core routers.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
5
nEverest Enterprise Global Testing Environment
•
A Cisco 3745 router functioned as a VoIP voice gateway. Real VoIP calls were placed to other
gateways located at different campuses.
•
One Cisco Catalyst 6506 switch functioned as the distribution router for a data center.
•
A Cisco 7507 router functioned as the WAN aggregation router for the many remote sites connected
to the campus through ATM or Frame Relay links with bandwidths less than T1 speed. High-speed
Layer 3 GE links were used to connect these devices, with sufficient redundancy.
Routing Description
EGP
•
ISP connections on egwas-7609-w1
•
eBGP connections on egsj-7609-w1, egsj-7609-w2, egbos-7206-w2, egden-7206-w1, and
egdal-7206-w2
•
iBGP connections on egwas-7609-w1 and egwas-7609-w2
IGP
•
EIGRP autonomous system 3
•
EIGRP within the entire campus, and extending to Miami, Pittsburgh, and New York via
egwas-7505-w3
•
EIGRP authentication on the WAN link to Miami, Pittsburgh, and New York
Denver Campus
The Denver test bed represented a medium-sized enterprise campus located in a North American region.
Hardware Description
•
The WAN aggregation routers connecting to the other enterprise global campuses and to the Internet
consisted of two Cisco 7206 NPE-G1 routers, one Cisco 7206 VXR NPE400 router, and a Cisco
7507 RSP8 router running ATM-T1/T3, peer-to-peer T1, High-Speed Serial Interface (HSSI),
ATM/Frame Relay, or Frame Relay-Frame Relay links, with ISDN on a Cisco 2600 router as a
backup.
•
The GE/FE backbone core layer consisted of two Cisco Catalyst 6506 switches with MSFC2 and
PFC2 cards, and a distribution layer consisted of two Catalyst 6506 switches, each with an MSFC1
card.
•
The campus also contained one Cisco Catalyst 6506 switch, one Cisco Catalyst 4506 switch with a
Cisco 4604 gateway module for T1 and FXS voice testing, and one Cisco Catalyst 4003 switch that
built the access layer.
•
A Cisco 3640 router was used as a VoIP voice gateway and placed real VoIP calls to other gateways
located at different campuses.
Routing Description
EGP
•
eBGP connections on egsj-7609-w1 and egwas-7609-w1
•
iBGP connections on egden-7206-w1 and egden-7206-w2
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
6
nEverest Enterprise Global Testing Environment
IGP
•
EIGRP autonomous system 4
•
EIGRP within the entire campus, extending to Colorado Springs, Houston, New Orleans, Santa Fe,
and Phoenix via egden-7206-w3 and egden-7507-w4
•
EIGRP authentication on WAN link to Colorado Springs, Houston, New Orleans, Santa Fe, and
Phoenix
Dallas Campus
The Dallas campus test bed represented a medium-sized enterprise campus located in a European region.
Global application servers were located at this campus serving the smaller and remote campuses.
Remote campuses connected to the Dallas campus are: Austin, Arlington, Boca Raton, and Houston.
Austin, Arlington, and Boca Raton were added to the Dallas campus for security testing in this phase 4
test.
Hardware Description
•
The WAN routers connecting to the other enterprise global sites and to the Internet consisted of
three Cisco 7206 VXR NPE400 routers and a Cisco 7507 RSP8 router running ATM and PPP on the
WANs.
•
The campus also consisted of a GE and FE LAN connected to two Cisco Catalyst 6506 switches,
each with an MSFC2 or PFC2 card.
•
A Cisco 3640 router was used as a VoIP voice gateway and placed real VoIP calls to other gateways
located at different campuses.
Routing Description
EGP
•
ISP connections on egdal-7206-w1
•
eBGP connections on egsj-7609-w2 and egwas-7609-w2
•
iBGP connections on egdal-7206-w1 and egdal-7206-w2
IGP
•
OSPF within the entire campus, and extending to Miami, Santa Fe, and Colorado Springs via
egdal-7505-w4
•
OSPF authentication on the WAN link to Miami, Santa Fe, and Colorado Springs
Remote Campuses
The remote campuses consisted of only a single-branch layer.
Hardware Description
•
Most of the remote network devices consisted of Cisco Catalyst 2950, Cisco Catalyst 3550, and
Cisco Catalyst 6506 switches, and Cisco 1760, Cisco 2651, Cisco 2800, Cisco 3640, Cisco 3660,
Cisco 3745, Cisco 3800, and Cisco 7206 routers.
•
The Miami and Phoenix remote campuses had GE links to the WAN router.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
7
nEverest Enterprise Global Testing Environment
•
Two Cisco Catalyst 6506 switches, each with an MSFC2 or PFC2 card and located in Miami,
performed both Layer 2 and Layer 3 functions.
•
The remaining remote campuses (Los Angeles, New York, Santa Fe, Colorado Springs, Houston,
Pittsburgh, New Orleans, Austin, Boca Raton, and Arlington) consisted of an FE link to the WAN
router.
•
Two Cisco Catalyst 6506 switches located in Miami, each with an MSFC2 or PFC2 card, performed
both Layer 2 and Layer 3 functions.
•
All WAN routers with the exception of the Cisco 7206 router in Miami were used as VoIP voice
gateways registering into a gatekeeper located at the San Jose headquarters, to place real VoIP calls
to other gateways located at other campuses.
•
The WAN router in the Pittsburgh 2 campus had an integrated switch.
•
The other remote campuses consisted of Los Angeles 2, Phoenix 2, Houston 2, San Diego, Oakland,
and San Francisco.
•
Linux end stations and PCs were used to simulate user traffic with Chariot and other test tools.
Routing Description
EGP
Not used.
IGP
A mix of OSPF and EIGRP was used, depending on the WAN link connecting the remote campus to the
major campus, as described in the previous “Hardware Description” section. OSPF and EIGRP
authentication was used on the WAN link to the major campuses.
Note
The remote branch campuses did not redistribute between multiple routing protocols, with the
exception of Miami, which extended Dallas’ OSPF to be a not-so-stubby area (NSSA). This
extension allowed for the redistribution of EIGRP learned routes sourced by the Washington, D. C.
campus to be redistributed and tagged into Miami and the OSPF protocol, but not propagated to the
rest of the OSPF domain. The Area Border Router (ABR) blocked these routes from being sent into
area 0.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
8
nEverest Enterprise Global Testing Environment
Enterprise Global Tests and Topologies Matrix
Table 1 marks the features tested at each campus in the phase 4 enterprise global network with an X.
Click your mouse on the highlighted campus or feature link, or go to the page number indicated, to read
to a description of that campus or feature test.
Table 1
Enterprise Global Tests and Topologies Matrix for nEverest Phase 4
San Jose
Campus,
page 4
Boston
Campus,
page 5
Washington, Denver
D.C. Campus, Campus,
page 5
page 6
Dallas
Campus,
page 7
Remote
Campuses,
page 7
BGP
X
X
X
X
X
—
BGP autonomous system prepend
X
X
X
X
X
—
BGP named community list
X
X
X
X
X
—
BGP prefix-based route filtering
X
X
X
X
X
—
BGP route authentication
X
X
X
X
X
—
BGP route dampening
X
X
X
X
X
—
BGP Soft Config feature
X
X
X
X
—
—
Default route generation
X
X
X
X
X
—
EIGRP
X
X
X
X
—
X
EIGRP metric tuning
X
X
X
X
—
X
EIGRP route authentication
X
X
X
X
—
X
EIGRP route filtration
X
X
X
X
—
X
EIGRP route redistribution
X
X
X
X
—
X
EIGRP stub router
X
X
X
X
—
X
OSPF
—
—
—
—
X
X
OSPF ABR Type 3 LSA filtering
—
—
—
—
X
X
OSPF inbound filtering
—
—
—
—
X
X
OSPF LSA throttling
—
—
—
—
X
X
OSPF NSSA
—
—
—
—
X
X
OSPF packet pacing
—
—
—
—
X
X
Route summarization
X
X
X
X
X
X
cRTP/dcRTP
—
—
—
X
X
X
LFI for MLP
—
—
—
X
—
X
802.1q
X
X
X
X
X
X
EtherChannel (FEC/GEC)
—
X
—
—
—
—
ISL VLAN
—
—
—
—
—
X
Feature and Tests
IP Routing, page 17
Link Efficiency, page 20
Link Type and Encapsulation, page 22
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
9
nEverest Enterprise Global Testing Environment
Table 1
Enterprise Global Tests and Topologies Matrix for nEverest Phase 4 (continued)
San Jose
Campus,
page 4
Boston
Campus,
page 5
Washington, Denver
D.C. Campus, Campus,
page 5
page 6
Dallas
Campus,
page 7
Remote
Campuses,
page 7
CDP
X
X
X
X
X
X
PortFast
X
X
X
X
X
X
STP
X
X
X
X
X
X
UDLD
X
—
X
X
X
X
VTP domain
X
—
X
X
X
X
Accept-register filter
X
—
—
—
—
—
Anycast RP with Auto-RP
X
—
—
X
X
X
Fallback RP
—
—
—
—
—
X
IGMP snooping
X
—
X
X
X
X
IGMP V2
X
X
X
X
X
X
MDS Multilayer Director
—
X
X
—
—
—
MMLS
—
X
X
X
X
—
Multicast boundary
X
—
X
X
X
X
PIM sparse mode
—
—
X
—
—
PIM sparse-dense mode
X
X
X
—
X
X
SSM Mapping
—
—
—
—
—
X
SSM/IGMPv3
—
—
—
—
—
X
MIB Walk—SNMP Traps
X
X
X
X
X
X
NTP
X
X
X
X
X
X
Syslog
X
—
X
X
X
X
QoS classification and marking
X
X
X
X
X
X
QoS congestion avoidance
X
X
X
X
X
X
QoS congestion management
X
X
X
X
X
X
QoS traffic conditioning
X
—
X
X
X
X
HSRP
X
X
X
X
X
X
Monitor convergence times
X
X
X
X
X
X
RPR+
X
—
—
—
—
—
X
X
—
X
X
X
Feature and Tests
Link Management, page 23
Multicast, page 24
Network Management, page 25
QoS, page 26
Resiliency, page 28
Security, page 29
IPSec AIM, ISA, and VAM
hardware encryption
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
10
nEverest Enterprise Global Testing Environment
Table 1
Enterprise Global Tests and Topologies Matrix for nEverest Phase 4 (continued)
Feature and Tests
San Jose
Campus,
page 4
Boston
Campus,
page 5
Washington, Denver
D.C. Campus, Campus,
page 5
page 6
Dallas
Campus,
page 7
Remote
Campuses,
page 7
IPSec/AES
X
—
—
—
—
X
IPSec/CA
—
—
—
—
X
—
IPSec/compression
X
—
—
—
—
X
IPSec/QoS for encrypted traffic
—
—
—
—
X
—
IPSec/QoS preclassify
X
—
—
—
X
X
IPSec/transport mode
—
—
—
X
—
—
IPSec/transport mode/GRE
—
X
—
—
—
X
IPSec/tunnel mode
—
—
—
—
X
—
IPSec/tunnel mode/GRE
X
—
—
—
X
X
IPSec/tunnel protection
X
—
—
—
—
X
IPSec for voice and video
—
—
—
—
X
X
PIX Firewall
X
—
—
—
—
—
TACACS/AAA
X
X
X
X
X
X
H.323 VoIP
X
X
X
X
X
X
SCCP calls
X
X
X
X
X
X
BGP clear neighbors
X
X
X
—
X
—
CEF disable/enable
—
X
X
—
—
—
EIGRP clear neighbors
X
X
X
—
—
X
EIGRP remove
X
X
X
—
—
X
Fail and reestablish WAN links
X
X
X
—
—
X
IPSec Flap encrypted link
X
X
X
—
X
X
IPSec flap HW/SW encryption
method
X
X
X
—
X
X
OSPF clear process
—
—
—
—
X
X
OSPF remove
—
X
—
—
X
—
PIX failover—reload/power cycle
primary
X
—
—
—
—
—
PIX failover—soft switch
X
—
—
—
—
—
PIX failover—reload/power
cycles secondary
X
—
—
—
—
—
Router reboot (power cycle)
X
X
—
—
X
X
Router reboot (soft reboot)
—
X
X
—
X
X
RPF failover
X
—
—
—
—
—
Shutdown/no shutdown
—
—
—
—
—
—
Voice over IP, page 32
Destructive Negative Tests, page 35
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
11
Test Results Summary
Table 1
Enterprise Global Tests and Topologies Matrix for nEverest Phase 4 (continued)
San Jose
Campus,
page 4
Boston
Campus,
page 5
Washington, Denver
D.C. Campus, Campus,
page 5
page 6
Dallas
Campus,
page 7
Remote
Campuses,
page 7
X
—
X
—
X
—
BGP add and remove summary
initiating route
X
X
X
—
X
—
BGP route flap
X
X
X
—
X
—
EIGRP add and remove summary
initiating route
X
X
—
—
—
—
EIGRP route flap
X
X
X
—
—
X
OSPF external route flap
—
—
—
—
X
X
OSPF add and remove summary
initiating route
—
—
—
—
X
—
OSPF internal route flap
—
—
—
—
X
X
PIX failover—attach failover
cable but disable fail
X
—
—
—
—
—
QoS add and remove class map
X
X
X
X
X
X
QoS add and remove policy map
X
X
X
X
X
X
QoS add and remove service
policy
X
X
X
X
X
X
VTP add and remove VLAN from
switch port
X
—
X
—
—
—
Feature and Tests
UDLD—remove TX portion of
GE connection
Nondestructive Negative Tests,
page 36
Test Results Summary
The following sections summarize the phase 4 test environment and test results:
•
Functionality Testing, page 13
•
System Testing, page 15
•
Reliability Testing, page 16
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
12
Functionality Testing
Functionality Testing
The following functionality test cases for the Cisco IOS nEverest enterprise global project were
performed:
•
IP Routing, page 17
•
Link Efficiency, page 20
•
Link Type and Encapsulation, page 22
•
Link Management, page 23
•
Multicast, page 24
•
Network Management, page 25
•
QoS, page 26
•
Resiliency, page 28
•
Security, page 29
•
Voice over IP, page 32
•
Destructive Negative Tests, page 35
•
Nondestructive Negative Tests, page 36
Results of Functionality Testing
Table 2 shows the functionality test results.
Table 2
Functionality Test Results
Component
Pass/Fail
Functionality testing
Passed with exceptions
Passed with Exception Explanations
A test case was marked “passed with exception” when the defects found were either inconsistent,
associated with a test tool, not seen in normal operations, or did not present a significant impact to a
customer’s daily network operations. The following exceptions were noted in the nEverest enterprise
global phase 4 functionality tests:
•
Cisco IOS Release 12.3(11)T1 image name not displayed by the show flash EXEC command
(CSCef90282)—After the c2800nm-adventerprisek9-mz.123-11.T1 image was copied onto flash
memory of the Cisco 2800 router, the image name was not shown in the result of the show flash
EXEC command. However, the image name was displayed by the dir flash command.
•
Spurious access at span_switch_ec_port_attrib_diff() (CSCef90382)—While a QoS policy map was
added and deleted on GE and POS interfaces, a spurious memory trace was displayed.
•
TFTP copies with long filenames produced inconsistent results with two routers
(CSCef18008)—For LEFS-formatted (low-end) file systems, Cisco supports files up to 50
characters in length. This length complies with the DOS file system (DOSFS) default format on
Cisco routers and, going forward, Cisco will encourage customers to migrate to the DOSFS format.
The DOSFS format does not have any limitation on the file length, and typically, the standard
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
13
Functionality Testing
released Cisco IOS image names do not exceed 50 characters in length. Hence, the problem will be
seen only with non-Cisco images. A workaround to this problem is to shorten the prefix before
copying the file into flash memory.
•
A Telnet, SSH, RSH, console or auxiliary session may hang when executing the show policy-map
and show class-map EXEC commands, or while configuring various modular QOS features
(CSCed14868)—This problem occurs when a user has executed either the show policy-map or
show class-map command and left the output of the command sitting at a --More-- prompt. In Cisco
IOS Releases 12.2, 12.1, and 12.1E, even with the fix for CSCea84387, as well as other versions
prior to the fix for CSCea84387, another user on another session issued the following commands
and tasks:
– show class-map command
– show policy-map command
– show run command
– write or write mem command
– write terminal command
– write network command
– Any first use of a command that uses the system:/running-conf command
– Any attempt to configure modular QOS features
In Cisco IOS Releases 12.3, 12.3T, and 12.2T, after the fix for CSCea84387, another user on another
session attempted to configure modular QOS features. The second terminal session did not respond
(was hung up) until the first one that was sitting at the --More-- prompt completed the show
command. The workaround is to not leave the show policy-map or the show class-map command
in the more state, or prior to executing one of these commands, issue the EXEC command term len
0, and then after the show command is complete, issue the EXEC command term len 24.
•
Memory leak and router hangs after NM-HDV fw not responding (CSCee77079)—A Cisco 2621
router did not respond (was hung up) when a lot of packets passed through its serial interface. The
following message appeared on the router console:
-Process= "Pool Manager", ipl= 0, pid= 6
-Traceback= 80E34F0C 80009588 8000A790 8045A9C8 8001FB60 8001FCA0 808B75F4
808BC1F4
%SYS-2-MALLOCFAIL: Memory allocation of 276 bytes failed from 0x8045A9C4,
alignment 32
Pool: I/O Free: 80 Cause: Not enough free memory
Alternate Pool: None Free: 0 Cause: No Alternate pool
The router had the VWIC-2MFT-E1-DI installed in NM-HDV module, and the E1 controller
configured as Frame Relay link, with a PVC of 1344 kbps CIR. The router was unresponsive to a
Telnet from another router or the console. The only way to recover was to do a cold reboot. The
Cisco 2621 router would still hang eventually, even when configured with the 40 percent I/O mem
settings. On a Cisco 2621 router with 128 MB of DRAM, the default I/O memory allocation is 4
percent or 5 MB. The workaround is to disable the DSP autorecovery feature using the test dsp
recovery disable command.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
14
System Testing
System Testing
The goal of the system test was to simulate a realistic customer environment by having the test team
configure all functional features under test and execute all Cisco IOS functionality simultaneously with
planned various levels of traffic generation.
The negative test cases were also executed during system test.
Results of System Testing
Table 3 shows the system testing results.
Table 3
System Testing Results
Component
Pass/Fail
System testing
Passed, and passed with exceptions
Passed with Exceptions Explanations
A test case was marked “passed with exception” when the defects found were either inconsistent,
associated with a test tool, not seen in normal operations, or did not present a significant impact to a
customer’s daily network operations. The following exceptions were noted in the nEverest enterprise
global phase 4 system tests:
•
Memory leak and router hangs after NM-HDV fw not responding (CSCee77079)—A Cisco 2621
router did not respond (was hung up) when a lot of packets passed through its serial interface. The
following message error message appeared on the router console:
-Process= "Pool Manager", ipl= 0, pid= 6
-Traceback= 80E34F0C 80009588 8000A790 8045A9C8 8001FB60 8001FCA0 808B75F4
808BC1F4
%SYS-2-MALLOCFAIL: Memory allocation of 276 bytes failed from 0x8045A9C4,
alignment 32
Pool: I/O Free: 80 Cause: Not enough free memory (CSCsa41793)
Alternate Pool: None Free: 0 Cause: No Alternate pool
The router had the VWIC-2MFT-E1-DI installed in NM-HDV module, and the E1 controller
configured as Frame Relay link, with a PVC of 1344 kbps CIR. The router was unresponsive to a
Telnet from another router or the console. The only way to recover was to do a cold reboot. The
Cisco 2621 router would still hang eventually, even when configured with 40 percent I/O memory
settings. On a Cisco 2621 router with 128 MB of DRAM, the default I/O memory allocation is 4
percent or 5 MB. The workaround is to disable the DSP autorecovery feature using the test dsp
recovery disable command.
•
VSEC: VPN-SM: router crashed in get_ipsec_attributes (CSCef26926)—A Cisco Catalyst 6000
switch or a Cisco 7600 series may reload with CPU signal 10 because of a race condition. This
symptom is observed when the platform is configured with a VPN-SM ACE blade, has IPSec
features enabled, and functions under a stress load. There is no workaround.
•
IO memory leak in middle buffer, multicast over IPHC-format compress on 7200
(CSCsa41793)—Multicast traffic that is sent over an MLP link may trigger an I/O memory leak in
the middle buffers. To determine if the problem is occurring, collect the I/O memory information
from the output of the show memory summary command and track this over a period of several
days. Another way to track this problem is to check that the output of the show buffers command
indicates that the current number of buffers is not drastically larger than the maximum number of
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
15
Reliability Testing
buffers. This problem is observed on Cisco 7200 series routers that run Cisco IOS interim Release
12.3(11.9) or Release 12.3(12) software, and that are configured with an ATM port adapter and a
virtual template (that is, it has virtual access interfaces) when there are two parallel VCs. The
symptom is platform independent. There is no workaround.
•
Cisco IOS Release 12.3(11)T1 image name not displayed by the show flash EXEC command
(CSCef90282)—After the c2800nm-adventerprisek9-mz.123-11.T1 image was copied onto flash
memory of the Cisco 2800 router, the image name was not shown in the result of the show flash
EXEC command. However, the image name was displayed by the dir flash command.
•
Traceback observed with %SYS-2-CHUNKSIBLINGS: Attempted to destroy chunk with siblings
(CSCef69425)—A traceback message was displayed during normal operation with interface flaps
when the c7500 rsp-jk9sv-mz.123-11.3 image was used.
•
VPNSM: traffic counter broken for GRE interface terminated on VPNSM (CSCef56578)—The
traffic rate counter is broken on the GRE tunnel interface terminated on a Cisco Catalyst 6000
VPNS. A standard router running the Cisco IOS Release 12.3 image was at the other end of the
tunnel.
•
VPNSM: system message timestamps is not correct (CSCef46921)—The timestamp of system
message for VPNSM is not correct, which makes it difficult to know when the system message is
reported.
•
Traceback at bc_loop1, pak_copy_network_start, crypto_encdec_packet (CSCef10182)—A Cisco
7200 router with encryption image may experience traceback messages. There is no workaround.
•
Memory allocated at crypto_isa_alloc_pak_and_blk was leaked (CSCee77399)—The memory leak
was found by the GD (Garbage Detector) tool developed by the Cisco IOS Infrastructure team. GD
was delivered as a superset of all memory leak detection tools. This is not a regression defect.
Reliability Testing
The reliability test was an extension of the system testing. The environment that was set up and executed
successfully in the system testing was executed for 150 hours to ensure that no new critical or severe
defects were found during an extended test period.
Results of Reliability Testing
Table 4 shows the reliability test results.
Table 4
Reliability Testing Results
Component
Pass/Fail
Reliability testing
Passed with exceptions
Passed with Exceptions Explanations
•
When the egcs-2651-vw image was running in ROM monitor mode, the system image in flash was
removed by the system one time, but no failure information or stack trace was available to explain
the failure.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
16
Test Case Descriptions
•
IO memory leak in middle buffer, multicast over IPHC-format compress on 7200
(CSCsa41793)—Multicast traffic that is sent over an MLP link may trigger an I/O memory leak in
the middle buffers. To determine if the problem is occurring, collect the I/O memory information
from the output of the show memory summary command and track this over a period of several
days. Another way to track this problem is to check that the output of the show buffers command
indicates that the current number of buffers is not drastically larger than the maximum number of
buffers. This problem is observed on Cisco 7200 series routers that run Cisco IOS interim Release
12.3(11.9) or Release 12.3(12) software, and that are configured with an ATM port adapter and a
virtual template (that is, it has virtual access interfaces) when there are two parallel VCs. The
symptom is platform independent. There is no workaround.
Test Case Descriptions
The following sections describe the functionality tests performed for phase 4.
IP Routing
The purpose of this test was to verify the deployment of the following features:
Layer 2 features such as VLAN, VLAN Trunking Protocol (VTP), Spanning Tree Protocol (STP),
UplinkFast, PortFast, bridge protocol data unit (BPDU) guard, and Unidirectional Link Detect (UDLD)
•
Layer 3 features such as Hot Standby Router Protocol (HSRP), EIGRP, OSPF, eBGP, and iBGP
Unless otherwise noted, the entire enterprise global network was used to perform the basic IP routing
functionality test. The following notes apply:
•
The EIGRP and OSPF protocols were used as the internal gateway protocols (IGPs), and BGP was
used for the external gateway protocol (EGP).
•
The BGP core consisted of the ATM cloud seen in the center of Figure 1, with two T3 links
connecting to Boston, and the POS OC-3 link making the connection between the San Jose and
Washington, D.C. campuses.
•
The routers used for the BGP core were as follows:
– San Jose: egsj-7609-w1, egsj-7609-w2
– Boston: egbos-7206-w1, egbos-7206-w2
– Washington, D.C: egwas-7609-w1, egwas-7609-w2
– Denver: egden-7206-w1, egden-7206-w2
– Dallas: egdal-7206-w1, egdal-7206-w2
•
The routers within the same campus established an iBGP neighbor relationship, whereas
intercampus connections were done via eBGP.
•
EGP authentication used Message Digest 5 (MD5) encapsulation and was performed on eBGP
neighbors between the San Jose and Washington, D.C. campuses.
•
Several eBGP connections from the campuses to two ISPs used route maps to filter unwanted routes.
•
Autonomous system path stripping was performed. The private autonomous system 6450x was
removed and the global autonomous system was applied and advertised to the ISP. The advertised
autonomous system path sent to the ISP reflected the appropriate desirability of using a subsequent
campus as an intermediate or transit autonomous system.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
17
Test Case Descriptions
•
BGP peer groups were set up in the following logical groups: internal peers, external campus peers,
and ISP peers.
•
All routes originated in other well-known peer campuses were advertised to other campuses with
the autonomous system prepended by 3.
•
IGP neighboring across WAN links used type MD5 authentication for the appropriate IGP.
•
The campus distribution, or collapsed distribution layer as appropriate, tuned its appropriate metrics
to ensure symmetric entrance and exit from the supported VLANs, and load balancing across the
redundant routers.
•
Approximately 10,000 routes were injected by Pagent’s Large Network Emulator (LNE) route
generator at various points in the topology. BGP was the IP EGP routing protocol for the ISP
connection.
•
EIGRP was configured as the IGP within the appropriate campus. Each major campus used its own
autonomous system to ensure campus independence.
•
The IGP for Dallas was OSPF. Dallas consisted of no more than four areas. One area was configured
as an NSSA.
•
Summarization was applied at the ABR for routes being created and advertised by the distribution
layer to the core layer, within the respective campus.
•
Multipath for EIGRP, OSPF, and BGP was set to the default number of paths on all platforms.
•
Mutual redistribution was performed. All IGP routes generated by the local campus were
redistributed into BGP. Only those eBGP learned routes originating from well-known peer
campuses were redistributed into the local IGP. These routes were tagged to prevent routing loops
due to mutual redistribution at multiple points.
•
Distributed CEF (dCEF) was enabled on all interfaces and platforms that supported it. Alternatively,
Cisco Express Forwarding (CEF) was enabled when platform and software supported this
capability.
Test Procedure
The procedure used to perform the basic IP functionality test follows:
Step 1
BGP was configured to allow for multiple autonomous systems to communicate using a common routing
protocol. BGP allowed administrative abilities such as route summarization, route filtration, and traffic
advertisement adjustments.
Step 2
BGP autonomous system prepend provided BGP with the ability to administratively advertise specific
routes as being less desirable when the test team examined the autonomous system path on the receiving
router.
Step 3
BGP named community lists were configured to allow grouping multiple community attributes into a
common named list.
Step 4
BGP prefix-based route filtering was configured to allow for prefix filtering with BGP sessions. This
filtering was done for many reasons. A typical scenario would be controlling the advertisement of routes
toward the ISP. One solution was to use route maps that filter based on prefix information, that is,
network IP addresses. Typically, only a block of IP address ranges are allowed to be transmitted, and
hence a route map can easily be created to filter any prefixes that are not within this range.
Step 5
BGP route authentication used MD5 authentication between two BGP peers, so that each segment sent
on the TCP connection between them was verified. All routers in this test bed that were peering using
BGP performed MD5 authentication using the same password; otherwise, the connection between them
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
18
Test Case Descriptions
could not be made. Invoking authentication caused the Cisco IOS software to generate and check the
MD5 digest of every segment sent on the TCP connection. If authentication was invoked and a segment
failed authentication, a message appeared on the console.
Step 6
BGP route dampening was configured to provide the ability to protect router and network stability
against repeated and excessive network state changes elsewhere within the BGP domain.
Step 7
The BGP Soft Config feature was configured to provide the ability to apply policies to BGP learned
routes without restarting the peer relationship. Typically, when the test team applied a new policy to
BGP learned routes via a BGP peer, the peer relationship needed to be restarted and the new policies
applied as the peering began.
Step 8
EIGRP default route generation generated a default route, either natively or as an external route.
Step 9
EIGRP was configured to provide enhancements over other routing protocols, such as fast convergence,
support for variable-length subnet masks, and support for partial updates and for multiple network layer
protocols.
Step 10
EIGRP metric tuning was configured to provide the ability to administratively adjust the link delay and
link bandwidth. A lower delay was applied to the interface during testing that normally would be the
active HSRP interface, to ensure symmetric routing and switching on and off of the supported VLANs.
Step 11
EIGRP route authentication using MD5 was invoked between two EIGRP neighbor peers. When the test
team used authentication, it forced the Cisco IOS software to generate and check the MD5 digest of
every segment sent on the EIGRP connection.
Step 12
EIGRP route filtration was configured to allow for explicit denial of route advertisement on an
interface-level basis. EIGRP route filtration can be used to minimize router resource consumption and,
similarly, to route summarization.However, when routes are denied from being advertised out a
particular interface, the devices are forced to use an otherwise generated summary route (for instance, a
default route), or they will not have a route to forward traffic toward.
Step 13
EIGRP route redistribution was configured and routes were redistributed from the EGP into the IGP
selectively. Based on the autonomous system of origin, routes were tagged to prevent them from being
redistributed into BGP. Only routes originated in other campuses were permitted to be redistributed into
EIGRP. Cost was assigned based on the number of the autonomous system listed within the path.
Step 14
EIGRP stub routing was configured to prevent EIGRP queries from being sent over limited bandwidth
links to nontransit routers. Instead, distribution routers to which the stub router was connected answered
the query on behalf of the stub router. EIGRP stub routing provided the ability to reduce the chance of
further network instability due to congested or problematic WAN links.
Step 15
OSPF was used as the IGP in the Dallas campus, and as the routing protocol running between the Dallas
campus and any directly connected remote campus. The core routers in Dallas were located in OSPF
area 0. Nonzero areas were connected to devices eg-dal-c1 and eg-dal-c2; device eg-dal-w3 had a stub
area connected via Houston.
Step 16
The OSPF ABR Type 3 link state advertisement (LSA) filtering feature was configured to allow the
administrator improved control of route distribution between OSPF areas.
Step 17
OSPF inbound filtering was configured to allow defining of a route map to prevent OSPF routes from
being added to the routing table. This filtering happens at the moment when OSPF is installing the route
into the routing table.
Note
The OSPF LSA throttling feature is enabled by default and allowed for faster OSPF convergence.
This feature was customized so that one command controlled the sending of LSAs and another
command controlled the receiving interval. This feature also provided a dynamic mechanism to slow
down the frequency of LSA updates in OSPF during times of network instability.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
19
Test Case Descriptions
Step 18
OSPF NSSA was configured to allow for the redistribution of external routes into an NSSA area,
creating a special type of LSA known as Type 7 that can exist only in an NSSA area. An NSSA
Autonomous System Boundary Router (ASBR) generated this LSA and an NSSA ABR translated it into
a Type 5 LSA, which was propagated into the OSPF domain.
Step 19
OSPF packet pacing was configured so that OSPF update and retransmission packets were sent more
efficiently. This feature also allowed display of the LSAs waiting to be sent out an interface.
Step 20
OSPF redistribution limits were configured to prevent a flooded network caused by a large number of
mistakenly injected IP routes into OSPF, perhaps caused when BGP was redistributed into OSPF.
Step 21
Route summarization provided the ability to administratively minimize resource consumption
associated with large routing tables. EIGRP was configured because it uses an interface-level
configuration to manually summarize, or it summarizes on the class-address boundary by default. OSPF
was configured to allow for summarization at the ABR. BGP was configured to allow for summarization
based on the routes it learns from the IGP, among other methods. EIGRP summarization was applied to
the distribution routers for routes that advertised subnetworks toward the core routers. The core routers
advertised routes toward the WAN aggregation routers that supported the branch campuses. OSPF
summarization was applied to all ABR routers. BGP summarization was applied to all eBGP
participating routers summarizing the local campus subnetworks.
Expected Results
The following results were expected:
•
Layer 2 features such as VLAN, VLAN trunking, VTP, STP, UplinkFast, PortFast, BPDU guard,
FEC, GEC, and UDLD would be correctly incorporated into the respective campus networks.
•
Layer 3 features such as HSRP, EIGRP, OSPF, eBGP, and iBGP would be correctly incorporated
into the respective campus networks.
•
The routing protocol features would be correctly incorporated into the network campus.
•
Basic network operation (network connectivity) and major IP routing features would work as
expected.
•
EIGRP and BGP routing or OSPF and BGP routing would work as expected.
•
Connectivity within enterprise global network and from the global network to the ISP network
would work as expected.
•
The network parameters such as CPU usage, memory usage, and route convergence times could be
captured using various test tools.
Link Efficiency
The purpose of the link efficiency functionality test was to ensure that the following link-layer efficiency
mechanisms worked with queueing and traffic shaping:
•
Link Fragmentation and Interleaving (LFI) for Multilink PPP (MLP)
•
LFI for Frame Relay and ATM VCs
•
Frame Relay Fragmentation (FRF)
•
Compressed Real-Time Protocol (cRTP)
•
Distributed Compressed Real-Time Protocol (dCRTP)
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
20
Test Case Descriptions
•
Dialer Watch
The following notes apply to the link efficiency functionality test:
•
LFI for MLP, FRF.12, and cRTP was deployed and tested in the enterprise global network. The LFI
feature reduces delay and jitter on slower-speed links by breaking up large datagrams and
interleaving low-delay traffic packets with resulting smaller packets. Interleaving on MLP allowed
large packets to be multilink-encapsulated and fragmented into a small enough size to satisfy the
delay requirements of real-time traffic. Small, real-time packets were not multilink-encapsulated
and were sent between fragments of the large packets.
•
LFI was applied when interactive traffic such as Telnet and VoIP was susceptible to increased
latency and jitter because the network processed large packets such as LAN-to-LAN FTP transfers
that traversed a WAN link, especially because they were queued on slower links.
•
LFI was designed especially for lower-speed links in which serialization delay is significant. LFI
required that MLP be configured on the interface with interleaving turned on.
•
LFI allows reserve queues to be set up so that Real-Time Protocol (RTP) streams can be mapped
into a higher priority queue in the configured weighted fair queue set.
•
FRF.12 was applied to a serial interface configured with Frame Relay encapsulation, and is usually
applied with access links that have a bandwidth of less than 2 Mbps. With FRF.12, nonreal-time data
frames can be carried together on lower-speed links without causing excessive delay to the real-time
traffic. FRF.12 allows routers from multiple remote sites to be multiplexed into a central site router
through Frame Relay links. FRF.12 enables Cisco 7500 series routers with a Versatile Interface
Processor (VIP) to support Frame Relay fragmentation, allowing scalability across multiple VIPs.
•
cRTP compresses the IP, UDP, or RTP header in an RTP data packet from 40 bytes to approximately
2 to 5 bytes. cRTP reduction in line overhead for multimedia RTP traffic results in a corresponding
reduction in delay. cRTP should be applied on any WAN interface where bandwidth is a concern
and there is a high portion of RTP traffic. cRTP can be used for media-on-demand and interactive
services such as Internet telephony.
Test Procedure
The procedure used to perform the link efficiency functionality test follows:
Step 1
cRTP was tested on the following 128K WAN links: FF1 between Denver and Colorado Springs
(egden-7507-w4 and egcs-2651-vw); FF2 between Dallas and Santa Fe (egdal-7507-w4 and
egsaf-2651-vw); and AF3 between Denver and New Orleans (egden-7206-w3 and egneo-2651-vw).
Step 2
MLP LFI was tested on the WAN link AF3 between Denver and New Orleans (egden-7206-w3 and
egneo-2651-vw), and FF2 between Dallas and Santa Fe (egdal-7507-w4 and egsaf-2651-vw). MLP LFI
was tested for both ATM and Frame Relay by associating a virtual template interface with an ATM or
Frame Relay PVC.
Step 3
FRF.12 was tested on the WAN links FF1 between Denver and Colorado Springs (egden-7507-w4 and
egcs-2651-vw), and FF2 between Dallas and Santa Fe (egdal-7507-w4 and egsaf-2651-vw).
Step 4
The Dialer Watch feature uses an ISDN BRI line to back up WAN or serial connection and was tested
on the ISDN link between the Denver and New Orleans remote campuses.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
21
Test Case Descriptions
Expected Results
The link efficiency mechanism was expected to work as designed, and would improve the efficiency and
predictability of the application service levels.
Link Type and Encapsulation
The purpose of the link type and encapsulation functionality test was to verify T3, E3, T3-ATM, POS
OC-3, and GE and FE connections, and Frame Relay, PPP, High-Level Data Link Control (HDLC),
ARPA (RFC 826 Ethernet-style ARP), 802.1q, Inter-Switch Link (ISL), and ATM adaptation layer
(AAL5snap) encapsulations.
The following notes apply to the link type and encapsulation functionality test:
•
The high-speed WAN layer consisted of a partially meshed set of connections consisting of T3, E3,
T3-ATM, and POS OC-3 connections. Each high-speed WAN router had redundant connections to
the local campus core routers using either GE or FE.
•
The Boston, Dallas, Denver, San Jose, and Washington, D.C. major campuses consisted of core,
distribution, WAN aggregation, and access layers. The layers were interconnected using redundant
GE and FE connections. The access layer connected to the workstations using FE.
•
All trunk connections used 802.1q encapsulation.
•
Branches were connected to the major sites using Frame Relay, ATM/Frame Relay, serial, or ISDN.
The link types used on the test network branch connections were serial, HSSI, T1, Ch-T1, E1,
Ch-E1, T3/DS3, E3, ATM E3, ATM T3, Ch-T3, Ch-E3, and FE. The encapsulation types used were
Frame Relay, PPP, HDLC, ARPA, 802.1q, ISL, and AAL5snap.
Test Procedure
The procedure used to perform the link type and encapsulation functionality test follows:
Step 1
802.1q VLANs were configured to allow LAN networks to be divided into workgroups connected via
common backbones to form VLAN topologies.
Step 2
Fast EtherChannel and Gigabit EtherChannel port bundles were configured to allow grouping multiple
FE and GE ports into a single, logical transmission path between the switch, and a router, host, or another
switch.
Step 3
ISL VLANs were configured to allow LAN networks to be divided into workgroups connected via
common backbones to form VLAN topologies.
Expected Results
Link types and encapsulations were expected to work.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
22
Test Case Descriptions
Link Management
The purpose of the link management functionality test was to verify correct operation of the following
link management mechanisms:
•
STP
•
Cisco Discovery Protocol (CDP)
•
UDLD
The Operation, Administration, and Maintenance (OAM) feature was also verified. This feature limits
the number of consecutive OAM Alarm Indication Signal (AIS) cells received before the subinterface is
brought up or down, and limits the number of OAM loopback retries before the subinterface is brought
down.
Test Procedure
The procedure used to perform the link management functionality test follows:
Step 1
CDP was used to provide device connection information, regardless of media. CDP also allowed for
improved troubleshooting ability. CDP was enabled on all LAN links.
This media- and protocol-independent device-discovery protocol runs on all Cisco-manufactured
equipment including routers, access servers, bridges, and switches. With CDP enabled, a device can
advertise its existence to other devices and receive information about other devices on the same LAN or
on the remote side of a WAN.
Step 2
PortFast, in conjunction with PortFast-BPDU guard, minimized STP convergence times associated with
bringing up an end device such as a workstation. PortFast was enabled on all access layer devices where
the port was connecting to an end device.
Step 3
STP was used to ensure that a Layer 2 LAN-switched environment was loop free with consistent packet
forwarding for the applicable Layer 2 destination. STP was implemented in every Layer 2 LAN switched
environment. In addition, it was tuned to ensure that the root device on the same device was the active
HSRP router.
Step 4
UpLinkFast provided improved convergence time for STP, when a directly connected link failed and
STP was forced to fail over to a redundant link. UpLinkFast was implemented in all Layer 2 LAN switch
devices.
Step 5
UDLD provided Layer 2 link integrity for LAN switches to ensure that the STP was appropriately
updated when the transmit or receive portion of a link failed. UDLD was enabled on all GE connections.
Step 6
VLAN Trunk Protocol (VTP) reduces administration in a switched network. In this test, a new VLAN
was configured on one VTP server so that the VLAN was distributed through all switches in the domain.
This reduced the need to configure the same VLAN everywhere. Each building was in a separate VTP
domain. The distribution layer switches were configured as VTP servers, and the connected access-layer
switches were configured in VTP transparent mode. A trunk was presented to an IP phone in Boston on
egbos-4006-a3 port 3/11. The trunked VLANs were checked to ensure that extraneous VLANs were
pruned from the trunk.
Expected Results
The link management mechanisms were expected to work as designed.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
23
Test Case Descriptions
Multicast
The purpose of the multicast functionality test was to deploy and verify multicast deployment scenarios
for large enterprise customers that want to gain the benefits of multicasting over the network. The
enterprise global test bed tested various multicast features on different Cisco platforms, with different
Cisco IOS and CatOS software images, as follows:
•
Accept-register filter
•
Anycast rendezvous point (RP) with Auto-RP
•
Fallback RP
•
Internet Group Management Protocol (IGMP) snooping
•
IGMPv2
•
MDS-7500 specific feature
•
Multicast multilayer switching (MMLS)
•
Multicast boundary
•
Protocol Independent Multicast (PIM) sparse mode
•
PIM sparse-dense mode
•
Source Specific Multicast (SSM)/IGMPv3
•
SSM Mapping feature
IP multicast routing was enabled on every router in the test bed. All campuses used PIM sparse-dense
mode except for the Denver campus. PIM sparse mode was tested on the Denver campus. Both Auto-RP
and static RP were configured in the test bed to provide redundancy.
Cisco’s IP/TV server was used to provide real multicast applications for the entire test bed. The multicast
traffic was sent to six different groups, and three of those groups performed SSM-related testing. Some
simulated multicast traffic was also generated with a traffic generator.
The IP/TV servers were connected to switches egsj-6505-sa3 and egwas-6506-sd1. The simulated IP/TV
traffic was generated from the San Jose campus from switches egsj-5505-sa1, egsj-5505-sa2, and
egsj-6506-sa3. Simulated feedback traffic was also sent from the San Jose campus user floors to the San
Jose data center.
Depending upon the location, the IP/TV client received a subset of the multicast groups:
•
In the large campuses (San Jose, Boston, Washington, D.C., Denver, and Dallas), the IP/TV clients
were configured on all the user access switches. Those clients were subscribed to high-speed
(1 Mbps) IP/TV programs.
•
The remote, lower bandwidth branches such as Colorado Springs and New Orleans were subscribed
to two 60 kbps groups. The other, higher bandwidth branches subscribed to two 200 kbps programs.
Branches egla2-2800-vw, eghou2-2800-vw, and egpit2-2800-vw were subscribed to SSM groups.
Test Procedure
The procedure used to perform the multicast functionality test follows:
Step 1
Accept-register filter was configured to allow the RP router to filter PIM register messages, so that RP
could control which source could register with it.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
24
Test Case Descriptions
Step 2
Anycast-RP used the Multicast Source Discovery Protocol (MSDP) to provide resiliency and
redundancy. Auto-RP was configured to automatically distribute the group-to-RP mapping information
in a PIM-enabled network.
Step 3
Fallback RP was configured on router egsj-6506-c2 to prevent dense-mode fallback and blocking
multicast traffic for groups not specifically configured.
Step 4
IGMP snooping was used on Layer 2 Cisco Catalyst switches. The Layer 2 switch monitored the IGMP
queries and responses between end hosts and the router, and thereby provided multicast subscription
control.
Step 5
IGMP v2 is enabled by default in the Cisco IOS software. IGMP messages were used by the router and
host to communicate with each other, so that the router could monitor the correct group membership
status.
Step 6
Multilayer Directors were configured and worked with Cisco Express Forwarding (CEF), unicast
distributed fast switching (DFS), or flow switching to distribute switching of multicast packets received
at the line cards.
Step 7
MMLS was used in the Cisco Catalyst switches to create hardware shortcuts for (S, G) and (*, G) entries
to forward multicast traffic.
Step 8
The multicast boundary feature was configured to administratively limit the range of multicast streams.
Step 9
PIM sparse mode was enabled in the Denver campus and was used throughout the entire campus.
Step 10
PIM sparse-dense mode was enabled on all Layer 3 native Cisco IOS and multicast devices in the
Boston, San Jose, Washington, D.C., and Dallas campuses. This mode controls the way multicast groups
are propagated within the network. Traffic is usually propagated using PIM sparse mode. This test also
verified whether the network could forward reasonable amounts of dense mode multicast traffic.
Step 11
SSM delivery datagram is based on (S, G) channels. Systems were configured to receive this traffic by
becoming members of the (S, G) channel. PIM-SSM was the routing protocol that supported this
implementation of SSM and is derived from PIM sparse mode. IGMPv3 was used to support the SSM.
Step 12
The SSM Mapping feature was configured to support SSM transitions. When a router received an IGMP
version 1 or version 2 membership report for a particular group G, the router translated this in one or
more SSM (S, G) channel memberships, such as IGMPv3 (S, G) INCLUDE membership reports, for the
well known sources associated with this group.
Expected Results
It was expected that all multicast scenarios would be successfully deployed.
Network Management
The purpose of the network management functionality test was to ensure that the information stored in
MIB databases could be accessed, propagated, read, and written (when applicable) using Simple
Network Management Protocol (SNMP), and to ensure that the operation of the Object Identifier (OID)
values reflected the actual operation on the device.
Test Procedure
The procedure used to perform the network management functionality test follows:
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
25
Test Case Descriptions
Step 1
Automated SNMP scripts were used to perform compliance testing. The snmp_walk_test script was used
to test the OIDs by platforms and technologies, report their value, and monitor the behavior of the unit
under test. UNIX workstations were used as the SNMP receivers.
Step 2
Device eg-cw2k (a Ciscoworks2000 server) in the San Jose campus was used as the UNIX Network
Time Protocol (NTP) and system message logging (syslog) server.
Step 3
The test team used syslog to collect messages from devices and log them on a server running a syslog
daemon. Logging messages to a central syslog server assists in the aggregation of logs and alerts. Every
Cisco device in the enterprise global test bed logged all debug-level messages to a UNIX-style syslog
file.
Expected Results
We expected that the information stored in the MIB database could be accessed, propagated, read, and
written, so that the operation of the OID values reflected the actual operation on the device.
QoS
QoS design and deployment in the enterprise global network is based on the Cisco AVVID Enterprise
QoS Solutions Design guide.
The following QoS features were tested:
•
Classification and marking using access lists, port numbers, IP precedence, and Differentiated
Services Code Point (DSCP).
•
Congestion management using low latency queueing (LLQ) and CBWFQ.
•
Congestion avoidance using Weighted Random Early Detection (WRED) and distributed WRED.
•
Traffic conditioning using Frame Relay traffic shaping (FRTS) and class-based policing.
•
Link efficiency using cRTP and MLP LFI.
The following DSCP values and traffic classes were used:
•
Real-Time ef—VoIP traffic.
•
Interactive af31—Telnet and voice signaling (gatekeeper, H.225, H.245, Skinny Client Control
Protocol or SCCP, and Media Gateway Control Protocol or MGCP), which use small packets.
•
Transactional af21—Lotus Notes and Oracle applications that are mission-critical, and that can
consume large amounts of bandwidth.
•
Streaming af11—IP/TV multicast video conferencing and multicast signaling.
•
Class-default 0—FTP, HTTP, and throughput scripts (best effort service).
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
26
Test Case Descriptions
A modular QoS CLI-based approach using class.maps, policy-maps, and service policy was used to
configure QoS network-wide.
Classification and marking was done at the distribution layer in the San Jose, Denver, and remote
campuses, and at the core layer in the Boston, Washington, D.C., and Dallas campuses. Traffic was
re-marked at subsequent hops in the core and WAN aggregation layers. WRED was deployed on WAN
links T3/E3 and OC-3 between main campuses. cRTP and LFI were applied on slow speed links
connecting to the remote sites. FRTS was applied on remote sites with Frame Relay connections.
In the case of remote campuses, QoS was enabled only on the primary WAN links on remote campuses.
QoS was not enabled on backup WAN links to the remote campuses.
Test Procedure
The procedure used to perform the QoS functionality test follows:
Step 1
QoS classification and marking are two separate actions that are usually done together. Access lists and
class maps were used to classify data. Packets were marked with policy map commands using DSCP and
IP precedence. Packet classification and marking took place on the outbound interfaces of the
distribution, core, and WAN layer switches in all campuses. Classification also took place at other
routers and switches in the network to enforce predictable per-hop behaviors. Five traffic classes were
used: real-time, interactive, transactional, streaming, and class-default.
Step 2
WRED was configured as the primary congestion avoidance mechanism. WRED uses algorithms that
provided buffer management to the output queues. WRED was applied using random detect,
DSCP-based sampling on the interactive, transactional, and class-default classes on the outbound
interfaces of the WAN aggregation routers with T3/E3 and OC-3 links.
Step 3
Network congestion management was facilitated by setting up queues of differing priorities. 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 interfaces for all WAN routers and
Layer 3 switches.
LLQ for Frame Relay was configured using a combination of class map, policy map, and Frame Relay
map class commands. The class map commands defined traffic classes according to protocol, interface,
or access list. The policy map commands defined how each class was treated in the queueing system
according to bandwidth, priority, queue limit, or WRED. The service policy output map class commands
attached a policy map to a Frame Relay VC. LLQ and CBFWQ were applied to all the WAN links on
the outbound interfaces of the WAN and remote branch routers, and also in the LAN on the outbound
interfaces of the distribution and core layers in all campuses.
Step 4
Traffic conditioning was facilitated using Cisco IOS traffic policing and shaping features. Phase 4
testing used the rate-limiting committed access rate (CAR) feature, class-based policing for policing
traffic, and FRTS for shaping traffic.
FRTS was applied to the following WAN links: FF1 linking Denver to Colorado Springs
(egden-7507-w4 and egcs-2651-vw); FF2 linking Dallas to Santa Fe (egdal-7507-w4 and
egsaf-2651-vw); AF linking San Jose to Los Angeles 2 (egsj-7609-w1 and egla2-2821-vw). For Frame
Relay, class-based policing was applied on the WAN link between Boston and Pittsburgh
(egbos-7206-w3 and egpit-3640-vw1).
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
27
Test Case Descriptions
Expected Results
We expected the QoS deployment scenarios to work for large enterprise customers that want to protect
their critical application data, including real-time VoIP, on WAN links.
Resiliency
Cisco defines network resiliency as the ability to recover from any network failure. The purpose of the
resiliency functionality test was to deploy and verify the following functions:
•
Routes configured to participate in an HSRP standby group, which provide redundant support for a
virtual IP address that is used by end hosts for a default gateway.
•
Monitor convergence times to learn how quickly the network recovers after a failure.
•
Route Processor Redundancy Plus (RPR+) on the Cisco 7600 series routers to verify that interfaces
stay up during a switch from an active to a standby Route Processor.
The following notes apply to the resiliency tests:
•
At the core layer, all campus core routers in San Jose had redundant supervisor modules and were
configured as the standby supervisor.
•
At the distribution layer, each campus used a full distribution layer, or a collapsed core and
distribution layer, and utilized a single supervisor for each device, but maintained two routers with
HSRP running between them on each that supported users in the access layer.
•
No resiliency feature was tested within the access layer except for physically redundant connectivity
from each access layer switch to the distribution layer router.
Test Procedure
The procedure used to perform the resiliency functionality test follows:
Step 1
HSRP testing: Routers were configured to participate in an HSRP standby group to provide redundant
support for a virtual IP address that was used by end hosts for a default gateway. The address was applied
to all routers with subnets in common with the end points (workstations), where there were two
redundant routers supporting the common end points. An example would be San Jose’s distribution layer
routers in building 1, building 2, and the data center.
Step 2
Monitoring convergence times allows users to see how quickly a network recovers after a failure. Fast
convergence times are necessary so that traffic is not lost and the impact of a failure is minimal.
Monitoring was done using the external Ixia traffic generator tool. The convergence time was measured
from the time of failure to the time of complete recovery.
Step 3
RPR+ was configured on all San Jose Core Cisco 6500 series routers (egsj-6509-c1 through c4) to verify
that interfaces stayed up during a switch from an active to a standby Route Processor. The interface
statuses were displayed after the test team copied a new image into both supervisors.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
28
Test Case Descriptions
Expected Results
The following results were expected:
•
Routes configured to participate in an HSRP standby group should provide redundant support for a
virtual IP address that is used by end hosts for a default gateway.
•
Convergence times should be fast so that customers do not lose traffic and the impact of a failure is
minimal.
•
RPR+ allows interfaces to stay up during a switch from an active to a standby Route Processor.
Security
The purpose of the security functionality test was to deploy and verify the IPSec deployment scenarios
for large enterprise customers that want to secure their intercampus communications while using the
scalability of key management features incorporated into IPSec.
The following security features were tested:
•
IPSec with AIM, ISA, and VAM hardware encryption
•
IPSec and QoS interactivity; QoS preclassify
•
IPSec transport and tunnel modes with peer-to-peer, site-to-site (hub spoke), and Generic Routing
Encapsulation (GRE) tunnel topologies
•
PIX Firewall
•
Cisco Secure Server (AAA, TACACS+), Public Key Infrastructure (PKI) (CA)
•
Payload, both voice and data
•
Encryption: Data Encryption Standard (DES), 3DES, hardware and software encryption
•
Internet Key Exchange (IKE) Extended Authentication
•
Key management: Internet Security Association and Key Management Protocol (ISAKMP):
preshared, PKI (SA)
•
Packet filtration: access lists
•
Compression
•
Tunnel protection
Tunnel mode and transport mode were both tested in site-to-site and peer-to-peer encryption
configurations. The encryption method varied between hardware- and software-based encryption. Data
that was transported included traffic generated from testing tools such as TGN, Chariot, and CallGen.
PKI provided two peers to dynamically share encryption keys.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
29
Test Case Descriptions
Test Procedure
The procedure used to perform the security functionality test follows:
Step 1
IPSec, Advanced Integration Module (AIM), Integrated Services Adapter (ISA), and Virtual Private
Network (VPN) Acceleration Module (VAM) hardware encryption were tested.
AIM and VAM modules were implemented in the security tests to increase encryption performance. The
AIM and VAM modules modify how a packet is treated within the router. With hardware crypto, the
CPU does not manage the packet all the time, and sends the packet to an AIM or VAM module before
queueing it for transmission.
The following encryption modules were used:
AIM-VPN (BP)
•
AIM-VPN (MP) for Cisco 2600 and 3600 routers
•
ISA, VAM, and VAM I for Cisco 7200 routers
The following IPSec encryption modules were tested as part of IPSec deployment:
•
SA-VAM VPN module was added to the Denver WAN router (egden-7206-w3).
•
SA-ISA module was added to the Cisco 7200 router WAN routers in San Jose (egsj-7206-w3),
Boston (egbos-7206-w3), Dallas (egdal-7206-w1 and egdal-7206-w2), and Phoenix
(egphx-7206-w1).
•
NM-VPN/MP (Mid-Performance) network module was added to the WAN Cisco routers in
Pittsburgh (egpit-3640-w1) and Los Angeles (egla-3640-w1).
•
AIM-VPN/HPII (High-Performance II) VPN module was added to the Houston (eghou-3660-w1)
WAN router.
•
MOD1700-VPN module was added to a Cisco1760 router. Data encryption 3DES algorithms were
used.
•
AIM-VPN/EP (Enhanced Performance) was added to a Cisco 2621 WAN router in Austin.
Step 2
IPSec AES—Advanced Encryption Standard and IP Payload Compression features—were deployed in
the Dallas and Houston-2 (eghou2-2800-vw) campuses.
Step 3
IPSec and Certificate Authority (CA) were tested.
This test was implemented between Dallas, Arlington, and Boca Raton, with a Microsoft CA server
located in San Jose. The IPSec and CA interaction was tested with the processing of requests and
revoking of certificates. Spoke-to-spoke calling was tested with VoIP packets that were encrypted at one
site, decrypted at a headend router at another site, routed to another tunnel interface, encrypted again,
and then decrypted one last time. Data packets were also encrypted and decrypted at sites that allowed
testing VPN termination behind the WAN edge.
Step 4
IPSec compression was deployed between Dallas (egdal-7206-w1), Houston2 (ehhou2-2800-vw), and
San Jose (egsj-7600-w3 and egla2-2800-vw).
IPSec compression enabled both compression and encryption of data to occur at Layer 3 when the system
selected Lempel-Ziv-Stac (LZS) with the IPSec transform set; that is, LZS compression occurred before
encryption.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
30
Test Case Descriptions
Step 5
IPSec and QoS for encrypted traffic were tested.
This feature test was implemented because it maximized bandwidth for all IPSec traffic. Bandwidth
policies were defined for encrypted flows or all other traffic on the interface would use the bandwidth
the IPSec does not use. A class map matched all the IPSec traffic leaving the routers. The test was
implemented between Dallas and Boca Raton.
Step 6
IPSec and QoS preclassify were tested.
This feature test was implemented in San Jose, Dallas, Boston, New York, Pittsburgh, and Houston to
enable IPSec to interoperate with QoS between the Dallas (egdal-7206-w1) and Austin (egaus-2621-w1)
campuses, for a simulated voice, video, and data traffic profile. For configuring an IPSec-encrypted IP
GRE tunnel, QoS preclassify was enabled on both the tunnel interface and crypto map.
Step 7
IPSec transport mode with no IP GRE tunnel was tested.
This implementation was considered for testing because it saved bandwidth compared to the IPSec
tunnel mode—no IP GRE tunnel mode. In this configuration, IPSec encrypted IP unicast traffic only and
the test was implemented between Denver and Phoenix. IPSec SAs were created for each access list line
matched. An access list was specified in the crypto map to designate packets that were to be encrypted.
Step 8
IPSec transport mode encrypting an IP GRE tunnel was tested.
This deployment was considered because it saved 16 bytes per packet over the IP GRE tunnel for G.729
calls. Because an additional IPSec IP header was not required, less overhead was incurred compared to
the IPsec tunnel mode encrypting an IP GRE tunnel feature test. G.729 and G.711 voice packets, Chariot
streams, and routing were encrypted. The dynamic routing protocol used within the IP GRE tunnel was
EIGRP.
Step 9
IPSec tunnel mode with no IP GRE tunnel was tested.
This implementation was considered because it saved bandwidth compared to the IPSec tunnel mode
with IP GRE tunnel test, did not utilize an IP GRE tunnel, and minimized the antireplay drops. In this
configuration, IPSec security associations were created for each access list line matched. An access list
was specified in the crypto map to designate packets that were to be encrypted. This test was
implemented between Dallas and Houston.
Step 10
IPSec tunnel mode encrypting an IP GRE tunnel was tested.
This implementation was considered because it incurred the greatest header overhead compared to IPSec
transport mode encrypting an IP GRE tunnel and IPSec tunnel mode with no IP GRE tunnel. The voice
packets (G.729, G.711), Chariot streams, and routing traffic were encrypted. The dynamic routing
protocol within the IP GRE tunnel was EIGRP. When this implementation was configured with routing
protocol EIGRP running within an IP GRE tunnel, the routing protocol’s hello packets maintained the
security associations between routers.
Step 11
IPSec tunnel protection was tested.
Tunnel protection for IPSec+GRE simplified the encryption configuration for post encapsulation types
of encryption for GRE or IP-in-IP tunnel interfaces.
Step 12
IPSec for voice and video was tested.
A voice- and video-enabled VPN configuration was implemented between two links (Dallas and Austin)
with QoS preclassify and an IPSec GRE tunnel configured. Voice and video streams were simulated by
Chariot emulators.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
31
Test Case Descriptions
Step 13
A PIX Firewall device was tested.
A PIX Firewall device was deployed in the San Jose campus. PIX Firewall was deployed behind the
perimeter Cisco 7200 router (egsj-7206-w4) that connected to the ISP. The PIX device was connected
to device egsj-7206-w3 inside the enterprise network. A web server was placed in the network, and two
PCs were used in the ISP test bed. One PC acted like an Internet user and hacker; the other PC acted like
a web server.
The following PIX features were tested:
Step 14
•
Network Address Translation (NAT)
•
Port Address Translation (PAT)
•
AAA/TACACS+ integration
•
Syslog
•
Failover and stateful failover
TACACS+ and AAA were tested.
TACACS+ services and AAA were tested as a part of the end-to-end global infrastructure at a system
level for all access, distribution, core, and WAN edge devices in the global topology. This feature test
was enabled on all routers and switches in the San Jose, Boston, Denver, Dallas, and remotes campuses
as part of the infrastructure. The AAA server was located in San Jose.
Expected Results
The following results were expected:
•
The site-to-site IPSec VPN in an Architecture for Voice, Video, and Integrated Data (AVVID)
infrastructure for enterprise customers deploying services and solutions that included VPN, QoS,
and IP telephony would work.
•
Campus PIX Firewall infrastructures would work.
Voice over IP
The purpose of the voice functionality test was to examine the convergence of the following two general
areas of VoIP telephony within the enterprise global topology:
•
The traditional H.323 gateway-based VoIP.
•
The newer IP telephone and Cisco CallManager version and upgrade (also called AVVID) additions.
The following voice functions were used in the testing:
•
Cisco CallManager clustering used the centralized and distributed model.
•
RTP voice streams testing took place after all call setups.
•
Transcoding testing took place in selected paths at the data center and other regional sites.
•
Codec testing used G.711 and G.729.
•
SRST testing took place at the Los Angeles, Colorado Springs, and Pittsburgh remote sites.
•
Cisco Call Manager Express (CCME).
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
32
Test Case Descriptions
The following test tools were used:
•
CallGen Telephony (Cisco 3660 router running CallGen Images):
– Legacy H323 Callgens: one router for digital T1s and one router for analog FXS.
– SCCP IP-Phone Callgens: one router for originate and one router for terminate.
– SCCP Digital T1 Callgens: one router for originate and one router for terminate.
– SCCP Analog FXS Callgens: one router for originate and one router for terminate.
•
Carrier Identification Code (CIC): CallGen Information Collector.
•
Abacus Bulk Call Generator.
•
Analog and 7970, 7960, 7940, and 7910 IP telephones.
Besides the features already listed, the scope included testing matrices in three areas:
•
H.323 and SCCP signaling protocols:
– H.323 to H.323 calls—Covered across entire VoIP legacy network.
– H.323 to SCCP calls—Covered across entire AVVID network.
– SCCP to SCCP calls—Covered across entire AVVID network.
•
Call types (T1 Channel Associated Signaling [CAS], FXS, and VoIP).
– FXS to FXS.
– FXS to T1.
– FXS to IP.
– T1 to T1.
– T1 to IP.
– IP to IP.
•
Gateway types:
– Cisco Catalyst 6000 series switch only.
– Cisco Catalyst 4000 series switch only.
– Cisco Catalyst 6000 series switch to Cisco Catalyst 6000 series switch.
– Cisco Catalyst 6000 series switch to Cisco Catalyst 4000 series switch.
– Cisco Catalyst 6000 series switch to gateway.
– Cisco Catalyst 4000 series switch to Cisco Catalyst 4000 series switch.
– Cisco Catalyst 4000 series switch to gateway.
– Gateway to gateway.
Following was the general testing procedure:
•
All campuses were wired—gateways, Cisco CallManagers, switches, Callgens, simulators, and so
on.
•
Propagated static routes were added to Callgen loopbacks on all adjacent routers.
•
IP telephones were configured.
•
Cisco CallManagers were configured and upgraded.
•
Gatekeepers were configured.
•
Callgen was configured.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
33
Test Case Descriptions
•
Inline power switches and IP telephones were configured.
•
SRST was configured.
•
CCME was configured.
•
All devices under test (all routers and switches) were configured.
•
Connectivity was brought up.
•
Troubleshooting was performed in all steps, as necessary.
Test Procedure
The procedure used to perform the VoIP functionality test follows:
Step 1
H.323 VoIP testing took place between all legacy gateways, Cisco Catalyst 4000 blades, VG200,
ATA186, and gatekeepers, and from gatekeepers and gateways to the Cisco CallManager.
Cisco gateways and gatekeepers were used to test H.323 VoIP. CallGen, a Cisco internal tool, was used
to make calls between the following configurations:
•
T1 CAS to T1 CAS
•
T1 CAS to FXS
•
FXS to T1 CAS
•
FXS to FXS
The following routers were used as gateways:
•
Cisco 2651
•
Cisco 2811
•
Cisco 2821
•
Cisco 2851
•
Cisco 3660
•
Cisco 3745
•
Cisco 3825
•
Cisco 3845
•
Cisco 7204
The gatekeeper function was performed in the San Jose and Los Angeles 2 campuses.
Step 2
Skinny Client Control Protocol (SCCP) testing took place between real or simulated IP telephones,
Cisco Catalyst 6000 blades, Cisco Catalyst 4000 switch transcoder, Survivable Remote Site Telephony
(SRST) gateways, and the Cisco CallManager.
The following hardware configurations were used for this test:
•
T1 CAS and FXS SCCP voice gateways on a Cisco Catalyst 6506.
•
T1 CAS and FXS SCCP voice gateways on WS-4604-GWY access gateway module on a Cisco
Catalyst 4507.
•
Inline power and real IP telephones on a Cisco Catalyst 6506.
•
Inline power and real IP telephones on WS-4604-GWY access gateway module on a Cisco Catalyst
4507.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
34
Test Case Descriptions
•
T1 CAS and FXS SCCP voice gateways on WS-4604-GWY access gateway module on a Cisco
Catalyst 4006.
•
Inline power and real IP telephones on WS-4604-GWY access gateway module on a Cisco Catalyst
4006.
•
FXS SCCP voice gateway on an ATA188.
•
T1 CAS and FXS SCCP voice gateway on a VG200.
•
T1 CAS and FXS SCCP voice gateway on a Cisco 2800 series router.
•
CCME on Cisco 2800 and 3800 series routers in the Boston and Pittsburgh campuses.
Expected Results
The convergence of the following two general areas of VoIP telephony within the enterprise global
topology was expected to work together:
•
The traditional H.323 gateway-based VoIP.
•
The newer IP telephone and Cisco CallManager version and upgrade (also called AVVID) additions.
Destructive Negative Tests
Negative tests were executed with an expectation of traffic loss and network instability. Negative tests
were performed on the following features:
•
IP routing: BGP, EIGRP, and OSPF
•
Link management
Test Procedure
The procedure used to perform the destructive negative test follows:
Step 1
BGP clear neighbors test verified that the neighbor relationship could be reestablished and
authentication was consistent. The test was performed with both a hard clear and soft reconfigure.
Step 2
The CEF disable and enable test removed and added VLANs from specific switch ports, then disabled
and reenabled CEF to ensure that CEF adjacencies were reestablished.
Step 3
EIGRP clear neighbors was a test that the neighbor relationship could be reestablished and
authentication was consistent.
The EIGRP remove was more extensive testing of EIGRP clearing performed by removing the EIGRP
process entirely from the router.
Step 4
The fail and reestablish WAN links test failed WAN links in the campuses and on the devices noted, and
ensured that alternative routes were learned before the WAN link, and that the applicable routing
neighbor relationship was reestablished.
Step 5
For the IPSec flap-encrypted link test, the interface to which the crypto map was applied was flapped.
The IPSec SAs were reformed and the GRE tunnels were reestablished.
Step 6
In the IPSec flap hardware and software encryption method test, the device was tested for its ability to
switch from hardware to software encryption, and then back to hardware encryption.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
35
Test Case Descriptions
Step 7
OSPF clear neighbors (clear process) test verified that the neighbor relationship could be reestablished
and authentication was consistent.
Step 8
OSPF remove was a more extensive testing of OSPF clearing performed by completely removing the
OSPF process from the router.
Step 9
The PIX failover soft switch test started a continuous ping (from inside to outside the network) and FTP
session with hash mark enabled. This test forced the secondary or standby router to become active.
Step 10
The PIX failover reload/power-cycle primary test reloaded the power-cycle primary/active PIX, then the
test was repeated. The tester started a continuous ping (from inside to outside the network) and FTP
session with hash mark enabled, before reloading the primary/active PIX.
Step 11
The PIX failover, reload/power-cycle secondary test reloaded the power-cycle secondary/standby PIX,
then the test was repeated. The tester started a continuous ping (from inside to outside the network) and
FTP session with hash mark enabled, before reloading the secondary/standby PIX.
Step 12
The router power-cycle reboot test verified the router’s ability to return to normal operation after a
manual reboot due to a power cycle.
Step 13
The router soft reboot test verified the router’s ability to return to normal operations after a soft reboot.
Step 14
RPF failover tested the impact on the test bed when failover occurred when the router was forwarding
multicast traffic.
Step 15
The RP failover test verified the fault tolerant capability of Anycast.
Step 16
The shut/no shut interface test was performed on the active traffic path using the shutdown and no
shutdown commands during the test.
Step 17
The UDLD test was done by physically unplugging and plugging, either fully or partially, the GE and
FE contributing connections.
Expected Results
It was expected that the destructive negative tests would result in traffic loss and network instability.
Nondestructive Negative Tests
The nondestructive negative tests were done without an expectation that they would cause significant
traffic loss and network instability, because of network, node, and path redundancy. Negative tests were
performed by adding and removing routes that generate summary routes.
Test Procedure
The procedure used to perform the nondestructive negative test follows:
Step 1
The BGP add and remove summary initiating route test added and removed the route that generated the
summary route.
Step 2
The BGP route flap, EIGRP route flap, and OSPF external route flap tests tested the routing protocol’s
dampening capabilities.
Step 3
The EIGRP add and remove summary initiating route test added and removed the route that generated
the summary route.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
36
Test Case Descriptions
Step 4
The EIGRP route flap that resulted from Step 3 were observed on the following devices:
•
egsj-6506-c1
•
egsj-6506-c2
•
egla-3640-vw
•
egbos-7206-w1
•
egbos-7206-w2
•
egpit-3640-vw
The query domain was limited to the respective WAN aggregation routers within both campuses.
Step 5
The OSPF add and remove summary initiating route test added and removed the route that generated the
summary route.
The routing protocol’s dampening capabilities were tested when routes learned by BGP, EIGRP, and
OSPF were flapped. These tests worked in tandem with the add and remove summary initiating route
tests to increase the modulation of flapped routes and trigger the dampening function in BGP, EIGRP,
and OSPF.
Step 6
Step 7
OSPF external route flap test: The effects of the BGP add and remove summary initiating route test from
Step 1 were observed on an NSSA area. The following devices were examined:
•
egdal-6506-c1
•
egdal-6506-c2
•
egdal-7206-w3
•
egdal-7505-w4
•
eghou-3660-vw
•
egsaf-2651-vw
OSPF internal route flap test: The effects of the BGP add and remove summary initiating route test from
Step 1 were observed on area 0. The following devices were examined:
•
egdal-6506-c1
•
egdal-6506-c2
•
egdal-7206-w3
•
egdal-7505-w4
•
eghou-3660-vw
•
egsaf-2651-vw
Step 8
In the PIX failover test, the testers attached a failover cable between a primary and secondary PIX device
but disabled failover (no failover command was used on the PIX device).
Step 9
The QoS add and remove class map test removed a class map from the configuration.
Step 10
The QoS add and remove policy map test removed a policy map from the configuration.
Step 11
The QoS add and remove service policy test removed a service policy from the configuration.
Step 12
The VTP add and remove VLAN test added and removed VLANs from switch ports, provided a load on
the VTP structure, and dynamically allocated VLANs on and off of trunks.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
37
Supplementary Information
Expected Results
It was expected the nondestructive negative tests should not result in traffic loss and network instability.
Supplementary Information
The following sections provide additional information about the phase 4 testing:
•
Device Characteristics, page 38
•
Technical Notes, page 59
Device Characteristics
Table 5 lists available information about the platforms, including both Cisco IOS and CatOS software
images and hardware, that were used in the phase 4 testing.
Table 5
Device Characteristics for the Phase 4 Test Bed
Device Name
Platform
Software Version
Image Name
Cisco 2651
12.3(12)fc2
c2600-js-mz.123-12.fc2
Hardware
Boston Campus
egbos-2651-v1
egbos-2811-w4
Cisco 2811
12.3(8)T5
c2800nm-adventerprisek9
-mz.123-8.T5
•
Slot 0: CISCO2651 mainboard
•
WIC 1: WIC-1B-U
•
Slot 1: NM-HDV
•
Slot 0: VWIC-2MFT-T1-DI
•
Slot 0: Part number 73-7214-05
•
Slot 0: Part number 73-8539-03
•
Slot 0: VWIC-1MFT-T1
•
Slot 3: Part number 73-8477-03
•
Slot 1: NM-HDV (possibly
PVDM-12s onboard)
egbos-4006-a2
Cisco Catalyst 12.2(18)EW2
4000
cat4000-k8
—
egbos-4006-a3
Cisco Catalyst 12.2(18)EW2
4000
cat4000-k8
—
egbos-6506-a1
Cisco Catalyst 12.2(18)SXD2
6000
cat6000-sup2k8
—
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
38
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
egbos-6506-c1
Cisco Catalyst 12.2(18)SXD2
WS-C6506
egbos-6506-c2
egbos-7206-w1
Software Version
Cisco Catalyst 12.2(18)SXD2
WS-C6506
Cisco
7206VXR
12.3(12)fc2
Image Name
s72033-ps-mz.122-18.SX
D2
s72033-ps-mz.122-18.SX
D2
C7200-JS-M
Hardware
•
3 – SFM-capable 16-port 1000
MB GBIC modules
(WS-X6516-GBIC) for 16 ports
•
4 – 48-port 10/100 MB RJ-45
Ethernet modules
(WS-X6248-RJ-45) for 48 ports
•
2 – Supervisor Engine 720
modules (WS-SUP720-BASE)
for 6 ports
•
6 – Policy Feature Card 3
submodules (WS-F6K-PFC3A)
•
6 – MSFC3 submodules
(WS-SUP720)
•
3 – SFM-capable 16-port 1000
MB GBIC modules
(WS-X6516-GBIC) for 16 ports
•
4 – 48-port 10/100 MB RJ-45
Ethernet modules
(WS-X6248-RJ-45) for 48 ports
•
2 – Supervisor Engine 720
modules (WS-SUP720-BASE)
for 6 ports
•
4 – Inline power modules
(WS-F6K-PWR)
•
6 – Policy Feature Card 3
submodules (WS-F6K-PFC3A)
•
6 – MSFC3 submodules
(WS-SUP720)
•
Slot 0: C7200-I/O-FE
•
Slot 1: PA-FE-TX
•
Slot 2: PA-FE-TX
•
Slot 3: PA-FE-TX
•
Slot 4: PA-2T3+
•
Slot 6: CX-FEIP2-TX port
(unsupported in a VIP)
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
39
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
Software Version
Image Name
egbos-7206-w2
Cisco
7206VXR
12.3(12)fc2
C7200-JS-M
egbos-7206-w3
Cisco
7206VXR
12.3(12)fc2
C7200-JK9S-M
Hardware
•
Slot 0: C7200-I/O-FE
•
Slot 1: PA-FE-TX
•
Slot 2: PA-FE-TX
•
Slot 3: PA-2T3+
•
Slot 4: PA-FE-TX
•
Slot 5: PA-FE-TX
•
Slot 6: PA-MC-2T1
•
Slot 1: SA-ISA or SM-ISM
•
Slot 2: PA-GE
•
Slot 3: PA-MC-2T1
•
Slot 4: PA-A3-8T1IMA
•
Slot 5: PA-8E
•
Slot 6: PA-4B-U
•
Slot 0: NM-2FE2W
•
Slot 1: NM-2V
•
VIC 0: VIC-2FXS
•
Slot 2: NM-HDV
•
Slot 0: VWIC-2MFT-T1-DI
•
Slot 3: NM-HDV (possibly
PVDM-12s onboard)
•
Slot 0: VWIC-2MFT-T1-DI
•
Slot 0: CISCO3660-MB-2FE
•
Slot 2: NM-4E
Dallas Campus
egdal-3640-v
Cisco 3640
egdal-3660-w5
Cisco 3660
12.3(12)fc2
12.3(12)fc2
c3640-a3js-mz.123-12.fc2
c3660-ik9su2-mz.123-12.
fc2
egdal-6506-c1msfc2
Cisco Catalyst 12.2(22)E2
6500
—
—
egdal-6506-c2
Cisco Catalyst 12.2(14)SY3
6500
—
—
egdal-7206-w1
Cisco
7206VXR
C7200-JK9S-M
12.3(12)fc2
•
Slot 0: C7200-I/O-FE
•
Slot 1: PA-FE-TX
•
Slot 2: PA-FE-TX
•
Slot 3: SA-ISA or SM-ISM
•
Slot 4: PA-A3-E3
•
Slot 5: PA-8E
•
Slot 6: PA-4T+
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
40
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
Software Version
Image Name
egdal-7206-w2
Cisco
7206VXR
12.3(12)fc2
C7200-JK9S-M
egdal-7206-w3
egdal-7507-w4
Cisco
7206VXR
Cisco 7500
12.3(12)fc2
12.3(12)fc2
C7200-JK9S-M
c3660-ik9su2-mz.123-12.
fc2
Hardware
•
Slot 0: C7200-I/O-FE
•
Slot 1: PA-FE-TX
•
Slot 2: PA-FE-TX
•
Slot 3: PA-MC-E3
•
Slot 4: PA-FE-TX
•
Slot 5: PA-8E
•
Slot 6: PA-MC-8E1/120
•
Slot 0: C7200-I/O-FE
•
Slot 1: PA-FE-TX
•
Slot 2: PA-FE-TX
•
Slot 3: PA-A3-8E1IMA
•
Slot 4: SA-ISA or SM-ISM
•
Slot 5: PA-4E
•
Slot 6: PA-MC-2E1/120
•
Slot 0: CISCO3660-MB-2FE
•
Slot 1: NM-2V
•
VIC 0: VIC-2FXS
•
VIC 1: VIC-2FXS
•
Slot 3: NM-1CE1B
•
Slot 5: NM-HDV
•
Slot 0: VWIC-2MFT-T1-DI
•
Slot 6: NM-2CT1-CSU
•
Slot 0: Cisco 2611XM
mainboard
•
WIC 1: WIC-1B-U
•
Slot 0: NM-2FE2W
•
Slot 1: NM-1FE-TX
•
Slot 2: NM-2V
•
VIC 0: VIC-2FXS
•
VIC 1: VIC-2FXO
•
Slot 3: NM-HDV
•
Slot 0: VWIC-2MFT-T1-DI
Denver Campus
egden-2600-isdn Cisco
2621XM
egden-3640-v
egden-4003-a2
Cisco 3640
12.3(12)fc2
12.3(12)fc2
Cisco Catalyst 8.2(1)GLX
4000
c2600-js-mz.123-12.fc2
c3640-a3js-mz.123-12.fc2
cat4000-k8
—
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
41
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
egden-4506-a3
Image Name
Hardware
Cisco Catalyst 12.2(18)EW2
4000
cat4000-I5S-M
—
egden-6506-a1
Cisco Catalyst 12.2(18)SXD2
6500
cat6000-sup2k8
—
egden-6506-c1
Cisco Catalyst 12.2(18)SXD2
WS-C6506
c6k222-jsv-mz.122-18.SX
D2
egden-6506-c2
Software Version
Cisco Catalyst 12.2(18)SXD2
WS-C6506
c6k222-jsv-mz.122-18.SX
D2
•
1 – Cisco Catalyst 6000
Supervisor 2 module
(WS-X6K-S2U-MSFC2) for 2
ports
•
3 – SFM-capable 16-port 1000
MB GBIC modules
(WS-X6516-GBIC) for 16 ports
•
4 – 48-port 10/100 MB RJ45
modules (WS-X6348-RJ-45) for
48 ports
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
•
4 – Inline power modules
(WS-F6K-PWR)
•
1 – Cisco Catalyst 6000
Supervisor 2 modules
(WS-X6K-S2U-MSFC2) for 2
ports
•
3 – SFM-capable 16-port
1000 MB GBIC modules
(WS-X6516-GBIC) for 16 ports
•
4 – 48-port 10/100MB RJ45
modules (WS-X6348-RJ-45) for
48 ports
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
•
4 – Inline power modules
(WS-F6K-PWR)
egden-6506-d1msfc
Cisco Catalyst 12.1(23)E1
6500 MSFC
c6msfc-jsv-mz.121-23.E1 —
egden-6506-d2msfc
Cisco Catalyst 12.1(23)E1
6500 MSFC
c6msfc-jsv-mz.121-23.E1 —
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
42
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
Software Version
Image Name
egden-7206-w1
Cisco
7206VXR
12.3(12)fc2
C7200-JS-M
egden-7206-w2
egden-7206-w3
egden-7507-w4
Cisco
7206VXR
Cisco
7206VXR
Cisco 7507
(Cisco RSP8)
12.3(12)fc2
12.3(9.10)T
12.3(12)fc2
C7200-JS-M
C7200-JK9S-M
rsp-jk9sv-mz.123-12
Hardware
•
Slot 1: PA-FE-TX
•
Slot 2: PA-FE-TX
•
Slot 3: PA-FE-TX
•
Slot 4: PA-A3-T3
•
Slot 1: PA-FE-TX
•
Slot 2: PA-FE-TX
•
Slot 3: PA-A3-T3
•
Slot 4: PA-FE-TX
•
Slot 5: PA-8E
•
Slot 6: PA-MC-4T1
•
Slot 0: C7200-I/O-FE
•
Slot 1: PA-FE-TX
•
Slot 2: PA-FE-TX
•
Slot 3: PA-MC-2T1
•
Slot 4: PA-8E
•
Slot 5: PA-A3-8T1IMA
•
Slot 6: SA-ISA or SM-ISM
•
Slot 0: GEIP w/ 128MB DRAM,
4096 KB SRAM
•
Slot 1: GEIP w/ 128MB DRAM,
4096 KB SRAM
•
Slot 2: RSP8
•
Slot 4: VIP4-80 with 256 MB
DRAM, 65536 KB SRAM
– Bay 0: PA-8E
– Bay 1: PA-FE-TX
•
Slot 5: VIP4-80 with 256 MB
DRAM, 65536 KB SRAM
– Bay 0: PA-MC-4T1
– Bay 1: PA-A3-8T1IMA
•
Slot 31: MAS-7500CI
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
43
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
Software Version
Image Name
Cisco 3640
12.3(12)fc2
c3640-js-mz.123-12.fc2
Hardware
San Jose Campus
egsj-3640-v
egsj-3745-gk
Cisco 3745
egsj-4006-b1a1
Slot 0: NM-2E2W
•
Slot 1: NM-1FE-TX
•
Slot 2: NM-2V
•
VIC 0: VIC-2FXS
•
VIC 1: VIC-2FXO
•
Slot 3: NM-HDV (possibly
PVDM-12s onboard)
•
Slot 0: VWIC-2MFT-T1-DI
C3745-JSX-M
—
Cisco Catalyst 8.2(1)GLX
4000
cat4000-k8
—
egsj-4006-b2a1
Cisco Catalyst 12.2(18)EW2
4000
cat4000-k8
—
egsj-4006-b2d1
Cisco Catalyst 12.2(18)EW2
WS-C4006
cat4000-i5s-mz.122-18.E
W2
egsj-4506-b2d2
12.3(12)fc2
•
Cisco Catalyst 12.2(18)EW2
WS-C4506
cat4000-i5s-mz.122-18.E
W2
•
1 – 1000BaseX (GBIC)
Supervisor module (WS-X4014)
for 2 ports
•
2 – 1000BaseX (GBIC) modules
(WS-X4306-GB) for 6 ports
•
3 – 10/100BaseTX (RJ45)
modules (WS-X4232-RJ-XX)
for 32 ports
•
1 – 1000BaseX (GBIC)
Supervisor module (WS-X4014)
for 2 ports
•
2 – 10/100BaseTX (RJ45)
modules (WS-X4232) for 34
ports
egsj-5505-b1a2
Cisco Catalyst 6.4(3)
5500
cat5000-sup3
—
egsj-5505-sa1
Cisco Catalyst 6.4(3)
5500
—
—
egsj-5505-sa2
Cisco Catalyst 6.4(3)
5500
cat5000-sup3
—
egsj-6506-b1a3
Cisco Catalyst 12.2(18)SXD2
6500
cat6000-sup2k8
—
egsj-6506-b1d1
Cisco Catalyst 12.2(23)E1
6500 (Cisco
MSFC2)
c6msfc2-jsv-mz.121-23.E —
1
egsj-6506-b1d1- Cisco Catalyst 8.3(1)
sup
6500
cat6000-sup2k8
—
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
44
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
Software Version
egsj-6506-b1d2
Cisco Catalyst 12.2(18)SXD2
WS-C6506
Image Name
c6k222-jsv-mz.122-18.SX
D2
Hardware
•
1 – Cisco Catalyst 6000
Supervisor 2 module
(WS-X6K-S2U-MSFC2) for 2
ports
•
2 – SFM-capable 16-port 1000
MB GBIC (WS-X6516-GBIC)
for 16 ports
•
3 – 2-port OC-12 ATM MM
modules
(WS-X6101-OC12-MMF) for 2
ports
•
4 – T1 modules (WS-X6608-T1)
for 8 ports
•
5 – T1 modules (WS-X6608-T1)
for 8 ports
•
6 – 48-port 10/100 MB RJ45
modules (WS-X6148-RJ-45) for
48 ports
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
egsj-6506-b2a2
Cisco Catalyst 8.3(1)
6500
cat6000-sup2k8
—
egsj-6506-sa3
Cisco Catalyst 12.2(18)SXD2
6500
cat6000-sup2k8
—
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
45
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
egsj-6506-sd1
Cisco Catalyst 12.2(18)SXD2
WS-C6506
egsj-6506-sd2
Software Version
Cisco Catalyst 12.2(18)SXD2
WS-C6506
Image Name
c6k222-jsv-mz.122-18.SX
D2
c6k222-jsv-mz.122-18.SX
D2
Hardware
•
1 – Cisco Catalyst 6000
Supervisor 2 module
(WS-X6K-S2U-MSFC2) for 2
ports
•
2 – SFM-capable 16-port 1000
MB GBIC (WS-X6516-GBIC)
modules for 16 ports
•
3 – 48-port 10/100 MB RJ45
modules (WS-X6148-RJ-45) for
48 ports
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
•
2 – Distributed Forwarding
Cards (WS-F6K-DFC)
•
1 – Catalyst 6000 Supervisor 2
module (WS-X6K-S2U-MSFC2)
for 2 ports
•
2 – SFM-capable 16-port 1000
MB GBIC (WS-X6516-GBIC)
for 16 ports
•
3 – 48-port 10/100 MB RJ45
modules (WS-X6148-RJ-45) for
48 ports
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
•
2 – Distributed Forwarding
Cards (WS-F6K-DFC)
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
46
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
Software Version
egsj-6509-c1
Cisco Catalyst 12.2(18)SXD2
WS-C6509
Image Name
c6k222-jsv-mz.122-18.SX
D2
Hardware
•
1 – Cisco Catalyst 6000
Supervisor 2 module
(WS-X6K-SUP2-2GE) for 2
ports
•
3 – Pure SFM-mode 16 port 1000
MB GBIC modules
(WS-X6816-GBIC) for 16 ports
•
6 – 48-port 10/100 MB RJ45
modules (WS-X6348-RJ-45) for
48 ports
•
5 – Switching Fabric
Module-128 modules
(WS-C6500-SFM)
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
•
3 – Distributed Forwarding
Cards (WS-F6K-DFC)
•
6 – Inline power modules
(WS-F6K-PWR)
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
47
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
Software Version
egsj-6509-c2
Cisco Catalyst 12.2(18)SXD2
WS-C6509
Image Name
c6k222-jsv-mz.122-18.SX
D2
Hardware
•
1– Cisco Catalyst 6000
Supervisor 2 module
(WS-X6K-SUP2-2GE) for 2
ports
•
3 – Pure SFM-mode 16 port 1000
MB GBIC modules
(WS-X6816-GBIC) for 16 ports
•
6 – 48-port 10/100 MB RJ45
modules (WS-X6148-RJ-45) for
48 ports
•
7 – 48-port 10/100 MB RJ45
modules (WS-X6148-RJ-45) for
48 ports
•
5 – Switching Fabric
Module-128 modules
(WS-C6500-SFM)
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
•
3 – Distributed Forwarding
Cards (WS-F6K-DFC)
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
48
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
Software Version
egsj-6509-c3
Cisco Catalyst 12.2(18)SXD2
WS-C6509
Image Name
c6k222-jsv-mz.122-18.SX
D2
Hardware
•
1– Cisco Catalyst 6000
Supervisor 2 module
(WS-X6K-SUP2-2GE) for 2
ports
•
3 – Pure SFM-mode 16 port 1000
MB GBIC modules
(WS-X6816-GBIC) for 16 ports
•
4 – 48-port 10/100 MB RJ45
modules (WS-X6348-RJ-45) for
48 ports
•
5 – Switching Fabric
Module-128 modules
(WS-C6500-SFM)
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
•
3 – Distributed Forwarding
Cards (WS-F6K-DFC)
•
4 – Inline power modules
(WS-F6K-PWR)
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
49
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
egsj-6509-c4
Cisco Catalyst 12.2(18)SXD2
WS-C6509
egsj-7206-w3
egsj-7206-w4
Cisco 7206
XVR
Cisco 7206
XVR
Software Version
12.3(12)fc2
12.3(12)fc2
Image Name
c6k222-jsv-mz.122-18.SX
D2
C7200-JK9S-M
C7200-JK9S-M
Hardware
•
1– Cisco Catalyst 6000
Supervisor 2 module
(WS-X6K-S2U-MSFC2) for 2
ports
•
3 – Pure SFM-mode 16 port 1000
MB GBIC modules
(WS-X6816-GBIC) for 16 ports
•
4 – 48-port 10/100 MB RJ45
modules (WS-X6348-RJ-45) for
48 ports
•
5 – Switching Fabric
Module-128 modules
(WS-C6500-SFM)
•
7 – 48-port 10/100 MB RJ45
modules (WS-X6148-RJ-45) for
48 ports
•
8 – SFM-capable 16-port
10/100/1000 MB RJ45 modules
(WS-X6516-GE-TX) for 16
ports
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
•
3 – Distributed Forwarding
Cards (WS-F6K-DFC)
•
4 – Inline power modules
(WS-F6K-PWR)
•
7 – Inline power modules
(WS-F6K-PWR)
•
Slot 3: PA-FE-TX
•
Slot 4: PA-MC-2T1
•
Slot 5: PA-A3-OC3MM
•
Slot 6: Part number 73-8491-02
•
Slot 1: SA-VAM
•
Slot 4: PA-2T3+
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
50
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
egsj-7609-w1
Cisco Catalyst 12.2(18)SXD2
OSR-7609
egsj-7609-w2
Software Version
Cisco Catalyst 12.2(18)SXD2
OSR-7609
Image Name
c6k222-jk9sv-mz.122-18.
SXD2
c6k222-jsv-mz.122-18.SX
D2
Hardware
•
1– Cisco Catalyst 6000
Supervisor 2 module
(WS-X6K-S2U-MSFC2) for 2
ports
•
2 – 2-port adapter FlexWAN
modules (WS-X6182-2PA)
•
4 – 2-port adapter FlexWAN
modules (WS-X6182-2PA)
•
5 – Switching Fabric
Module-128 modules
(WS-C6500-SFM)
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
•
8 – Inline power modules
(WS-F6K-PWR)
•
1– Cisco Catalyst 6000
Supervisor 2 module
(WS-X6K-S2U-MSFC2) for 2
ports
•
2 – 2-port adapter FlexWAN
modules (WS-X6182-2PA)
•
3 – 2-port adapter FlexWAN
modules (WS-X6182-2PA)
•
4 – 48-port 10/100 MB RJ45
modules (WS-X6348-RJ-45) for
48 ports
•
5 – Switching Fabric
Module-128 modules
(WS-C6500-SFM)
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
51
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
Software Version
Image Name
Cisco3660
12.3(12)fc2
c3660-js-mz.123-12.fc2
Hardware
Washington, D.C.
Campus
egwas-3660-v
egwas-6506-c1
Cisco Catalyst 12.2(18)SXD2
WS-C6506
c6k222-jk9sv-mz.122-18.
SXD2
•
Slot 0: CISCO3660-MB-2FE
•
Slot 1: NM-HDV (possibly
PVDM-12s onboard
•
Slot 0: VWIC-2MFT-T1-DI
•
Slot 2: NM-2V
•
VIC 0: VIC-2FXS
•
VIC 1: VIC-2FXS
•
Slot 4: NM-HDV (possibly
PVDM-12s onboard -- please
check)
•
Slot 0: VWIC-2MFT-T1-DI
•
1 – Cisco Catalyst 6000
Supervisor 2 module
(WS-X6K-S2U-MSFC2) for 2
ports
•
2 – SFM-capable 16-port
1000 MB GBIC
(WS-X6516-GBIC) for 16 ports
•
5 – IPSec VPN Accelerator
modules (WS-SVC-IPSEC-1) for
2 ports
•
6 – SFM-capable 48-port 10/100
Mbps RJ45 modules
(WS-X6548-RJ-45) for 48 ports
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
52
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
egwas-6506-c2msfc
Cisco Catalyst 121(23)E1
6506 (Cisco
MSFC2)
egwas-6506-sd1
Software Version
Cisco Catalyst 12.2(18)SXD2
WS-C6506
Image Name
c6msfc2-jsv-mz.121-23.E
1
c6k222-jsv-mz.122-18.SX
D2
Hardware
•
1 – Cisco Catalyst 6000
Supervisor 2 module
(WS-X6K-S2U-MSFC2) for 2
ports
•
6 – SFM-capable 48-port 10/100
Mbps RJ45 modules
(WS-X6548-RJ-45) for 48 ports
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
•
1 – Cisco Catalyst 6000
Supervisor 2 module
(WS-X6K-S2U-MSFC2) for 2
ports
•
6 – SFM-capable 48-port 10/100
Mbps RJ45 modules
(WS-X6548-RJ-45) for 48 ports
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
53
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
Software Version
Image Name
egwas-7507-w3
Cisco 7507
(Cisco RSP8)
12.3(12)fc2
rsp-jsv-mz.123-12.fc2
Hardware
•
Slot 0: GEIP w/ 128MB DRAM,
4096KB SRAM
•
Slot 1: VIP2-50 w/ 32MB
DRAM, 8192KB SRAM
– Bay 0: PA-FE-TX
– Bay 1: PA-FE-TX
•
Slot 2: RSP8
•
Slot 3: RSP8
•
Slot 4: VIP4-80 w/ 256MB
DRAM, 65536KB SRAM
– Bay 0: PA-MC-8T1
– Bay 1: PA-A3-T3
•
Slot 5: GEIP w/ 128MB DRAM,
4096KB SRAM
•
Slot 6: VIP2-40 w/ 64MB
DRAM, 2048KB SRAM
– Bay 0: CX-FEIP2-TX port
(unsupported in a VIP)
egwas-7609-w1
Cisco Catalyst 12.2(18)SXD2
OSR-7609
c6k222-jsv-mz.122-18.sx
d2
•
Slot 31: MAS-7500CI
•
1 – Cisco Catalyst 6000
Supervisor 2 module
(WS-X6K-S2U-MSFC2) for 2
ports
•
3 – 2-port adapter FlexWAN
modules (WS-X6182-2PA)
•
4 – 2-port adapter FlexWAN
modules (WS-X6182-2PA)
•
5 – 48-port 10/100 MB RJ45
modules (WS-X6348-RJ-45) for
48 ports
•
6 – 8-port 1000 MB GBIC
enhanced QoS modules
(WS-X6408A-GBIC) for 8 ports
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
54
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
Software Version
egwas-7609-w2
Cisco Catalyst 12.2(18)SXD2
OSR-7609
Image Name
c6k222-jsv-mz.122-18.sx
d2
Hardware
•
1 – Cisco Catalyst 6000
Supervisor 2 module
(WS-X6K-S2U-MSFC2) for 2
ports
•
3 – 2-port adapter FlexWAN
modules (WS-X6182-2PA)
•
4 – 48-port 10/100 MB RJ45
Ethernet modules
(WS-X6248-RJ-45) for 48 ports
•
6 – 8-port 1000 MB GBIC
enhanced QoS modules
(WS-X6408A-GBIC) for 8 ports
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
•
Slot 0: NM-VPN/MP
•
Slot 1: NM-2FE2W
•
WIC 0: WIC-1DSU-T1
•
Slot 2: NM-4E
c2600-jk9s-mz.123-12.fc
2
•
Slot 0: Part number 73-7754-02
•
WIC 1: WIC-1T
c1700-k9o3sv8y7-mz.123
-12.fc2
•
Slot 0: Cisco1760 mainboard
•
Slot 0: PVDM-256K-4
•
WIC 0: WIC-2T
•
WIC 1: WIC-1ENET
•
Slot 0: Cisco 2651 mainboard
•
WIC 0: WIC-1DSU-T1
•
WIC 1: WIC-1DSU-T1
•
Slot 1: NM-2V
•
VIC 0: VIC-2FXS
•
VIC 1: VIC-2FXS
Remote Campuses
egarl-3640-w1
egaus-2621-w1
egboc-1760-w1
egcs-2651-vw
egcs-2950-a
Cisco 3640
12.3(12)fc2
Cisco
2621XM
12.3(12)fc2
Cisco 1760
12.3(12)fc2
Cisco 2651
12.3(12)fc2
Cisco Catalyst 12.1(20)EA1
2950T-24
c3640-jk9s-mz.123-12.fc
2
c2600-js-mz.123-12.fc2
C2950-I6Q4L2-M
—
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
55
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
eghou2-2821-vw Cisco 2821
Software Version
Image Name
12.3(11)T2
c2800nm-adventerprisek9
-mz.123-11.T2
eghou-3550-a
Cisco Catalyst 12.1(20)EA1
3550-12T
C3550-I5Q3L2-M
eghou-3660-vw
Cisco 3660
c3660-ik9su2-mz.123-12.
fc2
egla2-2851-vw
Cisco 2851
12.3(12)fc2
12.3(11)T2
c2800nm-adventerprisek9
_ivs-mz.123-11.T2
egla-3550-a
Cisco Catalyst 12.1(20)EA1
3550-12T
C3550-I5Q3L2-M
egla-3745-vw
Cisco 3745
c3745-jk9s-mz.123-12.fc
2
12.3(12)fc2
Hardware
•
Slot 0: Part number 73-8854-07
•
Slot 0: Part number 73-8539-03
•
WIC 0: WIC-2T
•
Slot 1: Part number 73-8346-03
•
Slot 2: Part number 73-8476-02
•
Slot 3: Part number
800-21341-01
•
Slot 1: NM-HDV (possibly
PVDM-12s onboard)
•
Slot 0: VWIC-2MFT-T1-DI
—
•
Slot 0: CISCO3660-MB-2FE
•
Slot 1: NM-2V
•
VIC 0: VIC-2FXS
•
VIC 1: VIC-2FXS
•
Slot 3: NM-1CE1B
•
Slot 5: NM-HDV (possibly
PVDM-12s onboard)
•
Slot 0: VWIC-2MFT-T1-DI
•
Slot 6: NM-2CT1-CSU
•
Slot 0: Part number 73-8282-07
•
Slot 0: Part number 73-8539-03
•
Slot 0: VWIC-2MFT-T1-DI
•
Slot 1: Part number
800-21341-01
•
Slot 1: Part number 73-6593-01
—
•
Slot 0: Part number
800-15934-03
•
Slot 2: NM-2V
•
VIC 0: VIC-2FXS
•
VIC 1: VIC-2FXS
•
Slot 3: NM-2CT1-CSU
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
56
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
egmia-3640-vw2 Cisco 3640
egmia-6506-a1
egmia-6506-a2
egmia-7206-w1
Software Version
Image Name
12.3(12)fc2
c3640-js-mz.123-12.fc2
Cisco Catalyst 12.2(18)SXD2
WS-C6506
Cisco Catalyst 12.2(18)SXD2
WS-C6506
Cisco 7206
12.3(12)fc2
egneo-2651-vw
Cisco 2651
12.3(12)fc2
egneo-2950-a
Cisco Catalyst 12.1(20)EA1
2950T-24
c6k222-jsv-mz.122-18.SX
D2
c6k222-jsv-mz.122-18.SX
D2
C7200-JS-M
Hardware
•
Slot 0: NM-2FE2W
•
Slot 1: NM-2FE2W
•
WIC 1: WIC-1DSU-T1
•
Slot 2: NM-2V
•
VIC 0: VIC-2FXS
•
Slot 3: NM-HDV
•
Slot 0: VWIC-2MFT-T1-DI
•
1 – Cisco Catalyst 6000
Supervisor 2 module
(WS-X6K-SUP2-2GE) for 2
ports
•
3 – 48-port 10/100 MB RJ45
modules (WS-X6348-RJ-45) for
48 ports
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
•
3 – Inline power modules
(WS-F6K-PWR)
•
1 – Cisco Catalyst 6000
Supervisor 2 module
(WS-X6K-SUP2-2GE) for 2
ports
•
3 – 48-port 10/100 MB RJ45
modules (WS-X6348-RJ-45) for
48 ports
•
1 – Policy Feature Card 2
submodule (WS-F6K-PFC2)
•
1 – Cisco Catalyst 6000 MSFC 2
daughterboard
(WS-F6K-MSFC2)
•
3 – Inline power modules
(WS-F6K-PWR)
•
Slot 1: PA-FE-TX
•
Slot 6: PA-A3-T3
C2600-JS-M
—
C2950-I6Q4L2-M
—
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
57
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
egny-3550-a
egny-3745-vw
Image Name
Hardware
Cisco Catalyst 12.1(20)EA1
3550-12T
C3550-I5Q3L2-M
—
Cisco 3745
c3745-jk9s-mz.123-12.fc
2
egoak-3640-w1
Cisco 3640
egphx-3550-a
egphx-7204-vw
12.3(12)fc2
Slot 0: Part number
800-15934-01
•
WIC 0: WIC-1DSU-T1
•
WIC 1: WIC-1B-U
•
Slot 1: NM-2V
•
VIC 0: VIC-2FXS
•
VIC 1: VIC-2FXS
—
Cisco Catalyst 12.1(20)EA1
3550-12T
C3550-I5Q3L2-M
—
Cisco 7204
C7200-JK9S-M
Cisco 2851
12.3(12)fc2
•
C3640-IK9O3S-M
egphx2-3845-vw Cisco 3800
egpit2-2851-vw
Software Version
12.3(12)fc2
12.3(11)T2
12.3(11)T2
c3845-advipservicesk9-m
z.123-11.T2
c2800nm-adventerprisek9
_ivs-mz.123-11.T2
•
Slot 0: C7200-I/O-GE+E
•
Slot 3: PA-VXC-2TE1+
•
Slot 4: PA-MC-2T1
•
Slot 0: Part number 73-8799-04
•
Slot 0: Part number 73-8541-03
•
Slot 0: Part number 73-8346-03
•
Slot 1: VWIC-2MFT-T1
•
Slot 3: Part number 73-8477-03
•
Slot 1: Part number
800-21591-01
•
Slot 0: Part number
800-21341-01
•
Slot 4: Part number
800-23372-01
•
Slot 0: Part number 73-8282-07
•
Slot 0: Part number 73-8539-03
•
Slot 1: Part number 73-8539-03
•
Slot 0: VWIC-2MFT-T1-DI
•
Slot 1: Part number 73-8346-04
•
Slot 2: Part number
800-21341-01
•
Slot 3: VWIC-2MFT-T1-DI
•
Slot 1: Part number 73-6593-01
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
58
Supplementary Information
Table 5
Device Characteristics for the Phase 4 Test Bed (continued)
Device Name
Platform
Software Version
Image Name
egpit-3550-a
Cisco
3550-12T
12.3(11)T2
c3825-advipservicesk9-m
z.123-11.T2
egpit-3825-vw
egsaf-2651-vw
Cisco 3825
Cisco 2651
12.3(11)T2
12.3(12)fc2
c3825-advipservicesk9-m
z.123-11.T2
c2600-js-mz.123-12.fc2
egsaf-2950-a
Cisco Catalyst 12.1(20)EA1
2950T-24
C2950-I6Q4L2-M
egsan-2611xmw1
Cisco
2611XM
c2600-js-mz.123-12.fc2
egsfo-3745-w1
Cisco 3745
12.3(12)fc2
12.3(12)fc2
c3745-jk9s-mz.123-12.fc
2
Hardware
•
Slot 0: Part number 73-4021-06
•
Slot 0: Part number 73-8541-03
•
Slot 1: Part number 73-8541-03
•
Slot 0: VWIC-2MFT-T1
•
Slot 2: Part number
800-21341-01
•
Slot 2: Part number 73-6593-01
•
Slot 0: Part number 73-4021-06
•
Slot 0: Part number 73-8541-03
•
Slot 1: Part number 73-8541-03
•
Slot 0: VWIC-2MFT-T1
•
Slot 2: Part number
800-21341-01
•
Slot 2: Part number 73-6593-01
•
Slot 0: CISCO2651 Mainboard
•
WIC 0: WIC-1DSU-T1
•
WIC 1: WIC-1DSU-T1
•
Slot 1: NM-2V
•
VIC 0: VIC-2FXS
•
VIC 1: VIC-2FXS
—
•
Slot 0: CISCO2611XM
Mainboard
•
Slot 1: NM-1A-T3
•
Slot 0: Part number
800-15934-01
•
Slot 2: NM-1A-T3
Technical Notes
This section provides technical notes written by the test team about the testing.
Catalyst 6500 with SUP2, PFC2, and MSFC2 needs maximum memory to run Cisco IOS Release 12.2SX image
A Cisco Catalyst 6500 with SUP2, PFC2, and MSFC2 cards running the Cisco IOS Release 12.2SX
image may stop and reload (crash) after a system load due to the insufficient memory. The system may
also not be accessible because of the low memory condition.
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
59
Glossary of Terms
Glossary of Terms
3DES—DES encrypted three times
ABR—Area Border Router
AES—Advanced Encryption Standard
AIM—Advanced Integration Module
AVVID—Architecture for Voice, Video, and Integrated Data
BGP—Border Gateway Protocol
BPDU—bridge protocol data unit
CA—Certificate Authority
CBWFQ—Class-Based Weighted Fair Queueing
CCME—Cisco Call Manager Express
CDP—Cisco Discovery Protocol
CEF—Cisco Express Forwarding
CIC—Callgen Information Center
CoS—class of service
cRTP—Compressed Real-Time Protocol
DSCP—differentiated services code point
eBGP—external Border Gateway Protocol
EIGRP—Enhanced Interior Gateway Routing Protocol
FEC—Fast Ether Channel
FRTS—Frame Relay Traffic Shaping
FXS—Foreign Exchange Station
GEC—Gigabit EtherChannel
GRE—generic routing encapsulation
HSRP—Hot Standby Router Protocol
HSSI—High-Speed Serial Interface
iBGP—internal Border Gateway Protocol
IGMP—Internet Group Management Protocol
IGP—Interior Gateway Protocol
IKE—Internet Key Exchange
ISA—Internet Security Association
ISAKMP—Internet Security Association and Key Management Protocol
ISL—Inter-Switch Link
LEFS—low-end file system
LFI—Link Fragmentation and Interleaving
LLQ—low latency queueing
LSA—link state advertisement
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
60
Glossary of Terms
LZS—Lempel-Ziv-Stac
MD5—Message Digest 5
MDS—Multicast Distributed Switching
MIB—Management Information Base
MLP—Multilink PPP (also MLPPP)
MMLS—multicast multilayer switching
MPLS—Multiprotocol Label Switching
MQC—modular QoS CLI
MSDP—Multicast Source Discovery Protocol
NMS—network management systems
MSFC—Multilayer Switch Feature Card
NAT—Network Address Translation
NSSA—not-so-stubby-area
NTP—Network Time Protocol
OAM—Operation, Administration, and Maintenance
OC—optical carrier
OSPF—Open Shortest Path First
OSR—Optical Services Router
PAT—Port Address Translation
PFC—Policy Feature Card
PIM—Protocol Independent Multicast
PKI—Public Key Infrastructure
POS—packet over SONET
QoS—quality of service
RP—rendezvous point
RPF—Reverse Path Forwarding
RPR+—Route Processor Redundancy Plus
SCCP—Skinny Client Control Protocol
SNMP—Simple Network Management Protocol
STP—Spanning Tree Protocol
UDLD—Unidirectional Link Detect
VAM—VPN Acceleration Module
VTP—VLAN Trunking Protocol
WRED—Weighted Random Early Detection
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
61
Glossary of Terms
Cisco IOS Profiled Releases 12.3(12)fc2, 12.3(8)T5, 12.3(11)T2, 12.2(18)SXD2 and 12.2(18)EW2 Testing for Enterprise Global Customers
62