Cisco IOS Safe Harbor Release 12.1(13)E13 for
Financial Enterprise Customers
Version History
Version Number Date
Notes
1
This document was created upon test plan completion.
March 12, 2004
Executive Summary
Cisco IOS Safe Harbor is an initiative that provides the global financial services enterprise customer
with a stable Cisco IOS 12.1 E version of choice. Safe Harbor focuses on satisfying customer quality
requirements in key vertical markets. This program links and expands upon several Cisco testing
projects, including development, regression testing, and systems testing critical to the success of the
financial services business. Safe Harbor is the successful completion of extensive validated testing for
each release targeting the financial enterprise market.
The Cisco nEverest program will integrate testing for many diverse vertical markets and will leverage
Safe Harbor testing to verify a "holistic" approach to the general improvement of Cisco IOS software.
This document contains the following introductory sections:
•
About Cisco IOS Safe Harbor, page 2
•
Financial Lab Topology, page 2
•
Test Results Summary, page 243
•
DDTS Summary, page 248
•
Test Cases, page 249
This document contains the following test sections:
•
Memory Leak, page 249
•
Hardware Redundancy, page 255
•
Layer 2 Features, page 262
•
Layer 3 Routing Features, page 285
•
Network Management Features, page 442
•
Miscellaneous Features, page 447
Corporate Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Copyright © 2004 Cisco Systems, Inc. All rights reserved.
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
About Cisco IOS Safe Harbor
About Cisco IOS Safe Harbor
The goal of Cisco IOS Safe Harbor is to provide improved network stability, reliability, and performance
with respect to Cisco IOS software. Safe Harbor involves testing the feature sets and protocols in a
particular Cisco IOS Release 12.1 E image on the Catalyst 6500 platform to provide high quality code
for the financial services sector. This combination of features, hardware, and image is tested in a
laboratory environment that simulates the financial services business network environment using
regularly updated topologies and configurations provided by the financial customers. For information on
the hardware tested and the network setup of the test environment, see the “Financial Lab Topology”
section on page 2.
The groups of feature sets that are tested are the following: hardware redundancy, Layer 2 features,
hardware forwarding features, Layer 3 routing features, network management features, and several
miscellaneous features. Regression tests are conducted to validate existing features and verify that
functionality is maintained. Negative tests are designed and conducted to stress the features and their
interoperability. For information on each feature and its testing, see the “Test Cases” section on
page 249.
During the testing, the network is placed under loads that are consistent with those in a financial services
network. A standard suite of tools (for example, Netcom Smartbits, IXIA packet generator, or
Cisco Pagent) is used to generate network traffic. Network testing includes a combination of automated
and manual tests. Simple Network Management Protocol (SNMP) is used to poll the network during the
tests, and all tests are analyzed. For a summary of the test results, see the “Basic Topology: Testbed
Diagrams” section on page 4.
Note
Safe Harbor testing does not address issues that might exist in the customer change control and
operations processes.
Financial Lab Topology
The base Native IOS financial lab topology is defined in the following sections and illustrated in Figure 1
through Figure 12:
•
Basic Topology: Port Channel Deployment, page 3
•
Basic Topology: Routing Protocols, page 3
•
Basic Topology: Testbed Diagrams, page 4
•
Test Device Configurations, page 17
The financial services network environment configured in the lab includes the following hardware:
•
Sixteen Catalyst 6500 switches running Cisco Native IOS Release 12.1(13)E13 (SH1-97 to
SH1-110, SH1-113, and SH1-114)
•
Two Catalyst 6500 switches that are running Hybrid CatOS 6.4(6) train with no routing (Dista-1 and
Dista-2)
•
Pagent test devices to simulate the Internet Service Providers (ISPs), Area 3, and Area 4, injecting
Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), and Enhanced Interior Gateway
Routing Protocol (EIGRP) routes
•
IXIA test devices to generate simulated customer traffic
Cisco IOS Release 12.1(13)E13
2
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
The hardware configuration in the financial test lab includes a combination of distributed fabric,
fabric-capable, and nonfabric modules.
Note
The Switch Fabric Module is supported only with the Supervisor Engine 2 in the Catalyst 6500 series
switch.
Basic Topology: Port Channel Deployment
Figure 1 through Figure 12 show the portchannel deployment for the Safe Harbor testing. Catalyst 6500
series switches running Native Cisco IOS support both Layer 2 and Layer 3 EtherChannels, with up to
eight ports aggregated in a single EtherChannel interface. All interfaces in each EtherChannel must be
identically configured (the same speed, all Layer 2 or Layer 3, and so on).
EtherChannel load balancing can use MAC addresses or IP addresses, and either source or destination
or both source and destination addresses. The selected mode applies to all EtherChannels configured on
the switch.
EtherChannel is a trunking technology that groups multiple full-duplex 802.3 Ethernet interfaces to
provide fault-tolerant high-speed links between switches, routers, and servers. An EtherChannel
interface (consisting of up to eight Ethernet interfaces) is treated as a single interface; this is called a
portchannel.
The portchannels configured for Safe Harbor testing are Gigabit EtherChannels (GECs). The following
types of GEC portchannels are configured and tested for Safe Harbor:
•
Layer 3 GEC distributed forwarding card (DFC)
•
Layer 3 GEC DFC and non-DFC mixed
•
Layer 3 GEC using fabric-capable modules, nonfabric modules, and combinations of both
•
Layer 2 GEC using fabric-capable modules, nonfabric modules, and combinations of both
Basic Topology: Routing Protocols
The following routing protocols are configured for Safe Harbor testing:
•
BGP
– External BGP (eBGP)
– Interior BGP (iBGP)
•
EIGRP
•
OSPF
Figure 1 through Figure 12 shows the following:
•
Where each routing protocol is configured in the basic test lab topology.
•
The eBGP and iBGP routing protocol deployment for the Safe Harbor testing.
•
The EIGRP routing protocol deployment for Safe Harbor testing.
•
OSPF routing protocol areas configured for Safe Harbor testing.
Cisco IOS Release 12.1(13)E13
3
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Basic Topology: Testbed Diagrams
•
Figure 1 on page 5 summarizes hardware module types per device and their position in the chassis.
This data is taken directly from the output of the show module command.
•
Figure 5 on page 9 provides a detailed view of the Safe Harbor network OSPF routing topology.
•
Figure 3 on page 7 provides a detailed view of the Safe Harbor network EIGRP routing topology.
•
Figure 4 on page 8 provides a detailed view of the Safe Harbor network BGP routing topology.
•
Figure 5 on page 9 shows Ether Channeling—Part 1 configuration of the Safe Harbor testbed. It
displays the number of ports in each channel, the Channel ID, the static or dynamic configuration
of the channel, and whether the channel is Layer 3 or Layer 2.
•
Figure 6 on page 10 shows Ether Channeling—Part 2 configuration of the Safe Harbor testbed. It
displays the number of ports in each channel, the Channel ID, the static or dynamic configuration
of the channel, and whether the channel is Layer 3 or Layer 2.
•
Figure 7 on page 11 shows IP Interfaces—Part 1 configuration of the Safe Harbor testbed.
•
Figure 8 on page 12 shows IP Interfaces—Part 1 configuration of the Safe Harbor testbed.
•
Figure 9 on page 13 shows the Safe Harbor network multicast configuration overview based on one
of our largest financial customers. It presents a real-world scenario. This figure shows the extent that
devices participate in the overall multicast scheme, highlighting Multicast Source Discovery
Protocol (MSDP) and Rendezvous Point (RP).
•
Figure 10 on page 14 shows background traffic running to emulate real-world network conditions
with three multicast traversing the network and the devices they cross in a majority of the test plan.
•
Figure 11 on page 15 shows background traffic running to emulate real-world network conditions
four unicast streams traversing the network and the devices they cross in a majority of the test plan.
•
Figure 12 on page 16 shows the Safe Harbor network multicast test traffic configuration based on
one of our largest financial customers. It presents a real-world scenario. This figure shows the extent
that devices participate in the overall multicast scheme, highlighting Multicast Source Discovery
Protocol (MSDP) and Rendezvous Point (RP).
Cisco IOS Release 12.1(13)E13
4
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Figure 1
Safe Harbor Device Modules and Chassis Positions
Cisco IOS Release 12.1(13)E13
5
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Figure 2
Safe Harbor OSPF Routing
Cisco IOS Release 12.1(13)E13
6
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Figure 3
Safe Harbor EIGRP Routing
Cisco IOS Release 12.1(13)E13
7
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Figure 4
Safe Harbor BGP Routing
Cisco IOS Release 12.1(13)E13
8
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Figure 5
Safe Harbor EtherChannel—Part A
Cisco IOS Release 12.1(13)E13
9
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Figure 6
Safe Harbor EtherChannel—Part B
Cisco IOS Release 12.1(13)E13
10
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Figure 7
Safe Harbor IP Interfaces—Part A
Cisco IOS Release 12.1(13)E13
11
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Figure 8
Safe Harbor IP Interfaces—Part B
Cisco IOS Release 12.1(13)E13
12
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Figure 9
Safe Harbor Multicast
Cisco IOS Release 12.1(13)E13
13
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Figure 10
Safe Harbor Background Traffic—Multicast
Cisco IOS Release 12.1(13)E13
14
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Figure 11
Safe Harbor Background Traffic—Unicast
Cisco IOS Release 12.1(13)E13
15
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Figure 12
Safe Harbor Multicast Test Traffic
Cisco IOS Release 12.1(13)E13
16
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Test Device Configurations
The following configuration files were used in the Safe Harbor testbed for the following devices tested.
•
SH1-97, page 17
•
SH1-98, page 30
•
SH1-99, page 41
•
SH1-100, page 54
•
SH1-101, page 68
•
SH1-102, page 81
•
SH1-103, page 99
•
SH1-104, page 112
•
SH1-105, page 123
•
SH1-106, page 137
•
SH1-107, page 151
•
SH1-108, page 164
•
SH1-109, page 177
•
SH1-110, page 193
•
SH1-113, page 209
•
SH1-114, page 221
•
Dista-1, page 232
•
Dista-2, page 237
SH1-97
Go to Financial Lab Topology, page 2
Go to Test Cases, page 249
SH1-97#show config
Using 13544 out of 391160 bytes
!
!
version 12.1
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
no service password-encryption
!
hostname SH1-97
!
boot system flash sup-bootflash:
boot bootldr bootflash:
no logging console
enable secret 5 $1$2F4A$t7Nm9kVDxoJbcdKfoUgkr0
!
clock timezone EST -5
clock summer-time EDT recurring
vtp mode transparent
ip subnet-zero
!
!
Cisco IOS Release 12.1(13)E13
17
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip ftp username safeharbor
ip ftp password shshsh
no ip domain-lookup
!
ip multicast-routing
mls flow ip destination-source
mls flow ipx destination
mls ip multicast consistency-check
!
redundancy
mode rpr-plus
main-cpu
auto-sync startup-config
auto-sync running-config
auto-sync config-register
auto-sync bootvar
auto-sync standard
!
power redundancy-mode combined
!
!
vlan 1
tb-vlan1 1002
tb-vlan2 1003
!
vlan 97
remote-span
!
vlan 294
!
vlan 1002
tb-vlan1 1
tb-vlan2 1003
!
vlan 1003
tb-vlan1 1
tb-vlan2 1002
parent 1005
backupcrf enable
!
vlan 1004
bridge 1
stp type ibm
!
vlan 1005
bridge 15
!
!
interface Loopback0
ip address 172.31.4.97 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 172.31.0.98 255.255.255.255
ip pim sparse-mode
!
interface Loopback110
ip address 10.1.1.1 255.255.255.255
!
interface Loopback111
ip address 11.1.1.1 255.255.255.255
!
interface Loopback112
ip address 12.1.1.1 255.255.255.255
Cisco IOS Release 12.1(13)E13
18
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface Loopback113
ip address 13.1.1.1 255.255.255.255
!
interface Loopback114
ip address 14.1.1.1 255.255.255.255
!
interface Port-channel 11
description sh1-98 po11
ip address 172.31.1.1 255.255.255.252
ip access-group 182 in
ip access-group 182 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel 12
description sh1-99 po12
ip address 172.31.1.5 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel13
description sh1-100 po13
ip address 172.31.1.21 255.255.255.252
ip access-group 182 in
ip access-group 182 out
ip pim sparse-mode
logging event link-status
!
interface GigabitEthernet1/1
description sh1-99 gi2/1
no ip address
logging event link-status
channel-group 12 mode on
!
interface GigabitEthernet1/2
description sh1-100 gi1/2
no ip address
ip access-group 182 in
ip access-group 182 out
logging event link-status
channel-group 13 mode on
!
interface GigabitEthernet2/1
description sh1-99 g1/1
no ip address
logging event link-status
channel-group 12 mode on
!
interface GigabitEthernet2/2
description sh1-100 g2/2
no ip address
ip access-group 182 in
ip access-group 182 out
logging event link-status
channel-group 13 mode on
!
interface GigabitEthernet3/1
description sh1-99 g3/5
no ip address
logging event link-status
channel-group 12 mode on
Cisco IOS Release 12.1(13)E13
19
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface GigabitEthernet3/2
description sh1-100 g3/6
no ip address
ip access-group 182 in
ip access-group 182 out
logging event link-status
channel-group 13 mode on
!
interface GigabitEthernet3/3
no ip address
shutdown
!
interface GigabitEthernet3/4
no ip address
shutdown
!
interface GigabitEthernet3/5
no ip address
shutdown
!
interface GigabitEthernet3/6
no ip address
shutdown
!
interface GigabitEthernet3/7
no ip address
shutdown
!
interface GigabitEthernet3/8
no ip address
shutdown
!
interface GigabitEthernet3/9
description sh1-99 g4/15
no ip address
logging event link-status
channel-group 12 mode on
!
interface GigabitEthernet3/10
description sh1-100 g4/14
no ip address
ip access-group 182 in
ip access-group 182 out
logging event link-status
channel-group 13 mode on
!
interface GigabitEthernet3/11
no ip address
shutdown
!
interface GigabitEthernet3/12
no ip address
shutdown
!
interface GigabitEthernet3/13
no ip address
shutdown
!
interface GigabitEthernet3/14
no ip address
shutdown
!
interface GigabitEthernet3/15
Cisco IOS Release 12.1(13)E13
20
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface GigabitEthernet3/16
no ip address
shutdown
!
interface FastEthernet4/1
no ip address
shutdown
!
interface FastEthernet4/2
no ip address
shutdown
!
interface FastEthernet4/3
no ip address
shutdown
!
interface FastEthernet4/4
no ip address
shutdown
!
interface FastEthernet4/5
no ip address
shutdown
!
interface FastEthernet4/6
no ip address
shutdown
!
interface FastEthernet4/7
no ip address
shutdown
!
interface FastEthernet4/8
no ip address
shutdown
!
interface FastEthernet4/9
no ip address
shutdown
!
interface FastEthernet4/10
no ip address
shutdown
!
interface FastEthernet4/11
no ip address
shutdown
!
interface FastEthernet4/12
no ip address
shutdown
!
interface FastEthernet4/13
no ip address
shutdown
!
interface FastEthernet4/14
no ip address
shutdown
!
interface FastEthernet4/15
Cisco IOS Release 12.1(13)E13
21
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet4/16
no ip address
shutdown
!
interface FastEthernet4/17
no ip address
shutdown
!
interface FastEthernet4/18
no ip address
shutdown
!
interface FastEthernet4/19
no ip address
shutdown
!
interface FastEthernet4/20
no ip address
shutdown
!
interface FastEthernet4/21
no ip address
shutdown
!
interface FastEthernet4/22
no ip address
shutdown
!
interface FastEthernet4/23
no ip address
shutdown
!
interface FastEthernet4/24
description flashnet
ip address 10.194.17.97 255.255.255.0
shutdown
duplex full
!
interface GigabitEthernet7/1
description sh1-98 g7/1
no ip address
ip access-group 182 in
ip access-group 182 out
logging event link-status
channel-group 11 mode on
!
interface GigabitEthernet7/2
description sh1-98 g7/2
no ip address
ip access-group 182 in
ip access-group 182 out
logging event link-status
channel-group 11 mode on
!
interface GigabitEthernet7/3
no ip address
shutdown
!
interface GigabitEthernet7/4
no ip address
shutdown
Cisco IOS Release 12.1(13)E13
22
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface GigabitEthernet7/5
no ip address
shutdown
!
interface GigabitEthernet7/6
no ip address
shutdown
!
interface GigabitEthernet7/7
no ip address
shutdown
!
interface GigabitEthernet7/8
no ip address
shutdown
!
interface GigabitEthernet7/9
no ip address
shutdown
!
interface GigabitEthernet7/10
no ip address
shutdown
!
interface GigabitEthernet7/11
no ip address
shutdown
!
interface GigabitEthernet7/12
no ip address
shutdown
!
interface GigabitEthernet7/13
no ip address
shutdown
!
interface GigabitEthernet7/14
no ip address
shutdown
!
interface GigabitEthernet7/15
no ip address
shutdown
!
interface GigabitEthernet7/16
no ip address
shutdown
!
interface FastEthernet8/1
description rtp-wbu-te-p1 fa0/1
ip address 172.31.1.145 255.255.255.252
speed 100
duplex full
!
interface FastEthernet8/2
no ip address
shutdown
!
interface FastEthernet8/3
no ip address
shutdown
!
interface FastEthernet8/4
Cisco IOS Release 12.1(13)E13
23
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet8/5
no ip address
shutdown
!
interface FastEthernet8/6
no ip address
shutdown
!
interface FastEthernet8/7
no ip address
shutdown
!
interface FastEthernet8/8
no ip address
shutdown
!
interface FastEthernet8/9
no ip address
shutdown
!
interface FastEthernet8/10
no ip address
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
load-interval 30
shutdown
!
interface FastEthernet8/11
description IXIA 4/5
ip address 172.31.97.101 255.255.255.240
ip pim sparse-mode
speed 100
duplex full
!
interface FastEthernet8/12
no ip address
shutdown
!
interface FastEthernet8/13
description Ixia 4/3 - NAT Inside
ip address 172.31.97.1 255.255.255.240
ip nat inside
ip pim sparse-mode
hold-queue 300 in
!
interface FastEthernet8/14
description Ixia 4/4 - NAT Outside
ip address 172.31.97.17 255.255.255.240
ip nat outside
ip pim sparse-mode
hold-queue 300 in
!
interface FastEthernet8/15
no ip address
shutdown
!
interface FastEthernet8/16
no ip address
shutdown
Cisco IOS Release 12.1(13)E13
24
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface FastEthernet8/17
no ip address
!
interface FastEthernet8/18
no ip address
shutdown
!
interface FastEthernet8/19
no ip address
shutdown
!
interface FastEthernet8/20
no ip address
shutdown
!
interface FastEthernet8/21
no ip address
shutdown
!
interface FastEthernet8/22
no ip address
shutdown
!
interface FastEthernet8/23
no ip address
!
interface FastEthernet8/24
description flashnet
ip address 10.194.17.97 255.255.255.0
no ip route-cache
no ip mroute-cache
speed 100
duplex full
!
interface FastEthernet8/25
no ip address
!
interface FastEthernet8/26
no ip address
shutdown
!
interface FastEthernet8/27
no ip address
shutdown
!
interface FastEthernet8/28
no ip address
shutdown
!
interface FastEthernet8/29
no ip address
shutdown
!
interface FastEthernet8/30
no ip address
shutdown
!
interface FastEthernet8/31
no ip address
shutdown
!
interface FastEthernet8/32
no ip address
Cisco IOS Release 12.1(13)E13
25
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface FastEthernet8/33
no ip address
shutdown
!
interface FastEthernet8/34
no ip address
shutdown
!
interface FastEthernet8/35
no ip address
shutdown
!
interface FastEthernet8/36
no ip address
shutdown
!
interface FastEthernet8/37
no ip address
!
interface FastEthernet8/38
no ip address
shutdown
!
interface FastEthernet8/39
no ip address
shutdown
!
interface FastEthernet8/40
no ip address
shutdown
!
interface FastEthernet8/41
no ip address
shutdown
!
interface FastEthernet8/42
no ip address
shutdown
!
interface FastEthernet8/43
no ip address
shutdown
!
interface FastEthernet8/44
no ip address
speed 100
duplex full
!
interface FastEthernet8/45
no ip address
!
interface FastEthernet8/46
no ip address
shutdown
!
interface FastEthernet8/47
description rtp-wbu-te-p4 fa1/0
ip address 172.31.1.141 255.255.255.252
speed 100
duplex full
!
interface FastEthernet8/48
Cisco IOS Release 12.1(13)E13
26
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
description rtp-wbu-te-p4 fa1/1
ip address 172.31.1.157 255.255.255.252
!
interface Vlan1
no ip address
shutdown
!
interface Vlan140
no ip address
shutdown
!
router ospf 1
log-adjacency-changes
auto-cost reference-bandwidth 100000
passive-interface default
no passive-interface FastEthernet8/11
no passive-interface FastEthernet8/48
no passive-interface Port-channel11
no passive-interface Port-channel12
no passive-interface Port-channel13
network 10.1.1.1 0.0.0.0 area 0
network 11.1.1.1 0.0.0.0 area 0
network 12.1.1.1 0.0.0.0 area 0
network 13.1.1.1 0.0.0.0 area 0
network 14.1.1.1 0.0.0.0 area 0
network 172.31.0.0 0.0.0.255 area 0
network 172.31.1.0 0.0.0.7 area 0
network 172.31.1.20 0.0.0.3 area 0
network 172.31.1.156 0.0.0.3 area 6
network 172.31.1.0 0.0.0.255 area 0
network 172.31.2.1 0.0.0.0 area 0
network 172.31.4.0 0.0.0.255 area 0
network 172.31.97.0 0.0.0.255 area 0
maximum-paths 6
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor sh1-ibgp peer-group
neighbor sh1-ibgp remote-as 100
neighbor sh1-ibgp version 4
neighbor sh1-ibgp next-hop-self
neighbor 172.31.1.142 remote-as 10
neighbor 172.31.1.146 remote-as 20
neighbor 172.31.4.98 peer-group sh1-ibgp
neighbor 172.31.4.99 peer-group sh1-ibgp
neighbor 172.31.4.100 peer-group sh1-ibgp
no auto-summary
!
ip nat inside source static 10.2.2.10 100.100.100.10
ip nat outside source static 10.2.2.10 10.50.50.10
ip classless
ip route 0.0.0.0 0.0.0.0 Null0
ip route 10.2.2.0 255.255.255.0 172.31.97.2
ip route 10.50.50.0 255.255.255.0 172.31.97.18
ip route 172.18.177.128 255.255.255.192 10.194.17.254
ip route 172.18.179.128 255.255.255.192 10.194.17.254
no ip http server
ip pim rp-address 172.31.0.98 3 override
ip pim spt-threshold infinity
ip pim send-rp-announce Loopback1 scope 64 group-list 1
ip pim send-rp-discovery Loopback1 scope 64
ip msdp peer 172.31.4.98 connect-source Loopback0
ip msdp description 172.31.4.98 SH1-98
Cisco IOS Release 12.1(13)E13
27
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip msdp sa-filter out 172.31.4.98 list 131
ip msdp mesh-group global 172.31.4.98
ip msdp cache-sa-state
ip msdp originator-id Loopback0
!
!
logging trap debugging
logging 172.18.177.132
access-list 1 permit 239.98.0.0 0.0.255.255
access-list 3 permit 224.0.1.39
access-list 3 permit 224.0.1.40
access-list 15 permit 10.128.0.0 0.0.255.255
access-list 16 deny
170.1.1.0 0.0.0.255
access-list 16 permit any
access-list 30 deny
172.31.1.96
access-list 30 permit any
access-list 94 permit 10.207.0.0 0.0.255.255
access-list 151 permit ip 10.2.2.0 0.0.0.255 any
access-list 152 permit ip 10.2.2.0 0.0.0.31 any
access-list 153 permit ip 10.2.2.32 0.0.0.31 any
access-list 154 permit ip 10.2.2.64 0.0.0.31 any
access-list 155 permit ip 10.2.2.96 0.0.0.31 any
access-list 156 permit ip 10.2.2.128 0.0.0.31 any
access-list 157 permit ip 10.2.2.160 0.0.0.31 any
access-list 158 permit ip 10.2.2.192 0.0.0.31 any
access-list 159 permit ip 10.2.2.224 0.0.0.31 any
access-list 181 permit ip any any
access-list 182 permit ip any any
snmp-server community public RO
snmp-server community cisco RW
!
alias exec ip sh ip int brief | be Port
alias exec eigrp show run | be router eigrp
alias exec ospf sh run | be router ospf
alias exec bgp sh run | be router bgp
!
line con 0
exec-timeout 0 0
line vty 0 4
exec-timeout 0 0
password cisco
login
history size 256
transport input lat pad mop telnet rlogin udptn nasi
line vty 5 10
exec-timeout 0 0
password cisco
login
history size 256
transport input lat pad mop telnet rlogin udptn nasi
!
exception protocol ftp
exception dump 172.18.177.129
exception memory fragment 200000
exception memory minimum 200000
ntp clock-period 17179768
ntp update-calendar
ntp server 172.18.177.131
ntp server 172.18.177.132 prefer
!
monitor session 1 source interface Fa8/13
monitor session 2 source interface Fa8/14
end
Cisco IOS Release 12.1(13)E13
28
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
SH1-97#show version
Cisco Internetwork Operating System Software
IOS (tm) c6sup2_rp Software (c6sup2_rp-JSV-M), Version 12.1(nightly13e.E040229) NIGHTLY
BUILD, synced to cosmos_e V121_12_5_E1
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Mon 01-Mar-04 00:11 by
Image text-base: 0x40008BF0, data-base: 0x41A4C000
ROM: System Bootstrap, Version 12.1(4r)E, RELEASE SOFTWARE (fc1)
SH1-97 uptime is 2 weeks, 2 days, 22 hours, 46 minutes
Time since SH1-97 switched to active is 2 weeks, 2 days, 22 hours, 45 minutes
System returned to ROM by power-on (SP by power-on)
System restarted at 12:58:01 EST Mon Mar 1 2004
System image file is "sup-bootflash:c6sup22-jsv-mz.v121_13_e_throttle.040229"
cisco Catalyst 6000 (R7000) processor with 458752K/65536K bytes of memory.
Processor board ID SAD055205SV
R7000 CPU at 300Mhz, Implementation 39, Rev 2.1, 256KB L2, 1024KB L3 Cache
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
2 Virtual Ethernet/IEEE 802.3 interface(s)
72 FastEthernet/IEEE 802.3 interface(s)
36 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.
16384K bytes of Flash internal SIMM (Sector size 512K).
Standby is up
Standby has 227328K/34816K bytes of memory.
Configuration register is 0x2102
SH1-97#show module
Mod Ports Card Type
--- ----- -------------------------------------1
2 Catalyst 6000 supervisor 2 (Active)
2
2 Catalyst 6000 supervisor 2 (Standby)
3
16 Pure SFM-mode 16 port 1000mb GBIC
4
24 24 port 100FX Multi mode
5
0 Switching Fabric Module-136 (Standby)
6
0 Switching Fabric Module-136 (Active)
7
16 SFM-capable 16 port 1000mb GBIC
8
48 48 port 10/100 mb RJ45
Model
-----------------WS-X6K-S2U-MSFC2
WS-X6K-S2U-MSFC2
WS-X6816-GBIC
WS-X6324-100FX-MM
WS-X6500-SFM2
WS-X6500-SFM2
WS-X6516-GBIC
WS-X6348-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0002.7e38.740c to 0002.7e38.740d
3.2
6.1(3)
2 0001.c9db.4aac to 0001.c9db.4aad
3.9
6.1(3)
3 0002.7ee1.4158 to 0002.7ee1.4167
1.2
12.1(5r)E1
4 0008.a430.08d0 to 0008.a430.08e7
3.0
5.4(2)
5 0001.0002.0003 to 0001.0002.0003
1.1
6.1(3)
6 0001.0002.0003 to 0001.0002.0003
1.1
6.1(3)
7 0009.11e3.5430 to 0009.11e3.543f
5.5
6.3(1)
8 0005.7481.34a8 to 0005.7481.34d7
6.0
5.4(2)
Mod
--1
1
2
2
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-PFC2
WS-F6K-MSFC2
Serial No.
----------SAD060202WE
SAD0628036R
SAD055101LP
SAD055106YN
SAD055204B7
SAD055002UW
SAL06313ZS8
SAL0552FQTY
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
12.1(nightly
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD060204KK
3.0
Ok
SAD055205SV
1.3
Ok
SAD062802C1
3.2
Ok
SAD062803HM
2.5
Ok
Cisco IOS Release 12.1(13)E13
29
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
3 Distributed Forwarding Card WS-F6K-DFC
Mod Online Diag Status
--- ------------------1 Pass
2 Pass
3 Pass
4 Pass
5 Pass
6 Pass
7 Pass
8 Pass
SH1-97#
SAD055102P1
Return to SH1-97, page 17
SH1-98
Go to Test Device Configurations, page 17
Go to Financial Lab Topology, page 2
Go to Test Cases, page 249
SH1-98#show config
Using 11158 out of 391160 bytes
!
!
version 12.1
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
no service password-encryption
!
hostname SH1-98
!
boot system flash sup-bootflash:
boot bootldr bootflash:
no logging console
enable secret 5 $1$TRrh$wAA8amAvRdJKslmhmOEjj1
!
clock timezone EST -5
clock summer-time EDT recurring
ip subnet-zero
!
!
ip ftp username safeharbor
ip ftp password shshsh
no ip domain-lookup
ip domain-name cisco.com
no ip dhcp conflict logging
ip dhcp excluded-address 172.31.20.70
ip dhcp excluded-address 172.31.20.71
ip dhcp excluded-address 172.31.20.1
ip dhcp excluded-address 172.31.20.254
ip dhcp excluded-address 172.31.100.66
ip dhcp excluded-address 172.31.100.67
ip dhcp excluded-address 172.31.100.1
ip dhcp excluded-address 172.31.100.254
!
ip dhcp pool SH1-109-Vlan10
network 172.31.20.0 255.255.255.0
lease 0 0 5
!
Cisco IOS Release 12.1(13)E13
30
2.0
Ok
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip dhcp pool SH1-105-Vlan40
network 172.31.100.0 255.255.255.0
lease 0 0 5
!
ip multicast-routing
mls flow ip destination-source
mls flow ipx destination
mls ip multicast consistency-check
!
redundancy
mode rpr-plus
main-cpu
auto-sync running-config
auto-sync standard
!
power redundancy-mode combined
!
!
!
interface Loopback0
ip address 172.31.4.98 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 172.31.0.98 255.255.255.255
ip pim sparse-mode
!
interface Port-channel11
description sh1-97 po11
ip address 172.31.1.2 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel12
description sh1-99 po112
ip address 172.31.1.17 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel13
description sh1-100 po113
ip address 172.31.1.9 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface GigabitEthernet1/1
no ip address
shutdown
!
interface GigabitEthernet1/2
no ip address
shutdown
!
interface GigabitEthernet2/1
no ip address
shutdown
!
interface GigabitEthernet2/2
Cisco IOS Release 12.1(13)E13
31
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface GigabitEthernet3/1
description sh1-100 g3/5
no ip address
channel-group 13 mode desirable
!
interface GigabitEthernet3/2
description sh1-99 g3/6
no ip address
channel-group 12 mode on
!
interface GigabitEthernet3/3
no ip address
shutdown
!
interface GigabitEthernet3/4
no ip address
shutdown
!
interface GigabitEthernet3/5
no ip address
shutdown
!
interface GigabitEthernet3/6
no ip address
shutdown
!
interface GigabitEthernet3/7
no ip address
shutdown
!
interface GigabitEthernet3/8
no ip address
shutdown
!
interface GigabitEthernet3/9
description sh1-100 g4/13
no ip address
channel-group 13 mode desirable
!
interface GigabitEthernet3/10
description sh1-99 g4/14
no ip address
channel-group 12 mode on
!
interface GigabitEthernet3/11
no ip address
shutdown
!
interface GigabitEthernet3/12
no ip address
shutdown
!
interface GigabitEthernet3/13
no ip address
shutdown
!
interface GigabitEthernet3/14
no ip address
shutdown
!
interface GigabitEthernet3/15
Cisco IOS Release 12.1(13)E13
32
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface GigabitEthernet3/16
no ip address
shutdown
!
interface FastEthernet4/1
no ip address
shutdown
!
interface FastEthernet4/2
no ip address
shutdown
!
interface FastEthernet4/3
no ip address
shutdown
!
interface FastEthernet4/4
no ip address
shutdown
!
interface FastEthernet4/5
no ip address
shutdown
!
interface FastEthernet4/6
no ip address
shutdown
!
interface FastEthernet4/7
no ip address
shutdown
!
interface FastEthernet4/8
no ip address
shutdown
!
interface FastEthernet4/9
no ip address
shutdown
!
interface FastEthernet4/10
no ip address
shutdown
!
interface FastEthernet4/11
no ip address
shutdown
!
interface FastEthernet4/12
no ip address
shutdown
!
interface FastEthernet4/13
no ip address
shutdown
!
interface FastEthernet4/14
no ip address
shutdown
!
interface FastEthernet4/15
Cisco IOS Release 12.1(13)E13
33
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet4/16
no ip address
shutdown
!
interface FastEthernet4/17
no ip address
shutdown
!
interface FastEthernet4/18
no ip address
shutdown
!
interface FastEthernet4/19
no ip address
shutdown
!
interface FastEthernet4/20
no ip address
shutdown
!
interface FastEthernet4/21
no ip address
shutdown
!
interface FastEthernet4/22
no ip address
shutdown
!
interface FastEthernet4/23
no ip address
shutdown
!
interface FastEthernet4/24
description flashnet
ip address 10.194.17.98 255.255.255.0
shutdown
duplex full
!
interface GigabitEthernet7/1
description sh1-97 g7/1
no ip address
ip access-group 181 in
ip access-group 181 out
channel-group 11 mode on
!
interface GigabitEthernet7/2
description sh1-97 g7/2
no ip address
ip access-group 181 in
ip access-group 181 out
channel-group 11 mode on
!
interface GigabitEthernet7/3
no ip address
shutdown
!
interface GigabitEthernet7/4
no ip address
shutdown
!
interface GigabitEthernet7/5
Cisco IOS Release 12.1(13)E13
34
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface GigabitEthernet7/6
no ip address
shutdown
!
interface GigabitEthernet7/7
no ip address
shutdown
!
interface GigabitEthernet7/8
no ip address
shutdown
!
interface GigabitEthernet7/9
no ip address
shutdown
!
interface GigabitEthernet7/10
no ip address
shutdown
!
interface GigabitEthernet7/11
no ip address
shutdown
!
interface GigabitEthernet7/12
no ip address
shutdown
!
interface GigabitEthernet7/13
no ip address
shutdown
!
interface GigabitEthernet7/14
no ip address
shutdown
!
interface GigabitEthernet7/15
no ip address
shutdown
!
interface GigabitEthernet7/16
no ip address
shutdown
!
interface FastEthernet8/1
description rtp-wbu-te-p1 fa1/0
ip address 172.31.1.153 255.255.255.252
speed 100
duplex full
!
interface FastEthernet8/2
no ip address
shutdown
!
interface FastEthernet8/3
no ip address
shutdown
!
interface FastEthernet8/4
no ip address
shutdown
Cisco IOS Release 12.1(13)E13
35
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface FastEthernet8/5
no ip address
shutdown
!
interface FastEthernet8/6
no ip address
shutdown
!
interface FastEthernet8/7
no ip address
shutdown
!
interface FastEthernet8/8
no ip address
shutdown
!
interface FastEthernet8/9
no ip address
shutdown
!
interface FastEthernet8/10
no ip address
shutdown
!
interface FastEthernet8/11
no ip address
shutdown
!
interface FastEthernet8/12
no ip address
shutdown
!
interface FastEthernet8/13
no ip address
shutdown
!
interface FastEthernet8/14
no ip address
shutdown
!
interface FastEthernet8/15
no ip address
shutdown
!
interface FastEthernet8/16
no ip address
shutdown
!
interface FastEthernet8/17
no ip address
shutdown
!
interface FastEthernet8/18
no ip address
shutdown
!
interface FastEthernet8/19
no ip address
shutdown
!
interface FastEthernet8/20
no ip address
shutdown
Cisco IOS Release 12.1(13)E13
36
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface FastEthernet8/21
no ip address
shutdown
!
interface FastEthernet8/22
no ip address
shutdown
!
interface FastEthernet8/23
no ip address
shutdown
!
interface FastEthernet8/24
description flashnet
ip address 10.194.17.98 255.255.255.0
speed 100
duplex full
!
interface FastEthernet8/25
no ip address
shutdown
!
interface FastEthernet8/26
no ip address
shutdown
!
interface FastEthernet8/27
no ip address
shutdown
!
interface FastEthernet8/28
no ip address
shutdown
!
interface FastEthernet8/29
no ip address
shutdown
!
interface FastEthernet8/30
no ip address
shutdown
!
interface FastEthernet8/31
no ip address
shutdown
!
interface FastEthernet8/32
no ip address
shutdown
!
interface FastEthernet8/33
no ip address
shutdown
!
interface FastEthernet8/34
no ip address
shutdown
!
interface FastEthernet8/35
no ip address
shutdown
!
interface FastEthernet8/36
Cisco IOS Release 12.1(13)E13
37
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet8/37
no ip address
shutdown
!
interface FastEthernet8/38
no ip address
shutdown
!
interface FastEthernet8/39
no ip address
shutdown
!
interface FastEthernet8/40
no ip address
shutdown
!
interface FastEthernet8/41
no ip address
shutdown
!
interface FastEthernet8/42
no ip address
shutdown
!
interface FastEthernet8/43
no ip address
shutdown
!
interface FastEthernet8/44
no ip address
shutdown
!
interface FastEthernet8/45
no ip address
shutdown
!
interface FastEthernet8/46
no ip address
shutdown
!
interface FastEthernet8/47
description rtp-wbu-te-p4 fa2/0
ip address 172.31.1.149 255.255.255.252
duplex full
!
interface FastEthernet8/48
description rtp-wbu-te-p4 fa4/0
ip address 172.31.1.169 255.255.255.252
!
interface Vlan1
no ip address
shutdown
!
router ospf 1
log-adjacency-changes
auto-cost reference-bandwidth 100000
passive-interface default
no passive-interface FastEthernet8/48
no passive-interface Port-channel11
no passive-interface Port-channel12
no passive-interface Port-channel13
Cisco IOS Release 12.1(13)E13
38
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
network 172.31.0.0 0.0.0.255 area 0
network 172.31.1.0 0.0.0.3 area 0
network 172.31.1.8 0.0.0.3 area 0
network 172.31.1.16 0.0.0.3 area 0
network 172.31.1.168 0.0.0.3 area 6
network 172.31.2.5 0.0.0.0 area 0
network 172.31.4.0 0.0.0.255 area 0
maximum-paths 6
!
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor sh1-ibgp peer-group
neighbor sh1-ibgp remote-as 100
neighbor sh1-ibgp version 4
neighbor sh1-ibgp next-hop-self
neighbor 172.31.1.150 remote-as 10
neighbor 172.31.1.154 remote-as 20
neighbor 172.31.4.97 peer-group sh1-ibgp
neighbor 172.31.4.99 peer-group sh1-ibgp
neighbor 172.31.4.100 peer-group sh1-ibgp
no auto-summary
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.31.4.99
ip route 172.18.177.128 255.255.255.192 10.194.17.254
ip route 172.18.179.128 255.255.255.192 10.194.17.254
no ip http server
ip pim rp-address 172.31.0.98 3 override
ip pim spt-threshold infinity
ip pim send-rp-announce Loopback1 scope 64 group-list 1
ip pim send-rp-discovery Loopback1 scope 64
ip msdp peer 172.31.4.97 connect-source Loopback0
ip msdp description 172.31.4.97 SH1-97
ip msdp sa-filter out 172.31.4.97 list 131
ip msdp mesh-group global 172.31.4.97
ip msdp cache-sa-state
ip msdp originator-id Loopback0
!
!
logging trap debugging
logging 172.18.177.132
access-list 1 permit 239.98.0.0 0.0.255.255
access-list 3 permit 224.0.1.39
access-list 3 permit 224.0.1.40
access-list 10 permit 224.0.0.0 31.255.255.255
access-list 10 deny
any
access-list 131 permit ip any 239.98.0.0 0.0.255.255
access-list 181 permit ip any any
access-list 182 permit ip any any
snmp-server community public RO
snmp-server community cisco RW
!
alias exec ip sh ip int brief | be Port
alias exec eigrp show run | be router eigrp
alias exec ospf sh run | be router ospf
alias exec bgp sh run | be router bgp
!
line con 0
exec-timeout 0 0
line vty 0 4
exec-timeout 0 0
password cisco
login
Cisco IOS Release 12.1(13)E13
39
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
history size 256
transport input lat pad mop telnet rlogin udptn nasi
!
exception protocol ftp
exception dump 172.18.177.129
exception memory fragment 200000
exception memory minimum 200000
ntp clock-period 17180183
ntp update-calendar
ntp server 172.18.177.131
ntp server 172.18.177.132 prefer
end
SH1-98#show version
Cisco Internetwork Operating System Software
IOS (tm) c6sup2_rp Software (c6sup2_rp-JSV-M), Version 12.1(nightly13e.E040229) NIGHTLY
BUILD, synced to cosmos_e V121_12_5_E1
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Mon 01-Mar-04 00:11 by
Image text-base: 0x40008BF0, data-base: 0x41A4C000
ROM: System Bootstrap, Version 12.1(4r)E, RELEASE SOFTWARE (fc1)
SH1-98 uptime is 2 weeks, 2 days, 19 hours, 29 minutes
Time since SH1-98 switched to active is 2 weeks, 2 days, 19 hours, 29 minutes
System returned to ROM by power-on (SP by power-on)
System restarted at 16:14:03 EST Mon Mar 1 2004
System image file is "sup-bootflash:c6sup22-jsv-mz.v121_13_e_throttle.040229"
cisco Catalyst 6000 (R7000) processor with 458752K/65536K bytes of memory.
Processor board ID SAD055205W6
R7000 CPU at 300Mhz, Implementation 39, Rev 2.1, 256KB L2, 1024KB L3 Cache
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
1 Virtual Ethernet/IEEE 802.3 interface(s)
72 FastEthernet/IEEE 802.3 interface(s)
36 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.
16384K bytes of Flash internal SIMM (Sector size 512K).
Standby is up
Standby has 458752K/65536K bytes of memory.
Configuration register is 0x2102
SH1-98#show module
Mod Ports Card Type
--- ----- -------------------------------------1
2 Catalyst 6000 supervisor 2 (Active)
2
2 Catalyst 6000 supervisor 2 (Standby)
3
16 Pure SFM-mode 16 port 1000mb GBIC
4
24 24 port 100FX Multi mode
5
0 Switching Fabric Module-136 (Active)
6
0 Switching Fabric Module-136 (Standby)
7
16 SFM-capable 16 port 1000mb GBIC
8
48 48 port 10/100 mb RJ45
Model
-----------------WS-X6K-S2U-MSFC2
WS-X6K-S2U-MSFC2
WS-X6816-GBIC
WS-X6324-100FX-MM
WS-X6500-SFM2
WS-X6500-SFM2
WS-X6516-GBIC
WS-X6348-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.c9da.e7b4 to 0001.c9da.e7b5
3.2
6.1(3)
2 0001.c9da.e70c to 0001.c9da.e70d
3.2
6.1(3)
Cisco IOS Release 12.1(13)E13
40
Serial No.
----------SAD0602034Z
SAD055006L4
SAD055101KD
SAD055106XK
SAD05520493
SAD055204C7
SAD055204T3
SAL0547ESP4
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
3
4
5
6
7
8
Mod
--1
1
2
2
3
0001.63d3.b64a
0003.3287.5f9a
0001.0002.0003
0001.0002.0003
0001.63d4.2862
0005.740b.7138
to
to
to
to
to
to
0001.63d3.b659
0003.3287.5fb1
0001.0002.0003
0001.0002.0003
0001.63d4.2871
0005.740b.7167
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Distributed Forwarding Card
1.2
3.0
1.1
1.1
4.0
6.0
12.1(5r)E1
5.4(2)
6.1(3)
6.1(3)
6.1(3)
5.4(2)
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-DFC
12.1(nightly
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Ok
Ok
Ok
Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD060204RK
3.0
Ok
SAD055205W6
1.3
Ok
SAD060204LM
3.0
Ok
SAD0552067L
1.3
Ok
SAD055102R3
2.0
Ok
Mod Online Diag Status
--- ------------------1 Pass
2 Pass
3 Pass
4 Pass
5 Pass
6 Pass
7 Pass
8 Pass
SH1-98#
Return to SH1-98, page 30
SH1-99
Go to Test Device Configurations, page 17
Go to Financial Lab Topology, page 2
Go to Test Cases, page 249
SH1-99#show config
Using 15625 out of 391160 bytes
!
!
version 12.1
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
no service password-encryption
service internal
!
hostname SH1-99
!
boot system flash sup-bootflash:
boot bootldr bootflash:
logging buffered 100000 debugging
no logging console
enable secret 5 $1$kOP5$LkWaG3ARMT5Cpj9tDHJ9G.
!
clock timezone EST -5
clock summer-time EDT recurring
ip subnet-zero
!
!
ip ftp username safeharbor
ip ftp password shshsh
Cisco IOS Release 12.1(13)E13
41
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip domain-lookup
!
ip multicast-routing
ip multicast cache-headers
mls flow ip destination-source
mls flow ipx destination
mls ip multicast consistency-check
chat-script 10 m d'
!
redundancy
mode rpr-plus
main-cpu
auto-sync running-config
auto-sync standard
!
power redundancy-mode combined
!
!
!
interface Loopback0
ip address 172.31.4.99 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 172.31.0.100 255.255.255.255
ip pim sparse-mode
!
interface Port-channel12
description sh1-97 po12
ip address 172.31.1.6 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel13
description sh1-100 po12
ip address 172.31.1.13 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel14
description sh1-101 po14
ip address 172.31.1.25 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel15
description sh1-102 po15
ip address 172.31.1.29 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel16
description sh1-103 po16
ip address 172.31.1.33 255.255.255.252
ip access-group 181 in
ip access-group 181 out
Cisco IOS Release 12.1(13)E13
42
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip pim sparse-mode
logging event link-status
!
interface Port-channel17
description sh1-104 po17
ip address 172.31.1.37 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel64
description SH1-113 Po64
ip address 172.31.11.1 255.255.255.252
ip pim sparse-mode
logging event link-status
!
interface Port-channel65
description SH1-114 Po65
ip address 172.31.11.5 255.255.255.252
ip pim sparse-mode
logging event link-status
!
interface Port-channel66
description sh1-105 po66
ip address 172.31.1.65 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel67
description sh1-106 po67
ip address 172.31.1.69 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel112
description sh1-98 po12
ip address 172.31.1.18 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface GigabitEthernet1/1
description sh1-97 gi2/1
no ip address
channel-group 12 mode on
!
interface GigabitEthernet1/2
no ip address
shutdown
!
interface GigabitEthernet2/1
description sh1-97 gi1/1
no ip address
channel-group 12 mode on
!
interface GigabitEthernet2/2
description SH1-113 g3/9
no ip address
Cisco IOS Release 12.1(13)E13
43
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
channel-group 64 mode on
!
interface GigabitEthernet3/1
description sh1-100 g3/9
no ip address
channel-group 13 mode on
!
interface GigabitEthernet3/2
description sh1-101 g3/1
no ip address
channel-group 14 mode on
!
interface GigabitEthernet3/3
description sh1-103 g3/1
no ip address
ip access-group 181 in
ip access-group 181 out
channel-group 16 mode on
!
interface GigabitEthernet3/4
description sh1-102 g3/3
no ip address
channel-group 15 mode on
!
interface GigabitEthernet3/5
description sh1-97 g3/1
no ip address
channel-group 12 mode on
!
interface GigabitEthernet3/6
description sh1-98 g3/2
no ip address
channel-group 112 mode on
!
interface GigabitEthernet3/7
no ip address
shutdown
!
interface GigabitEthernet3/8
description sh1-100 g3/16
no ip address
channel-group 13 mode on
!
interface GigabitEthernet3/9
description sh1-100 g3/9
no ip address
channel-group 13 mode on
!
interface GigabitEthernet3/10
description sh1-101 g3/9
no ip address
channel-group 14 mode on
!
interface GigabitEthernet3/11
description sh1-103 g3/9
no ip address
ip access-group 181 in
ip access-group 181 out
channel-group 16 mode on
!
interface GigabitEthernet3/12
description sh1-104 g3/10
no ip address
channel-group 17 mode desirable
Cisco IOS Release 12.1(13)E13
44
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface GigabitEthernet3/13
description SH1-114 g2/1
no ip address
channel-group 65 mode on
!
interface GigabitEthernet3/14
no ip address
shutdown
!
interface GigabitEthernet3/15
description SH1-114 g2/2
no ip address
channel-group 65 mode on
!
interface GigabitEthernet3/16
description sh1-100 g3/16
no ip address
channel-group 13 mode on
!
interface GigabitEthernet4/1
description sh1-100 g4/9
no ip address
channel-group 13 mode on
!
interface GigabitEthernet4/2
description sh1-101 g3/2
no ip address
channel-group 14 mode on
!
interface GigabitEthernet4/3
description sh1-103 g4/1
no ip address
ip access-group 181 in
ip access-group 181 out
channel-group 16 mode on
!
interface GigabitEthernet4/4
description sh1-104 g4/2
no ip address
channel-group 17 mode desirable
!
interface GigabitEthernet4/5
description SH1-113 g3/10
no ip address
channel-group 64 mode on
!
interface GigabitEthernet4/6
no ip address
shutdown
!
interface GigabitEthernet4/7
no ip address
shutdown
!
interface GigabitEthernet4/8
description sh1-100 g4/16
no ip address
channel-group 13 mode on
!
interface GigabitEthernet4/9
description sh1-100 g4/9
no ip address
channel-group 13 mode on
Cisco IOS Release 12.1(13)E13
45
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface GigabitEthernet4/10
description sh1-101 g3/10
no ip address
channel-group 14 mode on
!
interface GigabitEthernet4/11
description sh1-103 g4/9
no ip address
ip access-group 181 in
ip access-group 181 out
channel-group 16 mode on
!
interface GigabitEthernet4/12
description sh1-102 g3/11
no ip address
channel-group 15 mode on
!
interface GigabitEthernet4/13
description sh1-97 gi3/9
no ip address
channel-group 12 mode on
!
interface GigabitEthernet4/14
description sh1-98 g3/10
no ip address
channel-group 112 mode on
!
interface GigabitEthernet4/15
no ip address
shutdown
!
interface GigabitEthernet4/16
description sh1-100 g4/16
no ip address
channel-group 13 mode on
!
interface FastEthernet7/1
description flashnet
ip address 10.194.17.99 255.255.255.0
shutdown
speed 100
duplex full
!
interface FastEthernet7/2
description IXIA 4/7
ip address 172.31.99.101 255.255.255.252
ip pim sparse-mode
speed 100
duplex full
!
interface FastEthernet7/3
no ip address
shutdown
!
interface FastEthernet7/4
no ip address
shutdown
!
interface FastEthernet7/5
no ip address
shutdown
!
interface FastEthernet7/6
Cisco IOS Release 12.1(13)E13
46
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet7/7
no ip address
!
interface FastEthernet7/8
no ip address
shutdown
!
interface FastEthernet7/9
no ip address
shutdown
!
interface FastEthernet7/10
no ip address
shutdown
!
interface FastEthernet7/11
no ip address
shutdown
!
interface FastEthernet7/12
no ip address
shutdown
!
interface FastEthernet7/13
no ip address
shutdown
!
interface FastEthernet7/14
no ip address
shutdown
!
interface FastEthernet7/15
no ip address
shutdown
!
interface FastEthernet7/16
no ip address
shutdown
!
interface FastEthernet7/17
no ip address
shutdown
!
interface FastEthernet7/18
no ip address
shutdown
!
interface FastEthernet7/19
no ip address
shutdown
!
interface FastEthernet7/20
no ip address
shutdown
!
interface FastEthernet7/21
no ip address
shutdown
!
interface FastEthernet7/22
no ip address
Cisco IOS Release 12.1(13)E13
47
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface FastEthernet7/23
no ip address
shutdown
!
interface FastEthernet7/24
description flashnet
ip address 10.194.17.99 255.255.255.0
speed 100
duplex full
!
interface FastEthernet7/25
no ip address
shutdown
!
interface FastEthernet7/26
no ip address
shutdown
!
interface FastEthernet7/27
no ip address
shutdown
!
interface FastEthernet7/28
no ip address
shutdown
!
interface FastEthernet7/29
no ip address
shutdown
!
interface FastEthernet7/30
no ip address
shutdown
!
interface FastEthernet7/31
no ip address
shutdown
!
interface FastEthernet7/32
no ip address
shutdown
!
interface FastEthernet7/33
no ip address
shutdown
!
interface FastEthernet7/34
no ip address
shutdown
!
interface FastEthernet7/35
no ip address
shutdown
!
interface FastEthernet7/36
no ip address
!
interface FastEthernet7/37
no ip address
!
interface FastEthernet7/38
description rtp-wbu-te-p4 fa3/1
Cisco IOS Release 12.1(13)E13
48
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip address 172.31.3.40 255.255.255.192
load-interval 30
hold-queue 400 in
!
interface FastEthernet7/39
no ip address
shutdown
!
interface FastEthernet7/40
no ip address
shutdown
!
interface FastEthernet7/41
no ip address
shutdown
!
interface FastEthernet7/42
no ip address
shutdown
!
interface FastEthernet7/43
no ip address
shutdown
!
interface FastEthernet7/44
no ip address
shutdown
!
interface FastEthernet7/45
no ip address
shutdown
!
interface FastEthernet7/46
no ip address
shutdown
!
interface FastEthernet7/47
description Ix-6/1
ip address 172.31.1.121 255.255.255.252
speed 100
duplex full
hold-queue 400 in
!
interface FastEthernet7/48
description Ix-6/2
ip address 172.31.1.125 255.255.255.252
speed 100
duplex full
hold-queue 400 in
!
interface GigabitEthernet9/1
description sh1-105 g3/1
no ip address
channel-group 66 mode on
!
interface GigabitEthernet9/2
description sh1-105 g4/1
no ip address
channel-group 66 mode on
!
interface GigabitEthernet9/3
no ip address
shutdown
!
Cisco IOS Release 12.1(13)E13
49
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface GigabitEthernet9/4
no ip address
shutdown
!
interface GigabitEthernet9/5
description sh1-106 g3/1
no ip address
channel-group 67 mode on
!
interface GigabitEthernet9/6
description sh1-106 g4/1
no ip address
channel-group 67 mode on
!
interface GigabitEthernet9/7
description SH1-113 g2/1
no ip address
channel-group 64 mode on
!
interface GigabitEthernet9/8
description SH1-113 g2/2
no ip address
channel-group 64 mode on
!
interface GigabitEthernet9/9
description SH1-114 g3/9
no ip address
channel-group 65 mode on
!
interface GigabitEthernet9/10
description SH1-114 g3/10
no ip address
channel-group 65 mode on
!
interface GigabitEthernet9/11
no ip address
shutdown
!
interface GigabitEthernet9/12
no ip address
shutdown
!
interface GigabitEthernet9/13
no ip address
shutdown
!
interface GigabitEthernet9/14
no ip address
shutdown
!
interface GigabitEthernet9/15
no ip address
shutdown
!
interface GigabitEthernet9/16
no ip address
shutdown
!
interface Vlan1
no ip address
shutdown
!
router eigrp 1320
redistribute ospf 1 metric 100000 10 255 1 1500 route-map OSPF2EIGRP-tag
Cisco IOS Release 12.1(13)E13
50
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
passive-interface Loopback1
network 172.31.0.126 0.0.0.0
network 172.31.1.24 0.0.0.3
network 172.31.1.28 0.0.0.3
network 172.31.1.160 0.0.0.3
no auto-summary
eigrp log-neighbor-changes
!
router ospf 1
router-id 172.31.2.9
log-adjacency-changes
auto-cost reference-bandwidth 100000
redistribute eigrp 1320 subnets route-map EIGRP2OSPF-tag
passive-interface default
no passive-interface FastEthernet7/2
no passive-interface FastEthernet7/47
no passive-interface FastEthernet7/48
no passive-interface Port-channel12
no passive-interface Port-channel13
no passive-interface Port-channel14
no passive-interface Port-channel15
no passive-interface Port-channel16
no passive-interface Port-channel17
no passive-interface Port-channel64
no passive-interface Port-channel65
no passive-interface Port-channel66
no passive-interface Port-channel67
no passive-interface Port-channel112
network 172.31.0.0 0.0.0.255 area 0
network 172.31.1.4 0.0.0.3 area 0
network 172.31.1.12 0.0.0.3 area 0
network 172.31.1.16 0.0.0.3 area 0
network 172.31.1.32 0.0.0.7 area 1
network 172.31.1.64 0.0.0.7 area 2
network 172.31.1.120 0.0.0.3 area 3
network 172.31.1.124 0.0.0.3 area 5
network 172.31.1.252 0.0.0.3 area 0
network 172.31.2.8 0.0.0.3 area 0
network 172.31.2.0 0.0.0.255 area 0
network 172.31.3.0 0.0.0.255 area 4
network 172.31.4.0 0.0.0.255 area 0
network 172.31.10.0 0.0.0.3 area 0
network 172.31.11.0 0.0.0.255 area 4
network 172.31.99.0 0.0.0.255 area 0
maximum-paths 6
!
router bgp 100
no synchronization
bgp log-neighbor-changes
network 172.31.0.0 mask 255.255.128.0
network 172.31.128.0 mask 255.255.224.0
redistribute eigrp 1320
redistribute ospf 1
neighbor sh1-ibgp peer-group
neighbor sh1-ibgp remote-as 100
neighbor sh1-ibgp update-source Loopback0
neighbor sh1-ibgp version 4
neighbor sh1-ibgp next-hop-self
neighbor 172.31.4.97 peer-group sh1-ibgp
neighbor 172.31.4.98 peer-group sh1-ibgp
neighbor 172.31.4.100 peer-group sh1-ibgp
no auto-summary
!
ip classless
Cisco IOS Release 12.1(13)E13
51
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip route 130.3.1.0 255.255.255.0 FastEthernet7/47
ip route 172.18.177.128 255.255.255.192 10.194.17.254
ip route 172.18.179.128 255.255.255.192 10.194.17.254
no ip http server
ip pim rp-address 172.31.0.98 3 override
ip pim spt-threshold infinity
ip pim send-rp-announce Loopback1 scope 64 group-list 1
ip pim send-rp-discovery Loopback1 scope 64
ip msdp peer 172.31.4.100 connect-source Loopback0
ip msdp description 172.31.4.100 SH1-100
ip msdp sa-filter out 172.31.4.100 list 131
ip msdp mesh-group regional 172.31.4.100
ip msdp cache-sa-state
ip msdp originator-id Loopback0
!
!
logging trap debugging
logging 172.18.177.132
access-list 1 permit 239.100.0.0 0.0.255.255
access-list 3 permit 224.0.1.39
access-list 3 permit 224.0.1.40
access-list 10 permit 224.0.0.0 31.255.255.255
access-list 10 permit any
access-list 17 permit 130.1.0.0 0.0.255.255
access-list 18 permit 180.1.0.0 0.0.254.255
access-list 22 permit 160.0.0.0 0.255.254.255
access-list 41 permit 140.0.0.0 0.255.255.255
access-list 50 permit 224.0.0.0 31.255.255.255
access-list 100 deny
ip host 172.31.1.29 host 172.31.1.30
access-list 100 deny
ip host 172.31.1.30 host 172.31.1.29
access-list 110 permit ip host 224.0.0.10 host 172.31.1.30
access-list 131 permit ip any 239.100.0.0 0.0.255.255
access-list 178 permit ip 140.0.0.0 0.255.255.255 any
access-list 181 permit ip any any
route-map OSPF2EIGRP-tag deny 10
match tag 140
!
route-map OSPF2EIGRP-tag permit 20
set tag 140
!
route-map EIGRP2OSPF-tag deny 10
match tag 150
!
route-map EIGRP2OSPF-tag permit 20
set tag 150
!
route-map EIGRP2BGP permit 10
match ip address 18
!
route-map OSPF2EIGRP-odd deny 10
match ip address 22
!
route-map OSPF2EIGRP-odd permit 20
!
route-map OSPF2EIGRP deny 10
match ip address 17
!
route-map OSPF2EIGRP permit 20
!
route-map ospf-to-eigrp permit 10
set tag 140
!
route-map ospf-to-eigrp deny 20
match tag 140
Cisco IOS Release 12.1(13)E13
52
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
route-map eigrp-to-ospf permit 10
set tag 150
!
route-map eigrp-to-ospf deny 20
match tag 150
!
snmp-server community public RO
snmp-server community cisco RW
!
alias exec ip sh ip int brief | be Port
alias exec ospf sh run | be router ospf
alias exec eigrp sh run | be router eigrp
alias exec bgp show runn | beg router bgp
!
line con 0
exec-timeout 0 0
line vty 0 4
exec-timeout 0 0
password cisco
login
length 0
history size 256
transport input lat pad mop telnet rlogin udptn nasi
!
exception protocol ftp
exception dump 172.18.177.129
exception memory fragment 200000
exception memory minimum 200000
scheduler runtime netinput 300
ntp clock-period 17180096
ntp update-calendar
ntp server 172.18.177.131
ntp server 172.18.177.132 prefer
end
SH1-99#show version
Cisco Internetwork Operating System Software
IOS (tm) c6sup2_rp Software (c6sup2_rp-JSV-M), Version 12.1(nightly13e.E040229) NIGHTLY
BUILD, synced to cosmos_e V121_12_5_E1
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Mon 01-Mar-04 00:11 by
Image text-base: 0x40008BF0, data-base: 0x41A4C000
ROM: System Bootstrap, Version 12.1(4r)E, RELEASE SOFTWARE (fc1)
SH1-99 uptime is 2 weeks, 2 days, 19 hours, 24 minutes
Time since SH1-99 switched to active is 2 weeks, 2 days, 19 hours, 24 minutes
System returned to ROM by power-on (SP by power-on)
System restarted at 16:19:07 EST Mon Mar 1 2004
System image file is "sup-bootflash:c6sup22-jsv-mz.v121_13_e_throttle.040229"
cisco Catalyst 6000 (R7000) processor with 458752K/65536K bytes of memory.
Processor board ID SAD055205S7
R7000 CPU at 300Mhz, Implementation 39, Rev 2.1, 256KB L2, 1024KB L3 Cache
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
1 Virtual Ethernet/IEEE 802.3 interface(s)
48 FastEthernet/IEEE 802.3 interface(s)
52 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.
Cisco IOS Release 12.1(13)E13
53
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
16384K bytes of Flash internal SIMM (Sector size 512K).
Standby is up
Standby has 458752K/65536K bytes of memory.
Configuration register is 0x2102
SH1-99#show module
Mod Ports Card Type
--- ----- -------------------------------------1
2 Catalyst 6000 supervisor 2 (Active)
2
2 Catalyst 6000 supervisor 2 (Standby)
3
16 Pure SFM-mode 16 port 1000mb GBIC
4
16 Pure SFM-mode 16 port 1000mb GBIC
5
0 Switching Fabric Module-136 (Standby)
6
0 Switching Fabric Module-136 (Active)
7
48 48 port 10/100 mb RJ45
9
16 SFM-capable 16 port 1000mb GBIC
Model
-----------------WS-X6K-S2U-MSFC2
WS-X6K-S2U-MSFC2
WS-X6816-GBIC
WS-X6816-GBIC
WS-X6500-SFM2
WS-X6500-SFM2
WS-X6348-RJ-45
WS-X6516-GBIC
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.c9da.e6e8 to 0001.c9da.e6e9
3.2
6.1(3)
2 0002.7e38.70e0 to 0002.7e38.70e1
3.2
6.1(3)
3 0001.63d3.b42a to 0001.63d3.b439
1.2
12.1(5r)E1
4 0001.63d3.b80a to 0001.63d3.b819
1.2
12.1(5r)E1
5 0001.0002.0003 to 0001.0002.0003
1.1
6.1(3)
6 0001.0002.0003 to 0001.0002.0003
1.1
6.1(3)
7 0005.7481.6778 to 0005.7481.67a7
6.0
5.4(2)
9 0009.11e0.a7d0 to 0009.11e0.a7df
5.0
6.3(1)
Mod
--1
1
2
2
3
4
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Distributed Forwarding Card
Distributed Forwarding Card
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-DFC
WS-F6K-DFC
Mod Online Diag Status
--- ------------------1 Pass
2 Pass
3 Pass
4 Pass
5 Pass
6 Pass
7 Pass
9 Pass
SH1-99#
Return to SH1-99, page 41
SH1-100
Go to Test Device Configurations, page 17
Go to Financial Lab Topology, page 2
Go to Test Cases, page 249
SH1-100#show config
Using 15703 out of 391160 bytes
Cisco IOS Release 12.1(13)E13
54
Serial No.
----------SAD06020371
SAD060100AY
SAD055101KC
SAD055101KU
SAD0552044G
SAD055204EZ
SAL0552FSB6
SAL06200YL1
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
12.1(nightly
12.1(nightly
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD060204MJ
3.0
Ok
SAD055205S7
1.3
Ok
SAD060201EJ
3.0
Ok
SAD055205VK
1.3
Ok
SAD055102T4
2.0
Ok
SAD055102NR
2.0
Ok
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
!
version 12.1
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
no service password-encryption
service internal
!
hostname SH1-100
!
boot system flash sup-bootflash:
boot bootldr bootflash:
logging buffered 1000000 debugging
no logging console
enable secret 5 $1$2yp5$0ms6Prwm8UItyW5GFN2Ba1
!
clock timezone EDT -5
clock summer-time EST recurring
ip subnet-zero
!
!
ip ftp username safeharbor
ip ftp password shshsh
no ip domain-lookup
!
ip multicast-routing
mls flow ip destination-source
mls flow ipx destination
mls ip multicast consistency-check
!
redundancy
mode rpr-plus
main-cpu
auto-sync running-config
auto-sync standard
!
power redundancy-mode combined
!
!
!
interface Loopback0
ip address 172.31.4.100 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 172.31.0.100 255.255.255.255
ip pim sparse-mode
!
interface Port-channel12
description sh1-99 po13
ip address 172.31.1.14 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel13
description sh1-97 po13
ip address 172.31.1.22 255.255.255.252
ip access-group 182 in
ip access-group 182 out
ip pim sparse-mode
logging event link-status
!
Cisco IOS Release 12.1(13)E13
55
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface Port-channel14
description sh1-101 po114
ip address 172.31.1.41 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel15
description sh1-102 po115
ip address 172.31.1.45 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel16
description sh1-103 po116
ip address 172.31.1.49 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel17
description sh1-104 po117
ip address 172.31.1.53 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel24
no ip address
!
interface Port-channel64
description SH1-113 Po164
ip address 172.31.11.9 255.255.255.252
ip pim sparse-mode
logging event link-status
!
interface Port-channel65
description SH1-114 Po165
ip address 172.31.11.13 255.255.255.252
ip pim sparse-mode
logging event link-status
!
interface Port-channel66
description sh1-105 po166
ip address 172.31.1.93 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel67
description sh1-106 po167
ip address 172.31.1.97 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel113
Cisco IOS Release 12.1(13)E13
56
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
description sh1-98 po13
ip address 172.31.1.10 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface GigabitEthernet1/1
description SH1-113 g3/1
no ip address
ip access-group 182 in
ip access-group 182 out
channel-group 64 mode on
!
interface GigabitEthernet1/2
description sh1-97 g1/2
no ip address
ip access-group 182 in
ip access-group 182 out
channel-group 13 mode on
!
interface GigabitEthernet2/1
no ip address
shutdown
!
interface GigabitEthernet2/2
description sh1-97 g2/2
no ip address
ip access-group 182 in
ip access-group 182 out
channel-group 13 mode on
!
interface GigabitEthernet3/1
description sh1-99 g3/1
no ip address
channel-group 12 mode on
!
interface GigabitEthernet3/2
description sh1-102 g3/1
no ip address
channel-group 15 mode on
!
interface GigabitEthernet3/3
description sh1-104 g3/1
no ip address
channel-group 17 mode on
!
interface GigabitEthernet3/4
description sh1-101 g3/3
no ip address
channel-group 14 mode on
!
interface GigabitEthernet3/5
description sh1-98 g3/1
no ip address
channel-group 113 mode auto
!
interface GigabitEthernet3/6
description sh1-97 g3/2
no ip address
ip access-group 182 in
ip access-group 182 out
channel-group 13 mode on
!
Cisco IOS Release 12.1(13)E13
57
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface GigabitEthernet3/7
description SH1-113 g3/2
no ip address
channel-group 64 mode on
!
interface GigabitEthernet3/8
description sh1-99 g3/8
no ip address
channel-group 12 mode on
!
interface GigabitEthernet3/9
description sh1-99 g3/9
no ip address
channel-group 12 mode on
!
interface GigabitEthernet3/10
description sh1-102 g3/9
no ip address
channel-group 15 mode on
!
interface GigabitEthernet3/11
description sh1-104 g3/9
no ip address
channel-group 17 mode on
!
interface GigabitEthernet3/12
description sh1-103 g4/10
no ip address
channel-group 16 mode on
!
interface GigabitEthernet3/13
no ip address
ip pim sparse-mode
shutdown
!
interface GigabitEthernet3/14
no ip address
shutdown
!
interface GigabitEthernet3/15
no ip address
shutdown
!
interface GigabitEthernet3/16
description sh1-99 g3/16
no ip address
channel-group 12 mode on
!
interface GigabitEthernet4/1
description sh1-99 g4/1
no ip address
channel-group 12 mode on
!
interface GigabitEthernet4/2
description sh1-102 g3/2
no ip address
channel-group 15 mode on
!
interface GigabitEthernet4/3
description sh1-104 g4/1
no ip address
channel-group 17 mode on
!
interface GigabitEthernet4/4
Cisco IOS Release 12.1(13)E13
58
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
description sh1-103 g3/2
no ip address
channel-group 16 mode on
!
interface GigabitEthernet4/5
description SH1-114 g2/9
no ip address
channel-group 65 mode on
!
interface GigabitEthernet4/6
description SH1-114 g2/10
no ip address
channel-group 65 mode on
!
interface GigabitEthernet4/7
no ip address
shutdown
!
interface GigabitEthernet4/8
description sh1-99 g4/8
no ip address
channel-group 12 mode on
!
interface GigabitEthernet4/9
description sh1-99 g4/9
no ip address
channel-group 12 mode on
!
interface GigabitEthernet4/10
description sh1-102 g3/10
no ip address
channel-group 15 mode on
!
interface GigabitEthernet4/11
description sh1-104 g4/9
no ip address
channel-group 17 mode on
!
interface GigabitEthernet4/12
description sh1-101 g3/11
no ip address
channel-group 14 mode on
!
interface GigabitEthernet4/13
description sh1-98 g3/9
no ip address
channel-group 113 mode auto
!
interface GigabitEthernet4/14
description sh1-97 g3/10
no ip address
ip access-group 182 in
ip access-group 182 out
channel-group 13 mode on
!
interface GigabitEthernet4/15
no ip address
shutdown
!
interface GigabitEthernet4/16
description sh1-99 g4/16
no ip address
channel-group 12 mode on
!
Cisco IOS Release 12.1(13)E13
59
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface FastEthernet7/1
description flashnet
ip address 10.194.17.100 255.255.255.0
shutdown
speed 100
duplex full
!
interface FastEthernet7/2
no ip address
switchport
switchport access vlan 40
switchport mode access
!
interface FastEthernet7/3
no ip address
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
load-interval 30
shutdown
!
interface FastEthernet7/4
no ip address
shutdown
!
interface FastEthernet7/5
no ip address
shutdown
!
interface FastEthernet7/6
no ip address
shutdown
!
interface FastEthernet7/7
no ip address
!
interface FastEthernet7/8
no ip address
shutdown
!
interface FastEthernet7/9
no ip address
shutdown
!
interface FastEthernet7/10
no ip address
shutdown
!
interface FastEthernet7/11
no ip address
shutdown
!
interface FastEthernet7/12
no ip address
shutdown
!
interface FastEthernet7/13
no ip address
shutdown
!
interface FastEthernet7/14
no ip address
shutdown
Cisco IOS Release 12.1(13)E13
60
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface FastEthernet7/15
no ip address
shutdown
!
interface FastEthernet7/16
no ip address
shutdown
!
interface FastEthernet7/17
no ip address
!
interface FastEthernet7/18
no ip address
shutdown
!
interface FastEthernet7/19
no ip address
shutdown
!
interface FastEthernet7/20
no ip address
shutdown
!
interface FastEthernet7/21
no ip address
shutdown
!
interface FastEthernet7/22
no ip address
shutdown
!
interface FastEthernet7/23
no ip address
shutdown
!
interface FastEthernet7/24
description flashnet
ip address 10.194.17.100 255.255.255.0
speed 100
duplex full
!
interface FastEthernet7/25
no ip address
shutdown
!
interface FastEthernet7/26
no ip address
shutdown
!
interface FastEthernet7/27
no ip address
shutdown
!
interface FastEthernet7/28
no ip address
shutdown
!
interface FastEthernet7/29
no ip address
shutdown
!
interface FastEthernet7/30
no ip address
Cisco IOS Release 12.1(13)E13
61
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface FastEthernet7/31
no ip address
shutdown
!
interface FastEthernet7/32
no ip address
shutdown
!
interface FastEthernet7/33
no ip address
shutdown
!
interface FastEthernet7/34
no ip address
shutdown
!
interface FastEthernet7/35
no ip address
shutdown
!
interface FastEthernet7/36
no ip address
shutdown
!
interface FastEthernet7/37
no ip address
shutdown
!
interface FastEthernet7/38
ip address 172.31.1.137 255.255.255.252 secondary
ip address 172.31.3.65 255.255.255.192
no ip redirects
no ip unreachables
!
interface FastEthernet7/39
no ip address
shutdown
!
interface FastEthernet7/40
no ip address
!
interface FastEthernet7/41
no ip address
shutdown
!
interface FastEthernet7/42
no ip address
shutdown
!
interface FastEthernet7/43
no ip address
shutdown
!
interface FastEthernet7/44
no ip address
shutdown
!
interface FastEthernet7/45
no ip address
shutdown
!
interface FastEthernet7/46
Cisco IOS Release 12.1(13)E13
62
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet7/47
description Ix-6/3
ip address 172.31.1.129 255.255.255.252
speed 100
duplex full
hold-queue 400 in
!
interface FastEthernet7/48
description Ix-6/4
ip address 172.31.1.133 255.255.255.252
hold-queue 400 in
!
interface GigabitEthernet9/1
description sh1-105 g5/1
no ip address
channel-group 66 mode on
!
interface GigabitEthernet9/2
description sh1-105 g6/1
no ip address
channel-group 66 mode on
!
interface GigabitEthernet9/3
no ip address
shutdown
!
interface GigabitEthernet9/4
no ip address
shutdown
!
interface GigabitEthernet9/5
description sh1-106 g5/1
no ip address
channel-group 67 mode on
!
interface GigabitEthernet9/6
description sh1-106 g6/1
no ip address
channel-group 67 mode on
!
interface GigabitEthernet9/7
description SH1-113 g2/9
no ip address
channel-group 64 mode on
!
interface GigabitEthernet9/8
description SH1-113 g2/10
no ip address
channel-group 64 mode on
!
interface GigabitEthernet9/9
description SH1-114 g3/1
no ip address
channel-group 65 mode on
!
interface GigabitEthernet9/10
description SH1-114 g3/2
no ip address
channel-group 65 mode on
!
interface GigabitEthernet9/11
Cisco IOS Release 12.1(13)E13
63
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface GigabitEthernet9/12
no ip address
shutdown
!
interface GigabitEthernet9/13
no ip address
shutdown
!
interface GigabitEthernet9/14
no ip address
shutdown
!
interface GigabitEthernet9/15
no ip address
shutdown
!
interface GigabitEthernet9/16
no ip address
shutdown
!
interface Vlan1
no ip address
shutdown
!
router eigrp 1320
redistribute ospf 1 metric 100000 10 255 1 1500 route-map OSPF2EIGRP-tag
network 172.31.0.126 0.0.0.0
network 172.31.1.40 0.0.0.7
network 172.31.1.136 0.0.0.3
no auto-summary
eigrp log-neighbor-changes
!
router ospf 1
router-id 172.31.2.13
log-adjacency-changes
auto-cost reference-bandwidth 100000
redistribute eigrp 1320 subnets route-map EIGRP2OSPF-tag
passive-interface default
no passive-interface GigabitEthernet3/13
no passive-interface FastEthernet7/3
no passive-interface FastEthernet7/47
no passive-interface FastEthernet7/48
no passive-interface Port-channel12
no passive-interface Port-channel13
no passive-interface Port-channel14
no passive-interface Port-channel15
no passive-interface Port-channel16
no passive-interface Port-channel17
no passive-interface Port-channel64
no passive-interface Port-channel65
no passive-interface Port-channel66
no passive-interface Port-channel67
no passive-interface Port-channel113
network 172.31.0.0 0.0.0.255 area 0
network 172.31.1.12 0.0.0.3 area 0
network 172.31.1.8 0.0.0.7 area 0
network 172.31.1.20 0.0.0.3 area 0
network 172.31.1.48 0.0.0.7 area 1
network 172.31.1.92 0.0.0.3 area 2
network 172.31.1.96 0.0.0.3 area 2
network 172.31.1.128 0.0.0.3 area 3
Cisco IOS Release 12.1(13)E13
64
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
network 172.31.1.132 0.0.0.3 area 5
network 172.31.1.252 0.0.0.3 area 0
network 172.31.2.12 0.0.0.3 area 0
network 172.31.3.0 0.0.0.255 area 4
network 172.31.4.0 0.0.0.255 area 0
network 172.31.10.0 0.0.0.3 area 0
network 172.31.11.0 0.0.0.255 area 4
network 172.31.99.0 0.0.0.255 area 0
maximum-paths 6
!
router bgp 100
no synchronization
bgp log-neighbor-changes
network 172.31.0.0 mask 255.255.128.0
network 172.31.128.0 mask 255.255.224.0
redistribute eigrp 1320
redistribute ospf 1
neighbor sh1-ibgp peer-group
neighbor sh1-ibgp remote-as 100
neighbor sh1-ibgp update-source Loopback0
neighbor sh1-ibgp version 4
neighbor sh1-ibgp next-hop-self
neighbor 172.31.4.97 peer-group sh1-ibgp
neighbor 172.31.4.98 peer-group sh1-ibgp
neighbor 172.31.4.99 peer-group sh1-ibgp
no auto-summary
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.31.4.99
ip route 172.18.177.128 255.255.255.192 10.194.17.254
ip route 172.18.179.128 255.255.255.192 10.194.17.254
ip route 172.31.1.98 255.255.255.255 Port-channel67
no ip http server
ip pim rp-address 172.31.0.98 3 override
ip pim spt-threshold infinity
ip pim send-rp-announce Loopback1 scope 64 group-list 1
ip pim send-rp-discovery Loopback1 scope 64
ip msdp peer 172.31.4.99 connect-source Loopback0
ip msdp description 172.31.4.99 SH1-99
ip msdp sa-filter out 172.31.4.99 list 131
ip msdp mesh-group regional 172.31.4.99
ip msdp cache-sa-state
ip msdp originator-id Loopback0
!
!
logging 172.18.177.132
access-list 1 permit 239.100.0.0 0.0.255.255
access-list 3 permit 224.0.1.39
access-list 3 permit 224.0.1.40
access-list 10 permit 239.255.254.241
access-list 17 permit 0.0.0.0 255.254.255.255
access-list 18 permit 180.1.0.0 0.0.254.255
access-list 22 permit 160.0.0.0 0.255.254.255
access-list 26 permit 165.250.241.0 0.0.0.255
access-list 30 deny
172.31.1.96
access-list 30 permit any
access-list 44 permit 172.31.1.129
access-list 131 permit ip any 239.100.0.0 0.0.255.255
access-list 181 permit ip any any
access-list 182 permit ip any any
access-list 191 permit ip host 172.31.1.20 host 172.31.1.21
access-list 191 permit ip host 172.31.1.21 host 172.31.1.20
access-list 199 permit ip host 172.31.1.98 host 172.31.1.97 log
route-map EIGRP2BGP permit 10
Cisco IOS Release 12.1(13)E13
65
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
match ip address 18
!
route-map OSPF2EIGRP-tag deny 10
match tag 150
!
route-map OSPF2EIGRP-tag permit 20
set tag 150
!
route-map EIGRP2OSPF-tag deny 10
match tag 140
!
route-map EIGRP2OSPF-tag permit 20
set tag 140
!
route-map OSPF2EIGRP-odd deny 10
match ip address 22
!
route-map OSPF2EIGRP-odd permit 20
!
route-map OSPF2EIGRP deny 10
match ip address 17
!
route-map OSPF2EIGRP permit 20
!
route-map ospf-to-eigrp permit 10
set tag 140
!
route-map ospf-to-eigrp deny 20
match tag 140
!
route-map eigrp-to-ospf permit 10
set tag 150
!
route-map eigrp-to-ospf deny 20
match tag 150
!
snmp-server community public RO
snmp-server community cisco RW
!
alias exec ospf sh run | be router ospf
alias exec eigrp sh run | be router eigrp
alias exec bgp sh runn | beg router bgp
!
line con 0
exec-timeout 0 0
line vty 0 4
exec-timeout 0 0
password cisco
login
history size 256
transport input lat pad mop telnet rlogin udptn nasi
!
exception protocol ftp
exception dump 172.18.177.129
exception memory fragment 200000
exception memory minimum 200000
scheduler runtime netinput 300
ntp clock-period 17180152
ntp update-calendar
ntp server 172.18.177.131
ntp server 172.18.177.132 prefer
end
SH1-100#show version
Cisco IOS Release 12.1(13)E13
66
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Cisco Internetwork Operating System Software
IOS (tm) c6sup2_rp Software (c6sup2_rp-JSV-M), Version 12.1(nightly13e.E040229) NIGHTLY
BUILD, synced to cosmos_e V121_12_5_E1
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Mon 01-Mar-04 00:11 by
Image text-base: 0x40008BF0, data-base: 0x41A4C000
ROM: System Bootstrap, Version 12.1(4r)E, RELEASE SOFTWARE (fc1)
SH1-100 uptime is 2 days, 22 hours, 46 minutes
Time since SH1-100 switched to active is 2 days, 22 hours, 32 minutes
System returned to ROM by power-on (SP by power-on)
System restarted at 12:57:31 EDT Mon Mar 15 2004
System image file is "sup-bootflash:c6sup22-jsv-mz.v121_13_e_throttle.040229"
cisco Catalyst 6000 (R7000) processor with 458752K/65536K bytes of memory.
Processor board ID SAD055107AS
R7000 CPU at 300Mhz, Implementation 39, Rev 3.3, 256KB L2, 1024KB L3 Cache
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
1 Virtual Ethernet/IEEE 802.3 interface(s)
48 FastEthernet/IEEE 802.3 interface(s)
52 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.
16384K bytes of Flash internal SIMM (Sector size 512K).
Standby is up
Standby has 458752K/65536K bytes of memory.
Configuration register is 0x2102
SH1-100#show module
Mod Ports Card Type
--- ----- -------------------------------------1
2 Catalyst 6000 supervisor 2 (Active)
2
2 Catalyst 6000 supervisor 2 (Standby)
3
16 Pure SFM-mode 16 port 1000mb GBIC
4
16 Pure SFM-mode 16 port 1000mb GBIC
5
0 Switching Fabric Module-136 (Active)
6
0 Switching Fabric Module-136 (Standby)
7
48 SFM-capable 48-port 10/100 Mbps RJ45
9
16 SFM-capable 16 port 1000mb GBIC
Model
-----------------WS-X6K-S2U-MSFC2
WS-X6K-S2U-MSFC2
WS-X6816-GBIC
WS-X6816-GBIC
WS-X6500-SFM2
WS-X6500-SFM2
WS-X6548-RJ-45
WS-X6516-GBIC
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0002.7e38.6abc to 0002.7e38.6abd
3.2
6.1(3)
2 0001.6415.b81e to 0001.6415.b81f
3.2
6.1(3)
3 0001.63d3.b4fa to 0001.63d3.b509
1.2
12.1(5r)E1
4 0001.63d4.4c72 to 0001.63d4.4c81
1.2
12.1(5r)E1
5 0001.0002.0003 to 0001.0002.0003
1.1
6.1(3)
6 0001.0002.0003 to 0001.0002.0003
1.1
6.1(3)
7 0002.7ee3.f566 to 0002.7ee3.f595
4.3
6.3(1)
9 0001.63d4.3da2 to 0001.63d4.3db1
4.0
6.1(3)
Mod
--1
1
2
2
3
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Distributed Forwarding Card
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-DFC
Serial No.
----------SAD055106GE
SAD0602030E
SAD055101LK
SAD055101PJ
SAD06010302
SAD0552048K
SAD062101D7
SAD055204VV
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
12.1(nightly
12.1(nightly
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD055004RV
3.0
Ok
SAD055107AS
2.0
Ok
SAD060204M0
3.0
Ok
SAD0552068V
1.3
Ok
SAD055102P3
2.0
Ok
Cisco IOS Release 12.1(13)E13
67
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
4 Distributed Forwarding Card WS-F6K-DFC
9 Distributed Forwarding Card WS-F6K-DFC
SAD060100F7
SAL06489A2Q
Mod Online Diag Status
--- ------------------1 Pass
2 Pass
3 Pass
4 Pass
5 Pass
6 Pass
7 Pass
9 Pass
SH1-100#
Return to SH1-100, page 54
SH1-101
Go to Test Device Configurations, page 17
Go to Financial Lab Topology, page 2
Go to Test Cases, page 249
SH1-101#term length 0
SH1-101#show config
Using 14539 out of 391160 bytes
!
!
version 12.1
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
no service password-encryption
service internal
!
hostname SH1-101
!
boot system flash sup-bootflash:
boot bootldr bootflash:
no logging console
aaa new-model
aaa authentication login default enable
aaa authentication login sh1-testcase group tacacs+ enable
enable secret 5 $1$lGzL$fPcvjf6cuGekcJs87L8q40
!
clock timezone EST -5
clock summer-time EDT recurring
ip subnet-zero
!
!
ip ftp username safeharbor
ip ftp password shshsh
no ip domain-lookup
ip domain-name cisco.com
!
ip multicast-routing
mls flow ip destination-source
mls flow ipx destination
mls ip multicast consistency-check
!
redundancy
mode rpr-plus
Cisco IOS Release 12.1(13)E13
68
2.0
2.5
Ok
Ok
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
main-cpu
auto-sync running-config
auto-sync standard
!
power redundancy-mode combined
!
!
!
interface Loopback0
ip address 172.31.4.101 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 172.31.0.102 255.255.255.255
ip pim sparse-mode
!
interface Port-channel10
description dista-1 PoCha
no ip address
switchport
switchport trunk encapsulation dot1q
!
interface Port-channel14
description sh1-99 po14
ip address 172.31.1.26 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel114
description sh1-100 po14
ip address 172.31.1.42 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface GigabitEthernet1/1
no ip address
shutdown
!
interface GigabitEthernet1/2
no ip address
shutdown
!
interface GigabitEthernet3/1
description sh1-99 g3/2
no ip address
channel-group 14 mode on
!
interface GigabitEthernet3/2
description sh1-99 g4/2
no ip address
channel-group 14 mode on
!
interface GigabitEthernet3/3
description sh1-100 g3/4
no ip address
channel-group 114 mode on
!
interface GigabitEthernet3/4
no ip address
shutdown
Cisco IOS Release 12.1(13)E13
69
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface GigabitEthernet3/5
no ip address
shutdown
!
interface GigabitEthernet3/6
no ip address
shutdown
!
interface GigabitEthernet3/7
no ip address
shutdown
!
interface GigabitEthernet3/8
no ip address
shutdown
!
interface GigabitEthernet3/9
description sh1-99 g3/10
no ip address
channel-group 14 mode on
!
interface GigabitEthernet3/10
description sh1-99 g4/10
no ip address
channel-group 14 mode on
!
interface GigabitEthernet3/11
description sh1-100 g4/12
no ip address
channel-group 114 mode on
!
interface GigabitEthernet3/12
no ip address
shutdown
!
interface GigabitEthernet3/13
no ip address
shutdown
!
interface GigabitEthernet3/14
no ip address
shutdown
!
interface GigabitEthernet3/15
no ip address
shutdown
!
interface GigabitEthernet3/16
description Ix-11/2
ip address 172.31.64.14 255.255.255.0
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
shutdown
!
interface GigabitEthernet7/1
description dista-1 3/1
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 10 mode on
!
interface GigabitEthernet7/2
Cisco IOS Release 12.1(13)E13
70
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
description dista-1 3/2
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 10 mode on
!
interface GigabitEthernet7/3
no ip address
shutdown
!
interface GigabitEthernet7/4
no ip address
shutdown
!
interface GigabitEthernet7/5
no ip address
shutdown
!
interface GigabitEthernet7/6
no ip address
shutdown
!
interface GigabitEthernet7/7
no ip address
shutdown
!
interface GigabitEthernet7/8
no ip address
shutdown
!
interface GigabitEthernet7/9
no ip address
ip pim sparse-mode
shutdown
!
interface GigabitEthernet7/10
no ip address
shutdown
!
interface GigabitEthernet7/11
no ip address
shutdown
!
interface GigabitEthernet7/12
no ip address
shutdown
!
interface GigabitEthernet7/13
no ip address
shutdown
!
interface GigabitEthernet7/14
no ip address
shutdown
!
interface GigabitEthernet7/15
no ip address
shutdown
!
interface GigabitEthernet7/16
description Ix-12/1
ip address 172.31.201.1 255.255.255.252
ip access-group 181 in
ip access-group 181 out
Cisco IOS Release 12.1(13)E13
71
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip pim sparse-mode
!
interface FastEthernet8/1
no ip address
shutdown
!
interface FastEthernet8/2
no ip address
shutdown
!
interface FastEthernet8/3
no ip address
shutdown
!
interface FastEthernet8/4
no ip address
shutdown
!
interface FastEthernet8/5
no ip address
shutdown
!
interface FastEthernet8/6
no ip address
shutdown
!
interface FastEthernet8/7
no ip address
shutdown
!
interface FastEthernet8/8
no ip address
shutdown
!
interface FastEthernet8/9
no ip address
shutdown
!
interface FastEthernet8/10
no ip address
shutdown
!
interface FastEthernet8/11
no ip address
shutdown
!
interface FastEthernet8/12
no ip address
shutdown
!
interface FastEthernet8/13
no ip address
shutdown
!
interface FastEthernet8/14
no ip address
shutdown
!
interface FastEthernet8/15
no ip address
shutdown
!
interface FastEthernet8/16
no ip address
Cisco IOS Release 12.1(13)E13
72
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface FastEthernet8/17
no ip address
shutdown
!
interface FastEthernet8/18
no ip address
shutdown
!
interface FastEthernet8/19
no ip address
shutdown
!
interface FastEthernet8/20
no ip address
shutdown
!
interface FastEthernet8/21
no ip address
shutdown
!
interface FastEthernet8/22
no ip address
shutdown
!
interface FastEthernet8/23
no ip address
shutdown
!
interface FastEthernet8/24
description flashnet
ip address 10.194.17.101 255.255.255.0
shutdown
duplex full
!
interface FastEthernet9/1
no ip address
!
interface FastEthernet9/2
no ip address
!
interface FastEthernet9/3
description IXIA 13/2
no ip address
switchport
switchport access vlan 201
switchport mode access
!
interface FastEthernet9/4
no ip address
switchport
switchport access vlan 40
switchport mode access
!
interface FastEthernet9/5
no ip address
shutdown
!
interface FastEthernet9/6
description Connected to Ixia 16/8
no ip address
speed 100
duplex full
Cisco IOS Release 12.1(13)E13
73
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
switchport
switchport access vlan 40
switchport mode access
!
interface FastEthernet9/7
no ip address
shutdown
!
interface FastEthernet9/8
no ip address
shutdown
!
interface FastEthernet9/9
no ip address
shutdown
!
interface FastEthernet9/10
no ip address
shutdown
!
interface FastEthernet9/11
no ip address
shutdown
!
interface FastEthernet9/12
no ip address
shutdown
!
interface FastEthernet9/13
no ip address
shutdown
!
interface FastEthernet9/14
no ip address
shutdown
!
interface FastEthernet9/15
no ip address
shutdown
!
interface FastEthernet9/16
no ip address
shutdown
!
interface FastEthernet9/17
no ip address
shutdown
!
interface FastEthernet9/18
no ip address
shutdown
!
interface FastEthernet9/19
no ip address
shutdown
!
interface FastEthernet9/20
no ip address
shutdown
!
interface FastEthernet9/21
no ip address
shutdown
!
Cisco IOS Release 12.1(13)E13
74
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface FastEthernet9/22
no ip address
shutdown
!
interface FastEthernet9/23
no ip address
shutdown
!
interface FastEthernet9/24
description flashnet
ip address 10.194.17.101 255.255.255.0
speed 100
duplex full
!
interface FastEthernet9/25
no ip address
shutdown
!
interface FastEthernet9/26
no ip address
shutdown
!
interface FastEthernet9/27
no ip address
shutdown
!
interface FastEthernet9/28
no ip address
shutdown
!
interface FastEthernet9/29
no ip address
shutdown
!
interface FastEthernet9/30
no ip address
shutdown
!
interface FastEthernet9/31
no ip address
shutdown
!
interface FastEthernet9/32
no ip address
shutdown
!
interface FastEthernet9/33
no ip address
shutdown
!
interface FastEthernet9/34
no ip address
shutdown
!
interface FastEthernet9/35
no ip address
shutdown
!
interface FastEthernet9/36
no ip address
shutdown
!
interface FastEthernet9/37
no ip address
Cisco IOS Release 12.1(13)E13
75
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface FastEthernet9/38
no ip address
shutdown
!
interface FastEthernet9/39
no ip address
shutdown
!
interface FastEthernet9/40
no ip address
shutdown
!
interface FastEthernet9/41
no ip address
shutdown
!
interface FastEthernet9/42
no ip address
shutdown
!
interface FastEthernet9/43
no ip address
shutdown
!
interface FastEthernet9/44
no ip address
shutdown
!
interface FastEthernet9/45
no ip address
shutdown
!
interface FastEthernet9/46
no ip address
shutdown
!
interface FastEthernet9/47
no ip address
shutdown
!
interface FastEthernet9/48
no ip address
shutdown
!
interface Vlan1
no ip address
!
interface Vlan40
ip address 172.31.70.14 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 1 ip 172.31.70.1
standby 1 priority 110
standby 1 preempt
standby 2 ip 172.31.70.254
standby 2 priority 90
standby 2 preempt
!
interface Vlan41
Cisco IOS Release 12.1(13)E13
76
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip address 172.31.71.14 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 2 ip 172.31.71.1
standby 2 priority 110
standby 2 preempt
standby 3 ip 172.31.71.254
standby 3 priority 90
standby 3 preempt
!
interface Vlan42
ip address 172.31.72.14 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 3 ip 172.31.72.1
standby 3 priority 110
standby 3 preempt
standby 4 ip 172.31.72.254
standby 4 priority 90
standby 4 preempt
!
interface Vlan43
ip address 172.31.73.14 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 4 ip 172.31.73.1
standby 4 priority 110
standby 4 preempt
standby 5 ip 172.31.73.254
standby 5 priority 90
standby 5 preempt
!
interface Vlan44
ip address 172.31.74.14 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 5 ip 172.31.74.1
standby 5 priority 110
standby 5 preempt
standby 6 ip 172.31.74.254
standby 6 priority 90
standby 6 preempt
!
interface Vlan45
ip address 172.31.75.14 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 6 ip 172.31.75.1
standby 6 priority 110
Cisco IOS Release 12.1(13)E13
77
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
standby
standby
standby
standby
6
7
7
7
preempt
ip 172.31.75.254
priority 90
preempt
!
interface Vlan46
ip address 172.31.76.14 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 7 ip 172.31.76.1
standby 7 priority 110
standby 7 preempt
standby 8 ip 172.31.76.254
standby 8 priority 90
standby 8 preempt
!
interface Vlan47
ip address 172.31.77.14 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 8 ip 172.31.77.1
standby 8 priority 110
standby 8 preempt
standby 9 ip 172.31.77.254
standby 9 priority 90
standby 9 preempt
!
interface Vlan48
ip address 172.31.78.14 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 9 ip 172.31.78.1
standby 9 priority 110
standby 9 preempt
standby 10 ip 172.31.78.254
standby 10 priority 90
standby 10 preempt
!
interface Vlan49
ip address 172.31.79.14 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 10 ip 172.31.79.1
standby 10 priority 110
standby 10 preempt
standby 11 ip 172.31.79.254
standby 11 priority 90
standby 11 preempt
!
interface Vlan50
ip address 172.31.80.14 255.255.255.0
no ip redirects
Cisco IOS Release 12.1(13)E13
78
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 11 ip 172.31.80.1
standby 11 priority 110
standby 11 preempt
standby 12 ip 172.31.80.254
standby 12 priority 90
standby 12 preempt
!
interface Vlan150
description Pagent EIGRP VLAN
ip address 172.31.150.101 255.255.255.0
no ip redirects
ip pim sparse-mode
standby ip 172.31.150.1
standby priority 120
standby preempt
!
interface Vlan180
no ip address
!
interface Vlan201
ip address 172.31.200.5 255.255.255.252
ip pim sparse-mode
shutdown
!
router eigrp 1320
passive-interface default
no passive-interface Vlan40
no passive-interface Vlan150
no passive-interface GigabitEthernet7/16
no passive-interface Port-channel14
no passive-interface Port-channel114
no passive-interface Loopback0
no passive-interface Loopback1
network 172.31.4.0 0.0.0.255
network 172.31.60.0 0.0.1.255
network 172.31.150.0 0.0.0.255
network 172.31.0.0
auto-summary
eigrp log-neighbor-changes
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.31.4.99
ip route 172.18.177.128 255.255.255.192 10.194.17.254
ip route 172.18.179.128 255.255.255.192 10.194.17.254
no ip http server
ip pim rp-address 172.31.0.102 1 override
ip pim rp-address 172.31.0.98 2 override
ip pim spt-threshold infinity
ip msdp peer 172.31.4.102 connect-source Loopback0
ip msdp cache-sa-state
ip msdp originator-id Loopback0
!
!
logging trap debugging
logging 172.18.177.132
access-list 1 permit 239.255.0.0 0.0.255.255
access-list 1 deny
any
access-list 2 permit 224.0.1.39
access-list 2 permit 224.0.1.40
access-list 30 deny
172.31.30.0
Cisco IOS Release 12.1(13)E13
79
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
access-list 30 permit any
access-list 40 deny
239.1.1.40
access-list 40 permit any
access-list 44 deny
239.255.200.50
access-list 100 permit ip any 172.31.41.0 0.0.0.255
access-list 181 permit ip any any
snmp-server community public RO
snmp-server community cisco RW
snmp-server enable traps casa
snmp-server enable traps vtp
snmp-server enable traps hsrp
snmp-server enable traps config
snmp-server enable traps entity
snmp-server enable traps bgp
snmp-server enable traps rsvp
snmp-server enable traps frame-relay
snmp-server enable traps syslog
snmp-server enable traps rtr
snmp-server enable traps dlsw
snmp-server enable traps isdn call-information
snmp-server enable traps isdn layer2
snmp-server host 172.20.26.12 public
!
tacacs-server host 172.18.177.132
alias exec ospf sh run | be router ospf
alias exec eigrp sh run | be router eigrp
!
line con 0
exec-timeout 0 0
line vty 0 4
exec-timeout 0 0
password cisco
history size 256
transport input lat pad mop telnet rlogin udptn nasi
!
exception protocol ftp
exception dump 172.18.177.129
exception memory fragment 200000
exception memory minimum 200000
scheduler runtime netinput 300
ntp clock-period 17180013
ntp update-calendar
ntp server 172.18.177.131
ntp server 172.18.177.132 prefer
end
SH1-101#show version
Cisco Internetwork Operating System Software
IOS (tm) c6sup2_rp Software (c6sup2_rp-JSV-M), Version 12.1(nightly13e.E040229) NIGHTLY
BUILD, synced to cosmos_e V121_12_5_E1
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Mon 01-Mar-04 00:11 by
Image text-base: 0x40008BF0, data-base: 0x41A4C000
ROM: System Bootstrap, Version 12.1(4r)E, RELEASE SOFTWARE (fc1)
SH1-101 uptime is 2 weeks, 2 days, 19 hours, 15 minutes
Time since SH1-101 switched to active is 2 weeks, 2 days, 19 hours, 15 minutes
System returned to ROM by power-on (SP by power-on)
System restarted at 16:28:23 EST Mon Mar 1 2004
System image file is "sup-bootflash:c6sup22-jsv-mz.v121_13_e_throttle.040229"
cisco Catalyst 6000 (R7000) processor with 458752K/65536K bytes of memory.
Processor board ID SAD055205S3
Cisco IOS Release 12.1(13)E13
80
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
R7000 CPU at 300Mhz, Implementation 39, Rev 2.1, 256KB L2, 1024KB L3 Cache
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
15 Virtual Ethernet/IEEE 802.3 interface(s)
72 FastEthernet/IEEE 802.3 interface(s)
34 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.
16384K bytes of Flash internal SIMM (Sector size 512K).
Configuration register is 0x2102
SH1-101#show module
Mod Ports Card Type
--- ----- -------------------------------------1
2 Catalyst 6000 supervisor 2 (Active)
3
16 Pure SFM-mode 16 port 1000mb GBIC
5
0 Switching Fabric Module-136 (Active)
6
0 Switching Fabric Module-136 (Standby)
7
16 SFM-capable 16 port 1000mb GBIC
8
24 24 port 100FX Multi mode
9
48 SFM-capable 48-port 10/100 Mbps RJ45
Model
-----------------WS-X6K-S2U-MSFC2
WS-X6816-GBIC
WS-X6500-SFM2
WS-X6500-SFM2
WS-X6516-GBIC
WS-X6324-100FX-MM
WS-X6548-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.6415.b3d2 to 0001.6415.b3d3
3.2
6.1(3)
3 0001.63d3.b59a to 0001.63d3.b5a9
1.2
12.1(5r)E1
5 0001.0002.0003 to 0001.0002.0003
1.1
6.1(3)
6 0001.0002.0003 to 0001.0002.0003
1.1
6.1(3)
7 0001.63d4.39f2 to 0001.63d4.3a01
4.0
6.1(3)
8 0008.a430.0ab0 to 0008.a430.0ac7
3.0
5.4(2)
9 000e.3828.55b0 to 000e.3828.55df
5.2
6.3(1)
Mod
--1
1
3
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Distributed Forwarding Card
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-DFC
Serial No.
----------SAD06010069
SAD055101MR
SAD060102Y4
SAD055002UN
SAD055204XF
SAD055106ZS
SAL0745P5VD
Sw
-----------7.5(0.6)HUB1
12.1(nightly
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Ok
Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD055205B0
3.0
Ok
SAD055205S3
1.3
Ok
SAD055102PV
2.0
Ok
Mod Online Diag Status
--- ------------------1 Pass
3 Pass
5 Pass
6 Pass
7 Pass
8 Pass
9 Pass
SH1-101#
Return to SH1-101, page 68
SH1-102
Go to Test Device Configurations, page 17
Go to Financial Lab Topology, page 2
Go to Test Cases, page 249
SH1-102>enable
Cisco IOS Release 12.1(13)E13
81
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Password:
SH1-102#term length 0
SH1-102#show config
Using 24238 out of 391160 bytes
!
!
version 12.1
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
no service password-encryption
service internal
!
hostname SH1-102
!
boot system flash sup-bootflash:
boot bootldr bootflash:
logging buffered 100000 debugging
no logging console
enable secret 5 $1$S.Ic$tdvvMChZC92pvJtvBCPFf/
!
clock timezone EST -5
clock summer-time EDT recurring
vtp domain FIN
vtp mode transparent
ip subnet-zero
!
!
ip ftp username safeharbor
ip ftp password shshsh
no ip domain-lookup
!
ip multicast-routing
mls flow ip destination-source
mls flow ipx destination
mls ip multicast consistency-check
!
redundancy
mode rpr-plus
main-cpu
auto-sync startup-config
auto-sync running-config
auto-sync config-register
auto-sync standard
!
power redundancy-mode combined
!
!
vlan 1
tb-vlan1 1002
tb-vlan2 1003
!
vlan 10,15,40-50,60-61,101-105,122,131,150,200
!
vlan 1002
tb-vlan1 1
tb-vlan2 1003
!
vlan 1003
tb-vlan1 1
tb-vlan2 1002
parent 1005
backupcrf enable
!
vlan 1004
Cisco IOS Release 12.1(13)E13
82
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
bridge 1
stp type ibm
!
vlan 1005
bridge 1
!
!
interface Loopback0
ip address 172.31.4.102 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 172.31.0.102 255.255.255.255
ip pim sparse-mode
!
interface Port-channel10
description dista-1 PoCha
no ip address
switchport
switchport trunk encapsulation dot1q
!
interface Port-channel14
no ip address
!
interface Port-channel15
description sh1-99 po15
ip address 172.31.1.30 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
ip hold-time eigrp 1000 250
logging event link-status
!
interface Port-channel20
no ip address
!
interface Port-channel115
description sh1-100 po15
ip address 172.31.1.46 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface GigabitEthernet1/1
no ip address
shutdown
!
interface GigabitEthernet1/2
no ip address
shutdown
!
interface GigabitEthernet2/1
no ip address
shutdown
!
interface GigabitEthernet2/2
no ip address
shutdown
!
interface GigabitEthernet3/1
description sh1-100 g3/2
no ip address
ip access-group 181 in
Cisco IOS Release 12.1(13)E13
83
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
channel-group 115 mode on
!
interface GigabitEthernet3/2
description sh1-100 g4/2
no ip address
ip access-group 181 in
channel-group 115 mode on
!
interface GigabitEthernet3/3
description sh1-99 g3/4
no ip address
channel-group 15 mode on
!
interface GigabitEthernet3/4
no ip address
shutdown
!
interface GigabitEthernet3/5
no ip address
shutdown
!
interface GigabitEthernet3/6
no ip address
shutdown
!
interface GigabitEthernet3/7
no ip address
shutdown
!
interface GigabitEthernet3/8
no ip address
shutdown
!
interface GigabitEthernet3/9
description sh1-100 g3/10
no ip address
ip access-group 181 in
channel-group 115 mode on
!
interface GigabitEthernet3/10
description sh1-100 g4/10
no ip address
ip access-group 181 in
channel-group 115 mode on
!
interface GigabitEthernet3/11
description sh1-99 g4/12
no ip address
channel-group 15 mode on
!
interface GigabitEthernet3/12
no ip address
shutdown
!
interface GigabitEthernet3/13
no ip address
shutdown
!
interface GigabitEthernet3/14
no ip address
shutdown
!
interface GigabitEthernet3/15
no ip address
Cisco IOS Release 12.1(13)E13
84
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface GigabitEthernet3/16
no ip address
ip pim sparse-mode
shutdown
!
interface FastEthernet4/1
ip address 2.2.2.1 255.255.255.252
!
interface FastEthernet4/2
description IXIA 13/1
no ip address
switchport
switchport access vlan 200
switchport mode access
!
interface FastEthernet4/3
no ip address
shutdown
!
interface FastEthernet4/4
no ip address
!
interface FastEthernet4/5
description Ix-2/4
ip address 172.31.202.1 255.255.255.252
ip access-group 181 in
ip access-group 181 out
no ip unreachables
ip pim sparse-mode
speed 100
duplex full
!
interface FastEthernet4/6
no ip address
shutdown
!
interface FastEthernet4/7
no ip address
shutdown
!
interface FastEthernet4/8
no ip address
shutdown
!
interface FastEthernet4/9
no ip address
shutdown
!
interface FastEthernet4/10
no ip address
shutdown
!
interface FastEthernet4/11
no ip address
shutdown
!
interface FastEthernet4/12
no ip address
shutdown
!
interface FastEthernet4/13
ip address 1.1.1.1 255.255.255.252
Cisco IOS Release 12.1(13)E13
85
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface FastEthernet4/14
ip address 1.1.1.5 255.255.255.252
shutdown
!
interface FastEthernet4/15
no ip address
shutdown
!
interface FastEthernet4/16
no ip address
shutdown
!
interface FastEthernet4/17
no ip address
shutdown
!
interface FastEthernet4/18
no ip address
shutdown
!
interface FastEthernet4/19
no ip address
shutdown
!
interface FastEthernet4/20
no ip address
shutdown
!
interface FastEthernet4/21
no ip address
shutdown
!
interface FastEthernet4/22
no ip address
shutdown
!
interface FastEthernet4/23
no ip address
shutdown
!
interface FastEthernet4/24
description flashnet
ip address 10.194.17.102 255.255.255.0
speed 100
duplex full
!
interface FastEthernet4/25
no ip address
shutdown
!
interface FastEthernet4/26
no ip address
shutdown
!
interface FastEthernet4/27
no ip address
shutdown
!
interface FastEthernet4/28
no ip address
shutdown
!
Cisco IOS Release 12.1(13)E13
86
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface FastEthernet4/29
no ip address
shutdown
!
interface FastEthernet4/30
no ip address
shutdown
!
interface FastEthernet4/31
no ip address
shutdown
!
interface FastEthernet4/32
no ip address
shutdown
!
interface FastEthernet4/33
no ip address
shutdown
!
interface FastEthernet4/34
no ip address
shutdown
!
interface FastEthernet4/35
no ip address
shutdown
!
interface FastEthernet4/36
no ip address
shutdown
!
interface FastEthernet4/37
no ip address
shutdown
!
interface FastEthernet4/38
no ip address
shutdown
!
interface FastEthernet4/39
no ip address
shutdown
!
interface FastEthernet4/40
no ip address
shutdown
!
interface FastEthernet4/41
no ip address
shutdown
!
interface FastEthernet4/42
no ip address
shutdown
!
interface FastEthernet4/43
no ip address
shutdown
!
interface FastEthernet4/44
no ip address
shutdown
!
Cisco IOS Release 12.1(13)E13
87
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface FastEthernet4/45
no ip address
shutdown
!
interface FastEthernet4/46
no ip address
shutdown
!
interface FastEthernet4/47
no ip address
shutdown
!
interface FastEthernet4/48
no ip address
!
interface GigabitEthernet7/1
no ip address
shutdown
!
interface GigabitEthernet7/2
no ip address
shutdown
!
interface GigabitEthernet7/3
no ip address
shutdown
!
interface GigabitEthernet7/4
no ip address
shutdown
!
interface GigabitEthernet7/5
no ip address
shutdown
!
interface GigabitEthernet7/6
description dista-1 3/6
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 10 mode on
!
interface GigabitEthernet7/7
no ip address
shutdown
!
interface GigabitEthernet7/8
description dista-1 3/8
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 10 mode on
!
interface GigabitEthernet7/9
no ip address
ip pim sparse-mode
shutdown
!
interface GigabitEthernet7/10
no ip address
shutdown
!
interface GigabitEthernet7/11
no ip address
Cisco IOS Release 12.1(13)E13
88
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface GigabitEthernet7/12
no ip address
shutdown
!
interface GigabitEthernet7/13
no ip address
shutdown
!
interface GigabitEthernet7/14
no ip address
shutdown
!
interface GigabitEthernet7/15
no ip address
shutdown
!
interface GigabitEthernet7/16
no ip address
shutdown
!
interface FastEthernet8/1
no ip address
shutdown
!
interface FastEthernet8/2
no ip address
shutdown
!
interface FastEthernet8/3
no ip address
shutdown
!
interface FastEthernet8/4
no ip address
shutdown
!
interface FastEthernet8/5
no ip address
shutdown
!
interface FastEthernet8/6
no ip address
shutdown
!
interface FastEthernet8/7
no ip address
shutdown
!
interface FastEthernet8/8
no ip address
shutdown
!
interface FastEthernet8/9
no ip address
shutdown
!
interface FastEthernet8/10
no ip address
shutdown
!
interface FastEthernet8/11
no ip address
Cisco IOS Release 12.1(13)E13
89
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface FastEthernet8/12
no ip address
shutdown
!
interface FastEthernet8/13
no ip address
shutdown
!
interface FastEthernet8/14
no ip address
shutdown
!
interface FastEthernet8/15
no ip address
shutdown
!
interface FastEthernet8/16
no ip address
shutdown
!
interface FastEthernet8/17
no ip address
shutdown
!
interface FastEthernet8/18
no ip address
shutdown
!
interface FastEthernet8/19
no ip address
shutdown
!
interface FastEthernet8/20
no ip address
shutdown
!
interface FastEthernet8/21
no ip address
shutdown
!
interface FastEthernet8/22
no ip address
shutdown
!
interface FastEthernet8/23
no ip address
shutdown
!
interface FastEthernet8/24
description flashnet
no ip address
shutdown
duplex full
!
interface Vlan1
no ip address
shutdown
!
interface Vlan40
ip address 172.31.70.15 255.255.255.0
no ip redirects
ip directed-broadcast
Cisco IOS Release 12.1(13)E13
90
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 1 ip 172.31.70.1
standby 1 priority 90
standby 1 preempt
standby 2 ip 172.31.70.254
standby 2 priority 110
standby 2 preempt
!
interface Vlan41
ip address 172.31.71.15 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 2 ip 172.31.71.1
standby 2 priority 90
standby 2 preempt
standby 3 ip 172.31.71.254
standby 3 priority 110
standby 3 preempt
!
interface Vlan42
ip address 172.31.72.15 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 3 ip 172.31.72.1
standby 3 priority 90
standby 3 preempt
standby 4 ip 172.31.72.254
standby 4 priority 110
standby 4 preempt
!
interface Vlan43
ip address 172.31.73.15 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 4 ip 172.31.73.1
standby 4 priority 90
standby 4 preempt
standby 5 ip 172.31.73.254
standby 5 priority 110
standby 5 preempt
!
interface Vlan44
ip address 172.31.74.15 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 5 ip 172.31.74.1
standby 5 priority 90
standby 5 preempt
standby 6 ip 172.31.74.254
standby 6 priority 110
Cisco IOS Release 12.1(13)E13
91
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
standby 6 preempt
!
interface Vlan45
ip address 172.31.75.15 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 6 ip 172.31.75.1
standby 6 priority 90
standby 6 preempt
standby 7 ip 172.31.75.254
standby 7 priority 110
standby 7 preempt
!
interface Vlan46
ip address 172.31.76.15 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 7 ip 172.31.76.1
standby 7 priority 90
standby 7 preempt
standby 8 ip 172.31.76.254
standby 8 priority 110
standby 8 preempt
!
interface Vlan47
ip address 172.31.77.15 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 8 ip 172.31.77.1
standby 8 priority 90
standby 8 preempt
standby 9 ip 172.31.77.254
standby 9 priority 110
standby 9 preempt
!
interface Vlan48
ip address 172.31.78.15 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 9 ip 172.31.78.1
standby 9 priority 90
standby 9 preempt
standby 10 ip 172.31.78.254
standby 10 priority 110
standby 10 preempt
!
interface Vlan49
ip address 172.31.79.15 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
Cisco IOS Release 12.1(13)E13
92
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
logging
standby
standby
standby
standby
standby
standby
event link-status
10 ip 172.31.79.1
10 priority 90
10 preempt
11 ip 172.31.79.254
11 priority 110
11 preempt
!
interface Vlan50
ip address 172.31.80.15 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 11 ip 172.31.80.1
standby 11 priority 90
standby 11 preempt
standby 12 ip 172.31.80.254
standby 12 priority 110
standby 12 preempt
!
interface Vlan122
description EQ Hosting LAN
ip address 61.172.243.2 255.255.255.128
ip access-group 122 out
no ip redirects
no ip unreachables
no ip mroute-cache
standby 20 ip 61.172.243.1
standby 20 priority 120
standby 20 preempt
standby 20 authentication ubiCN
!
interface Vlan131
description Shared Utility LAN
ip address 61.172.243.210 255.255.255.240
ip access-group 151 out
no ip redirects
no ip unreachables
no ip mroute-cache
standby 30 ip 61.172.243.209
standby 30 priority 120
standby 30 preempt
standby 30 authentication ubiCN
!
interface Vlan150
description Pagent EIGRP VLAN
ip address 172.31.150.102 255.255.255.0
no ip redirects
ip pim sparse-mode
standby ip 172.31.150.1
standby priority 110
standby preempt
!
interface Vlan200
ip address 172.31.200.1 255.255.255.252
ip pim sparse-mode
shutdown
!
router eigrp 1320
passive-interface default
no passive-interface Vlan40
no passive-interface Vlan150
Cisco IOS Release 12.1(13)E13
93
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no passive-interface FastEthernet4/1
no passive-interface FastEthernet4/5
no passive-interface Port-channel15
no passive-interface Port-channel115
network 172.31.4.0 0.0.0.255
network 172.31.60.0 0.0.1.255
network 172.31.150.0 0.0.0.255
network 172.31.0.0
auto-summary
eigrp log-neighbor-changes
!
router ospf 1
log-adjacency-changes
maximum-paths 6
!
ip classless
ip route 0.0.0.0 0.0.0.0 1.1.1.6
ip route 172.18.177.128 255.255.255.192 10.194.17.254
ip route 172.18.179.128 255.255.255.192 10.194.17.254
no ip http server
ip pim rp-address 172.31.0.102 1 override
ip pim rp-address 172.31.0.98 2 override
ip pim spt-threshold infinity
ip msdp peer 172.31.4.101 connect-source Loopback0
ip msdp cache-sa-state
ip msdp originator-id Loopback0
!
!
ip access-list extended ACLIPsec-DTC
deny
tcp any any eq sunrpc
deny
udp any any eq sunrpc
deny
tcp any any eq 2049
deny
udp any any eq 2049
deny
tcp any any range 32770 32780
permit icmp any any unreachable
permit icmp any any echo-reply
permit icmp any any time-exceeded
permit icmp any any source-quench
permit icmp any any general-parameter-problem
permit icmp any any packet-too-big
permit ip 64.12.0.0 0.0.255.255 any
permit ip 152.163.0.0 0.0.255.255 any
permit ip 205.188.0.0 0.0.255.255 any
permit ip 172.16.0.0 0.15.255.255 any
permit ip 10.0.0.0 0.7.255.255 any
permit ip 10.8.0.0 0.0.255.255 any
permit ip 10.128.0.0 0.63.255.255 any
permit ip 192.168.0.0 0.0.255.255 any
permit udp any any eq ntp
permit ip 149.174.128.0 0.0.127.255 any
permit tcp 64.236.8.208 0.0.0.15 any eq 55535
permit esp host 66.210.240.44 host 205.188.241.145
permit ahp host 66.210.240.44 host 205.188.241.145
permit udp host 66.210.240.44 host 205.188.241.145 eq isakmp
permit esp host 216.181.109.46 host 205.188.241.145
permit ahp host 216.181.109.46 host 205.188.241.145
permit udp host 216.181.109.46 host 205.188.241.145 eq isakmp
permit esp host 216.181.233.190 host 205.188.241.145
permit ahp host 216.181.233.190 host 205.188.241.145
permit udp host 216.181.233.190 host 205.188.241.145 eq isakmp
permit esp host 209.225.187.62 host 205.188.241.145
permit ahp host 209.225.187.62 host 205.188.241.145
permit udp host 209.225.187.62 host 205.188.241.145 eq isakmp
permit esp host 216.181.237.54 host 205.188.241.145
Cisco IOS Release 12.1(13)E13
94
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
udp
esp
ahp
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
host
216.181.237.54 host 205.188.241.145
216.181.237.54 host 205.188.241.145 eq isakmp
209.225.187.38 host 205.188.241.145
209.225.187.38 host 205.188.241.145
209.225.187.38 host 205.188.241.145 eq isakmp
216.181.212.78 host 205.188.241.145
216.181.212.78 host 205.188.241.145
216.181.212.78 host 205.188.241.145 eq isakmp
216.181.219.86 host 205.188.241.145
216.181.219.86 host 205.188.241.145
216.181.219.86 host 205.188.241.145 eq isakmp
216.181.108.182 host 205.188.241.145
216.181.108.182 host 205.188.241.145
216.181.108.182 host 205.188.241.145 eq isakmp
216.181.173.14 host 205.188.241.145
216.181.173.14 host 205.188.241.145
216.181.173.14 host 205.188.241.145 eq isakmp
209.225.190.86 host 205.188.241.145
209.225.190.86 host 205.188.241.145
209.225.190.86 host 205.188.241.145 eq isakmp
216.181.94.206 host 205.188.241.145
216.181.94.206 host 205.188.241.145
216.181.94.206 host 205.188.241.145 eq isakmp
216.181.15.94 host 205.188.241.145
216.181.15.94 host 205.188.241.145
216.181.15.94 host 205.188.241.145 eq isakmp
63.121.105.28 host 205.188.241.145
63.121.105.28 host 205.188.241.145
63.121.105.28 host 205.188.241.145 eq isakmp
216.181.237.142 host 205.188.241.145
216.181.237.142 host 205.188.241.145
216.181.237.142 host 205.188.241.145 eq isakmp
216.181.98.174 host 205.188.241.145
216.181.98.174 host 205.188.241.145
216.181.98.174 host 205.188.241.145 eq isakmp
66.202.67.65 host 205.188.241.145
66.202.67.65 host 205.188.241.145
66.202.67.65 host 205.188.241.145 eq isakmp
209.225.158.94 host 205.188.241.145
209.225.158.94 host 205.188.241.145
209.225.158.94 host 205.188.241.145 eq isakmp
216.181.98.230 host 205.188.241.145
216.181.98.230 host 205.188.241.145
216.181.98.230 host 205.188.241.145 eq isakmp
209.225.176.110 host 205.188.241.145
209.225.176.110 host 205.188.241.145
209.225.176.110 host 205.188.241.145 eq isakmp
209.102.96.201 host 205.188.241.145
209.102.96.201 host 205.188.241.145
209.102.96.201 host 205.188.241.145 eq isakmp
216.181.109.142 host 205.188.241.145
216.181.109.142 host 205.188.241.145
216.181.109.142 host 205.188.241.145 eq isakmp
66.147.140.132 host 205.188.241.145
66.147.140.132 host 205.188.241.145
66.147.140.132 host 205.188.241.145 eq isakmp
63.121.101.44 host 205.188.241.145
63.121.101.44 host 205.188.241.145
63.121.101.44 host 205.188.241.145 eq isakmp
63.113.105.74 host 205.188.241.145
63.113.105.74 host 205.188.241.145
63.113.105.74 host 205.188.241.145 eq isakmp
64.140.48.66 host 205.188.241.145
64.140.48.66 host 205.188.241.145
Cisco IOS Release 12.1(13)E13
95
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
permit
deny
deny
deny
deny
deny
deny
deny
udp host 64.140.48.66 host 205.188.241.145 eq isakmp
esp host 216.181.252.166 host 205.188.241.145
ahp host 216.181.252.166 host 205.188.241.145
udp host 216.181.252.166 host 205.188.241.145 eq isakmp
esp host 209.225.169.78 host 205.188.241.145
ahp host 209.225.169.78 host 205.188.241.145
udp host 209.225.169.78 host 205.188.241.145 eq isakmp
esp 172.28.23.0 0.0.0.255 96.20.20.0 0.0.0.255
esp 172.28.20.0 0.0.0.255 96.20.22.0 0.0.0.255
ahp 172.28.23.0 0.0.0.255 96.20.20.0 0.0.0.255
ahp 172.28.20.0 0.0.0.255 96.20.22.0 0.0.0.255
udp 172.28.23.0 0.0.0.255 96.20.20.0 0.0.0.255 eq isakmp
udp 172.28.20.0 0.0.0.255 96.20.22.0 0.0.0.255 eq isakmp
esp host 206.132.61.7 host 205.188.246.249
ahp host 206.132.61.7 host 205.188.246.249
udp host 206.132.61.7 host 205.188.246.249 eq isakmp
esp host 192.245.232.89 host 205.188.246.249
ahp host 192.245.232.89 host 205.188.246.249
udp host 192.245.232.89 host 205.188.246.249 eq isakmp
esp host 193.189.238.230 host 205.188.246.249
ahp host 193.189.238.230 host 205.188.246.249
udp host 193.189.238.230 host 205.188.246.249 eq isakmp
esp host 64.209.229.179 host 205.188.246.249
ahp host 64.209.229.179 host 205.188.246.249
udp host 64.209.229.179 host 205.188.246.249 eq isakmp
esp host 209.251.207.100 host 205.188.246.249
ahp host 209.251.207.100 host 205.188.246.249
udp host 209.251.207.100 host 205.188.246.249 eq isakmp
esp host 204.155.122.4 host 205.188.246.249
ahp host 204.155.122.4 host 205.188.246.249
udp host 204.155.122.4 host 205.188.246.249 eq isakmp
esp host 64.236.245.211 host 205.188.246.249
ahp host 64.236.245.211 host 205.188.246.249
udp host 64.236.245.211 host 205.188.246.249 eq isakmp
esp any host 205.188.241.145 log
ahp any host 205.188.241.145 log
udp any host 205.188.241.145 eq isakmp log
esp any host 205.188.246.249 log
ahp any host 205.188.246.249 log
udp any host 205.188.246.249 eq isakmp log
ip any any
!
logging trap debugging
logging 172.18.177.132
access-list 1 permit 239.255.0.0 0.0.255.255
access-list 1 deny
any
access-list 2 permit 224.0.1.39
access-list 2 permit 224.0.1.40
access-list 40 deny
239.1.1.40
access-list 40 permit any
access-list 44 deny
239.255.200.50
access-list 100 permit ip host 172.31.40.10 any
access-list 101 permit ip any host 172.31.41.101
access-list 102 permit ip any 172.31.41.0 0.0.0.255
access-list 122 permit icmp any any echo-reply
access-list 122 permit icmp any any echo
access-list 122 permit icmp any any unreachable
access-list 122 permit icmp any any time-exceeded
access-list 122 permit tcp any any established
access-list 122 permit udp any 61.172.243.0 0.0.0.127 gt 1023
access-list 122 permit ip 61.172.243.184 0.0.0.7 any
access-list 122 permit ip 61.172.243.208 0.0.0.15 any
access-list 122 permit ip 218.1.112.0 0.0.0.63 any
access-list 122 permit ip 10.9.0.0 0.0.255.255 any
Cisco IOS Release 12.1(13)E13
96
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
access-list 122 permit ip 64.37.152.0 0.0.3.255 any
access-list 122 permit ip 64.37.145.0 0.0.0.255 any
access-list 122 permit ip host 64.37.148.135 any
access-list 122 deny
ip any 61.172.243.0 0.0.0.127
access-list 150 permit ip any host 224.0.0.10
access-list 151 permit icmp any any echo-reply
access-list 151 permit icmp any any echo
access-list 151 permit icmp any any unreachable
access-list 151 permit icmp any any time-exceeded
access-list 151 permit udp any eq domain host 61.172.243.214 eq 5353
access-list 151 permit tcp any any established
access-list 151 permit ip 61.172.243.0 0.0.0.127 any
access-list 151 permit ip 61.172.243.184 0.0.0.7 any
access-list 151 permit ip 218.1.112.0 0.0.0.63 any
access-list 151 permit ip 10.9.0.0 0.0.255.255 any
access-list 151 permit ip 64.37.152.0 0.0.3.255 any
access-list 151 permit ip 64.37.145.0 0.0.0.255 any
access-list 151 permit ip host 64.37.148.135 any
access-list 151 deny
ip any 61.172.243.208 0.0.0.15
access-list 181 permit ip any any
snmp-server community public RO
snmp-server community cisco RW
snmp-server trap-source Loopback0
snmp-server enable traps hsrp
snmp-server enable traps config
snmp-server enable traps frame-relay
snmp-server enable traps isdn call-information
snmp-server enable traps isdn layer2
snmp-server host 172.18.112.10 cooler frame-relay isdn config snmp
!
tftp-server slot0:
tacacs-server host 172.18.112.184
tacacs-server key cisco
alias exec ospf sh run | be router ospf
alias exec eigrp sh run | be router eigrp
!
line con 0
exec-timeout 0 0
line vty 0 4
exec-timeout 0 0
password cisco
login
length 0
history size 256
transport input lat pad mop telnet rlogin udptn nasi
!
exception protocol ftp
exception dump 172.18.177.129
exception memory fragment 200000
exception memory minimum 200000
scheduler runtime netinput 300
ntp clock-period 17180054
ntp update-calendar
ntp server 172.18.177.131
ntp server 172.18.177.132 prefer
end
SH1-102#show version
Cisco Internetwork Operating System Software
IOS (tm) c6sup2_rp Software (c6sup2_rp-JSV-M), Version 12.1(nightly13e.E040229) NIGHTLY
BUILD, synced to cosmos_e V121_12_5_E1
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Mon 01-Mar-04 00:11 by
Image text-base: 0x40008BF0, data-base: 0x41A4C000
Cisco IOS Release 12.1(13)E13
97
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ROM: System Bootstrap, Version 12.1(11r)E1, RELEASE SOFTWARE (fc1)
SH1-102 uptime is 2 weeks, 2 days, 19 hours, 13 minutes
Time since SH1-102 switched to active is 4 days, 21 hours, 39 minutes
System returned to ROM by power-on (SP by power-on)
System restarted at 16:31:06 EST Mon Mar 1 2004
System image file is "sup-bootflash:c6sup22-jsv-mz.v121_13_e_throttle.040229"
cisco Catalyst 6000 (R7000) processor with 458752K/65536K bytes of memory.
Processor board ID SAD05070L5Y
R7000 CPU at 300Mhz, Implementation 39, Rev 2.1, 256KB L2, 1024KB L3 Cache
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
16 Virtual Ethernet/IEEE 802.3 interface(s)
72 FastEthernet/IEEE 802.3 interface(s)
36 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.
32768K bytes of Flash internal SIMM (Sector size 512K).
Standby is up
Standby has 458752K/65536K bytes of memory.
Configuration register is 0x2102
SH1-102#show module
Mod Ports Card Type
--- ----- -------------------------------------1
2 Catalyst 6000 supervisor 2 (Standby)
2
2 Catalyst 6000 supervisor 2 (Active)
3
16 Pure SFM-mode 16 port 1000mb GBIC
4
48 48 port 10/100 mb RJ45
5
0 Switching Fabric Module-136 (Standby)
6
0 Switching Fabric Module-136 (Active)
7
16 SFM-capable 16 port 1000mb GBIC
8
24 24 port 100FX Multi mode
Model
-----------------WS-X6K-S2U-MSFC2
WS-X6K-SUP2-2GE
WS-X6816-GBIC
WS-X6348-RJ-45
WS-X6500-SFM2
WS-X6500-SFM2
WS-X6516-GBIC
WS-X6324-100FX-MM
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.6477.53bc to 0001.6477.53bd
3.2
6.1(3)
2 0002.7ec1.104e to 0002.7ec1.104f
2.12 6.1(3)
3 0009.11f4.8f70 to 0009.11f4.8f7f
1.5
12.1(11r)E2
4 0001.9754.a660 to 0001.9754.a68f
1.1
5.4(2)
5 0001.0002.0003 to 0001.0002.0003
1.1
6.1(3)
6 0001.0002.0003 to 0001.0002.0003
1.1
6.1(3)
7 0001.63d4.2a22 to 0001.63d4.2a31
4.0
6.1(3)
8 0008.a430.05e8 to 0008.a430.05ff
3.0
5.4(2)
Mod
--1
1
2
2
3
4
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Distributed Forwarding Card
Inline Power Module
Mod
--1
2
Online Diag Status
------------------Pass
Pass
Cisco IOS Release 12.1(13)E13
98
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-DFC
WS-F6K-PWR
Serial No.
----------SAD0601007D
SAD05060MPR
SAL0707D16Z
SAD04340DY4
SAD060102Z7
SAD060102YG
SAD055204WM
SAD055106XY
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
12.1(nightly
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD0552059E
3.0
Ok
SAD055205RT
1.3
Ok
SAD050601VG
1.6
Ok
SAD05070L5Y
1.7
Ok
SAL0707D1C2
2.5
Ok
1.0
Ok
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
3 Pass
4 Pass
5 Pass
6 Pass
7 Pass
8 Pass
SH1-102#
Return to SH1-102, page 81
SH1-103
Go to Test Device Configurations, page 17
Go to Financial Lab Topology, page 2
Go to Test Cases, page 249
SH1-103#show config
Using 13447 out of 391160 bytes
!
!
version 12.1
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
no service password-encryption
service internal
!
hostname SH1-103
!
boot system flash sup-bootflash:
boot bootldr bootflash:
no logging console
enable secret 5 $1$eRg8$lPacqcMDTxV1JKJO.frYL/
!
clock timezone EST -5
clock summer-time EDT recurring
udld aggressive
udld message time 7
ip subnet-zero
!
!
ip ftp username safeharbor
ip ftp password shshsh
no ip domain-lookup
!
ip multicast-routing
ip cef load-sharing algorithm universal 00000006
mls flow ip destination-source
mls flow ipx destination
mls ip multicast consistency-check
errdisable recovery cause udld
errdisable recovery cause bpduguard
errdisable recovery cause channel-misconfig
errdisable recovery cause pagp-flap
errdisable recovery cause dtp-flap
errdisable recovery cause link-flap
errdisable recovery interval 30
!
redundancy
mode rpr-plus
Cisco IOS Release 12.1(13)E13
99
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
main-cpu
auto-sync running-config
auto-sync standard
!
power redundancy-mode combined
!
!
!
interface Loopback0
ip address 172.31.4.103 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 172.31.0.104 255.255.255.255
ip pim sparse-mode
!
interface Port-channel16
description sh1-99 po16
ip address 172.31.1.34 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel68
description sh1-107 po68
ip address 172.31.1.73 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel69
description sh1-108 po69
ip address 172.31.1.77 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel70
description sh1-109 po70
ip address 172.31.1.81 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel71
description sh1-110 po71
ip address 172.31.1.85 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel116
description sh1-100 po16
ip address 172.31.1.50 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
Cisco IOS Release 12.1(13)E13
100
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface GigabitEthernet1/1
no ip address
shutdown
!
interface GigabitEthernet1/2
no ip address
shutdown
!
interface GigabitEthernet2/1
no ip address
shutdown
!
interface GigabitEthernet2/2
no ip address
shutdown
!
interface GigabitEthernet3/1
description sh1-99 g3/3
no ip address
channel-group 16 mode on
!
interface GigabitEthernet3/2
description sh1-100 g4/4
no ip address
channel-group 116 mode on
!
interface GigabitEthernet3/3
no ip address
shutdown
!
interface GigabitEthernet3/4
no ip address
shutdown
!
interface GigabitEthernet3/5
description sh1-104 g8/7
no ip address
shutdown
!
interface GigabitEthernet3/6
no ip address
shutdown
!
interface GigabitEthernet3/7
no ip address
shutdown
!
interface GigabitEthernet3/8
no ip address
shutdown
!
interface GigabitEthernet3/9
description sh1-99 g3/11
no ip address
channel-group 16 mode on
!
interface GigabitEthernet3/10
no ip address
shutdown
!
interface GigabitEthernet3/11
no ip address
shutdown
!
Cisco IOS Release 12.1(13)E13
101
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface GigabitEthernet3/12
no ip address
shutdown
!
interface GigabitEthernet3/13
no ip address
shutdown
!
interface GigabitEthernet3/14
no ip address
shutdown
!
interface GigabitEthernet3/15
no ip address
shutdown
!
interface GigabitEthernet3/16
no ip address
shutdown
!
interface GigabitEthernet4/1
description sh1-99 g4/3
no ip address
channel-group 16 mode on
!
interface GigabitEthernet4/2
no ip address
shutdown
!
interface GigabitEthernet4/3
no ip address
shutdown
!
interface GigabitEthernet4/4
no ip address
shutdown
!
interface GigabitEthernet4/5
no ip address
shutdown
!
interface GigabitEthernet4/6
no ip address
shutdown
!
interface GigabitEthernet4/7
no ip address
shutdown
!
interface GigabitEthernet4/8
no ip address
shutdown
!
interface GigabitEthernet4/9
description sh1-99 g4/11
no ip address
channel-group 16 mode on
!
interface GigabitEthernet4/10
description sh1-100 g3/12
no ip address
channel-group 116 mode on
!
interface GigabitEthernet4/11
Cisco IOS Release 12.1(13)E13
102
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface GigabitEthernet4/12
no ip address
shutdown
!
interface GigabitEthernet4/13
no ip address
shutdown
!
interface GigabitEthernet4/14
no ip address
shutdown
!
interface GigabitEthernet4/15
no ip address
shutdown
!
interface GigabitEthernet4/16
no ip address
shutdown
!
interface GigabitEthernet7/1
no ip address
shutdown
!
interface GigabitEthernet7/2
no ip address
shutdown
!
interface GigabitEthernet7/3
no ip address
shutdown
!
interface GigabitEthernet7/4
no ip address
shutdown
!
interface GigabitEthernet7/5
no ip address
shutdown
!
interface GigabitEthernet7/6
no ip address
shutdown
!
interface GigabitEthernet7/7
description sh1-107 g3/1
no ip address
channel-group 68 mode on
!
interface GigabitEthernet7/8
description sh1-107 g3/2
no ip address
channel-group 68 mode on
!
interface GigabitEthernet7/9
description sh1-107 g3/3
no ip address
channel-group 68 mode on
!
interface GigabitEthernet7/10
description sh1-107 g3/4
Cisco IOS Release 12.1(13)E13
103
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
channel-group 68 mode on
!
interface GigabitEthernet7/11
no ip address
shutdown
!
interface GigabitEthernet7/12
no ip address
shutdown
!
interface GigabitEthernet7/13
description sh1-110 g3/1
no ip address
channel-group 71 mode desirable
!
interface GigabitEthernet7/14
description sh1-110 g4/1
no ip address
channel-group 71 mode desirable
!
interface GigabitEthernet7/15
description sh1-109 g3/1
no ip address
logging event link-status
speed nonegotiate
channel-group 70 mode on
!
interface GigabitEthernet7/16
description sh1-109 g4/1
no ip address
speed nonegotiate
channel-group 70 mode on
!
interface GigabitEthernet8/1
no ip address
shutdown
!
interface GigabitEthernet8/2
no ip address
shutdown
!
interface GigabitEthernet8/3
no ip address
shutdown
!
interface GigabitEthernet8/4
no ip address
shutdown
!
interface GigabitEthernet8/5
no ip address
shutdown
!
interface GigabitEthernet8/6
no ip address
shutdown
!
interface GigabitEthernet8/7
description sh1-108 g3/1
no ip address
channel-group 69 mode on
!
interface GigabitEthernet8/8
Cisco IOS Release 12.1(13)E13
104
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
description sh1-108 g3/2
no ip address
channel-group 69 mode on
!
interface GigabitEthernet8/9
description sh1-108 g3/3
no ip address
channel-group 69 mode on
!
interface GigabitEthernet8/10
description sh1-108 g3/4
no ip address
channel-group 69 mode on
!
interface GigabitEthernet8/11
no ip address
shutdown
!
interface GigabitEthernet8/12
no ip address
shutdown
!
interface GigabitEthernet8/13
description sh1-110 g7/1
no ip address
channel-group 71 mode desirable
!
interface GigabitEthernet8/14
description sh1-110 g8/1
no ip address
channel-group 71 mode desirable
!
interface GigabitEthernet8/15
description sh1-109 g7/1
no ip address
speed nonegotiate
channel-group 70 mode on
!
interface GigabitEthernet8/16
description sh1-109 g8/1
no ip address
speed nonegotiate
channel-group 70 mode on
!
interface FastEthernet9/1
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/2
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/3
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/4
no ip address
Cisco IOS Release 12.1(13)E13
105
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
speed 100
duplex full
!
interface FastEthernet9/5
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/6
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/7
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/8
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/9
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/10
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/11
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/12
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/13
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/14
no ip address
shutdown
speed 100
duplex full
!
Cisco IOS Release 12.1(13)E13
106
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface FastEthernet9/15
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/16
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/17
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/18
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/19
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/20
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/21
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/22
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/23
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/24
description flashnet
ip address 10.194.17.103 255.255.255.0
speed 100
duplex full
!
interface FastEthernet9/25
no ip address
shutdown
speed 100
Cisco IOS Release 12.1(13)E13
107
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
duplex full
!
interface FastEthernet9/26
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/27
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/28
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/29
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/30
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/31
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/32
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/33
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/34
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/35
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/36
no ip address
Cisco IOS Release 12.1(13)E13
108
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
speed 100
duplex full
!
interface FastEthernet9/37
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/38
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/39
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/40
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/41
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/42
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/43
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/44
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/45
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/46
no ip address
shutdown
speed 100
duplex full
!
Cisco IOS Release 12.1(13)E13
109
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface FastEthernet9/47
no ip address
shutdown
speed 100
duplex full
!
interface FastEthernet9/48
no ip address
shutdown
speed 100
!
interface Vlan1
no ip address
shutdown
!
router ospf 1
log-adjacency-changes
auto-cost reference-bandwidth 100000
passive-interface default
no passive-interface Port-channel16
no passive-interface Port-channel68
no passive-interface Port-channel69
no passive-interface Port-channel70
no passive-interface Port-channel71
no passive-interface Port-channel116
network 172.31.0.0 0.0.0.255 area 1
network 172.31.1.32 0.0.0.3 area 1
network 172.31.1.48 0.0.0.3 area 1
network 172.31.1.64 0.0.0.15 area 1
network 172.31.1.80 0.0.0.7 area 1
network 172.31.1.120 0.0.0.3 area 1
network 172.31.2.32 0.0.0.3 area 1
network 172.31.4.0 0.0.0.255 area 1
maximum-paths 6
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.31.4.99
ip route 172.18.177.128 255.255.255.192 10.194.17.254
ip route 172.18.179.128 255.255.255.192 10.194.17.254
no ip http server
ip pim rp-address 172.31.0.104 1 override
ip pim rp-address 172.31.0.98 2 override
ip pim spt-threshold infinity
ip msdp peer 172.31.4.104 connect-source Loopback0
ip msdp cache-sa-state
ip msdp originator-id Loopback0
!
!
logging trap debugging
logging 172.18.177.132
access-list 1 permit 239.255.0.0 0.0.255.255
access-list 1 deny
any
access-list 2 permit 224.0.1.39
access-list 2 permit 224.0.1.40
access-list 15 permit 239.255.127.0 0.0.0.255
access-list 181 permit ip any any
snmp-server community public RO
snmp-server community cisco RW
!
rmon event 1 log trap public description "Rising EventIndex for avgBusy1~%~" owner admin
rmon event 2 log trap public description "Falling EventIndex for avgBusy1" owner admin
rmon alarm 1 lsystem.57.0 60 absolute rising-threshold 90 1 falling-threshold 70 2 owner
admin
alias exec ip sh ip int brief | be Port
Cisco IOS Release 12.1(13)E13
110
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
alias exec eigrp show run | be router eigrp
alias exec mr sh ip mroute 239.255.127.100
alias exec ospf sh run | be router ospf
!
line con 0
exec-timeout 0 0
line vty 0 4
exec-timeout 0 0
timeout login response 0
password cisco
login
history size 256
transport input lat pad mop telnet rlogin udptn nasi
!
exception protocol ftp
exception dump 172.18.177.129
exception memory fragment 200000
exception memory minimum 200000
scheduler runtime netinput 300
ntp clock-period 17179912
ntp update-calendar
ntp server 172.18.177.131
ntp server 172.18.177.132 prefer
end
SH1-103#show version
Cisco Internetwork Operating System Software
IOS (tm) c6sup2_rp Software (c6sup2_rp-JSV-M), Version 12.1(nightly13e.E040229) NIGHTLY
BUILD, synced to cosmos_e V121_12_5_E1
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Mon 01-Mar-04 00:11 by
Image text-base: 0x40008BF0, data-base: 0x41A4C000
ROM: System Bootstrap, Version 12.1(4r)E, RELEASE SOFTWARE (fc1)
SH1-103 uptime is 2 weeks, 2 days, 19 hours, 12 minutes
Time since SH1-103 switched to active is 2 weeks, 2 days, 19 hours, 11 minutes
System returned to ROM by power-on (SP by power-on)
System restarted at 16:32:18 EST Mon Mar 1 2004
System image file is "sup-bootflash:c6sup22-jsv-mz.v121_13_e_throttle.040229"
cisco Catalyst 6000 (R7000) processor with 458752K/65536K bytes of memory.
Processor board ID SAD055205T9
R7000 CPU at 300Mhz, Implementation 39, Rev 2.1, 256KB L2, 1024KB L3 Cache
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
1 Virtual Ethernet/IEEE 802.3 interface(s)
48 FastEthernet/IEEE 802.3 interface(s)
68 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.
16384K bytes of Flash internal SIMM (Sector size 512K).
Standby is up
Standby has 458752K/65536K bytes of memory.
Configuration register is 0x2102
SH1-103#show module
Mod Ports Card Type
Model
Serial No.
--- ----- -------------------------------------- ------------------ ----------1
2 Catalyst 6000 supervisor 2 (Active)
WS-X6K-S2U-MSFC2
SAD060100BX
Cisco IOS Release 12.1(13)E13
111
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
2
3
4
5
6
7
8
9
2
16
16
0
0
16
16
48
Catalyst 6000 supervisor 2 (Standby)
Pure SFM-mode 16 port 1000mb GBIC
Pure SFM-mode 16 port 1000mb GBIC
Switching Fabric Module-136 (Standby)
Switching Fabric Module-136 (Active)
SFM-capable 16 port 1000mb GBIC
SFM-capable 16 port 1000mb GBIC
SFM-capable 48-port 10/100 Mbps RJ45
WS-X6K-S2U-MSFC2
WS-X6816-GBIC
WS-X6816-GBIC
WS-X6500-SFM2
WS-X6500-SFM2
WS-X6516-GBIC
WS-X6516-GBIC
WS-X6548-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.6415.b422 to 0001.6415.b423
3.2
6.1(3)
2 0001.c9da.e1dc to 0001.c9da.e1dd
3.2
6.1(3)
3 0001.63d3.b7aa to 0001.63d3.b7b9
1.2
12.1(5r)E1
4 0001.63d4.4ca2 to 0001.63d4.4cb1
1.2
12.1(5r)E1
5 0001.0002.0003 to 0001.0002.0003
1.1
6.1(3)
6 0001.0002.0003 to 0001.0002.0003
1.1
6.1(3)
7 0001.63d4.2a62 to 0001.63d4.2a71
4.0
6.1(3)
8 0001.63d4.3e42 to 0001.63d4.3e51
4.0
6.1(3)
9 0002.7ee3.7d84 to 0002.7ee3.7db3
4.3
6.3(1)
Mod
--1
1
2
2
3
4
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Distributed Forwarding Card
Distributed Forwarding Card
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-DFC
WS-F6K-DFC
Return to SH1-103, page 99
SH1-104
Go to Test Device Configurations, page 17
Go to Financial Lab Topology, page 2
Go to Test Cases, page 249
SH1-104#show config
Using 11713 out of 391160 bytes
!
!
version 12.1
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
no service password-encryption
service internal
!
Cisco IOS Release 12.1(13)E13
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
12.1(nightly
12.1(nightly
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD05520529
3.0
Ok
SAD055205T9
1.3
Ok
SAD0552053W
3.0
Ok
SAL06090LMV
2.4
Ok
SAD055102U3
2.0
Ok
SAD060100EV
2.0
Ok
Mod Online Diag Status
--- ------------------1 Pass
2 Pass
3 Pass
4 Pass
5 Pass
6 Pass
7 Pass
8 Pass
9 Pass
SH1-103#
112
SAD0601004E
SAD055101PD
SAD055101NL
SAD055204C8
SAD060102UV
SAD055204MG
SAD055204NZ
SAD061900DR
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
hostname SH1-104
!
boot system flash sup-bootflash:
boot bootldr bootflash:
no logging console
enable secret 5 $1$eAFZ$WrY7KELPyBFWCGR/ZDAKk0
!
clock timezone EST -5
clock summer-time EDT recurring
udld enable
udld message time 7
ip subnet-zero
!
!
ip ftp username safeharbor
ip ftp password shshsh
no ip domain-lookup
!
ip multicast-routing
mls flow ip destination-source
mls flow ipx destination
mls ip multicast consistency-check
errdisable recovery interval 30
!
redundancy
mode rpr-plus
main-cpu
auto-sync running-config
auto-sync standard
!
power redundancy-mode combined
!
!
!
interface Loopback0
ip address 172.31.4.104 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 172.31.0.104 255.255.255.255
ip pim sparse-mode
!
interface Port-channel17
description sh1-99 po17
ip address 172.31.1.38 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel68
description sh1-107 po168
ip address 172.31.1.101 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel69
description sh1-108 po169
ip address 172.31.1.105 255.255.255.252
ip access-group 181 in
Cisco IOS Release 12.1(13)E13
113
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip access-group 181 out
ip pim sparse-mode
logging event link-status
logging event bundle-status
!
interface Port-channel70
description sh1-109 po170
ip address 172.31.1.109 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel71
description sh1-110 po171
ip address 172.31.1.113 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel117
description sh1-100 po17
ip address 172.31.1.54 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface GigabitEthernet1/1
no ip address
shutdown
!
interface GigabitEthernet1/2
no ip address
shutdown
!
interface GigabitEthernet2/1
no ip address
shutdown
!
interface GigabitEthernet2/2
no ip address
shutdown
!
interface GigabitEthernet3/1
description sh1-100 g3/3
no ip address
channel-group 117 mode on
!
interface GigabitEthernet3/2
no ip address
shutdown
!
interface GigabitEthernet3/3
no ip address
shutdown
!
interface GigabitEthernet3/4
no ip address
shutdown
!
interface GigabitEthernet3/5
no ip address
Cisco IOS Release 12.1(13)E13
114
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface GigabitEthernet3/6
no ip address
shutdown
!
interface GigabitEthernet3/7
no ip address
shutdown
!
interface GigabitEthernet3/8
no ip address
shutdown
!
interface GigabitEthernet3/9
description sh1-100 g3/11
no ip address
channel-group 117 mode on
!
interface GigabitEthernet3/10
description sh1-99 g3/12
no ip address
channel-group 17 mode auto
!
interface GigabitEthernet3/11
no ip address
shutdown
!
interface GigabitEthernet3/12
no ip address
shutdown
!
interface GigabitEthernet3/13
description sh1-110 g3/3
no ip address
channel-group 71 mode on
!
interface GigabitEthernet3/14
description sh1-110 g3/4
no ip address
channel-group 71 mode on
!
interface GigabitEthernet3/15
no ip address
shutdown
!
interface GigabitEthernet3/16
no ip address
shutdown
!
interface GigabitEthernet4/1
description sh1-100 g4/3
no ip address
channel-group 117 mode on
!
interface GigabitEthernet4/2
description sh1-99 g4/4
no ip address
channel-group 17 mode auto
!
interface GigabitEthernet4/3
no ip address
shutdown
!
Cisco IOS Release 12.1(13)E13
115
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface GigabitEthernet4/4
no ip address
shutdown
!
interface GigabitEthernet4/5
no ip address
shutdown
!
interface GigabitEthernet4/6
no ip address
shutdown
!
interface GigabitEthernet4/7
no ip address
shutdown
!
interface GigabitEthernet4/8
no ip address
shutdown
!
interface GigabitEthernet4/9
description sh1-100 g4/11
no ip address
channel-group 117 mode on
!
interface GigabitEthernet4/10
no ip address
shutdown
!
interface GigabitEthernet4/11
no ip address
shutdown
!
interface GigabitEthernet4/12
no ip address
shutdown
!
interface GigabitEthernet4/13
no ip address
shutdown
!
interface GigabitEthernet4/14
no ip address
shutdown
!
interface GigabitEthernet4/15
description sh1-109 g3/5
no ip address
speed nonegotiate
udld port aggressive
channel-group 70 mode on
!
interface GigabitEthernet4/16
description sh1-109 g3/6
no ip address
speed nonegotiate
channel-group 70 mode on
!
interface GigabitEthernet7/1
no ip address
shutdown
!
interface GigabitEthernet7/2
no ip address
Cisco IOS Release 12.1(13)E13
116
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface GigabitEthernet7/3
no ip address
shutdown
!
interface GigabitEthernet7/4
no ip address
shutdown
!
interface GigabitEthernet7/5
no ip address
shutdown
!
interface GigabitEthernet7/6
no ip address
shutdown
!
interface GigabitEthernet7/7
description sh1-107 g3/5
no ip address
channel-group 68 mode desirable
!
interface GigabitEthernet7/8
description sh1-107 g3/6
no ip address
channel-group 68 mode desirable
!
interface GigabitEthernet7/9
description sh1-107 g4/5
no ip address
channel-group 68 mode desirable
!
interface GigabitEthernet7/10
description sh1-107 g4/6
no ip address
channel-group 68 mode desirable
!
interface GigabitEthernet7/11
no ip address
shutdown
!
interface GigabitEthernet7/12
no ip address
shutdown
!
interface GigabitEthernet7/13
no ip address
shutdown
!
interface GigabitEthernet7/14
no ip address
shutdown
!
interface GigabitEthernet7/15
no ip address
shutdown
!
interface GigabitEthernet7/16
no ip address
shutdown
!
interface GigabitEthernet8/1
no ip address
Cisco IOS Release 12.1(13)E13
117
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface GigabitEthernet8/2
no ip address
shutdown
!
interface GigabitEthernet8/3
no ip address
shutdown
!
interface GigabitEthernet8/4
no ip address
shutdown
!
interface GigabitEthernet8/5
no ip address
shutdown
!
interface GigabitEthernet8/6
no ip address
shutdown
!
interface GigabitEthernet8/7
description sh1-108 g3/5
no ip address
logging event link-status
logging event bundle-status
channel-group 69 mode on
!
interface GigabitEthernet8/8
description sh1-108 g3/6
no ip address
logging event link-status
logging event bundle-status
channel-group 69 mode on
!
interface GigabitEthernet8/9
description sh1-108 g4/5
no ip address
logging event link-status
logging event bundle-status
channel-group 69 mode on
!
interface GigabitEthernet8/10
description sh1-108 g4/6
no ip address
logging event link-status
logging event bundle-status
channel-group 69 mode on
!
interface GigabitEthernet8/11
no ip address
shutdown
!
interface GigabitEthernet8/12
no ip address
shutdown
!
interface GigabitEthernet8/13
description sh1-110 g4/3
no ip address
channel-group 71 mode on
!
interface GigabitEthernet8/14
Cisco IOS Release 12.1(13)E13
118
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
description sh1-110 g4/4
no ip address
channel-group 71 mode on
!
interface GigabitEthernet8/15
description sh1-109 g4/5
no ip address
speed nonegotiate
channel-group 70 mode on
!
interface GigabitEthernet8/16
description sh1-109 g4/6
no ip address
speed nonegotiate
channel-group 70 mode on
!
interface FastEthernet9/1
no ip address
shutdown
!
interface FastEthernet9/2
no ip address
shutdown
!
interface FastEthernet9/3
no ip address
shutdown
!
interface FastEthernet9/4
no ip address
shutdown
!
interface FastEthernet9/5
no ip address
shutdown
!
interface FastEthernet9/6
no ip address
shutdown
!
interface FastEthernet9/7
no ip address
shutdown
!
interface FastEthernet9/8
no ip address
shutdown
!
interface FastEthernet9/9
no ip address
shutdown
!
interface FastEthernet9/10
no ip address
shutdown
!
interface FastEthernet9/11
no ip address
shutdown
!
interface FastEthernet9/12
no ip address
shutdown
!
Cisco IOS Release 12.1(13)E13
119
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface FastEthernet9/13
no ip address
shutdown
!
interface FastEthernet9/14
no ip address
shutdown
!
interface FastEthernet9/15
no ip address
shutdown
!
interface FastEthernet9/16
no ip address
shutdown
!
interface FastEthernet9/17
no ip address
shutdown
!
interface FastEthernet9/18
no ip address
shutdown
!
interface FastEthernet9/19
no ip address
shutdown
!
interface FastEthernet9/20
no ip address
shutdown
!
interface FastEthernet9/21
no ip address
shutdown
!
interface FastEthernet9/22
no ip address
shutdown
!
interface FastEthernet9/23
no ip address
shutdown
!
interface FastEthernet9/24
description flashnet
ip address 10.194.17.104 255.255.255.0
duplex full
!
interface Vlan1
no ip address
shutdown
!
interface Vlan11
no ip address
shutdown
!
router ospf 1
log-adjacency-changes
auto-cost reference-bandwidth 100000
passive-interface default
no passive-interface Port-channel17
no passive-interface Port-channel68
no passive-interface Port-channel69
Cisco IOS Release 12.1(13)E13
120
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no passive-interface Port-channel70
no passive-interface Port-channel71
no passive-interface Port-channel117
network 172.31.0.0 0.0.0.255 area 1
network 172.31.1.36 0.0.0.3 area 1
network 172.31.1.52 0.0.0.3 area 1
network 172.31.1.92 0.0.0.3 area 1
network 172.31.1.96 0.0.0.15 area 1
network 172.31.1.112 0.0.0.3 area 1
network 172.31.2.36 0.0.0.3 area 1
network 172.31.4.0 0.0.0.255 area 1
maximum-paths 6
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.31.4.99
ip route 130.1.1.1 255.255.255.255 Port-channel17
ip route 172.18.177.128 255.255.255.192 10.194.17.254
ip route 172.18.179.128 255.255.255.192 10.194.17.254
no ip http server
ip pim rp-address 172.31.0.104 1 override
ip pim rp-address 172.31.0.98 2 override
ip pim spt-threshold infinity
ip msdp peer 172.31.4.103 connect-source Loopback0
ip msdp cache-sa-state
ip msdp originator-id Loopback0
!
!
logging trap debugging
logging 172.18.177.132
access-list 1 permit 239.255.0.0 0.0.255.255
access-list 1 deny
any
access-list 2 permit 224.0.1.39
access-list 2 permit 224.0.1.40
access-list 10 deny
172.31.1.102
access-list 20 deny
172.31.1.110
access-list 55 permit 172.31.1.106
access-list 55 deny
any
access-list 102 permit ip host 172.31.30.132 host 239.100.3.1
access-list 130 permit ip host 172.31.21.101 host 239.255.127.100
access-list 130 permit ip host 172.31.21.101 host 239.255.127.101
access-list 131 permit ip any host 172.31.1.114
access-list 150 permit icmp host 172.18.177.132 host 10.194.17.104 log
access-list 181 permit ip any any
snmp-server engineID local 543210000000000000000000
snmp-server engineID remote 172.31.1.106 udp-port 161 123450000000000000000000
snmp-server engineID remote 172.31.1.106 123450000000000000000000
snmp-server community public RO
snmp-server community cisco RW
snmp-server enable traps config
snmp-server host 172.31.1.106 cisco
snmp-server host 172.18.177.135 public
snmp-server host 172.31.1.106 public
!
tftp-server slot0:
tftp-server slot0:slot0:sh1-99.091802.cfg
tacacs-server host 161.44.11.123
alias exec ip sh ip int brief | be Port
alias exec eigrp show run | be router eigrp
alias exec ospf sh run | be router ospf
!
line con 0
exec-timeout 0 0
line vty 0 4
exec-timeout 0 0
Cisco IOS Release 12.1(13)E13
121
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
password cisco
login
history size 256
transport input lat pad mop telnet rlogin udptn nasi
line vty 5 10
exec-timeout 0 0
password cisco
login
history size 256
transport input lat pad mop telnet rlogin udptn nasi
!
exception protocol ftp
exception dump 172.18.177.129
exception memory fragment 200000
exception memory minimum 200000
scheduler runtime netinput 300
ntp clock-period 17179877
ntp update-calendar
ntp server 172.18.177.131
ntp server 172.18.177.132 prefer
end
SH1-104#show version
Cisco Internetwork Operating System Software
IOS (tm) c6sup2_rp Software (c6sup2_rp-JSV-M), Version 12.1(nightly13e.E040229) NIGHTLY
BUILD, synced to cosmos_e V121_12_5_E1
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Mon 01-Mar-04 00:11 by
Image text-base: 0x40008BF0, data-base: 0x41A4C000
ROM: System Bootstrap, Version 12.1(4r)E, RELEASE SOFTWARE (fc1)
SH1-104 uptime is 2 days, 16 hours, 55 minutes
Time since SH1-104 switched to active is 1 day, 17 hours, 10 minutes
System returned to ROM by power-on (SP by power-on)
System restarted at 18:49:10 EST Mon Mar 15 2004
System image file is "sup-bootflash:c6sup22-jsv-mz.v121_13_e_throttle.040229"
cisco Catalyst 6000 (R7000) processor with 458752K/65536K bytes of memory.
Processor board ID SAD055205MJ
R7000 CPU at 300Mhz, Implementation 39, Rev 2.1, 256KB L2, 1024KB L3 Cache
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
2 Virtual Ethernet/IEEE 802.3 interface(s)
24 FastEthernet/IEEE 802.3 interface(s)
68 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.
16384K bytes of Flash internal SIMM (Sector size 512K).
Standby is up
Standby has 458752K/65536K bytes of memory.
Configuration register is 0x2102
SH1-104#show module
Mod Ports Card Type
--- ----- -------------------------------------1
2 Catalyst 6000 supervisor 2 (Standby)
2
2 Catalyst 6000 supervisor 2 (Active)
3
16 Pure SFM-mode 16 port 1000mb GBIC
4
16 SFM-capable 16 port 1000mb GBIC
Cisco IOS Release 12.1(13)E13
122
Model
-----------------WS-X6K-S2U-MSFC2
WS-X6K-S2U-MSFC2
WS-X6816-GBIC
WS-X6516-GBIC
Serial No.
----------SAD0601008Z
SAD060100DD
SAD055101KK
SAD055204TJ
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
5
6
7
8
9
0
0
16
16
24
Switching Fabric Module-136 (Standby)
Switching Fabric Module-136 (Active)
SFM-capable 16 port 1000mb GBIC
SFM-capable 16 port 1000mb GBIC
24 port 100FX Multi mode
WS-X6500-SFM2
WS-X6500-SFM2
WS-X6516-GBIC
WS-X6516-GBIC
WS-X6324-100FX-MM
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0002.7e38.70c0 to 0002.7e38.70c1
3.2
6.1(3)
2 0001.c9da.e1bc to 0001.c9da.e1bd
3.2
6.1(3)
3 0001.63d3.b74a to 0001.63d3.b759
1.2
12.1(5r)E1
4 0002.7ee1.4b30 to 0002.7ee1.4b3f
4.0
6.1(3)
5 0001.0002.0003 to 0001.0002.0003
1.1
6.1(3)
6 0001.0002.0003 to 0001.0002.0003
1.1
6.1(3)
7 0001.63d4.2ad2 to 0001.63d4.2ae1
4.0
6.1(3)
8 0002.7ee1.4ef0 to 0002.7ee1.4eff
4.0
6.1(3)
9 0003.3287.6852 to 0003.3287.6869
3.0
5.4(2)
Mod
--1
1
2
2
3
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Distributed Forwarding Card
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-DFC
SAD0601031V
SAD0552046C
SAD055204PB
SAD055204XJ
SAD055106Y3
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
12.1(nightly
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD0552050T
3.0
Ok
SAD055206A3
1.3
Ok
SAD0552053D
3.0
Ok
SAD055205MJ
1.3
Ok
SAD055102NP
2.0
Ok
Mod Online Diag Status
--- ------------------1 Pass
2 Pass
3 Pass
4 Pass
5 Pass
6 Pass
7 Pass
8 Pass
9 Pass
SH1-104#
Return to SH1-104, page 112
SH1-105
Go to Test Device Configurations, page 17
Go to Financial Lab Topology, page 2
Go to Test Cases, page 249
SH1-105#show config
Using 14265 out of 391160 bytes
!
!
version 12.1
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
no service password-encryption
service internal
!
hostname SH1-105
!
boot system flash slot0:
boot bootldr bootflash:
Cisco IOS Release 12.1(13)E13
123
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
enable secret 5 $1$/tZu$AaxbpAkQCPoGHrLVZ9L9..
!
clock timezone EST -5
clock summer-time EDT recurring
ip subnet-zero
!
!
ip ftp username safeharbor
ip ftp password shshsh
no ip domain-lookup
!
ip multicast-routing
mls ip multicast non-rpf netflow
mls flow ip destination-source
mls flow ipx destination
!
redundancy
mode rpr-plus
main-cpu
auto-sync running-config
auto-sync bootvar
auto-sync standard
!
power redundancy-mode combined
!
!
!
interface Loopback0
ip address 172.31.4.105 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 172.31.0.106 255.255.255.255
ip pim sparse-mode
!
interface Port-channel20
description dista-2 PoCha
no ip address
switchport
switchport trunk encapsulation dot1q
!
interface Port-channel66
description sh1-99 po66
ip address 172.31.1.66 255.255.255.252
ip access-group 181 in
ip access-group 181 out
no ip unreachables
ip pim sparse-mode
logging event link-status
!
interface Port-channel166
description sh1-100 po66
ip address 172.31.1.94 255.255.255.252
ip access-group 181 in
ip access-group 181 out
no ip unreachables
ip pim sparse-mode
logging event link-status
!
interface GigabitEthernet1/1
no ip address
shutdown
!
interface GigabitEthernet1/2
Cisco IOS Release 12.1(13)E13
124
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface GigabitEthernet2/1
no ip address
shutdown
!
interface GigabitEthernet2/2
no ip address
!
interface GigabitEthernet3/1
description sh1-99 g9/1
no ip address
no ip unreachables
channel-group 66 mode on
!
interface GigabitEthernet3/2
description Ix-1/1
ip address 172.31.205.105 255.255.255.0 secondary
ip address 172.31.1.57 255.255.255.252
ip access-group 181 in
ip access-group 181 out
no ip unreachables
ip pim sparse-mode
!
interface GigabitEthernet3/3
no ip address
shutdown
!
interface GigabitEthernet3/4
no ip address
shutdown
!
interface GigabitEthernet3/5
no ip address
shutdown
!
interface GigabitEthernet3/6
no ip address
shutdown
!
interface GigabitEthernet3/7
description dista-2 4/4
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 20 mode on
!
interface GigabitEthernet3/8
description dista-2 4/6
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 20 mode on
!
interface GigabitEthernet4/1
description sh1-99 g9/2
no ip address
no ip unreachables
channel-group 66 mode on
!
interface GigabitEthernet4/2
no ip address
shutdown
Cisco IOS Release 12.1(13)E13
125
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface GigabitEthernet4/3
no ip address
shutdown
!
interface GigabitEthernet4/4
no ip address
shutdown
!
interface GigabitEthernet4/5
no ip address
shutdown
!
interface GigabitEthernet4/6
no ip address
shutdown
!
interface GigabitEthernet4/7
no ip address
shutdown
!
interface GigabitEthernet4/8
no ip address
shutdown
!
interface GigabitEthernet5/1
description sh1-100 9/1
no ip address
no ip unreachables
channel-group 166 mode on
!
interface GigabitEthernet5/2
no ip address
shutdown
!
interface GigabitEthernet5/3
no ip address
shutdown
!
interface GigabitEthernet5/4
no ip address
shutdown
!
interface GigabitEthernet5/5
no ip address
shutdown
!
interface GigabitEthernet5/6
no ip address
shutdown
!
interface GigabitEthernet5/7
no ip address
shutdown
!
interface GigabitEthernet5/8
no ip address
shutdown
!
interface GigabitEthernet6/1
description sh1-100 9/2
no ip address
no ip unreachables
channel-group 166 mode on
Cisco IOS Release 12.1(13)E13
126
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface GigabitEthernet6/2
no ip address
shutdown
!
interface GigabitEthernet6/3
no ip address
shutdown
!
interface GigabitEthernet6/4
no ip address
shutdown
!
interface GigabitEthernet6/5
no ip address
shutdown
!
interface GigabitEthernet6/6
no ip address
shutdown
!
interface GigabitEthernet6/7
no ip address
shutdown
!
interface GigabitEthernet6/8
no ip address
shutdown
!
interface FastEthernet7/1
description flashnet
ip address 10.194.17.105 255.255.255.0
shutdown
duplex full
!
interface FastEthernet7/2
no ip address
shutdown
!
interface FastEthernet7/3
no ip address
shutdown
!
interface FastEthernet7/4
no ip address
shutdown
!
interface FastEthernet7/5
no ip address
shutdown
!
interface FastEthernet7/6
no ip address
shutdown
!
interface FastEthernet7/7
no ip address
shutdown
!
interface FastEthernet7/8
no ip address
shutdown
!
interface FastEthernet7/9
Cisco IOS Release 12.1(13)E13
127
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet7/10
no ip address
shutdown
!
interface FastEthernet7/11
no ip address
shutdown
!
interface FastEthernet7/12
no ip address
shutdown
!
interface FastEthernet7/13
no ip address
shutdown
!
interface FastEthernet7/14
no ip address
shutdown
!
interface FastEthernet7/15
no ip address
shutdown
!
interface FastEthernet7/16
no ip address
shutdown
!
interface FastEthernet7/17
no ip address
shutdown
!
interface FastEthernet7/18
no ip address
shutdown
!
interface FastEthernet7/19
no ip address
shutdown
!
interface FastEthernet7/20
no ip address
shutdown
!
interface FastEthernet7/21
no ip address
shutdown
!
interface FastEthernet7/22
no ip address
shutdown
!
interface FastEthernet7/23
no ip address
shutdown
!
interface FastEthernet7/24
no ip address
shutdown
!
interface FastEthernet9/1
Cisco IOS Release 12.1(13)E13
128
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
description IXIA 13/4
no ip address
switchport
switchport access vlan 201
switchport mode access
!
interface FastEthernet9/2
no ip address
shutdown
!
interface FastEthernet9/3
no ip address
shutdown
!
interface FastEthernet9/4
no ip address
shutdown
!
interface FastEthernet9/5
no ip address
shutdown
!
interface FastEthernet9/6
no ip address
shutdown
!
interface FastEthernet9/7
no ip address
shutdown
!
interface FastEthernet9/8
no ip address
shutdown
!
interface FastEthernet9/9
no ip address
shutdown
!
interface FastEthernet9/10
no ip address
shutdown
!
interface FastEthernet9/11
no ip address
shutdown
!
interface FastEthernet9/12
no ip address
shutdown
!
interface FastEthernet9/13
description Ixia 3/1 - ACL testing
ip address 1.1.1.1 255.255.255.252
!
interface FastEthernet9/14
description Ixia 3/2 - ACL testing
ip address 1.1.1.5 255.255.255.252
shutdown
!
interface FastEthernet9/15
no ip address
shutdown
!
interface FastEthernet9/16
Cisco IOS Release 12.1(13)E13
129
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet9/17
no ip address
shutdown
!
interface FastEthernet9/18
no ip address
shutdown
!
interface FastEthernet9/19
no ip address
shutdown
!
interface FastEthernet9/20
no ip address
shutdown
!
interface FastEthernet9/21
no ip address
shutdown
!
interface FastEthernet9/22
no ip address
shutdown
!
interface FastEthernet9/23
no ip address
shutdown
!
interface FastEthernet9/24
ip address 10.194.17.105 255.255.255.0
speed 100
duplex full
!
interface FastEthernet9/25
no ip address
shutdown
!
interface FastEthernet9/26
no ip address
shutdown
!
interface FastEthernet9/27
no ip address
shutdown
!
interface FastEthernet9/28
no ip address
shutdown
!
interface FastEthernet9/29
no ip address
shutdown
!
interface FastEthernet9/30
no ip address
shutdown
!
interface FastEthernet9/31
no ip address
shutdown
!
Cisco IOS Release 12.1(13)E13
130
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface FastEthernet9/32
no ip address
shutdown
!
interface FastEthernet9/33
no ip address
shutdown
!
interface FastEthernet9/34
no ip address
shutdown
!
interface FastEthernet9/35
no ip address
shutdown
!
interface FastEthernet9/36
no ip address
shutdown
!
interface FastEthernet9/37
no ip address
shutdown
!
interface FastEthernet9/38
no ip address
shutdown
!
interface FastEthernet9/39
no ip address
shutdown
!
interface FastEthernet9/40
no ip address
shutdown
!
interface FastEthernet9/41
no ip address
shutdown
!
interface FastEthernet9/42
no ip address
shutdown
!
interface FastEthernet9/43
no ip address
shutdown
!
interface FastEthernet9/44
no ip address
shutdown
!
interface FastEthernet9/45
no ip address
shutdown
!
interface FastEthernet9/46
no ip address
shutdown
!
interface FastEthernet9/47
no ip address
shutdown
!
Cisco IOS Release 12.1(13)E13
131
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface FastEthernet9/48
no ip address
!
interface Vlan1
no ip address
shutdown
!
interface Vlan40
ip address 172.31.100.66 255.255.255.0
ip helper-address 172.31.4.98
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 1 ip 172.31.100.1
standby 1 priority 110
standby 1 preempt
standby 2 ip 172.31.100.254
standby 2 priority 90
standby 2 preempt
!
interface Vlan41
ip address 172.31.101.66 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 2 ip 172.31.101.1
standby 2 priority 110
standby 2 preempt
standby 3 ip 172.31.101.254
standby 3 priority 90
standby 3 preempt
!
interface Vlan42
ip address 172.31.102.66 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 3 ip 172.31.102.1
standby 3 priority 110
standby 3 preempt
standby 4 ip 172.31.102.254
standby 4 priority 90
standby 4 preempt
!
interface Vlan43
ip address 172.31.103.66 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 4 ip 172.31.103.1
standby 4 priority 110
standby 4 preempt
standby 5 ip 172.31.103.254
standby 5 priority 90
standby 5 preempt
!
Cisco IOS Release 12.1(13)E13
132
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface Vlan44
ip address 172.31.104.66 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 5 ip 172.31.104.1
standby 5 priority 110
standby 5 preempt
standby 6 ip 172.31.104.254
standby 6 priority 90
standby 6 preempt
!
interface Vlan45
ip address 172.31.105.66 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 6 ip 172.31.105.1
standby 6 priority 110
standby 6 preempt
standby 7 ip 172.31.105.254
standby 7 priority 90
standby 7 preempt
!
interface Vlan46
ip address 172.31.106.66 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 7 ip 172.31.106.1
standby 7 priority 110
standby 7 preempt
standby 8 ip 172.31.106.254
standby 8 priority 90
standby 8 preempt
!
interface Vlan47
ip address 172.31.107.66 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 8 ip 172.31.107.1
standby 8 priority 110
standby 8 preempt
standby 9 ip 172.31.107.254
standby 9 priority 90
standby 9 preempt
!
interface Vlan48
ip address 172.31.108.66 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 9 ip 172.31.108.1
Cisco IOS Release 12.1(13)E13
133
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
standby
standby
standby
standby
standby
9 priority 110
9 preempt
10 ip 172.31.108.254
10 priority 90
10 preempt
!
interface Vlan49
ip address 172.31.109.66 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 10 ip 172.31.109.1
standby 10 priority 110
standby 10 preempt
standby 11 ip 172.31.109.254
standby 11 priority 90
standby 11 preempt
!
interface Vlan50
ip address 172.31.110.66 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 11 ip 172.31.110.1
standby 11 priority 110
standby 11 preempt
standby 12 ip 172.31.110.254
standby 12 priority 90
standby 12 preempt
!
interface Vlan170
ip address 172.31.170.105 255.255.255.0
no ip redirects
standby ip 172.31.170.1
standby priority 90
!
interface Vlan201
ip address 172.31.200.21 255.255.255.252
ip access-group 181 in
ip access-group 181 out
no ip unreachables
ip pim sparse-mode
!
interface Vlan600
no ip address
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
!
router ospf 1
log-adjacency-changes
auto-cost reference-bandwidth 100000
passive-interface default
no passive-interface Vlan40
no passive-interface Vlan170
no passive-interface GigabitEthernet3/2
no passive-interface Port-channel66
no passive-interface Port-channel166
network 172.31.1.56 0.0.0.3 area 2
network 172.31.1.64 0.0.0.3 area 2
Cisco IOS Release 12.1(13)E13
134
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
network 172.31.1.92 0.0.0.3 area 2
network 172.31.4.0 0.0.0.255 area 2
network 172.31.60.0 0.0.0.255 area 2
network 172.31.96.0 0.0.31.255 area 2
network 172.31.170.0 0.0.0.255 area 2
network 172.31.0.0 0.0.255.255 area 2
maximum-paths 6
!
ip classless
ip route 0.0.0.0 0.0.0.0 1.1.1.6
ip route 0.0.0.0 0.0.0.0 172.31.4.99
ip route 172.18.177.0 255.255.255.0 10.194.17.254
ip route 172.18.177.128 255.255.255.192 10.194.17.254
ip route 172.18.179.128 255.255.255.192 10.194.17.254
no ip http server
ip pim rp-address 172.31.0.106 1 override
ip pim rp-address 172.31.0.98 2 override
ip pim spt-threshold infinity
ip msdp peer 172.31.4.106 connect-source Loopback0
ip msdp cache-sa-state
ip msdp originator-id Loopback0
!
!
logging trap debugging
logging 172.18.177.132
access-list 1 permit 239.255.0.0 0.0.255.255
access-list 1 deny
any
access-list 2 permit 224.0.1.39
access-list 2 permit 224.0.1.40
access-list 181 permit ip any any
snmp-server community public RO
snmp-server community cisco RW
!
alias exec ospf sh run | be router ospf
!
line con 0
exec-timeout 0 0
privilege level 15
line vty 0 4
exec-timeout 0 0
password cisco
login
length 0
history size 256
transport input lat pad mop telnet rlogin udptn nasi
line vty 5 10
exec-timeout 0 0
password cisco
login
length 0
history size 256
transport input lat pad mop telnet rlogin udptn nasi
!
exception protocol ftp
exception dump 172.18.177.129
exception memory fragment 200000
exception memory minimum 200000
scheduler runtime netinput 300
ntp clock-period 17180067
ntp update-calendar
ntp server 172.18.177.132
!
monitor session 1 source interface Fa9/1 rx
monitor session 1 destination interface Fa9/48
Cisco IOS Release 12.1(13)E13
135
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
end
SH1-105#show version
Cisco Internetwork Operating System Software
IOS (tm) c6sup1_rp Software (c6sup1_rp-JSV-M), Version 12.1(nightly13e.E040229) NIGHTLY
BUILD, synced to cosmos_e V121_12_5_E1
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Sun 29-Feb-04 22:37 by
Image text-base: 0x60020BC8, data-base: 0x618D8000
ROM: System Bootstrap, Version 12.0(3)XE, RELEASE SOFTWARE
BOOTLDR: MSFC Software (C6MSFC-BOOT-M), Version 12.1(nightly13e.E040229) NIGHTLY BUILD,
synced to cosmos_e V121_12_5_E1
SH1-105 uptime is 1 week, 2 days, 21 hours, 30 minutes
Time since SH1-105 switched to active is 1 week, 2 days, 21 hours, 29 minutes
System returned to ROM by power-on (SP by reload)
System restarted at 14:13:16 EST Mon Mar 8 2004
System image file is "slot0:c6sup11-jsv-mz.v121_13_e_throttle.040229"
cisco Catalyst 6000 (R5000) processor with 114688K/16384K bytes of memory.
Processor board ID SAD060203N1
R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
15 Virtual Ethernet/IEEE 802.3 interface(s)
72 FastEthernet/IEEE 802.3 interface(s)
36 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.
4096K bytes of packet SRAM memory.
16384K bytes of Flash internal SIMM (Sector size 256K).
Standby is up
Standby has 114688K/16384K bytes of memory.
Configuration register is 0x2102
SH1-105#show module
Mod Ports Card Type
--- ----- -------------------------------------1
2 Cat 6k sup 1 Enhanced QoS (Active)
2
2 Cat 6k sup 1 Enhanced QoS (Standby)
3
8 8 port 1000mb GBIC Enhanced QoS
4
8 8 port 1000mb GBIC Enhanced QoS
5
8 8 port 1000mb GBIC Enhanced QoS
6
8 8 port 1000mb GBIC Enhanced QoS
7
24 24 port 100FX Multi mode
9
48 48 port 10/100 mb RJ45
Model
-----------------WS-X6K-SUP1A-2GE
WS-X6K-SUP1A-2GE
WS-X6408A-GBIC
WS-X6408A-GBIC
WS-X6408A-GBIC
WS-X6408A-GBIC
WS-X6324-100FX-MM
WS-X6348-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0002.fcbd.b49c to 0002.fcbd.b49d
7.1
5.4(2)
2 0030.b632.6052 to 0030.b632.6053
1.0
5.1(1)CSX
3 0005.7408.6308 to 0005.7408.630f
2.0
5.4(2)
4 0005.740d.5788 to 0005.740d.578f
2.0
5.4(2)
5 0005.7408.6428 to 0005.7408.642f
2.0
5.4(2)
6 0005.7408.6420 to 0005.7408.6427
2.0
5.4(2)
7 0008.a430.08b8 to 0008.a430.08cf
3.0
5.4(2)
9 0005.7463.cff0 to 0005.7463.d01f
5.0
5.4(2)
Mod Sub-Module
Cisco IOS Release 12.1(13)E13
136
Model
Serial
Serial No.
----------SAD060203GM
SAD03396042
SAL0545E7GX
SAL0551FFML
SAL0545E6G3
SAL0545E7JA
SAD055106XG
SAL0544DYR3
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Hw
Status
------Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Status
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
--- --------------------------1 Policy Feature Card
1 MSFC Cat6k daughterboard
2 Policy Feature Card
2 MSFC Cat6k daughterboard
9 Inline Power Module
SH1-105#
--------------WS-F6K-PFC
WS-F6K-MSFC
WS-F6K-PFC
WS-F6K-MSFC
WS-F6K-PWR
--------------- ------- ------SAD060100NR
1.1
Ok
SAD060203N1
2.1
Ok
SAD03397596
1.0
Ok
SAD03400578
1.2
Ok
1.0
Ok
Return to SH1-105, page 123
SH1-106
Go to Test Device Configurations, page 17
Go to Financial Lab Topology, page 2
Go to Test Cases, page 249
SH1-106#show config
Using 15045 out of 391160 bytes
!
! Last configuration change at 17:41:34 EST Tue Mar 16 2004 by baggins
! NVRAM config last updated at 17:41:47 EST Tue Mar 16 2004 by baggins
!
version 12.1
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
no service password-encryption
service internal
!
hostname SH1-106
!
boot system flash slot0:c6sup11-jk2sv-mz.v121_13_e_throttle.040315
boot bootldr bootflash:c6msfc-boot-mz.v121_13_e_throttle.040229
logging buffered 1000000 debugging
no logging console
aaa new-model
aaa authentication login default enable
aaa authentication login sh1-testcase group tacacs+ enable
enable secret 5 $1$3VD5$Q7urh.4djlu9tAnoCipsh0
enable password ww
!
clock timezone EST -5
clock summer-time EDT recurring
vtp domain FIN
vtp mode transparent
ip subnet-zero
!
!
ip ftp username vnc
ip ftp password rtpsqelab
no ip domain-lookup
ip domain-name cisco.com
!
ip dhcp pool dhcp-test-pool
network 172.31.105.0 255.255.255.0
default-router 172.31.105.66 172.31.105.67 172.31.105.1 172.31.105.254
lease 0 1
!
ip multicast-routing
ip ssh time-out 120
ip ssh authentication-retries 3
mls aclmerge algorithm odm
mls aclmerge odm optimizations
Cisco IOS Release 12.1(13)E13
137
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
mls ip multicast consistency-check
mls ip multicast non-rpf netflow
mls flow ip destination-source
mls flow ipx destination
!
!
!
redundancy
mode rpr-plus
main-cpu
auto-sync running-config
auto-sync bootvar
auto-sync standard
!
!
vlan 1
tb-vlan1 1002
tb-vlan2 1003
!
vlan 40-50,170,200
!
vlan 1002
tb-vlan1 1
tb-vlan2 1003
!
vlan 1003
tb-vlan1 1
tb-vlan2 1002
parent 1005
backupcrf enable
!
vlan 1004
bridge 1
stp type ibm
!
vlan 1005
bridge 1
!
!
interface Loopback0
ip address 172.31.4.106 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 172.31.0.106 255.255.255.255
ip pim sparse-mode
!
interface Port-channel20
description dista-2 PoCha
no ip address
switchport
switchport trunk encapsulation dot1q
!
interface Port-channel67
description sh1-99 po67
ip address 172.31.1.70 255.255.255.252
ip access-group 181 in
ip access-group 181 out
no ip unreachables
ip pim sparse-mode
logging event link-status
!
interface Port-channel167
description sh1-100 po67
Cisco IOS Release 12.1(13)E13
138
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip address 172.31.1.98 255.255.255.252
ip access-group 182 in
ip access-group 182 out
no ip unreachables
ip pim sparse-mode
logging event link-status
load-interval 30
!
interface GigabitEthernet1/1
no ip address
shutdown
!
interface GigabitEthernet1/2
no ip address
shutdown
!
interface GigabitEthernet2/1
no ip address
shutdown
!
interface GigabitEthernet2/2
no ip address
shutdown
!
interface GigabitEthernet3/1
description sh1-99 g9/5
no ip address
no ip unreachables
ip pim sparse-mode
channel-group 67 mode on
!
interface GigabitEthernet3/2
no ip address
shutdown
!
interface GigabitEthernet3/3
no ip address
ip pim sparse-mode
shutdown
!
interface GigabitEthernet3/4
no ip address
shutdown
!
interface GigabitEthernet3/5
no ip address
shutdown
!
interface GigabitEthernet3/6
no ip address
shutdown
!
interface GigabitEthernet3/7
description dista-2 4/9
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 20 mode on
!
interface GigabitEthernet3/8
description dista-2 4/10
no ip address
switchport
switchport trunk encapsulation dot1q
Cisco IOS Release 12.1(13)E13
139
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
channel-group 20 mode on
!
interface GigabitEthernet4/1
description sh1-99 g9/6
no ip address
no ip unreachables
ip pim sparse-mode
channel-group 67 mode on
!
interface GigabitEthernet4/2
no ip address
shutdown
!
interface GigabitEthernet4/3
no ip address
shutdown
!
interface GigabitEthernet4/4
no ip address
shutdown
!
interface GigabitEthernet4/5
no ip address
shutdown
!
interface GigabitEthernet4/6
no ip address
shutdown
!
interface GigabitEthernet4/7
no ip address
shutdown
!
interface GigabitEthernet4/8
no ip address
shutdown
!
interface GigabitEthernet5/1
description sh1-100 g9/5
no ip address
ip access-group 182 in
ip access-group 182 out
channel-group 167 mode on
!
interface GigabitEthernet5/2
no ip address
shutdown
!
interface GigabitEthernet5/3
no ip address
shutdown
!
interface GigabitEthernet5/4
no ip address
shutdown
!
interface GigabitEthernet5/5
no ip address
shutdown
!
interface GigabitEthernet5/6
no ip address
shutdown
!
Cisco IOS Release 12.1(13)E13
140
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface GigabitEthernet5/7
no ip address
shutdown
!
interface GigabitEthernet5/8
no ip address
shutdown
!
interface GigabitEthernet6/1
description sh1-100 g9/6
no ip address
ip access-group 182 in
ip access-group 182 out
channel-group 167 mode on
!
interface GigabitEthernet6/2
no ip address
shutdown
!
interface GigabitEthernet6/3
no ip address
shutdown
!
interface GigabitEthernet6/4
no ip address
shutdown
!
interface GigabitEthernet6/5
no ip address
shutdown
!
interface GigabitEthernet6/6
no ip address
shutdown
!
interface GigabitEthernet6/7
no ip address
shutdown
!
interface GigabitEthernet6/8
no ip address
shutdown
!
interface FastEthernet7/1
description flashnet
ip address 10.194.17.106 255.255.255.0
shutdown
duplex full
!
interface FastEthernet7/2
no ip address
shutdown
!
interface FastEthernet7/3
no ip address
shutdown
!
interface FastEthernet7/4
no ip address
shutdown
!
interface FastEthernet7/5
no ip address
shutdown
Cisco IOS Release 12.1(13)E13
141
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface FastEthernet7/6
no ip address
shutdown
!
interface FastEthernet7/7
no ip address
shutdown
!
interface FastEthernet7/8
no ip address
shutdown
!
interface FastEthernet7/9
no ip address
shutdown
!
interface FastEthernet7/10
no ip address
shutdown
!
interface FastEthernet7/11
no ip address
shutdown
!
interface FastEthernet7/12
no ip address
shutdown
!
interface FastEthernet7/13
no ip address
shutdown
!
interface FastEthernet7/14
no ip address
shutdown
!
interface FastEthernet7/15
no ip address
shutdown
!
interface FastEthernet7/16
no ip address
shutdown
!
interface FastEthernet7/17
no ip address
shutdown
!
interface FastEthernet7/18
no ip address
shutdown
!
interface FastEthernet7/19
no ip address
shutdown
!
interface FastEthernet7/20
no ip address
shutdown
!
interface FastEthernet7/21
no ip address
shutdown
Cisco IOS Release 12.1(13)E13
142
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface FastEthernet7/22
no ip address
shutdown
!
interface FastEthernet7/23
no ip address
shutdown
!
interface FastEthernet7/24
no ip address
shutdown
!
interface FastEthernet9/1
description IXIA 16/2
ip address 1.1.1.1 255.255.255.252
!
interface FastEthernet9/2
description IXIA 13/3
ip address 2.2.2.1 255.255.255.252
!
interface FastEthernet9/3
no ip address
!
interface FastEthernet9/4
no ip address
!
interface FastEthernet9/5
no ip address
shutdown
!
interface FastEthernet9/6
no ip address
shutdown
!
interface FastEthernet9/7
no ip address
shutdown
!
interface FastEthernet9/8
no ip address
shutdown
!
interface FastEthernet9/9
no ip address
shutdown
!
interface FastEthernet9/10
no ip address
!
interface FastEthernet9/11
no ip address
shutdown
!
interface FastEthernet9/12
no ip address
shutdown
!
interface FastEthernet9/13
no ip address
shutdown
!
interface FastEthernet9/14
no ip address
Cisco IOS Release 12.1(13)E13
143
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface FastEthernet9/15
no ip address
shutdown
!
interface FastEthernet9/16
no ip address
shutdown
!
interface FastEthernet9/17
no ip address
!
interface FastEthernet9/18
no ip address
shutdown
!
interface FastEthernet9/19
no ip address
shutdown
!
interface FastEthernet9/20
no ip address
shutdown
!
interface FastEthernet9/21
no ip address
shutdown
!
interface FastEthernet9/22
no ip address
shutdown
!
interface FastEthernet9/23
no ip address
shutdown
!
interface FastEthernet9/24
description flashnet
ip address 10.194.17.106 255.255.255.0
speed 100
duplex full
!
interface FastEthernet9/25
no ip address
shutdown
!
interface FastEthernet9/26
no ip address
shutdown
!
interface FastEthernet9/27
no ip address
shutdown
!
interface FastEthernet9/28
no ip address
shutdown
!
interface FastEthernet9/29
no ip address
shutdown
!
interface FastEthernet9/30
Cisco IOS Release 12.1(13)E13
144
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet9/31
no ip address
shutdown
!
interface FastEthernet9/32
no ip address
shutdown
!
interface FastEthernet9/33
no ip address
shutdown
!
interface FastEthernet9/34
no ip address
shutdown
!
interface FastEthernet9/35
no ip address
shutdown
!
interface FastEthernet9/36
no ip address
shutdown
!
interface FastEthernet9/37
no ip address
shutdown
!
interface FastEthernet9/38
no ip address
shutdown
!
interface FastEthernet9/39
no ip address
shutdown
!
interface FastEthernet9/40
no ip address
shutdown
!
interface FastEthernet9/41
no ip address
shutdown
!
interface FastEthernet9/42
no ip address
shutdown
!
interface FastEthernet9/43
no ip address
shutdown
!
interface FastEthernet9/44
no ip address
shutdown
!
interface FastEthernet9/45
no ip address
shutdown
!
interface FastEthernet9/46
Cisco IOS Release 12.1(13)E13
145
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet9/47
no ip address
shutdown
!
interface FastEthernet9/48
no ip address
shutdown
!
interface Vlan1
no ip address
!
interface Vlan4
no ip address
!
interface Vlan40
ip address 172.31.100.67 255.255.255.0
ip helper-address 172.31.4.98
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 1 ip 172.31.100.1
standby 1 priority 90
standby 1 preempt
standby 2 ip 172.31.100.254
standby 2 priority 110
standby 2 preempt
!
interface Vlan41
ip address 172.31.101.67 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 2 ip 172.31.101.1
standby 2 priority 90
standby 2 preempt
standby 3 ip 172.31.101.254
standby 3 priority 110
standby 3 preempt
!
interface Vlan42
ip address 172.31.102.67 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 3 ip 172.31.102.1
standby 3 priority 90
standby 3 preempt
standby 4 ip 172.31.102.254
standby 4 priority 110
standby 4 preempt
!
interface Vlan43
ip address 172.31.103.67 255.255.255.0
no ip redirects
ip directed-broadcast
Cisco IOS Release 12.1(13)E13
146
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 4 ip 172.31.103.1
standby 4 priority 90
standby 4 preempt
standby 5 ip 172.31.103.254
standby 5 priority 110
standby 5 preempt
!
interface Vlan44
ip address 172.31.104.67 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 5 ip 172.31.104.1
standby 5 priority 90
standby 5 preempt
standby 6 ip 172.31.104.254
standby 6 priority 110
standby 6 preempt
!
interface Vlan45
ip address 172.31.105.67 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 6 ip 172.31.105.1
standby 6 priority 90
standby 6 preempt
standby 7 ip 172.31.105.254
standby 7 priority 110
standby 7 preempt
!
interface Vlan46
ip address 172.31.106.67 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 7 ip 172.31.106.1
standby 7 priority 90
standby 7 preempt
standby 8 ip 172.31.106.254
standby 8 priority 110
standby 8 preempt
!
interface Vlan47
ip address 172.31.107.67 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 8 ip 172.31.107.1
standby 8 priority 90
standby 8 preempt
standby 9 ip 172.31.107.254
standby 9 priority 110
Cisco IOS Release 12.1(13)E13
147
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
standby 9 preempt
!
interface Vlan48
ip address 172.31.108.67 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 9 ip 172.31.108.1
standby 9 priority 90
standby 9 preempt
standby 10 ip 172.31.108.254
standby 10 priority 110
standby 10 preempt
!
interface Vlan49
ip address 172.31.109.67 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 10 ip 172.31.109.1
standby 10 priority 90
standby 10 preempt
standby 11 ip 172.31.109.254
standby 11 priority 110
standby 11 preempt
!
interface Vlan50
ip address 172.31.110.67 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 11 ip 172.31.110.1
standby 11 priority 90
standby 11 preempt
standby 12 ip 172.31.110.254
standby 12 priority 110
standby 12 preempt
!
interface Vlan170
description Pagent OSPF VLAN
ip address 172.31.170.106 255.255.255.0
no ip redirects
standby ip 172.31.170.1
standby priority 110
standby preempt
!
interface Vlan200
ip address 172.31.200.17 255.255.255.252
ip access-group 181 in
ip access-group 181 out
no ip unreachables
ip pim sparse-mode
!
interface Vlan600
description IPTV server
no ip address
no ip redirects
ip pim query-interval 3
Cisco IOS Release 12.1(13)E13
148
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip pim sparse-mode
!
router ospf 1
log-adjacency-changes
auto-cost reference-bandwidth 100000
passive-interface default
no passive-interface Vlan40
no passive-interface Vlan170
no passive-interface FastEthernet9/2
no passive-interface Port-channel67
no passive-interface Port-channel167
network 172.31.1.68 0.0.0.3 area 2
network 172.31.1.96 0.0.0.3 area 2
network 172.31.4.0 0.0.0.255 area 2
network 172.31.60.0 0.0.0.255 area 2
network 172.31.96.0 0.0.31.255 area 2
network 172.31.170.0 0.0.0.255 area 2
network 172.31.0.0 0.0.255.255 area 2
maximum-paths 8
!
ip classless
ip route 172.18.177.128 255.255.255.192 10.194.17.254
ip route 172.18.179.128 255.255.255.192 10.194.17.254
no ip http server
ip pim rp-address 172.31.0.106 1 override
ip pim rp-address 172.31.0.98 2 override
ip pim spt-threshold infinity
ip msdp peer 172.31.4.105 connect-source Loopback0
ip msdp cache-sa-state
ip msdp originator-id Loopback0
!
!
logging trap debugging
access-list 1 permit 239.255.0.0 0.0.255.255
access-list 1 deny
any
access-list 2 permit 224.0.1.39
access-list 2 permit 224.0.1.40
access-list 181 permit ip any any
access-list 182 permit ip any any
snmp-server community public RO
snmp-server community cisco RW
snmp-server enable traps config
snmp-server host 172.18.177.135 public
snmp-server host 172.18.177.181 public
!
tacacs-server host 172.18.177.132
alias exec ospf sh run | be router ospf
!
line con 0
exec-timeout 0 0
privilege level 15
line vty 0 4
exec-timeout 0 0
login authentication sh1-testcase
length 0
history size 256
transport input lat pad mop telnet rlogin udptn nasi ssh
line vty 5 10
exec-timeout 0 0
login authentication sh1-testcase
length 0
history size 256
transport input lat pad mop telnet rlogin udptn nasi ssh
!
Cisco IOS Release 12.1(13)E13
149
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
exception protocol ftp
exception dump 172.18.177.132
exception memory fragment 200000
exception memory minimum 200000
scheduler runtime netinput 300
ntp clock-period 17180103
ntp update-calendar
ntp server 172.18.177.131
ntp server 172.18.177.132 prefer
!
monitor session 1 source interface Po20 rx
monitor session 1 destination interface Fa9/1
end
SH1-106#show version
Cisco Internetwork Operating System Software
IOS (tm) c6sup1_rp Software (c6sup1_rp-JK2SV-M), Version 12.1(nightly13e.E040315) NIGHTLY
BUILD, synced to cosmos_e V121_12_5_E1
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Mon 15-Mar-04 21:22 by
Image text-base: 0x60020BC8, data-base: 0x61A7E000
ROM: System Bootstrap, Version 12.0(3)XE, RELEASE SOFTWARE
BOOTLDR: MSFC Software (C6MSFC-BOOT-M), Version 12.1(nightly13e.E040229) NIGHTLY BUILD,
synced to cosmos_e V121_12_5_E1
SH1-106 uptime is 1 day, 18 hours, 31 minutes
Time since SH1-106 switched to active is 1 day, 18 hours, 30 minutes
System returned to ROM by power-on (SP by power-on)
System restarted at 17:44:47 EST Tue Mar 16 2004
System image file is "slot0:c6sup11-jk2sv-mz.v121_13_e_throttle.040315"
cisco Catalyst 6000 (R5000) processor with 114688K/16384K bytes of memory.
Processor board ID SAD060203M3
R5000 CPU at 200Mhz, Implementation 35, Rev 2.1, 512KB L2 Cache
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
16 Virtual Ethernet/IEEE 802.3 interface(s)
72 FastEthernet/IEEE 802.3 interface(s)
36 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.
4096K bytes of packet SRAM memory.
16384K bytes of Flash internal SIMM (Sector size 256K).
Standby is up
Standby has 114688K/16384K bytes of memory.
Configuration register is 0x2102
SH1-106#show module
Mod Ports Card Type
--- ----- -------------------------------------1
2 Cat 6k sup 1 Enhanced QoS (Active)
2
2 Cat 6k sup 1 Enhanced QoS (Standby)
3
8 8 port 1000mb GBIC Enhanced QoS
4
8 8 port 1000mb GBIC Enhanced QoS
5
8 8 port 1000mb GBIC Enhanced QoS
6
8 8 port 1000mb GBIC Enhanced QoS
7
24 24 port 100FX Multi mode
9
48 48 port 10/100 mb RJ45
Cisco IOS Release 12.1(13)E13
150
Model
-----------------WS-X6K-SUP1A-2GE
WS-X6K-SUP1A-2GE
WS-X6408A-GBIC
WS-X6408A-GBIC
WS-X6408A-GBIC
WS-X6408A-GBIC
WS-X6324-100FX-MM
WS-X6348-RJ-45
Serial No.
----------SAL0546EC5N
SAL0542D559
SAL0545E7J9
SAL0540CTF5
SAL0545E7GY
SAL0540CTE7
SAD05510703
SAD042101CV
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0006.d65a.1500 to 0006.d65a.1501
7.1
5.4(2)
2 0006.d659.9940 to 0006.d659.9941
7.1
5.4(2)
3 0005.7408.6418 to 0005.7408.641f
2.0
5.4(2)
4 0007.4f69.c058 to 0007.4f69.c05f
2.0
5.4(2)
5 0005.7408.6328 to 0005.7408.632f
2.0
5.4(2)
6 0005.7460.4440 to 0005.7460.4447
2.0
5.4(2)
7 0008.a430.0870 to 0008.a430.0887
3.0
5.4(2)
9 0001.9728.1050 to 0001.9728.107f
1.1
5.3(1)
Mod Sub-Module
--- --------------------------1 Policy Feature Card
1 MSFC Cat6k daughterboard
2 Policy Feature Card
2 MSFC Cat6k daughterboard
9 Inline Power Module
SH1-106#
Model
--------------WS-F6K-PFC
WS-F6K-MSFC
WS-F6K-PFC
WS-F6K-MSFC
WS-F6K-PWR
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD060100LZ
1.1
Ok
SAD060203M3
2.1
Ok
SAD053202FY
1.1
Ok
SAD05280377
1.4
Ok
1.0
Ok
Return to SH1-106, page 137
SH1-107
Go to Test Device Configurations, page 17
Go to Financial Lab Topology, page 2
Go to Test Cases, page 249
SH1-107#show config
Using 16380 out of 391160 bytes
!
!
version 12.1
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
no service password-encryption
!
hostname SH1-107
!
boot system flash slot0:
boot bootldr bootflash:
enable password cisco
!
clock timezone EST -5
clock summer-time EDT recurring
vtp domain FIN
vtp mode transparent
ip subnet-zero
!
!
ip ftp username safeharbor
ip ftp password shshsh
no ip domain-lookup
!
ip multicast-routing
ip cef load-sharing algorithm universal 00000004
mls flow ip destination-source
mls flow ipx destination
mls ip multicast non-rpf netflow
!
redundancy
Cisco IOS Release 12.1(13)E13
151
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
mode rpr-plus
main-cpu
auto-sync running-config
auto-sync standard
!
!
vlan 1
tb-vlan1 1002
tb-vlan2 1003
!
vlan 10-20,40-50,150,500-501,1000
!
vlan 1002
tb-vlan1 1
tb-vlan2 1003
!
vlan 1003
tb-vlan1 1
tb-vlan2 1002
!
vlan 1004
bridge 1
stp type ibm
!
!
interface Loopback0
ip address 172.31.4.107 255.255.255.255
ip pim sparse-mode
!
interface Port-channel1
ip address 172.31.1.117 255.255.255.252
ip pim sparse-mode
logging event link-status
!
interface Port-channel10
description dista-1 PoCha
no ip address
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface Port-channel68
description sh1-103 po68
ip address 172.31.1.74 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel168
description sh1-104 po68
ip address 172.31.1.102 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel171
no ip address
!
interface GigabitEthernet1/1
no ip address
shutdown
!
Cisco IOS Release 12.1(13)E13
152
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface GigabitEthernet1/2
no ip address
shutdown
!
interface GigabitEthernet2/1
no ip address
shutdown
!
interface GigabitEthernet2/2
no ip address
shutdown
!
interface GigabitEthernet3/1
description sh1-103 g7/7
no ip address
channel-group 68 mode on
!
interface GigabitEthernet3/2
description sh1-103 g7/8
no ip address
channel-group 68 mode on
!
interface GigabitEthernet3/3
description sh1-103 g7/9
no ip address
channel-group 68 mode on
!
interface GigabitEthernet3/4
description sh1-103 g7/10
no ip address
channel-group 68 mode on
!
interface GigabitEthernet3/5
description sh1-104 g7/7
no ip address
channel-group 168 mode auto
!
interface GigabitEthernet3/6
description sh1-104 g7/8
no ip address
channel-group 168 mode auto
!
interface GigabitEthernet3/7
no ip address
channel-group 1 mode on
!
interface GigabitEthernet3/8
no ip address
shutdown
!
interface GigabitEthernet4/1
description dista-1 1/1
no ip address
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 10 mode on
!
interface GigabitEthernet4/2
no ip address
shutdown
!
interface GigabitEthernet4/3
description dista-1 2/1
Cisco IOS Release 12.1(13)E13
153
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
channel-group 10 mode on
!
interface GigabitEthernet4/4
no ip address
shutdown
!
interface GigabitEthernet4/5
description sh1-104 g7/9
no ip address
channel-group 168 mode auto
!
interface GigabitEthernet4/6
description sh1-104 g7/10
no ip address
channel-group 168 mode auto
!
interface GigabitEthernet4/7
no ip address
channel-group 1 mode on
!
interface GigabitEthernet4/8
no ip address
shutdown
!
interface FastEthernet5/1
description flashnet
ip address 10.194.17.107 255.255.255.0
shutdown
duplex full
!
interface FastEthernet5/2
no ip address
shutdown
!
interface FastEthernet5/3
no ip address
shutdown
!
interface FastEthernet5/4
no ip address
shutdown
!
interface FastEthernet5/5
no ip address
shutdown
!
interface FastEthernet5/6
no ip address
shutdown
!
interface FastEthernet5/7
no ip address
shutdown
!
interface FastEthernet5/8
no ip address
shutdown
!
interface FastEthernet5/9
no ip address
Cisco IOS Release 12.1(13)E13
154
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface FastEthernet5/10
no ip address
shutdown
!
interface FastEthernet5/11
no ip address
shutdown
!
interface FastEthernet5/12
no ip address
shutdown
!
interface FastEthernet5/13
no ip address
shutdown
!
interface FastEthernet5/14
no ip address
shutdown
!
interface FastEthernet5/15
no ip address
shutdown
!
interface FastEthernet5/16
no ip address
shutdown
!
interface FastEthernet5/17
no ip address
shutdown
!
interface FastEthernet5/18
no ip address
shutdown
!
interface FastEthernet5/19
no ip address
shutdown
!
interface FastEthernet5/20
no ip address
shutdown
!
interface FastEthernet5/21
no ip address
shutdown
!
interface FastEthernet5/22
no ip address
shutdown
!
interface FastEthernet5/23
no ip address
shutdown
!
interface FastEthernet5/24
no ip address
shutdown
!
interface FastEthernet9/1
no ip address
Cisco IOS Release 12.1(13)E13
155
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface FastEthernet9/2
no ip address
shutdown
!
interface FastEthernet9/3
description IXIA 5/3
ip address 172.31.207.1 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
speed 100
duplex full
!
interface FastEthernet9/4
no ip address
shutdown
!
interface FastEthernet9/5
no ip address
shutdown
!
interface FastEthernet9/6
no ip address
shutdown
!
interface FastEthernet9/7
no ip address
shutdown
!
interface FastEthernet9/8
no ip address
shutdown
!
interface FastEthernet9/9
no ip address
shutdown
!
interface FastEthernet9/10
no ip address
shutdown
!
interface FastEthernet9/11
no ip address
shutdown
!
interface FastEthernet9/12
no ip address
shutdown
!
interface FastEthernet9/13
ip address 1.1.1.1 255.255.255.252
!
interface FastEthernet9/14
ip address 1.1.1.5 255.255.255.252
!
interface FastEthernet9/15
no ip address
shutdown
!
interface FastEthernet9/16
no ip address
shutdown
Cisco IOS Release 12.1(13)E13
156
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface FastEthernet9/17
no ip address
shutdown
!
interface FastEthernet9/18
no ip address
shutdown
!
interface FastEthernet9/19
no ip address
shutdown
!
interface FastEthernet9/20
no ip address
shutdown
!
interface FastEthernet9/21
no ip address
shutdown
!
interface FastEthernet9/22
no ip address
shutdown
!
interface FastEthernet9/23
no ip address
shutdown
!
interface FastEthernet9/24
description flashnet
ip address 10.194.17.107 255.255.255.0
speed 100
duplex full
!
interface FastEthernet9/25
no ip address
shutdown
!
interface FastEthernet9/26
no ip address
shutdown
!
interface FastEthernet9/27
no ip address
shutdown
!
interface FastEthernet9/28
no ip address
shutdown
!
interface FastEthernet9/29
no ip address
shutdown
!
interface FastEthernet9/30
no ip address
shutdown
!
interface FastEthernet9/31
no ip address
shutdown
!
interface FastEthernet9/32
Cisco IOS Release 12.1(13)E13
157
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet9/33
no ip address
shutdown
!
interface FastEthernet9/34
no ip address
shutdown
!
interface FastEthernet9/35
no ip address
shutdown
!
interface FastEthernet9/36
no ip address
shutdown
!
interface FastEthernet9/37
no ip address
shutdown
!
interface FastEthernet9/38
no ip address
shutdown
!
interface FastEthernet9/39
no ip address
shutdown
!
interface FastEthernet9/40
no ip address
shutdown
!
interface FastEthernet9/41
no ip address
shutdown
!
interface FastEthernet9/42
no ip address
shutdown
!
interface FastEthernet9/43
no ip address
shutdown
!
interface FastEthernet9/44
no ip address
shutdown
!
interface FastEthernet9/45
no ip address
shutdown
!
interface FastEthernet9/46
no ip address
shutdown
!
interface FastEthernet9/47
no ip address
shutdown
!
interface FastEthernet9/48
Cisco IOS Release 12.1(13)E13
158
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface Vlan1
no ip address
shutdown
!
interface Vlan10
ip address 172.31.10.68 255.255.255.0
ip access-group 135 in
no ip redirects
no ip unreachables
ip pim query-interval 3
ip pim sparse-mode
standby 1 ip 172.31.10.1
standby 1 priority 110
standby 1 preempt
standby 2 ip 172.31.10.254
standby 2 priority 90
standby 2 preempt
!
interface Vlan11
ip address 172.31.11.68 255.255.255.0
ip access-group 136 in
ip helper-address 172.31.16.82
no ip redirects
no ip unreachables
ip pim query-interval 3
ip pim sparse-mode
standby 2 ip 172.31.11.1
standby 2 priority 110
standby 2 preempt
standby 3 ip 172.31.11.254
standby 3 priority 90
standby 3 preempt
!
interface Vlan12
ip address 172.31.12.68 255.255.255.0
ip access-group 137 in
no ip redirects
no ip unreachables
ip pim query-interval 3
ip pim sparse-mode
standby 3 ip 172.31.12.1
standby 3 priority 110
standby 3 preempt
standby 4 ip 172.31.12.254
standby 4 priority 90
standby 4 preempt
!
interface Vlan13
ip address 172.31.13.68 255.255.255.0
ip access-group 138 in
no ip redirects
no ip unreachables
ip pim query-interval 3
ip pim sparse-mode
standby 4 ip 172.31.13.1
standby 4 priority 110
standby 4 preempt
standby 5 ip 172.31.13.254
standby 5 priority 90
standby 5 preempt
!
Cisco IOS Release 12.1(13)E13
159
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface Vlan14
ip address 172.31.14.68 255.255.255.0
ip access-group 139 in
no ip redirects
no ip unreachables
ip pim query-interval 3
ip pim sparse-mode
standby 5 ip 172.31.14.1
standby 5 priority 110
standby 5 preempt
standby 6 ip 172.31.14.254
standby 6 priority 90
standby 6 preempt
!
interface Vlan15
ip address 172.31.15.68 255.255.255.0
ip access-group 140 in
no ip redirects
no ip unreachables
ip pim query-interval 3
ip pim sparse-mode
standby 6 ip 172.31.15.1
standby 6 priority 110
standby 6 preempt
standby 7 ip 172.31.15.254
standby 7 priority 90
standby 7 preempt
!
interface Vlan16
ip address 172.31.16.68 255.255.255.0
ip access-group 141 in
no ip redirects
no ip unreachables
ip pim query-interval 3
ip pim sparse-mode
standby 7 ip 172.31.16.1
standby 7 priority 110
standby 7 preempt
standby 8 ip 172.31.16.254
standby 8 priority 90
standby 8 preempt
!
interface Vlan17
ip address 172.31.17.68 255.255.255.0
ip access-group 142 in
no ip redirects
no ip unreachables
ip pim query-interval 3
ip pim sparse-mode
standby 8 ip 172.31.17.1
standby 8 priority 110
standby 8 preempt
standby 9 ip 172.31.17.254
standby 9 priority 90
standby 9 preempt
!
interface Vlan18
ip address 172.31.18.68 255.255.255.0
ip access-group 143 in
no ip redirects
no ip unreachables
ip pim query-interval 3
ip pim sparse-mode
standby 9 ip 172.31.18.1
Cisco IOS Release 12.1(13)E13
160
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
standby
standby
standby
standby
standby
9 priority 110
9 preempt
10 ip 172.31.18.254
10 priority 90
10 preempt
!
interface Vlan19
ip address 172.31.19.68 255.255.255.0
ip access-group 144 in
no ip redirects
no ip unreachables
ip pim query-interval 3
ip pim sparse-mode
standby 10 ip 172.31.19.1
standby 10 priority 110
standby 10 preempt
standby 11 ip 172.31.19.254
standby 11 priority 90
standby 11 preempt
!
interface Vlan20
ip address 172.31.9.68 255.255.255.0
ip access-group 145 in
no ip redirects
no ip unreachables
ip pim query-interval 3
ip pim sparse-mode
standby 11 ip 172.31.9.1
standby 11 priority 110
standby 11 preempt
standby 12 ip 172.31.9.254
standby 12 priority 90
standby 12 preempt
!
router ospf 1
log-adjacency-changes
auto-cost reference-bandwidth 100000
passive-interface default
no passive-interface Vlan10
no passive-interface FastEthernet9/3
no passive-interface Port-channel1
no passive-interface Port-channel68
no passive-interface Port-channel168
network 172.31.0.0 0.0.0.255 area 1
network 172.31.1.72 0.0.0.3 area 1
network 172.31.1.100 0.0.0.3 area 1
network 172.31.1.116 0.0.0.3 area 1
network 172.31.2.48 0.0.0.3 area 1
network 172.31.4.0 0.0.0.255 area 1
network 172.31.8.0 0.0.7.255 area 1
network 172.31.16.0 0.0.3.255 area 1
network 172.31.50.0 0.0.0.255 area 1
network 172.31.207.0 0.0.0.3 area 1
maximum-paths 6
!
ip classless
no ip forward-protocol udp tftp
no ip forward-protocol udp nameserver
no ip forward-protocol udp domain
no ip forward-protocol udp time
no ip forward-protocol udp netbios-ns
no ip forward-protocol udp netbios-dgm
no ip forward-protocol udp tacacs
ip route 0.0.0.0 0.0.0.0 1.1.1.6
Cisco IOS Release 12.1(13)E13
161
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip route 172.18.177.128 255.255.255.192 10.194.17.254
ip route 172.18.179.128 255.255.255.192 10.194.17.254
no ip http server
ip pim rp-address 172.31.0.104 1 override
ip pim rp-address 172.31.0.98 2 override
ip pim spt-threshold infinity
!
!
logging trap debugging
logging 172.18.112.184
access-list 1 permit 239.255.0.0 0.0.255.255
access-list 1 deny
any
access-list 2 permit 224.0.1.39
access-list 2 permit 224.0.1.40
access-list 101 permit ip host 172.31.10.112 any
access-list 101 permit ip any host 172.31.10.112
access-list 102 permit ip host 172.31.21.101 host 239.255.127.100
access-list 102 deny
ip any any
access-list 135 permit ip 172.31.10.0 0.0.0.255 any
access-list 135 permit ip any 224.0.0.0 0.0.0.255
access-list 135 permit ip any 224.0.1.0 0.0.0.255
access-list 135 deny
ip any 224.0.0.0 15.255.255.255
access-list 135 permit ip any any
access-list 136 permit ip 172.31.11.0 0.0.0.255 any
access-list 136 permit ip any 224.0.0.0 0.0.0.255
access-list 136 permit ip any 224.0.1.0 0.0.0.255
access-list 136 deny
ip any 224.0.0.0 15.255.255.255
access-list 136 permit ip any any
access-list 137 permit ip 172.31.12.0 0.0.0.255 any
access-list 137 permit ip any 224.0.0.0 0.0.0.255
access-list 137 permit ip any 224.0.1.0 0.0.0.255
access-list 137 deny
ip any 224.0.0.0 15.255.255.255
access-list 137 permit ip any any
access-list 138 permit ip 172.31.13.0 0.0.0.255 any
access-list 138 permit ip any 224.0.0.0 0.0.0.255
access-list 138 permit ip any 224.0.1.0 0.0.0.255
access-list 138 deny
ip any 224.0.0.0 15.255.255.255
access-list 138 permit ip any any
access-list 139 permit ip 172.31.14.0 0.0.0.255 any
access-list 139 permit ip any 224.0.0.0 0.0.0.255
access-list 139 permit ip any 224.0.1.0 0.0.0.255
access-list 139 deny
ip any 224.0.0.0 15.255.255.255
access-list 139 permit ip any any
access-list 140 permit ip 172.31.15.0 0.0.0.255 any
access-list 140 permit ip any 224.0.0.0 0.0.0.255
access-list 140 permit ip any 224.0.1.0 0.0.0.255
access-list 140 deny
ip any 224.0.0.0 15.255.255.255
access-list 140 permit ip any any
access-list 141 permit ip 172.31.16.0 0.0.0.255 any
access-list 141 permit ip any 224.0.0.0 0.0.0.255
access-list 141 permit ip any 224.0.1.0 0.0.0.255
access-list 141 deny
ip any 224.0.0.0 15.255.255.255
access-list 141 permit ip any any
access-list 142 permit ip 172.31.17.0 0.0.0.255 any
access-list 142 permit ip any 224.0.0.0 0.0.0.255
access-list 142 permit ip any 224.0.1.0 0.0.0.255
access-list 142 deny
ip any 224.0.0.0 15.255.255.255
access-list 142 permit ip any any
access-list 143 permit ip 172.31.18.0 0.0.0.255 any
access-list 143 permit ip any 224.0.0.0 0.0.0.255
access-list 143 permit ip any 224.0.1.0 0.0.0.255
access-list 143 deny
ip any 224.0.0.0 15.255.255.255
access-list 143 permit ip any any
access-list 144 permit ip 172.31.19.0 0.0.0.255 any
Cisco IOS Release 12.1(13)E13
162
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
access-list 144 permit ip any 224.0.0.0 0.0.0.255
access-list 144 permit ip any 224.0.1.0 0.0.0.255
access-list 144 deny
ip any 224.0.0.0 15.255.255.255
access-list 144 permit ip any any
access-list 145 permit ip 172.31.9.0 0.0.0.255 any
access-list 145 permit ip any 224.0.0.0 0.0.0.255
access-list 145 permit ip any 224.0.1.0 0.0.0.255
access-list 145 deny
ip any 224.0.0.0 15.255.255.255
access-list 145 permit ip any any
access-list 181 permit ip any any
snmp-server community public RO
snmp-server community cisco RW
!
rmon event 1 log trap public description "Rising EventIndex for avgBusy1~%~" owner admin
rmon event 2 log trap public description "Falling EventIndex for avgBusy1" owner admin
rmon alarm 1 lsystem.57.0 60 absolute rising-threshold 90 1 falling-threshold 70 2 owner
admin
alias exec ip sh ip int brief | be Port
alias exec eigrp show run | be router eigrp
alias exec mr sh ip mr 239.255.127.100
alias exec ospf sh run | be router ospf
!
line con 0
exec-timeout 0 0
line vty 0 4
exec-timeout 0 0
password cisco
login
length 0
history size 256
transport input lat pad mop telnet rlogin udptn nasi
line vty 5 10
exec-timeout 0 0
password cisco
login
length 0
history size 256
transport input lat pad mop telnet rlogin udptn nasi
!
exception protocol ftp
exception dump 172.18.177.129
exception memory fragment 200000
exception memory minimum 200000
ntp clock-period 17180203
ntp update-calendar
ntp server 172.18.177.132
end
SH1-107#show version
Cisco Internetwork Operating System Software
IOS (tm) c6sup2_rp Software (c6sup2_rp-JSV-M), Version 12.1(nightly13e.E040229) NIGHTLY
BUILD, synced to cosmos_e V121_12_5_E1
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Sun 29-Feb-04 21:25 by
Image text-base: 0x40008BF0, data-base: 0x41A4C000
ROM: System Bootstrap, Version 12.1(4r)E, RELEASE SOFTWARE (fc1)
SH1-107 uptime is 1 week, 2 days, 18 hours, 27 minutes
Time since SH1-107 switched to active is 1 week, 2 days, 18 hours, 17 minutes
System returned to ROM by power-on (SP by power-on)
System restarted at 17:15:26 EST Mon Mar 8 2004
System image file is "slot0:c6sup12-jsv-mz.v121_13_e_throttle.040229"
Cisco IOS Release 12.1(13)E13
163
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
cisco Catalyst 6000 (R7000) processor with 112640K/18432K bytes of memory.
Processor board ID SAL0601FXUF
R7000 CPU at 300Mhz, Implementation 39, Rev 3.3, 256KB L2, 1024KB L3 Cache
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
12 Virtual Ethernet/IEEE 802.3 interface(s)
72 FastEthernet/IEEE 802.3 interface(s)
20 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.
32768K bytes of Flash internal SIMM (Sector size 512K).
Standby is up
Standby has 112640K/18432K bytes of memory.
Configuration register is 0x2102
SH1-107#show module
Mod Ports Card Type
--- ----- -------------------------------------1
2 Cat 6k sup 1 Enhanced QoS (Active)
2
2 Cat 6k sup 1 Enhanced QoS (Standby)
3
8 8 port 1000mb GBIC Enhanced QoS
4
8 8 port 1000mb GBIC Enhanced QoS
5
24 24 port 100FX Multi mode
9
48 SFM-capable 48-port 10/100 Mbps RJ45
Model
-----------------WS-X6K-SUP1A-2GE
WS-X6K-SUP1A-2GE
WS-X6408A-GBIC
WS-X6408A-GBIC
WS-X6324-100FX-MM
WS-X6548-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0006.d65a.4dec to 0006.d65a.4ded
7.1
5.4(2)
2 0006.d65a.4d2c to 0006.d65a.4d2d
7.1
5.4(2)
3 0005.7408.64e0 to 0005.7408.64e7
2.0
5.4(2)
4 0005.7408.6610 to 0005.7408.6617
2.0
5.4(2)
5 0003.3287.686a to 0003.3287.6881
3.0
5.4(2)
9 0009.11f5.2298 to 0009.11f5.22c7
5.2
6.3(1)
Mod Sub-Module
--- --------------------------1 Policy Feature Card
1 Cat6k MSFC 2 daughterboard
2 Policy Feature Card
2 Cat6k MSFC 2 daughterboard
SH1-107#
Model
--------------WS-F6K-PFC
WS-F6K-MSFC2
WS-F6K-PFC
WS-F6K-MSFC2
SH1-108
Go to Test Device Configurations, page 17
Go to Financial Lab Topology, page 2
Go to Test Cases, page 249
SH1-108#show config
Using 14213 out of 391160 bytes
!
!
version 12.1
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
no service password-encryption
Cisco IOS Release 12.1(13)E13
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAL0601FXKX
2.0
Ok
SAL0601FXUF
2.0
Ok
SAL0601FXD0
2.0
Ok
SAL0601FXUC
2.0
Ok
Return to SH1-107, page 151
164
Serial No.
----------SAL0601G6BV
SAL0501FWA7
SAL0545E7FM
SAL0545E6C0
SAD0551070E
SAL0708D6TF
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
service internal
!
hostname SH1-108
!
boot system flash slot0:
boot bootldr bootflash:
no logging console
aaa new-model
aaa authentication login default enable
aaa authentication login sh1-testcase group tacacs+ enable
enable secret 5 $1$rOL9$PKASr.jRsib8kECraGEjQ.
!
clock timezone EST -5
clock summer-time EDT recurring
vtp domain FIN
vtp mode transparent
ip subnet-zero
!
!
ip ftp username vnc
ip ftp password rtpsqelab
no ip domain-lookup
ip domain-name cisco.com
!
ip multicast-routing
ip ssh time-out 120
ip ssh authentication-retries 3
mls flow ip destination-source
mls flow ipx destination
mls aclmerge algorithm odm
mls aclmerge odm optimizations
mls ip multicast consistency-check
mls ip multicast non-rpf netflow
!
!
!
redundancy
mode rpr-plus
main-cpu
auto-sync running-config
auto-sync standard
!
!
vlan 1
tb-vlan1 1002
tb-vlan2 1003
!
vlan 10-20,40-50,60-61,150,500-501,1000
!
vlan 1002
tb-vlan1 1
tb-vlan2 1003
!
vlan 1003
tb-vlan1 1
tb-vlan2 1002
!
vlan 1004
bridge 1
stp type ibm
!
!
interface Loopback0
ip address 172.31.4.108 255.255.255.255
Cisco IOS Release 12.1(13)E13
165
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip pim sparse-mode
!
interface Port-channel1
ip address 172.31.1.118 255.255.255.252
ip pim sparse-mode
logging event link-status
logging event bundle-status
!
interface Port-channel10
description dista-1 PoCha
no ip address
switchport
switchport trunk encapsulation dot1q
!
interface Port-channel69
description sh1-103 po69
ip address 172.31.1.78 255.255.255.252
ip pim sparse-mode
logging event link-status
!
interface Port-channel169
description sh1-104 po69
ip address 172.31.1.106 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
logging event bundle-status
!
interface GigabitEthernet1/1
no ip address
shutdown
!
interface GigabitEthernet1/2
no ip address
shutdown
!
interface GigabitEthernet2/1
no ip address
shutdown
!
interface GigabitEthernet2/2
no ip address
shutdown
!
interface GigabitEthernet3/1
description sh1-103 g8/7
no ip address
ip access-group 182 in
ip access-group 182 out
logging event link-status
channel-group 69 mode on
!
interface GigabitEthernet3/2
description sh1-103 g8/8
no ip address
ip access-group 182 in
ip access-group 182 out
logging event link-status
channel-group 69 mode on
!
interface GigabitEthernet3/3
description sh1-103 g8/9
no ip address
Cisco IOS Release 12.1(13)E13
166
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip access-group 182 in
ip access-group 182 out
logging event link-status
channel-group 69 mode on
!
interface GigabitEthernet3/4
description sh1-103 g8/10
no ip address
ip access-group 182 in
ip access-group 182 out
logging event link-status
channel-group 69 mode on
!
interface GigabitEthernet3/5
description sh1-104 g8/7
no ip address
logging event link-status
logging event bundle-status
channel-group 169 mode on
!
interface GigabitEthernet3/6
description sh1-104 g8/8
no ip address
logging event link-status
logging event bundle-status
channel-group 169 mode on
!
interface GigabitEthernet3/7
no ip address
channel-group 1 mode on
!
interface GigabitEthernet3/8
description Ix-7/1
ip address 172.31.32.69 255.255.255.0
ip access-group 181 in
ip access-group 181 out
no ip unreachables
ip pim sparse-mode
!
interface GigabitEthernet4/1
description dista-1 1/2
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 10 mode on
!
interface GigabitEthernet4/2
description dista-1 2/2
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 10 mode on
!
interface GigabitEthernet4/3
description dista-1 2/3
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 10 mode on
!
interface GigabitEthernet4/4
description dista-1 2/4
no ip address
switchport
Cisco IOS Release 12.1(13)E13
167
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
switchport trunk encapsulation dot1q
channel-group 10 mode on
!
interface GigabitEthernet4/5
description sh1-104 g8/9
no ip address
logging event link-status
logging event bundle-status
channel-group 169 mode on
!
interface GigabitEthernet4/6
description sh1-104 g8/10
no ip address
logging event link-status
logging event bundle-status
channel-group 169 mode on
!
interface GigabitEthernet4/7
no ip address
channel-group 1 mode on
!
interface GigabitEthernet4/8
description Ix-7/2
ip address 172.31.208.5 255.255.255.252 secondary
ip address 172.31.208.1 255.255.255.252
ip access-group 181 in
ip access-group 181 out
no ip redirects
no ip unreachables
ip pim sparse-mode
logging event link-status
!
interface FastEthernet5/1
description flashnet
ip address 10.194.17.108 255.255.255.0
duplex full
!
interface FastEthernet5/2
no ip address
shutdown
!
interface FastEthernet5/3
no ip address
shutdown
!
interface FastEthernet5/4
no ip address
shutdown
!
interface FastEthernet5/5
no ip address
shutdown
!
interface FastEthernet5/6
no ip address
shutdown
!
interface FastEthernet5/7
no ip address
shutdown
!
interface FastEthernet5/8
no ip address
shutdown
Cisco IOS Release 12.1(13)E13
168
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface FastEthernet5/9
no ip address
shutdown
!
interface FastEthernet5/10
no ip address
shutdown
!
interface FastEthernet5/11
no ip address
shutdown
!
interface FastEthernet5/12
no ip address
shutdown
!
interface FastEthernet5/13
no ip address
shutdown
!
interface FastEthernet5/14
no ip address
shutdown
!
interface FastEthernet5/15
no ip address
shutdown
!
interface FastEthernet5/16
no ip address
shutdown
!
interface FastEthernet5/17
no ip address
shutdown
!
interface FastEthernet5/18
no ip address
shutdown
!
interface FastEthernet5/19
no ip address
shutdown
!
interface FastEthernet5/20
no ip address
shutdown
!
interface FastEthernet5/21
no ip address
shutdown
!
interface FastEthernet5/22
no ip address
shutdown
!
interface FastEthernet5/23
no ip address
shutdown
!
interface FastEthernet5/24
no ip address
shutdown
Cisco IOS Release 12.1(13)E13
169
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface FastEthernet9/1
no ip address
!
interface FastEthernet9/2
no ip address
!
interface FastEthernet9/3
no ip address
shutdown
!
interface FastEthernet9/4
no ip address
shutdown
!
interface FastEthernet9/5
no ip address
shutdown
!
interface FastEthernet9/6
no ip address
shutdown
!
interface FastEthernet9/7
no ip address
shutdown
!
interface FastEthernet9/8
no ip address
shutdown
!
interface FastEthernet9/9
no ip address
shutdown
!
interface FastEthernet9/10
no ip address
shutdown
!
interface FastEthernet9/11
no ip address
shutdown
!
interface FastEthernet9/12
no ip address
shutdown
!
interface FastEthernet9/13
no ip address
shutdown
!
interface FastEthernet9/14
no ip address
shutdown
!
interface FastEthernet9/15
no ip address
shutdown
!
interface FastEthernet9/16
no ip address
shutdown
!
interface FastEthernet9/17
Cisco IOS Release 12.1(13)E13
170
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet9/18
no ip address
shutdown
!
interface FastEthernet9/19
no ip address
shutdown
!
interface FastEthernet9/20
no ip address
shutdown
!
interface FastEthernet9/21
no ip address
shutdown
!
interface FastEthernet9/22
no ip address
shutdown
!
interface FastEthernet9/23
no ip address
shutdown
!
interface FastEthernet9/24
no ip address
shutdown
!
interface FastEthernet9/25
no ip address
shutdown
!
interface FastEthernet9/26
no ip address
shutdown
!
interface FastEthernet9/27
no ip address
shutdown
!
interface FastEthernet9/28
no ip address
shutdown
!
interface FastEthernet9/29
no ip address
shutdown
!
interface FastEthernet9/30
no ip address
shutdown
!
interface FastEthernet9/31
no ip address
shutdown
!
interface FastEthernet9/32
no ip address
shutdown
!
interface FastEthernet9/33
Cisco IOS Release 12.1(13)E13
171
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet9/34
no ip address
shutdown
!
interface FastEthernet9/35
no ip address
shutdown
!
interface FastEthernet9/36
no ip address
shutdown
!
interface FastEthernet9/37
no ip address
shutdown
!
interface FastEthernet9/38
no ip address
shutdown
!
interface FastEthernet9/39
no ip address
shutdown
!
interface FastEthernet9/40
no ip address
shutdown
!
interface FastEthernet9/41
no ip address
shutdown
!
interface FastEthernet9/42
no ip address
shutdown
!
interface FastEthernet9/43
no ip address
shutdown
!
interface FastEthernet9/44
no ip address
shutdown
!
interface FastEthernet9/45
no ip address
shutdown
!
interface FastEthernet9/46
no ip address
shutdown
!
interface FastEthernet9/47
no ip address
shutdown
!
interface FastEthernet9/48
no ip address
shutdown
!
interface Vlan1
Cisco IOS Release 12.1(13)E13
172
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
!
interface Vlan10
ip address 172.31.10.69 255.255.255.0
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 1 ip 172.31.10.1
standby 1 priority 90
standby 1 preempt
standby 2 ip 172.31.10.254
standby 2 priority 110
standby 2 preempt
!
interface Vlan11
ip address 172.31.11.69 255.255.255.0
ip helper-address 172.31.16.82
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 2 ip 172.31.11.1
standby 2 priority 90
standby 2 preempt
standby 3 ip 172.31.11.254
standby 3 priority 110
standby 3 preempt
!
interface Vlan12
ip address 172.31.12.69 255.255.255.0
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 3 ip 172.31.12.1
standby 3 priority 90
standby 3 preempt
standby 4 ip 172.31.12.254
standby 4 priority 110
standby 4 preempt
!
interface Vlan13
ip address 172.31.13.69 255.255.255.0
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 4 ip 172.31.13.1
standby 4 priority 90
standby 4 preempt
standby 5 ip 172.31.13.254
standby 5 priority 110
standby 5 preempt
!
interface Vlan14
ip address 172.31.14.69 255.255.255.0
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 5 ip 172.31.14.1
standby 5 priority 90
standby 5 preempt
standby 6 ip 172.31.14.254
standby 6 priority 110
standby 6 preempt
!
interface Vlan15
Cisco IOS Release 12.1(13)E13
173
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
description this in has 2ndary ip 172.31.150.69
ip address 172.31.150.69 255.255.255.0 secondary
ip address 172.31.15.69 255.255.255.0
no ip redirects
no ip unreachables
ip pim query-interval 3
ip pim sparse-mode
standby 6 ip 172.31.15.1
standby 6 priority 90
standby 6 preempt
standby 7 ip 172.31.15.254
standby 7 priority 110
standby 7 preempt
!
interface Vlan16
description this in has 2ndary ip 172.31.160.69
ip address 172.31.160.69 255.255.255.0 secondary
ip address 172.31.16.69 255.255.255.0
no ip redirects
no ip unreachables
ip pim query-interval 3
ip pim sparse-mode
standby 7 ip 172.31.16.1
standby 7 priority 90
standby 7 preempt
standby 8 ip 172.31.16.254
standby 8 priority 110
standby 8 preempt
!
interface Vlan17
ip address 172.31.17.69 255.255.255.0
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 8 ip 172.31.17.1
standby 8 priority 90
standby 8 preempt
standby 9 ip 172.31.17.254
standby 9 priority 110
standby 9 preempt
!
interface Vlan18
ip address 172.31.18.69 255.255.255.0
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 9 ip 172.31.18.1
standby 9 priority 90
standby 9 preempt
standby 10 ip 172.31.18.254
standby 10 priority 110
standby 10 preempt
!
interface Vlan19
ip address 172.31.19.69 255.255.255.0
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 10 ip 172.31.19.1
standby 10 priority 90
standby 10 preempt
standby 11 ip 172.31.19.254
standby 11 priority 110
standby 11 preempt
Cisco IOS Release 12.1(13)E13
174
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface Vlan20
ip address 172.31.9.69 255.255.255.0
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 11 ip 172.31.9.1
standby 11 priority 90
standby 11 preempt
standby 12 ip 172.31.9.254
standby 12 priority 110
standby 12 preempt
!
router ospf 1
log-adjacency-changes
auto-cost reference-bandwidth 100000
passive-interface default
no passive-interface Vlan10
no passive-interface GigabitEthernet3/8
no passive-interface GigabitEthernet4/8
no passive-interface Port-channel1
no passive-interface Port-channel69
no passive-interface Port-channel169
network 172.31.0.0 0.0.0.255 area 1
network 172.31.1.76 0.0.0.3 area 1
network 172.31.1.104 0.0.0.3 area 1
network 172.31.1.116 0.0.0.3 area 1
network 172.31.2.52 0.0.0.3 area 1
network 172.31.4.0 0.0.0.255 area 1
network 172.31.8.0 0.0.7.255 area 1
network 172.31.16.0 0.0.3.255 area 1
network 172.31.32.0 0.0.0.255 area 1
network 172.31.50.0 0.0.0.255 area 1
network 172.31.208.0 0.0.0.7 area 1
!
ip classless
ip route 172.18.177.128 255.255.255.192 10.194.17.254
ip route 172.18.179.128 255.255.255.192 10.194.17.254
no ip http server
ip pim rp-address 172.31.0.104 1 override
ip pim rp-address 172.31.0.98 2 override
ip pim spt-threshold infinity
!
!
logging trap debugging
access-list 1 permit 239.255.0.0 0.0.255.255
access-list 1 deny
any
access-list 2 permit 224.0.1.39
access-list 2 permit 224.0.1.40
access-list 102 permit ip host 172.31.21.101 host 239.255.127.100
access-list 102 deny
ip any any
access-list 120 permit ip host 172.31.21.101 host 239.255.127.100
access-list 181 permit ip any any
access-list 182 permit ip any any
snmp-server community public RO
snmp-server community cisco RW
snmp-server enable traps config
snmp-server host 172.18.177.135 public
snmp-server host 172.31.1.105 public
!
tacacs-server host 172.18.177.132
alias exec ip sh ip int brief | be Port
alias exec eigrp show run | be router eigrp
alias exec mr sh ip mr 239.255.127.100
Cisco IOS Release 12.1(13)E13
175
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
alias exec ospf sh run | be router ospf
!
line con 0
exec-timeout 0 0
line vty 0 4
exec-timeout 0 0
login authentication sh1-testcase
history size 256
transport input lat pad mop telnet rlogin udptn nasi ssh
line vty 5 10
exec-timeout 0 0
login authentication sh1-testcase
history size 256
transport input lat pad mop telnet rlogin udptn nasi ssh
!
exception protocol ftp
exception dump 172.18.177.132
exception memory fragment 200000
exception memory minimum 200000
scheduler runtime netinput 300
ntp clock-period 17180155
ntp update-calendar
ntp server 172.18.177.131
ntp server 172.18.177.132 prefer
end
SH1-108#show version
Cisco Internetwork Operating System Software
IOS (tm) c6sup2_rp Software (c6sup2_rp-JK2SV-M), Version 12.1(nightly13e.E040315) NIGHTLY
BUILD, synced to cosmos_e V121_12_5_E1
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Mon 15-Mar-04 22:18 by
Image text-base: 0x40008BF0, data-base: 0x41BF2000
ROM: System Bootstrap, Version 12.1(4r)E, RELEASE SOFTWARE (fc1)
SH1-108 uptime is 1 day, 18 hours, 32 minutes
Time since SH1-108 switched to active is 1 day, 18 hours, 32 minutes
System returned to ROM by power-on (SP by reload)
System restarted at 17:44:08 EST Tue Mar 16 2004
System image file is "slot0:c6sup12-jk2sv-mz.v121_13_e_throttle.040315"
cisco Catalyst 6000 (R7000) processor with 112640K/18432K bytes of memory.
Processor board ID SAL0601FY7X
R7000 CPU at 300Mhz, Implementation 39, Rev 3.3, 256KB L2, 1024KB L3 Cache
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
12 Virtual Ethernet/IEEE 802.3 interface(s)
72 FastEthernet/IEEE 802.3 interface(s)
20 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.
16384K bytes of Flash internal SIMM (Sector size 512K).
Standby is up
Standby has 112640K/18432K bytes of memory.
Configuration register is 0x2102
SH1-108#show module
Mod Ports Card Type
Model
Serial No.
--- ----- -------------------------------------- ------------------ -----------
Cisco IOS Release 12.1(13)E13
176
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
1
2
3
4
5
9
2
2
8
8
24
48
Cat 6k sup 1 Enhanced QoS (Active)
Cat 6k sup 1 Enhanced QoS (Standby)
8 port 1000mb GBIC Enhanced QoS
8 port 1000mb GBIC Enhanced QoS
24 port 100FX Multi mode
48-port 10/100 mb RJ45
WS-X6K-SUP1A-2GE
WS-X6K-SUP1A-2GE
WS-X6408A-GBIC
WS-X6408A-GBIC
WS-X6324-100FX-MM
WS-X6148-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0006.d65a.4ce8 to 0006.d65a.4ce9
7.1
5.4(2)
2 0006.d65a.4cdc to 0006.d65a.4cdd
7.1
5.4(2)
3 0005.7408.6410 to 0005.7408.6417
2.0
5.4(2)
4 0005.7408.6440 to 0005.7408.6447
2.0
5.4(2)
5 0008.a430.09f0 to 0008.a430.0a07
3.0
5.4(2)
9 000b.4603.b020 to 000b.4603.b04f
1.1
5.4(2)
Mod Sub-Module
--- --------------------------1 Policy Feature Card
1 Cat6k MSFC 2 daughterboard
2 Policy Feature Card
2 Cat6k MSFC 2 daughterboard
SH1-108#
Model
--------------WS-F6K-PFC
WS-F6K-MSFC2
WS-F6K-PFC
WS-F6K-MSFC2
SAL0550FAST
SAL0601G2HF
SAL0545E7GH
SAL0545E7FJ
SAD055106Z9
SAL064071XV
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAL0601FXM6
2.0
Ok
SAL0601FY7X
2.0
Ok
SAL0601FXMN
2.0
Ok
SAL0601FYB9
2.0
Ok
Return to SH1-108, page 164
SH1-109
Go to Test Device Configurations, page 17
Go to Financial Lab Topology, page 2
Go to Test Cases, page 249
SH1-109#show config
Using 20026 out of 391160 bytes
!
!
version 12.1
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
no service password-encryption
service internal
!
hostname SH1-109
!
boot system flash sup-bootflash:
boot bootldr bootflash:
no logging console
enable secret 5 $1$hXKk$4xXFEz6GkYsxdM5MlahSW1
!
clock timezone EST -5
clock summer-time EDT recurring
vtp domain FIN
vtp mode transparent
udld enable
udld message time 7
ip subnet-zero
!
!
ip ftp username safeharbor
Cisco IOS Release 12.1(13)E13
177
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip ftp password shshsh
no ip domain-lookup
!
ip multicast-routing
ip multicast cache-headers
mls flow ip destination-source
mls flow ipx destination
mls ip multicast consistency-check
errdisable recovery cause bpduguard
errdisable recovery cause channel-misconfig
errdisable recovery cause pagp-flap
errdisable recovery cause dtp-flap
errdisable recovery cause link-flap
errdisable recovery interval 30
!
redundancy
mode rpr-plus
main-cpu
auto-sync startup-config
auto-sync running-config
auto-sync config-register
auto-sync bootvar
auto-sync standard
!
power redundancy-mode combined
!
!
vlan 2-8,10-20,81-83,100,150,190,254,501,1000
!
vlan 1004
bridge 1
!
vlan 1005
bridge 1
!
!
interface Loopback0
ip address 172.31.4.109 255.255.255.255
ip pim sparse-mode
!
interface Port-channel1
ip address 172.31.1.201 255.255.255.252
ip pim sparse-mode
logging event link-status
!
interface Port-channel2
description SH1-110
no ip address
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1-9,21-4094
switchport mode trunk
!
interface Port-channel20
description dista-2 PoCha
no ip address
switchport
switchport trunk encapsulation dot1q
!
interface Port-channel70
description sh1-103 po70
ip address 172.31.1.82 255.255.255.252
ip access-group 181 in
ip access-group 181 out
Cisco IOS Release 12.1(13)E13
178
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip pim sparse-mode
logging event link-status
!
interface Port-channel170
description sh1-104 po70
ip address 172.31.1.110 255.255.255.252
ip pim sparse-mode
logging event link-status
!
interface Port-channel171
no ip address
!
interface Port-channel190
description dista-2
no ip address
switchport
switchport access vlan 190
switchport mode access
!
interface GigabitEthernet1/1
no ip address
shutdown
!
interface GigabitEthernet1/2
no ip address
shutdown
!
interface GigabitEthernet2/1
no ip address
switchport
switchport access vlan 82
!
interface GigabitEthernet2/2
no ip address
switchport
switchport access vlan 83
!
interface GigabitEthernet3/1
description sh1-103 g7/15
no ip address
logging event link-status
speed nonegotiate
channel-group 70 mode on
!
interface GigabitEthernet3/2
description dista-2 2/1
no ip address
switchport
switchport access vlan 190
switchport mode access
channel-group 190 mode desirable
!
interface GigabitEthernet3/3
no ip address
shutdown
!
interface GigabitEthernet3/4
no ip address
shutdown
!
interface GigabitEthernet3/5
description sh1-104 g4/15
no ip address
speed nonegotiate
Cisco IOS Release 12.1(13)E13
179
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
channel-group 170 mode on
!
interface GigabitEthernet3/6
description sh1-104 g4/16
no ip address
speed nonegotiate
channel-group 170 mode on
!
interface GigabitEthernet3/7
no ip address
channel-group 1 mode on
!
interface GigabitEthernet3/8
no ip address
shutdown
!
interface GigabitEthernet3/9
ip address 10.194.17.109 255.255.255.0
shutdown
!
interface GigabitEthernet3/10
no ip address
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet3/11
description SH1-110 via Po2
no ip address
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1-9,21-4094
switchport mode trunk
channel-group 2 mode desirable
!
interface GigabitEthernet3/12
no ip address
!
interface GigabitEthernet3/13
no ip address
shutdown
!
interface GigabitEthernet3/14
no ip address
shutdown
!
interface GigabitEthernet3/15
no ip address
shutdown
!
interface GigabitEthernet3/16
description Ix-9/1
ip address 172.31.249.1 255.255.255.252
ip access-group 181 in
ip access-group 181 out
no ip unreachables
ip pim sparse-mode
load-interval 30
!
interface GigabitEthernet4/1
description sh1-103 g7/16
no ip address
speed nonegotiate
channel-group 70 mode on
Cisco IOS Release 12.1(13)E13
180
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface GigabitEthernet4/2
description dista-2 2/2
no ip address
switchport
switchport access vlan 190
switchport mode access
channel-group 190 mode desirable
!
interface GigabitEthernet4/3
no ip address
shutdown
!
interface GigabitEthernet4/4
no ip address
shutdown
!
interface GigabitEthernet4/5
description sh1-104 g8/15
no ip address
speed nonegotiate
channel-group 170 mode on
!
interface GigabitEthernet4/6
description sh1-104 g8/16
no ip address
speed nonegotiate
channel-group 170 mode on
!
interface GigabitEthernet4/7
no ip address
channel-group 1 mode on
!
interface GigabitEthernet4/8
no ip address
shutdown
!
interface GigabitEthernet4/9
no ip address
shutdown
!
interface GigabitEthernet4/10
no ip address
shutdown
!
interface GigabitEthernet4/11
no ip address
shutdown
!
interface GigabitEthernet4/12
no ip address
shutdown
!
interface GigabitEthernet4/13
no ip address
shutdown
!
interface GigabitEthernet4/14
no ip address
shutdown
!
interface GigabitEthernet4/15
no ip address
shutdown
Cisco IOS Release 12.1(13)E13
181
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface GigabitEthernet4/16
no ip address
!
interface GigabitEthernet7/1
description sh1-103 g8/15
no ip address
speed nonegotiate
channel-group 70 mode on
!
interface GigabitEthernet7/2
no ip address
shutdown
!
interface GigabitEthernet7/3
description dista-2 1/1
no ip address
logging event link-status
speed nonegotiate
switchport
switchport trunk encapsulation dot1q
channel-group 20 mode on
!
interface GigabitEthernet7/4
no ip address
shutdown
!
interface GigabitEthernet7/5
no ip address
shutdown
!
interface GigabitEthernet7/6
no ip address
shutdown
!
interface GigabitEthernet7/7
no ip address
logging event link-status
speed nonegotiate
switchport
switchport trunk encapsulation dot1q
channel-group 20 mode on
!
interface GigabitEthernet7/8
no ip address
shutdown
!
interface GigabitEthernet7/9
no ip address
shutdown
!
interface GigabitEthernet7/10
no ip address
shutdown
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet7/11
no ip address
shutdown
!
interface GigabitEthernet7/12
no ip address
Cisco IOS Release 12.1(13)E13
182
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface GigabitEthernet7/13
no ip address
shutdown
!
interface GigabitEthernet7/14
no ip address
shutdown
!
interface GigabitEthernet7/15
no ip address
shutdown
!
interface GigabitEthernet7/16
description Ix-9/2
ip address 172.31.35.70 255.255.255.0
ip access-group 181 in
ip access-group 181 out
no ip unreachables
ip pim sparse-mode
load-interval 30
!
interface GigabitEthernet8/1
description sh1-103 g8/16
no ip address
speed nonegotiate
channel-group 70 mode on
!
interface GigabitEthernet8/2
no ip address
logging event link-status
shutdown
speed nonegotiate
!
interface GigabitEthernet8/3
description dista-2 4/2
no ip address
logging event link-status
speed nonegotiate
switchport
switchport trunk encapsulation dot1q
!
interface GigabitEthernet8/4
no ip address
shutdown
!
interface GigabitEthernet8/5
no ip address
shutdown
!
interface GigabitEthernet8/6
no ip address
shutdown
!
interface GigabitEthernet8/7
no ip address
logging event link-status
shutdown
speed nonegotiate
!
interface GigabitEthernet8/8
no ip address
shutdown
Cisco IOS Release 12.1(13)E13
183
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
switchport
switchport trunk encapsulation dot1q
!
interface GigabitEthernet8/9
no ip address
shutdown
switchport
switchport trunk encapsulation
!
interface GigabitEthernet8/10
no ip address
shutdown
switchport
switchport trunk encapsulation
!
interface GigabitEthernet8/11
no ip address
shutdown
switchport
switchport trunk encapsulation
!
interface GigabitEthernet8/12
no ip address
shutdown
switchport
switchport trunk encapsulation
!
interface GigabitEthernet8/13
no ip address
shutdown
!
interface GigabitEthernet8/14
no ip address
shutdown
!
interface GigabitEthernet8/15
no ip address
shutdown
!
interface GigabitEthernet8/16
no ip address
!
interface FastEthernet9/1
no ip address
speed 100
duplex full
!
interface FastEthernet9/2
no ip address
shutdown
!
interface FastEthernet9/3
no ip address
shutdown
!
interface FastEthernet9/4
no ip address
shutdown
!
interface FastEthernet9/5
no ip address
shutdown
!
interface FastEthernet9/6
Cisco IOS Release 12.1(13)E13
184
dot1q
dot1q
dot1q
dot1q
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet9/7
no ip address
shutdown
!
interface FastEthernet9/8
no ip address
shutdown
!
interface FastEthernet9/9
no ip address
shutdown
!
interface FastEthernet9/10
no ip address
shutdown
!
interface FastEthernet9/11
no ip address
shutdown
!
interface FastEthernet9/12
no ip address
shutdown
!
interface FastEthernet9/13
no ip address
shutdown
!
interface FastEthernet9/14
no ip address
shutdown
!
interface FastEthernet9/15
no ip address
shutdown
!
interface FastEthernet9/16
no ip address
shutdown
!
interface FastEthernet9/17
no ip address
shutdown
!
interface FastEthernet9/18
no ip address
shutdown
!
interface FastEthernet9/19
no ip address
shutdown
!
interface FastEthernet9/20
no ip address
shutdown
!
interface FastEthernet9/21
no ip address
shutdown
!
interface FastEthernet9/22
Cisco IOS Release 12.1(13)E13
185
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet9/23
no ip address
shutdown
!
interface FastEthernet9/24
description flashnet
ip address 10.194.17.109 255.255.255.0
speed 100
duplex full
!
interface FastEthernet9/25
no ip address
!
interface FastEthernet9/26
no ip address
shutdown
!
interface FastEthernet9/27
no ip address
!
interface FastEthernet9/28
no ip address
!
interface FastEthernet9/29
no ip address
shutdown
!
interface FastEthernet9/30
no ip address
!
interface FastEthernet9/31
no ip address
shutdown
!
interface FastEthernet9/32
no ip address
shutdown
!
interface FastEthernet9/33
no ip address
shutdown
!
interface FastEthernet9/34
no ip address
shutdown
!
interface FastEthernet9/35
no ip address
shutdown
!
interface FastEthernet9/36
no ip address
shutdown
!
interface FastEthernet9/37
no ip address
shutdown
!
interface FastEthernet9/38
no ip address
shutdown
Cisco IOS Release 12.1(13)E13
186
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface FastEthernet9/39
no ip address
shutdown
!
interface FastEthernet9/40
no ip address
shutdown
!
interface FastEthernet9/41
no ip address
shutdown
!
interface FastEthernet9/42
no ip address
shutdown
!
interface FastEthernet9/43
no ip address
shutdown
!
interface FastEthernet9/44
no ip address
shutdown
!
interface FastEthernet9/45
no ip address
shutdown
!
interface FastEthernet9/46
no ip address
shutdown
!
interface FastEthernet9/47
no ip address
shutdown
!
interface FastEthernet9/48
no ip address
shutdown
!
interface Vlan1
no ip address
!
interface Vlan5
ip address 5.5.5.5 255.255.255.0
!
interface Vlan10
ip address 172.31.20.70 255.255.255.0
ip access-group 135 in
ip helper-address 172.31.4.98
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 1 ip 172.31.20.1
standby 1 priority 110
standby 1 preempt
standby 2 ip 172.31.20.254
standby 2 priority 90
standby 2 preempt
!
interface Vlan11
ip address 172.31.21.70 255.255.255.0
ip access-group 136 in
Cisco IOS Release 12.1(13)E13
187
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 2 ip 172.31.21.1
standby 2 priority 110
standby 2 preempt
standby 3 ip 172.31.21.254
standby 3 priority 90
standby 3 preempt
!
interface Vlan12
ip address 172.31.22.70 255.255.255.0
ip access-group 137 in
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 3 ip 172.31.22.1
standby 3 priority 110
standby 3 preempt
standby 4 ip 172.31.22.254
standby 4 priority 90
standby 4 preempt
!
interface Vlan13
ip address 172.31.23.70 255.255.255.0
ip access-group 138 in
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 4 ip 172.31.23.1
standby 4 priority 110
standby 4 preempt
standby 5 ip 172.31.23.254
standby 5 priority 90
standby 5 preempt
!
interface Vlan14
ip address 172.31.24.70 255.255.255.0
ip access-group 139 in
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 5 ip 172.31.24.1
standby 5 priority 110
standby 5 preempt
standby 6 ip 172.31.24.254
standby 6 priority 90
standby 6 preempt
!
interface Vlan15
ip address 172.31.25.70 255.255.255.0
ip access-group 140 in
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 6 ip 172.31.25.1
standby 6 priority 110
standby 6 preempt
standby 7 ip 172.31.25.254
standby 7 priority 90
standby 7 preempt
!
interface Vlan16
ip address 172.31.26.70 255.255.255.0
Cisco IOS Release 12.1(13)E13
188
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip access-group 141 in
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 7 ip 172.31.26.1
standby 7 priority 110
standby 7 preempt
standby 8 ip 172.31.26.254
standby 8 priority 90
standby 8 preempt
!
interface Vlan17
ip address 172.31.27.70 255.255.255.0
ip access-group 142 in
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 8 ip 172.31.27.1
standby 8 priority 110
standby 8 preempt
standby 9 ip 172.31.27.254
standby 9 priority 90
standby 9 preempt
!
interface Vlan18
ip address 172.31.28.70 255.255.255.0
ip access-group 143 in
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 9 ip 172.31.28.1
standby 9 priority 110
standby 9 preempt
standby 10 ip 172.31.28.254
standby 10 priority 90
standby 10 preempt
!
interface Vlan19
ip address 172.31.29.70 255.255.255.0
ip access-group 144 in
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 10 ip 172.31.29.1
standby 10 priority 110
standby 10 preempt
standby 11 ip 172.31.29.254
standby 11 priority 90
standby 11 preempt
!
interface Vlan20
ip address 172.31.30.70 255.255.255.0
ip access-group 145 in
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 11 ip 172.31.30.1
standby 11 priority 110
standby 11 preempt
standby 12 ip 172.31.30.254
standby 12 priority 90
standby 12 preempt
!
interface Vlan190
Cisco IOS Release 12.1(13)E13
189
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip address 172.31.190.70 255.255.255.0
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 12 ip 172.31.190.1
standby 12 priority 110
standby 12 preempt
standby 13 ip 172.31.190.254
standby 13 priority 90
standby 13 preempt
!
interface Vlan501
ip address 172.31.51.2 255.255.255.0
no ip redirects
shutdown
standby ip 172.31.51.3
standby priority 90
standby preempt
!
router ospf 1
log-adjacency-changes
auto-cost reference-bandwidth 100000
passive-interface default
no passive-interface Vlan10
no passive-interface GigabitEthernet3/16
no passive-interface GigabitEthernet7/16
no passive-interface GigabitEthernet8/5
no passive-interface Port-channel1
no passive-interface Port-channel70
no passive-interface Port-channel170
network 172.31.0.0 0.0.0.255 area 1
network 172.31.1.80 0.0.0.3 area 1
network 172.31.1.108 0.0.0.3 area 1
network 172.31.1.140 0.0.0.3 area 1
network 172.31.1.200 0.0.0.3 area 1
network 172.31.2.56 0.0.0.3 area 1
network 172.31.4.0 0.0.0.255 area 1
network 172.31.20.0 0.0.3.255 area 1
network 172.31.24.0 0.0.7.255 area 1
network 172.31.35.0 0.0.0.255 area 1
network 172.31.51.0 0.0.0.255 area 1
network 172.31.249.0 0.0.0.3 area 1
maximum-paths 6
!
ip classless
ip route profile
ip route 0.0.0.0 0.0.0.0 172.31.4.99
ip route 172.18.177.128 255.255.255.192 10.194.17.254
ip route 172.18.179.128 255.255.255.192 10.194.17.254
no ip http server
ip pim rp-address 172.31.0.104 1 override
ip pim rp-address 172.31.0.98 2 override
ip pim spt-threshold infinity
!
!
logging trap debugging
logging 172.18.112.184
logging 172.18.177.132
access-list 1 permit 239.255.0.0 0.0.255.255
access-list 1 deny
any
access-list 2 permit 224.0.1.39
access-list 2 permit 224.0.1.40
access-list 100 remark Temp_ACL for non-RPF traffic
access-list 100 permit ip any host 224.0.0.13
Cisco IOS Release 12.1(13)E13
190
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
access-list
100
100
100
100
100
100
100
100
100
101
135
135
135
135
135
136
136
136
136
136
137
137
137
137
137
138
138
138
138
138
139
139
139
139
139
140
140
140
140
140
141
141
141
141
141
142
142
142
142
142
143
143
143
143
143
144
144
144
144
144
145
145
145
145
permit
permit
permit
permit
permit
permit
permit
deny
permit
permit
permit
permit
permit
deny
permit
permit
permit
permit
deny
permit
permit
permit
permit
deny
permit
permit
permit
permit
deny
permit
permit
permit
permit
deny
permit
permit
permit
permit
deny
permit
permit
permit
permit
deny
permit
permit
permit
permit
deny
permit
permit
permit
permit
deny
permit
permit
permit
permit
deny
permit
permit
permit
permit
deny
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
ip
any host 224.0.0.13 log
172.31.20.0 0.0.0.255 224.0.0.0
172.31.21.0 0.0.0.255 224.0.0.0
172.31.25.0 0.0.0.255 224.0.0.0
172.31.26.0 0.0.0.255 224.0.0.0
any 224.0.0.0 0.0.0.255
any 224.0.1.0 0.0.0.255
any 224.0.0.0 15.255.255.255
any any
any any
172.31.20.0 0.0.0.255 any
any 224.0.0.0 0.0.0.255
any 224.0.1.0 0.0.0.255
any 224.0.0.0 15.255.255.255
any any
172.31.21.0 0.0.0.255 any
any 224.0.0.0 0.0.0.255
any 224.0.1.0 0.0.0.255
any 224.0.0.0 15.255.255.255
any any
172.31.22.0 0.0.0.255 any
any 224.0.0.0 0.0.0.255
any 224.0.1.0 0.0.0.255
any 224.0.0.0 15.255.255.255
any any
172.31.23.0 0.0.0.255 any
any 224.0.0.0 0.0.0.255
any 224.0.1.0 0.0.0.255
any 224.0.0.0 15.255.255.255
any any
172.31.24.0 0.0.0.255 any
any 224.0.0.0 0.0.0.255
any 224.0.1.0 0.0.0.255
any 224.0.0.0 15.255.255.255
any any
172.31.25.0 0.0.0.255 any
any 224.0.0.0 0.0.0.255
any 224.0.1.0 0.0.0.255
any 224.0.0.0 15.255.255.255
any any
172.31.26.0 0.0.0.255 any
any 224.0.0.0 0.0.0.255
any 224.0.1.0 0.0.0.255
any 224.0.0.0 15.255.255.255
any any
172.31.27.0 0.0.0.255 any
any 224.0.0.0 0.0.0.255
any 224.0.1.0 0.0.0.255
any 224.0.0.0 15.255.255.255
any any
172.31.28.0 0.0.0.255 any
any 224.0.0.0 0.0.0.255
any 224.0.1.0 0.0.0.255
any 224.0.0.0 15.255.255.255
any any
172.31.29.0 0.0.0.255 any
any 224.0.0.0 0.0.0.255
any 224.0.1.0 0.0.0.255
any 224.0.0.0 15.255.255.255
any any
172.31.30.0 0.0.0.255 any
any 224.0.0.0 0.0.0.255
any 224.0.1.0 0.0.0.255
any 224.0.0.0 15.255.255.255
15.255.255.255
15.255.255.255
15.255.255.255
15.255.255.255
Cisco IOS Release 12.1(13)E13
191
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
access-list 145 permit ip any any
access-list 181 permit ip any any
snmp-server community public RO
snmp-server community cisco RW
!
alias exec ip sh ip int brief | be Port
alias exec eigrp show run | be router eigrp
alias exec mr sh ip mroute 239.255.127.100
alias exec ospf sh run | be router ospf
!
line con 0
exec-timeout 0 0
line vty 0 4
exec-timeout 0 0
password cisco
login
length 0
history size 256
transport input lat pad mop telnet rlogin udptn nasi
line vty 5 10
exec-timeout 0 0
password cisco
login
length 0
history size 256
transport input lat pad mop telnet rlogin udptn nasi
!
exception protocol ftp
exception dump 172.18.177.129
exception memory fragment 200000
exception memory minimum 200000
scheduler runtime netinput 300
ntp clock-period 17180103
ntp update-calendar
ntp server 172.18.177.132
end
SH1-109#show version
Cisco Internetwork Operating System Software
IOS (tm) c6sup2_rp Software (c6sup2_rp-JSV-M), Version 12.1(nightly13e.E040229) NIGHTLY
BUILD, synced to cosmos_e V121_12_5_E1
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Mon 01-Mar-04 00:11 by
Image text-base: 0x40008BF0, data-base: 0x41A4C000
ROM: System Bootstrap, Version 12.1(4r)E, RELEASE SOFTWARE (fc1)
SH1-109 uptime is 6 days, 19 hours, 49 minutes
Time since SH1-109 switched to active is 6 days, 19 hours, 49 minutes
System returned to ROM by power-on (SP by power-on)
System restarted at 15:54:35 EST Thu Mar 11 2004
System image file is "sup-bootflash:c6sup22-jsv-mz.v121_13_e_throttle.040229"
cisco Catalyst 6000 (R7000) processor with 458752K/65536K bytes of memory.
Processor board ID SAD055205U3
R7000 CPU at 300Mhz, Implementation 39, Rev 2.1, 256KB L2, 1024KB L3 Cache
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
15 Virtual Ethernet/IEEE 802.3 interface(s)
48 FastEthernet/IEEE 802.3 interface(s)
68 Gigabit Ethernet/IEEE 802.3 interface(s)
Cisco IOS Release 12.1(13)E13
192
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
381K bytes of non-volatile configuration memory.
16384K bytes of Flash internal SIMM (Sector size 512K).
Standby is up
Standby has 227328K/34816K bytes of memory.
Configuration register is 0x2102
SH1-109#show module
Mod Ports Card Type
--- ----- -------------------------------------1
2 Catalyst 6000 supervisor 2 (Active)
2
2 Catalyst 6000 supervisor 2 (Standby)
3
16 Pure SFM-mode 16 port 1000mb GBIC
4
16 Pure SFM-mode 16 port 1000mb GBIC
5
0 Switching Fabric Module-136 (Standby)
6
0 Switching Fabric Module-128 (Active)
7
16 SFM-capable 16 port 1000mb GBIC
8
16 Pure SFM-mode 16 port 1000mb GBIC
9
48 SFM-capable 48-port 10/100 Mbps RJ45
Model
-----------------WS-X6K-S2U-MSFC2
WS-X6K-S2U-MSFC2
WS-X6816-GBIC
WS-X6816-GBIC
WS-X6500-SFM2
WS-C6500-SFM
WS-X6516-GBIC
WS-X6816-GBIC
WS-X6548-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.6415.b3a6 to 0001.6415.b3a7
3.2
6.1(3)
2 0001.c9da.e268 to 0001.c9da.e269
3.2
6.1(3)
3 0002.7ee1.41b8 to 0002.7ee1.41c7
1.2
12.1(5r)E1
4 000d.ed23.8ff8 to 000d.ed23.9007
1.7
12.1(11r)E2
5 0001.0002.0003 to 0001.0002.0003
1.1
6.1(3)
6 0001.0002.0003 to 0001.0002.0003
1.3
6.1(3)
7 0001.63d4.21c2 to 0001.63d4.21d1
4.0
6.1(3)
8 0002.7ee1.4f70 to 0002.7ee1.4f7f
1.2
12.1(5r)E1
9 0009.11f6.4930 to 0009.11f6.495f
5.2
6.3(1)
Mod
--1
1
2
2
3
4
8
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Distributed Forwarding Card
Distributed Forwarding Card
Distributed Forwarding Card
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-DFC
WS-F6K-DFC
WS-F6K-DFC
Serial No.
----------SAD0551063X
SAD060100BR
SAD055101NY
SAL0741N098
SAD0550031L
SAL06111029
SAD055204WV
SAD055101M1
SAL0710A4V0
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
12.1(nightly
12.1(nightly
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
12.1(nightly
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD055205DB
3.0
Ok
SAD055205U3
1.3
Ok
SAD0552053U
3.0
Ok
SAD055205TB
1.3
Ok
SAD054904SP
2.0
Ok
SAL0744P0BL
2.5
Ok
SAD060100G8
2.0
Ok
Mod Online Diag Status
--- ------------------1 Pass
2 Pass
3 Pass
4 Pass
5 Pass
6 Pass
7 Pass
8 Pass
9 Pass
SH1-109#
Return to SH1-109, page 177
SH1-110
Go to Test Device Configurations, page 17
Go to Financial Lab Topology, page 2
Cisco IOS Release 12.1(13)E13
193
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Go to Test Cases, page 249
SH1-110#show config
Using 18232 out of 391160 bytes
!
!
version 12.1
no service slave-log
service timestamps debug uptime
service timestamps log datetime msec localtime
no service password-encryption
service internal
!
hostname SH1-110
!
boot system flash sup-bootflash:
boot bootldr bootflash:
no logging console
aaa new-model
aaa authentication login default enable
aaa authentication login sh1-testcase group tacacs+ enable
enable secret 5 $1$WlAL$Tb0im3WFfGj5wohoInCnn.
!
clock timezone EST -5
clock summer-time EDT recurring
vtp domain FIN
vtp mode transparent
udld aggressive
ip subnet-zero
!
!
ip ftp username vnc
ip ftp password rtpsqelab
no ip domain-lookup
ip domain-name cisco.com
!
ip multicast-routing
ip multicast cache-headers
ip ssh time-out 120
ip ssh authentication-retries 3
mls flow ip destination-source
mls flow ipx destination
mls aclmerge algorithm odm
mls aclmerge odm optimizations
mls ip multicast consistency-check
!
!
errdisable recovery cause udld
errdisable recovery interval 30
!
spanning-tree loopguard default
spanning-tree vlan 190 priority 8192
!
redundancy
mode rpr-plus
main-cpu
auto-sync running-config
auto-sync bootvar
auto-sync standard
!
power redundancy-mode combined
!
!
Cisco IOS Release 12.1(13)E13
194
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
vlan 2-8,10-20,22,81-83,100,110,120,150,190,254,501,1000
!
vlan 1004
bridge 1
!
vlan 1005
bridge 1
!
!
interface Loopback0
ip address 172.31.4.110 255.255.255.255
ip pim sparse-mode
!
interface Port-channel1
ip address 172.31.1.202 255.255.255.252
ip pim sparse-mode
logging event link-status
!
interface Port-channel2
description SH1-109
no ip address
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1-9,21-4094
switchport mode trunk
!
interface Port-channel20
description dista-2 PoCha
no ip address
switchport
switchport trunk encapsulation dot1q
!
interface Port-channel71
description sh1-103 po71
ip address 172.31.1.86 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel171
description sh1-104 po71
ip address 172.31.1.114 255.255.255.252
ip access-group 181 in
ip access-group 181 out
ip pim sparse-mode
logging event link-status
!
interface Port-channel190
description dista-2
no ip address
switchport
switchport access vlan 190
switchport mode access
!
interface GigabitEthernet1/1
no ip address
shutdown
!
interface GigabitEthernet1/2
no ip address
shutdown
!
interface GigabitEthernet2/1
Cisco IOS Release 12.1(13)E13
195
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface GigabitEthernet2/2
no ip address
shutdown
!
interface GigabitEthernet3/1
description sh1-103 g7/13
no ip address
channel-group 71 mode auto
!
interface GigabitEthernet3/2
description dista-2 2/3
no ip address
switchport
switchport access vlan 190
switchport mode access
channel-group 190 mode desirable
!
interface GigabitEthernet3/3
description sh1-104 g3/13
no ip address
channel-group 171 mode on
!
interface GigabitEthernet3/4
description sh1-104 g3/14
no ip address
channel-group 171 mode on
!
interface GigabitEthernet3/5
description dista-2 3/2
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 20 mode desirable
!
interface GigabitEthernet3/6
description dista-2 3/3
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 20 mode desirable
!
interface GigabitEthernet3/7
no ip address
channel-group 1 mode on
!
interface GigabitEthernet3/8
no ip address
shutdown
!
interface GigabitEthernet3/9
description flashnet
ip address 10.194.17.110 255.255.255.0
!
interface GigabitEthernet3/10
no ip address
shutdown
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet3/11
Cisco IOS Release 12.1(13)E13
196
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 1-9,21-4094
switchport mode trunk
channel-group 2 mode desirable
!
interface GigabitEthernet3/12
no ip address
shutdown
!
interface GigabitEthernet3/13
no ip address
shutdown
!
interface GigabitEthernet3/14
no ip address
shutdown
!
interface GigabitEthernet3/15
no ip address
shutdown
!
interface GigabitEthernet3/16
no ip address
shutdown
!
interface GigabitEthernet4/1
description sh1-103 g7/14
no ip address
channel-group 71 mode auto
!
interface GigabitEthernet4/2
description dista-2 2/4
no ip address
switchport
switchport access vlan 190
switchport mode access
channel-group 190 mode desirable
!
interface GigabitEthernet4/3
description sh1-104 g8/13
no ip address
channel-group 171 mode on
!
interface GigabitEthernet4/4
description sh1-104 g8/14
no ip address
channel-group 171 mode on
!
interface GigabitEthernet4/5
description dista-2 3/4
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 20 mode desirable
!
interface GigabitEthernet4/6
description dista-2 3/5
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 20 mode desirable
!
Cisco IOS Release 12.1(13)E13
197
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface GigabitEthernet4/7
no ip address
channel-group 1 mode on
!
interface GigabitEthernet4/8
no ip address
shutdown
!
interface GigabitEthernet4/9
no ip address
shutdown
!
interface GigabitEthernet4/10
no ip address
shutdown
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
!
interface GigabitEthernet4/11
no ip address
shutdown
!
interface GigabitEthernet4/12
no ip address
shutdown
!
interface GigabitEthernet4/13
no ip address
shutdown
!
interface GigabitEthernet4/14
no ip address
shutdown
!
interface GigabitEthernet4/15
no ip address
shutdown
switchport
switchport access vlan 16
!
interface GigabitEthernet4/16
description Ix-11/1
ip address 172.31.233.71 255.255.255.0 secondary
ip address 172.31.33.71 255.255.255.0
ip access-group 181 in
ip access-group 181 out
no ip redirects
no ip unreachables
ip pim sparse-mode
logging event link-status
load-interval 30
!
interface GigabitEthernet7/1
description sh1-103 g8/13
no ip address
channel-group 71 mode auto
!
interface GigabitEthernet7/2
no ip address
shutdown
!
interface GigabitEthernet7/3
description dista-2 1/2
Cisco IOS Release 12.1(13)E13
198
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
switchport
switchport trunk encapsulation dot1q
!
interface GigabitEthernet7/4
no ip address
shutdown
!
interface GigabitEthernet7/5
description dista-2 4/12
no ip address
shutdown
switchport
switchport trunk encapsulation dot1q
!
interface GigabitEthernet7/6
no ip address
shutdown
!
interface GigabitEthernet7/7
no ip address
shutdown
!
interface GigabitEthernet7/8
description dista-2 3/6
no ip address
shutdown
switchport
switchport trunk encapsulation dot1q
!
interface GigabitEthernet7/9
no ip address
shutdown
!
interface GigabitEthernet7/10
no ip address
shutdown
!
interface GigabitEthernet7/11
no ip address
shutdown
!
interface GigabitEthernet7/12
no ip address
shutdown
!
interface GigabitEthernet7/13
no ip address
shutdown
!
interface GigabitEthernet7/14
no ip address
shutdown
!
interface GigabitEthernet7/15
no ip address
shutdown
!
interface GigabitEthernet7/16
no ip address
shutdown
!
interface GigabitEthernet8/1
Cisco IOS Release 12.1(13)E13
199
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
description sh1-103 g8/14
no ip address
channel-group 71 mode auto
!
interface GigabitEthernet8/2
no ip address
shutdown
!
interface GigabitEthernet8/3
description dista-2 4/3
no ip address
shutdown
switchport
switchport trunk encapsulation dot1q
!
interface GigabitEthernet8/4
no ip address
shutdown
!
interface GigabitEthernet8/5
description dista-2 4/13
no ip address
shutdown
switchport
switchport trunk encapsulation dot1q
!
interface GigabitEthernet8/6
no ip address
shutdown
!
interface GigabitEthernet8/7
no ip address
shutdown
!
interface GigabitEthernet8/8
no ip address
shutdown
!
interface GigabitEthernet8/9
no ip address
shutdown
!
interface GigabitEthernet8/10
no ip address
shutdown
!
interface GigabitEthernet8/11
no ip address
shutdown
!
interface GigabitEthernet8/12
no ip address
shutdown
!
interface GigabitEthernet8/13
no ip address
shutdown
!
interface GigabitEthernet8/14
no ip address
shutdown
!
interface GigabitEthernet8/15
no ip address
Cisco IOS Release 12.1(13)E13
200
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip redirects
no ip unreachables
ip pim sparse-mode
logging event link-status
shutdown
!
interface GigabitEthernet8/16
description Ix-12/2
ip address 172.31.250.1 255.255.255.252
ip access-group 181 in
ip access-group 181 out
no ip unreachables
ip pim sparse-mode
load-interval 30
!
interface FastEthernet9/1
no ip address
!
interface FastEthernet9/2
no ip address
!
interface FastEthernet9/3
no ip address
shutdown
!
interface FastEthernet9/4
no ip address
shutdown
!
interface FastEthernet9/5
no ip address
shutdown
!
interface FastEthernet9/6
no ip address
shutdown
!
interface FastEthernet9/7
no ip address
shutdown
!
interface FastEthernet9/8
no ip address
shutdown
!
interface FastEthernet9/9
no ip address
shutdown
!
interface FastEthernet9/10
no ip address
shutdown
!
interface FastEthernet9/11
no ip address
shutdown
!
interface FastEthernet9/12
no ip address
shutdown
!
interface FastEthernet9/13
description IXIA 10/4
no ip address
Cisco IOS Release 12.1(13)E13
201
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
speed 100
duplex full
switchport
switchport access vlan 190
switchport mode access
!
interface FastEthernet9/14
description IXIA 10/5
no ip address
speed 100
duplex full
switchport
switchport access vlan 20
switchport mode access
!
interface FastEthernet9/15
no ip address
shutdown
!
interface FastEthernet9/16
no ip address
shutdown
!
interface FastEthernet9/17
no ip address
shutdown
!
interface FastEthernet9/18
no ip address
shutdown
!
interface FastEthernet9/19
no ip address
shutdown
!
interface FastEthernet9/20
no ip address
shutdown
!
interface FastEthernet9/21
no ip address
shutdown
!
interface FastEthernet9/22
no ip address
shutdown
!
interface FastEthernet9/23
no ip address
shutdown
!
interface FastEthernet9/24
no ip address
shutdown
!
interface FastEthernet9/25
no ip address
shutdown
!
interface FastEthernet9/26
no ip address
shutdown
!
interface FastEthernet9/27
Cisco IOS Release 12.1(13)E13
202
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet9/28
no ip address
shutdown
!
interface FastEthernet9/29
no ip address
shutdown
!
interface FastEthernet9/30
no ip address
shutdown
!
interface FastEthernet9/31
no ip address
shutdown
!
interface FastEthernet9/32
no ip address
shutdown
!
interface FastEthernet9/33
no ip address
shutdown
!
interface FastEthernet9/34
no ip address
shutdown
!
interface FastEthernet9/35
no ip address
shutdown
!
interface FastEthernet9/36
no ip address
shutdown
!
interface FastEthernet9/37
no ip address
shutdown
!
interface FastEthernet9/38
no ip address
shutdown
!
interface FastEthernet9/39
no ip address
shutdown
!
interface FastEthernet9/40
no ip address
shutdown
!
interface FastEthernet9/41
no ip address
shutdown
!
interface FastEthernet9/42
no ip address
shutdown
!
interface FastEthernet9/43
Cisco IOS Release 12.1(13)E13
203
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet9/44
no ip address
shutdown
!
interface FastEthernet9/45
no ip address
shutdown
!
interface FastEthernet9/46
no ip address
shutdown
!
interface FastEthernet9/47
no ip address
shutdown
!
interface FastEthernet9/48
no ip address
shutdown
!
interface Vlan1
no ip address
!
interface Vlan10
ip address 172.31.20.71 255.255.255.0
ip helper-address 172.31.4.98
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 1 ip 172.31.20.1
standby 1 priority 90
standby 1 preempt
standby 2 ip 172.31.20.254
standby 2 priority 110
standby 2 preempt
!
interface Vlan11
ip address 172.31.21.71 255.255.255.0
ip access-group 136 in
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 2 ip 172.31.21.1
standby 2 priority 90
standby 2 preempt
standby 3 ip 172.31.21.254
standby 3 priority 110
standby 3 preempt
!
interface Vlan12
ip address 172.31.22.71 255.255.255.0
ip access-group 137 in
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 3 ip 172.31.22.1
standby 3 priority 90
standby 3 preempt
standby 4 ip 172.31.22.254
standby 4 priority 110
standby 4 preempt
Cisco IOS Release 12.1(13)E13
204
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface Vlan13
ip address 172.31.23.71 255.255.255.0
ip access-group 138 in
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 4 ip 172.31.23.1
standby 4 priority 90
standby 4 preempt
standby 5 ip 172.31.23.254
standby 5 priority 110
standby 5 preempt
!
interface Vlan14
ip address 172.31.24.71 255.255.255.0
ip access-group 139 in
no ip redirects
ip pim neighbor-filter 55
ip pim query-interval 3
ip pim sparse-mode
standby 5 ip 172.31.24.1
standby 5 priority 90
standby 5 preempt
standby 6 ip 172.31.24.254
standby 6 priority 110
standby 6 preempt
!
interface Vlan15
ip address 172.31.25.71 255.255.255.0
ip access-group 140 in
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 6 ip 172.31.25.1
standby 6 priority 90
standby 6 preempt
standby 7 ip 172.31.25.254
standby 7 priority 110
standby 7 preempt
!
interface Vlan16
ip address 172.31.26.71 255.255.255.0
ip access-group 141 in
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 7 ip 172.31.26.1
standby 7 priority 90
standby 7 preempt
standby 8 ip 172.31.26.254
standby 8 priority 110
standby 8 preempt
!
interface Vlan17
ip address 172.31.27.71 255.255.255.0
ip access-group 142 in
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 8 ip 172.31.27.1
standby 8 priority 90
standby 8 preempt
standby 9 ip 172.31.27.254
Cisco IOS Release 12.1(13)E13
205
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
standby 9 priority 110
standby 9 preempt
!
interface Vlan18
ip address 172.31.28.71 255.255.255.0
ip access-group 143 in
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 9 ip 172.31.28.1
standby 9 priority 90
standby 9 preempt
standby 10 ip 172.31.28.254
standby 10 priority 110
standby 10 preempt
!
interface Vlan19
ip address 172.31.29.71 255.255.255.0
ip access-group 144 in
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 10 ip 172.31.29.1
standby 10 priority 90
standby 10 preempt
standby 11 ip 172.31.29.254
standby 11 priority 110
standby 11 preempt
!
interface Vlan20
ip address 172.31.30.71 255.255.255.0
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 11 ip 172.31.30.1
standby 11 priority 90
standby 11 preempt
standby 12 ip 172.31.30.254
standby 12 priority 110
standby 12 preempt
!
interface Vlan81
ip address 81.0.0.1 255.255.255.0
shutdown
!
interface Vlan82
ip address 82.0.0.1 255.255.255.0
shutdown
!
interface Vlan83
ip address 83.0.0.1 255.255.255.0
shutdown
!
interface Vlan190
ip address 172.31.190.71 255.255.255.0
no ip redirects
ip pim query-interval 3
ip pim sparse-mode
standby 12 ip 172.31.190.1
standby 12 priority 90
standby 12 preempt
standby 13 ip 172.31.190.254
standby 13 priority 110
standby 13 preempt
Cisco IOS Release 12.1(13)E13
206
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface Vlan501
ip address 172.31.51.1 255.255.255.0
no ip redirects
shutdown
standby ip 172.31.51.3
standby priority 110
standby preempt
!
router ospf 1
log-adjacency-changes
auto-cost reference-bandwidth 100000
passive-interface default
no passive-interface Vlan10
no passive-interface GigabitEthernet4/6
no passive-interface GigabitEthernet4/16
no passive-interface GigabitEthernet8/16
no passive-interface Port-channel1
no passive-interface Port-channel71
no passive-interface Port-channel171
network 172.31.0.0 0.0.0.255 area 1
network 172.31.1.84 0.0.0.3 area 1
network 172.31.1.112 0.0.0.3 area 1
network 172.31.1.140 0.0.0.3 area 1
network 172.31.1.200 0.0.0.3 area 1
network 172.31.2.60 0.0.0.3 area 1
network 172.31.4.0 0.0.0.255 area 1
network 172.31.20.0 0.0.3.255 area 1
network 172.31.24.0 0.0.7.255 area 1
network 172.31.33.0 0.0.0.255 area 1
network 172.31.49.0 0.0.0.255 area 1
network 172.31.51.0 0.0.0.255 area 1
network 172.31.190.0 0.0.0.255 area 1
network 172.31.250.0 0.0.0.3 area 1
maximum-paths 6
!
ip classless
ip route 172.18.177.128 255.255.255.192 10.194.17.254
ip route 172.18.179.128 255.255.255.192 10.194.17.254
no ip http server
ip pim rp-address 172.31.0.104 1 override
ip pim rp-address 172.31.0.98 2 override
ip pim spt-threshold infinity
!
!
logging trap debugging
access-list 1 permit 239.255.0.0 0.0.255.255
access-list 1 deny
any
access-list 2 permit 224.0.1.39
access-list 2 permit 224.0.1.40
access-list 20 deny
172.31.1.110
access-list 100 remark Temp_ACL for non-RPF traffic
access-list 100 permit ip any host 224.0.0.13
access-list 100 permit ip any host 224.0.0.13 log
access-list 100 permit ip 172.31.20.0 0.0.0.255 224.0.0.0
access-list 100 permit ip 172.31.21.0 0.0.0.255 224.0.0.0
access-list 100 permit ip 172.31.25.0 0.0.0.255 224.0.0.0
access-list 100 permit ip 172.31.26.0 0.0.0.255 224.0.0.0
access-list 100 permit ip any 224.0.0.0 0.0.0.255
access-list 100 permit ip any 224.0.1.0 0.0.0.255
access-list 100 deny
ip any 224.0.0.0 15.255.255.255
access-list 100 permit ip any any
access-list 100 remark Temp_ACL for non-RPF traffic
access-list 100 remark Temp_ACL for non-RPF traffic
15.255.255.255
15.255.255.255
15.255.255.255
15.255.255.255
Cisco IOS Release 12.1(13)E13
207
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
access-list 101 permit ip any any
access-list 181 permit ip any any
access-list 195 permit igmp host 172.31.33.111 any
snmp-server community public RO
snmp-server community cisco RW
snmp-server enable traps config
snmp-server host 172.18.177.135 public
snmp-server host 172.18.177.181 public
!
tacacs-server host 172.18.177.132
alias exec ip sh ip int brief | be Port
alias exec eigrp show run | be router eigrp
alias exec mr sh ip mroute 239.255.127.100
alias exec ospf sh run | be router ospf
!
line con 0
exec-timeout 0 0
history size 256
line vty 0 4
exec-timeout 0 0
login authentication sh1-testcase
history size 256
transport input lat pad mop telnet rlogin udptn nasi ssh
line vty 5 10
exec-timeout 0 0
login authentication sh1-testcase
history size 256
transport input lat pad mop telnet rlogin udptn nasi ssh
!
exception protocol ftp
exception dump 172.18.177.132
exception memory fragment 200000
exception memory minimum 200000
scheduler runtime netinput 300
ntp clock-period 17179925
ntp update-calendar
ntp server 172.18.177.131
ntp server 172.18.177.132 prefer
end
SH1-110#show version
Cisco Internetwork Operating System Software
IOS (tm) c6sup2_rp Software (c6sup2_rp-JK2SV-M), Version 12.1(nightly13e.E040315) NIGHTLY
BUILD, synced to cosmos_e V121_12_5_E1
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Tue 16-Mar-04 00:20 by
Image text-base: 0x40008BF0, data-base: 0x41BF2000
ROM: System Bootstrap, Version 12.1(11r)E1, RELEASE SOFTWARE (fc1)
SH1-110 uptime is 1 day, 19 hours, 2 minutes
Time since SH1-110 switched to active is 1 day, 19 hours, 1 minute
System returned to ROM by power-on (SP by power-on)
System restarted at 17:17:54 EST Tue Mar 16 2004
System image file is "sup-bootflash:c6sup22-jk2sv-mz.v121_13_e_throttle.040315"
cisco Catalyst 6000 (R7000) processor with 227328K/34816K bytes of memory.
Processor board ID SAD062803HY
R7000 CPU at 300Mhz, Implementation 39, Rev 3.3, 256KB L2, 1024KB L3 Cache
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
Cisco IOS Release 12.1(13)E13
208
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
17 Virtual Ethernet/IEEE 802.3 interface(s)
48 FastEthernet/IEEE 802.3 interface(s)
68 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.
32768K bytes of Flash internal SIMM (Sector size 512K).
Standby is up
Standby has 227328K/34816K bytes of memory.
Configuration register is 0x2102
SH1-110#show module
Mod Ports Card Type
--- ----- -------------------------------------1
2 Catalyst 6000 supervisor 2 (Active)
2
2 Catalyst 6000 supervisor 2 (Standby)
3
16 Pure SFM-mode 16 port 1000mb GBIC
4
16 Pure SFM-mode 16 port 1000mb GBIC
5
0 Switching Fabric Module-136 (Active)
6
0 Switching Fabric Module-136 (Standby)
7
16 SFM-capable 16 port 1000mb GBIC
8
16 SFM-capable 16 port 1000mb GBIC
9
48 48-port 10/100 mb RJ45
Model
-----------------WS-X6K-S2U-MSFC2
WS-X6K-S2U-MSFC2
WS-X6816-GBIC
WS-X6816-GBIC
WS-X6500-SFM2
WS-X6500-SFM2
WS-X6516-GBIC
WS-X6516-GBIC
WS-X6148-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.c9db.4bfc to 0001.c9db.4bfd
3.9
6.1(3)
2 0001.c9db.4bd4 to 0001.c9db.4bd5
3.9
6.1(3)
3 0001.63d4.4bd2 to 0001.63d4.4be1
1.2
12.1(5r)E1
4 0001.63d4.4c92 to 0001.63d4.4ca1
1.2
12.1(5r)E1
5 0001.0002.0003 to 0001.0002.0003
1.1
6.1(3)
6 0001.0002.0003 to 0001.0002.0003
1.1
6.1(3)
7 0001.63d4.3c32 to 0001.63d4.3c41
4.0
6.1(3)
8 0001.6477.53f4 to 0001.6477.5403
4.0
6.1(3)
9 000b.4603.af00 to 000b.4603.af2f
1.1
5.4(2)
Mod
--1
1
2
2
3
4
Sub-Module
--------------------------Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Policy Feature Card 2
Cat6k MSFC 2 daughterboard
Distributed Forwarding Card
Distributed Forwarding Card
Model
--------------WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-PFC2
WS-F6K-MSFC2
WS-F6K-DFC
WS-F6K-DFC
Serial No.
----------SAD0627036A
SAD0628036D
SAD055101JR
SAD055101NA
SAD05520456
SAD055204FX
SAD055204XP
SAD055204SV
SAL06407314
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
12.1(nightly
12.1(nightly
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAD0628029H
3.2
Ok
SAD062803HY
2.5
Ok
SAD06280281
3.2
Ok
SAD062803TF
2.5
Ok
SAD060100F2
2.0
Ok
SAD060100F0
2.0
Ok
Mod Online Diag Status
--- ------------------1 Pass
2 Pass
3 Pass
4 Pass
5 Pass
6 Pass
7 Pass
8 Pass
9 Pass
SH1-110#
Return to SH1-110, page 193
SH1-113
Go to Test Device Configurations, page 17
Cisco IOS Release 12.1(13)E13
209
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
Go to Financial Lab Topology, page 2
Go to Test Cases, page 249
SH1-113#show config
Using 12124 out of 391160 bytes
!
!
version 12.1
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
service internal
!
hostname SH1-113
!
boot system flash slot0:
boot bootldr bootflash:
no logging console
enable password cisco
!
clock timezone EST -5
clock summer-time EDT recurring
vtp file bootflash:SH-VTP-config
vtp domain FIN
vtp mode transparent
ip subnet-zero
!
!
ip ftp username safeharbor
ip ftp password shshsh
no ip domain-lookup
!
ip multicast-routing
mls flow ip destination-source
mls flow ipx destination
mls ip multicast consistency-check
mls ip multicast non-rpf netflow
!
redundancy
mode rpr-plus
main-cpu
auto-sync running-config
auto-sync bootvar
auto-sync standard
!
!
vlan 110-120,140,200
!
!
interface Loopback0
ip address 172.31.4.113 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 172.31.0.114 255.255.255.255
ip pim sparse-mode
!
interface Port-channel10
description Dista-1 Port Channel
no ip address
switchport
switchport trunk encapsulation dot1q
Cisco IOS Release 12.1(13)E13
210
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface Port-channel64
description SH1-99 Po64
ip address 172.31.11.2 255.255.255.252
ip pim sparse-mode
logging event link-status
!
interface Port-channel164
description SH1-100 Po64
ip address 172.31.11.10 255.255.255.252
ip pim sparse-mode
logging event link-status
!
interface GigabitEthernet1/1
no ip address
shutdown
!
interface GigabitEthernet1/2
no ip address
shutdown
!
interface GigabitEthernet2/1
description SH1-99 g9/7
no ip address
channel-group 64 mode on
!
interface GigabitEthernet2/2
description SH1-99 g9/8
no ip address
channel-group 64 mode on
!
interface GigabitEthernet2/3
no ip address
shutdown
!
interface GigabitEthernet2/4
no ip address
shutdown
!
interface GigabitEthernet2/5
no ip address
shutdown
!
interface GigabitEthernet2/6
no ip address
shutdown
!
interface GigabitEthernet2/7
no ip address
shutdown
!
interface GigabitEthernet2/8
no ip address
shutdown
!
interface GigabitEthernet2/9
description SH1-100 g9/7
no ip address
channel-group 164 mode on
!
interface GigabitEthernet2/10
description SH1-100 g9/8
no ip address
channel-group 164 mode on
Cisco IOS Release 12.1(13)E13
211
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface GigabitEthernet2/11
no ip address
shutdown
!
interface GigabitEthernet2/12
no ip address
shutdown
!
interface GigabitEthernet2/13
no ip address
shutdown
!
interface GigabitEthernet2/14
no ip address
shutdown
!
interface GigabitEthernet2/15
no ip address
shutdown
!
interface GigabitEthernet2/16
description Dista-1 3/7
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 10 mode on
!
interface GigabitEthernet3/1
description SH1-100 g1/1
no ip address
channel-group 164 mode on
!
interface GigabitEthernet3/2
description SH1-100 g3/7
no ip address
channel-group 164 mode on
!
interface GigabitEthernet3/3
no ip address
shutdown
!
interface GigabitEthernet3/4
no ip address
shutdown
!
interface GigabitEthernet3/5
no ip address
shutdown
!
interface GigabitEthernet3/6
no ip address
shutdown
!
interface GigabitEthernet3/7
no ip address
shutdown
!
interface GigabitEthernet3/8
no ip address
shutdown
!
interface GigabitEthernet3/9
description SH1-99 g2/2
Cisco IOS Release 12.1(13)E13
212
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
channel-group 64 mode on
!
interface GigabitEthernet3/10
description SH1-99 g4/5
no ip address
channel-group 64 mode on
!
interface GigabitEthernet3/11
no ip address
shutdown
!
interface GigabitEthernet3/12
no ip address
shutdown
!
interface GigabitEthernet3/13
no ip address
shutdown
!
interface GigabitEthernet3/14
no ip address
shutdown
!
interface GigabitEthernet3/15
no ip address
shutdown
!
interface GigabitEthernet3/16
description Dista-1 5/7
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 10 mode on
!
interface FastEthernet9/1
ip address 10.194.17.113 255.255.255.0
shutdown
duplex full
!
interface FastEthernet9/2
description Ix-4/6
ip address 172.31.253.1 255.255.255.252
ip pim sparse-mode
duplex full
!
interface FastEthernet9/3
description IXIA 13/6
no ip address
shutdown
switchport
switchport access vlan 200
switchport mode access
!
interface FastEthernet9/4
no ip address
shutdown
!
interface FastEthernet9/5
no ip address
shutdown
!
interface FastEthernet9/6
no ip address
Cisco IOS Release 12.1(13)E13
213
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface FastEthernet9/7
no ip address
shutdown
!
interface FastEthernet9/8
no ip address
shutdown
!
interface FastEthernet9/9
no ip address
shutdown
!
interface FastEthernet9/10
no ip address
shutdown
!
interface FastEthernet9/11
no ip address
shutdown
!
interface FastEthernet9/12
no ip address
shutdown
!
interface FastEthernet9/13
no ip address
shutdown
!
interface FastEthernet9/14
no ip address
shutdown
!
interface FastEthernet9/15
no ip address
shutdown
!
interface FastEthernet9/16
no ip address
shutdown
!
interface FastEthernet9/17
no ip address
shutdown
!
interface FastEthernet9/18
no ip address
shutdown
!
interface FastEthernet9/19
no ip address
shutdown
!
interface FastEthernet9/20
no ip address
shutdown
!
interface FastEthernet9/21
no ip address
shutdown
!
interface FastEthernet9/22
no ip address
Cisco IOS Release 12.1(13)E13
214
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface FastEthernet9/23
no ip address
shutdown
!
interface FastEthernet9/24
description flashnet
ip address 10.194.17.113 255.255.255.0
speed 100
duplex full
!
interface FastEthernet9/25
no ip address
shutdown
!
interface FastEthernet9/26
no ip address
shutdown
!
interface FastEthernet9/27
no ip address
shutdown
!
interface FastEthernet9/28
no ip address
shutdown
!
interface FastEthernet9/29
no ip address
shutdown
!
interface FastEthernet9/30
no ip address
shutdown
!
interface FastEthernet9/31
no ip address
shutdown
!
interface FastEthernet9/32
no ip address
shutdown
!
interface FastEthernet9/33
no ip address
shutdown
!
interface FastEthernet9/34
no ip address
shutdown
!
interface FastEthernet9/35
no ip address
shutdown
!
interface FastEthernet9/36
no ip address
shutdown
!
interface FastEthernet9/37
no ip address
shutdown
!
Cisco IOS Release 12.1(13)E13
215
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface FastEthernet9/38
no ip address
shutdown
!
interface FastEthernet9/39
no ip address
shutdown
!
interface FastEthernet9/40
no ip address
shutdown
!
interface FastEthernet9/41
no ip address
shutdown
!
interface FastEthernet9/42
no ip address
shutdown
!
interface FastEthernet9/43
no ip address
shutdown
!
interface FastEthernet9/44
no ip address
shutdown
!
interface FastEthernet9/45
no ip address
shutdown
!
interface FastEthernet9/46
no ip address
shutdown
!
interface FastEthernet9/47
no ip address
shutdown
!
interface FastEthernet9/48
no ip address
shutdown
!
interface Vlan1
no ip address
shutdown
!
interface Vlan110
ip address 172.31.210.113 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
ip ospf cost 25
logging event link-status
standby 1 ip 172.31.210.1
standby 1 priority 110
standby 1 preempt
standby 2 ip 172.31.210.254
standby 2 priority 90
standby 2 preempt
!
interface Vlan111
Cisco IOS Release 12.1(13)E13
216
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip address 172.31.211.113 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 2 ip 172.31.211.1
standby 2 priority 110
standby 2 preempt
standby 3 ip 172.31.211.254
standby 3 priority 90
standby 3 preempt
!
interface Vlan112
ip address 172.31.212.113 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 3 ip 172.31.212.1
standby 3 priority 110
standby 3 preempt
standby 4 ip 172.31.212.254
standby 4 priority 90
standby 4 preempt
!
interface Vlan113
ip address 172.31.213.113 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 4 ip 172.31.213.1
standby 4 priority 110
standby 4 preempt
standby 5 ip 172.31.213.254
standby 5 priority 90
standby 5 preempt
!
interface Vlan114
ip address 172.31.214.113 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 5 ip 172.31.214.1
standby 5 priority 110
standby 5 preempt
standby 6 ip 172.31.214.254
standby 6 priority 90
standby 6 preempt
!
interface Vlan115
ip address 172.31.215.113 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 6 ip 172.31.215.1
standby 6 priority 110
Cisco IOS Release 12.1(13)E13
217
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
standby
standby
standby
standby
6
7
7
7
preempt
ip 172.31.215.254
priority 90
preempt
!
interface Vlan116
ip address 172.31.216.113 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 7 ip 172.31.216.1
standby 7 priority 110
standby 7 preempt
standby 8 ip 172.31.216.254
standby 8 priority 90
standby 8 preempt
!
interface Vlan117
ip address 172.31.217.113 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 8 ip 172.31.217.1
standby 8 priority 110
standby 8 preempt
standby 9 ip 172.31.217.254
standby 9 priority 90
standby 9 preempt
!
interface Vlan118
ip address 172.31.218.113 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 9 ip 172.31.218.1
standby 9 priority 110
standby 9 preempt
standby 10 ip 172.31.218.254
standby 10 priority 90
standby 10 preempt
!
interface Vlan119
ip address 172.31.219.113 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 10 ip 172.31.219.1
standby 10 priority 110
standby 10 preempt
standby 11 ip 172.31.219.254
standby 11 priority 90
standby 11 preempt
!
interface Vlan120
ip address 172.31.220.113 255.255.255.0
no ip redirects
Cisco IOS Release 12.1(13)E13
218
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 11 ip 172.31.220.1
standby 11 priority 110
standby 11 preempt
standby 12 ip 172.31.220.254
standby 12 priority 90
standby 12 preempt
!
interface Vlan140
ip address 172.31.240.113 255.255.255.0
no ip redirects
standby ip 172.31.240.1
standby priority 90
standby preempt
!
interface Vlan200
ip address 172.31.200.9 255.255.255.252
ip pim sparse-mode
!
router ospf 1
log-adjacency-changes
auto-cost reference-bandwidth 100000
passive-interface default
no passive-interface Vlan110
no passive-interface Vlan140
no passive-interface Port-channel64
no passive-interface Port-channel164
network 172.31.4.0 0.0.0.255 area 4
network 172.31.11.0 0.0.0.255 area 4
network 172.31.208.0 0.0.15.255 area 4
network 172.31.240.0 0.0.0.255 area 4
network 172.31.0.0 0.0.255.255 area 4
maximum-paths 6
!
ip classless
ip route 10.194.17.0 255.255.255.0 10.194.17.254
ip route 172.18.177.0 255.255.255.0 10.194.17.254
no ip http server
ip pim rp-address 172.31.0.114 1 override
ip pim rp-address 172.31.0.98 2 override
ip pim spt-threshold infinity
ip msdp peer 172.31.4.114 connect-source Loopback0
ip msdp cache-sa-state
ip msdp originator-id Loopback0
!
!
access-list 1 permit 239.255.0.0 0.0.255.255
access-list 1 deny
any
access-list 2 permit 224.0.1.39
access-list 2 permit 224.0.1.40
snmp-server community public RO
snmp-server community cisco RW
snmp-server enable traps config
snmp-server host 172.18.177.132 public
!
alias exec ospf sh run | be router ospf
!
line con 0
exec-timeout 0 0
privilege level 15
password cisco
Cisco IOS Release 12.1(13)E13
219
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
login
history size 256
line vty 0 4
exec-timeout 0 0
password cisco
login
history size 256
transport input lat pad mop telnet rlogin udptn nasi
!
exception protocol ftp
exception dump 172.18.177.129
exception memory fragment 200000
exception memory minimum 200000
scheduler runtime netinput 300
ntp clock-period 17179962
ntp update-calendar
ntp server 172.18.177.131
ntp server 172.18.177.132 prefer
end
SH1-113#show version
Cisco Internetwork Operating System Software
IOS (tm) c6sup2_rp Software (c6sup2_rp-JSV-M), Version 12.1(nightly13e.E040229) NIGHTLY
BUILD, synced to cosmos_e V121_12_5_E1
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Sun 29-Feb-04 21:25 by
Image text-base: 0x40008BF0, data-base: 0x41A4C000
ROM: System Bootstrap, Version 12.1(3r)E2, RELEASE SOFTWARE (fc1)
SH1-113 uptime is 2 weeks, 2 days, 18 hours, 53 minutes
Time since SH1-113 switched to active is 2 weeks, 2 days, 18 hours, 52 minutes
System returned to ROM by power-on (SP by reload)
System restarted at 16:50:18 EST Mon Mar 1 2004
System image file is "slot0:c6sup12-jsv-mz.v121_13_e_throttle.040229"
cisco Catalyst 6000 (R7000) processor with 227328K/34816K bytes of memory.
Processor board ID SAD050301AU
R7000 CPU at 300Mhz, Implementation 39, Rev 2.1, 256KB L2, 1024KB L3 Cache
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
TN3270 Emulation software.
14 Virtual Ethernet/IEEE 802.3 interface(s)
48 FastEthernet/IEEE 802.3 interface(s)
34 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.
16384K bytes of Flash internal SIMM (Sector size 512K).
Configuration register is 0x2102
SH1-113#show module
Mod Ports Card Type
--- ----- -------------------------------------1
2 Cat 6k sup 1 Enhanced QoS (Active)
2
16 SFM-capable 16 port 1000mb GBIC
3
16 SFM-capable 16 port 1000mb GBIC
9
48 48-port 10/100 mb RJ45
Model
-----------------WS-X6K-SUP1A-2GE
WS-X6516-GBIC
WS-X6516-GBIC
WS-X6148-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0001.972d.5370 to 0001.972d.5371
7.0
5.4(2)
2 0008.7dc8.b67c to 0008.7dc8.b68b
5.3
6.3(1)
Cisco IOS Release 12.1(13)E13
220
Serial No.
----------SAD05020FPW
SAL0702BKMK
SAL0709DHKF
SAL0715BR2H
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
3
9
0008.7dc8.b41c to 0008.7dc8.b42b
000c.85e7.37f8 to 000c.85e7.3827
Mod Sub-Module
--- --------------------------1 Policy Feature Card
1 Cat6k MSFC 2 daughterboard
SH1-113#
5.3
1.2
6.3(1)
5.4(2)
Model
--------------WS-F6K-PFC
WS-F6K-MSFC2
7.5(0.6)HUB1 Ok
7.5(0.6)HUB1 Ok
Serial
Hw
Status
--------------- ------- ------SAD05020NVB
1.1
Ok
SAD050301AU
1.2
Ok
Return to SH1-113, page 209
SH1-114
Go to Test Device Configurations, page 17
Go to Financial Lab Topology, page 2
Go to Test Cases, page 249
SH1-114#show config
Using 12217 out of 391160 bytes
!
!
version 12.1
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname SH1-114
!
boot system flash slot0:
boot bootldr bootflash:
no logging console
enable password cisco
!
clock timezone EST -5
clock summer-time EDT recurring
vtp file bootflash:SH-VTP-config
vtp domain FIN
vtp mode transparent
ip subnet-zero
!
!
ip ftp username safeharbor
ip ftp password shshsh
no ip domain-lookup
!
ip multicast-routing
mls flow ip destination-source
mls flow ipx destination
mls ip multicast consistency-check
mls ip multicast non-rpf netflow
!
redundancy
mode rpr-plus
main-cpu
auto-sync running-config
auto-sync bootvar
auto-sync standard
!
!
vlan 2-199,207-329
!
Cisco IOS Release 12.1(13)E13
221
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
vlan 400
name test_RPR
!
vlan 401
name test_vlan
!
vlan 500-501,712-747,749-783,785-800,999
!
!
interface Loopback0
ip address 172.31.4.114 255.255.255.255
ip pim sparse-mode
!
interface Loopback1
ip address 172.31.0.114 255.255.255.255
ip pim sparse-mode
!
interface Port-channel10
description Dista-1 Port Channel
no ip address
switchport
switchport trunk encapsulation dot1q
!
interface Port-channel65
description SH1-99 Po65
ip address 172.31.11.6 255.255.255.252
ip pim sparse-mode
logging event link-status
!
interface Port-channel165
description SH1-100 Po65
ip address 172.31.11.14 255.255.255.252
ip pim sparse-mode
logging event link-status
!
interface GigabitEthernet1/1
no ip address
shutdown
!
interface GigabitEthernet1/2
no ip address
shutdown
!
interface GigabitEthernet2/1
description SH1-99 g9/7
no ip address
channel-group 65 mode on
!
interface GigabitEthernet2/2
description SH1-99 g9/8
no ip address
channel-group 65 mode on
!
interface GigabitEthernet2/3
no ip address
shutdown
!
interface GigabitEthernet2/4
no ip address
shutdown
!
interface GigabitEthernet2/5
no ip address
shutdown
Cisco IOS Release 12.1(13)E13
222
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface GigabitEthernet2/6
no ip address
shutdown
!
interface GigabitEthernet2/7
no ip address
shutdown
!
interface GigabitEthernet2/8
description Dista-1 3/4
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 10 mode on
!
interface GigabitEthernet2/9
description SH1-100 g4/5
no ip address
channel-group 165 mode on
!
interface GigabitEthernet2/10
description SH1-100 g4/6
no ip address
channel-group 165 mode on
!
interface GigabitEthernet2/11
no ip address
shutdown
!
interface GigabitEthernet2/12
no ip address
shutdown
!
interface GigabitEthernet2/13
no ip address
shutdown
!
interface GigabitEthernet2/14
no ip address
shutdown
!
interface GigabitEthernet2/15
no ip address
shutdown
!
interface GigabitEthernet2/16
description Dista-1 5/4
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 10 mode on
!
interface GigabitEthernet3/1
description SH1-100 g9/9
no ip address
channel-group 165 mode on
!
interface GigabitEthernet3/2
description SH1-100 g9/10
no ip address
channel-group 165 mode on
!
interface GigabitEthernet3/3
Cisco IOS Release 12.1(13)E13
223
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface GigabitEthernet3/4
no ip address
shutdown
!
interface GigabitEthernet3/5
no ip address
shutdown
!
interface GigabitEthernet3/6
no ip address
shutdown
!
interface GigabitEthernet3/7
no ip address
shutdown
!
interface GigabitEthernet3/8
description Dista-1 3/5
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 10 mode on
!
interface GigabitEthernet3/9
description SH1-99 g2/2
no ip address
channel-group 65 mode on
!
interface GigabitEthernet3/10
description SH1-99 g4/5
no ip address
channel-group 65 mode on
!
interface GigabitEthernet3/11
no ip address
shutdown
!
interface GigabitEthernet3/12
no ip address
shutdown
!
interface GigabitEthernet3/13
no ip address
shutdown
!
interface GigabitEthernet3/14
no ip address
shutdown
!
interface GigabitEthernet3/15
no ip address
shutdown
!
interface GigabitEthernet3/16
description Dista-1 5/5
no ip address
switchport
switchport trunk encapsulation dot1q
channel-group 10 mode on
!
interface FastEthernet9/1
Cisco IOS Release 12.1(13)E13
224
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
no ip address
shutdown
!
interface FastEthernet9/2
description IXIA 13/5
no ip address
switchport
switchport access vlan 201
switchport mode access
!
interface FastEthernet9/3
no ip address
shutdown
!
interface FastEthernet9/4
no ip address
shutdown
!
interface FastEthernet9/5
no ip address
shutdown
!
interface FastEthernet9/6
no ip address
shutdown
!
interface FastEthernet9/7
no ip address
shutdown
!
interface FastEthernet9/8
no ip address
shutdown
!
interface FastEthernet9/9
no ip address
shutdown
!
interface FastEthernet9/10
no ip address
shutdown
!
interface FastEthernet9/11
no ip address
shutdown
!
interface FastEthernet9/12
no ip address
shutdown
!
interface FastEthernet9/13
no ip address
shutdown
!
interface FastEthernet9/14
no ip address
shutdown
!
interface FastEthernet9/15
no ip address
shutdown
!
interface FastEthernet9/16
no ip address
Cisco IOS Release 12.1(13)E13
225
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
shutdown
!
interface FastEthernet9/17
no ip address
shutdown
!
interface FastEthernet9/18
no ip address
shutdown
!
interface FastEthernet9/19
no ip address
shutdown
!
interface FastEthernet9/20
no ip address
shutdown
!
interface FastEthernet9/21
no ip address
shutdown
!
interface FastEthernet9/22
no ip address
shutdown
!
interface FastEthernet9/23
no ip address
shutdown
!
interface FastEthernet9/24
description flashnet
ip address 10.194.17.114 255.255.255.0
speed 100
duplex full
!
interface FastEthernet9/25
no ip address
shutdown
!
interface FastEthernet9/26
no ip address
shutdown
!
interface FastEthernet9/27
no ip address
shutdown
!
interface FastEthernet9/28
no ip address
shutdown
!
interface FastEthernet9/29
no ip address
shutdown
!
interface FastEthernet9/30
no ip address
shutdown
!
interface FastEthernet9/31
no ip address
shutdown
!
Cisco IOS Release 12.1(13)E13
226
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface FastEthernet9/32
no ip address
shutdown
!
interface FastEthernet9/33
no ip address
shutdown
!
interface FastEthernet9/34
no ip address
shutdown
!
interface FastEthernet9/35
no ip address
shutdown
!
interface FastEthernet9/36
no ip address
shutdown
!
interface FastEthernet9/37
no ip address
shutdown
!
interface FastEthernet9/38
no ip address
shutdown
!
interface FastEthernet9/39
no ip address
shutdown
!
interface FastEthernet9/40
no ip address
shutdown
!
interface FastEthernet9/41
no ip address
shutdown
!
interface FastEthernet9/42
no ip address
shutdown
!
interface FastEthernet9/43
no ip address
shutdown
!
interface FastEthernet9/44
no ip address
shutdown
!
interface FastEthernet9/45
no ip address
shutdown
!
interface FastEthernet9/46
no ip address
shutdown
!
interface FastEthernet9/47
no ip address
shutdown
!
Cisco IOS Release 12.1(13)E13
227
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
interface FastEthernet9/48
no ip address
shutdown
!
interface Vlan1
no ip address
shutdown
!
interface Vlan110
ip address 172.31.210.114 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
ip ospf cost 25
logging event link-status
standby 1 ip 172.31.210.1
standby 1 priority 90
standby 1 preempt
standby 2 ip 172.31.210.254
standby 2 priority 110
standby 2 preempt
!
interface Vlan111
ip address 172.31.211.114 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 2 ip 172.31.211.1
standby 2 priority 90
standby 2 preempt
standby 3 ip 172.31.211.254
standby 3 priority 110
standby 3 preempt
!
interface Vlan112
ip address 172.31.212.114 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 3 ip 172.31.212.1
standby 3 priority 90
standby 3 preempt
standby 4 ip 172.31.212.254
standby 4 priority 110
standby 4 preempt
!
interface Vlan113
ip address 172.31.213.114 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 4 ip 172.31.213.1
standby 4 priority 90
standby 4 preempt
standby 5 ip 172.31.213.254
standby 5 priority 110
standby 5 preempt
Cisco IOS Release 12.1(13)E13
228
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
interface Vlan114
ip address 172.31.214.114 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 5 ip 172.31.214.1
standby 5 priority 90
standby 5 preempt
standby 6 ip 172.31.214.254
standby 6 priority 110
standby 6 preempt
!
interface Vlan115
ip address 172.31.215.114 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 6 ip 172.31.215.1
standby 6 priority 90
standby 6 preempt
standby 7 ip 172.31.215.254
standby 7 priority 110
standby 7 preempt
!
interface Vlan116
ip address 172.31.216.114 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 7 ip 172.31.216.1
standby 7 priority 90
standby 7 preempt
standby 8 ip 172.31.216.254
standby 8 priority 110
standby 8 preempt
!
interface Vlan117
ip address 172.31.217.114 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 8 ip 172.31.217.1
standby 8 priority 90
standby 8 preempt
standby 9 ip 172.31.217.254
standby 9 priority 110
standby 9 preempt
!
interface Vlan118
ip address 172.31.218.114 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
Cisco IOS Release 12.1(13)E13
229
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
standby
standby
standby
standby
standby
standby
9 ip 172.31.218.1
9 priority 90
9 preempt
10 ip 172.31.218.254
10 priority 110
10 preempt
!
interface Vlan119
ip address 172.31.219.114 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 10 ip 172.31.219.1
standby 10 priority 90
standby 10 preempt
standby 11 ip 172.31.219.254
standby 11 priority 110
standby 11 preempt
!
interface Vlan120
ip address 172.31.220.114 255.255.255.0
no ip redirects
ip directed-broadcast
ip pim query-interval 3
ip pim sparse-mode
logging event link-status
standby 11 ip 172.31.220.1
standby 11 priority 90
standby 11 preempt
standby 12 ip 172.31.220.254
standby 12 priority 110
standby 12 preempt
!
interface Vlan140
description Pagent OSPF VLAN
ip address 172.31.240.114 255.255.255.0
no ip redirects
standby ip 172.31.240.1
standby priority 110
standby preempt
!
router ospf 1
log-adjacency-changes
auto-cost reference-bandwidth 100000
passive-interface default
no passive-interface Vlan110
no passive-interface Vlan140
no passive-interface Port-channel65
no passive-interface Port-channel165
network 172.31.4.0 0.0.0.255 area 4
network 172.31.11.0 0.0.0.255 area 4
network 172.31.208.0 0.0.15.255 area 4
network 172.31.240.0 0.0.0.255 area 4
network 172.31.0.0 0.0.255.255 area 4
maximum-paths 6
!
ip classless
ip route 10.194.17.0 255.255.255.0 10.194.17.254
ip route 172.18.177.0 255.255.255.0 10.194.17.254
no ip http server
ip pim rp-address 172.31.0.114 1 override
ip pim rp-address 172.31.0.98 2 override
Cisco IOS Release 12.1(13)E13
230
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
ip pim spt-threshold infinity
ip msdp peer 172.31.4.113 connect-source Loopback0
ip msdp cache-sa-state
ip msdp originator-id Loopback0
!
!
access-list 1 permit 239.255.0.0 0.0.255.255
access-list 1 deny
any
access-list 2 permit 224.0.1.39
access-list 2 permit 224.0.1.40
snmp-server community public RO
snmp-server community cisco RW
snmp-server enable traps config
snmp-server host 172.18.177.132 public
!
alias exec ospf show runn | beg router ospf
!
line con 0
exec-timeout 0 0
timeout login response 0
privilege level 15
password cisco
login
history size 256
line vty 0 4
exec-timeout 0 0
password cisco
login
history size 256
transport input lat pad mop telnet rlogin udptn nasi
!
exception protocol ftp
exception dump 172.18.177.129
exception memory fragment 200000
exception memory minimum 200000
ntp clock-period 17179793
ntp update-calendar
ntp server 172.18.177.131
ntp server 172.18.177.132 prefer
end
SH1-114#show version
Cisco Internetwork Operating System Software
IOS (tm) c6sup2_rp Software (c6sup2_rp-JSV-M), Version 12.1(nightly13e.E040229) NIGHTLY
BUILD, synced to cosmos_e V121_12_5_E1
Copyright (c) 1986-2004 by cisco Systems, Inc.
Compiled Sun 29-Feb-04 21:25 by
Image text-base: 0x40008BF0, data-base: 0x41A4C000
ROM: System Bootstrap, Version 12.1(4r)E, RELEASE SOFTWARE (fc1)
SH1-114 uptime is 2 weeks, 2 days, 18 hours, 52 minutes
Time since SH1-114 switched to active is 2 weeks, 2 days, 18 hours, 51 minutes
System returned to ROM by power-on (SP by reload)
System restarted at 16:51:23 EST Mon Mar 1 2004
System image file is "slot0:c6sup12-jsv-mz.v121_13_e_throttle.040229"
cisco Catalyst 6000 (R7000) processor with 112640K/18432K bytes of memory.
Processor board ID SAL0603GURM
R7000 CPU at 300Mhz, Implementation 39, Rev 3.3, 256KB L2, 1024KB L3 Cache
Last reset from power-on
Bridging software.
X.25 software, Version 3.0.0.
SuperLAT software (copyright 1990 by Meridian Technology Corp).
Cisco IOS Release 12.1(13)E13
231
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
TN3270 Emulation software.
13 Virtual Ethernet/IEEE 802.3 interface(s)
48 FastEthernet/IEEE 802.3 interface(s)
34 Gigabit Ethernet/IEEE 802.3 interface(s)
381K bytes of non-volatile configuration memory.
16384K bytes of Flash internal SIMM (Sector size 512K).
Configuration register is 0x2102
SH1-114#show module
Mod Ports Card Type
--- ----- -------------------------------------1
2 Cat 6k sup 1 Enhanced QoS (Active)
2
16 SFM-capable 16 port 1000mb GBIC
3
16 SFM-capable 16 port 1000mb GBIC
9
48 48-port 10/100 mb RJ45
Model
-----------------WS-X6K-SUP1A-2GE
WS-X6516-GBIC
WS-X6516-GBIC
WS-X6148-RJ-45
Mod MAC addresses
Hw
Fw
--- ---------------------------------- ------ -----------1 0005.7485.2b18 to 0005.7485.2b19
7.1
5.4(2)
2 0009.11f5.ada8 to 0009.11f5.adb7
5.3
6.3(1)
3 0009.11f5.ad58 to 0009.11f5.ad67
5.3
6.3(1)
9 000c.85cf.d798 to 000c.85cf.d7c7
1.2
5.4(2)
Mod Sub-Module
--- --------------------------1 Policy Feature Card
1 Cat6k MSFC 2 daughterboard
SH1-114#
Model
--------------WS-F6K-PFC
WS-F6K-MSFC2
Serial No.
----------SAL0605HKNZ
SAL0709DJFH
SAL0708DB24
SAL0715BR1Q
Sw
-----------7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
7.5(0.6)HUB1
Status
------Ok
Ok
Ok
Ok
Serial
Hw
Status
--------------- ------- ------SAL0605HA8Z
2.0
Ok
SAL0603GURM
2.0
Ok
Return to SH1-114, page 221
Dista-1
Go to Test Device Configurations, page 17
Go to Financial Lab Topology, page 2
Go to Test Cases, page 249
dista-1> (enable) show config
This command shows non-default configurations only.
Use 'show config all' to show both default and non-default configurations.
...............
..................
..................
..................
..................
..................
....................
..
begin
!
# ***** NON-DEFAULT CONFIGURATION *****
!
!
#time: Thu Mar 18 2004, 12:22:10 EST
!
#version 6.4(8)
!
set password $2$HUVd$Tqn8CBrZKs1Gbc31oxrLD0
Cisco IOS Release 12.1(13)E13
232
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
set enablepass $2$fX1D$Lsu41oirUxJkSITgOEn2e.
set prompt dista-1>
set logout 0
!
#system
set system name dista-1
!
#!
#vtp
set vtp domain FIN
set vtp mode transparent
set vlan 1 name default type ethernet mtu 1500 said 100001 state active
set vlan 1002 name fddi-default type fddi mtu 1500 said 101002 state active
set vlan 1004 name fddinet-default type fddinet mtu 1500 said 101004 state active stp ibm
set vlan 1005 name trnet-default type trbrf mtu 1500 said 101005 state active stp ibm
set vlan 10-20,40-50,60-61,110-111,113,115,120,140,150,500-501,1000
set vlan 1003 name token-ring-default type trcrf mtu 1500 said 101003 state active mode
srb aremaxhop 7 stemaxhop 7 backupcrf off
set vlan 1002 translation 1 translation 1003
set vlan 1003 translation 1 translation 1002
!
#ip
set interface sc0 1000 10.194.17.111/255.255.255.0 10.194.17.255
set interface sl0 down
set ip route 172.18.0.0/255.255.0.0
10.194.17.254
set ip alias default
0.0.0.0
!
#syslog
set logging console disable
set logging level ip 2 default
!
#ntp
set ntp client enable
set ntp server 172.18.177.132
set ntp server 172.18.177.131
set timezone EST -5 0
set summertime enable EDT
!
#set boot command
set boot config-register 0x2102
set boot system flash bootflash:cat6000-sup2.6-4-8.bin
!
#mmls nonrpf
set mmls nonrpf timer 10
!
#port channel
set port channel 1/1,2/1 10
set port channel 3/6,3/8 17
set port channel 6/37-40 25
set port channel 1/2,2/2-4 30
set port channel 2/6 61
set port channel 3/1-3 106
set port channel 3/7,5/7 110
set port channel 2/5,2/7-8 248
set port channel 2/9-12 249
set port channel 2/13-16 250
set port channel 4/1-4 251
set port channel 4/5-8 252
set port channel 4/9-12 253
set port channel 4/13-16 254
set port channel 3/4-5,5/4-5 256
set port channel 6/1-4 257
Cisco IOS Release 12.1(13)E13
233
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
set port channel 6/5-8 258
set port channel 6/9-12 259
set port channel 6/13-16 260
set port channel 6/17-20 261
set port channel 6/21-24 262
set port channel 6/25-28 263
set port channel 6/29-32 264
set port channel 6/33-36 265
set port channel 6/41-44 267
set port channel 6/45-48 268
!
# default port status is enable
!
!
#module 1 : 2-port 1000BaseX Supervisor
set module name
1
set port name
1/1 sh1-107 gi4/1
set port name
1/2 sh1-108 gi4/1
clear trunk 1/1 21-499,502-1000,1025-4094
set trunk 1/1 on dot1q 1-20,500-501,1001-1005
clear trunk 1/2 21-499,502-1000
set trunk 1/2 on dot1q 1-20,500-501,1001-1005,1025-4094
set port channel 1/1-2 mode on
!
#module 2 : 16-port 1000BaseSX Ethernet
set module name
2
set vlan 60
2/5
set vlan 61
2/6
set port name
2/1 sh1-107 gi4/3
set port name
2/3 sh1-108 gi4/3
set port name
2/4 sh1-108 gi4/4
clear trunk 2/1 21-499,502-1000,1025-4094
set trunk 2/1 on dot1q 1-20,500-501,1001-1005
clear trunk 2/2 21-499,502-1000
set trunk 2/2 on dot1q 1-20,500-501,1001-1005,1025-4094
clear trunk 2/3 21-499,502-1000
set trunk 2/3 on dot1q 1-20,500-501,1001-1005,1025-4094
clear trunk 2/4 21-499,502-1000
set trunk 2/4 on dot1q 1-20,500-501,1001-1005,1025-4094
clear trunk 2/6 21-1000
set trunk 2/6 auto negotiate 1-20,1001-1005,1025-4094
set spantree portfast
2/5,2/10 enable
set port channel 2/1-4 mode on
!
#module 3 : 8-port 1000BaseX Ethernet
set module name
3
set port name
3/1 sh1-101 gi7/1
set port name
3/2 sh1-101 gi7/2
set port name
3/4 SH1-114 g2/8
set port name
3/5 SH1-114 g3/8
set port name
3/6 sh1-102 gi7/6
set port name
3/7 SH1-113 g2/16
set port name
3/8 sh1-102 gi7/8
set udld enable 3/3
clear trunk 3/1 2-39,51-59,62-149,151-1005,1025-4094
set trunk 3/1 desirable negotiate 1,40-50,60-61,150
clear trunk 3/2 2-39,51-59,62-149,151-1005,1025-4094
set trunk 3/2 desirable negotiate 1,40-50,60-61,150
set trunk 3/4 desirable negotiate 1-1005,1025-4094
set trunk 3/5 desirable negotiate 1-1005,1025-4094
clear trunk 3/6 1-39,51-59,62-149,151-1005
set trunk 3/6 auto negotiate 40-50,60-61,150,1025-4094
clear trunk 3/8 1-39,51-59,62-149,151-1005
set trunk 3/8 auto negotiate 40-50,60-61,150,1025-4094
Cisco IOS Release 12.1(13)E13
234
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
set port channel 3/1-2,3/4-8 mode on
!
#module 4 : 16-port 1000BaseSX Ethernet
set module name
4
set vlan 1000 4/16
set port name
4/16 Backbone
set spantree portfast
4/5,4/10 enable
!
#module 5 : 8-port 1000BaseX Ethernet
set module name
5
set vlan 43
5/1
set port disable
5/2-3,5/6,5/8
set port name
5/1 IXIA 1/2
set port name
5/4 SH1-114 g2/16
set port name
5/5 SH1-114 g3/16
set port name
5/7 SH1-113 g3/16
set trunk 5/4 desirable negotiate 1-1005,1025-4094
set trunk 5/5 desirable negotiate 1-1005,1025-4094
set port channel 5/4-5,5/7 mode on
!
#module 6 : 48-port 10/100BaseTX Ethernet
set vlan 10
6/12
set vlan 11
6/3
set vlan 16
6/4
set vlan 20
6/11
set vlan 41
6/1
set vlan 43
6/7
set vlan 44
6/6
set vlan 45
6/5
set vlan 110 6/8
set vlan 111 6/10
set vlan 113 6/9
set vlan 115 6/2
set vlan 120 6/13
set vlan 140 6/38
set vlan 150 6/37
set vlan 501 6/14
set vlan 1000 6/24
set port speed
6/1-12,6/24-26,6/30,6/35-36,6/47
set port duplex
6/1-12,6/24-26,6/30,6/35-36,6/47
set port name
6/1 IXIA 2/1
set port name
6/2 IXIA 4/1
set port name
6/3 Ixia 8/1
set port name
6/4 Ixia 8/2
set port name
6/5 IXIA 2/2
set port name
6/6 IXIA 2/8
set port name
6/7 IXIA 2/7
set port name
6/8 IXIA 3/3
set port name
6/9 IXIA 3/4
set port name
6/10 IXIA 5/4
set port name
6/11 Ixia 8/5
set port name
6/13 IXIA 10/1
set port name
6/37 rtp-wbu-te-p5 fa4/1
set port name
6/38 rtp-st-te-p4 fa2/0
set port name
6/48 rtp-wbu-knx1 eth0
clear trunk 6/5 2-44,46-59,61-1005,1025-4094
set trunk 6/5 on dot1q 1,45,60
clear trunk 6/6 2-43,45-60,62-1005,1025-4094
set trunk 6/6 on dot1q 1,44,61
set trunk 6/47 off negotiate 1-1005,1025-4094
clear trunk 6/48 1-9,11-39,41-109,111-1005,1025-4094
set trunk 6/48 on dot1q 10,40,110
set spantree portfast
6/1-48 enable
100
full
Cisco IOS Release 12.1(13)E13
235
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
!
#module 15 empty
!
#module 16 empty
!
#switch port analyzer
set span 6/6 6/17 tx inpkts disable learning enable multicast enable create
end
dista-1> (enable) show version
WS-C6506 Software, Version NmpSW: 6.4(8)
Copyright (c) 1995-2004 by Cisco Systems
NMP S/W compiled on Jan 6 2004, 15:03:09
System Bootstrap Version: 6.1(3)
Hardware Version: 2.0
PS1
Model: WS-C6506
Module: WS-CAC-1300W
Serial #: TBA03310431
Serial #: ACP03470662
Mod Port Model
Serial #
Versions
--- ---- ------------------- ----------- -------------------------------------1
2
WS-X6K-SUP2-2GE
SAD0508096C Hw : 2.2
Fw : 6.1(3)
Fw1: 6.1(3)
Sw : 6.4(8)
Sw1: 6.4(8)
WS-F6K-PFC2
SAD05060T6K Hw : 1.3
2
16
WS-X6416-GE-MT
SAD03441864 Hw : 1.0
Fw : 5.3(1)
Sw : 6.4(8)
3
8
WS-X6408A-GBIC
SAD042902PR Hw : 1.3
Fw : 5.4(2)
Sw : 6.4(8)
4
16
WS-X6416-GE-MT
SAD04030BMY Hw : 1.0
Fw : 5.3(1)
Sw : 6.4(8)
5
8
WS-X6408-GBIC
SAD03070639 Hw : 1.4
Fw : 4.2(0.24)VAI78
Sw : 6.4(8)
6
48
WS-X6248-RJ-45
SAD03151603 Hw : 1.1
Fw : 4.2(0.24)VAI78
Sw : 6.4(8)
DRAM
FLASH
NVRAM
Module Total
Used
Free
Total
Used
Free
Total Used Free
------ ------- ------- ------- ------- ------- ------- ----- ----- ----1
131072K 64456K 66616K 32768K 24644K
8124K 512K 298K 214K
Uptime is 37 days, 19 hours, 29 minutes
dista-1> (enable) show module
Mod Slot Ports Module-Type
--- ---- ----- ------------------------1
1
2
1000BaseX Supervisor
2
2
16
1000BaseSX Ethernet
3
3
8
1000BaseX Ethernet
4
4
16
1000BaseSX Ethernet
5
5
8
1000BaseX Ethernet
6
6
48
10/100BaseTX Ethernet
Mod Module-Name
--- -------------------1
2
3
Cisco IOS Release 12.1(13)E13
236
Serial-Num
----------SAD0508096C
SAD03441864
SAD042902PR
Model
------------------WS-X6K-SUP2-2GE
WS-X6416-GE-MT
WS-X6408A-GBIC
WS-X6416-GE-MT
WS-X6408-GBIC
WS-X6248-RJ-45
Sub
--yes
no
no
no
no
no
Status
-------ok
ok
ok
ok
ok
ok
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
4
5
6
SAD04030BMY
SAD03070639
SAD03151603
Mod MAC-Address(es)
--- -------------------------------------1
00-02-7e-27-78-3a to 00-02-7e-27-78-3b
00-02-7e-27-78-38 to 00-02-7e-27-78-39
00-d0-97-f0-2c-00 to 00-d0-97-f0-2f-ff
2
00-30-b6-d4-0e-8c to 00-30-b6-d4-0e-9b
3
00-01-64-11-f4-f8 to 00-01-64-11-f4-ff
4
00-d0-d3-9d-da-cc to 00-d0-d3-9d-da-db
5
00-50-54-6c-90-58 to 00-50-54-6c-90-5f
6
00-d0-58-e9-9a-bc to 00-d0-58-e9-9a-eb
Hw
Fw
Sw
------ ---------- ----------------2.2
6.1(3)
6.4(8)
1.0
1.3
1.0
1.4
1.1
5.3(1)
5.4(2)
5.3(1)
4.2(0.24)V
4.2(0.24)V
6.4(8)
6.4(8)
6.4(8)
6.4(8)
6.4(8)
Mod Sub-Type
Sub-Model
Sub-Serial Sub-Hw
--- ----------------------- ------------------- ----------- -----1
L3 Switching Engine II WS-F6K-PFC2
SAD05060T6K 1.3
dista-1> (enable)
Return to Dista-1, page 232
Dista-2
Go to Test Device Configurations, page 17
Go to Financial Lab Topology, page 2
Go to Test Cases, page 249
dista-2> (enable) show config
This command shows non-default configurations only.
Use 'show config all' to show both default and non-default configurations.
...............
..................
..................
..................
..................
..................
....................
..
begin
!
# ***** NON-DEFAULT CONFIGURATION *****
!
!
#time: Thu Mar 18 2004, 12:23:29 EST
!
#version 6.4(8)
!
set password $2$HdPF$ky0W54iah7rSH2NHCoDzs1
set enablepass $2$WHuS$8gNVDrC94NAzIlsdH32ic.
set prompt dista-2>
set logout 0
!
#system
set system name
!
#!
#vtp
dista-2
Cisco IOS Release 12.1(13)E13
237
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
set
set
set
set
set
set
set
set
set
srb
!
#ip
set
vtp domain FIN
vtp mode transparent
vlan 1 name default type ethernet mtu 1500 said 100001 state active
vlan 97 rspan name VLAN0097 state active
vlan 1002 name fddi-default type fddi mtu 1500 said 101002 state active
vlan 1004 name fddinet-default type fddinet mtu 1500 said 101004 state active stp ieee
vlan 1005 name trnet-default type trbrf mtu 1500 said 101005 state active stp ibm
vlan 10-21,40-50,100,110,120,150,170,190,254,294,501,600,1000
vlan 1003 name token-ring-default type trcrf mtu 1500 said 101003 state active mode
aremaxhop 0 stemaxhop 0 backupcrf off
interface sc0 1000 10.194.17.112/255.255.255.0 10.194.17.255
set ip route 172.18.0.0/255.255.0.0
10.194.17.254
set ip alias default
0.0.0.0
!
#syslog
set logging console disable
set logging level ip 2 default
!
#ntp
set ntp client enable
set ntp server 172.18.177.132
set ntp server 172.18.177.131
set timezone EST -5 0
set summertime enable EDT
!
#set boot command
set boot config-register 0x2102
set boot system flash bootflash:cat6000-sup2.6-4-8.bin
!
#udld
set udld enable
set udld interval 7
!
#port channel
set port channel 6/41-44 31
set port channel 6/1-4 32
set port channel 4/2,4/15 120
set port channel 2/5-8 129
set port channel 4/7-8 163
set port channel 4/9-11 164
set port channel 2/3-4 191
set port channel 6/17 192
set port channel 2/1-2 199
set port channel 1/2,4/3,4/12-13 213
set port channel 1/1,4/14 683
set port channel 4/4,4/6 771
set port channel 3/2-5 868
set port channel 3/6-8 869
set port channel 4/5 940
set port channel 3/1 942
!
#errdisable timeout
set errdisable-timeout enable udld
set errdisable-timeout interval 30
!
# default port status is enable
!
!
#module 1 : 2-port 1000BaseX Supervisor
set module name
1
set port name
1/1 sh1-109 g7/3
Cisco IOS Release 12.1(13)E13
238
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
set port name
1/2 sh1-110 g7/3
set port negotiation 1/1 disable
set udld aggressive-mode enable 1/1-2
clear trunk 1/1 190,1000
set trunk 1/1 auto negotiate 1-189,191-999,1001-1005,1025-4094
clear trunk 1/2 1000
set trunk 1/2 auto negotiate 1-999,1001-1005,1025-4094
set port channel 1/1 mode on
!
#module 2 : 16-port 1000BaseX Ethernet
set module name
2
set vlan 190 2/1-4
set port disable
2/5-8
set port name
2/1 SH1-109 g3/2
set port name
2/2 SH1-109 g4/2
set port name
2/3 SH1-110 g3/2
set port name
2/4 SH1-110 g4/2
set udld enable 2/5-16
clear trunk 2/1 190
set trunk 2/1 off negotiate 1-189,191-1005,1025-4094
clear trunk 2/2 190
set trunk 2/2 off negotiate 1-189,191-1005,1025-4094
clear trunk 2/3 190
set trunk 2/3 off negotiate 1-189,191-1005,1025-4094
clear trunk 2/4 190
set trunk 2/4 off negotiate 1-189,191-1005,1025-4094
clear trunk 2/5 1-39,51-1005
set trunk 2/5 off negotiate 40-50,1025-4094
clear trunk 2/6 1-39,51-1005
set trunk 2/6 off negotiate 40-50,1025-4094
set port channel 2/5-8 mode off
!
#module 3 : 8-port 1000BaseX Ethernet
set module name
3
set vlan 1000 3/1,3/7-8
set port name
3/2 SH1-110 g3/5
set port name
3/3 SH1-110 g3/6
set port name
3/4 SH1-110 g4/5
set port name
3/5 SH1-110 g4/6
set port name
3/7 SH1-109 flash
set port name
3/8 SH1-110 flash
clear trunk 3/2 190
set trunk 3/2 auto negotiate 1-189,191-1005,1025-4094
clear trunk 3/3 190
set trunk 3/3 auto negotiate 1-189,191-1005,1025-4094
clear trunk 3/4 190
set trunk 3/4 auto negotiate 1-189,191-1005,1025-4094
clear trunk 3/5 190
set trunk 3/5 auto negotiate 1-189,191-1005,1025-4094
!
#module 4 : 16-port 1000BaseSX Ethernet
set module name
4
set vlan 1000 4/16
set port disable
4/5
set
set
set
set
set
set
set
set
port
port
port
port
port
port
port
port
name
name
name
name
name
name
name
name
4/3
4/4
4/5
4/6
4/9
4/10
4/12
4/13
sh1-110 g8/3
SH1-105 g3/7
BAD PORT
sh1-105 g3/8
sh1-106 g3/7
sh1-106 3/8
sh1-110 g7/5
sh1-110 g8/5
Cisco IOS Release 12.1(13)E13
239
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
set port name
4/14 sh1-109 g6/3
set port name
4/16 dista-1 4/16
set port negotiation 4/2,4/14-15 disable
set udld aggressive-mode enable 4/1-16
clear trunk 4/2 1000
set trunk 4/2 auto negotiate 1-999,1001-1005,1025-4094
clear trunk 4/3 1000
set trunk 4/3 auto negotiate 1-999,1001-1005,1025-4094
clear trunk 4/4 1-39,51-169,171-599,601-1005
set trunk 4/4 auto negotiate 40-50,170,600,1025-4094
clear trunk 4/5 1-39,51-169,171-599,601-1005
set trunk 4/5 auto negotiate 40-50,170,600,1025-4094
clear trunk 4/6 1-39,51-169,171-599,601-1005
set trunk 4/6 auto negotiate 40-50,170,600,1025-4094
clear trunk 4/9 1-39,51-169,171-599,601-1005
set trunk 4/9 auto negotiate 40-50,170,600,1025-4094
clear trunk 4/10 1-39,51-169,171-599,601-1005
set trunk 4/10 auto negotiate 40-50,170,600,1025-4094
clear trunk 4/12 1000
set trunk 4/12 auto negotiate 1-999,1001-1005,1025-4094
clear trunk 4/13 1000
set trunk 4/13 auto negotiate 1-999,1001-1005,1025-4094
clear trunk 4/14 190,1000
set trunk 4/14 auto negotiate 1-189,191-999,1001-1005,1025-4094
clear trunk 4/15 1000
set trunk 4/15 auto negotiate 1-999,1001-1005,1025-4094
set spantree portfast
4/4-10 enable
set port channel 4/4,4/6,4/9-10,4/14 mode on
set port channel 4/2,4/5 mode off
!
#module 5 : 24-port 100BaseFX MM Ethernet
set vlan 1000 5/1-24
set port duplex
5/1-24 full
set port name
5/1 sh1-97 flash
set port name
5/2 sh1-98 flash
set port name
5/5 sh1-101 flash
set port name
5/6 sh1-102 flash
set port name
5/8 sh1-104 flash
set port name
5/19 sh1-106 flash
set port name
5/20 sh1-105 flash
set port name
5/21 sh1-108 flash
set port name
5/22 sh1-114 flash
set port name
5/23 sh1-107 flash
set port name
5/24 SH1-105-7/1
set spantree portfast
5/1,5/9 enable
!
#module 6 : 48-port 10/100BaseTX Ethernet
set vlan 10
6/14
set vlan 11
6/8
set vlan 16
6/9,6/20
set vlan 17
6/5
set vlan 18
6/45
set vlan 19
6/4
set vlan 20
6/6,6/10
set vlan 40
6/1,6/21-22
set vlan 41
6/2
set vlan 45
6/25
set vlan 47
6/7
set vlan 49
6/3
set vlan 50
6/11-12,6/15
set vlan 170 6/47
set vlan 190 6/17
set vlan 1000 6/13,6/23-24,6/43-44,6/46
set port speed
6/1-10,6/13-14,6/16,6/20-21,6/23-26,6/35-36,6/43-44,6/47
Cisco IOS Release 12.1(13)E13
240
100
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
set port duplex
6/1-10,6/13-14,6/16,6/20-21,6/23-24,6/26,6/35-36,6/43-44,6/47
set port name
6/1 IXIA 2/5
set port name
6/2 IXIA 5/2
set port name
6/3 IXIA 4/2
set port name
6/4 IXIA 5/2
set port name
6/5 IXIA 5/1
set port name
6/6 rtp-st-ipc1
set port name
6/7 IXIA 2/3
set port name
6/8 Ixia 8/3
set port name
6/9 Ixia 8/4
set port name
6/10 Ixia 8/6
set port name
6/12 IXIA 10/2
set port name
6/13 sh1-100 flash
set port name
6/14 IXIA 10/3
set port name
6/15 rtp-st-ips1
set port name
6/16 Ixia 10/6
set port name
6/17 Ixia 10/6
set port name
6/21 IXIA 10/7 DHCP
set port name
6/22 IXIA 10/8 DHCP
set port name
6/23 SH1-113 flashnet
set port name
6/24 SH1-114 flashnet
set port name
6/36 SH1-97 Fa8/44
set port name
6/43 sh1-109 flash
set port name
6/44 sh1-110 flash
set port name
6/45 rtp-st-ipc2
set port name
6/46 sh1-103 flash
set port name
6/47 rtp-wbu-te-p4 fa3/0
set port name
6/48 rtp-wbu-knx1 eth1
clear trunk 6/16 1-9,11-39,41-1005,1025-4094
set trunk 6/16 on dot1q 10,40
set trunk 6/25 off negotiate 1-1005,1025-4094
clear trunk 6/48 1-9,11-39,41-96,98-1005,1025-4094
set trunk 6/48 on dot1q 10,40,97
set spantree portfast
6/1-48 enable
!
#module 15 empty
!
#module 16 empty
!
#switch port analyzer
set rspan source 6/36 97 both multicast enable create
end
dista-2> (enable) show version
WS-C6506 Software, Version NmpSW: 6.4(8)
Copyright (c) 1995-2004 by Cisco Systems
NMP S/W compiled on Jan 6 2004, 15:03:09
full
System Bootstrap Version: 6.1(3)
Hardware Version: 2.0
PS1
Model: WS-C6506
Module: WS-CAC-1300W
Serial #: TBA03310403
Serial #: ACP03300280
Mod Port Model
Serial #
Versions
--- ---- ------------------- ----------- -------------------------------------1
2
WS-X6K-SUP2-2GE
SAD05080H4J Hw : 2.2
Fw : 6.1(3)
Fw1: 6.1(3)
Sw : 6.4(8)
Sw1: 6.4(8)
WS-F6K-PFC2
SAD05080LLD Hw : 1.3
2
16
WS-X6416-GBIC
SAL0745PD34 Hw : 2.5
Fw : 5.4(2)
Sw : 6.4(8)
Cisco IOS Release 12.1(13)E13
241
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Financial Lab Topology
3
8
WS-X6408A-GBIC
4
16
WS-X6416-GE-MT
5
24
WS-X6324-100FX-MM
6
48
WS-X6248A-RJ-45
SAD043500H1 Hw
Fw
Sw
SAD03441943 Hw
Fw
Sw
SAD0551070A Hw
Fw
Sw
SAD03406770 Hw
Fw
Sw
:
:
:
:
:
:
:
:
:
:
:
:
1.3
5.4(2)
6.4(8)
1.0
5.3(1)
6.4(8)
3.0
5.4(2)
6.4(8)
1.1
5.1(1)CSX
6.4(8)
DRAM
FLASH
NVRAM
Module Total
Used
Free
Total
Used
Free
Total Used Free
------ ------- ------- ------- ------- ------- ------- ----- ----- ----1
131072K 64348K 66724K 32768K 25082K
7686K 512K 306K 206K
Uptime is 37 days, 19 hours, 4 minutes
dista-2> (enable) show module
Mod Slot Ports Module-Type
--- ---- ----- ------------------------1
1
2
1000BaseX Supervisor
2
2
16
1000BaseX Ethernet
3
3
8
1000BaseX Ethernet
4
4
16
1000BaseSX Ethernet
5
5
24
100BaseFX MM Ethernet
6
6
48
10/100BaseTX Ethernet
Mod Module-Name
--- -------------------1
2
3
4
5
6
Model
------------------WS-X6K-SUP2-2GE
WS-X6416-GBIC
WS-X6408A-GBIC
WS-X6416-GE-MT
WS-X6324-100FX-MM
WS-X6248A-RJ-45
Sub
--yes
no
no
no
no
no
Status
-------ok
ok
ok
ok
ok
ok
Serial-Num
----------SAD05080H4J
SAL0745PD34
SAD043500H1
SAD03441943
SAD0551070A
SAD03406770
Mod MAC-Address(es)
--- -------------------------------------1
00-d0-c0-d4-9e-32 to 00-d0-c0-d4-9e-33
00-d0-c0-d4-9e-30 to 00-d0-c0-d4-9e-31
00-d0-d3-07-f8-00 to 00-d0-d3-07-fb-ff
2
00-0e-38-4b-18-28 to 00-0e-38-4b-18-37
3
00-30-b6-3e-fc-c0 to 00-30-b6-3e-fc-c7
4
00-30-96-2b-0a-28 to 00-30-96-2b-0a-37
5
00-08-a4-30-0a-f8 to 00-08-a4-30-0b-0f
6
00-d0-d3-28-bd-50 to 00-d0-d3-28-bd-7f
Hw
Fw
Sw
------ ---------- ----------------2.2
6.1(3)
6.4(8)
2.5
1.3
1.0
3.0
1.1
5.4(2)
5.4(2)
5.3(1)
5.4(2)
5.1(1)CSX
6.4(8)
6.4(8)
6.4(8)
6.4(8)
6.4(8)
Mod Sub-Type
Sub-Model
Sub-Serial Sub-Hw
--- ----------------------- ------------------- ----------- -----1
L3 Switching Engine II WS-F6K-PFC2
SAD05080LLD 1.3
dista-2> (enable)
Return to Dista-2, page 237
Cisco IOS Release 12.1(13)E13
242
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Test Results Summary
Test Results Summary
Table 1 summarizes the tests to be executed as part of the Cisco IOS Safe Harbor initiative. Table 1
includes the feature or function tested, the section that describes the feature set the feature or function
belongs to, the component tests for each feature or function, and whether the test is new in this iteration
of Safe Harbor testing.
Table 1
Safe Harbor Test Plan Summary
Test Suites
Feature/Function
Tests
Results
Memory Leak
Memory Leak, page 249
Repeated Telnet to Supervisor 11
Pass
Repeated Telnet to Supervisor 12
Repeated Telnet to Supervisor 22
Repeated SSH to Supervisor 11
CSCeb55703
Repeated SSH to Supervisor 12
Repeated SSH to Supervisor 22
Multicast Flap Memory
Hardware
Redundancy
Hardware Redundancy, page 255
Switch Fabric Module Failover
Pass
Supervisor 1 Failover
Supervisor 2 Failover
Power Supply Failure—Supervisor 1
Power Supply Failure—Supervisor 2
RPR+: Supervisor Hot Insert
Layer 2 Features
Unidirectional Link
Detection-Aggressive Mode,
page 262
Basic UDLD on Layer 2 Link
Trunking, page 264
Sup 1 Configuration and Failure Recovery
Pass
Basic UDLD on Layer 3 Link
Pass
Sup 2 Configuration and Failure Recovery
Port Aggregation Protocol
(Channeling), page 267
Basic Layer 2 Channeling Configuration
Pass
Basic Layer 3 Channeling Configuration
Layer 2 EtherChannel Load Balancing
Layer 3 EtherChannel Load Balancing
Layer 2 EtherChannel Failure and
Recovery—Supervisor 1
Layer 3 EtherChannel Failure and
Recovery—Supervisor 1
Layer 2 EtherChannel Failure and
Recovery—Supervisor 2
Layer 3 EtherChannel Failure and
Recovery—Supervisor 2
Gigabit Ethernet Module Reset—Sup 1
Gigabit Ethernet Module Reset—Sup 2
Cisco IOS Release 12.1(13)E13
243
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Test Results Summary
Table 1
Safe Harbor Test Plan Summary (continued)
Test Suites
Feature/Function
Tests
Results
Layer 2 Features
VLAN Trunking Protocol, page 282
Basic VLAN Trunking Protocol Configuration
Pass
Layer 3 Routing
Features
IP Multicast, page 285
Last-Hop Router Functionality
Pass
First-Hop Router Functionality
Basic Static RP Functionality—Supervisor 11
CSCea21798
Basic Static RP Functionality—Supervisor 22
CSCed73091
Basic Auto RP Functionality—Supervisor 22
Auto PIM RP Failover—First Hop Router
Impact—Supervisor 11
Auto PIM RP Failover—First Hop Router
Impact—Supervisor 12
Auto PIM RP Failover—First Hop Router
Impact—Supervisor 22
Auto PIM RP Failover—Traffic Impact—Supervisor
22
Static PIM-RP Failover—Supervisor 11
Static PIM-RP Failover—Supervisor 22—RP Impact
Static PIM-RP Failover—Supervisor 22—First-Hop
Router Impact
Static PIM-RP Failover—Supervisor 22—Traffic
Impact
Basic IGMP Functionality
IGMP Leave/Join Functionality
Non-RPF Rate Limiting and Multicast
Stub—Supervisor 1
Non-RPF Rate Limiting and Multicast
Stub—Supervisor 2
Layer 2 GEC Failover—SH1-110 to Dista-2
Layer 2 GEC Failover—SH1-108 to Dista-1
Layer 2 GEC Failover—SH1-114 to Dista-1
Layer 2 GEC Failover—SH1-106 to Dista-2
Layer 2 GEC Failover—SH1-102 to Dista-1
Layer 3 GEC Failover—SH1-104 to SH1-110
Layer 3 GEC Failover—SH1-104 to SH1-109
Layer 3 GEC Failover—SH1-104 to SH1-108
Layer 3 GEC Failover—SH1-104 to SH1-107
Layer 3 GEC Failover—SH1-100 to SH1-104
Layer 3 GEC Failover—SH1-100 to SH1-113
Cisco IOS Release 12.1(13)E13
244
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Test Results Summary
Table 1
Safe Harbor Test Plan Summary (continued)
Test Suites
Feature/Function
Tests
Results
Layer 3 Routing
Features
IP Multicast, page 285
Layer 3 GEC Failover—SH1-100 to SH1-106
Pass
Layer 3 GEC Failover—SH1-100 to SH1-105
Layer 3 GEC Failover—SH1-100 to SH1-102
Layer 3 GEC Failover—SH1-100 to SH1-101
Layer 3 GEC Failover—SH1-100 to SH1-97
Switch Fabric Module Failover—Supervisor 22
GEM Failover—Supervisor 11 as First-Hop Router
GEM Failover—Supervisor 11 as Last-Hop Router
GEM Failover—Supervisor 11 with Directly
Connected Layer 3 Interface
GEM Failover—Supervisor 22 as First-Hop Router
GEM Failover—Supervisor 22 as Last-Hop Router
GEM Failover—Supervisor 22 as Static RP
GEM Failover—Supervisor 22 as Auto RP
GEM Failover—Supervisor 22 with Directly
Connected Layer 3 Interface
Protocol Independent Module-Designated Router
Failover—Supervisor 11
Protocol Independent Module-Designated Router
Failover—Supervisor 22
Auto-RP Failover—RP Impact
Cisco Express Forwarding, page 396
CEF Packet Switching
Pass
CEF Route Entries on DFC
CEF Many-to-One Distribution Load Balance
CEF Many-to-Many Distribution with Polarization
Load Balance
Open Shortest Path First, page 405
OSPF Autocost
Pass
OSPF Passive Interface
OSPF Filtering
OSPF Redistribution
OSPF Topology Database Verification
Cisco IOS Release 12.1(13)E13
245
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Test Results Summary
Table 1
Safe Harbor Test Plan Summary (continued)
Test Suites
Feature/Function
Tests
Results
Layer 3 Routing
Features
Border Gateway Protocol, page 414
Add 120,000 Routes
Pass
Redistribution OSPF into BGP
Redistribution EIGRP into BGP
Redistribution OSPF and EIGRP into BGP
BGP Neighbor Flap
BGP Neighbor Flap—With Dampening
BGP Neighbor Flap—No Dampening
Hot Standby Routing Protocol,
page 424
HSRP Failover with Default Timers—Supervisor 11
Pass
HSRP Failover with Default Timers—Sup
22—Compact Switching Mode
HSRP Failover with Default Timers—Sup
22—Truncated Switching Mode
HSRP Failover with Fast Timers—Supervisor 11
HSRP Failover with Fast Timers—Supervisor 22
Impact of HSRP Traffic on CPU
HSRP Maximum Group Limit
GEM Failover with Attached HSRP Groups
Network
Management
Features
Enhanced Interior Gateway Routing
Protocol, page 437
EIGRP Summarization
Simple Network Management
Protocol, page 442
Basic Functionality Shut/No Shut
Interface—Supervisor 11
Pass
EIGRP Redistribution
Pass
Basic Functionality Shut/No Shut
Interface—Supervisor 22
Protos Negative Request Application
TACACS, page 445
User Authentication—Supervisor 11
Pass
User Authentication—Supervisor 22
Miscellaneous
Features
Dynamic Host Control Protocol,
page 447
Basic DHCP—Supervisor 11
Switched Port Analyzer, page 450
SPAN Basic Functionality
Pass
Access Control Lists, page 452
ACL 110 Supervisor 11
Pass
Basic DHCP—Supervisor 22
ACL 110 Supervisor 12
ACL 110 Supervisor 22
ACL 131 Supervisor 11
ACL 131 Supervisor 12
ACL 131 Supervisor 22
Cisco IOS Release 12.1(13)E13
246
Pass
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Test Results Summary
Table 1
Safe Harbor Test Plan Summary (continued)
Test Suites
Feature/Function
Tests
Results
Miscellaneous
Features
Parser, page 458
Show-All Script via Telnet Supervisor 11
Pass
Show-All Script via Telnet Supervisor 12
Show-All Script via Telnet Supervisor 22
Show-All Script via SSH Supervisor 11
Show-All Script via SSH Supervisor 12
Show-All Script via SSH Supervisor 22
Network Address Translation,
page 463
Static 2 Hosts
Pass
Static 40 Hosts
Static 40 Hosts Extended
Static 2 Networks
Static Inside Dynamic Outside
Dynamic Inside Static Outside
Addition/Removal of NAT Statements
Static 40 Hosts Overnight
Network Time Protocol, page 472
Increment Inside Random Outside with Match-Host
New
Basic NTP Functionality—Supervisor 1
Pass
Basic NTP Functionality—Supervisor 2
NTP Failover—Supervisor 1 and Supervisor 2
Syslog, page 476
Basic Syslog Functionality—Supervisor 1
Pass
Basic Syslog Functionality—Supervisor 2
User Datagram Protocol Broadcast
Flooding, page 477
UDP Broadcast Flooding
Pass
System Upgrade, page 480
Cisco IOS 12.1(8b)E15 to 12.1(13)E13
Upgrade—Supervisor 11
Pass
Cisco IOS 12.1(8b)E15 to 12.1(13)E13
Upgrade—Supervisor 12
Cisco IOS 12.1(8b)E15 to 12.1(13)E13
Upgrade—Supervisor 22
Cisco IOS 12.1(13)E6 to 12.1(13)E13
Upgrade—Supervisor 11
Cisco IOS 12.1(13)E6 to 12.1(13)E13
Upgrade—Supervisor 12
Cisco IOS 12.1(13)E6 to 12.1(13)E13
Upgrade—Supervisor 22
Secure Shell, page 485
SSH Server Vulnerability
Pass
Cisco IOS Release 12.1(13)E13
247
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
DDTS Summary
DDTS Summary
Table 2 lists Development Defect Tracking System (DDTS) software bugs, descriptions, and comments
filed by the Safe Harbor testing team during Cisco Native IOS Release 12.1(13)E13 testing. Table 3 lists
DDTS and descriptions encountered during Cisco Native IOS Release 12.1(13)E13 testing.
Table 2
Summary of DDTS Filed During Cisco Safe Harbor Native IOS 12.1(13)E13 Testing
DDTS
Description
CSCeb55703
Externally found moderate defect: More (M). Cannot ssh to router - crc comparison
failed.
CSCea21798
Internally found moderate defect: Duplicate (D). Packet loadbalancing is inconsistent
between 12.1E and 12.2S
CSCed73091
Internally found moderate defect: Awaiting Info (I). Spurious memory access during
reload - bgp.
Table 3
DDTS
Summary of DDTS Encountered During Cisco Safe Harbor Native IOS 12.1(13)E13 Testing
Description
CSCec58642 Spurious access: Traceback in pm_fc_print_fc_of_idb. Fixed in Const2
(CSCdz24826) and cosmos_e (CSCeb12301)
Cisco IOS Release 12.1(13)E13
248
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Test Cases
Test Cases
Functionality critical to the global financial service business tested for the Cisco IOS Safe Harbor release
is described in the following sections:
Note
•
Memory Leak, page 249
•
Hardware Redundancy, page 255
•
Layer 2 Features, page 262
•
Layer 3 Routing Features, page 285
•
Network Management Features, page 442
•
Miscellaneous Features, page 447
For a compete list of Cisco IOS commands and usage, refer to:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/index.htm
Memory Leak
Testing for memory leaks occurred each evening of a regular workday. The last regular test of the day
that is performed was repeated throughout the night, with the memory being recorded for each device in
the network. The duration of each memory leak test is approximately 16 hours, or from 5 p.m. to 9 a.m.
the next morning. On weekends, the test was run for the entire weekend, or approximately 64 hours, from
5 p.m. Friday evening until 9 a.m. Monday morning.
The testing that occurred for this iteration was a repetition of the EIGRP route summarization test.
Summarization was configured on devices SH1-99 and SH1-100, followed by a 5-minute sleep period.
Then summarization was removed from the same devices, followed by another 5-minute sleep period.
This cycle was repeated overnight. SNMP polls were taken every 5 minutes and the results for the
Memory Free for each device displayed.
Whenever a fault was encountered, the redundant module took over the functions of the failed hardware
module. Memory leak testing for Safe Harbor involved performing various failover scenarios to verify
that internal hardware redundancy failed over as expected.
The following tests were performed:
•
Repeated Telnet to Supervisor 11, page 249
•
Repeated Telnet to Supervisor 12, page 250
•
Repeated Telnet to Supervisor 22, page 251
•
Repeated SSH to Supervisor 11, page 251
•
Repeated SSH to Supervisor 12, page 252
•
Repeated SSH to Supervisor 22, page 253
•
Multicast Flap Memory, page 253
Repeated Telnet to Supervisor 11
This test verified that repeated Telnets to supervisor 11 did not impact memory or system stability.
Devices under test: SH1-105 (sup 11).
Cisco IOS Release 12.1(13)E13
249
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Memory Leak
Test Procedure
The procedure used to perform the Repeated Telnet to Supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Telnet into each DUT repeatedly (2500 times into SH1-105).
Step 5
Display the log for error messages.
Step 6
Verify that memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that the DUT does not become unresponsive or leak memory.
Results
Table 4
Repeated Telnet to Supervisor 11 Test Results
Test
Result
Repeated Telnet to Supervisor 11
Pass
Repeated Telnet to Supervisor 12
This test verified that repeated Telnets to supervisor 12 did not impact memory or system stability.
Devices under test: SH1-107 (sup 12).
Test Procedure
The procedure used to perform the Repeated Telnet to Supervisor 12 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Telnet into the DUT repeatedly (2500 times into SH1-107).
Step 5
Display the log for error messages.
Step 6
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that the DUT does not become unresponsive or leak memory.
Cisco IOS Release 12.1(13)E13
250
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Memory Leak
Results
Table 5
Repeated Telnet to Supervisor 12 Test Results
Test
Result
Repeated Telnet to Supervisor 12
Pass
Repeated Telnet to Supervisor 22
This test verified that repeated Telnets to supervisor 22 did not impact memory or system stability.
Devices under test: SH1-109 (sup 22).
Test Procedure
The procedure used to perform the Repeated Telnet to Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Telnet into each DUT repeatedly (1000 times into SH1-109).
Step 5
Display the log for error messages.
Step 6
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that the DUT does not become unresponsive or leak memory.
Results
Table 6
Repeated Telnet to Supervisor 22 Test Results
Test
Result
Repeated Telnet to Supervisor 22
Pass
Repeated SSH to Supervisor 11
This test verified that repeated SSH to supervisor 11 did not impact memory or system stability.
Devices under est: SH1-106 (sup 11).
Test Procedure
The procedure used to perform the Repeated SSH to Supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Cisco IOS Release 12.1(13)E13
251
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Memory Leak
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Telnet into each DUT repeatedly (1000 times into SH1-106).
Step 5
Display the log for error messages.
Step 6
Verify that memory and the CPU did not suffer severe, sustained, or unacceptable impact.
Note
The polling occurred over a 5-hour period of time.
Expected Results
•
We expect that the DUT does not become unresponsive or leak memory.
Results
Table 7
Repeated SSH to Supervisor 11 Test Results
Test
Result
Repeated SSH to Supervisor 11
Pass with exception CSCeb55703
Repeated SSH to Supervisor 12
This test verified that repeated SSH to supervisor 12 did not impact memory or system stability.
Devices under test:SH1-108 (sup 12).
Test Procedure
The procedure used to perform the Repeated SSH to Supervisor 12 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Telnet into each DUT repeatedly (1000 times into SH1-108).
Step 5
Display the log for error messages.
Step 6
Verify that memory and the CPU did not suffer severe, sustained, or unacceptable impact.
Note
The polling occurred over a 60-hour period of time.
Expected Results
•
We expect that the DUT does not become unresponsive or leak memory.
Cisco IOS Release 12.1(13)E13
252
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Memory Leak
Results
Table 8
Repeated SSH to Supervisor 12 Test Results
Test
Result
Repeated SSH to Supervisor 12
Pass with exception CSCeb55703
Repeated SSH to Supervisor 22
This test verified that repeated SSH to supervisor 22 did not impact memory or system stability.
Devices under test: SH1-109 (sup 22).
Test Procedure
The procedure used to perform the Repeated SSH to Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Telnet into each DUT repeatedly (1000 times into SH1-109).
Step 5
Display the log for error messages.
Step 6
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that the DUT does not become unresponsive or leak memory.
Results
Table 9
Repeated SSH to Supervisor 22 Test Results
Test
Result
Repeated SSH to Supervisor 22
Pass
Multicast Flap Memory
This test tracked the effects on memory utilization of the continuous addition and removal of mroutes
on a given device. There were three sets of multicast traffic used, one for each platform: Sup11, Sup12,
and Sup22. In each case, a Layer 2 switch is the first-hop device. For the 500 groups
239.100.[1,11].[1-250], SH1-114 and SH1-113 are PIM neighbors on the traffic source VLAN. SH1-114
is the first-hop router and maintains (*, G) and (S, G) entries for each of the 250 groups. An automated
script shuts down the Layer 2 link (portchannel 10) to the L2 switch (Dusty-1) for a period of 15 minutes.
SH1-113 becomes the first-hop router at this point, building (*, G) and (S, G) states for the 250 groups.
The 15-minute time period is long enough for all group mroute states to time out and be deleted on
Cisco IOS Release 12.1(13)E13
253
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Memory Leak
SH1-114. After 15 minutes, the Layer 2 link is brought back up, SH1-114 will rebuild the mroute entries
for each group. This link will remain up for another 15 minutes, long enough for all entries on SH1-113
to time out and be deleted.
SH1-114 and SH1-113 are Supervisor1/MSFC2 devices. The same pattern was created for Supervisor11
and Supervisor22 devices, as well. SH1-106 and SH1-105 were the Sup11 first-hop routers for groups
239.100.[2,12].[1-250]. SH1-110 and SH1-109 were the Sup22 first-hop routers for groups
239.100.[3,13].[1-250].
At the same time as the mroute entries are being created/deleted on the three pairs of devices, the
following is taking place on other devices in the network:
•
SH1-102 connectivity is being broken to the rest of the network, causing any traffic to go through
SH1-101.
•
SH1-100 connectivity is being broken to the rest of the network, causing SH1-99 to become the
primary PIM-RP for 1500+ mcast groups.
•
A clear ip mroute * command is being issued on SH1-104 every 6 minutes.
•
A clear ip route * command is being issued on SH1-98 every 5 minutes.
•
A clear ip route * command is being issued on SH1-101 every 5 minutes.
•
Interface FastEthernet8/14 on SH1-97 is being flapped every 10 minutes, removing the 5000 OSPF
routes being supplied by the Pagent test tool.
•
BGP peer flapping is configured to run as it did in the BGP Neighbor Flap test.
A summary of the plan of action for this test is here:
mem_leaks/mcast_flap_mem/plan_of_action.txt
Test Procedure
The procedure used to perform the Multicast Flap Memory test follows:
Step 1
Use the appropriate script to gather preliminary logging and version information. This script will also
begin the SNMP polling for CPU and memory usage for all Native IOS devices in the SH1 network.
Step 2
Gather an initial snapshot of all memory processes for all devices in the network.
Step 3
Alter the IXIA stream/receiver configuration so that the three sources are sending to 500 groups, from a
single IP source address, and the receivers are joining 500 groups.
Step 4
Begin the flap test. Let this test run over a weekend, at the least.
Step 5
Stop the flap test.
Step 6
Gather a final snapshot of all memory processes for all devices in the network.
Step 7
Verify that there has been no memory degradation from the initial snapshot to the final snapshot.
Step 8
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 9
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Note
The polling occurred over a 63-hour period of time.
Cisco IOS Release 12.1(13)E13
254
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Hardware Redundancy
Expected Results
•
We expect that the memory free and memory largest free values would trend steady over the duration
of the test for each respective device.
Results
Table 10
Multicast Flap Memory Test Results
Test
Result
Multicast Flap Memory
Pass
Hardware Redundancy
Whenever a fault was encountered, the redundant module took over the functions of the failed hardware
module. Testing hardware redundancy for Safe Harbor involved performing various failover scenarios
to verify that internal hardware redundancy failed over as expected.
The following tests were performed:
Note
•
Switch Fabric Module Failover, page 255
•
Supervisor 1 Failover, page 257
•
Supervisor 2 Failover, page 258
•
Power Supply Failure—Supervisor 1, page 259
•
Power Supply Failure—Supervisor 2, page 260
•
RPR+: Supervisor Hot Insert, page 261
For this iteration, and all subsequent iterations of testing, the total number of OSPF routes fed into the
network was reduced to 10,000. This change better reflected recommendations established and outlined
in Cisco IOS Release Notes for release 12.1 E at
http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/12_1e/ol_2310.htm#62683 for use with
RPs that have 128 MB of memory. Many devices in the Safe Harbor network have only 128 MB of
memory, limiting total routes to 20,000, using fixed-length masks.
Switch Fabric Module Failover
This test verified multicast functionality during Switch Fabric Module (SFM) failover. Unicast traffic
was sourced from IXIA and transits through SH1-102. The traffic was switched using the crossbar fabric.
This test performed a series of resets on the active SFM and measure traffic loss at each iteration.
In several of the following steps, verification that the traffic was using the SFM was requested. Examine
how the Medusa ASIC was handling traffic. The Medusa ASIC interfaces were between the line card
local bus and the backplane of the Catalyst 6500. If traffic was using the SFM (no legacy, or
nonfabric-enabled cards present), the Medusa mode was “Compact” for all line cards, indicating that it
was sending a compact header on the backplane for the switching decision.
Cisco IOS Release 12.1(13)E13
255
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Hardware Redundancy
Note
Any WS-X6816 modules were always in "Compact" mode, because they were fabric-only cards. More
on the switching modes involving the SFM can be found at the Cisco Catalyst 6500 Series Switches site:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter0918
6a008007fb2a.html
Goals
•
Verify that the router is using the crossbar fabric to switch the traffic prior to SFM failover.
•
Verify that the router is using the crossbar fabric to switch the traffic after the SFM failover.
•
Verify that failover times are within acceptable parameters.
Primary Devices Used
•
SH1-102: Supervisor 22; first hop router for unicast test traffic stream
Primary IXIA Ports Used
2/8, 5/1
Test Procedure
The procedure used to perform the Switch Fabric Module Failover test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-102 is receiving unicast traffic on portchannel 10 and transmitting the traffic on
portchannels 15 and 115.
Step 5
Verify that portchannels 10, 15, and 115 consist of interfaces on fabric-enabled line cards.
Portchannels 10, 15, and 115 are comprised of interfaces from modules 7 and 3.
Module 7 (WS-X6516-GBIC) is a fabric-enabled module. Module 3 (WS-X6816-GBIC) is a pure fabric
module. So both should be using the fabric to switch traffic.
Step 6
Verify that all fabric-enabled modules are using the crossbar fabric to switch the traffic.
Modules 3 and 7 are not in bus mode, so they are using the fabric to switch traffic.
Step 7
Start the test script that will failover the active fabric module on SH1-102 50 times while running traffic.
Step 8
Analyze the results from the script and verify that failover times are within tolerances.
Step 9
Display the log for error messages.
Step 10
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect failovers to occur within an acceptable amount of time and that traffic loss due to fabric
failure should be minimal.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco IOS Release 12.1(13)E13
256
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Hardware Redundancy
Results
Table 11
Switch Fabric Module Failover Test Results
Test
Result
Switch Fabric Module Failover
Pass
Supervisor 1 Failover
This test verified the proper operation of redundant supervisors during a series of 20 continual resets.
This test verified that the box fails between the supervisors as designed, recovers, and forwards traffic.
This test further verified that failure operations are within the design guidelines for the applicable
hardware and software versions under test. Although this test measures time, it is by no means a measure
of the speed at which failover can take place, which as this is dependent upon the configuration and line
cards in the system.
Supervisor Engine 2s are covered in this test. The device under test is SH1-107. A traffic stream was sent
from Dista-1 to Dista-2 a a fixed rate. The amount of traffic loss during device resets was used to
determine the recovery time (failover time).
Test Procedure
The procedure used to perform the Supervisor 1 Failover test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Display some of the factors that may contribute to reload times. Such factors may include configuration
size, memory used, size of IP routing table.
Step 5
Shutdown interface portchannel 10 on device SH1-108. This will ensure that the test traffic has to go
through SH1-107 to get to its destination.
Step 6
Begin the IXIA background unicast traffic stream #1. This will send traffic at a rate of 10,000pps from
Dista-1 to SH1-99. Send a 5-minute burst of traffic.
Step 7
Perform a forced switchover on SH1-107.
Step 8
Show how much traffic was received out of 3,000,000 packets sent. Measure the time that the switch was
down.
Step 9
Repeat the switchover sequence four more times, each time gathering statistics on traffic loss.
Step 10
Give the average time it took for the device to switch over, over the five iterations.
Step 11
Display the log for error messages.
Step 12
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect all resets of the supervisor to fall within the 1-2 min range.
Cisco IOS Release 12.1(13)E13
257
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Hardware Redundancy
Note
This time differs from the results in 12.1(8b)E15 testing as RPR+ is now the redundancy feature,
allowing for faster switchover times.
•
We expect the supervisors to come back online without any manual intervention.
Results
Table 12
Supervisor 1 Failover Test Results
Test
Result
Supervisor 1 Failover
Pass
Supervisor 2 Failover
This test verified the proper operation of redundant supervisors during a series of 20 continual resets.
This test verified that the box fails between the supervisors as designed, recovers, and forwards traffic.
This test further verified that failure operations are within the design guidelines for the applicable
hardware and software versions under test. Although this test measures time, it is by no means a measure
of the speed at which failover can take place, which is dependent upon the configuration and line cards
in the system.
Supervisor Engine 2s are covered in this test. The device under test is SH1-110. A traffic stream was sent
from Dista-1 to Dista-2 a a fixed rate. The amount of traffic loss during device resets was used to
determine the recovery time (failover time).
Test Procedure
The procedure used to perform the Supervisor 2 Failover test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Display some of the factors that may contribute to reload times. Such factors may include configuration
size, memory used, size of IP routing table.
Step 5
Shutdown interface portchannel 20 on device SH1-109. This will ensure that the test traffic has to go
through SH1-110 to get to its destination.
Step 6
Begin the IXIA background unicast traffic stream #3. This will send traffic at a rate of 10,000pps from
Dista-2 to Dista-1. Send a 5-minute burst of traffic.
Step 7
Perform a redundancy force-switchover on SH1-110.
Step 8
Show how much traffic was received out of 3,000,000 packets sent. Measure the time that the switch was
down.
Step 9
Repeat the switchover sequence four more times, each time gathering statistics on traffic loss.
Step 10
Give the average time it took for the device to switch over, over the five iterations.
Step 11
Display the log for error messages.
Cisco IOS Release 12.1(13)E13
258
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Hardware Redundancy
Step 12
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect all resets of the supervisor to fall within the 1-2 min range.
•
We expect supervisors to come back online without any manual intervention.
Results
Table 13
Supervisor 2 Failover Test Results
Test
Result
Supervisor 2 Failover
Pass
Power Supply Failure—Supervisor 1
This test verified the failure of a power supply in a supervisor 1-based system. The power supply was
failed via removal of the power module.
Test Procedure
The procedure used to perform the Power Supply Failure—Supervisor 1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the power supplies of SH1-106 are operating in redundant mode and that the capacity of each
individual power supply is sufficient to meet the needs of the device.
Step 5
Begin sending a test traffic stream through SH1-106. In this case it will be background unicast stream #
5.
Step 6
Simulate a power supply failure.
Step 7
Verify that the system is still operational with only one power supply.
Step 8
Measure any traffic loss that occurred as a result of the simulated power supply failure.
Step 9
Begin sending a test traffic stream through SH1-106.
Step 10
Re-insert the power supply in SH1-106.
Step 11
Verify that the second power supply has come back online.
Step 12
Measure any traffic loss that occurred as a result of the power supply re-insertion.
Step 13
Display the log for error messages.
Step 14
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco IOS Release 12.1(13)E13
259
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Hardware Redundancy
Expected Results
•
We expect no line card failures due to the removal or insertion of the power supply.
•
We expect no packet loss due to the removal or insertion of the power supply.
Results
Table 14
Power Supply Failure—Supervisor 1 Test Results
Test
Result
Power Supply Failure—Supervisor 1
Pass
Power Supply Failure—Supervisor 2
This test verified the failure of a power supply in a Supervisor 2-based system. The power supply was
failed via removal of the power module.
Test Procedure
The procedure used to perform the Power Supply Failure—Supervisor 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the power supplies of SH1-101 are operating in redundant mode and that the capacity of each
individual power supply is sufficient to meet the needs of the device.
Step 5
Begin sending a test traffic stream through SH1-101. In this case it will be multicast test traffic stream
A (210,000 packets at 1000 pps), for which SH1-101 has a directly connected Layer 3 receiver.
Step 6
Simulate a power supply failure.
Step 7
Verify that the system is still operational with only one power supply.
Step 8
Measure any traffic loss that occurred as a result of the simulated power supply failure.
Step 9
Begin sending a test traffic stream through SH1-101.
Step 10
Re-insert the power supply in SH1-101.
Step 11
Verify that the second power supply has come back online.
Step 12
Measure any traffic loss that occurred as a result of the power supply re-insertion.
Step 13
Display the log for error messages.
Step 14
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect no line card failures due to the removal or insertion of the power supply.
•
We expect no packet loss due to the removal or insertion of the power supply.
Cisco IOS Release 12.1(13)E13
260
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Hardware Redundancy
Results
Table 15
Power Supply Failure—Supervisor 2 Test Results
Test
Result
Power Supply Failure—Supervisor 2
Pass
RPR+: Supervisor Hot Insert
This test verified the ability of an unconfigured supervisor to be inserted as redundant into a device and
be loaded with the system configuration.
Test Procedure
The procedure used to perform the RPR+: Supervisor Hot Insert test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Remove the redundant supervisor of device SH1-110.
Step 5
Perform a write erase/reload sequence on SH1-110 to erase any configuration.
Step 6
Wait for reload to complete. Remove the unconfigured supervisor and re-insert the configured
supervisor.
Step 7
Wait for reload to complete. Hot-insert the unconfigured supervisor.
Step 8
Having verified the new supervisor comes online, force a switchover to verify that the redundant
supervisor has a full configuration.
Step 9
Display the log for error messages.
Step 10
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the blank (unconfigured) supervisor to come online and obtain a copy of the configuration
from the active supervisor.
•
We expect the standby supervisor to have the correct configuration in the event it becomes active.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 16
RPR+: Supervisor Hot Insert Test Results
Test
Result
RPR+: Supervisor Hot Insert
Pass
Cisco IOS Release 12.1(13)E13
261
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Layer 2 Features
Layer 2 feature testing for Safe Harbor involves the features:
•
Unidirectional Link Detection-Aggressive Mode, page 262
•
Trunking, page 264
•
Port Aggregation Protocol (Channeling), page 267
•
VLAN Trunking Protocol, page 282
Unidirectional Link Detection-Aggressive Mode
The Unidirectional Link Detection (UDLD) protocol allows devices connected through fiber-optic or
copper Ethernet cables (for example, Category 5 cabling) to monitor the physical status of the cables and
detect when a unidirectional link exists. When a unidirectional link is detected, UDLD shuts down the
affected port and alerts the user. Unidirectional links can cause a variety of problems, including
spanning-tree topology loops and erroneous Layer 3 routing.
In a bidirectional relationship, the UDLD-AM (aggressive mode) protocol disables the port at the end of
a link-up sequence if no reply is received. However, UDLD goes into an undetermined state.
The lowest value of a UDLD-AM message interval can be only 7 seconds, and the hold down time can
be 21 seconds.
Note
The lowest value of UDLD-AM message interval can be only 7 seconds, and the hold down time can be
21 sec. By default, the HSRP hello timer is 3 sec. and the hold down timer is 10 sec. When the link
becomes unidirectional, before the UDLD-AM can shut down the port, the HSRP will flap. After
UDLD-AM shuts down the unidirectional port, the HSRP will stay up and be stable.
Note
The lowest value of UDLD-AM message interval can be only 7 seconds, and the hold down time can be
21 sec. By default, EIGRP hello timer is 5 sec. and hold down timer is 15 sec. When the link becomes
unidirectional, before the UDLD-AM can shut down the port, the EIGRP neighbor will flap. After
UDLD-AM shuts down the unidirectional port, the EIGRP neighbor will stay up and be stable.
Note
If UDLD mode or UDLD-AM are enabled globally on Layer 3 switches, the interface shows the UDLD
message interval is 7 sec which is actually "running message interval." Once the UDLD neighbor is
established, the message interval changed to 60 sec. See CSCdv74001, which is integrated in Herschel
8EX and will be in Cisco IOS Release 13E but not Cisco IOS Release 8E.
The following tests were performed:
•
Basic UDLD on Layer 2 Link, page 262
•
Basic UDLD on Layer 3 Link, page 263
Basic UDLD on Layer 2 Link
This test created a unidirectional link between SH1-109 (DUT) and Dista-2. Console messages are
logged during the mock failure, and port states are recorded.
Cisco IOS Release 12.1(13)E13
262
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Test Procedure
The procedure used to perform the Basic UDLD on Layer 2 Link test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Confirm that UDLD is configured globally on the DUT and that UDLD Aggressive Mode is configured
locally on the interface g7/3.
Step 5
With terminal monitoring configured, pull the receive fiber from port 1/1 on Dista-2. Log any messages
on the DUT. Confirm the interface state of g7/3 on the DUT.
Step 6
Reconnect the transmit fiber. Record any log messages on the DUT and confirm the interface state. Issue
the udld reset command on the DUT, if the interface g7/3 does not return to up/up state.
Note
The udld reset command is needed as automatic error-recovery for udld is no longer configured.
This feature would only attempt to recover a port in udld state one time and the timing of the recovery
attempt could not be synchronized with our test.
Step 7
Display the log for error messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the UDLD to err-disable the port when the fiber is pulled.
•
We expect the port to recover when fiber is plugged back in.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 17
Basic UDLD on Layer 2 Link Test Results
Test
Result
Basic UDLD on Layer 2 Link
Pass
Basic UDLD on Layer 3 Link
This test emulated a unidirectional link on a Layer 3 interface. Console messages are logged, and
interface states throughout the process.
Devices under test: SH1-104, and SH1-109.
Test Procedure
The procedure used to perform the Basic UDLD on Layer 3 Link test follows:
Cisco IOS Release 12.1(13)E13
263
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that UDLD is configured globally on both DUTs and that UDLD Aggressive Mode is configured
locally on the interfaces g4/15 of SH1-104 and g3/5 of SH1-109. Also ensure terminal monitoring is
active on this session.
Step 5
Once it has been verified that the interfaces connecting the DUTs are in state up/up, pull the transmit
side of the g3/5 interface on SH1-109. Record logging messages from both DUTs and their interface
states as well.
Step 6
Reconnect the fiber pulled out in Step 5. Use the udld reset command to make sure the interfaces
are again up/up.
Note
The udld reset command is needed as automatic error-recovery for udld is no longer configured.
This feature would attempt to recover a port in udld state one time and the timing of the recovery attempt
could not be synchronized with our test.
Step 7
Pull out the receive side of the g3/5 interface on SH1-109, record all messages and the interface states
from both DUTs.
Step 8
Reconnect the fiber pulled out in Step 7. Use the "udld reset" command to make sure the interfaces
are again up/up (see note in Step 6).
Step 9
Display the log for error messages.
Step 10
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the UDLD to err-disable the port when the fiber was pulled.
•
We expect the port to recover when the fiber is plugged back in.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 18
Basic UDLD on Layer 3 Link Test Results
Test
Result
Basic UDLD on Layer 3 Link
Pass
Trunking
A trunk is a point-to-point link between one or more switch ports and another networking device such
as a router or a switch. Trunks carry the traffic of multiple VLANs over a single link and allow VLANs
to be extended across an entire network. Table 19 lists and describes the five modes of trunking on Cisco
switches.
Cisco IOS Release 12.1(13)E13
264
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Table 19
Trunking Modes on Cisco Switches
Mode
Description
On
Local interface trunks. Sends Dynamic Trunking Protocol (DTP) packets. Puts the port
into permanent trunking mode and negotiates to convert the link to a trunk link. The
port becomes a trunk port even if the neighboring port does not agree to the change.
Off
Local interface does not trunk. Puts the port into nontrunking mode and negotiates to
convert the link into a nontrunk link. The port becomes a nontrunk port even if the
neighboring port does not agree to the change.
Auto
Local interface trunks if it receives DTP packets. Enables the port to convert the link
to a trunk link. The port becomes a trunk port if the neighboring port is set to on or
desirable mode. This is the default mode for Fast Ethernet and Gigabit Ethernet ports.
Desirable
Local interface sends DTP packets. Makes the port actively attempt to convert the link
to a trunk line. The port becomes a trunk port if the neighboring port is set to on,
desirable, or auto mode.
Nonnegotiate Local interface forms a trunk and does not send DTP packets. Puts the port into
permanent trunking mode, but prevents the port from generating DTP frames. You must
configure the neighboring port normally as a trunk port to establish a trunk link.
The following trunking tests were performed:
•
Sup 1 Configuration and Failure Recovery, page 265
•
Sup 2 Configuration and Failure Recovery, page 266
Sup 1 Configuration and Failure Recovery
In this procedure tested the configuration of both static and dynamically formed trunks, the recovery of
both static and dynamic trunks, and trunk links that exist between SH1-107 and dista-1. These links were
configured, then failed and recovered to verify that trunking is reestablished.
Test Procedure
The procedure used to perform the Sup 1 Configuration and Failure Recovery test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
The standard configuration for this link in the SafeHarbor network is both sides configured for static
trunking. Confirm this is the current configuration and the trunk is currently working.
Step 5
Change the configuration on both sides to dynamic trunking, and confirm the ports begin trunking again.
Step 6
Fail one of the trunking links on SH1-107 and confirm it is down.
Step 7
Bring the port back up, and confirm the port begins trunking again.
Step 8
Change the configuration on both sides back to static trunking, and confirm the ports begin trunking
again.
Cisco IOS Release 12.1(13)E13
265
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Note
You do not need to explicitly "set trunk 2/1 on" because the port channel will change it automatically
after trunk 1/1 is changed.
Step 9
Fail one of the trunking links on SH1-107 and confirm its down.
Step 10
Bring the port back up, and confirm the port begins trunking again.
Step 11
Display the log for error messages.
Step 12
Show the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect the DUT to trunk in both static and dynamic mode.
•
We expect the trunk port to recover from a port failure.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 20
Sup 1 Configuration and Failure Recovery Test Results
Test
Result
Sup 1 Configuration and Failure Recovery
Pass
Sup 2 Configuration and Failure Recovery
In this procedure tested the configuration of both static and dynamically formed trunks, the recovery of
both static and dynamic trunks, and trunk links that exist between SH1-109 and dista-1. These links were
configured, then failed and recovered to verify that trunking is reestablished.
Test Procedure
The procedure used to perform the Sup 2 Configuration and Failure Recovery test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
The standard configuration for this link in the Safe Harbor network is both sides configured for dynamic
trunking. Confirm this is the current configuration and the trunk is currently working.
Note
The lack of 'switchport mode' configuration implies the port is configured as desirable.
Step 5
Change the configuration on both sides to static trunking, and confirm the ports begin trunking again.
Step 6
Fail one of the trunking links on SH1-109 and confirm its down.
Step 7
Bring the port back up, and confirm the port begins trunking again.
Cisco IOS Release 12.1(13)E13
266
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Step 8
Change the configuration on both sides back to dynamic trunking, and confirm the ports begin trunking
again.
Step 9
Fail one of the trunking links on SH1-109 and confirm its down.
Step 10
Bring the port back up, and confirm the port begins trunking again.
Step 11
Display the log for error messages.
Step 12
Show the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect the DUT to trunk in both static and dynamic mode.
•
We expect the trunk port to recover from a port failure.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 21
Sup 2 Configuration and Failure Recovery Test Results
Test
Result
Sup 2 Configuration and Failure Recovery
Pass
Port Aggregation Protocol (Channeling)
The port aggregation protocol (PAgP) facilitates the automatic creation of EtherChannels by exchanging
packets between Ethernet ports. PAgP packets are exchanged only between ports in auto and desirable
modes. Ports configured in on or off mode do not exchange PAgP packets. The protocol learns the
capabilities of port groups dynamically and informs the other ports. Once PAgP identifies correctly
matched EtherChannel links, it groups the ports into an EtherChannel. The EtherChannel is then added
to the spanning tree as a single bridge port.
EtherChannel includes four user-configurable modes: on, off, auto, and desirable. Only auto and
desirable are PAgP modes. The auto and desirable modes can be modified with the silent and non-silent
keywords. By default, ports are in auto silent mode.
An EtherChannel distributes frames across the links in a channel by reducing part of the binary pattern
formed from the addresses in the frame to a numerical value that selects one of the links in the channel.
EtherChannel frame distribution is based on a Cisco-proprietary hashing algorithm. The algorithm is
deterministic; given the same addresses and session information, you always hash to the same port in the
channel, preventing out-of-order packet delivery.
The following tests were performed:
•
Basic Layer 2 Channeling Configuration, page 268
•
Basic Layer 3 Channeling Configuration, page 269
•
Layer 2 EtherChannel Load Balancing, page 271
•
Layer 3 EtherChannel Load Balancing, page 272
•
Layer 2 EtherChannel Failure and Recovery—Supervisor 1, page 273
•
Layer 3 EtherChannel Failure and Recovery—Supervisor 1, page 275
Cisco IOS Release 12.1(13)E13
267
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
•
Layer 3 EtherChannel Failure and Recovery—Supervisor 2, page 278
•
Layer 3 EtherChannel Failure and Recovery—Supervisor 2, page 278
•
Gigabit Ethernet Module Reset—Sup 1, page 279
•
Gigabit Ethernet Module Reset—Sup 2, page 281
Basic Layer 2 Channeling Configuration
In Native IOS, a portchannel interface is created, and then individual interfaces are joined to that
portchannel interface. The configuration of the individual interfaces determines whether the channel is
static or dynamic.
This test verified the basic aspects of Layer 2 PAgP configuration to verify that the basic functionality
worked correctly. A set of links between SH1-107 and Dista-1 was given a configuration for static
channeling. Dynamic channeling was tested in the bundling of links between SH1-110 and Dista-2.
In Native IOS, a portchannel interface is created, and then individual interfaces are joined to that
portchannel interface. The configuration of those individual interfaces determines whether the channel
is static or dynamic.
Figure 13 shows the topology for PAgP Basic Layer 2 channeling configuration.
Figure 13
PAgP Basic Layer 2 Channeling Topology
Devices under test: SH1-107, and SH1-110.
Test Procedure
The procedure used to perform the Basic Layer 2 Channeling Configuration test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the channel between devices SH1-107 and Dista-1 is configured as a static channel.
Step 5
Verify that the channel between devices SH1-110 and Dista-1 is configured as a dynamic channel.
Step 6
Display the log for error messages.
Step 7
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco IOS Release 12.1(13)E13
268
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Expected Results
•
We expect the Layer 2 channels to form with their respective static and dynamic configurations.
Results
Table 22
Basic Layer 2 Channeling Configuration Test Results
Test
Result
Basic Layer 2 Channeling Configuration
Pass
Basic Layer 3 Channeling Configuration
This test verified Layer 3 portchannel functionality. This test verified static and dynamic channel
configurations for each of the following combinations: dCEF::dCEF channels, non-dCEF::non-dCEF
channels, and mixed::mixed (involving both non-dCEF and dCEF modules). Table 23 maps each of the
six steps to the combination covered.
Table 23
Basic Layer 3 Channeling Configuration Matrix
Devices
dCEF?
Channeling?
103-99
Yes
Static
104-99
Yes
Dynamic
103-109
Mixed Static
103-110
Mixed Dynamic
103-107
No
Static
104-107
No
Dynamic
Figure 14 and Figure 15 show the topologies for PAgP basic Layer 3 channeling configuration.
Figure 14
PAgP Basic Layer 3 Channeling Topology
Cisco IOS Release 12.1(13)E13
269
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Figure 15
PAgP Basic Layer 3 Channeling Topology
Devices under test: SH1-103, SH1-99, SH1-104, SH1-107, SH1-109, and SH1-110.
Test Procedure
The procedure used to perform the Basic Layer 3 Channeling Configuration test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
The portchannel (4 ports) between SH1-103 (Po16) and SH1-99 (Po16) resides on dCEF-only modules.
Verify that it is configured for static channeling and that it is functioning correctly.
Step 5
Step 6
Step 7
Step 8
•
Verify that the Status for Po16 on both SH1-99 and SH1-103 is connected.
•
Verify that the EC state for Po16 on both SH1-99 and SH1-103 is on.
The portchannel (4 ports) between SH1-104 (Po17) and SH1-99 (Po17) resides on dCEF-only modules.
Verify that it is configured for dynamic channeling and that it is functioning correctly.
•
Verify that the Status for Po17 on both SH1-99 and SH1-104 is connected.
•
Verify that the EC state for Po17 on SH1-99 is "Desirable-sl."
•
Verify that the EC state for Po17 on SH1-104 is "Automatic-sl."
The portchannel (4 ports) between SH1-103 (Po70) and SH1-109 (Po70) resides on mixed modules.
Verify that it is configured for static channeling and that it is functioning correctly.
•
Verify that the Status for Po70 on both SH1-109 and SH1-103 is connected.
•
Verify that the EC state for Po70 on both SH1-109 and SH1-103 is on.
The portchannel (4 ports) between SH1-103 (Po71) and SH1-110 (Po71) resides on mixed modules.
Verify that it is configured for dynamic channeling and that it is functioning correctly.
•
Verify that the Status for Po71 on both SH1-110 and SH1-103 is connected.
•
Verify that the EC state for Po71 on SH1-110 is "Automatic-sl."
•
Verify that the EC state for Po71 on SH1-103 is "Desirable-sl."
The portchannel (4 ports) between SH1-103 (Po68) and SH1-107 (Po68) resides on non-dCEF modules.
Verify that it is configured for static channeling and that it is functioning correctly.
Cisco IOS Release 12.1(13)E13
270
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Step 9
•
Verify that the Status for Po68 on both SH1-107 and SH1-103 is connected.
•
Verify that the EC state for Po68 on both SH1-107 and SH1-103 is on.
The portchannel (4 ports) between SH1-104 (Po68) and SH1-107 (Po168) resides on non-dCEF
modules. Verify that it is configured for dynamic channeling and that it is functioning correctly.
•
Verify that the Status for Po68 on SH1-104 and Po168 on SH1-107 is connected.
•
Verify that the EC state for Po68 on SH1-104 is "Desirable-sl."
•
Verify that the EC state for Po168 on SH1-107 is "Automatic-sl."
Step 10
Display the log for error messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the portchannels to form correctly in each configuration and line card combination.
Results
Table 24
Basic Layer 3 Channeling Configuration Test Results
Test
Result
Basic Layer 3 Channeling Configuration
Pass
Layer 2 EtherChannel Load Balancing
This test verified that load distribution took place across the individual interfaces in a Layer 2
Etherchannel. An IXIA traffic stream was generated, sending traffic from 20 emulated sources to a single
destination. This traffic was sent from one side of the SH1 network to the other, passing through the
Layer 2 GEC between SH1-110 and Dista-2 and the Layer 2 GEC between SH1-114 and Dista-1. Load
distribution was verified by examining the traffic statistics on individual interfaces. All traffic sent from
the multiple sources was received on the other end of the network, though balanced across many
interfaces.
Traffic (300,000 packets) was sent at a rate of 1,000 pps from IXIA port 5/1 to IXIA port 3/4. SH1-114
is a Supervisor 1 and SH1-110 is a Supervisor 2.
Test Procedure
The procedure used to perform the Layer 2 EtherChannel Load Balancing test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that portchannel 20 on SH1-110 and portchannel 10 on SH1-114 are Layer 2 etherchannels.
Step 5
Verify that the load-balance algorithm on the SP indicates that traffic should be passed out all four
interfaces of portchannel 10 on SH1-114.
Step 6
Clear the counters on SH1-110 and SH1-114.
Cisco IOS Release 12.1(13)E13
271
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Step 7
Make certain all other background unicast traffic is stopped. Begin the test traffic stream of 300,000
packets.
Step 8
After the stream has finished transmitting, verify that all the interfaces in portchannels 20 and 10 on
SH1-110 and SH1-114, respectively, have passed some traffic.
Step 9
Verify that all traffic that was sent was received.
Step 10
Display the log for error messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that all traffic sent from the multiple sources was received on the other end of the
network, though balanced across many interfaces.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 25
Layer 2 EtherChannel Load Balancing Test Results
Test
Result
Layer 2 EtherChannel Load Balancing
Pass
Layer 3 EtherChannel Load Balancing
This test verified that load distribution took place across the individual interfaces in a Layer 3
Etherchannel. Two IXIA traffic streams were used, each sending traffic from 20 emulated sources to a
single destination. The first traffic stream used has SH1-110 as the first-hop router. SH1-110 should
balance the traffic to the next-hop routers over the interfaces of portchannels 71 and 171. The second
traffic stream used has SH1-114 as the first-hop router. SH1-114 should balance the traffic to the
next-hop routers over the interfaces of portchannels 65 and 165.All traffic sent from the multiple sources
was received on the other end of the network, though balanced across many interfaces.
Traffic (300,000 packets) was sent at a rate of 1,000 pps from IXIA port 5/1 to IXIA port 3/4 (first
stream) and from IXIA port 5/4 to IXIA port 5/1. SH1-114 is a Supervisor 1 and SH1-110 is a Supervisor
2.
Test Procedure
The procedure used to perform the Layer 3 EtherChannel Load Balancing test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that portchannels 71 and 171 on SH1-110 are Layer 3 etherchannels.
Step 5
Verify that SH1-110 knows multiple paths to the destination.
Step 6
Verify that portchannels 65 and 165 on SH1-114 are Layer 3 etherchannels.
Cisco IOS Release 12.1(13)E13
272
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Step 7
Verify that SH1-114 knows multiple paths to the destination.
Step 8
Clear the counters on SH1-110 and SH1-114.
Step 9
Begin the test traffic streams of 300,000 packets.
Step 10
After the stream has finished transmitting, verify that all the interfaces in portchannels 20 and 10 on
SH1-110 and SH1-114, respectively, have passed some traffic.
Step 11
Verify that all traffic that was sent was received.
Step 12
Display the log for error messages.
Step 13
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect SH1-110 to balance the traffic to the next-hop routers over the interfaces of portchannels
71 and 171. The second traffic stream used has SH1-114 as the first-hop router. SH1-114 should
balance the traffic to the next-hop routers over the interfaces of portchannels 65 and 165. All traffic
sent from the multiple sources was received on the other end of the network, though balanced across
many interfaces.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 26
Layer 3 EtherChannel Load Balancing Test Results
Test
Result
Layer 3 EtherChannel Load Balancing
Pass
Layer 2 EtherChannel Failure and Recovery—Supervisor 1
This test verified the ability of Layer 2 etherchannels to handle software cycling. IXIA unicast traffic
was sent from 20 incrementing IP addresses to a single IP destination. The first-hop router is SH1-108.
Interfaces GigabitEthernet4/1-4, bundled into Layer 2 etherchannel portchannel 10, connect SH1-108 to
Dista-1. The next-hop router is out Layer 3 interface portchannel 69, which consists of bundled
interfaces GigabitEthernet3/1-4. First, portchannel 10 will be shutdown and brought back up. Then,
portchannel69 will be brought down and back up. In each case it is verified that the Layer 2 and Layer
3 etherchannels are re-formed correctly, and that traffic is passing across all the bundled interfaces.
Figure 16 showsthe Layer 2 EtherChannel failure and recovery supervisor 1 topology.
Cisco IOS Release 12.1(13)E13
273
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Figure 16
Layer 2 EtherChannel Failure and Recovery—Supervisor 1 Topology
Devices under test: SH1-108
Test Procedure
The procedure used to perform the Layer 2 EtherChannel Failure and Recovery—Supervisor 1 test
follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the traffic is being load-balanced across all the aggregated interfaces of portchannel 10 of
device SH1-108.
Step 5
Shutdown interface portchannel 10 of SH1-108.
Step 6
Bring interface portchannel 10 of SH1-108 back online.
Step 7
Verify that the channel re-forms correctly after the interface comes back online and that those interfaces
on module 4 which were passing traffic before are again passing traffic.
Step 8
Verify that the CBL values are all correct for the affected interfaces on all eleven VLANs that are being
trunked by portchannel 10.
Step 9
Shutdown the four interfaces that make up portchannel 10.
Step 10
Bring those four interfaces back online.
Step 11
Verify that the channel re-forms correctly after the interfaces comes back online and that those interfaces
on module 4 which were passing traffic before are again passing traffic.
Unicast traffic is correctly coming in on all four interfaces of portchannel 10:
Step 12
Verify that the CBL values are all correct for the affected interfaces on all eleven VLANs that are being
trunked by portchannel 10.
Step 13
Display the log for error messages.
Note
Port, portchannel and module flapping tests were occurring at the the same time by another tester on
SH1-103, SH1-104,SH1-110 and SH1-109 as seen in the log. It had no effect on this test.
Cisco IOS Release 12.1(13)E13
274
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Step 14
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that, following the reset of the module, the interfaces on that module will be
re-aggregated back into their respective portchannels and will again pass traffic.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 27
Layer 2 EtherChannel Failure and Recovery—Supervisor 1 Test Results
Test
Result
Layer 2 EtherChannel Failure and Recovery—Supervisor 1
Pass
Layer 3 EtherChannel Failure and Recovery—Supervisor 1
This test verified the ability of a Layer 3 etherchannel to handle software cycling. IXIA unicast traffic
was sent from 20 incrementing IP addresses to a single IP destination. The first-hop router is SH1-108.
Interfaces GigabitEthernet3/1-4, bundled into Layer 3 etherchannel portchannel 69, connect SH1-108 to
SH1-104. Portchannel 69 will be brought down and back up. It is verified that the Layer 3 etherchannel
is re-formed correctly, and that traffic is passing across all the bundled interfaces.
Figure 17 showsthe Layer 3 EtherChannel failure and recovery supervisor 1 topology.
Figure 17
Layer 3 EtherChannel Failure and Recovery—Supervisor 1 Topology
Devices under test: SH1-108
Test Procedure
The procedure used to perform the Layer 3 EtherChannel Failure and Recovery—Supervisor 1 test
follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Cisco IOS Release 12.1(13)E13
275
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the traffic is being load-balanced across all the aggregated interfaces of portchannel 10 of
device SH1-108.
Step 5
Shutdown interface portchannel 69 of SH1-108.
Step 6
Bring interface portchannel 69 of SH1-108 back online.
Step 7
Verify that the channel re-forms correctly after the interface comes back online and that those interfaces
on module 3 which were passing traffic before are again passing traffic.
Step 8
Shutdown the four interfaces that make up portchannel 69.
Step 9
Bring those four interfaces back online.
Step 10
Verify that the channel re-forms correctly after the interfaces come back online and that those interfaces
on module 3 which were passing traffic before are again passing traffic.
Step 11
Display the log for error messages.
Step 12
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that, following the reset of the module, the interfaces on that module will be
re-aggregated back into their respective portchannels and will again pass traffic.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 28
Layer 3 EtherChannel Failure and Recovery—Supervisor 1 Test Results
Test
Result
Layer 3 EtherChannel Failure and Recovery—Supervisor 1
Pass
Layer 2 EtherChannel Failure and Recovery—Supervisor 2
This test verified the ability of Layer 2 etherchannels to handle software cycling. IXIA unicast traffic
was sent from 20 incrementing IP addresses to a single IP destination. The first-hop router is SH1-110.
Interfaces GigabitEthernet7/3,5 and GigabitEthernet8/3,5, bundled into Layer 2 etherchannel
portchannel 20, connect SH1-110 to Dista-2. Portchannel 20 will be shutdown and brought back up. It
is verified that the Layer 2 etherchannel is re-formed correctly, and that traffic is passing across all the
bundled interfaces.
Figure 18 showsthe Layer 2 EtherChannel failure and recovery supervisor 2 topology.
Cisco IOS Release 12.1(13)E13
276
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Figure 18
Layer 2 EtherChannel Failure and Recovery—Supervisor 2 Topology
Devices under test: SH1-110
Test Procedure
The procedure used to perform the Layer 2 EtherChannel Failure and Recovery—Supervisor 2 test
follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the traffic is being load-balanced across all the aggregated interfaces of portchannel 20 of
device SH1-110.
Step 5
Shutdown interface portchannel 20 of SH1-110.
Step 6
Bring interface portchannel 20 of SH1-110 back online.
Step 7
Verify that the channel re-forms correctly after the interface comes back online and that those interfaces
on modules 7 and 8 which were passing traffic before are again passing traffic.
Unicast traffic is correctly coming in on all four interfaces of portchannel 10:
Step 8
Verify that the CBL values on the SP are all correct for the affected interfaces on all eleven VLANs that
are being trunked by portchannel 20.
Step 9
Shut down the four interfaces that make up portchannel 20.
Step 10
Bring those four interfaces back online.
Step 11
Verify that the channel re-forms correctly after the interfaces comes back online and that those interfaces
on module 4 which were passing traffic before are again passing traffic.
Step 12
Verify that the CBL values on the SP are all correct for the affected interfaces on all eleven VLANs that
are being trunked by portchannel 20.
Step 13
Display the log for error messages.
Step 14
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco IOS Release 12.1(13)E13
277
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Expected Results
•
We expect that, following the reset of the module, the interfaces on that module will be
re-aggregated back into their respective portchannels and will again pass traffic.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 29
Layer 2 EtherChannel Failure and Recovery—Supervisor 2 Test Results
Test
Result
Layer 2 EtherChannel Failure and Recovery—Supervisor 2
Pass
Layer 3 EtherChannel Failure and Recovery—Supervisor 2
This test verified the ability of a Layer 3 etherchannel to handle software cycling. IXIA unicast traffic
was sent from 20 incrementing IP addresses to a single IP destination. The first-hop router is SH1-110.
Interfaces GigabitEthernet3/3-4 and GigabitEthernet4/3-4, bundled into Layer 3 etherchannel
portchannel 69, connect SH1-110 to SH1-104. Portchannel171 will be brought down and back up. It is
verified that the Layer 3 etherchannel is re-formed correctly, and that traffic is passing across all the
bundled interfaces.
Figure 19 showsthe Layer 3 EtherChannel failure and recovery supervisor 2 topology.
Figure 19
Layer 3 EtherChannel Failure and Recovery—Supervisor 2 Topology
Devices under test: SH1-110
Test Procedure
The procedure used to perform the Layer 3 EtherChannel Failure and Recovery—Supervisor 2 test
follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Cisco IOS Release 12.1(13)E13
278
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Step 4
Verify that the traffic is being load-balanced across all the aggregated interfaces of portchannel 171 of
device SH1-110.
Step 5
Shutdown interface portchannel 171 of SH1-110.
Step 6
Bring interface portchannel 171 of SH1-110 back online.
Step 7
Verify that the channel re-forms correctly after the interface comes back online and that those interfaces
on module 3 which were passing traffic before are again passing traffic.
Step 8
Shutdown the four interfaces that make up portchannel 171.
Step 9
Bring those four interfaces back online.
Step 10
Verify that the channel re-forms correctly after the interfaces comes back online and that those interfaces
on modulea 3 and 4 which were passing traffic before are again passing traffic.
Step 11
Display the log for error messages.
Step 12
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that, following the reset of the module, the interfaces on that module will be
re-aggregated back into their respective portchannels and will again pass traffic.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 30
Layer 3 EtherChannel Failure and Recovery—Supervisor 2 Test Results
Test
Result
Layer 3 EtherChannel Failure and Recovery—Supervisor 2
Pass
Gigabit Ethernet Module Reset—Sup 1
This test verified the ability of Layer 2 and Layer 3 EtherChannels to handle module resets and failures.
IXIA unicast traffic was sent from 20 incrementing IP addresses to a single IP destination. The first-hop
router is SH1-108. Interfaces GigabitEthernet 4/1-4, bundled into Layer 2 etherchannel portchannel 10,
connect SH1-108 to Dista-1. The next-hop router is out Layer 3 interface portchannel 69, which consists
of bundled interfaces GigabitEthernet3/1-4. A test stream is sent first while module 4 is reset. The same
test stream is sent again, this time resetting module 3. In each case it is verified that the Layer 2 and
Layer 3 etherchannels are re-formed correctly. Traffic loss was measured for each case.
Figure 20 showsthe GEM reset supervisor 1 topology.
Cisco IOS Release 12.1(13)E13
279
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Figure 20
GEM Reset—Supervisor 1 Topology
Devices under test: SH1-108
Test Procedure
The procedure used to perform the Gigabit Ethernet Module Reset—Sup 1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Verify that the traffic is being load-balanced across all the aggregated interfaces of portchannels 10 and
69 of device SH1-108.Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Start the test traffic stream, sending 300 seconds worth of traffic at 1000pps rate.
Step 5
Reset module 4 of SH1-108.
Step 6
Verify that the channel re-forms correctly after the module comes back online and that those interfaces
on module 4 which were passing traffic before are again passing traffic.
Step 7
Determine the amount of traffic loss.
Step 8
Start the test traffic stream, sending 300 seconds worth of traffic at 1000pps rate.
Step 9
Reset module 3 of SH1-108.
Step 10
Verify that the interfaces on module 3 are aggregated back into portchannel 69 correctly, and that they
are again passing traffic.
Step 11
Determine the amount of traffic loss.
Step 12
Display the log for error messages.
Step 13
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that, following the reset of the module, the interfaces on that module will be
re-aggregated back into their respective portchannels and will again pass traffic.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco IOS Release 12.1(13)E13
280
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Results
Table 31
Gigabit Ethernet Module Reset—Sup 1 Test Results
Test
Result
Gigabit Ethernet Module Reset—Sup 1
Pass
Gigabit Ethernet Module Reset—Sup 2
This test verified the ability of Layer 2 and Layer 3 EtherChannels to handle module resets and failures.
IXIA unicast traffic was sent from 20 incrementing IP addresses to a single IP destination. The first-hop
router is SH1-110. Interfaces GigabitEthernet3/5-6,4/5-6, bundled into Layer 2 etherchannel
portchannel 20, connect SH1-110 to Dista-2. The next-hop router is out Layer 3 interface portchannel
171, which consists of bundled interfaces GigabitEthernet3/3-3/4,4/3-4/4. A test stream is sent first
while module 4 is reset. The same test stream is sent again, this time resetting module 3. In each case it
is verified that the Layer 2 and Layer 3 etherchannels are re-formed correctly. Traffic loss was measured
for each case as well.
A diagram of the relevant topology is below, but the ports assignments do not reflect the current
configuration as described above. To test failure to Dista-2 (i.e. portchannel 20) separately from failure
to outgoing portchannel 170, SH1-109 must be used instead of SH1-110. To enable the traffic to flow
over SH1-109, portchannels 20, 70, and 171 on SH1-110 must be shutdown first.
Figure 21 showsthe GEM reset supervisor 2 topology.
Figure 21
GEM Reset—Supervisor 2 Topology
Devices under test: SH1-109
Test Procedure
The procedure used to perform the Gigabit Ethernet Module Reset—Sup 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Deactivate portchannels 20, 71, and 171 on SH1-110 from the console port.
Cisco IOS Release 12.1(13)E13
281
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Step 5
Start the test traffic stream, sending 300 seconds worth of traffic at 1000pps rate.
Step 6
Verify that the traffic is being load-balanced across all the aggregated interfaces of portchannels 20 and
170 of device SH1-109.
Step 7
Reset module 7 of SH1-109.
Step 8
While unicast traffic is still flowing, verify that the portchannel 20 re-forms correctly after the module
comes back online and that those interfaces on module 7 which were passing traffic before are again
passing traffic.
Step 9
Determine the amount of traffic loss.
Step 10
Start the test traffic stream, sending 300 seconds worth of traffic at 1000pps rate.
Step 11
Reset modules 3 and 4 of SH1-109.
Step 12
While unicast traffic is still flowing, verify that the interfaces on modules 3 and 4 are aggregated back
into portchannel 170 correctly, and that they are again passing traffic.
The modules are online and the Status=Ok.
The interfaces from modules 3 and 4 have been aggregated back into portchannel 170.
Step 13
Determine the amount of traffic loss.
Step 14
Activate portchannels 20, 71, and 171 on SH1-110.
Step 15
Verify portchannels 20, 71, and 171 are back online on SH1-110.
Step 16
Display the log for error messages.
Step 17
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that, following the reset of the module, the interfaces on that module will be
re-aggregated back into their respective portchannels and will again pass traffic.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 32
Gigabit Ethernet Module Reset—Sup 2 Test Results
Test
Result
Gigabit Ethernet Module Reset—Sup 2
Pass
VLAN Trunking Protocol
VLAN Trunking Protocol (VTP) is a Layer 2 messaging protocol that maintains VLAN configuration
consistency by managing the addition, deletion, and renaming of VLANs on a network-wide basis. VTP
minimizes misconfigurations and configuration inconsistencies that can result in a number of problems,
such as duplicate VLAN names, incorrect VLAN-type specifications, and security violations.
You can use VTP to manage VLANs 1 to 1005 in your network. (Note that VTP does not support VLANs
1025 to 4094.) With VTP, you can make configuration changes centrally on one switch and have those
changes automatically communicated to all the other switches in the network.
Cisco IOS Release 12.1(13)E13
282
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
The following test was performed:
•
Basic VLAN Trunking Protocol Configuration, page 283
•
Layer 3 Routing Features, page 285
Basic VLAN Trunking Protocol Configuration
This procedure tests the various combinations of VTP client, server, and transparent modes between
devices SH1-107 and Dista-1. With each combination that is tested, VLANs are configured and behavior
is checked for normalcy.
Device under test: SH1-107.
Test Procedure
The procedure used to perform the Basic VLAN Trunking Protocol Configuration test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Confirm that SH1-107 and Dista-1 are in VTP transparent mode and that both devices are in the domain
named FIN.
•
Step 5
Step 6
Step 7
Verify that each device, SH1-107 and Dista-1, has the domain of "FIN" and is in VTP transparent
mode.
Confirm that a trunk link is configured between SH1-107 (g4/1, g4/3) and Dista-1 (1/1, 2/1).
•
Verify that the status of Po10 on SH1-107 is trunking.
•
Verify that each of the ports on Dista-1 in the port channel connecting to SH1-107 are trunking.
Run the script that will execute the following tasks.
•
Test1: With both SH1-107 and Dista-1 in Transparent mode, configure VLAN 200 on SH1-107.
Confirm that VLAN 200 is created on SH1-107 but not on Dista-1.
•
Test2: Configure SH1-107 for VTP server mode (Dista-1 still in Transparent mode) and add VLAN
201 to the VLAN database of SH1-107. Confirm that VLAN 201 is created on SH1-107 but not on
Dista-1.
•
Test3: Configure Dista-1 for VTP mode Client (SH1-107 is Server) and add VLAN 202 to the
VLAN database on SH1-107. Confirm that VLAN 202 was added to both SH1-107 and Dista-1.
•
Test4: Configure Dista-1 for VTP Server mode (SH1-107 in Server mode), add VLAN 203 to
SH1-107. Confirm that VLAN 203 is created on both SH1-107 and Dista-1.
•
Test5: With SH1-107 and Dista-1 both in Server mode, enable VTP Version 2 on Dista-1 (VTP V2
disabled on SH1-107). Configure VLAN 204 on SH1-107. Confirm that VLAN 204 is created on
both SH1-107 and Dista-1.
•
Test6: With the same VTP configurations as in Step 10, create VLAN 205 on Dista-1. Confirm that
VLAN 205 is created on both SH1-107 and Dista-1.
•
Test7: With SH1-107 in Server mode, configure Dista-1 for VTP Transparent mode and SH1-108
for VTP Client mode. Configure VLAN 206 on SH1-107. Confirm that VLAN 206 is not created on
Dista-1, but is created on SH1-108.
Check the output of the script, to make sure both cases passed.
Cisco IOS Release 12.1(13)E13
283
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 2 Features
Step 8
Display the log for error messages.
Step 9
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that when a switch is in VTP transparent mode, it should not accept any vlan changes
from a VTP server but should still forward the changes to other VTP switches in the domain. Locally
created vlans should not be propgated to other VTP clients or VTP servers.
•
We expect that when a switch is in VTP client mode, it should accept vlan changes from a VTP
server, but no changes should be allowed locally.
•
We expect that when a switch is in VTP server mode, local vlan changes should be propagated to
other VTP servers and vtVTP p clients.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 33
Basic VLAN Trunking Protocol Configuration Test Results
Test
Result
Basic VLAN Trunking Protocol Configuration
Pass
Cisco IOS Release 12.1(13)E13
284
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Layer 3 Routing Features
Layer 3 routing feature testing for Safe Harbor involves these features:
•
IP Multicast, page 285
•
Cisco Express Forwarding, page 396
•
Open Shortest Path First, page 405
•
Border Gateway Protocol, page 414
•
Hot Standby Routing Protocol, page 424
•
Enhanced Interior Gateway Routing Protocol, page 437
IP Multicast
Traditional IP communication allows a host to send packets to a single host (unicast transmission) or to
all hosts (broadcast transmission). IP multicast provides a third scheme, allowing a host to send packets
to a subset of all hosts (group transmission). These hosts are known as group members.
Packets delivered to group members are identified by a single multicast group address. Multicast packets
are delivered to a group using best-effort reliability, just like IP unicast packets.
The multicast environment consists of senders and receivers. Any host, regardless of whether it is a
member of a group, can send to a group. However, only the members of a group receive the message.
A multicast address is chosen for the receivers in a multicast group. Senders use that address as the
destination address of a datagram to reach all members of the group.
Membership in a multicast group is dynamic; hosts can join and leave at any time. There is no restriction
on the location or number of members in a multicast group. A host can be a member of more than one
multicast group at a time.
Note
On PFC1, the (*, G) can only be software switched. If the ip pim spt-threshold infinity command is
used on PFC1, there may be high CPU usage, and multicast packets might be lost under heavy traffic.
Note
All tests have been run with the mls ip multicast consistency-checker command enabled.
Note
The C flag is not set on the (S, G) as it was in 12.1(8b)E16. This change was made by CSCdw13674 PIM
scalability/convergence enhancement post 12.1(10)E, and is the intended behavior.
The following tests were performed:
•
Last-Hop Router Functionality, page 287
•
First-Hop Router Functionality, page 289
•
Basic Static RP Functionality—Supervisor 11, page 291
•
Basic Static RP Functionality—Supervisor 22, page 293
•
Basic Auto RP Functionality—Supervisor 22, page 296
•
Auto PIM RP Failover—First Hop Router Impact—Supervisor 11, page 299
Cisco IOS Release 12.1(13)E13
285
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
•
Auto PIM RP Failover—First Hop Router Impact—Supervisor 22, page 302
•
Auto PIM RP Failover—Traffic Impact—Supervisor 22, page 304
•
Static PIM-RP Failover—Supervisor 11, page 305
•
Basic IGMP Functionality, page 311
•
IGMP Leave/Join Functionality, page 313
•
Non-RPF Rate Limiting and Multicast Stub—Supervisor 1, page 317
•
Non-RPF Rate Limiting and Multicast Stub—Supervisor 2, page 319
•
Layer 2 GEC Failover—SH1-110 to Dista-2, page 322
•
Layer 2 GEC Failover—SH1-108 to Dista-1, page 324
•
Layer 2 GEC Failover—SH1-114 to Dista-1, page 326
•
Layer 2 GEC Failover—SH1-106 to Dista-2, page 329
•
Layer 2 GEC Failover—SH1-102 to Dista-1, page 331
•
Layer 3 GEC Failover—SH1-104 to SH1-110, page 333
•
Layer 3 GEC Failover—SH1-104 to SH1-109, page 337
•
Layer 3 GEC Failover—SH1-104 to SH1-108, page 341
•
Layer 3 GEC Failover—SH1-104 to SH1-107, page 344
•
Layer 3 GEC Failover—SH1-100 to SH1-104, page 347
•
Layer 3 GEC Failover—SH1-100 to SH1-113, page 351
•
Layer 3 GEC Failover—SH1-100 to SH1-106, page 355
•
Layer 3 GEC Failover—SH1-100 to SH1-105, page 359
•
Layer 3 GEC Failover—SH1-100 to SH1-102, page 362
•
Layer 3 GEC Failover—SH1-100 to SH1-101, page 367
•
Layer 3 GEC Failover—SH1-100 to SH1-97, page 371
•
Switch Fabric Module Failover—Supervisor 22, page 374
•
GEM Failover—Supervisor 11 as First-Hop Router, page 376
•
GEM Failover—Supervisor 11 as Last-Hop Router, page 377
•
GEM Failover—Supervisor 11 with Directly Connected Layer 3 Interface, page 379
•
GEM Failover—Supervisor 22 as First-Hop Router, page 381
•
GEM Failover—Supervisor 22 as Last-Hop Router, page 382
•
GEM Failover—Supervisor 22 as Static RP, page 384
•
GEM Failover—Supervisor 22 as Auto RP, page 386
•
GEM Failover—Supervisor 22 with Directly Connected Layer 3 Interface, page 388
•
Protocol Independent Module-Designated Router Failover—Supervisor 11, page 391
•
Protocol Independent Module-Designated Router Failover—Supervisor 22, page 393
•
Auto-RP Failover—RP Impact, page 394
Cisco IOS Release 12.1(13)E13
286
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Last-Hop Router Functionality
This test verified basic multicast functionality on the last-hop router, including the creation of hardware
shortcuts for multicast entries.
Goals:
•
Verify that the correct mroute entries are created on the correct devices.
•
Verify that the correct flags are set for the mroute entries.
•
Verify that traffic is being hardware-switched where appropriate.
Primary Devices Used:
•
SH1-105: Sup11; directly attached L3 receiver on secondary subnet; backup PIM-DR; groups
239.100.1.[1-10]
•
SH1-113: Sup12; RP-on-a-stick scenario; directly attached L3 receiver on primary subnet; groups
239.100.1.[1-10]
•
SH1-110: Sup22; directly attached L3 receiver on secondary subnet; primary PIM-DR; groups
239.100.2.[1-10]
•
SH1-102: Sup22; receivers are VLANs on primary subnets; primary PIM-DR; groups
239.100.[1-3].[1-10]
Primary IXIA Ports Used:
•
1/1, 4/6, 11/1, 2/1, 1/2, 2/7
Test Procedure
The procedure used to perform the Last-Hop Router Functionality test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the correct mroute entries and flags are created on SH1-105 for groups 239.100.1.[1-10], and
that this traffic is being hardware-switched.
For each group with SH1-105 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. There are no MMLS entries for any of these groups on SH1-105 because SH1-105 is a
Supervisor 1-based system, which software-switches (*, G) traffic. Also, verify that the correct flags are
set in the (*, G) entry: an S-flag because the traffic is forwarded using Sparse-mode, and a C-flag because
the receiver is directly connected to SH1-105. For each group, the Incoming Interface should be
Portchannel 166 (from SH1-100, the primary PIM-RP). The Outgoing Interface List (OIL) should
contain the appropriate interface GigabitEthernet3/2, which goes to the IXIA receiver port. It should be
noted that the receiver GigabitEthernet3/2 is on a secondary subnet.
Step 5
Verify that the correct mroute entries and flags are created on SH1-113 for groups 239.100.2.[1-10], and
that this traffic is being hardware-switched.
For each group with SH1-113 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. There are no MMLS entries for any of these groups on SH1-113 because SH1-113 is a
Supervisor 1-based system, which software-switches (*, G) traffic. Also, verify that the correct flags are
Cisco IOS Release 12.1(13)E13
287
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
set in the (*, G) entry: an S-flag because the traffic is forwarded using Sparse-mode, and a C-flag because
the receiver is directly connected to SH1-113. For each group, the Incoming Interface should be
portchannel 164 (from SH1-100, the primary PIM-RP). The Outgoing Interface List (OIL) should
contain the appropriate interface FastEthernet9/2, which goes to the IXIA receiver port.
Step 6
Verify that the correct mroute entries and flags are created on SH1-110 for groups 239.100.2.[1-10], and
that this traffic is being hardware-switched.
For each group with SH1-110 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-110. For
each group, the Incoming Interface should be portchannel 171 (from SH1-104). The Outgoing Interface
List (OIL) should contain two interfaces: VLAN 16 and GigabitEthernet4/16. Each should have an
H-flag next to it, indicating that it is being Hardware-switched. The MMLS entries for each group should
be consistent with the mroute entries, containing the same Incoming Interface and OIL. It should be
noted that the receiver interface GigabitEthernet4/16 is on a secondary subnet.
Step 7
Verify that the correct mroute entries and flags are created on SH1-102 for groups 239.100.1.[1-10],
239.100.2.[1-10], 239.100.3.[1-10], and that this traffic is being hardware-switched.
For each group 239.100.1.[1-10] with SH1-102 being the last-hop router, verify a (*, G) entry in the
mroute table. There is no (S, G) entry because the SPT threshold is configured to infinity, preventing the
creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because
the traffic is forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to
SH1-102. For each group, the Incoming Interface should be portchannel 115 (from SH1-100, the primary
PIM-RP). The Outgoing Interface List (OIL) should contain a single interface: VLAN 41. This should
have an H-flag next to it, indicating that it is being Hardware-switched. The MMLS entries for each
group should be consistent with the mroute entries, containing the same Incoming Interface and OIL.
For each group 239.100.2.[1-10] with SH1-102 being the last-hop router, look for a (*, G) entry in the
mroute table. There is no (S, G) entry because the SPT threshold is configured to infinity, preventing the
creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because
the traffic is forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to
SH1-102. For each group, the Incoming Interface should be portchannel 115 (from SH1-100, the primary
PIM-RP). The Outgoing Interface List (OIL) should contain a single interface: VLAN 43. This should
have an H-flag next to it, indicating that it is being Hardware-switched. The MMLS entries for each
group should be consistent with the mroute entries, containing the same Incoming Interface and OIL.
For each group 239.100.3.[1-10] with SH1-102 being the last-hop router, verify a (*, G) entry in the
mroute table. There is no (S, G) entry because the SPT threshold is configured to infinity, preventing the
creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because
the traffic is forwarded using Sparse-mode, and a C-flag because the receivers are directly connected to
SH1-102. For each group, the Incoming Interface should be portchannel 115 (from SH1-100, the primary
PIM-RP). The Outgoing Interface List (OIL) should contain two interfaces: VLAN 43 and
FastEthernet4/5. Each should have an H-flag next to it, indicating that they are being
Hardware-switched. The MMLS entries for each group should be consistent with the mroute entries,
containing the same Incoming Interface and OIL.
Step 8
Display the log for error messages.
Step 9
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco IOS Release 12.1(13)E13
288
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Expected Results
•
We expect that, for each receiver looked at during this test, proper mroute entries and flags have been
installed.
•
We expect that the test multicast groups are being hardware-switched, where appropriate.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 34
Last-Hop Router Functionality Test Results
Test
Result
Last-Hop Router Functionality
Pass
First-Hop Router Functionality
This test verified basic multicast functionality on the first-hop router, including the creation of hardware
shortcuts for multicast entries.
Goals:
•
Verify that the correct mroute entries are created in the correct devices.
•
Verify that the correct flags are set for the mroute entries.
•
Verify that traffic is being hardware-switched, where appropriate.
Primary Devices Used:
•
SH1-114: Sup12; Sender is connected to Dista-1 on VLAN 110; groups 239.100.1.[1-10]
•
SH1-106: Sup11; Sender is connected to Dista-2 on VLAN 49; groups 239.100.2.[1-10]
•
SH1-110: Sup22; Sender is connected to Dista-2 on VLAN 20; groups 239.100.3.[1-10]
Primary IXIA Ports Used:
•
3/3, 4/2, 13/2
Test Procedure
The procedure used to perform the First-Hop Router Functionality test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the IOS version under test. Verify the uptime and that the box hasn't
reloaded unnecessarily. Verify that there is not any process spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Show which device SH1-114 considers to be the primary PIM-RP for test groups 239.100.1.[1-10].
Cisco IOS Release 12.1(13)E13
289
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
For each of the groups 239.100.1.[1-10], SH1-114 should show the RP as being 172.31.0.100. The
address 172.31.0.100 is an Anycast RP address, shared by SH1-100 and SH1-99. SH1-114 should show
that it knows the RP address to be advertised by SH1-100 (the RPF interface should be portchannel 165).
Step 5
Verify that the correct mroute entries and flags are created on SH1-114 for groups 239.100.1.[1-10], and
that this traffic is being hardware-switched.
SH1-114 is the first-hop router for traffic groups 239.100.1.[1-10]. As such, it should be registered with
the RP, 172.31.0.100. The first-hop router, and all routers up to and including the RP, will have an (S, G)
entry for a given group, as per the rules of Sparse-mode PIM. SH1-114 should have the (S, G) entry for
each group in the test range. It should also have the F- and T-flags set for this (S, G) entry. The F-flag is
set because the source is registered with the RP. The T-flag is set because a Shortest-Path Tree (SPT) is
formed from the source to the RP. The Incoming interface is VLAN 110. The outgoing interface is
portchannel 165, as this is directly connected to SH1-100, the primary PIM-RP. The outgoing interface
should also have the H-flag set, indicating that it is being hardware-switched. Each group should have
an MMLS entry with the (S, G) entry. This (S, G) in the MMLS entry should have incoming and outgoing
interfaces listed that are consistent with the mroute (S, G) entry. On this device, there should be only one
MMLS entry, for the (S,G), because (*, G) flows are not hardware-switched on Supervisor 1-based
systems.
Step 6
Show which device SH1-106 considers to be the primary PIM-RP for test groups 239.100.2.[1-10].
For each of the groups 239.100.2.[1-10], SH1-106 should show the RP as being 172.31.0.100.
The address 172.31.0.100 is an Anycast RP address, shared by SH1-100 and SH1-99. SH1-106 should
show that it knows the RP address to be advertised by SH1-100 (the RPF interface should be
portchannel 167).
Step 7
Verify that the correct mroute entries and flags are created on SH1-106 for groups 239.100.2.[1-10], and
that this traffic is being hardware-switched.
SH1-106 is the first-hop router for traffic groups 239.100.2.[1-10]. As such, it should be registered with
the RP, 172.31.0.100. The first-hop router, and all routers up to and including the RP, will have an (S, G)
entry for a given group, as per the rules of Sparse-mode PIM. SH1-106 should have the (S, G) entry for
each group in the test range. It should also have the F- and T-flags set for this (S, G) entry. The F-flag is
set because the source is registered with the RP. The T-flag is set because a Shortest-Path Tree (SPT) is
formed from the source to the RP. The Incoming interface should be VLAN 49. The outgoing interface
should be portchannel 167, as this is directly connected to SH1-100, the primary PIM-RP. The outgoing
interface should have the H-flag set, indicating that it is being hardware-switched. Each group should
have an MMLS entry with the (S, G) entry. This (S, G) in the MMLS entry should have incoming and
outgoing interfaces listed that are consistent with the mroute (S, G) entry. There should be only one
MMLS entry, for the (S,G), because (*, G) flows are not hardware-switched on Supervisor 1 systems.
Step 8
Show which device SH1-110 considers to be the primary PIM-RP for test groups 239.100.3.[1-10].
For each of the groups 239.100.3.[1-10], SH1-110 should show the RP as being 172.31.0.100.
The address 172.31.0.100 is an Anycast RP address, shared by SH1-100 and SH1-99. While the output
from SH1-110 cannot specifically show SH1-100 to be the primary PIM-RP (SH1-100 and SH1-99 are
more than one hop away), it should show that it knows of it via portchannel 171 (the RPF interface
towards SH1-104).
Step 9
Verify that the correct mroute entries and flags are created on SH1-110 for groups 239.100.3.[1-10], and
that this traffic is being hardware-switched.
SH1-110 is the first-hop router for traffic groups 239.100.3.[1-10]. As such, it should be registered with
the RP, 172.31.0.100. The first-hop router, and all routers up to and including the RP, will have an (S, G)
entry for a given group, as per the rules of Sparse-mode PIM. SH1-110 should have the (S, G) entry for
each group in the test range. It should also have the F- and T-flags set for this (S, G) entry. The F-flag is
set because the source is registered with the RP. The T-flag is set because a Shortest-Path Tree (SPT) is
Cisco IOS Release 12.1(13)E13
290
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
formed from the source to the RP. The Incoming interface listed should be VLAN 20. The outgoing
interface should be portchannel 171, as this leads towards the RP with address 172.31.0.100. The
outgoing interface should also have the H-flag set, indicating that it is being hardware-switched. Each
group should have an MMLS entry with the (S, G) entry. This (S, G) in the MMLS entry should have
incoming and outgoing interfaces listed that are consistent with the mroute (S, G) entry. Both the (S, G)
and the (*, G) flows should have MMLS entries because both are hardware-switched on Supervisor 2
systems.
Step 10
Display the log for error messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that, for each receiver looked at during this test, proper mroute entries and flags have been
installed.
•
We expect that the test multicast groups are being hardware-switched, where appropriate.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 35
First-Hop Router Functionality Test Results
Test
Result
First-Hop Router Functionality
Pass
Basic Static RP Functionality—Supervisor 11
This test verified basic static RP functionality using the Supervisor 11 engine.
Goals:
•
Verify the RP configuration on all rendezvous points.
•
Verify the static RP configuration on any downstream devices.
•
Verify that the static RPs have the correct mroute entries and flags for the given traffic groups.Verify
that downstream devices, if any, know of the correct RP for the given traffic groups.
•
Verify that the static RPs have MMLS entries consistent with the mroute table and are hardware
forwarding the test traffic.
Primary Devices Used:
•
SH1-105 and SH1-106: Sup11; static RPs for groups 239.255.50.[1-10]
Primary IXIA Ports Used:
•
Note
2/3, 2/5
In the Safe Harbor topology, there are no routers downstream from SH1-105 and SH1-106. These two
routers act in the role of PIM-RPs running Anycast Static RP with MSDP, and in the role of PIM-DR
and non-PIM-DR (NDR) for the VLAN segments to which they're connected.
Cisco IOS Release 12.1(13)E13
291
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Test Procedure
The procedure used to perform the Basic Static RP Functionality—Supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify the static RP configuration on SH1-105 and SH1-106.
Step 5
Step 6
Step 7
•
Both SH1-105 and SH1-106 share the same IP address for the Loopback 1 interface:
172.31.0.106/32. This is the Anycast address.
•
Both SH1-105 and SH1-106 have two static RP configurations. 172.31.0.106 is used for all groups
that meet the ACL 1 parameters. 172.31.0.98 is used for all groups that meet the ACL 2 parameters.
•
Access-list 1 limits the scope of multicast addresses to those within 239.255.0.0/16.
•
SH1-105 and SH1-106 are the Anycast routers for multicast groups 239.255.0.0/16.
Verify that SH1-105 and SH1-106 see the proper device as the static RP for the appropriate group range.
•
For the ten test groups, 239.255.50.[1-10], SH1-105 and SH1-106 list the RP as 172.31.0.106, the
Anycast IP address shared by the two routers.
•
Each of the two routers, SH1-105 and SH1-106, shows the RPF interface for the RP to be Loopback1
and that it is directly connected.
Verify that SH1-106 is the PIM-DR on the networks shared with SH1-105.
•
SH1-105 have a PIM neighbor relationship on those subnets that they share, specifically VLANs
40-50.
•
SH1-106 shows that it sees SH1-106 as the DR on these subnets.
Verify that SH1-106 has the correct mroute entries and flags for all test traffic and that that traffic is being
hardware switched.
SH1-106 is the primary PIM-RP for the test multicast groups 239.255.50.[1-10]. It therefore has the
following for each group:
Step 8
•
Both a (*, G) and an (S, G) entry, in the mroute table.
•
An (S,G), only, in the MMLS table, as (*, G) flows are software-switched on Sup1 platforms.
•
A T-flag on the (S, G) entry, indicating that the Shortest Path Tree bit is set and the SPT is being
used.
•
An A-flag on the (S, G) entry, indicating that the entry is advertised via MSDP to the appropriate
neighbor(s).
•
An RPF-MFD tag on the incoming interface of the (S, G) listed in the mroute entry.
•
An H-flag on each outgoing interface of the (S, G) listed in the mroute entry.
•
An incoming interface of VLAN 47 on both the mroute entry and the MMLS entry of the (S,G), for
both the mroute entry and the MMLS entry.
•
An outgoing interface list in the (S, G) of the mroute and MMLS entries containing only VLAN 40.
•
An "RPF-MFD installed" indicator in the (S, G) of the MMLS entries.
Display the log for error messages.
Cisco IOS Release 12.1(13)E13
292
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 9
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that the primary PIM-RP will have the proper mroute entries and flags set for all test
groups.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 36
Basic Static RP Functionality—Supervisor 11 Test Results
Test
Result
Basic Static RP Functionality—Supervisor 11
Pass, exceptionCSCea21798.
Basic Static RP Functionality—Supervisor 22
This test verified basic static RP functionality using the Supervisor 22 engine.
Goals:
•
Verify the RP configuration on all rendezvous points.
•
Verify the static RP configuration on any downstream devices.
•
Verify that downstream devices, if any, know of the correct RP for the given traffic groups.
•
Verify that the static RPs have the correct mroute entries and flags for the given traffic groups.
•
Verify that the static RPs have MMLS entries consistent with the mroute table and are hardware
forwarding the test traffic.
Primary Devices Used:
•
SH1-103 and SH1-104: Sup22; static RPs for groups 239.255.[50-51].[1-10]
•
SH1-107 and SH1-108: Sup12; routers downstream from SH1-103 and SH1-104
•
SH1-109 and SH1-110: Sup22; routers downstream from SH1-103 and SH1-104
Primary IXIA Ports Used:
•
5/1, 5/2, 8/2, 13/1
Test Procedure
The procedure used to perform the Basic Static RP Functionality—Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify the static RP configuration on SH1-103 and SH1-104.
Cisco IOS Release 12.1(13)E13
293
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 5
Step 6
Step 7
Step 8
Step 9
•
SH1-103 and SH1-104 share the same IP address for the Loopback1 interface. This is the Anycast
address.
•
Both SH1-103 and SH1-104 have two static RP configuration lines. The first shows the RP as
172.31.0.104 for all groups matching ACL 1. The second shows the RP as 172.31.0.98 for all groups
matching ACL 2.
•
Access-list 1 restrains the scope of matching IP addresses to 239.255.0.0/16.
•
SH1-103 and SH1-104 are Anycast RPs for multicast groups 239.255.0.0/16.
Verify the static RP configuration on SH1-107, SH1-108, SH1-109, and SH1-110.
•
SH1-107, SH1-108, SH1-109, and SH1-110 have the same two RP configuration lines as SH1-103
and SH1-104.
•
These four routers see the RP for groups 239.255.0.0/16 as being the router with address
172.31.0.104.
Verify that SH1-110 is the PIM-DR on the networks shared with SH1-109.
•
SH1-109 and SH1-110 have a PIM neighbor relationship on those subnets that they share between
them, specifically VLANs 10-20.
•
SH1-109 sees SH1-110 as being the PIM-DR for all of these VLANs.
Verify that SH1-108 is the PIM-DR on the networks shared with SH1-107.
•
SH1-107 and SH1-108 have a PIM neighbor relationship on those subnets that they share between
them, specifically VLANs 10-20.
•
SH1-107 sees SH1-108 as being the PIM-DR for all of these VLANs.
Verify that SH1-108 and SH1-110, the PIM-DRs see the proper device as the static RP for the
appropriate group range.
•
SH1-108 and SH1-110 both see the router with address 172.31.0.104 as being the RP for groups
239.255.[50-51].[1-10].
•
SH1-108 shows its RPF interface towards this RP as being portchannel 169. This is connected to
SH1-104, the primary PIM-RP.
•
SH1-110 shows its RPF interface towards this RP as being portchannel 171. This is connected to
SH1-104, the primary PIM-RP.
Verify that SH1-110 has the correct mroute entries for all test traffic and that traffic is being hardware
switched.
SH1-110 is the last-hop router for groups 239.255.50.[1-10]. As such, it has the following:
•
A (*, G) for each of the ten groups, as the SPT-threshold is set to infinity.
•
An S-flag for each (*, G) mroute entry.
•
A C-flag for each (*, G) mroute entry.
•
An incoming interface of portchannel 171 for both the mroute and MMLS entries.
•
An outgoing interface of VLAN 17 for both the mroute and MMLS entries.
•
An RPF-MFD tag on the incoming interface of each (*, G) mroute entry.
•
An H-flag for the outgoing interface of each (*, G) mroute entry.
SH1-110 is the first-hop router for groups 239.255.51.[1-10]. As such, it has the following:
•
Both an (S, G) and a (*, G) entry in the mroute table and the MMLS table for each group.
•
An F-flag and a T-flag set for each (S, G) entry in the mroute table.
Cisco IOS Release 12.1(13)E13
294
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
•
An H-flag set for each outgoing interface of the (S, G) in the mroute table.
•
An incoming interface of VLAN 19 for each (S, G) in the mroute and MMLS tables.
•
Two outgoing interfaces, portchannel 171 and VLAN 17, for each (S, G) in the mroute and MMLS
tables.
•
An RPF-MFD tag for each of the (S, G) entries in the mroute table.
Note
The packets switched was shown as 0 (as seen in the output below) but the traffic was flowing. This was
just a cosmetic defect.
Step 10
Verify that SH1-108 has the correct mroute entries for all test traffic and that traffic is being hardware
switched.
SH1-108 is the first-hop router for groups 239.255.50.[1-10]. As such, it has the following:
•
Both an (S, G) and a (*, G) entry in the mroute table
•
An (S, G) only in the MMLS table for each group.
•
An F-flag and a T-flag set for each (S, G) entry in the mroute table.
•
An H-flag set for each outgoing interface of the (S, G) in the mroute table.
•
An incoming interface of VLAN 20 for each (S, G) in the mroute and MMLS tables.
•
Two outgoing interfaces, portchannel 169 and VLAN 16, for each (S, G) in the mroute and MMLS
tables.
•
An RPF-MFD tag for each of the (S, G) entries in the mroute table.
SH1-108 is the last-hop router for groups 239.255.51.[1-10]. As such, it has the following:
Step 11
•
A (*, G) for each of the ten groups, as the SPT-threshold is set to infinity.
•
No MMLS entries for these ten groups. (*, G) flows are software-switched on Sup1 platforms.
•
An S-flag and a C-flag for each (*, G) mroute entry.
•
An incoming interface of portchannel 169 for the mroute entries.
•
An outgoing interface of VLAN 16 for the mroute entries.
Verify that SH1-104 (the PIM-RP) has the correct mroute entries and flags for the test traffic groups and
that traffic is being hardware switched.
SH1-104 is the RP for all groups 239.255.50.[1-10] and 239.255.51.[1-10]. It, therefore, shows the
following:
•
An (S, G) for each entry in both the mroute and MMLS tables.
•
A (*, G) for each entry in the mroute table.
•
An incoming interface of portchannel 69 for groups 239.255.50.[1-10] in the mroute and MMLS
tables.
•
An outgoing interface of portchannel 71 for groups 239.255.50.[1-10] in the mroute and MMLS
tables.
•
An incoming interface of portchannel 71 for groups 239.255.51.[1-10] in the mroute and MMLS
tables.
•
An outgoing interface of portchannel 69 for groups 239.255.51.[1-10] in the mroute and MMLS
tables.
•
A T-flag and an A-flag for each entry in the mroute table.
Cisco IOS Release 12.1(13)E13
295
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
•
An H-flag for each outgoing interface in the mroute table.
•
An RPF-MFD tag for each mroute table (S, G) entry.
Step 12
Display the log for error messages.
Step 13
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that all downstream routers will know the correct device as the RP for the twenty
multicast test groups.
•
We expect that the PIM-DRs will have the proper mroute entries and flags set for groups for which
they are the last-hop router.
•
We expect that the PIM-DRs will have the proper mroute entries and flags set for groups for which
they are the first-hop router.
•
We expect that the primary PIM-RP will have the proper mroute entries and flags set for all test
groups.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 37
Basic Static RP Functionality—Supervisor 22 Test Results
Test
Result
Basic Static RP Functionality—Supervisor 22
Pass
Basic Auto RP Functionality—Supervisor 22
This test verified basic auto-RP functionality using the Supervisor 22 engine.
Goals:
•
Verify the auto-RP configuration on all RP candidates.
•
Verify the auto-RP configuration on the downstream devices SH1-106 (Sup11) and SH1-110
(Sup22).
•
Verify that downstream devices know of the correct RP for the given traffic groups.
•
Verify that the first-hop router has the correct mroute entries and flags for the given multicast test
groups.
•
Verify that the first-hop router has MMLS entries consistent with the mroute table and is hardware
forwarding the test traffic.
•
Verify that the elected RP has the correct mroute entries and flags for the given traffic groups.
•
Verify that the elected RP has MMLS entries consistent with the mroute table and is hardware
forwarding the test traffic.
Primary Devices Used:
•
SH1-99 and SH1-100: Sup22; auto-RP candidates for groups 239.100.[1-3].[1-10]
Cisco IOS Release 12.1(13)E13
296
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
•
SH1-106: Sup11; first-hop router for groups 239.100.2.[1-10]
•
SH1-110: Sup22; first-hop router for groups 239.100.3.[1-10]
Primary IXIA Ports Used:
•
4/2, 13/2
Test Procedure
The procedure used to perform the Basic Auto RP Functionality—Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify the auto-RP configuration on SH1-99 and SH1-100.
For the Auto-RP candidate SH1-99, there are three lines of configuration for the RP information:
1.
A static configuration naming the anycast address 172.31.0.98 as the RP for groups defined by
access-list 3. ACL 3 defines two groups, 224.0.1.39 and 224.0.1.40, which are Auto-RP control
groups. 224.0.1.39 is the group on which candidate RPs announce themselves and mapping agents
listen. Once an RP is elected, the group 224.0.1.40 is used for other routers in the network, which
join this group at startup (by default), to learn of the elected RP address and the groups for which
that is the RP.
2.
SH1-99 is also configured as a PIM Mapping Agent. A Mapping Agent will listen to group
224.0.1.39 for all candidate RPs. It will then elect an RP based on the highest IP address (in the case
of SH1-99 and SH1-100, SH1-100 is selected because its Loopback 1 interface address is higher).
Once it has elected an RP, it will cache RP-to-group mapping information, and send it out
periodically to 224.0.1.40, through which all other routers in the network learn the RP-to-group
information.All auto-RPs candidates are configured to send RP announce messages (to group
224.0.1.39). SH1-99 is announcing its candidacy for those groups defined by access-list 1. ACL 1
includes groups 239.100.0.0 through 239.100.255.255. So SH1-99 is saying "I am an RP candidate
for groups 239.100.x.x/16."
The configuration of SH1-100 is identical to that of SH1-99. SH1-100, by virtue of its higher Loopback
0 interface IP address, is the elected RP for groups 239.100.x.x/16.
Step 5
Verify the auto-RP configuration on downstream devices SH1-106 (Sup11) and SH1-110 (Sup22).
SH1-106 and SH1-110 have identical, and minimal, RP configurations. There are two lines for each:
Step 6
1.
The first line statically defines the RP for the local multicast range of groups 239.255.x.x/16. For
SH1-106, this RP is anycast address 172.31.0.106. For SH1-110, this RP is anycast address
172.31.0.104. The group range is defined in access-list 1.
2.
The second line statically defines the RP for the two auto-RP control groups (224.0.1.39 and
224.0.1.40) as being the anycast 172.31.0.98, with the two groups being defined in ACL 2.
Verify that SH1-106 and SH1-110, the first-hop routers, see the proper device as the elected RP for the
appropriate group ranges.
SH1-106 and SH1-110 obtained this mapping information by listening to group 239.0.1.40. It shows that
for groups 239.98.0.0/16 the RP is 172.31.0.98 and for groups 239.100.0.0/16 the RP is 172.31.0.100.
It got this information from source 172.31.0.100, a Mapping Agent. The output also shows that both RPs
Cisco IOS Release 12.1(13)E13
297
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
in the cache are in use. The output from show ip pim rp is consistent with what is expected. All groups
in the range 239.100.0.0/16 are using 172.31.0.100 as the RP and all groups in the range 239.98.0.0/16
are using 172.31.0.98 as the RP. This is the case for both SH1-106 and SH1-110.
Since the elected RP for groups 239.100.0.0/16 is SH1-100, SH1-106 should show its RPF interface to
the anycast address as being that interface connected to SH1-100. It does, in interface portchannel 167.
With SH1-100 being the elected RP for groups 239.100.0.0/16, SH1-110 should have its RPF interface
for the anycast IP address 172.31.0.100 pointing back to SH1-100. With SH1-100 two hops away from
SH1-110, the output does not prove anything.
Step 7
Verify that SH1-106, the first-hop router for groups 239.100.2.[1-10], has the correct mroute entries for
all test traffic and that that traffic is being hardware switched.
Being the first-hop router, SH1-106 has an (S, G) entry for each of the ten groups for which it is the
first-hop router with the correct interfaces listed (incoming interface of VLAN 49, outgoing interface is
portchannel 167. SH1-106 also has the correct flags set for the (S,G): an F-flag indicating that the source
is registered with the RP, and a T-flag indicating that it has joined the Shortest Path Tree (SPT). The
H-flag is also set on the outgoing interface, indicating that the flow is hardware-switched. The MMLS
entry information (incoming and outgoing interfaces) is consistent with the mroute entry.
Step 8
Verify that SH1-110, the first-hop router for groups 239.100.3.[1-10], has the correct mroute entries for
all test traffic and that traffic is being hardware switched.
Being the first-hop router, SH1-110 has an (S, G) entry for each of the ten groups for which it is the
first-hop router and the correct interfaces listed (incoming interface VLAN 20 and outgoing interface
portchannel 171). SH1-110 also has the correct flags set for the (S,G): an F-flag indicating that the source
is registered with the RP, and a T-flag indicating that it has joined the Shortest Path Tree (SPT). The
H-flag is also set, indicating that the flow is hardware-switched. The MMLS entry information (incoming
and outgoing interfaces) is consistent with the mroute entry.
Step 9
Verify that SH1-100 (the elected PIM-RP) has the correct mroute entries and flags for the test traffic
groups and that traffic is being hardware switched.
SH1-100 is the RP for the all groups 239.100.0.0/16. As the RP, it has an (S, G) entry in its mroute table
for each. It also has the T-flag set, prompting the (S, G) creation. Also, the H-flag is set correctly for each
outgoing interface, as the (S, G) flows are hardware-switched. The interfaces listed in the MMLS entries
for each group are consistent with the respective mroute entries.
The A-flag for the (S, G) entries should be set for all groups on the RP. This flag tells the router to
advertise that (S, G) entry to the MSDP peer with each SA message. The A-flag, however, is not set
consistently for each group listed below. This is due to the behavior of load-balancing packets sourced
from the RP in 12.1E on the 6500. Because of OSPF equal-cost paths from the source to each Anycast
RP, SH1-99 and SH1-100, some sources are registered with SH1-99 and some with SH1-100. SH1-100
is always used, though, to forward the multicast traffic, as it is the elected PIM-RP. So, for some groups,
SH1-100 will not advertise certain (S, G)’s in SA messages.
Step 10
Display the log for error messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that the first-hop routers will learn the correct (elected) RP and RP-to-group mapping
information.
•
We expect that the first-hop routers will have the correct (S, G) entries and flags set for each group.
•
We expect that the elected RP will have the correct (S, G) entries and flags set for each group.
Cisco IOS Release 12.1(13)E13
298
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 38
Basic Auto RP Functionality—Supervisor 22 Test Results
Test
Result
Basic Auto RP Functionality—Supervisor 22
Pass
Auto PIM RP Failover—First Hop Router Impact—Supervisor 11
This test verified multicast functionality on the first-hop router during an auto PIM-RP failover on a
Supervisor 11 platform. SH1-100 is the elected PIM-RP for thirty multicast test groups:
239.100.[1-3].[1-10]. SH1-106 is the Sup11 first-hop router for groups 239.100.2.[1-10]. SH1-100 was
reloaded, and the correct changes in the mroute and MMLS tables of SH1-106 were verified. Once
SH1-100 came back online, it was verified that SH1-106 reverted back to its initial state.
Goals:
•
Verify that the first-hop router has the correct mroute entries, flags and MMLS entries for all ten test
groups.
•
Verify that the first-hop router uses the new RP (SH1-99) for each of the ten test groups when
SH1-100 is failed over.
•
Verify that the first-hop router builds correct state again, sending traffic to the original PIM-RP for
all ten test groups, when it is back online.
Primary Devices Used:
•
SH1-106: Sup11; first-hop router for groups 239.255.2.[1-10]
Primary IXIA Ports Used:
•
12/1, 2/1, 1/2, 2/7, 2/4, 1/1, 2/6, 4/2, 4/6, 3/3, 5/3, 8/1, 7/2, 7/1, 9/1, 9/2, 10/1, 10/2, 13/2, 11/1, 12/2
Test Procedure
The procedure used to perform the Auto PIM RP Failover—First Hop Router Impact—Supervisor 11
test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the first-hop router, SH1-106, knows SH1-100 as the elected PIM-RP for the groups
239.100.2.[1-10].
According to the RP-to-group mapping on the first-hop router, SH1-106, the RP with address
172.31.0.100 is the elected PIM-RP for all groups 239.100.0.0/16. This address is an anycast address
shared by SH1-99 and SH1-100. Due to the higher IP address of its advertising interface, SH1-100
should be the elected PIM-RP.
For each group in the range 239.100.0.0/16, SH1-106 lists the RP with address 172.31.0.100 as the
PIM-RP.
Cisco IOS Release 12.1(13)E13
299
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
SH1-106 shows the reverse-path to the address 172.31.0.100 as being out interface portchannel 167. This
goes to device SH1-100. This indicates that SH1-100 is the elected RP for groups 239.100.0.0/16.
Step 5
Verify that the first-hop router, SH1-106, has the proper mroute and MMLS entries, with the correct flags
for the groups 239.100.2.[1-10].
SH1-106 has an (S, G) entry in its mroute table for each of the ten groups for which it is the first-hop
router. Each (S, G) entry has the F- and T-flags set, as well as the H-flag on each outgoing interface. The
F-flag indicates that the source is registered with the RP. The T-flag indicates that the Shortest Path Tree
(SPT) is being used. The H-flag indicates that the flow is being hardware-switched. The outgoing
interface is portchannel 167, which is connected to SH1-100, the elected PIM-RP. For each group, the
MMLS entry is consistent with the respective mroute entry.
Step 6
Reload SH1-100.
Step 7
Verify that the first-hop router, SH1-106, has the proper mroute and MMLS entries, with the correct flags
for the groups 239.100.2.[1-10] while SH1-100 is offline.
SH1-106 still has an (S, G) entry in its mroute table for each of the ten groups for which it is the first-hop
router. Each (S, G) entry still has the F- and T-flags set, as well as the H-flag on each outgoing interface.
This time, though, the outgoing interface is given as portchannel 67, which is connected to SH1-99. This
is because SH1-99 is now the elected PIM-RP, as SH1-100 is down. For each group, the MMLS entry is
consistent with the respective mroute entry.
Step 8
Once SH1-100 comes back online, verify that the first-hop router, SH1-106, has the proper mroute and
MMLS entries, with the correct flags for the groups 239.100.2.[1-10].
After SH1-100 has come back online and has begun forwarding traffic again, the outgoing interface is
again given as portchannel 167, which is connected to SH1-100. This is because SH1-100 is again the
elected PIM-RP. For each group, the MMLS entry is consistent with the respective mroute entry.
Step 9
Display the log for error messages.
Step 10
Show the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect that prior to the failover, SH1-106, the first-hop router for groups 239.100.2.[1-10],
should have all the correct mroute entries and flags for those ten groups.
•
We expect SH1-106 to have the correct MMLS entries, consistent with the mroute entries, and be
hardware-switching traffic.
•
We expect that after the failover, SH1-106 should adjust its mroute and MMLS entries to reflect the
RP change.
•
We expect that once the original RP is back online and forwarding traffic, SH1-106 should return its
mroute and MMLS entries to their original state.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 39
Auto PIM RP Failover—First Hop Router Impact—Supervisor 11 Test Results
Test
Result
Auto PIM RP Failover—First Hop Router Impact—Supervisor 11 Pass
Cisco IOS Release 12.1(13)E13
300
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Auto PIM RP Failover—First Hop Router Impact—Supervisor 12
This test verified multicast functionality on the first-hop router during an auto PIM-RP failover on a
Supervisor 12 platform. SH1-100 is the elected PIM-RP for thirty multicast test groups:
239.100.[1-3].[1-10]. SH1-114 is the Sup12 first-hop router for groups 239.100.1.[1-10]. SH1-100 was
reloaded, and the correct changes in the mroute and MMLS tables of SH1-114 were verified. Once
SH1-100 came back online, it was verified that SH1-114 reverts back to its initial state.
Goals:
•
Verify that the first-hop router has the correct mroute entries, flags and MMLS entries for all ten test
groups.
•
Verify that the first-hop router uses the new RP (SH1-99) for each of the ten test groups when
SH1-100 is failed over.
•
Verify that the first-hop router builds correct state again, sending traffic to the original PIM-RP for
all ten test groups, when it is back online.
Primary Devices Used:
•
SH1-114: Sup12; first-hop router for groups 239.255.1.[1-10]
Primary IXIA Ports Used:
•
12/1, 2/1, 1/2, 2/7, 2/4, 1/1, 2/6, 4/2, 4/6, 3/3, 5/3, 8/1, 7/2, 7/1, 9/1, 9/2, 10/1, 10/2, 13/2, 11/1, 12/2
Test Procedure
The procedure used to perform the Auto PIM RP Failover—First Hop Router Impact—Supervisor 12
test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the first-hop router, SH1-114, knows SH1-100 as the elected PIM-RP for the groups
239.100.2.[1-10].
According to the RP-to-group mapping on the first-hop router, SH1-114, the RP with address
172.31.0.100 is the elected PIM-RP for all groups 239.100.0.0/16. This address is an anycast address
shared by SH1-99 and SH1-100. Due to the higher IP address of its advertising interface, SH1-100
should be the elected PIM-RP.
For each group in the range 239.100.0.0/16, SH1-114 lists the RP with address 172.31.0.100 as the
PIM-RP.
SH1-114 shows the reverse-path to the address 172.31.0.100 as being out interface portchannel 165. This
goes to device SH1-100. This indicates that SH1-100 is the elected RP for groups 239.100.0.0/16.
Step 5
Verify that the first-hop router, SH1-114, has the proper mroute and MMLS entries, with the correct flags
for the groups 239.100.1.[1-10].
SH1-114 has an (S, G) entry in its mroute table for each of the ten groups for which it is the first-hop
router. Each (S, G) entry has the F- and T-flags set, as well as the H-flag on each outgoing interface. The
F-flag indicates that the source is registered with the RP. The T-flag indicates that the Shortest Path Tree
Cisco IOS Release 12.1(13)E13
301
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
(SPT) is being used. The H-flag indicates that the flow is being hardware-switched. The outgoing
interface is portchannel 165, which is connected to SH1-100, the elected PIM-RP. For each group, the
MMLS entry is consistent with the respective mroute entry.
Step 6
Reload SH1-100.
Step 7
Verify that the first-hop router, SH1-114, has the proper mroute and MMLS entries, with the correct flags
for the groups 239.100.1.[1-10] while SH1-100 is offline
SH1-114 still has an (S, G) entry in its mroute table for each of the ten groups for which it is the first-hop
router. Each (S, G) entry still has the F- and T-flags set, as well as the H-flag on each outgoing interface.
This time, though, the outgoing interface is given as portchannel 65, which is connected to SH1-99. This
is because SH1-99 is now the elected PIM-RP, as SH1-100 is down. For each group, the MMLS entry is
consistent with the respective mroute entry.
Step 8
Once SH1-100 comes back online, verify that the first-hop router, SH1-114, has the proper mroute and
MMLS entries, with the correct flags for the groups 239.100.1.[1-10].
After SH1-100 has come back online and has begun forwarding traffic again, the outgoing interface is
again given as portchannel 165, which is connected to SH1-100. This is because SH1-100 is again the
elected PIM-RP. For each group, the MMLS entry is consistent with the respective mroute entry.
Step 9
Display the log for error messages.
Step 10
Show the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect that prior to the failover, SH1-114, the first-hop router for groups 239.100.1.[1-10],
should have all the correct mroute entries and flags for those ten groups.
•
We expect SH1-114 to have the correct MMLS entries, consistent with the mroute entries, and be
hardware-switching traffic.
•
We expect that after the failover, SH1-114 should adjust its mroute and MMLS entries to reflect the
RP change.
•
We expect that once the original RP is back online and forwarding traffic, SH1-114 should return its
mroute and MMLS entries to their original state.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 40
Auto PIM RP Failover—First Hop Router Impact—Supervisor 12 Test Results
Test
Result
Auto PIM RP Failover—First Hop Router Impact—Supervisor 12 Pass
Auto PIM RP Failover—First Hop Router Impact—Supervisor 22
This test verified multicast functionality on the first-hop router during an auto PIM-RP failover on a
Supervisor 22 platform. SH1-100 is the elected PIM-RP for thirty multicast test groups:
239.100.[1-3].[1-10]. SH1-110 is the Sup22 first-hop router for groups 239.100.3.[1-10]. SH1-100 was
reloaded, and the correct changes in the mroute and MMLS tables of SH1-110 were verified. Once
SH1-100 came back online, it was verified that SH1-110 reverts back to its initial state.
Cisco IOS Release 12.1(13)E13
302
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Goals:
•
Verify that the first-hop router has the correct mroute entries, flags and MMLS entries for all ten test
groups.
•
Verify that the first-hop router uses the new RP (SH1-99) for each of the ten test groups when
SH1-100 is failed over.
•
Verify that the first-hop router builds correct state again, sending traffic to the original PIM-RP for
all ten test groups, when it is back online.
Primary Devices Used:
•
SH1-110: Sup11; first-hop router for groups 239.255.3.[1-10]
Primary IXIA Ports Used:
•
12/1, 2/1, 1/2, 2/7, 2/4, 1/1, 2/6, 4/2, 4/6, 3/3, 5/3, 8/1, 7/2, 7/1, 9/1, 9/2, 10/1, 10/2, 13/2, 11/1, 12/2
Test Procedure
The procedure used to perform the Auto PIM RP Failover—First Hop Router Impact—Supervisor 22
test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the first-hop router, SH1-110, knows SH1-100 as the elected PIM-RP for the groups
239.100.2.[1-10].
According to the RP-to-group mapping on the first-hop router, SH1-110, the RP with address
172.31.0.100 is the elected PIM-RP for all groups 239.100.0.0/16. This address is an anycast address
shared by SH1-99 and SH1-100. Due to the higher IP address of its advertising interface, SH1-100
should be the elected PIM-RP.
Step 5
Verify that the first-hop router, SH1-110, has the proper mroute and MMLS entries, with the correct flags
for the groups 239.100.3.[1-10].
SH1-110 has an (S, G) entry in its mroute table for each of the ten groups for which it is the first-hop
router. Each (S, G) entry has the F- and T-flags set, as well as the H-flag on each outgoing interface. The
F-flag indicates that the source is registered with the RP. The T-flag indicates that the Shortest Path Tree
(SPT) is being used. The H-flag indicates that the flow is being hardware-switched. The outgoing
interface is portchannel 171, which is connected to SH1-104. For each group, the MMLS entry is
consistent with the respective mroute entry.
Step 6
Reload SH1-100.
Step 7
Verify that the first-hop router, SH1-110, has the proper mroute and MMLS entries, with the correct flags
for the groups 239.100.3.[1-10] while SH1-100 is offline.
SH1-110 still has an (S, G) entry in its mroute table for each of the ten groups for which it is the first-hop
router. Each (S, G) entry still has the F- and T-flags set, as well as the H-flag on each outgoing interface.
This time, though, the outgoing interface is given as portchannel 71, which is connected to SH1-103,
which represents the best path to SH1-99, the newly elected PIM-RP, as SH1-100 is down. For each
group, the MMLS entry is consistent with the respective mroute entry.
Step 8
Once SH1-100 comes back online, verify that the first-hop router, SH1-110, has the proper mroute and
MMLS entries, with the correct flags for the groups 239.100.3.[1-10].
Cisco IOS Release 12.1(13)E13
303
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
After SH1-100 has come back online and has begun forwarding traffic again, the outgoing interface is
again given as portchannel 171, which leads to SH1-100. This is because SH1-100 is again the elected
PIM-RP. For each group, the MMLS entry is consistent with the respective mroute entry.
Step 9
Display the log for error messages.
Step 10
Show the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect that prior to the failover, SH1-110, the first-hop router for groups 239.100.3.[1-10],
should have all the correct mroute entries and flags for those ten groups.
•
We expect SH1-110 to have the correct MMLS entries, consistent with the mroute entries, and be
hardware-switching traffic.
•
We expect that after the failover, SH1-110 should adjust its mroute and MMLS entries to reflect the
RP change.
•
We expect that once the original RP is back online and forwarding traffic, SH1-110 should return its
mroute and MMLS entries to their original state.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 41
Auto PIM RP Failover—First Hop Router Impact—Supervisor 22 Test Results
Test
Result
Auto PIM RP Failover—First Hop Router Impact—Supervisor 22 Pass
Auto PIM RP Failover—Traffic Impact—Supervisor 22
This test verified the impact on the traffic during a PIM-RP failover on a Supervisor 22 platform.
SH1-100 is the elected PIM-RP for thirty multicast test groups: 239.255.[1-3].[1-10]. SH1-100 was
reloaded, and the traffic impact was measured.
Goals:
•
Verify that the impact to the traffic from a PIM-RP failover is acceptable.
Primary Devices Used:
•
SH1-100: Sup22
Primary IXIA Ports Used:
•
12/1, 2/1, 1/2, 2/7, 2/4, 1/1, 2/6, 4/2, 4/6, 3/3, 5/3, 8/1, 7/2, 7/1, 9/1, 9/2, 10/1, 10/2, 13/2, 11/1, 12/2
Test Procedure
The procedure used to perform the Auto PIM RP Failover—Traffic Impact—Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Cisco IOS Release 12.1(13)E13
304
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin sending a fixed stream of traffic
Step 5
Force the primary supervisor on SH1-100 to switch to the backup.
Step 6
Measure the traffic loss that occurs.
Step 7
Repeat the reload sequence four more times, each time measuring traffic loss.
Step 8
Determine the average amount of traffic loss.
Step 9
Display the log for error messages.
Step 10
Show the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect the average traffic loss resulting from the failover and recovery of the elected PIM-RP
should be acceptable.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 42
Auto PIM RP Failover—Traffic Impact—Supervisor 22 Test Results
Test
Result
Auto PIM RP Failover—Traffic Impact—Supervisor 22
Pass
Static PIM-RP Failover—Supervisor 11
This test verified multicast functionality of a Supervisor 11 platform during a static PIM-RP failover.
SH1-106 is the primary PIM-RP for ten multicast test groups: 239.255.50.[1-10]. SH1-106 was reloaded,
verifying the correct failover of mrouting state to SH1-105 and the reversion of state back to SH1-106,
after it came back online.
Goals:
•
Verify that the static RP has the correct mroute entries, flags and MMLS entries for all ten test
groups.
•
Verify that each of the ten test groups fails over to the backup PIM-RP after the failure of the
primary, with correct mroute and MMLS state.
•
Verify that all ten groups build correct state again on the primary PIM-RP when it is back online.
Primary Devices Used:
•
SH1-106: Sup11; static RP for groups 239.255.50.[1-10]
Primary IXIA Ports Used:
•
2/2, 2/8
Test Procedure
The procedure used to perform the Static PIM-RP Failover—Supervisor 11 test follows:
Cisco IOS Release 12.1(13)E13
305
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin sending a fixed stream of traffic
Step 5
Verify that the primary PIM-RP, SH1-106, has the proper mroute and MMLS entries, with the correct
flags for all ten groups.
Of the ten groups that SH1-106 is a static RP for, all should be switching using the (S, G) entry. All
should have the following flags set, also: T-flag, indicating that the SPT is being used; A-flag, indicating
that the (S, G) is being Advertised via MSDP to SH1-105, with the SA messages; H-flag, indicating that
traffic is being hardware-switched to the flagged outgoing interface. All three flags are set appropriately
on each group (S,G).
The MMLS entry for each group is correct and consistent with the respective mroute entry.
Step 6
Reload SH1-106.
Step 7
Verify that the new primary PIM-RP, SH1-105, has the correct mroute and MMLS entries, with the
correct flags set, for all twenty groups.
Of the ten groups that SH1-105 is now a static RP for, all should be switching using the (S, G) entry. All
should have the following flags set, also: T-flag, indicating that the SPT is being used; A-flag, indicating
that the (S, G) is being Advertised via MSDP to SH1-106, with the SA messages; H-flag, indicating that
traffic is being hardware-switched to the flagged outgoing interface. All three flags are set appropriately
on SH1-105.
The MMLS entry for each group is correct and consistent with the respective mroute entry.
Step 8
Once SH1-106 comes back online, verify that it is again the RP for all twenty groups and that its
mrouting table and MMLS entries are correct.
SH1-104 is again the primary PIM-RP. The entries, interfaces and flags are similar to those seen before
the failover.
Step 9
Determine the amount of traffic loss from the PIM-RP failover.
Out of 210,000 packets sent through SH1-106, 8745 were lost for multicast group A, and 9497 were lost
for multicast group C during the failover and recovery.
Step 10
Repeat the failover sequence, with traffic, four more times, each time determining traffic loss.
Step 11
Determine the average amount of traffic loss over the five failovers.
Step 12
Display the log for error messages.
Step 13
Show the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect that prior to the failover, SH1-106, the primary PIM-RP, should have all the correct
mroute entries and flags for the twenty groups for which it is the RP.
•
We expect SH1-106 to have the correct MMLS entries, consistent with the mroute entries, and be
hardware-switching traffic.
•
We expect SH1-105 to take over the role of primary PIM-RP when SH1-106 is reloaded, and
correctly populate its mroute and MMLS entries.
Cisco IOS Release 12.1(13)E13
306
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
•
We expect SH1-106 to resume the role of primary PIM-RP when it is back online and capable of
forwarding traffic.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 43
Static PIM-RP Failover—Supervisor 11 Test Results
Test
Result
Static PIM-RP Failover—Supervisor 11
Pass
Static PIM-RP Failover—Supervisor 22—RP Impact
This test verified multicast functionality on the PIM-RP during a PIM-RP failover on a Supervisor 22
platform. SH1-104 is the primary PIM-RP for groups twenty multicast test groups:
239.255.[50-51].[1-10]. SH1-104 was reloaded, verifying the correct failover of mrouting state to
SH1-103 and the reversion of state back to SH1-104, after it came back online.
Goals:
•
Verify that the static RP has the correct mroute entries, flags and MMLS entries for all twenty test
groups.
•
Verify that each of the twenty test groups fails over to the backup PIM-RP after the failure of the
primary, with correct mroute and MMLS state.
•
Verify that all twenty groups build correct state again on the primary PIM-RP when it is back online.
Primary Devices Used:
•
SH1-104: Sup22; static RP for groups 239.255.[50-51].[1-10]
Primary IXIA Ports Used:
•
5/1, 5/2, 8/2, 13/1
Test Procedure
The procedure used to perform the Static PIM-RP Failover—Supervisor 22—RP Impact test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the primary PIM-RP, SH1-104, has the proper mroute and MMLS entries, with the correct
flags for all twenty groups.
Of the twenty groups that SH1-104 is a static RP for, all should be switching using the (S, G) entry. All
should have the following flags set, also: T-flag, indicating that the SPT is being used; A-flag, indicating
that the (S, G) is being Advertised via MSDP to SH1-103, with the SA messages; H-flag, indicating that
traffic is being hardware-switched to the flagged outgoing interface.
The T-flag and the H-flag are set appropriately on all (S, G) entries. The A-flag is set inconsistently on
some entries and the M-flag (indicating that the entry was learned via MSDP) is even set on some (S, G)
mroute entries The DRs are registering some of the sources with SH1-103 and others with SH1-104, due
Cisco IOS Release 12.1(13)E13
307
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
to unicast load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-104
and for others on SH1-103. SH1-104 is always used to send multicast traffic on the RP, though, due to
the RPF interface being to SH1-104 from the DRs. This problem does not appear to result in any packet
loss.
The MMLS entry for each group is correct and consistent with the respective mroute entry.
Step 5
Reload SH1-104.
Step 6
Verify that the new primary PIM-RP, SH1-103, has the correct mroute and MMLS entries, with the
correct flags set, for all twenty groups while SH1-104 is offline.
Of the twenty groups that SH1-103 is now a static RP for, all should be switching using the (S, G) entry.
All should have the following flags set, also: T-flag, indicating that the SPT is being used; A-flag,
indicating that the (S, G) is being Advertised via MSDP to SH1-103, with the SA messages; H-flag,
indicating that traffic is being hardware-switched to the flagged outgoing interface.
The T-flag and the H-flag are set appropriately on all (S, G) entries. The A-flag is set inconsistently on
some entries and the M-flag (indicating that the entry was learned via MSDP) is even set on some (S, G)
mroute entries.
The MMLS entry for each group is correct and consistent with the respective mroute entry.
Step 7
Once SH1-104 comes back online, verify that it is again the RP for all twenty groups and that its
mrouting table and MMLS entries are correct.Display the log for error messages.
Step 8
Show the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect that prior to the failover, SH1-104, the primary PIM-RP, should have all the correct
mroute entries and flags for the twenty groups for which it is the RP.
•
We expect SH1-104 to have the correct MMLS entries, consistent with the mroute entries, and be
hardware-switching traffic.
•
We expect SH1-103 to take over the role of primary PIM-RP when SH1-104 is reloaded, and
correctly populate its mroute and MMLS entries.
•
We expect SH1-104 to resume the role of primary PIM-RP when it is back online and capable of
forwarding traffic.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 44
Static PIM-RP Failover—Supervisor 22—RP Impact Test Results
Test
Result
Static PIM-RP Failover—Supervisor 22—RP Impact
Pass
Static PIM-RP Failover—Supervisor 22—First-Hop Router Impact
This test verified multicast functionality on the first-hop router during a static PIM-RP failover on a
Supervisor 22 platform. SH1-110 is the first-hop router for ten multicast test groups: 239.255.51.[1-10].
SH1-104 (the primary PIM-RP) was reloaded, and the correct failover of mrouting state to SH1-103 was
verified. The reversion of state back to SH1-104, after it is back online, was also verified.
Cisco IOS Release 12.1(13)E13
308
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Goals:
•
Verify that the first-hop router has the correct mroute entries, flags and MMLS entries for all ten test
groups.
•
Verify that each of the ten test groups fails over to the backup PIM-RP after the failure of the
primary, with correct mroute and MMLS state.
•
Verify that all ten groups build correct state again on the primary PIM-RP when it is back online.
Primary Devices Used:
•
SH1-110: Sup22; first-hop router for groups 239.255.51.[1-10]
Primary IXIA Ports Used:
•
5/2, 4/6
Test Procedure
The procedure used to perform the Static PIM-RP Failover—Supervisor 22—First-Hop Router Impact
test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the first-hop router SH1-110 (for groups 239.255.51.[1-10]) see SH1-104 as the primary
PIM-RP.
For the ten groups 239.255.51.[1-10], SH1-110 sees the device with address 172.31.0.104 as the RP. This
is an anycast address shared by SH1-104 and SH1-103.
The first-hop router SH1-110 sees SH1-104 as the primary PIM-RP. This is verified in that its RPF
interface for the anycast address 172.31.0.104 is portchannel 171, which is connected to SH1-104.
Step 5
Verify that the first-hop router SH1-110 has the correct mroute and MMLS entries, with the correct flags
for groups 239.255.51.[1-10].
As the first-hop router, SH1-110 should have the F-flag and T-flag set for each of the ten groups. The
F-flag indicates that the source is registered with the RP. The T-flag indicates that the (S, G) is used to
switch the traffic, as should be the case on all first-hop routers in Sparse-mode. The H-flag should also
be set for any outgoing interface as the Supervisor 22 should hardware-switch any multicast traffic.
Each group does, in fact, have all the correct flags set.
Each group also has an MMLS entry that is consistent with the mroute entry for that group.
Step 6
Reload SH1-104.
Step 7
Verify that the first-hop router now sees SH1-103 as the primary PIM-RP.
Portchannel 71, the RPF interface for the anycast IP address, connects SH1-110 to SH1-103, which is
now considered to be the primary PIM-RP for the test groups.
Step 8
Verify that the first-hop router has updated its mroute and MMLS tables to reflect the RP change.
The only thing that should have changed on the first-hop router is the outgoing interface list for each
group. As SH1-103 is now the primary PIM-RP, the OIL should reflect that in including portchannel 71
(to SH1-103), and excluding portchannel 171 (to SH1-104). This is indeed the case for each group.
Again the MMLS entries are consistent with this change.
Cisco IOS Release 12.1(13)E13
309
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 9
Once SH1-104 comes back online, verify that the first-hop router SH1-110 uses SH1-104 as the primary
PIM-RP again.
The RPF interface for the anycast IP address is again portchannel 171, indicating that SH1-104 is again
the primary PIM-RP.
The OIL for each group again has portchannel 171, instead of portchannel 71. The MMLS entries also
reflect this change.
Step 10
Display the log for error messages.
Step 11
Show the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect SH1-110 to have all the correct mroute entries and flags for those groups for which it is
the first-hop router.
•
We expect SH1-110 to be hardware-switching the multicast traffic for the ten test groups.
•
We expect SH1-110 to properly reflect the change in the primary PIM-RP in its own mroute and
MMLS tables, both with the failover and recovery of SH1-104.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 45
Static PIM-RP Failover—Supervisor 22—First-Hop Router Impact Test Results
Test
Result
Static PIM-RP Failover—Supervisor 22—First-Hop Router Impact
Pass
Static PIM-RP Failover—Supervisor 22—Traffic Impact
This test verified the impact on the traffic during a PIM-RP failover on a Supervisor 22 platform.
SH1-104 is the primary PIM-RP for groups twenty multicast test groups: 239.255.[50-51].[1-10].
SH1-104 was reloaded, and the traffic impact was measured.
Goals:
•
Verify that the impact to the traffic from a PIM-RP failover is acceptable.
Primary Devices Used:
•
SH1-104: Sup22; static RP for groups 239.255.[50-51].[1-10]
Primary IXIA Ports Used:
•
5/1, 5/2, 8/2, 13/1
Test Procedure
The procedure used to perform the Static PIM-RP Failover—Supervisor 22—Traffic Impact test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Cisco IOS Release 12.1(13)E13
310
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin sending a fixed stream of traffic.
Step 5
Reload SH1-104, the primary PIM-RP.
Step 6
Measure the traffic loss that occurs.
Step 7
Repeat the reload sequence four more times, each time measuring traffic loss.
Step 8
Determine the average amount of traffic loss.
Step 9
Display the log for error messages.
Step 10
Show the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect the average traffic loss resulting from the failover and recovery of the primary PIM-RP
to be acceptable.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 46
Static PIM-RP Failover—Supervisor 22—Traffic Impact Test Results
Test
Result
Static PIM-RP Failover—Supervisor 22—Traffic Impact
Pass
Basic IGMP Functionality
Internet Group Management Protocol (IGMP) software components run on both the Cisco router and the
switch. An IGMP-capable IP multicast router sees all IGMP packets and can inform the switch when
specific hosts join or leave IP multicast groups.
When the IGMP-capable router receives an IGMP control packet, it creates an IGMP packet that
contains the request type (either join or leave), the multicast group address, and the MAC address of the
host. The router sends the packet to a well-known address to which all switches listen. When a switch
receives the packet, the supervisor engine interprets the packet and modifies the forwarding table
automatically. Cisco Group Management Protocol (CGMP) should seamlessly integrate with IGMP and
performs the same function.
This test verified basic IGMP functionality.
Goals:
•
Verify that IGMP entries are created on the proper devices for both L3 and VLAN interfaces.
Primary Devices Used:
•
SH1-106: Sup11; VLAN 41; groups 239.100.3.[1-10]
•
SH1-105: Sup11; L3 interface on secondary subnet on non-PIM-DR (NDR); groups
239.100.1.[1-10]
Cisco IOS Release 12.1(13)E13
311
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
•
SH1-110: Sup22; VLAN 11; VLAN 16; L3 interface on secondary subnet on PIM-DR; groups
239.100.[1-2].[1-10]
•
SH1-102: Sup22; VLAN 43; L3 interface on PIM-DR; groups 239.100.3.[1-10]
•
SH1-109: Sup22; L3 interface on NDR; groups 239.100.1.[1-10]
Primary IXIA Ports Used:
•
2/6, 1/1, 10/1, 11/1
Test Procedure
The procedure used to perform the Basic IGMP Functionality test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-102 has IGMP entries for groups 239.100.3.[1-10] which contain the correct interfaces.
Step 5
Verify that SH1-105 has IGMP entries for groups 239.100.1.[1-10] which contain the correct interfaces.
Step 6
Verify that SH1-106 has IGMP entries for groups 239.100.3.[1-10] which contain the correct interfaces.
Step 7
Verify that SH1-109 has IGMP entries for groups 239.100.1.[1-10] which contain the correct interfaces.
Step 8
Verify that SH1-110 has IGMP entries for groups 239.100.1.[1-10] which contain the correct interfaces.
Step 9
Verify that SH1-110 has IGMP entries for groups 239.100.2.[1-10] which contain the correct interfaces.
For groups 239.100.2.[1-10], SH1-110 has the correct interfaces joined in VLAN 16 and
GigabitEthernet4/16. It should be noted that Gi4/16 is a Layer 3 interface on a secondary subnet.
Step 10
Display the log for error messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect IGMP to function correctly on a variety of receiving interfaces, including VLANs, Layer
3 interfaces, and secondary subnets.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 47
Basic IGMP Functionality Test Results
Test
Result
Basic IGMP Functionality
Pass
Cisco IOS Release 12.1(13)E13
312
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
IGMP Leave/Join Functionality
Internet Group Management Protocol (IGMP) software components run on both the Cisco router and the
switch. An IGMP-capable IP multicast router sees all IGMP packets and can inform the switch when
specific hosts join or leave IP multicast groups.
When the IGMP-capable router receives an IGMP control packet, it creates an IGMP packet that
contains the request type (either join or leave), the multicast group address, and the MAC address of the
host. The router sends the packet to a well-known address to which all switches listen. When a switch
receives the packet, the supervisor engine interprets the packet and modifies the forwarding table
automatically. Cisco Group Management Protocol (CGMP) should seamlessly integrate with IGMP and
performs the same function.
This test verified basic IGMP functionality.
Goals:
•
Verify that IGMP leave requests are processed correctly on the router and traffic is stopped.
•
Verify that IGMP join requests are processed correctly and traffic is restarted.
Primary Devices Used:
•
SH1-105: Sup11; L3 interface on secondary subnet on NDR; groups 239.100.1.[1-10]
•
SH1-108: Sup12; VLAN 11; groups 239.100.1.[1-10]
•
SH1-110: Sup22; L3 interface on DR; groups 239.100.2.[1-10]
Primary IXIA Ports Used:
•
1/1, 8/1, 12/2
Test Procedure
The procedure used to perform the IGMP Leave/Join Functionality test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the IOS version under test. Verify the uptime and that the box hasn't
reloaded unnecessarily. Verify that there is not any process spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-105 has IGMP entries for groups 239.100.1.[1-10] with interface GigabitEthernet3/2
listed as a receiver.
SH1-105 has a record of an IGMP join for interface GigabitEthernet3/2 for all groups, as it should.
Step 5
Verify that SH1-105 has mroute entries for the groups 239.100.1.[1-10] and is forwarding traffic out the
appropriate interface.
SH1-105 has an mroute entry for all groups with GigabitEthernet3/2 in the OIL, as it should. Packets are
being forwarded out interface Gi3/2, as they should be.
Step 6
Turn on debugging for IGMP on SH1-105.
Cisco IOS Release 12.1(13)E13
313
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 7
Stop the IGMP protocol receiver on IXIA port 1/1, recording any debugs and verifying that traffic to the
receiver has stopped.
For each of the ten mcast test groups, there are the following:
•
SH1-105 received a Leave group message from the IXIA port (172.31.205.11) for each group
•
SH1-105 received a Group record for each group from the IXIA port indicating it wishes to receive
traffic for that group from 0 sources
•
SH1-105 lowers the IGMP expiration timer to 1 second for each group on interface
GigabitEthernet3/2 and
•
SH1-105 then sends one more Query for the group to the leaving interface, as per IGMP v2 rules
and, further down in the debugs:
•
SH1-105 sends a second and final Query out the leaving interface for each group, as per IGMP v2
rules
•
SH1-105 switches to INCLUDE mode for each group for the leaving interface, stopping traffic to
that interface
SH1-105 is no longer sending traffic to the receiver on interface Gi3/2.
Note
Step 8
There may me a very small amount of background traffic seen still going to the receiver. It can be ignored
for this test.
Start the IGMP protocol receiver on IXIA port 1/1, recording any debugs and verifying that traffic is
being sent to the receiver again.
For each of the ten groups receiving test multicast traffic, there are the following in the debugs:
•
SH1-105 receives an IGMP v2 Report on the interface attached to the receiver for the test group
•
SH1-105 receives a Group record from the IXIA receiver for the test group
•
SH1-105 adds the interface GigabitEthernet3/2 to the list of interfaces to transmit group traffic to
•
SH1-105 switches to EXCLUDE mode for the group on the interface
•
The EXCLUDE group timer is updated for the group
SH1-105 is again sending traffic to the IXIA receiver out interface GigabitEthernet3/2.
Step 9
Turn off all debugging on SH1-105.
Step 10
Verify that SH1-108 has IGMP entries for groups 239.100.1.[1-10] with interface VLAN 11 listed as
receiver.
SH1-108 has a record of an IGMP join for interface VLAN 11 for all groups, as it should.
Step 11
Verify that SH1-108 has mroute entries for the groups 239.100.1.[1-10] with VLAN 11 in the OIL, and
that the Dista-1 device is forwarding traffic out to the receiver.
SH1-108 has an mroute entry for all groups with VLAN 11 in the OIL, as it should. Packets are being
forwarded out port 6/3, as they should be.
Step 12
Turn on debugging for IGMP on SH1-107 and SH1-108.
Step 13
Stop the IGMP protocol receiver on IXIA port 8/1, recording any debugs and verifying that traffic to the
receiver has stopped.
Cisco IOS Release 12.1(13)E13
314
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Note
SH1-107 is the IGMP Querier for VLAN 11, and so will also participate in the leave process for that
VLAN .
For each of the ten mcast test groups, there are the following:
•
SH1-107 and SH1-108 received a Leave group message from the IXIA port (172.31.11.81) for each
group
•
SH1-107 and SH1-108 received a Group record for each group from the IXIA port indicating it
wishes to receive traffic for that group from 0 sources
•
SH1-107 and SH1-108 lower the IGMP expiration timer to 1 second for each group on interface
VLAN 11
•
SH1-107, the IGMP Querier, sends a series of two more group-specific IGMP Queries on VLAN 11
to ensure there are no more receivers on the subnet.
and, further down in the debugs:
•
Both SH1-108 and SH1-107 switch to INCLUDE mode for each group for the leaving interface,
stopping traffic to that interface
The IXIA port attached to Dista-1 port 6/3is no longer receiving multicast test traffic.
Note
Step 14
Note
There may me a very small amount of background traffic seen still going to the receiver. It can be ignored
for this test.
Start the IGMP protocol receiver on IXIA port 8/1, recording any debugs and verifying that traffic is
being sent to the receiver again.
As SH1-107 is the IGMP Querier for VLAN 11, it is very involved in the joining process for the
multicast test groups.
For each of the ten groups receiving test multicast traffic, there are the following in the debugs:
•
SH1-107 and SH1-108 receive an IGMP v2 Report on the interface attached to the receiver for the
test group
•
SH1-107 and SH1-108 receive a Group record from the IXIA receiver for the test group
•
SH1-107 and SH1-108 add the interface VLAN 11 to the list of interfaces to transmit group traffic to
•
SH1-107 and SH1-108 switch to EXCLUDE mode for the group on the interface
•
The EXCLUDE group timer is updated for the group
Dista-1 is again forwarding traffic out port 4/1 to the IXIA receiver.
Step 15
Turn off all debugging on SH1-107 and SH1-108.
Step 16
Verify that SH1-110 has IGMP entries for groups 239.100.1.[1-10] with interface GigabitEthernet8/16
listed as a receiver.
SH1-110 has a record of an IGMP join for interface GigabitEthernet8/16 for all groups, as it should.
Step 17
Verify that SH1-110 has mroute entries for the groups 239.100.1.[1-10] and is forwarding traffic out the
appropriate interface, GigabitEthernet8/16.
SH1-110 has an mroute entry for all groups with GigabitEthernet8/16 in the OIL, as it should. Packets
are being forwarded out interface Gi8/16, as they should be.
Cisco IOS Release 12.1(13)E13
315
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 18
Turn on debugging for IGMP on SH1-110.
Step 19
Stop the IGMP protocol receiver on IXIA port 12/2, recording any debugs and verifying that traffic to
the receiver has stopped.
For each of the ten mcast test groups, there are the following:
•
SH1-110 received a Leave group message from the IXIA port (172.31.250.2) for each group
•
SH1-110 received a Group record for each group from the IXIA port
•
SH1-110 lowers the IGMP expiration timer to 1 second for each group on interface
GigabitEthernet8/16 and
•
SH1-110 then sends one more Query for the group to the leaving interface, as per IGMP v2 rules
•
and, further down in the debugs:
•
SH1-110 sends a second and final Query out the leaving interface for each group, as per IGMP v2
rules
•
SH1-110 switches to INCLUDE mode for each group for the leaving interface, stopping traffic to
that interface
Interface Gi8/16 of SH1-110 is no longer transmitting multicast test traffic to the former receiver.
Step 20
Start the IGMP protocol receiver on IXIA port 12/2, recording any debugs and verifying that traffic is
being sent to the receiver again.
For each of the ten groups receiving test multicast traffic, there are the following in the debugs:
•
SH1-110 receives an IGMP v2 Report on the interface attached to the receiver for the test group
•
SH1-110 receives a Group record from the IXIA receiver for the test group
•
SH1-110 adds the interface GigabitEthernet8/16 to the list of interfaces to transmit group traffic to
•
SH1-110 switches to EXCLUDE mode for the group on the interface
•
The EXCLUDE group timer is updated for the group
SH1-110 is once again sending test traffic out interface GigabitEthernet8/16 to the IXIA receiver.
Step 21
Turn off all debugging on SH1-110.
Step 22
Display the log for error messages.
Step 23
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that the router is expected to cease transmitting traffic to the receiver when the IGMP
leaves are received and processed.
•
We expect that the router is expected to process the new IGMP reports received and begin
transmitting traffic to the receiver again.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco IOS Release 12.1(13)E13
316
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Results
Table 48
IGMP Leave/Join Functionality Test Results
Test
Result
IGMP Leave/Join Functionality
Pass
Non-RPF Rate Limiting and Multicast Stub—Supervisor 1
Stub multicast routing allows you to configure remote and stub routers as IGMP proxy agents. Instead
of fully participating in PIM, these stub routers simply forward IGMP messages from the hosts to the
upstream multicast router.
This test verified that the multicast stub command worked and that non-Reverse Path Forwarding (RPF)
rate limiting functionality worked on Policy Feature Cards (PFC1 and PFC2), and dCEF, including a
hardware shortcut.
PFC1, PFC2, and the DFCs support ACL-based filtering of RPF failures for sparse mode stub networks.
When you enable the ACL-based method of filtering Reverse Path Forwarding failures by entering the
mls ip multicast stub command on the redundant router, the ACLs automatically download to the PFC
and are applied to the interface you specify.
access-list
access-list
access-list
access-list
access-list
100
100
100
100
100
permit ip A.B.C.0 0.0.0.255 any
permit ip A.B.D.0 0.0.0.255 any
permit ip any 224.0.0.0 0.0.0.255
permit ip any 224.0.1.0 0.0.0.255
deny ip any 224.0.0.0 15.255.255.255
The ACLs filter Reverse Path Forwarding failures and drop them in hardware so that they are not
forwarded to the router. This test grades multicast stub functionality on the PFC1 (on SH1-107).
Multicast traffic was sent from one side of the network to the other (from Dista-2 to Dista-1). As a
component of this test, the non-RPF rate-limiting functionality was observed.
In this part of the test, SH1-107 was configured to be the multicast stub router. Ten groups of multicast
traffic (groups 239.100.1.1 through 239.100.1.10) were sent from Dista-1. Joins for these five groups
were sent from Dista-1. The IP address of the remote interface connecting SH1-107 to SH1-104 was
configured as the IGMP helper address. The IGMP join packets that were received by SH1-107 were
forwarded via this address statement to SH1-104. All ten groups should appear on SH1-104, when the
show ip igmp groups command is used.
Coupled with the mls ip multicast stub command on SH1-107 is the ip pim neighbor-filter access-list
command configured on SH1-104. This configuration blocked PIM neighbor updates coming from
SH1-107, and made SH1-107 truly transparent to the rest of multicast functionality.
Devices under test: SH1-107, SH1-108, SH1-104.
Test Procedure
The procedure used to perform the Non-RPF Rate Limiting and Multicast Stub—Supervisor 1 test
follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Cisco IOS Release 12.1(13)E13
317
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 4
Configure the VLAN 11 interface (source of IGMP joins) on SH1-107 as a multicast stub.
Step 5
Configure the IP helper address for SH1-107 VLAN 11, the address on SH1-104 to which SH1-107 will
forward the IGMP join packets.
With this helper-address configured, SH1-107 will process the IGMP packets itself, and will forward
them to SH1-104, as well.
Step 6
Configure SH1-104 to filter out IP PIM neighbor updates coming from SH1-107 on the interface
portchannel 68. Verify that access list 10 exists and points to the correct IP address of the blocked PIM
updates (the IP address of the interface on SH1-107 connected to SH1-104, or 172.31.1.102).
SH1-104 will no longer accept PIM updates from SH1-107.
This access-list, coupled with the filter configured above, will cause any traffic coming from SH1-107
(IP address 172.31.1.102, the address of the remote side of portchannel 68, which is SH1-104's
connection to SH1-107), including PIM neighbor updates, to be denied.
Step 7
Begin the IXIA traffic stream. This is multicast test traffic stream A sending from ten incrementing IP
sources to ten multicast groups, 230.100.1.[1-10]. It will send 5 minutes of traffic at a rate of 1000pps.
Step 8
Verify that the IGMP join messages have been forwarded from SH1-107 to SH1-104 and that SH1-104
does not register SH1-107 as an IP PIM neighbor:
SH1-104 is now receiving and processing IGMP packets sent by the IXIA receiver. The non-boldfaced
groups shown here are also being sent from the IXIA receiver. SH1-107, which is connected to SH1-104
via portchannel 68, is not listed among SH1-104's PIM neighbors. The filter worked.
Step 9
Verify that RPF rate-limiting is done in hardware on the stub router.
Rate-limiting of RPF failures is done in hardware. Note that Netflow is used for the hardware processing
of RPF failures. This is characteristic of the Supervisor 1.
Step 10
Determine the path of traffic to the receiver, starting at SH1-104 (the rendezvous point).
For each of the ten multicast groups, SH1-100 has both a (*, G) and an (S, G) entry. The (*, G) entry is
not being used, as indicated by the "Null" Incoming Interface List (IIL). The (S, G) entry is being used,
because SH1-100 is the RP for the test multicast groups.
The (S, G) entry is correct, with portchannel 65 in the IIL, and portchannels 17 in the Outgoing Interface
List (OIL).
SH1-104 is correctly forwarding traffic out both portchannels 68 and 69, to SH1-107 and SH1-108,
respectively. This is because both interfaces are listed in the OILs for the (S, G) entries above.
SH1-107 and SH1-108 are PIM neighbors with each other via VLANs 10-20. SH1-107 considers
SH1-108 to be the PIM Designated Router (PIM-DR) for each of the VLANs listed.
As SH1-108 is the PIM-DR for all traffic for VLANs 10-20, as shown above, SH1-107 should not
forward any multicast traffic to the destination. In the mroute table of SH1-107, we can see that the OIL
for each group entry is "Null," indicating that no traffic will be forwarded. This is correct. The IIL
correctly shows the portchannel 168 interface, as the multicast traffic is coming from SH1-104.
Indeed, no traffic is forwarded out portchannel 10 towards the destination. The InMcastPkts counter is
increasing because SH1-108 floods the multicast traffic onto VLAN 11, towards the destination. Dista-1,
being a Layer 2 device, floods the traffic to all ports in VLAN 11, including the channel to SH1-107.
Since SH1-108 is the PIM-DR, it should be forwarding traffic to the destination. Its mroute table
indicates that it is. It has portchannel 169 (from SH1-104) in the IIL for each multicast group, and it has
VLAN 11 in the OIL for each multicast group. It will therefore forward the traffic out VLAN 11 toward
the destination.
It is forwarding traffic out the portchannel 10 interface, which carries VLAN 11.
Cisco IOS Release 12.1(13)E13
318
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 11
Verify that 100 percent of the multicast traffic that was sent is received on the appropriate port (zero
packet loss).
Step 12
Negate the commands configured in Step 4 through Step 6.
Step 13
Display the log for error messages.
Step 14
Show the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect that SH1-107 will act as a multicast stub router and forward IGMP packets to its
helper-address, on SH1-104.
•
We expect that SH1-104 will receive and process the IGMP packets sent by SH1-107.
•
We expect SH1-104 to not have SH1-107 listed in its PIM neighbor table, when the neighbor-filter
command is configured.
•
We expect rate-limiting of non-RPF failures to be done in hardware.
•
We expect all traffic sent to be received by the appropriate receiver(s), following the correct path.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 49
Non-RPF Rate Limiting and Multicast Stub—Supervisor 1 Test Results
Test
Result
Non-RPF Rate Limiting and Multicast Stub—Supervisor 1
Pass
Non-RPF Rate Limiting and Multicast Stub—Supervisor 2
Stub multicast routing allows you to configure remote and stub routers as IGMP proxy agents. Instead
of fully participating in PIM, these stub routers simply forward IGMP messages from the hosts to the
upstream multicast router.
This test verified that the multicast stub command worked and that non-Reverse Path Forwarding (RPF)
rate limiting functionality worked on Policy Feature Cards (PFC1 and PFC2), and dCEF, including a
hardware shortcut.
PFC1, PFC2, and the DFCs support ACL-based filtering of RPF failures for sparse mode stub networks.
When you enable the ACL-based method of filtering Reverse Path Forwarding failures by entering the
mls ip multicast stub command on the redundant router, the ACLs automatically download to the PFC
and are applied to the interface you specify.
access-list
access-list
access-list
access-list
access-list
100
100
100
100
100
permit ip A.B.C.0 0.0.0.255 any
permit ip A.B.D.0 0.0.0.255 any
permit ip any 224.0.0.0 0.0.0.255
permit ip any 224.0.1.0 0.0.0.255
deny ip any 224.0.0.0 15.255.255.255
The ACLs filter Reverse Path Forwarding failures and drop them in hardware so that they are not
forwarded to the router. Multicast traffic was sent from one side of the network to the other (from Dista-1
to Dista-2). As a component of this test, the non-RPF rate limiting functionality was observed.
Cisco IOS Release 12.1(13)E13
319
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
In this part of the test, SH1-109 was configured to be the multicast stub router. Ten groups of multicast
traffic (groups 239.100.1.1 through 239.100.1.10) were sent from Dista-1. Joins for these five groups
were sent from an IXIA port connected to Dista-2. The IP address of the remote interface connecting
SH1-109 to SH1-104 was configured as the IGMP helper address. The IGMP join packets that are
received by SH1-109 were forwarded via this address statement to SH1-104. All ten groups should
appear on SH1-104, when the show ip igmp groups command is used.
Coupled with the mls ip multicast stub command on SH1-109 is the ip pim neighbor-filter access-list
command configured on SH1-104. This configuration blocked PIM neighbor updates coming from
SH1-109, and made SH1-109 truly transparent to the rest of multicast functionality.
Devices under test: SH1-109, SH1-110, SH1-104.
Test Procedure
The procedure used to perform the Non-RPF Rate Limiting and Multicast Stub—Supervisor 2 test
follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Configure the VLAN 11 interface (source of IGMP joins) on SH1-109 as a multicast stub.
Step 5
Configure the IP helper address for SH1-109 VLAN 11, the address on SH1-104 to which SH1-109 will
forward the IGMP join packets.
With this helper-address configured, SH1-109 will process the IGMP packets itself, and will forward
them to SH1-104, as well.
Step 6
Configure SH1-104 to filter out IP PIM neighbor updates coming from SH1-109 on the interface
portchannel 70. Verify that access list 20 exists and points to the correct IP address of the blocked PIM
updates (the IP address of the interface on SH1-109 connected to SH1-104, or 172.31.1.110).
This access-list will cause any traffic coming from SH1-109 (IP address 172.31.1.110, the address of the
remote side of portchannel 70, which is SH1-104's connection to SH1-109), including PIM neighbor
updates, to be denied.
Step 7
Begin the IXIA traffic stream. This is multicast test traffic stream A sending from ten incrementing IP
sources to ten multicast groups, 230.100.1.[1-10]. It will send 5 minutes of traffic at a rate of 1000pps.
Step 8
Verify that the IGMP join messages have been forwarded from SH1-109 to SH1-104 and that SH1-104
does not register SH1-109 as an IP PIM neighbor:
SH1-104 is now receiving and processing IGMP packets sent by the IXIA receiver.
SH1-109, which is connected to SH1-104 via portchannel 70, is not listed among SH1-104's PIM
neighbors. The filter worked.
Step 9
Verify that RPF rate-limiting is done in hardware on the stub router.
Rate-limiting of RPF failures is done in hardware. Note that CEF is used for the hardware processing of
RPF failures. This is characteristic of the Supervisor 2.
Step 10
Determine the path of traffic to the receiver, starting at SH1-100 (the rendezvous point). Traffic is
expected to be sent out portchannel 17 from SH1-100 to SH1-104 and then out both interfaces,
portchannels 70 and 71 from SH1-104, to SH1-109 and SH1-110, respectively, because there are IGMP
Cisco IOS Release 12.1(13)E13
320
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
joins coming from portchannel 70 (forwarded from SH1-109) and PIM requests coming from
portchannel 71 (from SH1-110). The traffic should be forwarded, beyond that, only by SH1-110, because
that is the PIM-DR for that segment. SH1-109 should not be forwarding VLAN traffic.
For each of the ten multicast groups, SH1-100 has both a (*, G) and an (S, G) entry. The (*, G) entry is
not being used, as indicated by the "Null" Incoming Interface List (IIL). The (S, G) entry is being used,
because SH1-100 is the RP for the test multicast groups.
The (S, G) entry is correct, with portchannel 65 in the IIL, and portchannels 17 in the Outgoing Interface
List (OIL).
SH1-104 is correctly forwarding traffic out both portchannels 70 and 71, to SH1-109 and SH1-110,
respectively. This is because both interfaces are listed in the OILs for the (S, G) entries above.
SH1-109 and SH1-110 are PIM neighbors with each other via VLANs 10-20 and portchannel 1. SH1-109
considers SH1-110 to be the PIM Designated Router (PIM-DR) for each of the 11 VLANs listed and
portchannel 1.
Indeed, no traffic is forwarded out portchannel 20 towards the destination.As SH1-110 is the PIM-DR
for all traffic for VLANs 10-20, as shown above, SH1-109 should not forward any multicast VLAN
traffic to the destination. In the mroute table of SH1-109, we can see that the OIL for each group entry
contains only Gi7/16 and that no VLAN traffic will be forwarded. This is correct. The IIL correctly
shows the portchannel 170 interface, as the multicast traffic is coming from SH1-104.
Since SH1-110 is the PIM-DR, it should be forwarding traffic to the destination. Its mroute table
indicates that it is. It has portchannel 171 (from SH1-104) in the IIL for each multicast group, and it has
VLAN 11 in the OIL for each multicast group. It will therefore forward the traffic out VLAN 11 toward
the destination.
It is forwarding traffic out the portchannel 20 interface, which carries VLAN 11. The high value of this
counter is due to background traffic that is also being forwarded by SH1-110.
Step 11
Verify that 100 percent of the multicast traffic that was sent is received on the appropriate port (zero
packet loss).
Step 12
Negate the commands configured in Step 4 through Step 6.
Step 13
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 14
Show the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect that SH1-109 will act as a multicast stub router and forward IGMP packets to its
helper-address, on SH1-104.
•
We expect that SH1-104 will receive and process the IGMP packets sent by SH1-109.
•
We expect SH1-104 to not have SH1-109 listed in its PIM neighbor table, when the neighbor-filter
command is configured.
•
We expect rate-limiting of non-RPF failures to be done in hardware.
•
We expect all traffic sent to be received by the appropriate receiver(s), following the correct path.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco IOS Release 12.1(13)E13
321
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Results
Table 50
Non-RPF Rate Limiting and Multicast Stub—Supervisor 2 Test Results
Test
Result
Non-RPF Rate Limiting and Multicast Stub—Supervisor 2
Pass
Layer 2 GEC Failover—SH1-110 to Dista-2
This test verified the ability of the devices to recover from a Layer 2 GEC failover, altering multicast
routing state in order to minimize traffic loss. Portchannel 20 on SH1-110 will be failed. It consists of
four ports spread evenly over two WS-X6516-GBIC modules.
Goals:
•
Verify that the NDR, SH1-109, builds the correct multicast routing states when the DR, SH1-110,
is severed from the Layer 2 device, Dista-2.
•
Verify that SH1-109 takes over the first-hop router role from SH1-110.
•
Verify that SH1-110 resumes the first-hop router and PIM-DR roles when the GEC is brought back
up.
•
Verify that traffic loss is minimal.
Primary Devices Used:
•
SH1-110: Sup22; last-hop router for groups 239.100.[1-2].[1-10]; last-hop router (DR) for groups
239.100.3.[1-10]
•
SH1-109: Sup22; will take over first- and last-hop router roles from SH1-110 for groups above
Primary IXIA Ports Used:
•
All
Test Procedure
The procedure used to perform the Layer 2 GEC Failover—SH1-110 to Dista-2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-110 is beginning the procedure with the correct multicast routing states.
For each group (239.100.1.x and 239.100.2.x) with SH1-110 being the last-hop router, verify a (*, G)
entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to infinity,
preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry:
an S-flag because the traffic is forwarded using Sparse-mode, and a C-flag because the receiver is
directly connected to SH1-110. For each group, the Incoming Interface should be portchannel 171 (from
SH1-104).
For 239.100.1.x groups, the Outgoing Interface List (OIL) should contain two interfaces: VLAN 11 and
GigabitEthernet8/16.
Cisco IOS Release 12.1(13)E13
322
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
For 239.100.2.x groups, the Outgoing Interface List (OIL) should contain two interfaces: VLAN 16 and
GigabitEthernet4/16.
Each should have an H-flag next to it, indicating that it is being Hardware-switched. It should be noted
that the receiver interface GigabitEthernet4/16 is on a secondary subnet.For each group (239.100.3.x)
with SH1-110 being the first-hop router,SH1-110 has an (S, G) entry in its mroute table. Each (S, G)
entry has the F- and T-flags set, as well as the H-flag on each outgoing interface. The F-flag indicates
that the source is registered with the RP. The T-flag indicates that the Shortest Path Tree (SPT) is being
used. The H-flag indicates that the flow is being hardware-switched. The incoming interface list is
VLAN 20. The outgoing interface list is VLAN 10 and portchannel 171 which is connected to SH1-104.
Step 5
Verify that SH1-110 is passing traffic both ways over all four interfaces in portchannel 20.
Step 6
Begin sending a fixed stream of traffic
Step 7
Shut down portchannel 20 on SH1-110.
Step 8
Verify that SH1-109 builds the correct multicast routing states as the new first- and last-hop router for
the various groups.
For each group (239.100.1.x and 239.100.2.x) with SH1-109 being the new last-hop router, verify a (*,
G) entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to infinity,
preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry:
an S-flag because the traffic is forwarded using Sparse-mode, and a C-flag because the receiver is
directly connected to SH1-110. For each group, the Incoming Interface should be portchannel 170 (from
SH1-104).
For 239.100.1.x groups, the Outgoing Interface List (OIL) should contain two interfaces: VLAN 11 and
GigabitEthernet7/16.
For 239.100.2.x groups, the Outgoing Interface List (OIL) should contain one interface: VLAN 16.
Each should have an H-flag next to it, indicating that it is being Hardware-switched. It should be noted
that the receiver interface GigabitEthernet4/16 is on a secondary subnet.For each group (239.100.3.x)
with SH1-110 being the first-hop router,SH1-110 has an (S, G) entry in its mroute table. Each (S, G)
entry has the F- and T-flags set, as well as the H-flag on each outgoing interface. The F-flag indicates
that the source is registered with the RP. The T-flag indicates that the Shortest Path Tree (SPT) is being
used. The H-flag indicates that the flow is being hardware-switched. The incoming interface list is
VLAN 20. The outgoing interface list is VLAN 10 and GigabitEthernet3/16.
Step 9
Measure traffic loss due to the etherchannel failure.
Step 10
Bring portchannel 20 of SH1-110 back online.
Step 11
With traffic running continuously, verify that SH1-110 again builds the correct multicast routing states
for the thirty test groups.
For each group (239.100.1.x and 239.100.2.x) with SH1-110 being the last-hop router, verify a (*, G)
entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to infinity,
preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry:
an S-flag because the traffic is forwarded using Sparse-mode, and a C-flag because the receiver is
directly connected to SH1-110. For each group, the Incoming Interface should be portchannel 171 (from
SH1-104).
For 239.100.1.x groups, the Outgoing Interface List (OIL) should contain two interfaces: VLAN 11 and
GigabitEthernet8/16.
For 239.100.2.x groups, the Outgoing Interface List (OIL) should contain two interfaces: VLAN 16 and
GigabitEthernet4/16.
Cisco IOS Release 12.1(13)E13
323
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Each should have an H-flag next to it, indicating that it is being Hardware-switched. It should be noted
that the receiver interface GigabitEthernet4/16 is on a secondary subnet.For each group (239.100.3.x)
with SH1-110 being the first-hop router,SH1-110 has an (S, G) entry in its mroute table. Each (S, G)
entry has the F- and T-flags set, as well as the H-flag on each outgoing interface. The F-flag indicates
that the source is registered with the RP. The T-flag indicates that the Shortest Path Tree (SPT) is being
used. The H-flag indicates that the flow is being hardware-switched. The incoming interface list is
VLAN 20. The outgoing interface list is VLAN 10 and portchannel 171 which is connected to SH1-104.
Step 12
Verify that all four interfaces in portchannel 20 are passing traffic.
Step 13
Verify that the CBL values.for SH1-110 portchannel 20 show forwarding state for all four interfaces.
The CBL value for both is 0x0000 0F00. This indicates that port 5 and port 6 of slot3 and port 5 and port
6 of slot 4 are both forwarding as expected. To understand how to interpret the CBL values correctly,
please look at Part 6 (Native) of the following document:
Step 14
Repeat the failover sequence four more times with a fixed amount of traffic, each time measuring the
traffic loss caused by the failover.
Step 15
Determine the average amount of traffic loss over the five failovers.
Step 16
Display the log for error messages.
Step 17
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that traffic will failover and be forwarded by SH1-109 when portchannel 20 between
SH1-110 and Dista-2 is torn down.
•
We expect that this failover will take place in a reasonable amount of time (within the 10-second
HSRP dead timer value for local receivers and within 40 second OSPF dead time for remote
receivers).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 51
Layer 2 GEC Failover—SH1-110 to Dista-2 Test Results
Test
Result
Layer 2 GEC Failover—SH1-110 to Dista-2
Pass
Layer 2 GEC Failover—SH1-108 to Dista-1
This test verified the ability of the devices to recover from a Layer 2 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 10 on SH1-108 will be failed. It consists of
four ports, all on a single WS-X6408-GBIC module.
Goals:
•
Verify that the NDR, SH1-107, builds the correct multicast routing states when the DR, SH1-108,
is severed from the Layer 2 device, Dista-1.
•
Verify that SH1-108 resumes the PIM-DR role when the GEC is brought back up.
•
Verify that traffic loss is minimal.
Cisco IOS Release 12.1(13)E13
324
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Primary Devices Used:
•
SH1-108: Sup12; last-hop router (DR) for groups 239.100.[1,3].[1-10]
•
SH1-107: Sup12; will take over last-hop router role from SH1-108 for groups above
Primary IXIA Ports Used:
•
All
Test Procedure
The procedure used to perform the Layer 2 GEC Failover—SH1-108 to Dista-1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-108 is beginning the procedure with the correct multicast routing states.
For each group (239.100.1.x, 239.100.3.x) with SH1-104 being the transient to the last-hop router, verify
a (*, G) entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to
infinity, preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G)
entry: an S-flag because the traffic is forwarded using Sparse-mode. For each group, the Incoming
Interface should be portchannel 169 (from SH1-104). There is no H-flag because SUP1 does not
hardware switch (*, G) entries.
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain two interfaces: VLAN 11 and
GigabitEthernet4/8.
Step 5
Verify that SH1-108 is passing traffic both ways over all four interfaces in portchannel 10.
Step 6
Begin sending a fixed stream of traffic.
Step 7
Shut down portchannel 10 on SH1-108.
Step 8
Verify that SH1-107 builds the correct multicast routing states as the new last-hop router for the various
groups.
For each group (239.100.1.x, 239.100.3.x) with SH1-104 being the transient to the last-hop router, verify
a (*, G) entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to
infinity, preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G)
entry: an S-flag because the traffic is forwarded using Sparse-mode. For each group, the Incoming
Interface should be portchannel 168 (from SH1-104). There is no H-flag because SUP1 does not
hardware switch (*, G) entries.
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain just one interface: VLAN 11
Step 9
Measure traffic loss due to the etherchannel failure.
Step 10
Bring portchannel 10 of SH1-108 back online.
Step 11
With traffic running continuously, verify that SH1-108 again builds the correct multicast routing states
for the ten test groups.
For each group (239.100.1.x, 239.100.3.x) with SH1-104 being the transient to the last-hop router, verify
a (*, G) entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to
infinity, preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G)
entry: an S-flag because the traffic is forwarded using Sparse-mode. For each group, the Incoming
Interface should be portchannel 169 (from SH1-104). There is no H-flag because SUP1 does not
hardware switch (*, G) entries.
Cisco IOS Release 12.1(13)E13
325
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain two interfaces: VLAN 11 and
GigabitEthernet4/8.
Step 12
Verify that all four interfaces in portchannel 10 are passing traffic.
Step 13
Verify that the CBL values for SH1-108 portchannel 10 show forwarding state for all four interfaces.
The CBL value for VLAN 11 is 0x00FF. This indicates that ports 1, 2, 3 and 4 of slot4 are all forwarding.
To understand how to interpret the CBL values correctly, please look at Part 6 (Native) of the following
document:
Step 14
Repeat the failover sequence four more times with a fixed amount of traffic, each time measuring the
traffic loss caused by the failover.
Step 15
Determine the average amount of traffic loss over the five failovers.
Step 16
Display the log for error messages.
Step 17
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that traffic will failover and be forwarded by SH1-107 when the portchannel between
SH1-108 and SH1-104 is torn down.
•
We expect that this failover will take place in a reasonable amount of time (within the 10-second
HSRP dead timer value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 52
Layer 2 GEC Failover—SH1-108 to Dista-1 Test Results
Test
Result
Layer 2 GEC Failover—SH1-108 to Dista-1
Pass
Layer 2 GEC Failover—SH1-114 to Dista-1
This test verified the ability of the devices to recover from a Layer 2 GEC failover, altering multicast
routing state in order to minimize traffic loss. Portchannel 10 on SH1-114 will be failed. It consists of
four ports spread evenly over two WS-X6516-GBIC modules.
Goals:
•
Verify that the NDR, SH1-113, builds the correct multicast routing states when the DR, SH1-114,
is severed from the Layer 2 device, Dista-1.
•
Verify that SH1-113 takes over the first-hop router role from SH1-114.
•
Verify that SH1-114 resumes the first-hop router role when the GEC is brought back up.
•
Verify that traffic loss is minimal.
Primary Devices Used:
•
SH1-114: Sup12; first-hop router for groups 239.100.1.[1-10]
•
SH1-113: Sup12; will take over first-hop router role from SH1-110 for groups above
Cisco IOS Release 12.1(13)E13
326
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Primary IXIA Ports Used:
•
All
Test Procedure
The procedure used to perform the Layer 2 GEC Failover—SH1-114 to Dista-1test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-114 is beginning the procedure with the correct multicast routing states.
As the last-hop router for these ten groups, SH1-114 should have a (*, G) entry for each group. This is
due to the SPT threshold being configured as infinity. Each (*, G) entry correctly has the S-flag, C-flag,
and F-flag set. The S-flag indicates that the flow is maintained via Sparse mode. The C-flag indicates
that the receiver is directly Connected. The F-flag indicates that a source is registering with the RP. For
mgroup 239.100.1.x the incoming interface list (IIL) is portchannel 165 and the outgoing interface list
(OIL) is VLAN 120. There is no hardware-switching of (*, G) flows on the Supervisor 1 platform, hence
the absence of the H-flag on the outgoing interface
Also as the first-hop router for these ten groups, SH1-114 should have a (S, G) entry in its mroute table
for each group. Each (S, G) entry has the F- and T-flags set, as well as the H-flag on each outgoing
interface. The F-flag indicates that the source is registered with the RP. The T-flag indicates that the
Shortest Path Tree (SPT) is being used. The H-flag indicates that the flow is being hardware-switched.
The incoming interface list is VLAN 110. The outgoing interface list is VLAN 120 and portchannel 165
which is connected to SH1-100.
Step 5
Verify that SH1-114 is passing traffic both ways over all four interfaces in portchannel 10.
Step 6
Begin sending a fixed stream of traffic.
Step 7
Shut down portchannel 10 on SH1-114.
Step 8
Verify that SH1-113 builds the correct multicast routing states as the new first- and last-hop router for
the various groups.
As the new last-hop router for these ten groups, SH1-113 should have a (*, G) entry for each group. This
is due to the SPT threshold being configured as infinity. Each (*, G) entry correctly has the S-flag, C-flag,
and F-flag set. The S-flag indicates that the flow is maintained via Sparse mode. The C-flag indicates
that the receiver is directly Connected. The F-flag indicates that a source is registering with the RP. For
mgroup 239.100.1.x the incoming interface list (IIL) is portchannel 164 and the outgoing interface list
(OIL) is VLAN 120. There is no hardware-switching of (*, G) flows on the Supervisor 1 platform, hence
the absence of the H-flag on the outgoing interface
Also as the new first-hop router for these ten groups, SH1-113 should have a (S, G) entry in its mroute
table for each group. Each (S, G) entry has the F- and T-flags set, as well as the H-flag on each outgoing
interface. The F-flag indicates that the source is registered with the RP. The T-flag indicates that the
Shortest Path Tree (SPT) is being used. The H-flag indicates that the flow is being hardware-switched.
The incoming interface list is VLAN 110. The outgoing interface list is VLAN 120 and portchannel 164
which is connected to SH1-100.
Step 9
Measure traffic loss due to the etherchannel failure.
Step 10
Bring portchannel 10 of SH1-114 back online.
Step 11
With traffic running continuously, verify that SH1-114 again builds the correct multicast routing states
for the thirty test groups.
Cisco IOS Release 12.1(13)E13
327
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
As the last-hop router for these ten groups, SH1-114 should have a (*, G) entry for each group. This is
due to the SPT threshold being configured as infinity. Each (*, G) entry correctly has the S-flag, C-flag,
and F-flag set. The S-flag indicates that the flow is maintained via Sparse mode. The C-flag indicates
that the receiver is directly Connected. The F-flag indicates that a source is registering with the RP. For
mgroup 239.100.1.x the incoming interface list (IIL) is portchannel 165 and the outgoing interface list
(OIL) is VLAN 120. There is no hardware-switching of (*, G) flows on the Supervisor 1 platform, hence
the absence of the H-flag on the outgoing interface
Also as the first-hop router for these ten groups, SH1-114 should have a (S, G) entry in its mroute table
for each group. Each (S, G) entry has the F- and T-flags set, as well as the H-flag on each outgoing
interface. The F-flag indicates that the source is registered with the RP. The T-flag indicates that the
Shortest Path Tree (SPT) is being used. The H-flag indicates that the flow is being hardware-switched.
The incoming interface list is VLAN 110. The outgoing interface list is VLAN 120 and portchannel 165
which is connected to SH1-100.
Step 12
Verify that all four interfaces in portchannel 10 are passing traffic.
Step 13
Verify that the CBL values for SH1-114 portchannel 10 show forwarding state for all four interfaces.
The CBL value for both is 0xC000 C000. This indicates that port 8 and port 16 of slot2 and slot 3 are
both forwarding. To understand how to interpret the CBL values correctly, please look at Part 6 (Native)
of the following document:
Step 14
Repeat the failover sequence four more times with a fixed amount of traffic, each time measuring the
traffic loss caused by the failover.
Step 15
Determine the average amount of traffic loss over the five failovers.
Step 16
Display the log for error messages.
Step 17
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that traffic will failover and be forwarded by SH1-113 with the correct multicast routing
states when the DR, SH1-114, is severed from the Layer 2 device, Dista-1.
•
We expect that this failover will take place in a reasonable amount of time (within the 10-second
HSRP dead timer value for local receivers and within 40 second OSPF dead time for remote
receivers).
•
We expect that SH1-114 will take over again when the GEC (Po10) is brought back up.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 53
Layer 2 GEC Failover—SH1-114 to Dista-1 Test Results
Test
Result
Layer 2 GEC Failover—SH1-114 to Dista-1
Pass
Cisco IOS Release 12.1(13)E13
328
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Layer 2 GEC Failover—SH1-106 to Dista-2
This test verified the ability of the devices to recover from a Layer 2 GEC failover, altering multicast
routing state in order to minimize traffic loss. portchannel 20 on SH1-106 will be failed. It consists of
two ports on a WS-X6408-GBIC module.
Goals:
•
Verify that the NDR, SH1-105, builds the correct multicast routing states when the DR, SH1-106,
is severed from the Layer 2 device, Dista-2.
•
Verify that SH1-105 takes over the first-hop router role from SH1-106.
•
Verify that SH1-110 resumes the first-hop router and PIM-DR roles when the GEC is brought back
up.
•
Verify that traffic loss is minimal.
Primary Devices Used:
•
SH1-106: Sup11; first-hop router for groups 239.100.2.[1-10]; last-hop router (DR) for groups
239.100.3.[1-10]
•
SH1-105: Sup11; will take over first- and last-hop router roles from SH1-106 for groups above
Primary IXIA Ports Used:
•
All
Test Procedure
The procedure used to perform the Layer 2 GEC Failover—SH1-106 to Dista-2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-106 is beginning the procedure with the correct multicast routing states.
As the last-hop router for these ten groups, SH1-106 should have a (*, G) entry for each group. This is
due to the SPT threshold being configured as infinity. Each (*, G) entry correctly has the S-flag, C-flag,
and F-flag set. The S-flag indicates that the flow is maintained via Sparse mode. The C-flag indicates
that the receiver is directly Connected. The F-flag indicates that a source is registering with the RP. For
mgroup 239.100.2.x the incoming interface list (IIL) is vlan49 and the outgoing interface list (OIL) is
portchannel 167 and VLAN 50. For mgroup 239.100.3.x the incoming interface list (IIL) is portchannel
167 and the outgoing interface list (OIL) is VLAN 41. There is no hardware-switching of (*, G) flows
on the Supervisor 1 platform, hence the absence of the H-flag on the outgoing interface and any MMLS
entries.
Step 5
Verify that SH1-106 is passing traffic both ways over both interfaces in portchannel 20.
Step 6
Begin sending a fixed stream of traffic.
Step 7
Shut down portchannel 20 on SH1-106.
Step 8
Verify that SH1-105 builds the correct multicast routing states as the new first- and last-hop router for
the various groups.
Cisco IOS Release 12.1(13)E13
329
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
When SH1-105 assumes the forwarding role for the ten groups from SH1-106, it should also take on the
same mroute and MMLS characteristics that SH1-106 had for each of the groups. This includes the (*,
G) entry with its S- and C-flags and the absence of any MMLS entry. For mgroup 239.100.2.x the
incoming interface list (IIL) is portchannel 166 and the outgoing interface list (OIL) is VLAN 50. For
mgroup 239.100.3.x the incoming interface list (IIL) is portchannel 166 and the outgoing interface list
(OIL) is VLAN 41.
Step 9
Measure traffic loss due to the etherchannel failure.
Step 10
Bring portchannel 20 of SH1-106 back online.
Step 11
With traffic running continuously, verify that SH1-106 again builds the correct multicast routing states
for the twenty test groups.
As the last-hop router for these ten groups, SH1-106 should have a (*, G) entry for each group. This is
due to the SPT threshold being configured as infinity. Each (*, G) entry correctly has the S-flag, C-flag,
and F-flag set. The S-flag indicates that the flow is maintained via Sparse mode. The C-flag indicates
that the receiver is directly Connected. The F-flag indicates that a source is registering with the RP. For
mgroup 239.100.2.x the incoming interface list (IIL) is vlan49 and the outgoing interface list (OIL) is
portchannel 167 and VLAN 50. For mgroup 239.100.3.x the incoming interface list (IIL) is portchannel
167 and the outgoing interface list (OIL) is VLAN 41. There is no hardware-switching of (*, G) flows
on the Supervisor 1 platform, hence the absence of the H-flag on the outgoing interface and any MMLS
entries.
Step 12
Verify that both interfaces in portchannel 20 are passing traffic.
Step 13
Verify that the CBL values for SH1-106 portchannel 20 show forwarding state for both interfaces.
The CBL value for both is 0xF000. This indicates that ports 8 and port 7 of slot3 are both forwarding.
To understand how to interpret the CBL values correctly, please look at Part 6 (Native) of the following
document:
Step 14
Repeat the failover sequence four more times with a fixed amount of traffic, each time measuring the
traffic loss caused by the failover.
Step 15
Determine the average amount of traffic loss over the five failovers.
Step 16
Display the log for error messages.
Step 17
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that traffic will failover and be forwarded by SH1-105 when DR, SH1-106, is severed
from the Layer 2 device, Dista-2.
•
We expect that SH1-106 resumes the PIM-DR role when the GEC (Po20) is brought back up
•
We expect that this failover will take place in a reasonable amount of time (within the 10-second
HSRP dead timer value for local receivers and within 40 second OSPF dead time for remote
receivers)
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco IOS Release 12.1(13)E13
330
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Results
Table 54
Layer 2 GEC Failover—SH1-106 to Dista-2 Test Results
Test
Result
Layer 2 GEC Failover—SH1-106 to Dista-2
Pass
Layer 2 GEC Failover—SH1-102 to Dista-1
This test verified the ability of the devices to recover from a Layer 2 GEC failover, altering multicast
routing state in order to minimize traffic loss. Portchannel 10 on SH1-102 will be failed. It consists of
two ports on a WS-X6516-GBIC module.
Goals:
•
Verify that the NDR, SH1-101, builds the correct multicast routing states when the DR, SH1-102,
is severed from the Layer 2 device, Dista-2.
•
Verify that SH1-102 resumes the PIM-DR role when the GEC is brought back up.
•
Verify that traffic loss is minimal.
Primary Devices Used:
•
SH1-102: Sup22; last-hop router for groups 239.100.[1-3].[1-10]
•
SH1-101: Sup22; will take over last-hop router role from SH1-102 for groups above
Primary IXIA Ports Used:
•
All
Test Procedure
The procedure used to perform the Layer 2 GEC Failover—SH1-102 to Dista-1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-102 is beginning the procedure with the correct multicast routing states.
SH1-102 is the last-hop router for each group, so all entries in the mroute table are (*, G) entries. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102. For
each group, the Incoming Interface is portchannel 115 (to SH1-100). The Outgoing Interface List (OIL)
for multicast group 239.100.1.x is VLAN 41. The OIL for group 239.100.2.x is VLAN 43 and for group
239.100.3.x is VLAN 43 and FastEthernet4/5. Each should have an H-flag next to it, indicating that it is
being Hardware-switched. The MMLS entries for each group should be consistent with the mroute
entries, containing the same Incoming Interface and OIL.
Step 5
Verify that SH1-102 is passing multicast traffic both ways over both interfaces in portchannel 10.
Step 6
Begin sending a fixed stream of traffic.
Step 7
Shut down portchannel 10 on SH1-102.
Cisco IOS Release 12.1(13)E13
331
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 8
Verify that SH1-101 builds the correct multicast routing states as the new last-hop router for the various
groups.
SH1-101 is now the last-hop router for each group; all entries in the mroute table are (*, G) entries. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-101. For
each group, the Incoming Interface is portchannel 114 (to SH1-100). The Outgoing Interface List (OIL)
for multicast group 239.100.1.x is VLAN 41and GigabitEthernet7/16. The OIL for group 239.100.2.x
and group 239.100.3.x is VLAN 43. Each should have an H-flag next to it, indicating that it is being
Hardware-switched. The MMLS entries for each group should be consistent with the mroute entries,
containing the same Incoming Interface and OIL.
Step 9
Measure traffic loss due to the etherchannel failure.
Step 10
Bring portchannel 10 of SH1-102 back online.
Step 11
With traffic running continuously, verify that SH1-102 again builds the correct multicast routing states
for the thirty test groups.
SH1-102 is the last-hop router for each group, so all entries in the mroute table are (*, G) entries. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102. For
each group, the Incoming Interface is portchannel 115 (to SH1-100). The Outgoing Interface List (OIL)
for multicast group 239.100.1.x is VLAN 41. The OIL for group 239.100.2.x is VLAN 43 and for group
239.100.3.x is VLAN 43 and FastEthernet4/5. Each should have an H-flag next to it, indicating that it is
being Hardware-switched. The MMLS entries for each group should be consistent with the mroute
entries, containing the same Incoming Interface and OIL.
Step 12
Verify that both interfaces in portchannel 10 are passing traffic.
Step 13
Verify that the CBL values for SH1-102 portchannel 10 show forwarding state for both interfaces.
The CBL value for both is 0x0000 CC00. This indicates that port 8 and port 6 of slot7 are both
forwarding. To understand how to interpret the CBL values correctly, please look at Part 6 (Native) of
the following document:
Step 14
Repeat the failover sequence four more times with a fixed amount of traffic, each time measuring the
traffic loss caused by the failover.
Step 15
Determine the average amount of traffic loss over the five failovers.
Step 16
Display the log for error messages.
Step 17
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that traffic will failover and be forwarded by SH1-101 when DR, SH1-102, is severed
from the Layer 2 device, Dista-2.
•
We expect that SH1-102 resumes the PIM-DR role when the GEC (Po10) is brought back up
•
We expect that this failover will take place in a reasonable amount of time (within the 10-second
HSRP dead timer value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco IOS Release 12.1(13)E13
332
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Results
Table 55
Layer 2 GEC Failover—SH1-102 to Dista-1 Test Results
Test
Result
Layer 2 GEC Failover—SH1-102 to Dista-1
Pass
Layer 3 GEC Failover—SH1-104 to SH1-110
This test verified the ability of the devices to recover from a Layer 3 GEC failover, altering multicast
routing state in order to minimize traffic loss. Portchannel 171 on SH1-110 will be failed. It consists of
four ports spread evenly over two WS-X6816-GBIC modules.
Goals:
•
Verify that devices SH1-103, SH1-104, SH1-109, and SH1-110 maintain correct multicast routing
states for the various groups during the etherchannel failure and after it is reestablished.
•
Verify that traffic loss is minimal.
Primary Devices Used:
•
SH1-110: Sup22; first-hop router for groups 239.100.3.[1-10]; last-hop router (DR) for groups
239.100.[1-2].[1-10]
•
SH1-104: Sup22; transit router for groups 239.100.[1-3].[1-10]
•
SH1-103: Sup22; new transit router for groups 239.100.[1-3].[1-10] after GEC failover
•
SH1-109: Sup22; new last-hop router for groups 239.100.[1-2].[1-10] after GEC failover
Primary IXIA Ports Used:
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-104 to SH1-110 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the IOS version under test. Verify the uptime and that the box hasn't
reloaded unnecessarily. Verify that there is not any process spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-104 is beginning the procedure with the correct multicast routing states.
For each group (239.100.1.x, 239.100.2.x, 239.100.3.x) with SH1-104 being the transient to the last-hop
router, verify a (*, G) entry in the mroute table. There is no (S, G) entry because the SPT threshold is
configured to infinity, preventing the creation of an (S, G) entry. Also, verify that the correct flags are
set in the (*, G) entry: an S-flag because the traffic is forwarded using Sparse-mode. For each group, the
Incoming Interface should be portchannel 117 (from SH1-100 the primary RP). Each should have an
H-flag next to it, indicating that it is being Hardware-switched as all traffic on the Supervisor 2 should
be hardware-switched.
Cisco IOS Release 12.1(13)E13
333
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain three interfaces:
portchannel 69, portchannel 70, and portchannel 71.
For 239.100.2.x groups, The Outgoing Interface List (OIL) should contain two interfaces:
portchannel 68 and portchannel 71.
For 239.100.3.x groups, The Outgoing Interface List (OIL) should contain two interfaces:
portchannel 69 and portchannel 117.
For each group (239.100.3.x) with SH1-104 being the transient to the first-hop router,SH1-110, there is
an (S, G) entry in its mroute table. Each (S, G) entry has the T-flag set, as well as the H-flag on each
outgoing interface. The T-flag indicates that the Shortest Path Tree (SPT) is being used. The H-flag
indicates that the flow is being hardware-switched. The incoming interface list is portchannel 71. The
outgoing interface list is portchannel 69 and portchannel 117 (to SH1-100 the primary RP).
Step 5
Verify that SH1-110 is beginning the procedure with the correct multicast routing states.
For each group (239.100.1.x and 239.100.2.x) with SH1-110 being the last-hop router, verify a (*, G)
entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to infinity,
preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry:
an S-flag because the traffic is forwarded using Sparse-mode, and a C-flag because the receiver is
directly connected to SH1-110. For each group, the Incoming Interface should be portchannel 171 (from
SH1-104).
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain two interfaces: VLAN 11 and
GigabitEthernet8/16.
For 239.100.2.x groups, The Outgoing Interface List (OIL) should contain two interfaces: VLAN 16 and
GigabitEthernet4/16.
Each should have an H-flag next to it, indicating that it is being Hardware-switched. It should be noted
that the receiver interface GigabitEthernet4/16 is on a secondary subnet.For each group (239.100.3.x)
with SH1-110 being the first-hop router,SH1-110 has an (S, G) entry in its mroute table. Each (S, G)
entry has the F- and T-flags set, as well as the H-flag on each outgoing interface. The F-flag indicates
that the source is registered with the RP. The T-flag indicates that the Shortest Path Tree (SPT) is being
used. The H-flag indicates that the flow is being hardware-switched. The incoming interface list is
VLAN 20. The outgoing interface list is VLAN 10 and portchannel 171 which is connected to SH1-104.
Step 6
Verify that SH1-110 is passing traffic both ways over all four interfaces in portchannel 171.
Step 7
Begin sending a fixed stream of traffic.
Step 8
Shut down portchannel 171 on SH1-110.
Step 9
Verify that SH1-104 builds the correct multicast routing states.
For each group (239.100.1.x, 239.100.2.x, 239.100.3.x) with SH1-104 being the transient to the last-hop
router, verify a (*, G) entry in the mroute table. There is no (S, G) entry because the SPT threshold is
configured to infinity, preventing the creation of an (S, G) entry. Also, verify that the correct flags are
set in the (*, G) entry: an S-flag because the traffic is forwarded using Sparse-mode. For each group, the
Incoming Interface should be portchannel 117 (from SH1-100 the primary RP). Each should have an
H-flag next to it, indicating that it is being Hardware-switched as all traffic on the Supervisor 2 should
be hardware-switched.
For 239.100.1.x groups, the (*, G) Outgoing Interface List (OIL) should contain two interfaces:
portchannel 69 and portchannel 70.
For 239.100.2.x groups, the (*, G) Outgoing Interface List (OIL) should contain one interface:
portchannel 68.
For 239.100.3.x groups, the (*, G) Outgoing Interface List (OIL) should contain two interfaces:
portchannel 69 and portchannel 70.
Cisco IOS Release 12.1(13)E13
334
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
For each group (239.100.3.x) with SH1-104 being the transient to the first-hop router,SH1-110, there is
an (S, G) entry in its mroute table. Each (S, G) entry has the T-flag set, as well as the H-flag on each
outgoing interface. The T-flag indicates that the Shortest Path Tree (SPT) is being used. The H-flag
indicates that the flow is being hardware-switched. The incoming interface list is portchannel70.
The outgoing interface list is portchannel69 and portchannel117 (to SH1-100 the primary RP).
Step 10
Verify that SH1-110 builds the correct multicast routing states.
For each group (239.100.2.x) with SH1-110 being the last-hop router, verify a (*, G) entry in the mroute
table. There is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation
of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the
traffic is forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to
SH1-110. For each group, the Incoming Interface should be portchannel71 (from SH1-103).
For 239.100.2.x groups, The Outgoing Interface List (OIL) should contain two interfaces: VLAN 16 and
GigabitEthernet4/16.
Each should have an H-flag next to it, indicating that it is being Hardware-switched. It should be noted
that the receiver interface GigabitEthernet4/16 is on a secondary subnet.
Step 11
Verify that SH1-103 builds the correct multicast routing states.
For each group (239.100.1.x, 239.100.2.x, 239.100.3.x) with SH1-103 being the transient to the last-hop
router, verify a (*, G) entry in the mroute table. There is no (S, G) entry because the SPT threshold is
configured to infinity, preventing the creation of an (S, G) entry. Also, verify that the correct flags are
set in the (*, G) entry: an S-flag because the traffic is forwarded using Sparse-mode. For each group, the
Incoming Interface should be portchannel16 (from SH1-99 the primary RP). Each should have an H-flag
next to it, indicating that it is being Hardware-switched as all traffic on the Supervisor 2 should be
hardware-switched.
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain one interface:
portchanne1 71.
For 239.100.2.x groups, The Outgoing Interface List (OIL) should contain one interface: portchannel 71.
For 239.100.3.x groups, The Outgoing Interface List (OIL) is Null.
Step 12
Verify that SH1-109 builds the correct multicast routing states.
For each group (239.100.1.x and 239.100.2.x) with SH1-109 being the last-hop router, verify a (*, G)
entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to infinity,
preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry:
an S-flag because the traffic is forwarded using Sparse-mode, and a C-flag because the receiver is
directly connected to SH1-109. For each group, the Incoming Interface should be portchannel 170 (from
SH1-104).
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain one interface:
GigabitEthernet7/16.
Each should have an H-flag next to it, indicating that it is being Hardware-switched. It should be noted
that the receiver interface GigabitEthernet7/16 is on a secondary subnet.For 239.100.2.x groups, The
Outgoing Interface List (OIL) is Null.
For each group (239.100.3.x) with SH1-109 being the first-hop router,SH1-109 has an (S, G) entry in its
mroute table. Each (S, G) entry has the T-flag set, as well as the H-flag on each outgoing interface. The
T-flag indicates that the Shortest Path Tree (SPT) is being used. The H-flag indicates that the flow is
being hardware-switched. The incoming interface list is VLAN 20. The outgoing interface list is Gigabit
Ethernet 3/16 and portchannel 170 (connected to SH1-104).
Cisco IOS Release 12.1(13)E13
335
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Note
Although the "J" flag was not set, this is not an error. SPT-threshold is set to infinity so the J flag is not
looked at.
Step 13
Measure traffic loss due to the etherchannel failure.
Step 14
Bring portchannel 171 of SH1-110 back online.
Step 15
Start traffic running continuously
Step 16
With traffic running continuously, verify that SH1-104 again builds the correct multicast routing states
for the test groups.
For each group (239.100.1.x, 239.100.2.x, 239.100.3.x) with SH1-104 being the transient to the last-hop
router, verify a (*, G) entry in the mroute table. There is no (S, G) entry because the SPT threshold is
configured to infinity, preventing the creation of an (S, G) entry. Also, verify that the correct flags are
set in the (*, G) entry: an S-flag because the traffic is forwarded using Sparse-mode. For each group, the
Incoming Interface should be portchannel 117 (from SH1-100 the primary RP). Each should have an
H-flag next to it, indicating that it is being Hardware-switched as all traffic on the Supervisor 2 should
be hardware-switched.
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain three interfaces:
portchannel 69, portchannel 70, and portchannel 71.
For 239.100.2.x groups, The Outgoing Interface List (OIL) should contain two interfaces:
portchannel 68 and portchannel 71.
For 239.100.3.x groups, the (*, G) Outgoing Interface List (OIL) should contain three interfaces:
portchannel 69, portchannel 70 and portchannel 71.
For each group (239.100.3.x) with SH1-104 being the transient to the first-hop router,SH1-110, there is
an (S, G) entry in its mroute table. Each (S, G) entry has the T-flag set, as well as the H-flag on each
outgoing interface. The T-flag indicates that the Shortest Path Tree (SPT) is being used. The H-flag
indicates that the flow is being hardware-switched. The incoming interface list is portchannel 71. The
outgoing interface list is portchannel 69 and portchannel 117 (to SH1-100 the primary RP).
Step 17
With traffic running continuously, verify that SH1-110 again builds the correct multicast routing states
for the test groups.
For each group (239.100.1.x and 239.100.2.x) with SH1-110 being the last-hop router, verify a (*, G)
entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to infinity,
preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry:
an S-flag because the traffic is forwarded using Sparse-mode, and a C-flag because the receiver is
directly connected to SH1-110. For each group, the Incoming Interface should be portchannel 171 (from
SH1-104).
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain two interfaces: VLAN 11 and
GigabitEthernet8/16.
For 239.100.2.x groups, The Outgoing Interface List (OIL) should contain two interfaces: VLAN 16 and
GigabitEthernet4/16.
Each should have an H-flag next to it, indicating that it is being Hardware-switched. It should be noted
that the receiver interface GigabitEthernet4/16 is on a secondary subnet.For each group (239.100.3.x)
with SH1-110 being the first-hop router,SH1-110 has an (S, G) entry in its mroute table. Each (S, G)
entry has the F- and T-flags set, as well as the H-flag on each outgoing interface. The F-flag indicates
that the source is registered with the RP. The T-flag indicates that the Shortest Path Tree (SPT) is being
used. The H-flag indicates that the flow is being hardware-switched. The incoming interface list is
VLAN 20. The outgoing interface list is VLAN 10 and portchannel 171 which is connected to SH1-104.
Cisco IOS Release 12.1(13)E13
336
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 18
Verify that all four interfaces in portchannel 171 are passing traffic.
Step 19
Repeat the failover sequence four more times with a fixed amount of traffic, each time measuring the
traffic loss caused by the failover.
Step 20
Determine the average amount of traffic loss over the five failovers.
Step 21
Display the log for error messages.
Step 22
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that traffic will failover and be forwarded by SH1-103 when the portchannel between
SH1-110 and SH1-104 is torn down.
•
We expect that this failover will take place in a reasonable amount of time (within the 40-second
OSPF dead timer value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 56
Layer 3 GEC Failover—SH1-104 to SH1-110 Test Results
Test
Result
Layer 3 GEC Failover—SH1-104 to SH1-110
Pass
Layer 3 GEC Failover—SH1-104 to SH1-109
This test verified the ability of the devices to recover from a Layer 3 GEC failover, altering multicast
routing state in order to minimize traffic loss. Portchannel 170 on SH1-109 will be failed. It consists of
four ports spread evenly over two WS-X6816-GBIC modules.
Goals:
•
Verify that the devices SH1-104, SH1-103, and SH1-109 build the correct multicast routing states
when the GEC is failed and brought back up.
•
Verify that traffic loss is minimal.
Primary Devices Used:
•
SH1-104: Sup22; transit router for groups 239.100.1.[1-10]
•
SH1-109: Sup22; last-hop router for groups 239.100.[1,3].[1-10]
•
SH1-103: Sup22; after failover, transit router for groups 239.100.1.[1-10]
Primary IXIA Ports Used:
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-104 to SH1-109 test follows:
Cisco IOS Release 12.1(13)E13
337
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-104 is beginning the procedure with the correct multicast routing states.
For each group (239.100.1.x) with SH1-104 being the transient to the last-hop router, verify a (*, G)
entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to infinity,
preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry:
an S-flag because the traffic is forwarded using Sparse-mode. For each group, the Incoming Interface
should be portchannel 117 (from SH1-100 the primary RP). Each should have an H-flag next to it,
indicating that it is being Hardware-switched as all traffic on the Supervisor 2 should be
hardware-switched.
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain three interfaces:
portchannel 69, portchannel 70, and portchannel 71.
Step 5
Verify that SH1-109 is beginning the procedure with the correct multicast routing states.
For each group (239.100.1.x) with SH1-109 being the last-hop router, verify a (*, G) entry in the mroute
table. There is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation
of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the
traffic is forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to
SH1-109. For each group, the Incoming Interface should be portchannel 170 (from SH1-104). The
Outgoing Interface List (OIL) should contain one interface (for the directly attached receiver):
GigabitEthernet7/16 with an H-flag next to it, indicating that it is being Hardware-switched. It should
be noted that the receiver interface GigabitEthernet4/16 is on a secondary subnet.
SH1-109 has an (S, G) entry in its mroute table for the 239.100.3.x groups for which it is the first-hop
router. In this scenario it is a router-on-a-stick for this group. Each (S, G) entry has the T-flag set, as well
as the H-flag on each outgoing interface. The T-flag indicates that the Shortest Path Tree (SPT) is being
used. The H-flag indicates that the flow is being hardware-switched. The incoming interface list is
VLAN 20. The outgoing interface list is GigabitEthernet3/16.
Note
There was an error in the script that incorrectly marked the flags as being in error for 239.100.3.1 when
they were actually correct.
Step 6
Verify that traffic is coming in on all four interfaces in portchannel 170 on SH1-109.
Step 7
Begin sending a fixed stream of traffic.
Step 8
Shut down portchannel 170 on SH1-109.
Step 9
Verify that SH1-104 builds the correct multicast routing states following the GEC failure.
For each group (239.100.1.x) with SH1-104 being the transient to the last-hop router, verify a (*, G)
entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to infinity,
preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry:
an S-flag because the traffic is forwarded using Sparse-mode. For each group, the Incoming Interface
should be portchannel 117 (from SH1-100 the primary RP). Each should have an H-flag next to it,
indicating that it is being Hardware-switched as all traffic on the Supervisor 2 should be
hardware-switched.
For 239.100.1.x groups, the Outgoing Interface List (OIL) should contain only two interfaces:
portchannel 69 and portchannel 71 since portchannel 70 on SH1-103 is now the transient for this group
to SH1-109.
Cisco IOS Release 12.1(13)E13
338
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 10
Verify that SH1-109 builds the correct multicast routing states following the GEC failure.
For each group (239.100.1.x) with SH1-109 being the last-hop router, verify a (*, G) entry in the mroute
table. There is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation
of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the
traffic is forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to
SH1-109. For each group, the Incoming Interface should have changed to be portchannel 70 (from
SH1-103). The Outgoing Interface List (OIL) should contain one interface (for the directly attached
receiver): GigabitEthernet7/16 with an H-flag next to it, indicating that it is being Hardware-switched.
It should be noted that the receiver interface GigabitEthernet4/16 is on a secondary subnet.
SH1-109 has an (S, G) entry in its mroute table for the 239.100.3.x groups for which it is the first-hop
router. In this scenario it is a router-on-a-stick for this group. Each (S, G) entry has the T-flag set, as well
as the H-flag on each outgoing interface. The T-flag indicates that the Shortest Path Tree (SPT) is being
used. The H-flag indicates that the flow is being hardware-switched. The incoming interface list is
VLAN 20. The outgoing interface list is GigabitEthernet3/16.
Note
Step 11
There was an error in the script that incorrectly marked the flags as being in error for 239.100.3.1 when
they were actually correct.
Verify that SH1-103 builds the correct multicast routing states following the GEC failure.
For each group (239.100.1.x) with SH1-103 being the transient to the last-hop router, verify a (*, G)
entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to infinity,
preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry:
an S-flag because the traffic is forwarded using Sparse-mode. For each group, the Incoming Interface
should be portchannel 16 (from SH1-99 the primary RP). Each should have an H-flag next to it,
indicating that it is being Hardware-switched as all traffic on the Supervisor 2 should be
hardware-switched.
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain one interface: portchannel 70.
Step 12
Verify that SH1-110 builds the correct multicast routing states following the GEC failure.
For each group (239.100.1.x) with SH1-110 being the last-hop router, verify a (*, G) entry in the mroute
table. There is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation
of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the
traffic is forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to
SH1-110. For each group, the Incoming Interface should be portchannel 171 (from SH1-104). The
Outgoing Interface List (OIL) should contain two interfaces: VLAN 11 and GigabitEthernet8/16. Each
should have an H-flag next to it, indicating that it is being Hardware-switched. It should be noted that
the receiver interface GigabitEthernet4/16 is on a secondary subnet.
SH1-110 has an (S, G) entry in its mroute table for each of the ten 239.100.3.x groups for which it is the
first-hop router. Each (S, G) entry has the F- and T-flags set, as well as the H-flag on each outgoing
interface. The F-flag indicates that the source is registered with the RP. The T-flag indicates that the
Shortest Path Tree (SPT) is being used. The H-flag indicates that the flow is being hardware-switched.
The incoming interface list is VLAN 20. The outgoing interface list is VLAN 10 and portchannel 171
which is connected to SH1-104.
Step 13
Measure traffic loss due to the etherchannel failure.
Step 14
Bring portchannel 170 of SH1-109 back online.
Step 15
Start traffic running continuously.
Step 16
Verify that SH1-104 again builds the correct multicast routing states for the test groups.
Cisco IOS Release 12.1(13)E13
339
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
For each group (239.100.1.x) with SH1-104 being the transient to the last-hop router, verify a (*, G)
entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to infinity,
preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry:
an S-flag because the traffic is forwarded using Sparse-mode. For each group, the Incoming Interface
should be portchannel 117 (from SH1-100 the primary RP). Each should have an H-flag next to it,
indicating that it is being Hardware-switched as all traffic on the Supervisor 2 should be
hardware-switched.
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain three interfaces:
portchannel 69, portchannel 70, and portchannel 71.
Step 17
With traffic running continuously, verify that SH1-109 again builds the correct multicast routing states
for the twenty test groups.
For each group (239.100.1.x) with SH1-109 being the last-hop router, verify a (*, G) entry in the mroute
table. There is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation
of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the
traffic is forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to
SH1-109. For each group, the Incoming Interface should be portchannel 170 (from SH1-104). The
Outgoing Interface List (OIL) should contain one interface (for the directly attached receiver):
GigabitEthernet7/16 with an H-flag next to it, indicating that it is being Hardware-switched. It should
be noted that the receiver interface GigabitEthernet4/16 is on a secondary subnet.
SH1-109 has an (S, G) entry in its mroute table for the 239.100.3.x groups for which it is the first-hop
router. In this scenario it is a router-on-a-stick for this group. Each (S, G) entry has the T-flag set, as well
as the H-flag on each outgoing interface. The T-flag indicates that the Shortest Path Tree (SPT) is being
used. The H-flag indicates that the flow is being hardware-switched. The incoming interface list is
VLAN 20. The outgoing interface list is GigabitEthernet3/16.
Step 18
Verify that all four interfaces in portchannel 170 are passing traffic.
Step 19
Repeat the failover sequence four more times with a fixed amount of traffic, each time measuring the
traffic loss caused by the failover.
Step 20
Determine the average amount of traffic loss over the five failovers.
Step 21
Display the log for error messages.
Step 22
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that traffic will failover and be forwarded by SH1-103 when the portchannel between
SH1-109 and SH1-104 is torn down.
•
We expect that this failover will take place in a reasonable amount of time (within the 40-second
OSPF dead timer value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 57
Layer 3 GEC Failover—SH1-104 to SH1-109 Test Results
Test
Result
Layer 3 GEC Failover—SH1-104 to SH1-109
Pass
Cisco IOS Release 12.1(13)E13
340
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Layer 3 GEC Failover—SH1-104 to SH1-108
This test verified the ability of the devices to recover from a Layer 3 GEC failover, altering multicast
routing state in order to minimize traffic loss. Portchannel 169 on SH1-108 will be failed. It consists of
four ports spread evenly over two WS-X6408-GBIC modules.
Goals:
•
Verify that devices SH1-108, SH1-104, and SH1-103 build the correct multicast routing states
following the GEC failure and recovery.
•
Verify that traffic loss is minimal.
Primary Devices Used:
•
SH1-108: Sup12; last-hop router for groups 239.100.[1-2].[1-10]
•
SH1-104: Sup22; transit router for groups 239.100.[1-2].[1-10]
•
SH1-103: Sup22; new transit router for groups 239.100.[1-2].[1-10] following the GEC failover
Primary IXIA Ports Used:
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-104 to SH1-108 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-104 is beginning the procedure with the correct multicast routing states.
For each group (239.100.1.x, 239.100.3.x) with SH1-104 being the transient to the last-hop router, verify
a (*, G) entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to
infinity, preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G)
entry: an S-flag because the traffic is forwarded using Sparse-mode. For each group, the Incoming
Interface should be portchannel 117 (from SH1-100 the primary RP). Each should have an H-flag next
to it, indicating that it is being Hardware-switched as all traffic on the Supervisor 2 should be
hardware-switched.
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain three interfaces:
portchannel 69, portchannel 70, and portchannel 71.
SH1-104 has an (S, G) entry in its mroute table for each of the ten 239.100.3.x groups for which it is the
transient to the first-hop router. Each (S, G) entry has the T-flag set, as well as the H-flag on each
outgoing interface. The T-flag indicates that the Shortest Path Tree (SPT) is being used. The H-flag
indicates that the flow is being hardware-switched. The incoming interface list is portchannel 71. The
outgoing interface list is portchannel 69 and portchannel 117 (to SH1-100 the primary RP).
Step 5
Verify that SH1-108 is beginning the procedure with the correct multicast routing states.
For each group (239.100.1.x, 239.100.3.x) with SH1-104 being the transient to the last-hop router, verify
a (*, G) entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to
infinity, preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G)
Cisco IOS Release 12.1(13)E13
341
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
entry: an S-flag because the traffic is forwarded using Sparse-mode. For each group, the Incoming
Interface should be portchannel 169 (from SH1-104). There is no H-flag because SUP1 does not
hardware switch (*, G) entries.
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain two interfaces: VLAN 11 and
GigabitEthernet4/8.
For 239.100.3.x groups, The Outgoing Interface List (OIL) should contain one interface:
GigabitEthernet3/8.
Step 6
Verify that SH1-108 is passing traffic both ways over all four interfaces in portchannel 169.
Step 7
Begin sending a fixed stream of traffic
Step 8
Shut down portchannel 169 on SH1-108.
Step 9
Verify that SH1-104 has the correct multicast routing states.
For each group (239.100.1.x, 239.100.3.x) with SH1-104 being the transient to the last-hop router, verify
a (*, G) entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to
infinity, preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G)
entry: an S-flag because the traffic is forwarded using Sparse-mode. For each group, the Incoming
Interface should be portchannel 117 (from SH1-100 the primary RP). Each should have an H-flag next
to it, indicating that it is being Hardware-switched as all traffic on the Supervisor 2 should be
hardware-switched.
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain two interfaces:
portchannel 70 and portchannel 71.
SH1-104 has an (S, G) entry in its mroute table for each of the ten 239.100.3.x groups for which it is the
transient to the first-hop router. Each (S, G) entry has the T-flag set, as well as the H-flag on each
outgoing interface. The T-flag indicates that the Shortest Path Tree (SPT) is being used. The H-flag
indicates that the flow is being hardware-switched. The incoming interface list is portchannel 71. The
outgoing interface list is portchannel 117 (to SH1-100 the primary RP).
Step 10
Verify that SH1-108 builds the correct multicast routing states.
For each group (239.100.1.x, 239.100.2.x, 239.100.3.x) with SH1-104 being the transient to the last-hop
router, verify a (*, G) entry in the mroute table. There is no (S, G) entry because the SPT threshold is
configured to infinity, preventing the creation of an (S, G) entry. Also, verify that the correct flags are
set in the (*, G) entry: an S-flag because the traffic is forwarded using Sparse-mode. For each group, the
Incoming Interface should change to be portchannel 69 (from SH1-103). There is no H-flag because
SUP1 does not hardware switch (*, G) entries.
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain two interfaces: VLAN 11 and
GigabitEthernet4/8.
For 239.100.3.x groups, The Outgoing Interface List (OIL) should contain one interface:
GigabitEthernet3/8.
Step 11
Verify that SH1-103 builds the correct multicast routing states as the new first- and last-hop router for
the various groups.
For each group (239.100.1.x) with SH1-103 being the transient to the last-hop router, verify a (*, G)
entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to infinity,
preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry:
an S-flag because the traffic is forwarded using Sparse-mode. For each group, the Incoming Interface
should be portchannel 16 (from SH1-99 the primary RP). Each should have an H-flag next to it,
indicating that it is being Hardware-switched as all traffic on the Supervisor 2 should be
hardware-switched.
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain one interface: portchannel 69.
Cisco IOS Release 12.1(13)E13
342
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
SH1-103 has an (S, G) entry in its mroute table for each of the 239.100.3.x groups for which it is the
new transient to the first-hop router. Each (S, G) entry has the T-flag set, as well as the H-flag on each
outgoing interface. The T-flag indicates that the Shortest Path Tree (SPT) is being used. The H-flag
indicates that the flow is being hardware-switched. The incoming interface list is portchannel 71. The
outgoing interface list is portchannel 69 since SH10103 is acting as a router-on-a-stick for this group.
For each group, the MMLS entry is consistent with the respective mroute entry.
Step 12
Verify that SH1-107 has the correct multicast routing states.
For each group (239.100.1.x, 239.100.3.x) SH1-107 should have null or no entries.
Step 13
Measure traffic loss due to the etherchannel failure.
Step 14
Bring portchannel 169 of SH1-108 back online.
Step 15
Start traffic running continuously.
Step 16
Verify that SH1-104 again builds the correct multicast routing states for the test groups.
For each group (239.100.1.x, 239.100.3.x) with SH1-104 being the transient to the last-hop router, verify
a (*, G) entry in the mroute table. There is no (S, G) entry because the SPT threshold is configured to
infinity, preventing the creation of an (S, G) entry. Also, verify that the correct flags are set in the (*, G)
entry: an S-flag because the traffic is forwarded using Sparse-mode. For each group, the Incoming
Interface should be portchannel 117 (from SH1-100 the primary RP). Each should have an H-flag next
to it, indicating that it is being Hardware-switched as all traffic on the Supervisor 2 should be
hardware-switched.
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain three interfaces:
portchannel 69, portchannel 70, and portchannel 71.
For 239.100.3.x groups, The Outgoing Interface List (OIL) should contain three interfaces:
portchannel 69, portchannel 70, and portchannel 71.
SH1-104 has an (S, G) entry in its mroute table for each of the ten 239.100.3.x groups for which it is the
transient to the first-hop router. Each (S, G) entry has the T-flag set, as well as the H-flag on each
outgoing interface. The T-flag indicates that the Shortest Path Tree (SPT) is being used. The H-flag
indicates that the flow is being hardware-switched. The incoming interface list is portchannel 71. The
outgoing interface list is portchannel 69 and portchannel 117 (to SH1-100 the primary RP). For each
group, the MMLS entry is consistent with the respective mroute entry.
Step 17
With traffic running continuously, verify that SH1-108 again builds the correct multicast routing states
for the twenty test groups.
For each group (239.100.1.x, 239.100.2.x, 239.100.3.x) with SH1-104 being the transient to the last-hop
router, verify a (*, G) entry in the mroute table. There is no (S, G) entry because the SPT threshold is
configured to infinity, preventing the creation of an (S, G) entry. Also, verify that the correct flags are
set in the (*, G) entry: an S-flag because the traffic is forwarded using Sparse-mode. For each group, the
Incoming Interface should be portchannel 169 (from SH1-104). There is no H-flag because SUP1 does
not hardware switch (*, G) entries.
For 239.100.1.x groups, The Outgoing Interface List (OIL) should contain two interfaces: VLAN 11 and
GigabitEthernet4/8.
For 239.100.3.x groups, The Outgoing Interface List (OIL) should contain one interface:
GigabitEthernet3/8.
Step 18
Verify that all four interfaces in portchannel 169 are passing traffic.
Step 19
Repeat the failover sequence four more times with a fixed amount of traffic, each time measuring the
traffic loss caused by the failover.
Step 20
Determine the average amount of traffic loss over the five failovers.
Cisco IOS Release 12.1(13)E13
343
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 21
Display the log for error messages.
Step 22
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that traffic will failover and be forwarded through RP SH1-103 when the portchannel
between SH1-108 and SH1-104 is torn down.
•
We expect that this failover will take place in a reasonable amount of time (within the 40-second
default OSPF dead time value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 58
Layer 3 GEC Failover—SH1-104 to SH1-108 Test Results
Test
Result
Layer 3 GEC Failover—SH1-104 to SH1-108
Pass
Layer 3 GEC Failover—SH1-104 to SH1-107
This test verified the ability of the devices to recover from a Layer 3 GEC failover, altering multicast
routing state in order to minimize traffic loss. Portchannel 168 on SH1-107 will be failed. It consists of
four ports spread evenly over two WS-X6408-GBIC modules.
Goals:
•
Verify that the devices SH1-107, SH1-104, and SH1-103 build the correct multicast routing states
to cope with the failure and recovery.
•
Verify that traffic loss is minimal.
Primary Devices Used:
•
SH1-107: Sup12; last-hop router for groups 239.100.2.[1-10]
•
SH1-104: Sup22; transit router for groups 239.100.2.[1-10]
•
SH1-103: Sup22; new transit router for groups 239.100.2.[1-10] following the GEC failure
Primary IXIA Ports Used:
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-104 to SH1-107 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-104 is beginning the procedure with the correct multicast routing states.
Cisco IOS Release 12.1(13)E13
344
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
For each group with SH1-104 being the transit router, verify a (*, G) entry in the mroute table. There is
no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S, G)
entry. Also, verify that the correct flag is set in the (*, G) entry: an S-flag because the traffic is forwarded
using Sparse-mode.
For groups 239.100.2.x
•
Incoming Interface should be portchannel 117 (from SH1-100).
•
Outgoing Interface List (OIL) should contain two interfaces: portchannel 68 and portchannel 71.
Each should have an H-flag next to it. T
Step 5
Verify that SH1-107 is beginning the procedure with the correct multicast routing states.
For each group with SH1-107 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102.
For groups 239.100.2.x
•
Incoming Interface should be portchannel 168 (from SH1-104).
•
Outgoing Interface List (OIL) should contain a single interface: FastEthernet9/3.
This should not have an H-flag next to it, because SH1-107 is a SUP1.
Step 6
Verify that SH1-107 is passing traffic both ways over all four interfaces in portchannel 168.
Step 7
Begin sending a fixed stream of traffic
Step 8
Shut down portchannel 168 on SH1-107.
Step 9
Verify that SH1-104 builds the correct multicast routing states following the GEC failure.
For each group with SH1-104 being the transit router, verify a (*, G) entry in the mroute table. There is
no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S, G)
entry. Also, verify that the correct flag is set in the (*, G) entry: an S-flag because the traffic is forwarded
using Sparse-mode.
For groups 239.100.2.x
•
Incoming Interface should be portchannel 117 (from SH1-100).
•
Outgoing Interface List (OIL) should contain one interface: portchannel 71.
Each should have an H-flag next to it. The MMLS entries for each group should be consistent with the
mroute entries, containing the same Incoming Interface and OIL.
Step 10
Verify that SH1-107 builds the correct multicast routing states following the GEC failure.
For each group with SH1-107 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102.
For groups 239.100.2.x
•
Incoming Interface should be portchannel 68 (from SH1-103).
•
Outgoing Interface List (OIL) should contain a single interface: FastEthernet9/3.
This should not have an H-flag next to it, because SH1-107 is a SUP1. The MMLS entries for each group
should be consistent with the mroute entries, containing the same Incoming Interface and OIL.
Step 11
Verify that SH1-103 builds the correct multicast routing states following the GEC failure.
Cisco IOS Release 12.1(13)E13
345
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
For each group with SH1-103 being the transit router, verify a (*, G) entry in the mroute table. There is
no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S, G)
entry. Also, verify that the correct flag is set in the (*, G) entry: an S-flag because the traffic is forwarded
using Sparse-mode.
For groups 239.100.2.x
•
Incoming Interface should be portchannel 16 (from SH1-100).
•
Outgoing Interface List (OIL) should contain a single interface: portchannel 68.
It should have an H-flag next to it.
Step 12
Verify that SH1-108 builds the correct multicast routing states following the GEC failure.
Step 13
Measure traffic loss due to the etherchannel failure.
Step 14
Bring portchannel 168 of SH1-107 back online.
Step 15
Strat traffic running continuously.
Step 16
Verify that SH1-104 again builds the correct multicast routing states for the test groups.
For each group with SH1-104 being the transit router, verify a (*, G) entry in the mroute table. There is
no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S, G)
entry. Also, verify that the correct flag is set in the (*, G) entry: an S-flag because the traffic is forwarded
using Sparse-mode.
For groups 239.100.2.x
•
Incoming Interface should be portchannel 117 (from SH1-100).
•
Outgoing Interface List (OIL) should contain two interfaces: portchannel 68 and portchannel 71.
Each should have an H-flag next to it. The MMLS entries for each group should be consistent with the
mroute entries, containing the same Incoming Interface and OIL.
Step 17
With traffic running continuously, verify that SH1-107 again builds the correct multicast routing states
for the ten test groups.
For each group with SH1-107 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102.
For groups 239.100.2.x
•
Incoming Interface should be portchannel 168 (from SH1-104).
•
Outgoing Interface List (OIL) should contain a single interface: FastEthernet9/3.
This should not have an H-flag next to it, because SH1-107 is a SUP1. The MMLS entries for each group
should be consistent with the mroute entries, containing the same Incoming Interface and OIL.
Step 18
Verify that all four interfaces in portchannel 168 are passing traffic.
Step 19
Repeat the failover sequence four more times with a fixed amount of traffic, each time measuring the
traffic loss caused by the failover.
Step 20
Determine the average amount of traffic loss over the five failovers.
Step 21
Display the log for error messages.
Step 22
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco IOS Release 12.1(13)E13
346
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Expected Results
•
We expect that traffic will failover and be forwarded through RP SH1-103 when the portchannel
between SH1-107 and SH1-104 is torn down.
•
We expect that this failover will take place in a reasonable amount of time (within the 40-second
default OSPF dead time value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 59
Layer 3 GEC Failover—SH1-104 to SH1-107 Test Results
Test
Result
Layer 3 GEC Failover—SH1-104 to SH1-107
Pass
Layer 3 GEC Failover—SH1-100 to SH1-104
This test verified the ability of the devices to recover from a Layer 2 GEC failover, altering multicast
routing state in order to minimize traffic loss. Portchannel 20 on SH1-104 will be failed.
Goals:
•
Verify that the devices SH1-104, SH1-100, and SH1-99 maintain the correct multicast routing states
during the GEC failover.
•
Verify that traffic loss is minimal.
Primary Devices Used:
•
SH1-104: Sup22; transit router for groups 239.100.[1-3].[1-10]
•
SH1-100: Sup22; elected RP for groups 239.100.0.0/16
•
SH1-99: Sup22; backup RP for groups 239.100.0.0/16
Primary IXIA Ports Used:
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-100 to SH1-104 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-100 is beginning with the correct multicast routing states.
The elected PIM-RP, SH1-100, should have an (S, G) entry for all thirty groups, and it does. For each
(S, G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and
the (S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP
peer (SH1-99) with the SA messages. The T-flag is correctly set for all groups.
Cisco IOS Release 12.1(13)E13
347
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.1.x:
•
Incoming interface: portchannel 65, RPF nbr 172.31.11.14, RPF-MFD
•
Outgoing interface list: portchannel 14, portchannel 15, portchannel 17, portchannel 66
For groups 239.100.2.x:
•
Incoming interface: portchannel 67, RPF nbr 172.31.1.98, RPF-MFD
•
Outgoing interface list: portchannel 15, portchannel 17, portchannel 64
For groups 239.100.3.x:
Step 5
•
Incoming interface: portchannel 17, RPF nbr 172.31.1.54, RPF-MFD
•
Outgoing interface list: portchannel 15, portchannel 67
Verify that SH1-104 is beginning the procedure with the correct multicast routing states.
For each group with SH1-104 being the transit router, verify a (*, G) entry in the mroute table. There is
no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S, G)
entry. Also, verify that the correct flag is set in the (*, G) entry: an S-flag because the traffic is forwarded
using Sparse-mode.
For groups 239.100.1.x:
•
Incoming Interface should be portchannel 117 (from SH1-100).
•
Outgoing Interface List (OIL) should contain 4 interfaces: portchannel 68, portchannel 69,
portchannel 70, and portchannel 71.
For groups 239.100.2.x:
•
Incoming Interface should be portchannel 117 (from SH1-100).
•
Outgoing Interface List (OIL) should contain 2 interfaces: portchannel 68 and portchannel 71.
Each should have an H-flag next to it. The MMLS entries for each group should be consistent with the
mroute entries, containing the same Incoming Interface and OIL.
For each group with SH1-104 being the local PIM-RP verify a (S, G) entry in the mroute table For each
(S, G) entry, it should have the T-flag set. The T-flag indicated that the SPT-bit is set and the (S, G) entry
is used. The T-flag is correctly set for all groups.
For groups 239.100.3.x:
•
Incoming Interface should be portchannel 71 (from SH1-110).
•
Outgoing Interface List (OIL) should contain 2 interfaces: portchannel 117, and portchannel 69.
Each should have an H-flag next to it. The MMLS entries for each group should be consistent with the
mroute entries, containing the same Incoming Interface and OIL.
Step 6
Verify that SH1-104 is passing traffic both ways over all four interfaces in portchannel 114.
Step 7
Begin sending a fixed stream of traffic
Cisco IOS Release 12.1(13)E13
348
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 8
Shut down portchannel 117 on SH1-104.
Step 9
Verify that SH1-100 builds the correct routing state from SH1-103.
The elected PIM-RP, SH1-100, should have an (S, G) entry for all thirty groups, and it does. For each
(S, G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and
the (S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP
peer (SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.3.x:
Step 10
•
Incoming interface: portchannel 16, RPF nbr 172.31.1.50, RPF-MFD
•
Outgoing interface list: portchannel 15, portchannel 67
Verify that SH1-104 has the correct multicast routing states.
All outgoing interfaces lists should be Null.
Step 11
Verify that SH1-99 builds the correct routing state down to SH1-103.
The newly elected PIM-RP, SH1-99, should have an (S, G) entry for all thirty groups, and it does. For
each (S, G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set
and the (S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the
MSDP peer (SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.1.x:
•
Incoming interface: portchannel 65, RPF nbr 172.31.11.14, RPF-MFD
•
Outgoing interface list: portchannel 16
For groups 239.100.2.x:
Step 12
•
Incoming interface: portchannel 67, RPF nbr 172.31.1.94, RPF-MFD
•
Outgoing interface list: portchannel 16
Verify that SH1-103 builds the correct multicast routing state to the backup RP, SH1-99. This is due to
the 4 port etherchannel between 103 and 99 having a lower cost than the 2 port etherchannel between
104 and 99.
Cisco IOS Release 12.1(13)E13
349
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
For each group with SH1-103 being the transit router, verify a (*, G) entry in the mroute table. There is
no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S, G)
entry. Also, verify that the correct flag is set in the (*, G) entry: an S-flag because the traffic is forwarded
using Sparse-mode.
For groups 239.100.2.x,
•
Incoming Interface should be portchannel 16 (from SH1-100).
•
Outgoing Interface List (OIL) should contain a single interface: portchannel 68.
It should have an H-flag next to it. The MMLS entries for each group should be consistent with the
mroute entries, containing the same Incoming Interface and OIL.
Step 13
Measure traffic loss due to the etherchannel failure.
Step 14
Bring portchannel 117 of SH1-104 back online.
Step 15
Start traffic running continuously.
Step 16
Verify that SH1-100 again builds the correct multicast routing states.
The elected PIM-RP, SH1-100, should have an (S, G) entry for all thirty groups, and it does. For each
(S, G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and
the (S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP
peer (SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.1.x:
•
Incoming interface: portchannel 65, RPF nbr 172.31.11.14, RPF-MFD
•
Outgoing interface list: portchannel 14, portchannel 15, portchannel 17, portchannel 66
For groups 239.100.2.x:
•
Incoming interface: portchannel 67, RPF nbr 172.31.1.98, RPF-MFD
•
Outgoing interface list: portchannel 15, portchannel 17, portchannel 64
For groups 239.100.3.x:
Step 17
•
Incoming interface: portchannel 17, RPF nbr 172.31.1.54, RPF-MFD
•
Outgoing interface list: portchannel 15, portchannel 67
Verify that SH1-104 again builds the correct multicast routing states for the thirty test groups.
For each group with SH1-104 being the transit router, verify a (*, G) entry in the mroute table. There is
no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S, G)
entry. Also, verify that the correct flag is set in the (*, G) entry: an S-flag because the traffic is forwarded
using Sparse-mode.
For groups 239.100.1.x:
•
Incoming Interface should be portchannel 117 (from SH1-100).
Cisco IOS Release 12.1(13)E13
350
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
•
Outgoing Interface List (OIL) should contain 4 interfaces: portchannel 68, portchannel 69,
portchannel 70, and portchannel 71.
For groups 239.100.2.x:
•
Incoming Interface should be portchannel 117 (from SH1-100).
•
Outgoing Interface List (OIL) should contain 2 interfaces: portchannel 68 and portchannel 71.
Each should have an H-flag next to it.
For each group with SH1-104 being the local PIM-RP verify a (S, G) entry in the mroute table. Also,
verify that the correct flag is set in the (*, G) entry: an S-flag because the traffic is forwarded using
Sparse-mode.
For groups 239.100.3.x:
•
Incoming Interface should be portchannel 71 (from SH1-110).
•
Outgoing Interface List (OIL) should contain 2 interfaces: portchannel 117, and portchannel 69.
Each should have an H-flag next to it.
Step 18
Verify that all four interfaces in portchannel 117 are passing traffic.
Step 19
Repeat the failover sequence four more times with a fixed amount of traffic, each time measuring the
traffic loss caused by the failover.
Step 20
Determine the average amount of traffic loss over the five failovers.
Step 21
Display the log for error messages.
Step 22
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that traffic will failover and be forwarded through RP SH1-99 when the portchannel
between SH1-104 and SH1-100 is torn down.
•
We expect that this failover will take place in a reasonable amount of time (within the 40-second
default OSPF dead time value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 60
Layer 3 GEC Failover—SH1-100 to SH1-104 Test Results
Test
Result
Layer 3 GEC Failover—SH1-100 to SH1-104
Pass
Layer 3 GEC Failover—SH1-100 to SH1-113
This test verified the ability of the devices to recover from a Layer 2 GEC failover, altering multicast
routing state in order to minimize traffic loss. Portchannel 20 on SH1-113 will be failed.
Goals:
•
Verify that the devices SH1-113, SH1-100, and SH1-99 maintain the correct multicast routing states
during the GEC failover.
Cisco IOS Release 12.1(13)E13
351
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
•
Verify that traffic loss is minimal.
Primary Devices Used:
•
SH1-113: Sup12; last-hop router for groups 239.100.3.[1-10]
•
SH1-100: Sup22; elected RP for groups 239.100.0.0/16
•
SH1-99: Sup22; backup RP for groups 239.100.0.0/16
Primary IXIA Ports Used:
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-100 to SH1-113 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-100 is beginning with the correct multicast routing states.
The elected PIM-RP, SH1-100, should have an (S, G) entry for all ten groups. For each (S, G) entry, it
should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and the (S, G) entry
is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP peer (SH1-99)
with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.2.x:
Step 5
•
Incoming interface: portchannel 67, RPF nbr 172.31.1.94, RPF-MFD
•
Outgoing interface list: portchannel 15, portchannel 17, portchannel 64
Verify that SH1-113 is beginning the procedure with the correct multicast routing states.
For each group (239.100.2.x) with SH1-113 being the last-hop router, verify a (*, G) entry in the mroute
table. There is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation
of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the
traffic is forwarded using Sparse-mode. and a C-flag because the receiver is directly connected to
SH1-113. For each group, the Incoming Interface should be portchannel 164 (from SH1-100, the primary
PIM-RP).
Step 6
For groups 239.100.2.x, the Outgoing Interface List (OIL) should contain a single interface:
FastEthernet9/2. Verify that SH1-113 is passing traffic both ways over all four interfaces in portchannel
164.
Step 7
Begin sending a fixed stream of traffic
Cisco IOS Release 12.1(13)E13
352
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 8
Shut down portchannel 164 on SH1-113.
Step 9
Verify that SH1-100 has the correct multicast routing states.
The elected PIM-RP, SH1-100, should have an (S, G) entry for all ten groups. For each (S, G) entry, it
should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and the (S, G) entry
is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP peer (SH1-99)
with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.2.x:
•
Incoming interface: portchannel 67, RPF nbr 172.31.1.94, RPF-MFD
•
Outgoing interface list: portchannel 15, portchannel 17
Step 10
Verify that SH1-113 builds the correct multicast routing state to the backup RP, SH1-99.
Step 11
For each group (239.100.2.x) with SH1-113 being the last-hop router, verify a (*, G) entry in the mroute
table. There is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation
of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the
traffic is forwarded using Sparse-mode. and a C-flag because the receiver is directly connected to
SH1-113. For each group, the Incoming Interface should be portchannel 64 (from SH1-99, the new
primary PIM-RP). For groups 239.100.2.x, the Outgoing Interface List (OIL) should contain a single
interface: FastEthernet9/2. Verify that SH1-99 builds the correct routing state down to SH1-113.
The newly elected PIM-RP, SH1-99, should have an (S, G) entry for all ten groups. For each (S, G) entry,
it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and the (S, G)
entry is used. The A-flag tells SH1-99 to advertise this particular (S, G) entry to the MSDP peer
(SH1-100) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.2.x:
Step 12
•
Incoming interface: portchannel 67, RPF nbr 172.31.1.94, RPF-MFD
•
Outgoing interface list: portchannel 64
Verify that SH1-114 builds the correct multicast routing states following the GEC failure.
No IP mroutes are found for any of the 10 multicast groups.
Step 13
Measure traffic loss due to the etherchannel failure.
Cisco IOS Release 12.1(13)E13
353
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 14
Bring portchannel 164 of SH1-113 back online.
Step 15
Start traffic running continuously.
Step 16
Verify that SH1-100 again builds the correct multicast routing states.
The elected PIM-RP, SH1-100, should have an (S, G) entry for all ten groups. For each (S, G) entry, it
should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and the (S, G) entry
is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP peer (SH1-99)
with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.2.x:
Step 17
•
Incoming interface: portchannel 67, RPF nbr 172.31.1.94, RPF-MFD
•
Outgoing interface list: portchannel 15, portchannel 17, portchannel 64
With traffic running continuously, verify that SH1-113 again builds the correct multicast routing states
for the ten test groups.
For each group (239.100.2.x) with SH1-113 being the last-hop router, verify a (*, G) entry in the mroute
table. There is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation
of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the
traffic is forwarded using Sparse-mode. and a C-flag because the receiver is directly connected to
SH1-113. For each group, the Incoming Interface should be portchannel 164 (from SH1-100, the primary
PIM-RP). For groups 239.100.2.x, the Outgoing Interface List (OIL) should contain a single interface:
FastEthernet9/2.
Step 18
Verify that both interfaces in portchannel 164 are passing traffic.
Step 19
Repeat the failover sequence four times with a fixed amount of traffic, each time measuring the traffic
loss caused by the failover.
Step 20
Determine the average amount of traffic loss over the five failovers.
Step 21
Display the log for error messages.
Step 22
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that traffic will failover and be forwarded through RP SH1-99 when the portchannel
between SH1-113 and SH1-100 is torn down.
•
We expect that this failover will take place in a reasonable amount of time (within the 40-second
default OSPF dead time value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco IOS Release 12.1(13)E13
354
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Results
Table 61
Layer 3 GEC Failover—SH1-100 to SH1-113 Test Results
Test
Result
Layer 3 GEC Failover—SH1-100 to SH1-113
Pass
Layer 3 GEC Failover—SH1-100 to SH1-106
This test verified the ability of the devices to recover from a Layer 3GEC failover, altering multicast
routing state in order to minimize traffic loss. Portchannel 20 on SH1-106 will be failed.
Goals:
•
Verify that the devices SH1-106, SH1-100, and SH1-99 maintain the correct multicast routing states
during the GEC failover.
•
Verify that traffic loss is minimal.
Primary Devices Used:
•
SH1-106: Sup11; last-hop router for groups 239.100.3.[1-10]; first-hop router for groups
239.100.2.[1-10]
•
SH1-100: Sup22; elected RP for groups 239.100.1.[1-10]
•
SH1-99: Sup22; backup RP for groups 239.100.1.[1-10]
Primary IXIA Ports Used:
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-100 to SH1-106 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-100 is beginning with the correct multicast routing states.
The elected PIM-RP, SH1-100, should have an (S, G) entry for all twenty groups, and it does. For each
(S, G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and
the (S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP
peer (SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
Cisco IOS Release 12.1(13)E13
355
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
For groups 239.100.2.x:
•
Incoming interface: portchannel 66, RPF nbr 172.31.1.94, RPF-MFD
•
Outgoing interface list: portchannel 15, portchannel 17, portchannel 64
For groups 239.100.3.x:
Step 5
•
Incoming interface: portchannel 17, RPF nbr 172.31.1.54, RPF-MFD
•
Outgoing interface list: portchannel 15 portchannel 67
Verify that SH1-106 is beginning the procedure with the correct multicast routing states.
For each group (239.100.3.x) with SH1-106 being the last-hop router, verify a (*, G) entry in the mroute
table. There is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation
of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the
traffic is forwarded using Sparse-mode. and a C-flag because the receiver is directly connected to
SH1-106. For each group, the Incoming Interface should be portchannel 167 (from SH1-100, the primary
PIM-RP).
For groups 239.100.3.x, the Outgoing Interface List (OIL) should contain a single interface: VLAN 41.
For each group (239.100.2.x) with SH1-106 being the first-hop router, SH1-106 has an (S, G) entry in
its mroute table. In this case, SH1-106 is a router-on-a-stick for these ten groups. Each (S, G) entry has
the F- and T-flags set, as well as the H-flag on each outgoing interface. The F-flag indicates that the
source is registered with the RP. The T-flag indicates that the Shortest Path Tree (SPT) is being used.
The H-flag indicates that the flow is being hardware-switched. The incoming interface list is VLAN 49.
The outgoing interface list is VLAN 50 and portchannel 167 which is connected to SH1-100.
Step 6
Verify that SH1-106 is passing traffic both ways over both interfaces in portchannel 167.
Step 7
Begin sending a fixed stream of traffic
Step 8
Shut down portchannel 167 on SH1-106.
Step 9
Verify that SH1-100 knows SH1-105 as the first-hop router for groups 239.100.2.[1-10] now.
The elected PIM-RP, SH1-100, should have an (S, G) entry for all ten groups, and it does. For each (S,
G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and the
(S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP peer
(SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.2.x:
Step 10
•
Incoming interface: portchannel 66, RPF nbr 172.31.1.94, RPF-MFD
•
Outgoing interface list: portchannel 15, portchannel 17, portchannel 64
Verify that SH1-106 builds the correct multicast routing state to the backup RP, SH1-99.
For each group (239.100.3.x) with SH1-106 being the last-hop router, verify a (*, G) entry in the mroute
table. There is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation
of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the
Cisco IOS Release 12.1(13)E13
356
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
traffic is forwarded using Sparse-mode. and a C-flag because the receiver is directly connected to
SH1-106. For each group, the Incoming Interface should be portchannel 67 (from SH1-99, the new
primary PIM-RP). For groups 239.100.3.x, the Outgoing Interface List (OIL) should contain a single
interface: VLAN 41.
Step 11
Verify that SH1-99 builds the correct routing state down to SH1-106.
The newly elected PIM-RP, SH1-99, should have an (S, G) entry for all ten groups, and it does. For each
(S, G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and
the (S, G) entry is used. The A-flag tells SH1-99 to advertise this particular (S, G) entry to the MSDP
peer (SH1-100) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.3.x:
•
Note
SH1-99 prefers the path to SH1-103 over SH1-104 because the port channel to SH1-103 has 4 ports
instead vs. 2.
•
Step 12
Incoming interface: portchannel 16, RPF nbr 172.31.11.14, RPF-MFD
Outgoing interface list: portchannel 67
Verify that SH1-105 takes over the role of first-hop router for the 239.100.2.x groups. This occurs
because of the equal cost paths to SH1-100 from both SH1-105 and SH1-106. This causes SH1-100 to
remain the preferred PIM DR through SH1-105 for 239.100.2.x groups rather than use SH1-99 through
SH1-106 after portchannel167 on SH1-106 is shut down.
For each group (239.100.2.x) with SH1-105 being the new first-hop router for the 239.100.2.x groups.,
SH1-105 has an (S, G) entry in its mroute table. Each (S, G) entry has the F- and T-flags set, as well as
the H-flag on each outgoing interface. The F-flag indicates that the source is registered with the RP. The
T-flag indicates that the Shortest Path Tree (SPT) is being used. The H-flag indicates that the flow is
being hardware-switched. The incoming interface list is VLAN 49. The outgoing interface list is
portchannel 166 which is connected to SH1-100.
Step 13
Measure traffic loss due to the etherchannel failure.
Step 14
Bring portchannel 167 of SH1-106 back online.
Note
At this point portchannel 167 came up but the OSPF neighbor relationship never came up. The multicast
routing source continued to go through SH1-105 (instead of SH1-106) to SH1-100.
This occurred even with access-group 181 on the portchannel and the Gig Ethernet interfaces that make
it up. As soon as the access-group 181 in was removed from portchannel 167, the OSPF neighbor came
up in 1-2 seconds and the multicast routing resumed correctly through portchannel 167 on SH1-106.
Step 15
Start traffic running continuously
Step 16
Verify that SH1-100 again builds the correct multicast routing states.
Cisco IOS Release 12.1(13)E13
357
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
The elected PIM-RP, SH1-100, should have an (S, G) entry for all thirty groups, and it does. For each
(S, G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and
the (S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP
peer (SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
For groups 239.100.2.x:
•
Incoming interface: portchannel 66, RPF nbr 172.31.1.94, RPF-MFD
•
Outgoing interface list: portchannel 15, portchannel 17, portchannel 64
For groups 239.100.3.x:
Step 17
•
Incoming interface: portchannel 17, RPF nbr 172.31.1.54, RPF-MFD
•
Outgoing interface list: portchannel 15
With traffic running continuously, verify that SH1-106 again builds the correct multicast routing states
for the twenty test groups.
For each group (239.100.3.x) with SH1-106 being the last-hop router, verify a (*, G) entry in the mroute
table. There is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation
of an (S, G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the
traffic is forwarded using Sparse-mode. and a C-flag because the receiver is directly connected to
SH1-106. For each group, the Incoming Interface should be portchannel 167 (from SH1-100, the primary
PIM-RP).
For groups 239.100.3.x, the Outgoing Interface List (OIL) should contain a single interface: VLAN 41.
For each group (239.100.2.x) with SH1-106 being the first-hop router, SH1-106 has an (S, G) entry in
its mroute table. In this case, SH1-106 is a router-on-a-stick for these ten groups. Each (S, G) entry has
the F- and T-flags set, as well as the H-flag on each outgoing interface. The F-flag indicates that the
source is registered with the RP. The T-flag indicates that the Shortest Path Tree (SPT) is being used.
The H-flag indicates that the flow is being hardware-switched. The incoming interface list is VLAN 49.
The outgoing interface list is VLAN 50 and portchannel 167 which is connected to SH1-100.
Step 18
Verify that both interfaces in portchannel 167 are passing traffic.
Step 19
Repeat the failover sequence four more times with a fixed amount of traffic, each time measuring the
traffic loss caused by the failover.
Step 20
Determine the average amount of traffic loss over the five failovers.
Step 21
Display the log for error messages.
Step 22
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that traffic will failover and be forwarded through RP SH1-99 when the portchannel
between SH1-106 and SH1-100 is torn down.
Cisco IOS Release 12.1(13)E13
358
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
•
We expect that this failover will take place in a reasonable amount of time (within the 40-second
default OSPF dead time value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 62
Layer 3 GEC Failover—SH1-100 to SH1-106 Test Results
Test
Result
Layer 3 GEC Failover—SH1-100 to SH1-106
Pass
Layer 3 GEC Failover—SH1-100 to SH1-105
This test verified the ability of the devices to recover from a Layer 3GEC failover, altering multicast
routing state in order to minimize traffic loss. Portchannel 20 on SH1-105 will be failed.
Goals:
•
Verify that the devices SH1-105, SH1-100, and SH1-99 maintain the correct multicast routing states
during the GEC failover.
•
Verify that traffic loss is minimal.
Primary Devices Used:
•
SH1-105: Sup11; last-hop router for groups 239.100.1.[1-10]
•
SH1-100: Sup22; elected RP for groups 239.100.0.0/16
•
SH1-99: Sup22; backup RP for groups 239.100.0.0/16
•
SH1-99 and SH1-100 are sharing the RP Anycast address 172.31.0.100; but SH1-100 is the elected
RP for groups 239.100.0.0/16 because it has the higher IP address.
Primary IXIA Ports Used:
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-100 to SH1-105 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-100 is beginning with the correct multicast routing states.
The elected PIM-RP, SH1-100, should have an (S, G) entry for all ten groups, and it does. For each (S,
G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and the
(S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP peer
(SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
Cisco IOS Release 12.1(13)E13
359
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.1.x:
Step 5
•
Incoming interface: portchannel 65, RPF nbr 172.31.11.14, RPF-MFD
•
Outgoing interface list: portchannel 14, portchannel 15, portchannel 17, portchannel 66
Verify that SH1-105 is beginning the procedure with the correct multicast routing states.
For each group with SH1-105 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102. For
each group, the Incoming Interface should be portchannel 166 (from SH1-100, the primary PIM-RP).
For groups 239.100.1.x, the Outgoing Interface List (OIL) should contain a single interface:
GigabitEthernet3/2.
This should have an H-flag next to it, indicating that it is being Hardware-switched. The MMLS entries
for each group should be consistent with the mroute entries, containing the same Incoming Interface and
OIL.
Step 6
Verify that SH1-105 is passing traffic both ways over all four interfaces in portchannel 166.
Step 7
Begin sending a fixed stream of traffic
Step 8
Shut down portchannel 166 on SH1-105.
Step 9
Verify that SH1-100 has the correct multicast routing states.
The elected PIM-RP, SH1-100, should have an (S, G) entry for all ten groups, and it does. For each (S,
G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and the
(S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP peer
(SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.1.x:
Step 10
•
Incoming interface: portchannel 65, RPF nbr 172.31.11.14, RPF-MFD
•
Outgoing interface list: portchannel 14, portchannel 15, portchannel 17
Verify that SH1-105 builds the correct multicast routing state to the backup RP, SH1-99.
Cisco IOS Release 12.1(13)E13
360
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
For each group with SH1-105 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102. For
each group, the Incoming Interface should be portchannel 66 (from SH1-99, the new primary PIM-RP).
For groups 239.100.1.x, the Outgoing Interface List (OIL) should contain a single interface:
GigabitEthernet3/2.
This should have an H-flag next to it, indicating that it is being Hardware-switched. The MMLS entries
for each group should be consistent with the mroute entries, containing the same Incoming Interface and
OIL.
Step 11
Verify that SH1-99 builds the correct routing state down to SH1-105.
The newly elected PIM-RP, SH1-99, should have an (S, G) entry for all ten groups, and it does. For each
(S, G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and
the (S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP
peer (SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.1.x:
Step 12
•
Incoming interface: portchannel 65, RPF nbr 172.31.11.14, RPF-MFD
•
Outgoing interface list: portchannel 66
Verify that SH1-106 builds the correct multicast routing states following the GEC failure.
No IP mroutes are found for any of the 10 multicast groups.
Step 13
Measure traffic loss due to the etherchannel failure.
Step 14
Bring portchannel 166 of SH1-105 back online.
Step 15
Start traffic running continuously.
Step 16
Verify that SH1-100 again builds the correct multicast routing states.
The elected PIM-RP, SH1-100, should have an (S, G) entry for all ten groups, and it does. For each (S,
G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and the
(S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP peer
(SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
Cisco IOS Release 12.1(13)E13
361
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.1.x:
Step 17
•
Incoming interface: portchannel 65, RPF nbr 172.31.11.14, RPF-MFD
•
Outgoing interface list: portchannel 14, portchannel 15, portchannel 17, portchannel 66
With traffic running continuously, verify that SH1-105 again builds the correct multicast routing states
for the ten test groups.
For each group with SH1-105 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102. For
each group, the Incoming Interface should be portchannel 166 (from SH1-100, the primary PIM-RP).
For groups 239.100.1.x, the Outgoing Interface List (OIL) should contain a single interface:
GigabitEthernet3/2.
This should have an H-flag next to it, indicating that it is being Hardware-switched. The MMLS entries
for each group should be consistent with the mroute entries, containing the same Incoming Interface and
OIL.
Step 18
Verify that both interfaces in portchannel 166 are passing traffic.
Step 19
Repeat the failover sequence four more times with a fixed amount of traffic, each time measuring the
traffic loss caused by the failover.
Step 20
Determine the average amount of traffic loss over the five failovers.
Step 21
Display the log for error messages.
Step 22
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that traffic will failover and be forwarded through RP SH1-99 when the portchannel
between SH1-105 and SH1-100 is torn down.
•
We expect that this failover will take place in a reasonable amount of time (within the 40-second
default OSPF dead time value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 63
Layer 3 GEC Failover—SH1-100 to SH1-105 Test Results
Test
Result
Layer 3 GEC Failover—SH1-100 to SH1-105
Pass
Layer 3 GEC Failover—SH1-100 to SH1-102
This test verified the ability of the devices to recover from a Layer 3GEC failover, altering multicast
routing state in order to minimize traffic loss. Portchannel 20 on SH1-102 will be failed.
Cisco IOS Release 12.1(13)E13
362
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Goals:
•
Verify that the devices SH1-102, SH1-100, and SH1-99 maintain the correct multicast routing states
during the GEC failover.
•
Verify that traffic loss is minimal.
Primary Devices Used:
•
SH1-102: Sup22; last-hop router for groups 239.100.[1-3].[1-10]
•
SH1-100: Sup22; elected RP for groups 239.100.0.0/16
•
SH1-99: Sup22; backup RP for groups 239.100.0.0/16
Primary IXIA Ports Used:
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-100 to SH1-102 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-100 is beginning with the correct multicast routing states.
The elected PIM-RP, SH1-100, should have an (S, G) entry for all thirty groups, and it does. For each
(S, G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and
the (S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP
peer (SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.1.x:
•
Incoming interface: portchannel 65, RPF nbr 172.31.11.14, RPF-MFD
•
Outgoing interface list: portchannel 14, portchannel 15, portchannel 17, portchannel 66
For groups 239.100.2.x:
•
Incoming interface: portchannel 66, RPF nbr 172.31.1.94, RPF-MFD
•
Outgoing interface list: portchannel 15, portchannel 17, portchannel 64
For groups 239.100.3.x:
Step 5
•
Incoming interface: portchannel 17, RPF nbr 172.31.1.54, RPF-MFD
•
Outgoing interface list: portchannel 15, portchannel 67
Verify that SH1-102 is beginning the procedure with the correct multicast routing states.
Cisco IOS Release 12.1(13)E13
363
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
For each group with SH1-102 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102. For
each group, the Incoming Interface should be portchannel 115 (from SH1-100, the primary PIM-RP).
For groups 239.100.1.x, the Outgoing Interface List (OIL) should contain a single interface: VLAN 41.
For groups 239.100.2.x, the Outgoing Interface List (OIL) should contain a single interface: VLAN 43.
For groups 239.100.3.x, the Outgoing Interface List (OIL) should contain two interfaces: VLAN 43 and
FastEthernet4/5.
This should have an H-flag next to it, indicating that it is being Hardware-switched.
Step 6
Verify that SH1-102 is passing traffic both ways over all four interfaces in portchannel 115.
Step 7
Begin sending a fixed stream of traffic
Step 8
Shut down portchannel 115 on SH1-102.
Step 9
Verify that SH1-100 has the correct multicast routing states.
The elected PIM-RP, SH1-100, should have an (S, G) entry for all thirty groups, and it does. For each
(S, G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and
the (S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP
peer (SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.1.x:
•
Incoming interface: portchannel 65, RPF nbr 172.31.11.14, RPF-MFD
•
Outgoing interface list: portchannel 14, portchannel 17, portchannel 66
For groups 239.100.2.x:
•
Incoming interface: portchannel 67, RPF nbr 172.31.1.94, RPF-MFD
•
Outgoing interface list: portchannel 17, portchannel 64
For groups 239.100.3.x:
Step 10
•
Incoming interface: portchannel 17, RPF nbr 172.31.1.54, RPF-MFD
•
Outgoing interface list: portchannel 67
Verify that SH1-102 builds the correct multicast routing state to the backup RP, SH1-99.
For each group with SH1-102 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102. For
each group, the Incoming Interface should be portchannel 15 (from SH1-99, the new primary
PIM-RP).
Cisco IOS Release 12.1(13)E13
364
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
For groups 239.100.1.x, the Outgoing Interface List (OIL) should contain a single interface: VLAN 41.
For groups 239.100.2.x, the Outgoing Interface List (OIL) should contain a single interface: VLAN 43.
For groups 239.100.3.x, the Outgoing Interface List (OIL) should contain two interfaces: VLAN 43 and
FastEthernet4/5.
This should have an H-flag next to it, indicating that it is being Hardware-switched. The MMLS entries
for each group should be consistent with the mroute entries, containing the same Incoming Interface and
OIL.
Step 11
Verify that SH1-99 builds the correct routing state down to SH1-102.
The new PIM-RP, SH1-99, should have an (S, G) entry for all thirty groups, and it does. It should also
have the T-flag and the A-flag set. The T-flag is correctly set for all groups while, as was seen above, the
A-flag is not consistently set for all groups. Also, due to this DDTS, the M-flag will be set on some (S,
G) entries. For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating
hardware-switching. There is always consistency between the mroute entries and the MMLS entries for
each group.
For groups 239.100.1.x:
•
Incoming interface: portchannel 65, RPF nbr 172.31.11.14, RPF-MFD
•
Outgoing interface list: portchannel 14, portchannel 15, portchannel 17, portchannel 66
For groups 239.100.2.x:
•
Incoming interface: portchannel 67, RPF nbr 172.31.1.94, RPF-MFD
•
Outgoing interface list: portchannel 15, portchannel 17, portchannel 64
For groups 239.100.3.x:
Step 12
•
Incoming interface: portchannel 17, RPF nbr 172.31.1.54, RPF-MFD
•
Outgoing interface list: portchannel 15
Verify that SH1-101 builds the correct multicast routing state to the backup RP, SH1-99.
For each group with SH1-102 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102. For
each group, the Incoming Interface should be portchannel 114 (from SH1-100, the primary PIM-RP).
For groups 239.100.1.x, the Outgoing Interface List (OIL) should contain a single interface:
GigabitEthernet7/16.
For groups 239.100.2.x, the Outgoing Interface List (OIL) should contain Null.
For groups 239.100.3.x, the Outgoing Interface List (OIL) should contain Null.
This should have an H-flag next to it, indicating that it is being Hardware-switched. The MMLS entries
for each group should be consistent with the mroute entries, containing the same Incoming Interface and
OIL.
Step 13
Measure traffic loss due to the etherchannel failure.
Step 14
Bring portchannel 115 of SH1-102 back online.
Step 15
Start traffic running continuously.
Step 16
Verify that SH1-100 again builds the correct multicast routing states.
Cisco IOS Release 12.1(13)E13
365
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
The elected PIM-RP, SH1-100, should have an (S, G) entry for all thirty groups, and it does. For each
(S, G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and
the (S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP
peer (SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.1.x:
•
Incoming interface: portchannel 65, RPF nbr 172.31.11.14, RPF-MFD
•
Outgoing interface list: portchannel 14, portchannel 15, portchannel 17, portchannel 66
For groups 239.100.2.x:
•
Incoming interface: portchannel 66, RPF nbr 172.31.1.94, RPF-MFD
•
Outgoing interface list: portchannel 15, portchannel 17, portchannel 64
For groups 239.100.3.x:
Step 17
•
Incoming interface: portchannel 17, RPF nbr 172.31.1.54, RPF-MFD
•
Outgoing interface list: portchannel 15, portchannel 67
With traffic running continuously, verify that SH1-102 again builds the correct multicast routing states
for the thirty test groups.
For each group with SH1-102 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102. For
each group, the Incoming Interface should be portchannel 115 (from SH1-100, the primary PIM-RP).
For groups 239.100.1.x, the Outgoing Interface List (OIL) should contain a single interface: VLAN 41.
For groups 239.100.2.x, the Outgoing Interface List (OIL) should contain a single interface: VLAN 43.
For groups 239.100.3.x, the Outgoing Interface List (OIL) should contain two interfaces: VLAN 43 and
FastEthernet4/5.
This should have an H-flag next to it, indicating that it is being Hardware-switched. The MMLS entries
for each group should be consistent with the mroute entries, containing the same Incoming Interface and
OIL.
Step 18
Verify that all four interfaces in portchannel 115 are passing traffic.
Step 19
Repeat the failover sequence four more times with a fixed amount of traffic, each time measuring the
traffic loss caused by the failover.
Step 20
Determine the average amount of traffic loss over the five failovers.
Step 21
Display the log for error messages.
Step 22
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco IOS Release 12.1(13)E13
366
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Expected Results
•
We expect that traffic will failover and be forwarded through RP SH1-99 when the portchannel
between SH1-102 and SH1-100 is torn down.
•
We expect that this failover will take place in a reasonable amount of time (worst case the 45-second
default EIGRP hold time).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 64
Layer 3 GEC Failover—SH1-100 to SH1-102 Test Results
Test
Result
Layer 3 GEC Failover—SH1-100 to SH1-102
Pass
Layer 3 GEC Failover—SH1-100 to SH1-101
This test verified the ability of the devices to recover from a Layer 3GEC failover, altering multicast
routing state in order to minimize traffic loss. Portchannel 20 on SH1-101 will be failed.
Goals:
•
Verify that the devices SH1-101, SH1-100, and SH1-99 maintain the correct multicast routing states
during the GEC failover.
•
Verify that traffic loss is minimal.
Primary Devices Used:
•
SH1-101: Sup22; last-hop router for groups 239.100.1.[1-10]
•
SH1-100: Sup22; elected RP for groups 239.100.1.[1-10]
•
SH1-99: Sup22; backup RP for groups 239.100.1.[1-10]
•
SH1-99 and SH1-100 are sharing the RP Anycast address 172.31.0.100; but SH1-100 is the elected
RP for groups 239.100.0.0/16 because it has the higher IP address.
Primary IXIA Ports Used:
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-100 to SH1-101 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-100 is beginning with the correct multicast routing states.
Cisco IOS Release 12.1(13)E13
367
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
The elected PIM-RP, SH1-100, should have an (S, G) entry for all ten groups, and it does. For each (S,
G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and the
(S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP peer
(SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.1.x:
Step 5
•
Incoming interface: portchannel 65, RPF nbr 172.31.11.14, RPF-MFD
•
Outgoing interface list: portchannel 14, portchannel 15, portchannel 17, portchannel 66
Verify that SH1-101 is beginning the procedure with the correct multicast routing states.
For each group with SH1-101 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102. For
each group, the Incoming Interface should be portchannel 114 (from SH1-100, the primary PIM-RP).
For groups 239.100.1.x, the Outgoing Interface List (OIL) should contain a single interface:
GigabitEthernet7/16
This should have an H-flag next to it, indicating that it is being Hardware-switched. The MMLS entries
for each group should be consistent with the mroute entries, containing the same Incoming Interface and
OIL.
Step 6
Verify that SH1-101 is passing traffic over portchannel 114.
Step 7
Begin sending a fixed stream of traffic
Step 8
Shut down portchannel 114 on SH1-101.
Step 9
Verify that SH1-100 builds the correct multicast routing state to the backup RP, SH1-99.
The elected PIM-RP, SH1-100, should have an (S, G) entry for all ten groups, and it does. For each (S,
G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and the
(S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP peer
(SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.1.x:
Cisco IOS Release 12.1(13)E13
368
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 10
•
Incoming interface: portchannel 65, RPF nbr 172.31.11.14, RPF-MFD
•
Outgoing interface list: portchannel 15, portchannel 17, portchannel 66
Verify that SH1-101 builds the correct multicast routing state to the backup RP, SH1-99.
For each group with SH1-101 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102. For
each group, the Incoming Interface should be portchannel 14 (from SH1-99, the new primary PIM-RP).
For groups 239.100.1.x, the Outgoing Interface List (OIL) should contain a single interface:
GigabitEthernet7/16
This should have an H-flag next to it, indicating that it is being Hardware-switched.
Step 11
Verify that SH1-99 builds the correct routing state down to SH1-101.
The newly elected PIM-RP, SH1-99, should have an (S, G) entry for all ten groups, and it does. For each
(S, G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and
the (S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP
peer (SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.100.1.x:
Step 12
•
Incoming interface: portchannel 65, RPF nbr 172.31.11.14, RPF-MFD
•
Outgoing interface list: portchannel 14
Verify that SH1-102 builds the correct multicast routing state to the backup RP, SH1-99.
For each group with SH1-102 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102. For
each group, the Incoming Interface should be portchannel 115 (from SH1-100, the primary PIM-RP).
For groups 239.100.1.x, the Outgoing Interface List (OIL) should contain a single interface: VLAN 41
This should have an H-flag next to it, indicating that it is being Hardware-switched.
Step 13
Measure traffic loss due to the etherchannel failure.
Step 14
Bring portchannel 114 of SH1-101 back online.
Step 15
With traffic running continuously, verify that SH1-101 again builds the correct multicast routing states
for the ten test groups.
Step 16
Verify that SH1-100 again builds the correct multicast routing states.
Cisco IOS Release 12.1(13)E13
369
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
The elected PIM-RP, SH1-100, should have an (S, G) entry for all ten groups, and it does. For each (S,
G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and the
(S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP peer
(SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss. Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates
that the group was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
For groups 239.100.1.x:
Step 17
•
Incoming interface: portchannel 65, RPF nbr 172.31.11.14, RPF-MFD
•
Outgoing interface list: portchannel 14, portchannel 15, portchannel 17, portchannel 66
With traffic running continuously, verify that SH1-101 again builds the correct multicast routing states
for the ten test groups.
For each group with SH1-101 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102. For
each group, the Incoming Interface should be portchannel 114 (from SH1-100, the primary PIM-RP).
For groups 239.100.1.x, the Outgoing Interface List (OIL) should contain a single interface:
GigabitEthernet7/16
This should have an H-flag next to it, indicating that it is being Hardware-switched. The MMLS entries
for each group should be consistent with the mroute entries, containing the same Incoming Interface and
OIL.
Step 18
Verify that the interface portchannel 114 is passing traffic.
Step 19
Repeat the failover sequence four more times with a fixed amount of traffic, each time measuring the
traffic loss caused by the failover.
Step 20
Determine the average amount of traffic loss over the five failovers.
Step 21
Display the log for error messages.
Step 22
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that traffic will failover and be forwarded through RP SH1-99 when the portchannel
between SH1-101 and SH1-100 is torn down.
•
We expect that this failover will take place in a reasonable amount of time (within the 45 second
EIGRP hold time value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco IOS Release 12.1(13)E13
370
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Results
Table 65
Layer 3 GEC Failover—SH1-100 to SH1-101 Test Results
Test
Result
Layer 3 GEC Failover—SH1-100 to SH1-101
Pass
Layer 3 GEC Failover—SH1-100 to SH1-97
This test verified the ability of the devices to recover from a Layer 3GEC failover, altering multicast
routing state in order to minimize traffic loss. Portchannel 20 on SH1-101 will be failed.
Goals:
•
Verify that the devices SH1-100, and SH1-97 maintain the correct multicast routing states during
the GEC failover.
•
Verify that traffic loss is minimal.
Primary Devices Used:
•
SH1-100: Sup22; transit router for groups 239.98.50.[1-10]
•
SH1-97: Sup22 and SH1-98: Sup22 are sharing the RP Anycast address 172.31.0.98; but SH1-97 is
the elected RP for groups 239.98.0.0/16 because it is the RP directly connected to the source.
•
SH1-99: Sup22; becomes router used for RPF when GEC is failed between SH1-97 and SH1-100.
Primary IXIA Ports Used:
•
All
Test Procedure
The procedure used to perform the Layer 3 GEC Failover—SH1-100 to SH1-97 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-97 is beginning with the correct multicast routing states.
The elected PIM-RP, SH1-97, should have an (S, G) entry for all 10 groups, and it does. For each (S, G)
entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and the (S,
G) entry is used. The A-flag tells SH1-97 to advertise this particular (S, G) entry to the MSDP peer
(SH1-98) with the SA messages. The T-flag is correctly set for all groups.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.98.50.x:
Step 5
•
Incoming interface: FastEthernet8/11
•
Outgoing interface list: portchannel 13
Verify that SH1-100 is beginning the procedure with the correct multicast routing states.
Cisco IOS Release 12.1(13)E13
371
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
For each group with SH1-100 being the transit router, verify a (*, G) entry in the mroute table. There is
no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S, G)
entry. Also, verify that the correct flag is set in the (*, G) entry: an S-flag because the traffic is forwarded
using Sparse-mode.
For groups 239.98.50.1.x:
•
Incoming Interface should be portchannel 13 (from SH1-97).
•
Outgoing Interface List (OIL) should contain 4 interfaces: portchannel 65, portchannel 67,
portchannel 17, portchannel 15.
The MMLS entries for each group should be consistent with the mroute entries, containing the same
Incoming Interface and OIL.
Step 6
Verify that SH1-100 is passing traffic in portchannel 13.
There are multicast packets coming in on each interface of portchannel 13.
Step 7
Begin sending a fixed stream of traffic.
Step 8
Shut down portchannel 13 on SH1-100.
The elected PIM-RP, SH1-97, should have an (S, G) entry for all 10 groups, and it does. For each (S, G)
entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and the (S,
G) entry is used. The A-flag tells SH1-97 to advertise this particular (S, G) entry to the MSDP peer
(SH1-98) with the SA messages. The T-flag is correctly set for all groups.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.98.50.x:
Step 9
•
Incoming interface: FastEthernet8/11
•
Outgoing interface list: portchannel 12 (to SH1-99)
Verify that SH1-100 builds the correct multicast routing state to the backup RP, SH1-98.
For each group with SH1-100 being the transit router, verify a (*, G) entry in the mroute table. There is
no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S, G)
entry. Also, verify that the correct flag is set in the (*, G) entry: an S-flag because the traffic is forwarded
using Sparse-mode.
For groups 239.98.50.1.x:
•
Incoming Interface should be portchannel 13 (from SH1-98).
•
Outgoing Interface List (OIL) should contain 4 interfaces: portchannel 65, portchannel 67,
portchannel 17, portchannel 15.
The MMLS entries for each group should be consistent with the mroute entries, containing the same
Incoming Interface and OIL.
What we actually see here is that SH1-99 is forwarding the traffic down to the receivers for three of the
interfaces, portchannel 67, portchannel 16, and portchannel 65. SH1-99 has portchannel 13 in its OIL,
as well, forwarding to SH1-100, which has portchannel 15 in its OIL. So, for three of the four receivers,
SH1-99 is forwarding traffic. For one of the receivers SH1-100 is forwarding the traffic.
The explanation is that, with the current setup, the cost from SH1-99 to SH1-97 is better than from to
SH1-100 to SH1-98 so the path through SH1-99 to SH1-97 would be the preferred one.
The lone receiver from SH1-102 to SH1-100 happens to have a better cost path than to SH1-100 than to
SH1-99 so it uses the path to SH1-100 as the preferred one. So, the actual results make sense with the
current setup.
Cisco IOS Release 12.1(13)E13
372
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 10
Measure traffic loss due to the etherchannel failure.
Step 11
Bring portchannel 13 of SH1-100 back online.
Step 12
Start traffic running continuously
Step 13
Verify that SH1-97 again builds the correct multicast routing states.
The elected PIM-RP, SH1-97, should have an (S, G) entry for all 10 groups, and it does. For each (S, G)
entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and the (S,
G) entry is used. The A-flag tells SH1-97 to advertise this particular (S, G) entry to the MSDP peer
(SH1-98) with the SA messages. The T-flag is correctly set for all groups.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
For groups 239.98.50.x:
Step 14
•
Incoming interface: FastEthernet8/11
•
Outgoing interface list: portchannel 13
Verify that SH1-100 again builds the correct multicast routing states for the ten test groups.
For each group with SH1-100 being the transit router, verify a (*, G) entry in the mroute table. There is
no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S, G)
entry. Also, verify that the correct flag is set in the (*, G) entry: an S-flag because the traffic is forwarded
using Sparse-mode.
For groups 239.98.50.1.x:
•
Incoming Interface should be portchannel 13 (from SH1-97).
•
Outgoing Interface List (OIL) should contain 4 interfaces: portchannel 65, portchannel 67,
portchannel 17, portchannel 15.
The MMLS entries for each group should be consistent with the mroute entries, containing the same
Incoming Interface and OIL.
Step 15
Verify that the interface portchannel 13 is passing traffic.
Step 16
Repeat the failover sequence four more times with a fixed amount of traffic, each time measuring the
traffic loss caused by the failover.
Step 17
Determine the average amount of traffic loss over the five failovers.
Step 18
Display the log for error messages.
Step 19
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that traffic will failover and be forwarded through SH1-99 when the portchannel between
SH1-97 and SH1-100 is torn down.
•
We expect that this failover will take place in a reasonable amount of time (within the 40-second
default OSPF dead time value).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco IOS Release 12.1(13)E13
373
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Results
Table 66
Layer 3 GEC Failover—SH1-100 to SH1-97 Test Results
Test
Result
Layer 3 GEC Failover—SH1-100 to SH1-97
Pass
Switch Fabric Module Failover—Supervisor 22
This test verified multicast functionality during Switch Fabric Module (SFM) failover. Multicast traffic
is sourced from IXIA and transits through SH1-106. The traffic is switched using the crossbar fabric.
This test performed a series of resets on the active SFM and measured traffic loss at each iteration.
In several of the following steps, verification that the traffic is using the SFM is requested. How the
Medusa ASIC handled traffic was verified. The Medusa ASIC interfaces are between the line card local
bus and the backplane of the Catalyst 6500. If traffic is using the SFM (no legacy, or nonfabric-enabled,
cards present), the Medusa mode will be compact for all line cards, indicating that it is sending a compact
header on the backplane for the switching decision. Note that any WS-X6816 modules are always in
compact mode, because they are fabric-only cards. More on the switching modes involving the SFM can
be found at the Cisco Catalyst 6500 Series Switches site:
http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter0
9186a008007fb2a.html
Goals:
•
Verify that the router is using the crossbar fabric to switch the traffic prior to SFM failover.
•
Verify that the router is using the crossbar fabric to switch the traffic after the SFM failover.
•
Verify that failover times are within acceptable parameters.
Primary Devices Used:
•
SH1-102: Sup22; last-hop router for groups 239.100.2.[1-10]
Primary IXIA Ports Used:
•
4/2, 1/2
Test Procedure
The procedure used to perform the Switch Fabric Module Failover—Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-102 is a last-hop router for test groups 239.100.2.[1-10].
As the last-hop router, SH1-102 should be switching the test traffic using a (*, G) entry (because
SPT-threshold is infinity). This is the case, as SH1-102 has a (*, G) entry for each group, and an (S, G)
for none. Each group also has the correct flags set: S-flag for Sparse mode; C-flag for the directly
Connected receiver; and the H-flag for Hardware switched traffic.
Incoming interface: portchannel 115, RPF nbr 172.31.1.45, RPF-MFD
Cisco IOS Release 12.1(13)E13
374
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Outgoing interface list: VLAN 43, Forward/Sparse, 04:40:11/00:02:10, H
Step 5
Verify that SH1-102 is receiving traffic on portchannel 115 and transmitting traffic on portchannel 10,
and that the traffic is being hardware-switched.
Multicast traffic is being received on portchannel 115 and transmitted on portchannel 10.
There is an MMLS entry for each group, indicating hardware-switching. Each entry shows the Incoming
interface as portchannel 115 and the Hardware switched outgoing interface as VLAN 43 (which is
carried on the portchannel 10 trunk).
Step 6
Verify that portchannels 10 and 115 consist of interfaces on fabric-enabled line cards.
portchannel s 10 and 115 are comprised of interfaces from modules 7 and 3, respectively.
Module 7 (WS-X6516-GBIC) is a fabric-enabled module. Module 3 (WS-X6816-GBIC) is a pure fabric
module. So both should be using the fabric to switch traffic.
Step 7
Verify that all fabric-enabled modules are using the crossbar fabric to switch the traffic.
Modules 3 and 7 are not in bus mode, so they are using the fabric to switch traffic.
Step 8
Start the test script which will failover the active fabric module on SH1-102 500 times while running
traffic.
Step 9
Analyze the results from the script and verify that failover times are within tolerances. Log output from
the test is given in full here:
Below there are three rows of data, Active, OIR, and Traffic. The Active row represents the amount of
time, in milliseconds, it took for the standby fabric module to come online as active, following the failure
of the active module. The OIR value represents the amount of time, in milliseconds, that it took for the
failed fabric module to return to an online (standby) state. Lastly, the Traffic value gives the amount of
time, in milliseconds, that traffic flow was interrupted.
Note
There was one iteration of the test that skewed OIR (iteration 390), and 2 iterations that skewed traffic
(iterations 391 and 392). I can't explain this anomaly.
The mean length of traffic loss was 0.633 seconds, well within tolerances. The fastest and slowest times
do not raise alarm either since almost all other times were either 8 or 12 msec. The times for failover and
reset of the fabric modules are also acceptable.
Step 10
Display the log for error messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that failovers should occur within an acceptable amount of time and that traffic loss due
to fabric failure should be minimal.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco IOS Release 12.1(13)E13
375
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Results
Table 67
Switch Fabric Module Failover—Supervisor 22 Test Results
Test
Result
Switch Fabric Module Failover—Supervisor 22
Pass
GEM Failover—Supervisor 11 as First-Hop Router
This test verified multicast functionality during Gigabit Ethernet (GE) module failover at the first-hop
router. There are four Gigabit Ethernet modules in SH1-106, which is the first-hop router for groups
239.100.2.[1-10]. Three of these were reset with traffic passing through them. Traffic continued to reach
the destination and mrouting and MMLS states were consistent with what was expected.
Goals:
•
Verify that the impact on traffic due to a GE module reset is minimal.
•
Verify that any impact to mrouting and MMLS states are consistent with what it expected.
Primary Devices Used:
•
SH1-106: Sup11; first-hop router for groups 239.255.2.[1-10]
Primary IXIA Ports Used:
•
4/2, 1/2
Test Procedure
The procedure used to perform the GEM Failover—Supervisor 11 as First-Hop Router test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-106 is the first-hop router for groups 239.100.2.[1-10].
A first-hop router should have an (S, G) entry with the F-flag and T-flag set. The F-flag indicates that the
source is registered with the RP. The T-flag indicates that the SPT-bit is set and the (S, G) is used.
SH1-106 has such an (S, G) entry for each of the ten groups. It is also hardware-forwarding the group
traffic out interface portchannel 167, as indicated by the H-flag. Each mroute is coupled with an MMLS
entry with consistent interface information.
Step 5
Show which modules are used by which etherchannels on SH1-106.
portchannel 20, which leads to the traffic source, consists of two interfaces on a WS-X6408-GBIC
module (Gi3/7 and Gi3/8). Portchannel 167, attached to the RP, consists of two interfaces, each on a
separate WS-X6408-GBIC module (Gi5/1 and Gi6/1).
Step 6
Verify that some multicast traffic is passing through the interfaces of each of these modules.
As the first-hop router, SH1-106 is receiving traffic on portchannel 20 and transmitting it on portchannel
167. This is confirmed in the Incoming Interface List (IIL) and Outgoing Interface List (OIL) for the
groups seen above.
Step 7
Reset module 3 on SH1-106.
Cisco IOS Release 12.1(13)E13
376
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 8
Once module 3 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
The mroute and MMLS entries are the same as in the initial state, with the correct flags and interfaces.
Step 9
Verify that the interfaces on module 3 are again passing traffic.
As the first-hop router, SH1-106 is receiving traffic on portchannel 20 and transmitting it on portchannel
167.
Step 10
Reset module 5 on SH1-106.
Step 11
Once module 5 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
The mroute and MMLS entries are the same as in the initial state, with the correct flags and interfaces.
Step 12
Verify that the interfaces on module 5 are again passing traffic.
Step 13
Reset module 6 on SH1-106.
Step 14
Once module 6 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
The mroute and MMLS entries are the same as in the initial state, with the correct flags and interfaces.
Step 15
Verify that the interfaces on module 6 are again passing traffic.
The interfaces on the reset module are again passing traffic as before.
Step 16
Display the log for error messages.
Step 17
Verify that there were no significant impacts on the CPU or memory of the devices under test.
Expected Results
•
We expect that the mroute and MMLS entries will be restored to their correct states when the reset
module and its interfaces are back online.
•
We expect that the interfaces of the reset module will pass traffic as before, once they come back
online.
•
We expect CPU and memory impact to be within acceptable limits.
Results
Table 68
GEM Failover—Supervisor 11 as First-Hop Router Test Results
Test
Result
GEM Failover—Supervisor 11 as First-Hop Router
Pass
GEM Failover—Supervisor 11 as Last-Hop Router
This test verified multicast functionality during Gigabit Ethernet (GE) module failover at the last-hop
router. There are four Gigabit Ethernet modules in SH1-106, which is the last-hop router for groups
239.100.3.[1-10]. Three of these were reset with traffic passing through them. Traffic continued to reach
the destination and mrouting and MMLS states were consistent with what was expected.
Goals:
•
Verify that the impact on traffic due to a GE module reset is minimal.
•
Verify that any impact to mrouting and MMLS states are consistent with what it expected.
Cisco IOS Release 12.1(13)E13
377
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Primary Devices Used:
•
SH1-106: Sup11; last-hop router for groups 239.255.3.[1-10]
Primary IXIA Ports Used:
•
N/A
Test Procedure
The procedure used to perform the GEM Failover—Supervisor 11 as Last-Hop Router test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-106 is the last-hop router for groups 239.100.3.[1-10].
As the last-hop router, SH1-106 should have a (*, G) entry for each group with the following flags set:
the S-flag, which indicates that the flow is set up in Sparse mode; the C-flag, indicating that the receiver
is directly Connected. SH1-106 has the (*, G) and both flags for each group for which it is the last-hop
router. It is not hardware-switching these flows, and therefore has no MMLS entry, as (*, G) flows are
software-switched on Supervisor 1 platforms.
Step 5
Show which modules are used by which etherchannels on SH1-106.
Being the last-hop router for the ten test groups, SH1-106 will have traffic coming in on portchannel 167
(from the RP) and going out portchannel 20 (to the receiver). Portchannel 167 consists of two ports,
Gi5/1 and Gi6/1. Portchannel 20 also consists of two ports, Gi3/7 and Gi3/8. The three modules
represented in these two etherchannels are all WS-X6408-GBIC modules.
Step 6
Verify that some multicast traffic is passing through the interfaces of each of these modules.
Traffic should be coming in on the interfaces of portchannel 167 (Gi5/1 and Gi6/1) and going out on the
interfaces of portchannel 20 (Gi3/7 and Gi3/8). This is indeed the case.
Step 7
Reset module 3 on SH1-106.
Step 8
Once module 3 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
The mroute and MMLS entries are correct as before, following the reset of module 3.
Step 9
Verify that the interfaces on module 3 are again passing traffic.
Both interfaces in portchannel 20 are again forwarding traffic.
Step 10
Reset module 5 on SH1-106.
Step 11
Once module 5 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
The mroute and MMLS entries are correct as before, following the reset of module 5. The (S, G) MMLS
entry is created because SH1-105 had become the DR when module 5 was reset on SH1-106. When
module 6 came back online, both SH1-105 and SH1-106 were forwarding traffic for a time until SH1-105
determined that SH1-106 was the DR again. As a result of both devices forwarding traffic, each was
receiving non-RPF traffic on VLAN 41 (the receiver VLAN). The (S, G) was created as a result of this
non-RPF traffic. It is deleted as soon as an assert is sent by SH1-106 on VLAN 41. This capture was
taken before this occurred though.
Step 12
Verify that the interfaces on module 5 are again passing traffic.
The interface in portchannel 167 are again receiving traffic.
Step 13
Reset module 6 on SH1-106.
Cisco IOS Release 12.1(13)E13
378
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 14
Once module 6 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
The mroute and MMLS entries are correct as before, following the reset of module 6.
Step 15
Verify that the interfaces on module 6 are again passing traffic.
The interface in portchannel 167 are again receiving traffic.
Step 16
Display the log for error messages.
Step 17
Verify that there were no significant impacts on the CPU or memory of the devices under test.
Expected Results
•
We expect that the proper mroute and MMLS entries will be reinstalled following the reset of the
various GE modules.
•
We expect that the proper interfaces on the reset modules will return to forwarding or receiving
traffic.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 69
GEM Failover—Supervisor 11 as Last-Hop Router Test Results
Test
Result
GEM Failover—Supervisor 11 as Last-Hop Router
Pass
GEM Failover—Supervisor 11 with Directly Connected Layer 3 Interface
This test determined the effect of resetting a GE module that has a directly connected Layer 3 interface.
Module 3 of SH1-105 has a directly connected Layer 3 interface on a secondary subnet. This interface
is connected to the receiver for groups 239.100.1.[1-10]. This module was reset, traffic resumed, and
mrouting and MMLS states were consistent with what was expected, after the module came back online.
Goals:
•
Verify that the impact on traffic to a Layer 3 receiver due to a GE module reset is minimal.
•
Verify that any impact to mrouting and MMLS states are consistent with what it expected.
Primary Devices Used:
•
SH1-105: Sup11; has directly connected Layer 3 receiver for groups 239.255.1.[1-10] on a
secondary subnet
Primary IXIA Ports Used:
•
N/A
Test Procedure
The procedure used to perform the GEM Failover—Supervisor 11 with Directly Connected Layer 3
Interface test follows:
Cisco IOS Release 12.1(13)E13
379
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that interface GigabitEthernet3/2 is a Layer 3 interface.
Interface GigabitEthernet3/2 is a Layer 3 interface with both a primary and secondary IP address
configured. The secondary network is what the receiver is on.
Step 5
Verify that SH1-105 has the correct mroute and MMLS entries for groups 239.100.1.[1-10].
SH1-105 has a (*, G) mroute entry for each group being received on the Layer 3 interface. Each (*, G)
has the S-flag and C-flag set. The S-flag indicates that Sparse-mode is being used. The C-flag indicates
that the receiver is directly Connected. There is no MMLS entry as (*, G) flows are not
hardware-switched on the Supervisor 1 platform.
Step 6
Verify that interface GigabitEthernet3/2 is passing traffic to the receiver port.
The Layer 3 interface is sending traffic to the receiver as it should.
Step 7
Reset module 3
Step 8
Once module 3 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
The mroute and MMLS entries are the same for all ten groups after module 3 comes back online and the
receiver is getting traffic again.
Step 9
Verify that interface GigabitEthernet3/2 is again passing traffic.
The Layer 3 interface is again transmitting traffic to the receiver.
Step 10
Display the log for error messages.
Step 11
Verify that there were no significant impacts on the CPU or memory of the devices under test.
Expected Results
•
We expect that the mroute and MMLS entries will be restored after the reset of the GE module with
the Layer 3 interface on it.
•
We expect that the Layer 3 interface will again send traffic to the receiver when the module comes
back online.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 70
GEM Failover—Supervisor 11 with Directly Connected Layer 3 Interface Test Results
Test
Result
GEM Failover—Supervisor 11 with Directly Connected Layer 3
Interface
Pass
Cisco IOS Release 12.1(13)E13
380
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
GEM Failover—Supervisor 22 as First-Hop Router
This test verified multicast functionality during Gigabit Ethernet (GE) module failover at the first-hop
router. There are four Gigabit Ethernet modules in SH1-110, which is the first-hop router for groups
239.100.3.[1-10]. All of these were reset with traffic passing through them. Traffic resumed through
these modules and mrouting and MMLS states were consistent with what was expected.
Goals:
•
Verify that the impact on traffic due to a GE module reset is minimal.
•
Verify that any impact to mrouting and MMLS states are consistent with what it expected.
Primary Devices Used:
•
SH1-110: Sup22; first-hop router for groups 239.255.3.[1-10]
Primary IXIA Ports Used:
•
N/A
Test Procedure
The procedure used to perform the GEM Failover—Supervisor 22 as First-Hop Router test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-110 is the first-hop router for groups 239.100.3.[1-10].
Since SH1-110 is the first-hop router for the ten test groups, it should have an (S, G) for each group.
Each (S, G) should have the F-flag set, as it will be registered with the RP. Each (S, G) should also have
the T-flag set as it is using the Shortest Path Tree (SPT) from the source to the RP. The outgoing
interfaces of each (S, G) should have the H-flag set, as traffic is hardware-switched on the Supervisor 2
platform.
For each of the ten groups: There is an (S, G) entry with the F- and T-flags set and each outgoing interface
in the (S, G) has the H-flag set. The information in the MMLS entries is consistent with the information
in the respective mroute entry.
Step 5
Show which modules are used by which etherchannels on SH1-110.
Traffic is coming into the first-hop router, SH1-110, on portchannel 20 and being sent to the PIM-RP on
portchannel 171. Portchannel 20 has four interfaces, two from module 3 and two from module 4. Both
modules 3 and 4 are WS-X6816-GBIC modules. Portchannel 171 also has four interfaces, evenly split
between modules 3 and 4.
Step 6
Verify that some multicast traffic is passing through the interfaces of each of these modules.
Packets are coming in each of the interfaces on portchannel 20 and going out each of the interfaces in
portchannel 171.
Step 7
Reset module 3 on SH1-110.
Step 8
Once module 3 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
Following the reset of module 3, part of portchannel 171, the mroute and MMLS entries are correctly as
they were before.
Step 9
Verify that the interfaces on module 3 are again passing traffic.
Cisco IOS Release 12.1(13)E13
381
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
The two interfaces in module 3 of portchannel 171 are again forwarding traffic.
Step 10
Reset module 4 on SH1-110.
Step 11
Once module 4 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
Following the reset of module 4, part of portchannel 171, the mroute and MMLS entries are correctly as
they were before.
Step 12
Verify that the interfaces on module 4 are again passing traffic.
The two interfaces in module 4 of portchannel 171 are again forwarding traffic.
Step 13
Reset module 7 on SH1-110.
Step 14
Once module 7 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
Following the reset of module 7, part of portchannel 20, the mroute and MMLS entries are correctly as
they were before.
Step 15
Verify that the interfaces on module 7 are again passing traffic.
The two interfaces in module 7 of portchannel 20 are again receiving traffic.
Step 16
Reset module 8 on SH1-110.
Step 17
Once module 8 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
Following the reset of module 8, part of portchannel 20, the mroute and MMLS entries are correctly as
they were before.
Step 18
Verify that the interfaces on module 8 are again passing traffic.
Step 19
Display the log for error messages.
Step 20
Verify that there were no significant impacts on the CPU or memory of the devices under test.
Expected Results
•
We expect the mroute and MMLS entries to be correct on SH1-110 after each module reset.
•
We expect that all the proper interfaces should again pass traffic following each module reset.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 71
GEM Failover—Supervisor 22 as First-Hop Router Test Results
Test
Result
GEM Failover—Supervisor 22 as First-Hop Router
Pass
GEM Failover—Supervisor 22 as Last-Hop Router
This test verified multicast functionality during Gigabit Ethernet (GE) module failover at the first-hop
router. There are two Gigabit Ethernet modules in SH1-102, which is the last-hop router for groups
239.100.[1-3].[1-10]. Both of these were reset with traffic passing through them. Traffic resumed
through these modules and mrouting and MMLS states were consistent with what was expected.
Cisco IOS Release 12.1(13)E13
382
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Goals:
•
Verify that the impact on traffic due to a GE module reset is minimal.
•
Verify that any impact to mrouting and MMLS states are consistent with what it expected.
Primary Devices Used:
•
SH1-102: Sup22; first-hop router for groups 239.255.[1-3].[1-10]
Primary IXIA Ports Used:
•
N/A
Test Procedure
The procedure used to perform the GEM Failover—Supervisor 22 as Last-Hop Router test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-102 is the last-hop router for groups 239.100.[1-3].[1-10].
For each group with SH1-102 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102. For
each group, the Incoming Interface should be portchannel 115 (from SH1-100, the primary PIM-RP).
For groups 239.100.1.x, the Outgoing Interface List (OIL) should contain a single interface: VLAN 41.
For groups 239.100.2.x, the Outgoing Interface List (OIL) should contain a single interface: VLAN 43.
For groups 239.100.3.x, the Outgoing Interface List (OIL) should contain two interfaces: VLAN 43 and
FastEthernet4/5.
This should have an H-flag next to it, indicating that it is being Hardware-switched. The MMLS entries
for each group should be consistent with the mroute entries, containing the same Incoming Interface and
OIL.
Step 5
Show which modules are used by which etherchannels on SH1-102.
Step 6
Verify that some multicast traffic is passing through the interfaces of each of these modules.
Step 7
Reset module 3 on SH1-102.
Step 8
Once module 3 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
For each group with SH1-102 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102. For
each group, the Incoming Interface should be portchannel 115 (from SH1-100, the primary PIM-RP).
For groups 239.100.1.x, the Outgoing Interface List (OIL) should contain a single interface: VLAN 41.
For groups 239.100.2.x, the Outgoing Interface List (OIL) should contain a single interface: VLAN 43.
For groups 239.100.3.x, the Outgoing Interface List (OIL) should contain two interfaces: VLAN 43 and
FastEthernet4/5.
Cisco IOS Release 12.1(13)E13
383
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
This should have an H-flag next to it, indicating that it is being Hardware-switched. The MMLS entries
for each group should be consistent with the mroute entries, containing the same Incoming Interface and
OIL.
Step 9
Verify that the interfaces on module 3 are again passing traffic.
Step 10
Reset module 7 on SH1-102.
Step 11
Once module 7 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
For each group with SH1-102 being the last-hop router, verify a (*, G) entry in the mroute table. There
is no (S, G) entry because the SPT threshold is configured to infinity, preventing the creation of an (S,
G) entry. Also, verify that the correct flags are set in the (*, G) entry: an S-flag because the traffic is
forwarded using Sparse-mode, and a C-flag because the receiver is directly connected to SH1-102. For
each group, the Incoming Interface should be portchannel 115 (from SH1-100, the primary PIM-RP).
For groups 239.100.1.x, the Outgoing Interface List (OIL) should contain a single interface: VLAN 41.
For groups 239.100.2.x, the Outgoing Interface List (OIL) should contain a single interface: VLAN 43.
For groups 239.100.3.x, the Outgoing Interface List (OIL) should contain two interfaces: VLAN 43 and
FastEthernet4/5.
Step 12
Verify that the interfaces on module 7 are again passing traffic.This should have an H-flag next to it,
indicating that it is being Hardware-switched. The MMLS entries for each group should be consistent
with the mroute entries, containing the same Incoming Interface and OIL.
Step 13
Display the log for error messages.
Step 14
Verify that there were no significant impacts on the CPU or memory of the devices under test.
Expected Results
•
We expect traffic to resume correctly when reset module comes back online.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 72
GEM Failover—Supervisor 22 as Last-Hop Router Test Results
Test
Result
GEM Failover—Supervisor 22 as Last-Hop Router
Pass
GEM Failover—Supervisor 22 as Static RP
This test verified multicast functionality during Gigabit Ethernet (GE) module failover on a static
PIM-RP. There are four Gigabit Ethernet modules in SH1-104, which is the static RP for groups
239.255.[50-51].[1-10]. Two of these were reset with traffic passing through them.Traffic resumed
through these modules and mrouting and MMLS states were consistent with what was expected.
Goals:
•
Verify that the impact on traffic due to a GE module reset is minimal.
•
Verify that any impact to mrouting and MMLS states are consistent with what it expected.
Cisco IOS Release 12.1(13)E13
384
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Primary Devices Used:
•
SH1-104: Sup22; static PIM-RP for groups 239.255.[50-51].[1-10]
Primary IXIA Ports Used:
•
N/A
Test Procedure
The procedure used to perform the GEM Failover—Supervisor 22 as Static RP test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-104 is the static RP for groups 239.255.[50-51].[1-10].
SH1-108 shows the RP for the twenty groups 239.255.[50-51].[1-10] to be the device with IP address
172.31.0.104. This is an anycast address shared by SH1-103 and SH1-104. SH1-108 shows the RPF
interface for the anycast address 172.31.0.104 to be portchannel 169, which is connected to SH1-104.
So SH1-104 is the primary PIM-RP for the twenty test groups. Like SH1-108, SH1-110 shows the RP
for the twenty groups to be the device with the IP address 172.31.0.104. The RPF interface for the
anycast address 172.31.0.104 is portchannel 171, which is directly connected to SH1-104. So SH1-110
also sees SH1-104 as the primary PIM-RP for the twenty test groups.
Step 5
Verify that SH1-104 has the correct mroute and MMLS entries for the groups 239.255.[50-51].[1-10].
As the primary PIM-RP for the twenty test groups, SH1-104 should have an (S, G) entry for each of the
groups. Each (S, G) should have the T-flag set to indicate the use of the Shortest Path Tree (SPT) and the
A-flag set so that the (S, G) is Advertised to the MSDP peer with SA messages. Each outgoing interface
of the (S, G) entry should have the H-flag set, as all traffic on the Supervisor 2 should be
hardware-switched. The incoming and outgoing interfaces in the (S, G) of the MMLS entry should be
consistent with the respective entry in the mrouting table.
SH1-104 does have an (S, G) for each entry with the T-flag set, and the H-flag set on each outgoing
interface of the (S, G)’s. The MMLS entries are consistent with their respective mroute entries.
The A-flag is not set consistently on each (S,G), though. This is due to DDTS CSCea21798. Because of
OSPF equal-cost paths from the source to each Anycast RP, SH1-103 and SH1-104, some sources are
registered with SH1-103 and some with SH1-104. SH1-104 is always used, though, to forward the
multicast traffic, as it is the elected PIM-RP. So, for some groups, SH1-104 will not advertise certain
(S, G)’s in SA messages.
Step 6
Show which modules are used by which etherchannels on SH1-104.
Only portchannels 71 and 69 are being used to receive/transmit traffic for these twenty test groups.
Portchannel 69 consists of four interfaces from module 8, a WS-X6515-GBIC module. Portchannel 71
consists of two interfaces from module 8 and two from module 3, a WS-X6816-GBIC module.
Step 7
Verify that some multicast traffic is passing through the interfaces of each of these modules.
Each interface of the two portchannels used is both sending and receiving traffic.
Step 8
Reset module 3 on SH1-104.
Step 9
Once module 3 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
The mroute and MMLS entries are correct for each of the twenty test groups following the reset of
module 3. For groups 239.255.50.[1-10], the outgoing interface will show portchannel 70 until it is
deleted. Portchannel 70 was used when module 3 was reset.
Cisco IOS Release 12.1(13)E13
385
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 10
Verify that the interfaces on module 3 are again passing traffic.
Again, both interfaces of the reset module are forwarding and receiving traffic.
Step 11
Reset module 8 on SH1-104.
Step 12
Once module 8 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
The mroute and MMLS entries are correct for each of the twenty test groups following the reset of
module 8. For groups 239.255.50.[1-10], the outgoing interface will show portchannel 70 until it is
deleted. Portchannel 70 was used when module 3 was reset.
The A-flag is not set on any of the twenty groups at this point. This is because all groups had been
registered with SH1-103 when it became the primary PIM-RP.
Step 13
Verify that the interfaces on module 8 are again passing traffic.
Again, all six interfaces of the reset module are forwarding and receiving traffic.
Step 14
Display the log for error messages.
Step 15
Verify that there were no significant impacts on the CPU or memory of the devices under test.
Expected Results
•
We expect the mroute and MMLS entries to be correct on SH1-104 after each module reset.
•
We expect that all the proper interfaces should again pass traffic following each module reset.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 73
GEM Failover—Supervisor 22 as Static RP Test Results
Test
Result
GEM Failover—Supervisor 22 as Static RP
Pass
GEM Failover—Supervisor 22 as Auto RP
This test verified multicast functionality during Gigabit Ethernet (GE) module failover on an elected RP.
There are two Gigabit Ethernet modules in SH1-97, which is the elected RP for groups 239.98.50.[1-10].
One of these was reset with traffic passing through them. The standby and active supervisors were reset,
also, as their uplink interfaces were used in the Etherchannels. Traffic resumed through these modules
and mrouting and MMLS states were consistent with what was expected.
Goals:
•
Verify that the impact on traffic due to a GE module reset is minimal.
•
Verify that any impact to mrouting and MMLS states are consistent with what it expected.
Primary Devices Used:
•
SH1-97: Sup22; elected RP for groups 239.98.50.[1-10]
Primary IXIA Ports Used:
N/A
Cisco IOS Release 12.1(13)E13
386
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Test Procedure
The procedure used to perform the GEM Failover—Supervisor 22 as Auto RP test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-97 is the elected RP for groups 239.98.50.[1-10].
SH1-99 shows that groups 239.98.0.0/16 use the RP with IP address 172.31.0.98. This is an anycast
address shared by SH1-97 and SH1-98.
SH1-99 knows the IP address for 172.31.0.98, the anycast address for groups 239.98.0.0/16, from
portchannel 12, which is directly connected to SH1-98. Therefore, SH1-98 is the elected RP for groups
239.98.0.0/16.
Step 5
Verify that SH1-97 has the correct mroute and MMLS entries for groups 239.98.50.[1-10].
As the RP for the ten test groups, SH1-97 should have an (S, G) mroute entry for each of the ten groups.
It does, and also has the T-flag and the A-flag set. The T-flag indicates that the Shortest Path Tree (SPT)
is being used to the source. The A-flag means that SH1-97 will advertise that (S, G) to its MSDP peer
with the next SA message. The H-flag is set on all outgoing interfaces in the (S,G), because the traffic
is hardware-switched.
There is an MMLS entry for each (S, G) in the mrouting table, and the interface information in the two
is consistent.
Step 6
Show which modules are used by which etherchannels on SH1-97.
Portchannel 13 is the only outgoing interface for the (S, G) flows listed above. It consists of an interface
from each of the two supervisors, and two interfaces from module 3, a WS-X6816-GBIC.
Step 7
Verify that some multicast traffic is passing through the interfaces of each of these modules on SH1-97.
Some multicast traffic is being sent out each of the four interfaces in portchannel 13.
Step 8
Reset module 3 on SH1-97.
Step 9
Once module 3 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
When module 3 came back online, the mroute and MMLS states were exactly as they were before.
Step 10
Verify that the interfaces on module 3 are again passing traffic.
The interfaces in module 3 are again sending out traffic.
Step 11
Reset the standby supervisor on SH1-97.
Step 12
Once the standby supervisor comes back online, verify that the correct mrouting and MMLS entries are
re-installed.
When the standby supervisor came back online, the mroute and MMLS states were exactly as they were
before.
Step 13
Verify that the interfaces the supervisors of SH1-97 are still passing traffic.
The interfaces in both the standby and the active supervisor are again sending out traffic.
Step 14
Reset the active supervisor on SH1-97.
Step 15
Once SH1-97 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
When SH1-97 came back online, the mroute and MMLS states were exactly as they were before.
Step 16
Verify that the interfaces of the supervisors of SH1-97 are still passing traffic.
Cisco IOS Release 12.1(13)E13
387
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
The interfaces in both the standby and active supervisors are again sending out traffic.
Step 17
Display the log for error messages.
Step 18
Verify that there were no significant impacts on the CPU or memory of the devices under test.
Expected Results
•
We expect the mroute and MMLS entries to be correct on SH1-97 after each module reset.
•
We expect that all the proper interfaces should again pass traffic following each module reset.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 74
GEM Failover—Supervisor 22 as Auto RP Test Results
Test
Result
GEM Failover—Supervisor 22 as Auto RP
Pass
GEM Failover—Supervisor 22 with Directly Connected Layer 3 Interface
This test determined the effect of resetting a Gigabit Ethernet (GE) module (that has a directly connected
Layer 3 interface. Modules 4 and 8 of SH1-110, and modules 3 and 7 of SH1-109 each have a directly
connected Layer 3 interface. These interfaces are connected to receivers for various multicast groups.
These modules were reset. Traffic resumed through these modules and mrouting and MMLS states were
consistent with what was expected. after each module came back online.
Goals:
•
Verify that the impact on traffic to a Layer 3 receiver due to a GE module reset is minimal.
•
Verify that any impact to mrouting and MMLS states are consistent with what it expected.
Primary Devices Used:
•
SH1-109: Sup22; has directly connected Layer 3 receiver on module 3 for groups 239.255.3.[1-10]
•
SH1-110: Sup22; has directly connected Layer 3 receiver on module 4 for groups 239.255.2.[1-10]
on a secondary subnetSH1-109: Sup22; has directly connected Layer 3 receiver on module 7 for
groups 239.255.1.[1-10]
•
SH1-110: Sup22; has directly connected Layer 3 receiver on module 8 for groups 239.255.1.[1-10]
Primary IXIA Ports Used:
•
N/A
Test Procedure
The procedure used to perform the GEM Failover—Supervisor 22 with Directly Connected Layer 3
Interface test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Cisco IOS Release 12.1(13)E13
388
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that interface GigabitEthernet3/16 on SH1-109 is a Layer 3 interface.
The interface has an IP address on a primary network.
Step 5
Verify that SH1-109 has the correct mroute and MMLS entries for groups 239.100.3.[1-10].
SH1-109 has the correct mroute entries for all ten groups. The interface GigabitEthernet3/16 is listed as
the outgoing interface for all ten groups. The S- and C-flags are set on the (*, G) entry, but it is the (S,
G) entry that is being used to switch the traffic, as is indicated by the T-flag being set. The H-flag is set
for each outgoing interface in the (S, G) mroute entries, as the traffic is being Hardware switched. The
(S, G) is installed because we have an RP-on-a-stick scenario here.
The MMLS entries are consistent with the mroute entries, with the (S, G) having the same incoming and
outgoing interfaces as the respective mroute entry.
Step 6
Verify that interface GigabitEthernet3/16 is passing traffic to the receiver port.
Step 7
Reset module 3.
Step 8
Once module 3 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
The mroutes and MMLS entries are correct after the GE module reset.
Step 9
Verify that interface GigabitEthernet3/16 is again passing traffic. Verify that interface
GigabitEthernet7/16 on SH1-109 is a Layer 3 interface.
The Layer 3 interface is again passing traffic to the receiver. GigabitEthernet7/16 on SH1-109 is a Layer
3 interface.
Step 10
Verify that SH1-109 has the correct mroute and MMLS entries for groups 239.100.1.[1-10].
SH1-109 has the correct mroute entries for all ten groups. The interface GigabitEthernet7/16 is listed as
the outgoing interface for all ten groups. The S- and C-flags are set on the (*, G) entry, because the traffic
is being forwarded in Sparse mode and the receiver is directly Connected. The H-flag is set for each
outgoing interface in the (*, G) mroute entries, as the traffic is being Hardware switched.
The MMLS entries are consistent with the mroute entries, with the (*, G) having the same incoming and
outgoing interfaces as the respective mroute entry.
Step 11
Verify that interface GigabitEthernet7/16 is passing traffic to the receiver port.
Step 12
Reset module 7.
Step 13
Once module 7 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
The mroutes and MMLS entries are correct after the GE module reset.
Step 14
Verify that interface GigabitEthernet7/16 of SH1-109 is again passing traffic.
The Layer 3 interface is again passing traffic to the receiver.
Verify that interfaces GigabitEthernet4/16 and GigabitEthernet8/16 on SH1-110 are Layer 3 interfaces.
The interfaces on SH1-110 are Layer 3 interfaces. Interface Gigabit Ethernet 4/16 has a secondary IP
address, the subnet of which the receiver is on.
Step 15
Verify that SH1-110 has the correct mroute and MMLS entries for groups 239.100.2.[1-10].
SH1-110 has the correct mroute entries for all ten groups. The incoming interface is portchannel 171.
The interface GigabitEthernet4/16 is listed as the outgoing interface for all ten groups. The S- and
C-flags are set on the (*, G) entry. The H-flag is set for each outgoing interface in the (*, G) mroute
entries, as the traffic is being Hardware switched.
Cisco IOS Release 12.1(13)E13
389
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
The MMLS entries are consistent with the mroute entries, with the (*, G) having the same incoming and
outgoing interfaces as the respective mroute entry.
Step 16
Verify that interface GigabitEthernet4/16 is passing traffic to the receiver port.
Step 17
Reset module 4 on SH1-110.
Step 18
Once module 4 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
The mroutes and MMLS entries are correct after the GE module reset.
Step 19
Verify that interface GigabitEthernet4/16 is again passing traffic.
The Layer 3 interface is again passing traffic to the receiver.
Step 20
Verify that SH1-110 has the correct mroute and MMLS entries for groups 239.100.1.[1-10].
SH1-110 has the correct mroute entries for all ten groups. The interface GigabitEthernet8/16 is listed as
the outgoing interface for all ten groups. The S- and C-flags are set on the (*, G) entry. The H-flag is set
for each outgoing interface in the (*, G) mroute entries, as the traffic is being Hardware switched.
The MMLS entries are consistent with the mroute entries, with the (*, G) having the same incoming and
outgoing interfaces as the respective mroute entry.
Step 21
Verify that interface GigabitEthernet8/16 is passing traffic to the receiver port.
The Layer 3 interface is passing traffic to the receiver.
Step 22
Reset module 8.
Step 23
Once module 8 comes back online, verify that the correct mrouting and MMLS entries are re-installed.
The mroutes and MMLS entries are correct after the GE module reset.
SH1-110 has the correct mroute entries for all ten groups. The incoming interface is portchannel 171.
The interface GigabitEthernet4/16 is listed as the outgoing interface for all ten groups. The S- and
C-flags are set on the (*, G) entry. The H-flag is set for each outgoing interface in the (*, G) mroute
entries, as the traffic is being Hardware switched.
The MMLS entries are consistent with the mroute entries, with the (*, G) having the same incoming and
outgoing interfaces as the respective mroute entry.
Step 24
Verify that interface GigabitEthernet8/16 is again passing traffic.
The Layer 3 interface is again passing traffic to the receiver.
Step 25
Display the log for error messages.
Step 26
Verify that there were no significant impacts on the CPU or memory of the devices under test.
Expected Results
•
We expect that the mroute and MMLS entries will be restored after the reset of the GE module with
the Layer 3 interface on it.
•
We expect that the Layer 3 interface will again send traffic to the receiver when the module comes
back online.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco IOS Release 12.1(13)E13
390
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Results
Table 75
GEM Failover—Supervisor 22 with Directly Connected Layer 3 Interface Test Results
Test
Result
GEM Failover—Supervisor 22 with Directly Connected Layer 3 Interface
Pass
Protocol Independent Module-Designated Router Failover—Supervisor 11
This test verified multicast functionality during designated router (PIM-DR) failover on a Supervisor 11
platform. Traffic for ten multicast groups is routed through the PIM-DR, which is SH1-106 (Sup11). The
SH1-105 backup took over the forwarding role when SH1-106 is failed.
Goals:
•
Verify that the proper mroute and MMLS entries are installed on the PIM-DR (SH1-106) before the
failover, and after it is recovered.
•
Verify that the proper mroute and MMLS entries are installed on the backup PIM-DR (SH1-105)
when SH1-106 is reloaded.
•
Verify that the impact to the traffic from a PIM-DR failover is acceptable.
Primary Devices Used:
•
SH1-106: Sup11; PIM-DR for groups 239.255.3.[1-10]
•
SH1-105: Sup11; backup PIM-DR for groups 239.255.3.[1-10]
Primary IXIA Ports Used:
•
13/2, 2/6
Test Procedure
The procedure used to perform the Protocol Independent Module-Designated Router
Failover—Supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-105 and SH1-106 are PIM neighbors and that SH1-106 is the PIM-DR.
SH1-105 and SH1-106 maintain a PIM neighbor relationship across VLANs 40 through 50. For each of
these eleven VLANs, SH1-105 indicates that its PIM neighbor, SH1-106, is the Designated Router (DR).
Step 5
Verify that the PIM-DR, SH1-106, has the correct mroute and MMLS entries for the groups it is the DR
for.
As the last-hop router for these ten groups, SH1-106 should have a (*, G) entry for each group. This is
due to the SPT threshold being configured as infinity. Each (*, G) entry correctly has the S-flag and
C-flag set. The S-flag indicates that the flow is maintained via Sparse mode. The C-flag indicates that
the receiver is directly Connected. There is no hardware-switching of (*, G) flows on the Supervisor 1
platform, hence the absence of the H-flag on the outgoing interface and any MMLS entries.
Incoming interface: portchannel 167, RPF nbr 172.31.1.97
Cisco IOS Release 12.1(13)E13
391
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Outgoing interface list: VLAN 41
Step 6
Begin sending a fixed stream of traffic through the PIM-DR SH1-106
Step 7
Force the primary supervisor on PIM-DR SH1-106 to switch to the backup supervisor.
This causes the primary PIM-RP to switch from SH1-106 to SH1-105.
Step 8
Verify that SH1-105 has assumed the role of PIM-DR and has the proper mroute and MMLS entries.
When SH1-105 assumes the forwarding role for the ten groups from SH1-106, it should also take on the
same mroute and MMLS characteristics that SH1-106 had for each of the groups. This includes the (*,
G) entry with its S- and C-flags and the absence of any MMLS entry.
Incoming interface: portchannel 166, RPF nbr 172.31.1.93
Outgoing interface list: VLAN 41
Step 9
Once SH1-106 comes back online, verify that it resumes its role as PIM-DR and recreates proper mroute
and MMLS entries.
The neighbor relationships between SH1-105 and SH1-106 have been reestablished and, again, SH1-105
sees SH1-106 as the PIM-DR for the eleven VLANs.
Having resumed the forwarding role for traffic to the ten test groups, SH1-106 again installs the (*, G)
entries with the correct flags. Again, it is not hardware-switching this traffic and has no MMLS entries.
Incoming interface: portchannel 167, RPF nbr 172.31.1.97
Outgoing interface list: VLAN 41
Step 10
Determine the amount of traffic that was lost during the PIM-DR failover above.
Step 11
Repeat the PIM-DR failover sequence four more times, each time determining the amount of traffic loss.
Step 12
Determine the average down time over the five tests.
Step 13
Display the log for error messages.
Step 14
Show the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect the primary PIM-DR (SH1-106) to have the correct mroute and MMLS entries before the
reload and after recovery.
•
We expect the backup PIM-DR (SH1-105) to create the correct mroute and MMLS entries after the
reload of SH1-106 and assume the forwarding role for all test groups.
•
We expect any impact on traffic during the failover process to be minimal and acceptable.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 76
Protocol Independent Module-Designated Router Failover—Supervisor 11 Test Results
Test
Result
Protocol Independent Module-Designated Router Failover—Supervisor 11 Pass
Cisco IOS Release 12.1(13)E13
392
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Protocol Independent Module-Designated Router Failover—Supervisor 22
This test verified multicast functionality during designated router (PIM-DR) failover on a Supervisor 22
platform. Traffic for ten multicast groups was routed through the PIM-DR, which is SH1-110. The
SH1-109 backup took over the forwarding role when SH1-110 is failed.
Goals:
•
Verify that the proper mroute and MMLS entries are installed on the PIM-DR (SH1-106) before the
failover, and after it is recovered.
•
Verify that the proper mroute and MMLS entries are installed on the backup PIM-DR (SH1-105)
when SH1-106 is reloaded.
•
Verify that the impact to the traffic from a PIM-DR failover is acceptable.
Primary Devices Used:
•
SH1-110: Sup22; LHR and PIM-DR for groups 239.100.[1-2].[1-10]
•
SH1-109: Sup22; backup PIM-DR for groups 239.100.[1-2].[1-10] after failover
Primary IXIA Ports Used:
•
4/2, 3/3, 11/1, 12/2, 10/1, 10/2
Test Procedure
The procedure used to perform the protocol independent module-designated router
failover—supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-109 and SH1-110 are PIM neighbors and that SH1-110 is the PIM-DR.
SH1-109 and SH1-110 maintain a PIM neighbor relationship across VLANs 10 through 20 and
portchannel 1. For each of these eleven VLANs and the etherchannel, SH1-109 indicates that its PIM
neighbor, SH1-110, is the Designated Router (DR).
Step 5
Verify that the PIM-DR, SH1-110, has the correct mroute and MMLS entries for the groups it is the DR
for.
As the last-hop router for these twenty groups, SH1-110 should have a (*, G) entry for each group. This
is due to the SPT threshold being configured as infinity. Each (*, G) entry correctly has the S-flag and
C-flag set. The S-flag indicates that the flow is maintained via Sparse mode. The C-flag indicates that
the receiver is directly Connected. The H-flag, correctly set on each of the outgoing interfaces, indicates
that the traffic out that interface is being hardware-switched. This is confirmed by the presence of an
MMLS entry for each group. The Outgoing interface list for the 239.100.1.x group contains VLAN 11
(for the receiver attached via the Dista-2 switch) and GigabitEthernet8/16 (for the directly attached
receiver). The Outgoing interface list for 239.100.2.x group contains VLAN 16 and
GigabitEthernet4/16.
Step 6
Begin sending a fixed stream of traffic through the PIM-DR SH1-110
Step 7
Force the primary supervisor on PIM-DR SH1-110 to switch to the backup supervisor.
This causes the primary PIM-RP to switch from SH1-110 to SH1-109.
Cisco IOS Release 12.1(13)E13
393
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 8
Verify that SH1-109 has assumed the role of PIM-DR and has the proper mroute and MMLS entries.
When SH1-109 assumes the forwarding role for the twenty groups from SH1-110, it should also take on
the same mroute and MMLS characteristics that SH1-110 had for each of the groups. This includes the
(*, G) entry with its S- and C-flags set. The Outgoing interface list for the 239.100.1.x group contains
VLAN 11 and GigabitEthernet7/16. The Outgoing interface list for 239.100.2.x group contains only
VLAN 16 since there are no directly attached receivers.
Step 9
Once SH1-110 comes back online, verify that it resumes its role as PIM-DR and recreates proper mroute
and MMLS entries.
The neighbor relationships between SH1-109 and SH1-110 have been reestablished and, again, SH1-109
sees SH1-110 as the PIM-DR for the eleven VLANs and the etherchannel. Having resumed the
forwarding role for traffic to the ten test groups, SH1-110 again installs the (*, G) entries with the correct
flags and the correct MMLS entry.
Step 10
Determine the amount of traffic that was lost during the PIM-DR failover above.
Step 11
Repeat the PIM-DR failover sequence four more times, each time determining the amount of traffic loss.
Step 12
Determine the average amount of traffic loss the IXIA receiver over the five test runs.
Step 13
Display the log for error messages.
Step 14
Show the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect the primary PIM-DR (SH1-110) to have the correct mroute and MMLS entries before the
reload and after recovery.
•
We expect the backup PIM-DR (SH1-109) to create the correct mroute and MMLS entries after the
reload of SH1-110 and assume the forwarding role for all test groups.
•
We expect any impact on traffic during the failover process to be minimal and acceptable.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 77
Protocol Independent Module-Designated Router Failover—Supervisor 22 Test Results
Test
Result
Protocol Independent Module-Designated Router Failover—Supervisor 22 Pass
Auto-RP Failover—RP Impact
This test verified multicast functionality on the elected PIM-RP during a PIM-RP failover on a
Supervisor 22 platform. SH1-100 was the elected PIM-RP for groups thirty multicast test groups:
239.100.[1-3].[1-10]. SH1-100 was reloaded, verifying the correct failover of mrouting state to SH1-99
and the reversion of state back to SH1-100, after it is back online.
Goals:
•
Verify that the elected RP has the correct mroute entries, flags and MMLS entries for all thirty test
groups.
Cisco IOS Release 12.1(13)E13
394
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
•
Verify that each of the thirty test groups fails over to the backup PIM-RP after the failure of the
primary, with correct mroute and MMLS state.
•
Verify that all thirty groups build correct state again on the original PIM-RP when it is back online.
Primary Devices Used:
•
SH1-100: Sup22; elected RP for groups 239.255.[1-3].[1-10]
Primary IXIA Ports Used:
•
12/1, 2/1, 1/2, 2/7, 2/4, 1/1, 2/6, 4/2, 4/6, 3/3, 5/3, 8/1, 7/2, 7/1, 9/1, 9/2, 10/1, 10/2, 13/2, 11/1, 12/2
Test Procedure
The procedure used to perform the Auto-RP Failover—RP Impact test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the elected PIM-RP, SH1-100, has the proper mroute and MMLS entries, with the correct
flags for all thirty groups.
The elected PIM-RP, SH1-100, should have an (S, G) entry for all thirty groups, and it does. For each
(S, G) entry, it should have the T-flag and the A-flag set. The T-flag indicated that the SPT-bit is set and
the (S, G) entry is used. The A-flag tells SH1-100 to advertise this particular (S, G) entry to the MSDP
peer (SH1-99) with the SA messages. The T-flag is correctly set for all groups.
The A-flag is not consistently set for all groups. This is due to the DDTS CSCea21798. The first-hop
routers are registering some of the sources with SH1-100 and others with SH1-99, due to unicast
load-balancing over equal-cost OSPF links. So the A-flag is set for some groups on SH1-100 and for
others on SH1-99. SH1-100 is always used to send multicast traffic on the RP, though, due to the RPF
interface from the first-hop routers being to SH1-100. This problem does not appear to result in any
packet loss.
Also, due to this DDTS, the M-flag will be set on some (S, G) entries. The M-flag indicates that the group
was learned via the MSDP peer.
For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating hardware-switching.
There is always consistency between the mroute entries and the MMLS entries for each group.
Step 5
Reload SH1-100.
A spurious memory access (related to BGP) occurred during the shutdown of SH1-100 and CSCed73091
was opened.
Step 6
Verify that the new primary PIM-RP, SH1-99, has the correct mroute and MMLS entries, with the correct
flags set, for all thirty groups while SH1-100 is offline.
The new PIM-RP, SH1-99, should have an (S, G) entry for all thirty groups, and it does. It should also
have the T-flag and the A-flag set. The T-flag is correctly set for all groups while, as was seen above, the
A-flag is not consistently set for all groups. Also, due to this DDTS, the M-flag will be set on some (S,
G) entries. For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating
hardware-switching. There is always consistency between the mroute entries and the MMLS entries for
each group.
Step 7
Once SH1-100 comes back online, verify that it is again the RP for all thirty groups and that its mrouting
table and MMLS entries are correct.
Cisco IOS Release 12.1(13)E13
395
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Being the PIM-RP again, SH1-100 should have an (S, G) entry for all thirty groups, and it does. It should
also have the T-flag and the A-flag set. The T-flag is correctly set for all groups while, as was seen above,
the A-flag is not consistently set for all groups. Also, due to this DDTS, the M-flag will be set on some
(S, G) entries. For each outgoing interface listed in the (S, G) entry, the H-flag is set, indicating
hardware-switching. There is always consistency between the mroute entries and the MMLS entries for
each group.
Step 8
Display the log for error messages.
Step 9
Show the results of CPU and memory monitoring of the devices in the SH1 network.
Expected Results
•
We expect prior to the failover, SH1-100, the primary PIM-RP, to have all the correct mroute entries
and flags for the thirty groups for which it is the RP.
•
We expect SH1-100 should have the correct MMLS entries, consistent with the mroute entries, and
be hardware-switching traffic.
•
We expect SH1-99 to take over the role of primary PIM-RP when SH1-100 is reloaded, and correctly
populate its mroute and MMLS entries.
•
We expect SH1-100 to resume the role of primary PIM-RP when it is back online and capable of
forwarding traffic.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 78
Auto-RP Failover—RP Impact Test Results
Test
Result
Auto-RP Failover—RP Impact
Pass, exception CSCea21798, CSCed73091
Cisco Express Forwarding
Cisco Express Forwarding (CEF) evolved to best accommodate the changing network dynamics and
traffic characteristics resulting from increasing numbers of short period flows typically associated with
web-based applications and interactive type sessions. Existing Layer 3 switching paradigms use a
route-cache model to maintain a fast lookup table for destination network prefixes. The route-cache
entries are traffic-driven in that the first packet to a new destination was routed via routing table
information and, as part of that forwarding operation, a route-cache entry for that destination was then
added. This behavior allows subsequent packet flows to that same destination network to be switched
based on an efficient route cache match. These entries are periodically aged out to keep the route cache
current and can be immediately invalidated if the network topology changes. This "demand-caching"
scheme—maintaining a very fast access subset of the routing topology information—is optimized for
scenarios whereby the majority of traffic flows are associated with a subset of destinations. However,
given that traffic profiles at the core of the Internet (and potentially within some large enterprise
networks) are no longer resembling this model, a new switching paradigm was required that would
eliminate the increasing cache maintenance resulting from growing numbers of topologically dispersed
destinations and dynamic network changes.
Cisco IOS Release 12.1(13)E13
396
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
CEF avoids the potential overhead of continuous cache churn by instead using a Forwarding Information
Base (FIB) for the destination switching decision that mirrors the entire contents of the IP routing table;
that is, that there was a one-to-one correspondence between FIB table entries and routing table prefixes.
Therefore, there was no need to maintain a route cache.
The following tests were performed:
•
CEF Packet Switching, page 397
•
CEF Route Entries on DFC, page 398
•
CEF Many-to-One Distribution Load Balance, page 399
•
CEF Many-to-Many Distribution with Polarization Load Balance, page 402
CEF Packet Switching
This test verified that IP Unicast traffic was hardware-switched. If traffic was not hardware-switched by
the Policy Feature Card (PFC), the traffic would have been fast-switched by the MSFC.
Figure 22 shows the topology for the Cisco Express Forwarding Packet-Switching test.
Figure 22
Cisco Express Forwarding Packet-Switching Topology
A fixed number of ping packets are sent from SH1-104 to SH1-103, across SH1-99. The ping and
response totals are compared against the number of MLS CEF Layer 3 packets switched. An extended
ping of 500 packets is used to calculate the number of packets hardware-switched across the interim
switch, SH1-99. The result should be 1000 FIB switched packets on SH1-99.
Devices under test: SH1-104, SH1-99, and SH1-103.
Test Procedure
The procedure used to perform the CEF Packet Switching test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Shutdown any alternate paths that the ping packets may take through the network from SH1-104 to
SH1-103 (on SH1-104, shutdown the Po68, Po69, Po70, and Po71 interfaces). Because these interfaces
are shutdown, all traffic sent from SH1-104 to SH1-103 will be switched through SH1-99.
Step 5
If there are any background traffic streams running, stop them for this test. They may interfere with the
counter statistics observed on SH1-99.
Step 6
Show the MLS statistics for Module 3 on SH1-99. This will give a base packet count from which to work.
SH1-99 begins the test with 14,311,317,225 packets having been FIB switched.
Step 7
Clear out the MLS entries on module 3 of SH1-99 and verify that there are none.
Cisco IOS Release 12.1(13)E13
397
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
No MLS flows are registered in module 3.
Step 8
Send 500 ping packets from SH1-104 (172.31.1.38) to SH1-103 (172.31.1.34).
All 500 ping packets sent received a reply.
Step 9
Verify that the 1000 packets (500 from echo request, 500 from echo reply) have been logged in the MLS
statistics on SH1-99.
After the 500 packet ping stream was sent, SH1-99 now shows 14,311,318,225 packets having been FIB
switched. This is an increase of 1000 packets from the value seen above, before the pings were sent. The
1000-packet increment includes the 500 ping packets and the 500 ping-reply packets.
Step 10
Verify that MLS entries have been created for the unicast flows.
Module 3 of SH1-99 now has two MLS flows established. One for the ping and one for the ping-reply.
Step 11
Return the configuration of SH1-104 to default by re-enabling the portchannel interfaces (Po68 to Po71)
that were shut down in Step 4.
Step 12
Restart any traffic streams that were stopped.
Step 13
Display the log for error messages.
Step 14
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that the MLS counters on SH1-99 to increment by 1000 when 500 ping packets are sent
from SH1-104 to SH1-103, through SH1-99.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 79
CEF Packet Switching Test Results
Test
Result
CEF Packet Switching
Pass
CEF Route Entries on DFC
This test verified that correct CEF table entries were used to forward IP unicast traffic passing through
a switch on a ws-x6816 module (with DFC). Devices SH1-99, SH1-103, and SH1-104 were used for the
test. portchannel 16 is used to connect SH1-99 to SH1-103 and portchannel 17 is used to connect SH1-99
to SH1-104.
Device under test: SH1-104.
Test Procedure
The procedure used to perform the CEF Route Entries on DFC test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Cisco IOS Release 12.1(13)E13
398
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
On device SH1-104, show the routing table entries for the networks 172.31.1.32, 172.31.1.36, and
172.31.1.0. The 172.31.1.32 network is one-hop away from SH1-104. The 172.31.1.36 network is
directly connected to SH1-104. The 172.31.1.0 network is remote (more than one hop away from) to
SH1-104.
There are 5 paths to the 172.31.1.32 network. 172.31.1.36 is directly connected to SH1-104. There is
only one path to the 172.31.1.0 network.
Step 5
Confirm that there are entries in the CEF table on the PFC2 for these networks and any host within them.
Each of the five paths shown in the routing table to the 172.31.1.32 network are also in the CEF table.
Because SH1-104 is directly connected to the 172.31.1.36 network, its CEF table has entries for the
network, hosts, and the broadcast address of that network. SH1-104 has the single entry to the 172.31.1.0
network that was in its routing table.
Step 6
Show which module of SH1-104 has the DFC module.
Module 3 has the DFC daughter card.
Step 7
Verify that the same CEF table entries on the PFC are also on the DFC of Module 3.
The DFC card on module 3 has all the CEF entries that the PFC had.
Step 8
Display the log for error messages.
Step 9
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that there will be corresponding CEF table entries for each routing table entry for
networks that are a) directly connected, b) one hop away, and c) more than one hop away.
•
We expect that the entries that are on the PFC2 are also on the DFC of Module 3.
Results
Table 80
CEF Route Entries on DFC Test Results
Test
Result
CEF Route Entries on DFC
Pass
CEF Many-to-One Distribution Load Balance
These tests were performed to verify that HW shortcuts and CEF distribution functioned properly with
IP unicast traffic. Two tests were performed that monitored unicast traffic streams of "many-to-one" with
20 increment IP addresses sending traffic to a single destination IP address and "many-to-many" with
100 source and 100 destination address pairs.
Figure 23 shows the topology for the CEF many-to-one distribution: load balance test.
Cisco IOS Release 12.1(13)E13
399
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Figure 23
Note
CEF Many-to-One Distribution Load Balance Topology
Background traffic was not used in this test because it would have confused the interface traffic counters
used to gauge traffic path and delivery.
Devices under test: SH1-103, SH1-104, SH1-107, SH1-108, SH1-109, and SH1-110.
Test Procedure
The procedure used to perform the CEF Many-to-One Distribution Load Balance test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Confirm that all the portchannel interfaces involved in this test are up and that the proper interfaces are
bundled in them.
Under the Ports column the label "P" indicates that the interface is "in portchannel." Under the
portchannel column the Label "R" indicates it is a routed (L3) port channel, and the Label "U" indicates
that the portchannel is "in-use." All etherchannels are L3 and up, and all bundled interfaces are in the
parent channel.
Cisco IOS Release 12.1(13)E13
400
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Test One (Many-to-One)
Test One used traffic streams with 20 incrementing source IP addresses destined to a single IP address.
The destination IP address was 172.31.27.51. The source IP addresses increment from 172.31.16.82 to
172.31.16.101.
The traffic source port Ix8/2 connected to switch Dista-1. The destination IP address was IXIA-1 port
Ix-5/1 connected to switch Dista-2. Router SH1-108 received the traffic from Dista-1 and distributed it
into the test network. One million packets at 10,000 pps were sent. The path of the traffic for this test
was as follows:
IXIAtx -> Dista-1 -> SH1-108 -> (SH1-103 / SH1-104) -> (SH1-109 / SH1-110) -> Dista-2 -> IXIArx
Step 5
Clear the traffic counters on the test devices and begin playing the traffic stream.
Step 6
Verify that at all 1 million packets sent were received.
There was no packet loss.
Step 7
Once the traffic stream has completed, show the interface traffic counters on devices SH1-108, SH1-103,
SH1-104, SH1-109, and SH1-110. This will demonstrate that CEF load-balancing did occur along the
traffic path.
The traffic is load-balanced correctly along each level from the source to the destination.
Step 8
Begin a continuous burst traffic stream with the same characteristics of the stream used above (20 source
IP addresses to 1 destination IP address). This stream will also be sent out IXIA port 8/2 and enter
Dista-1. Traffic counters are not important for this test, that is why we are sending a continuous burst of
traffic.
Step 9
Look at the MLS entries on each router along the traffic path. There should be a total of 20 entries at
each level (i.e. 20 entries on SH1-108; 20 entries on SH1-103 and SH1-104, combined; 20 entries on
SH1-109 and SH1-110, combined). Count each entry with a destination IP address (DstIP) of
172.31.27.51.
Note
In some cases, it may be necessary to look at the MLS entries on the DFC cards of certain modules.
There are 20 MLS entries for that destination IP address on SH1-108. Between SH1-103 and SH1-104
there are 20+ MLS entries. This is because SH1-104 has duplicate entries via which a single packet has
been switched. Between SH1-109 and SH1-110 there also my be 20+ MLS entries.
Step 10
Display the log for error messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that traffic sourced from multiple IP hosts to a single IP host will use multiple paths if
they are available.
•
We expect that traffic sourced from multiple IP hosts to a single IP host will be hardware switched.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco IOS Release 12.1(13)E13
401
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Results
Table 81
CEF Many-to-One Distribution Load Balance Test Results
Test
Result
CEF Many-to-One Distribution Load Balance
Pass
CEF Many-to-Many Distribution with Polarization Load Balance
This test was performed to verify that HW shortcuts and CEF distribution functioned properly with IP
unicast traffic. This test verified unicast traffic streams of "many-to-many" with 100 source and 100
destination address pairs.
Figure 24 shows the topology for the CEF many-to-many distribution with polarization.
Figure 24
Note
CEF Many-to-Many Distribution with Polarization Load Balance Topology
Background traffic was not used in this test because it would have confused the interface traffic counters
used to gauge traffic path and delivery.
Devices under test: SH1-103, SH1-104, SH1-107, SH1-108, SH1-110
Cisco IOS Release 12.1(13)E13
402
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Test Procedure
The procedure used to perform the CEF Many-to-Many Distribution with Polarization Load Balance test
follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Confirm that all the portchannel interfaces involved in this test are up and that the proper interfaces are
bundled in them. Table 82 lists the devices and which etherchannel IDs to check:
Table 82
Device
Many-to-Many Port-Channel Interfaces Readied and Bundled
Channel ID
SH1-103 68, 69, 70, 71
SH1-104 68, 69, 70, 71
SH1-107 68, 168
SH1-108 69, 169
SH1-110 71, 171
Under the Ports column the label "P" indicates that the interface is "in portchannel." Under the
portchannel column the Label "R" indicates it is a routed (L3) port channel, and the Label "U" indicates
that the portchannel is "in-use." All etherchannels are L3 and up, and all bundled interfaces are in the
parent channel.
Test Two (Many-to-Many)
Test Two uses traffic streams with 100 incrementing source IP addresses destined to 100 incrementing
IP addresses. The source IP addresses increment from 172.31.26.102 to 172.31.26.201. The destination
IP addresses increment from 172.31.16.82 to 172.31.16.181.
The traffic source was IXIA-1 port Ix10/2 connected to switch Dista-2. The destination IP address was
IXIA-1 port Ix-8/2 connected to switch Dista-1. Router SH1-110 received the traffic from Dista-2 and
distributed it into the test network. A total of 10 million packets at 100,000 pps was sent. The path of the
traffic for this test is as follows:
IXIAtx -> Dista-2 -> SH1-110 -> (SH1-103 / SH1-104) -> (SH1-107 / SH1-108) -> Dista-1 -> IXIArx
Polarization
The Sup2/MSFC2 uses the ipSrc, ipDst and pathcount to make frame distribution decisions. Under
certain network configurations traffic may not always use all paths available in the CEF table. In the test
configuration switches 110, 103 and 104 have the same pathcount. Figure 25 shows a description and
illustration of the problem.
If traffic B and D will hash to the right path of the two output paths, then that same traffic will hash to a
single path even if multiple paths are available. Traffic B and D do not take the separate paths available.
This behavior is expected, and is due to the original hash algorithm used by CEF.
Cisco IOS Release 12.1(13)E13
403
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Figure 25
Cisco Express Forwarding Packet-Switching with Polarization Topology
To address the polarization issue, Native IOS version 12.1(13)E3 allows the configuration of three
different CEF distribution algorithms. These are called original, universal (configured by default), and
tunnel. These algorithms, however, apply only to traffic that is software-switched; traffic that is
hardware-switched in the PFC2 uses the original algorithm. The test uses the default algorithm
(universal), but still encounters the polarization problem, due to hardware limits in the PFC2. This
problem is addressed with the introduction of the EARL7 ASIC in the coming supervisor 3.
Because there are now 100 different SrcIP::DstIP pairs, this test will not look at the MLS entries. Rather
it will look only at the traffic to endure that it is load-balanced correctly.
Step 5
Clear the traffic counters on the test devices. Begin the IXIA traffic stream sending traffic from Dista-2
to Dista-1.
Step 6
Verify that all of the 1 million packets that were sent were received on the proper IXIA port.
Step 7
Show the interface traffic counters on devices SH1-110, SH1-103, SH1-104, SH1-107, and SH1-108.
This will demonstrate that CEF load-balancing did occur along the traffic path.
The traffic is load-balanced correctly along each level from the source to the destination.
Step 8
Display the log for error messages.
Cisco IOS Release 12.1(13)E13
404
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 9
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that traffic sourced from multiple IP hosts to multiple IP hosts will use multiple paths if
they are available (with polarization taken into account).
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 83
CEF Many-to-Many Distribution with Polarization Load Balance Test Results
Test
Result
CEF Many-to-Many Distribution with Polarization Load Balance
Pass
Open Shortest Path First
Open Shortest Path First (OSPF) is an Interior Gateway Protocol (IGP) developed by the OSPF working
group of the Internet Engineering Task Force (IETF). Designed expressly for IP networks, OSPF
supports IP subnetting and tagging of externally derived routing information. OSPF also allows packet
authentication and uses IP multicast when sending and receiving packets.
The following tests were performed:
•
OSPF Autocost, page 405
•
OSPF Passive Interface, page 407
•
OSPF Filtering, page 409
•
OSPF Redistribution, page 410
•
OSPF Topology Database Verification, page 413
OSPF Autocost
This test verified that the auto-cost reference-bandwidth value command functions correctly. OSPF
used the interface cost to compute routing matrixes. By default: cost = 100/bandwidth (in Mbps)
The lowest cost is 1, which is for 100 Mbps interfaces. In order to let Gigabit Ethernet, GEC, or
10 Gigabit Ethernet, have a cost that will allow comparison of the higher speed connections, use the
auto-cost command to set up a higher reference bandwidth other than 100 Mbps. The default autocost
reference-bandwidth for the Native IOS Safe Harbor testing is 100,000.
Device under test: SH1-97.
Test Procedure
The procedure used to perform the OSPF Autocost test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Cisco IOS Release 12.1(13)E13
405
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin the test script that will perform Step 5 through Step 9.
Step 5
Show the auto-cost configuration for SH1-97.
OSPF is running on the networks associated with the interfaces being used, portchannel 11
(172.31.1.0/29) and portchannel 13 (172.31.1.20/30).
Step 6
Show the OSPF interface costs for interfaces portchannel 11 and portchannel 13 on SH1-97. Show that
portchannel 11 is a two-port channel, and portchannel 13 is a four-port channel. The auto-cost
configuration allows the 4-port portchannel to have one-half of the cost of the 2-port portchannel.
portchannel 11 is a two-port channel and portchannel 13 is a four-port channel. The OSPF interface cost
of the two-port channel is 50. The OSPF interface cost of the four-port channel is 25, exactly 1/2 the
value of the two-port channel:
Step 7
Reconfigure the reference bandwidth to the default bandwidth 100. Show that both portchannel
interfaces now have the same minimum cost of one (in this case, they would be compared equally with
a single fast-Ethernet interface).
With the reference-bandwidth changed to 100, both the two-port and four-port channels have an OSPF
interface cost of 1:
Step 8
Change the auto-cost value to 500000, and confirm that the interface costs have changed to 250 and 125
for portchannel 11 and portchannel 13, respectively.
With the reference-bandwidth changed to 500,000, the two-port channel has an OSPF interface cost of
250. And the four-port channel has an OSPF interface cost of 125, again 1/2 the cost of the two-port
channel:
Step 9
Change the auto-cost value back to 100000, and confirm that the interface costs have changed back to
their original values.
SH1-97 is back at the default configuration, and the default OSPF interface costs, for both portchannels.
Step 10
Display the log for error messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that the OSPF interface cost will change accordingly with the change in configuration of
the auto-cost reference value.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 84
OSPF Autocost Test Results
Test
Result
OSPF Autocost
Pass
Cisco IOS Release 12.1(13)E13
406
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
OSPF Passive Interface
This test verified that the passive-interface command functions correctly. Routers should not send
routing updates out passive interfaces. In the case of OSPF, hello packets will not be sent out passive
interfaces, so neighbors will not be formed.
For this test, SH1-106 is an OSPF neighbor to devices SH1-99 and SH1-100 in OSPF area 2. SH1-100
and SH1-99 are being sent OSPF routes by Pagent. SH1-100 and SH1-106 are connected by the
portchannel 67 interface on SH1-100 and the portchannel 167 interface on SH1-106. SH1-99 and
SH1-106 are connected by the portchannel 67 interface on SH1-100 and the portchannel 67 interface on
SH1-106. The passive-interface command was configured on portchannel 67 on SH1-100 and on
portchannel 67 on SH1-99. The neighbor tables on SH1-100 and SH1-99 were checked to verify the
command worked (SH1-106 should be removed). SH1-106 should likewise lose about 25,000 OSPF
routes out of its routing table (this includes both 15,000 OSPF routes generated by Pagent and 10,000
EIGRP routes redistributed into OSPF by SH1-99 and SH1-100). The passive-interface commands were
removed and the neighbor relationships and route table updates were reestablished.
Figure 26 shows the topology for the OSPF passive interface test.
Figure 26
OSPF Passive Interface Topology
Devices under test: SH1-99, SH1-100, and SH1-106.
Test Procedure
The procedure used to perform the OSPF Passive Interface test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Shutdown the portchannel 20 interface on device SH1-105. This will ensure that SH1-106 will have no
secondary way to get the routes from SH1-99 and SH1-100.
Step 5
Verify that SH1-99, SH1-100 and SH1-106 are running OSPF (process ID 1) and that both belong to
Area 2.
portchannel 67 of SH1-99 is on network 172.31.1.68/30. The 172.31.1.64/29 network is running OSPF
area 2. portchannel 67 of SH1-100 is on network 172.31.1.96/30. The 172.31.1.96/30 network is running
OSPF area 2. portchannel 67 of SH1-106 is on network 172.31.1.68/30. portchannel 167 of SH1-106 is
on network 172.31.1.96/30. The 172.31.1.68/30 and 172.31.1.96/30 networks are running OSPF area 2.
Cisco IOS Release 12.1(13)E13
407
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 6
Verify the neighbor relationship between SH1-100 and SH1-106 and between SH1-99 and SH1-106.
All relevant neighbor relationships are up and FULL.
Step 7
Show the number of OSPF routes that SH1-106 has in its routing table.
SH1-106 has entries for ~25,000 OSPF routes.
Step 8
Configure a passive interface on portchannel 67 of SH1-99 and on portchannel 67 of SH1-100.
Step 9
After the Dead Timer expires for the neighbors on SH1-106, verify the neighbor relationship no longer
exists between SH1-100 and SH1-106 or between SH1-99 and SH1-106. Confirm that the OSPF routes
SH1-106 was receiving from its neighbors are no longer in its routing table. SH1-106 should only have
5000 OSPF routes in its routing table (from another Pagent source connected to Dista-2).
SH1-106 no longer knows SH1-99 and SH1-100 as OSPF neighbors. SH1-106 no only knows about 2500
OSPF routes. 2500 of these routes are being generated by the Pagent device connected to Dista-2.
Step 10
Remove the passive interfaces configured above.
Step 11
Verify that the neighbor relationship between SH1-100/SH1-99 and SH1-106 has been reestablished and
confirm that SH1-106 again received routing updates from its neighbors.
The OSPF neighbor relationships between SH1-106 and SH1-99/100 are again established and FULL.
SH1-106 again has roughly 25,000 OSPF routes in its routing table.
Step 12
Bring up the portchannel 20 interface on SH1-105 that was shutdown earlier.
Step 13
Display the log for error messages.
Step 14
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that the neighbor relationships between SH1-99, SH1-100 and SH1-106 will be broken
down when the passive-interface commands are applied.
•
We expect that SH1-106 will destroy the ~17,500 routes that it was learning from SH1-99 and
SH1-100 when it loses those two devices as neighbors.
•
We expect that the neighbor relationships will re-form properly when the passive-interface
commands are removed.
•
We expect that SH1-106 will, once again, fully populate its routing table with the new updates from
SH1-99 and SH1-100.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 85
OSPF Passive Interface Test Results
Test
Result
OSPF Passive Interface
Pass
Cisco IOS Release 12.1(13)E13
408
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
OSPF Filtering
This procedure tested the capability of OSPF to filter out routes using the distribute-list command.
SH1-97, SH1-100, and SH1-106 are connected as such: SH1-97 to SH1-100 to SH1-106. These
connections are Layer 3 links (channels). The link between SH1-100 and SH1-106 (Po13) is network
172.31.1.96/30. Figure 27 shows the relevant topology. SH1-97 knows, through OSPF, this network via
portchannel 13. SH1-97 was configured with an access list and the distribute-list command, so that
SH1-97 no longer knows this route; it is filtered out.
Figure 27
OSPF Filtering Topology
Devices under test: SH1-97, SH1-100, and SH1-106.
Test Procedure
The procedure used to perform the OSPF Filtering test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Confirm that SH1-97, SH1-100, and SH1-106 are running OSPF and have network statements for their
respective connecting networks (Figure 27).
SH1-97 is running OSPF area 0 on the 172.31.1.20/30 network. SH1-100 is running OSPF area 0 on the
172.31.1.20/30 and OSPF area 2 172.31.1.96/30 networks. SH1-106 is running OSPF area 2 on the
172.31.1.96/30 network.
Step 5
Confirm that SH1-97 knows the route to network 172.31.1.96 via portchannel 13.
SH1-97 knows the route to 172.31.1.96 via portchannel 13.
Step 6
Confirm that access-list 30 is configured, on SH1-97, to deny network 172.31.1.96.
Step 7
Configure the distribute-list command for access-list 30 on SH1-97, OSPF process ID 1.
This distribute-list will keep SH1-97 from receiving routing updates from SH1-100.
Step 8
Verify that the route to the 172.31.1.96 network is no longer known via Po13 in SH1-97. SH1-97 has
connections to other routers running OSPF and, so, should learn the route to that network via another
interface.
SH1-97 now knows the route to 172.31.1.96 via portchannel 12.
Step 9
Remove the distribute-list command configured on SH1-97.
Cisco IOS Release 12.1(13)E13
409
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 10
Verify that the route to the 172.31.1.96 network is, once again, in the routing table of SH1-97, known
via portchannel 13.
SH1-97 again knows the route to 172.31.1.96 via portchannel 13.
Step 11
Display the log for error messages.
Step 12
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that SH1-97 will not know the route to network 172.31.1.96 out interface portchannel 13
when the filter is applied.
•
We expect that SH1-97 will re-learn the route to the 172.31.1.96 network out interface portchannel
13 when the filter is removed.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 86
OSPF Filtering Test Results
Test
Result
OSPF Filtering
Pass
OSPF Redistribution
This test verified that the redistribution of EIGRP routes into OSPF functions properly. The baseline
configuration for the Safe Harbor Native Cisco IOS testbed includes having all EIGRP routes
redistributed into OSPF by devices SH1-99 and SH1-100. This test verified that the EIGRP routes from
EIGRP 1320 are known to device SH1-97 via OSPF. The redistribute configuration statements from
SH1-99 and SH1-100 is then removed so the routes from EIGRP 1320 should no longer be known by
SH1-97. Redistribution on SH1-99 and SH1-100 is then reconfigured and the routes from EIGRP 1320
should, again, be known to SH1-97 via OSPF.
Figure 28 shows the topology for the OSPF redistribution test.
Cisco IOS Release 12.1(13)E13
410
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Figure 28
OSPF Redistribution Topology
Devices under test: SH1-97, SH1-99, SH1-100, and SH1-101.
Test Procedure
The procedure used to perform the OSPF Redistribution test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin the test script the will perform Step 5 through Step 15.
Step 5
•
PASSED. SH1-99 and SH1-100 are redistributing EIGRP into OSPF and are running EIGRP 1320
& OSPF process id 1
•
PASSED. SH1-101 is running EIGRP AS 1320
•
PASSED. SH1-97 is running OSPF process 1
•
PASSED. The routes 172.31.1.25 & 172.31.1.42 are known to SH1-97 via OSPF process 1
•
PASSED. 20125 subnets are known via OSPF 1 on SH1-97 (minimum 19500 should be known).
•
PASSED. Routes 172.31.1.25 & 172.31.1.42 are removed from the routing table on SH1-97
•
PASSED. SH1-97 has 10102 routes. Should know at least 9625 routes.
•
PASSED. Redistribution was successfully reconfigured
•
PASSED. The routes 172.31.1.25 & 172.31.1.42 are known to SH1-97 via OSPF process 1
•
PASSED. known_subs is 20125, should_know is 20125.
Routing table has been restored.Verify that SH1-99 and SH1-100 are running both OSPF process ID 1
and EIGRP 1320.
Cisco IOS Release 12.1(13)E13
411
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Both SH1-99 and SH1-100 are running OSPF and EIGRP processes. Both are also redistributing EIGRP
1320 routes into OSPF 1.
Step 6
Confirm that SH1-101 is running EIGRP 1320.
SH1-101 is running EIGRP 1320.
Step 7
Confirm that SH1-97 is running OSPF process ID 1.
SH1-97 is running OSPF 1.
Step 8
Confirm that the routes 172.31.1.25 and 172.31.1.42 are known to SH1-97 via OSPF.
Both routes are know to SH1-97 via OSPF 1. Further they have been redistributed from EIGRP, indicated
by the "type extern 2" tag.
Step 9
Show the number of OSPF routes known to SH1-97 (there should be roughly 20,000).
SH1-97 knows roughly 20,000 OSPF routes. 10,000 of these are EIGRP routes that have been
redistributed.
Step 10
Remove the redistribution configuration from both SH1-99 and SH-100.
Step 11
See if the route entries seen in are still present on SH1-97.
The two routes in the EIGRP domain are no longer known.
Step 12
Show the number of OSPF routes known to SH1-97 (there should be only about 10,000 now).
SH1-97 now only knows of about 10,000 OSPF routes. The 10,000 EIGRP routes are no longer being
redistributed.
Step 13
Re-configure redistribution on SH1-99 and SH1-100.
Step 14
Confirm that the route entries seen in are once again present on SH1-97.
With redistribution reconfigured, the two routes are again known to SH1-97 via OSPF 1.
Step 15
Show the number of OSPF routes known to SH1-97 (there should be over 20,000, again).
Again, SH1-97 knows of the 10,000 EIGRP routes that have been redistributed, or 20,000 OSPF routes
total.
Step 16
Display the log for error messages.
Step 17
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that the route entries observed in will no longer be known via OSPF 1 with the removal
of the redistribution configuration.
•
We expect that these route entries will be created again, when redistribution is reconfigured.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 87
OSPF Redistribution Test Results
Test
Result
OSPF Redistribution
Pass
Cisco IOS Release 12.1(13)E13
412
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
OSPF Topology Database Verification
This test verified that the OSPF topology database functions correctly. Each section of the test observes
the OSPF database both in the case of no Pagent or IXIA test tools feeding extra routes (Pagent and IXIA
interfaces shut down or disabled) and in the case of Pagent and IXIA feeding extra routes.
Devices under test: SH1-97, SH1-98, SH1-99, and SH1-100.
Test Procedure
The procedure used to perform the OSPF Topology Database Verification test follows:
Step 1
From each router in the Safe Harbor network, gather information about the OSPF interfaces and the
OSPF processes that are running.
Step 2
From each ABR in the Safe Harbor network, gather information about the OSPF database maintained
for each area.
Step 3
Verify Router LSA. In each area, verify there is one Router LSA in the database for each router in that
area.
Step 4
Verify Network LSA. For each multi-access network which has more than one OSPF router on it, a DR
and BDR are elected and the DR generates a Network LSA for this subnet. However, an OSPF router
with an interface on a multi-access network with no other OSPF routers still shows up as DR, but no
Network LSA is generated because there is no other OSPF router on the subnet. So, in order to know
which multi-access subnets should have a Network LSA generated for them, look for the existence of a
BDR on that subnet. In each area, verify that there is one Network LSA for each BDR interface in the
output of show ip ospf interface.
Step 5
Verify Summary Network LSA. In each area, count the number of DR or Loopback interfaces which are
up/up state in the output of show ip ospf interface. Verify that the number of Summary Network LSA's
in each area is equal to the sum of the previous counts of all the other areas times the number of ABRs
advertising those routes.
Step 6
Verify Summary ASBR. An ABR between areas X and Y will generate a Summary ASBR into X for an
ASBR which exists in Y. However, an ABR which is an ASBR will not advertise itself. Safe Harbor has
a unique topology in that every area has dual ABRs which also happen to be ASBRs. So each
ABR/ASBR sees its partner as an ASBR in both areas, and will advertise its partner with a Summary
ASBR LSA in both areas. In each area, verify there is a Summary ASBR LSA from each ABR in that
area for each ASBR outside this area.
Step 7
Verify External LSAs. Verify there is an External LSA for each external route redistributed into OSPF.
Results
Table 88
OSPF Topology Database Verification Test Results
Test
Result
OSPF Topology Database Verification
Pass
Cisco IOS Release 12.1(13)E13
413
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Border Gateway Protocol
Border Gateway Protocol (BGP) is an exterior gateway protocol designed to exchange network reach
ability information with other BGP systems in other autonomous systems. BGP exchanges routing
information in the form of routing updates. An update includes a network number, a list of autonomous
systems that the routing information has passed through (the autonomous system path), and a list of other
path attributes.
The following tests were performed:
•
Add 120,000 Routes, page 414
•
Redistribution OSPF into BGP, page 415
•
Redistribution EIGRP into BGP, page 417
•
Redistribution OSPF and EIGRP into BGP, page 419
•
BGP Neighbor Flap, page 421
•
BGP Neighbor Flap—With Dampening, page 422
•
BGP Neighbor Flap—No Dampening, page 423
Add 120,000 Routes
This test ensured that no memory leaks or unexpected CPU load occurs with 8 BGP neighbors in the core
(4 core routers and 4 pagent neighbors) and a total of 100,000 BGP routes, 10,000 OSPF routes, and
10,000 EIGRP routes. The test begins with the core routers SH1-97, SH1-98, SH1-99, and SH1-100
having no routes added from the test tools.
During the course of this test, OSPF routes were added to the network via the Pagent and IXIA test tools.
EIGRP and BGP routes were added via the Pagent test tool. All of the routes were added successively,
with no scaling up. The CPU and memory were monitored on the core routers to verify that there were
no anomalies.
Devices under test: SH1-97, SH1-98, SH1-99, and SH1-100.
Test Procedure
The procedure used to perform the Add 120,000 Routes test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
If the routes from the test tools have already been added to the various places in the network, stop them
now.
Step 5
Show a route summary for the 4 core devices with no test tool routes added.
Each of the four core routers has only slightly more than 100 routes, total, in its routing table.
Step 6
Add all the BGP routes.
Step 7
Confirm that the 100,000 BGP routes are now in the routing tables of the core routers.
Each of the four core routers now has about 100,000 BGP routes and about 100,000 total routes in its
routing table.
Step 8
Add all the OSPF routes.
Cisco IOS Release 12.1(13)E13
414
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 9
Confirm that the 10,000 OSPF routes are now in the routing tables of the core routers.
Each of the four core routers now has about 10,000 OSPF routes and about 110,000 total routes in its
routing table.
Step 10
Add all the EIGRP routes.
Step 11
Confirm that the 10,000 EIGRP routes are now in the routing tables of the core routers.
Each of the four core routers now has about 10,000 EIGRP routes and about 120,000 total routes in its
routing table. The 10,000 EIGRP routes manifest in the routing tables of SH1-97 and SH1-98 as OSPF
routes due to the redistribution of the EIGRP routes by SH1-99 and SH1-100.
Step 12
Display the log for error messages.
Step 13
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that all 120,000 routes can be added to the core devices without any unacceptable impact
on the CPU or memory utilization.
Results
Table 89
Add 120,000 Routes Test Results
Test
Result
Add 120,000 Routes
Pass
Redistribution OSPF into BGP
This test verified that route redistribution works correctly between BGP and OSPF. Device SH1-100 is
a border router between OSPF and BGP. It is on this router, and its neighbor SH1-99, that the
configuration for redistribution was applied. Only a limited number of OSPF routes were redistributed
into BGP. Device SH1-97 will be used to check whether the routes have been redistributed.
Figure 29 shows the topology for route redistribution OSPF into BGP:
Cisco IOS Release 12.1(13)E13
415
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Figure 29
Redistribution OSPF into BGP Topology
Devices under test: SH1-97, SH1-99, SH1-100
Test Procedure
The procedure used to perform the Redistribution OSPF into BGP test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
On device SH1-97, determine by what protocol the route for 170.1.1.0 is known.
The route to 170.1.1.0 is known via OSPF 1.
Step 5
Show the default BGP configuration of SH1-99 and SH1-100.
Both SH1-99 and SH1-100 are running BGP 100.
Step 6
Configure redistribution from BGP into OSPF on both devices SH1-99 and SH1-100.
Step 7
Confirm that access-list 16 is configured on SH1-97, and that it denies the 170.1.1.0 network.
Step 8
Apply a inbound distribute-list using access-list 16 in the OSPF configuration on SH1-97 to block
network 170.1.1.0 from being known by OSPF.
This will prohibit SH1-97 from learning about the 170.1.1.0 network via OSPF 1.
Step 9
Confirm that the route to 170.1.1.0 is now know via BGP 100 on SH1-97 and has a metric of 100, as
configured above.
SH1-97 now knows the route to 170.1.1.0 via BGP 100.
Step 10
Remove the redistribution from SH1-99 and SH1-100 and the distribute-list command from SH1-97.
Verify that the 170.1.1.0 network is known again via OSPF 1.
Cisco IOS Release 12.1(13)E13
416
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
With OSPF routes no longer being redistributed into BGP by SH1-99 and SH1-100, and with SH1-97 no
longer blocking the route 170.1.1.0 from being learned by OSPF 1, SH1-97 knows the route to 170.1.1.0
via OSPF 1.
Step 11
Display the log for error messages.
Step 12
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that OSPF routes will be correctly redistributed into BGP.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 90
Redistribution OSPF into BGP Test Results
Test
Result
Redistribution OSPF into BGP
Pass
Redistribution EIGRP into BGP
This test verified that route redistribution works correctly between BGP and EIGRP. Device SH1-100 is
a border router between EIGRP and BGP. It is on this router, and its neighbor SH1-99, that the
configuration for redistribution was applied. Only a limited number of EIGRP routes were redistributed
into BGP. Device SH1-97 will be used to check whether the routes have been redistributed.
Figure 30 shows the topology for route redistribution EIGRP into BGP:
Figure 30
Redistribution EIGRP into BGP Topology
Cisco IOS Release 12.1(13)E13
417
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Devices under test: SH1-97, SH1-99, SH1-100
Test Procedure
The procedure used to perform the Redistribution EIGRP into BGP test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Confirm that the routes to 180.1.1.0 and 180.1.2.0 are known on SH1-97 via OSPF 1, redistributed from
EIGRP (identified by the "type extern 2" label).
The routes to 180.1.1.0 and 180.1.2.0 are known to SH1-97 via OSPF 1, having been redistributed from
EIGRP.
Step 5
Confirm that the access-list 18 exists in SH1-99 and SH1-100 and permits only the even subnets within
180.1.x.x/24.
This access-list, configured on SH1-99 and SH1-100, will permit only networks with the last bit of the
third octet set to 0. This means it will permit only even networks.
Step 6
Confirm that there is a route-map called EIGRP2BGP on SH1-99 and SH1-100 which uses matches IP
addresses to access-list 18.
The route-maps, configured on SH1-99 and SH1-100, contain a permit sequence, bound by access-list
18.
Step 7
Configure redistribution of EIGRP into BGP on SH1-99 and SH1-100 using the route-map EIGRP2BGP,
which only allows the even subnets within 180.1.x.x.
SH1-99 and SH1-100 will now redistribute the EIGRP routes into BGP with the restriction defined by
the EIGRP2BGP route-map.
Step 8
Note
Remove the redistribution statement from the OSPF configuration on SH1-99 and SH1-100.
If this step is not taken, SH1-97 will continue to know the 180.x.x.x networks via OSPF 1, because OSPF
has a lower administrative distance than BGP.
SH1-99 and SH1-100 will no longer redistribute EIGRP 1320 routes into OSPF 1.
Step 9
Confirm that the even networks within 180.1.x.0/24 are known to SH1-97 via BGP 100.
SH1-97 knows only the even routes via BGP 100. SH1-99 and SH1-100 have redistributed only the even
EIGRP routes into BGP, successfully matching the route-map, EIGRP2BGP.
Step 10
Remove the redistribution configurations applied in BGP on devices SH1-99 and SH1-100.
SH1-99 and SH1-100 are returned to their default configurations, redistributing neither OSPF 1 nor
EIGRP 1320 routes into BGP 100.
Step 11
Reapply the EIGRP redistribution configuration in OSPF on SH1-99 and SH1-100 that was deleted.
SH1-99 and SH1-100 will again redistribute EIGRP 1320 routes into OSPF 1.
Step 12
Confirm that the routes are known, again, via OSPF 1.
As was the original case, SH1-97 knows the routes via OSPF 1.
Step 13
Display the log for error messages.
Cisco IOS Release 12.1(13)E13
418
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 14
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that EIGRP routes will be correctly redistributed into BGP.
•
We expect that the application of a route-map will correctly alter the rules by which BGP
redistributes routes.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 91
Redistribution EIGRP into BGP Test Results
Test
Result
Redistribution EIGRP into BGP
Pass
Redistribution OSPF and EIGRP into BGP
This test verified that route redistribution works correctly between BGP and both OSPF and EIGRP.
Device SH1-100 is a border router between OSPF, EIGRP, and BGP. It is on this router, and its neighbor
SH1-99, that the configuration for redistribution was applied. OSPF and EIGRP was redistributed into
BGP at the same time. Only a limited number of routes were redistributed. Device SH1-97 was used to
check whether the routes have been redistributed.
Figure 31 shows the topology for route redistribution OSPF and EIGRP into BGP:
Figure 31
Redistribution OSPF and EIGRP into BGP Topology
Devices under test: SH1-97, SH1-99, SH1-100
Cisco IOS Release 12.1(13)E13
419
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Test Procedure
The procedure used to perform the Redistribution OSPF and EIGRP into BGP test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
On device SH1-97, determine by what protocol the route for 170.1.1.0 is known.
The route to 170.1.1.0 is know via OSPF 1.
Step 5
Confirm that the routes to 180.1.1.0 and 180.1.2.0 are known on SH1-97 via OSPF 1, redistributed from
EIGRP (identified by the "type extern 2" label).
The routes to 180.1.1.0 and 180.1.2.0 are known to SH1-97 via OSPF 1, having been redistributed from
EIGRP.
Step 6
Show the default BGP configuration of SH1-99 and SH1-100.
Both SH1-99 and SH1-100 are running BGP 100.
Step 7
Configure redistribution from OSPF into BGP on both devices SH1-99 and SH1-100.
Step 8
Confirm that access-list 16 is configured on SH1-97, and that it denies the 170.1.1.0 network.
Step 9
Apply a inbound distribute-list using access-list 16 in the OSPF configuration on SH1-97 to block
network 170.1.1.0 from being known by OSPF.
This will prohibit SH1-97 from learning about the 170.1.1.0 network via OSPF 1.
Step 10
Confirm that the access-list 18 exists in SH1-99 and SH1-100 and permits only the even subnets within
180.1.x.x/24.
This access-list, configured on SH1-99 and SH1-100, will permit only networks with the last bit of the
third octet set to 0. This means it will permit only even networks.
Step 11
Confirm that there is a route-map called EIGRP2BGP on SH1-99 and SH1-100 which uses matches IP
addresses to access-list 18.
The route-maps, configured on SH1-99 and SH1-100, contain a permit sequence, bound by access-list
18.
Step 12
Configure redistribution of EIGRP into BGP on SH1-99 and SH1-100 using the route-map EIGRP2BGP,
which only allows the even subnets within 180.1.x.x.
SH1-99 and SH1-100 will now redistribute the EIGRP routes into BGP with the restriction defined by
the EIGRP2BGP route-map.
Step 13
Note
Remove the redistribution statement from the OSPF configuration on SH1-99 and SH1-100.
If this step is not taken, SH1-97 will continue to know the 180.x.x.x networks via OSPF 1, because OSPF
has a lower administrative distance than BGP.
SH1-99 and SH1-100 will no longer redistribute EIGRP 1320 routes into OSPF 1.
Step 14
Confirm that the route to 170.1.1.0 is now know via BGP 100 on SH1-97 and has a metric of 100, as
configured in Step 5.
SH1-97 now knows the route to 170.1.1.0 via BGP 100.
Step 15
Confirm that the even networks within 180.1.x.0/24 are known to SH1-97 via BGP 100.
Cisco IOS Release 12.1(13)E13
420
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
SH1-97 knows only the even routes from EIGRP. SH1-99 and SH1-100 have redistributed only the even
EIGRP routes into BGP, successfully matching the route-map, EIGRP2BGP.
Step 16
Reapply the EIGRP redistribution configuration in OSPF on SH1-99 and SH1-100 that was deleted in
Step 13.
SH1-99 and SH1-100 will again redistribute EIGRP 1320 routes into OSPF 1.
Step 17
Remove the redistribution configurations applied in BGP on devices SH1-99 and SH1-100 in Step 7 and
Step 12.
SH1-99 and SH1-100 are returned to their default configurations, redistributing neither OSPF 1 nor
EIGRP 1320 routes into BGP 100.
Step 18
Remove the distribute-list from SH1-97, applied in Step 9.
Now, SH1-97 can learn the route 170.1.1.0 via OSPF 1 again.
Step 19
Confirm that the routes are known, again, via OSPF 1.
As was the original case, SH1-97 knows the routes from OSPF and EIGRP via OSPF 1.
Step 20
Display the log for error messages.
Step 21
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that EIGRP routes will be correctly redistributed into BGP.
•
We expect that OSPF routes will be correctly redistributed into BGP.
•
We expect that the application of a route-map will correctly alter the rules by which BGP
redistributes routes.
•
We expect that the redistribution of both OSPF and EIGRP routes into BGP at the same time.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 92
Redistribution OSPF and EIGRP into BGP Test Results
Test
Result
Redistribution OSPF and EIGRP into BGP
Pass
BGP Neighbor Flap
This test verified that a flapping non dampened BGP peer did not cause any memory leaks or prolonged
high CPU utilization, and that the DUT functions properly after the peer stops flapping. With BGP routes
being fed into devices SH1-97 and SH1-98, this test will simulate constant flapping of those BGP
neighbors. Specifically, the Pagent device rtp-wbu-te-p4 is feeding 35,000 BGP routes into SH1-97 from
interface fa1/0. The Pagent configuration on this interface was modified to enable flapping and the test
was run overnight.
Devices under test: SH1-97, SH1-98, SH1-99, and SH1-100.
Cisco IOS Release 12.1(13)E13
421
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Test Procedure
The procedure used to perform the BGP Neighbor Flap test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-97 is an eBGP peer with a Pagent router. The Pagent router is sending 35000 route
updates from AS 10.
Step 5
Log into the Pagent test tool.and configure the lne bgp interface fa2/0 (BGP route feed) to flap every 600
seconds followed by a non-flapping period of 600 seconds. Turn router-flap on and allow this to continue
overnight.
Step 6
Display the log for error messages.
Step 7
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that at the completion of this test, the amount of memory free for each device being
monitored will be roughly the same, indicating no memory leaks.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 93
BGP Neighbor Flap Test Results
Test
Result
BGP Neighbor Flap
Pass
BGP Neighbor Flap—With Dampening
This test verified that a flapping non dampened BGP peer did not cause any memory leaks or prolonged
high CPU utilization, and that the DUT functions properly after the peer stops flapping. With BGP routes
being fed into devices SH1-97 and SH1-98, this test will simulate constant flapping of those BGP
neighbors. Specifically, the Pagent device rtp-wbu-te-p4 is feeding 35,000 BGP routes into SH1-97 from
interface fa1/0. The Pagent configuration on this interface was modified to enable flapping and the test
was run overnight.
Devices under test: SH1-97, SH1-98, SH1-99, and SH1-100.
Test Procedure
The procedure used to perform the BGP Neighbor Flap—With Dampening test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Cisco IOS Release 12.1(13)E13
422
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 4
Verify that SH1-97 is an eBGP peer with a Pagent router. The Pagent router is sending 35000 route
updates from AS 10.
Step 5
Verify that route-dampening is configured on core devices SH1-97, SH1-98, SH1-99, and SH1-100,
which connect to the Pagent test tool running the BGP emulator.
Step 6
Log into the Pagent test tool.and configure lne bgp interface fa1/0 (BGP route feed) to withdraw ten
routes every 1 second and keep each route withdrawn for ten minutes. Let this test run overnight.
Step 7
Display the log for error messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that at the completion of this test, the amount of memory free for each device being
monitored will be roughly the same, indicating no memory leaks.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 94
BGP Neighbor Flap—With Dampening Test Results
Test
Result
BGP Neighbor Flap—With Dampening
Pass
BGP Neighbor Flap—No Dampening
This test verified that a flapping non dampened BGP peer did not cause any memory leaks or prolonged
high CPU utilization, and that the DUT functions properly after the peer stops flapping. With BGP routes
being fed into devices SH1-97 and SH1-98, this test will simulate constant flapping of those BGP
neighbors. Specifically, the Pagent device rtp-wbu-te-p4 is feeding 35,000 BGP routes into SH1-97 from
interface fa1/0. The Pagent configuration on this interface was modified to enable flapping and the test
was run overnight.
Devices under test: SH1-97, SH1-98, SH1-99, and SH1-100.
Test Procedure
The procedure used to perform the BGP Neighbor Flap—No Dampening test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-97 is an eBGP peer with a Pagent router. The Pagent router is sending 65000 route
updates from AS 20.
Step 5
Verify that route-dampening is not configured on core devices SH1-97, SH1-98, SH1-99, and SH1-100,
which connect to the Pagent test tool running the BGP emulator.
Step 6
Log into the Pagent test tool.and configure lne bgp interface fa1/0 (BGP route feed) to withdraw ten
routes every 1 second and keep each route withdrawn for ten minutes. Let this test run overnight.
Cisco IOS Release 12.1(13)E13
423
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 7
Display the log for error messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that at the completion of this test, the amount of memory free for each device being
monitored will be roughly the same, indicating no memory leaks.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 95
BGP Neighbor Flap—No Dampening Test Results
Test
Result
BGP Neighbor Flap—No Dampening
Pass
Hot Standby Routing Protocol
For IP, the Hot Standby Router Protocol (HSRP) allows one router to automatically assume the function
of the second router if the second router fails. HSRP is particularly useful when the users on one subnet
require continuous access to resources in the network.
The following tests were performed:
•
HSRP Failover with Default Timers—Supervisor 11, page 424
•
HSRP Failover with Default Timers—Sup 22—Compact Switching Mode, page 426
•
HSRP Failover with Default Timers—Sup 22—Truncated Switching Mode, page 428
•
HSRP Failover with Fast Timers—Supervisor 11, page 430
•
HSRP Failover with Fast Timers—Supervisor 22, page 432
•
Impact of HSRP Traffic on CPU, page 434
•
HSRP Maximum Group Limit, page 435
•
GEM Failover with Attached HSRP Groups, page 436
HSRP Failover with Default Timers—Supervisor 11
This test verified HSRP failover when a link was down. This test also verified that the HSRP preempt
command worked when the link returned to an up/up state, if the interface was configured with a higher
priority than the currently active router interface in the same HSRP group.
Figure 32 shows the topology for HSRP failover with Default Timers on Sup 11.
Cisco IOS Release 12.1(13)E13
424
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Figure 32
HSRP Failover with Default Timers—Sup 11 Topology
Devices under test: SH1-105, SH1-106
Test Procedure
The procedure used to perform the HSRP Failover with Default Timers—Supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify the HSRP configurations on devices SH1-105 and SH1-106 for VLANs 40 through 50.
Each VLAN is configured to belong to two HSRP groups. That VLAN will then be active for one group
and standby for the other on each of the two routers. For example, VLAN 50 has HSRP configured for
groups 11 and 12. SH1-105 is active for group 11 and standby for group 12. SH1-106 is standby for
group 11 and active for group 12.
Step 5
Verify that the links between SH1-105 and Dista-1 and the links between SH1-106 and Dista-1 are trunks
and that VLANs 40 to 50 are active within them.
portchannel 20 on each of the two devices is a trunk with VLANs 40-50 in spanning tree forwarding
state.
Step 6
Note
Verify that HSRP is active on SH1-106 for VLAN 40 Group 2 (this is the VLAN on which traffic will
be sent by IXIA), and standby on SH1-105 for VLAN 40.
The IXIA traffic stream is configured with the MAC address of the default gateway for group 2.
SH1-105 is in Standby mode for VLAN 40 Group 2, while SH1-106 is Active for the same group.
Step 7
Verify that traffic is being sent to the active HSRP router.
SH1-105 is not receiving any incoming unicast packets from IXIA. This is because it is the Standby
HSRP router for VLAN 40 Group 2. SH1-106 is receiving incoming unicast packets from IXIA. This is
because it is the Active HSRP router for VLAN 40 Group 2.
Step 8
Begin the IXIA unicast traffic stream. This stream transmits 300,000 packets at 10,000 pps.
Cisco IOS Release 12.1(13)E13
425
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 9
On SH1-106, shut down the portchannel 20 interface which should force the unicast traffic stream to fail
over to SH1-105.
Step 10
Verify that the active HSRP router for VLAN 40, group 2 is now SH1-105.
SH1-105 is now the Active HSRP router on VLAN 40 Group 2.
Step 11
Measure the time (using traffic loss) required for the switchover to occur.
Step 12
Bring the portchannel 20 interface back up on SH1-106.
Step 13
Verify that HSRP on SH1-106 preempts SH1-105 and once again becomes the active HSRP router.
SH1-106 is again the Active HSRP router for VLAN 40 Group 2.
Step 14
Perform a series of four more port cycles on the portchannel 20 interface of SH1-106. Measure the
average amount of time required for switchover following interface shutdown (include the results from
the first run above).
Step 15
Measure the average amount of time required for switchover following interface shutdown (include the
results from the first run above).
Step 16
Display the log for error messages.
Step 17
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 96
HSRP Failover with Default Timers—Supervisor 11 Test Results
Test
Result
HSRP Failover with Default Timers—Supervisor 11
Pass
HSRP Failover with Default Timers—Sup 22—Compact Switching Mode
This test verified HSRP failover when a link was down. This test also verified that the HSRP preempt
command worked when the link returned to an up/up state, if the interface was configured with a higher
priority than the currently active router interface in the same HSRP group.
Figure 33 shows the CSM topology for HSRP failover with Default Timers on Sup 22.
Cisco IOS Release 12.1(13)E13
426
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Figure 33
HSRP Failover with Default Timers—Sup 22—Compact Switching Mode
SH1-109 and SH1-110 switch the traffic on the L2 GECs in compact mode.
Devices under test: SH1-109, SH1-110
Test Procedure
The procedure used to perform the HSRP Failover with Default Timers—Sup 22—Compact Switching
Mode test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify the HSRP configurations on devices SH1-109 and SH1-110 for VLANs 10 through 20.
Step 5
Verify that the links between SH1-109 and Dista-2 and the links between SH1-110 and Dista-2 are trunks
and that VLANs 10 to 20 are active within them.
portchannel 20 on either box is trunking VLANs 10-20.
Step 6
Note
Verify that HSRP is active on SH1-110 for VLAN 17 (this is the VLAN on which traffic will be sent by
IXIA), and standby on SH1-109 for VLAN 17.
The IXIA traffic stream is configured with the MAC address of the default gateway for group 9.
SH1-109 is in Standby mode for VLAN 17 Group 9, while SH1-110 is Active for the same group:
Step 7
Verify that the CEF adjacencies for each of the virtual IP addresses of each of the 11 VLANs are punt,
and not drop, on SH1-110.
The CEF adjacencies for all 11 VLANs are punt adjacencies.
Step 8
Verify that traffic is being sent to the active HSRP router.
SH1-109 is not receiving any incoming unicast packets from IXIA. This is because it is the Standby
HSRP router for VLAN 17 Group 9. SH1-110 is receiving incoming unicast packets from IXIA. This is
because it is the Active HSRP router for VLAN 17 Group 9.
Step 9
Verify that traffic is being switched in compact mode on the interfaces in portchannel 20.
All the modules in SH1-109 are switching in compact mode, while the interfaces of portchannel 20 of
SH1-110 (modules 3-4) are in compact mode.
Cisco IOS Release 12.1(13)E13
427
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 10
Begin the IXIA unicast traffic stream. This stream transmits 60,000 packets at 1,000 pps.
Step 11
On SH1-110, shut down the portchannel 20 interface which should force the unicast traffic stream to fail
over to SH1-109.
Step 12
Verify that the active HSRP router for VLAN 17, group 9 is now SH1-109.
SH1-109 is now the Active HSRP router on VLAN 17 Group 9.
Step 13
Measure the time (using traffic loss) required for the switchover to occur.
Step 14
Bring the portchannel 20 interface back up on SH1-110.
Step 15
Verify that the CEF adjacencies for each of the virtual IP addresses of each of the 11 VLANs are punt,
and not drop, on SH1-110.
Step 16
Verify that HSRP on SH1-110 preempts SH1-109 and once again becomes the active HSRP router.
SH1-110 is again the Active HSRP router for VLAN 17 Group 9.
Step 17
Perform a series of four more port cycles on the portchannel 20 interface of SH1-110. Measure the
average amount of time required for switchover following interface shutdown (include the results from
the first run above).
Step 18
Measure the average amount of time required for switchover following interface shutdown (include the
results from the first run above).
Step 19
Display the log for error messages.
Step 20
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 97
HSRP Failover with Default Timers—Sup 22—Compact Switching Mode Test Results
Test
Result
HSRP Failover with Default Timers—Sup 22—Compact Switching Mode
Pass
HSRP Failover with Default Timers—Sup 22—Truncated Switching Mode
This test verified HSRP failover when a link was down. This test also verified that the HSRP preempt
command worked when the link returned to an up/up state, if the interface was configured with a higher
priority than the currently active router interface in the same HSRP group.
A diagram showing the relevant topology is below:Figure 33 shows the TSM topology for HSRP failover
with Default Timers on Sup 22.
Cisco IOS Release 12.1(13)E13
428
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Figure 34
HSRP Failover with Default Timers—Sup 22—Truncated Switching Mode Topology
SH1-101 and SH1-102 switch the traffic on the L2 GECs in truncated mode.
Devices under test: SH1-101, SH1-102
Test Procedure
The procedure used to perform the HSRP Failover with Default Timers—Sup 22—Truncated Switching
Mode test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify the HSRP configurations on devices SH1-101 and SH1-102 for VLANs 40 through 50.
Step 5
Verify that the links between SH1-101 and Dista-1 and the links between SH1-102 and Dista-1 are trunks
and that VLANs 40 to 50 are active within them.
portchannel 10 on either device is trunking VLANs 40-50.
Step 6
Note
Verify that HSRP is active on SH1-102 for VLAN 44 (this is the VLAN on which traffic will be sent by
IXIA), and standby on SH1-101 for VLAN 44.
The IXIA traffic stream is configured with the MAC address of the default gateway for group 6.
SH1-101 is in Standby mode for VLAN 44 Group 6, while SH1-102 is Active for the same group.
Step 7
Verify that the CEF adjacencies for each of the virtual IP addresses of each of the 11 VLANs are punt,
and not drop, on SH1-102.
All CEF adjacencies for the 11 VLANs are punt adjacencies.
Step 8
Verify that traffic is being sent to the active HSRP router.
Begin the IXIA unicast traffic stream. This stream transmits 600,000 packets at 10,000 pps.
SH1-101 is not receiving any incoming unicast packets from IXIA. This is because it is the Standby
HSRP router for VLAN 44 Group 6. SH1-102 is receiving incoming unicast packets from IXIA. This is
because it is the Active HSRP router for VLAN 44 Group 6.
Cisco IOS Release 12.1(13)E13
429
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 9
Verify that traffic is being switched in truncated mode on the interfaces in portchannel 10.
The modules of portchannel 10 members' interfaces are switching in truncated mode.
Step 10
Begin the IXIA unicast traffic stream. This stream transmits 600,000 packets at 10,000 pps.
Step 11
On SH1-102, shut down the portchannel 10 interface which should force the unicast traffic stream to fail
over to SH1-101.
Step 12
Verify that the active HSRP router for VLAN 44, group 6 is now SH1-101.
SH1-101 is now the Active HSRP router on VLAN 44 Group 6.
Step 13
Measure the time (using traffic loss) required for the switchover to occur.
Step 14
Bring the portchannel 10 interface back up on SH1-102.
Step 15
Verify that the CEF adjacencies for each of the virtual IP addresses of each of the 11 VLANs are punt,
and not drop, on SH1-102.
Step 16
Verify that HSRP on SH1-102 preempts SH1-101 and once again becomes the active HSRP router.
SH1-102 is again the Active HSRP router for VLAN 44 Group 6.
Step 17
Perform a series of four more port cycles on the portchannel 10 interface of SH1-102. Measure the
average amount of time required for switchover following interface shutdown (include the results from
the first run above).
Step 18
Measure the average amount of time required for switchover following interface shutdown (include the
results from the first run above).
Step 19
Display the log for error messages.
Step 20
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 98
HSRP Failover with Default Timers—Sup 22—Truncated Switching Mode Test Results
Test
Result
HSRP Failover with Default Timers—Sup 22—Truncated Switching Mode Pass
HSRP Failover with Fast Timers—Supervisor 11
This test verified HSRP failover when a link was down with fast timers configured on the test VLAN.
Fast timers consist of a 1-second hello timer and a 3-second dead timer. The traffic is coming in on
VLAN 40.
Figure 33 shows the topology for HSRP failover with Fast Timers on Sup 11.
Cisco IOS Release 12.1(13)E13
430
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Figure 35
HSRP Failover with Fast Timers—Sup 11 Topology
Devices under test: SH1-105, SH1-106
Test Procedure
The procedure used to perform the HSRP Failover with Fast Timers—Supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify the HSRP configurations on devices SH1-105 and SH1-106 for VLAN 40.
Each VLAN is configured to belong to two HSRP groups. That VLAN will then be active for one group
and standby for the other on each of the two routers. For example, VLAN 50 has HSRP configured for
groups 11 and 12. SH1-105 is active for group 11 and standby for group 12. SH1-106 is standby for
group 11 and active for group 12.
Step 5
Note
Verify that HSRP is active on SH1-106 for VLAN 40 Group 2 (this is the VLAN on which traffic will
be sent by IXIA), and standby on SH1-105 for the same.
The IXIA traffic stream is configured with the MAC address of the default gateway for group 2.
SH1-105 is in Standby mode for VLAN 40 Group 2, while SH1-106 is Active for the same group.
Step 6
Verify that traffic is being sent to the active HSRP router.
SH1-105 is not receiving any incoming unicast packets from IXIA. This is because it is the Standby
HSRP router for VLAN 40 Group 2. SH1-106 is receiving incoming unicast packets from IXIA. This is
because it is the Active HSRP router for VLAN 40 Group 2.
Step 7
Reconfigure Group 2 of VLAN 40 on both SH1-105 and SH1-106 so that the hello and hold timers are
1-second and 3-seconds, respectively.
Step 8
Begin the IXIA unicast traffic stream. This stream transmits 300,000 packets at 10,000 pps.
Step 9
On SH1-106, shut down the portchannel 20 interface which should force the unicast traffic stream to fail
over to SH1-105.
Step 10
Measure the time (using traffic loss) required for the switchover to occur.
Cisco IOS Release 12.1(13)E13
431
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Of the 300,000 packets sent, only 275,099 were received. This is a packet loss of 24901 packets, or a
failover time of 2.49 seconds.
Step 11
Bring the portchannel 20 interface back up on SH1-106.
Step 12
Perform a series of four more port cycles on the portchannel 20 interface of SH1-106. Measure the
average amount of time required for switchover following interface shutdown (include the results from
the first run above).
Step 13
Measure the average amount of time required for switchover following interface shutdown (include the
results from the first run above).
Step 14
Remove the fast timers configuration from VLAN 40 of SH1-105 and SH1-106.
Step 15
Display the log for error messages.
Step 16
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 99
HSRP Failover with Fast Timers—Supervisor 11 Test Results
Test
Result
HSRP Failover with Fast Timers—Supervisor 11
Pass
HSRP Failover with Fast Timers—Supervisor 22
This test verified HSRP failover when a link was down with fast timers configured on the test VLAN.
Fast timers consist of a 1-second hello timer and a 3-second hold timer. The traffic is coming in on
VLAN 44.
Figure 36 shows the topology for the HSRP failover with fast timers—supervisor 22 test:
Figure 36
HSRP Failover with Fast Timers—Supervisor 22 Topology
Cisco IOS Release 12.1(13)E13
432
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Devices under test: SH1-101, and SH1-102.
Test Procedure
The procedure used to perform the HSRP Failover with Fast Timers—Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify the HSRP configurations on devices SH1-101 and SH1-102 for VLAN 44.
Step 5
Verify that HSRP is active on SH1-102 for VLAN 44 Group 6 (this is the VLAN on which traffic will
be sent by IXIA), and standby on SH1-101 for the same.
Note
The IXIA traffic stream is configured with the MAC address of the default gateway for group 6.
SH1-101 is in Standby mode for VLAN 44 Group 6, while SH1-102 is Active for the same group.
Step 6
Verify that traffic is being sent to the active HSRP router.
SH1-101 is not receiving any incoming unicast packets from IXIA. This is because it is the Standby
HSRP router for VLAN 44 Group 6. SH1-102 is receiving incoming unicast packets from IXIA. This is
because it is the Active HSRP router for VLAN 44 Group 6.
Step 7
Reconfigure Group 6 of VLAN 44 on both SH1-101 and SH1-102 so that the hello and hold timers are
1-second and 3-seconds, respectively.
Step 8
Begin the IXIA unicast traffic stream. This stream transmits 300,000 packets at 10,000 pps.
Step 9
On SH1-102, shut down the portchannel 10 interface which should force the unicast traffic stream to fail
over to SH1-101.
Step 10
Measure the time (using traffic loss) required for the switchover to occur.
Step 11
Bring the portchannel 10 interface back up on SH1-102.
Step 12
Perform a series of four more port cycles on the portchannel 20 interface of SH1-102. Measure the
average amount of time required for switchover following interface shutdown (include the results from
the first run above).
Step 13
Measure the average amount of time required for switchover following interface shutdown (include the
results from the first run above).
Step 14
Remove the fast timers configuration from VLAN 44 of SH1-101 and SH1-102.
Step 15
Display the log for error messages.
Step 16
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco IOS Release 12.1(13)E13
433
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Results
Table 100
HSRP Failover with Fast Timers—Supervisor 22 Test Results
Test
Result
HSRP Failover with Fast Timers—Supervisor 22
Pass
Impact of HSRP Traffic on CPU
This test measures the impact of traffic on the CPU of the supervisor 22 when traffic is going through a
VLAN that has 16 HSRP groups configured on it. VLANs 60 and 61 are configured on SH1-101 and
SH1-102; 16 separate HSRP groups (101-116) are configured on each VLAN interface. Traffic is
sourced from IXIA, connected to Dista-1, on VLAN 60. The destination is an IXIA port also connected
to Dista-1, on VLAN 61. Traffic is sent at increasing rates of 100,000 pps, 250,000 pps, 500,000 pps,
and 1 million pps. The CPU and memory utilization is measured.
Figure 37 shows the topology for impact of HSRP traffic on CPU.
Figure 37
Impact of HSRP Traffic on CPU Topology
Devices under test: SH1-101, and SH1-102.
Test Procedure
The procedure used to perform the Impact of HSRP Traffic on CPU test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Write the running-configuration to memory (NVRAM) so that it can be recalled later. Do this for
SH1-101 and SH1-102.
Cisco IOS Release 12.1(13)E13
434
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 5
Determine which VLAN interfaces are present on the device.
Step 6
Remove any VLANs discovered in for both SH1-101 and SH1-102, with the exception of VLAN 1.
Perform this function on each device, for its respective VLANs.
Step 7
Configure VLANs 60 and 61 on each device SH1-101 and SH1-102. Each of these VLANs will
participate in HSRP with the other device on 16 groups within each VLAN. SH1-101 will be the active
HSRP router for the odd groups, while SH1-102 will be active HSRP router for the even groups. Also
configure each VLAN to participate in multicast PIM-SM. Make sure VLAN 60 and 61 are configured
on Dista-1
Step 8
Verify that the HSRP states on each device, for each VLAN and group, are as they should be. For
SH1-101, all odd-numbered groups should be active, and the even-numbered groups should be standby.
For SH1-102, all odd groups should be standby and all even groups active.
Step 9
Verify that ports 6/5 and 6/6 on Dista-1 are on VLANs 60 and 61, respectively.
Step 10
Begin the traffic stream. This stream will run at the following rates (packets per second) for one minute
each: 25K, 50K, 75K, 100K, 125K. 22.5 million packets total will be sent, at these varying rates.
Step 11
Verify that 100% of the traffic sent was received on the proper port.
All packets were received for all traffic rates.
Step 12
Remove the VLAN 60 and VLAN 61 configurations from SH1-101 and SH1-102.
Step 13
Copy the startup configuration in NVRAM to the running configuration, and bring the vlan interfaces up
(VLANs 40-50 and those others removed in Step 6), restoring the default configuration for the devices
under test.
Step 14
Display the log for error messages.
Step 15
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that 100 percent of the traffic sent at the varying rates to be received correctly.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 101
Impact of HSRP Traffic on CPU Test Results
Test
Result
Impact of HSRP Traffic on CPU
Pass
HSRP Maximum Group Limit
The PFC2 and MSFC2 support a maximum of 16 unique HSRP groups. There are concerns, that in recent
Cisco IOS code, no warnings are given if more than 16 unique HSRP groups are configured. This test
demonstrates that an error message is displayed when an attempt is made to configure the 17th group.
Device under test: SH1-103.
Test Procedure
The procedure used to perform the HSRP Maximum Group Limit test follows:
Cisco IOS Release 12.1(13)E13
435
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Configure 16 HSRP groups on VLAN 100 of SH1-103.
The 16 HSRP groups are configured without a problem.
Step 5
Attempt to configure the 17th HSRP group.
An error message occurs when the 17th group is configured.
Step 6
Remove VLAN 100 from the configuration on SH2-104.
Step 7
Display the log for error messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
We expect an error message to appear on an attempt to configure the 17th HSRP group, and the 17th
group should not be configurable.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 102
HSRP Maximum Group Limit Test Results
Test
Result
HSRP Maximum Group Limit
Pass
GEM Failover with Attached HSRP Groups
This test verified the resetting of one or more GE modules to which HSRP groups are attached. The
traffic is coming in on VLAN 20.
Devices under test: SH1-110
Test Procedure
The procedure used to perform the GEM Failover with Attached HSRP Groups test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Start the test traffic stream. This stream is multicast test traffic stream C, sending to ten groups
239.100.3.[1-10]. This stream will send 1000pps for 60 seconds.
Step 5
Verify that SH1-110 is the active HSRP router for VLAN 20 group 12.
Step 6
Reset module 3 on SH1-110.
Cisco IOS Release 12.1(13)E13
436
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Step 7
Once module 3 comes back online, verify that SH1-110 is still the active HSRP router for VLAN 20
group 12.
Step 8
Determine the amount of traffic loss.
605 packets were lost out of the 60,000 sent.
Step 9
Start the test traffic stream.
Step 10
Verify that SH1-110 is the active HSRP router for VLAN 20 group 12.
Step 11
Reset module 4 on SH1-110.
Step 12
Verify that SH1-110 is still the active HSRP router for VLAN 20 group 12.
Step 13
Determine the amount of traffic loss.
54 packets were lost out of the 60,000 sent.
Step 14
Start the test traffic stream.
Step 15
Verify that SH1-110 is the active HSRP router for VLAN 20 group 12.
Step 16
Reset both modules 3 and 4 on SH1-110.
Step 17
Verify that SH1-110 is no longer the standby HSRP router for VLAN 20 group 12.
Step 18
Determine the amount of traffic loss.
67 packets were lost out of the 60,000 sent.
Step 19
Display the log for error messages.
Step 20
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the traffic to quit flowing over Portchannel 20 when Mod 3 is reset because Mod 3 effects
Portchannels 20, as well as 1, 70 and 71. So SH1-109 takes over as the FHR due to the greater
bandwidth (i.e. more active ports/portchannel). Once the ports on SH1-110 became active again, we
expect the traffic to switch back over to SH1-110.
•
We expect HSRP on SH1-109 to take over when all 4 GE interfaces are failed on portchannel 20 of
SH1-110.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 103
GEM Failover with Attached HSRP Groups Test Results
Test
Result
GEM Failover with Attached HSRP Groups
Pass
Enhanced Interior Gateway Routing Protocol
The Enhanced Interior Gateway Routing Protocol (EIGRP) is an enhanced version of the IGRP protocol
developed by Cisco Systems. Enhanced IGRP uses the same distance vector algorithm and distance
information as IGRP. However, the convergence properties and the operating efficiency of Enhanced
IGRP have improved significantly over IGRP.
Cisco IOS Release 12.1(13)E13
437
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
The convergence technology is based on research conducted at SRI International and employs an
algorithm referred to as the Diffusing Update Algorithm (DUAL). This algorithm guarantees loop-free
operation at every instant throughout a route computation and allows all devices involved in a topology
change to synchronize at the same time. Routers that are not affected by topology changes are not
involved in recomputations. The convergence time with DUAL rivals other routing protocol.
The following tests were performed:
•
EIGRP Summarization, page 438
•
EIGRP Redistribution, page 439
EIGRP Summarization
This test verified manual EIGRP summarization by using the ip summary-address interface
configuration command.
Several /24 networks are known via EIGRP by device SH1-101 that can be summarized as a single /22
network on the portchannels of devices SH1-99 and SH1-100 (portchannels 14 and 15). This test will
involve the summarization of the routes 172.31.20.0/24 to 172.31.23.0/24 into 172.31.20.0/22.
Devices under test: SH1-99, SH1-100, and SH1-101.
Test Procedure
The procedure used to perform the EIGRP Summarization test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Run the test script that will perform Step 5 through Step 9.
Step 5
Show that the routes are not summarized and exist as /24 routes on SH1-101.
The routing entries for all four networks are shown as /24 networks.
Step 6
Configure the ip summary-address eigrp command on the portchannel 14 and portchannel 15 interfaces
of SH1-100 and SH1-99.
Step 7
Verify that the routes to the networks that were shown in now have an entry on the summary subnet of
172.31.20.0/22.
Summarization results in the four networks being known as /22 networks, now.
Step 8
Remove the summarization configuration statements applied in Step 4.
Step 9
Confirm that the routing entries appear as /24 networks, as they did above.
The four networks are again known as /24 networks:
Step 10
Display the log for error messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the /24 networks shown to be correctly summarized as /22 networks.
Cisco IOS Release 12.1(13)E13
438
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 104
EIGRP Summarization Test Results
Test
Result
EIGRP Summarization
Pass
EIGRP Redistribution
This test verified that EIGRP route redistribution works correctly, with and without access lists (ACLs)
and route map filtering.
Figure 38 shows SH1-99 and SH1-100 redistributing OSPF routes into EIGRP 1320 (of which SH1-101
is a member).
Figure 38
EIGRP Redistribution
The routes examined in this test are OSPF routes for 10,000 networks with a /24 mask, beginning at
160.1.1.0, 160.1.2.0, 160.1.3.0, and so on. These routes are fed directly into device SH1-97 via the
Pagent test tool.
Because redistribution is a part of the normal configuration in the Safe Harbor topology, the first part of
the test was to remove that configuration on devices SH1-99 and SH1-100, and verify that the 160.x.x.x
networks are no longer propagated to SH1-101 in the EIGRP domain. Redistribution will then be
configured with a route map added, which will allow only the odd-numbered networks to be redistributed
(160.1.1.0, 160.1.3.0, 160.1.5.0, and so on). The even-numbered networks will not appear in the routing
table of SH1-101. The final part of the test was to reconfigure redistribution as it is in the default setup
for this network to allow all 160.x.x.x networks to be redistributed.
Devices under test: SH1-97, SH1-99, SH1-100, and SH1-101.
Cisco IOS Release 12.1(13)E13
439
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
Test Procedure
The procedure used to perform the EIGRP Redistribution test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin the test script that will perform Step 5 through Step 15.
Results for /ats/local/tests/SafeHarbor/eigrp/SH1-eigrp_redistribution.tcl run at 2003-12-16-1240
Step 5
•
PASSED. SH1-99 and SH1-100 are redistributing OSPF into EIGRP and are running EIGRP 1320
•
PASSED. Routes are redistributing properly.
•
PASSED. 20124 subnets are known via EIGRP 1320 on SH1-101 (minimum 15000 should be
known).
•
PASSED. Routes have been removed from routing table on SH1-101.
•
PASSED. Route maps and acl's are properly configured on SH1-99, SH1-100.
•
PASSED. All odd routes are known and all even routes are unknown on SH1-101.
•
PASSED. SH1-101 has an appropriate number of routes.
•
PASSED. Routing table has been restored on SH1-101.
•
SH1-eigrp_redistribution test PASSED!
Show the default EIGRP configuration for devices SH1-99 and SH1-100.
Both SH1-99 and SH1-100 are running EIGRP 1320 and redistributing OSPF routes into EIGRP as part
of the default configuration.
Step 6
Show that, with the default EIGRP configuration (allowing redistribution), the 160.x.x.x networks are
propagated to SH1-101.
SH1-101 knows the two routes via EIGRP 1320, and notes that the routes have been redistributed by
EIGRP.
Step 7
Show that SH1-101 has a full routing table with ~20,000 total routes (10,000 routes from OSPF 1 and
10,000 routes from EIGRP 1320).
Initially, SH1-101 has roughly 20,000 EIGRP routes in its routing table. This includes 10,000 EIGRP
routes and 10,000 OSPF routes that have been redistributed into EIGRP.
Step 8
Remove the redistribution configuration from devices SH1-99 and SH1-100.
WIth the redistribution configurations removed, SH1-99 and SH1-100 should not redistribute OSPF
routes into EIGRP any longer.
Step 9
Confirm that the routes for the 160.x.x.x networks are no longer present in SH1-101 and that the routing
table has been trimmed by ~10,000 routes. It may be several minutes before the old routes time out and
are eliminated.
SH1-101 no longer knows the routes to the OSPF networks, as redistribution has been removed.
SH1-101 only has 10,000 routes in its routing table, now. These are the 10,000 EIGRP routes.
Step 10
Show the route-map OSPF2EIGRP-odd and the access-list 22 on SH1-99 and SH1-100.
The route-maps configured on SH1-99 and SH1-100 contain two sequences. The first denies any routes
matching access-list 22, and the second permits all other routes. Access-list 22 permits 160.x.x.x
networks with a 0 set as the last bit in the third octet. This means that the third octet has to be even to
Cisco IOS Release 12.1(13)E13
440
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Layer 3 Routing Features
pass the access-list. Combined with the route-map, which denies any routes passing access-list 22, only
routes with odd third octets will be allowed within the 160.x.x.x network. All other OSPF networks will
be allowed, as is determined by the second sequence statement in the route-map.
Step 11
Configure redistribution on SH1-99 and SH1-100, applying the route-map OSPF2EIGRP-odd, so that
the even networks are blocked from being redistributed.
Redistribution is configured with a route-map that allows only routes with an odd third octet.
Step 12
Confirm that the only routes for the 160.x.x.x networks that are on SH1-101 are for the odd networks,
160.1.1.0, 160.1.3.0, 160.1.5.0, and so on.
SH1-101 knows only those 160.x.x.x routes with an odd third octet. The route-map has correctly filtered
the redistribution.
Step 13
Show that the number of subnets in the routing table of SH1-101 has been decreased by 5000.
SH1-101 now has only about 17,500 EIGRP routes in its routing table. 5,000 160.x.x.x OSPF routes are
being generated by the Pagent test tool. Allowing only those routes with an odd third octet filters out
2,500 of those routes. There are 5,000 other routes from OSPF, also, for a total of 7,500 routes.
Step 14
Reconfigure the default redistribution configuration that was removed inStep 8.
The original redistribution configuration, allowing all OSPF routes to be redistributed, is reapplied.
Step 15
Confirm that all of the 160.x.x.x networks are redistributed into SH1-101 (odd and even), and that the
routing table on SH1-101 is back to normal status (seen in Step 5).
Both odd and even 160.x.x.x routes have been redistributed and are known by SH1-101 again. Again,
SH1-101 has a full routing table.
Step 16
Display the log for error messages.
Step 17
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that, when the default redistribution configuration is removed from SH1-99 and SH1-100,
none of the 10,000 OSPF routes will be propagated to SH1-101.
•
We expect that, when the route-map OSPF2EIGRP-odd is applied, with redistribution, on SH1-99
and SH1-100, only the odd subnets within 160.x.x.x will be propagated to SH1-101.
•
We expect that, when the default redistribution configuration is re-applied to SH1-99 and SH1-100,
all of the routes for the 160.x.x.x networks will be in the routing table of SH1-101 and that the
routing table will be populated correctly in its default state.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 105
EIGRP Redistribution Test Results
Test
Result
EIGRP Redistribution
Pass
Cisco IOS Release 12.1(13)E13
441
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Network Management Features
Network Management Features
Network management feature testing for Safe Harbor is described in the following sections:
•
Simple Network Management Protocol, page 442
•
TACACS, page 445
Simple Network Management Protocol
The Simple Network Management Protocol (SNMP) system consists of an SNMP manager, an SNMP
agent, and a MIB.
SNMP is an application-layer protocol that provides a message format for communication between
SNMP managers and agents.
Protos tests send exceptional elements to SNMP agents and managers in the form of requests and traps.
These elements are designed to provoke undesired behavior of the subject implementation. An
exceptional element is an input that might not have been considered properly when implementing the
software.
The following tests were performed:
•
Basic Functionality Shut/No Shut Interface—Supervisor 11, page 442
•
Basic Functionality Shut/No Shut Interface—Supervisor 22, page 443
•
Protos Negative Request Application, page 444
Basic Functionality Shut/No Shut Interface—Supervisor 11
This test verified the basic SNMP functionality of the Supervisor 11. In this procedure, SNMP traps are
created by a shut/no shut of an interface on device SH1-108. The logging messages created on the device
should be logged to the SNMP trap receiver.
Device under test: SH1-106.
Test Procedure
The procedure used to perform the Basic Functionality Shut/No Shut Interface—Supervisor 11 test
follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-106 is configured to send SNMP traps generated by configuration messages to the server
172.18.177.135
SH1-106 is configured to generate SNMP traps when configuration mode is entered and to send them to
the host 172.18.177.135.
Step 5
Enter and leave configuration mode on SH1-106, generating a log message.
Step 6
Verify that the traps are received by a machine that is set up as the SNMP trap receiver. View the output
from the log files of that machine.
Cisco IOS Release 12.1(13)E13
442
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Network Management Features
The host has logged an SNMP trap from the device under test, 10.194.17.106.
Step 7
Display the log for error messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that SNMP functions according to specifications, generating and sending a trap to the
configured host.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 106
Basic Functionality Shut/No Shut Interface—Supervisor 11 Test Results
Test
Result
Basic Functionality Shut/No Shut Interface—Supervisor 11
Pass
Basic Functionality Shut/No Shut Interface—Supervisor 22
This test verified the basic SNMP functionality of the supervisor 22. In this procedure, SNMP traps are
created by a shut/no shut of an interface on device SH1-110. The logging messages created on the device
should be logged to the SNMP trap receiver.
Device under test: SH1-110.
Test Procedure
The procedure used to perform the Basic Functionality Shut/No Shut Interface—Supervisor 22 test
follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-110 is configured to send SNMP traps generated by configuration messages to the server
172.18.177.135.
SH1-110 is configured to generate SNMP traps when configuration mode is entered and to send them to
the host 172.18.177.181.
Step 5
Enter and leave configuration mode on SH1-110, generating a log message.
Step 6
Verify that the traps are received by a machine that is set up as the SNMP trap receiver. View the output
from the log files of that machine.
The host has logged an SNMP trap from the device under test, 10.194.17.110:
Step 7
Display the log for error messages.
Step 8
Show the results of CPU and memory monitoring of the devices in the SH1 network.
Cisco IOS Release 12.1(13)E13
443
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Network Management Features
Expected Results
•
We expect that SNMP functions according to specifications, generating and sending a trap to the
configured host.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 107
Basic Functionality Shut/No Shut Interface—Supervisor 22 Test Results
Test
Result
Basic Functionality Shut/No Shut Interface—Supervisor 22
Pass
Protos Negative Request Application
This test verified that no SNMP vulnerabilities exist in the Native Cisco IOS code. Protos testing
involves sending erroneous SNMP packets to the device under test. These tests are run on all
permutations of supervisor and MSFC. This is a negative test, so the only verification is that the DUT
was unaffected.
Test Procedure
The procedure used to perform the Protos Negative Request Application test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Start background unicast and multicast traffic (rate=10,000 pps for unicast traffic and 1000 pps for
multicast traffic). Streams need to be configured to play for 5 minutes.
Step 5
Verify the SNMP Community String settings default.
Step 6
Execute the protos traffic generation scripts. The protos test cases will be sent to each DUT using
packetmaster test engine.
Note
With the options given above, each test takes about 1 min to complete, "delay" and "replywait" are in
milliseconds. However, if a router crashes or hangs without providing the information needed to verify
this bug the parameters may be adjusted. If detailed information about the SNMP packets is required use
the '-showreply -zerocase' options. Running in this manner takes several hours.
Step 7
After background traffic is done, verify no packets were lost. Show results.
Step 8
Display the log for error messages.
Step 9
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect all DUTs to not drop any background traffic while running the test.
Cisco IOS Release 12.1(13)E13
444
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Network Management Features
•
We expect all DUTs to not pause indefinitely, reload, or give trace backs while running the test.
Results
Table 108
Protos Negative Request Application Test Results
Test
Result
Protos Negative Request Application
Pass
TACACS
Terminal Access Controller Access Control System (TACACS) is an authentication protocol that
provides remote access authentication and related services, such as event logging. User passwords are
administered in a central database rather than in individual routers, providing an easily scalable network
security solution.
Login authentication increases the security of the system by keeping unauthorized users from guessing
the password. The user is limited to a specific number of attempts to successfully log in to the switch. If
the user fails to authorize the password, the system delays access and captures the user ID and the IP
address of the station in the syslog file and in the SNMP trap.
The following test was performed:
•
User Authentication—Supervisor 11, page 445
•
User Authentication—Supervisor 22, page 446
User Authentication—Supervisor 11
This test verified that the TACACS login authentication works correctly on a supervisor 1 on MSFC 1
system. The server 172.18.177.132 is a TACACS server. It was used in this test as the source of user
authentication information.
Device under test: SH1-106.
Test Procedure
The procedure used to perform the User Authentication—Supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-106 has connectivity to the TACACS server 172.18.177.132.
The server is reachable.
Step 5
Configure SH1-106 to be a TACACS device with 172.18.177.132 as its server.
Step 6
Verify that user authentication is necessary on SH1-106. Telnet from SH1-105 to SH1-106.
Authentication works as designed.
Step 7
Shut down the interface connecting SH1-106 with the TACACS server.
Step 8
Verify that SH1-106 no longer has connectivity to the TACACS server.
Cisco IOS Release 12.1(13)E13
445
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Network Management Features
Step 9
Telnet from SH1-105 to SH1-106 and verify that the login process falls back to IOS default.
Step 10
Remove the TACACS configuration from SH1-106.
Step 11
Bring the flashnet interface back online.
Step 12
Display the log for error messages.
Step 13
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that TACACS login authentication works correctly.
•
We expect that when the TACACS server becomes unavailable, the login process will fall back to
the IOS default.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 109
User Authentication—Supervisor 11 Test Results
Test
Result
User Authentication—Supervisor 11
Pass
User Authentication—Supervisor 22
This test verified that the TACACS login authentication works correctly on a supervisor 2/msfc2 system.
The server 172.18.177.132 is a TACACS server. It was used in this test as the source of user
authentication information.
Devices under test: SH1-110
Note
Use console on access server (172.18.177.171 2110) to get to SH1-110, not telnet.
Test Procedure
The procedure used to perform the User Authentication—Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that SH1-110 has connectivity to the TACACS server 172.18.177.132.
Step 5
Configure SH1-110 to be a TACACS device with 172.18.177.132 as its server.
Step 6
Verify that user authentication is necessary on SH1-110. Telnet from SH1-104 to SH1-110.
Step 7
Shut down the interface connecting SH1-110 with the TACACS server.
Step 8
Verify that SH1-110 no longer has connectivity to the TACACS server.
Step 9
Telnet SH1-104 to SH1-110 from and verify that the login process falls back to IOS default.
Cisco IOS Release 12.1(13)E13
446
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Step 10
Remove the TACACS configuration from SH1-110.
Step 11
Bring the flashnet interface back online.
Step 12
Display the log for error messages.
Step 13
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect the TACACS login authentication to work correctly.
•
We expect that if the TACACS server becomes unavailable, the login process will fall back to the
IOS default.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 110
User Authentication—Supervisor 22 Test Results
Test
Result
User Authentication—Supervisor 22
Pass
Miscellaneous Features
Miscellaneous features tested for Safe Harbor are described in the following sections:
•
Dynamic Host Control Protocol, page 447
•
Switched Port Analyzer, page 450
•
Access Control Lists, page 452
•
Parser, page 458
•
Show-All Script via SSH Supervisor 11, page 460
•
Network Time Protocol, page 472
•
Syslog, page 476
•
User Datagram Protocol Broadcast Flooding, page 477
•
System Upgrade, page 480
•
Secure Shell, page 485
Dynamic Host Control Protocol
As explained in RFC 2131, Dynamic Host Configuration Protocol, DHCP provides configuration
parameters to Internet hosts. DHCP consists of two components: a protocol for delivering host-specific
configuration parameters from a DHCP Server to a host and a mechanism for allocating network
addresses to hosts. DHCP is built on a client/server model, where designated DHCP Server hosts allocate
network addresses and deliver configuration parameters to dynamically configured hosts.
The following tests were performed:
Cisco IOS Release 12.1(13)E13
447
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
•
Basic DHCP—Supervisor 11, page 448
•
Basic DHCP—Supervisor 22, page 449
Basic DHCP—Supervisor 11
The diagram below shows the basic steps that occur when a DHCP client requests an IP address from a
DHCP Server. The client, Host A, sends a DHCPDISCOVER broadcast message to locate a Cisco IOS
DHCP Server. A DHCP Server offers configuration parameters (such as an IP address, a MAC address,
a domain name, and a lease for the IP address) to the client in a DHCPOFFER unicast message.
Since the DHCPDISCOVER and DHCPREQUEST packets are broadcast, only hosts on the same LAN
segment will receive them. If the DHCP server is on a different LAN segment, additional configuration
is necessary in order for the server to receive the client's packets. On the router interface which is on a
directly connected LAN segment with the client, configure an ip helper-address pointing to the DHCP
server. This will enable the forwarding of User Datagram Protocol (UDP) broadcasts, including BOOTP
and DHCP, received on that interface to the DHCP server.
Figure 39 shows the basic DHCP supervisor 11 topology.
Figure 39
Basic DHCP—Sup 11 Topology
Test Procedure
The procedure used to perform the Basic DHCP—Supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the DUT has an ip helper address a configured on the incoming interface.
On the incoming interface, verify that the command ip helper address <ip address> is
configured, and that the ip address specified is an address on the DHCP server. Note the IP address of
this router, and any others addresses in use on this segment. These will need to be excluded from the
DHCP address pool.
Step 5
Verify that the DHCP server is configured on the device specified by the ip helper address (i.e. SH1-98).
Verify that the 'no dhcp server conflict logging' is configured. Verify that all the router ip addresses on
the client subnet have been excluded. Verify that a DHCP pool for the client subnet has been configured.
Step 6
Clear any previous DHCP server statistics on the DHCP server and enable DHCP debugging (on
SH1-98)
Verify that the server stats have been zeroed out.
Step 7
Launch, configure, and run the script that will initiate a DHCP request from the IXIA test tool.
Cisco IOS Release 12.1(13)E13
448
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Step 8
Verify that the DHCP Discover and Request messages are forwarded by the DUT to the DHCP server.
Verify that a DHCPDISCOVER message was received from the script through the DUT as relay. Verify
that after the DHCPOFFER is sent, a DHCPREQUEST is received from the same client.
Step 9
Turn off DHCP debugging on the DHCP server (SH1-98)
Step 10
Display the log for error messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that all DHCP broadcast messages sent from the IXIA will be forwared to the DHCP
server.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 111
Basic DHCP—Supervisor 11 Test Results
Test
Result
Basic DHCP—Supervisor 11
Pass
Basic DHCP—Supervisor 22
The diagram below shows the basic steps that occur when a DHCP client requests an IP address from a
DHCP Server. The client, Host A, sends a DHCPDISCOVER broadcast message to locate a Cisco IOS
DHCP Server. A DHCP Server offers configuration parameters (such as an IP address, a MAC address,
a domain name, and a lease for the IP address) to the client in a DHCPOFFER unicast message.
Since the DHCPDISCOVER and DHCPREQUEST packets are broadcast, only hosts on the same LAN
segment will receive them. If the DHCP server is on a different LAN segment, additional configuration
is necessary in order for the server to receive the client's packets. On the router interface which is on a
directly connected LAN segment with the client, configure an ip helper-address pointing to the DHCP
server. This will enable the forwarding of User Datagram Protocol (UDP) broadcasts, including BOOTP
and DHCP, received on that interface to the DHCP server.
Figure 40 shows the basic DHCP supervisor 11 topology.
Figure 40
Basic DHCP—Sup 22 Topology
Cisco IOS Release 12.1(13)E13
449
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Test Procedure
The procedure used to perform the Basic DHCP—Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the DUT has an ip helper address a configured on the incoming interface.
On the incoming interface, verify that the command ip helper address <ip address> is configured, and
that the ip address specified is an address on the DHCP server. Note the ip address of this router, and any
others addresses in use on this segment. These will need to be excluded from the DHCP address pool.
Step 5
Verify that the DHCP server is configured on the device specified by the ip helper address.
Verify that the 'no dhcp server conflict logging' is configured. Verify that all the router ip addresses on
the client subnet have been excluded. Verify that a DHCP pool for the client subnet has been configured.
Step 6
Clear any previous DHCP server statistics on the DHCP server and enable DHCP debugging.
Verify that the server stats have been zeroed out.
Step 7
Launch, configure, and run the script that will initiate a DHCP request from the IXIA test tool.
Step 8
Verify that the DHCP Discover and Request messages are forwarded by the DUT to the DHCP server.
Verify that a DHCPDISCOVER message was received from the script through the DUT as relay. Verify
that after the DHCPOFFER is sent, a DHCPREQUEST is received from the same client.
Step 9
Turn off DHCP debugging on the DHCP server.
Step 10
Display the log for error messages.
Step 11
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that all DHCP broadcast messages sent from the IXIA will be forwarded to the DHCP
server.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 112
Basic DHCP—Supervisor 22 Test Results
Test
Result
Basic DHCP—Supervisor 22
Pass
Switched Port Analyzer
Local switched port analyzer (SPAN) selects network traffic to send to a network analyzer such as a
switch probe device or other Remote Monitoring (RMON) probe. SPAN does not affect the switching of
network traffic on source ports or VLANs. SPAN sends a copy of the packets received or sent by the
source ports and VLANs to the destination port. The destination port must be dedicated for SPAN use.
Cisco IOS Release 12.1(13)E13
450
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
The following test was performed:
•
SPAN Basic Functionality, page 451
SPAN Basic Functionality
This test verified the basic functionality of the SPAN feature across both the Supervisor 1 and Supervisor
2 platforms, and across a number of different modules. Two multicast streams and six unicast streams
with.will be sent into the network at Dista-2. There were six receivers, all on Dista-1. Traffic passed
through SH1-110 (Sup22), SH1-108 (Sup12), SH1-106 (Sup11), and SH1-102 (Sup22) along the way to
the two destinations. There are six interfaces in these four devices configured to monitor the multicast
traffic. These six interfaces are on WS-X6816-GBIC, and WS-X6408-GBIC module.
Devices under test:.SH1-102, SH1-106, SH1-108, SH1-110
Test Procedure
The procedure used to perform the SPAN Basic Functionality test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Configure the span sessions on SH1-102, SH1-106, SH1-108 and SH1-110 after clearing any existing
ones.
Step 5
Clear the counters on all four devices.
Step 6
Begin an IXIA stream sending 300,000 packets from multiple sources to multiple destinations. The
Background Unicast and Test Multicast traffic is used here; the Background Multicast traffic is not used.
Step 7
Compare the counters from each monitored interface with the packets reported received by IXIA.
Step 8
Remove the SPAN configurations from the devices.
Step 9
Display the log for error messages.
Step 10
Verify that there were no significant impacts on the CPU or memory of the devices under test.
Expected Results
•
We expect that each of the packets sent in the test traffic stream will be duplicated on each of the
four monitor destination interfaces.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 113
SPAN Basic Functionality Test Results
Test
Result
SPAN Basic Functionality
Pass
Cisco IOS Release 12.1(13)E13
451
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Access Control Lists
Access control lists (ACLs) are used to classify traffic and permit or deny forwarding based on this
classification.
The following tests were performed:
•
ACL 110 Supervisor 11, page 452
•
ACL 110 Supervisor 12, page 453
•
ACL 110 Supervisor 22, page 454
•
ACL 131 Supervisor 11, page 455
•
ACL 131 Supervisor 12, page 456
•
ACL 131 Supervisor 22, page 457
ACL 110 Supervisor 11
ACL 110 is a 1404 line access list taken from customer configuration. Our ACL test script configures
this ACL on a router. For each line of the ACL, the script creates a stream on an IXIA box that matches
the ACL; 10,000 packets from each stream are sent through the router and back to the IXIA. The script
then checks the IXIA statistics to verify that 10,000 packets were received for each stream that matched
a permit, and that no packets were received for each stream that matched a deny. This script is run against
a supervisor 11.
Test Procedure
The procedure used to perform the ACL 110 Supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin ACL test script on SH1-105 which will configure ACL 110 on the DUT and send traffic against
each line of the ACL to verify functionality.
Step 5
Using the script's output file, verify that all packets were permitted/denied correctly. Verify that the CPU
and memory should not suffer severe or sustained impact during the test on the DUT.
All packets were permitted or denied correctly.
Step 6
Display the log for error messages.
Step 7
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect each DUT will not permit any denied traffic, and will not deny any permitted traffic.
•
We expect all traffic to be hardware-switched with no permitted packets dropped.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco IOS Release 12.1(13)E13
452
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Results
Table 114
ACL 110 Supervisor 11 Test Results
Test
Result
ACL 110 Supervisor 11
Pass
ACL 110 Supervisor 12
ACL 110 is a 1404 line access list taken from customer configuration. Our ACL test script configures
this ACL on a router. For each line of the ACL, the script creates a stream on an IXIA box that matches
the ACL; 10,000 packets from each stream are sent through the router and back to the IXIA. The script
then checks the IXIA statistics to verify that 10,000 packets were received for each stream that matched
a permit, and that no packets were received for each stream that matched a deny. This script is run against
a supervisor 12.
Test Procedure
The procedure used to perform the ACL 110 Supervisor 12 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin ACL test script on SH1-108 which will configure ACL 110 on the DUT and send traffic against
each line of the ACL to verify functionality.
Step 5
Using the script's output file, verify that all packets were permitted/denied correctly. Verify that the CPU
and memory should not suffer severe or sustained impact during the test on the DUT.
All packets were permitted or denied correctly.
Step 6
Display the log for error messages.
Step 7
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect each DUT will not permit any denied traffic, and will not deny any permitted traffic.
•
We expect all traffic to be hardware-switched with no permitted packets dropped.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 115
ACL 110 Supervisor 12 Test Results
Test
Result
ACL 110 Supervisor 12
Pass
Cisco IOS Release 12.1(13)E13
453
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
ACL 110 Supervisor 22
ACL 110 is a 1404 line access list taken from customer configuration. Our ACL test script configures
this ACL on a router. For each line of the ACL, the script creates a stream on an IXIA box that matches
the ACL; 10,000 packets from each stream are sent through the router and back to the IXIA. The script
then checks the IXIA statistics to verify that 10,000 packets were received for each stream that matched
a permit, and that no packets were received for each stream that matched a deny. This script is run against
a supervisor 22.
Test Procedure
The procedure used to perform the ACL 110 Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin ACL test script on SH1-102 which will configure ACL 110 on the DUT and send traffic against
each line of the ACL to verify functionality.
Step 5
Using the script's output file, verify that all packets were permitted/denied correctly. Verify that the CPU
and memory should not suffer severe or sustained impact during the test on the DUT.
All packets were permitted or denied correctly.
Note
There was an ACL failure on a single permit ACL because the host portion was denied by a previous
ACL. This is expected.
Step 6
Display the log for error messages.
Step 7
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect each DUT will not permit any denied traffic, and will not deny any permitted traffic.
•
We expect all traffic to be hardware-switched with no permitted packets dropped.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 116
ACL 110 Supervisor 22 Test Results
Test
Result
ACL 110 Supervisor 22
Pass
Cisco IOS Release 12.1(13)E13
454
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
ACL 131 Supervisor 11
ACL 131 is a 2985 line access control list taken from a customer configuration. Our ACL test script
configures this ACL on a router. For each line of the ACL, the script creates a stream on an IXIA box
that matches the ACL; 10,000 packets from each stream are sent through the router and back to the IXIA.
The script then checks the IXIA statistics to verify that 10,000 packets were received for each stream
that matched a permit, and that no packets were received for each stream that matched a deny.
Test Procedure
The procedure used to perform the ACL 131 Supervisor 11 test follows:
Note
To fit this ACL in the TCAM you need to be using the ODM ACL merge algorithm. This feature is not
supported until Cisco IOS Release 12.1(11b)E4. Until then we must split the ACL into two ACLs and
run them separately.
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin ACL test script on SH1-106 which will configure ACL 131 on the DUT and send traffic against
each line of the ACL to verify functionality.
Step 5
Verify using script output file that all packets were permitted/denied correctly.
All packets were permitted or denied correctly.
Step 6
Display the log for error messages.
Step 7
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect each DUT will not permit any denied traffic, and will not deny any permitted traffic.
•
We expect all traffic to be hardware-switched with no permitted packets dropped.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 117
ACL 131 Supervisor 11 Test Results
Test
Result
ACL 131 Supervisor 11
Pass
Cisco IOS Release 12.1(13)E13
455
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
ACL 131 Supervisor 12
ACL 131 is a 2985 line access control list taken from a customer configuration. Our ACL test script
configures this ACL on a router. For each line of the ACL, the script creates a stream on an IXIA box
that matches the ACL; 10,000 packets from each stream are sent through the router and back to the IXIA.
The script then checks the IXIA statistics to verify that 10,000 packets were received for each stream
that matched a permit, and that no packets were received for each stream that matched a deny.
Test Procedure
The procedure used to perform the ACL 131 Supervisor 12 test follows:
Note
To fit this ACL in the TCAM you need to be using the ODM ACL merge algorithm. This feature is not
supported until Cisco IOS Release 12.1(11b)E4. Until then we must split the ACL into two ACLs and
run them separately.
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin ACL test script on SH1-108 which will configure ACL 131 on the DUT and send traffic against
each line of the ACL to verify functionality.
Step 5
Verify using script output file that all packets were permitted/denied correctly.
All packets were permitted or denied correctly.
Note
All ACL's using 172.31.32.x failed because they matched the port on SH1-108 that directly connected
to the IXIA port. This caused this path to be preferred over the routed path that the script was expecting.,
the expected path had zero packets. This is not an error, just a quirk of the way the script generates IP
addresses.
Step 6
Display the log for error messages.
Step 7
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect each DUT will not permit any denied traffic, and will not deny any permitted traffic.
•
We expect all traffic to be hardware-switched with no permitted packets dropped.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 118
ACL 131 Supervisor 12 Test Results
Test
Result
ACL 131 Supervisor 12
Pass
Cisco IOS Release 12.1(13)E13
456
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
ACL 131 Supervisor 22
ACL 131 is a 2985 line access control list taken from a customer configuration. Our ACL test script
configures this ACL on a router. For each line of the ACL, the script creates a stream on an IXIA box
that matches the ACL; 10,000 packets from each stream are sent through the router and back to the IXIA.
The script then checks the IXIA statistics to verify that 10,000 packets were received for each stream
that matched a permit, and that no packets were received for each stream that matched a deny.
Test Procedure
The procedure used to perform the ACL 131 Supervisor 22 test follows:
Note
To fit this ACL in the TCAM you need to be using the ODM ACL merge algorithm. This feature is not
supported until Cisco IOS Release 12.1(11b)E4. Until then we must split the ACL into two ACLs and
run them separately.
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin ACL test script on SH1-110 which will configure ACL 131 on the DUT and send traffic against
each line of the ACL to verify functionality.
Step 5
Verify using script output file that all packets were permitted/denied correctly.
All packets were permitted or denied correctly.
Step 6
Display the log for error messages.
Step 7
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect each DUT will not permit any denied traffic, and will not deny any permitted traffic.
•
We expect all traffic to be hardware-switched with no permitted packets dropped.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 119
ACL 131 Supervisor 22 Test Results
Test
Result
ACL 131 Supervisor 22
Pass
Cisco IOS Release 12.1(13)E13
457
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Parser
Parser testing robustly exercises the command-line interface (CLI) of a router. The testing walks the
parser tree, executing completed commands and filling in options as it comes to them. Certain branches
of the parser tree were left out due to time constraints of the testing (for example, the show
tag-switching tdp, and show mpls commands.
The following tests were performed:
•
Show-All Script via Telnet Supervisor 11, page 458
•
Show-All Script via Telnet Supervisor 12, page 459
•
Show-All Script via Telnet Supervisor 22, page 459
•
Show-All Script via SSH Supervisor 11, page 460
•
Show-All Script via SSH Supervisor 12, page 461
•
Show-All Script via SSH Supervisor 22, page 462
Show-All Script via Telnet Supervisor 11
An automated script was used to test over 19,000 valid show and clear commands on a supervisor 11.
Certain commands were left out (for example, the show memory; show tag-switching tdp; show mpls)
due the to length of time they take to execute.
Test Procedure
The procedure used to perform the Show-All Script via Telnet Supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin executing show and clear commands on the devices under test.
There were no errors during the running of this test. Links to the various output files are provided:
SH1-105
Step 5
Display the log for error messages.
Step 6
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 120
Show-All Script via Telnet Supervisor 11 Test Results
Test
Result
Show-All Script via Telnet Supervisor 11
Pass
Cisco IOS Release 12.1(13)E13
458
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Show-All Script via Telnet Supervisor 12
An automated script was used to test over 19,000 valid show and clear commands on a supervisor 12.
Certain commands were left out (for example, the show memory; show tag-switching tdp; show mpls)
due the to length of time they take to execute.
Test Procedure
The procedure used to perform the parser Show-All Script via Telnet Supervisor 12 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin executing show and clear commands on the devices under test.
There were no errors during the running of this test. Links to the various output files are provided:
Step 5
Display the log for error messages.
Step 6
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 121
Show-All Script via Telnet Supervisor 12 Test Results
Test
Result
Show-All Script via Telnet Supervisor 12
Pass
Show-All Script via Telnet Supervisor 22
An automated script was used to test over 19,000 valid show and clear commands on a supervisor 22.
Certain commands were left out (for example, the show memory; show tag-switching tdp; show mpls)
due the to length of time they take to execute.
Test Procedure
The procedure used to perform the Show-All Script via Telnet Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Begin executing show and clear commands on the devices under test.
There were no errors during the running of this test. Links to the various output files are provided:
Cisco IOS Release 12.1(13)E13
459
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Step 5
Display the log for error messages.
Step 6
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 122
Show-All Script via Telnet Supervisor 22 Test Results
Test
Result
Show-All Script via Telnet Supervisor 22
Pass
Show-All Script via SSH Supervisor 11
An automated script was used to test over 19,000 valid show and clear commands on a supervisor 11.
Certain commands were left out (for example, the show memory; show tag-switching tdp; show mpls)
due the to length of time they take to execute.
Test Procedure
The procedure used to perform the Show-All Script via SSH Supervisor 11 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test
Step 4
Verify DUT is configured with a hostname, domain name, and TACACS authentication on VTY lines.
Step 5
Ensure the SSH server on DUT is enabled by generating an RSA key pair. Configure the VTY lines to
allow SSH, and verify that each DUT is accepting SSH connections.
Note
If in the following step you get the error message 'WARNING: REMOTE HOST IDENTIFICATION
HAS CHANGED!' this means that this device has generated a different key than last time this test was
performed. You will need to delete the line which contains the old key in the file ~/.ssh/known_hosts and
connect again.
Step 6
Begin executing show and clear commands on the devices under test.
Step 7
Display the log for error messages.
There were no errors during the running of this test. Links to the various output files are provided:
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco IOS Release 12.1(13)E13
460
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Expected Results
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 123
Show-All Script via SSH Supervisor 11 Test Results
Test
Result
Show-All Script via SSH Supervisor 11
Pass
Show-All Script via SSH Supervisor 12
An automated script was used to test over 19,000 valid show and clear commands on a supervisor 12.
Certain commands were left out (for example, the show memory; show tag-switching tdp; show mpls)
due the to length of time they take to execute.
Test Procedure
The procedure used to perform the Show-All Script via SSH Supervisor 12 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify each DUT is configured with a hostname, domain name, and TACACS authentication on VTY
lines.
Step 5
Ensure the SSH server on each DUT is enabled by generating an RSA key pair. Configure the VTY lines
to allow SSH, and verify that each DUT is accepting SSH connections.
Note
If in the following step you get the error message 'WARNING: REMOTE HOST IDENTIFICATION
HAS CHANGED!' this means that this device has generated a different key than last time this test was
performed. You will need to delete the line which contains the old key in the file ~/.ssh/known_hosts and
connect again.
Step 6
Begin executing show and clear commands on the devices under test.
Step 7
Display the log for error messages.
There were no errors during the running of this test. Links to the various output files are provided:
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Cisco IOS Release 12.1(13)E13
461
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Results
Table 124
Show-All Script via SSH Supervisor 12 Test Results
Test
Result
Show-All Script via SSH Supervisor 12
Pass
Show-All Script via SSH Supervisor 22
An automated script was used to test over 19,000 valid show and clear commands on a supervisor 22.
Certain commands were left out (for example, the show memory; show tag-switching tdp; show mpls)
due the to length of time they take to execute.
Test Procedure
The procedure used to perform the parser Show-All Script via SSH Supervisor 22 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify DUT is configured with a hostname, domain name, and TACACS authentication on VTY lines.
Step 5
Ensure the SSH server on each DUT is enabled by generating an RSA key pair. Configure the VTY lines
to allow SSH, and verify that each DUT is accepting SSH connections.
Note
If in the following step you get the error message 'WARNING: REMOTE HOST IDENTIFICATION
HAS CHANGED!' this means that this device has generated a different key than last time this test was
performed. You will need to delete the line which contains the old key in the file ~/.ssh/known_hosts and
connect again.
Step 6
Begin executing show and clear commands on the devices under test.
Step 7
Display the log for error messages.
There were no errors during the running of this test. Links to the various output files are provided:
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 125
Show-All Script via SSH Supervisor 22 Test Results
Test
Result
Show-All Script via SSH Supervisor 22
Pass
Cisco IOS Release 12.1(13)E13
462
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Network Address Translation
Two key problems facing the Internet are depletion of IP address space and scaling in routing. Network
Address Translation (NAT) is a feature that allows the IP network of an organization to appear from the
outside to use different IP address space than what it is actually using. Thus, NAT allows an organization
with non globally routable addresses to connect to the Internet by translating those addresses into
globally routable address space. NAT also allows a more graceful renumbering strategy for organizations
that are changing service providers or voluntarily renumbering into classless interdomain routing
(CIDR) blocks. NAT is also described in RFC 1631.
The following tests were performed:
•
Static 2 Hosts, page 463
•
Static 40 Hosts, page 464
•
Static 40 Hosts Extended, page 465
•
Static 2 Networks, page 466
•
Static Inside Dynamic Outside, page 467
•
Dynamic Inside Static Outside, page 468
•
Addition/Removal of NAT Statements, page 469
•
Static 40 Hosts Overnight, page 470
•
Increment Inside Random Outside with Match-Host, page 471
Static 2 Hosts
This test verified the basic functionality of the NAT feature on a supervisor 2 on MSFC 2. The DUT was
configured to translate outside global addresses into outside local addresses and inside global addresses
to inside local addresses. IXIA will send 1 million packets in each direction for each test using
overlapping inside and outside static NAT. IXIA will also send a background multicast stream from the
inside interface to the outside interface.
Device under test: SH1-97.
Test Procedure
The procedure used to perform the Static 2 Hosts test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Verify that the DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, ARP entries to next-hop routers, and monitor sessions for the inside and outside interfaces
setup, but not active.
Step 4
Clear statistics and counters, and begin transmitting unicast NAT traffic and multicast background
traffic. While traffic is transmitting, turn monitoring on the inside interface, then the outside interface,
and capture inbound and outbound packets on both interfaces. Verify the packets from the inside
interface have the inside local and outside local ip addresses, and the packets from the outside interface
have the inside global and outside global ip addresses.
Cisco IOS Release 12.1(13)E13
463
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Step 5
After traffic has completed, confirm that no packets were lost and stop SNMP data collection. Show
current status of NAT, interfaces, and buffers on the DUT. Confirm that the memory and CPU did not
suffer severe or sustained impact during the test on the DUT.
PASSED. Counted 2500000 packets during the test, and expected 2500000.
Step 6
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 7
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect all unicast packets to be translated correctly.
•
We expect all multicast packets to be forwarded correctly.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 126
Static 2 Hosts Test Results
Test
Result
Static 2 Hosts
Pass
Static 40 Hosts
This test verified the basic functionality of the NAT feature on a supervisor 2 or MSFC 2. The DUT was
configured to translate outside global addresses into outside local addresses and inside global addresses
to inside local addresses. IXIA will send 1 million packets in each direction for each test using
overlapping inside and outside static NAT. IXIA will also send a background multicast stream from the
inside interface to the outside interface.
Device under test: SH1-97.
Test Procedure
The procedure used to perform the Static 40 Hosts test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Verify that there are no alignment errors or other abnormal messages in the log, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices being tested.
Step 4
Verify DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, ARP entries to next-hop routers, and monitor sessions on inside and outside interfaces setup
but not active.
Step 5
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
While traffic is sending, turn monitoring on the inside interface, then the outside interface, and capture
with a sniffer an inbound and outbound packet on both interfaces. Verify the packets from the inside
interface have the inside local and outside local ip addresses, and the packets from the outside interface
have the inside global and outside global ip addresses.
Cisco IOS Release 12.1(13)E13
464
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
From the NAT configuration in Step 4, we know that 10.2.2.X is the inside local and 10.50.50.X is the
outside local address. These are the addresses expected as both source and destination on the inside
interface. 100.100.100.X is the inside global and 10.2.2.X is the outside global address. These are the
addresses expected as both source and destination on the outside interface.
Step 6
After traffic has completed, confirm that no packets were lost and stop SNMP data collection. Show the
current status of NAT, the interfaces, and buffers on the DUT. Confirm that the memory and CPU did not
suffer severe or sustained impact during the test on the DUT.
PASSED. Counted 2500000 packets during the test, and expected 2500000.
Step 7
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 8
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect all unicast packets to be translated correctly.
•
We expect all multicast packets to be forwarded correctly.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 127
Static 40 Hosts Test Results
Test
Result
Static 40 Hosts
Pass
Static 40 Hosts Extended
This test verified the basic functionality of the NAT feature on a supervisor 2 or MSFC 2. The DUT was
configured to translate outside global addresses into outside local addresses and inside global addresses
to inside local addresses. IXIA will send 10 million packets in each direction for each test using
overlapping inside and outside static NAT. IXIA will also send a background multicast stream from the
inside interface to the outside interface.
Device under test: SH1-97.
Test Procedure
The procedure used to perform the Static 40 Hosts Extended test follows:
Step 1
Use the appropriate script to gather preliminary logging and version information.
Step 2
Verify DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, arp entries to next-hop routers, and monitor sessions on inside and outside interfaces setup but
not active.
Step 3
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
While traffic is sending, turn monitoring on the inside interface, then the outside interface, and capture
inbound and outbound packets on both interfaces. Verify the packets from the inside interface have the
inside local and outside local ip addresses, and the packets from the outside interface have the inside
global and outside global ip addresses.
Cisco IOS Release 12.1(13)E13
465
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Step 4
After traffic has completed, confirm that no packets were lost and stop SNMP data collection. Show the
current status for NAT, interfaces, and buffers on the DUT. Confirm that the memory and CPU did not
suffer severe or sustained impact during the test on the DUT.
PASSED. Counted 20500000 packets during the test, and expected 20500000.
Step 5
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 6
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect all unicast packets to be translated correctly.
•
We expect all multicast packets to be forwarded correctly.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 128
Static 40 Hosts Extended Test Results
Test
Result
Static 40 Hosts Extended
Pass
Static 2 Networks
This test verified the basic functionality of the NAT feature on a supervisor 2 or MSFC 2. The DUT was
configured to translate outside global addresses into outside local addresses and inside global addresses
to inside local addresses. IXIA will send 1 million packets in each direction for each test using
overlapping inside and outside static NAT. IXIA will also send a background multicast stream from the
inside interface to the outside interface.
Device under test: SH1-97.
Test Procedure
The procedure used to perform the Static 2 Networks test follows:
Step 1
Use the appropriate script to gather preliminary logging and version information.
Step 2
Verify DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, ARP entries to next-hop routers, and monitor sessions on inside and outside interfaces setup
but not active.
Step 3
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
While traffic is sending, turn monitoring on the inside interface, then the outside interface, and capture
with a sniffer an inbound and outbound packet on both interfaces. Verify the packets from the inside
interface have the inside local and outside local ip addresses, and the packets from the outside interface
have the inside global and outside global ip addresses.
Step 4
After traffic has completed, confirm that no packets were lost and stop SNMP data collection. Show
current status NAT, interfaces, and buffers on the DUT. Confirm that the memory and CPU did not suffer
severe or sustained impact during the test on the DUT.
Cisco IOS Release 12.1(13)E13
466
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Step 5
PASSED. Counted 2500000 packets during the test, and expected 2500000.
Step 6
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 7
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect all unicast packets to be translated correctly.
•
We expect all multicast packets to be forwarded correctly.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 129
Static 2 Networks Test Results
Test
Result
Static 2 Networks
Pass
Static Inside Dynamic Outside
This test verified the basic functionality of the NAT feature on a supervisor 2 or MSFC 2. The DUT was
configured to translate outside global addresses into outside local addresses and inside global addresses
to inside local addresses. IXIA will send 1 million packets in each direction for each test using
overlapping inside and outside static NAT. IXIA will also send a background multicast stream from the
inside interface to the outside interface.
Device under test: SH1-97.
Test Procedure
The procedure used to perform the Static Inside Dynamic Outside test follows:
Step 1
Use the appropriate script to gather preliminary logging and version information.
Step 2
Verify DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, arp entries to next-hop routers, and monitor sessions on inside and outside interfaces setup but
not active.
Step 3
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
While traffic is sending, turn monitoring on the inside interface, then the outside interface, and capture
with a sniffer an inbound and outbound packet on both interfaces. Verify the packets from the inside
interface have the inside local and outside local ip addresses, and the packets from the outside interface
have the inside global and outside global ip addresses.
Step 4
After traffic has completed, confirm that no packets were lost and stop SNMP data collection. Show
current status NAT, interfaces, and buffers on the DUT. Confirm that the memory and CPU did not suffer
severe or sustained impact during the test on the DUT.
•
Step 5
PASSED. Counted 2500000 packets during the test, and expected 2500000.
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Cisco IOS Release 12.1(13)E13
467
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Step 6
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Expected Results
The following test results are expected:
•
We expect all unicast packets to be translated correctly.
•
We expect all multicast packets to be forwarded correctly.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 130
Static Inside Dynamic Outside Test Results
Test
Result
Static Inside Dynamic Outside
Pass
Dynamic Inside Static Outside
This test verified the basic functionality of the NAT feature on a supervisor 2 or MSFC 2. The DUT was
configured to translate outside global addresses into outside local addresses and inside global addresses
to inside local addresses. The DUT for this test is SH1-97. IXIA will send 1 million packets in each
direction for each test using overlapping inside and outside static NAT. IXIA will also send a background
multicast stream from the inside interface to the outside interface.
Test Procedure
The procedure used to perform the Dynamic Inside Static Outside test follows:
Step 1
Use the appropriate script to gather preliminary logging and version information.
Step 2
Verify DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, arp entries to next-hop routers, and monitor sessions on inside and outside interfaces setup but
not active.
Step 3
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
While traffic is sending, turn monitoring on the inside interface, then the outside interface, and capture
with a sniffer an inbound and outbound packet on both interfaces. Verify the packets from the inside
interface have the inside local and outside local ip addresses, and the packets from the outside interface
have the inside global and outside global ip addresses.
Step 4
After traffic has completed, confirm that no packets were lost and stop SNMP data collection. Show
current status NAT, interfaces, and buffers on the DUT. Confirm that the memory and CPU did not suffer
severe or sustained impact during the test on the DUT.
PASSED. Counted 2500000 packets during the test, and expected 2500000.
Step 5
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 6
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Cisco IOS Release 12.1(13)E13
468
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Expected Results
•
We expect all unicast packets to be translated correctly.
•
We expect all multicast packets to be forwarded correctly.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 131
Dynamic Inside Static Outside Test Results
Test
Result
Dynamic Inside Static Outside
Pass
Addition/Removal of NAT Statements
This test measured the impact on the CPU from the removal and addition of NAT statements while those
translations were in use. There are four NAT statements on switch SH1-97, translating four outside
global addresses into four outside local addresses. Traffic is passed with source IP addresses of the four
outside global addresses. As traffic is being passed, the NAT statements for those four particular
translations are removed, and then readded, while the CPU was being monitored.
Test Procedure
The procedure used to perform the Addition/Removal of NAT Statements test follows:
Step 1
Use the appropriate script to gather preliminary logging and version information.
Step 2
Verify DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, arp entries to next-hop routers, and monitor sessions on inside and outside interfaces setup but
not active.
Step 3
Begin sending unicast NAT traffic. While traffic is sending, turn monitoring on the inside interface, then
the outside interface, and capture with a sniffer an inbound and outbound packet on both interfaces.
Verify the packets from the inside interface have the inside local and outside local ip addresses, and the
packets from the outside interface have the inside global and outside global ip addresses.
Step 4
Remove each of the static NAT statements every 10 seconds and re-add them. Then remove all 4 NAT
statements at once, and then re-add them. Finally remove the first two NAT statements 10 seconds apart,
followed by removing the last two statements at once. Then re-add all four statements.
Step 5
After NAT statements re-added, turn monitoring on the inside interface, then the outside interface, and
capture with a sniffer an inbound and outbound packet on both interfaces. Verify the packets from the
inside interface have the inside local and outside local ip addresses, and the packets from the outside
interface have the inside global and outside global ip addresses.
Step 6
After traffic has completed, show current status of NAT, interfaces, and buffers on the DUT. Confirm that
the memory and CPU did not suffer severe or sustained impact during the test on the DUT.
Step 7
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 8
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Cisco IOS Release 12.1(13)E13
469
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Expected Results
•
We expect all unicast packets to be translated correctly.
•
We expect all multicast packets to be forwarded correctly.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 132
Addition/Removal of NAT Statements Test Results
Test
Result
Addition/Removal of NAT Statements
Pass
Static 40 Hosts Overnight
This test verified the basic functionality of the NAT feature on a supervisor 2 or MSFC 2. The DUT was
configured to translate outside global addresses into outside local addresses and inside global addresses
to inside local addresses. IXIA will send 400 million packets in each direction for each test using
overlapping inside and outside static NAT. IXIA will also send a background multicast stream from the
inside interface to the outside interface.
Device under test: SH1-97.
Test Procedure
The procedure used to perform the Static 40 Hosts Overnight test follows:
Step 1
Begin monitoring the DUT's CPU utilization and memory usage.
Step 2
Verify DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, arp entries to next-hop routers, and monitor sessions on inside and outside interfaces setup but
not active.
Step 3
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
While traffic is sending, turn monitoring on the inside interface, then the outside interface, and capture
with a sniffer an inbound and outbound packet on both interfaces. Verify the packets from the inside
interface have the inside local and outside local ip addresses, and the packets from the outside interface
have the inside global and outside global ip addresses.
Step 4
After traffic has completed, confirm that no packets were lost and stop SNMP data collection. Show
current status NAT, interfaces, and buffers on the DUT. Confirm that the memory and CPU did not suffer
severe or sustained impact during the test on the DUT.
Note
Although the script reported the FAILED because it counted 804999999 packets during the test, but
expected 805000000, this intermittent anomaly of losing 1 packet is being investigated but is not
considered to be a failure of the test.
Step 5
Stop the script that collects logging information and SNMP data from the devices in the SH1 network.
Step 6
Verify that the CPU and memory did not suffer from severe, sustained, or unacceptable impact.
Cisco IOS Release 12.1(13)E13
470
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Expected Results
•
We expect all unicast packets to be translated correctly.
•
We expect all multicast packets to be forwarded correctly.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 133
Static 40 Hosts Overnight Test Results
Test
Result
Static 40 Hosts Overnight
Pass
Increment Inside Random Outside with Match-Host
This test verified the basic functionality of the NAT feature on a sup2/msfc2. The device under test was
configured to translate outside global addresses into outside local addresses and inside global addresses
to inside local addresses. IXIA sent 1 million packets in each direction for each test using overlapping
inside and outside static NAT. IXIA also sent a background multicast stream of 500,000 packets from
the inside interface to the outside interface.
Device under test: SH1-97
Test Procedure
The procedure used to perform the Increment Inside Random Outside with Match-Host test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify DUT has NAT inside and outside interfaces, static NAT translations, static routes to NAT
networks, ARP entries to next-hop routers, and monitor sessions on inside and outside interfaces setup
but not active.
Step 5
Clear statistics and counters, and begin sending unicast NAT traffic and multicast background traffic.
While traffic is sending, turn monitoring on the inside interface, then the outside interface, and capture
with a sniffer an inbound and outbound packet on both interfaces. Verify the packets from the inside
interface have the inside local and outside local ip addresses, and the packets from the outside interface
have the inside global and outside global ip addresses.
Step 6
After traffic has completed, confirm that no packets were lost and stop SNMP data collection. Show
current status NAT, interfaces, and buffers on the DUT. Confirm that the memory and CPU did not suffer
severe or sustained impact during the test on the DUT.
Step 7
Display the log for error messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Cisco IOS Release 12.1(13)E13
471
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Expected Results
•
We expect all unicast packets to be translated correctly.
•
We expect all multicast packets to be forwarded correctly.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 134
Increment Inside Random Outside with Match-Host Test Results
Test
Result
Increment Inside Random Outside with Match-Host
Pass
Network Time Protocol
Network Time Protocol (NTP) synchronizes timekeeping among a set of distributed time servers and
clients. This synchronization allows events to be correlated when system logs are created and other
time-specific events occur.
An NTP server must be accessible by the client switch. NTP runs over User Datagram Protocol (UDP),
that runs over IP. NTP is extremely efficient; no more than one packet per minute is necessary to
synchronize two machines to within a millisecond of one another.
NTP testing verified basic functionality. It used a local Sun server (IP address: 172.18.177.132) as the
NTP server. SH1-104 was configured as the NTP client.
The following tests were performed:
•
Basic NTP Functionality—Supervisor 1, page 472
•
Basic NTP Functionality—Supervisor 2, page 473
•
NTP Failover—Supervisor 1 and Supervisor 2, page 474
Basic NTP Functionality—Supervisor 1
This test verified the basic functionality of NTP on the supervisor 1. It used a local Sun server (IP
address: 172.18.177.132), and a local Cisco 6500 router running native as NTP servers. SH1-106 was
configured as the NTP client.
Device under test: SH1-106.
Test Procedure
The procedure used to perform the Basic NTP Functionality—Supervisor 1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that there is one or more servers configured as the NTP server on the DUT.
The servers 172.18.177.132 (preferred) and 172.18.177.131 are configured as the NTP server on
SH1-106:
Cisco IOS Release 12.1(13)E13
472
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Step 5
Verify that the association between the NTP server and the client is active.
Both 172.18.177.131 and 172.18.177.132 are (~) configured as NTP servers on the DUT. Both the
configured servers show the same stratum value (st=2), making them equally qualified. The server
172.18.177.132 is the (*) master, and is synced to the DUT, though, because it was configured to be
preferred. 172.18.177.131 is shown as (+) selected, because it is qualified to be an NTP server:
Step 6
Verify that the NTP status is "synchronized" and that the time and date shown on SH1-104 are the same
as those shown on the server (NTP is working).
The ntp status on SH1-106 shows that the NTP server and the DUT are synchronized:
The times and dates from both the NTP server and the DUT match:
Step 7
Display the log for error messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that the test device is synchronized to the configured NTP server and that the clocks on
the device and the server are synchronized.
Results
Table 135
Basic NTP Functionality—Supervisor 1 Test Results
Test
Result
Basic NTP Functionality—Supervisor 1
Pass
Basic NTP Functionality—Supervisor 2
This test verified the basic functionality of NTP on the supervisor 2. It used a local Sun server (IP
address: 172.18.177.132), and a local Cisco 6500 router running native as NTP servers. SH1-104 was
configured as the NTP client.
Device under test: SH1-104.
Test Procedure
The procedure used to perform the Basic NTP Functionality—Supervisor 1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Verify that the supervisor is running the IOS version under test. Verify the uptime and that the box hasn't
reloaded unnecessarily. Verify that there is not any process spiking the CPU when the test begins.
Step 2
Display the log for error messages, and then clear it.
Display the log buffer to verify that there are no erroneous log messages. Then clear the log to verify
that error messages have not appeared during the test.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that there is one or more servers configured as the NTP server on the DUT.
Cisco IOS Release 12.1(13)E13
473
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
The servers 172.18.177.132 (preferred) and 172.18.177.131 are configured as the NTP server on the
DUT.
Step 5
Verify that the association between the NTP server and the client is active.
Both 172.18.177.131 and 172.18.177.132 are (~) configured as NTP servers on the DUT. Both the
configured servers show the same stratum value (st=2), making them equally qualified. The server
172.18.177.132 is the (*) master, and is synced to the DUT, though, because it was configured to be
preferred. 172.18.177.131 is shown as (+) selected, because it is qualified to be an NTP server:
Step 6
Verify that the NTP status is "synchronized" and that the time and date shown on SH1-104 are the same
as those shown on the server (NTP is working).
The status shows that the NTP server and SH1-104 are synchronized:
The times and dates from both the NTP server and the DUT match:
Step 7
Display the log for error messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that the test device is synchronized to the configured NTP server and that the clocks on
the device and the server are synchronized.
Results
Table 136
Basic NTP Functionality—Supervisor 2 Test Results
Test
Result
Basic NTP Functionality—Supervisor 2
Pass
NTP Failover—Supervisor 1 and Supervisor 2
Two NTP servers are configured on each device in the test network. This test verified the ability of the
device to switch over to the backup NTP server if the primary server fails.
Devices under test: SH1-106, and SH1-104.
Test Procedure
The procedure used to perform the NTP Failover—Supervisor 1 and Supervisor 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that the servers with IP addresses 172.18.177.131 and 172.18.177.132 (preferred) are configured
as the NTP servers on SH1-104 and SH1-106 and that 172.18.177.132 is synced to SH1-106 as the
master.
The two servers are configured on SH1-104.
Cisco IOS Release 12.1(13)E13
474
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
On SH1-104, both servers are (~) configured. The server 172.18.177.131 is (+) selected, as it is a
qualified NTP server. The server 172.18.177.132 is (*) master (synced).
SH1-104 is synchronized to the reference server, 172.18.177.132.
The two servers are configured on SH1-106:
On SH1-106, both servers are (~) configured. The server 172.18.177.131 is (+) selected, as it is a
qualified NTP server. The server 172.18.177.132 is (*) master (synced):
SH1-106 is synchronized to the reference server, 172.18.177.132:
Step 5
Note
Step 6
On the server 172.18.177.132, stop the NTP daemon.
You must have root authority.
Verify that the server 172.18.177.131 is now the master server for each SH1-104 and SH1-106 and that
NTP is functioning again. (This may take a long while, as the timeout interval is very lengthy.)
On SH1-104, both servers are (~) configured. The server 172.18.177.131 is now (*) master (synced),
while the server 172.18.177.132 is not even (+) selected:
SH1-104 is synchronized to the new reference server, 172.18.177.131:
On SH1-106, both servers are (~) configured. The server 172.18.177.131 is now (*) master (synced),
while the server 172.18.177.132 is not even (+) selected:
Note
Synchronization required 2+ hours to complete on some devices.
SH1-106 is synchronized to the new reference server, 172.18.177.131:
Step 7
Start the NTP daemon on the server 172.18.177.132 again and verify that it once again becomes the
active master server for SH1-104 and SH1-106. (Again, this may take a long while (e.g. 15 min), as the
timeout interval is very lengthy.)
Both SH1-104 and SH1-106 again have the original NTP status, with 172.18.177.132 as the NTP
server-of-choice:
Step 8
Display the log for error messages.
Step 9
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that the test device is synchronized to the configured NTP server and that the clocks on
the device and the server are synchronized.
Results
Table 137
NTP Failover—Supervisor 1 and Supervisor 2 Test Results
Test
Result
NTP Failover—Supervisor 1 and Supervisor 2
Pass
Cisco IOS Release 12.1(13)E13
475
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Syslog
The system log (syslog) protocol provides a transport to allow a machine to send event notification
messages across IP networks to event message collectors, that are also known as syslog servers.
The following tests were performed:
•
Basic Syslog Functionality—Supervisor 1, page 476
•
Basic Syslog Functionality—Supervisor 2, page 477
Basic Syslog Functionality—Supervisor 1
This test verified syslog functionality.
Device under test: SH1-105.
Test Procedure
The procedure used to perform the Basic Syslog Functionality—Supervisor 1 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that syslog is configured on the DUT and that the designated server is 172.18.177.132.
The DUT is configured to send logging messages to server 172.18.177.132.
Step 5
Enable the terminal monitor command on the DUT and enable IP PIM debugging for a short time.
Debug messages appeared on the terminal before debugging was turned off:
Step 6
Display output from the syslog server. Compare it to messages received on the DUT.
The syslog server logged the debug messages from SH1-105 (10.17.194.105):
Step 7
Display the log for error messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that each message logged to the VTY session should also be logged to the syslog server.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 138
Basic Syslog Functionality—Supervisor 1 Test Results
Test
Result
Basic Syslog Functionality—Supervisor 1
Pass
Cisco IOS Release 12.1(13)E13
476
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Basic Syslog Functionality—Supervisor 2
This test verified syslog functionality.
Device under test: SH1-104.
Test Procedure
The procedure used to perform the Basic Syslog Functionality—Supervisor 2 test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Verify that syslog is configured on SH1-104 and that the designated server is 172.18.177.132.
SH1-104 is configured to send log messages to the logging server, 172.18.177.132.
Step 5
Enable the terminal monitor command on SH1-104 and enable IP PIM debugging for a short time.
SH1-104 logged PIM debug messages to the terminal session.
Step 6
Display output from the syslog server. Compare it to messages received on SH1-104.
The debug messages that were displayed in the terminal session on SH1-104 were logged to the syslog
server and appear there.
Step 7
Display the log for error messages.
Step 8
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that each message logged to the VTY session should also be logged to the syslog server.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 139
Basic Syslog Functionality—Supervisor 2 Test Results
Test
Result
Basic Syslog Functionality—Supervisor 2
Pass
User Datagram Protocol Broadcast Flooding
A broadcast is a data packet that is destined for multiple hosts. Broadcasts can occur at the data link
layer and the network layer. Data-link broadcasts are sent to all hosts attached to a particular physical
network. Network layer broadcasts are sent to all hosts attached to a particular logical network. TCP/IP
supports the following types of broadcast packets:
•
All ones—By setting the broadcast address to all ones (255.255.255.255), all hosts on the network
receive the broadcast.
Cisco IOS Release 12.1(13)E13
477
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
•
Network—By setting the broadcast address to a specific network number in the network portion of
the IP address and setting all ones in the host portion of the broadcast address, all hosts on the
specified network receive the broadcast. For example, when a broadcast packet is sent with the
broadcast address of 131.108.255.255, all hosts on network number 131.108 receive the broadcast.
•
Subnet—By setting the broadcast address to a specific network number and a specific subnet
number, all hosts on the specified subnet receive the broadcast. For example, when a broadcast
packet is set with the broadcast address of 131.108.4.255, all hosts on subnet 4 of network 131.108
receive the broadcast.
Because broadcasts are recognized by all hosts, a significant goal of router configuration is to control
unnecessary proliferation of broadcast packets. Cisco routers support two kinds of broadcasts: directed
and flooded. A directed broadcast is a packet sent to a specific network or series of networks, whereas a
flooded broadcast is a packet sent to every network. In IP internetworks, most broadcasts take the form
of UDP broadcasts.
The following test was performed:
•
UDP Broadcast Flooding, page 478
UDP Broadcast Flooding
There are several facets to this test. An IXIA broadcast stream is used for each aspect of the procedure.
First, the broadcast stream is sent into the network at a single device. It is verified that this device
forwards the broadcast out all physical interfaces. Next the device is configured to use an IP helper
address, which will cause the IP destination portion of the header, originally a broadcast address, to be
replaced by a unicast address, destined for the IP helper address.
The IXIA streams that are configured have been done so with UDP port 53 (domain name system, DNS).
The next part of the procedure tests the functionality of the no ip forward-protocol command, that is
expected to halt the forwarding of any broadcasts using the protocol specified (in this case DNS).
Device under test: SH1-101.
Test Procedure
The procedure used to perform the UDP Broadcast Flooding test follows:
Step 1
Record the version, start time, and CPU utilization from each DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Step 4
Confirm that the ip helper-address command and the no ip forward-protocol commands
are not yet configured on the device.
Step 5
Begin the broadcast IXIA stream on Ix-16/8 (SH1-101 Fa9/6). The stream should have a length of 74
Bytes and be sent at a rate of 5,000 pps. The broadcast stream has a DMAC of FFFF.FFFF.FFFF and a
DIP of 255.255.255.255. This stream will come in on VLAN 40 and should be broadcast out all
interfaces carrying VLAN 40. Verify that it is.
The broadcasts are coming in on fa9/6 and being forwarded out fa9/4 and Po10.
Step 6
Configure an IP helper-address of 172.31.1.25 on the VLAN 40 interface of SH1-101. This IP address
belongs to the remote side of portchannel 14, connecting to SH1-99.
Step 7
Confirm that the traffic coming in is now being sent out Po14, as unicast traffic.
The packets are now being forwarded out gi3/10 of Po14 as unicast packets:
Cisco IOS Release 12.1(13)E13
478
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Step 8
Configure no ip forward-protocol udp domain globally on SH1-101. This will cause the router to stop
forwarding any UDP traffic with an L4 port of 53 (DNS). Confirm that traffic stops being sent out Po14.
The test packets are no longer being forwarded out gi3/10 of Po14.
Allow IP forwarding of DNS packets again, and confirm that unicast traffic is being sent to the IP
helper-address again.
Again, the test packets are being forwarded out gi3/10 of Po14.
Step 9
Remove the ip helper-address configuration from SH1-101
Step 10
Stop the IXIA traffic for about 2 minutes. Reconfigure the IXIA stream to send at a rate of 2500 pps,
instead of the previous 5000 pps.
The traffic was stopped at 4:07 pm
Step 11
Send traffic for about two minutes, enough to get a measure of what halving the traffic rate does for
helping CPU utilization.
The traffic was started at 4:10 pm. The CPU utilization decreased.
Step 12
Note
Stop the IXIA traffic for a short period of time. Reconfigure the IXIA stream to send at a rate of 5000
pps, but with a packet size of 500 Bytes (was 74 Bytes previously). The traffic was started at 4:15 pm.
The CPU utilization decreased.
The packet size was already set to 500, so I changed it to 74. The CPU utilization decreased.
Step 13
Send traffic for about two minutes, enough to get a measure of what increasing the packet size does for
the CPU utilization.
Step 14
Display the log for error messages.
Step 15
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect that SH1-101 will forward all broadcast packets on the same VLAN (VLAN 40) on which
they come in.
•
We expect packets to be forwarded to the IP helper-address as unicast packets when configured to
do so.
•
We expect packets will not be forwarded when the DNS protocol is blocked, and should resume
when the filter is lifted.
•
We expect no unacceptable impact on the CPU or memory of the DUT.
Results
Table 140
UDP Broadcast Flooding Test Results
Test
Result
UDP Broadcast Flooding
Pass
Cisco IOS Release 12.1(13)E13
479
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
System Upgrade
This test measured the basic ability of the code to boot correctly. The boot process was followed in each
case from the console and screened for any errors. The output shows three separate sections, one for each
supervisor and MSFC combination: supervisor 11, supervisor 12, and supervisor 22.
This test verified that the Cisco IOS upgrade process worked correctly.
The following tests were performed:
•
Cisco IOS 12.1(8b)E15 to 12.1(13)E13 Upgrade—Supervisor 11, page 480
•
Cisco IOS 12.1(8b)E15 to 12.1(13)E13 Upgrade—Supervisor 12, page 481
•
Cisco IOS 12.1(8b)E15 to 12.1(13)E13 Upgrade—Supervisor 22, page 482
•
Cisco IOS 12.1(13)E6 to 12.1(13)E13 Upgrade—Supervisor 11, page 483
•
Cisco IOS 12.1(13)E6 to 12.1(13)E13 Upgrade—Supervisor 12, page 483
•
Cisco IOS 12.1(13)E6 to 12.1(13)E13 Upgrade—Supervisor 22, page 484
Cisco IOS 12.1(8b)E15 to 12.1(13)E13 Upgrade—Supervisor 11
This test verified that the Cisco IOS upgrade process worked correctly. This test measured the basic
ability of the code to boot correctly on supervisor 11 for a Cisco IOS 12.1(8b)E15 to 12.1(13)E13
upgrade. The boot process was followed from the console and screened for errors.
Device under test: SH1-105
Test Procedure
The procedure used to perform the Cisco IOS 12.1(8b)E15 to 12.1(13)E13 Upgrade—Supervisor 11 test
follows:
Step 1
Record the start time of this test.
Step 2
On Sup 11, verify that SH1-105 is running the old Native Cisco IOS image, 12.1(8b)E15.
Step 3
Verify that the Sup11 image under test is on the proper file devices.
Step 4
Verify that the MSFC1 boot image is on the proper file devices.
Step 5
Verify that the boot string points to the proper device and filename for both the test image and the MSFC
boot image. Save any changes to NVRAM when done.
Step 6
Either power-cycle the device or perform a reset on the standby supervisor followed by a reload, to verify
that both primary and standby supervisors reload with the new image. Report any error messages seen
during reload.
Note
It should be noted that with the upgrade from 12.1(8b)E to 12.1(13)E, both supervisors need to be
upgraded at the same time. The reason is that 12.1(13)E supports the RPR+ redundancy feature, while
12.1(8b)E supports only EHSA mode redundancy. The two are not compatible and the boot-up of
whichever supervisor is upgrading to 12.1(13)E will suspend for that reason.
Step 7
Verify that both supervisors come online successfully and that the new image is running.
Cisco IOS Release 12.1(13)E13
480
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Expected Results
•
The Cisco IOS 12.1(8b)E15 to 12.1(13)E13 upgrade process should complete without error.
Results
Table 141
Cisco IOS 12.1(8b)E15 to 12.1(13)E13 Upgrade—Supervisor 11 Test Results
Test
Result
Cisco IOS 12.1(8b)E15 to 12.1(13)E13 Upgrade—Supervisor 11
Pass
Cisco IOS 12.1(8b)E15 to 12.1(13)E13 Upgrade—Supervisor 12
This test verified that the Cisco IOS upgrade process worked correctly. It measured the basic ability of
the code to boot correctly on supervisor 12 for a Cisco IOS 12.1(8b)E15 to 12.1(13)E13 upgrade. The
boot process was followed from the console and screened for errors.
Device under test: SH1-107.
Test Procedure
The procedure used to perform the Cisco IOS 12.1(8b)E15 to 12.1(13)E13 Upgrade—Supervisor 12 test
follows:
Step 1
Record the start time of this test.
Step 2
On Sup 12, verify that SH1-107 is running the old Native Cisco IOS image, 12.1(8b)E15.
Step 3
Verify that the Sup12 image under test is on the proper file devices.
Step 4
Verify that the MSFC2 boot image is on the proper file devices.
Step 5
Verify that the boot string points to the proper device and filename for both the test image and the MSFC
boot image. Save any changes to NVRAM when done.
Step 6
Either power-cycle the device or perform a reset on the standby supervisor followed by a reload, to verify
that both primary and standby supervisors reload with the new image. Report any error messages seen
during reload.
Note
It should be noted that with the upgrade from 12.1(8b)E to 12.1(13)E, both supervisors need to be
upgraded at the same time. The reason is that 12.1(13)E supports the RPR+ redundancy feature, while
12.1(8b)E supports only EHSA mode redundancy. The two are not compatible and the boot-up of
whichever supervisor is upgrading to 12.1(13)E will suspend for that reason.
Step 7
Verify that both supervisors come online successfully and that the new image is running.
Expected Results
•
The Cisco IOS 12.1(8b)E15 to 12.1(13)E13 upgrade process should complete without error.
Cisco IOS Release 12.1(13)E13
481
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Results
Table 142
Cisco IOS 12.1(8b)E15 to 12.1(13)E13 Upgrade—Supervisor 12 Test Results
Test
Result
Cisco IOS 12.1(8b)E15 to 12.1(13)E13 Upgrade—Supervisor 12
Pass
Cisco IOS 12.1(8b)E15 to 12.1(13)E13 Upgrade—Supervisor 22
This test verified that the Cisco IOS upgrade process worked correctly. It measured the basic ability of
the code to boot correctly on supervisor 22 for a Cisco IOS 12.1(8b)E15 to 12.1(13)E13 upgrade. The
boot process was followed from the console and screened for errors.
Device under test: SH1-109.
Test Procedure
The procedure used to perform the Cisco IOS 12.1(8b)E15 to 12.1(13)E13 Upgrade—Supervisor 22 test
follows:
Step 1
Record the start time of this test.
Step 2
On Sup 22, verify that SH1-109 is running the old Native Cisco IOS image, 12.1(8b)E15.
Step 3
Verify that the Sup22 image under test is on the proper file devices.
Step 4
Verify that the MSFC2 boot image is on the proper file devices.
Step 5
Verify that the boot string points to the proper device and filename for both the test image and the MSFC
boot image. Save any changes to NVRAM when done.
Step 6
Either power-cycle the device or perform a reset on the standby supervisor followed by a reload, to verify
that both primary and standby supervisors reload with the new image. Report any error messages seen
during reload.
Note
It should be noted that with the upgrade from 12.1(8b)E to 12.1(13)E, both supervisors need to be
upgraded at the same time. The reason is that 12.1(13)E supports the RPR+ redundancy feature, while
12.1(8b)E supports only EHSA mode redundancy. The two are not compatible and the boot-up of
whichever supervisor is upgrading to 12.1(13)E will suspend for that reason.
Step 7
Verify that both supervisors come online successfully and that the new image is running.
Expected Results
•
The Cisco IOS 12.1(8b)E15 to 12.1(13)E13 upgrade process should complete without error.
Cisco IOS Release 12.1(13)E13
482
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Results
Table 143
Cisco IOS 12.1(8b)E15 to 12.1(13)E13 Upgrade—Supervisor 22 Test Results
Test
Result
Cisco IOS 12.1(8b)E15 to 12.1(13)E13 Upgrade—Supervisor 22
Pass
Cisco IOS 12.1(13)E6 to 12.1(13)E13 Upgrade—Supervisor 11
This test verified that the Cisco IOS upgrade process worked correctly. It measured the basic ability of
the code to boot correctly on supervisor 11 for a Cisco IOS 12.1(13)E6 to 12.1(13)E13 upgrade. The
boot process was followed from the console and screened for errors.
Device under test: SH1-105.
Test Procedure
The procedure used to perform the Cisco IOS 12.1(13)E6 to 12.1(13)E13 Upgrade—Supervisor 11 test
follows:
Step 1
Record the start time of this test.
Step 2
On Sup 11, verify that SH1-105 is running the old Native Cisco IOS image, 12.1(13)E6.
Step 3
Verify that the Sup11 image under test is on the proper file devices.
Step 4
Verify that the MSFC1 boot image is on the proper file devices.
Step 5
Verify that the boot string points to the proper device and filename for both the test image and the MSFC
boot image. Save any changes to NVRAM when done.
Step 6
Either power-cycle the device or perform a reset on the standby supervisor followed by a reload, to verify
that both primary and standby supervisors reload with the new image. Report any error messages seen
during reload.
Step 7
Verify that both supervisors come online successfully and that the new image is running.
Expected Results
•
The Cisco IOS 12.1(13)E6 to 12.1(13)E13 upgrade process should complete without error.
Cisco IOS 12.1(13)E6 to 12.1(13)E13 Upgrade—Supervisor 12
This test verified that the Cisco IOS upgrade process worked correctly. It measured the basic ability of
the code to boot correctly on supervisor 12 for a Cisco IOS 112.1(13)E6 to 12.1(13)E13 upgrade. The
boot process was followed from the console and screened for errors.
Device under test: SH1-107.
Test Procedure
The procedure used to perform the Cisco IOS 12.1(13)E6 to 12.1(13)E13 Upgrade—Supervisor 12 test
follows:
Cisco IOS Release 12.1(13)E13
483
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Step 1
Record the start time of this test.
Step 2
On Sup 12, verify that SH1-107 is running the old Native Cisco IOS image, 12.1(13)E6.
Step 3
Verify that the Sup12 image under test is on the proper file devices.
Step 4
Verify that the MSFC2 boot image is on the proper file devices.
Step 5
Verify that the boot string points to the proper device and filename for both the test image and the MSFC
boot image. Save any changes to NVRAM when done.
Step 6
Either power-cycle the device or perform a reset on the standby supervisor followed by a reload, to verify
that both primary and standby supervisors reload with the new image. Report any error messages seen
during reload.
Step 7
Verify that both supervisors come online successfully and that the new image is running.
Expected Results
•
The Cisco IOS 12.1(13)E6 to 12.1(13)E13 upgrade process should complete without error.
Results
Table 144
Cisco IOS 12.1(13)E6 to 12.1(13)E13 Upgrade—Supervisor 11 Test Results
Test
Result
Cisco IOS 12.1(13)E6 to 12.1(13)E13 Upgrade—Supervisor 11
Pass
Cisco IOS 12.1(13)E6 to 12.1(13)E13 Upgrade—Supervisor 22
This test verified that the Cisco IOS upgrade process worked correctly. It measured the basic ability of
the code to boot correctly on supervisor 22 for a Cisco IOS 12.1(13)E6 to 12.1(13)E13 upgrade. The
boot process was followed from the console and screened for errors.
Device under test: SH1-109.
Test Procedure
The procedure used to perform the Cisco IOS 12.1(13)E6 to 12.1(13)E13 Upgrade—Supervisor 22 test
follows:
Step 1
Record the start time of this test.
Step 2
On Sup 22, verify that SH1-109 is running the old Native Cisco IOS image, 12.1(13)E6.
Step 3
Verify that the Sup22 image under test is on the proper file devices.
Step 4
Verify that the MSFC2 boot image is on the proper file devices.
Step 5
Verify that the boot string points to the proper device and filename for both the test image and the MSFC
boot image. Save any changes to NVRAM when done.
Step 6
Either power-cycle the device or perform a reset on the standby supervisor followed by a reload, to verify
that both primary and standby supervisors reload with the new image. Report any error messages seen
during reload.
Cisco IOS Release 12.1(13)E13
484
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Step 7
Verify that both supervisors come online successfully and that the new image is running.
Expected Results
•
The Cisco IOS 12.1(13)E6 to 12.1(13)E13 upgrade process should complete without error.
Results
Table 145
Cisco IOS 12.1(13)E6 to 12.1(13)E13 Upgrade—Supervisor 22 Test Results
Test
Result
Cisco IOS 12.1(13)E6 to 12.1(13)E13 Upgrade—Supervisor 22
Pass
Secure Shell
Secure Shell (SSH) is an application and a protocol that provide a secure replacement to the Berkeley
r-tools. The protocol secures the sessions using standard cryptographic mechanisms, and the application
can be used similarly to the Berkeley rexec and RSH tools. Two versions of SSH are available: SSH
Version 1 and SSH Version 2. Only SSH Version 1 is implemented in the Cisco IOS software.
The SSH Server feature enables a SSH client to make a secure, encrypted connection to a Cisco router.
This connection provides functionality that is similar to that of an inbound Telnet connection. Before
SSH, security was limited to Telnet security. SSH allows a strong encryption to be used with the
Cisco IOS software authentication. The SSH server in Cisco IOS software will work with publicly and
commercially available SSH clients.
The user authentication mechanisms supported for SSH are RADIUS, TACACS+, and the use of locally
stored user names and passwords.
The following test was performed:
•
SSH Server Vulnerability, page 485
SSH Server Vulnerability
This test verified that the SSH server built into Cisco IOS crypto images is not susceptible to SSH
malformed packet vulnerabilities as described at:
•
http://www.cisco.com/warp/public/707/ssh-packet-suite-vuln.shtml.
The test protocol data units (PDUs) sent to the device were downloaded from:
•
http://www.rapid7.com/Product-Download.html.
Test Procedure
The procedure used to perform the SSH Server Vulnerability test follows:
Step 1
Record the version, start time, and CPU utilization from DUT.
Step 2
Display the log for error messages, and then clear it.
Step 3
Begin monitoring memory and CPU utilization for the devices under test.
Cisco IOS Release 12.1(13)E13
485
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Step 4
Ensure SH1-110 is configured with a hostname, domain name, and TACACS authentication on VTY
lines.
Step 5
Ensure the SSH server on SH1-110 is enabled by generating an RSA key pair. Configure the VTY lines
to allow SSH, and verify that SH1-110 is accepting SSH connections.
Step 6
Send malformed SSH packets at SH1-110 while monitoring device. Ensure device does not hang, crash
or reload.
Step 7
Remove configuration added in this test case.
The configuration was left on SH1-110 for this iteration of testing.
Step 8
Display the log for error messages.
Step 9
Verify that the memory and the CPU did not suffer from severe, sustained, or unacceptable impact.
Expected Results
•
We expect SSH vulnerability testing will not cause the router to pause indefinitely, or reload.
Results
Table 146
SSH Server Vulnerability Test Results
Test
Result
SSH Server Vulnerability
Pass
Cisco IOS Release 12.1(13)E13
486
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, Cisco Unity, Follow Me Browsing, FormShare, and StackWise are
trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.;
and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco
IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver,
EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard,
LightStream, Linksys, MGX, MICA, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing,
RateMUX, Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, The Fastest Way to Increase Your
Internet Quotient, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other
countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply
a partnership relationship between Cisco and any other company. (0402R)Copyright © 2003, Cisco Systems, Inc.
All rights reserved.
Cisco IOS Release 12.1(13)E13
487
Cisco IOS Safe Harbor Release 12.1(13)E13 for Financial Enterprise Customers
Miscellaneous Features
Cisco IOS Release 12.1(13)E13
488