You are on page 1of 1484

Cisco IOS Software Configuration Guide

Release 12.2(33)SXH and Later Releases

Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883

Text Part Number: OL-13013-06


THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL
STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.

THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT
SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE
OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.

The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCBs public
domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California.

NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED AS IS WITH
ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT
LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF
DEALING, USAGE, OR TRADE PRACTICE.

IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,
WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO
OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this
URL: www.cisco.com/go/trademarks. Third-party trademarks mentioned 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. (1110R)

Cisco IOS Software Configuration Guide, Release 12.2SX


20072012, Cisco Systems, Inc. All rights reserved.
C O N T E N T S

Preface xli

Audience xli

Related Documentation xli

Conventions xli

Obtaining Documentation, Obtaining Support, and Security Guidelines xlii

CHAPTER 1 Product Overview 1-1

Supervisor Engine Memory Devices and Ports 1-1


Understanding Supervisor Engine 720-10GE Memory Devices and Ports 1-1
Understanding Supervisor Engine 720 Memory Devices and Ports 1-2
Understanding Supervisor Engine 32 Memory Devices and Ports 1-4
Understanding ME6500 Flash Memory Devices and Ports 1-5
User Interfaces 1-5

Module Status Monitoring 1-6

Software Features Supported in Hardware by the PFC and DFC 1-6

PART 1 Configuration Fundamentals

CHAPTER 2 Command-Line Interfaces 2-1

Accessing the CLI 2-2


Accessing the CLI through the EIA/TIA-232 Console Interface 2-2
Accessing the CLI through Telnet 2-2
Performing Command Line Processing 2-3

Performing History Substitution 2-4

Cisco IOS Command Modes 2-4

Displaying a List of Cisco IOS Commands and Syntax 2-5

Securing the CLI 2-6

ROM-Monitor Command-Line Interface 2-7

CHAPTER 3 Configuring Smart Port Macros 3-1

Understanding Smart Port Macros 3-1


Understanding Cisco-Provided Smart Port Macros 3-1
Understanding User-Created Smart Port Macros 3-2

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 iii
Contents

Configuring Smart Port Macros 3-2


Smart Port Macro Default Configuration 3-2
Smart Port Macro Configuration Guidelines 3-3
Applying the Cisco-Provided Smart Port Macros 3-4
Configuring User-Created Smart Port Macros 3-13
Displaying Smart Port Macros 3-16

CHAPTER 4 Configuring Virtual Switching Systems 4-1

Understanding Virtual Switching Systems 4-1


VSS Overview 4-2
VSS Redundancy 4-11
Multichassis EtherChannels 4-14
Packet Handling 4-16
System Monitoring 4-20
Dual-Active Detection 4-22
VSS Initialization 4-25
VSS Configuration Guidelines and Restrictions 4-29
General VSS Restrictions and Guidelines 4-29
VSL Restrictions and Guidelines 4-29
Multichassis EtherChannel Restrictions and Guidelines 4-29
Dual-Active Detection Restrictions and Guidelines 4-30
Service Module Restrictions and Guidelines 4-30
Configuring a VSS 4-30
Converting to a VSS 4-31
Displaying VSS Information 4-37
Converting a VSS to Standalone Chassis 4-37
Configuring VSS Parameters 4-39
Configuring Multichassis EtherChannels 4-45
Configuring Dual-Active Detection 4-46
Configuring Service Modules in a VSS 4-52
Viewing Chassis Status and Module Information in a VSS 4-54

Upgrading a VSS 4-55


Performing a Fast Software Upgrade of a VSS 4-55
Performing an Enhanced Fast Software Upgrade of a VSS 4-56

PART 2 High Availability

CHAPTER 5 Performing an Enhanced Fast Software Upgrade 5-1

eFSU Overview 5-1

Cisco IOS Software Configuration Guide, Release 12.2SX


iv OL-13013-06
Contents

eFSU Operation 5-2


Outage Time and Support Considerations 5-3
Reserving Module Memory 5-3
Error Handling for eFSU Preload 5-4
eFSU Restrictions 5-4

Performing an Enhanced Fast Software Upgrade 5-5


Software Upgrade Process Summary For a Switch 5-5
Preparing for the Upgrade 5-6
Copying the New Software Image 5-8
Loading the New Software onto the Standby Supervisor Engine 5-8
Displaying the Maximum Outage Time for Installed Modules (Optional) 5-10
Forcing a Switchover from Active to Standby 5-10
Accepting the New Software Version and Stopping the Rollback Process (Optional) 5-11
Committing the New Software to the Standby 5-12
Verifying the Software Installation 5-12
Aborting the Upgrade Process 5-13
Performing an eFSU Upgrade on an Installed Modular Image 5-14
Upgrading an Installed Modular Image 5-14
Example an eFSU Upgrade on an Installed Modular Image 5-15
Upgrading a Non-eFSU Image to an eFSU Image 5-16

CHAPTER 6 Configuring NSF with SSO Supervisor Engine Redundancy 6-1

Understanding NSF with SSO Supervisor Engine Redundancy 6-1


NSF with SSO Supervisor Engine Redundancy Overview 6-2
SSO Operation 6-2
NSF Operation 6-3
Cisco Express Forwarding 6-3
Multicast MLS NSF with SSO 6-4
Routing Protocols 6-4
NSF Benefits and Restrictions 6-8
Supervisor Engine Configuration Synchronization 6-9
Supervisor Engine Redundancy Guidelines and Restrictions 6-9
Redundancy Configuration Guidelines and Restrictions 6-9
Hardware Configuration Guidelines and Restrictions 6-10
Configuration Mode Restrictions 6-11
NSF Configuration Tasks 6-11
Configuring SSO 6-11
Verifying the Redundancy States 6-12
Configuring Multicast MLS NSF with SSO 6-13

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 v
Contents

Verifying Multicast NSF with SSO 6-13


Configuring CEF NSF 6-13
Verifying CEF NSF 6-14
Configuring BGP NSF 6-14
Verifying BGP NSF 6-14
Configuring OSPF NSF 6-15
Verifying OSPF NSF 6-16
Configuring IS-IS NSF 6-17
Verifying IS-IS NSF 6-17
Configuring EIGRP NSF 6-19
Verifying EIGRP NSF 6-19
Synchronizing the Supervisor Engine Configurations 6-20
Copying Files to the Redundant Supervisor Engine 6-20

CHAPTER 7 Configuring RPR Supervisor Engine Redundancy 7-1

Understanding RPR 7-1


Supervisor Engine Redundancy Overview 7-2
RPR Operation 7-2
Supervisor Engine Configuration Synchronization 7-3

Supervisor Engine Redundancy Guidelines and Restrictions 7-3


Redundancy Guidelines and Restrictions 7-3
Hardware Configuration Guidelines and Restrictions 7-3
Configuration Mode Restrictions 7-4
Configuring Supervisor Engine Redundancy 7-4
Configuring Redundancy 7-4
Synchronizing the Supervisor Engine Configurations 7-5
Displaying the Redundancy States 7-5
Performing a Fast Software Upgrade 7-6

Copying Files to the RP 7-7

PART 3 Interface and Hardware Components

CHAPTER 8 Configuring Interfaces 8-1

Understanding Interface Configuration 8-2

Using the Interface Command 8-2

Configuring a Range of Interfaces 8-4

Defining and Using Interface-Range Macros 8-6

Configuring Optional Interface Features 8-6

Cisco IOS Software Configuration Guide, Release 12.2SX


vi OL-13013-06
Contents

Configuring Ethernet Interface Speed and Duplex Mode 8-7


Configuring Jumbo Frame Support 8-10
Configuring IEEE 802.3x Flow Control 8-13
Configuring the Port Debounce Timer 8-15
Adding a Description for an Interface 8-16
Understanding Online Insertion and Removal 8-16

Monitoring and Maintaining Interfaces 8-17


Monitoring Interface Status 8-17
Clearing Counters on an Interface 8-18
Resetting an Interface 8-18
Shutting Down and Restarting an Interface 8-19

Checking the Cable Status Using the TDR 8-19

CHAPTER 9 Configuring UDLD 9-1

Understanding UDLD 9-1


UDLD Overview 9-2
UDLD Aggressive Mode 9-3
Fast UDLD 9-4
Default UDLD Configuration 9-4

Configuring UDLD 9-5


Enabling UDLD Globally 9-5
Enabling UDLD on LAN Ports 9-5
Disabling UDLD on Fiber-Optic LAN Ports 9-6
Configuring the Global UDLD Probe Message Interval 9-6
Configuring Fast UDLD 9-6
Resetting Disabled LAN Interfaces 9-7

CHAPTER 10 Power Management and Environmental Monitoring 10-1

Understanding Power Management 10-1


Enabling or Disabling Power Redundancy 10-2
Powering Modules Off and On 10-3
Viewing System Power Status 10-4
Power Cycling Modules 10-5
Determining System Power Requirements 10-5
Determining System Hardware Capacity 10-5
Determining Sensor Temperature Threshold 10-9
Understanding Environmental Monitoring 10-10
Overview 10-10
Monitoring System Environmental Status 10-10

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 vii
Contents

Understanding LED Environmental Indications 10-12

CHAPTER 11 Configuring EnergyWise 11-1

CHAPTER 12 Configuring Online Diagnostics 12-1

Understanding Online Diagnostics 12-1

Configuring Online Diagnostics 12-2


Setting Bootup Online Diagnostics Level 12-2
Configuring On-Demand Online Diagnostics 12-3
Scheduling Online Diagnostics 12-4
Configuring Health-Monitoring Diagnostics 12-5
Running Online Diagnostic Tests 12-5
Starting and Stopping Online Diagnostic Tests 12-6
Running All Online Diagnostic Tests 12-7
Displaying Online Diagnostic Tests and Test Results 12-7
Performing Memory Tests 12-12

CHAPTER 13 Configuring Onboard Failure Logging 13-1

Understanding OBFL 13-1


Overview of OBFL 13-2
Data Collected by OBFL 13-2
Restrictions for OBFL 13-9

Enabling OBFL 13-9

Configuration Examples for OBFL 13-10


Enabling OBFL Message Logging: Example 13-10
OBFL Message Log: Example 13-10
OBFL Component Uptime Report: Example 13-10
OBFL Report for a Specific Time: Example 13-11

CHAPTER 14 Configuring and Monitoring the Switch Fabric Functionality 14-1

Understanding the Switch Fabric Functionality 14-1


Switch Fabric Functionality Overview 14-2
Forwarding Decisions for Layer 3-Switched Traffic 14-2
Switching Modes 14-2
Configuring the Switch Fabric Functionality 14-3

Monitoring the Switch Fabric Functionality 14-4


Displaying the Switch Fabric Redundancy Status 14-4
Displaying Fabric Channel Switching Modes 14-4

Cisco IOS Software Configuration Guide, Release 12.2SX


viii OL-13013-06
Contents

Displaying the Fabric Status 14-5


Displaying the Fabric Utilization 14-5
Displaying Fabric Errors 14-6

CHAPTER 15 Configuring Cisco IP Phone Support 15-1

Understanding Cisco IP Phone Support 15-1


Cisco IP Phone Connections 15-2
Cisco IP Phone Voice Traffic 15-2
Cisco IP Phone Data Traffic 15-3
Other Cisco IP Phone Features 15-3
Default Cisco IP Phone Support Configuration 15-4

Cisco IP Phone Support Configuration Guidelines and Restrictions 15-4

Configuring Cisco IP Phone Support 15-5


Configuring Voice Traffic Support 15-5
Configuring Data Traffic Support 15-6

CHAPTER 16 Configuring Power over Ethernet Support 16-1

Understanding PoE 16-1


Device Roles 16-2
PoE Overview 16-2
CPD-Based PoE Management 16-3
Inline Power IEEE Power Classification Override 16-3
LLDP Inline Power Negotiation for PoE+ (IEEE 802.3at) 16-4

Configuring PoE Support 16-4


Displaying PoE Status 16-5
Configuring Per-Port PoE Support 16-5
Configuring PoE Power Priority 16-7
Configuring PoE Monitoring and Policing 16-8
Disabling LLDP Power Negotiation (IEEE 802.3at) 16-8

PART 2 LAN Switching

CHAPTER 17 Configuring LAN Ports for Layer 2 Switching 17-1

Understanding Layer 2 Switching 17-1


Understanding Layer 2 Ethernet Switching 17-1
Understanding VLAN Trunks 17-3
Layer 2 LAN Port Modes 17-4
Default Layer 2 LAN Interface Configuration 17-5

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 ix
Contents

Layer 2 LAN Interface Configuration Guidelines and Restrictions 17-5

Configuring LAN Interfaces for Layer 2 Switching 17-6


Configuring a LAN Port for Layer 2 Switching 17-7
Enabling Out-of-Band MAC Address Table Synchronization 17-8
Configuring MAC Address Table Notification 17-8
Configuring a Layer 2 Switching Port as a Trunk 17-10
Configuring a LAN Interface as a Layer 2 Access Port 17-16
Configuring an IEEE 802.1Q Custom EtherType Field Value 17-18

CHAPTER 18 Configuring Flex Links 18-1

Understanding Flex Links 18-1

Configuring Flex Links 18-3


Flex Links Default Configuration 18-4
Flex Links Configuration Guidelines and Restrictions 18-4
Configuring Flex Links 18-4
Monitoring Flex Links 18-5

CHAPTER 19 Configuring EtherChannels 19-1

Understanding EtherChannels 19-1


EtherChannel Feature Overview 19-2
Understanding EtherChannel Configuration 19-2
Understanding LACP 1:1 Redundancy 19-5
Understanding Port Channel Interfaces 19-5
Understanding Load Balancing 19-5
EtherChannel Feature Configuration Guidelines and Restrictions 19-6
Configuring EtherChannels 19-8
Configuring Port Channel Logical Interfaces for Layer 3 EtherChannels 19-8
Configuring Channel Groups 19-9
Configuring the LACP System Priority and System ID 19-11
Configuring EtherChannel Load Balancing 19-12
Configuring EtherChannel Hash-Distribution Algorithm 19-13
Configuring the EtherChannel Min-Links Feature 19-14
Configuring LACP 1:1 Redundancy 19-15
Configuring Auto Interleaved Port Priority For LACP Port Channels 19-16
Configuring LACP Port-Channel Standalone Disable 19-17

CHAPTER 20 Configuring mLACP for Server Access 20-1

Understanding mLACP for Server Access 20-1

Cisco IOS Software Configuration Guide, Release 12.2SX


x OL-13013-06
Contents

Overview of mLACP for Server Access 20-2


Understanding mLACP Operation 20-2
Failure Protection Scenarios 20-6
mLACP Failover 20-6
mLACP for Server Access Guidelines and Restrictions 20-9

Configuring mLACP for Server Access 20-10


Summary of mLACP PoA Configuration Values 20-11
Configuring mLACP Global Options 20-11
Configuring the Interchassis Communication Channel 20-12
Configuring Interchassis Redundancy Groups 20-13
Forcing a PoA Failover 20-18
Troubleshooting mLACP 20-18
Verifying an Active PoA 20-18
Verifying a Standby PoA 20-22

CHAPTER 21 Configuring IEEE 802.1ak MVRP and MRP 21-1

Understanding IEEE 802.1ak MVRP and MRP 21-1


Overview 21-1
Dynamic VLAN Creation 21-3
MVRP Interoperability with VTP 21-3
MVRP Interoperation with Non-Cisco Devices 21-5
MVRP Interoperability with Other Software Features and Protocols 21-5

IEEE 802.1ak MVRP and MRP Guidelines and Restrictions 21-7

Configuring IEEE 802.1ak MVRP and MRP 21-8


Enabling MVRP 21-8
Enabling Automatic Detection of MAC Addresses 21-9
Enabling MVRP Dynamic VLAN Creation 21-9
Changing the MVRP Registrar State 21-9
Troubleshooting the MVRP Configuration 21-10

Configuration Examples for IEEE 802.1ak MVRP and MRP 21-11


Enabling MVRP 21-11
Enabling MVRP Automatic Detection of MAC Addresses 21-11
Enabling Dynamic VLAN Creation 21-11
Changing the MVRP Registrar State 21-11

CHAPTER 22 Configuring VTP 22-1

Understanding VTP 22-1


Understanding the VTP Domain 22-2
Understanding VTP Modes 22-3

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 xi
Contents

Understanding VTP Advertisements 22-3


Understanding VTP Authentication 22-4
Understanding VTP Version 2 22-4
Understanding VTP Version 3 22-5
Understanding VTP Pruning 22-6
VLAN Interaction 22-8
Interaction Between VTP Version 3 and VTP Version 2 Devices 22-8
Interaction Between VTP Version 3 and VTP Version 1 Devices 22-8

VTP Default Configuration 22-8

VTP Configuration Guidelines and Restrictions 22-9

Configuring VTP 22-10


Configuring VTP Global Parameters 22-10
Configuring the VTP Mode 22-15
Configuring VTP Mode on a Per-Port Basis 22-17
Displaying VTP Statistics 22-18

CHAPTER 23 Configuring VLANs 23-1

Understanding VLANs 23-1


VLAN Overview 23-2
VLAN Ranges 23-2
VLAN Configuration Guidelines and Restrictions 23-3

Configuring VLANs 23-3


Configurable VLAN Parameters 23-4
Ethernet VLAN Default Parameters 23-4
VLAN Locking 23-4
Creating or Modifying an Ethernet VLAN 23-5
Assigning a Layer 2 LAN Interface to a VLAN 23-6
Configuring the Internal VLAN Allocation Policy 23-7
Configuring VLAN Translation 23-7
Mapping 802.1Q VLANs to ISL VLANs 23-10
Saving VLAN Information 23-11

CHAPTER 24 Configuring Private VLANs 24-1

Understanding Private VLANs 24-1


Private VLAN Domains 24-2
Private VLAN Ports 24-3
Primary, Isolated, and Community VLANs 24-3
Private VLAN Port Isolation 24-4
IP Addressing Scheme with Private VLANs 24-4

Cisco IOS Software Configuration Guide, Release 12.2SX


xii OL-13013-06
Contents

Private VLANs Across Multiple Switches 24-5


Private VLAN Interaction with Other Features 24-5
Private VLAN Configuration Guidelines and Restrictions 24-6
Secondary and Primary VLAN Configuration 24-7
Private VLAN Port Configuration 24-9
Limitations with Other Features 24-9
Configuring Private VLANs 24-11
Configuring a VLAN as a Private VLAN 24-11
Associating Secondary VLANs with a Primary VLAN 24-12
Mapping Secondary VLANs to the Layer 3 VLAN Interface of a Primary VLAN 24-13
Configuring a Layer 2 Interface as a Private VLAN Host Port 24-15
Configuring a Layer 2 Interface as a Private VLAN Promiscuous Port 24-16
Monitoring Private VLANs 24-17

CHAPTER 25 Configuring Private Hosts 25-1

Understanding Private Hosts 25-1


Private Hosts Overview 25-1
Isolating Hosts in a VLAN 25-2
Restricting Traffic Flow (Using Private Hosts Port Mode and PACLs) 25-3
Port ACLs 25-5
Configuration Guidelines and Limitations 25-6
General Restrictions 25-6
ACL Guidelines 25-6
VLANs on the Trunk Port 25-7
Interaction with Other Features 25-7
Spoofing Protection 25-7
Multicast Operation 25-8
Configuring Private Hosts 25-8
Configuration Summary 25-8
Detailed Configuration Steps 25-9
Configuration Examples 25-11
Enabling Index Learning on Isolated Mode Ports 25-12

CHAPTER 26 Configuring IEEE 802.1Q Tunneling 26-1

Understanding 802.1Q Tunneling 26-1

802.1Q Tunneling Configuration Guidelines and Restrictions 26-3

Configuring 802.1Q Tunneling 26-6


Configuring 802.1Q Tunnel Ports 26-6

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 xiii
Contents

Configuring the Switch to Tag Native VLAN Traffic 26-7

CHAPTER 27 Configuring Layer 2 Protocol Tunneling 27-1

Understanding Layer 2 Protocol Tunneling 27-1

Configuring Support for Layer 2 Protocol Tunneling 27-2

CHAPTER 28 Configuring STP and MST 28-1

Understanding STP 28-1


STP Overview 28-2
Understanding the Bridge ID 28-2
Understanding Bridge Protocol Data Units 28-3
Election of the Root Bridge 28-4
STP Protocol Timers 28-4
Creating the Spanning Tree Topology 28-5
STP Port States 28-5
STP and IEEE 802.1Q Trunks 28-12
Understanding IEEE 802.1w RSTP 28-13
Port Roles and the Active Topology 28-13
Rapid Convergence 28-14
Synchronization of Port Roles 28-15
Bridge Protocol Data Unit Format and Processing 28-16
Topology Changes 28-17
Rapid-PVST 28-18
Understanding MST 28-18
MST Overview 28-19
MST Regions 28-19
IST, CIST, and CST 28-20
Hop Count 28-23
Boundary Ports 28-23
Standard-Compliant MST Implementation 28-24
Interoperability with IEEE 802.1D-1998 STP 28-26
Configuring STP 28-26
Default STP Configuration 28-27
Enabling STP 28-28
Enabling the Extended System ID 28-29
Configuring the Root Bridge 28-30
Configuring a Secondary Root Bridge 28-31
Configuring STP Port Priority 28-32
Configuring STP Port Cost 28-33

Cisco IOS Software Configuration Guide, Release 12.2SX


xiv OL-13013-06
Contents

Configuring the Bridge Priority of a VLAN 28-35


Configuring the Hello Time 28-36
Configuring the Forward-Delay Time for a VLAN 28-36
Configuring the Maximum Aging Time for a VLAN 28-37
Enabling Rapid-PVST 28-37
Configuring MST 28-38
Default MST Configuration 28-39
MST Configuration Guidelines and Restrictions 28-39
Specifying the MST Region Configuration and Enabling MST 28-40
Configuring the Root Bridge 28-41
Configuring a Secondary Root Bridge 28-43
Configuring Port Priority 28-43
Configuring Path Cost 28-44
Configuring the Switch Priority 28-45
Configuring the Hello Time 28-46
Configuring the Forwarding-Delay Time 28-47
Configuring the Transmit Hold Count 28-47
Configuring the Maximum-Aging Time 28-48
Configuring the Maximum-Hop Count 28-48
Specifying the Link Type to Ensure Rapid Transitions 28-48
Designating the Neighbor Type 28-49
Restarting the Protocol Migration Process 28-50
Displaying the MST Configuration and Status 28-50

CHAPTER 29 Configuring Optional STP Features 29-1


Understanding the Optional STP Features 29-1
Understanding STP Port Types 29-2
Understanding PortFast 29-2
Understanding Bridge Assurance 29-3
Understanding BPDU Guard 29-5
Understanding PortFast BPDU Filtering 29-5
Understanding UplinkFast 29-6
Understanding BackboneFast 29-7
Understanding EtherChannel Guard 29-9
Understanding Root Guard 29-10
Understanding Loop Guard 29-10
Understanding PVST Simulation 29-11
Configuring the Optional STP Features 29-12
Enabling PortFast 29-12

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 xv
Contents

Enabling Bridge Assurance 29-14


Enabling PortFast BPDU Filtering 29-15
Enabling BPDU Guard 29-16
Enabling UplinkFast 29-18
Enabling BackboneFast 29-19
Enabling EtherChannel Guard 29-20
Enabling Root Guard 29-20
Enabling Loop Guard 29-21
Configuring PVST Simulation 29-22
Verifying the Optional STP Features 29-23
Using the show spanning-tree Commands 29-23
Examples in Release 12.2(33)SXI and Later Releases 29-23
Examples in Releases Earlier Than Release 12.2(33)SXI 29-26

PART 3 IP Routing Protocols

CHAPTER 30 Configuring Layer 3 Interfaces 30-1

Layer 3 Interface Configuration Guidelines and Restrictions 30-2

Configuring Subinterfaces on Layer 3 Interfaces 30-2

Configuring IPv4 Routing and Addresses 30-4

Configuring IPX Routing and Network Numbers 30-7

Configuring AppleTalk Routing, Cable Ranges, and Zones 30-8

Configuring Other Protocols on Layer 3 Interfaces 30-9

CHAPTER 31 Configuring UDE and UDLR 31-1

Understanding UDE and UDLR 31-1


UDE and UDLR Overview 31-1
Supported Hardware 31-2
Understanding UDE 31-2
Understanding UDLR 31-3
Configuring UDE and UDLR 31-3
Configuring UDE 31-3
Configuring UDLR 31-6

PART 4 Multiprotocol Label Switching

CHAPTER 32 Configuring Multiprotocol Label Switching 32-1

MPLS 32-1

Cisco IOS Software Configuration Guide, Release 12.2SX


xvi OL-13013-06
Contents

Understanding MPLS 32-2


Hardware-Supported MPLS Functions 32-4
Supported Cisco IOS Features 32-5
MPLS Guidelines and Restrictions 32-7
Supported MPLS Commands 32-7
Configuring MPLS 32-8
MPLS Per-Label Load Balancing 32-8
MPLS Configuration Examples 32-8
DE/CLP and EXP Mapping on FR/ATMoMPLS VC 32-10
Match on ATM CLP Bit 32-10
Set on ATM CLP Bit 32-12
VPN Switching 32-13
VPN Switching Operation 32-13
MPLS VPN Guidelines and Restrictions 32-14
MPLS VPN Supported Commands 32-14
Configuring MPLS VPN 32-15
MPLS VPN Sample Configuration 32-15
Any Transport over MPLS 32-17
AToM Load Balancing 32-17
Understanding EoMPLS 32-17
EoMPLS Guidelines and Restrictions 32-18
Configuring EoMPLS 32-19
Configuring MUX-UNI Support on LAN Cards 32-26

CHAPTER 33 Configuring A-VPLS 33-1


Understanding A-VPLS 33-1

Restrictions for A-VPLS 33-2

Configuring A-VPLS 33-3


Enabling Load-Balancing with ECMP and FAT Pseudowires 33-3
Enabling Port-Channel Load-Balancing 33-4
Explicitly Specifying the PE Routers As Part of Virtual Ethernet Interface Configuration 33-4
Configuring an MPLS Traffic Engineering Tunnel 33-5
Configuring a GRE Tunnel 33-6
Routed Pseudo-Wire (RPW) and Routed VPLS 33-8

PART 5 IP Switching

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 xvii
Contents

CHAPTER 34 Configuring IP Unicast Layer 3 Switching 34-1

Understanding Layer 3 Switching 34-2


Understanding Hardware Layer 3 Switching 34-2
Understanding Layer 3-Switched Packet Rewrite 34-2
Default Hardware Layer 3 Switching Configuration 34-4

Configuration Guidelines and Restrictions 34-4

Configuring Hardware Layer 3 Switching 34-5

Displaying Hardware Layer 3 Switching Statistics 34-6

PART 6 IPv6

CHAPTER 35 Configuring IPv6 Multicast PFC3 and DFC3 Layer 3 Switching 35-1

Features that Support IPv6 Multicast 35-1

IPv6 Multicast Guidelines and Restrictions 35-2

New or Changed IPv6 Multicast Commands 35-3

Configuring IPv6 Multicast Layer 3 Switching 35-3

Using show Commands to Verify IPv6 Multicast Layer 3 Switching 35-3


Verifying MFIB Clients 35-4
Displaying the Switching Capability 35-4
Verifying the (S,G) Forwarding Capability 35-5
Verifying the (*,G) Forwarding Capability 35-5
Verifying the Subnet Entry Support Status 35-5
Verifying the Current Replication Mode 35-5
Displaying the Replication Mode Auto-Detection Status 35-5
Displaying the Replication Mode Capabilities 35-5
Displaying Subnet Entries 35-6
Displaying the IPv6 Multicast Summary 35-6
Displaying the NetFlow Hardware Forwarding Count 35-6
Displaying the FIB Hardware Bridging and Drop Counts 35-7
Displaying the Shared and Well-Known Hardware Adjacency Counters 35-7

CHAPTER 36 Configuring MLD Snooping for IPv6 Multicast Traffic 36-1

Understanding MLD Snooping 36-2


MLD Snooping Overview 36-2
MLD Messages 36-3
Source-Based Filtering 36-3
Explicit Host Tracking 36-3
MLD Snooping Proxy Reporting 36-4

Cisco IOS Software Configuration Guide, Release 12.2SX


xviii OL-13013-06
Contents

Joining an IPv6 Multicast Group 36-4


Leaving a Multicast Group 36-6
Understanding the MLD Snooping Querier 36-7

Default MLD Snooping Configuration 36-8

MLD Snooping Configuration Guidelines and Restrictions 36-8

MLD Snooping Querier Configuration Guidelines and Restrictions 36-9

Enabling the MLD Snooping Querier 36-9

Configuring MLD Snooping 36-10


Enabling MLD Snooping 36-10
Configuring a Static Connection to a Multicast Receiver 36-11
Configuring a Multicast Router Port Statically 36-11
Configuring the MLD Snooping Query Interval 36-12
Enabling Fast-Leave Processing 36-12
Enabling SSM Safe Reporting 36-13
Configuring Explicit Host Tracking 36-13
Configuring Report Suppression 36-14
Displaying MLD Snooping Information 36-14

PART 7 IP Multicast

CHAPTER 37 Configuring IPv4 Multicast Layer 3 Switching 37-1

Understanding IPv4 Multicast Layer 3 Switching 37-1


IPv4 Multicast Layer 3 Switching Overview 37-2
Multicast Layer 3 Switching Cache 37-2
Layer 3-Switched Multicast Packet Rewrite 37-3
Partially and Completely Switched Flows 37-4
Non-RPF Traffic Processing 37-5
Multicast Boundary 37-8
Understanding IPv4 Bidirectional PIM 37-9

Default IPv4 Multicast Layer 3 Switching Configuration 37-9

IPv4 Multicast Layer 3 Switching Configuration Guidelines and Restrictions 37-10


Restrictions 37-10
Unsupported Features 37-10
Configuring IPv4 Multicast Layer 3 Switching 37-11
Source-Specific Multicast with IGMPv3, IGMP v3lite, and URD 37-11
Enabling IPv4 Multicast Routing Globally 37-11
Enabling IPv4 PIM on Layer 3 Interfaces 37-12
Enabling IP Multicast Layer 3 Switching Globally 37-12

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 xix
Contents

Enabling IP Multicast Layer 3 Switching on Layer 3 Interfaces 37-13


Configuring the Replication Mode 37-13
Enabling Local Egress Replication 37-15
Configuring the Layer 3 Switching Global Threshold 37-16
Enabling Installation of Directly Connected Subnets 37-17
Specifying the Flow Statistics Message Interval 37-17
Enabling Shortcut-Consistency Checking 37-17
Configuring ACL-Based Filtering of RPF Failures 37-18
Displaying RPF Failure Rate-Limiting Information 37-18
Configuring Multicast Boundary 37-19
Displaying IPv4 Multicast Layer 3 Hardware Switching Summary 37-19
Displaying the IPv4 Multicast Routing Table 37-22
Displaying IPv4 Multicast Layer 3 Switching Statistics 37-23
Configuring IPv4 Bidirectional PIM 37-24
Enabling IPv4 Bidirectional PIM Globally 37-24
Configuring the Rendezvous Point for IPv4 Bidirectional PIM Groups 37-25
Setting the IPv4 Bidirectional PIM Scan Interval 37-25
Displaying IPv4 Bidirectional PIM Information 37-26
Using IPv4 Debug Commands 37-28
Clearing IPv4 Multicast Layer 3 Switching Statistics 37-28
Redundancy for Multicast Traffic 37-29

CHAPTER 38 Configuring IGMP Snooping for IPv4 Multicast Traffic 38-1

Understanding IGMP Snooping 38-2


IGMP Snooping Overview 38-2
Joining a Multicast Group 38-2
Leaving a Multicast Group 38-4
Understanding the IGMP Snooping Querier 38-5
Understanding IGMP Version 3 Support 38-5
Default IGMP Snooping Configuration 38-7

IGMP Snooping Configuration Guidelines and Restrictions 38-8

IGMP Snooping Querier Configuration Guidelines and Restrictions 38-8

Configuring IGMP Snooping 38-9


Enabling IGMP Snooping 38-9
Configuring the IGMP Snooping Querier 38-10
Enabling IGMP Fast-Leave Processing 38-13
Configuring Source-Specific Multicast Mapping 38-14
CGMP Automatic Detection 38-14
Configuring IGMPv3 Explicit Host Tracking 38-15

Cisco IOS Software Configuration Guide, Release 12.2SX


xx OL-13013-06
Contents

Displaying IGMP Snooping Information 38-15

CHAPTER 39 Configuring MVR for IPv4 Multicast Traffic 39-1

Understanding MVR 39-1


Using MVR in a Multicast Television Application 39-2

Configuring MVR 39-4


Default MVR Configuration 39-4
MVR Configuration Guidelines and Limitations 39-5
Configuring MVR Global Parameters 39-5
Configuring MVR Interfaces 39-6
Displaying MVR Information 39-8
Clearing MVR Counters 39-9

CHAPTER 40 Configuring IPv4 IGMP Filtering and Router Guard 40-1

Understanding IGMP Filtering 40-1


IGMP Filtering Overview 40-2
IGMP Filters 40-2
IGMP Filter Precedence 40-4
Filter Hierarchy Example 40-4
Displaying IGMP Filtering 40-5
Clearing IGMP Filtering Statistics 40-7

Understanding Router Guard 40-7


Router Guard Overview 40-8
Configuring Router Guard 40-8
Displaying Router Guard Configurations 40-9
Displaying Router Guard Interfaces 40-10
Clearing Router Guard Statistics 40-11

CHAPTER 41 Configuring PIM Snooping 41-1

Understanding PIM Snooping 41-1

Default PIM Snooping Configuration 41-4

PIM Snooping Configuration Guidelines and Restrictions 41-4

Configuring PIM Snooping 41-5


Enabling PIM Snooping Globally 41-5
Enabling PIM Snooping in a VLAN 41-5
Disabling PIM Snooping Designated-Router Flooding 41-6

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 xxi
Contents

CHAPTER 42 Configuring IPv4 Multicast VPN Support 42-1

Understanding MVPN 42-1


MVPN Overview 42-2
Multicast Routing and Forwarding and Multicast Domains 42-2
Multicast Distribution Trees 42-2
Multicast Tunnel Interfaces 42-5
PE Router Routing Table Support for MVPN 42-6
Multicast Distributed Switching Support 42-6
Hardware-Assisted IPv4 Multicast 42-6
MVPN Configuration Guidelines and Restrictions 42-7

Configuring MVPN 42-8


Forcing Ingress Multicast Replication Mode (Optional) 42-8
Configuring a Multicast VPN Routing and Forwarding Instance 42-9
Configuring Multicast VRF Routing 42-15
Configuring Interfaces for Multicast Routing to Support MVPN 42-19

Sample Configurations for MVPN 42-21


MVPN Configuration with Default MDTs Only 42-21
MVPN Configuration with Default and Data MDTs 42-23

PART 8 Quality of Service

CHAPTER 43 Configuring PFC QoS 43-1

Understanding PFC QoS 43-2


Port Types Supported by PFC QoS 43-2
Overview 43-2
Component Overview 43-5
Understanding Classification and Marking 43-14
Policers 43-17
Understanding Port-Based Queue Types 43-20
PFC QoS Default Configuration 43-27
PFC QoS Global Settings 43-27
Default Values with PFC QoS Enabled 43-28
Default Values with PFC QoS Disabled 43-52
PFC QoS Configuration Guidelines and Restrictions 43-52
General Guidelines 43-53
Class Map Command Restrictions 43-56
Policy Map Command Restrictions 43-56
Policy Map Class Command Restrictions 43-56
Supported Granularity for CIR and PIR Rate Values 43-56

Cisco IOS Software Configuration Guide, Release 12.2SX


xxii OL-13013-06
Contents

Supported Granularity for CIR and PIR Token Bucket Sizes 43-57
IP Precedence and DSCP Values 43-58
Configuring PFC QoS 43-58
Enabling PFC QoS Globally 43-59
Enabling Ignore Port Trust 43-60
Configuring DSCP Transparency 43-61
Enabling Queueing-Only Mode 43-61
Enabling Microflow Policing of Bridged Traffic 43-62
Enabling VLAN-Based PFC QoS on Layer 2 LAN Ports 43-63
Enabling Egress ACL Support for Remarked DSCP 43-63
Creating Named Aggregate Policers 43-64
Configuring a PFC QoS Policy 43-67
Configuring Egress DSCP Mutation 43-85
Configuring Ingress CoS Mutation on IEEE 802.1Q Tunnel Ports 43-86
Configuring DSCP Value Maps 43-89
Configuring the Trust State of Ethernet LAN Ports 43-92
Configuring Trusted Boundary with Cisco Device Verification 43-94
Configuring the Ingress LAN Port CoS Value 43-94
Configuring Standard-Queue Drop Threshold Percentages 43-95
Mapping QoS Labels to Queues and Drop Thresholds 43-100
Allocating Bandwidth Between Standard Transmit Queues 43-110
Setting the Receive-Queue Size Ratio 43-112
Configuring the Transmit-Queue Size Ratio 43-113
Common QoS Scenarios 43-114
Sample Network Design Overview 43-114
Classifying Traffic from PCs and IP Phones in the Access Layer 43-115
Accepting the Traffic Priority Value on Interswitch Links 43-118
Prioritizing Traffic on Interswitch Links 43-119
Using Policers to Limit the Amount of Traffic from a PC 43-122
PFC QoS Glossary 43-123

CHAPTER 44 Using AutoQoS 44-1

Understanding AutoQoS 44-1


AutoQoS Support for a Cisco IP Phone 44-2
AutoQoS Support for Cisco IP Communicator 44-2
AutoQoS Support for Marked Traffic 44-2
Using AutoQoS 44-3
AutoQoS Configuration Guidelines and Restrictions 44-3
Configuring AutoQoS 44-4

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 xxiii
Contents

CHAPTER 45 Configuring MPLS QoS 45-1

Terminology 45-2

MPLS QoS Features 45-3


MPLS Experimental Field 45-3
Trust 45-3
Classification 45-3
Policing and Marking 45-4
Preserving IP ToS 45-4
EXP Mutation 45-4
MPLS DiffServ Tunneling Modes 45-4

MPLS QoS Overview 45-4


Specifying the QoS in the IP Precedence Field 45-5

MPLS QoS 45-5


LERs at the Input Edge of an MPLS Network 45-6
LSRs in the Core of an MPLS Network 45-6
LERs at the Output Edge of an MPLS Network 45-7
Understanding MPLS QoS 45-7
LERs at the EoMPLS Edge 45-8
LERs at the IP Edge (MPLS, MPLS VPN) 45-9
LSRs at the MPLS Core 45-13
MPLS QoS Default Configuration 45-15

MPLS QoS Commands 45-16

MPLS QoS Restrictions and Guidelines 45-17

Configuring MPLS QoS 45-17


Enabling QoS Globally 45-18
Enabling Queueing-Only Mode 45-19
Configuring a Class Map to Classify MPLS Packets 45-20
Configuring the MPLS Packet Trust State on Ingress Ports 45-22
Configuring a Policy Map 45-22
Displaying a Policy Map 45-27
Configuring MPLS QoS Egress EXP Mutation 45-28
Configuring EXP Value Maps 45-29
MPLS DiffServ Tunneling Modes 45-30
Short Pipe Mode 45-31
Uniform Mode 45-32
MPLS DiffServ Tunneling Restrictions and Usage Guidelines 45-34

Configuring Short Pipe Mode 45-34


Ingress PE RouterCustomer Facing Interface 45-34

Cisco IOS Software Configuration Guide, Release 12.2SX


xxiv OL-13013-06
Contents

Configuring Ingress PE RouterP Facing Interface 45-35


Configuring the P RouterOutput Interface 45-37
Configuring the Egress PE RouterCustomer Facing Interface 45-38

Configuring Uniform Mode 45-39


Configuring the Ingress PE RouterCustomer Facing Interface 45-39
Configuring the Ingress PE RouterP Facing Interface 45-40
Configuring the Egress PE RouterCustomer Facing Interface 45-41

CHAPTER 46 Configuring PFC QoS Statistics Data Export 46-1

Understanding PFC QoS Statistics Data Export 46-1


PFC QoS Statistics Data Export Default Configuration 46-2
Configuring PFC QoS Statistics Data Export 46-2

PART 9 Security

CHAPTER 47 Configuring Network Security 47-1

Configuring MAC Address-Based Traffic Blocking 47-2

Configuring TCP Intercept 47-2

Configuring Unicast Reverse Path Forwarding Check 47-2


Understanding PFC3 Unicast RPF Check Support 47-2
Unicast RPF Check Guidelines and Restrictions 47-3
Configuring Unicast RPF Check 47-4

CHAPTER 48 Using AutoSecure 48-1


Understanding AutoSecure 48-1
Benefits of AutoSecure 48-2
Securing the Management Plane 48-2
Securing the Forwarding Plane 48-5
AutoSecure Guidelines and Restrictions 48-6

Configuring AutoSecure 48-6


Using the AutoSecure Command 48-7
Configuring Additional Security 48-8
Verifying AutoSecure 48-8
AutoSecure Configuration Example 48-9

CHAPTER 49 Understanding Cisco IOS ACL Support 49-1

ACL Support in Hardware and Software 49-1

Cisco IOS ACL Configuration Guidelines and Restrictions 49-3

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 xxv
Contents

Policy-Based ACLs 49-3


Understanding PBACLs 49-3
PBACL Guidelines and Restrictions 49-4
Configuring PBACL 49-4
Configuring IPv6 Address Compression 49-6

Optimized ACL Logging 49-8


Understanding OAL 49-8
OAL Guidelines and Restrictions 49-8
Configuring OAL 49-8
Guidelines and Restrictions for Using Layer 4 Operators in ACLs 49-10
Determining Layer 4 Operation Usage 49-10
Determining Logical Operation Unit Usage 49-11

CHAPTER 50 Configuring Cisco TrustSec 50-1


Hardware Supported 50-3

CHAPTER 51 Configuring Port ACLs and VLAN ACLs 51-1

Understanding ACLs 51-1


Understanding ACLs 51-2
Understanding VACLs 51-2
Understanding Port ACLs 51-3
PACL and VACL Interactions 51-4
Configuring PACLs 51-7
PACL Configuration Guidelines 51-8
Configuring IP and MAC ACLs on a Layer 2 Interface 51-8
Configuring Access-group Mode on Layer 2 Interface 51-9
Applying ACLs to a Layer 2 Interface 51-9
Applying ACLs to a Port Channel 51-10
Displaying an ACL Configuration on a Layer 2 Interface 51-10
Configuring VACLs 51-11
VACL Configuration Guidelines 51-11
Defining a VLAN Access Map 51-13
Configuring a Match Clause in a VLAN Access Map Sequence 51-13
Configuring an Action Clause in a VLAN Access Map Sequence 51-14
Applying a VLAN Access Map 51-15
Verifying VLAN Access Map Configuration 51-15
VLAN Access Map Configuration and Verification Examples 51-15
Configuring a Capture Port 51-16
Configuring MAC PBF 51-17

Cisco IOS Software Configuration Guide, Release 12.2SX


xxvi OL-13013-06
Contents

Configuring VACL Logging 51-19

CHAPTER 52 Configuring Denial of Service Protection 52-1

Understanding DoS Protection 52-2

DoS Protection Default Configuration 52-13

DoS Protection Configuration Guidelines and Restrictions 52-14


Monitoring Packet Drop Statistics 52-15
Displaying Rate-Limiter Information 52-17
Configuring Sticky ARP 52-18

CHAPTER 53 Configuring Control Plane Policing 53-1


Understanding Control Plane Policing 53-1

CoPP Default Configuration 53-2

CoPP Configuration Guidelines and Restrictions 53-2

Configuring CoPP 53-3

Monitoring CoPP 53-4

Defining Traffic Classification 53-5


Traffic Classification Overview 53-5
Traffic Classification Guidelines 53-6
Sample Basic ACLs for CoPP Traffic Classification 53-7

CHAPTER 54 Configuring DHCP Snooping 54-1

Understanding DHCP Snooping 54-1


Overview of DHCP Snooping 54-2
Trusted and Untrusted Sources 54-2
DHCP Snooping Binding Database 54-3
Packet Validation 54-3
DHCP Snooping Option-82 Data Insertion 54-3
Overview of the DHCP Snooping Database Agent 54-5
DHCP Snooping Host Tracking 54-6
Default Configuration for DHCP Snooping 54-7

DHCP Snooping Configuration Restrictions and Guidelines 54-7


DHCP Snooping Configuration Restrictions 54-7
DHCP Snooping Configuration Guidelines 54-8
Minimum DHCP Snooping Configuration 54-8
Configuring DHCP Snooping 54-9
Enabling DHCP Snooping Globally 54-9
Enabling DHCP Option-82 Data Insertion 54-10

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 xxvii
Contents

Enabling the DHCP Option-82 on Untrusted Port Feature 54-11


Enabling DHCP Snooping Host Tracking 54-11
Enabling DHCP Snooping MAC Address Verification 54-12
Enabling DHCP Snooping on VLANs 54-13
Configuring the DHCP Trust State on Layer 2 LAN Interfaces 54-14
Configuring Spurious DHCP Server Detection 54-14
Configuring DHCP Snooping Rate Limiting on Layer 2 LAN Interfaces 54-15
Configuring the DHCP Snooping Database Agent 54-16
Configuration Examples for the Database Agent 54-16
Displaying a Binding Table 54-19

CHAPTER 55 Configuring IP Source Guard 55-1

Overview of IP Source Guard 55-1


IP Source Guard Interaction with VLAN-Based Features 55-2
Channel Ports 55-2
Trunk Ports 55-2
Layer 2 and Layer 3 Port Conversion 55-2
IP Source Guard and Voice VLAN 55-2
IP Source Guard and Web-Based Authentication 55-2
IP Source Guard Restrictions 55-3
Configuring IP Source Guard on the Switch 55-3

Displaying IP Source Guard Information 55-4

Displaying IP Source Binding Information 55-6

CHAPTER 56 Configuring Dynamic ARP Inspection 56-1


Understanding DAI 56-1
Understanding ARP 56-2
Understanding ARP Spoofing Attacks 56-2
Understanding DAI and ARP Spoofing Attacks 56-2
Interface Trust States and Network Security 56-3
Rate Limiting of ARP Packets 56-4
Relative Priority of ARP ACLs and DHCP Snooping Entries 56-4
Logging of Dropped Packets 56-5
Default DAI Configuration 56-5

DAI Configuration Guidelines and Restrictions 56-6

Configuring DAI 56-6


Enabling DAI on VLANs 56-7
Configuring the DAI Interface Trust State 56-8
Applying ARP ACLs for DAI Filtering 56-8

Cisco IOS Software Configuration Guide, Release 12.2SX


xxviii OL-13013-06
Contents

Configuring ARP Packet Rate Limiting 56-9


Enabling DAI Error-Disabled Recovery 56-10
Enabling Additional Validation 56-11
Configuring DAI Logging 56-12
Displaying DAI Information 56-14
DAI Configuration Samples 56-15
Sample One: Two Switches Support DAI 56-16
Sample Two: One Switch Supports DAI 56-20

CHAPTER 57 Configuring Traffic Storm Control 57-1

Understanding Traffic Storm Control 57-1

Default Traffic Storm Control Configuration 57-3

Configuration Guidelines and Restrictions 57-3

Configuring Traffic Storm Control 57-4


Enabling Traffic Storm Control 57-4
Configuring the Traffic Storm Control Shutdown Mode 57-6
Configuring Traffic Storm Control SNMP Traps 57-6
Displaying Traffic Storm Control Settings 57-7

CHAPTER 58 Configuring Unknown Unicast and Multicast Flood Control 58-1

Understanding Unknown Traffic Flood Control 58-2

Configuring UUFB or UMFB 58-2

Configuring UUFRL 58-3

CHAPTER 59 Configuring Network Admission Control 59-1

Understanding NAC 59-1


NAC Overview 59-2
NAC Device Roles 59-3
AAA Down Policy 59-4
NAC IP Validation 59-4
NAC and Switchover 59-12
Configuring NAC 59-12
Default NAC Configuration 59-12
NAC IP Guidelines, Limitations, and Restrictions 59-12
Configuring NAC IP Validation 59-14
Configuring EAPoUDP 59-18
Configuring Identity Profiles and Policies 59-18
Configuring NAC High Availability 59-19

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 xxix
Contents

Configuring a NAC AAA Down Policy 59-20

Monitoring and Maintaining NAC 59-23


Clearing Table Entries 59-23
Displaying NAC Information 59-23

CHAPTER 60 Configuring IEEE 802.1X Port-Based Authentication 60-1

Understanding 802.1X Port-Based Authentication 60-1


Understanding 802.1X Device Roles 60-2
Understanding the Port-based Authentication Process 60-3
Authentication Initiation and Message Exchange 60-6
Ports in Authorized and Unauthorized States 60-8
802.1X Host Modes 60-9
Understanding 802.1X Authentication with DHCP Snooping 60-11
Understanding 802.1X Accounting 60-12
Understanding 802.1X Authentication with VLAN Assignment 60-13
Understanding Multiple VLANs and VLAN User Distribution with VLAN Assignment 60-15
Understanding 802.1X Authentication with Guest VLAN 60-15
Understanding 802.1X Authentication with Restricted VLAN 60-16
Understanding 802.1X Authentication with Inaccessible Authentication Bypass 60-17
Understanding 802.1X Authentication with Voice VLAN Ports 60-18
Understanding 802.1X Authentication Critical Voice VLAN Support 60-19
Understanding 802.1X Authentication with Port Security 60-19
Understanding 802.1X Authentication with ACL Assignments and Redirect URLs 60-20
Understanding 802.1X Authentication with Port Descriptors 60-22
Understanding 802.1X Authentication with MAC Authentication Bypass 60-23
Understanding Network Admission Control Layer 2 IEEE 802.1X Validation 60-24
Understanding RADIUS Change of Authorization 60-25
Understanding 802.1X Authentication with Wake-on-LAN 60-25
Understanding MAC Move 60-26
Understanding MAC Replace 60-27
Understanding 802.1x Supplicant and Authenticator Switches with Network Edge Access Topology
(NEAT) 60-27
802.1X Authentication Feature Configuration Guidelines 60-29
802.1X Authentication 60-29
802.1X Host Mode 60-30
VLAN Assignment, Guest VLAN, Restricted VLAN, and Inaccessible Authentication Bypass 60-31
MAC Authentication Bypass 60-32
Web-Based Authentication 60-33
Configuring 802.1X Port-Based Authentication 60-33

Cisco IOS Software Configuration Guide, Release 12.2SX


xxx OL-13013-06
Contents

Default 802.1X Port-Based Authentication Configuration 60-34


Enabling 802.1X Authentication 60-35
Configuring Switch-to-RADIUS-Server Communication 60-37
Configuring 802.1X Authenticator Host Mode 60-38
Enabling Fallback Authentication 60-40
Enabling Periodic Reauthentication 60-42
Manually Reauthenticating the Client Connected to a Port 60-43
Initializing Authentication for the Client Connected to a Port 60-44
Removing 802.1X Client Information 60-44
Clearing Authentication Sessions 60-45
Changing 802.1X Timeouts 60-45
Setting the Switch-to-Client Frame Retransmission Number 60-47
Setting the Reauthentication Number 60-47
Configuring IEEE 802.1X Accounting 60-48
Configuring VLAN User Distribution 60-49
Configuring a Guest VLAN 60-49
Configuring a Restricted VLAN 60-51
Configuring the Inaccessible Authentication Bypass Feature 60-53
Enabling Critical Voice VLAN Support 60-56
Configuring MAC Authentication Bypass 60-57
Configuring NAC Layer 2 IEEE 802.1X Validation 60-58
Configuring NAC Agentless Audit Support 60-59
Configuring the Switch for DACLs or Redirect URLs 60-60
Configuring a Port to Ignore CoA Commands 60-62
Configuring 802.1X Authentication with WoL 60-62
Disabling 802.1X Authentication on the Port 60-63
Resetting the 802.1X Configuration to the Default Values 60-63
Configuring an Authenticator and a Supplicant Switch with NEAT 60-64
Displaying Authentication Status and Information 60-65
Displaying 802.1X Status 60-66
Displaying Authentication Methods and Status 60-67
Displaying MAC Authentication Bypass Status 60-70
Enabling MAC Move 60-71
Enabling MAC Replace 60-71

CHAPTER 61 Configuring Web-Based Authentication 61-1


Understanding Web-Based Authentication 61-1
Device Roles 61-2
Host Detection 61-3

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 xxxi
Contents

Session Creation 61-3


Authentication Process 61-3
AAA Fail Policy 61-4
Customization of the Authentication Proxy Web Pages 61-4
Web-based Authentication Interactions with Other Features 61-5
Configuring Web-Based Authentication 61-6
Default Web-Based Authentication Configuration 61-7
Web-based Authentication Configuration Guidelines and Restrictions 61-7
Web-based Authentication Configuration Task List 61-8
Configuring the Authentication Rule and Interfaces 61-8
Configuring AAA Authentication 61-9
Configuring Switch-to-RADIUS-Server Communication 61-9
Configuring the HTTP Server 61-11
Configuring an AAA Fail Policy 61-13
Configuring the Web-based Authentication Parameters 61-14
Removing Web-based Authentication Cache Entries 61-15
Displaying Web-Based Authentication Status 61-15

CHAPTER 62 Configuring Port Security 62-1

Understanding Port Security 62-1


Port Security with Dynamically Learned and Static MAC Addresses 62-2
Port Security with Sticky MAC Addresses 62-2
Port Security with IP Phones 62-3
Default Port Security Configuration 62-3

Port Security Guidelines and Restrictions 62-3


Configuring Port Security 62-5
Enabling Port Security 62-5
Configuring the Port Security Violation Mode on a Port 62-6
Configuring the Port Security Rate Limiter 62-7
Configuring the Maximum Number of Secure MAC Addresses on a Port 62-9
Enabling Port Security with Sticky MAC Addresses on a Port 62-9
Configuring a Static Secure MAC Address on a Port 62-10
Configuring Secure MAC Address Aging on a Port 62-11
Displaying Port Security Settings 62-12

PART 10 NetFlow

Cisco IOS Software Configuration Guide, Release 12.2SX


xxxii OL-13013-06
Contents

CHAPTER 63 Configuring NetFlow 63-1

Understanding NetFlow 63-1


NetFlow Overview 63-2
NetFlow on the PFC 63-2
NetFlow on the RP 63-3
NetFlow Features 63-3

Default NetFlow Configuration 63-4

NetFlow Restrictions 63-4


General NetFlow Restrictions 63-5
Flow Mask Conflicts 63-6
Example Feature Configurations 63-7
Configuring NetFlow 63-9
Configuring NetFlow on the PFC 63-10
Configuring NetFlow Features 63-13

CHAPTER 64 Configuring NDE 64-1

Understanding NDE 64-2


NDE Overview 64-2
NDE on the RP 64-2
NDE on the PFC 64-2
Default NDE Configuration 64-10

NDE Configuration Guidelines and Restrictions 64-10

Configuring NDE 64-10


Configuring NDE on the PFC 64-11
Configuring NDE on the RP 64-13
Enabling NDE for Ingress-Bridged IP Traffic 64-14
Displaying the NDE Address and Port Configuration 64-15
Configuring NDE Flow Filters 64-16
Displaying the NDE Configuration 64-17

PART 11 Network Management

CHAPTER 65 Configuring Call Home 65-1

Understanding Call Home 65-2

Obtaining Smart Call Home 65-3

Default Settings 65-3

Configuring Call Home 65-3


Configuration Overview 65-4

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 xxxiii
Contents

Configuring Customer Contact Information 65-4


Configuring Destination Profiles 65-5
Subscribing to Alert Groups 65-13
Enabling Call Home 65-16
Testing Call Home Communications 65-16
Configuring and Enabling Smart Call Home 65-19
Configuring the Smart Call Home Service 65-20
Enabling the Smart Call Home Service 65-20
Declare and Authenticate a CA Trustpoint 65-21
Start Smart Call Home Registration 65-22
Displaying Call Home Configuration Information 65-23

Alert Group Trigger Events and Commands 65-26


Message Contents 65-33
Sample Syslog Alert Notification in Long-Text Format 65-37
Sample Syslog Alert Notification in XML Format 65-37

CHAPTER 66 Using the System Event Archive 66-1

Understanding the System Event Archive 66-1

Displaying the SEA Logging System 66-2

Copying the SEA To Another Device 66-3

CHAPTER 67 Backplane Traffic Monitoring 67-1

Understanding Traffic Monitoring 67-1

Default Configuration 67-2


Configuration Guidelines and Restrictions 67-2

Configuring Backplane Traffic Monitoring 67-2

CHAPTER 68 Configuring Local SPAN, RSPAN, and ERSPAN 68-1

Understanding Local SPAN, RSPAN, and ERSPAN 68-1


Local SPAN, RSPAN, and ERSPAN Overview 68-2
Local SPAN, RSPAN, and ERSPAN Sources 68-5
Local SPAN, RSPAN, and ERSPAN Destinations 68-7
Local SPAN, RSPAN, and ERSPAN Configuration Guidelines and Restrictions 68-7
General Guidelines and Restrictions 68-8
Feature Incompatibilities 68-8
Local SPAN, RSPAN, and ERSPAN Session Limits 68-10
Local SPAN, RSPAN, and ERSPAN Interface Limits 68-10
Local SPAN, RSPAN, and ERSPAN Guidelines and Restrictions 68-10

Cisco IOS Software Configuration Guide, Release 12.2SX


xxxiv OL-13013-06
Contents

VSPAN Guidelines and Restrictions 68-11


RSPAN Guidelines and Restrictions 68-12
ERSPAN Guidelines and Restrictions 68-13
Distributed Egress SPAN Mode Guidelines and Restrictions 68-14

Configuring Local SPAN, RSPAN, and ERSPAN 68-15


Local SPAN, RSPAN, and ERSPAN Default Configuration 68-15
Configuring a Destination as an Unconditional Trunk (Optional) 68-16
Configuring Destination Trunk VLAN Filtering (Optional) 68-16
Configuring Destination Port Permit Lists (Optional) 68-18
Configuring the Egress SPAN Mode (Optional) 68-18
Configuring Local SPAN 68-19
Configuring RSPAN 68-23
Configuring ERSPAN 68-30
Configuring Source VLAN Filtering in Global Configuration Mode 68-34
Verifying the Configuration 68-35
Configuration Examples 68-35

CHAPTER 69 Configuring SNMP IfIndex Persistence 69-1

Understanding SNMP IfIndex Persistence 69-1

Configuring SNMP IfIndex Persistence 69-2


Enabling SNMP IfIndex Persistence Globally 69-2
Disabling SNMP IfIndex Persistence Globally 69-2
Enabling and Disabling SNMP IfIndex Persistence on Specific Interfaces 69-3
Clearing SNMP IfIndex Persistence Configuration from a Specific Interface 69-3

CHAPTER 70 Using Top-N Reports 70-1


Understanding Top-N Reports 70-1
Top-N Reports Overview 70-1
Understanding Top-N Reports Operation 70-2

Using Top-N Reports 70-2


Enabling Top-N Reports Creation 70-3
Displaying Top-N Reports 70-3
Clearing Top-N Reports 70-4

CHAPTER 71 Using the Layer 2 Traceroute Utility 71-1

Understanding the Layer 2 Traceroute Utility 71-1

Usage Guidelines 71-2

Using the Layer 2 Traceroute Utility 71-3

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 xxxv
Contents

CHAPTER 72 Using the Mini Protocol Analyzer 72-1

Understanding How the Mini Protocol Analyzer Works 72-1

Configuring the Mini Protocol Analyzer 72-2


Filtering the Packets to be Captured 72-3
Starting and Stopping a Capture 72-4

Displaying and Exporting the Capture Buffer 72-6

Mini Protocol Analyzer Configuration, Operation, and Display Examples 72-7


General Configuration Examples 72-7
Filtering Configuration Examples 72-8
Operation Examples 72-9
Display Examples 72-9

PART 12 Appendixes

APPENDIX A Configuring Ethernet Services Plus Line Cards A-1

Release 12.2SX ES+ Line Card Support and Restrictions A-2

Line Card Configuration A-2


Displaying the ES+ Line Card Type A-3
Resetting an ES+ Line Card A-3
Configuring QoS A-3
Supported Interfaces A-4
QoS Functions A-4
Configuring Classification A-6
Configuring Policing A-9
Configuring Marking A-16
Configuring Shaping A-19
Configuring QoS Queue Scheduling A-21
Configuring Hierarchical QoS A-29
Configuring MPLS Traffic Engineering Class-Based Tunnel Selection A-32
MPLS Traffic Engineering Overview A-33
MPLS Traffic Engineering Class-Based Tunnel Selection Restrictions and Usage Guidelines A-33
Creating Multiple MPLS Member TE or DS-TE Tunnels with the Same Headend and the Same
Tailend A-34
Creating a Master Tunnel, Attaching Member Tunnels, and Making the Master Tunnel Visible A-35
Verifying the MPLS Configuration A-38
Configuring IPoDWDM A-41
IPoDWDM-Capable ES+ Line Cards A-41
WAN PHY and OTN Support on ES+ Line Cards A-41

Cisco IOS Software Configuration Guide, Release 12.2SX


xxxvi OL-13013-06
Contents

Upgrading Field-Programmable Devices A-49


Overview of FPD Images and Packages A-49
FPD Quick Upgrade A-50
Upgrading FPD Images A-51
Optional FPD Procedures A-54
FPD Image Upgrade Examples A-56
Troubleshooting A-57
Using the Cisco IOS Event Tracer to Troubleshoot Problems A-58
Troubleshooting XFP Issues A-58
Preparing for Online Insertion and Removal of ES+ Line Cards A-59

APPENDIX B Online Diagnostic Tests B-1


Global Health-Monitoring Tests B-2
TestEARLInternalTables B-2
TestSPRPInbandPing B-3
TestScratchRegister B-3
TestMacNotification B-4
TestErrorCounterMonitor B-4
TestLtlFpoeMemoryConsistency B-5
TestMgmtPortsLoopback B-5
TestDataPortLoopback B-6
Per-Port Tests B-6
TestNonDisruptiveLoopback B-7
TestLoopback B-7
TestActiveToStandbyLoopback B-8
TestUnusedPortLoopback B-8
TestTransceiverIntegrity B-9
TestNetflowInlineRewrite B-9
TestPortTxMonitoring B-10
TestSnrMonitoring B-10
TestDCPLoopback B-11
TestCCPLoopback B-11
TestNPLoopback B-12
TestMediaLoopback B-13
PFC Layer 2 Forwarding Engine Tests B-13
TestNewIndexLearn B-13
TestDontConditionalLearn B-14
TestBadBpduTrap B-14
TestMatchCapture B-15

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 xxxvii
Contents

TestStaticEntry B-15

DFC Layer 2 Forwarding Engine Tests B-16


TestDontLearn B-16
TestNewLearn B-16
TestIndexLearn B-17
TestConditionalLearn B-18
TestTrap B-18
TestBadBpdu B-19
TestProtocolMatchChannel B-19
TestCapture B-20
TestStaticEntry B-20
PFC Layer 3 Forwarding Engine Tests B-21
TestFibDevices B-21
TestIPv4FibShortcut B-22
TestIPv6FibShortcut B-22
TestMPLSFibShortcut B-23
TestNATFibShortcut B-23
TestL3Capture2 B-24
TestAclPermit B-24
TestAclDeny B-25
TestNetflowShortcut B-25
TestQoS B-26
DFC Layer 3 Forwarding Engine Tests B-26
TestFibDevices B-26
TestIPv4FibShortcut B-27
TestIPv6FibShortcut B-28
TestMPLSFibShortcut B-28
TestNATFibShortcut B-29
TestL3Capture2 B-29
TestAclPermit B-30
TestAclDeny B-30
TestQoS B-31
TestNetflowShortcut B-31
TestAclFpgaMonitor B-32
Replication Engine Tests B-32
TestL3VlanMet B-32
TestIngressSpan B-33
TestEgressSpan B-33
Fabric Tests B-34

Cisco IOS Software Configuration Guide, Release 12.2SX


xxxviii OL-13013-06
Contents

TestFabricSnakeForward B-34
TestFabricSnakeBackward B-34
TestSynchedFabChannel B-35
TestFabricCh0Health B-36
TestFabricCh1Health B-36
Exhaustive Memory Tests B-36
TestFibTcamSSRAM B-37
TestAsicMemory B-37
TestAclQosTcam B-38
TestNetflowTcam B-38
TestQoSTcam B-39
IPSEC Services Modules Tests B-39
TestIPSecClearPkt B-39
TestHapiEchoPkt B-40
TestIPSecEncryptDecryptPkt B-40
Stress Tests B-41
TestTrafficStress B-41
TestEobcStressPing B-41
TestMicroburst B-42
Critical Recovery Tests B-42
TestL3HealthMonitoring B-42
TestTxPathMonitoring B-43
TestSynchedFabChannel B-43
General Tests B-44
ScheduleSwitchover B-44
TestFirmwareDiagStatus B-44
TestCFRW B-45
ViSN Tests B-45
TestVslLocalLoopback B-45
TestVslStatus B-46
TestVslBridgeLink B-46
TestVSActiveToStandbyLoopback B-46

APPENDIX C Acronyms C-1

INDEX

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 xxxix
Contents

Cisco IOS Software Configuration Guide, Release 12.2SX


xl OL-13013-06
Preface

This preface describes who should read the Cisco IOS Software Configuration Guide, Release 12.2SX ,
and its document conventions.

Audience
This guide is for experienced network administrators who are responsible for configuring and
maintaining the switches supported in Cisco IOS Release 12.2SX.

Related Documentation
The following publications are available for Cisco IOS Release 12.2SX:
Catalyst 6500 Series Switch Installation Guide
Catalyst 6500 Series Switch Module Installation Guide
Cisco IOS Master Command List, Release 12.2SX
Catalyst 6500 Series Switch Cisco IOS System Message Guide, Release 12.2SX
Release Notes for Cisco IOS Release 12.2SX
Cisco IOS Configuration Guides and Command References:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html
For information about MIBs, go to this URL:
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

Conventions
This document uses the following conventions:

Convention Description
boldface font Commands, command options, and keywords are in boldface.
italic font Arguments for which you supply values are in italics.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 xli
Preface

Convention Description
[ ] Elements in square brackets are optional.
{x|y|z} Alternative keywords are grouped in braces and separated by vertical bars.
[x|y|z] Optional alternative keywords are grouped in brackets and separated by
vertical bars.
string A nonquoted set of characters. Do not use quotation marks around the
string or the string will include the quotation marks.
screen font Terminal sessions and information the system displays are in screen font.
boldface screen Information you must enter is in boldface screen font.
font
italic screen font Arguments for which you supply values are in italic screen font.
This pointer highlights an important line of text in an example.

^ The symbol ^ represents the key labeled Controlfor example, the key
combination ^D in a screen display means hold down the Control key
while you press the D key.
< > Nonprinting characters, such as passwords are in angle brackets.

Notes use the following conventions:

Note Means reader take note. Notes contain helpful suggestions or references to material not covered in the
publication.

Cautions use the following conventions:

Caution Means reader be careful. In this situation, you might do something that could result in equipment
damage or loss of data.

Obtaining Documentation, Obtaining Support, and Security


Guidelines
For information on obtaining documentation, obtaining support, providing documentation feedback,
security guidelines, and also recommended aliases and general Cisco documents, see the monthly
Whats New in Cisco Product Documentation, which also lists all new and revised Cisco technical
documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Cisco IOS Software Configuration Guide, Release 12.2SX


xlii OL-13013-06
C H A P T E R 1
Product Overview

This chapter consists of these sections:


Supervisor Engine Memory Devices and Ports, page 1-1
User Interfaces, page 1-5
Module Status Monitoring, page 1-6
Software Features Supported in Hardware by the PFC and DFC, page 1-6

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Supervisor Engine Memory Devices and Ports


For complete information about the chassis, modules, and software features supported by
Cisco IOS Release 12.2SX, see the Release Notes for Cisco IOS Release 12.2SX:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/release/notes/ol_14271.html
These sections describe the ports and flash memory devices on the supervisor engines:
Understanding Supervisor Engine 720-10GE Memory Devices and Ports, page 1-1
Understanding Supervisor Engine 720 Memory Devices and Ports, page 1-2
Understanding Supervisor Engine 32 Memory Devices and Ports, page 1-4
Understanding ME6500 Flash Memory Devices and Ports, page 1-5

Understanding Supervisor Engine 720-10GE Memory Devices and Ports


These sections describe the Supervisor Engine 720-10GE memory devices and ports:
Supervisor Engine 720-10GE Flash Memory Devices, page 1-2
Supervisor Engine 720-10GE Ports, page 1-2

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 1-1
Chapter 1 Product Overview
Supervisor Engine Memory Devices and Ports

Supervisor Engine 720-10GE Flash Memory Devices


The Supervisor Engine 720-10GE has these flash memory devices:
disk0: (active) and slavedisk0: (standby):
External CompactFlash Type II slots
For CompactFlash Type II flash PC cards sold by Cisco Systems, Inc.
sup-bootdisk: (active) and slavesup-bootdisk: (standby):
Switch processor (SP) 1-GB internal CompactFlash flash memory
From SP ROMMON, it is bootdisk:
Not accessible from route processor (RP) ROMMON
bootflash: (active) and slave-bootflash: (standby):
RP 64-MB internal flash memory
Not accessible from SP ROMMON

Supervisor Engine 720-10GE Ports


The Supervisor Engine 720-10GE has these ports:
Console portEIA/TIA-232 (RS-232) port
Ports 1 and 2
Gigabit Ethernet SFP (fiber or 10/100/1000 Mbps RJ-45)
Fast Ethernet SFP
Port 310/100/1000 Mbps RJ-45
Ports 4 and 510-Gigabit Ethernet X2

Note The 1-Gigabit Ethernet ports and the 10-Gigabit Ethernet ports have the same QoS port architecture
(2q4t/1p3q4t) unless you disable the 1-Gigabit Ethernet ports with the mls qos 10g-only global
configuration command. With the 1-Gigabit Ethernet ports disabled, the QoS port architecture of the
10-Gigabit Ethernet ports is 8q4t/1p7q4t.

See the Configuring Optional Interface Features section on page 8-6 for information about configuring
the ports.

Understanding Supervisor Engine 720 Memory Devices and Ports


These sections describe the Supervisor Engine 720 memory devices and ports:
Supervisor Engine 720 Flash Memory Devices, page 1-3
Configuring Supervisor Engine 720 Ports, page 1-3

Cisco IOS Software Configuration Guide, Release 12.2SX


1-2 OL-13013-06
Chapter 1 Product Overview
Supervisor Engine Memory Devices and Ports

Supervisor Engine 720 Flash Memory Devices


The Supervisor Engine 720 has these flash memory devices:
disk0: and disk1: (active) and slavedisk0: and slavedisk1: (standby):
External CompactFlash Type II slots
For CompactFlash Type II flash PC cards sold by Cisco Systems, Inc.
sup-bootflash: (active) and slavesup-bootflash: (standby):
Switch processor (SP) 64-MB internal flash memory
From SP ROMMON, it is bootflash:
Not accessible from route processor (RP) ROMMON
With WS-CF-UPG=, sup-bootdisk: (active) and slavesup-bootflash: (standby):
SP 512-MB internal CompactFlash flash memory
From SP ROMMON, it is bootdisk:
Not accessible from RP ROMMON
See this publication for more information:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/hardware/Config_Notes/78_1727
7.html
bootflash: (active) and slave-bootflash: (standby):
RP 64-MB internal flash memory
Not accessible from SP ROMMON

Configuring Supervisor Engine 720 Ports


The Supervisor Engine 720 has these ports:
Port 1Small form-factor pluggable (SFP); no unique configuration options.
Port 2 RJ-45 connector and an SFP connector (default). To use the RJ-45 connector, you must
change the configuration.
To configure port 2 on a Supervisor Engine 720 to use either the RJ-45 connector or the SFP
connector, perform this task:

Command Purpose
Step 1 Router(config)# interface gigabitethernet slot/2 Selects the Ethernet port to be configured.
Step 2 Router(config-if)# media-type {rj45 | sfp} Selects the connector to use.

This example shows how to configure port 2 on a Supervisor Engine 720 in slot 5 to use the RJ-45
connector:
Router(config)# interface gigabitethernet 5/2
Router(config-if)# media-type rj45

See the Configuring Optional Interface Features section on page 8-6 for more information about
configuring the ports.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 1-3
Chapter 1 Product Overview
Supervisor Engine Memory Devices and Ports

Understanding Supervisor Engine 32 Memory Devices and Ports


These sections describe the Supervisor Engine 32 memory devices and ports:
Supervisor Engine 32 Flash Memory Devices, page 1-4
Supervisor Engine 32 Ports, page 1-4

Note Supervisor Engine 32 does not support switch fabric connectivity.

Supervisor Engine 32 Flash Memory Devices


The Supervisor Engine 32 has these flash memory devices:
disk0: (active) and slavedisk0: (standby):
External CompactFlash Type II slots
For CompactFlash Type II flash PC cards sold by Cisco Systems, Inc.
sup-bootdisk: (active) and slavesup-bootflash: (standby):
Switch processor (SP) 256-MB internal CompactFlash flash memory
From SP ROMMON, it is bootdisk:
Not accessible from route processor (RP) ROMMON
bootflash: (active) and slave-bootflash: (standby):
RP 64-MB internal flash memory
Not accessible from SP ROMMON

Supervisor Engine 32 Ports


The Supervisor Engine 32 has these ports:
Console portEIA/TIA-232 (RS-232) port
Two Universal Serial Bus (USB) 2.0 portsNot currently enabled
WS-SUP32-GE-3B:
Ports 1 through 8Small form-factor pluggable (SFP)
Port 910/100/1000 Mbps RJ-45
WS-SUP32-10GE:
Ports 1 and 210-Gigabit Ethernet XENPAK
Port 310/100/1000 Mbps RJ-45
See the Configuring Optional Interface Features section on page 8-6 for information about configuring
the ports.

Cisco IOS Software Configuration Guide, Release 12.2SX


1-4 OL-13013-06
Chapter 1 Product Overview
User Interfaces

Understanding ME6500 Flash Memory Devices and Ports


These sections describe the Cisco ME6500 series Ethernet switch memory devices and ports:
ME6500 Flash Memory Devices, page 1-5
ME6500 Ports, page 1-5

ME6500 Flash Memory Devices


The ME6500 has these flash memory devices:
disk0:
One external CompactFlash Type II slot
Supports CompactFlash Type II flash PC cards
sup-bootflash:
Switch processor (SP) 128 MB internal CompactFlash flash memory
From SP ROMMON, it is bootflash:
Not accessible from route processor (RP) ROMMON
bootflash:
RP 64-MB internal flash memory
Not accessible from SP ROMMON

ME6500 Ports
The ME6500 has these ports:
ME-C6524GS-8S and ME-C6524GT-8S
Ports 2532: Gigabit Ethernet SFP
Requires Gigabit Ethernet SFPs
ME-C6524GS-8S
Ports 124: Gigabit Ethernet SFP
Requires Gigabit Ethernet SFPs
ME-C6524GT-8SPorts 124: 10/100/1000 Mbps RJ-45 Ethernet ports

User Interfaces
Release 12.2SX supports configuration using the following interfaces:
CLISee Chapter 2, Command-Line Interfaces.
SNMPSee the Release 12.2 IOS Configuration Fundamentals Configuration Guide and
Command Reference at this URL:
http://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide/ffun_c.html

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 1-5
Chapter 1 Product Overview
Module Status Monitoring

Cisco IOS web browser interfaceSee Using the Cisco Web Browser in the IOS Configuration
Fundamentals Configuration Guide at this URL:
http://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide/fcf005.html

Module Status Monitoring


The supervisor engine polls the installed modules with Switch Communication Protocol (SCP) messages
to monitor module status.
The SCP sends a message every two seconds to each module. Module nonresponse after 3 messages
(6 seconds) is classified as a failure. CPU_MONITOR system messages are sent every 30 seconds. After
25 sequential failures (150 seconds), the supervisor engine power cycles the module and sends a
CPU_MONITOR TIMED_OUT system message and OIR PWRCYCLE system messages.

Software Features Supported in Hardware by the PFC and DFC


The PFC3 and DFC3 provide hardware support for these Cisco IOS software features:
Access Control Lists (ACLs) for Layer 3 ports and VLAN interfaces:
Permit and deny actions of input and output standard and extended ACLs

Note Flows that require ACL logging are processed in software on the route processor (RP).

Except on MPLS interfaces, reflexive ACL flows after the first packet in a session is processed
in software on the RP
Dynamic ACL flows

Note Idle timeout is processed in software on the RP.

For more information about PFC and DFC support for ACLs, see Chapter 49, Understanding Cisco
IOS ACL Support.
For complete information about configuring ACLs, see the Cisco IOS Security Configuration Guide,
Release 12.2, Traffic Filtering and Firewalls, at this URL:
http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfacls.html
Bidirectional Protocol Independent Multicast (PIM) in hardwareSee Understanding IPv4
Bidirectional PIM section on page 37-9.
IPv4 Multicast over point-to-point generic route encapsulation (GRE) TunnelsSee the publication
at this URL:
http://www.cisco.com/en/US/docs/ios/12_2/interface/configuration/guide/icflogin.html
Multiple-path Unicast Reverse Path Forwarding (RPF) CheckTo configure Unicast RPF Check,
see the Configuring Unicast Reverse Path Forwarding Check section on page 47-2.
Except on MPLS interfaces, Network Address Translation (NAT) for IPv4 unicast and multicast
traffic.
Note the following information about hardware-assisted NAT:

Cisco IOS Software Configuration Guide, Release 12.2SX


1-6 OL-13013-06
Chapter 1 Product Overview
Software Features Supported in Hardware by the PFC and DFC

NAT of UDP traffic is not supported in PFC3A mode.


The PFC3 does not support NAT of multicast traffic.
The PFC3 does not support NAT configured with a route-map that specifies length.
When you configure NAT and NDE on an interface, the PFC3 sends all traffic in fragmented
packets to the RP to be processed in software. (CSCdz51590)
To configure NAT, see the Cisco IOS IP Configuration Guide, Release 12.2, IP Addressing and
Services, Configuring IP Addressing, Configuring Network Address Translation, at this URL:
http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfipadr.html
To prevent a significant volume of NAT traffic from being sent to the RP, due to either a DoS attack
or a misconfiguration, enter the mls rate-limit unicast acl {ingress | egress} command described
at this URL:
http://www.cisco.com/en/US/docs/ios/security/command/reference/sec_m2.html#mls_rate-limit_u
nicast_acl
(CSCea23296)
NetFlow AggregationSee this URL:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/netfl
ow.html#NetFlow_Aggregation
Policy-based routing (PBR) for route-map sequences that use the match ip address, set ip
next-hop, and ip default next-hop PBR keywords.
To configure PBR, see the Cisco IOS Quality of Service Solutions Configuration Guide, Release
12.2, Classification, Configuring Policy-Based Routing, at this URL:
http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfpbr_ps1835_TSD_Products_C
onfiguration_Guide_Chapter.html

Note If the RP address falls within the range of a PBR ACL, traffic addressed to the RP is policy
routed in hardware instead of being forwarded to the RP. To prevent policy routing of traffic
addressed to the RP, configure PBR ACLs to deny traffic addressed to the RP.

Except on MPLS interfaces, TCP interceptTo configure TCP intercept, see the Configuring TCP
Intercept section on page 47-2.

Note The PFC3 does not provide hardware acceleration for tunnels configured with the tunnel key command.

GRE Tunneling and IP in IP TunnelingThe PFC3 and DFC3s support the following tunnel
commands:
tunnel destination
tunnel mode gre
tunnel mode ipip
tunnel source
tunnel ttl
tunnel tos
Other supported types of tunneling run in software on the RP.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 1-7
Chapter 1 Product Overview
Software Features Supported in Hardware by the PFC and DFC

The tunnel ttl command (default 255) sets the TTL of encapsulated packets.
The tunnel tos command, if present, sets the ToS byte of a packet when it is encapsulated. If the
tunnel tos command is not present and QoS is not enabled, the ToS byte of a packet sets the ToS
byte of the packet when it is encapsulated. If the tunnel tos command is not present and QoS is
enabled, the ToS byte of a packet as modified by PFC QoS sets the ToS byte of the packet when it
is encapsulated.
To configure GRE Tunneling and IP in IP Tunneling, see these publications:
http://www.cisco.com/en/US/docs/ios/12_2/interface/configuration/guide/icflogin.html
http://www.cisco.com/en/US/docs/ios/12_2/interface/command/reference/irfshoip.html
To configure the tunnel tos and tunnel ttl commands, see this publication for more information:
http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/12s_tos.html
Note the following information about tunnels:
Each hardware-assisted tunnel must have a unique source. Hardware-assisted tunnels cannot
share a source even if the destinations are different. Use secondary addresses on loopback
interfaces or create multiple loopback interfaces. Failure to use unique source addresses may
result in control plane failures when software path congestion occurs. (CSCdy72539)
Each tunnel interface uses one internal VLAN.
Each tunnel interface uses one additional router MAC address entry per router MAC address.
The PFC3A does not support any PFC QoS features on tunnel interfaces.
Other PFC versions support PFC QoS features on tunnel interfaces.
The RP supports tunnels configured with egress features on the tunnel interface. Examples of
egress features are output Cisco IOS ACLs, NAT (for inside to outside translation), TCP
intercept, and encryption.
VLAN ACLs (VACLs)To configure VACLs, see Chapter 51, Configuring Port ACLs and VLAN
ACLs.

Cisco IOS Software Configuration Guide, Release 12.2SX


1-8 OL-13013-06
P A R T 1

Configuration Fundamentals
C H A P T E R 2
Command-Line Interfaces

This chapter describes the command-line interfaces (CLIs) you use to configure the switches supported
by Cisco IOS Release 12.2SX.

Note For complete syntax and usage information for the commands used in this chapter, see these
publications:
The Cisco IOS Master Command List, Release 12.2SX, at this URL:
http://www.cisco.com/en/US/docs/ios/mcl/122sxmcl/12_2sx_mcl_book.html
The Release 12.2 publications at this URL:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_installation_and_configuratio
n_guides_list.html

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

This chapter consists of these sections:


Accessing the CLI, page 2-2
Performing Command Line Processing, page 2-3
Performing History Substitution, page 2-4
Cisco IOS Command Modes, page 2-4
Displaying a List of Cisco IOS Commands and Syntax, page 2-5
Securing the CLI, page 2-6
ROM-Monitor Command-Line Interface, page 2-7

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 2-1
Chapter 2 Command-Line Interfaces
Accessing the CLI

Accessing the CLI


These sections describe accessing the CLI:
Accessing the CLI through the EIA/TIA-232 Console Interface, page 2-2
Accessing the CLI through Telnet, page 2-2

Accessing the CLI through the EIA/TIA-232 Console Interface

Note EIA/TIA-232 was known as recommended standard 232 (RS-232) before its acceptance as a standard by
the Electronic Industries Alliance (EIA) and Telecommunications Industry Association (TIA).

Perform initial configuration over a connection to the EIA/TIA-232 console interface. See the
Catalyst 6500 Series Switch Module Installation Guide for console interface cable connection
procedures.
To make a console connection, perform this task:

Command Purpose
Step 1 Press Return. Brings up the prompt.
Step 2 Router> enable Initiates enable mode enable.
Step 3 Password: password Completes enable mode enable.
Router#
Step 4 Router# quit Exits the session when finished.

After making a console connection, you see this display:


Press Return for Console prompt

Router> enable
Password:
Router#

Accessing the CLI through Telnet

Note Before you can make a Telnet connection to the switch, you must configure an IP address (see the
Configuring IPv4 Routing and Addresses section on page 30-4).

The switch supports up to eight simultaneous Telnet sessions. Telnet sessions disconnect automatically
after remaining idle for the period specified with the exec-timeout command.
To make a Telnet connection to the switch, perform this task:

Cisco IOS Software Configuration Guide, Release 12.2SX


2-2 OL-13013-06
Chapter 2 Command-Line Interfaces
Performing Command Line Processing

Command Purpose
Step 1 telnet {hostname | ip_addr} Makes a Telnet connection from the remote host to the
switch you want to access.
Step 2 Password: password Initiates authentication.
Router# Note If no password has been configured, press Return.
Step 3 Router> enable Initiates enable mode enable.
Step 4 Password: password Completes enable mode enable.
Router#
Step 5 Router# quit Exits the session when finished.

This example shows how to open a Telnet session to the switch:


unix_host% telnet Router_1
Trying 172.20.52.40...
Connected to 172.20.52.40.
Escape character is '^]'.

User Access Verification

Password:
Router_1> enable
Password:
Router_1#

Performing Command Line Processing


Commands are not case sensitive. You can abbreviate commands and parameters if the abbreviations
contain enough letters to be different from any other currently available commands or parameters. You
can scroll through the last 20 commands stored in the history buffer, and enter or edit the command at
the prompt. Table 2-1 lists the keyboard shortcuts for entering and editing commands.

Table 2-1 Keyboard Shortcuts

Keystrokes Purpose
Press Ctrl-B or Moves the cursor back one character.
press the left arrow key1
Press Ctrl-F or Moves the cursor forward one character.
press the right arrow key1
Press Ctrl-A Moves the cursor to the beginning of the command line.
Press Ctrl-E Moves the cursor to the end of the command line.
Press Esc B Moves the cursor back one word.
Press Esc F Moves the cursor forward one word.
1. The arrow keys function only on ANSI-compatible terminals such as VT100s.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 2-3
Chapter 2 Command-Line Interfaces
Performing History Substitution

Performing History Substitution


The history buffer stores the last 20 commands you entered. History substitution allows you to access
these commands without retyping them, by using special abbreviated commands. Table 2-2 lists the
history substitution commands.

Table 2-2 History Substitution Commands

Command Purpose
1
Ctrl-P or the up arrow key. Recalls commands in the history buffer, beginning
with the most recent command. Repeat the key
sequence to recall successively older commands.
Ctrl-N or the down arrow key.1 Returns to more recent commands in the history
buffer after recalling commands with Ctrl-P or the
up arrow key. Repeat the key sequence to recall
successively more recent commands.
Router# show history While in EXEC mode, lists the last several
commands you have just entered.
1. The arrow keys function only on ANSI-compatible terminals such as VT100s.

Cisco IOS Command Modes


Note For complete information about Cisco IOS command modes, see the Cisco IOS Configuration
Fundamentals Configuration Guide at this URL:
http://www.cisco.com/en/US/docs/ios/12_2/configfun/configuration/guide/ffun_c.html

The Cisco IOS user interface is divided into many different modes. The commands available to you
depend on which mode you are currently in. To get a list of the commands in a given mode, type a
question mark (?) at the system prompt. See the Displaying a List of Cisco IOS Commands and Syntax
section on page 2-5.
When you start a session on the switch, you begin in user mode, often called user EXEC mode. Only a
limited subset of the commands are available in EXEC mode. To have access to all commands, you must
enter privileged EXEC mode. Normally, you must type in a password to access privileged EXEC mode.
From privileged EXEC mode, you can type in any EXEC command or access global configuration mode.
The configuration modes allow you to make changes to the running configuration. If you later save the
configuration, these commands are stored across reboots. You must start at global configuration mode.
From global configuration mode, you can enter interface configuration mode, subinterface configuration
mode, and a variety of protocol-specific modes.

Note With Release 12.1(11b)E and later, when you are in configuration mode you can enter EXEC mode-level
commands by entering the do keyword before the EXEC mode-level command.

Cisco IOS Software Configuration Guide, Release 12.2SX


2-4 OL-13013-06
Chapter 2 Command-Line Interfaces
Displaying a List of Cisco IOS Commands and Syntax

ROM-monitor mode is a separate mode used when the switch cannot boot properly. For example, the
switch might enter ROM-monitor mode if it does not find a valid system image when it is booting, or if
its configuration file is corrupted at startup. See the ROM-Monitor Command-Line Interface section
on page 2-7.
Table 2-3 lists and describes frequently used Cisco IOS modes.

Table 2-3 Frequently Used Cisco IOS Command Modes

Mode Description of Use How to Access Prompt


User EXEC Connect to remote devices, change Log in. Router>
terminal settings on a temporary
basis, perform basic tests, and
display system information.
Privileged EXEC (enable) Set operating parameters. The From the user EXEC mode, enter Router#
privileged command set includes the enable command and the
the commands in user EXEC enable password.
mode, as well as the configure
command. Use this command to
access the other command modes.
Global configuration Configure features that affect the From the privileged EXEC mode, Router(config)#
system as a whole. enter the configure terminal
command.
Interface configuration Many features are enabled for a From global configuration mode, Router(config-if)#
particular interface. Interface enter the interface type slot/port
commands enable or modify the command.
operation of an interface.
Console configuration From the directly connected From global configuration mode, Router(config-line)#
console or the virtual terminal enter the line console 0 command.
used with Telnet, use this
configuration mode to configure
the console interface.

The Cisco IOS command interpreter, called the EXEC, interprets and executes the commands you enter.
You can abbreviate commands and keywords by entering just enough characters to make the command
unique from other commands. For example, you can abbreviate the show command to sh and the
configure terminal command to config t.
When you type exit, the switch backs out one level. To exit configuration mode completely and return
to privileged EXEC mode, press Ctrl-Z.

Displaying a List of Cisco IOS Commands and Syntax


In any command mode, you can display a list of available commands by entering a question mark (?).
Router> ?

To display a list of commands that begin with a particular character sequence, type in those characters
followed by the question mark (?). Do not include a space. This form of help is called word help because
it completes a word for you.
Router# co?

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 2-5
Chapter 2 Command-Line Interfaces
Securing the CLI

collect configure connect copy

To display keywords or arguments, enter a question mark in place of a keyword or argument. Include a
space before the question mark. This form of help is called command syntax help because it reminds you
which keywords or arguments are applicable based on the command, keywords, and arguments you have
already entered.
For example:
Router# configure ?
memory Configure from NV memory
network Configure from a TFTP network host
overwrite-network Overwrite NV memory from TFTP network host
terminal Configure from the terminal
<cr>

To redisplay a command you previously entered, press the up arrow key or Ctrl-P. You can continue to
press the up arrow key to see the last 20 commands you entered.

Tip If you are having trouble entering a command, check the system prompt, and enter the question mark (?)
for a list of available commands. You might be in the wrong command mode or using incorrect syntax.

Enter exit to return to the previous mode. Press Ctrl-Z or enter the end command in any mode to
immediately return to privileged EXEC mode.

Securing the CLI


Securing access to the CLI prevents unauthorized users from viewing configuration settings or making
configuration changes that can disrupt the stability of your network or compromise your network
security. You can create a strong and flexible security scheme for your switch by configuring one or more
of these security features:
Protecting access to privileged EXEC commands
At a minimum, you should configure separate passwords for the user EXEC and privileged EXEC
(enable) IOS command modes. You can further increase the level of security by configuring
username and password pairs to limit access to CLI sessions to specific users. For more information,
see Configuring Security with Passwords, Privilege Levels, and Login Usernames for CLI Sessions
on Networking Devices at this URL:
http://www.cisco.com/en/US/docs/ios/security/configuration/guide/sec_cfg_sec_4cli.html
Controlling switch access with RADIUS, TACACS+, or Kerberos
For a centralized and scalable security scheme, you can require users to be authenticated and
authorized by an external security server running either Remote Authentication Dial-In User Service
(RADIUS), Terminal Access Controller Access-Control System Plus (TACACS+), or Kerberos.
For more information about RADIUS, see Configuring RADIUS at this URL:
http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfrad.html
For more information about TACACS+, see Configuring TACACS+ at this URL:
http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scftplus.html
For more information about Kerberos, see Configuring Kerberos at this URL:
http://www.cisco.com/en/US/docs/ios/12_2/security/configuration/guide/scfkerb.html

Cisco IOS Software Configuration Guide, Release 12.2SX


2-6 OL-13013-06
Chapter 2 Command-Line Interfaces
ROM-Monitor Command-Line Interface

Configuring a secure connection with SSH or HTTPS


To prevent eavesdropping of your configuration session, you can use a Secure Shell (SSH) client or
a browser that supports HTTP over Secure Socket Layer (HTTPS) to make an encrypted connection
to the switch.
For more information about SSH, see Configuring Secure Shell at this URL:
http://www.cisco.com/en/US/docs/ios-xml/ios/sec_usr_ssh/configuration/12-2sx/sec-secure-copy.h
tml
For more information about HTTPS, see HTTPS - HTTP Server and Client with SSL 3.0 at this
URL:
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/ftsslsht.html
Copying configuration files securely with SCP
To prevent eavesdropping when copying configuration files or image files to or from the switch, you
can use the Secure Copy Protocol (SCP) to perform an encrypted file transfer. For more information
about SCP, see Secure Copy at this URL:
http://www.cisco.com/en/US/docs/ios-xml/ios/sec_usr_ssh/configuration/12-2sy/sec-usr-ssh-sec-c
opy.html
For additional information about securing the CLI, see Cisco IOS Security Configuration Guide:
Securing User Services, Release 12.2SX at this URL:
http://www.cisco.com/en/US/docs/ios-xml/ios/security/config_library/12-2sx/secuser-12-2sx-library.ht
ml

ROM-Monitor Command-Line Interface


The ROM-monitor is a ROM-based program that executes upon platform power-up, reset, or when a fatal
exception occurs. The switch enters ROM-monitor mode if it does not find a valid software image, if the
NVRAM configuration is corrupted, or if the configuration register is set to enter ROM-monitor mode.
From the ROM-monitor mode, you can load a software image manually from flash memory, from a
network server file, or from bootflash.
You can also enter ROM-monitor mode by restarting and pressing the Break key during the first 60
seconds of startup.

Note The Break key is always enabled for 60 seconds after rebooting, regardless of whether the Break key is
configured to be off by configuration register settings.

To access the ROM-monitor mode through a terminal server, you can escape to the Telnet prompt and
enter the send break command for your terminal emulation program to break into ROM-monitor mode.
Once you are in ROM-monitor mode, the prompt changes to rommon 1>. Enter a question mark (?) to
see the available ROM-monitor commands.
For more information about the ROM-monitor commands, see the Cisco IOS Master Command List,
Release 12.2SX.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 2-7
Chapter 2 Command-Line Interfaces
ROM-Monitor Command-Line Interface

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Cisco IOS Software Configuration Guide, Release 12.2SX


2-8 OL-13013-06
C H A P T E R 3
Configuring Smart Port Macros

This chapter describes how to configure and apply smart port macros. Release 12.2(33)SXH and later
releases support smart port macros.

Note For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS
Master Command List, Release 12.2SX, at this URL:
http://www.cisco.com/en/US/docs/ios/mcl/122sxmcl/12_2sx_mcl_book.html

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

This chapter consists of these sections:


Understanding Smart Port Macros, page 3-1
Configuring Smart Port Macros, page 3-2
Displaying Smart Port Macros, page 3-16

Understanding Smart Port Macros


These sections describe smart port macros:
Understanding Cisco-Provided Smart Port Macros, page 3-1
Understanding User-Created Smart Port Macros, page 3-2

Understanding Cisco-Provided Smart Port Macros


There are Cisco-provided smart port macros embedded in the switch software (see Table 3-1). You can
display these macros and the commands they contain by using the show parser macro user EXEC
command.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 3-1
Chapter 3 Configuring Smart Port Macros
Configuring Smart Port Macros

Table 3-1 Cisco-Provided Smart Port Macros

Macro Name Description


cisco-global Use this global configuration macro to enable load balancing across VLANs, provide
rapid convergence of spanning-tree instances and to enable port error recovery.
cisco-desktop Use this interface configuration macro for increased network security and reliability
when connecting a desktop device, such as a PC, to a switch port.
cisco-phone Use this interface configuration macro when connecting a desktop device such as a
PC with a Cisco IP phone to a switch port. This macro is an extension of the
cisco-desktop macro and provides the same security and resiliency features, but with
the addition of dedicated voice VLANs to ensure proper treatment of delay-sensitive
voice traffic.
cisco-switch Use this interface configuration macro for Layer 2 connections between devices like
switches and routers.
cisco-router Use this interface configuration macro for Layer 3 connections between devices like
switches and routers.

Cisco also provides a collection of pretested, Cisco-recommended baseline configuration templates for
Catalyst switches. The online reference guide templates provide the CLI commands that you can use to
create smart port macros based on the usage of the port. You can use the configuration templates to create
smart port macros to build and deploy Cisco-recommended network designs and configurations.

Understanding User-Created Smart Port Macros


Smart port macros provide a convenient way to save and share common configurations. You can use
smart port macros to enable features and settings based on the location of a switch in the network and
for mass configuration deployments across the network.
Each smart port macro is a user-defined set of Cisco IOS CLI commands. When you apply a smart port
macro on an interface, the CLI commands within the macro are configured on the interface. When the
macro is applied to an interface, the existing interface configurations are not lost. The new commands
are added to the interface and are saved in the running configuration file.

Configuring Smart Port Macros


Smart Port Macro Default Configuration, page 3-2
Smart Port Macro Configuration Guidelines, page 3-3
Applying the Cisco-Provided Smart Port Macros, page 3-4
Configuring User-Created Smart Port Macros, page 3-13

Smart Port Macro Default Configuration


This example shows how to list the Cisco-provided smart port macros:
Router# show parser macro brief | include default
default global : cisco-global

Cisco IOS Software Configuration Guide, Release 12.2SX


3-2 OL-13013-06
Chapter 3 Configuring Smart Port Macros
Configuring Smart Port Macros

default interface: cisco-desktop


default interface: cisco-phone
default interface: cisco-switch
default interface: cisco-router

There are no smart port macros applied to any interfaces.

Smart Port Macro Configuration Guidelines


These section describe the smart port macro configuration guidelines:
You can display all of the macros on the switch by using the show parser macro user EXEC
command. Display the contents of a specific macro by using the show parser macro name
macro-name user EXEC command.
A macro cannot be edited. If the name following the macro name command is an existing macros
name, that macro is replaced by the new macro.
If a description already exists for a macro, the macro description command appends any
description that you enter to the existing description; it does not replace it. The entered descriptions
are separated by the pipe (|) character.
The maximum macro description length is 256 characters. When the description string becomes
longer than 256 characters, the oldest descriptions are deleted to make room for new ones.
User-created recursive macros are not supported. You cannot define a macro that calls another
macro.
Each user-created macro can have up to three keyword-value pairs.
A macro definition can contain up to 3,000 characters. Line endings count as two characters.
When creating a macro, do not use the exit or end commands or change the command mode by using
interface interface-id. This could cause commands that follow exit, end, or interface interface-id
to execute in a different command mode. When creating a macro, all CLI commands should be in
the same configuration mode.
When creating a macro that requires the assignment of unique values, use the parameter value
keywords to designate values specific to the interface. Keyword matching is case sensitive. All
matching occurrences of the keyword are replaced with the corresponding value. Any full match of
a keyword, even if it is part of a larger string, is considered a match and is replaced by the
corresponding value.
Macro names are case sensitive. For example, the commands macro name Sample-Macro and
macro name sample-macro will result in two separate macros.
Some macros might contain keywords that require a parameter value. You can use the macro global
apply macro-name ? global configuration command or the macro apply macro-name ? interface
configuration command to display a list of any required values in the macro. If you apply a macro
without entering the keyword values, the commands are invalid and are not applied.
When a macro is applied globally to a switch or to a switch interface, the existing configuration on
the interface is retained. This is helpful when applying an incremental configuration.
If you modify a macro definition by adding or deleting commands, the changes are not reflected on
the interface where the original macro was applied. You need to reapply the updated macro on the
interface to apply the new or changed commands.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 3-3
Chapter 3 Configuring Smart Port Macros
Configuring Smart Port Macros

You can use the macro global trace macro-name global configuration command or the macro trace
macro-name interface configuration command to apply and debug a macro to find any syntax or
configuration errors. If a command fails because of a syntax error or a configuration error, the macro
continues to apply the remaining commands.
Some CLI commands are specific to certain interface types. If a macro is applied to an interface that
does not accept the configuration, the macro will fail the syntax check or the configuration check,
and the switch will return an error message.
Applying a macro to an interface range is the same as applying a macro to a single interface. When
you use an interface range, the macro is applied sequentially to each interface within the range. If a
macro command fails on one interface, it is still applied to the remaining interfaces.
When you apply a macro to a switch or a switch interface, the macro name is automatically added
to the switch or interface. You can display the applied commands and macro names by using the
show running-config user EXEC command.

Applying the Cisco-Provided Smart Port Macros


These sections describe how to apply the Cisco-provided smart port macros:
Using the cisco-global Smart Port Macro, page 3-4
Using the cisco-desktop Smart Port Macro, page 3-5
Using the cisco-phone Smart Port Macro, page 3-7
Using the cisco-switch Smart Port Macro, page 3-9
Using the cisco-router Smart Port Macro, page 3-11

Using the cisco-global Smart Port Macro


These sections describe how to apply the cisco-global smart port macro:
Displaying the Contents of the cisco-global Smart Port Macro, page 3-4
Applying the cisco-global Smart Port Macro, page 3-5

Displaying the Contents of the cisco-global Smart Port Macro

This example shows how to display the contents of the cisco-global smart port macro:
Router# show parser macro name cisco-global
Macro name : cisco-global
Macro type : default global
# Enable dynamic port error recovery for link state
# failures
errdisable recovery cause link-flap
errdisable recovery interval 60

# VTP requires Transparent mode for future 802.1x Guest VLAN


# and current Best Practice
vtp domain [smartports]
vtp mode transparent

# Config Cos to DSCP mappings


mls qos map cos-dscp 0 8 16 26 32 46 48 56

# Enable aggressive mode UDLD on all fiber uplinks


udld aggressive

Cisco IOS Software Configuration Guide, Release 12.2SX


3-4 OL-13013-06
Chapter 3 Configuring Smart Port Macros
Configuring Smart Port Macros

# Enable Rapid PVST+ and Loopguard


spanning-tree mode rapid-pvst
spanning-tree loopguard default
spanning-tree extend system-id

Applying the cisco-global Smart Port Macro

To apply the cisco-global smart port macro, perform this task:

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
Step 2 Router(config)# macro global apply cisco-global Applies the cisco-global smart port macro.
Step 3 Router(config)# end Returns to privileged EXEC mode.
Step 4 Router# show parser macro description Displays the macros that have been applied.

This example shows how to apply the cisco-global smart port macro and display the name of the applied
macro:
Router# configure terminal
Router(config)# macro global apply cisco-global
Changing VTP domain name from previous_domain_name to [smartports]
Setting device to VTP TRANSPARENT mode.
Router(config)# end
Router# show parser macro description
Global Macro(s): cisco-global

Interface Macro Description(s)


--------------------------------------------------------------
--------------------------------------------------------------
Router#

Using the cisco-desktop Smart Port Macro


These sections describe how to apply the cisco-desktop smart port macro:
Displaying the Contents of the cisco-desktop Smart Port Macro, page 3-5
Applying the cisco-desktop Smart Port Macro, page 3-6

Displaying the Contents of the cisco-desktop Smart Port Macro

This example shows how to display the contents of the cisco-desktop smart port macro:
Router# show parser macro name cisco-desktop
Macro name : cisco-desktop
Macro type : default interface
# macro keywords $AVID
# Basic interface - Enable data VLAN only
# Recommended value for access vlan (AVID) should not be 1
switchport
switchport access vlan $AVID
switchport mode access

# Enable port security limiting port to a single


# MAC address -- that of desktop
switchport port-security

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 3-5
Chapter 3 Configuring Smart Port Macros
Configuring Smart Port Macros

switchport port-security maximum 1

# Ensure port-security age is greater than one minute


# and use inactivity timer
switchport port-security violation restrict
switchport port-security aging time 2
# Configure port as an edge network port
spanning-tree portfast
spanning-tree portfast edge bpduguard default

Applying the cisco-desktop Smart Port Macro

To apply the cisco-desktop smart port macro, perform this task:

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
1
Step 2 Router(config)# interface type slot/port Selects the interface to configure.
Step 3 Router(config-if)# macro apply cisco-desktop Applies the cisco-desktop smart port macro. The
$AVID access_vlan_ID recommended range for access_vlan_ID is 24094.
Step 4 Router(config-if)# end Returns to privileged EXEC mode.
Step 5 Router# show parser macro description interface Displays the macros that have been applied.
type1 slot/port
Step 6 Router# show running-config interface Displays all of the commands configured on the
type1 slot/port interface.
1. type = fastethernet, gigabitethernet, or tengigabitethernet

This example shows how to apply the cisco-desktop smart port macro to Gigabit Ethernet port 1/1 with
VLAN 2 specified as the access VLAN and how to verify the result:
Router# configure terminal
Router(config)# interface gigabitethernet 1/1
Router(config-if)# macro apply cisco-desktop $AVID 2
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc... to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION

%Portfast has been configured on GigabitEthernet1/1 but will only


have effect when the interface is in a non-trunking mode.
Router(config)# end
Router# show parser macro description interface gigabitethernet 1/1
Global Macro(s): cisco-global

Interface Macro Description(s)


--------------------------------------------------------------
Gi1/1 cisco-desktop
--------------------------------------------------------------
Router# show running-config interface gigabitethernet 1/1
Building configuration...

Current configuration : 307 bytes


!
interface GigabitEthernet1/1
switchport
switchport access vlan 2
switchport mode access

Cisco IOS Software Configuration Guide, Release 12.2SX


3-6 OL-13013-06
Chapter 3 Configuring Smart Port Macros
Configuring Smart Port Macros

switchport port-security
switchport port-security aging time 2
switchport port-security violation restrict
shutdown
macro description cisco-desktop
spanning-tree portfast
spanning-tree bpduguard enable
end

Router#

Using the cisco-phone Smart Port Macro


These sections describe how to apply the cisco-phone smart port macro:
Displaying the Contents of the cisco-phone Smart Port Macro, page 3-7
Applying the cisco-phone Smart Port Macro, page 3-8

Displaying the Contents of the cisco-phone Smart Port Macro

This example shows how to display the contents of the cisco-phone smart port macro:
Router# show parser macro name cisco-phone
Macro name : cisco-phone
Macro type : default interface
# macro keywords $AVID $VVID
# VoIP enabled interface - Enable data VLAN
# and voice VLAN (VVID)
# Recommended value for access vlan (AVID) should not be 1
switchport
switchport access vlan $AVID
switchport mode access

# Update the Voice VLAN (VVID) value which should be


# different from data VLAN
# Recommended value for voice vlan (VVID) should not be 1
switchport voice vlan $VVID

# Enable port security limiting port to a 3 MAC


# addressess -- One for desktop and two for phone
switchport port-security
switchport port-security maximum 3

# Ensure port-security age is greater than one minute


# and use inactivity timer
switchport port-security violation restrict
switchport port-security aging time 2
# Enable auto-qos to extend trust to attached Cisco phone
auto qos voip cisco-phone

# Configure port as an edge network port


spanning-tree portfast
spanning-tree portfast edge bpduguard default

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 3-7
Chapter 3 Configuring Smart Port Macros
Configuring Smart Port Macros

Applying the cisco-phone Smart Port Macro

To apply the cisco-phone smart port macro, perform this task:

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
1
Step 2 Router(config)# interface type slot/port Selects the interface to configure.
Step 3 Router(config-if)# macro apply cisco-phone $AVID Applies the cisco-phone smart port macro. The
access_vlan_ID $VVID voice_vlan_ID recommended range for access_vlan_ID is 24094. The
recommended range for voice_vlan_ID is 24094.
Step 4 Router(config-if)# end Returns to privileged EXEC mode.
Step 5 Router# show parser macro description interface Displays the macros that have been applied.
type1 slot/port
Step 6 Router# show running-config interface Displays all of the commands configured on the
type1 slot/port interface.
1. type = fastethernet, gigabitethernet, or tengigabitethernet

When applying the cisco-phone smart port macro, note the following information:
Some of the generated commands are in the category of PFC QoS commands that are applied to all
ports controlled by a port ASIC. When one of these generated commands is applied, PFC QoS
displays the messages caused by application of the command to all the ports controlled by the
port ASIC. Depending on the module, these commands are applied to as many as 48 ports. See the
Number of port groups and Port ranges per port group listed for each module in the Release
Notes for Cisco IOS Release 12.2SX.
You might see messages that instruct you to configure other ports to trust CoS. You must do so to
enable the generated QoS commands.
You might not be able to apply the cisco-phone smart port macro and other macros on ports that are
controlled by the same port ASIC because of conflicting port trust state requirements.
This example shows how to apply the cisco-phone smart port macro to Gigabit Ethernet port 2/2 with
VLAN 2 specified as the access VLAN and how to verify the result:
Router# configure terminal
Router(config)# interface gigabitethernet 2/2
Router(config-if)# macro apply cisco-phone $AVID 2 $VVID 3
Hardware QoS is enabled
Propagating cos-map to inband port
Propagating cos-map configuration to: [port list not shown]

[Output for other ports controlled by the same port ASIC omitted]
Warning: rcv cosmap will not be applied in hardware.
To modify rcv cosmap in hardware, all of the interfaces below
must be put into 'trust cos' state:
[port list not shown]
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc... to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION

%Portfast has been configured on GigabitEthernet1/2 but will only


have effect when the interface is in a non-trunking mode.
Router(config)# end

Cisco IOS Software Configuration Guide, Release 12.2SX


3-8 OL-13013-06
Chapter 3 Configuring Smart Port Macros
Configuring Smart Port Macros

Router# show parser macro description interface gigabitethernet 2/2


Global Macro(s): cisco-global

Interface Macro Description(s)


--------------------------------------------------------------
Gi2/2 cisco-phone
--------------------------------------------------------------

Router# show running-config interface gigabitethernet 2/2


Building configuration...

Building configuration...

Current configuration : 307 bytes


!
interface GigabitEthernet1/2
Building configuration...

Current configuration : 1336 bytes


!
interface GigabitEthernet2/2
switchport
switchport access vlan 2
switchport mode access
switchport voice vlan 3
switchport port-security
switchport port-security maximum 3
switchport port-security aging time 2
switchport port-security violation restrict
shutdown

[QoS queuing commands omitted: these vary according to port type]


mls qos trust cos
auto qos voip cisco-phone
macro description cisco-phone
spanning-tree portfast
spanning-tree bpduguard enable
end

Router#

Using the cisco-switch Smart Port Macro


These sections describe how to apply the cisco-switch smart port macro:
Displaying the Contents of the cisco-switch Smart Port Macro, page 3-9
Applying the cisco-switch Smart Port Macro, page 3-10

Displaying the Contents of the cisco-switch Smart Port Macro

This example shows how to display the contents of the cisco-switch smart port macro:
Router# show parser macro name cisco-switch
Macro name : cisco-switch
Macro type : default interface
# macro keywords $NVID
# Do not apply to EtherChannel/Port Group
# Access Uplink to Distribution

# Define unique Native VLAN on trunk ports


# Recommended value for native vlan (NVID) should not be 1

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 3-9
Chapter 3 Configuring Smart Port Macros
Configuring Smart Port Macros

switchport
switchport trunk native vlan $NVID

# Update the allowed VLAN range (VRANGE) such that it


# includes data, voice and native VLANs
# switchport trunk allowed vlan VRANGE

# Hardcode trunk and disable negotiation to


# speed up convergence
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate

# 802.1w defines the link as pt-pt for rapid convergence


spanning-tree link-type point-to-point

Router#

Applying the cisco-switch Smart Port Macro

To apply the cisco-switch smart port macro, perform this task:

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
1
Step 2 Router(config)# interface type slot/port Selects the interface to configure.
Step 3 Router(config-if)# macro apply cisco-switch Applies the cisco-switch smart port macro. The
$NVID native_vlan_ID recommended range for native_vlan_ID is 24094.
Step 4 Router(config-if)# end Returns to privileged EXEC mode.
Step 5 Router# show parser macro description interface Displays the macros that have been applied.
type1 slot/port
Step 6 Router# show running-config interface Displays all of the commands configured on the
type1 slot/port interface.
1. type = fastethernet, gigabitethernet, or tengigabitethernet

This example shows how to apply the cisco-switch smart port macro to Gigabit Ethernet port 1/4 with
VLAN 4 specified as the native VLAN and how to verify the result:
Router# configure terminal
Router(config)# interface gigabitethernet 1/4
Router(config-if)# macro apply cisco-switch $NVID 4
Router(config-if)# end
Router# show parser macro description interface gigabitethernet 1/4
Interface Macro Description(s)
--------------------------------------------------------------
Gi1/4 cisco-switch
--------------------------------------------------------------
Router# show running-config interface gigabitethernet 1/4
Building configuration...

Current configuration : 247 bytes


!
interface GigabitEthernet1/4
switchport
switchport trunk encapsulation dot1q
switchport trunk native vlan 4
switchport mode trunk

Cisco IOS Software Configuration Guide, Release 12.2SX


3-10 OL-13013-06
Chapter 3 Configuring Smart Port Macros
Configuring Smart Port Macros

switchport nonegotiate
shutdown
macro description cisco-switch
spanning-tree link-type point-to-point
end

Router#

Using the cisco-router Smart Port Macro


These sections describe how to apply the cisco-router smart port macro:
Displaying the Contents of the cisco-router Smart Port Macro, page 3-11
Applying the cisco-router Smart Port Macro, page 3-12

Displaying the Contents of the cisco-router Smart Port Macro

This example shows how to display the contents of the cisco-router smart port macro:
Router# show parser macro name cisco-router
Macro name : cisco-router
Macro type : default interface
# macro keywords $NVID
# Do not apply to EtherChannel/Port Group
# Access Uplink to Distribution
switchport

# Define unique Native VLAN on trunk ports


# Recommended value for native vlan (NVID) should not be 1
switchport trunk native vlan $NVID

# Update the allowed VLAN range (VRANGE) such that it


# includes data, voice and native VLANs
# switchport trunk allowed vlan VRANGE

# Hardcode trunk and disable negotiation to


# speed up convergence
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate

# Configure qos to trust this interface


auto qos voip trust
mls qos trust dscp

# Ensure fast access to the network when enabling the interface.


# Ensure that switch devices cannot become active on the interface.
spanning-tree portfast
spanning-tree portfast edge bpduguard default

Router#

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 3-11
Chapter 3 Configuring Smart Port Macros
Configuring Smart Port Macros

Applying the cisco-router Smart Port Macro

To apply the cisco-router smart port macro, perform this task:

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
1
Step 2 Router(config)# interface type slot/port Selects the interface to configure.
Step 3 Router(config-if)# macro apply cisco-router Applies the cisco-router smart port macro. The
$NVID native_vlan_ID recommended range for native_vlan_ID is 24094.
Step 4 Router(config-if)# end Returns to privileged EXEC mode.
Step 5 Router# show parser macro description interface Displays the macros that have been applied.
type1 slot/port
Step 6 Router# show running-config interface Displays all of the commands configured on the
type1 slot/port interface.
1. type = fastethernet, gigabitethernet, or tengigabitethernet

Note The cisco-router smart port macro includes the auto qos voip trust command. When entered on a port
configured with the switchport command, the auto qos voip trust command generates and applies the
mls qos trust cos command to the port, but the cisco-router smart port macro changes the port trust state
to trust DSCP with the mls qos trust dscp command. When you apply the cisco-router smart port macro,
ignore messages that instruct you to enter the mls qos trust cos command on other ports controlled by
the port ASIC.

This example shows how to apply the cisco-router smart port macro to Gigabit Ethernet port 1/5 and how
to verify the result:
Router# configure terminal
Router(config)# interface gigabitethernet 1/5
Router(config-if)# macro apply cisco-router $NVID 5
Hardware QoS is enabled
Propagating cos-map to inband port
Propagating cos-map configuration to: [port list not shown]

[Output for other ports controlled by the same port ASIC omitted]
[Output from temporarily applied trust CoS command omitted]
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc... to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION

%Portfast has been configured on GigabitEthernet1/5 but will only


have effect when the interface is in a non-trunking mode.
Router(config-if)# end
Router# show parser macro description interface gigabitethernet 1/5
Interface Macro Description(s)
--------------------------------------------------------------
Gi1/5 cisco-router
--------------------------------------------------------------
Router# show running-config interface gigabitethernet 1/5
Building configuration...

Current configuration : 1228 bytes

Cisco IOS Software Configuration Guide, Release 12.2SX


3-12 OL-13013-06
Chapter 3 Configuring Smart Port Macros
Configuring Smart Port Macros

!
interface GigabitEthernet1/5
switchport
switchport trunk encapsulation dot1q
switchport trunk native vlan 5
switchport mode trunk
switchport nonegotiate
shutdown
wrr-queue bandwidth 20 100 200

[QoS queuing commands omitted: these vary according to port type]


mls qos trust dscp
auto qos voip trust
macro description cisco-router
spanning-tree portfast
spanning-tree bpduguard enable
end

Router#

Configuring User-Created Smart Port Macros


These sections describe how to configure user-created smart port macros:
Creating Smart Port Macros, page 3-13
Applying Smart Port Macros, page 3-14

Creating Smart Port Macros


To create a smart port macro, perform this task:

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 3-13
Chapter 3 Configuring Smart Port Macros
Configuring Smart Port Macros

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
Step 2 Router(config)# macro name macro-name Creates a macro.
Macro names are case sensitive. For example, the
commands macro name Sample-Macro and macro
name sample-macro will result in two separate macros.
A macro definition can contain up to 3,000 characters.
Line endings count as two characters.
There is no prompt displayed in macro creation mode.
Enter the macro commands on separate lines.
Use the # character at the beginning of a line to enter a
comment within the macro.
Use the @ character to end the macro.
Do not use the exit or end commands or change the
command mode with the interface interface-id in a
macro. This could cause any commands following exit,
end, or interface interface-id to execute in a different
command mode. For best results, all commands in a
macro should be in the same configuration mode.
Each user-created macro can have up to three
keyword-value pairs.
Step 3 # macro keywords keyword1 keyword2 keyword3 (Optional) You can create a help string to describe the
keywords that you define in the macro. You can enter up
to three help string comments in a macro.
Step 4 end Returns to privileged EXEC mode.
Step 5 show parser macro name macro-name Verifies that the macro was created.

Note The no form of the macro name global configuration command only deletes the macro definition. It
does not affect the configuration of those interfaces on which the macro is already applied.

This example shows how to create a macro that defines the Layer 2 access VLAN and the number of
secure MAC addresses and also includes two help string keywords by using # macro keywords:
Router(config)# macro name test
#macro keywords $VLANID $MAX
switchport access vlan $VLANID
switchport port-security maximum $MAX
@

Applying Smart Port Macros


To apply a smart port macro, perform this task:

Cisco IOS Software Configuration Guide, Release 12.2SX


3-14 OL-13013-06
Chapter 3 Configuring Smart Port Macros
Configuring Smart Port Macros

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
Step 2 Router(config)# default interface interface-id (Optional) Clears all configuration from the specified
interface.
Step 3 Router(config)# interface interface_id (Required for interface macros.) Specifies the interface
on which to apply the macro and enters interface
configuration mode.
Step 4 Router(config)# macro global {apply | trace} Applies or traces and applies each individual command
macro-name [keyword value] [keyword value] defined in the macro.
[keyword value]
For global macros:
Or
To find any syntax or configuration errors, enter the
Router(config-if)# macro {apply | trace} macro global trace macro-name command to apply
macro-name [keyword value] [keyword value]
and debug the macro.
[keyword value]
To display a list of any keyword-value pairs defined
in the macro, enter the macro global apply
macro-name ? command.
For interface macros:
To find any syntax or configuration errors, enter the
macro trace macro-name command to apply and
debug the macro.
To display a list of any keyword-value pairs defined
in the macro, enter the macro apply macro-name ?
command.
To successfully apply the macro, you must enter any
required keyword-value pairs.
Keyword matching is case sensitive.
In the commands that the macro applies, all matching
occurrences of keywords are replaced with the
corresponding values.
Step 5 Router(config)# end Returns to privileged EXEC mode.
Step 6 Router# show parser macro description Verifies that the macro is applied to the interface.
[interface interface_id]

You can delete a global macro-applied configuration on a switch only by entering the no version of each
command that is in the macro. You can delete all configurations on an interface by entering the default
interface interface_id interface configuration command.
This example shows how to apply the user-created macro called snmp, to set the host name address to
test-server and to set the IP precedence value to 7:
Router(config)# macro global apply snmp ADDRESS test-server VALUE 7

This example shows how to debug the user-created macro called snmp by using the macro global trace
global configuration command to find any syntax or configuration errors in the macro when it is applied
to the switch:
Router(config)# macro global trace snmp VALUE 7
Applying command...snmp-server enable traps port-security

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 3-15
Chapter 3 Configuring Smart Port Macros
Displaying Smart Port Macros

Applying command...snmp-server enable traps linkup


Applying command...snmp-server enable traps linkdown
Applying command...snmp-server host
%Error Unknown error.
Applying command...snmp-server ip precedence 7

This example shows how to apply the user-created macro called desktop-config and to verify the
configuration:
Router(config)# interface fastethernet1/2
Router(config-if)# macro apply desktop-config
Router(config-if)# end
Router# show parser macro description
Interface Macro Description
--------------------------------------------------------------
Fa1/2 desktop-config
--------------------------------------------------------------

This example shows how to apply the user-created macro called desktop-config and to replace all
occurrences of vlan with VLAN ID 25:
Router(config-if)# macro apply desktop-config vlan 25

Displaying Smart Port Macros


To display the smart port macros, use one or more of the privileged EXEC commands in Table 3-2.

Table 3-2 Commands for Displaying Smartports Macros

Command Purpose
show parser macro Displays all configured macros.
show parser macro name macro-name Displays a specific macro.
show parser macro brief Displays the configured macro names.
show parser macro description [interface interface-id] Displays the macro description for all interfaces or for a
specified interface.

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Cisco IOS Software Configuration Guide, Release 12.2SX


3-16 OL-13013-06
C H A P T E R 4
Configuring Virtual Switching Systems

This chapter describes how to configure a virtual switching system (VSS) for the Catalyst 6500 series
switch. Cisco IOS Release 12.2(33)SXH1 and later releases support VSS.

Note For complete syntax and usage information for the commands used in this chapter, see these
publications:
The Cisco IOS Virtual Switch Command Reference at this URL:
http://www.cisco.com/en/US/docs/ios/vswitch/command/reference/vs_book.html
The Cisco IOS Release 12.2 publications at this URL:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_installation_and_configuratio
n_guides_list.html

Tip For additional information about Cisco Catalyst 6500 series switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

This chapter consists of these sections:


Understanding Virtual Switching Systems, page 4-1
VSS Configuration Guidelines and Restrictions, page 4-29
Configuring a VSS, page 4-30
Upgrading a VSS, page 4-55

Understanding Virtual Switching Systems


These sections describe a VSS:
VSS Overview, page 4-2
VSS Redundancy, page 4-11
Multichassis EtherChannels, page 4-14

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-1
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

Packet Handling, page 4-16


System Monitoring, page 4-20
Dual-Active Detection, page 4-22
VSS Initialization, page 4-25
VSS Configuration Guidelines and Restrictions, page 4-29

VSS Overview
Network operators increase network reliability by configuring switches or SIP-400 CWAN line cards in
redundant pairs and by provisioning links to the redundant pairs. Figure 4-1 shows a typical switch
network configuration. Redundant network elements and redundant links can add complexity to network
design and operation. Virtual switching simplifies the network by reducing the number of network
elements and hiding the complexity of managing redundant switches and links.
A VSS combines a pair of Catalyst 6500 series switches or SIP-400 CWAN line cards into a single
network element. The VSS manages the redundant links, which externally act as a single port channel.
The VSS simplifies network configuration and operation by reducing the number of Layer 3 routing
neighbors and by providing a loop-free Layer 2 topology.

Figure 4-1 Typical Switch Network Design

Access

Distribution

Core
181320

The following sections present an overview of the VSS. These topics are covered in detail in subsequent
chapters:
Key Concepts, page 4-3
VSS Functionality, page 4-5
Hardware Requirements, page 4-8
Understanding VSL Topology, page 4-10

Cisco IOS Software Configuration Guide, Release 12.2SX


4-2 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

Key Concepts
The VSS incorporates the following key concepts:
Virtual Switching System, page 4-3
VSS Active and VSS Standby Chassis, page 4-3
Virtual Switch Link, page 4-3
Multichassis EtherChannel, page 4-5

Virtual Switching System

A VSS combines a pair of switches into a single network element. For example, a VSS in the distribution
layer of the network interacts with the access and core networks as if it were a single switch. See
Figure 4-2.
An access switch connects to both chassis of the VSS using one logical port channel. The VSS manages
redundancy and load balancing on the port channel. This capability enables a loop-free Layer 2 network
topology. The VSS also simplifies the Layer 3 network topology because the VSS reduces the number
of routing peers in the network.

Figure 4-2 VSS in the Distribution Network

Physical view Logical view

Virtual Distribution Switch Virtual Distribution Switch

181321
Access Access

VSS Active and VSS Standby Chassis

When you create or restart a VSS, the peer chassis negotiate their roles. One chassis becomes the VSS
active chassis, and the other chassis becomes the VSS standby.
The VSS active chassis controls the VSS. It runs the Layer 2 and Layer 3 control protocols for the
switching modules on both chassis. The VSS active chassis also provides management functions for the
VSS, such as module online insertion and removal (OIR) and the console interface.
The VSS active and VSS standby chassis perform packet forwarding for ingress data traffic on their
locally hosted interfaces. However, the VSS standby chassis sends all control traffic to the VSS active
chassis for processing.

Virtual Switch Link

For the two chassis of the VSS to act as one network element, they need to share control information and
data traffic.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-3
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

The virtual switch link (VSL) is a special link that carries control and data traffic between the two chassis
of a VSS, as shown in Figure 4-3. The VSL is implemented as an EtherChannel with up to eight links.
The VSL gives control traffic higher priority than data traffic so that control messages are never
discarded. Data traffic is load balanced among the VSL links by the EtherChannel load-balancing
algorithm.

Figure 4-3 Virtual Switch Link

Virtual switch

Chassis 1 Chassis 2

181322
Virtual switch link
(VSL)

When you configure VSL all existing configurations are removed from the interface except for specific
allowed commands. When you configure VSL, the system puts the interface into a restricted mode.
When an interface is in restricted mode, only specific configuration commands can be configured on the
interface.
The following VSL configuration commands are not removed from the interface when it becomes
restricted:
mls qos trust cos
mls qos channel-consistency
description
logging event
load-interval
vslp
port-channel port
When in VSL restricted mode, only these configuration commands are available:
channel-group
default
description
exit
load-interval
logging
mls
mls ip
mls ipx
mls netflow
mls rp

Cisco IOS Software Configuration Guide, Release 12.2SX


4-4 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

mls switching
no
shutdown

Note The mls qos command is not available when a port is in VSL restricted mode.

Multichassis EtherChannel

An EtherChannel (also known as a port channel) is a collection of two or more physical links that
combine to form one logical link. Layer 2 protocols operate on the EtherChannel as a single logical
entity.
A multichassis EtherChannel (MEC) is a port channel that spans the two chassis of a VSS. The access
switch views the MEC as a standard port channel. See Figure 4-4.
The VSS supports a maximum of 512 EtherChannels. This limit applies to the combined total of regular
EtherChannels and MECs. Because VSL requires two EtherChannel numbers (one for each chassis),
there are 510 user-configurable EtherChannels. If an installed service module uses an internal
EtherChannel, that EtherChannel will be included in the total.

Note For releases earlier than Cisco IOS Release 12.2(33)SXI, the maximum number of EtherChannels is 128,
allowing 126 user-configurable EtherChannels.

Figure 4-4 VSS with MEC

VSL
Chassis 1 Chassis 2

MEC
181323

VSS Functionality
The following sections describe the main functionality of a VSS:
Redundancy and High Availability, page 4-6
Packet Handling, page 4-6
System Management, page 4-6
Quad-Supervisor Uplink Forwarding on In-chassis Standby Supervisor Engines, page 4-6
Interface Naming Convention, page 4-8
Software Features, page 4-8

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-5
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

Redundancy and High Availability

In a VSS, supervisor engine redundancy operates between the VSS active and VSS standby chassis,
using stateful switchover (SSO) and nonstop forwarding (NSF). The peer chassis exchange configuration
and state information across the VSL and the VSS standby supervisor engine runs in hot VSS standby
mode.
The VSS standby chassis monitors the VSS active chassis using the VSL. If it detects failure, the VSS
standby chassis initiates a switchover and takes on the VSS active role. When the failed chassis recovers,
it takes on the VSS standby role.
If the VSL fails completely, the VSS standby chassis assumes that the VSS active chassis has failed, and
initiates a switchover. After the switchover, if both chassis are VSS active, the dual-active detection
feature detects this condition and initiates recovery action. For additional information about dual-active
detection, see the Dual-Active Detection section on page 4-22.

Packet Handling

The VSS active supervisor engine runs the Layer 2 and Layer 3 protocols and features for the VSS and
manages the DFC modules for both chassis.
The VSS uses VSL to communicate protocol and system information between the peer chassis and to
carry data traffic between the chassis when required.
Both chassis perform packet forwarding for ingress traffic on their interfaces. If possible, ingress traffic
is forwarded to an outgoing interface on the same chassis to minimize data traffic that must traverse the
VSL.
Because the VSS standby chassis is actively forwarding traffic, the VSS active supervisor engine
distributes updates to the VSS standby supervisor engine PFC and all VSS standby chassis DFCs.

System Management

The VSS active supervisor engine acts as a single point of control for the VSS. For example, the VSS
active supervisor engine handles OIR of switching modules on both chassis. The VSS active supervisor
engine uses VSL to send messages to and from local ports on the VSS standby chassis.
The command console on the VSS active supervisor engine is used to control both chassis. In virtual
switch mode, the command console on the VSS standby supervisor engine blocks attempts to enter
configuration mode.
The VSS standby chassis runs a subset of system management tasks. For example, the VSS standby
chassis handles its own power management.

Quad-Supervisor Uplink Forwarding on In-chassis Standby Supervisor Engines

When you use VSS quad-supervisor uplink forwarding, the in-chassis standby (ICS) supervisor engine
acts as a DFC line card. Only one processor, the SP processor, acts as the DFC line card; the RP processor
is reset to ROMMON. During the bootup, once the chassis level role is resolved, the ICS downloads the
image from the in-chassis active (ICA) supervisor engine. Once the supervisor engine is booted with the
image, it will function in the same way as a DFC line card. All applications running in virtual switch
(VS) view the in-chassis standby as a DFC line card.
See Figure 4-6 for the various roles that supervisor engines can assume within a quad-supervisor VSS
system.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-6 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

Figure 4-5 Typical VSS Quad-Supervisor Configuration

VSL
Active Standby
Supervisor Supervisor
Supervisor 1: Supervisor 2:
active, ICA standby, ICA
Supervisor 3 ICS Supervisor 4 ICS
Linecard 1 Linecard 1
Linecard 2 Linecard 2

197277
Linecard N Linecard N
Active chassis Standby chassis

If your supervisor engine is:


in-chassis active, it can be VSS active or VSS standby.
in-chassis standby, it can only be an ICS.
VSS active, it can only be ICA.
VSS standby, it can only be ICA.
Quad-supervisor uplink forwarding provides these key features:
eFSU upgrades You can upgrade or downgrade your VSS system using ISSU. See Upgrading a
VSS section on page 4-55 for more information about eFSU upgrades.
Image version mismatchBefore the bootup, the ICS completes a version check. If there is a
version mismatch, the ICS is set to ROMMON. If you want to boot different images on the ICS and
ICA. You need to configure the no switch virtual in-chassis standby bootup version
mismatch-check command. This command is only valid once all four supervisors are running
software that supports Quad-supervisor uplink forwarding. If one supervisor is running software that
does not support Quad-supervisor uplink forwarding the command will have no effect.
EARL mode mismatchIf the supervisor engine EARL modes do not match then the supervisor
engine is reset to ROMMON. It is recommended that all four supervisor engines run the same EARL
Lite or EARL Heavy version.
VSS RPR switchoverOn RPR switchover the ICS will be reset. For more information regarding
RPR see RPR and SSO Redundancy section on page 4-12.
In-chassis RPR switchoverICS supervisor engines in the supervisor engine 1 and supervisor
engine 2 positions boot up as RPR-Warm. RPR-Warm is when a supervisor engine acts as a DFC.
When a VSS stateful switchover occurs, the supervisor engine is reset to ROMMON and boot ups
with the supervisor engine image. You can verify the switchover mode of the supervisor engines by
entering the show module command.
VSS stateful switchoverWhen the in-chassis active supervisor engine crashes, a switchover occurs
and the whole chassis reloads (including the ICS) during which the standby supervisor engine takes
over as the in-chassis active supervisor engine. A z-switchover operates exactly like a switchover
except that the ICS supervisor engine takes priority and is assigned the in-chassis standby supervisor
engine. You can initiate a z-switchover by entering the redundancy force switchover command on
the in-chassis active supervisor engine. You can verify the switchover mode of the supervisor
engines by entering the show module command.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-7
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

If you insert a supervisor engine from another system (VS or standalone) in the supervisor engine 1 or
supervisor engine 2 position of your existing two supervisor engine VSS system, the supervisor engine
does a reset to update the supervisor engine number, and then reboots before going online as a DFC.

Interface Naming Convention

In VSS mode, interfaces are specified using the switch number (in addition to slot and port), because the
same slot numbers are used on both chassis. For example, the interface 1/5/4 command specifies port 4
of the switching module in slot 5 of switch 1. The interface 2/5/4 command specifies port 4 on the
switching module in slot 5 of switch 2.

Software Features

With some exceptions, the VSS has feature parity with the standalone Catalyst 6500 series switch. Major
exceptions include:
In software releases earlier than Cisco IOS Release 12.2(33)SXI2, the VSS does not support IPv6
unicast or MPLS.
In software releases earlier than Cisco IOS Release 12.2(33)SXI, port-based QoS and port ACLs
(PACLs) are supported only on Layer 2 single-chassis or multichassis EtherChannel (MEC) links.
Beginning with Cisco IOS Release 12.2(33)SXI, port-based QoS and PACLs can be applied to any
physical port in the VSS, excluding ports in the VSL. PACLs can be applied to no more than 2046
ports in the VSS.
In software releases earlier than Cisco IOS Release 12.2(33)SXI4, the VSS does not support
supervisor engine redundancy within a chassis.
Starting in Cisco IOS Release 12.2(33)SXI4, the VSS does support supervisor engine redundancy
within a chassis.
The VSS does not support Lawful Intercept.

Hardware Requirements
The following sections describe the hardware requirements of a VSS:
Chassis and Modules, page 4-8
VSL Hardware Requirements, page 4-9
PFC, DFC, and CFC Requirements, page 4-10
Multichassis EtherChannel Requirements, page 4-10
Service Module Support, page 4-10
WAN Module Support, page 4-10

Chassis and Modules

Table 4-1 describes the hardware requirements for the VSS chassis and modules.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-8 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

Table 4-1 VSS Hardware Requirements

Hardware Count Requirements


Chassis 2 The VSS is available on chassis that support VS-S720-10G supervisor
engines and WS-X6708-10GE switching modules.
Note The two chassis need not be identical.
Supervisor Engines 2 The VSS requires Supervisor Engine 720 with 10-Gigabit Ethernet ports.
You must use either two VS-S720-10G-3C or two VS-S720-10G-3CXL
supervisor engine modules.
The two supervisor engines must match exactly.
Switching Modules 2+ The VSS requires 67xx series switching modules.
The VSS does not support classic, CEF256, or dCEF256 switching
modules. In virtual switch mode, unsupported switching modules remain
powered off.

VSL Hardware Requirements

The VSL EtherChannel supports only 10-Gigabit Ethernet ports. The 10-Gigabit Ethernet port can be
located on the supervisor engine module or on one of the following switching modules:
WS-X6708-10GE-3C or WS-X6708-10GE-3CXL
WS-X6716-10GE-3C or WS-X6716-10GE-3CXL
WS-X6716-10T-3C or WS-X6716-10T-3CXL

Note Using the 10-Gigabit Ethernet ports on a WS-X6716-10GE switching module in the VSL
EtherChannel requires Cisco IOS Release 12.2(33)SXI or a later release.
Using the 10-Gigabit Ethernet ports on a WS-X6716-10T switching module in the VSL
EtherChannel requires Cisco IOS Release 12.2(33)SXI4 or a later release.

We recommend that you use both of the 10-Gigabit Ethernet ports on the supervisor engines to create
the VSL between the two chassis.
You can add additional physical links to the VSL EtherChannel by using the 10-Gigabit Ethernet ports
on WS-X6708-10GE, WS-X6716-10GE, or WS-X6716-10T switching modules.

Note When using the 10-Gigabit Ethernet ports on the WS-X6716-10GE or WS-X6716-10T switching
module as VSL links, you must operate the ports in performance, not oversubscription, mode. If you
enter the no hw-module switch x slot y oversubscription command to configure
non-oversubscription mode (performance mode), then only ports 1, 5, 9, and 13 are configurable;
the other ports on the module are disabled.
Port-groups are independent of each other and one, or more, port-groups can operate in
non-oversubscribed (1:1) mode (e.g. for VSL) with the 3 unused ports administratively shutdown,
while the others can still operate in oversubscribed (4:1) mode.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-9
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

PFC, DFC, and CFC Requirements

The VSS supports any 67xx series switching module with CFC hardware.
The VSS supports DFC3C or DFC3CXL hardware and does not support DFC3A/3B/3BXL hardware.
If any switching module in the VSS is provisioned with DFC3C, the whole VSS must operate in PFC3C
mode. If a 67xx series switching module with a DFC3A/3B/3BXL is inserted in the chassis of a VSS,
the module will remain unpowered, because VSS supports only DFC3C and DFC3CXL.
If the supervisor engines are provisioned with PFC3C, the VSS will automatically operate in 3C mode,
even if some of the modules are 3CXL. However, if the supervisor engines are provisioned with
PFC3CXL, but some of the modules are 3C, you need to configure the VSS to operate in 3C mode. The
platform hardware vsl pfc mode pfc3c configuration command sets the system to operate in 3C mode
after the next restart. See the SSO Dependencies section on page 4-27 for further details about this
command.

Multichassis EtherChannel Requirements

Physical links from any 67xx series switching module can be used to implement a Multichassis
EtherChannel (MEC).

Service Module Support

Using the indicated minimum software releases, the following service modules are supported in a VSS:

Minimum Minimum
Cisco IOS Module
Service Module Release Release
Network Analysis Module (NAM-1 and NAM-2) 12.2(33)SXH1 3.6(1a)
(WS-SVC-NAM-1 and WS-SVC-NAM-2)
Application Control Engine (ACE10 and ACE20) (ACE10-6500-K9 12.2(33)SXI A2(1.3)
and ACE20-MOD-K9)
Intrusion Detection System Services Module (IDSM-2) 12.2(33)SXI 6.0(2)E1
(WS-SVC-IDSM2-K9)
Wireless Services Module (WiSM) (WS-SVC-WISM-1-K9 12.2(33)SXI 3.2.171.6
Firewall Services Module (FWSM) (WS-SVC-FWM-1-K9) 12.2(33)SXI 4.0.4

Note Before deploying a service module in VSS mode, upgrade the module to the minimum supported release
in standalone mode.

WAN Module Support

No WAN modules are currently supported in virtual switch mode.

Understanding VSL Topology


A VSS contains two chassis that communicate using the VSL, which is a special port group.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-10 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

We recommend that you configure both of the 10-Gigabit Ethernet ports on the supervisor engines as
VSL ports. Optionally, you can also configure the VSL port group to contain switching module
10-Gigabit Ethernet ports. This configuration provides additional VSL capacity. See Figure 4-6 for an
example topology.

Figure 4-6 VSL Topology Example

VSL
Active Standby
Supervisor Supervisor

Linecard 1 Linecard 1
Linecard 2 Linecard 2

181326
Linecard N Linecard N
Active chassis Standby chassis

VSS Redundancy
The following sections describe how redundancy in a VSS supports network high availability:
Overview, page 4-11
RPR and SSO Redundancy, page 4-12
Failed Chassis Recovery, page 4-13
VSL Failure, page 4-13
User Actions, page 4-14

Overview
A VSS operates stateful switchover (SSO) between the VSS active and VSS standby supervisor engines.
Compared to standalone mode, a VSS has the following important differences in its redundancy model:
The VSS active and VSS standby supervisor engines are hosted in separate chassis and use the VSL
to exchange information.
The VSS active supervisor engine controls both chassis of the VSS. The VSS active supervisor
engine runs the Layer 2 and Layer 3 control protocols and manages the switching modules on both
chassis.
The VSS active and VSS standby chassis both perform data traffic forwarding.
If the VSS active supervisor engine fails, the VSS standby supervisor engine initiates a switchover and
assumes the VSS active role.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-11
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

RPR and SSO Redundancy


A VSS operates with stateful switchover (SSO) redundancy if it meets the following requirements:
Both supervisor engines must be running the same software version.
VSL-related configuration in the two chassis must match.
PFC mode must match.
SSO and nonstop forwarding (NSF) must be configured on each chassis.
See the SSO Dependencies section on page 4-27 for additional details about the requirements for SSO
redundancy on a VSS. See Chapter 6, Configuring NSF with SSO Supervisor Engine Redundancy for
information about configuring SSO and NSF.
With SSO redundancy, the VSS standby supervisor engine is always ready to assume control following
a fault on the VSS active supervisor engine. Configuration, forwarding, and state information are
synchronized from the VSS active supervisor engine to the redundant supervisor engine at startup and
whenever changes to the VSS active supervisor engine configuration occur. If a switchover occurs,
traffic disruption is minimized.
If a VSS does not meet the requirements for SSO redundancy, the VSS will use route processor
redundancy (RPR). In RPR mode, the VSS active supervisor engine does not synchronize configuration
changes or state information with the VSS standby. The VSS standby supervisor engine is only partially
initialized and the switching modules on the VSS standby supervisor are not powered up. If a switchover
occurs, the VSS standby supervisor engine completes its initialization and powers up the switching
modules. Traffic is disrupted for the normal reboot time of the chassis.
The VSS normally runs stateful switchover (SSO) between the VSS active and VSS standby supervisor
engines (see Figure 4-7). The VSS determines the role of each supervisor engine during initialization.
The supervisor engine in the VSS standby chassis runs in hot standby state. The VSS uses the VSL link
to synchronize configuration data from the VSS active to the VSS standby supervisor engine. Also,
protocols and features that support high availability synchronize their events and state information to the
VSS standby supervisor engine.

Figure 4-7 Chassis Roles in a VSS

VSL
Active Standby
Supervisor Supervisor

Linecard 1 Linecard 1
Linecard 2 Linecard 2
181326

Linecard N Linecard N
Active chassis Standby chassis

Cisco IOS Software Configuration Guide, Release 12.2SX


4-12 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

Failed Chassis Recovery


If the VSS active chassis or supervisor engine fails, the VSS initiates a stateful switchover (SSO) and
the former VSS standby supervisor engine assumes the VSS active role. The failed chassis performs
recovery action by reloading the supervisor engine.
If the VSS standby chassis or supervisor engine fails, no switchover is required. The failed chassis
performs recovery action by reloading the supervisor engine.
The VSL links are unavailable while the failed chassis recovers. After the chassis reloads, it becomes
the new VSS standby chassis and the VSS reinitializes the VSL links between the two chassis.
The switching modules on the failed chassis are unavailable during recovery, so the VSS operates only
with the MEC links that terminate on the VSS active chassis. The bandwidth of the VSS is reduced until
the failed chassis has completed its recovery and become operational again. Any devices that are
connected only to the failed chassis experience an outage.

Note The VSS may experience a brief data path disruption when the switching modules in the VSS standby
chassis become operational after the SSO.

After the SSO, much of the processing power of the VSS active supervisor engine is consumed in
bringing up a large number of ports simultaneously in the VSS standby chassis. As a result, some links
might be brought up before the supervisor engine has configured forwarding for the links, causing traffic
to those links to be lost until the configuration is complete. This condition is especially disruptive if the
link is an MEC link. Two methods are available to reduce data disruption following an SSO:
Beginning in Cisco IOS Release 12.2(33)SXH2, you can configure the VSS to activate non-VSL
ports in smaller groups over a period of time rather than all ports simultaneously. For information
about deferring activation of the ports, see the Configuring Deferred Port Activation During VSS
Standby Recovery section on page 4-45.
You can defer the load sharing of the peer switchs MEC member ports during reestablishment of
the port connections. See the Failed Chassis MEC Recovery section on page 4-16 for details about
load share deferral.

VSL Failure
To ensure fast recovery from VSL failures, fast link notification is enabled in virtual switch mode on all
port channel members (including VSL ports) whose hardware supports fast link notification.

Note Fast link notification is not compatible with link debounce mechanisms. In virtual switch mode, link
debounce is disabled on all port channel members.

If a single VSL physical link goes down, the VSS adjusts the port group so that the failed link is not
selected.
If the VSS standby chassis detects complete VSL link failure, it initiates a stateful switchover (SSO). If
the VSS active chassis has failed (causing the VSL links to go down), the scenario is chassis failure, as
described in the previous section.
If only the VSL has failed and the VSS active chassis is still operational, this is a dual-active scenario.
The VSS detects that both chassis are operating in VSS active mode and performs recovery action. See
the Dual-Active Detection section on page 4-22 for additional details about the dual-active scenario.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-13
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

User Actions
From the VSS active chassis command console, you can initiate a VSS switchover or a reload.
If you enter the reload command from the command console, the entire VSS performs a reload.
To reload only the VSS standby chassis, use redundancy reload peer command.
To force a switchover from the VSS active to the VSS standby supervisor engine, use the redundancy
force-switchover command.
To reset the VSS standby PRE module or to reset both the VSS active and VSS standby PRE modules,
use the redundancy reload shelf command.

Multichassis EtherChannels
These sections describe multichassis EtherChannels (MECs):
Overview, page 4-14
MEC Failure Scenarios, page 4-15

Overview
A multichassis EtherChannel is an EtherChannel with ports that terminate on both chassis of the VSS
(see Figure 4-8). A VSS MEC can connect to any network element that supports EtherChannel (such as
a host, server, router, or switch).
At the VSS, an MEC is an EtherChannel with additional capability: the VSS balances the load across
ports in each chassis independently. For example, if traffic enters the VSS active chassis, the VSS will
select an MEC link from the VSS active chassis. This MEC capability ensures that data traffic does not
unnecessarily traverse the VSL.
Each MEC can optionally be configured to support either PAgP or LACP. These protocols run only on
the VSS active chassis. PAgP or LACP control packets destined for an MEC link on the VSS standby
chassis are sent across VSL.
An MEC can support up to eight VSS active physical links, which can be distributed in any proportion
between the VSS active and VSS standby chassis.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-14 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

Figure 4-8 MEC Topology

Router, switch
or server

Virtual switch MEC


Supervisor Supervisor
engine engine

181327
Active chassis Standby chassis

MEC Failure Scenarios


We recommend that you configure the MEC with at least one link to each chassis. This configuration
conserves VSL bandwidth (traffic egress link is on the same chassis as the ingress link), and increases
network reliability (if one VSS supervisor engine fails, the MEC is still operational).
The following sections describe possible failures and the resulting impacts:
Single MEC Link Failure, page 4-15
All MEC Links to the VSS Active Chassis Fail, page 4-15
All MEC Links to the VSS Standby Chassis Fail, page 4-16
All MEC Links Fail, page 4-16
VSS Standby Chassis Failure, page 4-16
VSS Active Chassis Failure, page 4-16
Failed Chassis MEC Recovery, page 4-16

Single MEC Link Failure

If a link within the MEC fails (and other links in the MEC are still operational), the MEC redistributes
the load among the operational links, as in a regular port.

All MEC Links to the VSS Active Chassis Fail

If all links to the VSS active chassis fail, the MEC becomes a regular EtherChannel with operational
links to the VSS standby chassis.
Data traffic terminating on the VSS active chassis reaches the MEC by crossing the VSL to the VSS
standby chassis. Control protocols continue to run in the VSS active chassis. Protocol messages reach
the MEC by crossing the VSL.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-15
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

All MEC Links to the VSS Standby Chassis Fail

If all links fail to the VSS standby chassis, the MEC becomes a regular EtherChannel with operational
links to the VSS active chassis.
Control protocols continue to run in the VSS active chassis. All control and data traffic from the VSS
standby chassis reaches the MEC by crossing the VSL to the VSS active chassis.

All MEC Links Fail

If all links in an MEC fail, the logical interface for the EtherChannel is set to unavailable. Layer 2 control
protocols perform the same corrective action as for a link-down event on a regular EtherChannel.
On adjacent switches, routing protocols and Spanning Tree Protocol (STP) perform the same corrective
action as for a regular EtherChannel.

VSS Standby Chassis Failure

If the VSS standby chassis fails, the MEC becomes a regular EtherChannel with operational links on the
VSS active chassis. Connected peer switches detect the link failures, and adjust their load-balancing
algorithms to use only the links to the VSS active chassis.

VSS Active Chassis Failure

VSS active chassis failure results in a stateful switchover (SSO). See the VSS Redundancy section on
page 4-11 for details about SSO on a VSS. After the switchover, the MEC is operational on the new VSS
active chassis. Connected peer switches detect the link failures (to the failed chassis), and adjust their
load-balancing algorithms to use only the links to the new VSS active chassis.

Failed Chassis MEC Recovery

When a failed chassis returns to service as the new VSS standby chassis, protocol messages reestablish
the MEC links between the recovered chassis and connected peer switches.
Although the recovered chassis MEC links are immediately ready to receive unicast traffic from the peer
switch, received multicast traffic may be lost for a period of several seconds to several minutes. To
reduce this loss, you can configure the port load share deferral feature on MEC port channels of the peer
switch. When load share deferral is configured, the peers deferred MEC port channels will establish
with an initial load share of 0. During the configured deferral interval, the peers deferred port channels
are capable of receiving data and control traffic, and of sending control traffic, but are unable to forward
data traffic to the VSS. See the Configuring Port Load Share Deferral on the Peer Switch section on
page 4-46 for details about configuring port load share deferral.

Packet Handling
In a VSS, the VSS active supervisor engine runs the Layer 2 and Layer 3 protocols and features for the
VSS and manages the DFC modules for both chassis.
The VSS uses the VSL to communicate system and protocol information between the peer chassis and
to carry data traffic between the two chassis.
Both chassis perform packet forwarding for ingress traffic on their local interfaces. The VSS minimizes
the amount of data traffic that must traverse the VSL.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-16 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

The following sections describe packet handling in a VSS:


Traffic on the VSL, page 4-17
Layer 2 Protocols, page 4-17
Layer 3 Protocols, page 4-18
SPAN, page 4-20

Traffic on the VSL


The VSL carries data traffic and in-band control traffic between the two chassis. All frames forwarded
over the VSL link are encapsulated with a special 32-byte header, which provides information for the
VSS to forward the packet on the peer chassis.
The VSL transports control messages between the two chassis. Messages include protocol messages that
are processed by the VSS active supervisor engine, but received or transmitted by interfaces on the VSS
standby chassis. Control traffic also includes module programming between the VSS active supervisor
engine and switching modules on the VSS standby chassis.
The VSS needs to transmit data traffic over the VSL under the following circumstances:
Layer 2 traffic flooded over a VLAN (even for dual-homed links).
Packets processed by software on the VSS active supervisor engine where the ingress interface is on
the VSS standby chassis.
The packet destination is on the peer chassis, such as the following examples:
Traffic within a VLAN where the known destination interface is on the peer chassis.
Traffic that is replicated for a multicast group and the multicast receivers are on the peer chassis.
The known unicast destination MAC address is on the peer chassis.
The packet is a MAC notification frame destined for a port on the peer chassis.
VSL also transports system data, such as NetFlow export data and SNMP data, from the VSS standby
chassis to the VSS active supervisor engine.
To preserve the VSL bandwidth for critical functions, the VSS uses strategies to minimize user data
traffic that must traverse the VSL. For example, if an access switch is dual-homed (attached with an
MEC terminating on both VSS chassis), the VSS transmits packets to the access switch using a link on
the same chassis as the ingress link.
Traffic on the VSL is load-balanced with the same global hashing algorithms available for
EtherChannels (the default algorithm is source-destination IP).

Layer 2 Protocols
The VSS active supervisor engine runs the Layer 2 protocols (such as STP and VTP) for the switching
modules on both chassis. Protocol messages that are transmitted and received on the VSS standby chassis
switching modules must traverse the VSL to reach the VSS active supervisor engine.
The following sections describe Layer 2 protocols for a VSS:
Spanning Tree Protocol, page 4-18
Virtual Trunk Protocol, page 4-18
EtherChannel Control Protocols, page 4-18
Multicast Protocols, page 4-18

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-17
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

Spanning Tree Protocol

The VSS active chassis runs Spanning Tree Protocol (STP). The VSS standby chassis redirects STP
BPDUs across the VSL to the VSS active chassis.
The STP bridge ID is commonly derived from the chassis MAC address. To ensure that the bridge ID
does not change after a switchover, the VSS continues to use the original chassis MAC address for the
STP Bridge ID.

Virtual Trunk Protocol

Virtual Trunk Protocol (VTP) uses the IP address of the switch and local current time for version control
in advertisements. After a switchover, VTP uses the IP address of the newly VSS active chassis.

EtherChannel Control Protocols

Link Aggregation Control Protocol (LACP) and Port Aggregation Protocol (PAgP) packets contain a
device identifier. The VSS defines a common device identifier for both chassis to use.
A new PAgP enhancement has been defined for assisting with dual-active scenario detection. For
additional information, see the Dual-Active Detection section on page 4-22.

Multicast Protocols

In Release 12.2(33)SXI4 and later releases, fast-redirect optimization makes multicast traffic redirection
between inter-chassis or intra-chassis line cards faster for Layer 2 trunk multichassis EtherChannel or
distributed EtherChannel in case of member port link failure and recovery. This operation occurs mainly
when a member port link goes down (port leaves the EtherChannel) and when the member port link goes
up (port joins or rejoins the EtherChannel). Fast-redirect does not take effect when you add or remove a
member port due to a configuration change or during system boot up.

Layer 3 Protocols
The MSFC on the VSS active supervisor engine runs the Layer 3 protocols and features for the VSS.
Both chassis perform packet forwarding for ingress traffic on their interfaces. If possible, ingress traffic
is forwarded to an outgoing interface on the same chassis, to minimize data traffic that must traverse the
VSL.
Because the VSS standby chassis is actively forwarding traffic, the VSS active supervisor engine
distributes updates to the VSS standby supervisor engine PFC and all VSS standby chassis DFCs.
The following sections describe Layer 3 protocols for a VSS:
IPv4, page 4-18
IPv6 and MPLS, page 4-19
IPv4 Multicast, page 4-19
Software Features, page 4-20

IPv4

The supervisor engine on the VSS active chassis runs the IPv4 routing protocols and performs any
required software forwarding.
Routing updates received on the VSS standby chassis are redirected to the VSS active chassis across the
VSL.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-18 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

Hardware forwarding is distributed across all DFCs on the VSS. The supervisor engine on the VSS active
chassis sends FIB updates to all local DFCs, remote DFCs, and the VSS standby supervisor engine PFC.
All hardware routing uses the router MAC address assigned by the VSS active supervisor engine. After
a switchover, the original MAC address is still used.
The supervisor engine on the VSS active chassis performs all software forwarding (for protocols such
as IPX) and feature processing (such as fragmentation and TTL exceed). If a switchover occurs, software
forwarding is disrupted until the new VSS active supervisor engine obtains the latest CEF and other
forwarding information.
In virtual switch mode, the requirements to support non-stop forwarding (NSF) are the same as in
standalone mode. For additional information about NSF requirements, refer to the Catalyst 6500 Series
Switch Cisco IOS Configuration Guide, Release 12.2SX.
From a routing peer perspective, EtherChannels remain operational during a switchover (only the links
to the failed chassis are down, so the routing adjacencies remains valid).
The VSS implements path filtering by storing only local paths (paths that do not traverse the VSL) in the
FIB entries. Therefore, IP forwarding performs load sharing among the local paths. If no local paths to
a given destination are available, the VSS updates the FIB entry to include remote paths (reachable by
traversing the VSL).

IPv6 and MPLS

In Cisco IOS Release 12.2(33)SXI2 and later releases, the VSS supports IPv6 unicast and MPLS.

IPv4 Multicast

The IPv4 multicast protocols run on the VSS active supervisor engine. Internet Group Management
Protocol (IGMP) and Protocol Independent Multicast (PIM) protocol packets received on the VSS
standby supervisor engine are transmitted across VSL to the VSS active chassis.
The VSS active supervisor engine sends IGMP and PIM protocol packets to the VSS standby supervisor
engine in order to maintain Layer 2 information for stateful switchover (SSO).
The VSS active supervisor engine distributes multicast FIB and adjacency table updates to the VSS
standby supervisor engine and switching module DFCs.
For Layer 3 multicast in the VSS, learned multicast routes are stored in hardware in the VSS standby
supervisor engine. After a switchover, multicast forwarding continues, using the existing hardware
entries.

Note To avoid multicast route changes as a result of the switchover, we recommend that all links carrying
multicast traffic be configured as MEC rather than Equal Cost Multipath (ECMP).

In virtual switch mode, the VSS active chassis does not program the multicast expansion table (MET)
on the VSS standby chassis. The VSS standby supervisor engine programs the outgoing interface
hardware entries for all local multicast receivers
If all switching modules on the VSS active chassis and VSS standby chassis are egress capable, the
multicast replication mode is set to egress mode; otherwise, the mode is set to ingress mode.
In egress mode, replication is distributed to DFCs that have ports in outgoing VLANs for a particular
flow. In ingress mode, replication for all outgoing VLANs is done on the ingress DFC.
For packets traversing VSL, all Layer 3 multicast replication occurs on the ingress chassis. If there are
multiple receivers on the egress chassis, replicated packets are forwarded over the VSL.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-19
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

Software Features

Software features run only on the VSS active supervisor engine. Incoming packets to the VSS standby
chassis that require software processing are sent across the VSL.
For features supported in hardware, the ACL configuration is sent to the TCAM manager on the VSS
active supervisor engine, the VSS standby supervisor engine, and all DFCs.

SPAN
The VSS supports all SPAN features for non-VSL interfaces. The VSS supports SPAN features on VSL
interfaces with the following limitations:
If the VSL is configured as a local SPAN source, the SPAN destination interface must be on the same
chassis as the source interface.
VSL cannot be configured as a SPAN destination.
VSL cannot be configured as a traffic source of RSPAN, ERSPAN, or egress-only SPAN.
The number of SPAN sessions available to a VSS is the same as for a single chassis running in standalone
mode.

System Monitoring
The following sections describe system monitoring and system management for a VSS:
Power Management, page 4-20
Environmental Monitoring, page 4-20
File System Access, page 4-21
VSL Diagnostics, page 4-21
Service Modules, page 4-21
Network Management, page 4-22

Power Management
From the VSS active chassis, you can control power-related functions for the VSS standby chassis. For
example, use the power enable switch command to control power to the modules and slots on the VSS
standby chassis. Use the show power switch command to see the current power settings and status.

Environmental Monitoring
Environmental monitoring runs on both supervisor engines. The VSS standby chassis reports
notifications to the VSS active supervisor engine. The VSS active chassis gathers log messages for both
chassis. The VSS active chassis synchronizes the calendar and system clock to the VSS standby chassis.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-20 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

File System Access


You can access file systems of both chassis from the VSS active chassis. Prefix the device name with the
switch number and slot number to access directories on the VSS standby chassis. For example, the
command dir sw2-slot6-disk0: lists the contents of disk0 on the VSS standby chassis (assuming switch
2 is the VSS standby chassis). You can access the VSS standby chassis file system only when VSL is
operational.

VSL Diagnostics
You can use the diagnostic schedule and diagnostic start commands on a VSS. In virtual switch mode,
these commands require an additional parameter, which specifies the chassis to apply the command.
When you configure a VSL port on a switching module or a supervisor engine module, the diagnostics
suite incorporates additional tests for the VSL ports.
Use the show diagnostic content command to display the diagnostics test suite for a module.
The following VSL-specific diagnostics tests are available on WS-X6708-10GE switching modules with
VSL ports. These tests are disruptive:
TestVslBridgeLink
TestVslLocalLoopback
The following VSL-specific diagnostics tests are available on a Supervisor Engine 720-10GE with VSL
ports. These tests are disruptive:
TestVSActiveToStandbyLoopback
TestVslBridgeLink
TestVslLocalLoopback
The following VSL-specific diagnostics test is available for VSL ports on the switching module or the
supervisor engine. This test is not disruptive:
TestVslStatus
See the ViSN Tests section on page B-45.

Service Modules
The following system monitoring and system management guidelines apply to service modules
supported by the VSS:
The supervisor engine in the same chassis as the service module controls the powering up of the
service module. After the service module is online, you initiate a session from the VSS active
supervisor engine to configure and maintain the service module.
Use the session command to connect to the service module. If the service module is in the VSS
standby chassis, the session runs over the VSL.
The VSS active chassis performs the graceful shutdown of the service module, even if the service
module is in the VSS standby chassis.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-21
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

Network Management
The following sections describe network management for a VSS:
Telnet over SSH Sessions and the Web Browser User Interface, page 4-22
SNMP, page 4-22
Command Console, page 4-22

Telnet over SSH Sessions and the Web Browser User Interface

A VSS supports remote access using Telnet over SSH sessions and the Cisco web browser user interface.
All remote access is directed to the VSS active supervisor engine, which manages the whole VSS.
If the VSS performs a switchover, Telnet over SSH sessions and web browser sessions are disconnected.

SNMP

The SNMP agent runs on the VSS active supervisor engine.


CISCO-VIRTUAL-SWITCH-MIB is a new MIB for virtual switch mode and contains the following
main components:
cvsGlobalObjects Domain #, Switch #, Switch Mode
cvsCoreSwitchConfig Switch Priority
cvsChassisTable Chassis Role and Uptime
cvsVSLConnectionTable VSL Port Count, Operational State
cvsVSLStatsTable Total Packets, Total Error Packets
cvsVSLPortStatsTable TX/RX Good, Bad, Bi-dir and Uni-dir Packets

Command Console

Connect console cables to both supervisor engine console ports. You can only use configuration mode
in the console for the VSS active supervisor engine.
The console on the VSS standby chassis will indicate that chassis is operating in VSS standby mode by
adding the characters -stdby to the command line prompt. You cannot enter configuration mode on the
VSS standby chassis console.
The following example shows the prompt on the VSS standby console:
Router-stdby> show switch virtual
Switch mode : Virtual Switch
Virtual switch domain number : 100
Local switch number : 1
Local switch operational role: Virtual Switch Standby
Peer switch number : 2
Peer switch operational role : Virtual Switch Active

Dual-Active Detection
If the VSL fails, the VSS standby chassis cannot determine the state of the VSS active chassis. To ensure
that switchover occurs without delay, the VSS standby chassis assumes the VSS active chassis has failed
and initiates switchover to take over the VSS active role.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-22 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

If the original VSS active chassis is still operational, both chassis are now VSS active. This situation is
called a dual-active scenario. A dual-active scenario can have adverse affects on network stability,
because both chassis use the same IP addresses, SSH keys, and STP bridge ID. The VSS must detect a
dual-active scenario and take recovery action.
The VSS supports these three methods for detecting a dual-active scenario:
Enhanced PAgPUses PAgP messaging over the MEC links to communicate between the two
chassis through a neighbor switch. Enhanced PAgP is faster than IP BFD, but requires a neighbor
switch that supports the PAgP enhancements.
IP Bidirectional Forwarding Detection (BFD)Uses BFD messaging over a backup Ethernet
connection. IP BFD uses a direct connection between the two chassis and does not require support
from a neighbor switch.
dual-active fast-helloUses special hello messages over a backup Ethernet connection. Dual-active
fast-hello is faster than IP BFD and does not require support from a neighbor switch. This method
is available only in Cisco IOS Release 12.2(33)SXI and later releases,
You can configure all three detection methods to be VSS active at the same time.
For line redundancy, we recommend dedicating at least two ports per switch for dual-active detection.
For module redundancy, the two ports can be on different switching modules in each chassis, and should
be on different modules than the VSL links, if feasible.
The dual-active detection and recovery methods are described in the following sections:
Dual-Active Detection Using Enhanced PAgP, page 4-23
Dual-Active Detection Using IP BFD, page 4-24
Dual-Active Detection Using Dual-Active Fast Hello Packets, page 4-24
Recovery Actions, page 4-25

Dual-Active Detection Using Enhanced PAgP


Port aggregation protocol (PAgP) is a Cisco-proprietary protocol for managing EtherChannels. If a VSS
MEC terminates to a Cisco switch, you can run PAgP protocol on the MEC. If PAgP is running on the
MECs between the VSS and an upstream or downstream switch, the VSS can use PAgP to detect a
dual-active scenario. The MEC must have at least one port on each chassis of the VSS.
In virtual switch mode, PAgP messages include a new type length value (TLV) which contains the ID of
the VSS active switch. Only switches in virtual switch mode send the new TLV.
For dual-active detection to operate successfully, one or more of the connected switches must be able to
process the new TLV. Catalyst 6500 series switches with Supervisor Engine 32 and Supervisor Engine
720 have this capability if they are running Cisco IOS Release 12.2(33)SXH1 or later. For a list of other
Cisco products that support enhanced PAgP, refer to Release Notes for Cisco IOS Release 12.2SX at this
URL:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/release/notes/ol_14271.html
When the VSS standby chassis detects VSL failure, it initiates SSO and becomes VSS active. Subsequent
PAgP messages to the connected switch from the newly VSS active chassis contain the new VSS active
ID. The connected switch sends PAgP messages with the new VSS active ID to both VSS chassis.
If the formerly VSS active chassis is still operational, it detects the dual-active scenario because the VSS
active ID in the PAgP messages changes. This chassis initiates recovery actions as described in the
Recovery Actions section on page 4-25.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-23
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

Dual-Active Detection Using IP BFD


To use the IP BFD detection method, you must provision a direct Ethernet connection between the two
switches. Regular Layer 3 ping will not function correctly on this connection, as both chassis have the
same IP address. The VSS instead uses the Bidirectional Forwarding Detection (BFD) protocol.
If the VSL fails, both chassis create BFD neighbors, and try to establish adjacency. If the original VSS
active chassis receives an adjacency message, it realizes that this is a dual-active scenario, and initiates
recovery actions as described in the Recovery Actions section on page 4-25.

Note If Flex Links are configured on the VSS, we recommend using the PAgP detection method. Do not
configure Flex Links and BFD dual-active detection on the same VSS.

Dual-Active Detection Using Dual-Active Fast Hello Packets


Cisco IOS Release 12.2(33)SXI and later releases support the dual-active fast hello method.
To use the dual-active fast hello packet detection method, you must provision a direct Ethernet
connection between the two switches. You can dedicate up to four non-VSL links for this purpose.
The two chassis periodically exchange special Layer 2 dual-active hello messages containing
information about the switch state. If the VSL fails and a dual-active scenario occurs, each switch
recognizes from the peers messages that there is a dual-active scenario and initiates recovery actions as
described in the Recovery Actions section on page 4-25. If a switch does not receive an expected
dual-active fast hello message from the peer before the timer expires, the switch assumes that the link is
no longer capable of dual-active detection.
When you configure dual-active fast hello mode, all existing configurations are removed automatically
from the interface except for the specific commands. When you configure dual-active fast hello mode,
the system puts the interface into a restricted mode. When an interface is in restricted mode, only specific
configuration commands can be entered on the interface.
The following fast hello configuration commands are not removed from the interface when it becomes
restricted:
description
logging event
load-interval
rcv-queue cos-map
rcv-queue queue-limit
rcv-queue random-detect
rcv-queue threshold
wrr-queue bandwidth
wrr-queue cos-map
wrr-queue queue-limit
wrr-queue random-detect
wrr-queue threshold
priority-queue cos-map
When in dual-active fast hello restricted mode, these configuration commands are available:

Cisco IOS Software Configuration Guide, Release 12.2SX


4-24 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

default
description
dual-active
exit
load-interval
logging
no
shutdown

Note ASIC-specific QoS commands are not configurable on the fast hello ports directly, but are allowed to
remain on the fast hello port if the commands were configured on another non-fast hello port in that same
ASIC group. For a list of these commands, see the Configuring PFC QoS - General Guidelines Section
at:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/qos.html
#wp1583195

Recovery Actions
An VSS active chassis that detects a dual-active condition shuts down all of its non-VSL interfaces
(except interfaces configured to be excluded from shutdown) to remove itself from the network, and
waits in recovery mode until the VSL links have recovered. You might need to intervene directly to fix
the VSL failure. When the shut down chassis detects that VSL is operational again, the chassis reloads
and returns to service as the VSS standby chassis.
Loopback interfaces are also shut down in recovery mode. We do not recommend configuring loopback
interfaces at this time (while in recovery mode), because any new loopback interfaces configured in
recovery mode will not be shut down.

Note If the running configuration of the chassis in recovery mode has been changed without saving, the
chassis will not automatically reload. In this situation, you must write the configuration to memory and
then reload manually.

VSS Initialization
A VSS is formed when the two chassis and the VSL link between them become operational. The peer
chassis communicate over the VSL to negotiate the chassis roles.
If only one chassis becomes operational, it assumes the VSS active role. The VSS forms when the second
chassis becomes operational and both chassis bring up their VSL interfaces.
VSS initialization is described in the following sections:
Virtual Switch Link Protocol, page 4-26
SSO Dependencies, page 4-27
Initialization Procedure, page 4-28

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-25
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

Virtual Switch Link Protocol


The Virtual Switch Link Protocol (VSLP) consists of several protocols that contribute to virtual switch
initialization. The VSLP includes the following protocols:
Role Resolution Protocol
The peer chassis use Role Resolution Protocol (RRP) to negotiate the role (VSS active or VSS
standby) for each chassis.
Link Management Protocol
The Link Management Protocol (LMP) runs on all VSL links, and exchanges information required
to establish communication between the two chassis.
LMP identifies and rejects any unidirectional links. If LMP flags a unidirectional link, the chassis
that detects the condition brings the link down and up to restart the VSLP negotiation. VSL moves
the control traffic to another port if necessary.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-26 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

SSO Dependencies
For the VSS to operate with SSO redundancy, the VSS must meet the following conditions:
Identical software versions
Both supervisor engine modules on the VSS must be running the identical software version.
VSL configuration consistency
During the startup sequence, the VSS standby chassis sends virtual switch information from the
startup-config file to the VSS active chassis.
The VSS active chassis ensures that the following information matches correctly on both chassis:
Switch virtual domain
Switch virtual node
Switch priority
VSL port channel: switch virtual link identifier
VSL ports: channel-group number, shutdown, total number of VSL ports
Power redundancy-mode
Power enable on VSL modules
If the VSS detects a mismatch, it prints out an error message on the VSS active chassis console and
the VSS standby chassis comes up in RPR mode.
After you correct the configuration file, save the file by entering the copy running-config
startup-config command on the VSS active chassis, and then restart the VSS standby chassis.
PFC mode check
If both supervisor engines are provisioned with PFC3C, the VSS will automatically operate in
PFC3C mode, even if some of the switching modules are equipped with 3CXL daughter feature
cards (DFCs).
However, if the supervisor engines are provisioned with PFC3CXL and there is a mixture of DFC3C
and DFC3CXL switching modules, the system PFC mode will depend on how the 3C and 3CXL
switching modules are distributed between the two chassis.
Each chassis in the VSS determines its system PFC mode. If the supervisor engine of a given chassis
is provisioned with PFC3CXL and all the switching modules in the chassis are provisioned with
DFC3CXL, the PFC mode for the chassis is PFC3CXL. However, if any of the switching modules
is provisioned with DFC3C, the chassis PFC mode will be set to PFC3C. If there is a mismatch
between the PFC modes of two chassis, the VSS will come up in RPR mode instead of SSO mode.
You can prevent this situation by using the platform hardware vsl pfc mode pfc3c command to
force the VSS to operate in PFC3C mode after the next reload.
SSO and NSF enabled
SSO and NSF must be configured and enabled on both chassis. For detailed information on
configuring and verifying SSO and NSF, see Chapter 6, Configuring NSF with SSO
Supervisor Engine Redundancy.
If these conditions are not met, the VSS operates in RPR redundancy mode. For a description of SSO
and RPR, see the VSS Redundancy section on page 4-11.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-27
Chapter 4 Configuring Virtual Switching Systems
Understanding Virtual Switching Systems

Initialization Procedure
The following sections describe the VSS initialization procedure:
VSL Initialization, page 4-28
System Initialization, page 4-28
VSL Down, page 4-28

VSL Initialization

A VSS is formed when the two chassis and the VSL link between them become operational. Because
both chassis need to be assigned their role (VSS active or VSS standby) before completing initialization,
VSL is brought online before the rest of the system is initialized. The initialization sequence is as
follows:
1. The VSS initializes all cards with VSL ports, and then initializes the VSL ports.
2. The two chassis communicate over VSL to negotiate their roles (VSS active or VSS standby).
3. The VSS active chassis completes the boot sequence, including the consistency check described in
the SSO Dependencies section on page 4-27.
4. If the consistency check completed successfully, the VSS standby chassis comes up in SSO VSS
standby mode. If the consistency check failed, the VSS standby chassis comes up in RPR mode.
5. The VSS active chassis synchronizes configuration and application data to the VSS standby chassis.

System Initialization

If you boot both chassis simultaneously, the VSL ports become VSS active, and the chassis will come
up as VSS active and VSS standby. If priority is configured, the higher priority switch becomes active.
If you boot up only one chassis, the VSL ports remain inactive, and the chassis comes up as VSS active.
When you subsequently boot up the other chassis, the VSL links become active, and the new chassis
comes up as VSS standby.

VSL Down

If the VSL is down when both chassis try to boot up, the situation is similar to a dual-active scenario.
One of the chassis becomes VSS active and the other chassis initiates recovery from the dual-active
scenario. For further information, see the Configuring Dual-Active Detection section on page 4-46.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-28 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
VSS Configuration Guidelines and Restrictions

VSS Configuration Guidelines and Restrictions


The following sections describe restrictions and guidelines for VSS configuration:
General VSS Restrictions and Guidelines, page 4-29
VSL Restrictions and Guidelines, page 4-29
Multichassis EtherChannel Restrictions and Guidelines, page 4-29
Dual-Active Detection Restrictions and Guidelines, page 4-30
Service Module Restrictions and Guidelines, page 4-30
Configuring a VSS, page 4-30

General VSS Restrictions and Guidelines


When configuring the VSS, note the following guidelines and restrictions:
The VSS configurations in the startup-config file must match on both chassis.
We recommend enabling out-of-band MAC address table synchronization among DFC-equipped
switching modules by entering the mac-address-table synchronize command.

VSL Restrictions and Guidelines


When configuring the VSL, note the following guidelines and restrictions:
For line redundancy, we recommend configuring at least two ports per switch for the VSL. For
module redundancy, the two ports can be on different switching modules in each chassis.
The no mls qos channel-consistency command is automatically applied when you configure the
VSL. Do not remove this command.
Monitor capture sessions cannot be started if a source is the VSL on the port channel of the standby
switch.
You can specify multiple sources for the monitor capture, but you will need to remove the VSL as a
source. The following message is displayed when a remote VSL port channel on the standby switch
is specified and you attempt to start the monitor capture:
% remote VSL port is not allowed as capture source

The following message is displayed when a scheduled monitor capture start fails because a source
is a remote VSL port channel:
Packet capture session 1 failed to start. A source port is a remote VSL.

Multichassis EtherChannel Restrictions and Guidelines


When configuring MECs, note the following guidelines and restrictions:
All links in an MEC must terminate locally on the VSS active or VSS standby chassis of the same
virtual domain.
For an MEC using LACP control protocol, minlinks defines the minimum number of physical links
in each chassis for the MEC to be operational.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-29
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

For an MEC using LACP control protocol, maxbundle defines the maximum number of links in the
MEC across the whole VSS.
MEC supports LACP 1:1 redundancy. For additional information about LACP 1:1 redundancy, refer
to the Understanding LACP 1:1 Redundancy section on page 19-5.
An MEC can be connected to another MEC on a different VSS domain.

Dual-Active Detection Restrictions and Guidelines


When configuring dual-active detection, note the following guidelines and restrictions:
If Flex Links are configured on the VSS, we recommend using the PAgP detection method. Do not
configure Flex Links and BFD dual-active detection on the same VSS.
For line redundancy, we recommend configuring at least two ports per switch for dual-active
detection. For module redundancy, the two ports can be on different switching modules in each
chassis, and should be on different modules than the VSL, if feasible.

Service Module Restrictions and Guidelines


When configuring service modules in a VSS, note the following guidelines and restrictions:
When configuring and attaching VLAN groups to a service module interface in a VSS, use the
switch {1 | 2} command keyword. For example, the firewall vlan-group command becomes the
firewall switch num slot slot vlan-group command.
When upgrading the software image of a service module in a VSS, use the switch {1 | 2} command
keyword.
EtherChannel load balancing (ECLB) is not supported between an IDSM-2 in the VSS active chassis
and an IDSM-2 in the VSS standby chassis.
A switchover between two service modules in separate chassis of a VSS is considered an
intrachassis switchover.

Note For detailed instructions, restrictions, and guidelines for a service module in a VSS, see the configuration
guide and command reference for the service module.

Configuring a VSS
These sections describe how to configure a VSS:
Converting to a VSS, page 4-31
Displaying VSS Information, page 4-37
Converting a VSS to Standalone Chassis, page 4-37
Configuring VSS Parameters, page 4-39
Configuring Multichassis EtherChannels, page 4-45
Configuring Dual-Active Detection, page 4-46
Configuring Service Modules in a VSS, page 4-52

Cisco IOS Software Configuration Guide, Release 12.2SX


4-30 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Viewing Chassis Status and Module Information in a VSS, page 4-54


Upgrading a VSS, page 4-55

Converting to a VSS
By default, the Catalyst 6500 series switch is configured to operate in standalone mode (the switch is a
single chassis). The VSS combines two standalone switches into one virtual switch, operating in virtual
switch mode.

Note When you convert two standalone switches into one VSS, all non-VSL configuration settings on the VSS
standby chassis will revert to the default configuration.

To convert two standalone chassis into a VSS, you perform the following major activities:
Save the standalone configuration files.
Configure SSO and NSF on each chassis.
Configure each chassis as a VSS.
Convert to a VSS.
Configure the peer VSL information.
In virtual switch mode, both chassis use the same configuration file. When you make configuration
changes on the VSS active chassis, these changes are automatically propagated to the VSS standby
chassis.
The tasks required to convert the standalone chassis to a VSS are detailed in the following sections:
Backing Up the Standalone Configuration, page 4-32
Configuring SSO and NSF, page 4-32
Assigning Virtual Switch Domain and Switch Numbers, page 4-33
Configuring VSL Port Channel and Ports, page 4-34
Converting the Chassis to Virtual Switch Mode, page 4-35
(Optional) Configuring VSS Standby Chassis Modules, page 4-36
In the procedures that follow, the example commands assume the configuration shown in Figure 4-9.

Figure 4-9 Example VSS

T 5/1 T 5/2
Chassis A Chassis B
(Switch 1) (Switch 2)
181325

Virtual switch link


(VSL)

Two chassis, A and B, are converted into a VSS with virtual switch domain 100. Interface 10-Gigabit
Ethernet 5/1 on Switch 1 is connected to interface 10-Gigabit Ethernet 5/2 on Switch 2 to form the VSL.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-31
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Backing Up the Standalone Configuration


Save the configuration files for both chassis operating in standalone mode. You need these files to revert
to standalone mode from virtual switch mode. On Switch 1, perform this task:

Command Purpose
Step 1 Switch-1# copy running-config startup-config (Optional) Saves the running configuration to startup
configuration.
Step 2 Switch-1# copy startup-config Copies the startup configuration to a backup file.
disk0:old-startup-config

Perform the following task on Switch 2:

Command Purpose
Step 1 Switch-2# copy running-config startup-config (Optional) Saves the running configuration to the
startup configuration file.
Step 2 Switch-2# copy startup-config Copies the startup configuration to a backup file.
disk0:old-startup-config

Configuring SSO and NSF


SSO and NSF must be configured and enabled on both chassis. On Switch 1, perform this task:

Command Purpose
Step 1 Switch-1(config)# redundancy Enters redundancy configuration mode.
Step 2 Switch-1(config-red)# mode sso Configures SSO. When this command is entered, the
redundant supervisor engine is reloaded and begins to
work in SSO mode.
Step 3 Switch-1(config-red)# exit Exits redundancy configuration mode.
Step 4 Switch-1(config)# router routing_protocol processID Enables routing, which places the router in router
configuration mode.
Step 5 Switch-1(config-router)# nsf Enables NSF operations for the routing protocol.
Step 6 Switch-1(config-router)# end Exits to privileged EXEC mode.
Step 7 Switch-1# show running-config Verifies that SSO and NSF are configured and
enabled.
Step 8 Switch-1# show redundancy states Displays the operating redundancy mode.

Perform the following task on Switch 2:

Command Purpose
Step 1 Switch-2(config)# redundancy Enters redundancy configuration mode.
Step 2 Switch-2(config-red)# mode sso Configures SSO. When this command is entered, the
redundant supervisor engine is reloaded and begins to
work in SSO mode.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-32 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Command Purpose
Step 3 Switch-2(config-red)# exit Exits redundancy configuration mode.
Step 4 Switch-2(config)# router routing_protocol processID Enables routing, which places the router in router
configuration mode.
Step 5 Switch-2(config-router)# nsf Enables NSF operations for the routing protocol.
Step 6 Switch-2(config-router)# end Exits to privileged EXEC mode.
Step 7 Switch-2# show running-config Verifies that SSO and NSF are configured and
enabled.
Step 8 Switch-2# show redundancy states Displays the operating redundancy mode.

For detailed information on configuring and verifying SSO and NSF, see Chapter 6, Configuring NSF
with SSO Supervisor Engine Redundancy.

Assigning Virtual Switch Domain and Switch Numbers


You must configure the same virtual switch domain number on both chassis of the VSS. The virtual
switch domain is a number between 1 and 255, and must be unique for each VSS in your network (the
domain number is incorporated into various identifiers to ensure that these identifiers are unique across
the network).
Within the VSS, you must configure one chassis to be switch number 1 and the other chassis to be switch
number 2.
To configure the virtual switch domain and switch number on both chassis, perform this task on
Switch 1:

Command Purpose
Step 1 Switch-1(config)# switch virtual domain 100 Configures the virtual switch domain on Chassis A.
Step 2 Switch-1(config-vs-domain)# switch 1 Configures Chassis A as virtual switch number 1.
Step 3 Switch-1(config-vs-domain)# exit Exits config-vs-domain.

Perform the following task on Switch 2:

Command Purpose
Step 1 Switch-2(config)# switch virtual domain 100 Configures the virtual switch domain on Chassis B.
Step 2 Switch-2(config-vs-domain)# switch 2 Configures Chassis B as virtual switch number 2.
Step 3 Switch-2(config-vs-domain)# exit Exits config-vs-domain.

Note The switch number is not stored in the startup or running configuration, because both chassis use the
same configuration file (but must not have the same switch number).

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-33
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Configuring VSL Port Channel and Ports


The VSL is configured with a unique port channel on each chassis. During the conversion, the VSS
configures both port channels on the VSS active chassis. If the VSS standby chassis VSL port channel
number has been configured for another use, the VSS comes up in RPR mode. To avoid this situation,
check that both port channel numbers are available on both of the chassis.
Check the port channel number by using the show running-config interface port-channel command.
The command displays an error message if the port channel is available for VSL. For example, the
following command shows that port channel 20 is available on Switch 1:
Switch-1 # show running-config interface port-channel 20
% Invalid input detected at '^' marker.

To configure the VSL port channels, perform this task on Switch 1:

Command Purpose
Step 1 Switch-1(config)# interface port-channel 10 Configures port channel 10 on Switch 1.
Step 2 Switch-1(config-if)# switch virtual link 1 Associates Switch 1 as owner of port channel 10.
Step 3 Switch-1(config-if)# no shutdown Activates the port channel.
Step 4 Switch-1(config-if)# exit Exits interface configuration.

Perform the following task on Switch 2:

Command Purpose
Step 1 Switch-2(config)# interface port-channel 20 Configures port channel 20 on Switch 2.
Step 2 Switch-2(config-if)# switch virtual link 2 Associates Switch 2 as owner of port channel 20.
Step 3 Switch-2(config-if)# no shutdown Activates the port channel.
Step 4 Switch-2(config-if)# exit Exits interface configuration mode.

You must add the VSL physical ports to the port channel. In the following example, interfaces 10-Gigabit
Ethernet 3/1 and 3/2 on Switch 1 are connected to interfaces 10-Gigabit Ethernet 5/2 and 5/3 on
Switch 2.

Tip For line redundancy, we recommend configuring at least two ports per switch for the VSL. For module
redundancy, the two ports can be on different switching modules in each chassis.

To configure the VSL ports, perform this task on Switch 1:

Command Purpose
Step 1 Switch-1(config)# interface range Enters configuration mode for interface range
tengigabitethernet 3/1-2 tengigabitethernet 3/1-2 on Switch 1.
Step 2 Switch-1(config-if)# channel-group 10 mode on Adds this interface to channel group 10.
Step 3 witch-1(config-if)# no shutdown Activates the port.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-34 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Perform the following task on Switch 2:

Command Purpose
Step 1 Switch-2(config)# interface range Enters configuration mode for interface range
tengigabitethernet 5/2-3 tengigabitethernet 5/2-3 on Switch 2.
Step 2 Switch-2(config-if)# channel-group 20 mode on Adds this interface to channel group 20.
Step 3 Switch-2(config-if)# no shutdown Activates the port.

Converting the Chassis to Virtual Switch Mode


Conversion to virtual switch mode requires a restart for both chassis. After the reboot, commands that
specify interfaces with module/port now include the switch number. For example, a port on a switching
module is specified by switch/module/port.
Prior to the restart, the VSS converts the startup configuration to use the switch/module/port convention.
A backup copy of the startup configuration file is saved on the RP. This file is assigned a default name,
but you are also prompted to override the default name if you want to change it.
Prior to the conversion, ensure that the PFC operating mode matches on both chassis. If they do not
match, VSS comes up in RPR redundancy mode. Enter the show platform hardware pfc mode
command on each chassis to display the current PFC mode. If only one of the chassis is in PFC3CXL
mode, you can configure it to use PFC3C mode with the platform hardware vsl pfc mode pfc3c
command.
To verify the PFC operating mode, perform this task:

Command Purpose
Step 1 Switch-1# show platform hardware pfc mode Ensures that the PFC operating mode matches on
both chassis, to ensure that the VSS comes up in SSO
redundancy mode.
Step 2 Switch-2# show platform hardware pfc mode Ensures that the PFC operating mode matches on
both chassis, to ensure that the VSS comes up in SSO
redundancy mode.
Step 3 Switch-1(config)# platform hardware vsl pfc mode (Optional) Sets the PFC operating mode to PFC3C on
pfc3c Chassis A.
Step 4 Switch-2(config)# platform hardware vsl pfc mode (Optional) Sets the PFC operating mode to PFC3C on
pfc3c Chassis B.

To convert Chassis 1 to virtual switch mode, perform this task:

Command Purpose
Switch-1# switch convert mode virtual Converts Switch 1 to virtual switch mode.
After you enter the command, you are prompted to
confirm the action. Enter yes.
The system creates a converted configuration file, and
saves the file to the RP bootflash.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-35
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

To convert Chassis 2 to virtual switch mode, perform this task on Switch 2:

Command Purpose
Switch-2# switch convert mode virtual Converts Switch 2 to virtual switch mode.
After you enter the command, you are prompted to
confirm the action. Enter yes.
The system creates a converted configuration file, and
saves the file to the RP bootflash.

Note After you confirm the command (by entering yes at the prompt), the running configuration is
automatically saved as the startup configuration and the chassis reboots. After the reboot, the chassis is
in virtual switch mode, so you must specify interfaces with three identifiers (switch/module/port).

(Optional) Configuring VSS Standby Chassis Modules


After the reboot, each chassis contains the module provisioning for its own slots. In addition, the
modules from the VSS standby chassis have been automatically provisioned on the VSS active chassis
with default configuration.
Configurations for the VSS standby chassis modules are restored to their default settings (for example,
no IP addresses).
You can view the module provisioning information in the configuration file, by entering the show
startup-config command (after you have saved the configuration).

Note Do not delete or modify this section of the configuration file. In Cisco IOS Release 12.2(33)SXI and
later releases, you can no longer add module provisioning entries using the module provision CLI
command. When a module is not present, the provisioning entry for that module can be cleared using the
no slot command with the module provision CLI command. Note that the VSS setup does not support
the module clear-config command.

The following example shows the module provisioning information from a configuration file:
module provision switch 1
slot 1 slot-type 148 port-type 60 number 4 virtual-slot 17
slot 2 slot-type 137 port-type 31 number 16 virtual-slot 18
slot 3 slot-type 227 port-type 60 number 8 virtual-slot 19
slot 4 slot-type 225 port-type 61 number 48 virtual-slot 20
slot 5 slot-type 82 port-type 31 number 2 virtual-slot 21
module provision switch 2
slot 1 slot-type 148 port-type 60 number 4 virtual-slot 33
slot 2 slot-type 227 port-type 60 number 8 virtual-slot 34
slot 3 slot-type 137 port-type 31 number 16 virtual-slot 35
slot 4 slot-type 225 port-type 61 number 48 virtual-slot 36
slot 5 slot-type 82 port-type 31 number 2 virtual-slot 37

Cisco IOS Software Configuration Guide, Release 12.2SX


4-36 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Displaying VSS Information


To display basic information about the VSS, perform one of these tasks:

Command Purpose
Router# show switch virtual Displays the virtual switch domain number, and the
switch number and role for each of the chassis.
Router# show switch virtual role Displays the role, switch number, and priority for
each of the chassis in the VSS.
Router# show switch virtual link Displays the status of the VSL.

The following example shows the information output from these commands:
Router# show switch virtual
Switch mode : Virtual Switch
Virtual switch domain number : 100
Local switch number : 1
Local switch operational role: Virtual Switch Active
Peer switch number : 2
Peer switch operational role : Virtual Switch Standby

Router# show switch virtual role


Switch Switch Status Preempt Priority Role Session ID
Number Oper(Conf) Oper(Conf) Local Remote
------------------------------------------------------------------
LOCAL 1 UP FALSE(N) 100(100) ACTIVE 0 0
REMOTE 2 UP FALSE(N) 100(100) STANDBY 8158 1991

In dual-active recovery mode: No

Router# show switch virtual link


VSL Status: UP
VSL Uptime: 4 hours, 26 minutes
VSL SCP Ping: Pass OK
VSL ICC (Ping): Pass
VSL Control Link: Te 1/5/1

Converting a VSS to Standalone Chassis


To convert a VSS into two standalone chassis, you perform the following major steps:
Copying the VSS Configuration to a Backup File, page 4-38
Converting the VSS Active Chassis to Standalone, page 4-38
Converting the Peer Chassis to Standalone, page 4-38

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-37
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Copying the VSS Configuration to a Backup File


Save the configuration file from the VSS active chassis. You may need this file if you convert to virtual
switch mode again. You only need to save the file from the VSS active chassis, because the configuration
file on the VSS standby chassis is identical to the file on the VSS active chassis.

Command Purpose
Step 1 Switch-1# copy running-config startup-config (Optional) Saves the running configuration to startup
configuration. This step is only required if there are
unsaved changes in the running configuration that
you want to preserve.
Step 2 Switch-1# copy startup-config disk0:vs-startup-config Copies the startup configuration to a backup file.

Converting the VSS Active Chassis to Standalone


When you convert the VSS active chassis to standalone mode, the VSS active chassis removes the
provisioning and configuration information related to VSL links and the peer chassis modules, saves the
configuration file, and performs a reload. The chassis comes up in standalone mode with only the
provisioning and configuration data relevant to the standalone system.
The VSS standby chassis of the VSS becomes VSS active. VSL links on this chassis are down because
the peer is no longer available.
To convert the VSS active chassis to standalone mode, perform this task on the VSS active chassis:

Command Purpose
Switch-1# switch convert mode stand-alone Converts Switch 1 to standalone mode.
After you enter the command, you are prompted to
confirm the action. Enter yes.

Converting the Peer Chassis to Standalone


When you convert the new VSS active chassis to standalone mode, the chassis removes the provisioning
and configuration information related to VSL links and the peer chassis modules, saves the configuration
file and performs a reload. The chassis comes up in standalone mode with only its own provisioning and
configuration data.
To convert the peer chassis to standalone, perform this task on the VSS standby chassis:

Command Purpose
Switch-2# switch convert mode stand-alone Converts Switch 2 to standalone mode.
After you enter the command, you are prompted to
confirm the action. Enter yes.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-38 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Configuring VSS Parameters


These sections describe how to configure VSS parameters:
Configuring VSL Switch Priority, page 4-39
Configuring PFC Mode, page 4-40
Configuring PFC Mode, page 4-40
Configuring a VSL, page 4-41
Displaying VSL Information, page 4-41
Configuring VSL QoS, page 4-42
Subcommands for VSL Port Channels, page 4-43
Subcommands for VSL Ports, page 4-43
Configuring the Router MAC Address Assignment, page 4-44

Configuring VSL Switch Priority


To configure the switch priority, perform this task:

Command Purpose
Step 1 Router(config)# switch virtual domain 100 Enters configuration mode for the virtual switch
domain.
Step 2 Router(config-vs-domain)# switch [1 | 2] priority Configures the priority for the chassis. The switch
[priority_num] with the higher priority assumes the VSS active role.
The range is 1 (lowest priority) to 255 (highest
priority); the default is 100.
Note

The new priority value only takes effect after you


save the configuration and perform a reload of
the VSS.
If the higher priority switch is currently in VSS
standby state, you can make it the VSS active
switch by initiating a switchover. Enter the
redundancy force-switchover command.
The show switch virtual role command displays
the operating priority and the configured priority
for each switch in the VSS.
The no form of the command resets the priority
value to the default priority value of 100. The
new value takes effect after you save the
configuration and perform a reload.
Step 3 Router# show switch virtual role Displays the current priority.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-39
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Note If you make configuration changes to the switch priority, the changes only take effect after you save the
running configuration to the startup configuration file and perform a reload. The show switch virtual
role command shows the operating and priority values. You can manually set the VSS standby switch to
VSS active using the redundancy force-switchover command.

This example shows how to configure virtual switch priority:


Router(config)# switch virtual domain 100
Router(config-vs-domain)# switch 1 priority 200
Router(config-vs-domain)# exit

This example shows how to display priority information for the VSS:
Router# show switch virtual role
Switch Switch Status Preempt Priority Role Session ID
Number Oper(Conf) Oper(Conf) Local Remote
------------------------------------------------------------------
LOCAL 1 UP FALSE(N) 100(200) ACTIVE 0 0
REMOTE 2 UP FALSE(N) 100(100) STANDBY 8158 1991

In dual-active recovery mode: No

Configuring PFC Mode


If you have a mixture of DFC3C and DFC3CXL switching modules in the VSS, set the PFC mode by
performing this task:

Command Purpose
Router(config)# platform hardware vsl pfc mode pfc3c Sets the PFC configuration mode for the VSS to
PFC3C.
Note This command requires a system reload
before it takes effect.
Router# show platform hardware pfc mode Displays the current settings for the PFC mode.

This example shows how to set the PFC configuration mode for the VSS to PFC3C. You can wait until
the next maintenance window to perform the reload command.
Router(config)# platform hardware vsl pfc mode pfc3c
Router(config)# end
Router# reload

If all the supervisor engines and switching modules in the VSS are 3CXL, the following warning is
displayed if you set the PFC mode to PFC3C:
Router(config)# platform hardware vsl pfc mode pfc3c
PFC Preferred Mode: PFC3CXL. The discrepancy between Operating Mode and
Preferred Mode could be due to PFC mode config. Your System has all PFC3XL modules.
Remove ' platform hardware vsl pfc mode pfc3c ' from global config.

This example shows how to display the operating and configured PFC modes:
Router# show platform hardware pfc mode
PFC operating mode : PFC3C
Configured PFC operating mode : PFC3C

Cisco IOS Software Configuration Guide, Release 12.2SX


4-40 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Configuring a VSL
To configure a port channel to be a VSL, perform this task:

Command Purpose
Step 1 Router(config)# interface port-channel channel_num Enters configuration mode for the specified port
channel.
Step 2 Router(config-if)# switch virtual link switch_num Assigns the port channel to the virtual link for the
specified switch.

Note We recommend that you configure the VSL prior to converting the chassis into a VSS.

This example shows how to configure the VSL:


Switch-1(config)# interface port-channel 10
Switch-1(config-if)# switch virtual link 1
Switch-1(config-if)# no shutdown
Switch-1(config)# interface tenGigabitEthernet 5/1
Switch-1(config-if)# channel-group 10 mode on
Switch-1(config-if)# no shutdown

Switch-2(config)# interface port-channel 25


Switch-2(config-if)# switch virtual link 2
Switch-2(config-if)# no shutdown
Switch-2(config-if)# interface tenGigabitEthernet 5/2
Switch-2(config-if)# channel-group 25 mode on
Switch-2(config-if)# no shutdown

Displaying VSL Information


To display information about the VSL, perform one of these tasks:

Command Purpose
Router# show switch virtual link Displays information about the VSL.
Router# show switch virtual link port-channel Displays information about the VSL port channel.
Router# show switch virtual link port Displays information about the VSL ports.

This example shows how to display VSL information:


Router# show switch virtual link
VSL Status : UP
VSL Uptime : 1 day, 3 hours, 39 minutes
VSL SCP Ping : Pass
VSL ICC Ping : Pass
VSL Control Link : Te 1/5/1

Router# show switch virtual link port-channel


VSL Port Channel Information

Flags: D - down P - bundled in port-channel


I - stand-alone s - suspended
H - Hot-standby (LACP only)

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-41
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

R - Layer3 S - Layer2
U - in use N - not in use, no aggregation
f - failed to allocate aggregator

M - not in use, no aggregation due to minimum links not met


m - not in use, port not aggregated due to minimum links not met
u - unsuitable for bundling
w - waiting to be aggregated

Group Port-channel Protocol Ports


------+-------------+-----------+---------------------------------------------
10 Po10(RU) - Te1/5/4(P) Te1/5/5(P)
20 Po20(RU) - Te2/5/4(P) Te2/5/5(P)

Router# show switch virtual link port


VSL Link Info : Configured: 2 Operational: 1

Peer Peer Peer


Interface State MAC Switch Interface
-----------------------------------------------------------------------
Te1/5/4 operational 0013.5fcb.1480 2 Te2/5/4
Te1/5/5 link_down - - -

Last operational Current packet Last Diag Time since


Interface Failure state State Result Last Diag
-------------------------------------------------------------------------------
Te1/5/4 No failure Hello bidir Never ran 7M:51S
Te1/5/5 No failure No failure Never ran 7M:51S

Hello Tx (T4) ms Hello Rx (T5*) ms


Interface State Cfg Cur Rem Cfg Cur Rem
----------------------------------------------------------------------
Te1/5/4 operational 500 500 404 5000 5000 4916
Te1/5/5 link_down 500 - - 500000 - -
Te2/5/4 operational 500 500 404 500000 500000 499916
Te2/5/5 link_down 500 - - 500000 - -
*T5 = min_rx * multiplier

Configuring VSL QoS


The VSS automatically configures VSL ports for trust CoS, using default CoS mappings (you cannot
change the mappings on VSL ports).
For switching modules that support per-ASIC configuration, the VSL configuration applies to all ports
on the same ASIC (including any non-VSL ports).
The VSS disables the QoS commands on VSL ports (and any non-VSL ports on the same ASIC). For
example, you cannot use QoS queuing or map commands on VSL ports.
To ensure that all eight QoS receive queues are enabled for the 10-Gigabit Ethernet ports on the
supervisor engine, enter the mls qos 10g-only global configuration command.
In Cisco IOS Release 12.2(33)SXI and later releases, when the mls qos 10g-only command is entered
and only one of the two 10-Gigabit Ethernet ports on the supervisor engine is a VSL port, the non-VSL
10-Gigabit Ethernet port can be configured for QoS.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-42 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Subcommands for VSL Port Channels


On a VSL port channel, only a subset of interface subcommands are available in the command console.
Table 4-2 describes the available interface subcommands.

Table 4-2 Interface Subcommands for VSL Port Channels

Subcommand Description
default Sets a command to its defaults.
description Enters a text description for the interface.
exit Exits from interface configuration mode.
load-interval Specifies interval for load calculation for an
interface.
logging Configures logging for interface.
mls Specifies multilayer switching subcommands.
no Disables a command, or sets the command
defaults.
shutdown Shuts down the selected interface.
switch virtual link Specifies the switch associated with this port
channel.
vslp Specifies VSLP interface configuration
commands.

Subcommands for VSL Ports


If a port is included in a VSL port channel, only a subset of interface subcommands are available in the
command console. Table 4-3 describes the available interface subcommands.

Table 4-3 Interface Subcommands for VSL Ports

Subcommand Description
channel-group Adds the interface to the specified channel group.
default Sets a command to its defaults.
description Adds a description to the interface.
exit Exits from interface configuration mode.
load-interval Specifies interval for load calculation for an
interface.
logging Configures logging for the interface.
no Disables a command, or sets the command
defaults.
shutdown Shuts down the selected interface.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-43
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Configuring the Router MAC Address Assignment


When the VSS is started for the first time, the initial VSS active supervisor engine assigns a router MAC
address for the VSS. By default, the supervisor engine assigns a MAC address from its own chassis.
After a switchover to the second chassis, the VSS continues to use the MAC address from the previously
VSS active chassis as the router MAC address.
In the rare case where both chassis later become inactive, and then they start up with the second
supervisor engine becoming the initial VSS active supervisor engine, the VSS will start up with a router
MAC address from the second chassis. Other Layer 2 hosts that do not respond to GARP and are not
directly connected to the VSS will retain the earlier router MAC address of the VSS, and will not be able
to communicate with the VSS. To avoid this possibility, you can configure the VSS to assign a router
MAC address from a reserved pool of addresses with the domain ID encoded in the last octet of the MAC
address, or you can specify a MAC address.

Note If you change the router MAC address, you must reload the virtual switch for the new router MAC
address to take effect.

To specify that the router MAC address is assigned from a reserved pool of domain-based addresses,
perform this task:

Command Purpose
Step 1 Router(config)# switch virtual domain domain_id Enters VSS configuration mode.
Step 2 Router(config-vs-domain)# mac-address use-virtual The router MAC address is assigned from a reserved
pool of domain-based addresses.
Note The no form of this command reverts to the
default setting, using a MAC address from
the backplane of the initial VSS active
chassis.

To specify a router MAC address, perform this task:

Command Purpose
Step 1 Router(config)# switch virtual domain domain_id Enters VSS configuration mode.
Step 2 Router(config-vs-domain)# mac-address mac-address The router MAC address is specified in three 2-byte
hexadecimal numbers.

This example shows how to configure router MAC address assignment from a reserved pool of
domain-based addresses:
Router(config)# switch virtual domain 255
Router(config-vs-domain)# mac-address use-virtual

The following example shows how to specify the router MAC address in hexadecimal format:
Router(config)# switch virtual domain 255
Router(config-vs-domain)# mac-address 0123.4567.89ab

Cisco IOS Software Configuration Guide, Release 12.2SX


4-44 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Configuring Deferred Port Activation During VSS Standby Recovery


Instead of allowing all ports to be activated simultaneously when a failed chassis is restarted as the VSS
standby chassis, you can configure the system to defer activation of non-VSL ports and then activate the
ports in groups over a period of time.
To specify deferred port activation, perform this task:

Command Purpose
Step 1 Router(config)# switch virtual domain 1 Enters VSS configuration mode.
Step 2 Router(config-vs-domain)# standby port delay Specifies that the port activation will be initially
delay-time deferred and then performed in cycles.
For delay-time, specify the period in seconds before
port activation will begin. The range is 30 to 3600.
Step 3 Router(config-vs-domain)# standby port bringup number Specifies the number of ports to be activated per
cycle-time cycle and the waiting time between cycles.
For number, specify the number of ports to be
activated per cycle. The range is 1 to 100. The default
value is 1 port.
For cycle-time, specify the period in seconds
between cycles. The range is 1 to 10. The default
value is 1 second.

This example shows how to configure port activation to be deferred by 120 seconds, then activated in
groups of 20 ports every 5 seconds:
Router(config)# switch virtual domain 1
Router(config-vs-domain)# standby port delay 120
Router(config-vs-domain)# standby port bringup 20 5

Configuring Multichassis EtherChannels


Configure multichassis EtherChannels (MECs) as you would for a regular EtherChannel. The VSS will
recognize that the EtherChannel is an MEC when ports from both chassis are added to the EtherChannel.
You can verify the MEC configuration by entering the show etherchannel command.
One VSS supports a maximum of 512 port channels.

Note Releases earlier than Cisco IOS Release 12.2(33)SXI support a maximum of 128 port channels.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-45
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

The Configuring Port Load Share Deferral on the Peer Switch section provides additional details about
MECs:

Configuring Port Load Share Deferral on the Peer Switch


To configure the load share deferral feature for a port channel, perform this task on the switch that is an
MEC peer to the VSS:

Command Purpose
Step 1 Router(config)# port-channel load-defer seconds (Optional) Configures the port load share deferral
interval for all port channels.
secondsThe time interval during which load
sharing is initially 0 for deferred port channels. The
range is 1 to 1800 seconds; the default is 120
seconds.
Step 2 Router(config)# interface port-channel Enters interface configuration mode for the port channel.
channel-num
Step 3 Router(config-if)# port-channel port load-defer Enables port load share deferral on the port channel.

This example shows how to configure the load share deferral feature on port channel 10 of the switch
that is an MEC peer to the VSS:
Router(config)# port-channel load-defer 60
Router(config)# interface port-channel 10
Router(config-if)# port-channel port load-defer
This will enable the load share deferral feature on this port-channel.
Do you wish to proceed? [yes/no]: yes

Configuring Dual-Active Detection


The following sections describe how to configure dual-active detection:
Configuring Enhanced PAgP Dual-Active Detection, page 4-46
Configuring BFD Dual-Active Detection, page 4-48
Configuring Fast Hello Dual-Active Detection, page 4-49
Configuring the Exclusion List, page 4-50
Displaying Dual-Active Detection, page 4-50

Configuring Enhanced PAgP Dual-Active Detection


If enhanced PAgP is running on the MECs between the VSS and its access switches, the VSS can use
enhanced PAgP messaging to detect a dual-active scenario.
By default, PAgP dual-active detection is enabled. However, the enhanced messages are only sent on port
channels with trust mode enabled (see the trust mode description in the note).

Cisco IOS Software Configuration Guide, Release 12.2SX


4-46 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Note Before changing PAgP dual-active detection configuration, ensure that all port channels with trust mode
enabled are in administrative down state. Use the shutdown command in interface configuration mode
for the port channel. Remember to use the no shutdown command to reactivate the port channel when
you are finished configuring dual-active detection.

To enable or disable PAgP dual-active detection, perform this task:

Command Purpose
Step 1 Router(config)# switch virtual domain domain_id Enters virtual switch submode.
Step 2 Router(config-vs-domain)# dual-active detection pagp Enables sending of the enhanced PAgP messages.

You must configure trust mode on the port channels that will detect PAgP dual-active detection. By
default, trust mode is disabled.

Note If PAgP dual-active detection is enabled, you must place the port channel in administrative down state
before changing the trust mode. Use the shutdown command in interface configuration mode for the port
channel. Remember to use the no shutdown command to reactivate the port channels when you are
finished configuring trust mode on the port channel.

To configure trust mode on a port channel, perform this task:

Command Purpose
Step 1 Router(config)# switch virtual domain domain_id Enters virtual switch submode.
Step 2 Router(config-vs-domain)# dual-active detection pagp Enables trust mode for the specified port channel.
trust channel-group group_number

This example shows how to enable PAgP dual-active detection:


Router(config)# interface port-channel 20
Router(config-if)# shutdown
Router(config-if)# exit
Router(config)# switch virtual domain 100
Router(config-vs-domain)# dual-active detection pagp
Router(config-vs-domain)# dual-active detection pagp trust channel-group 20
Router(config-vs-domain)# exit
Router(config)# interface port-channel 20
Router(config-if)# no shutdown
Router(config-if)# exit

This example shows the error message if you try to enable PAgP dual-active detection when a trusted
port channel is not shut down first:
Router(config)# switch virtual domain 100
Router(config-vs-domain)# dual-active detection pagp
Trusted port-channel 20 is not administratively down.
To change the pagp dual-active configuration, shutdown these port-channels first.
Remember to no shutdown these port-channels afterwards.

This example shows the error message if you try to configure trust mode for a port channel that is not
shut down first:
Router(config)# switch virtual domain 100

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-47
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Router(config-vs-domain)# dual-active detection pagp trust channel-group 20


Trusted port-channel 20 is not administratively down. To change the pagp dual-active trust
configuration, shutdown the port-channel first. Remember to no shutdown the
port-channel afterwards.

Configuring BFD Dual-Active Detection


For the BFD dual-active detection, you must configure dual-active interface pairs that will act as BFD
messaging links. By default, BFD detection is enabled.
To configure BFD dual-active detection, perform this task:

Command Purpose
Step 1 Router(config)# switch virtual domain domain_id Enters virtual switch submode.
Step 2 Router(config-vs-domain)# dual-active detection bfd Enables BFD dual-active detection method. By
default, BFD detection is enabled.
Step 3 Router(config-vs-domain)# dual-active pair interface Configures the dual-active pair of interfaces. The
int_1 interface int_2 bfd interfaces int_1 and int_2 are of the form
type1 switch/slot/port.

The interfaces must be directly connected (a single


Layer 3 hop).
1. type = fastethernet, gigabitethernet, or tengigabitethernet

When you configure the dual-active interface pairs, note the following information:
The individual ports must be configured first with both an IP address and BFD configuration. The
configuration is validated when you add the dual-active interface pair.
The IP addresses assigned to the dual-active pair must be from two different networks or
subnetworks.
The BFD timers must be configured with the same values on the ports at both ends of the link to
ensure proper operation of Layer 3 BFD dual-active detection.
The MAC address cannot be specified on the interface.

Note We recommend that you configure a short BFD interval and small multiplier value (such as 50 to 100 ms
for the interval and 3 as the multiplier value). If the interval and multiplier values are large, there is a
long delay before the system initiates dual-active mode recovery. This condition can cause network
instability and poor convergence.

This example shows how to configure interfaces for BFD dual-active detection:
Router (config)# interface gigabitethernet 1/9/48
Router (config-if)# no switchport
Router (config-if)# ip address 200.230.230.231 255.255.255.0
Router (config-if)# bfd interval 100 min_rx 100 multiplier 3
Router (config-if)# no shutdown
Router (config-if)# interface gigabitethernet 2/1/48
Router (config-if)# no switchport
Router (config-if)# ip address 201.230.230.231 255.255.255.0
Router (config-if)# bfd interval 100 min_rx 100 multiplier 3
Router (config-if)# no shutdown
Router (config-if)# exit
Router (config)# switch virtual domain 100

Cisco IOS Software Configuration Guide, Release 12.2SX


4-48 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Router (config-vs-domain)# dual-active detection bfd


Router (config-vs-domain)# dual-active pair interface g 1/9/48 interface g 2/1/48 bfd

adding a static route 200.230.230.0 255.255.255.0 Gi2/1/48 for this dual-active pair
adding a static route 201.230.230.0 255.255.255.0 Gi1/9/48 for this dual-active pair
Router(config-vs-domain)# exit
Router(config)# exit
Router# show switch virtual dual-active bfd
Bfd dual-active detection enabled: Yes
Bfd dual-active interface pairs configured:
interface1 Gi1/9/48 interface2 Gi2/1/48

Configuring Fast Hello Dual-Active Detection


Fast hello dual-active detection is enabled by default; however, you must configure dual-active interface
pairs to act as fast hello dual-active messaging links.
To configure fast hello dual-active detection, perform this task:

Command Purpose
Step 1 Router(config)# switch virtual domain domain_id Enters the virtual switch submode.
Step 2 Router(config-vs-domain)# dual-active detection Enables the fast hello dual-active detection method.
fast-hello Fast hello dual-active detection is enabled by default.
Step 3 Router(config-vs-domain)# exit Exits virtual switch submode.
1
Step 4 Router(config)# interface type switch/slot/port Selects the interface to configure. This interface must
be directly connected to the other chassis and must
not be a VSL link.
Step 5 Router(config-if)# dual-active fast-hello Enables fast hello dual-active detection on the
interface, automatically removes all other
configuration from the interface, and restricts the
interface to dual-active configuration commands.
Step 6 Router(config-if)# no shutdown Activates the interface.
1. type = fastethernet, gigabitethernet, or tengigabitethernet

When you configure fast hello dual-active interface pairs, note the following information:
You can configure a maximum of four interfaces on each chassis to connect with the other chassis
in dual-active interface pairs.
Each interface must be directly connected to the other chassis and must not be a VSL link. We
recommend using links from a switching module not used by the VSL.
Each interface must be a physical port. Logical ports such as an SVI are not supported.
Configuring fast hello dual-active mode will automatically remove all existing configuration from
the interface and will restrict the interface to fast hello dual-active configuration commands.
Unidirectional link detection (UDLD) will be disabled on fast hello dual-active interface pairs.
This example shows how to configure an interface for fast hello dual-active detection:
Router(config)# switch virtual domain 255
Router(config-vs-domain)# dual-active detection fast-hello
Router(config-vs-domain)# exit
Router(config)# interface fastethernet 1/2/40

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-49
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Router(config-if)# dual-active fast-hello


WARNING: Interface FastEthernet1/2/40 placed in restricted config mode. All extraneous
configs removed!

Router(config-if)# no shutdown
Router(config-if)# exit
Router(config)# exit
Router# show run interface fastethernet 1/2/40
interface FastEthernet1/2/40
no switchport
no ip address
dual-active fast-hello
end

Configuring the Exclusion List


When a dual-active scenario is detected, part of the recovery action is for the chassis to shut down all of
its non-VSL interfaces. You can specify one or more interfaces to be excluded from this action (for
example, to exclude the interface you use for remote access to the chassis).
To specify interfaces that are not to be shut down by dual-active recovery, perform this task:

Command Purpose
Step 1 Router(config)# switch virtual domain domain_id Enters virtual switch submode.
Step 2 Router(config-vs-domain)# dual-active exclude Specifies an interface to exclude from shutting down
interface type1 switch/slot/port in dual-active recovery.
1. type = fastethernet, gigabitethernet, or tengigabitethernet

When you configure the exclusion list, note the following information:
The interface must be a physical port configured with an IP address.
The interface must not be a VSL port.
The interface must not be in use for IP BFD dual-active detection.
The interface must not be in use for fast hello dual-active detection.
This example shows how to configure an interface as an exclusion:
Router(config)# switch virtual domain 100
Router (config-vs-domain)# dual-active exclude interface gigabitethernet 1/5/5

Displaying Dual-Active Detection


To display information about dual-active detection, perform this task:

Command Purpose
Router# show switch virtual dual-active [bfd | pagp Displays information about dual-active detection
| fast-hello | summary] configuration and status.

This example shows how to display the summary status for dual-active detection:
Router# show switch virtual dual-active summary
Pagp dual-active detection enabled: Yes

Cisco IOS Software Configuration Guide, Release 12.2SX


4-50 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Bfd dual-active detection enabled: Yes


Fast-hello dual-active detection enabled: Yes

No interfaces excluded from shutdown in recovery mode


In dual-active recovery mode: No
This example shows how to display information for BFD dual-active detection:
Router# show switch virtual dual-active bfd
Bfd dual-active detection enabled: Yes
Bfd dual-active interface pairs configured:
interface1 Gi1/9/48 interface2 Gi2/1/48

This example shows how to display information for fast-hello dual-active detection:
Router# show switch virtual dual-active fast-hello
Fast-hello dual-active detection enabled: Yes

Fast-hello dual-active interfaces:


Port State (local only)
-----------------------------
Gi1/4/47 Link dn
Gi2/4/47 -

This example shows how to display PAgP status and the channel groups with trust mode enabled:
Router# show pagp dual-active
PAgP dual-active detection enabled: Yes
PAgP dual-active version: 1.1

Channel group 3 dual-active detect capability w/nbrs Dual-Active trusted group: No


Dual-Active Partner Partner Partner
Port Detect Capable Name Port Version
Fa1/2/33 No None None N/A

Channel group 4
Dual-Active trusted group: Yes
No interfaces configured in the channel group

Channel group 5
Dual-Active trusted group: Yes
Channel group 5 is not participating in PAGP

Channel group 10 dual-active detect capability w/nbrs Dual-Active trusted group: Yes
Dual-Active Partner Partner Partner
Port Detect Capable Name Port Version
Gi1/6/1 Yes partner-1 Gi1/5/1 1.1
Gi2/5/1 Yes partner-1 Gi1/5/2 1.1

Channel group 11 dual-active detect capability w/nbrs Dual-Active trusted group: No


Dual-Active Partner Partner Partner
Port Detect Capable Name Port Version
Gi1/6/2 Yes partner-1 Gi1/3/1 1.1
Gi2/5/2 Yes partner-1 Gi1/3/2 1.1

Channel group 12 dual-active detect capability w/nbrs Dual-Active trusted group: Yes
Dual-Active Partner Partner Partner
Port Detect Capable Name Port Version
Fa1/2/13 Yes partner-1 Fa1/2/13 1.1
Fa1/2/14 Yes partner-1 Fa1/2/14 1.1
Gi2/1/15 Yes partner-1 Fa1/2/15 1.1
Gi2/1/16 Yes partner-1 Fa1/2/16 1.1

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-51
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Note The show switch virtual dual-active pagp command displays the same output as the show pagp
dual-active command.

Configuring Service Modules in a VSS


To configure a service module in a VSS, you must add the switch number to many of the configuration
commands, as described in this section.

Note For detailed instructions on configuring a service module in a VSS, see the configuration guide and
command reference for the service module.

The following sections provide examples of how to configure a service module in a VSS:
Opening a Session with a Service Module in a VSS, page 4-52
Assigning a VLAN Group to a Firewall Service Module in a VSS, page 4-53
Assigning a VLAN Group to an ACE Service Module in a VSS, page 4-53
Verifying Injected Routes in a Service Module in a VSS, page 4-54

Opening a Session with a Service Module in a VSS


To configure service modules that require opening a session, perform this task:

Command Purpose
Router# session switch num slot slot processor Opens a session with the specified module.
processor-id
numSpecifies the switch to access; valid values are 1
and 2.
slotSpecifies the slot number of the module.
processor-idSpecifies the processor ID number.
Range: 0 to 9.

This example shows how to open a session to a Firewall Service Module in a VSS:
Router# session switch 1 slot 4 processor 1
The default escape character is Ctrl-^, then x.
You can also type 'exit' at the remote prompt to end the session
Trying 127.0.0.41 ... Open

Cisco IOS Software Configuration Guide, Release 12.2SX


4-52 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Assigning a VLAN Group to a Firewall Service Module in a VSS


To assign a VLAN group to a FWSM, perform this task:

Command Purpose
Router(config)# firewall switch num slot slot Assigns VLANs to a firewall group in the specified module.
vlan-group [vlan_group | vlan_range]
numSpecifies the switch to access; valid values are 1
and 2.
slotSpecifies the slot number of the module.
vlan_groupSpecifies the group ID as an integer.
vlan_rangeSpecifies the VLANs assigned to the
group.

This example shows how to assign a VLAN group to a Firewall Service Module in a VSS:
Router(config)# firewall switch 1 slot 4 vlan-group 100,200

Assigning a VLAN Group to an ACE Service Module in a VSS


To assign a VLAN group to an ACE, perform this task:

Command Purpose
Step 1 Router(config)# svclc multiple-vlan-interfaces Enables multiple VLAN interfaces mode for service
modules.
Step 2 Router(config)# svclc switch num slot slot Assign VLANs to a firewall group in the specified module.
vlan-group [vlan_group | vlan_range]
numSpecifies the switch to access; valid values are 1
and 2.
slotSpecifies the slot number of the module.
vlan_groupSpecifies the group ID as an integer.
vlan_rangeSpecifies the VLANs assigned to the
group.

This example shows how to assign multiple VLAN groups to an ACE service module in a VSS:
Router(config)# svclc multiple-vlan-interfaces
Router(config)# svclc switch 1 slot 4 vlan-group 100,200

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-53
Chapter 4 Configuring Virtual Switching Systems
Configuring a VSS

Verifying Injected Routes in a Service Module in a VSS


To view route health injection (RHI) routes, perform this task:

Command Purpose
Router# show svclc rhi-routes switch num slot slot Displays injected RHI routes in the specified service
module.
numSpecifies the switch to access; valid values
are 1 and 2.
slotSpecifies the slot number of the module.

This example shows how to view injected routes in a service module in a VSS:
Router# show svclc rhi-routes switch 1 slot 4
RHI routes added by slot 34
ip mask nexthop vlan weight tableid
--------------- --------------- --------------- ------ ------ -------
A 23.1.1.4 255.255.255.252 20.1.1.1 20 1 0

Viewing Chassis Status and Module Information in a VSS


To view chassis status and information about modules installed in either or both chassis of a VSS,
perform the following task:

Command Purpose
Router# show module switch { 1 | 2 | all } Displays information about modules in the specified chassis
(1 or 2), or in both chassis (all).

This example shows how to view the chassis status and module information for chassis number 1 of a
VSS:
Router# show module switch 1
Switch Number: 1 Role: Virtual Switch Active
---------------------- -----------------------------
Mod Ports Card Type Model Serial No.
--- ----- -------------------------------------- ------------------ -----------
1 48 CEF720 48 port 10/100/1000mb Ethernet WS-X6748-GE-TX SAL1215M2YA
2 8 CEF720 8 port 10GE with DFC WS-X6708-10GE SAL1215M55F
3 1 Application Control Engine Module ACE20-MOD-K9 SAD120603SU
.
.
.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-54 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

Upgrading a VSS
Cisco IOS Rel ease 12.2(33)SXH supports a fast software upgrade (FSU) of the VSS using RPR.
Cisco IOS Release 12.2(33)SXI and later releases support an enhanced fast software upgrade (eFSU) of
the VSS using SSO.
This section describes both types of VSS upgrade:
Performing a Fast Software Upgrade of a VSS, page 4-55
Performing an Enhanced Fast Software Upgrade of a VSS, page 4-56

Performing a Fast Software Upgrade of a VSS


The FSU of a VSS is similar to the RPR-based standalone chassis FSU described in the Performing a
Fast Software Upgrade section on page 7-6. While the standalone chassis upgrade is initiated by
reloading the VSS standby supervisor engine, the VSS upgrade is initiated by reloading the VSS standby
chassis. During the FSU procedure, a software version mismatch between the VSS active and the VSS
standby chassis causes the system to boot in RPR redundancy mode, which is stateless and causes a hard
reset of the all modules. As a result, the FSU procedure requires system downtime corresponding to the
RPR switchover time.

Note VSS mode supports only one supervisor engine in each chassis. If another supervisor engine resides in
the chassis it will act as the DFC.

To perform an FSU of a VSS, perform this task:

Command Purpose
Step 1 Router# copy tftp disk_name Uses TFTP to copy the new software image to flash
memory on the VSS active and VSS standby chassis
(disk0: and slavedisk0:). Answer the prompts to identify
the name and location of the new software image.
Step 2 Router# config terminal Enters global configuration mode.
Step 3 Router(config)# no boot system Removes any previously assigned boot variables.
Step 4 Router(config)# config-register 0x2102 Sets the configuration register.
Step 5 Router(config)# boot system flash device:file_name Configures the chassis to boot the new image.
Step 6 Router(config)# end Returns to privileged EXEC mode.
Step 7 Router# copy running-config startup-config Saves the configuration.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-55
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

Command Purpose
Step 8 Router# redundancy reload peer Reloads the VSS standby chassis and brings it back
online running the new version of the Cisco IOS
software. Due to the software version mismatch between
the two chassis, the VSS standby chassis will be in RPR
redundancy mode.
Note Before reloading the VSS standby chassis, make
sure you wait long enough to ensure that all
configuration synchronization changes have
completed.
Step 9 Router# redundancy force-switchover Forces the VSS standby chassis to assume the role of the
VSS active chassis running the new Cisco IOS image.
The modules are reloaded and the module software is
downloaded from the new VSS active chassis.
The old VSS active chassis reboots with the new image
and becomes the VSS standby chassis.

This example shows how to perform an FSU:


Router# config terminal
Router(config)# no boot system
Router(config)# config-register 0x2102
Router(config)# boot system flash disk0:image_name
Router(config)# end
Router# copy running-config startup-config
Router# redundancy reload peer
Router# redundancy force-switchover

Performing an Enhanced Fast Software Upgrade of a VSS


An eFSU uses the same commands and software infrastructure as an in-service software upgrade (ISSU).
The eFSU differs from an ISSU in that it resets the modules, which results in a brief traffic interruption.
The eFSU sequence for a VSS follows the same logical steps as the single-chassis eFSU described in the
Performing an Enhanced Fast Software Upgrade section on page 5-5, but the procedure applies to the
VSS active and VSS standby supervisor engine in each chassis, instead of two supervisor engines in one
chassis. During an eFSU, the VSS standby chassis, including the supervisor engine and modules, is
upgraded and brought up in a stateful switchover (SSO) mode. The eFSU process then forces a
switchover and performs the same upgrade on the other chassis, which becomes the new VSS standby.

Note VSS mode supports only one supervisor engine in each chassis. If another supervisor resides in the
chassis it will act as the DFC.

This section contains the following topics:


eFSU Restrictions and Guidelines, page 4-57
eFSU Stages for a VSS Upgrade, page 4-58
Configuring and Performing an eFSU Upgrade, page 4-59
eFSU Upgrade Example, page 4-67

Cisco IOS Software Configuration Guide, Release 12.2SX


4-56 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

eFSU Restrictions and Guidelines


When performing an eFSU, note the following guidelines and restrictions:
An eFSU can install a full image upgrade or a patch upgrade. Any patch upgrade will be installed
by the same process as a full image upgrade, regardless of whether the patch requires a reload or a
process restart.
The new image file must reside in the file system of the supervisor engine in each chassis before the
eFSU can be initiated. The issu commands will accept only global file system names (for example,
disk0: or sup-bootdisk:). The issu commands will not accept switch number-specific file system
names (for example, sw1-slot5-disk0:).
When preparing for the eFSU, do not change the boot variable. Although a boot variable change is
required in the FSU (RPR) procedure, changing the boot variable in the eFSU procedure will cause
the CurrentVersion variable to be inconsistent, preventing execution of the eFSU.
The issu commands for a VSS eFSU upgrade are similar to those for a single-chassis (standalone)
eFSU, as described in the Performing an Enhanced Fast Software Upgrade section on page 5-5,
with the following differences:
Where the standalone issu commands accept an argument of slot number, the VSS issu
commands accept a switch and slot number, in the format of switch/slot (for example, 1/5 refers
to switch 1, slot 5).
For a normal VSS eFSU, it is not necessary to specify a switch or slot number when entering
the VSS issu commands.
You cannot change the rollback timer period during the eFSU process.
During the eFSU process, do not perform any manual switchover other than those caused by the issu
commands.
During the eFSU process, do not perform an online insertion or removal (OIR) of any module.
During an eFSU downgrade, if the process is aborted (either due to an MCL error or by entering the
abortversion command) just after executing the loadversion command, the SSO VSS standby is
reloaded with the original image but the SSO VSS standbys ICS is not because the bootvar of the
SSO VSS standbys ICS is not modified during an abort executed after the loadversion command.
Images with different feature sets fail the eFSU compatibility check, regardless of the software
release.
The eFSU feature does not support upgrades or downgrades between modular and non-modular IOS
versions.
The eFSU feature does not support upgrades or downgrades between installed and binary modes of
modular IOS. The Installed mode was removed after Cisco IOS Release 12.2(33)SXI3.
Before you start a downgrade with eFSU (reverting to an earlier version of Cisco IOS software),
remove configurations and disable any features or functions that are not supported in the earlier
version. Otherwise the configuration files fail to synchronize and the standby supervisor engine
reloads.
The eFSU upgrade feature works with NSF/SSO. Software features that do not support NSF/SSO
stop operating until after the software upgrade switchover, when they come back online.
Images with release dates more than 18 months apart are not supported for eFSU. See the
SX_SY_EFSU_Compatibility_Matrix to verify compatibility.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-57
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

eFSU Stages for a VSS Upgrade


The eFSU sequence consists of several stages, each explicitly initiated by entering a specific issu
command in the CLI. At each stage, you can verify the system status or roll back the upgrade before
moving to the next stage.
The following sections describe the eFSU stages for a VSS upgrade:
Preparation, page 4-58
Loadversion Stage, page 4-58
Runversion Stage, page 4-58
Acceptversion Stage (Optional), page 4-58
Commitversion Stage, page 4-59
Abortversion (Optional), page 4-59

Preparation

Before you can initiate the eFSU process, the upgrade image must reside in the file system of the
supervisor engine in each chassis; otherwise, the initial command will be rejected. The VSS must be in
a stable operating state with one chassis in the VSS active state and the other chassis in the hot VSS
standby state.

Loadversion Stage

The eFSU process begins when you enter the issu loadversion command specifying the location in
memory of the new upgrade images on the VSS active and VSS standby chassis. Although the issu
loadversion command allows you to specify the switch and slot number of the VSS active and VSS
standby chassis, it is not necessary to do so. When you enter the issu loadversion command, the entire
VSS standby chassis, including the supervisor engine and modules, is reloaded with the new upgrade
image. Because the VSS standby chassis modules are unavailable while reloading, the throughput of the
VSS is temporarily reduced by 50 percent during this stage. After reloading, the VSS standby chassis
boots with the new image and initializes in SSO mode, restoring traffic throughput. In this state, the VSS
standby chassis runs a different software version than the VSS active chassis, which requires the VSS
active chassis to communicate with modules running different image versions between the two chassis.

Runversion Stage

When the VSS standby chassis is successfully running the new image in SSO mode, you can enter the
issu runversion command. This command forces a switchover in which the upgraded VSS standby
chassis takes over as the new VSS active chassis. The formerly VSS active chassis reloads and initializes
as the new VSS standby chassis in SSO mode, running the old image. As in the loadversion stage, the
throughput of the VSS is temporarily reduced during the VSS standby chassis reload, and the VSS
standby chassis runs a different software version than the VSS active chassis.

Acceptversion Stage (Optional)

When you enter the issu runversion command, a switchover to the chassis running the new image
occurs, which starts an automatic rollback timer as a safeguard to ensure that the upgrade process does
not cause the VSS to be nonoperational. Before the rollback timer expires, you must either accept or
commit the new software image. If the timer expires, the upgraded chassis reloads and reverts to the

Cisco IOS Software Configuration Guide, Release 12.2SX


4-58 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

previous software version. To stop the rollback timer, enter the issu acceptversion command. Prior to
starting the eFSU process, you can disable the rollback timer or configure it to a value up to two hours
(the default is 45 minutes).
Operating with an upgraded VSS active chassis, this stage allows you to examine the functionality of the
new software image. When you are satisfied that the new image is acceptable, enter the issu
commitversion command to complete the upgrade process.

Commitversion Stage

To apply the upgrade image to the second chassis, completing the eFSU, enter the issu commitversion
command. The VSS standby chassis is reloaded and booted with the new upgrade image, initializing
again as the VSS standby chassis. As in the loadversion stage, the throughput of the VSS is temporarily
reduced while the modules are reloaded and initialized. After the successful reload and reboot of the VSS
standby chassis, the VSS upgrade process is complete.

Abortversion (Optional)

At any time before you enter the issu commitversion command, you can roll back the upgrade by
entering the issu abortversion command. The upgrade process also aborts automatically if the software
detects a failure. The rollback process depends on the current state. If the eFSU is aborted before you
enter the issu runversion command, the VSS standby chassis is reloaded with the old image. If the eFSU
is aborted after the issu runversion command, a switchover is executed. The VSS standby chassis,
running the old image, becomes the VSS active chassis. The formerly VSS active chassis is then reloaded
with the old image, completing the rollback.

Configuring and Performing an eFSU Upgrade


The following sections describe how to configure and perform an eFSU upgrade:
Changing the eFSU Rollback Timer, page 4-60
Performing an eFSU Upgrade, page 4-60
Performing an eFSU Upgrade from Previous Cisco IOS Releases to Cisco IOS Release
12.2(33)SXI4, page 4-61
Performing an eFSU Upgrade from Cisco IOS Release 12.2(33)SXI4 to Future Cisco IOS Releases,
page 4-62
Performing an eFSU Downgrade from Cisco IOS Release 12.2(33)SXI4 to Earlier Cisco IOS
Releases, page 4-63
Performing an eFSU Downgrade from a Future Cisco IOS Release to Cisco IOS Release
12.2(33)SXI4, page 4-65
Performing an eFSU Upgrade on an Installed Modular Image, page 4-66
Aborting an eFSU Upgrade, page 4-67

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-59
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

Changing the eFSU Rollback Timer

To view or change the eFSU rollback timer, perform the following task before beginning an upgrade:

Command Purpose
Step 1 Router# config terminal Enters configuration mode.
Step 2 Router(config)# issu set rollback-timer (Optional) Sets the rollback timer to ensure that the upgrade
{seconds | hh:mm:ss} process does not leave the VSS nonoperational. If the timer
expires, the software image reverts to the previous software
image. To stop the timer, you must either accept or commit
the new software image.
The timer duration can be set with one number (seconds),
indicating the number of seconds, or as hours, minutes, and
seconds with a colon as the delimiter (hh:mm:ss). The range
is 0 to 7200 seconds (2 hours); the default is 2700 seconds
(45 minutes). A setting of 0 disables the rollback timer.
Step 3 Router(config)# exit Returns to privileged EXEC mode.
Step 4 Router# show issu rollback timer Displays the current rollback timer value.

This example shows how to set the eFSU rollback timer to one hour using both command formats:
Router# config terminal
Router(config)# issu set rollback-timer 3600
% Rollback timer value set to [ 3600 ] seconds
Router(config)# issu set rollback-timer 01:00:00
% Rollback timer value set to [ 3600 ] seconds
Router(config)#

Performing an eFSU Upgrade

To perform an eFSU upgrade (or downgrade) of a VSS, perform this task:

Command Purpose
Step 1 Router# copy tftp disk_name Uses TFTP to copy the new software image to flash memory
on the VSS active and VSS standby chassis (disk0: and
slavedisk0:) and to the ICSs, if they exist. Answer the
prompts to identify the name and location of the new
software image.
Step 2 Router# show issu state [switch/slot] [detail] (Optional) Verifies that the VSS is ready to run the eFSU.
Note You can use the show issu state command at any
stage of the upgrade to verify the progress and status
of the upgrade.
Step 3 Router# issu loadversion Starts the upgrade process by loading the new software
[active_switch/slot] active-image image onto the VSS standby chassis. The image name
[standby_switch/slot] standby-image
includes the path of the target image to be loaded, in the
format devicename:filename.
It may take several seconds for the new image to load and
for the VSS standby chassis to transition to SSO mode.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-60 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

Command Purpose
Step 4 Router# issu runversion Forces a switchover, causing the VSS standby chassis to
become VSS active and begin running the new software.
The previously VSS active chassis becomes VSS standby
and boots with the old image.
Step 5 Router# issu acceptversion (Optional) Halts the rollback timer to ensure that the new
software image is not automatically aborted during the
upgrade process.
Step 6 Router# issu commitversion Loads the new software image onto the VSS standby
chassis.
Step 7 Router# show issu state [switch/slot][detail] Verifies the status of the upgrade process. If the upgrade
was successful, both the VSS active and VSS standby
chassis are running the new software version.

For an example of the eFSU upgrade sequence, see the eFSU Upgrade Example section on page 4-67.

Performing an eFSU Upgrade from Previous Cisco IOS Releases to Cisco IOS Release 12.2(33)SXI4

With previous Cisco IOS releases if you have a second ICS in your chassis, it will be forced to
ROMMON.
To perform an eFSU upgrade of a VSS from Cisco IOS Release 12.2(33)SXI to Cisco IOS Release
12.(33)SXI4, perform this task:

Command Purpose
Step 1 Router# copy tftp disk_name Uses TFTP to copy the new software image to flash memory
on the active and standby chassis (disk0: and slavedisk0:).
Answer the prompts to identify the name and location of the
new software image.
Step 2 Router# show issu state [switch/slot] [detail] (Optional) Verifies that the VSS is ready to run the eFSU.
Note You can use the show issu state command at any
stage of the upgrade to verify the progress and status
of the upgrade.
Step 3 Router# issu loadversion Starts the upgrade process by loading the new software
[active_switch/slot] active-image image onto the standby chassis. The image name includes
[standby_switch/slot] standby-image
the path of the target image to be loaded, in the format
devicename:filename.
It may take several seconds for the new image to load and
for the standby chassis to transition to SSO mode.
Step 4 Router# issu runversion Forces a switchover, causing the standby chassis to become
active and begin running the new software. The previously
active chassis becomes standby and boots with the old
image.
Step 5 Router# issu acceptversion (Optional) Halts the rollback timer to ensure that the new
software image is not automatically aborted during the
upgrade process.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-61
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

Command Purpose
Step 6 Router# issu commitversion Loads the new software image onto the standby chassis.
Step 7 Router# show issu state [switch/slot][detail] Verifies the status of the upgrade process. If the upgrade
was successful, both the active and standby chassis are
running the new software version.

If you intend to bring up the ICS supervisor engine with Cisco IOS Release 12.2(33)SXI4, you will need
to manually boot up the ICS supervisor engine after the eFSU cycle is complete.

Performing an eFSU Upgrade from Cisco IOS Release 12.2(33)SXI4 to Future Cisco IOS Releases

To perform an eFSU upgrade of a VSS from Cisco IOS Release 12.2(33)SXI4 to a future Cisco IOS
Release, perform this task:

Command Purpose
Step 1 Router# copy tftp disk_name Uses TFTP to copy the new software image to flash memory
on the active and standby chassis (disk0: and slavedisk0:)
and to the ICSs, if they exist. Answer the prompts to
identify the name and location of the new software image.
Step 2 Router# show issu state [switch/slot] [detail] (Optional) Verifies that the VSS is ready to run the eFSU.
Note You can use the show issu state command at any
stage of the upgrade to verify the progress and status
of the upgrade.
Step 3 Router# switch virtual in-chassis standby (Optional) Includes or removes the ICS, from the eFSU
switch [disable | enable] cycle. This command must be executed before the start of
the eFSU cycle even if the ICS is in ROMMON.
Step 4 Router# issu loadversion Starts the upgrade process by loading the new software
[active_switch/slot] active-image image onto the standby chassis. The image name includes
[standby_switch/slot] standby-image
the path of the target image to be loaded, in the format
devicename:filename.
It may take several seconds for the new image to load and
for the standby chassis to transition to SSO mode.

Note This command is not extended for the ICS. The file
system mentioned for the ICA is used for the
respective ICS. For example, if the issu
loadversion disk0:image_name
slavesup-bootdisk:image_name command is
executed the loadversion command is accepted. The
presence of the image is checked in the disk0: for
the active supervisor engine (both the ICA and ICS)
and the SPs bootdisk for the SSO standby (both the
ICA and ICS).

Cisco IOS Software Configuration Guide, Release 12.2SX


4-62 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

Command Purpose
Step 5 Router# issu runversion Forces a switchover, causing the standby engine chassis to
become active and begin running the new software. The
previously active chassis becomes standby and boots with
the old image.

Note If there are two supervisor engines in the active


chassis, an in-chassis role reversal will occur if the
upgrade cycle starts with both supervisor engines in
the active chassis unless you have configured a
supervisor engine to not participate in the upgrade.
Step 6 Router# issu acceptversion (Optional) Halts the rollback timer to ensure that the new
software image is not automatically aborted during the
upgrade process.
Step 7 Router# issu commitversion Loads the new software image onto the standby chassis.
Step 8 Router# show issu state [switch/slot][detail] Verifies the status of the upgrade process. If the upgrade
was successful, both the active and standby chassis are
running the new software version. The ICS is forced to
ROMMON.

If the ICS is participating in the eFSU upgrade, you must ensure that the ICS is up and running before
performing each ISSU step. If the ICS is not up and running, you need to wait until it is online. You can
verify that the ICS is online by entering the show module command.

Performing an eFSU Downgrade from Cisco IOS Release 12.2(33)SXI4 to Earlier Cisco IOS Releases

To perform an eFSU downgrade of a VSS from Cisco IOS Release 12.2(33)SXI4 to an earlier Cisco IOS
release, perform this task:

Command Purpose
Step 1 Router# copy tftp disk_name Uses TFTP to copy the new software image to flash memory
on the active and standby chassis (disk0: and slavedisk0:).
Answer the prompts to identify the name and location of the
new software image.
Step 2 Router# show issu state [switch/slot] [detail] (Optional) Verifies that the VSS is ready to run the eFSU.
Note You can use the show issu state command at any
stage of the upgrade to verify the progress and status
of the upgrade.
Step 3 Router# switch virtual in-chassis standby (Optional) Includes or removes the ICS from the eFSU
switch [disable | enable] cycle. This command must be executed before the start of
the eFSU cycle even if the ICS is in ROMMON.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-63
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

Command Purpose
Step 4 Router# issu loadversion Starts the downgrade process by loading the new software
[active_switch/slot] active-image image onto the standby chassis. The image name includes
[standby_switch/slot] standby-image
the path of the target image to be loaded, in the format
devicename:filename.
It may take several seconds for the new image to load and
for the standby chassis to transition to SSO mode.

Note If the active ICS is online when you enter the issu
loadversion command, then an error message is
displayed when the standby supervisor engine is
booting up with the pre-12.2(33)SXI4 image, which
prompts you to disable the active ICS. Once you
disable the active ICS, the cycle will proceed. If you
do not disable the active ICS and enter the issu
runversion command, the command is not
accepted. You will have to either abort the
downgrade process or disable the active ICS to
proceed with the downgrade.
If the standby ICS is online when you enter the issu
loadversion command, the pre-12.2(33)SXI4
image that comes up on the SSO standby forces the
standby ICS to ROMMON.
Step 5 Router# issu runversion Forces a switchover, causing the standby chassis to become
active and begin running the new software. The previously
active chassis becomes standby and boots with the old
image.
Step 6 Router# issu acceptversion (Optional) Halts the rollback timer to ensure that the new
software image is not automatically aborted during the
upgrade process.
Step 7 Router# issu commitversion Loads the new software image onto the standby chassis.
Step 8 Router# show issu state [switch/slot][detail] Verifies the status of the downgrade process. If the
downgrade was successful, both the active and standby
chassis are running the new software version.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-64 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

Performing an eFSU Downgrade from a Future Cisco IOS Release to Cisco IOS Release 12.2(33)SXI4

To perform an eFSU downgrade of a VSS from a future Cisco IOS Release to Cisco IOS Release
12.2(33)SXI4, perform this task:

Command Purpose
Step 1 Router# copy tftp disk_name Uses TFTP to copy the new software image to the ICSs and
flash memory on the active and standby chassis (disk0: and
slavedisk0:). Answer the prompts to identify the name and
location of the new software image.
Step 2 Router# show issu state [switch/slot] [detail] (Optional) Verifies that the VSS is ready to run the eFSU.
Note You can use the show issu state command at any
stage of the upgrade to verify the progress and status
of the upgrade.
Step 3 Router# switch virtual in-chassis standby (Optional) Includes or removes the ICS from the eFSU
switch [disable | enable] cycle. This command must be executed before the start of
the eFSU cycle even if the ICS is in ROMMON.

Note If you did not remove the ICS from the downgrade
using the switch virtual disable command the
loadversion cycle is aborted, the SSO standby
reloads with the initial image.
Step 4 Router# issu loadversion Starts the downgrade process by loading the new software
[active_switch/slot] active-image image onto the standby chassis. The image name includes
[standby_switch/slot] standby-image
the path of the target image to be loaded, in the format
devicename:filename.
It may take several seconds for the new image to load and
for the standby chassis to transition to SSO mode.

Note This command is not extended for the ICS. The file
system mentioned for the ICA is used for the
respective ICS. For example, if the issu
loadversion disk0:image_name
slavesup-bootdisk:image_name command is
executed the loadversion command is accepted. The
presence of the image is checked in the disk0: for
the active supervisor engine (both the ICA and ICS)
and the SPs bootdisk for the SSO standby (both the
ICA and ICS).
Step 5 Router# issu runversion Forces a switchover, causing the standby chassis to become
active and begin running the new software. The previously
active chassis becomes standby and boots with the old
image.
Step 6 Router# issu acceptversion (Optional) Halts the rollback timer to ensure that the new
software image is not automatically aborted during the
upgrade process.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-65
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

Command Purpose
Step 7 Router# issu commitversion Loads the new software image onto the standby chassis.
Step 8 Router# show issu state [switch/slot][detail] Verifies the status of the downgrade process. If the
downgrade was successful, both the active and standby
chassis are running the new software version.

If the ICS is participating in the eFSU upgrade, you must ensure that the ICS is up and running before
performing each ISSU step. If the ICS is not up and running you need to wait until it is online. You can
verify that the ICS is online by entering the show module command.

Performing an eFSU Upgrade on an Installed Modular Image

To perform an eFSU upgrade (or downgrade) of an ION VSS, perform this task:

Command Purpose
Step 1 Router# copy tftp disk_name Uses TFTP to copy the new software image to flash memory
on the active and VSS standby chassis (disk0: and
slavedisk0:). Answer the prompts to identify the name and
location of the new software image.

Note You should have a console on both the active and


VSS standby supervisor engines because you will
go back and forth between them.

Step 2 Router# install file bootdisk:filename Installs the modular image on to both the active and VSS
bootdisk:/location standby supervisor engines.
Step 3 Router# show issu state [switch/slot][detail] Verifies the status of the upgrade process; status should
display Init.
Step 4 Router# issu loadversion new-image Starts the upgrade process by loading the installed software
image onto the active and VSS standby chassis. The image
name includes the path of the target image to be loaded, in
the format devicename:filename.
It may take several seconds for the new image to load and
for the VSS standby chassis to transition to SSO mode.

Note This command will cause the VSS standby chassis


to reload.
Step 5 Router# show issu state [switch/slot][detail] Verifies the status of the upgrade process; status should
display Load Version.
Step 6 Router# issu runversion Forces a switchover, causing the VSS standby chassis to
become active and begin running the new software. The
previously active chassis becomes VSS standby and boots
with the old image.
Step 7 Router# show issu state [switch/slot][detail] Verifies the status of the upgrade process; status should
display Run Version.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-66 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

Command Purpose
Step 8 Router# issu commitversion Loads the new software image onto the VSS standby
chassis.

Note This command will cause the VSS standby chassis


to reload.
Step 9 Router# show issu state [switch/slot][detail] Verifies the status of the upgrade process; status should
display Init.
Step 10 Router# redundancy force-switchover (Optional) Forces the VSS standby Route Processor (RP) to
assume the role of the active RP.

For an example of the eFSU upgrade on an Installed Modular Image sequence, see the eFSU Upgrade
on an Installed Modular Image Example section on page 4-68.

Aborting an eFSU Upgrade

To manually abort the eFSU and roll back the upgrade, perform this task:

Command Purpose
Router# issu abortversion Stops the upgrade process and forces a rollback to the
previous software image.

This example shows how to abort an eFSU upgrade for a VSS:


Router# issu abortversion

eFSU Upgrade Example


This example shows how to perform and verify an eFSU upgrade for a VSS.

Verify the System Readiness

After copying the new image files into the file systems of the active and VSS standby chassis, enter the
show issu state detail command and the show redundancy status command to check that the VSS is
ready to perform the eFSU. One chassis must be in the active state and the other chassis in the hot VSS
standby state. Both chassis should be in the ISSU Init state and in SSO redundancy state. In the example,
both chassis are running an oldversion image.
Router# show issu state detail
Slot = 1/2
RP State = Active
ISSU State = Init
Boot Variable = disk0:s72033-oldversion.v1,12;
Operating Mode = sso
Primary Version = N/A
Secondary Version = N/A
Current Version = disk0:s72033-oldversion.v1
Variable Store = PrstVbl

Slot = 2/7
RP State = Standby
ISSU State = Init

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-67
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

Boot Variable = disk0:s72033-oldversion.v1,12;


Operating Mode = sso
Primary Version = N/A
Secondary Version = N/A
Current Version = disk0:s72033-oldversion.v1

Router# show redundancy status


my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Secondary
Unit ID = 18

Redundancy Mode (Operational) = sso


Redundancy Mode (Configured) = sso
Redundancy State = sso
Maintenance Mode = Disabled
Communications = Up

client count = 132


client_notification_TMR = 30000 milliseconds
keep_alive TMR = 9000 milliseconds
keep_alive count = 0
keep_alive threshold = 18
RF debug mask = 0x0

eFSU Upgrade on an Installed Modular Image Example


This example shows how to perform an an eFSU upgrade on an installed modular image:
Router# copy ftp://172.18.108.26/s72033-advipservicesk9_wan-vz.122-33.SXI2
sup-bootdisk:s72033-advipservicesk9_wan-vz.122-33.SXI2.bin
Router# copy ftp://172.18.108.26/s72033-advipservicesk9_wan-vz.122-33.SXI2
slavesup-bootdisk:s72033-advipservicesk9_wan-vz.122-33.SXI2.bin
Router# install file sup-bootdisk:s72033-advipservicesk9_wan-vz.122-33.SXI2.bin sup-bootdisk:/newsys
Router# install file slavesup-bootdisk:s72033-advipservicesk9_wan-vz.122-33.SXI2.bin
slavesup-bootdisk:/newsys
Router# show issu state
Slot = 1/6
RP State = Active
ISSU State = Init
Boot Variable = bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm,12;

Slot = 2/6
RP State = Standby
ISSU State = Init
Boot Variable = bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm,12;
Router# issu loadversion sup-bootdisk:/newsys/s72033/base/s72033-advipservicesk9_wan-vm
%issu loadversion executed successfully, Standby is being reloaded
Router# show issu state
Slot = 1/6
RP State = Active
ISSU State = Load Version
Boot Variable = bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm,12;

Slot = 2/6
RP State = Standby
ISSU State = Load Version
Boot Variable = bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm,12;
Router# issu runversion
This command will reload the Active unit. Proceed ? [confirm]
Router# show issu state
Slot = 2/6

Cisco IOS Software Configuration Guide, Release 12.2SX


4-68 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

RP State = Active
ISSU State = Run Version
Boot Variable = bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm,12;

Slot = 1/6
RP State = Standby
ISSU State = Run Version
Boot Variable = bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm,12;
Router# issu commitversion
%issu commitversion executed successfully
Router# show issu state
Slot = 2/6
RP State = Active
ISSU State = Init
Boot Variable = bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm,12;

Slot = 1/6
RP State = Standby
ISSU State = Init
Boot Variable = bootdisk:/sys/s72033/base/s72033-advipservicesk9_wan-vm,12;
Router# redundancy force-switchover

Load the New Image to the VSS Standby Chassis

Enter the issu loadversion command to start the upgrade process. In this step, the VSS standby chassis
reboots, reloads with the new image, and initializes as the VSS standby chassis in SSO redundancy
mode, running the new image. This step is complete when the chassis configuration is synchronized, as
indicated by the Bulk sync succeeded message.
Router# issu loadversion disk0:s72033-newversion.v2

000133: Aug 6 16:17:44.486 PST: %LINEPROTO-5-UPDOWN: Line protocol on Interface


TenGigabitEthernet1/2/4, changed state to down
000134: Aug 6 16:17:43.507 PST: %LINEPROTO-5-UPDOWN: Line protocol on Interface
TenGigabitEthernet2/7/4, changed state to down
000135: Aug 6 16:17:43.563 PST: %LINK-3-UPDOWN: Interface TenGigabitEthernet2/7/4,
changed state to down
000136: Aug 6 16:17:44.919 PST: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/2/4,
changed state to down

(Deleted many interface and protocol down messages)

%issu loadversion executed successfully, Standby is being reloaded

(Deleted many interface and protocol down messages, then interface and protocol up messages)

0000148: Aug 6 16:27:54.154 PST: %LINEPROTO-5-UPDOWN: Line protocol on Interface


TenGigabitEthernet1/2/5, changed state to up
000149: Aug 6 16:27:54.174 PST: %LINK-3-UPDOWN: Interface TenGigabitEthernet2/7/5,
changed state to up
000150: Aug 6 16:27:54.186 PST: %LINEPROTO-5-UPDOWN: Line protocol on Interface
TenGigabitEthernet2/7/5, changed state to up
000151: Aug 6 16:32:58.030 PST: %HA_CONFIG_SYNC-6-BULK_CFGSYNC_SUCCEED: Bulk Sync
succeeded

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-69
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

Verify the New Image on the VSS Standby Chassis

You can now enter the show issu state detail command and the show redundancy command to check
that both chassis are in the ISSU Load Version state and SSO redundancy state. In this example, the
VSS standby chassis is now running the newversion image.

Router# show issu state detail


Slot = 1/2
RP State = Active
ISSU State = Load Version
Boot Variable = disk0:s72033-oldversion.v1,12
Operating Mode = sso
Primary Version = disk0:s72033-oldversion.v1
Secondary Version = disk0:s72033-newversion.v2
Current Version = disk0:s72033-oldversion.v1
Variable Store = PrstVbl

Slot = 2/7
RP State = Standby
ISSU State = Load Version
Boot Variable =
disk0:s72033-newversion.v2,12;disk0:s72033-oldversion.v1,12
Operating Mode = sso
Primary Version = disk0:s72033-oldversion.v1
Secondary Version = disk0:s72033-newversion.v2
Current Version = disk0:s72033-newversion.v2

Router# show redundancy status


my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Secondary
Unit ID = 18

Redundancy Mode (Operational) = sso


Redundancy Mode (Configured) = sso
Redundancy State = sso
Maintenance Mode = Disabled
Communications = Up

client count = 132


client_notification_TMR = 30000 milliseconds
keep_alive TMR = 9000 milliseconds
keep_alive count = 1
keep_alive threshold = 18
RF debug mask = 0x0

Execute a Switchover to the New Image

When the VSS standby chassis is successfully running the new image in SSO redundancy state, enter the
issu runversion command to force a switchover. The upgraded VSS standby chassis takes over as the
new active chassis, running the new image. The formerly active chassis reloads and initializes as the new
VSS standby chassis in SSO mode, running the old image (in case the software upgrade needs to be
aborted and the old image restored). This step is complete when the chassis configuration is
synchronized, as indicated by the Bulk sync succeeded message.
Router# issu runversion
This command will reload the Active unit. Proceed ? [confirm]
System Bootstrap, Version 12.2(17r)S4, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 2005 by cisco Systems, Inc.

Cisco IOS Software Configuration Guide, Release 12.2SX


4-70 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

Cat6k-Sup720/RP platform with 1048576 Kbytes of main memory

Download Start
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
(Deleted many lines)
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Download Completed! Booting the image.
Self decompressing the image :
##########################################################################################
(Deleted many lines)
################################################################################ [OK]
running startup....

(Deleted many lines)

000147: Aug 6 16:53:43.199 PST: %HA_CONFIG_SYNC-6-BULK_CFGSYNC_SUCCEED: Bulk Sync


succeeded

Verify the Switchover

You can now enter the show issu state detail command and the show redundancy command to check
that both chassis are in the ISSU Run Version state and SSO redundancy state. In this example, the
active chassis is now running the newversion image.

Router# show issu state detail


Slot = 2/7
RP State = Active
ISSU State = Run Version
Boot Variable =
disk0:s72033-newversion.v2,12;disk0:s72033-oldversion.v1,12
Operating Mode = sso
Primary Version = disk0:s72033-newversion.v2
Secondary Version = disk0:s72033-oldversion.v1
Current Version = disk0:s72033-newversion.v2
Variable Store = PrstVbl

Slot = 1/2
RP State = Standby
ISSU State = Run Version
Boot Variable = disk0:s72033-oldversion.v1,12
Operating Mode = sso
Primary Version = disk0:s72033-newversion.v2
Secondary Version = disk0:s72033-oldversion.v1
Current Version = disk0:s72033-oldversion.v1

Router# show redundancy status


my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Primary
Unit ID = 39

Redundancy Mode (Operational) = sso


Redundancy Mode (Configured) = sso
Redundancy State = sso
Maintenance Mode = Disabled
Communications = Up

client count = 134


client_notification_TMR = 30000 milliseconds
keep_alive TMR = 9000 milliseconds

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-71
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

keep_alive count = 1
keep_alive threshold = 18
RF debug mask = 0x0

Commit the New Image to the VSS Standby Chassis

When the active chassis is successfully running the new image in the SSO redundancy state, you can
enter either the issu acceptversion command to stop the rollback timer and hold this state indefinitely,
or the issu commitversion command to continue with the eFSU. To continue, enter the issu
commitversion command to upgrade the VSS standby chassis and complete the eFSU sequence. The
VSS standby chassis reboots, reloads with the new image, and initializes as the VSS standby chassis in
the SSO redundancy state, running the new image. This step is complete when the chassis configuration
is synchronized, as indicated by the Bulk sync succeeded message.

Router# issu commitversion


Building configuration...
[OK]
000148: Aug 6 17:17:28.267 PST: %LINEPROTO-5-UPDOWN: Line protocol on Interface
TenGigabitEthernet2/7/4, changed state to down
000149: Aug 6 17:17:28.287 PST: %LINEPROTO-5-UPDOWN: Line protocol on Interface
TenGigabitEthernet1/2/4, changed state to down

(Deleted many interface and protocol down messages)

%issu commitversion executed successfully

(Deleted many interface and protocol down messages, then interface and protocol up messages)

000181: Aug 6 17:41:51.086 PST: %LINEPROTO-5-UPDOWN: Line protocol on Interface


TenGigabitEthernet1/2/5, changed state to up
000182: Aug 6 17:42:52.290 PST: %HA_CONFIG_SYNC-6-BULK_CFGSYNC_SUCCEED: Bulk Sync
succeeded

Verify That the Upgrade is Complete

You can now enter the show issu state detail command and the show redundancy command to check
the results of the eFSU. In this example, both chassis are now running the newversion image,
indicating that the eFSU was successful. Because the eFSU has completed, the two chassis will be
once again in the ISSU Init Version state, as they were before the eFSU was initiated.

Router# show issu state detail


Slot = 2/7
RP State = Active
ISSU State = Init
Boot Variable =
disk0:s72033-newversion.v2,12;disk0:s72033-oldversion.v1,12
Operating Mode = sso
Primary Version = N/A
Secondary Version = N/A
Current Version = disk0:s72033-newversion.v2
Variable Store = PrstVbl

Slot = 1/2
RP State = Standby
ISSU State = Init
Boot Variable =
disk0:s72033-newversion.v2,12;disk0:s72033-oldversion.v1,12

Cisco IOS Software Configuration Guide, Release 12.2SX


4-72 OL-13013-06
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

Operating Mode = sso


Primary Version = N/A
Secondary Version = N/A
Current Version = disk0:s72033-newversion.v2

Router# show redundancy status


my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Primary
Unit ID = 39

Redundancy Mode (Operational) = sso


Redundancy Mode (Configured) = sso
Redundancy State = sso
Maintenance Mode = Disabled
Communications = Up

client count = 134


client_notification_TMR = 30000 milliseconds
keep_alive TMR = 9000 milliseconds
keep_alive count = 1
keep_alive threshold = 18
RF debug mask = 0x0

Tip For additional information about Cisco Catalyst 6500 series switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 4-73
Chapter 4 Configuring Virtual Switching Systems
Upgrading a VSS

Cisco IOS Software Configuration Guide, Release 12.2SX


4-74 OL-13013-06
P A R T 2

High Availability
CH A P T E R 5
Performing an Enhanced Fast Software Upgrade

This chapter provides information about how to perform a software upgrade using the Enhanced Fast
Software Upgrade (eFSU) feature.

Note For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS
Master Command List, Release 12.2SX, at this URL:
http://www.cisco.com/en/US/docs/ios/mcl/122sxmcl/12_2sx_mcl_book.html

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

This chapter contains the following sections:


eFSU Overview, page 5-1
eFSU Restrictions, page 5-4
Performing an Enhanced Fast Software Upgrade, page 5-5
Performing an eFSU Upgrade on an Installed Modular Image, page 5-14
Upgrading a Non-eFSU Image to an eFSU Image, page 5-16

eFSU Overview
The following sections provide an overview of how eFSU works:
eFSU Operation, page 5-2
Outage Time and Support Considerations, page 5-3
Reserving Module Memory, page 5-3
Error Handling for eFSU Preload, page 5-4

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 5-1
Chapter 5 Performing an Enhanced Fast Software Upgrade
eFSU Overview

Note eFSU is supported in VSS mode. See the VSS Configuration Guidelines and Restrictions section on
page 4-29 for more information.

eFSU Operation
eFSU is an enhanced software upgrade procedure. Cisco IOS Release 12.2(33)SXI and later releases
support eFSU.
Non-eFSU (FSU) software upgrades require system downtime, because a software version mismatch between
the active and the standby supervisor engines forces the system to boot in RPR redundancy mode, which is
stateless and causes a hard reset of the all modules.
eFSU enables an increase in network availability by reducing the downtime caused by software
upgrades. eFSU does this by:
Bringing up the standby supervisor engine in SSO mode even when the active and the standby
supervisor engines have different software versions, or with VSS configured, when the supervisor
engines in the two chassis have different software versions.
During an eFSU, new software is loaded onto the standby supervisor engine while the active supervisor
engine continues to operate using the previous software. As part of the upgrade, the standby processor
reaches the SSO Standby Hot stage, a switchover occurs, and the standby becomes active, running
the new software. In previous releases Supervisor Engines running different software versions ran
in the Route Processor Redundancy Mode.
You can continue with the upgrade to load the new software onto the other processor, or you can
abort the upgrade and resume operation with the old software.
Preloading new module software into memory on supported modules to avoid a hard reset.
If the new software release contains new module software, eFSU preloads the new module software
onto any modules in the switch that support eFSU preload. When the switchover occurs between the
active and standby supervisor engines, the modules are restarted with the new software image.
The following modules support eFSU preload:
WS-X67xx modules
SIP-400 and SIP-600
All other modules undergo a hard reset at switchover, and the software image loads after the module
restarts.
During a software upgrade, the switch performs the following steps automatically on modules that
support eFSU preload:
Reserves the necessary memory for the new Cisco IOS software image on each module.
Preloads a new software image onto the modules as part of the issu loadversion command.
Restarts the modules with the new software image when a switchover occurs (issu runversion).
During the restart, the software features and routing protocols are not available.
If a rollback or abort occurs, to minimize disruption, the switch preloads the original software
version onto the module. Once the rollback or abort is completed, the module is restarted with
the original software version.

Cisco IOS Software Configuration Guide, Release 12.2SX


5-2 OL-13013-06
Chapter 5 Performing an Enhanced Fast Software Upgrade
eFSU Overview

Note All modules that support eFSU preload must have at least 512 MB of memory, with enough memory free
to hold the new software image. If there is insufficient free memory, eFSU does not attempt the preload,
but instead resets the modules during the switchover.

Outage Time and Support Considerations


During an eFSU upgrade, modules are restarted or reset after the switchover that occurs between the
supervisor engines. Because the modules are restarted or reset, any links attached to the modules go up
and down and traffic processing is disrupted until protocols and software features are brought back
online. The length of time that module processing is disrupted (outage time) depends on whether the
eFSU process was able to preload a new software image onto the module.
For modules that support eFSU preload, the outage time for an eFSU module warm reload is faster
than an RPR mode module reload.
For modules that do not support eFSU preload, the outage time for module reload is similar to an
RPR mode module reload.
Once the new software is loaded (issu loadversion), you can use the show issu outage slot all command
to display the maximum outage time for installed modules. See the Displaying the Maximum Outage
Time for Installed Modules (Optional) section on page 5-10 for a command example.

Reserving Module Memory


On modules that support eFSU, the supervisor engine automatically reserves memory on the module to
store the new software image (decompressed format). The amount of memory needed varies according
to the module type.
Although we do not recommend it, you can enter the following command to keep the switch from reserving
memory for the software preload (where slot-num specifies which slot the module is installed in):
no mdr download reserve memory image slot slot-num

Note All modules that support eFSU preload must have at least 512 MB of memory, with enough memory free
to hold the new software image. If there is insufficient free memory, eFSU does not attempt the preload,
but instead resets the modules during the switchover.

To display whether or not the memory reservation was successful on a module, use the show issu outage
slot all command See the Displaying the Maximum Outage Time for Installed Modules (Optional)
section on page 5-10 for a command example.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 5-3
Chapter 5 Performing an Enhanced Fast Software Upgrade
eFSU Restrictions

Error Handling for eFSU Preload


If problems occur during eFSU preload, the switch takes the following actions:
Module crash during loadversionThe module is reset when a switchover occurs.
Module not active when eFSU startedNo power is provided to the module during the software
upgrade, and the module is reset when the process ends. The same action is applied to a module that
is inserted into the switch after the software upgrade process has begun.
Module crash during run version or during rollbackThe module boots with the software image
version that corresponds to the software image that is present on the active supervisor engine.

eFSU Restrictions
eFSU requires two supervisor engines, one active and one standby.
Both the active and standby supervisor engines must have enough flash memory to store both the
old and new software images prior to the upgrade process.
Images from different features sets, regardless of release, fail the eFSU compatibility check.
When downgrading with eFSU to an earlier version of Cisco IOS Software, the configuration files
fail to synchronize and the standby supervisor engine reloads unless you disable any features or
functions that are not supported in the earlier version before you start the process. Remove any
configuration commands that are not available in the earlier version.
During an eFSU upgrade, the modules are restarted.
The switch examines the old and new software images and automatically performs the appropriate
process (eFSU) to upgrade the software image:
For a patch upgrade, if the module software is the same in both the old and the new software
images, because no module software upgfrade is required, the eFSU upgrades only the
supervisor engine software. The system downtime is from 0 to 3 seconds.
If the module software in the images is different, the modules are restarted or reset during the
upgrade process. System downtime depends on whether the modules support eFSU (see the
Outage Time and Support Considerations section on page 5-3 for more information).
The eFSU upgrade feature works with NSF/SSO. Software features that do not support NSF/SSO
stop operating until they come back online after the switchover that occurs during the software
upgrade.
Release 12.2(33)SXJ and later releases support NTPv4. Earlier releases support NTPv3. With
NTPv3, be aware of CSCec87418, which can cause eFSU to fail.
All modules that support eFSU preload must have at least 512 MB of memory, with enough memory
free to hold the new software image. If there is insufficient free memory, eFSU does not attempt the
preload, but instead resets the modules during the switchover.
Online insertion and replacement (OIR) is not supported during an eFSU. If you attempt to insert a
new module in the switch while the upgrade is active, the switch does not provide power for the
module. When the upgrade ends, the switch resets the newly inserted module.
Do not perform a manual switchover between supervisor engines during the upgrade.
Make sure that the configuration register is set to allow autoboot (the lowest byte of the register
should be set to 2).

Cisco IOS Software Configuration Guide, Release 12.2SX


5-4 OL-13013-06
Chapter 5 Performing an Enhanced Fast Software Upgrade
Performing an Enhanced Fast Software Upgrade

Before you enter the issu abortversion command (to abort a software upgrade), make sure that the
standby supervisor engine is Up (STANDBY HOT [in SSO] or COLD [in RPR]).
The Fast Software Upgrade (FSU) process supports upgrade from earlier releases to Release
12.2(33)SXI or later releases. During this process, the module software image is also upgraded on
those modules that support eFSU.
The enhanced Fast Software Upgrade (eFSU) process supports upgrades from Release 12.2(33)SXI
and rebuilds to Release 12.2(33)SXJ. During this process, the module software image is also
upgraded on those modules that support eFSU.

Performing an Enhanced Fast Software Upgrade


The following sections describe the process for performing an enhanced fast software upgrade (eFSU) on
the Catalyst 6500 series switch:
Software Upgrade Process Summary For a Switch, page 5-5
Preparing for the Upgrade, page 5-6
Copying the New Software Image, page 5-8
Loading the New Software onto the Standby Supervisor Engine, page 5-8
Displaying the Maximum Outage Time for Installed Modules (Optional), page 5-10
Forcing a Switchover from Active to Standby, page 5-10
Accepting the New Software Version and Stopping the Rollback Process (Optional), page 5-11
Committing the New Software to the Standby, page 5-12
Verifying the Software Installation, page 5-12
Aborting the Upgrade Process, page 5-13
Each section briefly describes a particular step in the upgrade process and provides command examples.
In the command examples, important fields in the command output are shown in bold. Check these fields
to verify the status of the command.

Software Upgrade Process Summary For a Switch


The following sections provide examples of the software upgrade process. To upgrade the software,
perform the following tasks:

Command Purpose
Step 1 Router> enable Enables privileged EXEC mode. Enter your password if
prompted.
Step 2 Router# copy tftp disk_name Uses TFTP to copy the new software image to flash memory
on the active and standby supervisor engines (disk0: and
slavedisk0:). Answer the prompts to identify the name and
location of the new software image.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 5-5
Chapter 5 Performing an Enhanced Fast Software Upgrade
Performing an Enhanced Fast Software Upgrade

Command Purpose
Step 3 Router# show version | in image These show commands verify that the switch is ready to run
Router# show bootvar eFSU. The show version and show bootvar commands
verify the boot image settings.
Router# show redundancy The show redundancy and show issu state commands
Router# show issu state [detail]
verify that redundancy mode is enabled and that SSO and
NSF are configured.
Note Use the show redundancy and show issu state
commands throughout the upgrade to verify the
status of the upgrade.
Step 4 Router# issu loadversion active-slot Starts the upgrade process and loads the new software
active-image standby-slot standby-image image onto the standby supervisor engine. It may take
several seconds for the new image to load and for the
standby supervisor engine to transition to SSO mode.
Step 5 Router# show issu outage slot all (Optional) Displays the maximum outage time for installed
modules. Enter the command on the switch processor of the
supervisor engine.
Step 6 Router# issu runversion Forces a switchover, which causes the standby supervisor
engine to become active and begin running the new
software. The previously active processor becomes standby
and boots with the old image.
Step 7 Router# issu acceptversion (Optional) Halts the rollback timer to ensure that the new
software image is not automatically aborted during the
upgrade process.
Step 8 Router# issu commitversion Loads the new software image onto the standby supervisor
engine in the specified slot.
Step 9 Router# show redundancy Verifies the status of the upgrade process. If the upgrade
Router# show issu state [detail] was successful, both the active and standby supervisor
engines are running the new software version.

Preparing for the Upgrade


Before attempting to perform a software upgrade, be sure to review the eFSU Restrictions section on
page 5-4.
To prepare for eFSU, perform the tasks in the following sections:
Verifying the Boot Image Version and Boot Variable, page 5-6
Verifying Redundancy Mode, page 5-7
Verifying eFSU State, page 5-8

Verifying the Boot Image Version and Boot Variable


Before starting, enter the show version and show bootvar commands to verify the boot image version
and BOOT environment variable, as shown in the following examples:
Router# show version | in image
BOOT variable = disk0:image_name;
CONFIG_FILE variable =
BOOTLDR variable =

Cisco IOS Software Configuration Guide, Release 12.2SX


5-6 OL-13013-06
Chapter 5 Performing an Enhanced Fast Software Upgrade
Performing an Enhanced Fast Software Upgrade

Configuration register is 0x2002

Standby is up
Standby has 1048576K/65536K bytes of memory.

Standby BOOT variable = disk0:image_name;


Standby CONFIG_FILE variable =
Standby BOOTLDR variable =

Verifying Redundancy Mode


Verify that redundancy mode is enabled and that NSF and SSO are configured. The following command
example shows how to verify redundancy:
Router# show redundancy
Redundant System Information :
------------------------------
Available system uptime = 45 minutes
Switchovers system experienced = 0
Standby failures = 0
Last switchover reason = none

Hardware Mode = Duplex


Configured Redundancy Mode = sso
Operating Redundancy Mode = sso
Maintenance Mode = Disabled
Communications = Up

Current Processor Information :


-------------------------------
Active Location = slot 6
Current Software state = ACTIVE
Uptime in current state = 44 minutes
Image Version = Cisco IOS Software, image_details
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Wed 18-Feb-09 12:48 by kchristi
BOOT = disk0:image_name;
CONFIG_FILE =
BOOTLDR =
Configuration register = 0x2002

Peer Processor Information :


----------------------------
Standby Location = slot 5
Current Software state = STANDBY HOT
Uptime in current state = 28 minutes
Image Version = Cisco IOS Software, image_details
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled image_details
BOOT = disk0:image_name ;
CONFIG_FILE =
BOOTLDR =
Configuration register = 0x2002

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 5-7
Chapter 5 Performing an Enhanced Fast Software Upgrade
Performing an Enhanced Fast Software Upgrade

Verifying eFSU State


Verify that the the ISSU state is Init, rather than an intermediate eFSU upgrade state. Enter this
command:
Router# show issu state detail
Slot = 6
RP State = Active
ISSU State = Load Version
Boot Variable = disk0:image_name
Operating Mode = sso
Primary Version = disk0:sierra.0217
Secondary Version = disk0:sierra.0217
Current Version = disk0:sierra.0217
Variable Store = PrstVbl
ROMMON CV = [disk0:image_name]

Slot = 5
RP State = Standby
ISSU State = Load Version
Boot Variable = disk0:image_name
Operating Mode = sso
Primary Version = disk0:image_name
Secondary Version = disk0:image_name
Current Version = disk0:image_name

Copying the New Software Image


Before starting the eFSU process, copy the new software image to flash memory (disk0: and slavedisk0:)
on the active and standby supervisor engines.

Loading the New Software onto the Standby Supervisor Engine


Enter the issu loadversion command to start the upgrade process. This command reboots the standby
supervisor engine and loads the new software image onto the standby supervisor engine. When the
download is complete, you are prompted to enter the runversion command.

Note Do not automatically disable the features that are not common to both images. During the standby
initialization, after you enter the issu loadversion command, if there are any enabled features that are
not supported on the standby supervisor engine, a message is displayed that states that the standby
supervisor engine cannot initialize while this feature is enabled, and the standby supervisor engine is
forced to RPR (in the load-version state).

Router# issu loadversion device:filename


%issu loadversion executed successfully, Standby is being reloaded

When execution of the issu loadversion command completes, the standby supervisor engine is loaded
with the new software image and the supervisor engine is in SSO mode. The issu loadversion command
might take several seconds to complete. If you enter the show commands too soon, you might not see
the information that you need.

Cisco IOS Software Configuration Guide, Release 12.2SX


5-8 OL-13013-06
Chapter 5 Performing an Enhanced Fast Software Upgrade
Performing an Enhanced Fast Software Upgrade

These examples show how to check the status of the upgrade using the show redundancy and show issu
state detail commands:
Router# show redundancy
Redundant System Information :
------------------------------
Available system uptime = 1 hour, 0 minutes
Switchovers system experienced = 0
Standby failures = 1
Last switchover reason = none

Hardware Mode = Duplex


Configured Redundancy Mode = sso
Operating Redundancy Mode = sso
Maintenance Mode = Disabled
Communications = Up

Current Processor Information :


-------------------------------
Active Location = slot 6
Current Software state = ACTIVE
Uptime in current state = 59 minutes
Image Version = Cisco IOS Software, image_details
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled ...
BOOT = disk0:image_name
CONFIG_FILE =
BOOTLDR =
Configuration register = 0x2002

Peer Processor Information :


----------------------------
Standby Location = slot 5
Current Software state = STANDBY HOT
Uptime in current state = 3 minutes
Image Version = Cisco IOS Software, image_name
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled ...
BOOT = disk0:image_name
CONFIG_FILE =
BOOTLDR =
Configuration register = 0x2002

Router# show issu state detail


Slot = 6
RP State = Active
ISSU State = Load Version
Boot Variable = disk0:image_name
Operating Mode = sso
Primary Version = disk0:image_name
Secondary Version = disk0:image_name
Current Version = disk0:image_name
Variable Store = PrstVbl
ROMMON CV = [disk0:image_name]

Slot = 5
RP State = Standby
ISSU State = Load Version
Boot Variable = disk0:image_name
Operating Mode = sso
Primary Version = disk0:image_name
Secondary Version = disk0:image_name
Current Version = disk0:image_name

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 5-9
Chapter 5 Performing an Enhanced Fast Software Upgrade
Performing an Enhanced Fast Software Upgrade

Displaying the Maximum Outage Time for Installed Modules (Optional)


Once the new software is downloaded, you can enter the show issu outage slot all command on the
switch processor to display the maximum outage time for the installed modules:
Router# show issu outage slot all
Slot # Card Type MDR Mode Max Outage Time
------ ------------------------------------------- ----------- ---------------
1 CEF720 8 port 10GE with DFC WARM_RELOAD 300 secs
2 96-port 10/100 Mbps RJ45 RELOAD 360 secs
4 CEF720 48 port 1000mb SFP RELOAD 360 secs

Slot # Reason Error Number


------ ------------------------------------------- ------------
1 PLATFORM_INIT 3
2 PLATFORM_INIT 3
4 PREDOWNLOAD_LC_MIMIMUM_MEMORY_FAILURE 5
Router#

Forcing a Switchover from Active to Standby


Enter the issu runversion command to force a switchover between the active and standby supervisor
engines. The standby supervisor engine, which has the new software image loaded, becomes active. The
previously active supervisor engine becomes the standby and boots with the old software image (in case
the software upgrade needs to be aborted and the old image restored).
Router# issu runversion

This command will reload the Active unit. Proceed ? [confirm] y

A switchover between the supervisor engines occurs now. The previous standby supervisor engine becomes
active and is running the new software version. The previous active supervisor engine, now the standby
supervisor engine, boots with the old software.

Note At this point, the new active supervisor engine is running the new software image and the standby is
running the old software image. You should verify the state of the active and standby supervisor engines
as shown in the following examples (show redundancy and show issu state detail).

Router# show redundancy


------------------------------
Available system uptime = 1 hour, 9 minutes
Switchovers system experienced = 1
Standby failures = 0
Last switchover reason = user forced

Hardware Mode = Duplex


Configured Redundancy Mode = sso
Operating Redundancy Mode = sso
Maintenance Mode = Disabled
Communications = Up

Current Processor Information :


-------------------------------
Active Location = slot 5
Current Software state = ACTIVE
Uptime in current state = 7 minutes
Image Version = Cisco IOS Software, image_details

Cisco IOS Software Configuration Guide, Release 12.2SX


5-10 OL-13013-06
Chapter 5 Performing an Enhanced Fast Software Upgrade
Performing an Enhanced Fast Software Upgrade

Technical Support: http://www.cisco.com/techsupport


Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled ...
BOOT = disk0:image_name
CONFIG_FILE =
BOOTLDR =
Configuration register = 0x2002

Peer Processor Information :


----------------------------
Standby Location = slot 6
Current Software state = STANDBY HOT
Uptime in current state = 0 minutes
Image Version = Cisco IOS Software, image_details
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Wed 18-Feb-09 12:48 by kchristi
BOOT = disk0:image_name
CONFIG_FILE =
BOOTLDR =
Configuration register = 0x2002

Router# show issu state detail


Slot = 5
RP State = Active
ISSU State = Run Version
Boot Variable = disk0:image_name
Operating Mode = sso
Primary Version = disk0:image_name
Secondary Version = disk0:image_name
Current Version = disk0:image_name
Variable Store = PrstVbl
ROMMON CV = [disk0:image_name]

Slot = 6
RP State = Standby
ISSU State = Run Version
Boot Variable = disk0:image_name
Operating Mode = sso
Primary Version = disk0:image_name
Secondary Version = disk0:image_name
Current Version = disk0:image_name

Note To complete the upgrade process, enter the issu acceptversion (optional) and issu commitversion
commands (as described in the following sections).

Accepting the New Software Version and Stopping the Rollback Process
(Optional)
You must either accept or commit the new software image, or the rollback timer will expire and stop the
upgrade process. If that occurs, the software image reverts to the previous software version. The rollback
timer is a safeguard to ensure that the upgrade process does not leave the switch nonoperational.

Note New features that are not supported by the previous image are allowed to be enabled only after you enter
the issu commitversion command.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 5-11
Chapter 5 Performing an Enhanced Fast Software Upgrade
Performing an Enhanced Fast Software Upgrade

The following command sequence shows how the issu acceptversion command stops the rollback timer
to enable you to examine the functionality of the new software image. When you are satisfied that the
new image is acceptable, enter the issu commitversion command to end the upgrade process.
Router# show issu rollback-timer
Rollback Process State = In progress
Configured Rollback Time = 00:45:00
Automatic Rollback Time = 00:37:28

Router# issu acceptversion


% Rollback timer stopped. Please issue the commitversion command.

View the rollback timer to see that the rollback process has been stopped:
Router# show issu rollback-timer
Rollback Process State = Not in progress
Configured Rollback Time = 00:45:00

Committing the New Software to the Standby


Enter the issu commitversion command to load the new software image onto the standby supervisor
engine and complete the software upgrade process. In the following example, the new image is loaded
onto the standby supervisor engine in slot 5:
Router# issu commitversion
Building configuration...
[OK]
%issu commitversion executed successfully

Note The software upgrade process is now complete. Both the active and standby supervisor engines are
running the new software version.

Verifying the Software Installation


You should verify the status of the software upgrade. If the upgrade was successful, both the active and
standby supervisor engines are running the new software version.
Router# show redundancy
Redundant System Information :
------------------------------
Available system uptime = 1 hour, 17 minutes
Switchovers system experienced = 1
Standby failures = 1
Last switchover reason = user forced

Hardware Mode = Duplex


Configured Redundancy Mode = sso
Operating Redundancy Mode = sso
Maintenance Mode = Disabled
Communications = Up

Current Processor Information :


-------------------------------
Active Location = slot 5
Current Software state = ACTIVE
Uptime in current state = 15 minutes
Image Version = Cisco IOS Software, image_name

Cisco IOS Software Configuration Guide, Release 12.2SX


5-12 OL-13013-06
Chapter 5 Performing an Enhanced Fast Software Upgrade
Performing an Enhanced Fast Software Upgrade

Technical Support: http://www.cisco.com/techsupport


Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled ...
BOOT = disk0:image_name
CONFIG_FILE =
BOOTLDR =
Configuration register = 0x2002

Peer Processor Information :


----------------------------
Standby Location = slot 6
Current Software state = STANDBY HOT
Uptime in current state = 0 minutes
Image Version = Cisco IOS Software, image_details
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled ...
BOOT = disk0:image_name
CONFIG_FILE =
BOOTLDR =
Configuration register = 0x2002

Router# show issu state detail

Slot = 5
RP State = Active
ISSU State = Init
Boot Variable = disk0:image_name
Operating Mode = sso
Primary Version = N/A
Secondary Version = N/A
Current Version = disk0:image_name
Variable Store = PrstVbl
ROMMON CV = [disk0:simage_name ]

Slot = 6
RP State = Standby
ISSU State = Init
Boot Variable = disk0:image_name
Operating Mode = sso
Primary Version = N/A
Secondary Version = N/A
Current Version = disk0:image_name

Aborting the Upgrade Process


You can manually abort the software upgrade at any stage by entering the issu abortversion command.
The upgrade process also aborts on its own if the software detects a failure.
If you abort the process after you enter the issu loadversion command, the standby supervisor engine is
reset and reloaded with the original software.
The following is an example of the issu abortversion slot image command that shows how to abort the
software upgrade process:
Router# issu abortversion 6 c7600s72033

Note Before you enter the issu abortversion command, make sure that the standby supervisor engine is Up
(STANDBY HOT [in SSO] or COLD [in RPR]).

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 5-13
Chapter 5 Performing an Enhanced Fast Software Upgrade
Performing an eFSU Upgrade on an Installed Modular Image

Performing an eFSU Upgrade on an Installed Modular Image


The following sections describe the process for performing an enhanced fast software upgrade (eFSU) on
an Installed Modular Image (ION):
Upgrading an Installed Modular Image, page 5-14
Example an eFSU Upgrade on an Installed Modular Image, page 5-15

Upgrading an Installed Modular Image


To perform an eFSU upgrade (or downgrade) of an ION VSS, perform this task:

Command Purpose
Step 1 Router# copy tftp disk_name Uses TFTP to copy the new software image to flash memory
on the active and standby chassis (disk0: and slavedisk0:).
Answer the prompts to identify the name and location of the
new software image.

Note It is best to have a console on both the active and


standby supervisor engines as you will go back and
forth between them.

Step 2 Router# install file bootdisk:filename Installs the modular image onto both the active and standby
bootdisk:/location supervisor engines.
Step 3 Router# show issu state [switch/slot][detail] Verifies the status of the upgrade process; status should
display Init.
Step 4 Router# issu loadversion new-image Starts the upgrade process by loading the installed software
image onto the active and standby chassis. The image name
includes the path of the target image to be loaded, in the
format devicename:filename.
It may take several seconds for the new image to load and
for the standby chassis to transition to SSO mode.

Note This command will cause the standby chassis to


reload.
Step 5 Router# show issu state [switch/slot][detail] Verifies the status of the upgrade process; status should
display Load Version.
Step 6 Router# issu runversion Forces a switchover, causing the standby chassis to become
active, and begins running the new software. The previously
active chassis becomes standby and boots with the old
image.
Step 7 Router# show issu state [switch/slot][detail] Verifies the status of the upgrade process; status should
display Run Version.

Cisco IOS Software Configuration Guide, Release 12.2SX


5-14 OL-13013-06
Chapter 5 Performing an Enhanced Fast Software Upgrade
Performing an eFSU Upgrade on an Installed Modular Image

Command Purpose
Step 8 Router# issu commitversion Loads the new software image onto the standby chassis.

Note This command will cause the standby chassis to


reload.
Step 9 Router# show issu state [switch/slot][detail] Verifies the status of the upgrade process; status should
display Init.
Step 10 Router# redundancy force-switchover (Optional) Forces the standby Route Processor (RP) to
assume the role of the active RP.

For an example of the eFSU upgrade on an Installed Modular Image sequence, see the Example an
eFSU Upgrade on an Installed Modular Image section on page 5-15.

Example an eFSU Upgrade on an Installed Modular Image


This example shows how to perform an an eFSU upgrade on an Installed Modular Image.
Router# copy ftp://172.18.108.26/image_name sup-bootdisk:simage_name
Router# copy ftp://172.18.108.26/image_name slavesup-bootdisk:image_name
Router# install file sup-bootdisk:image_name sup-bootdisk:/newsys
Router# install file slavesup-bootdisk:image_name slavesup-bootdisk:/newsys
Router# show issu state
Slot = 1/6
RP State = Active
ISSU State = Init
Boot Variable = bootdisk:/sys/s72033/base/image_name ,12;

Slot = 2/6
RP State = Standby
ISSU State = Init
Boot Variable = bootdisk:/sys/s72033/base/image_name ,12;
Router# issu loadversion sup-bootdisk:/newsys/s72033/base/image_name
%issu loadversion executed successfully, Standby is being reloaded
Router# show issu state
Slot = 1/6
RP State = Active
ISSU State = Load Version
Boot Variable = bootdisk:/sys/s72033/base/image_name ,12;

Slot = 2/6
RP State = Standby
ISSU State = Load Version
Boot Variable = bootdisk:/sys/s72033/base/image_name ,12;
Router# issu runversion
This command will reload the Active unit. Proceed ? [confirm]
Router# show issu state
Slot = 2/6
RP State = Active
ISSU State = Run Version
Boot Variable = bootdisk:/sys/s72033/base/image_name,12;

Slot = 1/6
RP State = Standby
ISSU State = Run Version
Boot Variable = bootdisk:/sys/s72033/base/image_name,12;

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 5-15
Chapter 5 Performing an Enhanced Fast Software Upgrade
Upgrading a Non-eFSU Image to an eFSU Image

Router# issu commitversion


%issu commitversion executed successfully
Router# show issu state
Slot = 2/6
RP State = Active
ISSU State = Init
Boot Variable = bootdisk:/sys/s72033/base/image_name,12;

Slot = 1/6
RP State = Standby
ISSU State = Init
Boot Variable = bootdisk:/sys/s72033/base/image_name,12;
Router# redundancy force-switchover

Upgrading a Non-eFSU Image to an eFSU Image


If the new Cisco IOS software image does not support eFSU, you must manually upgrade the software
image. To do so, you must upgrade the software image on the standby supervisor engine and then
perform a manual switchover so that the standby takes over processing with the new image. You can then
upgrade the software image on the previously active, and now standby, supervisor engine. For more
information, see the Software Upgrade Process Summary For a Switch section on page 5-5.

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Cisco IOS Software Configuration Guide, Release 12.2SX


5-16 OL-13013-06
C H A P T E R 6
Configuring NSF with SSO
Supervisor Engine Redundancy

This chapter describes how to configure supervisor engine redundancy using Cisco nonstop forwarding
(NSF) with stateful switchover (SSO) on Catalyst 6500 series switches.

Note For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS
Master Command List, Release 12.2SX, at this URL:
http://www.cisco.com/en/US/docs/ios/mcl/122sxmcl/12_2sx_mcl_book.html
Cisco ME 6500 Series Ethernet switches do not support redundancy.
NSF with SSO does not support IPv6 multicast traffic.

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

This chapter consists of these sections:


Understanding NSF with SSO Supervisor Engine Redundancy, page 6-1
Supervisor Engine Configuration Synchronization, page 6-9
NSF Configuration Tasks, page 6-11
Copying Files to the Redundant Supervisor Engine, page 6-20

Understanding NSF with SSO Supervisor Engine Redundancy


These sections describe supervisor engine redundancy using NSF with SSO:
NSF with SSO Supervisor Engine Redundancy Overview, page 6-2
SSO Operation, page 6-2
NSF Operation, page 6-3
Cisco Express Forwarding, page 6-3

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 6-1
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
Understanding NSF with SSO Supervisor Engine Redundancy

Multicast MLS NSF with SSO, page 6-4


Routing Protocols, page 6-4
NSF Benefits and Restrictions, page 6-8

NSF with SSO Supervisor Engine Redundancy Overview

Note The two Gigabit Ethernet interfaces on the redundant supervisor engine are always active unless you
enter the fabric switching-mode allow dcef-only command.
With a Supervisor Engine 720, if all the installed switching modules have DFCs, enter the fabric
switching-mode allow dcef-only command to disable the Ethernet ports on both supervisor
engines, which ensures that all modules are operating in dCEF mode and simplifies switchover to
the redundant supervisor engine. (CSCec05612)

Catalyst 6500 series switches support fault resistance by allowing a redundant supervisor engine to take
over if the primary supervisor engine fails. Cisco NSF works with SSO to minimize the amount of time
a network is unavailable to its users following a switchover while continuing to forward IP packets.
Catalyst 6500 series switches also support route processor redundancy (RPR) for redundancy. For
information about these redundancy modes, see Chapter 7, Configuring RPR
Supervisor Engine Redundancy.
The following events cause a switchover:
A hardware failure on the active supervisor engine
Clock synchronization failure between supervisor engines
A manual switchover

SSO Operation
SSO establishes one of the supervisor engines as active while the other supervisor engine is designated
as standby, and then SSO synchronizes information between them. A switchover from the active to the
redundant supervisor engine occurs when the active supervisor engine fails, or is removed from the
switch, or is manually shut down for maintenance. This type of switchover ensures that Layer 2 traffic
is not interrupted.
In networking devices running SSO, both supervisor engines must be running the same configuration so
that the redundant supervisor engine is always ready to assume control following a fault on the active
supervisor engine. SSO switchover also preserves FIB and adjacency entries and can forward Layer 3
traffic after a switchover. Configuration information and data structures are synchronized from the active
to the redundant supervisor engine at startup and whenever changes to the active supervisor engine
configuration occur. Following an initial synchronization between the two supervisor engines, SSO
maintains state information between them, including forwarding information.
During switchover, system control and routing protocol execution is transferred from the active
supervisor engine to the redundant supervisor engine. The switch requires between 0 and 3 seconds to
switchover from the active to the redundant supervisor engine.

Cisco IOS Software Configuration Guide, Release 12.2SX


6-2 OL-13013-06
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
Understanding NSF with SSO Supervisor Engine Redundancy

NSF Operation
Cisco NSF always runs with SSO and provides redundancy for Layer 3 traffic. NSF works with SSO to
minimize the amount of time that a network is unavailable to its users following a switchover. The main
purpose of NSF is to continue forwarding IP packets following a supervisor engine switchover.
Cisco NSF is supported by the BGP, OSPF, EIGRP, and IS-IS protocols for routing and is supported by
Cisco Express Forwarding (CEF) for forwarding. The routing protocols have been enhanced with
NSF-capability and awareness, which means that routers running these protocols can detect a switchover
and take the necessary actions to continue forwarding network traffic and to recover route information
from the peer devices. The IS-IS protocol can be configured to use state information that has been
synchronized between the active and the redundant supervisor engine to recover route information
following a switchover instead of information received from peer devices.
A networking device is NSF-aware if it is running NSF-compatible software. A device is NSF-capable
if it has been configured to support NSF; it will rebuild routing information from NSF-aware or
NSF-capable neighbors.
Each protocol depends on CEF to continue forwarding packets during switchover while the routing
protocols rebuild the Routing Information Base (RIB) tables. After the routing protocols have converged,
CEF updates the FIB table and removes stale route entries. CEF then updates the modules with the new
FIB information.

Cisco Express Forwarding


A key element of NSF is packet forwarding. In a Cisco networking device, packet forwarding is provided
by Cisco Express Forwarding (CEF). CEF maintains the FIB, and uses the FIB information that was
current at the time of the switchover to continue forwarding packets during a switchover. This feature
reduces traffic interruption during the switchover.
During normal NSF operation, CEF on the active supervisor engine synchronizes its current FIB and
adjacency databases with the FIB and adjacency databases on the redundant supervisor engine. Upon
switchover of the active supervisor engine, the redundant supervisor engine initially has FIB and
adjacency databases that are mirror images of those that were current on the active supervisor engine.
For platforms with intelligent modules, the modules will maintain the current forwarding information
over a switchover. For platforms with forwarding engines, CEF will keep the forwarding engine on the
redundant supervisor engine current with changes that are sent to it by CEF on the active supervisor
engine. The modules or forwarding engines will be able to continue forwarding after a switchover as
soon as the interfaces and a data path are available.
As the routing protocols start to repopulate the RIB on a prefix-by-prefix basis, the updates will cause
prefix-by-prefix updates to CEF, which it uses to update the FIB and adjacency databases. Existing and
new entries will receive the new version (epoch) number, indicating that they have been refreshed. The
forwarding information is updated on the modules or forwarding engine during convergence. The
supervisor engine signals when the RIB has converged. The software removes all FIB and adjacency
entries that have an epoch older than the current switchover epoch. The FIB now represents the newest
routing protocol forwarding information.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 6-3
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
Understanding NSF with SSO Supervisor Engine Redundancy

Multicast MLS NSF with SSO

Note NSF with SSO does not support IPv6 multicast traffic. If you configure support for IPv6 multicast traffic,
configure RPR redundancy.

Multicast multilayer switching (MMLS) NSF with SSO is required so that Layer 3 multicast traffic that
is switched by the router is not dropped during switchover. Without MMLS NSF with SSO, the Layer 3
multicast traffic is dropped until the multicast protocols converge.
During the switchover process, traffic is forwarded using the old database (from the previously active
supervisor engine). After multicast routing protocol convergence has taken place, the shortcuts
downloaded by the newly active route processor (RP) will be merged with the existing flows and marked
as new shortcuts. Stale entries will slowly be purged from the database allowing NSF to function during
the switchover while ensuring a smooth transition to the new cache.
Because multicast routing protocols such as Protocol Independent Multicast (PIM) sparse mode and PIM
dense mode are data driven, multicast packets are leaked to the router during switchover so that the
protocols can converge.
Because the traffic does not need to be forwarded by software for control-driven protocols such as
bidirectional PIM, the switch will continue to leak packets using the old cache for these protocols. The
router builds the mroute cache and installs the shortcuts in hardware. After the new routes are learned,
a timer is triggered to go through the database and purge the old flows.

Note Multicast MLS NSF with SSO requires NSF support in the unicast protocols.

Routing Protocols
The routing protocols run only on the RP of the active supervisor engine, and they receive routing
updates from their neighbor routers. Routing protocols do not run on the RP of the redundant supervisor
engine. Following a switchover, the routing protocols request that the NSF-aware neighbor devices send
state information to help rebuild the routing tables. Alternately, the IS-IS protocol can be configured to
synchronize state information from the active to the redundant supervisor engine to help rebuild the
routing table on the NSF-capable device in environments where neighbor devices are not NSF-aware.
Cisco NSF supports the BGP, OSPF, IS-IS, and EIGRP protocols

Note For NSF operation, the routing protocols depend on CEF to continue forwarding packets while the
routing protocols rebuild the routing information.

BGP Operation
When an NSF-capable router begins a BGP session with a BGP peer, it sends an OPEN message to the
peer. Included in the message is a statement that the NSF-capable device has graceful restart
capability. Graceful restart is the mechanism by which BGP routing peers avoid a routing flap following
a switchover. If the BGP peer has received this capability, it is aware that the device sending the message
is NSF-capable. Both the NSF-capable router and its BGP peers need to exchange the graceful restart
capability in their OPEN messages at the time of session establishment. If both the peers do not exchange
the graceful restart capability, the session will not be graceful restart capable.

Cisco IOS Software Configuration Guide, Release 12.2SX


6-4 OL-13013-06
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
Understanding NSF with SSO Supervisor Engine Redundancy

If the BGP session is lost during the supervisor engine switchover, the NSF-aware BGP peer marks all
the routes associated with the NSF-capable router as stale; however, it continues to use these routes to
make forwarding decisions for a set period of time. This functionality prevents packets from being lost
while the newly active supervisor engine is waiting for convergence of the routing information with the
BGP peers.
After a supervisor engine switchover occurs, the NSF-capable router reestablishes the session with the
BGP peer. In establishing the new session, it sends a new graceful restart message that identifies the
NSF-capable router as having restarted.
At this point, the routing information is exchanged between the two BGP peers. After this exchange is
complete, the NSF-capable device uses the routing information to update the RIB and the FIB with the
new forwarding information. The NSF-aware device uses the network information to remove stale routes
from its BGP table; the BGP protocol then is fully converged.
If a BGP peer does not support the graceful restart capability, it will ignore the graceful restart capability
in an OPEN message but will establish a BGP session with the NSF-capable device. This function will
allow interoperability with non-NSF-aware BGP peers (and without NSF functionality), but the BGP
session with non-NSF-aware BGP peers will not be graceful restart capable.

Note BGP support in NSF requires that neighbor networking devices be NSF-aware; that is, the devices must
have the graceful restart capability and advertise that capability in their OPEN message during session
establishment. If an NSF-capable router discovers that a particular BGP neighbor does not have graceful
restart capability, it will not establish an NSF-capable session with that neighbor. All other neighbors
that have graceful restart capability will continue to have NSF-capable sessions with this NSF-capable
networking device.

OSPF Operation
When an OSPF NSF-capable router performs a supervisor engine switchover, it must perform the
following tasks in order to resynchronize its link state database with its OSPF neighbors:
Relearn the available OSPF neighbors on the network without causing a reset of the neighbor
relationship
Reacquire the contents of the link state database for the network
As quickly as possible after a supervisor engine switchover, the NSF-capable router sends an OSPF NSF
signal to neighboring NSF-aware devices. Neighbor networking devices recognize this signal as an
indicator that the neighbor relationship with this router should not be reset. As the NSF-capable router
receives signals from other routers on the network, it can begin to rebuild its neighbor list.
After neighbor relationships are reestablished, the NSF-capable router begins to resynchronize its
database with all of its NSF-aware neighbors. At this point, the routing information is exchanged
between the OSPF neighbors. Once this exchange is complete, the NSF-capable device uses the routing
information to remove stale routes, update the RIB, and update the FIB with the new forwarding
information. The OSPF protocols are then fully converged.

Note OSPF NSF requires that all neighbor networking devices be NSF-aware. If an NSF-capable router
discovers that it has non-NSF-aware neighbors on a particular network segment, it will disable NSF
capabilities for that segment. Other network segments composed entirely of NSF-capable or NSF-aware
routers will continue to provide NSF capabilities.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 6-5
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
Understanding NSF with SSO Supervisor Engine Redundancy

IS-IS Operation
When an IS-IS NSF-capable router performs a supervisor engine switchover, it must perform the
following tasks in order to resynchronize its link state database with its IS-IS neighbors:
Relearn the available IS-IS neighbors on the network without causing a reset of the neighbor
relationship
Reacquire the contents of the link state database for the network
The IS-IS NSF feature offers two options when you configure NSF:
Internet Engineering Task Force (IETF) IS-IS
Cisco IS-IS
If neighbor routers on a network segment are running a software version that supports the IETF Internet
draft for router restartability, they will assist an IETF NSF router that is restarting. With IETF, neighbor
routers provide adjacency and link-state information to help rebuild the routing information following a
switchover. A benefit of IETF IS-IS configuration is operation between peer devices based on a proposed
standard.

Note If you configure IETF on the networking device, but neighbor routers are not IETF-compatible, NSF will
abort following a switchover.

If the neighbor routers on a network segment are not NSF-aware, you must use the Cisco configuration
option. The Cisco IS-IS configuration transfers both protocol adjacency and link-state information from
the active to the redundant supervisor engine. An advantage of Cisco configuration is that it does not rely
on NSF-aware neighbors.

IETF IS-IS Configuration

As quickly as possible after a supervisor engine switchover, the NSF-capable router sends IS-IS NSF
restart requests to neighboring NSF-aware devices using the IETF IS-IS configuration. Neighbor
networking devices recognize this restart request as an indicator that the neighbor relationship with this
router should not be reset, but that they should initiate database resynchronization with the restarting
router. As the restarting router receives restart request responses from routers on the network, it can
begin to rebuild its neighbor list.
After this exchange is complete, the NSF-capable device uses the link-state information to remove stale
routes, update the RIB, and update the FIB with the new forwarding information; IS-IS is then fully
converged.
The switchover from one supervisor engine to the other happens within seconds. IS-IS reestablishes its
routing table and resynchronizes with the network within a few additional seconds. At this point, IS-IS
waits for a specified interval before it will attempt a second NSF restart. During this time, the new
redundant supervisor engine will boot up and synchronize its configuration with the active supervisor
engine. The IS-IS NSF operation waits for a specified interval to ensure that connections are stable
before attempting another restart of IS-IS NSF. This functionality prevents IS-IS from attempting
back-to-back NSF restarts with stale information.

Cisco IS-IS Configuration

Using the Cisco configuration option, full adjacency and LSP information is saved, or checkpointed, to
the redundant supervisor engine. Following a switchover, the newly active supervisor engine maintains
its adjacencies using the checkpointed data, and can quickly rebuild its routing tables.

Cisco IOS Software Configuration Guide, Release 12.2SX


6-6 OL-13013-06
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
Understanding NSF with SSO Supervisor Engine Redundancy

Note Following a switchover, Cisco IS-IS NSF has complete neighbor adjacency and LSP information;
however, it must wait for all interfaces to come on line that had adjacencies prior to the switchover. If
an interface does not come on line within the allocated interface wait time, the routes learned from these
neighbor devices are not considered in routing table recalculation. IS-IS NSF provides a command to
extend the wait time for interfaces that, for whatever reason, do not come on line in a timely fashion.

The switchover from one supervisor engine to the other happens within seconds. IS-IS reestablishes its
routing table and resynchronizes with the network within a few additional seconds. At this point, IS-IS
waits for a specified interval before it will attempt a second NSF restart. During this time, the new
redundant supervisor engine will boot up and synchronize its configuration with the active supervisor
engine. After this synchronization is completed, IS-IS adjacency and LSP data is check-pointed to the
redundant supervisor engine; however, a new NSF restart will not be attempted by IS-IS until the interval
time expires. This functionality prevents IS-IS from attempting back-to-back NSF restarts.

EIGRP Operation
When an EIGRP NSF-capable router initially comes back up from an NSF restart, it has no neighbor and
its topology table is empty. The router is notified by the redundant (now active) supervisor engine when
it needs to bring up the interfaces, reacquire neighbors, and rebuild the topology and routing tables. The
restarting router and its peers must accomplish these tasks without interrupting the data traffic directed
toward the restarting router. EIGRP peer routers maintain the routes learned from the restarting router
and continue forwarding traffic through the NSF restart process.
To prevent an adjacency reset by the neighbors, the restarting router will use a new Restart (RS) bit in
the EIGRP packet header to indicate a restart. The RS bit will be set in the hello packets and in the initial
INIT update packets during the NSF restart period. The RS bit in the hello packets allows the neighbors
to be quickly notified of the NSF restart. Without seeing the RS bit, the neighbor can only detect an
adjacency reset by receiving an INIT update or by the expiration of the hello hold timer. Without the RS
bit, a neighbor does not know if the adjacency reset should be handled using NSF or the normal startup
method.
When the neighbor receives the restart indication, either by receiving the hello packet or the INIT packet,
it will recognize the restarting peer in its peer list and will maintain the adjacency with the restarting
router. The neighbor then sends it topology table to the restarting router with the RS bit set in the first
update packet indicating that it is NSF-aware and is helping out the restarting router. The neighbor does
not set the RS bit in their hello packets, unless it is also a NSF restarting neighbor.

Note A router may be NSF-aware but may not be participating in helping out the NSF restarting neighbor
because it is coming up from a cold start.

If at least one of the peer routers is NSF-aware, the restarting router would then receive updates and
rebuild its database. The restarting router must then find out if it had converged so that it can notify the
routing information base (RIB). Each NSF-aware router is required to send an end of table (EOT) marker
in the last update packet to indicate the end of the table content. The restarting router knows it has
converged when it receives the EOT marker. The restarting router can then begin sending updates.
An NSF-aware peer would know when the restarting router had converged when it receives an EOT
indication from the restarting router. The peer then scans its topology table to search for the routes with
the restarted neighbor as the source. The peer compares the route timestamp with the restart event
timestamp to determine if the route is still available. The peer then goes active to find alternate paths for
the routes that are no longer available through the restarted router.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 6-7
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
Understanding NSF with SSO Supervisor Engine Redundancy

When the restarting router has received all EOT indications from its neighbors or when the NSF converge
timer expires, EIGRP will notify the RIB of convergence. EIGRP waits for the RIB convergence signal
and then floods its topology table to all awaiting NSF-aware peers.

NSF Benefits and Restrictions


Cisco NSF provides these benefits:
Improved network availabilityNSF continues forwarding network traffic and application state
information so that user session information is maintained after a switchover.
Overall network stabilityNetwork stability may be improved with the reduction in the number of
route flaps that had been created when routers in the network failed and lost their routing tables.
Neighboring routers do not detect a link flapBecause the interfaces remain up throughout a
switchover, neighboring routers do not detect a link flap (the link does not go down and come
back up).
Prevents routing flapsBecause SSO continues forwarding network traffic in the event of a
switchover, routing flaps are avoided.
No loss of user sessionsUser sessions established before the switchover are maintained.
Cisco NSF with SSO has these restrictions:
For NSF operation, you must have SSO configured on the device.
NSF with SSO supports IP Version 4 traffic and protocols only.
Enhanced Object Tracking is not SSO-aware and cannot be used with Hot Standby Routing Protocol
(HSRP), Virtual Router Redundancy Protocol (VRRP), or Gateway Load Balancing Protocol
(GLBP) in SSO mode.
The VRRP is not SSO-aware, meaning state information is not maintained between the active and
standby supervisor engine during normal operation. VRRP and SSO can coexist but both features
work independently. Traffic that relies on VRRP may switch to the VRRP standby in the event of a
supervisor switchover.
NSF with SSO does not support L2VPN.
Except in VSS mode, Release 12.2(33)SXH and later releases support IPv4 Multiprotocol Label
Switching (MPLS) with Cisco NSF with SSO. In VSS mode, Release 12.2(33)SXI2 and later
releases support IPv4 MPLS with Cisco NSF with SSO. For additional information about supported
MPLS features, search for MPLS in the Release Notes for Cisco IOS Release 12.2(33)SXH and
Later Releases:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/release/notes/features.html
All neighboring devices participating in BGP NSF must be NSF-capable and configured for BGP
graceful restart.
OSPF NSF for virtual links is not supported.
All OSPF networking devices on the same network segment must be NSF-aware (running an NSF
software image).
For IETF IS-IS, all neighboring devices must be running an NSF-aware software image.
IPv4 Multicast NSF with SSO is supported by the PFC3 only.
The underlying unicast protocols must be NSF-aware in order to use multicast NSF with SSO.
Bidirectional forwarding detection (BFD) is not SSO-aware and is not supported by NSF with SSO.

Cisco IOS Software Configuration Guide, Release 12.2SX


6-8 OL-13013-06
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
Supervisor Engine Configuration Synchronization

Supervisor Engine Configuration Synchronization


These sections describe supervisor engine configuration synchronization:
Supervisor Engine Redundancy Guidelines and Restrictions, page 6-9
Redundancy Configuration Guidelines and Restrictions, page 6-9

Note Configuration changes made through SNMP are not synchronized to the redundant supervisor engine.
After you configure the switch through SNMP, copy the running-config file to the startup-config file on
the active supervisor engine to trigger synchronization of the startup-config file on the redundant
supervisor engine.

Supervisor Engine Redundancy Guidelines and Restrictions


These sections describe supervisor engine redundancy guidelines and restrictions:
Redundancy Configuration Guidelines and Restrictions, page 6-9
Hardware Configuration Guidelines and Restrictions, page 6-10
Configuration Mode Restrictions, page 6-11

Redundancy Configuration Guidelines and Restrictions


These guidelines and restrictions apply to all redundancy modes:
Because the Supervisor Engine 720 and Supervisor Engine 720-10GE integrate the switch fabric
functionality on the supervisor engine, a supervisor engine switchover will force a fabric switchover
as well. During the fabric switchover, data will be lost for a period of between 0.5 seconds and 1.5
seconds. When a Supervisor Engine 720 or Supervisor Engine 720-10GE is installed in a
Catalyst 6500 series switch E series chassis (such as the WS-C6509-E), Release 12.2(33)SXH
incorporates a fast fabric switchover mechanism, called enhanced hot-standby fabric switchover
time, to reduce the data loss to a period of between 50 milliseconds and 0.5 seconds for
feature-capable cards.
When a redundant supervisor engine is in standby mode, the two Gigabit Ethernet interfaces on the
redundant supervisor engine are always active unless you enter the fabric switching-mode allow
dcef-only command.
With a Supervisor Engine 720, if all the installed switching modules have DFCs, enter the fabric
switching-mode allow dcef-only command to disable the Ethernet ports on both supervisor
engines, which ensures that all modules are operating in dCEF mode and simplifies switchover to
the redundant supervisor engine.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 6-9
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
Supervisor Engine Configuration Synchronization

Using the supervisor engine Ethernet ports as routed ports or EtherChannel ports will significantly
increase the switchover time.

Note In Cisco IOS Release 12.2(33)SXI2 and later releases, the switchover recovery time is
greatly improved for EtherChannels containing the Ethernet ports of both the active and
standby supervisor engines. This improvement, which reduces the data disruption period
from up to 4 seconds to less than one second, applies only to Supervisor Engine 720 and
Supervisor Engine 32, and applies only when the EtherChannel contains no ports other than
those of the supervisor engines.

Supervisor engine redundancy does not provide supervisor engine mirroring or supervisor engine
load balancing. Only one supervisor engine is active.
Configuration changes made through SNMP are not synchronized to the redundant supervisor
engine. After you configure the switch through SNMP, copy the running-config file to the
startup-config file on the active supervisor engine to trigger synchronization of the startup-config
file on the redundant supervisor engine.
Supervisor engine switchover takes place after the failed supervisor engine completes a core dump.
A core dump can take up to 15 minutes. To get faster switchover time, disable core dump on the
supervisor engines.
If a fabric synchronization error occurs, the default behavior is to switchover to the redundant
supervisor engine. In some cases, a switchover to the redundant supervisor engine is more disruptive
than powering down the module that caused the fabric synchronization error. Enter the no fabric
error-recovery fabric-switchover command to disable the switchover and power down the module
with the fabric synchronization error.

Hardware Configuration Guidelines and Restrictions


For redundant operation, the following guidelines and restrictions must be met:
Cisco IOS running on the SP and the RP supports redundant configurations where the supervisor
engines are identical. If they are not identical, one will boot first and become active and hold the
other supervisor engine in a reset condition.
Each supervisor engine must have the resources to run the switch on its own, which means all
supervisor engine resources are duplicated, including all flash devices.
Make separate console connections to each supervisor engine. Do not connect a Y cable to the
console ports.
Both supervisor engines must have the same system image (see the Copying Files to the Redundant
Supervisor Engine section on page 6-20).

Note If a newly installed redundant supervisor engine has the Catalyst operating system installed,
remove the active supervisor engine and boot the switch with only the redundant supervisor
engine installed. Follow the procedures in the current release notes to convert the redundant
supervisor engine from the Catalyst operating system.

The configuration register in the startup-config must be set to autoboot.

Cisco IOS Software Configuration Guide, Release 12.2SX


6-10 OL-13013-06
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
NSF Configuration Tasks

Note There is no support for booting from the network.

Configuration Mode Restrictions


The following configuration restrictions apply during the startup synchronization process:
You cannot perform configuration changes during the startup (bulk) synchronization. If you attempt
to make configuration changes during this process, the following message is generated:
Config mode locked out till standby initializes

If configuration changes occur at the same time as a supervisor engine switchover, these
configuration changes are lost.

NSF Configuration Tasks


The following sections describe the configuration tasks for the NSF feature:
Configuring SSO, page 6-11
Verifying the Redundancy States, page 6-12
Configuring Multicast MLS NSF with SSO, page 6-13
Verifying Multicast NSF with SSO, page 6-13
Configuring CEF NSF, page 6-13
Verifying CEF NSF, page 6-14
Configuring BGP NSF, page 6-14
Verifying BGP NSF, page 6-14
Configuring OSPF NSF, page 6-15
Verifying OSPF NSF, page 6-16
Configuring IS-IS NSF, page 6-17
Verifying IS-IS NSF, page 6-17

Configuring SSO
You must configure SSO in order to use NSF with any supported protocol. To configure SSO, perform
this task:

Command Purpose
Step 1 Router(config)# redundancy Enters redundancy configuration mode.
Step 2 Router(config-red)# mode sso Configures SSO. When this command is entered, the
redundant supervisor engine is reloaded and begins to
work in SSO mode.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 6-11
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
NSF Configuration Tasks

Command Purpose
Step 3 Router# show running-config Verifies that SSO is enabled.
Step 4 Router# show redundancy states Displays the operating redundancy mode.

This example shows how to configure the system for SSO:


Router> enable
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# redundancy
Router(config-red)# mode sso
Router(config-red)# end

Verifying the Redundancy States


To verify the redundancy states, enter the show redundancy states command:
Router# show redundancy states
my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Primary
Unit ID = 5

Redundancy Mode (Operational) = sso


Redundancy Mode (Configured) = sso
Split Mode = Disabled
Manual Swact = Enabled
Communications = Up

client count = 29
client_notification_TMR = 30000 milliseconds
keep_alive TMR = 9000 milliseconds
keep_alive count = 1
keep_alive threshold = 18
RF debug mask = 0x0

In this example, the system cannot enter the redundancy state because the second supervisor engine is
disabled or missing:
Router# show redundancy states
my state = 13 -ACTIVE
peer state = 1 -DISABLED
Mode = Simplex
Unit = Primary
Unit ID = 1

Redundancy Mode (Operational) = sso


Redundancy Mode (Configured) = sso
Redundancy State = Non Redundant
Maintenance Mode = Disabled
Communications = Down Reason: Simplex mode

client count = 11
client_notification_TMR = 30000 milliseconds
keep_alive TMR = 4000 milliseconds
keep_alive count = 0
keep_alive threshold = 7
RF debug mask = 0x0

Cisco IOS Software Configuration Guide, Release 12.2SX


6-12 OL-13013-06
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
NSF Configuration Tasks

Configuring Multicast MLS NSF with SSO

Note The commands in this section are optional and can be used to customize your configuration. For most
users, the default settings are adequate.

Multicast MLS NSF with SSO is on by default when SSO is selected as the redundancy mode. To
configure multicast NSF with SSO parameters, perform this task:

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
Step 2 Router(config)# mls ip multicast sso convergence-time Specifies the maximum time to wait for protocol
time convergence; valid values are from 0 to 3600
seconds.
Step 3 Router(config)# mls ip multicast sso leak interval Specifies the packet leak interval; valid values are
from 0 to 3600 seconds. For PIM sparse mode and
PIM dense mode this is the period of time after
which packet leaking for existing PIM sparse mode
and PIM dense mode multicast forwarding entries
should be completed.
Step 4 Router(config)# mls ip multicast sso leak percentage Specifies the percentage of multicast flows; valid
values are from 1 to 100 percent. The value
represents the percentage of the total number of
existing PIM sparse mode and PIM dense mode
multicast flows that should be flagged for packet
leaking.

Verifying Multicast NSF with SSO


To verify the multicast NSF with SSO settings, enter the show mls ip multicast sso command:
router# show mls ip multicast sso
Multicast SSO is enabled
Multicast HA Parameters
---------------------------------------------------+------+
protocol convergence timeout 120 secs
flow leak percent 10
flow leak interval 60 secs

Configuring CEF NSF


The CEF NSF feature operates by default while the networking device is running in SSO mode. No
configuration is necessary.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 6-13
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
NSF Configuration Tasks

Verifying CEF NSF


To verify that CEF is NSF-capable, enter the show cef state command:
router# show cef state

CEF Status [RP]


CEF enabled/running
dCEF enabled/running
CEF switching enabled/running
CEF default capabilities:
Always FIB switching: yes
Default CEF switching: yes
Default dCEF switching: yes
Update HWIDB counters: no
Drop multicast packets: no
.
.
.
CEF NSF capable: yes
IPC delayed func on SSO: no
RRP state:
I am standby RRP: no
My logical slot: 0
RF PeerComm: no

Configuring BGP NSF

Note You must configure BGP graceful restart on all peer devices participating in BGP NSF.

To configure BGP for NSF, perform this task (repeat this procedure on each of the BGP NSF peer
devices):

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
Step 2 Router(config)# router bgp as-number Enables a BGP routing process, which places the
router in router configuration mode.
Step 3 Router(config-router)# bgp graceful-restart Enables the BGP graceful restart capability,
starting BGP NSF.
If you enter this command after the BGP session
has been established, you must restart the session
for the capability to be exchanged with the BGP
neighbor.
Use this command on the restarting router and all
of its peers.

Verifying BGP NSF


To verify BGP NSF, you must check that the graceful restart function is configured on the SSO-enabled
networking device and on the neighbor devices. To verify, follow these steps:

Cisco IOS Software Configuration Guide, Release 12.2SX


6-14 OL-13013-06
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
NSF Configuration Tasks

Step 1 Verify that bgp graceful-restart appears in the BGP configuration of the SSO-enabled router by
entering the show running-config command:
Router# show running-config

.
.
.
router bgp 120
.
.
.
bgp graceful-restart
neighbor 10.2.2.2 remote-as 300
.
.
.

Step 2 Repeat step 1 on each of the BGP neighbors.


Step 3 On the SSO device and the neighbor device, verify that the graceful restart function is shown as both
advertised and received, and confirm the address families that have the graceful restart capability. If no
address families are listed, then BGP NSF also will not occur:
router# show ip bgp neighbors x.x.x.x

BGP neighbor is 192.168.2.2, remote AS YY, external link


BGP version 4, remote router ID 192.168.2.2
BGP state = Established, up for 00:01:18
Last read 00:00:17, hold time is 180, keepalive interval is 60 seconds
Neighbor capabilities:
Route refresh:advertised and received(new)
Address family IPv4 Unicast:advertised and received
Address famiiy IPv4 Multicast:advertised and received
Graceful Restart Capabilty:advertised and received
Remote Restart timer is 120 seconds
Address families preserved by peer:
IPv4 Unicast, IPv4 Multicast
Received 1539 messages, 0 notifications, 0 in queue
Sent 1544 messages, 0 notifications, 0 in queue
Default minimum time between advertisement runs is 30 seconds

Configuring OSPF NSF

Note All peer devices participating in OSPF NSF must be made OSPF NSF-aware, which happens
automatically once you install an NSF software image on the device.

To configure OSPF NSF, perform this task:

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 6-15
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
NSF Configuration Tasks

Command Purpose
Step 2 Router(config)# router ospf processID Enables an OSPF routing process, which places the
router in router configuration mode.
Step 3 Router(config-router)# nsf Enables NSF operations for OSPF.

Verifying OSPF NSF


To verify OSPF NSF, you must check that the NSF function is configured on the SSO-enabled
networking device. To verify OSPF NSF, follow these steps:

Step 1 Verify that nsf appears in the OSPF configuration of the SSO-enabled device by entering the show
running-config command:
Router# show running-config

router ospf 120


log-adjacency-changes
nsf
network 192.168.20.0 0.0.0.255 area 0
network 192.168.30.0 0.0.0.255 area 1
network 192.168.40.0 0.0.0.255 area 2
.
.
.

Step 2 Enter the show ip ospf command to verify that NSF is enabled on the device:
router> show ip ospf

Routing Process "ospf 1" with ID 192.168.2.1 and Domain ID 0.0.0.1


Supports only single TOS(TOS0) routes
Supports opaque LSA
SPF schedule delay 5 secs, Hold time between two SPFs 10 secs
Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs
Number of external LSA 0. Checksum Sum 0x0
Number of opaque AS LSA 0. Checksum Sum 0x0
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
External flood list length 0
Non-Stop Forwarding enabled, last NSF restart 00:02:06 ago (took 44 secs)
Area BACKBONE(0)
Number of interfaces in this area is 1 (0 loopback)
Area has no authentication
SPF algorithm executed 3 times

Cisco IOS Software Configuration Guide, Release 12.2SX


6-16 OL-13013-06
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
NSF Configuration Tasks

Configuring IS-IS NSF


To configure IS-IS NSF, perform this task:

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
Step 2 Router(config)# router isis [tag] Enables an IS-IS routing process, which places the
router in router configuration mode.
Step 3 Router(config-router)# nsf [cisco | ietf] Enables NSF operation for IS-IS.
Enter the ietf keyword to enable IS-IS in a
homogeneous network where adjacencies with
networking devices supporting IETF draft-based
restartability is guaranteed.
Enter the cisco keyword to run IS-IS in
heterogeneous networks that might not have
adjacencies with NSF-aware networking devices.
Step 4 Router(config-router)# nsf interval [minutes] (Optional) Specifies the minimum time between
NSF restart attempts. The default time between
consecutive NSF restart attempts is 5 minutes.
Step 5 Router(config-router)# nsf t3 {manual [seconds] | (Optional) Specifies the time IS-IS will wait for the
adjacency} IS-IS database to synchronize before generating
overloaded link-state information for itself and
flooding that information out to its neighbors.
The t3 keyword applies only if you selected IETF
operation. When you specify adjacency, the router
that is restarting obtains its wait time from
neighboring devices.
Step 6 Router(config-router)# nsf interface wait seconds (Optional) Specifies how long an IS-IS NSF restart
will wait for all interfaces with IS-IS adjacencies to
come up before completing the restart. The default
is 10 seconds.

Verifying IS-IS NSF


To verify IS-IS NSF, you must check that the NSF function is configured on the SSO-enabled networking
device. To verify IS-IS NSF, follow these steps:

Step 1 Verify that nsf appears in the IS-IS configuration of the SSO-enabled device by entering the show
running-config command. The display will show either the Cisco IS-IS or the IETF IS-IS configuration.
The following display indicates that the device uses the Cisco implementation of IS-IS NSF:
Router# show running-config
<...Output Truncated...>
router isis
nsf cisco
<...Output Truncated...>

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 6-17
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
NSF Configuration Tasks

Step 2 If the NSF configuration is set to cisco, enter the show isis nsf command to verify that NSF is enabled
on the device. Using the Cisco configuration, the display output will be different on the active and
redundant RPs. The following display shows sample output for the Cisco configuration on the active RP.
In this example, note the presence of NSF restart enabled:
router# show isis nsf

NSF is ENABLED, mode 'cisco'

RP is ACTIVE, standby ready, bulk sync complete


NSF interval timer expired (NSF restart enabled)
Checkpointing enabled, no errors
Local state:ACTIVE, Peer state:STANDBY HOT, Mode:SSO

The following display shows sample output for the Cisco configuration on the standby RP. In this
example, note the presence of NSF restart enabled:
router# show isis nsf

NSF enabled, mode 'cisco'


RP is STANDBY, chkpt msg receive count:ADJ 2, LSP 7
NSF interval timer notification received (NSF restart enabled)
Checkpointing enabled, no errors
Local state:STANDBY HOT, Peer state:ACTIVE, Mode:SSO

Step 3 If the NSF configuration is set to ietf, enter the show isis nsf command to verify that NSF is enabled on
the device. The following display shows sample output for the IETF IS-IS configuration on the
networking device:
router# show isis nsf

NSF is ENABLED, mode IETF


NSF pdb state:Inactive
NSF L1 active interfaces:0
NSF L1 active LSPs:0
NSF interfaces awaiting L1 CSNP:0
Awaiting L1 LSPs:
NSF L2 active interfaces:0
NSF L2 active LSPs:0
NSF interfaces awaiting L2 CSNP:0
Awaiting L2 LSPs:
Interface:Serial3/0/2
NSF L1 Restart state:Running
NSF p2p Restart retransmissions:0
Maximum L1 NSF Restart retransmissions:3
L1 NSF ACK requested:FALSE
L1 NSF CSNP requested:FALSE
NSF L2 Restart state:Running
NSF p2p Restart retransmissions:0
Maximum L2 NSF Restart retransmissions:3
L2 NSF ACK requested:FALSE
Interface:GigabitEthernet2/0/0
NSF L1 Restart state:Running
NSF L1 Restart retransmissions:0
Maximum L1 NSF Restart retransmissions:3
L1 NSF ACK requested:FALSE
L1 NSF CSNP requested:FALSE
NSF L2 Restart state:Running
NSF L2 Restart retransmissions:0
Maximum L2 NSF Restart retransmissions:3
L2 NSF ACK requested:FALSE
L2 NSF CSNP requested:FALSE
Interface:Loopback1

Cisco IOS Software Configuration Guide, Release 12.2SX


6-18 OL-13013-06
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
NSF Configuration Tasks

NSF L1 Restart state:Running


NSF L1 Restart retransmissions:0
Maximum L1 NSF Restart retransmissions:3
L1 NSF ACK requested:FALSE
L1 NSF CSNP requested:FALSE
NSF L2 Restart state:Running
NSF L2 Restart retransmissions:0
Maximum L2 NSF Restart retransmissions:3
L2 NSF ACK requested:FALSE
L2 NSF CSNP requested:FALSE

Configuring EIGRP NSF


To configure EIGRP NSF, perform this task:

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
Step 2 Router(config)# router eigrp as-number Enables an EIGRP routing process, which places
the router in router configuration mode.
Step 3 Router(config-router)# nsf Enables EIGRP NSF.
Use this command on the restarting router and all
of its peers.

Verifying EIGRP NSF


To verify EIGRP NSF, you must check that the NSF function is configured on the SSO-enabled
networking device. To verify EIGRP NSF, follow these steps:

Step 1 Verify that nsf appears in the EIGRP configuration of the SSO-enabled device by entering the show
running-config command:
Router# show running-config
.
.
.
router eigrp 100
auto-summary
nsf
.
.
.
Step 2 Enter the show ip protocols command to verify that NSF is enabled on the device:
Router# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 100"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0
EIGRP maximum hopcount 100

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 6-19
Chapter 6 Configuring NSF with SSO Supervisor Engine Redundancy
Copying Files to the Redundant Supervisor Engine

EIGRP maximum metric variance 1


Redistributing: eigrp 100
EIGRP NSF-aware route hold timer is 240s
EIGRP NSF enabled
NSF signal timer is 20s
NSF converge timer is 120s
Automatic network summarization is in effect
Maximum path: 4
Routing for Networks:
Routing Information Sources:
Gateway Distance Last Update
Distance: internal 90 external 170

Synchronizing the Supervisor Engine Configurations


During normal operation, the startup-config and config-registers configurations are synchronized by
default between the two supervisor engines. In a switchover, the new active supervisor engine uses the
current configuration.

Copying Files to the Redundant Supervisor Engine


Enter this command to copy a file to the disk0: device on a redundant supervisor engine:
Router# copy source_device:source_filename slavedisk0:target_filename

Enter this command to copy a file to the bootflash: device on a redundant supervisor engine:
Router# copy source_device:source_filename slavesup-bootflash:target_filename

Enter this command to copy a file to the bootflash: device on a redundant RP:
Router# copy source_device:source_filename slavebootflash:target_filename

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Cisco IOS Software Configuration Guide, Release 12.2SX


6-20 OL-13013-06
C H A P T E R 7
Configuring RPR Supervisor Engine Redundancy

This chapter describes how to configure supervisor engine redundancy using route processor redundancy
(RPR).

Note For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS
Master Command List, Release 12.2SX, at this URL:
http://www.cisco.com/en/US/docs/ios/mcl/122sxmcl/12_2sx_mcl_book.html
Cisco ME 6500 Series Ethernet switches do not support redundancy.
In RPR redundancy mode, the ports on a Supervisor Engine 720-10GE in standby mode are disabled.
RPR supports IPv6 multicast traffic.
Release 12.2(33)SXH and later releases do not support Route Processor Redundancy Plus (RPR+).

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

This chapter consists of these sections:


Understanding RPR, page 7-1
Supervisor Engine Redundancy Guidelines and Restrictions, page 7-3
Configuring Supervisor Engine Redundancy, page 7-4
Performing a Fast Software Upgrade, page 7-6
Copying Files to the RP, page 7-7

Understanding RPR
These sections describe RPR supervisor engine redundancy:
Supervisor Engine Redundancy Overview, page 7-2
RPR Operation, page 7-2

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 7-1
Chapter 7 Configuring RPR Supervisor Engine Redundancy
Understanding RPR

Supervisor Engine Configuration Synchronization, page 7-3

Supervisor Engine Redundancy Overview


Catalyst 6500 series switches support fault resistance by allowing a redundant supervisor engine to take
over if the primary supervisor engine fails. RPR supports a switchover time of 2 or more minutes.
The following events cause a switchover:
A hardware failure on the active supervisor engine
Clock synchronization failure between supervisor engines
A manual switchover

RPR Operation
RPR supports the following features:
Auto-startup and bootvar synchronization between active and redundant supervisor engines
Hardware signals that detect and decide the active or redundant status of supervisor engines
Clock synchronization every 60 seconds from the active to the redundant supervisor engine
A redundant supervisor engine that is booted but not all subsystems are up: if the active supervisor
engine fails, the redundant supervisor engine become fully operational
An operational supervisor engine present in place of the failed unit becomes the redundant
supervisor engine
Support for fast software upgrade (FSU) (See the Performing a Fast Software Upgrade section on
page 7-6.)
When the switch is powered on, RPR runs between the two supervisor engines. The supervisor engine
that boots first becomes the RPR active supervisor engine. The Multilayer Switch Feature Card and
Policy Feature Card become fully operational. The route processor (RP) and PFC on the redundant
supervisor engine come out of reset but are not operational.
In a switchover, the redundant supervisor engine become fully operational and the following occurs:
All switching modules power up again
Remaining subsystems on the RP (including Layer 2 and Layer 3 protocols) are brought up
Access control lists (ACLs) are reprogrammed into supervisor engine hardware

Note In a switchover, there is a disruption of traffic because some address states are lost and then restored after
they are dynamically redetermined.

Cisco IOS Software Configuration Guide, Release 12.2SX


7-2 OL-13013-06
Chapter 7 Configuring RPR Supervisor Engine Redundancy
Supervisor Engine Redundancy Guidelines and Restrictions

Supervisor Engine Configuration Synchronization

Note Configuration changes made through SNMP are not synchronized to the redundant supervisor engine.
After you configure the switch through SNMP, copy the running-config file to the startup-config file on
the active supervisor engine to trigger synchronization of the startup-config file on the redundant
supervisor engine.

During RPR mode operation, the startup-config files and the config-register configurations are
synchronized by default between the two supervisor engines. In a switchover, the new active supervisor
engine uses the current configuration.

Supervisor Engine Redundancy Guidelines and Restrictions


These sections describe supervisor engine redundancy guidelines and restrictions:
Redundancy Guidelines and Restrictions, page 7-3
Hardware Configuration Guidelines and Restrictions, page 7-3
Configuration Mode Restrictions, page 7-4

Redundancy Guidelines and Restrictions


These guidelines and restrictions apply to RPR:
When a redundant supervisor engine is in standby mode, the two Gigabit Ethernet interfaces on the
redundant supervisor engine are always active.
Supervisor engine redundancy does not provide supervisor engine mirroring or supervisor engine
load balancing. Only one supervisor engine is active.
Configuration changes made through SNMP are not synchronized to the redundant supervisor
engine. After you configure the switch through SNMP, copy the running-config file to the
startup-config file on the active supervisor engine to trigger synchronization of the startup-config
file on the redundant supervisor engine.
Supervisor engine switchover takes place after the failed supervisor engine completes a core dump.
A core dump can take up to 15 minutes. To get faster switchover time, disable core dump on the
supervisor engines.

Hardware Configuration Guidelines and Restrictions


For redundant operation, the following guidelines and restrictions must be met:
Cisco IOS running on the SP and RP supports redundant configurations where the supervisor
engines are identical. If they are not identical, one will boot first and become active and hold the
other supervisor engine in a reset condition.
Each supervisor engine must have the resources to run the switch on its own, which means all
supervisor engine resources are duplicated, including all flash devices.
Make separate console connections to each supervisor engine. Do not connect a Y cable to the
console ports.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 7-3
Chapter 7 Configuring RPR Supervisor Engine Redundancy
Configuring Supervisor Engine Redundancy

Except during an FSU, both supervisor engines must have the same system image (see the Copying
Files to the RP section on page 7-7).

Note If a newly installed redundant supervisor engine has the Catalyst operating system installed,
remove the active supervisor engine and boot the switch with only the redundant supervisor
engine installed. Follow the procedures in the current release notes to convert the redundant
supervisor engine from the Catalyst operating system.

The configuration register must be set to 0x2102 (config-register 0x2102).

Note There is no support for booting from the network.

Configuration Mode Restrictions


The following configuration restrictions apply during the startup synchronization process:
You cannot perform configuration changes during the startup (bulk) synchronization. If you attempt
to make configuration changes during this process, the following message is generated:
Config mode locked out till standby initializes

If configuration changes occur at the same time as a supervisor engine switchover, these
configuration changes are lost.

Configuring Supervisor Engine Redundancy


These sections describe how to configure supervisor engine redundancy:
Configuring Redundancy, page 7-4
Synchronizing the Supervisor Engine Configurations, page 7-5
Displaying the Redundancy States, page 7-5

Configuring Redundancy
To configure redundancy, perform this task:

Command Purpose
Step 1 Router(config)# redundancy Enters redundancy configuration mode.
Step 2 Router(config-red)# mode rpr Configures RPR. When this command is entered, the
redundant supervisor engine is reloaded and begins to
work in RPR mode.
Step 3 Router# show running-config Verifies that RPR is enabled.
Step 4 Router# show redundancy states Displays the operating redundancy mode.

This example shows how to configure the system for RPR:

Cisco IOS Software Configuration Guide, Release 12.2SX


7-4 OL-13013-06
Chapter 7 Configuring RPR Supervisor Engine Redundancy
Configuring Supervisor Engine Redundancy

Router> enable
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# redundancy
Router(config-red)# mode rpr
Router(config-red)# end

Synchronizing the Supervisor Engine Configurations


During normal operation, the startup-config and config-registers configuration are synchronized by
default between the two supervisor engines. In a switchover, the new active supervisor engine uses the
current configuration.

Note Do not change the default auto-sync configuration.

Displaying the Redundancy States


To display the redundancy states, perform this task:

Command Purpose
Router# show redundancy states Displays the redundancy states.

This example shows how to display the redundancy states:


Router# show redundancy states
my state = 13 -ACTIVE
peer state = 8 -STANDBY HOT
Mode = Duplex
Unit = Primary
Unit ID = 1

Redundancy Mode (Operational) = Route Processor Redundancy


Redundancy Mode (Configured) = Route Processor Redundancy
Split Mode = Disabled
Manual Swact = Enabled
Communications = Up

client count = 11
client_notification_TMR = 30000 milliseconds
keep_alive TMR = 9000 milliseconds
keep_alive count = 0
keep_alive threshold = 18
RF debug mask = 0x0

In this example, the system cannot enter the redundancy state because the second supervisor engine is
disabled or missing:
Router# show redundancy states
my state = 13 -ACTIVE
peer state = 1 -DISABLED
Mode = Simplex
Unit = Primary
Unit ID = 1

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 7-5
Chapter 7 Configuring RPR Supervisor Engine Redundancy
Performing a Fast Software Upgrade

Redundancy Mode (Operational) = rpr


Redundancy Mode (Configured) = rpr
Redundancy State = Non Redundant
Maintenance Mode = Disabled
Communications = Down Reason: Simplex mode

client count = 11
client_notification_TMR = 30000 milliseconds
keep_alive TMR = 4000 milliseconds
keep_alive count = 0
keep_alive threshold = 7
RF debug mask = 0x0

Performing a Fast Software Upgrade


The fast software upgrade (FSU) procedure supported by RPR allows you to upgrade the Cisco IOS
image on the supervisor engines without reloading the system.

Note If you are performing a first-time upgrade to RPR from EHSA, you must reload both supervisor
engines. FSU from EHSA is not supported.
FSU from an IOS image to a modular IOS image is not supported. FSU from a modular IOS image
to an IOS image is not supported. (CSCsb07831)

To perform an FSU, perform this task:

Command Purpose
Step 1 Router# copy source_device:source_filename {disk0 | Copies the new Cisco IOS image to the disk0: device or
disk1}:target_filename the disk1: device on the active supervisor engine.
Or:
Router# copy source_device:source_filename Copies the new Cisco IOS image to the bootflash:
sup-bootflash:target_filename device on the active supervisor engine.
Or:
Router# copy source_device:source_filename Copies the new Cisco IOS image to the disk0: device or
{slavedisk0 | slavedisk1}:target_filename the disk1: device on the redundant supervisor engine.
Or:
Router# copy source_device:source_filename Copies the new Cisco IOS image to the bootflash:
slavesup-bootflash:target_filename device on the redundant supervisor engine.
Step 2 Router# config terminal Configures the supervisor engines to boot the new
Router(config)# config-register 0x2102 image.
Router(config)# boot system flash device:file_name
Step 3 Router# copy running-config start-config Saves the configuration.

Cisco IOS Software Configuration Guide, Release 12.2SX


7-6 OL-13013-06
Chapter 7 Configuring RPR Supervisor Engine Redundancy
Copying Files to the RP

Command Purpose
Step 4 Router# hw-module module num reset Reloads the redundant supervisor engine and brings it
back online (running the new version of the Cisco IOS
software).
Note Before reloading the redundant supervisor
engine, make sure you wait long enough to
ensure that all configuration synchronization
changes have completed.
Step 5 Router# redundancy force-switchover Conducts a manual switchover to the redundant
supervisor engine. The redundant supervisor engine
becomes the new active supervisor engine running the
new Cisco IOS image. The modules are reloaded and the
module software is downloaded from the new active
supervisor engine.
The old active supervisor engine reboots with the new
image and becomes the redundant supervisor engine.
Note To perform an EHSA to RPR FSU, use the
reload command in Step 5.

This example shows how to perform an FSU:


Router# config terminal
Router(config)# config-register 0x2102
Router(config)# boot system flash disk0:image_name
Router# copy running-config start-config
Router# hw-module module redundant_spervisor_reset
Router# redundancy force-switchover

Copying Files to the RP


Use the following command to copy a file to the bootflash: device on an active RP:
Router# copy source_device:source_filename bootflash:target_filename

Use the following command to copy a file to the bootflash: device on a redundant RP:
Router# copy source_device:source_filename slavebootflash:target_filename

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 7-7
Chapter 7 Configuring RPR Supervisor Engine Redundancy
Copying Files to the RP

Cisco IOS Software Configuration Guide, Release 12.2SX


7-8 OL-13013-06
P A R T 3

Interface and Hardware Components


C H A P T E R 8
Configuring Interfaces

This chapter describes how to configure interfaces in Cisco IOS Release 12.2SX.

Note For complete syntax and usage information for the commands used in this chapter, see these
publications:
The Cisco IOS Master Command List, Release 12.2SX, at this URL:
http://www.cisco.com/en/US/docs/ios/mcl/122sxmcl/12_2sx_mcl_book.html
The Release 12.2 publications at this URL:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_installation_and_configuratio
n_guides_list.html

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

This chapter consists of these sections:


Understanding Interface Configuration, page 8-2
Using the Interface Command, page 8-2
Configuring a Range of Interfaces, page 8-4
Defining and Using Interface-Range Macros, page 8-6
Configuring Optional Interface Features, page 8-6
Understanding Online Insertion and Removal, page 8-16
Monitoring and Maintaining Interfaces, page 8-17
Checking the Cable Status Using the TDR, page 8-19

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 8-1
Chapter 8 Configuring Interfaces
Understanding Interface Configuration

Understanding Interface Configuration


Many features in the software are enabled on a per-interface basis. When you enter the interface
command, you must specify the following information:
Interface type:
Fast Ethernet (use the fastethernet keyword)
Gigabit Ethernet (use the gigabitethernet keyword)
10-Gigabit Ethernet (use the tengigabitethernet keyword)

Note For WAN interfaces, see the configuration note for the WAN module.

Slot numberThe slot in which the module is installed. On switches supported by


Cisco IOS Release 12.2SX, slots are numbered starting with 1 from top to bottom.
Port numberThe physical port number on the module. On switches supported by
Cisco IOS Release 12.2SX, the port numbers always begin with 1. When facing the rear of the
switch, ports are numbered from the left to the right.
You can identify ports from the physical location. You also can use show commands to display
information about a specific port, or all the ports.

Using the Interface Command


Note You use the commands described in this section to configure both physical ports and logical interfaces.

These procedures apply to all interface configuration processes. Begin the interface configuration
process in global configuration mode. To use the interface command, follow these steps:

Step 1 Enter the configure terminal command at the privileged EXEC prompt to enter global configuration
mode:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)#

Step 2 In the global configuration mode, enter the interfaces command. Identify the interface type and the
number of the connector or interface card.
The following example shows how to select Fast Ethernet, slot 5, interface 1:
Router(config)# interfaces fastethernet 5/1
Router(config-if)#

Cisco IOS Software Configuration Guide, Release 12.2SX


8-2 OL-13013-06
Chapter 8 Configuring Interfaces
Using the Interface Command

Step 3 Enter the show interfaces EXEC command to see a list of all interfaces that are installed. A report is
provided for each interface that the device supports, as shown in this display:
Router# show interfaces fastethernet 5/48
FastEthernet5/48 is up, line protocol is up
Hardware is C6k 100Mb 802.3, address is 0050.f0ac.3083 (bia 0050.f0ac.3083)
Internet address is 172.20.52.18/27
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 100Mb/s
ARP type: ARPA, ARP Timeout 04:00:00
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)
5 minute input rate 1000 bits/sec, 1 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
4834677 packets input, 329545368 bytes, 0 no buffer
Received 4796465 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
51926 packets output, 15070051 bytes, 0 underruns
0 output errors, 2 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

Step 4 Enter the show hardware EXEC command to see a list of the system software and hardware:
Router# show hardware
Cisco Internetwork Operating System Software
IOS (tm) c6sup2_rp Software (c6sup2_rp-JSV-M), Version 12.1(5c)EX, EARLY DEPLOY)
Synced to mainline version: 12.1(5c)
TAC:Home:Software:Ios General:CiscoIOSRoadmap:12.1
Copyright (c) 1986-2001 by cisco Systems, Inc.
Compiled Wed 28-Mar-01 17:52 by hqluong
Image text-base: 0x30008980, data-base: 0x315D0000

ROM: System Bootstrap, Version 12.1(3r)E2, RELEASE SOFTWARE (fc1)


BOOTFLASH: c6sup2_rp Software (c6sup2_rp-JSV-M), Version 12.1(5c)EX, EARLY DEPL)

Router uptime is 2 hours, 55 minutes


System returned to ROM by power-on (SP by power-on)
Running default software

cisco Catalyst 6000 (R7000) processor with 114688K/16384K bytes of memory.


Processor board ID SAD04430J9K
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)
2 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 0x2

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 8-3
Chapter 8 Configuring Interfaces
Configuring a Range of Interfaces

Step 5 To begin configuring Fast Ethernet port 5/5, enter the interface keyword, interface type, and slot
number/port number at the privileged EXEC prompt, as shown in the following example:
Router# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router(config)# interface fastethernet 5/5
Router(config-if)#

Note You do not need to add a space between the interface type and interface number. For example,
in the preceding line you can specify either fastethernet 5/5 or fastethernet5/5.

Step 6 After each interface command, enter the interface configuration commands your particular interface
requires.
The commands you enter define the protocols and applications that will run on the interface. The
commands are collected and applied to the interface command until you enter another interface
command or press Ctrl-Z to get out of interface configuration mode and return to privileged EXEC
mode.
Step 7 After you configure an interface, check its status by using the EXEC show commands listed in
Monitoring and Maintaining Interfaces section on page 8-17.

Configuring a Range of Interfaces


The interface-range configuration mode allows you to configure multiple interfaces with the same
configuration parameters. After you enter the interface-range configuration mode, all command
parameters you enter are attributed to all interfaces within that range until you exit out of the
interface-range configuration mode.
To configure a range of interfaces with the same configuration, perform this task:

Command Purpose
Router(config)# [no] interface range Selects the range of interfaces to be configured.
{{vlan vlan_ID - vlan_ID [, vlan vlan_ID - vlan_ID]}
| {type1 slot/port - port [, type1 slot/port - port]}
| {macro_name [, macro_name]}}
1. type = fastethernet, gigabitethernet, or tengigabitethernet

When configuring a range of interfaces, note the following information:


For information about macros, see the Defining and Using Interface-Range Macros section on
page 8-6.
You can enter up to five comma-separated ranges.
You are not required to enter spaces before or after the comma.
You do not need to add a space between the interface numbers and the dash when using the
interface range command.

Cisco IOS Software Configuration Guide, Release 12.2SX


8-4 OL-13013-06
Chapter 8 Configuring Interfaces
Configuring a Range of Interfaces

The no interface range command supports VLAN interfaces.


The interface range command supports VLAN interfaces for which Layer 2 VLANs have not been
created with the interface vlan command.

Note The link state messages (LINK-3-UPDOWN and LINEPROTO-5-UPDOWN) are disabled by default.
Enter the logging event link status command on each interface where you want the messages enabled.

This example shows how to reenable all Fast Ethernet ports 5/1 to 5/5:
Router(config)# interface range fastethernet 5/1 - 5
Router(config-if)# no shutdown
Router(config-if)#
*Oct 6 08:24:35: %LINK-3-UPDOWN: Interface FastEthernet5/1, changed state to up
*Oct 6 08:24:35: %LINK-3-UPDOWN: Interface FastEthernet5/2, changed state to up
*Oct 6 08:24:35: %LINK-3-UPDOWN: Interface FastEthernet5/3, changed state to up
*Oct 6 08:24:35: %LINK-3-UPDOWN: Interface FastEthernet5/4, changed state to up
*Oct 6 08:24:35: %LINK-3-UPDOWN: Interface FastEthernet5/5, changed state to up
*Oct 6 08:24:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet5/
5, changed state to up
*Oct 6 08:24:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet5/
3, changed state to up
*Oct 6 08:24:36: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet5/
4, changed state to up
Router(config-if)#

This example shows how to use a comma to add different interface type strings to the range to reenable
all Fast Ethernet ports in the range 5/1 to 5/5 and both Gigabit Ethernet ports (1/1 and 1/2):
Router(config-if)# interface range fastethernet 5/1 - 5, gigabitethernet 1/1 - 2
Router(config-if)# no shutdown
Router(config-if)#
*Oct 6 08:29:28: %LINK-3-UPDOWN: Interface FastEthernet5/1, changed state to up
*Oct 6 08:29:28: %LINK-3-UPDOWN: Interface FastEthernet5/2, changed state to up
*Oct 6 08:29:28: %LINK-3-UPDOWN: Interface FastEthernet5/3, changed state to up
*Oct 6 08:29:28: %LINK-3-UPDOWN: Interface FastEthernet5/4, changed state to up
*Oct 6 08:29:28: %LINK-3-UPDOWN: Interface FastEthernet5/5, changed state to up
*Oct 6 08:29:28: %LINK-3-UPDOWN: Interface GigabitEthernet1/1, changed state to
up
*Oct 6 08:29:28: %LINK-3-UPDOWN: Interface GigabitEthernet1/2, changed state to
up
*Oct 6 08:29:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet5/
5, changed state to up
*Oct 6 08:29:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet5/
3, changed state to up
*Oct 6 08:29:29: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet5/
4, changed state to up
Router(config-if)#

If you enter multiple configuration commands while you are in interface-range configuration mode, each
command is executed as it is entered (they are not batched together and executed after you exit
interface-range configuration mode).
If you exit interface-range configuration mode while the commands are being executed, some commands
may not be executed on all interfaces in the range. Wait until the command prompt reappears before
exiting interface-range configuration mode.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 8-5
Chapter 8 Configuring Interfaces
Defining and Using Interface-Range Macros

Defining and Using Interface-Range Macros


You can define an interface-range macro to automatically select a range of interfaces for configuration.
Before you can use the macro keyword in the interface range macro command string, you must define
the macro.
To define an interface-range macro, perform this task:

Command Purpose
Router(config)# define interface-range macro_name Defines the interface-range macro and save it in NVRAM.
{vlan vlan_ID - vlan_ID} | {type1 slot/port - port}
[, {type1 slot/port - port}]
1. type = fastethernet, gigabitethernet, or tengigabitethernet

This example shows how to define an interface-range macro named enet_list to select Fast Ethernet ports
5/1 through 5/4:
Router(config)# define interface-range enet_list fastethernet 5/1 - 4

To show the defined interface-range macro configuration, perform this task:

Command Purpose
Router# show running-config Shows the defined interface-range macro configuration.

This example shows how to display the defined interface-range macro named enet_list:
Router# show running-config | include define
define interface-range enet_list FastEthernet5/1 - 4
Router#

To use an interface-range macro in the interface range command, perform this task:

Command Purpose
Router(config)# interface range macro macro_name Selects the interface range to be configured using the values
saved in a named interface-range macro.

This example shows how to change to the interface-range configuration mode using the interface-range
macro enet_list:
Router(config)# interface range macro enet_list
Router(config-if)#

Configuring Optional Interface Features


These sections describe optional interface features:
Configuring Ethernet Interface Speed and Duplex Mode, page 8-7
Configuring Jumbo Frame Support, page 8-10
Configuring IEEE 802.3x Flow Control, page 8-13

Cisco IOS Software Configuration Guide, Release 12.2SX


8-6 OL-13013-06
Chapter 8 Configuring Interfaces
Configuring Optional Interface Features

Configuring the Port Debounce Timer, page 8-15


Adding a Description for an Interface, page 8-16

Configuring Ethernet Interface Speed and Duplex Mode


These sections describe how to configure Ethernet port speed and duplex mode:
Speed and Duplex Mode Configuration Guidelines, page 8-7
Configuring the Ethernet Interface Speed, page 8-7
Setting the Interface Duplex Mode, page 8-8
Configuring Link Negotiation on Gigabit Ethernet Ports, page 8-8
Displaying the Speed and Duplex Mode Configuration, page 8-9

Speed and Duplex Mode Configuration Guidelines


You usually configure Ethernet port speed and duplex mode parameters to auto and allow ports to
negotiate the speed and duplex mode. If you decide to configure the port speed and duplex modes
manually, consider the following information:
If you set the Ethernet port speed to auto, the switch automatically sets the duplex mode to auto.
If you enter the no speed command, the switch automatically configures both speed and duplex to
auto.
If you configure an Ethernet port speed to a value other than auto (for example, 10, 100, or
1000 Mbps), configure the connecting port to match. Do not configure the connecting port to
negotiate the speed.
If you manually configure the Ethernet port speed to either 10 Mbps or 100 Mbps, the switch
prompts you to also configure the duplex mode on the port.

Note A LAN port cannot automatically negotiate Ethernet port speed and duplex mode if the connecting port
is configured to a value other than auto.

Caution Changing the Ethernet port speed and duplex mode configuration might shut down and reenable the
interface during the reconfiguration.

Configuring the Ethernet Interface Speed

Note If you configure the Ethernet port speed to auto on a 10/100-Mbps or 10/100/1000-Mbps Ethernet port,
both speed and duplex are autonegotiated. 10-Gigabit Ethernet ports do not support autonegotiation.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 8-7
Chapter 8 Configuring Interfaces
Configuring Optional Interface Features

To configure the port speed for a 10/100 or a 10/100/1000-Mbps Ethernet port, perform this task:

Command Purpose
Step 1 Router(config)# interface fastethernet slot/port Selects the Ethernet port to be configured.
Step 2 Router(config-if)# speed {10 | 100 | 1000 | Configures the speed of the Ethernet interface.
{auto [10 100 [1000]]}}

When configuring the port speed for a 10/100/1000-Mbps Ethernet port, note the following:
Enter the auto 10 100 keywords to restrict the negotiated speed to 10-Mbps or 100-Mbps.
The auto 10 100 1000 keywords have the same effect as the auto keyword by itself.
This example shows how to configure the speed to 100 Mbps on the Fast Ethernet port 5/4:
Router(config)# interface fastethernet 5/4
Router(config-if)# speed 100

Setting the Interface Duplex Mode

Note 10-Gigabit Ethernet and Gigabit Ethernet are full duplex only. You cannot change the duplex mode
on 10-Gigabit Ethernet or Gigabit Ethernet ports or on a 10/100/1000-Mps port configured for
Gigabit Ethernet.
If you set the port speed to auto on a 10/100-Mbps or a 10/100/1000-Mbps Ethernet port, both speed
and duplex are autonegotiated. You cannot change the duplex mode of autonegotiation ports.

To set the duplex mode of an Ethernet or Fast Ethernet port, perform this task:

Command Purpose
Step 1 Router(config)# interface fastethernet slot/port Selects the Ethernet port to be configured.
Step 2 Router(config-if)# duplex [auto | full | half] Sets the duplex mode of the Ethernet port.

This example shows how to set the duplex mode to full on Fast Ethernet port 5/4:
Router(config)# interface fastethernet 5/4
Router(config-if)# duplex full

Configuring Link Negotiation on Gigabit Ethernet Ports

Note Link negotiation does not negotiate port speed.

On Gigabit Ethernet ports, link negotiation exchanges flow-control parameters, remote fault
information, and duplex information. Link negotiation is enabled by default.
The ports on both ends of a link must have the same setting. The link will not come up if the ports at
each end of the link are set inconsistently (link negotiation enabled on one port and disabled on the other
port).

Cisco IOS Software Configuration Guide, Release 12.2SX


8-8 OL-13013-06
Chapter 8 Configuring Interfaces
Configuring Optional Interface Features

Table 8-1 shows the four possible link negotiation configurations and the resulting link status for each
configuration.

Table 8-1 Link Negotiation Configuration and Possible Link Status

Link Negotiation State Link Status


Local Port Remote Port Local Port Remote Port
Off Off Up Up
On On Up Up
Off On Up Down
On Off Down Up

To configure link negotiation on a port, perform this task:

Command Purpose
Step 1 Router(config)# interface gigabitethernet Selects the port to be configured.
slot/port
Step 2 Router(config-if)# speed nonegotiate Disables link negotiation.

This example shows how to enable link negotiation on Gigabit Ethernet port 5/4:
Router(config)# interface gigabitethernet 5/4
Router(config-if)# no speed nonegotiate

Displaying the Speed and Duplex Mode Configuration


To display the speed and duplex mode configuration for a port, perform this task:

Command Purpose
1
Router# show interfaces type slot/port [transceiver Displays the speed and duplex mode configuration. To display
properties] autonegotiation status for speed and duplex, add the
transceiver properties option.
1. type = fastethernet, gigabitethernet, or tengigabitethernet

This example shows how to display the speed and duplex mode of Fast Ethernet port 5/4:
Router# show interfaces fastethernet 5/4
FastEthernet5/4 is up, line protocol is up
Hardware is Cat6K 100Mb Ethernet, address is 0050.f0ac.3058 (bia 0050.f0ac.3058)
MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 100Mb/s
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:33, output never, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 8-9
Chapter 8 Configuring Interfaces
Configuring Optional Interface Features

5 minute output rate 0 bits/sec, 0 packets/sec


1238 packets input, 273598 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
1380 packets output, 514382 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Router#

This example shows how to display the speed and duplex autonegotiation status for Gigabit Ethernet
port 3/1:
Router# show interfaces GigabitEthernet 3/1 transceiver properties
Name : Gi3/1 Admin Speed Nego : Enable , Admin Duplex Nego : Enable
Router#

Configuring Jumbo Frame Support


These sections describe jumbo frame support:
Understanding Jumbo Frame Support, page 8-10
Configuring MTU Sizes, page 8-12

Caution The following switching modules support a maximum ingress frame size of 8092 bytes:

WS-X6516-GE-TX when operating at 100 Mbps


WS-X6148-RJ-45, WS-X6148-RJ-45V and WS-X6148-RJ21, WS-X6148-RJ21V
WS-X6248-RJ-45 and WS-X6248-TEL
WS-X6248A-RJ-45 and WS-X6248A-TEL
WS-X6348-RJ-45, WS-X6348-RJ45V and WS-X6348-RJ-21, WX-X6348-RJ21V

When jumbo frame support is configured, these modules drop ingress frames larger than 8092 bytes.

Note The WS-X6548-GE-TX, WS-X6548V-GE-TX, WS-X6148-GE-TX, and WS-X6148V-GE-TX do not


support jumbo frames.

Understanding Jumbo Frame Support


These sections describe jumbo frame support:
Jumbo Frame Support Overview, page 8-11
Ethernet Ports, page 8-11
VLAN Interfaces, page 8-12

Cisco IOS Software Configuration Guide, Release 12.2SX


8-10 OL-13013-06
Chapter 8 Configuring Interfaces
Configuring Optional Interface Features

Jumbo Frame Support Overview

A jumbo frame is a frame larger than the default Ethernet size. You enable jumbo frame support by
configuring a larger-than-default maximum transmission unit (MTU) size on a port or VLAN interface
and configuring the global LAN port MTU size.

Note Jumbo frame support fragments routed traffic in software on the route processor (RP).
Jumbo frame support does not fragment bridged traffic.

Bridged and Routed Traffic Size Check at Ingress 10, 10/100, and 100 Mbps Ethernet and 10-Gigabit Ethernet Ports
Jumbo frame support compares ingress traffic size with the global LAN port MTU size at ingress 10,
10/100, and 100 Mbps Ethernet and 10-Gigabit Ethernet LAN ports that have a nondefault MTU size
configured. The port drops traffic that is oversized. You can configure the global LAN port MTU size
(see the Configuring the Global Egress LAN Port MTU Size section on page 8-13).

Bridged and Routed Traffic Size Check at Ingress Gigabit Ethernet Ports
Gigabit Ethernet LAN ports configured with a nondefault MTU size accept frames containing packets
of any size larger than 64 bytes. With a nondefault MTU size configured, Gigabit Ethernet LAN ports
do not check for oversize ingress frames.

Routed Traffic Size Check on the PFC


For traffic that needs to be routed, Jumbo frame support on the PFC compares traffic sizes to the
configured MTU sizes and provides Layer 3 switching for jumbo traffic between interfaces configured
with MTU sizes large enough to accommodate the traffic. Between interfaces that are not configured
with large enough MTU sizes, if the do not fragment bit is not set, the PFC sends the traffic to the RP
to be fragmented and routed in software. If the do not fragment bit is set, the PFC drops the traffic.

Bridged and Routed Traffic Size Check at Egress 10, 10/100, and 100 Mbps Ethernet Ports
10, 10/100, and 100 Mbps Ethernet LAN ports configured with a nondefault MTU size transmit frames
containing packets of any size larger than 64 bytes. With a nondefault MTU size configured, 10, 10/100,
and 100 Mbps Ethernet LAN ports do not check for oversize egress frames.

Bridged and Routed Traffic Size Check at Egress Gigabit Ethernet and 10-Gigabit Ethernet Ports
Jumbo frame support compares egress traffic size with the global egress LAN port MTU size at egress
Gigabit Ethernet and 10-Gigabit Ethernet LAN ports that have a nondefault MTU size configured. The
port drops traffic that is oversized. You can configure the global LAN port MTU size (see the
Configuring the Global Egress LAN Port MTU Size section on page 8-13).

Ethernet Ports

These sections describe configuring nondefault MTU sizes on Ethernet ports:


Ethernet Port Overview, page 8-12
Layer 3 Ethernet Ports, page 8-12
Layer 2 Ethernet Ports, page 8-12

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 8-11
Chapter 8 Configuring Interfaces
Configuring Optional Interface Features

Ethernet Port Overview


Configuring a nondefault MTU size on a 10, 10/100, or 100 Mbps Ethernet port limits ingress packets
to the global LAN port MTU size and permits egress traffic of any size larger than 64 bytes.
Configuring a nondefault MTU size on a Gigabit Ethernet port permits ingress packets of any size larger
than 64 bytes and limits egress traffic to the global LAN port MTU size.
Configuring a nondefault MTU size on a 10-Gigabit Ethernet port limits ingress and egress packets to
the global LAN port MTU size.
Configuring a nondefault MTU size on an Ethernet port limits routed traffic to the configured MTU size.
You can configure the MTU size on any Ethernet port.

Layer 3 Ethernet Ports


On a Layer 3 port, you can configure an MTU size on each Layer 3 Ethernet port that is different than
the global LAN port MTU size.

Note Traffic through a Layer 3 Ethernet LAN port that is configured with a nondefault MTU size is also
subject to the global LAN port MTU size (see the Configuring the Global Egress LAN Port MTU Size
section on page 8-13).

Layer 2 Ethernet Ports


On a Layer 2 port, you can only configure an MTU size that matches the global LAN port MTU size (see
the Configuring the Global Egress LAN Port MTU Size section on page 8-13).

VLAN Interfaces

You can configure a different MTU size on each Layer 3 VLAN interface. Configuring a nondefault
MTU size on a VLAN interface limits traffic to the nondefault MTU size. You can configure the MTU
size on VLAN interfaces to support jumbo frames.

Configuring MTU Sizes


These sections describe how to configure MTU sizes:
Configuring MTU Sizes, page 8-12
Configuring the Global Egress LAN Port MTU Size, page 8-13

Configuring the MTU Size

To configure the MTU size, perform this task:

Command Purpose
Step 1 Router(config)# interface {{vlan vlan_ID} | Selects the interface to configure.
{{type1 slot/port} | {port-channel
port_channel_number} slot/port}}
Step 2 Router(config-if)# mtu mtu_size Configures the MTU size.

Cisco IOS Software Configuration Guide, Release 12.2SX


8-12 OL-13013-06
Chapter 8 Configuring Interfaces
Configuring Optional Interface Features

Command Purpose
Step 3 Router(config-if)# end Exits configuration mode.
Step 4 Router# show running-config interface Displays the running configuration.
[{gigabitethernet | tengigabitethernet}
slot/port]
1. type = fastethernet, gigabitethernet, tengigabitethernet, or ge-wan

When configuring the MTU size, note the following information:


For VLAN interfaces and Layer 3 Ethernet ports, supported MTU values are from 64 to 9216 bytes.
For Layer 2 Ethernet ports, you can configure only the global egress LAN port MTU size (see the
Configuring the Global Egress LAN Port MTU Size section on page 8-13).
This example shows how to configure the MTU size on Gigabit Ethernet port 1/2:
Router# configure terminal
Router(config)# interface gigabitethernet 1/2
Router(config-if)# mtu 9216
Router(config-if)# end

This example shows how to verify the configuration:


Router# show interface gigabitethernet 1/2
GigabitEthernet1/2 is administratively down, line protocol is down
Hardware is C6k 1000Mb 802.3, address is 0030.9629.9f88 (bia 0030.9629.9f88)
MTU 9216 bytes, BW 1000000 Kbit, DLY 10 usec,
<...Output Truncated...>
Router#

Configuring the Global Egress LAN Port MTU Size

To configure the global egress LAN port MTU size, perform this task:

Command Purpose
Step 1 Router(config)# system jumbomtu mtu_size Configures the global egress LAN port MTU size.
Note Because it would change all the interface MTU
sizes to the default (1500), rather than to any
configured nondefault interface MTU size, do not
use the system jumbomtu command to set the
MTU size to 1500. (CSCtq52016)
Step 2 Router(config)# end Exits configuration mode.

Configuring IEEE 802.3x Flow Control


Gigabit Ethernet and 10-Gigabit Ethernet ports use flow control to stop the transmission of frames to the
port for a specified time; other Ethernet ports use flow control to respond to flow-control requests.
If a Gigabit Ethernet or 10-Gigabit Ethernet port receive buffer becomes full, the port can be configured
to transmit an IEEE 802.3x pause frame that requests the remote port to delay sending frames for a
specified time. All Ethernet ports can can be configured to respond to IEEE 802.3x pause frames from
other devices.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 8-13
Chapter 8 Configuring Interfaces
Configuring Optional Interface Features

To configure flow control on an Ethernet port, perform this task:

Command Purpose
Step 1 Router(config)# interface type1 slot/port Selects the port to configure.
Step 2 Router(config-if)# flowcontrol {receive | send} Configures a port to send or respond to pause frames.
{desired | off | on}
Step 3 Router# show interfaces [type1 slot/port] Displays the flow-control configuration for all ports.
flowcontrol
1. type = fastethernet, gigabitethernet, or tengigabitethernet

When configuring flow control, note the following information:


Because auto negotiation does not work on 10 Gigbit Ethernet fiber optic ports, they respond to
pause frames by default. On 10 Gigbit Ethernet fiber optic ports, the flow-control operational mode
is always the same as administrative mode.
You cannot configure how WS-X6502-10GE 10-Gigabit Ethernet ports respond to pause frames.
WS-X6502-10GE 10-Gigabit Ethernet ports are permanently configured to respond to pause frames.
When configuring how a port responds to pause frames, note the following information:
For a Gigabit Ethernet port, when the configuration of a remote port is unknown, you can use
the receive desired keywords to configure the Gigabit Ethernet port to respond to received
pause frames. (Supported only on Gigabit Ethernet ports.)
Use the receive on keywords to configure a port to respond to received pause frames.
Use the receive off keywords to configure a port to ignore received pause frames.
When configuring transmission of pause frames on a port, note the following information:
For a Gigabit Ethernet port, when the configuration of the remote ports is unknown, you can use
the send desired keywords to configure the Gigabit Ethernet port to send pause frames.
(Supported only on Gigabit Ethernet ports.)
Use the send on keywords to configure a port to send pause frames.
Use the send off keywords to configure a port not to send pause frames.
This example shows how to turn on receive flow control and how to verify the flow-control
configuration:
Router# configure terminal
Router(config)# interface gigabitethernet 1/2
Router(config-if)# flowcontrol receive on
Router(config-if)# end
Router# show interfaces flowcontrol

Interface Send Receive


Gi1/1 Desired OFF
Gi1/2 Desired ON
Fa5/1 Not capable OFF
<output truncated>

Cisco IOS Software Configuration Guide, Release 12.2SX


8-14 OL-13013-06
Chapter 8 Configuring Interfaces
Configuring Optional Interface Features

Configuring the Port Debounce Timer


The port debounce timer delays notification of a link change. Delayed notification of a link changecan
decrease traffic loss due to network reconfiguration.
If the status of a link changes quickly from up to down and then back to up, the port debounce timer
suppresses the link status notification. If the link transitions from up to down, but does not come back
up, the port debounce timer delays the link status notification.
Delayed link status notification allows a quick port status change and recovery to occur without
triggering any of the changes that are necessary when a port stays down. The normal operation of
DWDM links sometimes includes quick port status changes and recoveries. Delayed link status
notification can also be used to mitigate link flaps because of bad cabling.
You can configure the port debounce timer separately on each LAN port.

Caution Enabling the port debounce timer causes link down detections to be delayed, resulting in loss of traffic
during the debouncing period. This situation might affect the convergence and reconvergence of some
Layer 2 and Layer 3 protocols.

To configure the debounce timer on a port, perform this task:

Command Purpose
1
Step 1 Router(config)# interface type slot/port Selects the port to configure.
Step 2 Router(config-if)# link debounce Configures the debounce timer.
[time debounce_time]
Note The default port debounce timer values provide
appropriate link change notification delay on
DWDM links.
Step 3 Router# show interfaces debounce Verifies the configuration.
1. type = fastethernet, gigabitethernet, or tengigabitethernet

When configuring the debounce timer on a port, note the following information:
The time keyword is supported only on fiber Gigabit Ethernet ports. With the time keyword, you
can increase the port debounce timer value in increments of 100 milliseconds up to
5000 milliseconds on ports operating at 1000 Mpbs over copper media.
The debounce timer recognizes 10-Gbps copper media and detects media-only changes.
Table 8-2 lists the time delay that occurs before notification of a link change.

Table 8-2 Default Port Debounce Timer Delay Times

Port Type Debounce Timer Disabled Debounce Timer Enabled


Ports operating at 10 Mpbs or 100 Mbps: 300 milliseconds 3100 milliseconds
Ports operating at 1000 Mpbs
Copper media ports: 300 milliseconds 3100 milliseconds
Fiber media ports: 10 milliseconds 100 milliseconds

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 8-15
Chapter 8 Configuring Interfaces
Understanding Online Insertion and Removal

Table 8-2 Default Port Debounce Timer Delay Times

Port Type Debounce Timer Disabled Debounce Timer Enabled


Ports operating at 10 Gbps:
Note The show interfaces debounce command does not display the default value for 10-GigabitEthernet ports when the port
debounce timer is disabled.
Except WS-X6502-10GE ports: 10 milliseconds 1000 milliseconds
WS-X6502-10GE ports: 1000 milliseconds 3100 milliseconds

This example shows how to enable the port debounce timer on Fast Ethernet port 5/12:
Router(config)# interface fastethernet 5/12
Router(config-if)# link debounce
Router(config-if)# end

This example shows how to display the port debounce timer settings:
Router# show interfaces debounce | include enable
Fa5/12 enable 3100

Adding a Description for an Interface


You can add a description about an interface to help you remember its function. The description appears
in the output of the following commands: show configuration, show running-config, and show
interfaces.
To add a description for an interface, perform this task:

Command Purpose
Router(config-if)# description string Adds a description for an interface.

This example shows how to add a description on Fast Ethernet port 5/5:
Router(config)# interface fastethernet 5/5
Router(config-if)# description Channel-group to "Marketing"

Understanding Online Insertion and Removal


The online insertion and removal (OIR) feature supported on the Catalyst 6500 series switches allows
you to remove and replace modules while the system is online. You can shut down the modules before
removal and restart it after insertion without causing other software or interfaces to shut down.

Note Do not remove or install more than one module at a time. After you remove or install a module, check
the LEDs before continuing. For module LED descriptions, see the Catalyst 6500 Series Switch
Installation Guide.

Cisco IOS Software Configuration Guide, Release 12.2SX


8-16 OL-13013-06
Chapter 8 Configuring Interfaces
Monitoring and Maintaining Interfaces

When a module has been removed or installed, the Catalyst 6500 series switch stops processing traffic
for the module and scans the system for a configuration change. Each interface type is verified against
the system configuration, and then the system runs diagnostics on the new module. There is no disruption
to normal operation during module insertion or removal.
The switch can bring only an identical replacement module online. To support OIR of an identical
module, the module configuration is not removed from the running-config file when you remove a
module.
If the replacement module is different from the removed module, you must configure it before the switch
can bring it online.
Layer 2 MAC addresses are stored in an EEPROM, which allows modules to be replaced online without
requiring the system to update switching tables and data structures. Regardless of the types of modules
installed, the Layer 2 MAC addresses do not change unless you replace the supervisor engine. If you do
replace the supervisor engine, the Layer 2 MAC addresses of all ports change to those specified in the
address allocator on the new supervisor engine.

Monitoring and Maintaining Interfaces


You can perform the tasks in the following sections to monitor and maintain interfaces:
Monitoring Interface Status, page 8-17
Clearing Counters on an Interface, page 8-18
Resetting an Interface, page 8-18
Shutting Down and Restarting an Interface, page 8-19

Monitoring Interface Status


The software contains commands that you can enter at the EXEC prompt to display information about
the interface including the version of the software and the hardware and statistics about interfaces. The
following table lists some of the interface monitoring commands. (You can display the complete list of
show commands by using the show ? command at the EXEC prompt.) These commands are described
in the Cisco IOS Interface Command Reference publication.
To display information about the interface, perform these tasks:

Command Purpose
Router# show ibc Displays current internal status information.
Router# show eobc Displays current internal out-of-band information.
Router# show interfaces [type slot/port] Displays the status and configuration of all or a specific
interface.
Router# show running-config Displays the currently running configuration.
Router# show rif Displays the current contents of the routing information field
(RIF) cache.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 8-17
Chapter 8 Configuring Interfaces
Monitoring and Maintaining Interfaces

Command Purpose
Router# show protocols [type slot/port] Displays the global (system-wide) and interface-specific
status of any configured protocol.
Router# show version Displays the hardware configuration, software version, the
names and sources of configuration files, and the boot images.

This example shows how to display the status of Fast Ethernet port 5/5:
Router# show protocols fastethernet 5/5
FastEthernet5/5 is up, line protocol is up
Router#

Clearing Counters on an Interface


To clear the interface counters shown with the show interfaces command, perform this task:

Command Purpose
Router# clear counters {{vlan vlan_ID} | Clears interface counters.
{type1 slot/port} | {port-channel channel_ID}}
1. type = fastethernet, gigabitethernet, or tengigabitethernet

This example shows how to clear and reset the counters on Fast Ethernet port 5/5:
Router# clear counters fastethernet 5/5
Clear "show interface" counters on this interface [confirm] y
Router#
*Sep 30 08:42:55: %CLEAR-5-COUNTERS: Clear counter on interface FastEthernet5/5

The clear counters command clears all the current counters from the interface unless the optional
arguments specify a specific interface.

Note The clear counters command clears counters displayed with the EXEC show interfaces command, not
counters retrieved using SNMP.

Resetting an Interface
To reset an interface, perform this task:

Command Purpose
Router# clear interface type1 slot/port Resets an interface.
1. type = fastethernet, gigabitethernet, or tengigabitethernet

This example shows how to reset Fast Ethernet port 5/5:


Router# clear interface fastethernet 5/5
Router#

Cisco IOS Software Configuration Guide, Release 12.2SX


8-18 OL-13013-06
Chapter 8 Configuring Interfaces
Checking the Cable Status Using the TDR

Shutting Down and Restarting an Interface


You can shut down an interface, which disables all functions on the specified interface and shows the
interface as unavailable on all monitoring command displays. This information is communicated to other
network servers through all dynamic routing protocols. The interface is not included in any routing
updates.
To shut down an interface and then restart it, perform this task:

Command Purpose
Step 1 Router(config)# interface {{vlan vlan_ID} | Selects the interface to be configured.
{type1 slot/port} | {port-channel channel_ID}}
Step 2 Router(config-if)# shutdown Shuts down the interface.
Step 3 Router(config-if)# no shutdown Reenables the interface.
1. type = fastethernet, gigabitethernet, or tengigabitethernet

This example shows how to shut down Fast Ethernet port 5/5:
Router(config)# interface fastethernet 5/5
Router(config-if)# shutdown
Router(config-if)#
*Sep 30 08:33:47: %LINK-5-CHANGED: Interface FastEthernet5/5, changed state to
administratively down

This example shows how to reenable Fast Ethernet port 5/5:


Router(config-if)# no shutdown
Router(config-if)#
*Sep 30 08:36:00: %LINK-3-UPDOWN: Interface FastEthernet5/5, changed state to up

To check if an interface is disabled, enter the EXEC show interfaces command. An interface that has
been shut down is shown as administratively down in the show interfaces command display.

Checking the Cable Status Using the TDR


You can check the status of copper cables using the time domain reflectometer (TDR). The TDR detects
a cable fault by sending a signal through the cable and reading the signal that is reflected back to it. All
or part of the signal can be reflected back by any number of cable defects or by the end of the cable itself.
Use the TDR to determine if the cabling is at fault if you cannot establish a link. This test is especially
important when replacing an existing switch, upgrading to Gigabit Ethernet, or installing new cables.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 8-19
Chapter 8 Configuring Interfaces
Checking the Cable Status Using the TDR

Note TDR can test cables up to a maximum length of 115 meters.


For information about which modules support the TDR, see this document:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/release/notes/ol_14271.ht
ml
TDR results are not meaningful for a link that is operating successfully.
The port must be up before running the TDR test. If the port is down, you cannot enter the test
cable-diagnostics tdr command successfully, and the following message is displayed:
Router# test cable-diagnostics tdr interface gigabitethernet2/12
% Interface Gi2/12 is administratively down
% Use 'no shutdown' to enable interface before TDR test start.

To start or stop the TDR test, perform this task:

Command Purpose
test cable-diagnostics tdr interface {interface Starts or stops the TDR test.
interface_number}

This example shows how to run the TDR-cable diagnostics:


Router # test cable-diagnostics tdr interface gigabitethernet2/1
TDR test started on interface Gi2/1
A TDR test can take a few seconds to run on an interface
Use 'show cable-diagnostics tdr' to read the TDR results.
Router #

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Cisco IOS Software Configuration Guide, Release 12.2SX


8-20 OL-13013-06
C H A P T E R 9
Configuring UDLD

This chapter describes how to configure the UniDirectional Link Detection (UDLD) protocol. Release
12.2(33)SXI4 and later releases support fast UDLD, which provides faster detection times.

Note For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS
Master Command List, Release 12.2SX, at this URL:
http://www.cisco.com/en/US/docs/ios/mcl/122sxmcl/12_2sx_mcl_book.html

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

This chapter consists of these sections:


Understanding UDLD, page 9-1
Default UDLD Configuration, page 9-4
Configuring UDLD, page 9-5

Understanding UDLD
Normal-mode UDLD classifies a link as unidirectional if the received UDLD packets do not contain
information that is correct for the neighbor device. In addition to the functionality of normal mode
UDLD, aggressive-mode UDLD puts ports into the errdisabled state if the relationship between two
previously synchronized neighbors cannot be reestablished.
These sections describe how UDLD works:
UDLD Overview, page 9-2
UDLD Aggressive Mode, page 9-3
Fast UDLD, page 9-4

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 9-1
Chapter 9 Configuring UDLD
Understanding UDLD

UDLD Overview
The Cisco-proprietary UDLD protocol monitors the physical configuration of the links between devices
and ports that support UDLD. UDLD detects the existence of unidirectional links. When a unidirectional
link is detected, UDLD puts the affected port into the errdisabled state and alerts the user. UDLD can
operate in either normal or aggressive mode.
For example, UDLD can help prevent these problems:
Spanning tree topology loops caused by unidirectional links
Incorrect cabling of unbundled fiber strands
Transceiver or link hardware malfunction
Incorrect or excessive flooding of packets
Loss of traffic without notice (also known as black holing)
UDLD is a Layer 2 protocol that works with the Layer 1 protocols to determine the physical status of a
link. At Layer 1, autonegotiation takes care of physical signaling and fault detection. UDLD performs
tasks that autonegotiation cannot perform, such as detecting the identities of neighbors and shutting
down misconnected LAN ports. When you enable both autonegotiation and UDLD, Layer 1 and Layer 2
detections work together to prevent physical and logical unidirectional connections and the
malfunctioning of other protocols.
A unidirectional link occurs whenever traffic transmitted by the local device over a link is received by
the neighbor, but traffic transmitted from the neighbor is not received by the local device. If one of the
fiber strands in a pair is disconnected, as long as autonegotiation is active, the link does not stay up. In
this case, the logical link is undetermined, and UDLD does not take any action. If both fibers are working
normally at Layer 1, then UDLD at Layer 2 determines whether those fibers are connected correctly and
whether traffic is flowing bidirectionally between the correct neighbors. This check cannot be performed
by autonegotiation, because autonegotiation operates at Layer 1.
LAN ports with UDLD enabled periodically transmit UDLD packets to neighbor devices. If the packets
are echoed back within a specific time frame (the message detection time is 3 times as long as the
message interval, plus a timeout period) and they are lacking a specific acknowledgment (echo), the link
is flagged as unidirectional and the LAN port is shut down. Devices on both ends of the link must support
UDLD in order for the protocol to successfully identify and disable unidirectional links.

Note By default, UDLD is disabled on nonfiber LAN ports to avoid sending unnecessary control traffic on this
type of media because it is often used for access ports.

Figure 9-1 shows an example of a unidirectional link condition. Switch B successfully receives traffic
from Switch A on the port. However, Switch A does not receive traffic from Switch B on the same port.
UDLD detects the problem and disables the port.

Cisco IOS Software Configuration Guide, Release 12.2SX


9-2 OL-13013-06
Chapter 9 Configuring UDLD
Understanding UDLD

Figure 9-1 Unidirectional Link

Switch A

TX RX

TX RX
Switch B

18720
UDLD Aggressive Mode
UDLD aggressive mode is disabled by default. Configure UDLD aggressive mode only on point-to-point
links between network devices that support UDLD aggressive mode. With UDLD aggressive mode
enabled, when a port on a bidirectional link that has a UDLD neighbor relationship established stops
receiving UDLD packets, UDLD tries to reestablish the connection with the neighbor. After eight failed
retries, the port is disabled.
To prevent spanning tree loops, the default nonaggressive UDLD interval of 15 seconds is fast enough
to shut down a unidirectional link before a blocking port transitions to the forwarding state (with default
spanning tree parameters).
When you enable UDLD aggressive mode, you receive additional benefits in the following situations:
One side of a link has a port stuck (both Tx and Rx).
One side of a link remains up while the other side of the link has gone down.
In these cases, UDLD aggressive mode disables one of the ports on the link, which prevents traffic from
being discarding.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 9-3
Chapter 9 Configuring UDLD
Default UDLD Configuration

Fast UDLD
Release 12.2(33)SXI4 and later releases support fast UDLD.
Fast UDLD is a per-port configuration option that supports UDLD message time intervals between 200
and 1000 milliseconds. Fast UDLD can be configured to provide subsecond unidirectional link
detection. (Without fast UDLD, the message time intervals are 7 through 90 seconds).
When configuring fast UDLD, note the following guidelines and restrictions:
Cisco IOS Software Modularity images do not support fast UDLD.
Fast UDLD is disabled by default.
Normal and aggressive mode both support fast UDLD.
Fast UDLD ports do not support the link debounce command.
Fast UDLD supports only point-to-point links between network devices that support fast UDLD.
Configure fast UDLD on at least two links between each connected network device. Fast UDLD
does not support single-link connections to neighbor devices.
Fast UDLD does not report a unidirectional link if the same error occurs simultaneously on more
than one link to the same neighbor device.
Fast UDLD cannot detect unidirectional links when the CPU utilization exceeds 60 percent.
Fast UDLD is supported on a limited number of ports:
60 ports with a Supervisor Engine 720
10 ports with a Supervisor Engine 32
10 ports with a Cisco ME 6500 Series Ethernet Switch (ME6524)

Default UDLD Configuration


Table 9-1 shows the default UDLD configuration.

Table 9-1 UDLD Default Configuration

Feature Default Value


UDLD global enable state Globally disabled.
UDLD aggressive mode Disabled.
Fast UDLD Disabled.
Fast UDLD error reporting Disabled.
UDLD per-port enable state for fiber-optic media Enabled on all Ethernet fiber-optic LAN ports.
UDLD per-port enable state for twisted-pair (copper) media Disabled on all Ethernet 10/100 and 1000BASE-TX LAN
ports.

Cisco IOS Software Configuration Guide, Release 12.2SX


9-4 OL-13013-06
Chapter 9 Configuring UDLD
Configuring UDLD

Configuring UDLD
These sections describe how to configure UDLD:
Enabling UDLD Globally, page 9-5
Enabling UDLD on LAN Ports, page 9-5
Disabling UDLD on Fiber-Optic LAN Ports, page 9-6
Configuring the Global UDLD Probe Message Interval, page 9-6
Configuring Fast UDLD, page 9-6
Resetting Disabled LAN Interfaces, page 9-7

Enabling UDLD Globally


To enable UDLD globally on all fiber-optic LAN ports, perform this task:

Command Purpose
Router(config)# udld {enable | aggressive} Enables UDLD globally on fiber-optic LAN ports.
Note This command only configures fiber-optic LAN ports.
Individual LAN port configuration overrides the
setting of this command.

Enabling UDLD on LAN Ports


By default, UDLD is disabled on nonfiber-optic LAN ports. To enable UDLD on a LAN port, perform
this task:

Command Purpose
1
Step 1 Router(config)# interface type slot/port Selects the LAN port to configure.
Step 2 Router(config-if)# udld port [aggressive] Enables UDLD on a specific LAN port. Enter the
aggressive keyword to enable aggressive mode. On a
fiber-optic LAN port, this command overrides the udld
enable global configuration command setting.
Router(config-if)# no udld port [aggressive] Disables UDLD on a nonfiber-optic LAN port.
Note On a fiber-optic LAN port, the no udld port
command reverts the LAN port configuration to
the udld enable global configuration command
setting.
Step 3 Router# show udld type1 slot/number Verifies the configuration.
1. type = fastethernet, gigabitethernet, or tengigabitethernet

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 9-5
Chapter 9 Configuring UDLD
Configuring UDLD

Disabling UDLD on Fiber-Optic LAN Ports


By default, UDLD is enabled on fiber-optic LAN ports. To disable UDLD on a fiber-optic LAN port,
perform this task:

Command Purpose
1
Step 1 Router(config)# interface type slot/port Selects the LAN port to configure.
Step 2 Router(config-if)# udld port disable Disables UDLD on a fiber-optic LAN port.
Note The no form of this command, which reverts the
port to the udld enable global configuration
command setting, is only supported on fiber-optic
LAN ports.
Step 3 Router# show udld type1 slot/number Verifies the configuration.
1. type = fastethernet, gigabitethernet, or tengigabitethernet

Configuring the Global UDLD Probe Message Interval


To configure the time between UDLD probe messages globally on all ports that are in advertisement
mode and are currently determined to be bidirectional, perform this task:

Command Purpose
Step 1 Router(config)# udld message time interval Configures the time between UDLD probe messages on
ports that are in advertisement mode and are currently
determined to be bidirectional; valid values are from 7 to
90 seconds.
Step 2 Router# show udld type1 slot/number Verifies the configuration.
1. type = fastethernet, gigabitethernet, or tengigabitethernet

Configuring Fast UDLD


Release 12.2(33)SXI4 and later releases support fast UDLD. These sections describe how to configure
fast UDLD:
Configuring Fast UDLD on a Port, page 9-7
Enabling Fast UDLD Error Reporting, page 9-7

Note You can configure fast UDLD on ports where UDLD is not enabled, but fast UDLD is active only when
UDLD is enabled on the port.

Cisco IOS Software Configuration Guide, Release 12.2SX


9-6 OL-13013-06
Chapter 9 Configuring UDLD
Configuring UDLD

Configuring Fast UDLD on a Port


To configure fast UDLD on a port, perform this task:

Command Purpose
Step 1 Router(config-if)# udld fast-hello interval Configures the fast UDLD probe message interval on a
port.
Note
See the guidelines and restrictions in the Fast
UDLD section on page 9-4.
When selecting the value, follow these guidelines:
Valid values are from 200 to 1000 milliseconds.
Adjust the fast UDLD probe message interval to
the longest interval possible that will provide the
desired link failure detection time. A shorter
message interval increases the likelihood that
UDLD will falsely report link failures under
stressful conditions.
Step 2 Router# show udld fast-hello Displays fast UDLD configuration and operational state.
1
Step 3 Router# show udld fast-hello type slot/number Verifies the per-port fast UDLD configuration and
operational state.
1. type = fastethernet, gigabitethernet, or tengigabitethernet

Enabling Fast UDLD Error Reporting


By default, fast UDLD error-disables ports with unidirectional links. You can globally enable fast UDLD
to report unidirectional links with a message displayed on the console instead of error-disabling ports
with unidirectional links.

Note When fast UDLD error reporting is enabled, you must manually take the action appropriate for the state
of the link.

To globally enable fast UDLD error reporting, perform this task:

Command Purpose
Router(config)# udld fast-hello error-reporting Enables fast UDLD error reporting.

Resetting Disabled LAN Interfaces


To reset all LAN ports that have been shut down by UDLD, perform this task:

Command Purpose
Router# udld reset Resets all LAN ports that have been shut down by UDLD.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 9-7
Chapter 9 Configuring UDLD
Configuring UDLD

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Cisco IOS Software Configuration Guide, Release 12.2SX


9-8 OL-13013-06
C H A P T E R 10
Power Management and Environmental
Monitoring

This chapter describes the power management and environmental monitoring features in
Cisco IOS Release 12.2SX.

Note For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS
Master Command List, Release 12.2SX, at this URL:
http://www.cisco.com/en/US/docs/ios/mcl/122sxmcl/12_2sx_mcl_book.html

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

This chapter consists of these sections:


Understanding Power Management, page 10-1
Understanding Environmental Monitoring, page 10-10

Understanding Power Management


These sections describe power management:
Enabling or Disabling Power Redundancy, page 10-2
Powering Modules Off and On, page 10-3
Viewing System Power Status, page 10-4
Power Cycling Modules, page 10-5
Determining System Power Requirements, page 10-5
Determining System Hardware Capacity, page 10-5
Determining Sensor Temperature Threshold, page 10-9

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 10-1
Chapter 10 Power Management and Environmental Monitoring
Understanding Power Management

Note In systems with redundant power supplies, both power supplies must be of the same wattage. The
Catalyst 6500 series switches allow you to use both AC-input and DC-input power supplies in the same
chassis. For detailed information on supported power supply configurations, see the Catalyst 6500
Series Switch Installation Guide.

The modules have different power requirements, and some configurations require more power than a
single power supply can provide. The power management feature allows you to power all installed
modules with two power supplies. However, redundancy is not supported in this configuration because
the total power drawn from both power supplies is at no time greater than the capability of one supply.
Redundant and nonredundant power configurations are described in the following sections.
To determine the power requirements for your system, see the Determining System Power
Requirements section on page 10-5.

Enabling or Disabling Power Redundancy


To disable or enable redundancy (redundancy is enabled by default) from global configuration mode,
enter the power redundancy-mode combined | redundant commands. You can change the
configuration of the power supplies to redundant or nonredundant at any time.
To disable redundancy, use the combined keyword. In a nonredundant configuration, the power available
to the system is the combined power capability of both power supplies. The system powers up as many
modules as the combined capacity allows. However, if one power supply fails and there is not enough
power for all of the previously powered-up modules, the system powers down those modules.
To enable redundancy, use the redundant keyword. In a redundant configuration, the total power drawn
from both power supplies is not greater than the capability of one power supply. If one supply
malfunctions, the other supply can take over the entire system load. When you install and power up two
power supplies, each concurrently provides approximately half of the required power to the system. Load
sharing and redundancy are enabled automatically; no software configuration is required.
To view the current state of modules and the total power available for modules, enter the show power
command (see the Viewing System Power Status section on page 10-4).
Table 10-1 describes how the system responds to changes in the power supply configuration.

Table 10-1 Effects of Power Supply Configuration Changes

Configuration Change Effect


Redundant to nonredundant System log and syslog messages are generated.
System power is increased to the combined power capability of both power
supplies.
Modules marked power-deny in the show power oper state field are brought up if
there is sufficient power.
Nonredundant to redundant (both System log and syslog messages are generated.
power supplies must be of equal System power is decreased to the power capability of one supply.
wattage)
If there is not enough power for all previously powered-up modules, some modules
are powered down and marked as power-deny in the show power oper state field.

Cisco IOS Software Configuration Guide, Release 12.2SX


10-2 OL-13013-06
Chapter 10 Power Management and Environmental Monitoring
Understanding Power Management

Table 10-1 Effects of Power Supply Configuration Changes (continued)

Configuration Change Effect


Equal wattage power supply is System log and syslog messages are generated.
inserted with redundancy enabled System power equals the power capability of one supply.
No change in module status because the power capability is unchanged.
Equal wattage power supply is System log and syslog messages are generated.
inserted with redundancy disabled
System power is increased to the combined power capability of both power
supplies.
Modules marked power-deny in the show power oper state field are brought up if
there is sufficient power.
Higher or lower wattage power System log and syslog messages are generated.
supply is inserted with redundancy
The system does not allow you to operate a power supply of different wattage even
enabled
if the wattage is higher than the installed supply. The inserted supply shuts down.
Higher or lower wattage power System log and syslog messages are generated.
supply is inserted with redundancy System power is increased to the combined power capability of both power
disabled supplies.
Modules marked power-deny in the show power oper state field are brought up if
there is sufficient power.
Power supply is removed with System log and syslog messages are generated.
redundancy enabled
No change in module status because the power capability is unchanged.
Power supply is removed with System log and syslog messages are generated.
redundancy disabled System power is decreased to the power capability of one supply.
If there is not enough power for all previously powered-up modules, some modules
are powered down and marked as power-deny in the show power oper state field.
System is booted with power System log and syslog messages are generated.
supplies of different wattage
The system does not allow you to have power supplies of different wattage installed
installed and redundancy enabled
in a redundant configuration. The lower wattage supply shuts down.
System is booted with power System log and syslog messages are generated.
supplies of equal or different System power equals the combined power capability of both power supplies.
wattage installed and redundancy
disabled The system powers up as many modules as the combined capacity allows.

Powering Modules Off and On


To power modules off and on from the CLI, perform this task:

Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
Step 2 Router(config)# power enable module slot_number Powers a module on.
Step 3 Router(config)# no power enable module slot_number Powers a module off.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 10-3
Chapter 10 Power Management and Environmental Monitoring
Understanding Power Management

Note When you enter the no power enable module slot command to power down a module, the modules
configuration is not saved.

This example shows how to power on the module in slot 3:


Router# configure terminal
Router(config)# power enable module 3

Viewing System Power Status


You can view the current power status of system components by entering the show power command as
follows:
Router# show power
system power redundancy mode = redundant
system power total = 1153.32 Watts (27.46 Amps @ 42V)
system power used = 397.74 Watts ( 9.47 Amps @ 42V)
system power available = 755.58 Watts (17.99 Amps @ 42V)
Power-Capacity PS-Fan Output Oper
PS Type Watts A @42V Status Status State
---- ------------------ ------- ------ ------ ------ -----
1 WS-CAC-2500W 1153.32 27.46 OK OK on
2 none
Pwr-Requested Pwr-Allocated Admin Oper
Slot Card-Type Watts A @42V Watts A @42V State State
---- ------------------ ------- ------ ------- ------ ----- -----
1 WS-X6K-SUP2-2GE 142.38 3.39 142.38 3.39 on on
2 - - 142.38 3.39 - -
5 WS-X6248-RJ-45 112.98 2.69 112.98 2.69 on on
Router#

You can view the current power status of a specific power supply by entering the show power command
as follows:
Router# show power status power-supply 2
Power-Capacity PS-Fan Output Oper
PS Type Watts A @42V Status Status State
---- ------------------ ------- ------ ------ ------ -----
1 WS-CAC-6000W 2672.04 63.62 OK OK on
2 WS-CAC-9000W-E 2773.68 66.04 OK OK on
Router#

You can display power supply input fields by specifying the power supply number in the command. A
new power-output field with operating mode is displayed for power supplies with more than one output
mode. Enter the show env status power-supply command as follows:
Router# show env status power-supply 1
power-supply 1:
power-supply 1 fan-fail: OK
power-supply 1 power-input 1: AC low
power-supply 1 power-output-fail: OK
Router# show env status power-supply 2
power-supply 2:
power-supply 2 fan-fail: OK
power-supply 2 power-input 1: none<<< new
power-supply 2 power-input 2: AC low<<< new
power-supply 2 power-input 3: AC high<<< new
power-supply 2 power-output: low (mode 1)<<< high for highest mode only
power-supply 2 power-output-fail: OK

Cisco IOS Software Configuration Guide, Release 12.2SX


10-4 OL-13013-06
Chapter 10 Power Management and Environmental Monitoring
Understanding Power Management

Power Cycling Modules


You can power cycle (reset) a module from global configuration mode by entering the power cycle
module slot command. The module powers off for 5 seconds, and then powers on.

Determining System Power Requirements


For information about power consumption, see the Release Notes for Cisco IOS Release 12.2SX
publication at this URL:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/release/notes/ol_14271.html

Determining System Hardware Capacity


You can determine the system hardware capacity by entering the show platform hardware capacity
command. This command displays the current system utilization of the hardware resources and displays
a list of the currently available hardware capacities, including the following:
Hardware forwarding table utilization
Switch fabric utilization
CPU(s) utilization
Memory device (flash, DRAM, NVRAM) utilization
This example shows how to display CPU capacity and utilization information for the route processor,
the switch processor, and a switching module:
Router# show platform hardware capacity cpu
CPU Resources
CPU utilization: Module 5 seconds 1 minute 5 minutes
1 RP 0% / 0% 1% 1%
1 SP 5% / 0% 5% 4%
7 69% / 0% 69% 69%
8 78% / 0% 74% 74%

Processor memory: Module Bytes: Total Used %Used


1 RP 176730048 51774704 29%
1 SP 192825092 51978936 27%
7 195111584 35769704 18%
8 195111584 35798632 18%
I/O memory: Module Bytes: Total Used %Used
1 RP 35651584 12226672 34%
1 SP 35651584 9747952 27%
7 35651584 9616816 27%
8 35651584 9616816 27%
Router#

This example shows how to display EOBC-related statistics for the route processor, the switch processor,
and the DFCs:
Router# show platform hardware capacity eobc EOBC Resources
Module Packets/sec Total packets Dropped packets
1 RP Rx: 61 108982 0
Tx: 37 77298 0
1 SP Rx: 34 101627 0
Tx: 39 115417 0
7 Rx: 5 10358 0

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 10-5
Chapter 10 Power Management and Environmental Monitoring
Understanding Power Management

Tx: 8 18543 0
8 Rx: 5 12130 0
Tx: 10 20317 0
Router#

This example shows how to display the current and peak switching utilization:
Router# show platform hardware capacity fabric Switch Fabric Resources
Bus utilization: current is 100%, peak was 100% at 12:34 12mar45
Fabric utilization: ingress egress
Module channel speed current peak current peak
1 0 20G 100% 100% 12:34 12mar45 100% 100% 12:34 12mar45
1 1 20G 12% 80% 12:34 12mar45 12% 80% 12:34 12mar45
4 0 20G 12% 80% 12:34 12mar45 12% 80% 12:34 12mar45
13 0 8G 12% 80% 12:34 12mar45 12% 80% 12:34 12mar45
Router#

This example shows how to display information about the total capacity, the bytes used, and the
percentage that is used for the flash and NVRAM resources present in the system:
Router# show platform hardware capacity flash
Flash/NVRAM Resources
Usage: Module Device Bytes: Total Used %Used
1 RP bootflash: 31981568 15688048 49%
1 SP disk0: 128577536 105621504 82%
1 SP sup-bootflash: 31981568 29700644 93%
1 SP const_nvram: 129004 856 1%
1 SP nvram: 391160 22065 6%
7 dfc#7-bootflash: 15204352 616540 4%
8 dfc#8-bootflash: 15204352 0 0%
Router#

This example shows how to display the capacity and utilization of the EARLs present in the system:
Router# show platform hardware capacity forwarding
L2 Forwarding Resources
MAC Table usage: Module Collisions Total Used %Used
6 0 65536 11 1%
VPN CAM usage: Total Used %Used
512 0 0%
L3 Forwarding Resources
FIB TCAM usage: Total Used %Used
72 bits (IPv4, MPLS, EoM) 196608 36 1%
144 bits (IP mcast, IPv6) 32768 7 1%

detail: Protocol Used %Used


IPv4 36 1%
MPLS 0 0%
EoM 0 0%

IPv6 4 1%
IPv4 mcast 3 1%
IPv6 mcast 0 0%

Adjacency usage: Total Used %Used


1048576 175 1%

Forwarding engine load:


Module pps peak-pps peak-time
6 8 1972 02:02:17 UTC Thu Apr 21 2005

Netflow Resources

Cisco IOS Software Configuration Guide, Release 12.2SX


10-6 OL-13013-06
Chapter 10 Power Management and Environmental Monitoring
Understanding Power Management

TCAM utilization: Module Created Failed %Used


6 1 0 0%
ICAM utilization: Module Created Failed %Used
6 0 0 0%

Flowmasks: Mask# Type Features


IPv4: 0 reserved none
IPv4: 1 Intf FulNAT_INGRESS NAT_EGRESS FM_GUARDIAN
IPv4: 2 unused none
IPv4: 3 reserved none

IPv6: 0 reserved none


IPv6: 1 unused none
IPv6: 2 unused none
IPv6: 3 reserved none

CPU Rate Limiters Resources


Rate limiters: Total Used Reserved %Used
Layer 3 9 4 1 44%
Layer 2 4 2 2 50%

ACL/QoS TCAM Resources


Key: ACLent - ACL TCAM entries, ACLmsk - ACL TCAM masks, AND - ANDOR,
QoSent - QoS TCAM entries, QOSmsk - QoS TCAM masks, OR - ORAND,
Lbl-in - ingress label, Lbl-eg - egress label, LOUsrc - LOU source,
LOUdst - LOU destination, ADJ - ACL adjacency

Module ACLent ACLmsk QoSent QoSmsk Lbl-in Lbl-eg LOUsrc LOUdst AND OR ADJ
6 1% 1% 1% 1% 1% 1% 0% 0% 0% 0% 1%

Router#

This example shows how to display the interface resources:


Router# show platform hardware capacity interface Interface Resources
Interface drops:
Module Total drops: Tx Rx Highest drop port: Tx Rx
9 0 2 0 48

Interface buffer sizes:


Module Bytes: Tx buffer Rx buffer
1 12345 12345
5 12345 12345
Router#

This example shows how to display SPAN information:


Router# show platform hardware capacity monitor SPAN Resources
Source sessions: 2 maximum, 0 used
Type Used
Local 0
RSPAN source 0
ERSPAN source 0
Service module 0
Destination sessions: 64 maximum, 0 used
Type Used
RSPAN destination 0
ERSPAN destination (max 24) 0
Router#

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 10-7
Chapter 10 Power Management and Environmental Monitoring
Understanding Power Management

This example shows how to display the capacity and utilization of resources for Layer 3 multicast
functionality:
Router# show platform hardware capacity multicast
L3 Multicast Resources
IPv4 replication mode: ingress
IPv6 replication mode: ingress
Bi-directional PIM Designated Forwarder Table usage: 4 total, 0 (0%) used
Replication capability: Module IPv4 IPv6
5 egress egress
9 ingress ingress
MET table Entries: Module Total Used %Used
5 65526 6 0%
Router#

This example shows how to display information about the system power capacities and utilizations:
Router# show platform hardware capacity power
Power Resources
Power supply redundancy mode: administratively combined operationally combined
System power: 1922W, 0W (0%) inline, 1289W (67%) total allocated
Powered devices: 0 total
Router#

This example shows how to display the capacity and utilization of QoS policer resources for each PFC
and DFC:
Router# show platform hardware capacity qos
QoS Policer Resources
Aggregate policers: Module Total Used %Used
1 1024 102 10%
5 1024 1 1%
Microflow policer configurations: Module Total Used %Used
1 64 32 50%
5 64 1 1%
Router#

This example shows how to display information about the key system resources:
Router# show platform hardware capacity systems System Resources
PFC operating mode: PFC3BXL
Supervisor redundancy mode: administratively rpr-plus, operationally rpr-plus
Switching Resources: Module Part number Series CEF mode
5 WS-SUP720-BASE supervisor CEF
9 WS-X6548-RJ-45 CEF256 CEF
Router#

This example shows how to display VLAN information:


Router# show platform hardware capacity vlan VLAN Resources
VLANs: 4094 total, 10 VTP, 0 extended, 0 internal, 4084 free Router#

Cisco IOS Software Configuration Guide, Release 12.2SX


10-8 OL-13013-06
Chapter 10 Power Management and Environmental Monitoring
Understanding Power Management

Determining Sensor Temperature Threshold


The system sensors set off alarms based on different temperature threshold settings. You can determine
the allowed temperatures for the sensors by using the show environment alarm threshold command.
This example shows how to determine sensor temperature thresholds:
Router> show environment alarm threshold
environmental alarm thresholds:

power-supply 1 fan-fail: OK
threshold #1 for power-supply 1 fan-fail:
(sensor value != 0) is system minor alarm power-supply 1 power-output-fail: OK
threshold #1 for power-supply 1 power-output-fail:
(sensor value != 0) is system minor alarm fantray fan operation sensor: OK
threshold #1 for fantray fan operation sensor:
(sensor value != 0) is system minor alarm operating clock count: 2
threshold #1 for operating clock count:
(sensor value < 2) is system minor alarm
threshold #2 for operating clock count:
(sensor value < 1) is system major alarm operating VTT count: 3
threshold #1 for operating VTT count:
(sensor value < 3) is system minor alarm
threshold #2 for operating VTT count:
(sensor value < 2) is system major alarm VTT 1 OK: OK
threshold #1 for VTT 1 OK:
(sensor value != 0) is system minor alarm VTT 2 OK: OK
threshold #1 for VTT 2 OK:
(sensor value != 0) is system minor alarm VTT 3 OK: OK
threshold #1 for VTT 3 OK:
(sensor value != 0) is system minor alarm clock 1 OK: OK
threshold #1 for clock 1 OK:
(sensor value != 0) is system minor alarm clock 2 OK: OK
threshold #1 for clock 2 OK:
(sensor value != 0) is system minor alarm module 1 power-output-fail: OK
threshold #1 for module 1 power-output-fail:
(sensor value != 0) is system major alarm module 1 outlet temperature: 21C
threshold #1 for module 1 outlet temperature:
(sensor value > 60) is system minor alarm
threshold #2 for module 1 outlet temperature:
(sensor value > 70) is system major alarm module 1 inlet temperature: 25C
threshold #1 for module 1 inlet temperature:
(sensor value > 60) is system minor alarm
threshold #2 for module 1 inlet temperature:
(sensor value > 70) is system major alarm module 1 device-1 temperature: 30C
threshold #1 for module 1 device-1 temperature:
(sensor value > 60) is system minor alarm
threshold #2 for module 1 device-1 temperature:
(sensor value > 70) is system major alarm module 1 device-2 temperature: 29C
threshold #1 for module 1 device-2 temperature:
(sensor value > 60) is system minor alarm
threshold #2 for module 1 device-2 temperature:
(sensor value > 70) is system major alarm module 5 power-output-fail: OK
threshold #1 for module 5 power-output-fail:
(sensor value != 0) is system major alarm module 5 outlet temperature: 26C
threshold #1 for module 5 outlet temperature:
(sensor value > 60) is system minor alarm
threshold #2 for module 5 outlet temperature:
(sensor value > 75) is system major alarm module 5 inlet temperature: 23C
threshold #1 for module 5 inlet temperature:
(sensor value > 50) is system minor alarm
threshold #2 for module 5 inlet temperature:
(sensor value > 65) is system major alarm EARL 1 outlet temperature: N/O

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 10-9
Chapter 10 Power Management and Environmental Monitoring
Understanding Environmental Monitoring

threshold #1 for EARL 1 outlet temperature:


(sensor value > 60) is system minor alarm
threshold #2 for EARL 1 outlet temperature:
(sensor value > 75) is system major alarm EARL 1 inlet temperature: N/O
threshold #1 for EARL 1 inlet temperature:
(sensor value > 50) is system minor alarm
threshold #2 for EARL 1 inlet temperature:
(sensor value > 65) is system major alarm

Understanding Environmental Monitoring


These sections describe environmental monitoring:
Overview, page 10-10
Monitoring System Environmental Status, page 10-10
Understanding LED Environmental Indications, page 10-12

Overview
Environmental monitoring of chassis components provides early-warning indications of possible
component failures, which ensures a safe and reliable system operation and avoids network
interruptions. This section describes the monitoring of these critical system components, which allows
you to identify and rapidly correct hardware-related problems in your system.

Monitoring System Environmental Status


To display system status information, enter the show environment [alarm | cooling | status |
temperature] command. The keywords display the following information:
alarmDisplays environmental alarms.
statusDisplays alarm status.
thresholdsDisplays alarm thresholds.
coolingDisplays fan tray status, chassis cooling capacity, ambient temperature, and per-slot
cooling capacity.
statusDisplays field-replaceable unit (FRU) operational status and power and temperature
information.
temperatureDisplays FRU temperature information.
To view the system status information, enter the show environment command:
Router# show environment
environmental alarms:
no alarms

Router# show environment alarm


environmental alarms:
no alarms

Router# show environment cooling


fan-tray 1:
fan-tray 1 fan-fail: failed
fan-tray 2:

Cisco IOS Software Configuration Guide, Release 12.2SX


10-10 OL-13013-06
Chapter 10 Power Management and Environmental Monitoring
Understanding Environmental Monitoring

fan 2 type: FAN-MOD-9


fan-tray 2 fan-fail: OK
chassis cooling capacity: 690 cfm
ambient temperature: 55C ["40C (user-specified)" if temp-controlled]
chassis per slot cooling capacity: 75 cfm

module 1 cooling requirement: 70 cfm


module 2 cooling requirement: 70 cfm
module 5 cooling requirement: 30 cfm
module 6 cooling requirement: 70 cfm
module 8 cooling requirement: 70 cfm
module 9 cooling requirement: 30 cfm

Router# show environment status


backplane:
operating clock count: 2
operating VTT count: 3
fan-tray 1:
fan-tray 1 type: WS-9SLOT-FAN
fan-tray 1 fan-fail: OK
VTT 1:
VTT 1 OK: OK
VTT 1 outlet temperature: 33C
VTT 2:
VTT 2 OK: OK
VTT 2 outlet temperature: 35C
VTT 3:
VTT 3 OK: OK
VTT 3 outlet temperature: 33C
clock 1:
clock 1 OK: OK, clock 1 clock-inuse: in-use
clock 2:
clock 2 OK: OK, clock 2 clock-inuse: not-in-use
power-supply 1:
power-supply 1 fan-fail: OK
power-supply 1 power-output-fail: OK
module 1:
module 1 power-output-fail: OK
module 1 outlet temperature: 30C
module 1 device-2 temperature: 35C
RP 1 outlet temperature: 35C
RP 1 inlet temperature: 36C
EARL 1 outlet temperature: 33C
EARL 1 inlet temperature: 31C
module 2:
module 2 power-output-fail: OK
module 2 outlet temperature: 31C
module 2 inlet temperature: 29C
module 3:
module 3 power-output-fail: OK
module 3 outlet temperature: 36C
module 3 inlet temperature: 29C
module 4:
module 4 power-output-fail: OK
module 4 outlet temperature: 32C
module 4 inlet temperature: 32C
module 5:
module 5 power-output-fail: OK
module 5 outlet temperature: 39C
module 5 inlet temperature: 34C
module 7:
module 7 power-output-fail: OK
module 7 outlet temperature: 42C
module 7 inlet temperature: 29C

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 10-11
Chapter 10 Power Management and Environmental Monitoring
Understanding Environmental Monitoring

EARL 7 outlet temperature: 45C


EARL 7 inlet temperature: 32C
module 9:
module 9 power-output-fail: OK
module 9 outlet temperature: 41C
module 9 inlet temperature: 36C
EARL 9 outlet temperature: 33C
EARL 9 inlet temperature: N/O

Understanding LED Environmental Indications


All modules have an LED labeled STATUS. There are LEDs on power supplies and fan trays that indicate
problems. A nongreen LED indicates a problem.
Supervisor engines have an LED labeled SYSTEM that indicates alarms. The alarm can be on a
supervisor engine, module, power supply, fan tray, or backplane.
In non-VSS mode, the SYSTEM LED indicates the following:
With one supervisor engine, the SYSTEM LED on the active supervisor engine indicates the alarm
status for the chassis.
With two supervisor engines, the SYSTEM LED on the standby supervisor engine indicates the
alarm status of the standby supervisor engine.
In VSS mode, the SYSTEM LED indicates the following:
With one supervisor engine in each chassis, the SYSTEM LED on the active chassis supervisor
engine indicates the alarm status for both chassis. The SYSTEM LED on the standby chassis
supervisor engine indicates the alarm status of the standby chassis.
With two supervisor engines in each chassis, the SYSTEM LED on the active-chassis, in-chassis
active supervisor engine indicates system status for both chassis.
With two supervisor engines in each chassis, the SYSTEM LED on the standby-chassis in-chassis
active supervisor engine indicates the alarm status of the standby chassis.
With two supervisor engines in each chassis, the SYSTEM LEDs on in-chassis standby supervisor
engines are turned off.
The SYSTEM LED can indicate two alarm types: major and minor. Major alarms indicate a critical
problem that could lead to the system being shut down. Minor alarms are for informational purposes
only, alerting you to a problem that could turn critical if corrective action is not taken.
Temperature sensors monitor key components. The temperature sensors are polled every 30 seconds. If
the sensed temperature falls below the alarm threshold, the alarm is immediately cancelled.
For major alarms, there is a delay before any automatic actions occur to protect the switch. The delay is
5 minutes for a major alarm from a board sensor, and a 1 minute for a major alarm from an ASIC sensor.
Table 10-2 lists the environmental indicators for the supervisor engine and switching modules.

Note See the Catalyst 6500 Series Switch Supervisor Engine Guide for additional information on LEDs,
including the supervisor engine STATUS LED.

Cisco IOS Software Configuration Guide, Release 12.2SX


10-12 OL-13013-06
Chapter 10 Power Management and Environmental Monitoring
Understanding Environmental Monitoring

Table 10-2 Environmental Monitoring for Supervisor Engine and Switching Modules

SYSTEM
Alarm LED
Component Type Color Action
VSS mode supervisor engine Major Red Generates syslog message and an SNMP trap. After the time delay, these
temperature sensor exceeds actions happen:
major threshold
With a redundant supervisor engine in the same chassis, the peer
chassis becomes active and the previously active supervisor engine
drops to ROMMON. With Release 12.2(33)SXI4 and later releases, if
the fan tray is faulty or absent, the chassis with fault shuts down. The
peer chassis continues operating.
With a single supervisor engine in the chassis, the supervisor engine
drops to ROMMON and the peer chassis becomes active. With
Release 12.2(33)SXI4 and later releases, if the fan tray is faulty or
absent, the faulty chassis shuts down.
Non-VSS mode supervisor Major Red Generates syslog message and an SNMP trap. After the time delay, these
engine temperature sensor actions happen:
exceeds major threshold
With a redundant supervisor engine in the same chassis, the redundant
supervisor engine becomes active and the previously active
supervisor engine drops to ROMMON. With Release 12.2(33)SXI4
and later releases, if the fan tray is faulty or absent, the chassis shuts
down.
With a single supervisor engine, the supervisor engine drops to
ROMMON. With Release 12.2(33)SXI4 and later releases, if the fan
tray is faulty or absent, the chassis shuts down.
Supervisor engine Minor Orange Generates syslog message and an SNMP trap.
temperature sensor exceeds Monitors the condition.
minor threshold
Redundant supervisor engine Major Red Generates syslog message and an SNMP trap.
temperature sensor exceeds
If a major alarm is generated and the overtemperature condition is not
major or minor threshold
corrected, the system shuts down after 5 minutes.
Minor Orange Monitors the condition if a minor alarm is generated.
Switching module Major Red Generates syslog message and SNMP.
temperature sensor exceeds
Powers down the module (see the Understanding Power Management
major threshold
section on page 10-1).
Switching module Minor Orange Generates syslog message and an SNMP trap.
temperature sensor exceeds
Monitors the condition.
minor threshold

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 10-13
Chapter 10 Power Management and Environmental Monitoring
Understanding Environmental Monitoring

Cisco IOS Software Configuration Guide, Release 12.2SX


10-14 OL-13013-06
CH A P T E R 11
Configuring EnergyWise

EnergyWise is a Cisco energy management architecture that provides a common approach to


configuring, reporting and managing the power consumed by Cisco switches and attached devices. With
Cisco EnergyWise, power can be managed on a network, sub-network or network element level.

Release Feature Modification


12.2(33)SXI4 EnergyWise Phase2 introduced on Catalyst 6500 Series

EnergyWise configuration procedures for the Catalyst 6500 Series are documented in the Cisco
EnergyWise Configuration Guide, EnergyWise Phase 2 located at the following URL:
http://www.cisco.com/en/US/docs/switches/lan/energywise/phase2/ios/configuration/guide/ew_v2.html
Additional Cisco EnergyWise documents, such as White Papers, Data Sheets, FAQs, andare located at
the following URL:
http://www.cisco.com/en/US/products/ps10195/
Cisco EnergyWise Orchestrator configuration guides are located at the following URL:
http://www.cisco.com/en/US/products/ps10195/products_installation_and_configuration_guides_list.h
tml

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 11-1
Cisco IOS Software Configuration Guide, Release 12.2SX
2 OL-13013-06
C H A P T E R 12
Configuring Online Diagnostics

This chapter describes how to configure the online diagnostics in Cisco IOS Release 12.2SX.

Note For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS
Master Command List, Release 12.2SX, at this URL:
http://www.cisco.com/en/US/docs/ios/mcl/122sxmcl/12_2sx_mcl_book.html

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

This chapter consists of these sections:


Understanding Online Diagnostics, page 12-1
Configuring Online Diagnostics, page 12-2
Running Online Diagnostic Tests, page 12-5
Performing Memory Tests, page 12-12

Understanding Online Diagnostics


With online diagnostics, you can test and verify the hardware functionality of the switch while the switch
is connected to a live network.
The online diagnostics contain packet switching tests that check different hardware components and
verify the data path and control signals. Disruptive online diagnostic tests, such as the built-in self-test
(BIST) and the disruptive loopback test, and nondisruptive online diagnostic tests, such as packet
switching, run during bootup, module online insertion and removal (OIR), and system reset. The
nondisruptive online diagnostic tests run as part of background health monitoring. Either disruptive or
nondisruptive tests can be run at the users request (on-demand).
The online diagnostics detect problems in the following areas:
Hardware components
Interfaces (GBICs, Ethernet ports, and so forth)

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 12-1
Chapter 12 Configuring Online Diagnostics
Configuring Online Diagnostics

Connectors (loose connectors, bent pins, and so forth)


Solder joints
Memory (failure over time)
Online diagnostics is one of the requirements for the high availability feature. High availability is a set
of quality standards that seek to limit the impact of equipment failures on the network. A key part of high
availability is detecting hardware failures and taking corrective action while the switch runs in a live
network. Online diagnostics in high availability detect hardware failures and provide feedback to high
availability software components to make switchover decisions.
Online diagnostics are categorized as bootup, on-demand, schedule, or health-monitoring diagnostics.
Bootup diagnostics run during bootup; on-demand diagnostics run from the CLI; schedule diagnostics
run at user-designated intervals or specified times when the switch is connected to a live network; and
health-monitoring runs in the background.

Configuring Online Diagnostics


These sections describe how to configure online diagnostics:
Setting Bootup Online Diagnostics Level, page 12-2
Configuring On-Demand Online Diagnostics, page 12-3
Scheduling Online Diagnostics, page 12-4

Setting Bootup Online Diagnostics Level


You can set the bootup diagnostics level as minimal or complete or you can bypass the bootup
diagnostics entirely. Enter the complete keyword to run all diagnostic tests; enter the minimal keyword
to run only EARL tests and loopback tests for all ports in the switch. Enter the no form of the command
to bypass all diagnostic tests. The default bootup diagnositcs level is minimal.
To set the bootup diagnostic level, perform this task:

Command Purpose
Router(config)# diagnostic bootup level {minimal | Sets the bootup diagnostic level.
complete}

This example shows how to set the bootup online diagnostic level:
Router(config)# diagnostic bootup level complete
Router(config)#

This example shows how to display the bootup online diagnostic level:
Router(config)# do show diagnostic bootup level
Router(config)#

Cisco IOS Software Configuration Guide, Release 12.2SX


12-2 OL-13013-06
Chapter 12 Configuring Online Diagnostics
Configuring Online Diagnostics

Configuring On-Demand Online Diagnostics


You can run the on-demand online diagnostic tests from the CLI. You can set the execution action to
either stop or continue the test when a failure is detected or to stop the test after a specific number of
failures occur by using the failure count setting. You can configure a test to run multiple times using the
iteration setting.
You should run packet-switching tests before memory tests.

Note Do not use the diagnostic start all command until all of the following steps are completed.

Because some on-demand online diagnostic tests can affect the outcome of other tests, you should
perform the tests in the following order:
1. Run the nondisruptive tests.
2. Run all tests in the relevant functional area.
3. Run the TestTrafficStress test.
4. Run the TestEobcStressPing test.
5. Run the exhaustive-memory tests.
To run on-demand online diagnostic tests, perform this task:

Step 1 Run the nondisruptive tests.


To display the available tests and their attributes, and determine which commands are in the
nondisruptive category, enter the show diagnostic content command.
Step 2 Run all tests in the relevant functional area.
Packet-switching tests fall into specific functional areas. When a problem is suspected in a particular
functional area, run all tests in that functional area. If you are unsure about which functional area you
need to test, or if you want to run all available tests, enter the complete keyword.
Step 3 Run the TestTrafficStress test.
This is a disruptive packet-switching test. This test switches packets between pairs of ports at line rate
for the purpose of stress testing. During this test all of the ports are shut down, and you may see link
flaps. The link flaps will recover after the test is complete. The test takes several minutes to complete.
Disable all health-monitoring tests f before running this test by using the no diagnostic monitor module
number test all command.
Step 4 Run the TestEobcStressPing test.
This is a disruptive test and tests the Ethernet over backplane channel (EOBC) connection for the
module. The test takes several minutes to complete. You cannot run any of the packet-switching tests
described in previous steps after running this test. However, you can run tests described in subsequent
steps after running this test.
Disable all health-monitoring tests before running this test by using the no diagnostic monitor module
number test all command. The EOBC connection is disrupted during this test and will cause the
health-monitoring tests to fail and take recovery action.
Step 5 Run the exhaustive-memory tests.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 12-3
Chapter 12 Configuring Online Diagnostics
Configuring Online Diagnostics

Before running the exhaustive-memory tests, all health-monitoring tests should be disabled because the
tests will fail with health monitoring enabled and the switch will take recovery action. Disable the
health-monitoring diagnostic tests by using the no diagnostic monitor module number test all
command.
Perform the exhaustive-memory tests in the following order:
1. TestFibTcamSSRAM
2. TestAclQosTcam
3. TestNetFlowTcam
4. TestAsicMemory
5. TestAsicMemory
You must reboot the after running the exhaustive-memory tests before it is operational again. You cannot
run any other tests on the switch after running the exhaustive-memory tests. Do not save the
configuration when rebooting as it will have changed during the tests. After the reboot, reenable the
health-monitoring tests using the diagnostic monitor module number test all command.

To set the bootup diagnostic level, perform this task:

Command Purpose
Router# diagnostic ondemand {iteration Configures on-demand diagnostic tests to run, how many
iteration_count} | {action-on-error {continue | times to run (iterations), and what action to take when errors
stop}[error_count]}
are found.

This example shows how to set the on-demand testing iteration count:
Router# diagnostic ondemand iteration 3
Router#

This example shows how to set the execution action when an error is detected:
Router# diagnostic ondemand action-on-error continue 2
Router#

Scheduling Online Diagnostics


You can schedule online diagnostics to run at a designated time of day or on a daily, weekly, or monthly
basis. You can schedule tests to run only once or to repeat at an interval. Use the no form of this
command to remove the scheduling.
To schedule online diagnostics, perform this task:

Command Purpose
Router(config)# diagnostic schedule module number Schedules on-demand diagnostic tests on the specified
test {test_id | test_id_range | all} [port {num | module for a specific date and time, how many times to run
num_range | all}] {on mm dd yyyy hh:mm} | {daily
hh:mm} | {weekly day_of_week hh:mm}
(iterations), and what action to take when errors are found.

Cisco IOS Software Configuration Guide, Release 12.2SX


12-4 OL-13013-06
Chapter 12 Configuring Online Diagnostics
Running Online Diagnostic Tests

This example shows how to schedule diagnostic testing on a specific date and time for a specific port on
module 1:
Router(config)# diagnostic schedule module 1 test 1,2,5-9 port 3 on january 3 2003 23:32
Router(config)#

This example shows how to schedule diagnostic testing to occur daily at a certain time for a specific port:
Router(config)# diagnostic schedule module 1 test 1,2,5-9 port 3 daily 12:34
Router(config)#

This example shows how to schedule diagnostic testing to occur weekly on a certain day for a specific port:
Router(config)# diagnostic schedule module 1 test 1,2,5-9 port 3 weekly friday 09:23
Router(config)#

Configuring Health-Monitoring Diagnostics


You can configure health-monitoring diagnostic testing while the switch is connected to a live network.
You can configure the execution interval for each health-monitoring test, the generation of a system
message upon test failure, or the enabling or disabling an individual test. Use the no form of this
command to disable testing.
To configure health-monitoring diagnostic testing, perform this task:

Command Purpose
Step 1 Router(config)# diagnostic monitor interval module Configures the health-monitoring interval of the specified
number test {test_id | test_id_range | all} [hour tests. The no form of this command will change the
hh] [min mm] [second ss] [millisec ms] [day day]
interval to the default interval, or zero.
Step 2 Router(config)#[no] diagnostic monitor module Enables or disables health-monitoring diagnostic tests.
number test {test_id | test_id_range | all}
Step 3 Router# show diagnostic health Displays the output for the health checks performed.

This example shows how to configure the specified test to run every two minutes on module 1:
Router(config)# diagnostic monitor interval module 1 test 1 min 2
Router(config)#

This example shows how to run the test if health monitoring has not previously been enabled:
Router(config)# diagnostic monitor module 1 test 1

This example shows how to enable the generation of a syslog message when any health-monitoring test
fails:
Router(config)# diagnostic monitor syslog
Router(config)#

Running Online Diagnostic Tests


After you configure online diagnostics, you can start or stop diagnostic tests or display the test results.
You can also see which tests are configured and what diagnostic tests have already run.
These sections describe how to run online diagnostic tests after they have been configured:
Starting and Stopping Online Diagnostic Tests, page 12-6

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 12-5
Chapter 12 Configuring Online Diagnostics
Running Online Diagnostic Tests

Running All Online Diagnostic Tests, page 12-7


Displaying Online Diagnostic Tests and Test Results, page 12-7

Note We recommend that before you enable any online diagnostics tests that you enable the logging
console/monitor to see all warning messages.
We recommend that when you are running disruptive tests that you only run the tests when
connected through the console. When disruptive tests are complete, a warning message on the
console recommends that you reload the system to return to normal operation. Strictly follow this
warning.
While tests are running, all ports are shut down because a stress test is being performed with ports
configured to loop internally; external traffic might alter the test results. The switch must be
rebooted to bring the switch to normal operation. When you issue the command to reload the switch,
the system will ask you if the configuration should be saved. Do not save the configuration.
If you are running the tests on a supervisor engine, after the test is initiated and complete, you must
reload or power down and then power up the entire system.
If you are running the tests on a switching module, rather than the supervisor engine, after the test
is initiated and complete, you must reset the switching module.

Starting and Stopping Online Diagnostic Tests


After you configure diagnostic tests to run, you can use the start and stop to begin or end a diagnostic
test.
To start or stop an online diagnostic command, perform one of these tasks:

Command Purpose
Router# diagnostic start module number test {test_id Starts a diagnostic test on a port or range of ports on the
| test_id_range | minimal | complete | basic | specified module.
per-port | non-disruptive
| all} [port {num | port#_range | all}]
Router# diagnostic stop module number Stops a diagnostic test on the specified module.

This example shows how to start a diagnostic test on module 1:


Router# diagnostic start module 1 test 5
Module 1:Running test(s) 5 may disrupt normal system operation
Do you want to run disruptive tests? [no]yes
00:48:14:Running OnDemand Diagnostics [Iteration #1] ...
00:48:14:%DIAG-SP-6-TEST_RUNNING:Module 1:Running TestNewLearn{ID=5} ...
00:48:14:%DIAG-SP-6-TEST_OK:Module 1:TestNewLearn{ID=5} has completed successfully
00:48:14:Running OnDemand Diagnostics [Iteration #2] ...
00:48:14:%DIAG-SP-6-TEST_RUNNING:Module 1:Running TestNewLearn{ID=5} ...
00:48:14:%DIAG-SP-6-TEST_OK:Module 1:TestNewLearn{ID=5} has completed successfully
Router#

This example shows how to stop a diagnostic test:


Router# diagnostic stop module 1
Router#

Cisco IOS Software Configuration Guide, Release 12.2SX


12-6 OL-13013-06
Chapter 12 Configuring Online Diagnostics
Running Online Diagnostic Tests

Running All Online Diagnostic Tests


You can run all diagnostic tests, disruptive and nondisruptive, at once with a single command. In this
case, all test dependencies will be handled automatically.

Note Running all online diagnostic tests will disrupt normal system operation. Reset the system after the
diagnostic start system test all command has completed.
Do not insert, remove, or power down modules or the supervisor while the system test is running.
Do not issue any diagnostic command other than the diagnostic stop system test all command while
the system test is running.
Make sure no traffic is running in background.

To start or stop all online diagnostic tests, perform one of these tasks:

Command Purpose
Router# diagnostic start system test all Executes all online diagnostic tests.
Router# diagnostic stop system test all Stops the execution of all online diagnostic tests.

This example shows how to start all online diagnostic tests:


Router# diagnostic start system test all
*************************************************************************
* WARNING: *
* 'diagnostic start system test all' will disrupt normal system *
* operation. The system requires RESET after the command *
* 'diagnostic start system test all' has completed prior to *
* normal use. *
* *
* IMPORTANT: *
* 1. DO NOT INSERT, OIR, or POWER DOWN Linecards or *
* Supervisor while system test is running. *
* *
* 2. DO NOT ISSUE ANY DIAGNOSTIC COMMAND except *
* "diagnostic stop system test all" while system test *
* is running. *
* *
* 3. PLEASE MAKE SURE no traffic is running in background. *
*************************************************************************
Do you want to continue? [no]:

Displaying Online Diagnostic Tests and Test Results


You can display the online diagnostic tests that are configured and check the results of the tests using
the following show commands:
show diagnostic content
show diagnostic health

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 12-7
Chapter 12 Configuring Online Diagnostics
Running Online Diagnostic Tests

To display the diagnostic tests that are configured, perform this task:

Command Purpose
show diagnostic {bootup level | content [module num] | Displays the test results of online diagnostics and lists
events [module num] [event-type event-type] | health | supported test suites.
ondemand settings | result [module num] [detail] |
schedule [module num]}

This example shows how to display the online diagnostics that are configured on module 1:
Router# show diagnostic content module 1

Module 1: Supervisor Engine 32 8GE (Active)

Diagnostics test suite attributes:


M/C/* - Minimal bootup level test / Complete bootup level test / NA
B/* - Basic ondemand test / NA
P/V/* - Per port test / Per device test / NA
D/N/* - Disruptive test / Non-disruptive test / NA
S/* - Only applicable to standby unit / NA
X/* - Not a health monitoring test / NA
F/* - Fixed monitoring interval test / NA
E/* - Always enabled monitoring test / NA
A/I - Monitoring is active / Monitoring is inactive
R/* - Power-down line cards and need reload supervisor / NA
K/* - Require resetting the line card after the test has completed / NA
T/* - Shut down all ports and need reload supervisor / NA

Test Interval Thre-


ID Test Name Attributes day hh:mm:ss.ms shold
==== ================================== ============ =============== =====
1) TestScratchRegister -------------> ***N****A*** 000 00:00:30.00 5
2) TestSPRPInbandPing --------------> ***N****A*** 000 00:00:15.00 10
3) TestTransceiverIntegrity --------> **PD****I*** not configured n/a
4) TestActiveToStandbyLoopback -----> M*PDSX**I*** not configured n/a
5) TestLoopback --------------------> M*PD*X**I*** not configured n/a
6) TestTxPathMonitoring ------------> M**N****A*** 000 00:00:02.00 10
7) TestNewIndexLearn ---------------> M**N****I*** 000 00:00:15.00 10
8) TestDontConditionalLearn --------> M**N****I*** 000 00:00:15.00 10
9) TestBadBpduTrap -----------------> M**D*X**I*** not configured n/a
10) TestMatchCapture ----------------> M**D*X**I*** not configured n/a
11) TestProtocolMatchChannel --------> M**D*X**I*** not configured n/a
12) TestFibDevices ------------------> M**N****I*** 000 00:00:15.00 10
13) TestIPv4FibShortcut -------------> M**N****I*** 000 00:00:15.00 10
14) TestL3Capture2 ------------------> M**N****I*** 000 00:00:15.00 10
15) TestIPv6FibShortcut -------------> M**N****I*** 000 00:00:15.00 10
16) TestMPLSFibShortcut -------------> M**N****I*** 000 00:00:15.00 10
17) TestNATFibShortcut --------------> M**N****I*** 000 00:00:15.00 10
18) TestAclPermit -------------------> M**N****I*** 000 00:00:15.00 10
19) TestAclDeny ---------------------> M**D*X**I*** not configured n/a
20) TestQoSTcam ---------------------> M**D*X**I*** not configured n/a
21) TestL3VlanMet -------------------> M**N****I*** 000 00:00:15.00 10
22) TestIngressSpan -----------------> M**N****I*** 000 00:00:15.00 10
23) TestEgressSpan ------------------> M**D*X**I*** not configured n/a
24) TestNetflowInlineRewrite --------> C*PD*X**I*** not configured n/a
25) TestTrafficStress ---------------> ***D*X**I**T not configured n/a
26) TestFibTcamSSRAM ----------------> ***D*X**IR** not configured n/a
27) TestAsicMemory ------------------> ***D*X**IR** not configured n/a
28) TestAclQosTcam ------------------> ***D*X**IR** not configured n/a
29) TestNetflowTcam -----------------> ***D*X**IR** not configured n/a
30) ScheduleSwitchover --------------> ***D*X**I*** not configured n/a

Cisco IOS Software Configuration Guide, Release 12.2SX


12-8 OL-13013-06
Chapter 12 Configuring Online Diagnostics
Running Online Diagnostic Tests

31) TestFirmwareDiagStatus ----------> M**N****I*** 000 00:00:15.00 10


32) TestAsicSync --------------------> ***N****A*** 000 00:00:15.00 10
33) TestUnusedPortLoopback ----------> **PN****A*** 000 00:01:00.00 10
34) TestErrorCounterMonitor ---------> ***N****A*** 000 00:00:30.00 10
35) TestPortTxMonitoring ------------> **PN****A*** 000 00:01:15.00 5
36) TestL3HealthMonitoring ----------> ***N**FEA*** 000 00:00:05.00 10
37) TestCFRW ------------------------> M*VN*X**I*** not configured n/a

Router#

This example shows how to display the online diagnostic results for module 1:
Router# show diagnostic result module 1
Current bootup diagnostic level: bypass

Module 1: Cisco ME 6524 Ethernet Switch SerialNo : CAT103956WS

Overall Diagnostic Result for Module 1 : MINOR ERROR


Diagnostic level at card bootup: bypass

Test results: (. = Pass, F = Fail, U = Untested)

1) TestSPRPInbandPing --------------> .
2) TestTransceiverIntegrity:

Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
----------------------------------------------------------------------------
U U U U U U U U U U U U U U U U U U U U U U U U

Port 25 26 27 28 29 30 31 32
----------------------------
. . U U U U U .

3) TestScratchRegister -------------> .
4) TestNonDisruptiveLoopback:

Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
----------------------------------------------------------------------------
. . . . . . . . . . . . . . . . . . . . . . . .

Port 25 26 27 28 29 30 31 32
----------------------------
U U U U U U U U

5) TestLoopback:

Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
----------------------------------------------------------------------------
. F . . . . . . . . . . . . . . . . . . . . . .

Port 25 26 27 28 29 30 31 32
----------------------------
. . . . . . . .

6) TestNewIndexLearn ---------------> .
7) TestDontConditionalLearn --------> .
8) TestBadBpduTrap -----------------> .
9) TestMatchCapture ----------------> .
10) TestProtocolMatchChannel --------> .
11) TestFibDevices ------------------> .
12) TestIPv4FibShortcut -------------> .

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 12-9
Chapter 12 Configuring Online Diagnostics
Running Online Diagnostic Tests

13) TestL3Capture2 ------------------> .


14) TestIPv6FibShortcut -------------> .
15) TestMPLSFibShortcut -------------> .
16) TestNATFibShortcut --------------> .
17) TestAclPermit -------------------> .
18) TestAclDeny ---------------------> .
19) TestQoSTcam ---------------------> .
20) TestL3VlanMet -------------------> .
21) TestIngressSpan -----------------> .
22) TestEgressSpan ------------------> .
23) TestNetflowInlineRewrite:

Port 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
----------------------------------------------------------------------------
U U U U U U U U U U U U U U U U U U U U U U U U

Port 25 26 27 28 29 30 31 32
----------------------------
U U U U U U U U

24) TestTrafficStress ---------------> U


25) TestFibTcamSSRAM ----------------> U
26) TestAsicMemory ------------------> U
27) TestLtlFpoeMemoryConsistency ----> .
28) TestAclQosTcam ------------------> U
29) TestNetflowTcam -----------------> U
30) FirmwareDiagStatus --------------> .
31) TestL3HealthMonitoring ----------> .
32) TestCFRW:

Device 1
---------
.

33) TestRwEngineOverSubscription ----> U

Router#

This example shows how to display the detailed online diagnostic results for module 1:
Router# show diagnostic result module 1 detail
Current bootup diagnostic level:minimal

Module 1:

Overall Diagnostic Result for Module 1 :PASS


Diagnostic level at card bootup:minimal

Test results:(. = Pass, F = Fail, U = Untested)

___________________________________________________________________________

1) TestScratchRegister -------------> .

Error code ------------------> 0 (DIAG_SUCCESS)


Total run count -------------> 330
Last test execution time ----> May 12 2003 14:49:36
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 12 2003 14:49:36
Total failure count ---------> 0

Cisco IOS Software Configuration Guide, Release 12.2SX


12-10 OL-13013-06
Chapter 12 Configuring Online Diagnostics
Running Online Diagnostic Tests

Consecutive failure count ---> 0


___________________________________________________________________________

2) TestSPRPInbandPing --------------> .

Error code ------------------> 0 (DIAG_SUCCESS)


Total run count -------------> 660
Last test execution time ----> May 12 2003 14:49:38
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> May 12 2003 14:49:38
Total failure count ---------> 0
Consecutive failure count ---> 0
___________________________________________________________________________

3) TestGBICIntegrity:

Port 1 2
----------
U U

Error code ------------------> 0 (DIAG_SUCCESS)


Total run count -------------> 0
Last test execution time ----> n/a
First test failure time -----> n/a
Last test failure time ------> n/a
Last test pass time ---------> n/a
Total failure count ---------> 0
Consecutive failure count ---> 0
________________________________________________________________________
.
.
.

Router#

This example shows how to display the output for the health checks performed:
Router# show diagnostic health
CPU utilization for the past 5 mins is greater than 70%
five minutes: 81%
EARL reset history:
Module 5: WS-SUP720-BASE EARL patch log -
Num. of times patch applied : 0
Num. of times patch requested : 0
Non-zero port counters for 1/8 -
13. linkChange = 159810
Non-zero port counters for 1/9 -
0. rxCRCAlignErrors = 5
3. rxFragmentPkts = 9
6. ifInErrors = 46
13. linkChange = 1
Current bootup diagnostic level: minimal
Test results: (. = Pass, F = Fail, U = Untested)
36) TestErrorCounterMonitor ---------> F
Error code ------------------> 1 (DIAG_FAILURE)
Total run count -------------> 29
Last test execution time ----> Mar 16 2007 19:04:02
First test failure time -----> Mar 16 2007 19:03:21
Last test failure time ------> Mar 16 2007 19:04:02
Last test pass time ---------> Mar 16 2007 19:03:19
Total failure count ---------> 4
Consecutive failure count ---> 4

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 12-11
Chapter 12 Configuring Online Diagnostics
Performing Memory Tests

Error Records as following.


ID -- Asic Identification
IN -- Asic Instance
PO -- Asic Port Number
RE -- Register Identification
RM -- Register Identification More
EG -- Error Group
DV -- Delta Value
CF -- Consecutive Failure
TF -- Total Failure
ID IN PO RE RM DV EG CF TF
---------------------------------------------------------------
26 0 0 338 255 256 2 13 13
26 0 0 344 255 256 2 13 13
26 0 0 358 255 256 2 13 13
System Memory: 524288K total, 353225K used, 171063K free, 1000K kernel reserved
Lowest(b) : 171020288
Process kernel, type POSIX, PID = 1
0K total, 0K text, 0K data, 0K stack, 0K dynamic
Process sbin/chkptd.proc, type POSIX, PID = 16386
2296K total, 1988K text, 120K data, 12K stack, 176K dynamic
65536 heapsize, 55356 allocated, 8084 free
Router#

Performing Memory Tests


Most online diagnostic tests do not need any special setup or configuration. However, the memory tests,
which include the TestFibTcamSSRAM and TestLinecardMemory tests, have some required tasks and
some recommended tasks that you should complete before running them.
Before you run any of the online diagnostic memory tests, perform the following tasks:
Required tasks
Isolate network traffic by disabling all connected ports.
Do not send test packets during a memory test.
Reset the system before returning the system to normal operating mode.
Turn off all background health-monitoring tests using the no diagnostic monitor module number
test all command.

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

Cisco IOS Software Configuration Guide, Release 12.2SX


12-12 OL-13013-06
CH A P T E R 13
Configuring Onboard Failure Logging

This chapter describes how to configure Onboard Failure Logging (OBFL) in


Cisco IOS Release 12.2SX. Release 12.2(33)SXH and later releases support OBFL.

Note For complete syntax and usage information for the commands used in this chapter, see the Cisco IOS
Master Command List, Release 12.2SX, at this URL:
http://www.cisco.com/en/US/docs/ios/mcl/122sxmcl/12_2sx_mcl_book.html

Tip For additional information about Cisco Catalyst 6500 Series Switches (including configuration examples
and troubleshooting information), see the documents listed on this page:
http://www.cisco.com/en/US/products/hw/switches/ps708/tsd_products_support_series_home.html

This chapter consists of these sections:


Understanding OBFL, page 13-1
Restrictions for OBFL, page 13-9
Enabling OBFL, page 13-9
Configuration Examples for OBFL, page 13-10

Understanding OBFL
These sections describe OBFL:
Overview of OBFL, page 13-2
Data Collected by OBFL, page 13-2

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 13-1
Chapter 13 Configuring Onboard Failure Logging
Understanding OBFL

Overview of OBFL
The Onboard Failure Logging (OBFL) feature collects data such as operating temperatures, hardware
uptime, interrupts, and other important events and messages from system hardware installed in a Cisco
router or switch. The data is stored in nonvolatile memory and helps technical personnel diagnose
hardware problems.

Data Collected by OBFL


The OBFL feature records operating temperatures, hardware uptime, interrupts, and other important
events and messages that can assist with diagnosing problems with hardware cards (or modules) installed
in a Cisco router or switch. Data is logged to files stored in nonvolatile memory. When the onboard
hardware is started up, a first record is made for each area monitored and becomes a base value for
subsequent records. The OBFL feature provides a circular updating scheme for collecting continuous
records and archiving older (historical) records, ensuring accurate data about the system. Data is
recorded in one of two formats: continuous information that displays a snapshot of measurements and
samples in a continuous file, and summary information that provides details about the data being
collected. The data is displayed using the show logging onboard command. The message No historical
data to display is seen when historical data is not available.
The following sections describe the type of data collected:
Temperature, page 13-2
Operational Uptime, page 13-4
Interrupts, page 13-7
Message Logging, page 13-8

Temperature
Temperatures surrounding hardware modules can exceed recommended safe operating ranges and cause
system problems such as packet drops. Higher than recommended operating temperatures can also
accelerate component degradation and affect device reliability. Monitoring temperatures is important for
maintaining environmental control and system reliability. Once a temperature sample is logged, the
sample becomes the base value for the next record. From that point on, temperatures are recorded either
when there are changes from the previous record or if the maximum storage time is exceeded.
Temperatures are measured and recorded in degrees Celsius.

Temperature Example
--------------------------------------------------------------------------------
TEMPERATURE SUMMARY INFORMATION
--------------------------------------------------------------------------------
Number of sensors : 12
Sampling frequency : 5 minutes
Maximum time of storage : 120 minutes
--------------------------------------------------------------------------------
Sensor | ID | Maximum Temperature 0C
--------------------------------------------------------------------------------
MB-Out 980201 43
MB-In 980202 28
MB 980203 29
MB 980204 38
EARL-Out 910201 0
EARL-In 910202 0

Cisco IOS Software Configuration Guide, Release 12.2SX


13-2 OL-13013-06
Chapter 13 Configuring Onboard Failure Logging
Understanding OBFL

SSA 1 980301 38
SSA 2 980302 36
JANUS 1 980303 36
JANUS 2 980304 35
GEMINI 1 980305 0
GEMINI 2 980306 0
---------------------------------------------------------------
Temp Sensor ID
0C 1 2 3 4 5 6 7 8 9 10 11 12
---------------------------------------------------------------
No historical data to display
---------------------------------------------------------------
--------------------------------------------------------------------------------
TEMPERATURE CONTINUOUS INFORMATION
--------------------------------------------------------------------------------
Sensor | ID |
--------------------------------------------------------------------------------
MB-Out 980201
MB-In 980202
MB 980203
MB 980204
EARL-Out 910201
EARL-In 910202
SSA 1 980301
SSA 2 980302
JANUS 1 980303
JANUS 2 980304
GEMINI 1 980305
GEMINI 2 980306

-------------------------------------------------------------------------------
Time Stamp |Sensor Temperature 0C
MM/DD/YYYY HH:MM:SS | 1 2 3 4 5 6 7 8 9 10 11 12
-------------------------------------------------------------------------------
03/06/2007 22:32:51 31 26 27 27 NA NA 33 32 30 29 NA NA
03/06/2007 22:37:51 43 28 29 38 NA NA 38 36 36 35 NA NA
-------------------------------------------------------------------------------

To interpret this data:


Number of sensors is the total number of temperature sensors that will be recorded. A column for
each sensor is displayed with temperatures listed under the number of each sensor, as available.
Sampling frequency is the time between measurements.
Maximum time of storage determines the maximum amount of time, in minutes, that can pass when
the temperature remains unchanged and the data is not saved to storage media. After this time, a
temperature record will be saved even if the temperature has not changed.
The Sensor column lists the name of the sensor.
The ID column lists an assigned identifier for the sensor.
Maximum Temperature 0C shows the highest recorded temperature per sensor.
Temp indicates a recorded temperature in degrees Celsius in the historical record. Columns
following show the total time each sensor has recorded that temperature.
Sensor ID is an assigned number, so that temperatures for the same sensor can be stored together.

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 13-3
Chapter 13 Configuring Onboard Failure Logging
Understanding OBFL

Operational Uptime
The operational uptime tracking begins when the module is powered on, and information is retained for
the life of the module.

Operational Uptime Example


--------------------------------------------------------------------------------
UPTIME SUMMARY INFORMATION
--------------------------------------------------------------------------------
First customer power on : 03/06/2007 22:32:51
Total uptime : 0 years 0 weeks 2 days 18 hours 10 minutes
Total downtime : 0 years 0 weeks 0 days 8 hours 7 minutes
Number of resets : 130
Number of slot changes : 16
Current reset reason : 0xA1
Current reset timestamp : 03/07/2007 13:29:07
Current slot : 2
Current uptime : 0 years 0 weeks 1 days 7 hours 0 minutes
--------------------------------------------------------------------------------
Reset | |
Reason | Count |
--------------------------------------------------------------------------------
0x5 64
0x6 62
0xA1 4
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
UPTIME CONTINUOUS INFORMATION
--------------------------------------------------------------------------------
Time Stamp | Reset | Uptime
MM/DD/YYYY HH:MM:SS | Reason | years weeks days hours minutes
--------------------------------------------------------------------------------
03/06/2007 22:32:51 0xA1 0 0 0 0 0
--------------------------------------------------------------------------------

The operational uptime application tracks the following events:


Date and time the customer first powered on a component.
Total uptime and downtime for the component in years, weeks, days, hours, and minutes.
Total number of component resets.
Total number of slot (module) changes.
Current reset timestamp to include the date and time.
Current slot (module) number of the component.
Current uptime in years, weeks, days, hours, and minutes.
Reset reason; see Table 13-1 to translate the numbers displayed.
Count is the number of resets that have occurred for each reset reason.

Table 13-1 Reset Reason Codes and Explanations

Reset Reason
Code (in hex) Component/Explanation
0x01 Chassis on
0x02 Line card hot plug in

Cisco IOS Software Configuration Guide, Release 12.2SX


13-4 OL-13013-06
Chapter 13 Configuring Onboard Failure Logging
Understanding OBFL

Table 13-1 Reset Reason Codes and Explanations

Reset Reason
Code (in hex) Component/Explanation
0x03 Supervisor requests line card off or on
0x04 Supervisor requests hard reset on line card
0x05 Line card requests Supervisor off or on
0x06 Line card requests hard reset on Supervisor
0x07 Line card self reset using the internal system register
0x08
0x09
0x0A Momentary power interruption on the line card
0x0B
0x0C
0x0D
0x0E
0x0F
0x10
0x11 Off or on after Supervisor non-maskable interrupts (NMI)
0x12 Hard reset after Supervisor NMI
0x13 Soft reset after Supervisor NMI
0x14
0x15 Off or on after line card asks Supervisor NMI
0x16 Hard reset after line card asks Supervisor NMI
0x17 Soft reset after line card asks Supervisor NMI
0x18
0x19 Off or on after line card self NMI
0x1A Hard reset after line card self NMI
0x1B Soft reset after line card self NMI
0x21 Off or on after spurious NMI
0x22 Hard reset after spurious NMI
0x23 Soft reset after spurious NMI
0x24
0x25 Off or on after watchdog NMI
0x26 Hard reset after watchdog NMI
0x27 Soft reset after watchdog NMI
0x28
0x29 Off or on after parity NMI
0x2A Hard reset after parity NMI

Cisco IOS Software Configuration Guide, Release 12.2SX


OL-13013-06 13-5
Chapter 13 Configuring Onboard Failure Logging
Understanding OBFL

Table 13-1 Reset Reason Codes and Explanations

Reset Reason
Code (in hex) Component/Explanation
0x2B Soft reset after parity NMI
0x31 Off or on after system fatal interrupt
0x32 Hard reset after system fatal interrupt
0x33 Soft reset after system fatal interrupt
0x34
0x35 Off or on after application-specific integrated circuit (ASIC) interrupt
0x36 Hard reset after ASIC interrupt
0x37 Soft reset after ASIC interrupt
0x38
0x39 Off or on after unknown interrupt
0x3A Hard reset after unknown interrupt
0x3B Soft reset after unknown interrupt
0x41 Off or on after CPU exception
0x42 Hard reset after CPU exception
0x43 Soft reset after CPU exception
0xA1 Reset data converted to generic data

Cisco IOS Software Configuration Guide, Release 12.2SX


13-6 OL-13013-06
Chapter 13 Configuring Onboard Failure Logging
Understanding OBFL

Interrupts
Interrupts are generated by system components that require attention from the CPU such as ASICs and
NMIs. Interrupts are generally related to hardware limit conditions or errors that need to be corrected.
The continuous format records each time a component is interrupted, and this record is stored and used
as base information for subsequent records. Each time the list is saved, a timestamp is added. Time
differences from the previous interrupt are counted, so that technical personnel can gain a complete
record of the components operational history when an error occurs.

Interrupts Example
--------------------------------------------------------------------------------
INTERRUPT SUMMARY INFORMATION
--------------------------------------------------------------------------------
Name | ID | Offset | Bit | Count
--------------------------------------------------------------------------------
No historical data to display
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
CONTINUOUS INTERRUPT INFORMATION
--------------------------------------------------------------------------------
MM/DD/YYYY HH:MM:SS mmm | Name | ID